Contradictory justification for status quo

[Sativa via Digitalmars-d]

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.