The DIP Process

[Jonathan Marler]

On Friday, 1 March 2019 at 05:24:25 UTC, Nick Sabalausky 
(Abscissa) wrote:
> My take on all this (not that it counts for anything):
>
> See? This is what happens when you introduce 
> bureaucracy/red-tape to problems. You get the same problems, 
> just with much slower progress.
>
> Frankly, I think we already have far better mechanisms that 
> anything a supposedly-improved DIP process could ever provide: 
> Github reviews and CI tests.
>
> Looking at DIP1016 in particular:
>
> 1. Using the same Github code review process we already use to 
> get things done instead of this "The DIP Process" contrivance 
> would have allowed the DIP the flexibility necessary to receive 
> W&A feedback sooner AND respond to such feedback without the 
> "Too bad, go back to start, try again" 
> formality-for-the-sake-of-formality worthlessness.
>
> 2. The test suite is going to do a ****FAAAAARRRR**** better 
> job of rooting out technical problems than five years of 
> human-review. Does anyone seriously think it *wouldn't* have 
> caught the issues with 1016 right away? And even if so, does 
> that say more about the DIP process, or does it say more about 
> the test suite?

I completely agree with this.  Languages are very hard and the 
DIP process has been put in place as a result.  Walter and Andrei 
want to be sure that any language changes we make going forward 
are thoroughly researched and vetted.  The DIP process was put in 
place so they could leverage the community's efforts rather than 
having to do all the work themselves and leverage the large 
experience/viewpoint pool that comes with large group. However, 
the process itself has sorely missed the mark in achieving this.

For some reason, someone decided that rather than having the 
entire community work together on a DIP, it should be everyone 
except Walter and Andrei.  So now the original goal of

   "Let's research and vet a new proposal as a community to see if 
it's good for D"

Has now become:

   "Go spend a year writing a proposal for your idea to convince 
Walter and Andrei that your proposal is a good idea. And do all 
this without any feedback from them during this time.  Then at 
the end, they'll look over the proposal and either accept it or 
reject it, maybe they'll give you some good feedback, maybe they 
won't.  Oh and if they don't accept it, you'll need to start the 
whole process over again.  And if they give bad feedback, too 
bad, the process doesn't account for this or give you any 
recourse and we MUST FOLLOW THE PROCESS TO THE LETTER.  Why? 
Well...because it's the process."

Now I'm not saying that processes are all inherently bad.  They 
are an attempt to provide a set of rules to facilitate a final 
goal.  Processes become a hindrance when people start to rigidly 
adhere to them no matter what, and they forget the original goal 
of why the process was created in the first place.  The DIP 
process is now suffering from the "rigid adherence" problem but 
also has a second problem.  The DIP process as it's designed is 
horribly flawed because it has left out the 2 most important 
people in the community in most of the process.

To fix this we need to fix the process, and also fix people's 
mindsets.  Keep the original goal in mind.  When the process 
contradicts the original goal don't just adhere to the process 
anyway, feel free to break it.  And lastly, fix the process.  
Don't write Walter and Andrei out until the end.  The communities 
efforts will be much more effective if they are guided by its 
leaders rather than forcing them to go in a direction for an 
entire year that may be completely in the wrong direction.