www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - New DIP Rules

reply Mike Parker <aldacron gmail.com> writes:
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.
Jul 22 2020
next sibling parent reply claptrap <clap trap.com> writes:
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.
Jul 22 2020
next sibling parent Tobias Pankrath <tobias pankrath.net> writes:
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.
Jul 22 2020
prev sibling parent reply Dominikus Dittes Scherkl <dominikus scherkl.de> writes:
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.
Jul 22 2020
parent claptrap <clap trap.com> writes:
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.
Jul 22 2020
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
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.
Jul 22 2020
next sibling parent aberba <karabutaworld gmail.com> writes:
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.
Jul 22 2020
prev sibling parent reply claptrap <clap trap.com> writes:
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.
Jul 22 2020
parent reply Ogi <ogion.art gmail.com> writes:
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.
Jul 22 2020
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
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.
Jul 22 2020
prev sibling next sibling parent ag0aep6g <anonymous example.com> writes:
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.
Jul 22 2020
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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!
Jul 22 2020
parent aberba <karabutaworld gmail.com> writes:
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.
Jul 22 2020
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
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.
Jul 22 2020
parent reply jmh530 <john.michael.hall gmail.com> writes:
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
Jul 22 2020
parent reply bachmeier <no spam.net> writes:
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).
Jul 22 2020
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
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.
Jul 22 2020
prev sibling parent reply Dominikus Dittes Scherkl <dominikus scherkl.de> writes:
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.
Jul 23 2020
parent reply bachmeier <no spam.net> writes:
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.
Jul 23 2020
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 23 July 2020 at 12:02:33 UTC, bachmeier wrote:

 On Thursday, 23 July 2020 at 07:43:57 UTC, Dominikus Dittes 
 Scherkl wrote:

 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.




Everything Dominikus said is in the text. The paragraph you took 
the quote from is explicitly saying that Walter and Atila will no 
longer write DIPs themselves, will select others to author them, 
and those authors will be responsible for the DIPs from beginning 
to end. Then later the text says that Walter and Atila will 
evaluate the DIP in whatever state it evolved under the author's 
control. (Although, I just noticed "additional draft" should be 
"initial draft". Sorry if that's confusing!)


 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.


The whole point is that the DIP *becomes a normal* DIP, meaning 
it's authored and maintained by someone who is not a language 
maintainer, just like any other DIP. That's the part that's 
changed. We're taking Walter and Atila out of the DIP authoring 
process instead of, as some have requested, taking them out of 
the decision-making process.
Jul 23 2020
prev sibling parent Avrina <avrina12309412342 gmail.com> writes:
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 :).
Jul 22 2020