mininglabs

Data mining, analysis and visualization

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