[prev in list] [next in list] [prev in thread] [next in thread]
List: nix-dev
Subject: Re: [Nix-dev] Too many open issues
From: Wout Mertens <wout.mertens () gmail ! com>
Date: 2016-07-23 9:39:35
Message-ID: CAO3V83KLETM148GFCFDr+74jNOPU-R3xHRw0Pnw=VUHfri5o4g () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
- *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@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@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
[Attachment #5 (text/html)]
<div dir="ltr"><ul><li><b style="line-height:1.5">Splitting the repo</b><span \
style="line-height:1.5">: Indeed, losing history is bad, so no go. See below for \
alternative.</span><br></li><li><span style="line-height:1.5"><b>Triage</b>: Good \
ideas to split the load. See below.</span></li><li><span \
style="line-height:1.5"><b>Autoclose</b>: Still convinced we should use it. See \
below.</span></li></ul><div>For <b>triage</b>, we can indeed triage by section (just \
add labels) and then maintainers can filter by the labels they can work \
on.</div><div>Right now we have 515 <a \
href="https://github.com/NixOS/nixpkgs/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20no%3Alabel">issues \
without labels</a>. <b>Let's label them!</b></div><div>We <b>need to make labels \
based on skillset</b> 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.</div><div><br></div><div><b>Splitting the repo</b> 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 <a \
href="http://rfc.zeromq.org/spec:42/C4/#23-patch-requirements">the C4 rules</a>, it \
is very <b>clear when a PR can be merged</b>, and what needs to be done to make it \
mergeable.</div><div>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.</div><div><br></div><div><b>Autoclosing</b> 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.</div><div>No warnings are needed btw, since responding \
reopens. A warning means two mails instead of one.</div><div><b>We should not be \
afraid of missing out on bugs or ideas</b>. They are re-discovered all the time, and \
the good ones will be interesting enough to stay open.</div><div><br></div><div>So, \
conclusion:</div><div><ol><li><font size="2">We need to add <b>skillset \
labels</b></font></li><li><font size="2">We need a <b>triager army</b> that apply \
labels to unlabeled issues</font></li><li><font size="2"><b>Maintainers use \
filters</b> to see their custom issue list</font></li><li><font size="2">Let's \
use <a href="http://rfc.zeromq.org/spec:42/C4/#23-patch-requirements">C4</a> to \
<b>objectively decide mergeability</b></font></li><li><font size="2">Let's run \
autoclose, starting with issues not updated for 6 months (<a \
href="https://github.com/NixOS/nixpkgs/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20%20updated%3A%3C%3D2016-01-23%20">205 \
of them</a>)</font></li></ol><div><font size="2">I'll start a different email \
thread soliciting for skillset labels.</font></div></div></div><br><div \
class="gmail_quote"><div dir="ltr">On Sat, Jul 23, 2016 at 3:22 AM Profpatsch <<a \
href="mailto:mail@profpatsch.de">mail@profpatsch.de</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">On 16-07-22 09:59am, Michael Walker \
wrote:<br> > If there are 1000+ open issues, it's hard to know what to \
prioritise.<br> > If inactive issues get closed, it at least helps cut down on \
things<br> > which may no longer be relevant (and if they are, someone finds \
the<br> > closed issue, comments in it, and it opens again).<br>
<br>
I do think Github gives us the means for that.<br>
You can sort by activity, by age, by label, by reactions …<br>
<br>
To start triaging just sort by least recently updated<br>
and work from start to finish. ;)<br>
<br>
--<br>
Proudly written in Mutt with Vim on NixOS.<br>
Q: Why is this email five sentences or less?<br>
A: <a href="http://five.sentenc.es" rel="noreferrer" \
target="_blank">http://five.sentenc.es</a><br> May take up to five days to read your \
message. If it's urgent, call me.<br> \
_______________________________________________<br> nix-dev mailing list<br>
<a href="mailto:nix-dev@lists.science.uu.nl" \
target="_blank">nix-dev@lists.science.uu.nl</a><br> <a \
href="http://lists.science.uu.nl/mailman/listinfo/nix-dev" rel="noreferrer" \
target="_blank">http://lists.science.uu.nl/mailman/listinfo/nix-dev</a><br> \
</blockquote></div>
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic