Re: [Python-Dev] tracker status options
Daniel (ajax) Diniz wrote: I feel we should make the tracker more useful for core developers, volunteers and end-users. I also think having a clear workflow helps a lot. Yet, I'd rather have a tracker that allowed users with different interpretations to work as they feel most comfortable than one that requires a change of assumptions. One other thing to keep in mind (and something I try to do myself) is to include a comment saying *why* a particular status change was made. Yes, that doesn't help all that much when people are searching for issues at various stages, but it definitely helps: a) anyone on the nosy list (since the comment and the field changes will typically either arrive in the same email or at least close together in time) b) anyone reading the issue later (as they will see more than just a series of status changes at the bottom of the issue page) If it's a matter of the triage folks wanting to be able to mark particular kinds of issues to make them easier to find or avoid later, then keywords may be a better option than messing with the stages. Heck, you could even go for the internet UI du jour and allow free form tags rather than being restricted to just the preset list of keywords - the free form tags would be a little more experimental, with the more useful ones eventually making their way to the list of properly defined keywords. The less useful ones could fall into natural disuse without cluttering up the main keyword selection UI. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] tracker status options
On Tue Mar 24 02:06:29 CET 2009, Tennessee Leeuwenburg tleeuwenburg at gmail.com wrote: 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. 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: * Whether the nature of the requirement is still under debate or whether it is well-understood So, having triaged a few issues, here are my thoughts. The current workflow is roughly: o test needed o patch needed o patch review o commit review One can look at these and see what needs to be done next. I think that in practice the above list actually expands something like this: o consensus needed o test needed o patch needed o patch needs work o patch review o commit review The first of these additional items is equivalent to your bullet item above. I would propose that the issue, regardless of whether or not it is a bug fix or a feature request, goes into 'consensus needed' whenever there is significant debate as to the validity of the bug or feature request. It moves to an appropriate later stage when agreement has been reached (which may be by fiat of a developer or the BDFLso the triage people would need to know who can pronounce). The second addition is not as clearly useful. 'patch needs work' could be the result of a developer review, or of any other review. That is, at that stage we are trying to reach consensus that the patch is the correct solution to the problem or feature request. An issue could bounce back and forth between 'patch review' and 'patch needs work' multiple times (and it would probably be best if the patch submitter could request 'patch review'). But one could argue that the issue could just as easily be bounced back and forth between 'patch review' and 'patch needed', since one would need to read the comment stream to figure out what was actually going on anyway. I think it would be a useful addition, since it would enable someone to search for 'patch needed' in order to look for issues to pick up, whereas 'patch needs work' would indicate someone was working on it. (Of course, that someone could also stop working on it...but if one wished to find such issues, one could simply sort 'patch needs work' issues by last activity date.) Hmm. Or perhaps it should be patch needs consensus, given the issue I'm looking at where I want to set it to this stage :) * Whether the issue is up for grabs by any developer or whether responsibility lies with an individual or group already Isn't that covered by 'assigned to'? * Whether the issue is ready for more serious consideration by more experienced or core developers Hmm. Theoretically that's covered by 'patch review'. Given that 'commit review' is (currently?) reserved for issues being considered for addition to a release candidate or final release, perhaps we need an additional stage 'core review' that would come after 'patch review'. Then triage could promote issues from 'patch review' to 'core review' if triage thinks it is ready for review by someone with commit privileges. This of course assumes that people other than core developers are actually doing patch review. I certainly intend to, but how many of us are there really going to be? -- R. David Murray http://www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
R. David Murray wrote: So, having triaged a few issues, here are my thoughts. The current workflow is roughly: o test needed o patch needed o patch review o commit review One can look at these and see what needs to be done next. I think that in practice the above list actually expands something like this: o consensus needed o test needed o patch needed o patch needs work o patch review o commit review As a point of comparison, here are the GNUnet mantis status codes. The following status codes are used in Mantis: * New A new bug, developers did not look into these yet. * Feedback Developers require feedback from users reporting the bug to resolve it. Also used if a general discussion between the researches is needed on how to address a problem. * Acknowledged Developers have seen the bug. * Confirmed Developers are convinced that the bug is a problem that needs to be fixed. * Assigned Some developer has started working on the problem. Note that developers may give up on problems, putting the bug back to confirmed, or feedback. * Resolved The bug has been fixed in some version in Subversion or in a patch attached to the bug report. * Closed Resolved bugs are closed after the bugfix has made it into a full release of GNUnet. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
o consensus needed o test needed o patch needed o patch needs work o patch review o commit review The first of these additional items is equivalent to your bullet item above. I would propose that the issue, regardless of whether or not it is a bug fix or a feature request, goes into 'consensus needed' Well, there is always the unset state, which means not triaged. So if you propose that this should be the default initial state, I'm opposed. Instead, would it help to add a confirmed state? For a bug, that would mean that it was successfully reproduced; for a patch, it was confirmed as desirable. If the person performing triage cannot confirm the bug, they should reject the issue (or recommend rejection, in case they are unsure). Somebody performing triage should never conclude with I don't know; this would be time-wasting. If, for a bug, the reviewer disagrees that it would be a bug if the behavior actually exists, then the issue should be closed (resolution not-a-bug/invalid). If the reviewer agrees that it would be a bug, but fails to reproduce it, a test is needed. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
On Tue, 24 Mar 2009 at 21:27, Martin v. L?wis wrote: o consensus needed o test needed o patch needed o patch needs work o patch review o commit review The first of these additional items is equivalent to your bullet item above. I would propose that the issue, regardless of whether or not it is a bug fix or a feature request, goes into 'consensus needed' Well, there is always the unset state, which means not triaged. So if you propose that this should be the default initial state, I'm opposed. No, I was not suggesting it be the default state. Instead, would it help to add a confirmed state? For a bug, that would mean that it was successfully reproduced; for a patch, it was confirmed as desirable. So, 'confirmed' instead of 'consensus needed' (or confirmed/approved, to cover feature requests), and 'patch is appropriate' that comes...I'm not quite sure where? If the person performing triage cannot confirm the bug, they should reject the issue (or recommend rejection, in case they are unsure). Somebody performing triage should never conclude with I don't know; this would be time-wasting. The cases I was considering are cases where in the comments on the ticket there is disagreement either on whether or not the bug is a bug or (more often) whether or not the feature is desirable, and at the patch stage whether or not the patch is the appropriate fix. I think currently things sit in 'patch needed' until consensus is reached on the patch, but I haven't watched enough tickets progress yet to be sure :) Adding another stage here may be more confusing than it is helpful, seeing as I can't really figure out where it would go. Did I guess correctly that the process for recommending rejection is to set the stage to 'commit/reject', the resolution to 'invalid' (or whatever is appropriate) and the status to 'pending'? That seemed to work for the issue I did it to, in that someone came along and closed it shortly after that. If, for a bug, the reviewer disagrees that it would be a bug if the behavior actually exists, then the issue should be closed (resolution not-a-bug/invalid). If the reviewer agrees that it would be a bug, but fails to reproduce it, a test is needed. OK, so I guess I now understand how the current workflow is supposed to work: if its stage is 'unassigned', then it hasn't been accepted as a bug/enhancement yet, and triage should make that accept/reject judgement. The tricky bit here for me is that I, as a new person doing triage, don't always feel comfortable in passing judgement on a bug or feature request. So what would be the mechanism for a triage person to request a passing of judgement from someone with more experience/authority? Post to python-dev? Given such a mechanism, I think I would be comfortable with the current workflow, with the expectation that I would need to call for assistance less and less frequently over time, and ultimately only for those things where discussion among the devs really is needed. Hmm. Maybe I should write a short guide to performing triage and post it for feedback. -- R. David Murray http://www.bitdance.com___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
So, 'confirmed' instead of 'consensus needed' (or confirmed/approved, to cover feature requests), and 'patch is appropriate' that comes...I'm not quite sure where? If the person who did the triage actually thinks the patch is ready to be committed, it would be commit review. Not sure in what other way a patch might be appropriate. The cases I was considering are cases where in the comments on the ticket there is disagreement either on whether or not the bug is a bug or (more often) whether or not the feature is desirable, and at the patch stage whether or not the patch is the appropriate fix. If the person doing the triage has made a final call, the issue can enter the next stage. There should never be debate on the tracker, IMO (although there often is). It might be that people disagree with a triage, then they should appeal to python-dev, not on the issue itself. It might be that they think the reviewer misunderstood the issue, then they should clarify, and the reviewer should revert the status. IMO, the reviewer should *always* take action, either by asking for more information, or by advancing the issue to the next stage. Did I guess correctly that the process for recommending rejection is to set the stage to 'commit/reject', the resolution to 'invalid' (or whatever is appropriate) and the status to 'pending'? That seemed to work for the issue I did it to, in that someone came along and closed it shortly after that. If you have permission to do so, you should just close the issue (in that manner). If you don't have permission, you can leave a message saying I recommend to close the issue. If you are unsure, you can set it to Pending, and ask for help on python-dev. In that case, you haven't actually done triage, but merely considered it, and determined that it looks too difficult. The tricky bit here for me is that I, as a new person doing triage, don't always feel comfortable in passing judgement on a bug or feature request. So what would be the mechanism for a triage person to request a passing of judgement from someone with more experience/authority? Post to python-dev? Exactly. Never assign to somebody, unless that somebody has explicitly requested such an assignment, or unless he gave blank permission to be assigned certain kinds of issues. Hmm. Maybe I should write a short guide to performing triage and post it for feedback. That can't hurt. Different people make different experiences. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
On Tue, 24 Mar 2009 at 22:41, Martin v. L?wis wrote: If the person doing the triage has made a final call, the issue can enter the next stage. There should never be debate on the tracker, IMO (although there often is). It might be that people disagree with a triage, then they should appeal to python-dev, not on the issue itself. It might be that they think the reviewer misunderstood the issue, then they should clarify, and the reviewer should revert the status. OK, so given this then I revise the way I understand what is happening in the ticket I'm looking at: a reviewer has said this patch needs work and the submitter has not responded. Since the behavior has been accepted as a valid bug this means...I can either work on the patch, or post a message asking if the submitter wants to either revise the patch or discuss it on python-dev. In the latter case if the submitter does not respond, then the issue continues to languish. IMO it shouldn't be closed, because it really is a bug. Does this match what you would expect a reviewer to do? (A person really doing triage would of course not work on the patch themselves :) IMO, the reviewer should *always* take action, either by asking for more information, or by advancing the issue to the next stage. Did I guess correctly that the process for recommending rejection is to set the stage to 'commit/reject', the resolution to 'invalid' (or whatever is appropriate) and the status to 'pending'? That seemed to work for the issue I did it to, in that someone came along and closed it shortly after that. If you have permission to do so, you should just close the issue (in that manner). If you don't have permission, you can leave a message saying I recommend to close the issue. If you are unsure, you can set it to Pending, and ask for help on python-dev. In that case, you haven't actually done triage, but merely considered it, and determined that it looks too difficult. OK, so I guess I've been given more power than I was expecting, and I'll just have to step up the bar and learn to use it appropriately :) -- R. David Murray http://www.bitdance.com___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
OK, so given this then I revise the way I understand what is happening in the ticket I'm looking at: a reviewer has said this patch needs work and the submitter has not responded. Since the behavior has been accepted as a valid bug this means...I can either work on the patch, or post a message asking if the submitter wants to either revise the patch or discuss it on python-dev. In the latter case if the submitter does not respond, then the issue continues to languish. IMO it shouldn't be closed, because it really is a bug. Does this match what you would expect a reviewer to do? (A person really doing triage would of course not work on the patch themselves :) Right. The issue would be in the patch needs work stage until somebody contributes. No further review needed, and yes, the issue will languish until somebody improves the patch. OK, so I guess I've been given more power than I was expecting, and I'll just have to step up the bar and learn to use it appropriately :) :-) With power comes responsibility, of course. However, review/triage doesn't really help unless it gets issues to be resolved, eventually. In the specific case: if the bug has already been confirmed, there is nothing else to be done for the review. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
R. David Murray wrote: I understood from posts I saw go by earlier from Daniel that 'pending' meant 'close pending unless there is feedback to the contrary' (and I just used it that way). It sounds like that is indeed correct but not universally known, and thus I would suggest that at a minimum this status be changed to 'close pending' to make it clearer. Aha, at least one post I feel I can reply to. Sort of. I do have a set of triaging principles and beliefs about each issue property, but if you explained to me that 'closed' actually requires unsetting versions, priority and keywords, I'd buy it and would add that to my set of triaging beliefs. OK, maybe I'd ask for an explanation :) ISTM that each tracker user understands different things from each option, each assignee reacts differently to changes in their issues. I kinda try to understand what people mean with the options, not what the options should mean. If I set issues to pending and simultaneously declare my interpretation of pending, in part that's because I expect different people to see different meanings in the status change. I've seen issues in the top 10 most active that lived in a pending status for most of their existence. I'm having trouble posting in these threads because I actually can't tell whether adding a stage, removing a component or renaming a status is better or worse than the status quo. I feel we should make the tracker more useful for core developers, volunteers and end-users. I also think having a clear workflow helps a lot. Yet, I'd rather have a tracker that allowed users with different interpretations to work as they feel most comfortable than one that requires a change of assumptions. On my first triaging sprint Brett asked whether a new stage would make things better and Martin said he could add any new components that could make triaging easier. I told them I was unsure about it, that I might have requests for new options after some thinking, but that I had a couple of RFEs. It's been over a month, but new options still make me uneasy. Let me hit send before I conclude (again) this adds nothing to the discussion and discard it :) Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
Tennessee Leeuwenburg wrote:
Hi all,
I'm continuing to (slowly) work through issues. I have been looking
particularly at a lot of the open issues regarding strftime.
It would be great to put in some of those extra status options that were
discussed recently...
Open/New
Needs help / Chatting
Under development
Pending feedback
Closed
For everyone's reference, after some debate, the above list of status
options was where the conversation finished. So the two options Needs
help / chatting and Under development would need to be added. Issues
that are Under development should revert to Needs help / chatting
after a month of inactivity.
Would it be possible to get these put in? Maybe I'm one of a small
number of people who are nibbling at the bottom end of the bugs, but I
find it somewhat frustrating not to be able to classify the issues that
I find into needs help / chatting vs under development to help make
more sense of the search results.
Cheers,
-T
Maybe a flow chart can help unambiguize things a bit. What follows is
maybe one starting place. I tried to separate steps that might be done by
users from developers so that there is a clear order to the process. This
seems to follow the general way that python issues are resolved from what
I've observed.
While this chart separates the descriptive/brain storming and patch making
parts of an issue, in actuality, a patch (tests, fix, and docs) can be
developed partially or fully in the discussion faze for the purpose of
helping the discussion, then later reused and fine tuned in the patch
making faze.
Hope this is helpful and doesn't get too mangled in sending.
(new issue)
|
v
[discuss issue] -+
| |
v |
|
{request issue review}|
| |
v |
|
invalid issue ? (yes)-- [close issue] |
(no)| |
| v |
| (closed) |
v |
|
valid issue ? (no)--+
(yes)
|
v
[develop patch] --+
| |
v |
|
{request patch review} |
| |
v |
|
patch ready ? (no) ---+
(yes)
|
v
[apply patch]
|
v
[close issue]
|
v
(closed)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
Hi Ron,
Good flowchart.
Cheers,
-T
On Wed, Mar 25, 2009 at 1:11 PM, Ron Adam r...@ronadam.com wrote:
Tennessee Leeuwenburg wrote:
Hi all,
I'm continuing to (slowly) work through issues. I have been looking
particularly at a lot of the open issues regarding strftime.
It would be great to put in some of those extra status options that were
discussed recently...
Open/New
Needs help / Chatting
Under development
Pending feedback
Closed
For everyone's reference, after some debate, the above list of status
options was where the conversation finished. So the two options Needs help
/ chatting and Under development would need to be added. Issues that are
Under development should revert to Needs help / chatting after a month
of inactivity.
Would it be possible to get these put in? Maybe I'm one of a small number
of people who are nibbling at the bottom end of the bugs, but I find it
somewhat frustrating not to be able to classify the issues that I find into
needs help / chatting vs under development to help make more sense of
the search results.
Cheers,
-T
Maybe a flow chart can help unambiguize things a bit. What follows is
maybe one starting place. I tried to separate steps that might be done by
users from developers so that there is a clear order to the process. This
seems to follow the general way that python issues are resolved from what
I've observed.
While this chart separates the descriptive/brain storming and patch making
parts of an issue, in actuality, a patch (tests, fix, and docs) can be
developed partially or fully in the discussion faze for the purpose of
helping the discussion, then later reused and fine tuned in the patch making
faze.
Hope this is helpful and doesn't get too mangled in sending.
(new issue)
|
v
[discuss issue] -+
| |
v |
|
{request issue review}|
| |
v |
|
invalid issue ? (yes)-- [close issue] |
(no)| |
| v |
| (closed) |
v |
|
valid issue ? (no)--+
(yes)
|
v
[develop patch] --+
| |
v |
|
{request patch review} |
| |
v |
|
patch ready ? (no) ---+
(yes)
|
v
[apply patch]
|
v
[close issue]
|
v
(closed)
--
--
Tennessee Leeuwenburg
http://myownhat.blogspot.com/
Don't believe everything you think
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
R. David Murray wrote: On Tue, 24 Mar 2009 at 21:27, Martin v. L�wis wrote: o consensus needed o test needed o patch needed o patch needs work o patch review o commit review The first of these additional items is equivalent to your bullet item above. I would propose that the issue, regardless of whether or not it is a bug fix or a feature request, goes into 'consensus needed' Well, there is always the unset state, which means not triaged. So if you propose that this should be the default initial state, I'm opposed. No, I was not suggesting it be the default state. Instead, would it help to add a confirmed state? For a bug, that would mean that it was successfully reproduced; for a patch, it was confirmed as desirable. So, 'confirmed' instead of 'consensus needed' (or confirmed/approved, to cover feature requests), and 'patch is appropriate' that comes...I'm not quite sure where? If the person performing triage cannot confirm the bug, they should reject the issue (or recommend rejection, in case they are unsure). Somebody performing triage should never conclude with I don't know; this would be time-wasting. The cases I was considering are cases where in the comments on the ticket there is disagreement either on whether or not the bug is a bug or (more often) whether or not the feature is desirable, and at the patch stage whether or not the patch is the appropriate fix. I think currently things sit in 'patch needed' until consensus is reached on the patch, but I haven't watched enough tickets progress yet to be sure :) Adding another stage here may be more confusing than it is helpful, seeing as I can't really figure out where it would go. Did I guess correctly that the process for recommending rejection is to set the stage to 'commit/reject', the resolution to 'invalid' (or whatever is appropriate) and the status to 'pending'? That seemed to work for the issue I did it to, in that someone came along and closed it shortly after that. If, for a bug, the reviewer disagrees that it would be a bug if the behavior actually exists, then the issue should be closed (resolution not-a-bug/invalid). If the reviewer agrees that it would be a bug, but fails to reproduce it, a test is needed. OK, so I guess I now understand how the current workflow is supposed to work: if its stage is 'unassigned', then it hasn't been accepted as a bug/enhancement yet, and triage should make that accept/reject judgement. The tricky bit here for me is that I, as a new person doing triage, don't always feel comfortable in passing judgement on a bug or feature request. So what would be the mechanism for a triage person to request a passing of judgement from someone with more experience/authority? Post to python-dev? Given such a mechanism, I think I would be comfortable with the current workflow, with the expectation that I would need to call for assistance less and less frequently over time, and ultimately only for those things where discussion among the devs really is needed. Hmm. Maybe I should write a short guide to performing triage and post it for feedback. Might I suggest studying the status values used by the Django team in their Trac tracker instance. They seem to have a very methodical workflow. http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Want to know? Come to PyCon - soon! http://us.pycon.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
2009/3/22 Tennessee Leeuwenburg tleeuwenb...@gmail.com Hi Daniel, That would be great. It occurs to me that if we wanted to use Stage settings, it would be easy to search for issues which are not closed by literally searching for 'not closed' rather than 'open'. I think it's also unclear whether the 'pending' stage means 'suspended pending additional user feedback' or 'resolution of this issue is impending'. My understanding was that it meant 'pending additional feedback' in the sense of awaiting, rather than imminent. It's the latter; it's pending feedback. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
That would be great. It occurs to me that if we wanted to use Stage settings, it would be easy to search for issues which are not closed by literally searching for 'not closed' rather than 'open'. I think it's also unclear whether the 'pending' stage means 'suspended pending additional user feedback' or 'resolution of this issue is impending'. My understanding was that it meant 'pending additional feedback' in the sense of awaiting, rather than imminent. It's the latter; it's pending feedback. Which latter (there seem to be multiple pairs in Tennessee's message)? In any case, it's not really pending feedback. Instead, it means if there is no feedback really soon, it will get closed. So closure is impending and imminent. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
On Tue, Mar 24, 2009 at 11:00 AM, Martin v. Löwis mar...@v.loewis.dewrote: That would be great. It occurs to me that if we wanted to use Stage settings, it would be easy to search for issues which are not closed by literally searching for 'not closed' rather than 'open'. I think it's also unclear whether the 'pending' stage means 'suspended pending additional user feedback' or 'resolution of this issue is impending'. My understanding was that it meant 'pending additional feedback' in the sense of awaiting, rather than imminent. It's the latter; it's pending feedback. Which latter (there seem to be multiple pairs in Tennessee's message)? In any case, it's not really pending feedback. Instead, it means if there is no feedback really soon, it will get closed. So closure is impending and imminent. 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. 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. 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. 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: * Whether the nature of the requirement is still under debate or whether it is well-understood * Whether the issue is up for grabs by any developer or whether responsibility lies with an individual or group already * Whether the issue is ready for more serious consideration by more experienced or core developers 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. 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. 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): * Under discussion * Under development 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. 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. I'm all for more debate on options for these new flags, but I haven't heard a whole lot of alternatives to date... Cheers, -Tennessee
Re: [Python-Dev] tracker status options
On Mon, 23 Mar 2009 at 16:20, Tennessee Leeuwenburg wrote: literally searching for 'not closed' rather than 'open'. I think it's also unclear whether the 'pending' stage means 'suspended pending additional user feedback' or 'resolution of this issue is impending'. My understanding was that it meant 'pending additional feedback' in the sense of awaiting, rather than imminent. I understood from posts I saw go by earlier from Daniel that 'pending' meant 'close pending unless there is feedback to the contrary' (and I just used it that way). It sounds like that is indeed correct but not universally known, and thus I would suggest that at a minimum this status be changed to 'close pending' to make it clearer. -- R. David Murray http://www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
Hi Daniel, That would be great. It occurs to me that if we wanted to use Stage settings, it would be easy to search for issues which are not closed by literally searching for 'not closed' rather than 'open'. I think it's also unclear whether the 'pending' stage means 'suspended pending additional user feedback' or 'resolution of this issue is impending'. My understanding was that it meant 'pending additional feedback' in the sense of awaiting, rather than imminent. In any case, let me know when the tracker is online and I will suggest the tag alterations that I think would be appropriate. Regards, -Tennessee On Fri, Mar 20, 2009 at 10:53 AM, Daniel (ajax) Diniz aja...@gmail.comwrote: Martin v. Löwis wrote: In addition, I would like to see a specification of the exact labels to be used, plus a one-line description that should be attached to the labels. Tennessee, If you'd like to test those additional status options, I'm setting a test instance of the Python tracker up at http://bot.bio.br/python-dev/ . It might be frequently offline for a while, but once things are stable it'll be reliable enough to perform such experiments. If it's easy on resource usage, I might have one instance following the Python tracker code closely and a more bleeding-edge one :) Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/tleeuwenburg%40gmail.com -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ Don't believe everything you think ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
It would be great to put in some of those extra status options that were discussed recently... Open/New Needs help / Chatting Under development Pending feedback Closed Are you sure that you want them to be status options? Why not stages? ISTM that an issue that Needs help is still Open. Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
On Wed, Mar 18, 2009 at 23:47, Martin v. Löwis mar...@v.loewis.de wrote: It would be great to put in some of those extra status options that were discussed recently... Open/New Needs help / Chatting Under development Pending feedback Closed Are you sure that you want them to be status options? Why not stages? Because Tennessee is after a way to sift through open issues looking for ones that are not being actively worked on, thus the Under Dev status. Just because an issue needs [a] patch doesn't means it is being worked on currently. ISTM that an issue that Needs help is still Open. Once the backlog of bugs has been cleaned up and we get into a habit of triaging new bugs as soon as they come in this won't be quite as necessary. I believe Tennessee wanted this status to signify that more input is needed from others originally and to perform triage. Out of the two this one is needed the least in my opinion. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
On Wed, Mar 18, 2009 at 23:47, Martin v. Löwis mar...@v.loewis.de mailto:mar...@v.loewis.de wrote: It would be great to put in some of those extra status options that were discussed recently... Open/New Needs help / Chatting Under development Pending feedback Closed Are you sure that you want them to be status options? Why not stages? Because Tennessee is after a way to sift through open issues looking for ones that are not being actively worked on, thus the Under Dev status. Just because an issue needs [a] patch doesn't means it is being worked on currently. How is being actively worked on defined? How do these additional status values help in answering that question? ISTM that an issue that Needs help is still Open. Once the backlog of bugs has been cleaned up and we get into a habit of triaging new bugs as soon as they come in this won't be quite as necessary. I believe Tennessee wanted this status to signify that more input is needed from others originally and to perform triage. Out of the two this one is needed the least in my opinion. If you want them, we can add them. However, I would then need a complete specification of how various pieces that currently refer to Open/Closed should behave with respect to the new status, such as - list of issues displayed - weekly email notifications - initial value that status should get - relationship to existing status values In addition, I would like to see a specification of the exact labels to be used, plus a one-line description that should be attached to the labels. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker status options
Martin v. Löwis wrote: In addition, I would like to see a specification of the exact labels to be used, plus a one-line description that should be attached to the labels. Tennessee, If you'd like to test those additional status options, I'm setting a test instance of the Python tracker up at http://bot.bio.br/python-dev/ . It might be frequently offline for a while, but once things are stable it'll be reliable enough to perform such experiments. If it's easy on resource usage, I might have one instance following the Python tracker code closely and a more bleeding-edge one :) Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] tracker status options
Hi all, I'm continuing to (slowly) work through issues. I have been looking particularly at a lot of the open issues regarding strftime. It would be great to put in some of those extra status options that were discussed recently... Open/New Needs help / Chatting Under development Pending feedback Closed For everyone's reference, after some debate, the above list of status options was where the conversation finished. So the two options Needs help / chatting and Under development would need to be added. Issues that are Under development should revert to Needs help / chatting after a month of inactivity. Would it be possible to get these put in? Maybe I'm one of a small number of people who are nibbling at the bottom end of the bugs, but I find it somewhat frustrating not to be able to classify the issues that I find into needs help / chatting vs under development to help make more sense of the search results. Cheers, -T ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
