Django Weblog: New governance model for the Django project

History and rationale

The Django open-source project was started by Adrian Holovaty and Jacob Kaplan-Moss, who also served as the first leaders of the project. They made the first few grants of commit access to other people back in the early days after Django was open-sourced, and the core team of committers had grown significantly by 2014, when Adrian and Jacob chose to step down from their leadership roles. At that time the basic structure, of a core team of committers who could add code to Django as they chose, was retained, and a new group -- a "Technical Board" of five committers, elected by the core committers -- was created to serve as an ultimate tie-breaking decision-maker.

In practice, however, almost all code added to Django now is merged by the Django Fellows -- paid contractors of the Django Software Foundation, whose responsibilities include triaging, reviewing, and merging pull requests to Django -- or by a small number of active volunteer committers. And all releases of Django are now issued by the Fellows, on schedules decided well in advance. Which means most of the historical "core team" of committers now have very little direct involvement with Django despite holding significant theoretical power within the project. And instead of committers discussing and deciding amongst themselves, nearly all technical decisions in Django's development are made by consensus on public forums where anyone can participate.

Additionally, the growth of that "core team" has slowed almost to a standstill; new committers are added only very rarely, and there's neither a clear path to "core" status nor any way for someone to tell whether they are, or could be, a good candidate for it. Discussions on project mailing lists and in-person at conferences have also indicated that many potential contributors measure themselves against an unrealistic idea of both their own capabilities, and of the prowess of the existing "core" developers, which has the effect of discouraging perfectly well-qualified people from attempting to get more seriously involved in contributing to Django.

All of this is frustrating for everyone, and not good for Django's long-term health as a project. Replacing or reforming "Django core" and the project's governance has thus become a perennial topic of long discussions, especially among the current "core" team and groups like the DSF membership.

What's changing

As of the adoption of DEP 10, the structure of the Django open-source project is changing in several ways. The former "core team" is now dissolved, and the commit access of the former "core" members will be removed. A new role -- "Merger" -- is being created, and will have commit access, but only to merge pull requests from others: Mergers cannot decide to add things to Django on their own initiative, and hold no special decision-making privileges.

Alongside this, a new role of "Releaser" is being created, and will have access to issue releases of Django and carry out the associated mechanics (like bumping version numbers in key files).

Technical decisions are already, in practice, made by consensus in public venues where anyone can participate; this is now formalized as the primary and expected way Django will be developed, and there will not be any special class of "committers" or "core" individuals with special power to commit or block something solely on their own say-so.

The Technical Board will be kept as a final decision-making authority for cases where this is needed -- which have historically come up only rarely -- and is also charged with canvassing for ideas and proposals for Django's future technical direction, and with setting the release schedule.

However, membership on the Technical Board will no longer be restricted to committers, and the Technical Board will no longer be elected by committers, which is necessary because the "core" committers, as a group, cease to exist. Instead, anyone who demonstrates a history of technical contributions to Django is eligible to run for the Technical Board, and the Technical Board will be elected by the DSF's Individual members, all of whom have been granted that membership based on their involvement with and contributions to Django (and there are provisions for non-DSF-member voters in the rare case where someone who's been involved with Django does not hold DSF membership). This expands Technical Board elections from having around 50 potential voters (with the old model of only committers voting) to currently nearly 200, and quite likely more as the DSF's membership grows.

Both the voter rolls, and the elections of the Technical Board, will be overseen by the Board of Directors of the DSF (with any DSF Board member who runs for the Technical Board having to abstain from involvement in election oversight), which will have the authority to investigate the qualifications and good faith of both candidates and voters.

Finally, the term "Django Core Developer" is being repurposed as an honorary title, bestowed by the DSF on individuals who've had major, long-term impact on the history of Django, similar to the "Fellow of the Python Software Foundation" honor bestowed by the PSF for contributions to Python. This title will be automatically granted to anyone who held "core" status -- in any of several forms, because that term has been nebulous on occasion -- at any time prior to DEP 10's adoption.

Effective immediately the Django Fellows, currently Carlton Gibson and Mariusz Felisiak, are the initial Mergers and Releasers, and the Django Technical Board will appoint additional people into those roles as needed to keep them properly staffed. The current Technical Board and the DSF Board also will work to hold the first election of a new Technical Board under DEP 10, which will be held once the necessary registration and voting infrastructure are in place.

There will also be a flurry of updates to documentation and other parts of the Django project website to ensure the new process and structure are described as accurately as possible. Until then, please refer people to this blog post for its summary of what's happening, or to the text of DEP 10 for the full details.

The future

Later this year we'll be celebrating the 15th anniversary of the original open-sourcing of Django. In that time, there have been 278 releases of the framework, nearly 1,900 people have contributed to the primary repository, and the number of people who've learned and used Django is nearly impossible to measure; the main django-users mailing list has tens of thousands of members, and is certain to represent only a fraction of the global Django-using community.

It's the hope of everyone who worked on this proposal that formally opening up Django's governance and decision-making will put the project on a healthier and more sustainable footing for the long term, and remove one of the barriers (the effective obsolescence of the "Django core" and stagnation of its membership) to welcoming new contributors to Django from all parts of its worldwide community.