Probably, we can all help maintainers, by reviewing our own issues, and probably closing them. For this we need to substitute USER with our github log in the following link:
https://github.com/ocaml/opam-repository/issues/created_by/USER Regards, Ivan On Tue, Sep 27, 2016 at 10:55 AM, Gabriel Scherer <[email protected] > wrote: > 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? > > > Maybe for another time, but have opam-repository maintainers and > contributors considered having an actual get-together event? Given the > current distribution, Cambridge or London could be good starting points. > (I'm personally stuck on the wrong side of the Atlantic before January, but > in general terms I would consider attending such an event. There would also > be interesting discussions to be had regarding opam 2.0 migration and > Conex.) > > On Tue, Sep 27, 2016 at 4:48 AM, Thomas Gazagnaire <[email protected]> > wrote: > >> >> 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 >> > > > _______________________________________________ > Platform mailing list > [email protected] > http://lists.ocaml.org/listinfo/platform > >
_______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
