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