Django moving toward 1.0: tickets overview
As the Django web framework (see our previous study comparing 3 major web frameworks) is moving toward the 1.0 release (due in early september this year), one of the creators of Django, Adrian Holovaty, asked about the strength and weekness of Django replied:
I love the way URLconfs work — like a table of contents for your Web app. I also love template inheritance. I don’t love the fact that we’re generally slow in keeping up with tickets and feature requests.
We decided to take a look at Django’s bug tracking system to see how the team is keeping up with tickets, and especially managing the constant incoming of new tickets filled in by users. Here is the resulting plot of ‘new’ tickets (i.e. before they get classified by Django’s team and excluding those related to the ‘Django Web site’ component) along with marks of the Django releases.
For putting things into perspective, we did the same work for the Turbogears trac. The project is quite similar to Django but the total number of tickets is 4 time smaller (~8k tickets total for Django, ~2k for TurboGears).
Remarks:
- we see that keeping up with bugs and tickets is a real challenge with more than 800 tickets currently in a ‘new’ state and a constant flow of new tickets needing triage being added everyday (8 new tickets are created everyday on average) ; if we compare with TurboGears, we see that the trend is more upward for Django but we have to keep in mind the difference in magnitude of the two projects
- a first task force has drastically reduced the number of tickets right before the 0.96.1 release and the same kind of effort will be required to bring down the number of ‘new’ tickets before the 1.0 release
- maybe a focus on long lasting, (and probably, for some of them) forgotten tickets could help bring to down the ticket number without a major effort and help to focus on recent and relevant tickets
Keeping up with tickets as the framework keeps on gaining momentum is tricky and Django’s team has a great reputation for dealing efficiently with tickets. More than a simple bugtracker, the trac instance is the central place where the community around the project keeps trac of bugs, ideas or wishes. As Django moves toward the 1.0. release, implicate the community as a whole by organising a series of sprints seems to be a bold move to distribuate the burden of dealing with the fair amount of tickets in Django’s trac as much as possible.
[update 1/17:00 July 29th GMT] for putting things into perspective, we added the same graph for TurboGears (figure #2), a quite similar python web framework
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Comments
Nice graph 
I’m not sure about what you’re measuring, but I suspect be measuring something that we don’t pay attention to all that much. We don’t really use Trac’s “new/assigned” states very much; instead, we use a custom “triage state” field to indicate where in the ticket’s lifecycle it is.
Still, you’ll get no complaints from me about your conclusions: keeping up with the incoming flow is incredibly hard, and without a lot of community support and regular sprints we’d simply drown.
I’ve actually been keeping track of some statistics myself for around six months: http://munin.djangoproject.com/com/djangoproject.com-trac_tickets.html. This tracks the “triage state” field, which is probably the most accurate reflection of what’s going on in the tracker.
I think we’ve done an OK job: the number of “unreviewed” tickets has stayed mostly constant since we had a “get control of tickets” sprint in June. Still, it’s been trending upwards, as has the “design decision needed” state, which is worrying.
You’re right, we simply measured the number of tickets in a ‘new’ stage. Since the field ‘state’ is not the primary way for Django developers to mark their work it’s not that significant (but some use that field, otherwise the numbers would not evolve like that over time).
Since the main interest of those graphs is to compare with other projects (TurboGears), we decided to go for a measure (the number of tickets is stage ‘new’) that could be applied to both Django and TurboGears … with all the limitation of the measure …
Good work on the comparison. You seem to be doing an efficient job here!
Turbogears seems to have broken the upward trend better. However, the relatively decreasing number of recent tickets seems to suggest that the user-base or code-base has lost momentum.
pytechd: from another article:
We use R (http://cran.r-project.org/) for generating the graphs.
@pytechd:
we basically use python for everything related to screen scraping, more specifically, we used the BeautifulSoup library to fetch and parse the tickets history in django’s trac.
As snirpyor says, all the graphs are then created with R, a stat library that I strongly encourage you to check out if you’re interested by this kind of visualization.
If you need to get an admission in a school, college or a university or call upon any help in any kind of job, so don’t get anxious. Get ideas about your creation by using custom essay service. I don’t think that there is anything immoral in using writing services.
Insightful in it’s own right, but I would like to see how this compares to other frameworks, or open source projects in general. The first sprint seems to have done wonders.
As far as I know the djangoproject has a good reputation dealing with tickets (in in other respects).