[pep-8002] Django
This commit is contained in:
parent
b930b50071
commit
42eea19c8b
99
pep-8002.rst
99
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
|
||||
<https://github.com/django/deps/blob/master/final/0001-dep-process.rst>`_.
|
||||
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
|
||||
<http://www.holovaty.com/writing/bdfls-retiring/>`_, `Jacob's post
|
||||
<https://jacobian.org/writing/retiring-as-bdfls/>`_)
|
||||
9 years into the project's history. Following the stepping down,
|
||||
the DEP process was defined.
|
||||
|
||||
|
||||
Acknowledgements
|
||||
================
|
||||
|
||||
|
|
Loading…
Reference in New Issue