In response to the controversy over the acceptance of DIP 1028 (Make @safe the Default), which ultimately resulted in the reversal of the decision, I received proposals to change how DIP assessments are carried out. This is beyond the scope of my role as DIP manager, so I put it on the agenda of our most recent quarterly D Language Foundation meeting, where we discussed it and reached a decision.

The crux of the proposals was that the language maintainers, Walter and Atila, should not be in a position to evaluate their own DIPs. The suggestions were to either add a third maintainer to the team or to have a person on call to evaluate any DIPs by Walter and Atila.

On the surface, these are reasonable suggestions. There are many scenarios in modern society where we expect individuals to recuse themselves from performing their normal duties when those duties intersect with their personal interests. However, language design is generally not one of them.

Adding a third maintainer, whether on a flexible or permanent basis, requires finding someone with the proper skillset and scope of knowledge to fill the role, which is no easy task. But even were such a person found, we can find no rationale to prevent any language maintainer from evaluating their own proposals. By definition, as language maintainers, Walter and Atila are the final arbiters of which features do and do not make it into D. Whether one of them or someone else is the source of a feature proposal is irrelevant. They are either maintainers or they aren't. To take either of them out of the decision making process would be to say they aren't.

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.

That we have two maintainers means nothing is accepted unless they both agree. Very few DIPs reach Formal Assessment without flaws and with both maintainers in agreement on acceptance. In those cases, whether the end result is acceptance or rejection, the decision isn't reached without debate and without one of them finally convincing the other (often over the phone). The decision making is not a rubberstamp. It's actually sometimes adversarial. When it comes to proposals by the maintainers, introducing such adversity earlier in the process may be a good thing.

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.)

With this change, Walter and Atila will still be the ones who decide what does and does not get into the language, but any feature ideas they have will evolve, for better or worse, without their input. Those DIPs from Walter currently moving through the DIP queue will remain in their current form. Those still in Draft Review in PR queue will be subject to the new rule and will be revised by a different author.

Two other major issues were raised in the wake of 1028:

* /No rationale was provided for acceptance./ This is my fault. I have always requested a rationale for rejection, but not for acceptance. Often, the maintainers have had specific issues with the DIPs they accepted. In those cases, they have always provided comment. Only one DIP had previously been accepted without any comment at all (1024). I did not ask for a rationale for either 1024 or 1028. Henceforth, we will always provide a rationale for both acceptance and rejection.

* /Walter didn't listen to the feedback./ There is a difference between listening to feedback and disagreeing with feedback. I ask every DIP author to respond to each unique point of feedback in the Feedback Thread, but no DIP author is required to modify their DIP in response to feedback. All criticisms, positive and negative, will be there in both threads for the language maintainers to take into account as part of the assessment. We hope the change I outlined above will alleviate this by putting the decision to modify maintainer's DIP idea into the hands of an author who is not a language maintainer.

On Wednesday, 22 July 2020 at 08:20:37 UTC, Mike Parker wrote:
> In response to the controversy over the acceptance of DIP 1028
>
> 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.)

This is utterly pointless, it's still the maintainers DIP in all but name, the self interest in seeing it pass is still there 100%.

The problem could have been avoided, Walter knew that 1028 was going to be massively unpopular, he said he was expecting the backlash. But he steamrollered it through anyway.

What he could have done is ask Andrei to take his place as a reviewer given he knew how controversial the DIP was. Or he could have let Atila come to a decision by himself.

Both of those would have been better than what happened, or what is now proposed.


> * /Walter didn't listen to the feedback./ There is a difference between listening to feedback and disagreeing with feedback.

Why then did Andrei manage to change Walters mind when the community couldn't? Andrei didn't say anything that hadn't already been said 100 times.

Simple fact is either Walter didn't take the time to understand what the community was saying / or he didn't value what they said.

On Wednesday, 22 July 2020 at 09:56:54 UTC, claptrap wrote:
>
> This is utterly pointless, it's still the maintainers DIP in all but name, the self interest in seeing it pass is still there 100%.

I disagree. Take for example the DIP about string formatting. Walter dropped his idea b.c. of the community feedback. With this new method one of the various counter proposals would have been up for the formal assessment and he could still drop it (same outcome) or adopt it (different outcome). But he could not have pushed it through.

I think this is a step in the right direction.

On Wednesday, 22 July 2020 at 09:56:54 UTC, claptrap wrote:
> On Wednesday, 22 July 2020 at 08:20:37 UTC, Mike Parker wrote:
>> In response to the controversy over the acceptance of DIP 1028
>>
>> Henceforth, when a language maintainer wants to write a DIP, he will instead recruit someone to write it for him. [...]
>
> This is utterly pointless, it's still the maintainers DIP in all but name, the self interest in seeing it pass is still there 100%.

No it isn't. Because a third person may change the DIP according to feedback and then the maintainers can decide it they like the DIP the new way or not. I think this is a huge improvement.

> Simple fact is either Walter didn't take the time to understand what the community was saying / or he didn't value what they said.

Even there having a third person deeply involved is huge improvement. Maybe not ideal, but the best we can get. Let's try it before claiming that it's not worth it.

