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.
