diff --git a/accepted/README.rst b/accepted/README.rst index 3a417584..e04c19d5 100644 --- a/accepted/README.rst +++ b/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. \ No newline at end of file +details. diff --git a/draft/0007-dependency-policy.rst b/draft/0007-dependency-policy.rst index f2665bca..afb600f3 100644 --- a/draft/0007-dependency-policy.rst +++ b/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 ========= diff --git a/final/0001-dep-process.rst b/final/0001-dep-process.rst index 0e9a1f3a..86e672c3 100644 --- a/final/0001-dep-process.rst +++ b/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 `_ is the best way to go about this. +`Django Internals on the forum `_ +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", diff --git a/final/0011-accessibility-team.rst b/final/0011-accessibility-team.rst index a0e5ae20..a1b36701 100644 --- a/final/0011-accessibility-team.rst +++ b/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. diff --git a/rejected/README.rst b/rejected/README.rst index fd77e894..559882f8 100644 --- a/rejected/README.rst +++ b/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.