On Wednesday, 22 July 2020 at 08:20:37 UTC, Mike Parker wrote:
>
> Adding a third maintainer, whether on a flexible or permanent basis, requires finding someone with the proper skillset and scope of knowledge to fill the role, which is no easy task. But even were such a person found, we can find no rationale to prevent any language maintainer from evaluating their own proposals. By definition, as language maintainers, Walter and Atila are the final arbiters of which features do and do not make it into D. Whether one of them or someone else is the source of a feature proposal is irrelevant. They are either maintainers or they aren't. To take either of them out of the decision making process would be to say they aren't.
>

I would like that D has a third maintainer because that would give the project a better balance of terror. As you described Atila an Walter can still have veto rights in order for the project not to be hijacked.


> 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.)
>

I don't understand what this is supposed to accomplish. This is basically rule by proxy which is something I see in every day in real life politics and it is always ugly for obvious reasons.

I rather suggest that a maintainer cannot decide if a DIP they created themselves can be accepted or not. Maintainer still has full veto rights but not full accept rights. This almost require that we have more maintainers.

The other direction is a more Committee but requires even more people for a stable organization. I understood this wasn't really feasible at this point.

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.

On Wednesday, 22 July 2020 at 10:57:20 UTC, IGotD- wrote:
> On Wednesday, 22 July 2020 at 08:20:37 UTC, Mike Parker wrote:
>>
>> Adding a third maintainer, whether on a flexible or permanent basis, requires finding someone with the proper skillset and scope of knowledge to fill the role, which is no easy task. But even were such a person found, we can find no rationale to prevent any language maintainer from evaluating their own proposals. By definition, as language maintainers, Walter and Atila are the final arbiters of which features do and do not make it into D. Whether one of them or someone else is the source of a feature proposal is irrelevant. They are either maintainers or they aren't. To take either of them out of the decision making process would be to say they aren't.
>>
>
> I would like that D has a third maintainer because that would give the project a better balance of terror. As you described Atila an Walter can still have veto rights in order for the project not to be hijacked.
>
>
>> 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.)
>>
>
> I don't understand what this is supposed to accomplish. This is basically rule by proxy which is something I see in every day in real life politics and it is always ugly for obvious reasons.

And they they still manage to find loop holes in the system to exploit nevertheless.

>
> I rather suggest that a maintainer cannot decide if a DIP they created themselves can be accepted or not. Maintainer still has full veto rights but not full accept rights. This almost require that we have more maintainers.

Great idea.

>
> The other direction is a more Committee but requires even more people for a stable organization. I understood this wasn't really feasible at this point.


Sometimes someone gotta trust someone will make a good decision and committees don't always (mostly??) make right decisions either. We all know familiar examples.

I believe Walter has made more good decisions in the past. With some few mistakes here and there. And in most times the community jump in and they're forced to revert.

Some of these DIP are the result of the same people who ask for random things based on daily wishes that they end up not needing after all.

It's hard to filter through which ones are pointless nitpicking, abstract or practical. And the community doesn't help with making progress sometimes...and things end up abandoned by the DIP authors...so many demands.

On Wednesday, 22 July 2020 at 10:24:34 UTC, Dominikus Dittes Scherkl wrote:
> On Wednesday, 22 July 2020 at 09:56:54 UTC, claptrap wrote:
>> On Wednesday, 22 July 2020 at 08:20:37 UTC, Mike Parker wrote:
>>> In response to the controversy over the acceptance of DIP 1028
>>>
>>> Henceforth, when a language maintainer wants to write a DIP, he will instead recruit someone to write it for him. [...]
>>
>> This is utterly pointless, it's still the maintainers DIP in all but name, the self interest in seeing it pass is still there 100%.
>
> No it isn't. Because a third person may change the DIP according to feedback and then the maintainers can decide it they like the DIP the new way or not. I think this is a huge improvement.

If Walter can convince Atila that safewashing is good then he can convince whoever writes the DIPs for him. Unless you imagine that Walter will completely step back once a DIP is initiated? No criticism of Walter but I dont see him doing that, most people wouldnt.

On Wednesday, 22 July 2020 at 10:57:20 UTC, IGotD- wrote:
> On Wednesday, 22 July 2020 at 08:20:37 UTC, Mike Parker wrote:
>>
>> Adding a third maintainer, whether on a flexible or permanent basis, requires finding someone with the proper skillset and scope of knowledge to fill the role, which is no easy task. But even were such a person found, we can find no rationale to prevent any language maintainer from evaluating their own proposals. By definition, as language maintainers, Walter and Atila are the final arbiters of which features do and do not make it into D. Whether one of them or someone else is the source of a feature proposal is irrelevant. They are either maintainers or they aren't. To take either of them out of the decision making process would be to say they aren't.
>>
>
> I would like that D has a third maintainer because that would give the project a better balance of terror. As you described Atila an Walter can still have veto rights in order for the project not to be hijacked.

Maybe a third maintainer who only steps in when needed. I have no idea but I assume most DIPS are not actually that contentious?

So maybe have a vote of the core team, if it's above a certain threshold, ask someone else to step in instead of the person voting on their own DIP.

A good step in the right direction, even if it didn't go the direction most people seemed to want.

Lets give it a try!