On Wednesday, 22 July 2020 at 11:54:33 UTC, claptrap wrote:
>
> 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.

The way I see it, this third person should be not a maintainer but an independent arbiter who is not involved in the whole DIP process. He has no vote when maintainers decides if the DIP should be accepted. But, after the DIP gets accepted, community would have a right to appeal to the arbiter and he can decide to repeal this DIP.

This wouldn’t change the existing process, only add an extra safeguard. Walter would be allowed to write his own DIPs without an overhead of adding an additional person. Arbiter’s involvement will only be needed in very special cases.

If Andrei would agree to take this position, that would be great. It would’t require his constant involvement. And everyone would be happy to know that Andrei is still on board.

On Wednesday, 22 July 2020 at 08:20:37 UTC, Mike Parker wrote:

> 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 might work, provided the author of the DIP (a) provides the necessary details in the DIP, and (b) makes a good faith effort to understand and address feedback. I'm not convinced that will happen. My preferred alternative would have been for Walter to not go through the DIP process. That would be less work for him and everyone else, and it would maintain the integrity of the DIP process. He could talk directly with Atila and anyone else he chooses to bring into the process.

On 7/22/20 10:14 AM, Ogi wrote:
> On Wednesday, 22 July 2020 at 11:54:33 UTC, claptrap wrote:
>>
>> 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.
> 
> The way I see it, this third person should be not a maintainer but an independent arbiter who is not involved in the whole DIP process. He has no vote when maintainers decides if the DIP should be accepted. But, after the DIP gets accepted, community would have a right to appeal to the arbiter and he can decide to repeal this DIP.
> 
> This wouldn’t change the existing process, only add an extra safeguard. Walter would be allowed to write his own DIPs without an overhead of adding an additional person. Arbiter’s involvement will only be needed in very special cases.
> 
> If Andrei would agree to take this position, that would be great. It would’t require his constant involvement. And everyone would be happy to know that Andrei is still on board.

Thanks for the thought. I'm glad to opine about things on occasion and am not going anywhere, but the official position has taken a toll on me. I need to decline.

Even if I was up for it, it would be a huge positive step forward to find someone else for it. The D language is a few strong contributors away from greatness.

On Wednesday, 22 July 2020 at 14:47:29 UTC, bachmeier wrote:
> [snip]
>
> This might work, provided the author of the DIP (a) provides the necessary details in the DIP, and (b) makes a good faith effort to understand and address feedback. I'm not convinced that will happen. My preferred alternative would have been for Walter to not go through the DIP process. That would be less work for him and everyone else, and it would maintain the integrity of the DIP process. He could talk directly with Atila and anyone else he chooses to bring into the process.

I'm confused about your preferred alternative. If that were used for the @safe DIP, then Walter would have talked to Atila (who approved it) and a few others and then it would have been accepted. The outcome would have been the same. At least with the prior DIP process, the community would have been involved early on to provide feedback. While that feedback was largely ignored, it is functionally the same as the prior process just with a larger group of people who can provide feedback, multiple rounds, and a more formal process.

About the new process, I'm glad that they are listening to feedback, but it would be no easy feat for Walter to outsource something with the complexity of DIP 1000 (the DIP itself).

Personally, I would have preferred to see more focus on governance, such as an advisory vote on DIPs where the voters are not the whole community but a carefully selected subset of significant contributors or users of D (I learned about something similar that Stan uses, apparently they were influenced by Karl Fogel [1]). It could start as an advisory vote and if people are happy with it then it could be considered a community veto, whereby the DIP must achieve at least 1/3 of the advisory vote in addition to both LMs support to be approved or something like that.

[1] https://producingoss.com/en/producingoss-letter.pdf

On Wednesday, 22 July 2020 at 08:20:37 UTC, Mike Parker wrote:
> * /Walter didn't listen to the feedback./ There is a difference between listening to feedback and disagreeing with feedback.

The issue here is that he does listen to feedback, but doesn't have an actual discussion. He doesn't say why he doesn't agree with it and just provides a response that stops all discussion instead of promoting it to come to an understanding. The DIP is written to be similarly and deliberately vague. There was no mention of any sort of "greenwashing" until after the DIP was already accepted, it was obviously a major key reason for why extern(C/C++) was being implemented the way it was. But none of that reasoning was conveyed, so there was no discussion for why that reasoning was terrible.

