Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update DEPs 1, 10, and 12 to reflect current governance #81

Merged
merged 6 commits into from
Oct 30, 2023
Merged

Update DEPs 1, 10, and 12 to reflect current governance #81

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
7b5c077
✨ Updates DEPs 1, 10, and 12 to reflect current governmence:
jacobian Oct 21, 2023
1ed2dec
✨ updates from @carltongibson's feedback
jacobian Oct 22, 2023
8231278
✏️ typos and fixes from @thibaudcolas
jacobian Oct 23, 2023
0ea0c82
Apply suggestions from code review
jacobian Oct 30, 2023
6cebd5d
♻️ mention the forum first
jacobian Oct 30, 2023
56eace2
🔥 remove potentially elitest-sounding aside
jacobian Oct 30, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
153 changes: 85 additions & 68 deletions final/0001-dep-process.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ DEP 1: DEP Purpose and Guidelines
:Status: Final
:Type: Process
:Created: 2014-04-14
:Last-Modified: 2014-11-15
:Last-Modified: 2023-10-21

.. contents:: Table of Contents
:depth: 3
Expand Down Expand Up @@ -62,23 +62,12 @@ DEP submission workflow

So, you'd like to submit a DEP? Here's how it works, and what to expect.

There are a couple of terms you should be familiar with before reading the
rest of this document:

The Technical Board
There are several reference in this DEP to the **Technical Board**
(sometimes just "the Board"). This refers to Django's `Technical Board
<https://docs.djangoproject.com/en/dev/internals/organization/#technical-
board>`_, the group of experienced and active committers who steer technical
choices. Django's documentation lists `the current Technical Board
membership <https://www.djangoproject.com/foundation/teams
/#technical-board-team>`_.

Core Developers
Similarly, there are several references to **Core Developers** (sometimes
"core devs"). This refers to the members of Django's `core team
<https://docs.djangoproject.com/en/dev/internals/organization/#core-team>`_,
and specifically those with commit access.
There are several references in this DEP to the **Steering Council**. This
refers to Django's `Steering Council
<https://docs.djangoproject.com/en/dev/internals/organization/#steering-council>`_,
the group of experienced and active contributors who steer technical choices.
Django's documentation lists `the current Steering Council membership
<https://www.djangoproject.com/foundation/teams/#steering-council-team>`_.

At a very high level, the DEP submission process looks like this:

Expand All @@ -94,7 +83,7 @@ At a very high level, the DEP submission process looks like this:
4. `Discussion, development, and updates`_ — the DEP and reference
implementation are discussed, improved, and updated as feedback comes in.

5. `Review & Resolution`_ — the DEP is reviewed by the Technical Board and
5. `Review & Resolution`_ — the DEP is reviewed by the Steering Council and
either accepted or rejected.

6. `Implementation`_ — the implementation of the proposed feature is completed
Expand All @@ -110,10 +99,9 @@ that a single DEP contain a single key proposal or new idea. Small enhancements
or patches usually don't need a DEP and follow Django's normal `contribution
process <https://docs.djangoproject.com/en/dev/internals/contributing/>`_.

The more focused the DEP, the more successful it tends to be. The Core
Developers reserve the right to reject DEP proposals if they appear too
unfocused or too broad. If in doubt, split your DEP into several well-focused
ones.
The more focused the DEP, the more successful it tends to be. The Steering
Council reserve the right to reject DEP proposals if they appear too unfocused
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
Expand Down Expand Up @@ -151,38 +139,46 @@ Implementation Team
DEPs generally don't have implementers, and Process DEPs sometimes will.

Shepherd
The **Shepherd** is the Core Developer who will be the primary reviewer
of the DEP on behalf of the Django team, will be the main point person
who will help the Author assess the fitness of their proposal, and
is the person who will finally submit the DEP for pronouncement by the
Technical Board. When the implementation team doesn't contain someone
who can commit to Django, the Shepherd will be the one who actually merges
the code into the project.
If a DEP is being written by someone relatively new to the Django community,
they will likely need a **Shepherd** -- a mentor, essentially -- to help. The 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.

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.

DEPs don't necessarily require a Shepherd, but it's a good idea, especially
for newer contributors.

.. _merger: https://docs.djangoproject.com/en/dev/internals/organization/#mergers

It's normal for a single person to fulfill multiple roles -- in most cases the
Author will be an/the Implementer, and it's not uncommon for the implementation
team to include the Shepherd as well. It's unusual but acceptable for a single
person to fulfill all roles, though this generally only happens when that person
is a long-time committer.
is a long-time contributor.

