The DIP Process

[Nicholas Wilson]

On Thursday, 28 February 2019 at 23:15:30 UTC, Olivier FAURE 
wrote:
> On Thursday, 28 February 2019 at 03:06:37 UTC, Nicholas Wilson 
> wrote:
>> A DIP is only as good as the feedback it receives.
>
> You're saying this like it's self-evident, but it seems very 
> clear to me that it's the very root of your disagreement with 
> Andrei: you believe that the process should involve the 
> reviewers making an effort proportional to the DIP author, 
> whereas Andrei believes that the process should minimize 
> reviewer effort.
>
> Now, neither of these ideas are inherently invalid, but you 
> have to realize they're a trade-off. You're not going to 
> convince Andrei to change the DIP process by saying "The 
> current process wastes the time of DIP authors!", because 
> Andrei is already aware of that. The problem is that is that a 
> process with a heavier involvement from W&A would waste/spend 
> more of *their* time, which Andrei considers a bad trade-off.

Thank you for making that observation.

Yes it is a tradeoff, but we are at one extremum at the moment. I 
don't think I suggested that the effort of W&A put in prior to 
the formal assessment should match that of the author, sorry for 
the confusion if it came across that way. Perhaps I should have 
said "A DIP improves only as much as the feedback it receives."

(Pedantically I suppose the improvements are bounded by the 
feedback it receives, since that didn't help 1017 at all.)

> (personally, I can see where he's coming from; there are a lot 
> of people writing DIPs, and only two W&A; any process which 
> requires more involvement from them is going going to see them 
> spending less time on maintaining the compiler, designing 
> features, and whatever else it is they're doing)

Maximising the return on investment of having reviews is 
important and I believe that there is a lot of low hanging fruit, 
but the PRIMARY issue it that this whole debacle could have been 
avoided if W&A had said "We've found some significant issues with 
this DIP please edit the DIP to fix them." Instead there was no 
communication at all, they got confused by ambiguities in the DIP 
and delivered the right verdict (in the sense that e.g. exception 
handling needs to be accounted for) for COMPLETELY the wrong 
reasons. Their behaviour that followed was less than stellar.

> (that said, the current process could definitely stand to be 
> improved, and I like the direction Mike is going for)

Yes, I'm expecting quite a few changes to the process in response 
to issues identified with DIPs 1000, 1015-18 at the DConf 
Foundation meeting.