On Mon, Mar 04, 2019 at 02:25:01PM -0800, Walter Bright via Digitalmars-d wrote: [...]
> When I was growing up, I noticed something interesting. I was able to recognize people that were less "mature" than I was, but not more "mature".  I could only see my maturation in hindsight. I think it's similar with manners.
[...]

And also with programming languages.  Cf. the Blub paradox:

	http://www.paulgraham.com/avg.html


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs

On 3/4/2019 2:34 PM, Rubn wrote:
> That's doesn't sound like a very good lawyer.

It's the order in which you argue a case to a judge. Judges prefer to rule based on the law, because it's easier. It's much easier to win a case when the law is on your side. It's much harder to argue that justice should override the law.

On Monday, 4 March 2019 at 22:25:01 UTC, Walter Bright wrote:
> On 3/4/2019 5:03 AM, Jonathan Marler wrote:
>> [...]
>
> For starters, "How To Win Friends and Influence People" by Carnegie is a long-standing classic for good reason.
>
> And, "Emily Post's Etiquette".
>
> When I was growing up, I noticed something interesting. I was able to recognize people that were less "mature" than I was, but not more "mature". I could only see my maturation in hindsight. I think it's similar with manners.
>
> 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. I've been working on mine since I first read HTWFaIP as a teenager.

Thanks for the suggestions, I've ordered them and look forward to what I can learn from them.

>
>
>> [...]
>
> Even if you're right about their motives, you'll never resolve it by bringing it out into the open. You'll just make them mad at you.

Well you've got a point there.  I wouldn't say I'm convinced that in most cases if you present it in the right way that you can actually discuss things like that so long as you do it the right way.  But I could be wrong. In any case this is a new perspective I will try to consider in the future, and now I know where you stand on the subject as well.

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.

On Wednesday, 6 March 2019 at 15:48:12 UTC, FeepingCreature wrote:


> highly dedicated, enthusiastic and ascetic developers who can work for months to years in radio silence

> if I worked on a feature for a year
>

> a few lines of feedback can invalidate months of work

I keep seeing variations of this "months of effort" claim. There's simply no such thing. It's more like "months of waiting".

The effort on a DIP is front-loaded. The majority of it goes into getting the initial draft ready for the Draft Review stage. Some DIPs receive more feedback than others in Draft Review, but even those that have long discussions tend to get them out of the way early on, with a little more feedback trickling in now and again while the author waits for me to move the DIP to the next round, but very little revision after the initial couple of weeks or so.

When I do initiate the next phase, I do a couple of editing passes to get the grammar and the language in decent shape and then we do the Community Review. Some DIPs require revision subsequent to the review, some do not. But if there are any, they are relatively minor. Then there's more waiting until the Final Review. Usually, there are no subsequent revisions here. Then the DIP goes to Walter and Andrei.

I'm not trying to minimize the amount of effort involved. Some DIPs do require more work than others. But let's not exaggerate the scale -- the lion's share of the effort is up front. The rest of the time is spent waiting.

As for Walter and Andrei's feedback, I've thought about this quite a bit lately and I really don't think it reasonable to require it up front. Imagine they flat out tell a DIP author in Draft Review that the DIP has zero chance of being approved. The DIP author closes the PR and then we'll never know. Because there was no Community Review, the community lost the opportunity to debate and improve the DIP. There is no chance to change Walter or Andrei's mind. And yes, they have approved a DIP before that they expected to reject.

If, on the other hand, Walter and Andrei provide editorial feedback to strengthen the DIP, this will easily lead to the impression that they are likely to approve it. How does the DIP author feel, then, when they get to the end and it's rejected?

What if we wait and instead ask them for feedback during the Community Review? Now they can see the debate, see the improvements. So... should they reject a bad DIP now? Should they suggest their own improvements? Again, what if they do suggest improvements and then reject the DIP in the end? At this point, why bother with the Final Review or Formal Assessment at all?

I appreciate the sentiment behind the suggestions throughout this thread. The goal is to increase the likelihood of acceptance while giving an early out to DIPs that won't be accepted. I agree we can do more of the former, but not the latter.

The DIP process is long, but it absolutely should be. And anyone going into it needs to understand that up front and that they might not agree with the end result. But again, the majority of the effort goes into the initial draft, so having a long process does not add a significant burden of effort on the DIP author. It may test the author's patience, but that's something else entirely.