Submitting the draft
--------------------

Once the idea's been vetted and the roles are filled, a draft DEP should be
presented to django-developers. 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.
presented to the Django Forum and/or django-developers. 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.

Following the discussion on django-developers, the proposal should be sent as a
GitHub pull request to the `django/deps <https://github.com/django/deps>`_ repo.
This PR should add a DEP to the ``drafts/`` directory, written in the style
described below. The draft must be written in DEP style; if it isn't the pull
request may be rejected until proper formatting rules are followed.
Following the discussion, the proposal should be sent as a GitHub pull request
to the `django/deps <https://github.com/django/deps>`_ repo. This PR should add
a DEP to the ``drafts/`` directory, written in the style described below. The
draft must be written in DEP style; if it isn't, the pull request may be rejected
until proper formatting rules are followed.

At this point, a core dev 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 to ensure that this
review happens quickly. The reviewer will do the following:
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
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
must make technical sense, even if they don't seem likely to be
Expand Down Expand Up @@ -224,10 +220,10 @@ reference implementation, and of course updates to the DEP. It's rare for
a DEP to be judged on the first draft; far more common is several rounds
of feedback and updates.

Updates to a DEP can be submitted as pull requests; once again,
a core developer will merge those pull requests (typically they don't
require much if any review). In cases where the Author has commit access
(fairly common), the Author should just update the draft DEP directly.
Updates to a DEP can be submitted as pull requests; once again, someone with
merge access to the DEP repo will merge those pull requests (typically they
don't require much if any review). In cases where the Author has commit access
the Author should just update the draft DEP directly.

Feature DEPs generally consist of two parts, a design document and a
reference implementation. It is generally recommended that at least a
Expand All @@ -246,34 +242,34 @@ DEP authors should use their discretion here.
Review & Resolution
-------------------

Once the author has completed a DEP, the shepherd will ask the Technical Board
for review and pronouncement. The final authority for deciding on a DEP rests
with the Technical Board. They may choose to rule on a DEP as a team, or they
may designate one or more board members to review and decide.
Once the author has completed a DEP, the Author or Shepherd will ask the
Steering Council for review and pronouncement. The final authority for deciding
on a DEP rests with the Steering Council. They may choose to rule on a DEP as a
team, or they may designate one or more members to review and decide.

Having the shepherd (i.e. a core dev) rather than the author ask helps ensure
that the DEP meets the basic technical bar before it's called for review. It
also provides a fairly strong fitness test before the board is asked to rule on
it, making board rulings fairly easy. If the core developer shepherd is happy,
the board will likely be as well.
Having the Shepherd (i.e. an experienced contributor) rather than the Author ask
helps ensure that the DEP meets the basic technical bar before it's called for
review. It also provides a fairly strong fitness test before the Steering
Council is asked to rule on it, making rulings fairly easy. If the Shepherd is
happy, the Steering Council will likely be as well.

For a DEP to be accepted it must meet certain minimum criteria. It must be a
clear and complete description of the proposed enhancement. The enhancement must
represent a net improvement. The proposed implementation, if applicable, must be
solid and must not complicate Django unduly. Finally, a proposed enhancement
must "fit" with Django's general philosophy and architecture. This last category
is the most imprecise and takes the most judgment, so if the Board rejects a
DEP for lack of "fit" they should provide a clear explanation for why.
is the most imprecise and takes the most judgment, so if the Steering Council
rejects a DEP for lack of "fit" they should provide a clear explanation for why.

At this point, the DEP will be considered "Accepted" and moved to the
``accepted`` directory in the DEPs repo.

A DEP can also be "Withdrawn". The DEP author or a core developer can assign
the DEP this status when the author is no longer interested in the DEP, or if no
progress is being made on the DEP. Once a DEP is withdrawn, it's moved
to the ``withdrawn`` directory for reference. Later, another author may
resurrect the DEP by opening a pull request, updating (at least) the author,
and moving it back to ``draft``.
A DEP can also be "Withdrawn". The DEP Author or maintainer of the DEPs repo
can assign the DEP this status when the Author is no longer interested in the
DEP, or if no progress is being made on the DEP. Once a DEP is withdrawn, it's
moved to the ``withdrawn`` directory for reference. Later, another author may
resurrect the DEP by opening a pull request, updating (at least) the author, and
moving it back to ``draft``.

Finally, a DEP can also be "Rejected". Perhaps after all is said and done it
was not a good idea. It is still important to have a record of this
Expand All @@ -290,7 +286,7 @@ Implementation
Finally, once a DEP has been accepted, the implementation must be completed. In
many cases some (or all) implementation will actually happen during the DEP
process: Feature DEPs will often have fairly complete implementations before
being reviewed by the board. When the implementation is complete and
being reviewed by the Steering Council. When the implementation is complete and
incorporated into the main source code repository, the status will be changed to
"Final" and the DEP moved to the ``final`` directory.

Expand Down Expand Up @@ -380,7 +376,7 @@ The headers must contain the following fields:
``Implementation-Team``
The person/people who have committed to implementing this DEP
``Shepherd``
The core developer "on point" for the DEP
A more experienced developer to help mentor and guide the DEP forward
``Requires``
If this DEP depends on another DEP being implemented first,
this should be a link to the required DEP.
Expand Down Expand Up @@ -417,7 +413,7 @@ finished DEPs you can submit corrections as GitHub issues or pull requests
against the DEP repository.

When in doubt about where to send your changes, please check first with the DEP
author and/or a core developer.
author and/or the Steering Council.

DEP authors with git push privileges for the DEP repository can update the DEPs
themselves.
Expand Down Expand Up @@ -445,6 +441,15 @@ email within a few weeks, contact django-developers.
Differences between DEPs and PEPs
=================================

.. note::

This section is historical, describing the differences between the DEP and
PEP processes when this was originally written in 2014. Since then, the PEP
process has changed -- in particular, there's now a Python Steering Council,
and a mechanism for delegating authority for each specific PEP. This section
hasn't been updated to reflect those changes, nor the changes to the DEP
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 <https://www.python.org/dev/peps/pep-0001/>`_).
Expand All @@ -469,7 +474,7 @@ Relative to the PEP process, we made the following changes in DEPs:
- DEPs are "edited" (e.g. pull request approved) by any core developer,
rather than an explicit "editor" role like the PEP editors.

- DEPs are pronounced upon by the Technical Board, rather than a BDFL (because
- DEPs are pronounced upon by the Steering Council, rather than a BDFL (because
Django no longer has BDFLs).

- DEPs explicitly require identifying a few roles (Author, Implementation Team,
Expand All @@ -490,6 +495,18 @@ Relative to the PEP process, we made the following changes in DEPs:

- DEPs may only be reStructuredText (there is no plain text option).

Revision History
================

2023-10-23
Updates to reflect changes in governance since this document was originally
written, including changes from "Technical Board" to "Steering Council",
the removal of the no-longer-existant "Core Developer" concept, and updates
to reflect the Merger role.

2014-04-14
Initial version

Copyright
=========

Expand Down
13 changes: 11 additions & 2 deletions accepted/0010-new-governance.rst → final/0010-new-governance.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,15 +6,24 @@ DEP 0010: New governance for the Django project
:Author: James Bennett
:Implementation Team: James Bennett, others to be determined
:Shepherd: Aymeric Augustin
:Status: Accepted
:Status: Final
:Type: Process
:Created: 2018-09-22
:Last-Modified: 2021-06-01
:Last-Modified: 2023-10-21

.. contents:: Table of Contents
:depth: 3
:local:

.. note::

This is a historical document, describing the changes from Django's BDFL
structure to its Technical Board leadership, later updated by `DEP 12`_ to
the Steering Council. See Django's documentation for `operational documentation
of the Steering Council and how it works`_.

.. _DEP 12: https://github.com/django/deps/blob/main/final/0012-steering-council.rst
.. _operational documentation of the Steering Council and how it works: https://docs.djangoproject.com/en/dev/internals/organization/#steering-council

Abstract
========
Expand Down
13 changes: 11 additions & 2 deletions accepted/0012-steering-council.rst → final/0012-steering-council.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,15 +6,24 @@ DEP 0012: The Steering Council
:Author: Andrew Godwin
:Implementation Team: Andrew Godwin
:Shepherd: Carlton Gibson
:Status: Accepted
:Status: Final
:Type: Process
:Created: 2022-10-26
:Last-Modified: 2022-12-03
:Last-Modified: 2023-10-21

.. contents:: Table of Contents
:depth: 3
:local:

.. note::

This is a historical document, describing the changes from the Technical
Board stucture described in `DEP 10`_ to a Steering Council. See Django's
documentation for `operational documentation of the Steering Council and how
it works`_.

.. _DEP 10: https://github.com/django/deps/blob/main/final/0010-new-governance.rst
.. _operational documentation of the Steering Council and how it works: https://docs.djangoproject.com/en/dev/internals/organization/#steering-council

Abstract
========
Expand Down