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".