[prev in list] [next in list] [prev in thread] [next in thread]
List: nix-dev
Subject: Re: [Nix-dev] Too many open issues
From: obadz <obadz-nix () obadz ! com>
Date: 2016-07-22 18:28:26
Message-ID: CAFB71a64CsVTH3J1VypJ88bZ+EgXL51v3b83GfNyZLB2OPUTWA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Jul 22, 2016 at 6:21 PM, Guillaume Maudoux (Layus) <
layus.on@gmail.com> wrote:
> Furthermore, I think that every issue should be assigned to someone. Being
> assigned to an issue would mean that you are responsible for its progress,
> like pinging the maintainers, not for fixing the problem by yourself (but
> you still can).
>
I think this is a key point. While we can't really hope for 0 open
issues/PR, maybe we should be striving towards 0 unassigned issues/PR.
May I suggest a policy where we "liberally" assign issues/PR to each other.
The lifecycle of an issue/PR would then look something like this:
- First triager comes up with his best guess as to who could be useful
on the issue/PR, maybe based on `git log`
- First assignee may decide that he isn't the best person to look at
this and reassigns further
- Hopefully the iterative process lets assignment converge towards the
right expert
Of course the downside of such a process is that major contributors whose
time is already stretched thin are going to end up with a
disproportionately high share of issues/PRs assigned to them. However they
are also most likely to know who is capable of tackling the issue/PR and
further re-assign it, or to request help by adding a tag like `status:
need-help`?
The key here would be that we shouldn't get rattled if we get assigned an
issue/PR. All it means is "I think you know more about this than I do, feel
free to pass it on to someone else if aren't the right person or can't
handle this with the appropriate urgency".
Thoughts?
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 22, 2016 \
at 6:21 PM, Guillaume Maudoux (Layus) <span dir="ltr"><<a \
href="mailto:layus.on@gmail.com" target="_blank">layus.on@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Furthermore, \
I think that every issue should be assigned to someone. Being assigned to an issue \
would mean that you are responsible for its progress, like pinging the maintainers, \
not for fixing the problem by yourself (but you still \
can).<br></blockquote><div><br></div><div>I think this is a key point. While we \
can't really hope for 0 open issues/PR, maybe we should be striving towards 0 \
unassigned issues/PR.</div><div><br></div><div>May I suggest a policy where we \
"liberally" assign issues/PR to each other. The lifecycle of an issue/PR \
would then look something like this:</div><div><ul><li>First triager comes up with \
his best guess as to who could be useful on the issue/PR, maybe based on `git \
log`</li><li>First assignee may decide that he isn't the best person to look at \
this and reassigns further</li><li>Hopefully the iterative process lets assignment \
converge towards the right expert</li></ul><div>Of course the downside of such a \
process is that major contributors whose time is already stretched thin are going to \
end up with a disproportionately high share of issues/PRs assigned to them. However \
they are also most likely to know who is capable of tackling the issue/PR and further \
re-assign it, or to request help by adding a tag like `status: \
need-help`?</div><div><br></div><div>The key here would be that we shouldn't get \
rattled if we get assigned an issue/PR. All it means is "I think you know more \
about this than I do, feel free to pass it on to someone else if aren't the right \
person or can't handle this with the appropriate \
urgency".</div></div><div><br></div><div>Thoughts?</div></div></div></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