The DIP Process

[Mike Parker]

Given the nature of the feedback on the DIP process lately, I 
thought it prudent to explain how I, as DIP manager, view things.

The core of the process looks like this:

Step 1: The author creates the DIP
Step 2: The author submits the DIP to the DIP manager
Step 3: The language maintainers review the DIP
Step 4: The DIP manager informs the author of the verdict

That's what the heart of the process is, an interaction between 
the DIP author and Walter & Andrei, facilitated by me.

Every language has a process for improvement proposals. At their 
core, they are all the same, even if they have different ways for 
getting there. Take a look at the documenetation for Python 
Enhancement Proposals:

https://www.python.org/dev/peps/pep-0001/#start-with-an-idea-for-python

The core of the process is the same. What they add to it is this:

"The PEP champion (a.k.a. Author) should first attempt to 
ascertain whether the idea is PEP-able. Posting to the 
comp.lang.python newsgroup (a.k.a. python-list at python.org mailing 
list) or the python-ideas at python.org mailing list is the best way 
to go about this.

Vetting an idea publicly before going as far as writing a PEP is 
meant to save the potential author time. Many ideas have been 
brought forward for changing Python that have been rejected for 
various reasons. Asking the Python community first if an idea is 
original helps prevent too much time being spent on something 
that is guaranteed to be rejected based on prior discussions 
(searching the internet does not always do the trick). It also 
helps to make sure the idea is applicable to the entire community 
and not just the author. Just because an idea sounds good to the 
author does not mean it will work for most people in most areas 
where Python is used."

TL;DR, they require the author to ask the community if the 
concept of the proposal is something that should be put through 
their process.

Look around at other languages and you will find a number of 
variations on the core process, all involving some form of 
community feedback.

In our process, we take the community feedback as a review of the 
written proposal. We have implemented multiple feedback rounds to 
get this done. The purpose here is *not* to allow the community 
to preliminarily approve a proposal, or to vote on it. The 
decision to accept or reject rests squarely with Walter and 
Andrei. The purpose of the Community Reviews is to reduce the 
burden on the author of crafting a proposal that will meet Walter 
and Andrei's standards.

The people who visit participate in DIP reviews do not represent 
a small fraction of the D user base, but their backgrounds are 
diverse enough that there are strong odds of receiving valuable 
feedback.

The Community Review rounds help the DIP author sound out the 
proposal, or kick the tires if you will. Reviewers are free to 
leave their opinions of the proposed feature, the details of the 
proposal, to identify structural flaws or other opportunities for 
enhancement, etc. If the author makes significant revisions, I 
will almost certainly call for another round of Community Review 
based on how signficant I judge the revisions to be.

In the Final Review round, the emphasis is on helping the DIP 
author identify structural issues. Anything overlooked in 
previous rounds or introduced as a result of any revisions along 
the way. We aren't interested in personal opinions at this point.

The keywords in both the previous paragraphs are "help/helping 
the DIP author".

In the end, it is entirely up to the DIP author to accept or 
reject any or all of the feedback provided in any community 
review round. It is not up to me, as DIP manager, to block a DIP 
from progressing if the author chooses to make no revisions. I 
always ask the DIP manager to respond to feedback in the review 
thread as far as explaining why a set of related criticisms will 
result in a revision or none at all, but I do not require the 
author to actually make revisions. I am not the final arbiter of 
what does or does not constitute a solid proposal. So I see any 
complaints that a DIP "should not have progressed out of 
Draft/Community review" as missing the point.

My experience with the process has both evolved my understanding 
of it and helped me identify flaws. Early on, I did not see the 
process quite as I describe it above. I mismanaged a couple of 
DIPs (specifically 1006 and 1011) and that led to an overhaul of 
both my understanding and the process document. I looked at how 
other languages handle their processes and revised Dicebot's 
initial work with a goal of preventing my initial mistakes and 
and clarifying the purpose of each review round.

I'm still open to revising the process. We want a process that 
helps us produce the best DIPs we can so that Andrei and Walter 
have all the information they need to render their verdict. But 
any revisions to the process *must not* lose sight of these two 
basic facts:

* the burden of producing the proposal lies with the author
* the burden of reviewing the proposal lies with Walter and Andrei

Any process in between should be aimed at helping to reduce the 
burden for either party. I'm already going to implement two 
changes in my part of the process based on lessons I've learned 
through recent reviews:

* I will no longer simply *ask* DIP authors to respond to 
feedback in the review threads, I will *require* it. Note that 
this does not mean I will require the author to make any 
revisions, nor does it mean that I will pull the DIP if the 
opinions of the proposal are overwhelmingly negative. Again, 
that's not my role. It means the author must leave responses to 
feedback in the thread agreeing or disagreeing with each unique 
criticism and the decision to proceed lies entirely with the 
author. That includes Walter and Andrei if either of them are the 
sole author of a DIP. Previously, I didn't even ask them to 
respond as they are the ones rendering the final verdict anyway, 
but I now recognize it's important that all DIP authors express 
their opinions of the feedback they receive.

* I will do my best to provide more detailed summaries of the 
Formal Assessment. Walter and Andrei tend to deliver their 
opinions of a proposal informally, either tersely or over a long 
email discussion. I do my best to summarize their thoughts at the 
bottom of the DIP. After the response to the review of DIP 1016, 
I discussed with Walter and Andrei how I can provide more 
detailed summaries and we will work to make that happen going 
forward.

Again, we're all open to suggestions on how to improve the 
process, so feel free to leave feedback here or email me directly.

Thanks!