On Apr 14, 2014, at 1:51 PM, Adrian Holovaty <adr...@holovaty.com> wrote:
> 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 > > -- > 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-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
