301 lines
13 KiB
Plaintext
301 lines
13 KiB
Plaintext
==================================
|
|
Organization of the Django Project
|
|
==================================
|
|
|
|
Principles
|
|
==========
|
|
|
|
The Django Project is managed by a team of volunteers pursuing three goals:
|
|
|
|
- Driving the development of the Django web framework,
|
|
- Fostering the ecosystem of Django-related software,
|
|
- Leading the Django community in accordance with the values described in the
|
|
`Django Code of Conduct`_.
|
|
|
|
The Django Project isn't a legal entity. The `Django Software Foundation`_, a
|
|
non-profit organization, handles financial and legal matters related to the
|
|
Django Project. Other than that, the Django Software Foundation lets the
|
|
Django Project manage the development of the Django framework, its ecosystem
|
|
and its community.
|
|
|
|
.. _Django Code of Conduct: https://www.djangoproject.com/conduct/
|
|
.. _Django Software Foundation: https://www.djangoproject.com/foundation/
|
|
|
|
.. _mergers-team:
|
|
|
|
Mergers
|
|
=======
|
|
|
|
Role
|
|
----
|
|
|
|
Mergers_ are a small set of people who merge pull requests to the `Django Git
|
|
repository`_.
|
|
|
|
Prerogatives
|
|
------------
|
|
|
|
Mergers hold the following prerogatives:
|
|
|
|
- Merging any pull request which constitutes a `minor change`_ (small enough
|
|
not to require the use of the `DEP process`_). A Merger must not merge a
|
|
change primarily authored by that Merger, unless the pull request has been
|
|
approved by:
|
|
|
|
- another Merger,
|
|
- a technical board member,
|
|
- a member of the `triage & review team`_, or
|
|
- a member of the `security team`_.
|
|
|
|
- Initiating discussion of a minor change in the appropriate venue, and request
|
|
that other Mergers refrain from merging it while discussion proceeds.
|
|
- Requesting a vote of the technical board regarding any minor change if, in
|
|
the Merger's opinion, discussion has failed to reach a consensus.
|
|
- Requesting a vote of the technical board when a `major change`_ (significant
|
|
enough to require the use of the `DEP process`_) reaches one of its
|
|
implementation milestones and is intended to merge.
|
|
|
|
.. _`minor change`: https://github.com/django/deps/blob/main/accepted/0010-new-governance.rst#terminology
|
|
.. _`major change`: https://github.com/django/deps/blob/main/accepted/0010-new-governance.rst#terminology
|
|
|
|
Membership
|
|
----------
|
|
|
|
`The technical board`_ selects Mergers_ as necessary to maintain their number
|
|
at a minimum of three, in order to spread the workload and avoid over-burdening
|
|
or burning out any individual Merger. There is no upper limit to the number of
|
|
Mergers.
|
|
|
|
It's not a requirement that a Merger is also a Django Fellow, but the Django
|
|
Software Foundation has the power to use funding of Fellow positions as a way
|
|
to make the role of Merger sustainable.
|
|
|
|
The following restrictions apply to the role of Merger:
|
|
|
|
- A person must not simultaneously serve as a member of the technical board. If
|
|
a Merger is elected to the technical board, they shall cease to be a Merger
|
|
immediately upon taking up membership in the technical board.
|
|
- A person may serve in the roles of Releaser and Merger simultaneously.
|
|
|
|
The selection process, when a vacancy occurs or when the technical board deems
|
|
it necessary to select additional persons for such a role, occur as follows:
|
|
|
|
- Any member in good standing of an appropriate discussion venue, or the Django
|
|
Software Foundation board acting with the input of the DSF's Fellowship
|
|
committee, may suggest a person for consideration.
|
|
- The technical board considers the suggestions put forth, and then any member
|
|
of the technical board formally nominates a candidate for the role.
|
|
- The technical board votes on nominees.
|
|
|
|
Mergers may resign their role at any time, but should endeavor to provide some
|
|
advance notice in order to allow the selection of a replacement. Termination of
|
|
the contract of a Django Fellow by the Django Software Foundation temporarily
|
|
suspends that person's Merger role until such time as the technical board can
|
|
vote on their nomination.
|
|
|
|
Otherwise, a Merger may be removed by:
|
|
|
|
- Becoming disqualified due to election to the technical board.
|
|
- Becoming disqualified due to actions taken by the Code of Conduct committee
|
|
of the Django Software Foundation.
|
|
- A vote of the technical board.
|
|
|
|
.. _releasers-team:
|
|
|
|
Releasers
|
|
=========
|
|
|
|
Role
|
|
----
|
|
|
|
Releasers_ are a small set of people who have the authority to upload packaged
|
|
releases of Django to the `Python Package Index`_, and to the
|
|
`djangoproject.com`_ website.
|
|
|
|
Prerogatives
|
|
------------
|
|
|
|
Releasers_ :doc:`build Django releases </internals/howto-release-django>` and
|
|
upload them to the `Python Package Index`_, and to the `djangoproject.com`_
|
|
website.
|
|
|
|
Membership
|
|
----------
|
|
|
|
`The technical board`_ selects Releasers_ as necessary to maintain their number
|
|
at a minimum of three, in order to spread the workload and avoid over-burdening
|
|
or burning out any individual Releaser. There is no upper limit to the number
|
|
of Releasers.
|
|
|
|
It's not a requirement that a Releaser is also a Django Fellow, but the Django
|
|
Software Foundation has the power to use funding of Fellow positions as a way
|
|
to make the role of Releaser sustainable.
|
|
|
|
A person may serve in the roles of Releaser and Merger simultaneously.
|
|
|
|
The selection process, when a vacancy occurs or when the technical board deems
|
|
it necessary to select additional persons for such a role, occur as follows:
|
|
|
|
- Any member in good standing of an appropriate discussion venue, or the Django
|
|
Software Foundation board acting with the input of the DSF's Fellowship
|
|
committee, may suggest a person for consideration.
|
|
- The technical board considers the suggestions put forth, and then any member
|
|
of the technical board formally nominates a candidate for the role.
|
|
- The technical board votes on nominees.
|
|
|
|
Releasers may resign their role at any time, but should endeavor to provide
|
|
some advance notice in order to allow the selection of a replacement.
|
|
Termination of the contract of a Django Fellow by the Django Software
|
|
Foundation temporarily suspends that person's Releaser role until such time as
|
|
the technical board can vote on their nomination.
|
|
|
|
Otherwise, a Releaser may be removed by:
|
|
|
|
- Becoming disqualified due to actions taken by the Code of Conduct committee
|
|
of the Django Software Foundation.
|
|
- A vote of the technical board.
|
|
|
|
.. _`Python Package Index`: https://pypi.org/project/Django/
|
|
.. _djangoproject.com: https://www.djangoproject.com/download/
|
|
|
|
.. _technical-board:
|
|
|
|
Technical board
|
|
===============
|
|
|
|
Role
|
|
----
|
|
|
|
The technical board is a group of experienced contributors who:
|
|
|
|
- provide oversight of Django's development and release process,
|
|
- assist in setting the direction of feature development and releases,
|
|
- take part in filling certain roles, and
|
|
- have a tie-breaking vote when other decision-making processes fail.
|
|
|
|
Their main concern is to maintain the quality and stability of the Django Web
|
|
Framework.
|
|
|
|
Prerogatives
|
|
------------
|
|
|
|
The technical board holds the following prerogatives:
|
|
|
|
- Making a binding decision regarding any question of a technical change to
|
|
Django.
|
|
- Vetoing the merging of any particular piece of code into Django or ordering
|
|
the reversion of any particular merge or commit.
|
|
- Announcing calls for proposals and ideas for the future technical direction
|
|
of Django.
|
|
- Setting and adjusting the schedule of releases of Django.
|
|
- Selecting and removing mergers and releasers.
|
|
- Participating in the removal of members of the technical board, when deemed
|
|
appropriate.
|
|
- Calling elections of the technical board outside of those which are
|
|
automatically triggered, at times when the technical board deems an election
|
|
is appropriate.
|
|
- Participating in modifying Django's governance (see
|
|
:ref:`organization-change`).
|
|
- Declining to vote on a matter the technical board feels is unripe for a
|
|
binding decision, or which the technical board feels is outside the scope of
|
|
its powers.
|
|
- Taking charge of the governance of other technical teams within the Django
|
|
open-source project, and governing those teams accordingly.
|
|
|
|
Membership
|
|
----------
|
|
|
|
`The technical board`_ is an elected group of five experienced contributors
|
|
who demonstrate:
|
|
|
|
- A history of technical contributions to Django or the Django ecosystem. This
|
|
history must begin at least 18 months prior to the individual's candidacy for
|
|
the technical board.
|
|
- A history of participation in Django's development outside of contributions
|
|
merged to the `Django Git repository`_. This may include, but is not
|
|
restricted to:
|
|
|
|
- Participation in discussions on the |django-developers| mailing list or
|
|
the `Django forum`_.
|
|
- Reviewing and offering feedback on pull requests in the Django source-code
|
|
repository.
|
|
- Assisting in triage and management of the Django bug tracker.
|
|
|
|
- A history of recent engagement with the direction and development of Django.
|
|
Such engagement must have occurred within a period of no more than two years
|
|
prior to the individual's candidacy for the technical board.
|
|
|
|
A new board is elected after each release cycle of Django. The election process
|
|
works as follows:
|
|
|
|
#. The technical board direct one of its members to notify the Secretary of the
|
|
Django Software Foundation, in writing, of the triggering of the election,
|
|
and the condition which triggered it. The Secretary post to the appropriate
|
|
venue -- the |django-developers| mailing list and the `Django forum`_ to
|
|
announce the election and its timeline.
|
|
#. As soon as the election is announced, the `DSF Board`_ begin a period of
|
|
voter registration. All `individual members of the DSF`_ are automatically
|
|
registered and need not explicitly register. All other persons who believe
|
|
themselves eligible to vote, but who have not yet registered to vote, may
|
|
make an application to the DSF Board for voting privileges. The voter
|
|
registration form and roll of voters is maintained by the DSF Board. The DSF
|
|
Board may challenge and reject the registration of voters it believes are
|
|
registering in bad faith or who it believes have falsified their
|
|
qualifications or are otherwise unqualified.
|
|
#. Registration of voters close one week after the announcement of the
|
|
election. At that point, registration of candidates begin. Any qualified
|
|
person may register as a candidate. The candidate registration form and
|
|
roster of candidates are maintained by the DSF Board, and candidates must
|
|
provide evidence of their qualifications as part of registration. The DSF
|
|
Board may challenge and reject the registration of candidates it believes do
|
|
not meet the qualifications of members of the Technical Board, or who it
|
|
believes are registering in bad faith.
|
|
#. Registration of candidates close one week after it has opened. One week
|
|
after registration of candidates closes, the Secretary of the DSF publish
|
|
the roster of candidates to the |django-developers| mailing list and the
|
|
`Django forum`_, and the election begin. The DSF Board provide a voting form
|
|
accessible to registered voters, and is the custodian of the votes.
|
|
#. Voting is by secret ballot containing the roster of candidates, and any
|
|
relevant materials regarding the candidates, in a randomized order. Each
|
|
voter may vote for up to five candidates on the ballot.
|
|
#. The election conclude one week after it begins. The DSF Board then tally the
|
|
votes and produce a summary, including the total number of votes cast and
|
|
the number received by each candidate. This summary is ratified by a
|
|
majority vote of the DSF Board, then posted by the Secretary of the DSF to
|
|
the |django-developers| mailing list and the Django Forum. The five
|
|
candidates with the highest vote totals are immediately become the new
|
|
technical board.
|
|
|
|
A member of the technical board may be removed by:
|
|
|
|
- Becoming disqualified due to actions taken by the Code of Conduct committee
|
|
of the Django Software Foundation.
|
|
- Determining that they did not possess the qualifications of a member of the
|
|
technical board. This determination must be made jointly by the other members
|
|
of the technical board, and the `DSF Board`_. A valid determination of
|
|
ineligibility requires that all other members of the technical board and all
|
|
members of the DSF Board vote who can vote on the issue (the affected person,
|
|
if a DSF Board member, must not vote) vote "yes" on a motion that the person
|
|
in question is ineligible.
|
|
|
|
.. _`Django forum`: https://forum.djangoproject.com/
|
|
.. _`Django Git repository`: https://github.com/django/django/
|
|
.. _`DSF Board`: https://www.djangoproject.com/foundation/#board
|
|
.. _`individual members of the DSF`: https://www.djangoproject.com/foundation/individual-members/
|
|
.. _mergers: https://www.djangoproject.com/foundation/teams/#mergers-team
|
|
.. _releasers: https://www.djangoproject.com/foundation/teams/#releasers-team
|
|
.. _`security team`: https://www.djangoproject.com/foundation/teams/#security-team
|
|
.. _`the technical board`: https://www.djangoproject.com/foundation/teams/#technical-board-team
|
|
.. _`triage & review team`: https://www.djangoproject.com/foundation/teams/#triage-review-team
|
|
|
|
.. _organization-change:
|
|
|
|
Changing the organization
|
|
=========================
|
|
|
|
Changes to this document require the use of the `DEP process`_, with
|
|
modifications described in `DEP 0010`_.
|
|
|
|
.. _`DEP process`: https://github.com/django/deps/blob/main/final/0001-dep-process.rst
|
|
.. _`DEP 0010`: https://github.com/django/deps/blob/main/accepted/0010-new-governance.rst#changing-this-governance-process
|