From 42f8f113f590e48fd4747bff405cb45474745bb6 Mon Sep 17 00:00:00 2001 From: Thibaud Colas Date: Wed, 16 Oct 2024 23:50:07 +0100 Subject: [PATCH 1/2] Update DEPs terminology to match current landscape --- accepted/README.rst | 4 +-- draft/0007-dependency-policy.rst | 42 ++++++++++++++++++------------- final/0001-dep-process.rst | 39 +++++++++++++++------------- final/0011-accessibility-team.rst | 2 +- rejected/README.rst | 2 +- 5 files changed, 49 insertions(+), 40 deletions(-) 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 9ff3467d..b820d605 100644 --- a/draft/0007-dependency-policy.rst +++ b/draft/0007-dependency-policy.rst @@ -25,8 +25,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 @@ -56,7 +56,7 @@ as Django itself. We define "maturity" as: issues that wouldn't make it into Django shouldn't be accepted as a dependency, either. -- **Maintained** - if we discover bugs in a dependency, we need to be fairly +- **Maintained** - if we discover bugs in a dependency, we need to be fairly confident that they'll be fixed quickly. - **Takes security seriously** - we should be confident that if we or our users @@ -65,18 +65,18 @@ as Django itself. We define "maturity" as: should have a vulnerability disclosure policy, security-specific contacts, and a history of taking vulnerabilities seriously. -- **Works on all the same platforms as Django does** - Linux, Mac, Windows, - and all supported Python versions (including PyPy). This probably means that - dependencies that require C extensions are probably not acceptable [1]_. +- **Works on all the same platforms as Django does** - Linux, Mac, Windows, + and all supported Python versions (including PyPy). This probably means that + dependencies that require C extensions are probably not acceptable [1]_. - **Backwards compatible** in minor releases. We should be able to specify as wide a range of required versions as possible so that releases of Django are de-coupled (as much as possible) from dependencies. Generally, we'll want to specify dependencies as ``foo>=1.0,<2.0``, and be confident that - point-releases of ``foo`` won't break Django. + 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- @@ -103,8 +103,8 @@ answers a few questions: - What's the dependency? Why should we use it over re-inventing this particular wheel [2]_? -- Does the package meet the maturity bar laid out above? If there are - any maturity risks -- for example, if the project only has a single +- Does the package meet the maturity bar laid out above? If there are + any maturity risks -- for example, if the project only has a single maintainer -- that should be identified so we can do a cost/benefit analysis. @@ -123,11 +123,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 ========================= @@ -151,8 +151,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. @@ -186,7 +186,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: @@ -214,6 +214,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 9b6ded7e..4c33de1c 100644 --- a/final/0001-dep-process.rst +++ b/final/0001-dep-process.rst @@ -7,7 +7,7 @@ DEP 1: DEP Purpose and Guidelines :Status: Final :Type: Process :Created: 2014-04-14 -:Last-Modified: 2023-10-21 +:Last-Modified: 2023-10-21 .. contents:: Table of Contents :depth: 3 @@ -144,8 +144,8 @@ Shepherd can be someone with a long history of contributing to Django, who can help the Author assess the fitness of their proposal and help make sure it gets accepted. The primary job of the Shepherd will be to review the DEP in an - editorial role, and help guide the Author through the DEP process. - + editorial role, and help guide the Author through the DEP process. + The Shepherd may be a `Merger`_, and if so the Shepherd will be the one who actually merges the code into the project. Or, the Shepherd may be a member of the Steering Council, which can help streamline discussion. @@ -202,7 +202,7 @@ Once the DEP is ready for the repository, the reviewer will: * Merge the pull request. * Assign a DEP number (almost always just the next available number), and rename - the DEP file with the new number (e.g. rename ``dep-process.rst`` to + the DEP file with the new number (e.g. rename ``dep-process.rst`` to ``0001-dep-process.rst``) Developers with commit access to the DEPs repo may create drafts directly by @@ -296,17 +296,17 @@ DEP format To save everyone time reading DEPs, they need to follow a common format and outline; this section describes that format. In most cases, it's probably easiest to start with copying the provided `DEP template <../template.rst>`_, -and filling it in as you go. +and filling it in as you go. -DEPs must be written in `reStructuredText `_ -(the same format as Django's documentation). +DEPs must be written in `reStructuredText `_ +(the same format as Django's documentation). Each DEP should have the following parts: #. A short descriptive title (e.g. "ORM expressions"), which is also reflected in the DEP's filename (e.g. ``0181-orm-expressions.rst``). -#. A preamble -- a rST `field list `_ +#. A preamble -- a rST `field list `_ containing metadata about the DEP, including the DEP number, the names of the various members of the `DEP team <#forming- the-team>`_, and so forth. See `DEP Metadata`_ below for specific details. @@ -355,8 +355,8 @@ Each DEP should have the following parts: DEP Metadata ------------ -Each DEP must begin with some metadata given as an rST -`field list `_. +Each DEP must begin with some metadata given as an rST +`field list `_. The headers must contain the following fields: ``DEP`` @@ -398,8 +398,8 @@ Auxiliary Files --------------- DEPs may include auxiliary files such as diagrams. Such files must be named -``XXXX-descriptive-title.ext``, where "XXXX" is the DEP number, -"descriptive-title" is a short slug indicating what the file contains, and +``XXXX-descriptive-title.ext``, where "XXXX" is the DEP number, +"descriptive-title" is a short slug indicating what the file contains, and "ext" is replaced by the actual file extension (e.g. "png"). Reporting DEP Bugs, or Submitting DEP Updates @@ -451,8 +451,8 @@ Differences between DEPs and PEPs process either. As stated in the preamble, the DEP process is more or less a direct copy of -the PEP process (and this document is a modified version of -`PEP 1 `_). +the PEP process (and this document is a modified version of +`PEP 1 `_). Relative to the PEP process, we made the following changes in DEPs: @@ -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 cc4594d0..61946e21 100644 --- a/final/0011-accessibility-team.rst +++ b/final/0011-accessibility-team.rst @@ -52,7 +52,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. From fdbbfddd0371bcf5064172cb5c79f52ad9949f43 Mon Sep 17 00:00:00 2001 From: Thibaud Colas Date: Tue, 12 Nov 2024 23:09:59 +0000 Subject: [PATCH 2/2] Remove django-developers references from DEP 1 --- final/0001-dep-process.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/final/0001-dep-process.rst b/final/0001-dep-process.rst index 4c33de1c..b1b8ccc6 100644 --- a/final/0001-dep-process.rst +++ b/final/0001-dep-process.rst @@ -105,8 +105,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 @@ -165,7 +165,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. @@ -177,7 +177,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