The new rule for DIPs by language maintainers was a mistake

[Paul Backus]

Early last year, Mike Parker, the DIP manager, announced [a set 
of new rules][1] for DIPs by language maintainers (i.e., Walter 
and Atila).

Under these new rules, rather that author DIPs directly, language 
maintainers would be required to find a community "champion" for 
each DIP they wished to submit, and allow that champion to author 
the DIP on their behalf. The purpose of this rule was to avoid 
the potential bias introduced by having a DIP's author be the one 
to evaluate it: in general, it is much easier to judge someone 
else's work impartially than one's own.

In light of recent events--in particular, the addition of 
[AliasAssign][2] and [ImportC][3] to the language--I think it is 
safe to say that this new rule has failed to achieve its goal.

The community's role in the DIP process is, and always has been, 
100% advisory. The D project uses a "Benevolent Dictator for 
Life" (BDFL) governance model, in which all decision-making power 
rests in the hands of the language maintainers. Thus, when a 
language maintainer submits a DIP for community review, it is not 
in order to seek the community's *approval* (which is 
unnecessary), but to solicit *constructive feedback*.

Constructive feedback is a good thing. It leads to better DIPs, 
and, ultimately, a better D language. It follows that, when we 
are deciding on rules for the DIP process, we should try to do so 
in a way that encourages as much constructive feedback as 
possible.

Unfortunately, the "champion" requirement does exactly the 
opposite: it actively *discourages* the language maintainers from 
soliciting constructive feedback on their proposals.

To see how, consider the choice faced by a language maintainer 
who wishes to propose a new feature for D:

* **Option 1: use the DIP process.** The benefit of this choice 
is that the language maintainer can get constructive feedback 
from the community. Prior to the new rule, the cost of this 
choice was that the language maintainer had to write up his 
proposal as a DIP. Now, the cost is that the language maintainer 
must find a champion, and help the champion write up the proposal.

* **Option 2: bypass the DIP process.** The benefit of this 
choice is that the new feature can be merged quickly and without 
any bureaucratic red tape. The cost is that the language 
maintainer misses out on the opportunity for constructive 
feedback afforded by the DIP process.

It is important to keep in mind that, given D's BDFL governance 
model, *option 2 is always on the table.* It follows that 
anything that makes option 1 more difficult will, on the margin, 
encourage language maintainers to choose option 2 instead.

By requiring the involvement of an additional person, the 
"champion" requirement makes option 1 more difficult than it was 
before. And the result has been exactly what you'd expect: rather 
than using the DIP process to solicit community feedback on 
ImportC and AliasAssign, the language maintainers have chosen to 
merge them without DIPs.

It is time for us to admit that the "champion" requirement was a 
mistake. It should be removed from the DIP process, and language 
maintainers should be allowed (and encouraged) to submit their 
proposals for community feedback directly.

[1]: https://forum.dlang.org/post/rf96ib$176$1@digitalmars.com
[2]: https://dlang.org/spec/declaration.html#AliasAssign
[3]: https://dlang.org/spec/importc.html