The DIP Process

[Nicholas Wilson]

On Wednesday, 6 March 2019 at 18:40:57 UTC, Mike Parker wrote:
> the lion's share of the effort is up front. The rest of the 
> time is spent waiting.

1. You missed the vast amount of political effort required to get 
to the bottom of why it was rejected.

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

Not quite that harshly, but 
https://github.com/dlang/DIPs/pull/101#issuecomment-414803648 ...

> Because there was no Community Review, the community lost the 
> opportunity to debate and improve the DIP.

Not entirely, there is still draft review.

> There is no chance to change Walter or Andrei's mind.

...the author agreed to withdraw it.

> And yes, they have approved a DIP before that they expected to 
> reject.

Out of curiosity, which one?

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

You should it imply that? If they see a problem or a direction 
they fell the DIP should go in

> How does the DIP author feel, then, when they get to the end 
> and it's rejected?

That depends entirely on _why_ is was rejected. In the case of 
1015 or 1016, disappointed would be an understatement, although 
for different reasons.

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

If the DIP is beyond salvaging, or the author has failed to fix 
any problems previously identified *chough* 1017 *cough*.

> Should they suggest their own improvements?

Yes!

> Again, what if they do suggest improvements and then reject the 
> DIP in the end?

Then they will have their reasons, and those reasons will be 
available for all to see (and possibly ridiculed if they are 
completely wrong (e.g. 1015/16), and rightly so).

> At this point, why bother with the Final Review or Formal 
> Assessment at all?

It may pick up something the community has missed.

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

2. It should be a trivial effort for W&A to answer:
at the end of the draft stage, reading _just_ the title and the 
abstract, "If this thing is well specified something we _think_ 
would benefit from having in the language?"
at the end of community: is this well specified? Has the answer 
above changed? What issues that have been identified, must be 
resolved?

> The DIP process is long, but it absolutely should be.

No, it should be thorough. One of the sections of the DConf 
foundation meeting is to provide a platform for rigorous review 
and feedback to cut down the amount of time it takes.

> And anyone going into it needs to understand that up front and 
> that they might not agree with the end result. But again, the 
> majority of the effort goes into the initial draft, so having a 
> long process does not add a significant burden of effort on the 
> DIP author. It may test the author's patience, but that's 
> something else entirely.

See point 1.

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

s/long/thorough

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

Unfortunately just because a DIP is up to standard and the 
community endorses it, doesn't mean that it will be accepted, see 
1015.

> Walter and Andrei have accepted DIPs conditionally and sent 
> them back to the author for modification before, and they 
> likely will again.
>
> So the TL;DR from me is, Walter and Andrei should not be 
> involved in the process until the end.

I couldn't disagree more. Their involvement means we can avoid 
process errors like:
1015 (wrong outcome)
1016 (poor handling of the response)
1017 (everything, but principally wasting time reviewing a DIP 
that contains all of its flaws)
1018 @implicit, ideally they would have taken the hint a bit 
sooner but they eventually fixed it, which is was matters, even 
it if detracted from the review.

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

Thats all well and good, but as long as W&A are the ones that 
have the final say, it is them who need to answer point 2.