New DIP Rules

[Mike Parker]

In response to the controversy over the acceptance of DIP 1028 
(Make @safe the Default), which ultimately resulted in the 
reversal of the decision, I received proposals to change how DIP 
assessments are carried out. This is beyond the scope of my role 
as DIP manager, so I put it on the agenda of our most recent 
quarterly D Language Foundation meeting, where we discussed it 
and reached a decision.

The crux of the proposals was that the language maintainers, 
Walter and Atila, should not be in a position to evaluate their 
own DIPs. The suggestions were to either add a third maintainer 
to the team or to have a person on call to evaluate any DIPs by 
Walter and Atila.

On the surface, these are reasonable suggestions. There are many 
scenarios in modern society where we expect individuals to recuse 
themselves from performing their normal duties when those duties 
intersect with their personal interests. However, language design 
is generally not one of them.

Adding a third maintainer, whether on a flexible or permanent 
basis, requires finding someone with the proper skillset and 
scope of knowledge to fill the role, which is no easy task. But 
even were such a person found, we can find no rationale to 
prevent any language maintainer from evaluating their own 
proposals. By definition, as language maintainers, Walter and 
Atila are the final arbiters of which features do and do not make 
it into D. Whether one of them or someone else is the source of a 
feature proposal is irrelevant. They are either maintainers or 
they aren't. To take either of them out of the decision making 
process would be to say they aren't.

On the other hand, it's not often that the community comes 
together in fierce agreement on any D issue. When that happens, 
as it did in the case of DIP 1028, it can't be ignored. That's 
why the decision to accept was reversed. It's also why we've 
decided on implementing a change that we hope will be an 
improvement.

That we have two maintainers means nothing is accepted unless 
they both agree. Very few DIPs reach Formal Assessment without 
flaws and with both maintainers in agreement on acceptance. In 
those cases, whether the end result is acceptance or rejection, 
the decision isn't reached without debate and without one of them 
finally convincing the other (often over the phone). The decision 
making is not a rubberstamp. It's actually sometimes adversarial. 
When it comes to proposals by the maintainers, introducing such 
adversity earlier in the process may be a good thing.

Henceforth, when a language maintainer wants to write a DIP, he 
will instead recruit someone to write it for him. This third 
party will not just be the DIP author, he or she will be the 
champion of the DIP. The idea is that the maintainer provides the 
author with the broad outline (bullet points, notes, whatever 
works) and any input necessary to get the initial draft off the 
ground, but the author is ultimately responsible for the content, 
including modifying the additional draft as they see fit, and 
deciding which bits of community feedback to incorporate and 
which to ignore throughout the DIP process. (All such DIPs will 
include a note that the idea came from a maintainer.)

With this change, Walter and Atila will still be the ones who 
decide what does and does not get into the language, but any 
feature ideas they have will evolve, for better or worse, without 
their input. Those DIPs from Walter currently moving through the 
DIP queue will remain in their current form. Those still in Draft 
Review in PR queue will be subject to the new rule and will be 
revised by a different author.

Two other major issues were raised in the wake of 1028:

* /No rationale was provided for acceptance./ This is my fault. I 
have always requested a rationale for rejection, but not for 
acceptance. Often, the maintainers have had specific issues with 
the DIPs they accepted. In those cases, they have always provided 
comment. Only one DIP had previously been accepted without any 
comment at all (1024). I did not ask for a rationale for either 
1024 or 1028. Henceforth, we will always provide a rationale for 
both acceptance and rejection.

* /Walter didn't listen to the feedback./ There is a difference 
between listening to feedback and disagreeing with feedback. I 
ask every DIP author to respond to each unique point of feedback 
in the Feedback Thread, but no DIP author is required to modify 
their DIP in response to feedback. All criticisms, positive and 
negative, will be there in both threads for the language 
maintainers to take into account as part of the assessment. We 
hope the change I outlined above will alleviate this by putting 
the decision to modify maintainer's DIP idea into the hands of an 
author who is not a language maintainer.