The DIP Process

[Jonathan Marler]

On Wednesday, 6 March 2019 at 18:40:57 UTC, Mike Parker wrote:
> On Wednesday, 6 March 2019 at 15:48:12 UTC, FeepingCreature 
> wrote:
>
>
>> highly dedicated, enthusiastic and ascetic developers who can 
>> work for months to years in radio silence
>
>> if I worked on a feature for a year
>>
>
>> a few lines of feedback can invalidate months of work
>
> I keep seeing variations of this "months of effort" claim. 
> There's simply no such thing. It's more like "months of 
> waiting".
>
> The effort on a DIP is front-loaded. The majority of it goes 
> into getting the initial draft ready for the Draft Review 
> stage. Some DIPs receive more feedback than others in Draft 
> Review, but even those that have long discussions tend to get 
> them out of the way early on, with a little more feedback 
> trickling in now and again while the author waits for me to 
> move the DIP to the next round, but very little revision after 
> the initial couple of weeks or so.

I don't think you're giving the proper weight to the amount of 
time and effort that it takes to go through the DIP process.  
We're not just talking the time it takes to write the DIP readme 
file.  There's the time it takes for everyone that is involved to 
read it, think about it, discuss it on the forums, research it, 
create test cases, look at code to see how to implemented it, 
etc.  Alot of time and effort goes into a DIP that isn't shown in 
the final readme document, and it takes that time away from many 
people, not just the author and manager of the DIP.

> As for Walter and Andrei's feedback, I've thought about this 
> quite a bit lately and I really don't think it reasonable to 
> require it up front. Imagine they flat out tell a DIP author in 
> Draft Review that the DIP has zero chance of being approved. 
> The DIP author closes the PR and then we'll never know.

If Walter and Andrei say a DIP has 0% chance of being approved, 
then we've just saved alot of people alot of time, argument and 
potentially hurt feelings.  Walter and Andrei aren't required to 
give a final ruling at this time, but it would be great if they 
could give feedback like:

     "I'm not sure about this feature, we'll need some good 
rational and examples to be convinced."

     "I really want this feature in D in some form, let's do some 
good research to make sure there are no nasty corner cases and 
that we get a very good implementation".

     "I don't see any path for this particular feature to be 
accepted."

I think W&A can tell the difference between a poorly written DIP 
and a poor idea.  If a DIP is poorly written they can say "I 
think there's a good idea here but the DIP is poorly written".

> there was no Community Review, the community lost the 
> opportunity to debate and improve the DIP. There is no chance 
> to change Walter or Andrei's mind. And yes, they have approved 
> a DIP before that they expected to reject.

You're talking like W&A are children who rush to judgement and 
can't keep an open mind.  I don't think this is the case, and if 
it is, we got bigger problems on our hands :) I think they are 
capable of giving reasonable feedback without unnecessarily 
rushing to judgment.

>
> If, on the other hand, Walter and Andrei provide editorial 
> feedback to strengthen the DIP, this will easily lead to the 
> impression that they are likely to approve it. How does the DIP 
> author feel, then, when they get to the end and it's rejected?
>

It's all in the way the response is worded.  If they're not sure 
about the idea yet and are waiting for more research from the 
community then they can indicate that.

     "Not sure whether or not this feature would be good for D at 
this time. Would like to see some more rational/research from the 
community on this one."

> What if we wait and instead ask them for feedback during the 
> Community Review? Now they can see the debate, see the 
> improvements. So... should they reject a bad DIP now? Should 
> they suggest their own improvements? Again, what if they do 
> suggest improvements and then reject the DIP in the end? At 
> this point, why bother with the Final Review or Formal 
> Assessment at all?

Should they reject the DIP now?  It depends on what they think of 
it. If they know it will never be accepted then yes.  If not, 
then why would they reject it?

Should they suggest their own improvements?  Of course, why not?  
If they still end up rejecting the DIP that's a much better 
process than if they left no feedback at all during the whole 
process, and now the DIP will contain more relevant points that 
matter rather than focusing on things that don't since it wasn't 
given any guidance.

>
> I appreciate the sentiment behind the suggestions throughout 
> this thread. The goal is to increase the likelihood of 
> acceptance while giving an early out to DIPs that won't be 
> accepted. I agree we can do more of the former, but not the 
> latter.

Increasing acceptance is most certainly 100% NOT the goal. I 
don't remember anyone saying that. The goal is to leverage the 
community to vet new features for D.  Our suggestions help with 
that goal by

1) directing people's efforts towards fruitful endeavors rather 
than wasting time on pointless ones
2) maintaining a positive community by showing we value people's 
time by taking our own time to leave feedback and give direction

>
> A long process also means that people aren't going to submit 
> DIPs willy nilly. There needs to be a substantial amount of 
> thought that goes into one, so the bar should be high. The 
> stages of review are there so that the community can put their 
> collective deliberation into it and try to persuade the author 
> to change/fix/enhance the DIP in one way or another. This isn't 
> always going to produce a DIP that's up to standard, but that 
> doesn't mean rejection. Walter and Andrei have accepted DIPs 
> conditionally and sent them back to the author for modification 
> before, and they likely will again.

I keep hearing these rules and justifications like

     A long process also means that people aren't going to submit
     DIPs willy nilly

It's true that people are detured from things if they take 
longer, but that's not justification to implement such a rule. 
They would also be detured if they had to hand out their social 
security number and perform a double-backflip on the trampoline 
before they could submit a DIP :)  Instead, we should let the 
process evolve naturally and only intervene with rules when 
problems occur, and even then, creating a new rule should be a 
last resort since it's very hard to write a rule that is good in 
all cases.

>
> So the TL;DR from me is, Walter and Andrei should not be 
> involved in the process until the end. As I suggested before, 
> however, we could absolutely use a couple of people at the 
> beginning who have the background needed to nudge a DIP toward 
> the standard of technical soundness Walter and Andrei are 
> looking for.
>
> My focus is on grammar, vocabulary, that sort of thing. Given a 
> couple of people who have received instruction from Walter and 
> Andrei and with whom I can consult to ensure the DIP is hitting 
> all the right notes at different stages of the review, we can 
> produce higher quality DIPs and hopefully make the process more 
> efficient.

Though I see your reasoning I think you can see from my responses 
that I very much disagree with your conclusion.  What we're 
saying is, at the very minimum, there should not be a rule to 
exclude Walter and Andrei till the end.  You provided one example 
where them leaving feedback early on would cause a DIP to fail.  
This is exactly what we want.  We don't want to waste people's 
time if Walter and Andrei already know they're going to reject 
the DIP.  In the case where they don't know whether or not it 
will succeed, then you're example doesn't apply since Walter and 
Andrei wouldn't leave feedback indicating the DIP is Dead on 
Arrival.

As to whether Walter and Andrei should be required to leave 
feedback, I would argue "yes" but I know that's a more radical 
change to the current process.  However, I strongly believe they 
shouldn't be pushed out of the process until the end.  Each DIP 
will be unique, let each one be handled in the proper way.  If 
W&A think a DIP is viable and want to wait for community feedback 
and revision that's fine.  If they have suggestions/guidance for 
it, even better.  If they know it's a waste of time, then I 
recommend they say something and point the author towards better 
endeavors.