[ocaml-platform] Improving the opam-repository issue tracker

[Gabriel Scherer]

A crisp related quote from Russ Albery on Debian's bug tracker, in the
September 22nd Linux Weekly News edition:

Debian's bug system is a tool we use to improve the distribution, not a
> user support channel.  We should not retain bugs that do not help us
> achieve that.  It would be great if it could also be a user support
> channel, but this is just unachievable for a volunteer-maintained
> distribution like Debian, and we should avoid creating the impression that
> we promise to do this.
>
>
http://lwn.net/Articles/700987/

On Tue, Sep 27, 2016 at 11:42 AM, Ivan Gotovchits <ivg at ieee.org> wrote:

> 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 <
> gabriel.scherer at gmail.com> 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 <thomas at gazagnaire.org
>> > 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
>>> Platform at lists.ocaml.org
>>> http://lists.ocaml.org/listinfo/platform
>>>
>>
>>
>> _______________________________________________
>> Platform mailing list
>> Platform at lists.ocaml.org
>> http://lists.ocaml.org/listinfo/platform
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20160927/25e3263b/attachment.html>