Permalink
Reply
Early last year, Mike Parker, the DIP manager, announced a set of new rules 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 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 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.
