On Thu, Sep 30, 2010 at 9:14 AM, Waylan Limberg <way...@gmail.com> wrote: > On Wed, Sep 29, 2010 at 7:46 PM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> On Thu, Sep 30, 2010 at 7:26 AM, Luke Plant <l.plant...@cantab.net> wrote: >>> On Thu, 2010-09-30 at 01:32 +0400, Ivan Sagalaev wrote: >>> >>>> My suggestion is about this unfortunate ticket status -- 'Accepted'. >>>> This now works as a sort of a dusty shelf: when anyone of the core team >>>> looks at the patch and decides that there's nothing wrong with it he >>>> puts it on that shelf where the ticket has all the chances to lie for >>>> months or even years. And if the author of the patch tries from time to >>>> time pitching it to get it into trunk he can easily fall into all sorts >>>> of "not-a-good-times": conferences, feature freezes, hot discussions on >>>> other topics etc. >>>> >>>> My proposal is simple: 'Accepted' status shouldn't exist. If the patch >>>> is good it should be committed right away. If it's not there have to be >>>> an explanation why it needs improvement or why it's going to be >>>> wontfixed. Simple waiting doesn't really improve quality of the patch. >>>> >>>> What do you think? >>> >>> This doesn't account for these facts: >>> >>> 1) Accepted != Ready for checkin. >>> 2) A lot of triage is done by people without commit access. >>> >>> Sometimes a ticket stays at 'Accepted' for a long time because it >>> doesn't actually have anyone motivated enough to write even a patch, or >>> tests etc, which means that it is de-facto low priority, and we >>> shouldn't feel guilty about this kind. The ones in the 'Ready for >>> checkin' queue are the ones that deserve to be checked in, and it >>> currently has only 35 in it, compared to 1226 in 'Accepted'. >> >> This is an important stat -- but it glosses over the fact that 1226 >> "accepted" tickets doesn't necessarily clarify how many of these have >> viable patches -- or patches at all. >> >> Accepted tickets can be: >> >> * Purely accepted, indicating that someone has verified that the >> problem exists, but not how to solve it >> >> * Accepted with a patch that is wrong in some way (e.g., fixing the >> symptom, not the problem) >> >> * Accepted with a patch that is missing documentation or tests >> >> * Accepted with a valid patch, just awaiting review by someone else. >> >> A ticket in the first three conditions patently isn't ready for >> checkin. A ticket in the last condition *may* be ready for checkin; we >> ask for independent verification before it gets moved to RFC. > > So, in other words, accepted simply means that the ticket reports a > valid bug or feature request that is considered worth fixing, but > offers to indication as to the status of any patches for committing. > Obviously, some seem to imply the later meaning into "Accepted" which > could raise the question regarding whether it is named correctly (I > say it is fine). But, more importantly, is there a place were each > status is simply defined? > > Sure there is this: > http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage > > But that hardly makes clear exactly what "accepted" actually means. > The text in that section is helpful to understanding the basic > process, but if someone changes the status of my ticket, there's no > definitive place to go and see exactly what that status means. > > In fact, in reading the list over the last few years, I have the > impression that this is a problem that is repeated constantly. People > don't understand what the various statuses mean and get frustrated > when things do not happen as they expected. I think perhaps clearer > documentation would help in this case.
A reasonable suggestion if ever I've heard one. I've opened a ticket to track the idea: http://code.djangoproject.com/ticket/14360 and I've put it on the 1.3 milestone; if anyone wants to take a swing a clarifying the language before I (or someone else on the core team) gets a chance to look at it, feel free. 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.
