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. -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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.
