<div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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?</blockquote><div><br></div><div>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.)<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 27, 2016 at 4:48 AM, Thomas Gazagnaire <span dir="ltr"><<a href="mailto:thomas@gazagnaire.org" target="_blank">thomas@gazagnaire.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">>> Nowadays I consider it a lost cause when I file an issue on the opam-<br>
>> repository.<br>
>><br>
>> I think this is an issue.<br>
>><br>
>> I perfectly understand that from the point of view of repo maintainers the<br>
>> amount of issues (136 now) doesn't entice them to go through the backlog<br>
>> to try to fix or close them. However I believe that if we try to limit the<br>
>> backlog or tag them more appropriately there may be a better chance that<br>
>> issues do not simply get ignored.<br>
>><br>
>> Going through the least recently updated issues:<br>
>><br>
>> <a href="https://github.com/ocaml/opam-" rel="noreferrer" target="_blank">https://github.com/ocaml/opam-</a><br>
>> repository/issues?q=is%3Aopen+<wbr>is%3Aissue+sort%3Aupdated-asc<br>
>><br>
>> here are a few things that come to mind:<br>
>><br>
>> 1. Kill that `request for package` tag. Being a developer-oriented package<br>
>> system I don't think the opam repository is the place to ask for<br>
>> packaging, people should ask upstream (I don't say this didn't make sense<br>
>> when opam was a baby).<br>
>> 2. Kill too open ended questions with the `question` tag.<br>
>> 3. Go through the `bug` tag. It seems a lot of old things can be closed.<br>
><br>
> 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).<br>
><br>
> 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).<br>
><br>
> 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.<br>
><br>
> 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...<br>
><br>
>> 4. There seem to be a lot of old install glitches that I'm sure are no<br>
>> longer relevant.<br>
>> 5. There are a few open issues where people say that the problem is<br>
>> solved, they should be closed...<br>
>><br>
>> I think we should walk up from the oldest issues and whenever things are<br>
>> are unclear tag them with `scheduled for closure` and comment that without<br>
>> any further feedback in 7 days, the issue will be closed. Also in general<br>
>> it would be nice to introduce tags to distinguish between repo<br>
>> organisation issues like [1] (may be long lived) and end-user repo install<br>
>> failures like [2] (should be short lived).<br>
><br>
> 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?<br>
<br>
</div></div>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.<br>
<span class="HOEnZb"><font color="#888888"><br>
Thomas<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Platform mailing list<br>
<a href="mailto:Platform@lists.ocaml.org">Platform@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/platform" rel="noreferrer" target="_blank">http://lists.ocaml.org/<wbr>listinfo/platform</a><br>
</div></div></blockquote></div><br></div>