> 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 "solution" doesn't solve the problem, but then again if you don't think there's a problem then you obviously aren't going to provide a suitable solution :).

On Wednesday, 22 July 2020 at 15:08:04 UTC, jmh530 wrote:
> On Wednesday, 22 July 2020 at 14:47:29 UTC, bachmeier wrote:
>> [snip]
>>
>> This might work, provided the author of the DIP (a) provides the necessary details in the DIP, and (b) makes a good faith effort to understand and address feedback. I'm not convinced that will happen. My preferred alternative would have been for Walter to not go through the DIP process. That would be less work for him and everyone else, and it would maintain the integrity of the DIP process. He could talk directly with Atila and anyone else he chooses to bring into the process.
>
> I'm confused about your preferred alternative. If that were used for the @safe DIP, then Walter would have talked to Atila (who approved it) and a few others and then it would have been accepted. The outcome would have been the same. At least with the prior DIP process, the community would have been involved early on to provide feedback. While that feedback was largely ignored, it is functionally the same as the prior process just with a larger group of people who can provide feedback, multiple rounds, and a more formal process.

My major concern is that the DIP process will stop working if Walter keeps using it. A DIP needs to be detailed, questions need to be answered, and an honest attempt needs to be made to deal with feedback. All the DIP process is doing now is generating mobs with pitchforks.

> About the new process, I'm glad that they are listening to feedback, but it would be no easy feat for Walter to outsource something with the complexity of DIP 1000 (the DIP itself).

To some extent, you have a similar problem with every DIP. Making a decision is a big task. Does it even make sense to ask for feedback from everyone with something like DIP 1000? It's not obvious to me that the DIP process is helpful for Walter's proposals. If Walter and Atila want input, they can post to the mailing list asking for input.

They shouldn't have to deal with community input unless it helps the decision process, and to the extent that it would be helpful. What isn't helpful is soliciting feedback and then making everyone upset because they felt their feedback was ignored. Is it better to waste everyone's time than for them to make these decisions themselves? At times these discussions are built on an implicit assumption that there is no opportunity cost of the DIP process (for Walter and Atila but also the other members of the community).

On Wednesday, 22 July 2020 at 16:07:44 UTC, bachmeier wrote:
> [snip]

I think it's important to recognize the difference between something like DIP 1000 - where your points are quite fair and involved a lot of work from Walter that few other people could do - and DIP 1028 - where there are many people who Walter could have assigned to do the work.

This change implies that Walter isn't going to be writing the things like DIP 1028 that are relatively straightforward. Saves him some time. However, I have some skepticism that Walter would wait for a DIP to be prepared before starting work on something as important as DIP 1000. I would expect him to plow ahead and prepare a preview switch and solicit some feedback. Maybe the DIP gets done, but if it doesn't and there's an implementation that people are happy with then I wouldn't be surprised if it is just gradually put in.

On Wednesday, 22 July 2020 at 13:15:28 UTC, rikki cattermole wrote:
> 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!

I agree.

On Wednesday, 22 July 2020 at 16:07:44 UTC, bachmeier wrote:
> My major concern is that the DIP process will stop working if Walter keeps using it. A DIP needs to be detailed, questions need to be answered, and an honest attempt needs to be made to deal with feedback.

But exactly this point is adressed by the new proposal:
Walter won't write DIPs in the future, but some third person instead.
This person will write the DIP detailed, answers questions and work in the given feedback. Walter and Attila then decides if the result should go in or not.
I like this approach.

On Thursday, 23 July 2020 at 07:43:57 UTC, Dominikus Dittes Scherkl wrote:
> On Wednesday, 22 July 2020 at 16:07:44 UTC, bachmeier wrote:
>> My major concern is that the DIP process will stop working if Walter keeps using it. A DIP needs to be detailed, questions need to be answered, and an honest attempt needs to be made to deal with feedback.
>
> But exactly this point is adressed by the new proposal:
> Walter won't write DIPs in the future, but some third person instead.
> This person will write the DIP detailed, answers questions and work in the given feedback. Walter and Attila then decides if the result should go in or not.
> I like this approach.

I don't see that in the announcement. It says only

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

The main reason others do those things with their DIPs is because they'll be quickly dismissed if they don't. This proposal doesn't add anything to the requirements for DIP authors.