Update DEPs terminology to match current landscape

accepted/README.rst

@@ -1,6 +1,6 @@
 Approved DEPs
 =============
 
-DEPs that have been approved by the Technical Board and are in the
+DEPs that have been approved by the Steering Council and are in the
 process of being implemented. See `DEP 1 <../final/0001-dep-process.rst>`_ for
-details.
+details.

draft/0007-dependency-policy.rst

@@ -24,8 +24,8 @@ policy of "no external dependencies allowed."
 In a nutshell, the policy is that adding a new external dependency should be
 treated similarly to adding a major new feature to Django: it requires a DEP,
 demonstration that the dependency is needed, rough consensus among the
-community and core team that the chosen dependency, and a final decision by
-the Technical Board.
+community and core contributors that the chosen dependency,
+and a final decision by the Steering Council.
 
 The rest of this document explains the guidelines and process for adding new
 dependencies, as well as the background and motivation about why this policy was
@@ -75,7 +75,7 @@ as Django itself. We define "maturity" as:
   point-releases of ``foo`` won't break Django.
 
 Again, these are guidelines. At the end of the day, the criteria comes down to
-"would we include this code in Django?" The Tech Board has the final call.
+"would we include this code in Django?" The Steering Council has the final call.
 
 .. [1] Note the "probably" there. It is, in principle, possible to distribute
        C extensions in a way that no longer requires a compiler -- platform-
@@ -122,11 +122,11 @@ Re-evaluating dependencies
 --------------------------
 
 During each minor release cycle -- and especially before LTS releases -- the
-core team should re-evaluate all existing dependencies. If some dependency is
-starting regress on the maturity front (particularly if it has become
-unmaintained), we want to identify it early and start looking for backup plans.
-This might mean removing the dependency, taking over maintenance ourselves,
-looking for funding to pay new maintainers, etc.
+core contributors should re-evaluate all existing dependencies. If some
+dependency is starting regress on the maturity front (particularly if it has
+become unmaintained), we want to identify it early and start looking for backup
+plans. This might mean removing the dependency, taking over maintenance
+ourselves, looking for funding to pay new maintainers, etc.
 
 Background and Motivation
 =========================
@@ -150,8 +150,8 @@ occasional downtime, leading to frustration when trying to deploy to production.
 didn't go well. Many users struggled even to get the package installed.
 
 That experience led to a deep suspicion of Python packaging tools among the
-Django core team, and a de-facto policy emerged of only requiring the lowest
-common denominator: installation via direct download and ``python setup.py
+Django core contributors, and a de-facto policy emerged of only requiring the
+lowest common denominator: installation via direct download and ``python setup.py
 install``. This meant not using any of Python's packaging features developed
 since about 2002, including most notably dependencies. In 2016, Django's only
 dependencies are optional.
@@ -185,7 +185,7 @@ we took full advantage of features now available.
 
 In particular, external dependencies -- other packages specified in
 ``setup.py``'s ``install_requires`` argument -- should be fair game to add to
-Django, when appropriate. Django core developers often duplicate effort
+Django, when appropriate. Django core contributors often duplicate effort
 re-implementing  features that are available as dependencies. And, much of the
 time, those external implementations are substantially better than what's
 included in Django. For example:
@@ -213,6 +213,12 @@ specifically -- there may be good arguments both for and against each specific
 example. They're offered here as examples to of the types of options that open
 up once we start to allow external dependencies.
 
+Revision History
+================
+
+2024-10-04
+    Updates to reflect current governance.
+
 Copyright
 =========
 

final/0001-dep-process.rst

@@ -104,8 +104,8 @@ or too broad.  If in doubt, split your DEP into several well-focused ones.
 
 The DEP Author (see below for the formal definition of an Author)
 should first attempt to ascertain whether the idea is DEP-able.  Posting to
