I believe Brett mentioned the 'languishing' status for the tracker in passing in his notes from the language summit. To expand on this: the desire for this arises from the observation that we have a lot of bugs in the tracker that we don't want to close, because they are real bugs or non-crazy enhancement requests, but for one reason or another (lack of an interested party, lack of a good, non-controversial solution, lack of a test platform on which to test the bug fix, the fix is hard but the bug is not of a commensurate priority, etc) the issue just isn't getting dealt with, and won't get dealt with until the blocking factor changes. The motivation for introducing a new status, rather than continuing to leave these bugs in 'open' state, is to make it clear which bugs are the *active* bugs, the ones we should be focusing on and working to fix first. This would allow the count of open bugs to be a more meaningful metric than it is currently, and might even allow us to get to a point where the open bug count stops increasing. More importantly, however, it would act as a first level partition of the non-closed bugs, such that the ones for which it is most likely that effective action can be taken will be what appear first. This is especially important for new people coming in to help. How many people have looked at the tracker, and decided to start from the oldest bugs and see what they can fix? I know I started out that way. Looking through those oldest bugs can be quite discouraging, since many of them are old because they are hard, or blocked for one reason or another. We would in addition propose that a 'languishing' search be added to the standard searches. I would also propose that the default search be changed to search all bugs, and group them by status, not priority. This will make it more likely that bug *reporters* will find existing bugs that relate to the problem they are experiencing or the feature they want to propose. The other searches (except open) should probably return languishing issues as well as open, since they sort in reverse chronological order the more active bugs will be at the top, and that way the languishing bugs won't be forgotten. (Note: languishing bugs should probably never have the 'needs review' keyword, since bugs should not be allowd to languish simply for need of a review.) To move a bug to state languishing, the procedure should be to post a comment saying why you are moving the bug to that status, that by implication or explicitly lays out the conditions required for it to move back to open. Doing so may wake someone up who wants to and can deal with the issue, in which case it can be moved back to open. --David PS: I believe that the other change that would be required in addition to adding the new status and search is to alter the bug summary email script to handle the languishing state. If I've missed anything else please let me know.
R. David Murray wrote:
I believe Brett mentioned the 'languishing' status for the tracker in passing in his notes from the language summit.
<snip explanation> Thanks for that. I had assumed Brett meant something along those lines, but it is good to have the rationale made explicit. Cheers, Nick. P.S. Not that it's needed, but +1 :) -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
R. David Murray
I believe Brett mentioned the 'languishing' status for the tracker in passing in his notes from the language summit.
I see a bunch of existing "Status / Resolution" choices. "open" / "later" "open" / "postponed" "open" / "remind" I did not find any documentation about them in both places: * http://wiki.python.org/moin/TrackerDocs/ "Tracker documentation" * http://www.python.org/dev/workflow/ "Issue workflow" Maybe these 2 documentation entry points could be merged and improved, first. They are not available on the same menu, and there's no cross-link between them: * "Issue workflow" from http://www.python.org/dev/ * "Tracker documentation" from http://bugs.python.org/ -- Florent Xicluna
On Mon, 22 Feb 2010 20:28:41 +0000, Florent Xicluna
R. David Murray
writes: I believe Brett mentioned the 'languishing' status for the tracker in passing in his notes from the language summit.
I see a bunch of existing "Status / Resolution" choices. "open" / "later" "open" / "postponed" "open" / "remind"
I did not find any documentation about them in both places: * http://wiki.python.org/moin/TrackerDocs/ "Tracker documentation" * http://www.python.org/dev/workflow/ "Issue workflow"
Maybe these 2 documentation entry points could be merged and improved, first. They are not available on the same menu, and there's no cross-link between them: * "Issue workflow" from http://www.python.org/dev/ * "Tracker documentation" from http://bugs.python.org/
There is a plan to improve the dev docs, and to merge a bunch of stuff that is scattered here and there into them. Brett will presumably add this item to his his punch list if it isn't already on it; thanks for pointing it out. It's a good question what the difference between 'later' and 'postponed' is. I'm guessing that 'later' is equivalent to 'languishing' (ie: its a good idea but nobody wants to do it right now), while 'postponed' is for something that needs to wait until the next release is out the door, or something like that. There is exactly one open ticket with 'remind' set (by Skip, issue 1374063), and 10 closed tickets. I'll review the closed tickets and move them to languishing if appropriate. I suspect remind is not a particularly useful resolution value. It would probably be better as a keyword. So I would suggest removing the resolutions 'later' and 'remind', and adding a 'remind' keyword if anyone speaks up as wanting it. Postponed I think is useful for the 'wait for next release' case on open tickets, although again it might be more useful as a keyword (it isn't really a 'resolution'). --David
Am 22.02.2010 21:28, schrieb Florent Xicluna:
R. David Murray
writes: I believe Brett mentioned the 'languishing' status for the tracker in passing in his notes from the language summit.
I see a bunch of existing "Status / Resolution" choices. "open" / "later" "open" / "postponed" "open" / "remind"
Those are taken from SourceForge, and I'm not sure we need all of them, as David says. :) But the point of the "languishing" status is really to not have them in your results when searching for open issues. Searching for "open, but not with one of these three resolutions" is much harder.
I did not find any documentation about them in both places: * http://wiki.python.org/moin/TrackerDocs/ "Tracker documentation" * http://www.python.org/dev/workflow/ "Issue workflow"
As David says, I have a plan to consolidate the dev docs and bring them into the source repo. Of course, just because it is my plan, it doesn't need to be done by me :) Aren't there people sprinting somewhere? :) Georg
On Tue, 23 Feb 2010 01:35:03 +0100, Georg Brandl
Am 22.02.2010 21:28, schrieb Florent Xicluna:
I did not find any documentation about them in both places: * http://wiki.python.org/moin/TrackerDocs/ "Tracker documentation" * http://www.python.org/dev/workflow/ "Issue workflow"
As David says, I have a plan to consolidate the dev docs and bring them into the source repo. Of course, just because it is my plan, it doesn't need to be done by me :)
Aren't there people sprinting somewhere? :)
Yeah, but none of the people who are good at driving doc stuff (you or Brett or Ezio) are here :) --David
On Feb 22, 2010, at 12:17 AM, R. David Murray wrote:
To expand on this: the desire for this arises from the observation that we have a lot of bugs in the tracker that we don't want to close, because they are real bugs or non-crazy enhancement requests, but for one reason or another (lack of an interested party, lack of a good, non-controversial solution, lack of a test platform on which to test the bug fix, the fix is hard but the bug is not of a commensurate priority, etc) the issue just isn't getting dealt with, and won't get dealt with until the blocking factor changes.
In my opinion, the problem is not so much that tickets are left open for a long time, as that there's no distinction between triaged and un-triaged tickets. I think it's perfectly fine for tickets to languish as "open", in no special state, as long as it's easy to find out whether someone has gotten back to the original patch-submitter or bug-reporter to clarify the status at least once. Of course, then the submitter needs to be able to put it back into the un-triaged state by making a counterproposal, or attaching a new patch. To the extent that people are frustrated with the Python development process, it's generally not that their bugs don't get fixed (they understand that they're depending on volunteer labor); it's that they went to the trouble to diagnose the bug, specify the feature, and possibly even develop a complete fix or implementation, only to never hear *anything* about what the likelihood is that it will be incorporated. In the Twisted tracker, whenever we provide feedback or do a code review that includes critical feedback that needs to be dealt with before it's merged, we re-assign the ticket to its original submitter. I feel that this is pretty clear: it means "the ticket is open, it's valid, but it's also not my problem; if you want it fixed, fix it yourself".
participants (5)
-
Florent Xicluna -
Georg Brandl -
Glyph Lefkowitz -
Nick Coghlan -
R. David Murray