The DIP Process

[Mike Parker via Digitalmars-d]

Now that I'm managing the DIPs, here's how I intend to move 
forward with the process (mostly what Dicebot was already doing, 
but I want to outline it somewhere for reference).

* When a DIP is submitted as a PR, it will go through a pre-merge 
review on github to get it ready for public review here in the 
forums. The focus will be on copy editing and ensuring that 
obvious flaws are repaired (certain feature interactions aren't 
covered, corner cases are ignored, not enough detail is given, 
etc). This is not intended to be the place to debate the merits 
of the DIP.

* When I think it's ready to move forward and the author is ready 
to begin, I'll assign a DIP number and merge it. At that point, 
I'll announce it here in the forums for the first round of 
preliminary review. More review rounds will be announced as 
necessary. I'll tag each version of the DIP with a review number 
so that it's easy to reference and compare them from the forum 
threads.

* When a round of preliminary reviews results in minor changes, 
or none at all, then I'll schedule a formal review where the DIP 
will be accepted or rejected.

* If a DIP is rejected, I'll write up the rationale. If the 
author can address the concerns that led to rejection, then he or 
she can rewrite the DIP and begin the process again.

I intend to begin the first preliminary review round of DIP 1006 
some time soon (later today or tomorrow). The formal review of 
DIP 1003 has been delayed for a bit at the author's request, but 
is still very much on the table. I'll get to that as soon as the 
author is ready.