<br><br><div class="gmail_quote">On Tue, Mar 24, 2009 at 11:00 AM, "Martin v. Löwis" <span dir="ltr"><<a href="mailto:martin@v.loewis.de" target="_blank">martin@v.loewis.de</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>> That would be great. It occurs to me that if we wanted to use<br>
> "Stage" settings, it would be easy to search for issues which are<br>
> not closed by literally searching for 'not closed' rather than<br>
> 'open'. I think it's also unclear whether the 'pending' stage means<br>
> 'suspended pending additional user feedback' or 'resolution of this<br>
> issue is impending'. My understanding was that it meant 'pending<br>
> additional feedback' in the sense of awaiting, rather than imminent.<br>
><br>
><br>
> It's the latter; it's "pending feedback".<br>
<br>
</div>Which "latter" (there seem to be multiple pairs in Tennessee's message)?<br>
<br>
In any case, it's not really "pending feedback". Instead, it means "if<br>
there is no feedback really soon, it will get closed". So closure is<br>
impending and imminent.</blockquote><div><br></div></div>I think this indicates that the flag in not sufficiently self-descriptive. My understanding, and I think the understanding of some others, is that this flag indicates a suspension of development pending additional feedback, rather the impending conclusion of development pending further feedback. In some of my earlier emails to this list, other developers were happy to mark issues that were being deferred as a result of requiring further specification or clarification as "pending feedback", which is quite the opposite of imminent closure.<br>
<br>While some may feel that the use of this flag is unambiguously used to signify imminent closure, I respectfully point out the recent occasions where confusion has occurred, and not just from a single individual.<br><br>
Perhaps some developers have a well-established workflow and interpret these flag in a particular, consistent fashion, however part of the purpose of the issue tracker is to allow a diverse group to work on development as a group. On that basis, I feel that more documentation, and clearer terminology, is required in order to support the bug resolution process. <br>
<br>I have identified some gaps in the workflow process which impact me personally in classifying issues. These issues will not impact on all developers; clearly they will be entirely superfluous, perhaps even confusing, for some individuals. However the impact still remains for some. There appears to be a general agreement that ability to distinguish between issues on the following bases would be useful:<br>
* Whether the nature of the requirement is still under debate or whether it is well-understood<br> * Whether the issue is "up for grabs" by any developer or whether responsibility lies with an individual or group already<br>
* Whether the issue is ready for more serious consideration by more experienced or core developers<br><br>Since these issues relate primarily to the long-standing, dubious or complex issues which are not fully resolved, often of lower priority, it is apparent that more experienced developers will not find a lot of use in the addition of further flag, but I don't see that their workflow would be frustrated either.<br>
<br>I'm happy to put my time an effort into classification of low-priority issues, classification, and code development for areas which would probably not otherwise receive much attention. However, to do this effectively, I need to be able to set up additional parameters against the issues to support the search requirements needed. Doing this on the development tracker seems to be the best approach, seeing as there seems to be some closely-held positions regarding the existing set of flags -- it would be quite inappropriate to disrupt existing workflows for the more experienced and core developers without demonstrating the value of new flags. However, I do feel that adding flags is of very clear value to the development process overall.<br>
<br>My suggestion remains to add two additional attributes, either as "stage" or "status" options (personally I still feel 'status' is appropriate, but I don't mind where they go):<br> * Under discussion<br>
* Under development<br><br>This would flag "Open" issues as being up for grabs by any developer, "Under discussion" as something which is not ready for a developer to start work on a solution and which is still being worked out. "Under development" similarly means that everyone who needs to be involved is already involved. Issues that were "under discussion" or "under development" would drop back to "Open" after a month of inactivity. Issues which could not be advanced without further feedback would be marked as "suspended pending feedback", and never drop back to Open. The current "pending feedback" which appears to be used to indicate imminent closure should perhaps be altered to "pending closure".<br>
<br>Thus, "Open" indicated triage is required. The default view on the issue tracker should be "all issues not closed". The default view for a triage nurse would be "show me everything that is open".<br>
<br>I'm all for more debate on options for these new flags, but I haven't heard a whole lot of alternatives to date...<br><br>Cheers,<br>-Tennessee<br>