On 2/28/2019 9:04 PM, Nick Sabalausky (Abscissa) wrote:
> Could someone point me to some of these attempts/examples? I'm curious to take a look at them.


https://digitalmars.com/d/archives/digitalmars/D/announce/DIP_1016--ref_T_accepts_r-values--Formal_Assessment_54145.html

Just look for my posts.

On Thursday, 28 February 2019 at 23:17:15 UTC, Olivier FAURE wrote:
>.
>
> If that's the direction you're going for, then the rejection rationale needs to be a little more polished than DIP-1016's was.
>

That's mostly on me. I take the informal feedback they give and craft the summary. I've committed to providing more detailed review summaries in the future and they've committed to helping me do so.

On Friday, 1 March 2019 at 05:24:25 UTC, Nick Sabalausky (Abscissa) wrote:
> See? This is what happens when you introduce bureaucracy/red-tape to problems. You get the same problems, just with much slower progress.

Bureaucracy is arguable unavoidable.  At this kind of scale (really, more than 5-10 people or so), what we need is _maximally efficient_ bureaucracy.  We can't get rid of the cruft, the arbitrariness, the red tape, only replace it with new cruft that's hopefully smaller.  The solution space is constrained to bureaucratic solutions


> The test suite is going to do a ****FAAAAARRRR**** better job of rooting out technical problems than five years of human-review.

This requires a disproportionate amount of work to implement the DIP, which is wasted if the DIP is not accepted.  Not to mention, it raises the barrier of entry to a would-be DIP author -- now, you have to know or learn compiler internals too!

On 3/1/19 2:02 AM, Elronnd wrote:
> On Friday, 1 March 2019 at 05:24:25 UTC, Nick Sabalausky (Abscissa) wrote:
>> The test suite is going to do a ****FAAAAARRRR**** better job of rooting out technical problems than five years of human-review.
> 
> This requires a disproportionate amount of work to implement the DIP, which is wasted if the DIP is not accepted.  Not to mention, it raises the barrier of entry to a would-be DIP author -- now, you have to know or learn compiler internals too!

