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@python.org mailing list) or the python-ideas@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!

Something we could do differently is to create a list of actionable items that should occur before the next review.

Each item should be kept pretty loose and open. So that the item doesn't dictate what the DIP author should do with it.

As a wiki article anybody could add items. For the purpose of being heard.

It would effectively be a to do list. Which might eliminate quite a bit of concern from the community at large over issues being ignored (potentially unknowingly).

I am concerned about how much work it could add to people's roles. But perhaps we can make it more of a community lead thing? To get others involved in the DIP process more.

On Tuesday, 26 February 2019 at 11:28:56 UTC, Mike Parker wrote:
> I'm still open to revising the process.

Good I'm sure that people will have plenty of things to say at Dconf/the foundation meeting at dconf

> * I will no longer simply *ask* DIP authors to respond to feedback in the review threads, I will *require* it.

Good, that strikes one item off the dconf foundation meeting agenda.

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

Good.

> * 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.

Thanks!

“The people who visit participate in DIP reviews do not represent a small fraction of the D user base” => The people who participate in DIP reviews represent a small fraction of the D user base

“I always ask the DIP manager to respond to feedback” => I always ask the DIP author to respond to feedback

On Tuesday, 26 February 2019 at 11:28:56 UTC, Mike Parker wrote:

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

One thing I should add regarding this bit of the procedure:

"the DIP Manager or the Language Maintainers may allow for exceptions which waive requirements or responsibilities at their discretion"

I don't see anything inherently unfair in this. And I think allowing such flexibility is necessary for a healthy process. That said, it's not an option intended to be used frequently.

DIP 1010 (static foreach) was fast-tracked through each stage of the process, but before 1018, no part of the process was skipped for any DIP.

In this case, Walter and Andrei were both heavily involved in the drafting of the DIP and in the review of the implementation:

https://github.com/dlang/dmd/pull/8688

The DIP went through extensive Draft review:

https://github.com/dlang/DIPs/pull/129

And as far as I can see there were no major structural deficiencies identified in the community review:

https://forum.dlang.org/post/eoqddfqbjtgfydajozsn@forum.dlang.org

Given that the purpose of the intermediate review rounds is intended to improve the odds the DIP will meet the standards of Walter and Andrei, that both were involved in the development of the DIP and its implementation, and that they see it as an important feature that they'd like to ship ASAP, the decision to skip the Final Review shouldn't be controversial.

All DIPs are subject to that possibility of any part of the process being skipped or abbreviated, so there's nothing inherently unfair that it happened here. Especially considering that Andre and Walter felt the DIP was already at a stage where they could accept it.

So I won't be removing the quoted line from the procedure document. What I can do is say that Walter and Andrei have had enough respect for the process that they have never demanded/ordered/required me to fast-track or skip a review round. In this case, they asked me if it was possible to do. Given the circumstances I've described, I saw no harm in it, especially given their timeline. If I had recommended we not do it and provided a rational reason, I'm confident we would have had a final review round.

Again, this is something that should be rare, but when the circumstances warrant it, it shouldn't be prohibited.

On Tuesday, 26 February 2019 at 11:28:56 UTC, Mike Parker wrote:
> 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!

I think most points of the DIP process make sense, but it has one very large problem.  Feedback from language maintainers (Walter and Andrei) is not done until the end of the process. You're asking someone to go through a process that can take a year before the people who have the power to accept or reject the proposal look at it or leave any feedback.  This is extremely wasteful of the author's time, the reviewer's time and causes extreme pressure for everyone involved.  A years worth of waiting, debate and revision that are now wasted and could have easily been avoided if language maintainers left their feedback early on.  Walter and Andrei should be involved in the process throughout, not just render judgement at the end.

In the years I've been here I have found that feedback from anyone other than Walter and Andrei has very little bearing on what Walter and Andrei will think.  The entire community can think an idea is great, but then Walter or Andrei completely reject it.  And the opposite is true as well, I've seen W&A champion an idea that the community generally rejects. Designing a process to ask many people to create and perfect a proposal for a year catered to 2 specific people without any feedback from them is mind-boggling to me.

Based on my observations, my guess is that the DIP process was designed to alleviate the amount of work needed from Walter and Andrei, but look what it's produced.

To Walter and Andrei:

The amount of decision-making power you hold needs to be matched by the amount of involvement you have in the process.  There's no such thing as a free lunch, you can't just punt the work to everyone else for so long and then expect everything to work out great when all that work is completely rejected.  This is a gross misuse of people's time and a good way to foster a hostile community. When you leave early feedback, you're likely to trade a years worth of debate and revision between many people for a few minutes of your time.

