[Nix-dev] Too many open issues

[Wout Mertens]

   - *Splitting the repo*: Indeed, losing history is bad, so no go. See
   below for alternative.
   - *Triage*: Good ideas to split the load. See below.
   - *Autoclose*: Still convinced we should use it. See below.

For *triage*, we can indeed triage by section (just add labels) and then
maintainers can filter by the labels they can work on.
Right now we have 515 issues without labels
<https://github.com/NixOS/nixpkgs/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20no%3Alabel>.
*Let's label them!*
We *need to make labels based on skillset* needed to fix. The topic labels
come close, but e.g. "topic: non-nixos" is not a skillset. "skill: bash"
and "skill: kernel" are. Labels are free, let's add all the ones that can
be useful for filtering.

*Splitting the repo* is not a good idea. However, some PRs are languishing
because it is unclear if they can be merged, and the persons that can make
the call are unresponsive. Using the C4 rules
<http://rfc.zeromq.org/spec:42/C4/#23-patch-requirements>, it is very *clear
when a PR can be merged*, and what needs to be done to make it mergeable.
Instead of splitting the repo, let's mark certain parts of the code as
"merge only when permission from core maintainers", and all the rest is
open for C4.

*Autoclosing* is like garbage collection. Auto-close and then reopening by
a response, is more efficient than triagers having to go in and decide if
something can be closed. We can add labels that prevent auto-close.
No warnings are needed btw, since responding reopens. A warning means two
mails instead of one.
*We should not be afraid of missing out on bugs or ideas*. They are
re-discovered all the time, and the good ones will be interesting enough to
stay open.

So, conclusion:

   1. We need to add *skillset labels*
   2. We need a *triager army* that apply labels to unlabeled issues
   3. *Maintainers use filters* to see their custom issue list
   4. Let's use C4 <http://rfc.zeromq.org/spec:42/C4/#23-patch-requirements>
   to *objectively decide mergeability*
   5. Let's run autoclose, starting with issues not updated for 6 months (205
   of them
   <https://github.com/NixOS/nixpkgs/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20%20updated%3A%3C%3D2016-01-23%20>
   )

I'll start a different email thread soliciting for skillset labels.

On Sat, Jul 23, 2016 at 3:22 AM Profpatsch <mail at profpatsch.de> wrote:

> On 16-07-22 09:59am, Michael Walker wrote:
> > If there are 1000+ open issues, it's hard to know what to prioritise.
> > If inactive issues get closed, it at least helps cut down on things
> > which may no longer be relevant (and if they are, someone finds the
> > closed issue, comments in it, and it opens again).
>
> I do think Github gives us the means for that.
> You can sort by activity, by age, by label, by reactions …
>
> To start triaging just sort by least recently updated
> and work from start to finish. ;)
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160723/a3e446dd/attachment.html>