The DIP Process

[Manu]

On Thu, Feb 28, 2019 at 4:30 PM Olivier FAURE via Digitalmars-d
<digitalmars-d at 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.