Refs #31676 -- Updated technical board description in organization docs.

According to DEP 0010.
This commit is contained in:
Mariusz Felisiak 2021-07-21 11:06:58 +02:00
parent 228ec8e015
commit f2ed2211c2
1 changed files with 108 additions and 36 deletions

View File

@ -30,7 +30,7 @@ Role
---- ----
Mergers_ are a small set of people who merge pull requests to the `Django Git Mergers_ are a small set of people who merge pull requests to the `Django Git
repository <https://github.com/django/django>`_. repository`_.
Prerogatives Prerogatives
------------ ------------
@ -166,63 +166,135 @@ Technical board
Role Role
---- ----
The technical board is a group of experienced and active committers who steer The technical board is a group of experienced contributors who:
technical choices. Their main concern is to maintain the quality and stability
of the Django web framework. - 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 Prerogatives
------------ ------------
The technical board holds two prerogatives: The technical board holds the following prerogatives:
- Making major technical decisions when no consensus is found otherwise. This - Making a binding decision regarding any question of a technical change to
happens on the |django-developers| mailing-list. Django.
- Veto a grant of commit access or remove commit access. This happens on the - Vetoing the merging of any particular piece of code into Django or ordering
``django-core`` mailing-list. the reversion of any particular merge or commit.
- Announcing calls for proposals and ideas for the future technical direction
In both cases, the technical board is a last resort. In these matters, it of Django.
fulfills a similar function to the former Benevolent Dictators For Life. - Setting and adjusting the schedule of releases of Django.
- Selecting and removing mergers and releasers.
When the board wants to exercise one of these prerogatives, it must hold a - Participating in the removal of members of the technical board, when deemed
private, simple majority vote on the resolution. The quorum is the full appropriate.
committee — each member must cast a vote or abstain explicitly. Then the board - Calling elections of the technical board outside of those which are
communicates the result, and if possible the reasons, on the appropriate automatically triggered, at times when the technical board deems an election
mailing-list. There's no appeal for such decisions. is appropriate.
- Participating in modifying Django's governance (see
In addition, at its discretion, the technical board may act in an advisory :ref:`organization-change`).
capacity on non-technical decisions. - 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 Membership
---------- ----------
`The technical board`_ is an elected group of five committers. They're expected `The technical board`_ is an elected group of five experienced contributors
to be experienced but there's no formal seniority requirement. who demonstrate:
A new board is elected after each feature release of Django. The election - A history of technical contributions to Django or the Django ecosystem. This
process is managed by a returns officer nominated by the outgoing technical history must begin at least 18 months prior to the individual's candidacy for
board. The election process works as follows: 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:
#. Candidates advertise their application for the technical board to the team. - 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.
They must be committers already. There's no term limit for technical board - A history of recent engagement with the direction and development of Django.
members. Such engagement must have occurred within a period of no more than two years
prior to the individual's candidacy for the technical board.
#. Each team member can vote for zero to five people among the candidates. A new board is elected after each release cycle of Django. The election process
Candidates are ranked by the total number of votes they received. works as follows:
In case of a tie, the person who joined the core team earlier wins. #. 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.
Both the application and the voting period last between one and two weeks, at A member of the technical board may be removed by:
the outgoing board's discretion.
- 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 .. _mergers: https://www.djangoproject.com/foundation/teams/#mergers-team
.. _releasers: https://www.djangoproject.com/foundation/teams/#releasers-team .. _releasers: https://www.djangoproject.com/foundation/teams/#releasers-team
.. _`security team`: https://www.djangoproject.com/foundation/teams/#security-team .. _`security team`: https://www.djangoproject.com/foundation/teams/#security-team
.. _`the technical board`: https://www.djangoproject.com/foundation/teams/#technical-board-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 .. _`triage & review team`: https://www.djangoproject.com/foundation/teams/#triage-review-team
.. _organization-change:
Changing the organization Changing the organization
========================= =========================
Changes to this document require a four fifths majority of votes cast in a Changes to this document require the use of the `DEP process`_, with
core team vote and no veto by the technical board. 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