diff --git a/pep-8002.rst b/pep-8002.rst index b2dfacde2..8e5223653 100644 --- a/pep-8002.rst +++ b/pep-8002.rst @@ -490,6 +490,105 @@ the Project was doing (prior to 2015 when the Main Governance Document was adopted by the Steering Council), rather than a change in direction. +Django +====== + +The governance structure is documented in `Organization of the Django Project +https://docs.djangoproject.com/en/2.1/internals/organization/`_. + + +Key people and their functions +------------------------------ + +The project recognizes three kinds of contributors. Members of the +core team, the Technical Board, and Fellows. Regular core committers +no longer exercise their "commit bit", instead they rely on pull +requests being reviewed and accepted. There is a bot which merges +the pull request. The Technical Board steers technical choices. +Fellows are hired contractors who triage new tickets and review patches +from the community, including non-trivial ones. + +Core team members are added by nomination and vote within the core +team, with technical board veto (so far not exercised). Technical +board is elected by and from the core team membership every 18 months +(every major Django release). Sub-teams within the core team are +self-selected by interest. + + +Regular decision process +------------------------ + +Most day-to-day decisions are made by Fellows and sometimes other active +core team members. + +The core team votes on new members which requires a 4/5 majority of +votes cast, no quorum requirement. The Technical Board has veto power. +This power was never exercised + + +Controversial decision process +------------------------------ + +The Technical Board occasionally approves Django +Enhancement Proposals (DEPs) but those are rare. The DEP process is +roughly modeled after PEPs and documented in `DEP 1 +`_. +DEPs are mostly used to design major new features, but also for +information on general guidelines and process. + +An idea for a DEP should be first publically vetted on the +django-developers mailing list. After it was roughly validated, the +author forms a team with three roles: + +* *authors* who write the DEP and steers the discussion; +* *implementers* who prepare the implementation of the DEP; +* a *shepherd* who is a core developer and will be the primary reviewer + of the DEP. + +The DEP's draft is submitted, assigned a number, and discussed. Authors +collect feedback and steer discussion as they see fit. Suggested venues +to avoid endless open-ended discussions are: separate mailing lists, +Wiki pages, working off of pull requests on the DEP. + +Once the feedback round is over, the shepherd asks the Technical Board +for review and pronouncement. The Board can rule on a DEP as a team or +designate one member to review and decide. + +In any case where consensus can't be reached, the Technical Board has +final say. This was never exercised. + +Differences between DEPs and PEPs +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The main difference is that the entire workflow is based on pull +requests rather than e-mail. They are pronounced upon by the Technical +Board. They need to have the key roles identified before submission +and throughout the process. The *shepherd* role exists to guide a DEP +to completion without engaging the Technical Board. + +Those changes to the process make it more distributed and workable in +a governance model without a BDFL. + + +Planning a new release +---------------------- + +Releases are done on a fixed time-based schedule, with a major version +every 18 months. With paid Fellows to ensure the necessary work gets +down, on-time releases are routine. + + +Changes in the process over time +-------------------------------- + +Django originally had two BDFLs: Jacob Kaplan-Moss and Adrian Holovaty. +They retired (`Adrian's post +`_, `Jacob's post +`_) +9 years into the project's history. Following the stepping down, +the DEP process was defined. + + Acknowledgements ================