The New DIP Process

[Mike Parker]

After discussion in a recent meeting, we're ready now to start 
accepting DIPs for review. And that means it's time to announce 
the new process.

The main goal of the new process is to reduce the amount of 
"process". The rules of the prior system were intended to create 
a moderately high barrier of entry in order to discourage 
frivolous proposals. In practice, they created an extremely high 
barrier of entry that also discouraged serious proposals, 
frustrated several DIP authors who went through the process, 
created too much of a time sink for everyone involved, and did 
not allow for early indication of the chances that an author's 
time and effort would result in a favorable outcome.

The new system simplifies the process by putting most of the 
control in the hands of DIP authors. Some key points:

* Feedback begins with the initial DIP idea.
* The predefined review rounds are gone.
* Multiple DIPs can be under review at the same time.
* The DIP author decides when a draft is ready to submit for 
assessment.

Most of the process takes place in two new forums: DIP Ideas and 
DIP Development (dip.idea and dip.development on the NNTP 
server). The purpose of the Ideas forum is to determine if 
developing the DIP is feasible. The purpose of the Development 
forum is to strengthen proposals in development.

The process works as follows.

* A potential DIP author (or someone looking for an author) posts 
a description of the idea in the DIP Ideas forum for community 
discussion and feedback. Periodically, I'll make sure Walter and 
Atila are aware of the new idea posts so they can provide their 
initial thoughts. This should give a potential author a good 
sense of the DIPs chances, e.g., great idea, go for it; maybe, 
give it a go if you'd like; no way, no how. Based on this 
feedback, the potential author can decide whether to proceed with 
development.
* When an author does proceed, then once the initial draft is 
ready, they should make a new post in the DIP Development forum 
with a link to the draft for community feedback. They should 
address feedback as necessary by revising the DIP or explaining 
why they disagree. The author should expect to allow two or three 
weeks for feedback just to give stakeholders enough time to 
process it and formulate an opinion, particularly if they want 
feedback from Walter and Atila at this stage.
* After at least two or three weeks of feedback, the author can 
contact me when the revised draft is ready. If the extent of 
revision is significant, I'll ask the author to make a new DIP 
Development thread for feedback on the new draft. Otherwise, I'll 
ask the author to submit a PR to the DIP repository.
* When the PR is submitted, I'll merge it, assign a DIP number, 
edit as necessary, and email Walter and Atila for assessment. 
They'll have two weeks to review it (though depending on 
circumstances, we can extend that as necessary). As before, 
they'll accept it, reject it, or ask for modifications.

I want to emphasize that though any DIP that makes it to 
assessment in this new process should theoretically have a strong 
chance of acceptance, there can never be a guarantee. For 
example, Walter or Atila or someone else may uncover a major 
overlooked flaw before the decision is made. Or an author may 
have proceeded with a DIP that Walter and/or Atila expressed 
skepticism toward at some point in the Ideas or Development forum 
and the DIP failed to convince.

The key point is that we want the author to know before the first 
draft whether the DIP has a strong, weak, or near-zero chance, 
and during development whether they're generally going in the 
right direction, but no one can offer a 100% guarantee.

All potential DIP authors should read the DIP Authoring Process 
doc here:

https://github.com/dlang/DIPs/blob/master/docs/process-authoring.md

Once the development is underway, the author should also read the 
Authoring Guidelines:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-authors.md

I should note that while we still want the language of the final 
draft to be semi-formal to formal, it's not something the author 
needs to be overly concerned about during development. Once the 
PR is submitted, I'll clean up the language as much as necessary 
and check with the author to ensure I've not changed the meaning 
of anything. The guidelines describe some simple things the 
author can keep in mind during development, but getting the 
details right is the primary concern at that stage.

Finally, I want to make it clear that the new forums will be 
heavily and strictly moderated. We want focused, on-topic 
discussion there. On the web interface, each forum will have a 
banner at the top of the page that includes a link to the forum 
guidelines:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-forums.md

With the publication of this announcement, Vladimir will deploy 
the new forums when he's ready to do so. At that point, the DIP 
Ideas forum will be open for business.

It is generally a requirement that a DIP idea be submitted to the 
Ideas forum first. I will delete any new thread in the 
Development forum for a draft DIP that was not first discussed in 
the Ideas forum. However, I will make exceptions if an author 
contacts me first with an explanation of why they want to skip 
the Ideas stage and makes it clear they understand what they're 
giving up.

We'll give this new process some time to see how flows. We can 
tweak it as we need to over time to work out any kinks.