The new rule for DIPs by language maintainers was a mistake
snarwin at gmail.com
Tue Oct 19 02:22:54 UTC 2021
Early last year, Mike Parker, the DIP manager, announced [a set
of new rules] for DIPs by language maintainers (i.e., Walter
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] and [ImportC] 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
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.
More information about the Digitalmars-d