www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The new rule for DIPs by language maintainers was a mistake

reply Paul Backus <snarwin gmail.com> writes:
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
Oct 18 2021
next sibling parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Tuesday, 19 October 2021 at 02:22:54 UTC, Paul Backus wrote:

 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.


If you step back and consider why option 2 wouldn't be used all 
the time, then I'd suggest community engagement as an important 
additional factor to the already mentioned technical benefit of 
constructive feedback.

In light of community engagement, a champion concept makes 
sense...there is now a larger surface for the community to 
influence a language maintainer-led DIP.

I would have thought that the idea of a champion would be quite 
attractive to a langue-maintainer; a person to battle for you in 
the forums, so to speak. You are not wrong in that the 
involvement of an additional person in the DIP does come with a 
cost, but how that cost effects the DIP process, I'm not entirely 
sure.
Oct 19 2021
parent Paul Backus <snarwin gmail.com> writes:
On Tuesday, 19 October 2021 at 08:47:03 UTC, Jordan Wilson wrote:

 I would have thought that the idea of a champion would be quite 
 attractive to a langue-maintainer; a person to battle for you 
 in the forums, so to speak. You are not wrong in that the 
 involvement of an additional person in the DIP does come with a 
 cost, but how that cost effects the DIP process, I'm not 
 entirely sure.


In practice, finding a champion has turned out to be extremely 
difficult, and several language-maintainer DIPs have been unable 
to progress beyond Draft status due to lack of one.

In retrospect, this is not terribly surprising. It takes a lot of 
effort to write a DIP and shepherd it through the DIP process. 
Few people are motivated enough to put forth that effort even for 
their own proposals; fewer still are willing to do so on someone 
else's behalf.
Oct 19 2021
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 19 October 2021 at 02:22:54 UTC, Paul Backus wrote:

 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.


Partly agree. If the language maintainers are governing the 
development of the DIP, the champion acts just as a diplomat 
between them and the community. In that case, in effect they are 
doing the DIP themselves anyway and could do it directly just as 
well.

But I think the champion principle can work if the champion is 
given the task to address the reviews him/herself without 
involvement from the maintainers before the final verdict. The 
champion is still required to keep the DIP focused on the 
original problem, but otherwise has freedom to develop the DIP 
how he/she sees fit. The maintainers can still give feedback in 
the reviews.

So I think we should either allow them to submit the DIPs 
themselves, or require them to let the champion to develop the 
DIP freely. I think the latter is what is encouraged in any case.
Oct 19 2021
parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 19 October 2021 at 09:27:49 UTC, Dukc wrote:

 But I think the champion principle can work if the champion is 
 given the task to address the reviews him/herself without 
 involvement from the maintainers before the final verdict. The 
 champion is still required to keep the DIP focused on the 
 original problem, but otherwise has freedom to develop the DIP 
 how he/she sees fit. The maintainers can still give feedback in 
 the reviews.


Should have re-read the thread where Mike announced the champion 
principle before posting this. What I "suggested" is already 
supposed to be the case.
Oct 19 2021
prev sibling parent reply ClapTrap <clap trap.com> writes:
On Tuesday, 19 October 2021 at 02:22:54 UTC, Paul Backus wrote:

 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.


Did people actually think that getting someone to write and 
submit the DIP on behalf of a "language maintainer" would somehow 
make the "language maintainer" unbiased when it came to reviewing 
it? That seems hopelessly naive if you ask me.

This idea should have been shot down just because it doesn't 
solve the problem it is supposed to, never mind if it's caused 
other problems.
Oct 19 2021
parent bauss <jj_1337 live.dk> writes:
On Tuesday, 19 October 2021 at 18:25:21 UTC, ClapTrap wrote:

 Did people actually think that getting someone to write and 
 submit the DIP on behalf of a "language maintainer" would 
 somehow make the "language maintainer" unbiased when it came to 
 reviewing it? That seems hopelessly naive if you ask me.


Not gonna lie, most of the D community sometimes seem very naive.
Oct 20 2021