The DIP Process

[Jonathan Marler]

On Friday, 1 March 2019 at 21:23:10 UTC, Walter Bright wrote:
> When I get involved early in the DIP process, what happens is 
> the author quits and leaves it to me to finish, which usually 
> means doing 98% of the work.

This doesn't make sense.  If you leave feedback and the author 
quits you don't have to take over the work.  Let someone else 
take it over.  Even better, since you left feedback, the new 
owner can take your feedback and improve the DIP with it.  If no 
one takes it over, then the DIP isn't worth anyone's time and 
you've now saved a years worth of the author's and community's 
time from researching/revising and debating worthless DIP.

>
> Most proposals to improve process with D revolve around asking 
> myself and Andrei to do most of the work. It just doesn't scale.
>
> The point of the DIP process is to mobilize the community to do 
> the work, demand a high standard, and vet the work.

This is misrepresentation of what we are proposing.  We are not 
proposing that you "baby" each DIP through the whole process.  We 
are proposing that you stay involved along the process just like 
all the other reviewers.  This means that if you see a new DIP 
and it definitely will never get into the language, take a minute 
to respond immediately with why it won't be accepted.  Not every 
proposal will need your intervention either.  If you take a look 
at a DIP and it looks fine but needs some polish, let the 
community do that.  If you see a DIP and there's a question you 
can already answer such as a general direction it should take, 
then give that direction.  All we're asking for is feedback and 
direction from you.  Since you are the decision maker, you're the 
only one that can do this job.

What's worse is it sounds like you and Andrei are actually using 
the DIP process to go out of your way not to leave any feedback 
at all.  I have no idea why either of you would think this is a 
good idea.

>
> As mentioned before, this has been successful in the C++ 
> community in that the standard of proposals has steadily risen. 
> I've spoken with Mike Parker about picking out a couple of 
> approved DIPs to be presented as a "gold standard" on how to do 
> a DIP. We expect to replace them with better ones over time, to 
> keep on raising the bar on quality.
>
> Having such examples makes it much easier to review a DIP and 
> bounce it back as "not good enough".
>

The C++ standard is a good goal to work towards but trying to 
force it on a community that hasn't matured yet will not produce 
the results you want.  In my opinion, the DIP process should 
start with yours and Andrei's involvement and evolve naturally 
into what the C++ community has.  As the community interacts with 
you and Andrei on the proposals, certain people will start to 
stand out as those who can implement your standards and who have 
similar opinions as you.  Over time, you should find that you 
just don't need to spend as much time because your "lieutenants" 
will already be giving the feedback that you would have given.

Trying to force this heirarchy without the necessary foundation 
of transferring knowledge and expertise to the community will 
result in a "foundation-less" process where no one is able to 
know what you and Andrei want so in your eyes the quality 
suffers.  That's exactly what we are seeing today.


> ---
>
> On a final note it doesn't matter to the DIP approval process 
> how hard anyone works on the proposal, or how much time they 
> spent on it, etc. Only results matter. By the same token, I 
> don't expect anyone to care how much time I spend on D, I don't 
> expect anyone to use D because people worked hard on it, etc. 
> The only thing that matters is how good D is.

Agreed.  We are not complaining about the amount of work.  We are 
complaining that there is no feedback to the work we are doing so 
we are "wasting work".  The "amount of work" is not a problem.  A 
large community with a good process can do amazing things, but 
with a bad process will just be a waste of everyone's time as it 
does not produce any results and takes everyone's work away from 
what could be productive tasks.

>
> It's a bit like the Olympics. Nobody cares how hard/long an 
> athlete trained. Only that they win. Who would want it any 
> other way?

Exactly.  With the current process everyone is doing alot of work 
and producing no results.  We are proposing to change the process 
not to save work, but to turn the work we are already doing into 
effective results.