[prev in list] [next in list] [prev in thread] [next in thread]
List: nix-dev
Subject: Re: [Nix-dev] Too many open issues
From: Azul <mail () azulinho ! com>
Date: 2016-07-22 17:19:14
Message-ID: CAMP=owj9G5Py8uRfbQTQgmg-C67ag_6HqmwYzXVEaeTgwgRLVw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
triage exists to help manipulating a backlog, it is just another tool to
make sure team members are only working valuable issues and not spend the
time bikshedding, it also prevents duplication.
auto-closing issues due to being no longer applicable, or simply to reduce
the size of the backlog is another tool.
theming or (tagging) issues another process that helps to keep team members
with knowhow in a particular area aligned with the issues they care or are
able to fix in the shortest amount of time compared to other
dev/maintainers in the team.
voting is another good way to measure how important an issue is for a
number of users.
with these processes in place, someone responsible for managing the backlog
can look to every issue opened and work their way to reduce the overall
size of that backlog. then, it can be tagged and grouped into themes,
languages, maintainers, expertise and so on so that maintainers can find
then quickly.
if the backlog is then sorted by votes, common sense or other means then it
can be sliced and batched so that there is always a chunk of issues
available to be worked on ( attempt readers probably noticed by now I am a
kanban boy).
open source prj on github have the best tooling available to manage these
workflows, tools like the 'autoclose machine' mentioned here, zenhub for
managing work in progress in a simple board and others are out there and
usually free for open source projects.
from this thread it seems to me that the most useful action would be to
nominate someone to manage that backlog and make a constant effort to bring
it down to a workable size, and always ordered by the ones that need to be
tackled first.
On 22 Jul 2016 17:58, "Guillaume Maudoux (Layus)" <layus.on@gmail.com>
wrote:
> Hi,
>
> I have tried code triage for some weeks, and finally stopped using it.
>
> Yes, it allows to spread attention to many issues, but many issues do not
> need attention, either because they are already in progress, or because
> nobody really cares.
>
> Some issues are even weirder, like the 200 issues opened automatically fo=
r
> wiki migration. These are the only one that could benefit from auto close=
.
>
> Codetriage is not the solution, and not really a solution.
>
> Regards,
>
> -- Layus.
>
> Le 22 juillet 2016 20:12:18 UTC+07:00, Kevin Cox <kevincox@kevincox.ca> a
> =C3=A9crit :
>>
>> On 22/07/16 08:55, Alexey Shmalko wrote:
>>
>>> This one: https://www.codetriage.com/nixos/nixpkgs
>>
>>
>>
>> That's it! I have subscribed to get a couple issues a day so hopefully I
>> can help a bit. This site seems like a nice way to spread the load.
>>
>> It's open source too, and I just opened an issue asking them to
>> implement filters as I'm not really interesting in seeing in-progress
>> issues.
>>
>> https://github.com/codetriage/codetriage/issues/498
>>
>>
>> ------------------------------
>>
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
> _______________________________________________
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
[Attachment #5 (text/html)]
<p dir="ltr">triage exists to help manipulating a backlog, it is just another tool to \
make sure team members are only working valuable issues and not spend the time \
bikshedding, it also prevents duplication.<br> auto-closing issues due to being no \
longer applicable, or simply to reduce the size of the backlog is another tool.<br> \
theming or (tagging) issues another process that helps to keep team members with \
knowhow in a particular area aligned with the issues they care or are able to fix in \
the shortest amount of time compared to other dev/maintainers in the team.<br> voting \
is another good way to measure how important an issue is for a number of users.<br> \
with these processes in place, someone responsible for managing the backlog can look \
to every issue opened and work their way to reduce the overall size of that backlog. \
then, it can be tagged and grouped into themes, languages, maintainers, expertise and \
so on so that maintainers can find then quickly. <br> if the backlog is then sorted \
by votes, common sense or other means then it can be sliced and batched so that there \
is always a chunk of issues available to be worked on ( attempt readers probably \
noticed by now I am a kanban boy).</p> <p dir="ltr">open source prj on github have \
the best tooling available to manage these workflows, tools like the 'autoclose \
machine' mentioned here, zenhub for managing work in progress in a simple board \
and others are out there and usually free for open source projects.</p> <p \
dir="ltr">from this thread it seems to me that the most useful action would be to \
nominate someone to manage that backlog and make a constant effort to bring it down \
to a workable size, and always ordered by the ones that need to be tackled first. \
</p> <div class="gmail_quote">On 22 Jul 2016 17:58, "Guillaume Maudoux \
(Layus)" <<a href="mailto:layus.on@gmail.com">layus.on@gmail.com</a>> \
wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi,<br> <br>
I have tried code triage for some weeks, and finally stopped using it.<br>
<br>
Yes, it allows to spread attention to many issues, but many issues do not need \
attention, either because they are already in progress, or because nobody really \
cares.<br> <br>
Some issues are even weirder, like the 200 issues opened automatically for wiki \
migration. These are the only one that could benefit from auto close.<br> <br>
Codetriage is not the solution, and not really a solution.<br>
<br>
Regards,<br>
<br>
-- Layus.<br><br><div class="gmail_quote">Le 22 juillet 2016 20:12:18 UTC+07:00, \
Kevin Cox <<a href="mailto:kevincox@kevincox.ca" \
target="_blank">kevincox@kevincox.ca</a>> a écrit :<blockquote \
class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <pre>On 22/07/16 08:55, Alexey Shmalko \
wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex \
0.8ex;border-left:1px solid #729fcf;padding-left:1ex"> This one: <a \
href="https://www.codetriage.com/nixos/nixpkgs" \
target="_blank">https://www.codetriage.com/nixos/nixpkgs</a></blockquote><br><br>That's \
it! I have subscribed to get a couple issues a day so hopefully I<br>can help a bit. \
This site seems like a nice way to spread the load.<br><br>It's open source too, \
and I just opened an issue asking them to<br>implement filters as I'm not really \
interesting in seeing in-progress<br>issues.<br><br><a \
href="https://github.com/codetriage/codetriage/issues/498" \
target="_blank">https://github.com/codetriage/codetriage/issues/498</a><br><br><br></pre><p \
style="margin-top:2.5em;margin-bottom:1em;border-bottom:1px solid \
#000"></p><pre><hr><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" \
target="_blank">http://lists.science.uu.nl/mailman/listinfo/nix-dev</a><br></pre></blockquote></div></div><br>_______________________________________________<br>
nix-dev mailing list<br>
<a href="mailto:nix-dev@lists.science.uu.nl">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> \
<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