DEPs: Django Enhancement Proposals

[Adrian Holovaty]

Yesterday at PyCon, about a dozen people from the Django core team had a lunch meeting to talk about various ideas we should implement. One idea was to start doing a Django equivalent of Python's PEPs, which would serve as a formal way to document large new features/changes in Django.

The goal would be to have "design documents" in a single place, rather than relying on parsing dozens of micro-decisions made in mailing list threads, Trac tickets, etc. And, importantly, we would only use this for medium-to-large features, so as not to introduce too much inertia.

We also talked about doing it immediately, just using pull requests on GitHub, to get some momentum going. No need to build any fancy systems, etc.

Today at the sprints, I went ahead and started drafting how this would work. Here is a new GitHub repo for DEPs (Django Enhancement Proposals):

https://github.com/django/deps

And here is DEP 1, a draft attempt to document how the process works:

https://github.com/django/deps/blob/master/deps/0001.txt

Note the "TODO: Next steps" at the bottom. I'm not exactly sure what the best process would be once a DEP is formally created. Can somebody with more familiarity with Python's PEP process provide some suggestions?

Adrian

[Donald Stufft]

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABm4ZCT1S1_ybYVe_0BGKvGAsQx3VDsD0KWZtBfR9fD6nOU7vQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Normally in the PEP process once you have a PEP you go through rounds of discussion on the mailing list. The PEP is responsible for documenting the solution the PEP suggests as well as any dissenting opinions. Once the PEP author believes there is no more discussion to be had they ask for pronouncement. This is where the BDFL or BDFL-Delegate (Guido doesn’t care about everything, so he can appoint someone to decide in his place) reads over the PEP and accepts it or rejects it. If it is accepted the status changes from Draft to Accepted and it stays that way until it gets implemented and committed. Then it changes from accepted to final and the PEP process is done.

One thing i’m not sure of, how is DEPs going to work without a BDFL? Generally they are used to get feedback and provide a clear concise argument to the BDFL in cases where there is not a good way to get a rough consensus amongst python-dev.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

[Alex Gaynor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

For us, I think the value of a DEP is in putting the conclusion of a discussion in one place, rather than forcing everyone to read the entire thread to know how it went. To that end, I don't think anything needs to change about how we accept DEPs.

Alex

-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v0.8.0
Comment: Email security by Mailvelope - http://www.mailvelope.com

wsFcBAEBCAAQBQJTTCE4CRASX1xn3+lAhAAAjBoP/3c3P30xlHh1Z3BDvrS5
LHuzyQR/Lp3rws+83Cnh0Xi154xcWkd1np5PvbXXya747NSLEIayryDHiYlw
hhdeGFA77TJxG/q6LRjbDAgFq7YsLERtIYLkWvWmiFTuKZDHELj4oGGs9SQS
LjGm+r0M32LQPpV8yui3rBP1AbBl1/KddztyzzQqNdYEhvahxiScKFaOE+vH
bSbsCONZv1TCFDcpy4y70Mlz9CzLsNpanO9Mjq8066RG0MB9HKr6w5Yqi6OS
ItYQrmiiLcAwARi3BlRqBsmBcWGJ55pOfNXq3GPwScWiQ1ySap2W4+rbml1C
7Fxfp1KIE4DfLmfiQuPgCWZhrpr1hRBdVRXXHvWkYnPmxlXWUFxFwgrtSeZh
fC5t9F3jmSG02L2JnwHjhynSOTyh9d+bCbRE/hdij+DP0v9iZBGNvzQq04Dy
X72xJ99R7mRKHrHjvPa0IMuRqpXia/fPn1+2t2Ujf32nXDc+V3l+BTWm9W+D
b1LFjpfJJwXoho4VK5bPu+NDibWR62HZ64ee3Hq2/g+H7o8WGNPk4YOFwCmS
eLnrM44Zg+nwtzhstiW15nS2znIMrce6Xmllv2lDw1VBawNEdTZ9H5utKu04
Iv3JGLqLP/2g4wQC87ITWvkKwOCNhKROMuizmilqwclW+gsiOQ7cgYj5AOp5
t1gz
=YJkP
-----END PGP SIGNATURE-----

--

"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

GPG Key fingerprint: 125F 5C67 DFE9 4084

[Aymeric Augustin]

On 14 avr. 2014, at 19:51, Adrian Holovaty <adr...@holovaty.com> wrote:

> One idea was to start doing a Django equivalent of Python's PEPs, which would serve as a formal way to document large new features/changes in Django.

Would it be interesting to retro-spec the major features added in the past?

--
Aymeric.

[Michael Manfre]

I think there would be value in adding DEPs for the major features that will ship with 1.7.

Regards,

Michael Manfre

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/58B4EA9B-C450-476D-A9E9-8008718FF912%40polytechnique.org.

[Andrew Farrell]

Who is responsible then for deciding what the conclusion of the discussion was? If there is no such person, how does the process handle the case when people talk past each other and don't actually come to a conclusion?

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAGdCwBv7qvwv8Ksdajz1UUWgYcXEt%3DPLHfZCRjGW0YjT_TW51Q%40mail.gmail.com.

[Alex Gaynor]

The same way we do now?

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2By5TLa1o9PO4yNAt_7EELaU4H9MoXH-3DuVObKKW%3DjYopizyA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[Albert O'Connor]

+1

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFRnB2VVbvarWOWa4BGKqNFn_EFz%2BntyTqpg6iLxdBbMrOexEA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Albert O'Connor  

@amjoconn

avocadoproject.ca / albertoconnor.ca

[Russell Keith-Magee]

I agree - there are a bunch of wiki pages that capture a lot of this
information; it wouldn't be a whole lot of effort to turn this into
formal DEP documents.

https://code.djangoproject.com/wiki/ClassBasedViews
https://code.djangoproject.com/wiki/ContribAuthImprovements
https://code.djangoproject.com/wiki/ContribEmailAuth (not yet finalised)
https://code.djangoproject.com/wiki/AppLoadingRefactor (partial;
doesn't include everything Aymeric did, but there are other mailing
list threads)
https://code.djangoproject.com/wiki/FileStorageRefactor
https://code.djangoproject.com/wiki/LoggingProposal (includes link to
mailing list with the full details)
https://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl (proposed,
but never actioned)
https://code.djangoproject.com/wiki/SchemaEvolution (older; probably
not relevant)

