On Friday, 27 February 2015 at 02:58:31 UTC, Andrei Alexandrescu
wrote:
On 2/26/15 6:17 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Feb 26, 2015 at 05:57:53PM -0800, Andrei Alexandrescu
via Digitalmars-d wrote:
On 2/26/15 5:48 PM, Zach the Mystic wrote:
I sometimes feel so bad for Kenji, who has come up with
several
reasonable solutions for longstanding problems, *and*
implemented
them, only to have them be frozen for *years* by indecision
at the
top.
Yah, we need to be quicker with making decisions, even
negative. This
requires collaboration from both sides - people shouldn't get
furious
if their proposal is rejected. Kenji has been incredibly
gracious
about this.
[...]
I don't think people would be furious if they knew from the
beginning
that something would be rejected. At least, most reasonable
people
won't, and I'm assuming that the set of unreasonable people who
contribute major features is rather small (i.e., near
cardinality 0).
Well yes in theory there's no difference between theory and
practice etc. What has happened historically (fortunately not
as much lately) was that statistically most proposals have been
simply Not Good. Statistically, proposal authors have been
Positively Convinced that their proposals were of Obviously
Excellent. (That includes me; statistically most ideas I've
ever had have been utter crap, but seldom seemed like it in the
beginning.) This cycle has happened numerous times. We've
handled that poorly in the past, and we're working on handling
it better.
What *does* make people furious / disillusioned is when they
are led to
believe that their work would be accepted, and then after they
put in
all the effort to implement it, make it mergeable, keep it up
to date
with the moving target of git HEAD, etc., it then gets
summarily
dismissed. Or ignored for months and years, and then suddenly
shot
down. Or worse, get *merged*, only to be reverted later
because the
people who didn't bother giving feedback earlier now show up
and decide
that they don't like the idea after all. (It's a different
story if
post-merge rejection happened because it failed in practice --
I think
reasonable people would accept that. But post-merge rejection
because
of earlier indecision / silence kills morale really quickly.
Don't
expect to attract major contributors if morale is low.)
Yes, getting back on a decision or promise is a failure of
leadership. For example, what happened with [$] was
regrettable. We will do our best to avoid such in the future.
I should add, however, that effort in and by itself does not
warrant approval per se. Labor is a prerequisite of any good
accomplishment, but is not all that's needed.
I'm following with interest the discussion "My Reference Safety
System (DIP???)". Right now it looks like a lot of work - a
long opener, subsequent refinements, good discussion. It also
seems just that - there's work but there's no edge to it yet;
right now a DIP along those ideas is more likely to be rejected
than approved. But I certainly hope something good will come
out of it. What I hope will NOT happen is that people come to
me with a mediocre proposal going, "We've put a lot of Work
into this. Well?"
Andrei
I'm curious if project management(e.g., MS Project) is used to
optimize and clarify goals for the D language?
If such a project was maintained, anyone could download it and
see the current state of D.
The main use being the optimization of tasks and display the
"timeline". If something has been sitting around for a year and
is blocking other tasks then you can easily see that.
It obviously would lot of work to setup such a project. I imagine
you could write some script to import data from github or
whatever into the project and possibly vice versa.
