<br><br><div class="gmail_quote">On Tue, Mar 24, 2009 at 23:25, Tennessee Leeuwenburg <span dir="ltr"><<a href="mailto:tleeuwenburg@gmail.com">tleeuwenburg@gmail.com</a>></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 Wed, Mar 25, 2009 at 4:47 PM, Stephen J. Turnbull <span dir="ltr"><<a href="mailto:stephen@xemacs.org" target="_blank">stephen@xemacs.org</a>></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;">
<div>Brett Cannon writes:<br>
<br>
> What do other people think? If others are happy with Stage as it is then we<br>
> could add the "Needs docs" step along with "Needs backporting" and that<br>
> should fill in the gaps along with a "Needs Decision" keyword to help grab<br>
> the attention of core developers when people are stuck and need help with<br>
> deciding how to do something (should address Tennessee's desires).<br>
<br>
</div>There's plenty of stuff that "needs decision" being discussed on<br>
python-dev. Are committers really going to troll the tracker for the<br>
"needs decision" keyword?</blockquote><div><br></div></div><div>I'm not sure that "needs decision" does in fact address what I'm talking about, and I am also concerned that it would make the committers life harder. What I wanted wasn't a flag to get a committer's attention on the issue, but rather a flag for the committers not to waste their time until the issue has been bashed into shape. It's a flag that the people involved are still debating what to do about the issue, and it's not yet ready for higher consideration.</div>
<div><br></div><div>Under that model, I imagine the core committers would do what (I think) they have always done -- react to what is on python-dev, review patches when they are flagged as ready, and take up specific issues which are of interest to them.</div>
<div><br></div><div>I would use use the new flag when processing new issues often. I'm currently involved in a discussion about the implementation of additional operators for timedelta objects, for example. In this case there's a patch, but the functionality is still being debated amongst the group (it had been dormant for a while before I commented on it). If I want the input of a committer, there's nothing stopping me from posting to python-dev for more input. However, I would love to mark the issue as "under discussion" so that I can start categorising issues into two camps -- one which is ready for development and one which is not. For example, I'm considering building some sub-issues, some which deal with uncontroversial aspects of the parent issue, so that they can move forward, and others which will concentrate on the thorny bits. At the moment, all the new functionality is being blocked by the debate. </div>
<div><br></div><div>I feel that I have all the power I need to get more attention to this issue if I want, but what I can't do is exclude it from the list of "new" issues. It's not ready for any of the "stage" levels as yet, but it's not "fully up for grabs" either. It's in a pre-development, post-triage state.</div>
</div></blockquote><div><br>Well, it has been suggested to add a "confirmed" stage to say the issue has been triaged, but nothing more. After that committers can simply wait until an issue has reached "patch review" or "committer review" if triaging ends up working that well.<br>
<br>-Brett<br></div></div>