<br><br><div>On Thu May 08 2014 at 1:44:21 AM, Ezio Melotti <<a href="mailto:ezio.melotti@gmail.com">ezio.melotti@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, May 8, 2014 at 1:58 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> On 8 May 2014 01:59, "R. David Murray" <<a href="mailto:rdmurray@bitdance.com" target="_blank">rdmurray@bitdance.com</a>> wrote:<br>
>><br>
>> On Wed, 07 May 2014 08:09:03 -0700, Carol Willing<br>
>> <<a href="mailto:willingc@willingconsulting.com" target="_blank">willingc@willingconsulting.<u></u>com</a>> wrote:<br>
>> > I'm wondering if "decision needed" might be more accurately named<br>
>> > "triage needed"?<br>
>> ><br>
>> > Looking at David's well documented proposals and other mail comments,<br>
>> > "triage needed" more specifically describes the 'state'.<br>
>> ><br>
>> > A few thoughts:<br>
>> ><br>
>> > 1. "Triage needed" would raise the importance and visibility of the<br>
>> > triage contributor role. A positive for onboarding and growing<br>
>> > development talent.<br>
>> ><br>
>> > 2. "Triage needed" is more descriptive and clearer than "decision<br>
>> > needed" especially for those users that do not read documentation or<br>
>> > understand the development workflow. "Decision needed" implies that a<br>
>> > decision will be made to include or not include in a release.<br>
>> > Realistically, decisions are made throughout the remainder of the<br>
>> > development process based on time, resources, etc.<br>
>><br>
>> I'll be interested in what others think, but to me "decision needed" is<br>
>> closer than "triage needed".  That is, the state means that someone other<br>
>> than the person moving the issue to that state needs to make a decision.<br>
>> That decision can be "Is this something we consider a bug?  What releases<br>
>> can we fix this in given our backward compatibility requirements?<br>
>> Is this an acceptable enhancement?  And any other decision that needs<br>
>> to be made before the issue can move forward.<br>
>><br>
<br>
I agree.  To me "triaging" mostly means updating fields/metadata and<br>
it's something that is done once the issue is reported.  This also<br>
includes adding people to the nosy list so that they can comment and<br>
start dealing with the issues, but I don't consider this "triaging"<br>
anymore.  IOW "triage needed" would correspond to "- no selection -".<br>
OTOH, "decision needed" means that the people working on the issue<br>
need to reach an agreement.  A good example of this is<br>
<a href="http://bugs.python.org/issue18967" target="_blank">http://bugs.python.org/<u></u>issue18967</a>.  Here no triaging is needed IMHO.<br></blockquote><div><br></div><div>This is exactly the way I thought as well: the initial default state is "triage needed" and "decision needed" means someone higher up has to make a call on a question. Can we simply name the "no selection" state have the text "triage needed"?</div>
<div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>> All of these *can* be "triage" decisions, but to my ear it is the word<br>
>> "triage" that is more about deciding where to allocate resources ("which<br>
>> release"), whereas we generally don't work that way.  We just decide if<br>
>> it can go in or not, and if the patch is ready before the next release,<br>
>> it can go in.<br>
>><br>
>> More specifically, because I removed 'committer decision needed',<br>
>> 'decision needed' covers the case of needing a committer decision,<br>
>> which is by definition not a triage decision :)<br>
>><br>
>> Perhaps 'committer decision needed' should be kept after all?<br>
><br>
<br>
I don't think the distinction is useful.  Anyone can contribute to the<br>
discussion, as long as they don't just give their opinion and change<br>
the stage directly.  For example in <a href="http://bugs.python.org/issue18967" target="_blank">http://bugs.python.org/<u></u>issue18967</a><br>
a Mercurial dev could give his opinion, and if the others agree, the<br>
stage can be updated (to "needs patch" or "needs review" if a patch is<br>
already present).<br>
<br>
> From a work queue perspective, two separate states likely makes sense, since<br>
> "Triage needed" & "Committer decision needed" are aimed at slightly<br>
> different groups of people (with the latter being a subset of the former).<br>
> That way, "Committer decision needed" becomes a clear avenue for escalation<br>
> by triagers to the core developers when they need a design decision or risk<br>
> assessment on a particular approach.<br>
><br>
<br>
I would rather keep the list of stages short, i.e.:<br>
  - no selection -<br>
  information needed<br>
  decision needed<br>
  patch needed<br>
  review needed<br>
  commit (review) needed<br>
  resolved<br>
<br>
with the following meanings<br>
  - no selection -: issue hasn't been triaged/looked at yet<br>
  information needed: something needs to be confirmed/clarified before<br>
proceeding<br>
  decision needed: an agreement should be reached before taking action<br>
  patch needed: we know what to do, we need the code<br>
  review needed: we have the code, we need someone to review it<br>
  commit (review) needed: we have the code, we need a committer to commit it<br>
  resolved: issue is now closed<br>
<br>
These would be useful to (triagers also includes committers):<br>
  - no selection -: triagers (searching for untriaged issues)<br>
  information needed: original poster (probably not useful in searches)<br>
  decision needed: committers (and possibly triagers)<br>
  patch needed: everyone (people searching for issues that need patches)<br>
  review needed: triagers (searching for issues that need a review)<br>
  commit (review) needed: committers (searching for issues that are<br>
ready to go in)<br>
  resolved: everyone (people marveling at the outstanding work of our team)<br>
<br>
Also think how these stages would affect the dashboards (e.g.<br>
"information needed" should be prominent on the original poster's<br>
dashboard).<br>
<br>
<br>
To illustrate the possible evolution of an issue I made a couple of flow charts:<br>
   <a href="http://imgur.com/a/UgJBJ" target="_blank">http://imgur.com/a/UgJBJ</a><br>
<br>
The first is without "patch update needed" the second includes it.<br>
Also note that is possible to go from basically every state to<br>
"resolved", however I omitted those arrows, since they would just<br>
clutter the flow chart.  I'm not sure if this should be enforced<br>
(probably not), but at least it should provided a clearer picture.<br>
<br>
I left "decision needed", removed "patch update needed", and possibly<br>
removed the "review" from "commit review needed":<br>
  1) "decision needed" means that the problem is clear, but we have to<br>
discuss about the best solution.  To me, "triage needed" mostly means<br>
that the fields/metadata are not updated;<br>
  2) "patch update needed" seems redundant to me, and can be replaced<br>
with "patch needed" + "assigned to <previous patch author>".  I'm not<br>
strongly opposed about removing it though;<br>
  3) "commit review needed" seems useful to signal to core devs that<br>
someone reviewed the patch and it is now ready to be committed.  This<br>
assumes that the committer will do a further review, but if we already<br>
passed the "review needed" stage, there are good chances that the<br>
patch is ready to go in (if not we can always go back to "patch<br>
needed").  This can also be simply called "commit needed";<br>
<br>
<br>
> That more structured mechanism should nicely complement the option of<br>
> punting decisions to the collective wisdom (hah!) of python-dev &<br>
> python-ideas.<br>
><br>
> Cheers,<br>
> Nick.<br>
><br>
>><br>
>> --David<br>
______________________________<u></u>_________________<br>
core-workflow mailing list<br>
<a href="mailto:core-workflow@python.org" target="_blank">core-workflow@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/core-workflow" target="_blank">https://mail.python.org/<u></u>mailman/listinfo/core-workflow</a><br>
This list is governed by the PSF Code of Conduct: <a href="https://www.python.org/psf/codeofconduct" target="_blank">https://www.python.org/psf/<u></u>codeofconduct</a><br>
</blockquote>