A long process also means that people aren't going to submit DIPs willy nilly. There needs to be a substantial amount of thought that goes into one, so the bar should be high. The stages of review are there so that the community can put their collective deliberation into it and try to persuade the author to change/fix/enhance the DIP in one way or another. This isn't always going to produce a DIP that's up to standard, but that doesn't mean rejection. Walter and Andrei have accepted DIPs conditionally and sent them back to the author for modification before, and they likely will again.

So the TL;DR from me is, Walter and Andrei should not be involved in the process until the end. As I suggested before, however, we could absolutely use a couple of people at the beginning who have the background needed to nudge a DIP toward the standard of technical soundness Walter and Andrei are looking for.

My focus is on grammar, vocabulary, that sort of thing. Given a couple of people who have received instruction from Walter and Andrei and with whom I can consult to ensure the DIP is hitting all the right notes at different stages of the review, we can produce higher quality DIPs and hopefully make the process more efficient.

On Wednesday, 6 March 2019 at 18:40:57 UTC, Mike Parker wrote:
> On Wednesday, 6 March 2019 at 15:48:12 UTC, FeepingCreature wrote:
>
>
>> highly dedicated, enthusiastic and ascetic developers who can work for months to years in radio silence
>
>> if I worked on a feature for a year
>>
>
>> a few lines of feedback can invalidate months of work
>
> I keep seeing variations of this "months of effort" claim. There's simply no such thing. It's more like "months of waiting".
>
> The effort on a DIP is front-loaded. The majority of it goes into getting the initial draft ready for the Draft Review stage. Some DIPs receive more feedback than others in Draft Review, but even those that have long discussions tend to get them out of the way early on, with a little more feedback trickling in now and again while the author waits for me to move the DIP to the next round, but very little revision after the initial couple of weeks or so.

I don't think you're giving the proper weight to the amount of time and effort that it takes to go through the DIP process.  We're not just talking the time it takes to write the DIP readme file.  There's the time it takes for everyone that is involved to read it, think about it, discuss it on the forums, research it, create test cases, look at code to see how to implemented it, etc.  Alot of time and effort goes into a DIP that isn't shown in the final readme document, and it takes that time away from many people, not just the author and manager of the DIP.

> As for Walter and Andrei's feedback, I've thought about this quite a bit lately and I really don't think it reasonable to require it up front. Imagine they flat out tell a DIP author in Draft Review that the DIP has zero chance of being approved. The DIP author closes the PR and then we'll never know.

If Walter and Andrei say a DIP has 0% chance of being approved, then we've just saved alot of people alot of time, argument and potentially hurt feelings.  Walter and Andrei aren't required to give a final ruling at this time, but it would be great if they could give feedback like:

    "I'm not sure about this feature, we'll need some good rational and examples to be convinced."

    "I really want this feature in D in some form, let's do some good research to make sure there are no nasty corner cases and that we get a very good implementation".

    "I don't see any path for this particular feature to be accepted."

I think W&A can tell the difference between a poorly written DIP and a poor idea.  If a DIP is poorly written they can say "I think there's a good idea here but the DIP is poorly written".

> there was no Community Review, the community lost the opportunity to debate and improve the DIP. There is no chance to change Walter or Andrei's mind. And yes, they have approved a DIP before that they expected to reject.

You're talking like W&A are children who rush to judgement and can't keep an open mind.  I don't think this is the case, and if it is, we got bigger problems on our hands :) I think they are capable of giving reasonable feedback without unnecessarily rushing to judgment.

>
> If, on the other hand, Walter and Andrei provide editorial feedback to strengthen the DIP, this will easily lead to the impression that they are likely to approve it. How does the DIP author feel, then, when they get to the end and it's rejected?
>

It's all in the way the response is worded.  If they're not sure about the idea yet and are waiting for more research from the community then they can indicate that.

    "Not sure whether or not this feature would be good for D at this time. Would like to see some more rational/research from the community on this one."

> What if we wait and instead ask them for feedback during the Community Review? Now they can see the debate, see the improvements. So... should they reject a bad DIP now? Should they suggest their own improvements? Again, what if they do suggest improvements and then reject the DIP in the end? At this point, why bother with the Final Review or Formal Assessment at all?

Should they reject the DIP now?  It depends on what they think of it. If they know it will never be accepted then yes.  If not, then why would they reject it?

Should they suggest their own improvements?  Of course, why not?  If they still end up rejecting the DIP that's a much better process than if they left no feedback at all during the whole process, and now the DIP will contain more relevant points that matter rather than focusing on things that don't since it wasn't given any guidance.

