Django Fellowship Program: A retrospective
For the past three months, I’ve had the privilege of serving as a "Django Fellow" during the pilot program. I’ve given a weekly summary of my activities on the django-developers mailing list, but the Django Software Foundation asked me to give a retrospective on this blog.
One year ago, Django didn’t have continuous integration with pull requests. It was up to the committer to run the tests locally or hope a contributor had run the tests on all the different database and Python versions that we support. Unfortunately, this resulted in frequent build breakages that would often go unfixed for days or even weeks. This hindered development and made subsequent breakages even more difficult to debug. Last spring (pre-fellowship), I wrote some Ansible playbooks in order to build a small cluster of Jenkins machines so we had enough executors to make pull request integration feasible. This has been a huge win, both for keeping the build green and for helping contributors test their contribution, as they often don’t have all the environments setup locally. During the time of the fellowship, I expanded our Jenkins cluster with some machines running Ubuntu 14.04 (existing machines were on 12.04) to enable testing with newer databases and versions of GIS dependencies. This helped to identify bugs with the newer dependencies and was also needed for testing some of the new contrib.postgres features coming in Django 1.8. I also added flake8 integration on pull requests to flag style warnings before they inadvertently get committed. Automating these checks is one less thing for reviewers to worry about during code reviews.
Also on the infrastructure front, I upgraded the djangoproject.com Web site from Django 1.6 to 1.7. Thanks to the work of many volunteers, we rolled out a new design for djangoproject.com. I helped to QA the new design before it went live.
In our ticket tracker, I’ve triaged around 10 new tickets each week, keeping the “Unreviewed” ticket queue from piling up to 40-50 tickets like has often happened in the past.
Moving on to our release process, Django has struggled with communicating about and issuing timely bug fix releases. Part of the problem was because only a small number of people (two) were able to issue a release. The Django team has remedied this issue by revising our policy on who can release Django. I issued a set of bug fix releases as well as security releases this month. Coordinating security releases by preparing patches and backporting them to all supported versions of Django is a time-consuming task that benefits from dedicated attention that the fellowship program provides.
As the release manager for 1.8, I sent weekly email updates on the status of release blockers and we hit our target for a feature freeze earlier this week and an alpha release last Friday. Rarely have Django releases stayed on their original schedule like this. All the major features that we targeted in our 1.8 Roadmap were completed. I spent a lot of time reviewing many of them. Take a look at the 1.8 release notes for all the great work we’ve completed. To ensure a timely release, I fixed release blockers (regressions or major bugs in next features) myself when no one else had time or interest to work on them.
We’ve also worked hard to fix issues on the stable 1.7 branch. So far the 1.7.x series of releases has fixed over one hundred regressions or bugs in new features.
On the code review front, I reviewed an average of fifteen patches a week from core developers and community members. I think that providing timely code reviews is one of the most important tasks of the fellowship program as it improves the project’s culture and prevents would-be contributors from abandoning us. I don’t think it’s a secret that this is something that Django has struggled with in the past. Consider this testimonial from Loïc Bistuer, who’s now one of Django’s team members:
When I started contributing to Django, patches - especially non-trivial ones - had a tendency to languish in the pull request queue. I eventually gave up on contributing altogether after some of my contributions remained unreviewed for months. Then Tim started dedicating a lot of time to Django and reviewed my contributions. The timely reviews and fast feedback loop acted as catalyst and together we've landed over a hundred patches including 4 major features for Django 1.7 in a matter of months. The churn rate on Django contributors has been very high historically and the Fellowship program is a direct answer to that; it's a great chance for Django and for everyone who relies on it.
I hope you’ll consider a gift to the Django Software Foundation to help renew the fellowship program and all the exciting work it enables.
Back to Top