On Thu, Feb 25, 2010 at 3:43 AM, Jeremy Dunck <jdu...@gmail.com> wrote: > 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.
There's also a more fundamental issue - simple availability of volunteer time. Part of the reason that the ticket queue is so large is a sheer lack of resources. For example, about two weeks ago, I spent just over a week triaging unreviewed tickets. This is time I didn't spend committing other tickets. The only reason I did this is because a backlog of 300 tickets had accumulated, and we can't make a release with unreviewed tickets, since an unreviewed ticket is potentially an unknown release blocker. I'm not casting blame here. Those doing triage work are doing a great job. I'm just pointing out that we have a problem. Despite the best efforts of our volunteer triage team, they haven't been able to keep up with the backlog. We either need more volunteers to do triage, or we need to accept as a community that progress isn't going to be as fast as we may like. There is also an extent to which Django 1.2 has been the culprit. Django 1.2 has been particularly unkind to the ticket queue. The feature list for 1.2 is *huge*, and this has meant that smaller issues have taken a back seat. For comparison, we made lots of bugfixes during the 1.1 development cycle - enough to warrant 1.0.1 and 1.0.2 point releases. However, during the 1.2 development cycle, there really hasn't been enough activity in 1.1.X to warrant us cutting a bugfix release. One concrete suggestion I would make is that we scale down our goals for 1.3. There are still a couple of big ticket items that are pending from 1.2 (like class-based generic views and logging). There are also some lingering big issues that we need to address (like the flexibility of auth.User). However, I think we would be well served to deliberately hold back on big features for 1.3 in the interests of clearing some of our ticket backlog. >> 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. Completely agreed. You can't fix the problem of people not reading the documentation by providing more documentation. >> 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. ... > 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. The things we need to have in Trac are exactly the things we can't have because of our open-door policy. Ticket fields like "feature", "severity" and "priority" are great at identifying tickets that require attention -- as long as they are curated in a consistent way. We used to have these flags in Django's trac, and every bug was reported "critical, high priority bug" -- since, to the person reporting it, it probably was. The net result is that the flags mean nothing. The set of flags we have currently are designed to minimize the amount of Trac gardening we have to do. I'm open to any suggestions on how we could be using Trac (or any other tool) better, but in making these suggestions, you need to be able to work within the constraints that exist, such as the inconsistent (and unknowable) volunteer effort levels and allowing contributions from people unfamiliar with our process. 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.
