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).

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.)


T

-- 
One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot

On Thu, 26 Feb 2015 18:13:12 -0800, Jonathan M Davis via Digitalmars-d wrote:

> whereas creating a PR for dmd will sometimes put things in a position where Walter finally approves it (or rejects it) rather than simply discussing it and getting nowhere.

oh, i see. i really enjoy multiple `alias this` now, it's a great merge! and that great new tuple syntax... i love it!

ah, sorry, i was daydreaming.

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

On Friday, 27 February 2015 at 02:58:31 UTC, Andrei Alexandrescu wrote:
> 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?"

Can I ask you a general question about safety: If you became convinced that really great safety would *require* more function attributes, what would be the threshold for including them? I'm trying to "go the whole hog" with safety, but I'm paying what seems to me the necessary price -- more parameter attributes. Some of these gains ("out!" parameters, e.g.) seem like they would only apply to very rare code, and yet they *must* be there, in order for functions to "talk" to each other accurately.

Are you interested in accommodating the rare use cases for the sake of robust safety, or do you just want to stop at the very common use cases ("ref returns", e.g.)? "ref returns" will probably cover more than half of all use cases for memory safety. Each smaller category will require additions to what a function signature can contain (starting with expanding `return` to all reference types, e.g.), while covering a smaller number of actual use cases... but on the other hand, it's precisely because they cover fewer use cases that they will appear so much less often.

On 2/26/2015 6:58 PM, Andrei Alexandrescu wrote:
> 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.

Yeah, that's always a problem. Ideally, how much work someone put into a proposal should have nothing to do with whether it is incorporated or not. But being human, we feel a tug to incorporate something because someone expended much effort on it. It's always much harder to turn them down.

On Friday, 27 February 2015 at 02:46:57 UTC, ketmar wrote:
> On Thu, 26 Feb 2015 18:13:12 -0800, Jonathan M Davis via Digitalmars-d
> wrote:
>
>> whereas creating a PR for dmd will sometimes put things in a position
>> where Walter finally approves it (or rejects it) rather than simply
>> discussing it and getting nowhere.
>
> oh, i see. i really enjoy multiple `alias this` now, it's a great merge!
> and that great new tuple syntax... i love it!
>
> ah, sorry, i was daydreaming.

Didn't multiple alias this get merged? I wasn't even following it.

On Fri, 27 Feb 2015 06:34:40 +0000, weaselcat wrote:

> On Friday, 27 February 2015 at 02:46:57 UTC, ketmar wrote:
>> On Thu, 26 Feb 2015 18:13:12 -0800, Jonathan M Davis via Digitalmars-d wrote:
>>
>>> whereas creating a PR for dmd will sometimes put things in a position where Walter finally approves it (or rejects it) rather than simply discussing it and getting nowhere.
>>
>> oh, i see. i really enjoy multiple `alias this` now, it's a great
>> merge!
>> and that great new tuple syntax... i love it!
>>
>> ah, sorry, i was daydreaming.
> 
> Didn't multiple alias this get merged? I wasn't even following it.

it was blessed and... and then everybody forgot about it.

On Friday, 27 February 2015 at 02:58:31 UTC, Andrei Alexandrescu wrote:
> 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.

Everyone's a Marxist when it comes to their own labour :)

On Thursday, 26 February 2015 at 20:35:04 UTC, deadalnix wrote:
> Yes, I don't care about the specific enum case, in fact, that is one of the least offender and this is why I choose it as an example here.
Hmm. I still consider it a major issue and thought we agreed to
introduce "final enum" to be used with "final switch" - and was
sightly dissapointed that it didn't go in 2.067

How can we make progress, if even the things that have reached
consens on are not promoted?

Same goes for multiple "alias this".

On 2/27/15 1:09 AM, John Colvin wrote:
> On Friday, 27 February 2015 at 02:58:31 UTC, Andrei Alexandrescu wrote:
>> 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.
>
> Everyone's a Marxist when it comes to their own labour :)

Nice! -- Andrei