Russ %-)

[Mark Lavin]

I'll be the first one to bite and submit one https://github.com/django/deps/pull/1 It needs a lot of work as noted in the PR but I'm happy to be a guinea pig for the process.

Best,

Mark

[Jannis Leidel]

I've just fixed a few formatting issues with the files, including
renaming it to 0001.rst to use Github's automatic rST rendering.

The new URL is:

https://github.com/django/deps/blob/master/deps/0001.rst

What I also wanted to point out is that the copyright statement at the
end of DEP 1 ("This document has been placed in the public domain.")
doesn't have any meaning in many legal jurisdiction, e.g. Germany. We
should instead promote using the Creative Commons Zero (CC0) license
which is "giving creators a way to waive all their copyright and related
rights in their works to the fullest extent allowed by law".

It's what I have been told comes closest to a "public domain" license
that works for global projects like Django. It was specifically created
to handle situations like we have with the DEPs now.

More info: http://creativecommons.org/about/cc0 (including FAQ)

Jannis

[Aymeric Augustin]

On 15 avr. 2014, at 02:41, Russell Keith-Magee <rus...@keith-magee.com> wrote:

> On Tue, Apr 15, 2014 at 2:17 AM, Aymeric Augustin
> <aymeric....@polytechnique.org> wrote:

>> \Would it be interesting to retro-spec the major features added in the past?

>
> I agree - there are a bunch of wiki pages that capture a lot of this
> information; it wouldn't be a whole lot of effort to turn this into
> formal DEP documents.

I’ve also sent a few proposals to this mailing list that could easily be turned
into DEPs.

In order to keep some sense of chronology, I propose to reserve numbers
1XY for features implemented in Django 1.X and to start at 200 for new DEPs.

--
Aymeric.

[Russell Keith-Magee]

… and we should probably reserve DEP8 for our coding style guide :-)

Russ %-)

[Aymeric Augustin]

On 15 avr. 2014, at 08:41, Russell Keith-Magee <rus...@keith-magee.com> wrote:

> … and we should probably reserve DEP8 for our coding style guide :-)

… which brings the question of the relation between DEPs and online docs.

We already have a coding style guide in the docs.

I assume it’s fine if DEP8 is just a link to that page.

--
Aymeric.

[Matt]

And DEP20 for Django philosophy :}

https://docs.djangoproject.com/en/dev/misc/design-philosophies/