-`django-developers <https://docs.djangoproject.com/en/dev/internals/mailing-
-lists /#django-developers-mailing-list>`_ is the best way to go about this.
+`Django Internals on the forum <https://forum.djangoproject.com/c/internals/5>`_
+is the best way to go about this.
 
 Vetting an idea publicly before going as far as writing a DEP is meant to save
 the potential author time. Many ideas have been brought forward for changing
@@ -164,7 +164,7 @@ Submitting the draft
 --------------------
 
 Once the idea's been vetted and the roles are filled, a draft DEP should be
-presented to the Django Forum and/or django-developers. This gives the author a
+presented to the Django Forum. This gives the author a
 chance to flesh out the draft DEP to make sure it's properly formatted, of high
 quality, and to address initial concerns about the proposal.
 
@@ -176,7 +176,7 @@ until proper formatting rules are followed.
 
 At this point, contributors will review the pull request. In most cases the reviewer
 will be the Shepherd of the DEP, but if that's not possible for some reason the
-author may want to ask on django-developers and/or the Django Forum to ensure
+author may want to ask on the Django Forum to ensure
 that this review happens quickly. A reviewer will do the following:
 
 * Read the DEP to check if it is ready: sound and complete.  The ideas
@@ -435,7 +435,7 @@ a competing DEP.
 If you are interested in assuming ownership of a DEP, first try to contact the
 original author and ask for permission. If they approve, ask them to open a pull
 request transferring the DEP to you. If the original author doesn't respond to
-email within a few weeks, contact django-developers.
+email within a few weeks, raise it on the Django Forum.
 
 
 Differences between DEPs and PEPs
@@ -471,7 +471,7 @@ Relative to the PEP process, we made the following changes in DEPs:
     index by status isn't needed.
   - DEP file names are more descriptive (e.g. ``0181-orm-expressions.rst``),
     again to avoid the need for additional tooling.
-  - DEPs are "edited" (e.g. pull request approved) by any core developer,
+  - DEPs are "edited" (e.g. pull request approved) by any core contributor,
     rather than an explicit "editor" role like the PEP editors.
 
 - DEPs are pronounced upon by the Steering Council, rather than a BDFL (because
@@ -481,9 +481,9 @@ Relative to the PEP process, we made the following changes in DEPs:
   and Shepherd) before submission and throughout the process. With PEPs, most
   are authored and implemented by the same person, but the same doesn't seem to
   be true of DEPs (so far), hence the "implementer" role. As for the "shepherd":
-  the BDFL or BDFL-delegate tends to be much more hands-on than the Technical
-  Board, so the role of commenting and critiquing will be fulfilled by the
-  shepherd, rather than the board. Further, we've observed that features are
+  the BDFL or BDFL-delegate tends to be much more hands-on than the Steering
+  Council, so the role of commenting and critiquing will be fulfilled by the
+  shepherd, rather than the Council. Further, we've observed that features are
   tremendously unlikely to make it into Django without a committer on board to
   do the detail-work of merging a patch.
 
@@ -498,6 +498,9 @@ Relative to the PEP process, we made the following changes in DEPs:
 Revision History
 ================
 
+2024-10-04
+    Further updates to reflect current governance.
+
 2023-10-23
     Updates to reflect changes in governance since this document was originally
     written, including changes from "Technical Board" to "Steering Council",

final/0011-accessibility-team.rst

@@ -51,7 +51,7 @@ terminated by:
 - Becoming disqualified due to actions taken by the Code of Conduct committee
   of the Django Software Foundation.
 
-- A vote of the Technical Board, or full consensus of the rest of the
+- A vote of the Steering Council, or full consensus of the rest of the
   Accessibility Team, if the team is considered too large, the person is not
   making positive contributions, or any other sound reason.
 

rejected/README.rst

@@ -1,5 +1,5 @@
 Rejected DEPs
 =============
 
-DEPs that have been rejected by the Technical Board.
+DEPs that have been rejected by the Steering Council.
 See `DEP 1 <../final/0001-dep-process.rst>`_ for details.