>
> I appreciate the sentiment behind the suggestions throughout this thread. The goal is to increase the likelihood of acceptance while giving an early out to DIPs that won't be accepted. I agree we can do more of the former, but not the latter.

Increasing acceptance is most certainly 100% NOT the goal. I don't remember anyone saying that. The goal is to leverage the community to vet new features for D.  Our suggestions help with that goal by

1) directing people's efforts towards fruitful endeavors rather than wasting time on pointless ones
2) maintaining a positive community by showing we value people's time by taking our own time to leave feedback and give direction

>
> A long process also means that people aren't going to submit DIPs willy nilly. There needs to be a substantial amount of thought that goes into one, so the bar should be high. The stages of review are there so that the community can put their collective deliberation into it and try to persuade the author to change/fix/enhance the DIP in one way or another. This isn't always going to produce a DIP that's up to standard, but that doesn't mean rejection. Walter and Andrei have accepted DIPs conditionally and sent them back to the author for modification before, and they likely will again.

I keep hearing these rules and justifications like

    A long process also means that people aren't going to submit
    DIPs willy nilly

It's true that people are detured from things if they take longer, but that's not justification to implement such a rule. They would also be detured if they had to hand out their social security number and perform a double-backflip on the trampoline before they could submit a DIP :)  Instead, we should let the process evolve naturally and only intervene with rules when problems occur, and even then, creating a new rule should be a last resort since it's very hard to write a rule that is good in all cases.

>
> So the TL;DR from me is, Walter and Andrei should not be involved in the process until the end. As I suggested before, however, we could absolutely use a couple of people at the beginning who have the background needed to nudge a DIP toward the standard of technical soundness Walter and Andrei are looking for.
>
> My focus is on grammar, vocabulary, that sort of thing. Given a couple of people who have received instruction from Walter and Andrei and with whom I can consult to ensure the DIP is hitting all the right notes at different stages of the review, we can produce higher quality DIPs and hopefully make the process more efficient.

Though I see your reasoning I think you can see from my responses that I very much disagree with your conclusion.  What we're saying is, at the very minimum, there should not be a rule to exclude Walter and Andrei till the end.  You provided one example where them leaving feedback early on would cause a DIP to fail.  This is exactly what we want.  We don't want to waste people's time if Walter and Andrei already know they're going to reject the DIP.  In the case where they don't know whether or not it will succeed, then you're example doesn't apply since Walter and Andrei wouldn't leave feedback indicating the DIP is Dead on Arrival.

As to whether Walter and Andrei should be required to leave feedback, I would argue "yes" but I know that's a more radical change to the current process.  However, I strongly believe they shouldn't be pushed out of the process until the end.  Each DIP will be unique, let each one be handled in the proper way.  If W&A think a DIP is viable and want to wait for community feedback and revision that's fine.  If they have suggestions/guidance for it, even better.  If they know it's a waste of time, then I recommend they say something and point the author towards better endeavors.

On Wednesday, 6 March 2019 at 19:54:23 UTC, Jonathan Marler wrote:
>
> As to whether Walter and Andrei should be required to leave feedback, I would argue "yes" but I know that's a more radical change to the current process.  However, I strongly believe they shouldn't be pushed out of the process until the end.  Each DIP will be unique, let each one be handled in the proper way.  If W&A think a DIP is viable and want to wait for community feedback and revision that's fine.  If they have suggestions/guidance for it, even better.  If they know it's a waste of time, then I recommend they say something and point the author towards better endeavors.

+1

On Wednesday, 6 March 2019 at 18:40:57 UTC, Mike Parker wrote:
> the lion's share of the effort is up front. The rest of the time is spent waiting.

1. You missed the vast amount of political effort required to get to the bottom of why it was rejected.

> As for Walter and Andrei's feedback, I've thought about this quite a bit lately and I really don't think it reasonable to require it up front. Imagine they flat out tell a DIP author in Draft Review that the DIP has zero chance of being approved. The DIP author closes the PR and then we'll never know.

Not quite that harshly, but https://github.com/dlang/DIPs/pull/101#issuecomment-414803648 ...

> Because there was no Community Review, the community lost the opportunity to debate and improve the DIP.

Not entirely, there is still draft review.

> There is no chance to change Walter or Andrei's mind.

...the author agreed to withdraw it.

> And yes, they have approved a DIP before that they expected to reject.

