On Nov 15, 6:31 am, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> On Mon, Nov 15, 2010 at 1:00 PM, Tai Lee <real.hu...@mrmachine.net> wrote: > > I like the idea of needmoreinfo as a resolution, which makes it clear > > to the reporter that they need to take the next step to re-open the > > ticket with more info. I don't think that closed with "invalid" and a > > comment makes this as clear. > > > However, I think there's another problem area where we need to be able > > to make it clear that someone needs to take the next step, and that is > > when a ticket has been "accepted", feedback has been given to the > > reporter, and the reporter has actioned that feedback (e.g. by > > uploading a patch with tests and docs as per the feedback). In this > > case the ticket will often languish in "accepted" for months (or > > years). Since it is frowned upon for a reporter to mark their own > > ticket as RFC, there's no way for the reporter to flag the ticket as > > feedback actioned and put it back in the court of the original triager > > or core developer who accepted it and gave their feedback, who can > > then either push it up to RFC or commit it themselves. > > Incorrect. There *is* a way for a reporter to flag that they have > followed through on feedback -- they update the 'need docs', 'needs > tests' and 'needs improvement' flags. > > Example workflow: > > * Alice creates a ticket, with an incomplete patch (no tests, > incorrect implementation) > * Bob reviews the patch, marks it "Accepted, needs tests, patch needs > improvement" > * Alice updates the patch, adding tests (but not changing the > implemenation). She removes the two flags. > * Charlie reviews the patch, resets the 'patch needs improvement flag' > * Alice updates the patch, fixing the implementation. She removes the > needs improvement flag. > * Daisy reviews the patch, marks it RFC. > > At any point in this process, a search for tickets "Accepted & has > patch & !needs improvement & !needs docs & !needs tests" will reveal > tickets that need review of some kind. These tickets either need to be > moved to RFC, or need to have their flags set to indicate the > deficiency in the patch. I admit I am guilty of breaking the (unknown to me) rule/etiquette of marking my own tickets RFC as a last resort to move them forward. Unlike your example workflow, my experience is often like this: * I create a ticket and submit a patch plus passing tests (no need for docs if it's a bug or a promise to add them once it is reviewed and accepted, i.e. it passes the DDN stage). * The ticket stays unreviewed for days, weeks or months or it is marked as accepted at best, without actual feedback how to proceed, one way or another. * At some point I mark it RFC since as far as I am concerned it *is* ready for checkin. * More time passes and still nobody bothers. If I'm doing it wrong, please educate me. George -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
