Refs #31676 -- Updated technical board description in organization docs.
According to DEP 0010.
This commit is contained in:
parent
228ec8e015
commit
f2ed2211c2
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue