The DIP Process

[Walter Bright]

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.

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.

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

---

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.

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?