On Wed, Nov 17, 2010 at 3:17 AM, George Sakkis <george.sak...@gmail.com> wrote: > 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.
To date, this hasn't been formally documented. This is something that #14401 will hopefully address. > 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. You aren't doing anything wrong (that I can see), but you perhaps have some unrealistic expectations. You need to remember that this is a volunteer project. Nobody is paid to work on Django. Uploading a patch doesn't automatically give you special priority. It puts your patch on a very long list of things that need to be done. Given infinite time, this list of things will be done -- but we don't have infinite time, so we need to prioritize. Yes, you have 2 tickets currently in RFC state. Assuming your RFC self-triage isn't premature, these should get committed to trunk before 1.3 ships. However, stand back and take an objective look at these tickets -- neither of them are especially critical. Yes, they're bugs, and yes, it would be nice to resolve them. But they don't cause catastrophic data loss. They've existed as misfeatures of the ORM since before 1.0. And we haven't been overrun with people complaining about these issues. I don't see a great deal of reason to prioritize these two tickets over any of other issues vying for my time. And hence, I haven't. Instead, I've concentrated on things that needed to be done for the alpha or beta release (new features, doctest ports), or other more immediate Django-related activities (mailing lists, IRC). The other core developers have made similar value judgements, and as a result your ticket hasn't reached the top of anyones todo list. Once the beta is out of the way and we have a feature freeze in place, pure bugs like the tickets you describe will have a much better chance of being committed. As for other tickets languishing in accepted state -- they need to be reviewed. We need people to volunteer to do that reviewing. By a conservative query [1], there are there are currently 352 tickets in that state. There are also 173 completely unreviewed tickets. Without wanting to seem completely mercenary -- why are your tickets more deserving than the 500 others that need review attention? We've had a number of discussions recently about ways to improve Trac to give better visibility to "work that needs doing", and better ways to provide feedback on what the community as a whole considers important. However, this won't increase the amount of time that is volunteered; the best we can hope for is a better utilization of the limited volunteer resources at our disposal. If you have any ideas on how to increase the amount of volunteer time that is available to us, I'm all ears. I'm also open to any suggestions on how to better engage the community to do the work that needs doing. But please be realistic -- this is a volunteer project, we can't force anyone to do anything, and the core team is already extremely busy. [1] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_better_patch=%211&needs_tests=%211&needs_docs=%211&has_patch=1&order=priority&stage=Accepted Yours, Russ Magee %-) -- 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.