Since you asked for suggestions, here's how I would revise the process:

Step 1: Research your proposal, search through the forums/DIP repo/github/Google
Step 2: Create a forum post with your proposal,  Walter or Andrei is required to either accept or reject whether the proposal warrants the effort to formalize it.
Step 3: If formalization is accepted, the author does so

We are now at Step 1 of the current DIP process.  I would then follow the current process as it exists with the modification that Walter and Andrei be involved throughout.  DIPs should be a document that contains the research and results of a proposal that includes feedback from the entire community, including Walter and Andrei. Seeing it as a document created by the community to be presented to Walter and Andrei with no feedback from them results in the problems I discussed above.

On 2/26/19 12:46 PM, Jonathan Marler wrote:
> I think most points of the DIP process make sense, but it has one very large problem.  Feedback from language maintainers (Walter and Andrei) is not done until the end of the process. You're asking someone to go through a process that can take a year before the people who have the power to accept or reject the proposal look at it or leave any feedback.  This is extremely wasteful of the author's time, the reviewer's time and causes extreme pressure for everyone involved.

This is the case for all relevant submission processes I know of - conferences, journals, programming languages. A process of shepherding/assistance is not unheard of, but exceptionally rare. I've only had direct experience with it in HOPL, which itself is an exceptional (and an exceptionally rare) conference. I recall the POPL community had something similar. Until we have an army of competent reviewers, we can't consider this.

The initial community process is an important step that ensures good initial quality of submissions. This is the case for many programming language communities. We could definitely do better there, and the DIP guidelines could emphasize the importance and the structure of this stage.

The process of revisions is intended to provide a path for proposals to evolve from initial submission to approval. Improvements of the mechanics and logistics of the revisions would be welcome.

I'm not sure how we can improve this from the top, but I'd love to foster more of an esprit de corps on the submitters' side. A DIP can be very impactful, but it requires hard work with no guaranteed outcome. All of the time and energy spent on contesting the DIP 1016 decision should have been at best directed toward improving the proposal. The attitude that DIP rejection is not an acceptable outcome and consequently needs to be negotiated in forums, that - that must be replaced with an attitude that a setback offers a solid ground for a better proposal.

On Tuesday, 26 February 2019 at 18:22:09 UTC, Andrei Alexandrescu wrote:
> This is the case for all relevant submission processes I know of - conferences, journals, programming languages. A process of shepherding/assistance is not unheard of, but exceptionally rare.

In my fields (medicine and genomics), it is extremely common that high impact journals offer a pre-review/estimate of suitability to authors prior to submission.

For example, one does not typically submit to NEJM or Nature without discussing with an editor first.

> Until we have an army of competent reviewers, we can't consider this.

Extending this analogy, these reviews are typically done by associate editor.

On 2/26/19 2:45 PM, James Blachly wrote:
> On Tuesday, 26 February 2019 at 18:22:09 UTC, Andrei Alexandrescu wrote:
>> This is the case for all relevant submission processes I know of - conferences, journals, programming languages. A process of shepherding/assistance is not unheard of, but exceptionally rare.
> 
> In my fields (medicine and genomics), it is extremely common that high impact journals offer a pre-review/estimate of suitability to authors prior to submission.
> 
> For example, one does not typically submit to NEJM or Nature without discussing with an editor first.

Yah, I know of the process from my wife. There are quite a few differences between the fields. One is that in medicine a case presentation is in and by itself publishable material, and all the editor needs to do is assess the rarity and relevance of the material.

On Tuesday, 26 February 2019 at 19:49:52 UTC, Andrei Alexandrescu wrote:
> On 2/26/19 2:45 PM, James Blachly wrote:
>> On Tuesday, 26 February 2019 at 18:22:09 UTC, Andrei Alexandrescu wrote:
>>> This is the case for all relevant submission processes I know of - conferences, journals, programming languages. A process of shepherding/assistance is not unheard of, but exceptionally rare.
>> 
>> In my fields (medicine and genomics), it is extremely common that high impact journals offer a pre-review/estimate of suitability to authors prior to submission.
>> 
>> For example, one does not typically submit to NEJM or Nature without discussing with an editor first.
>
> Yah, I know of the process from my wife. There are quite a few differences between the fields. One is that in medicine a case presentation is in and by itself publishable material, and all the editor needs to do is assess the rarity and relevance of the material.

I am not at all describing “case reports,” and your thoughtless dismissal of earnest feedback/suggestion really underlines the criticisms others have leveled against you specifically, and perhaps the process generally.