| |
 | Posted by Mike Parker |  Permalink Reply |
|
Mike Parker 
| 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.
|
