New DIP Rules

ag0aep6g anonymous at example.com
Wed Jul 22 11:05:47 UTC 2020


On 22.07.20 10:20, Mike Parker wrote:
> 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.
[...]
> 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.)

Good: Another person has influence on the DIP. An author can't exactly 
veto a DIP, but they can retract it, forcing Walter to find another 
champion. If he can't find one (because everyone hates the DIP), it 
won't go through.

Bad: This still allows the scenario where 99% of the community are 
against a DIP, yet Walter pushes it through regardless. Ultimately, he 
only has to convince a single person more than before.

Also bad: What if Walter cannot find a champion? Not even because the 
DIP is controversial, but just because no one qualified enough has the 
time. I remember Walter saying more than once that he doesn't want to 
write DIPs on various things, it's just that no one else does, so it 
falls to him. If Walter can't find a champion for that reason, a good, 
necessary DIP might not happen, even if everyone would be in favor.

I don't know if it has been suggested before, but I think this would be 
an obvious alternative: Give the community veto power. Let the community 
vote on every DIP (could just be thumbs up/down on GitHub). If two 
thirds (or 80% or 90% or whatever) vote against a DIP, it gets rejected. 
With this, Walter can't ruin the language single-handedly, but he can 
still make progress even when there's no one else willing to champion a DIP.


More information about the Digitalmars-d mailing list