"Getting to a draft DEP" process should be simplified

[mjtamlyn]

I would like to see the barrier to merging a draft DEP be lowered. In particular:

• A reference implementation should not be expected, but we could mention for example some public API designs would be advisable. I understand this increases the likelihood that the DEP may not be completely resolvable with the patterns discussed, but in practice they will change anyway. A decent discussion of the problem and the proposed architecture of the solution should be sufficient to get a general consensus from the technical board as to whether the idea is worth pursuing.
• A shepherd should be recommended but the implementation team should not be necessary. This allows us to potentially source an implementation team using DSF money or direct sponsorship of a DEP, but that it has already reached a general consensus of "we want to see this area explored and believe in the rough plan".
• We should require all DEPs to be peer reviewed to reach draft status, not give the core team a bye.
• We should ensure that there is a clean process for evolving a draft DEP after it has been merged as people want to work on it.

Comments welcome! I can probably look at drafting some changes to DEP0001. In particular the sections around the DEP submission workflow and submitting the draft need some work.

[mjtamlyn]

A separate consideration which would likely need a new process DEP is the idea of maintaining a list of ideas the team would like to see explored, but haven't done the research etc necessary to consider writing a proper DEP. Examples include many ORM features such as:

• Database constraints
• Server side cursors
• Database level defaults
• Database schema
• Expression based indexes for contrib.postgres
• Exposing and formalising the rel API
• Pushing cascade behaviour to the database schema

Other possible things:

• Pluggable translation backends/depending on an external package for translation support
• Add monitoring and performance hooks within Django
• Streamline the process of testing standalone apps
• Implement a system for setup/teardown hooks for the testing environment
• Formalise a process for alternatives to ModelAdmin classes which can be hooked into the AdminSite

These are all "hard" problems, some of which may not really need the full DEP process to complete, but the team can quickly agree that they meet two criteria:

• This would take longer to do than could be reasonably achieved at a normal Django sprint
• We would like to see progress in this area

This should encourage people to consider writing DEPs, doing the research and design. This is likely workable on in a sprint, even if the end solution would be better as funded work. In some sense, this is a repository of "accepted tickets" which are in some way "hard".

[jacobian]

Couple of quick notes from meeting with @mjtamlyn in person:

• We don't have a process for updating DEP 1 (LOL) so this change should include the process by which this change will be processed.
• Merging from a PR to master should indicate that at least one core dev sorta thinks this is a good enough idea (or a good enough problem) to consider, not necessarily require a fully-fleshed DEP.
• The DEP author should get commit to django/deps to keep things updated.
• Take away the core dev backdoor.
• For ideas, how about a tag on tickets: should-be-a-dep

I can take on writing this into a PR if nobody beats me to it.

[jacobian]

Another improvement: for feature DEPs, add an "Implementation" section to the end of Final DEPs that points to the commits/PRs/etc that were merged to implement the DEP.

[thibaudcolas]

@jacobian when you have the chance, could you write a quick update here reflecting on how much of this thread is still relevant – perhaps elements of Updates to DEPs 1, 10, and 12 to reflect current governance that still need taking forward?

I’ve opened #85 for a specific "DEP pain point" I’ve noticed.