>> Nowadays I consider it a lost cause when I file an issue on the opam- >> repository. >> >> I think this is an issue. >> >> I perfectly understand that from the point of view of repo maintainers the >> amount of issues (136 now) doesn't entice them to go through the backlog >> to try to fix or close them. However I believe that if we try to limit the >> backlog or tag them more appropriately there may be a better chance that >> issues do not simply get ignored. >> >> Going through the least recently updated issues: >> >> https://github.com/ocaml/opam- >> repository/issues?q=is%3Aopen+is%3Aissue+sort%3Aupdated-asc >> >> here are a few things that come to mind: >> >> 1. Kill that `request for package` tag. Being a developer-oriented package >> system I don't think the opam repository is the place to ask for >> packaging, people should ask upstream (I don't say this didn't make sense >> when opam was a baby). >> 2. Kill too open ended questions with the `question` tag. >> 3. Go through the `bug` tag. It seems a lot of old things can be closed. > > Agreed - I was briefly involved with Git-for-Windows. I disliked hugely the > way the principal maintainer runs that project, but one thing which was very > impressive was his rapid triage of issues. For standard FAQ questions, "we" > (i.e. a maintainer) should comment with the appropriate FAQ link (number 1 > would be advice either to contact upstream or a pointer to the packaging > instructions; number 2 would either link to the manual or a general FAQ to > open an issue on the appropriate docs repository; etc.) and immediately > *close* the issue. It doesn't prevent the poster from commenting a little > further, but it removes a "pointless" issue from the list as quickly as > possible. Also, if an issue was woefully lacking in required information, the > issue was closed, rather than requesting further information and leaving it > open. The OP can always re-open the issue having supplied further details (or > start a fresh one). > > If your issue survives that process, his next stage was tag it and determine > who was going to fix it - if it a maintainer volunteers, it's assigned; > otherwise if you don't agree to fix it, it's closed at once (happens with > feature requests more than bugs, obviously). > > Finally, about once a month, he'd go through old issues and ping them for > status - and close anything which seemed not to be making progress. > > It seems to me that for opam-repository a ruthless model would work well! Or, > as we can see, you can't see the wood for them trees... > >> 4. There seem to be a lot of old install glitches that I'm sure are no >> longer relevant. >> 5. There are a few open issues where people say that the problem is >> solved, they should be closed... >> >> I think we should walk up from the oldest issues and whenever things are >> are unclear tag them with `scheduled for closure` and comment that without >> any further feedback in 7 days, the issue will be closed. Also in general >> it would be nice to introduce tags to distinguish between repo >> organisation issues like [1] (may be long lived) and end-user repo install >> failures like [2] (should be short lived). > > Perhaps what is needed is a somewhat tedious day with maintainers in the same > (virtual) place, so that (brief) discussions can take place immediately, to > control the backlog?
I agree, I rarely look at the issue tracker and its current state makes me quite sad (these two are maybe related). Any help to triage these issues would be greatly appreciated. I will make a quick first scan to close the obvious ones. Thomas _______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
