The DIP Process

FeepingCreature feepingcreature at gmail.com
Wed Mar 6 15:48:12 UTC 2019


On Monday, 4 March 2019 at 22:25:01 UTC, Walter Bright wrote:
> BTW, I think it's very good of you to recognize issues and work 
> to resolve them. I have a lot of respect for that. But don't 
> expect to just read a book and get better at it. It's a 
> lifelong struggle.
>

Frankly-

at several points in this thread it seems that your response to a 
complaint that something was not done or not attempted has been 
"I've tried doing that, and it has not worked, so I no longer try 
to do that."

I don't see how a process that relies on feedback can function 
when one of the participants has given up on feedback. I don't 
see how DIPs can work if you've given up on supporting DIPs!

I think asking you to put in all of the effort in implementing a 
feature, pushing a DIP through to completion is unreasonable. 
However, providing no feedback and letting the DIP author develop 
in the wrong direction and finally giving a verdict a year into 
the process is *also* unreasonable. Letting others try to push 
effort off onto you is unreasonable, but it's not fair to the 
developers of current DIPs to punish them for the bad behavior of 
previous developers.

If you have given up on providing feedback during the process, 
then

1. this should be clearly documented on the relevant Wiki pages, 
and
2. you should probably expect very few dips and a high rate of 
burnout.

You, W&A, are not the Standards Committee. D is not C++. We do 
not have so large a community that we can select the very best 
and most important of DIPs and still have DIPs be a meaningful 
mechanism for driving the language forward.

If DIPs should be limited to either trivial features or highly 
dedicated, enthusiastic and ascetic developers who can work for 
months to years in radio silence, get a terse rejection and keep 
trucking - saints - then the current course of action is 
appropriate. Frankly, if I worked on a feature for a year and got 
the response that Manu got, I'd fork the project.

But if the point of DIPs is to get moderate changes to the 
language proposed, reviewed, implemented and included - the sort 
of thing where if you go wrong in the beginning, you can spend a 
long time and a lot of effort walking in the wrong direction - 
then there absolutely must be, not equitability, but some amount 
of sane proportion between the effort put in by W&A and the 
effort *not wasted* by the DIP author. It is grossly 
disproportionate that a few lines of feedback can invalidate 
months of work *done within the lines drawn by the process*. That 
is a bad process, and it will not work, and in its failure it 
will drive people away from contributing at all.

It's okay to not have a DIP process. But a broken process that 
absorbs community effort for no gain is a danger to the entire 
project.


More information about the Digitalmars-d mailing list