Out of curiosity, which one?

> If, on the other hand, Walter and Andrei provide editorial feedback to strengthen the DIP, this will easily lead to the impression that they are likely to approve it.

You should it imply that? If they see a problem or a direction they fell the DIP should go in

> How does the DIP author feel, then, when they get to the end and it's rejected?

That depends entirely on _why_ is was rejected. In the case of 1015 or 1016, disappointed would be an understatement, although for different reasons.

> What if we wait and instead ask them for feedback during the Community Review? Now they can see the debate, see the improvements. So... should they reject a bad DIP now?

If the DIP is beyond salvaging, or the author has failed to fix any problems previously identified *chough* 1017 *cough*.

> Should they suggest their own improvements?

Yes!

> Again, what if they do suggest improvements and then reject the DIP in the end?

Then they will have their reasons, and those reasons will be available for all to see (and possibly ridiculed if they are completely wrong (e.g. 1015/16), and rightly so).

> At this point, why bother with the Final Review or Formal Assessment at all?

It may pick up something the community has missed.

> I appreciate the sentiment behind the suggestions throughout this thread. The goal is to increase the likelihood of acceptance while giving an early out to DIPs that won't be accepted. I agree we can do more of the former, but not the latter.

2. It should be a trivial effort for W&A to answer:
at the end of the draft stage, reading _just_ the title and the abstract, "If this thing is well specified something we _think_ would benefit from having in the language?"
at the end of community: is this well specified? Has the answer above changed? What issues that have been identified, must be resolved?

> The DIP process is long, but it absolutely should be.

No, it should be thorough. One of the sections of the DConf foundation meeting is to provide a platform for rigorous review and feedback to cut down the amount of time it takes.

> And anyone going into it needs to understand that up front and that they might not agree with the end result. But again, the majority of the effort goes into the initial draft, so having a long process does not add a significant burden of effort on the DIP author. It may test the author's patience, but that's something else entirely.

See point 1.

> A long process also means that people aren't going to submit DIPs willy nilly.

s/long/thorough

>There needs to be a substantial amount of
> thought that goes into one, so the bar should be high. The stages of review are there so that the community can put their collective deliberation into it and try to persuade the author to change/fix/enhance the DIP in one way or another. This isn't always going to produce a DIP that's up to standard, but that doesn't mean rejection.

Unfortunately just because a DIP is up to standard and the community endorses it, doesn't mean that it will be accepted, see 1015.

> Walter and Andrei have accepted DIPs conditionally and sent them back to the author for modification before, and they likely will again.
>
> So the TL;DR from me is, Walter and Andrei should not be involved in the process until the end.

I couldn't disagree more. Their involvement means we can avoid process errors like:
1015 (wrong outcome)
1016 (poor handling of the response)
1017 (everything, but principally wasting time reviewing a DIP that contains all of its flaws)
1018 @implicit, ideally they would have taken the hint a bit sooner but they eventually fixed it, which is was matters, even it if detracted from the review.

> As I suggested before, however, we could absolutely use a couple of people at the beginning who have the background needed to nudge a DIP toward the standard of technical soundness Walter and Andrei are looking for.

Thats all well and good, but as long as W&A are the ones that have the final say, it is them who need to answer point 2.

On 02.03.19 07:15, Elronnd wrote:
> On Friday, 1 March 2019 at 21:23:10 UTC, Walter Bright wrote:
>> On a final note it doesn't matter to the DIP approval process how hard anyone works on the proposal, or how much time they spent on it, etc. Only results matter. By the same token, I don't expect anyone to care how much time I spend on D, I don't expect anyone to use D because people worked hard on it, etc. The only thing that matters is how good D is.
>>
>> It's a bit like the Olympics. Nobody cares how hard/long an athlete trained. Only that they win. Who would want it any other way?
> 
> Oh come on.  This comparison makes no sense, the olympics are nothing like a programming language.

It's an analogy. The point was merely that results matter, not effort.

On Thursday, 7 March 2019 at 02:33:11 UTC, Timon Gehr wrote:
>>> It's a bit like the Olympics. Nobody cares how hard/long an athlete trained. Only that they win. Who would want it any other way?
>> 
>> Oh come on.  This comparison makes no sense, the olympics are nothing like a programming language.
>
> It's an analogy. The point was merely that results matter, not effort.

Community-building matters.  If you don't provide positive feedback to other people who are putting great effort to help your project, they are unlikely to continue putting effort into your project.