<br><br><div class="gmail_quote">On Mon, Mar 9, 2009 at 21:00, Tennessee Leeuwenburg <span dir="ltr">&lt;<a href="mailto:tleeuwenburg@gmail.com">tleeuwenburg@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div class="im">On Tue, Mar 10, 2009 at 2:39 PM, Brett Cannon <span dir="ltr">&lt;<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>&gt;</span> wrote:<br></div><div><div>
</div><div class="h5"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div>On Mon, Mar 9, 2009 at 20:25, Tennessee Leeuwenburg <span dir="ltr">&lt;<a href="mailto:tleeuwenburg@gmail.com" target="_blank">tleeuwenburg@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br><br>I am beginning reviewing some more issues in the tracker. I think it would be useful to have the following status options (new status options marked with a &#39;+&#39;):<br>  Open: Means that the issue has been created and not further reviewed<br>



  + Request Approved: Means that the issue is marked as worth further development by the community<br>  + Specification Approved: Means that the functionality to be developed is written down in some form, and agreed at least in general terms (preferably in fairly specific terms)<br>



  + Under Development: Means that an implementation is currently under development<br>  Pending Feedback: Means that work is suspended pending feedback<br>  + Under Final Review: Means that a patch has been submitted and may be a flag that core developers can usefully review the work done without having to revisit the whole process<br>



  Closed: Means that the issue is either suspended indefinitely or has been resolved (see resolution value)</blockquote></div><div><br> I assume you want all of this for the Status field, correct?<br><br>As for the options, some of these overlap with the Stage field. For instance, if something has been set to any stage other than &quot;accepted/rejected&quot; it means it needs to be looked into, so that duplicates your &quot;Request Approved&quot; status. Similar thing with the review stages and &quot;Under Final Review&quot;.<br>


<br>But a general &quot;under development&quot; status would probably be worth adding. That way if an issue is &quot;open&quot; it needs attention, &quot;Under development&quot; means someone is working on a solution, &quot;pending&quot; means someone is blocking the issue for more information, and &quot;closed&quot; means closed.<br>


<br>One thing to watch out for, Tennessee, is getting too specific. Like your &quot;Request Approved&quot; and &quot;Specification Approved&quot; just seems too heavy-handed to my tastes. Personally, I prefer to make sure the issue workflow to be somewhat simple so that people don&#39;t end up arguing over stuff like whether something has been specified well enough to have it set to &quot;Spec Approved&quot; even if someone else disagrees (which you know would happen).<br>


<br>-Brett</div></div></blockquote></div></div><div><br><div class="im">Hi Brett,<br><br>Some great points. The &quot;stage&quot; settings do overlap a
lot of what I had suggested. What I&#39;m trying to reach is a way to flag
quite clearly whether a tracker issue is:<br>
  * In need of a first response<br>  * Being taken care of by someone<br>  * Needs the attention of core developers, just about ready<br><br>At
the moment, the open/closed settings are a bit useless -- issues are
&quot;Open&quot; until they are finished, at which point they are &quot;Closed&quot;. I
personally suspect that &quot;Pending feedback&quot; is little-used.</div></div></div></blockquote><div><br>For now. But once auto-closing of pending issues is set up then it will get used consistently (don&#39;t ask me when that is happening, I just know Daniel and Martin have been talking about it).<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><div class="im"> At the
moment, many &quot;Open&quot; issues are in various states of maturity or
disrepair, so the only really useful information is whether an issue is
&quot;Closed&quot;. <br>
<br>Examining the stage options more closely, they are very
code-oriented.</div></div></div></blockquote><div><br>Right, because we are dealing with code. =)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div><div class="im"> Really they relate to implementation, not other parts of
the process. It&#39;s difficult for me as someone who wants to help out
with the Issue resolution process as much as coding to take an atomic
action to help advance the issue through a process. <br>
<br>What do you think about the following &quot;Status&quot; flags:<br><br>  * Open: Means newly-created, needs early attention<br>  * + Request for Comment: Means that a discussion regarding functionality is requested<br>


  * + Under Development: Means that a caring developer is taking care of it<br>  * Pending Feedback: blocking on new information<br>  * Closed: Means closed<br><br>Once the issue is marked as under development, more information is then provided by the &quot;Stage&quot; flag.<br>


<br>&quot;Request for Comment&quot; means that anyone who is stuck on trying to
get their ideas sorted or a loose specification agreed on can call for
feedback through this flag. There&#39;s still some risk of arguments
blocking the progression to &quot;Under development&quot;, but the issue owner
can at least pass to &quot;Under development&quot; at their own will without
requiring universal agreement.<br>
</div></div></div></blockquote><div><br>There is also a worry of abuse if anyone can set this. If only people in the Developer role can set this then that&#39;s fine. But if people start using this just to get attention because they are unhappy with how slowly something is going it will kill its usefulness.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><div class="im"><br>Core developers can then search on &#39;commit review&#39; or &#39;patch
review&#39; to see what could use their attention, while people who are
happy to contribute to the debate can search on &quot;Open&quot; and &quot;Request for
Comment&quot; issues. Obviously the RFC flag is redundant when an issue is
first raised, since the submitter always has the option of simply
emailing this list. However, for older, potentially stale issues, it is
a useful indicator that the issue may be either closed out or could use
refreshing.<br>
<br>I don&#39;t mind what approach is taken -- I&#39;m happy to work within the
current infrastructure if someone can suggest a good way. I really just
want to be able to start distinguishing between issues that are
essentially new and under debate versus issues that most people agree
are a &quot;Good Thing To Do&quot;, and then helping those issues advance to the
point of implementation by discussing and, if necessary, formalising or
recording requirements against them.<br></div></div></div></blockquote></div><br>I have always viewed it that if Stage is set to anything other than its empty default it is worth looking into. But it seems to me what you are after is some obvious way to disambiguate issues that are feature requests that someone has just asked for and anyone can work on if they want, and issues that require attention, i.e. bugs and patches. Is that accurate?<br>
<br>-Brett<br>