django/docs/internals/organization.txt

==================================
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