Permalink
Reply
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.
