On Wed, Feb 24, 2010 at 11:14 AM, Tobias McNulty <tob...@caktusgroup.com> wrote: ... > I'm hoping this will spark a discussion about how we can work more > efficiently and put donated time to better use. I may be a bit biased, > because this is coming on the tail end of spending 2+ person hours trying to > reproduce a ticket in the PyCon sprint that, I later found out, two others > had done the same thing with a day earlier, but neither had indicated as > much in the ticket.
The basic problem, as ever, is managing volunteer time. In this case, it looks like a failure of triage. A committer often looks for ready-for-checkin, and this ticket, despite having a patch, never got marked ready-for-checkin. Prompted by your question, I see that there are over 700 tickets in this status -- I'd say a ticket should fairly quickly clear this stage -- either be marked ready or marked patch-needs-improvement. But of course the triagers themselves are volunteers, doing relatively unglamorous work when they can. (And thank you to all triagers for their work!) http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_better_patch=%211&has_patch=1&order=priority&stage=%21Ready+for+checkin There are over 200 bugs marked 1.2 -- even after features got booted to 1.3 (including yours), with the release date coming soon. I'm sure more will have to be pushed. James got to be the bad guy booting tickets for features late for 1.2-- some apparently due to workflow failure. But he's just following the workflow, too. > A couple ideas to get us started: > > 1) Reemphasize via documentation and/or training (and/or by reading this > message) the proper work flow for tickets (e.g., accept it when you start > working on it, post a comment when you're done, etc.): > > http://docs.djangoproject.com/en/dev/internals/contributing/#claiming-tickets I don't think documenting it more is the solution -- if people aren't clear on the process as documented, I certainly haven't heard that confusion. I think the issue is that documenting and doing are two different things. For example, I know that I should only have tickets assigned to me if I'm actively working them, but that hasn't stopped me from forgetfully breaking that rule pretty often. > 2) For each release, assign several people (I'd be happy to take a turn) the > task of searching through all outstanding tickets in the milestone in > question a couple weeks before the feature freeze and assigning > "committable" ones to specific committers. Maybe this ticket is an outlier, > but I expect there are others out there that are also getting missed. I'm > not sure if this means that the current way ticket triage is outlined to > work is just not happening, or if there are changes we need to make so that > it works more effectively: > > http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage This gets at the problem more directly -- we used to have a feature/bug classification, but it was abused -- lots of people marked things as bugs simply because they felt they were necessary, and hence not "features". Everything is miscellaneous, but if there is no consistent distinction between bug and feature, there's no point in having the field. I don't think we need a workflow that assigns committables to specific committers-- they're working and doing what they can, we already have a ready-for-commit sign, and (I presume) the issue isn't that they aren't committing as quickly as possible -- the # of ready-for-commit tickets has hovered between 15 and 100 for a year, and sits at 50 now. Tickets are being resolved quite a bit, so the inflow is roughly matching the outflow. What you're asking for, I think, is some sensitivity to the scope of a change vs. how long it's been pending. This is a pretty hard problem to address -- if it falls to triagers, you're back where we started of triaging not being able to keep up with the queue. It'd be nice if Trac stored time-stamped state transitions to reveal this sort of thing. That said, I wasn't aware that the # of untriaged tickets was that high-- if I had known, maybe I would have spent more time triaging. So I'm asking myself: where in the process are there places that workflow breaks down, and how can we make those places more visible? I'm presuming that if it were more visible, it would be better addressed -- but it may simply be the case that we need more volunteers to step into the break -- to stop filing their feature patches, and to start clearing the triage queue. http://docs.djangoproject.com/en/dev/internals/contributing/#triage-by-the-general-community -- 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.
