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

According to DEP 0010.

docs/internals/organization.txt

@@ -30,7 +30,7 @@ Role
 ----
 
 Mergers_ are a small set of people who merge pull requests to the `Django Git
-repository <https://github.com/django/django>`_.
+repository`_.
 
 Prerogatives
 ------------
@@ -166,63 +166,135 @@ Technical board
 Role
 ----
 
-The technical board is a group of experienced and active committers who steer
-technical choices. Their main concern is to maintain the quality and stability
-of the Django web framework.
+The technical board is a group of experienced contributors who:
 
-Prerogatives
-------------
-
-The technical board holds two prerogatives:
-
-- Making major technical decisions when no consensus is found otherwise. This
-  happens on the |django-developers| mailing-list.
-- Veto a grant of commit access or remove commit access. This happens on the
-  ``django-core`` mailing-list.
+- 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.
 
-In both cases, the technical board is a last resort. In these matters, it
-fulfills a similar function to the former Benevolent Dictators For Life.
+Their main concern is to maintain the quality and stability of the Django Web
+Framework.
 
-When the board wants to exercise one of these prerogatives, it must hold a
-private, simple majority vote on the resolution. The quorum is the full
-committee — each member must cast a vote or abstain explicitly. Then the board
-communicates the result, and if possible the reasons, on the appropriate
-mailing-list. There's no appeal for such decisions.
+Prerogatives
+------------
 
-In addition, at its discretion, the technical board may act in an advisory
-capacity on non-technical decisions.
+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 committers. They're expected
-to be experienced but there's no formal seniority requirement.
-
-A new board is elected after each feature release of Django. The election
-process is managed by a returns officer nominated by the outgoing technical
-board. The election process works as follows:
-
-#. Candidates advertise their application for the technical board to the team.
-
-   They must be committers already. There's no term limit for technical board
-   members.
-
-#. Each team member can vote for zero to five people among the candidates.
-   Candidates are ranked by the total number of votes they received.
-
-   In case of a tie, the person who joined the core team earlier wins.
-
-Both the application and the voting period last between one and two weeks, at
-the outgoing board's discretion.
+`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 a four fifths majority of votes cast in a
-core team vote and no veto by the technical board.
+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