Chicken vs egg... :(

On Thu, Feb 28, 2019 at 4:30 PM Olivier FAURE via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Tuesday, 26 February 2019 at 22:16:09 UTC, Manu wrote:
> > 4. Off the back of extensive discussion while trying to dig out
> > details, while also being insulted, it was concluded that there
> > are 2
> > minor and self-contained issues.
>
> We strongly disagree on this one.
>
> Your opinion is, explicitly, that the only criticisms of the DIP were about the lack of exception support and the "ref to implicit cast" issue (your "bad choice of variable name"), and that the DIP would have been accepted if not for them.

No, I'm saying those 2 trivial issues are things that we KNOW blocked
acceptance.
Any further critical issues that blocked acceptance are unknown, and I
have no path to address them. The point is, as it rested, the DIP is
left in the dark in terms of how to move forward.
I made the point: "I amend those things, and then what? We wait a year
and find out what the actual issue is?"

The feedback does not address any critical issues with the DIP that if resolved, would move it forwards. The only take-away value that I learned from the rejection was that I'm an idiot, and someone competent should do this instead. There's nothing actionable there past small self-contained fixes, which I did submit a PR for, which was reverted.

> You especially
> insist on the "one word" part, and seem pretty confident that
> this word completely changed the final result.

No, I'm being misunderstood over and over again.
I'm saying that if I changed that word, it would affect **the
rejection text**, that is, in order to reject the DIP, they would have
had to write something more useful, instead of rejecting it on the
basis of something which took minutes to amend.
If there was a revision cycle where the blindingly obvious issues
could have been amended, then the rejection would necessarily have had
to have been something worthwhile instead.

> This is *not* what W&A have said. In that, they have said, multiple times, that these problems were *symptoms* of the lack of polish of the proposal, and that the DIP couldn't be accepted until that lack of polish was corrected.

But that's entirely vague.
"Language Maintainers found other issues with the proposal, most of
which may have been remedied through simple revision"
I don't know what to do with that. I don't feel that way, it seems
pretty straight forward to me.
I had to spawn a chaotic thread where I got insulted a lot while
trying to convince people it didn't say what they thought it said
before I was able to reveal anything useful. And useful feedback did
indeed exist, but it was hard to dig out, and it certainly isn't
written anywhere near the rejection text. It's effectively lost if
anyone does want to understand why the DIP was rejected.

> > So if we rejected the DIP, we didn't do so on account of one word that can be so easily changed; we did so on account of a DIP that as a whole failed to clarify what it purports to do (and equally importantly, to not do).

The DIP does what it purports to do and it's exactly the thing I want
as far as I can tell... so I don't know how to correct that without
actionable feedback.
In terms of process (which is on discussion here), that whole
follow-up thread is what's wrong. As Walter finally made clear in his
last post here, the rejection text SHOULD contain details on how to
move forward.
The process shouldn't require a follow-up thread like that one to
discover details that are actionable, and more than simple
revision-worthy changes.

On Friday, 1 March 2019 at 05:04:05 UTC, Nick Sabalausky (Abscissa) wrote:
> (Disclaimer: No intention of being contentious here, just a genuine question) Could someone point me to some of these attempts/examples? I'm curious to take a look at them.

I think he's referring to these posts:
- https://forum.dlang.org/post/q2vr50$1lga$1@digitalmars.com
- https://forum.dlang.org/post/q2ubds$1r6e$1@digitalmars.com
- https://forum.dlang.org/post/q2rfug$7af$1@digitalmars.com

On Tuesday, 26 February 2019 at 11:28:56 UTC, Mike Parker wrote:
> * I will no longer simply *ask* DIP authors to respond to feedback in the review threads, I will *require* it. Note that this does not mean I will require the author to make any revisions, nor does it mean that I will pull the DIP if the opinions of the proposal are overwhelmingly negative.

Exactly how it should be, in my opinion. This is a step forward.

On Friday, 1 March 2019 at 05:24:25 UTC, Nick Sabalausky (Abscissa) wrote:
> My take on all this (not that it counts for anything):
>
> See? This is what happens when you introduce bureaucracy/red-tape to problems. You get the same problems, just with much slower progress.
>
> Frankly, I think we already have far better mechanisms that anything a supposedly-improved DIP process could ever provide: Github reviews and CI tests.
>
> Looking at DIP1016 in particular:
>
> 1. Using the same Github code review process we already use to get things done instead of this "The DIP Process" contrivance would have allowed the DIP the flexibility necessary to receive W&A feedback sooner AND respond to such feedback without the "Too bad, go back to start, try again" formality-for-the-sake-of-formality worthlessness.
>
> 2. The test suite is going to do a ****FAAAAARRRR**** better job of rooting out technical problems than five years of human-review. Does anyone seriously think it *wouldn't* have caught the issues with 1016 right away? And even if so, does that say more about the DIP process, or does it say more about the test suite?

I completely agree with this.  Languages are very hard and the DIP process has been put in place as a result.  Walter and Andrei want to be sure that any language changes we make going forward are thoroughly researched and vetted.  The DIP process was put in place so they could leverage the community's efforts rather than having to do all the work themselves and leverage the large experience/viewpoint pool that comes with large group. However, the process itself has sorely missed the mark in achieving this.

For some reason, someone decided that rather than having the entire community work together on a DIP, it should be everyone except Walter and Andrei.  So now the original goal of

  "Let's research and vet a new proposal as a community to see if it's good for D"

Has now become:

  "Go spend a year writing a proposal for your idea to convince Walter and Andrei that your proposal is a good idea. And do all this without any feedback from them during this time.  Then at the end, they'll look over the proposal and either accept it or reject it, maybe they'll give you some good feedback, maybe they won't.  Oh and if they don't accept it, you'll need to start the whole process over again.  And if they give bad feedback, too bad, the process doesn't account for this or give you any recourse and we MUST FOLLOW THE PROCESS TO THE LETTER.  Why? Well...because it's the process."

Now I'm not saying that processes are all inherently bad.  They are an attempt to provide a set of rules to facilitate a final goal.  Processes become a hindrance when people start to rigidly adhere to them no matter what, and they forget the original goal of why the process was created in the first place.  The DIP process is now suffering from the "rigid adherence" problem but also has a second problem.  The DIP process as it's designed is horribly flawed because it has left out the 2 most important people in the community in most of the process.

To fix this we need to fix the process, and also fix people's mindsets.  Keep the original goal in mind.  When the process contradicts the original goal don't just adhere to the process anyway, feel free to break it.  And lastly, fix the process.  Don't write Walter and Andrei out until the end.  The communities efforts will be much more effective if they are guided by its leaders rather than forcing them to go in a direction for an entire year that may be completely in the wrong direction.

When I get involved early in the DIP process, what happens is the author quits and leaves it to me to finish, which usually means doing 98% of the work.

Most proposals to improve process with D revolve around asking myself and Andrei to do most of the work. It just doesn't scale.

The point of the DIP process is to mobilize the community to do the work, demand a high standard, and vet the work.

As mentioned before, this has been successful in the C++ community in that the standard of proposals has steadily risen. I've spoken with Mike Parker about picking out a couple of approved DIPs to be presented as a "gold standard" on how to do a DIP. We expect to replace them with better ones over time, to keep on raising the bar on quality.

Having such examples makes it much easier to review a DIP and bounce it back as "not good enough".

---

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?

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.

Oh Walter, this is soo plain wrong! I adopted D in my company, more than 15 years ago, exactly for the opposite reason...

/P