The DIP Process

[Manu]

On Tue, Feb 26, 2019 at 10:25 AM Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 2/26/19 12:46 PM, Jonathan Marler wrote:
> > I think most points of the DIP process make sense, but it has one very
> > large problem.  Feedback from language maintainers (Walter and Andrei)
> > is not done until the end of the process. You're asking someone to go
> > through a process that can take a year before the people who have the
> > power to accept or reject the proposal look at it or leave any
> > feedback.  This is extremely wasteful of the author's time, the
> > reviewer's time and causes extreme pressure for everyone involved.
>
> This is the case for all relevant submission processes I know of -
> conferences, journals, programming languages. A process of
> shepherding/assistance is not unheard of, but exceptionally rare. I've
> only had direct experience with it in HOPL, which itself is an
> exceptional (and an exceptionally rare) conference. I recall the POPL
> community had something similar. Until we have an army of competent
> reviewers, we can't consider this.
>
> The initial community process is an important step that ensures good
> initial quality of submissions. This is the case for many programming
> language communities. We could definitely do better there, and the DIP
> guidelines could emphasize the importance and the structure of this stage.
>
> The process of revisions is intended to provide a path for proposals to
> evolve from initial submission to approval. Improvements of the
> mechanics and logistics of the revisions would be welcome.
>
> I'm not sure how we can improve this from the top, but I'd love to
> foster more of an esprit de corps on the submitters' side. A DIP can be
> very impactful, but it requires hard work with no guaranteed outcome.
> All of the time and energy spent on contesting the DIP 1016 decision
> should have been at best directed toward improving the proposal. The
> attitude that DIP rejection is not an acceptable outcome and
> consequently needs to be negotiated in forums, that - that must be
> replaced with an attitude that a setback offers a solid ground for a
> better proposal.

It seems like you've missed the point again.

I can't see anything in the process amendments that could have averted
the issues with my DIP.
I'm going to write this once, then I'm not going to post about this anymore.

This is the process as I saw it:

1. The DIP pipeline is long, in the mean time, there were community
reviews, many amendments were made, and objections were eliminated.

2. In contrast to the copy ctor DIP, which I suspect enjoyed A&W's
input the whole way along (demonstrated by the pre-acceptance), which
presumably included true and actionable feedback, it was clearly
stated that there was a deliberate intent to NOT read or consider a
single word in my in-progress DIP at any time prior to final review.
  a. This was iterated more than once.
  b. In theory, this is fine, but we're certainly playing on an
un-level playing-field, and what followed shows the weakness of this
strategy.

3. My DIP was rejected
  a. This is fine, there are valid reasons for this
  b. The rejection text was *completely* unhelpful, and 75% of it was
completely wrong
  c. Despite an incorrect assessment, it was made *very clear* that I
should start again, submit a new one *on the back of the queue*

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.
  a. All the rhetoric supporting the official rejection text was invalidated.
  b. One real issue is that the rewrite didn't support exceptions
    - I submit a PR to correct it, it was merged, and then reverted
because the DIP was final
  c. The second is that the formal review fell off the wagon on
account of one variable name, and used that to build a large fantasy
about what the text intended, which was in conflict to the heading
*immediately above* (and the DIP title, and the brief, and plenty of
points elsewhere)
    - This confusion did not occur at any point during the community review
    - Surely the reviewers must have found the conflict with the title
immediately above odd, and perhaps might have considered seeking
clarification rather than repeatedly insult me about it

5. It is clear my DIP could be reconsidered and interpreted completely
differently with 2 minor and self-contained amendments.
  a. This is the change: `my_short` => `short(10)`
  b. Just yesterday, Andrei re-re-reiterated "copy&paste 75% of the
text, get 75% of the same review", which pisses me off even more,
because I should only have to change one word, and get at least a 75%
*different* review, since that 75% was completely wrong the first
time.

6. No consideration or acceptance that the review was thoroughly
flawed is acknowledged, and despite this realisation, it remains
insisted that I produce a new DIP at the back of the pipeline.

7. The rejection is fine. The process following the rejection was
insulting and deeply unsatisfying.
  a. I think a feature of this is a deference to process; "We rejected
it, so it's rejected, period. Oh, I see that we didn't actually review
what was written because we misunderstood a single word and made up
the rest following that misunderstanding... you could change that word
and we reconsider the actual text, but process says it's rejected, so
you must start again"
  b. Again, you're entitled to stand by a bullshit process, but I
don't want anything to do with it!
  c. It would have saved everyone a lot of time, energy, and good-will
to accept a one-word amendment and then re-consider.


TL;DR, true feedback was that I needed to do one legit self-contained
fix to the rewrite syntax to support exceptions (I made a PR for that
correction), and a *one word* (a trivial variable name) amendment to
have the thing re-read correctly, and I'm not satisfied that I should
have to restart the process on that matter.
It would take me *seconds* to fix and resubmit, but I'm a salty
arsehole, and I'm disenfranchised by the process and stubborn
insistence that because I chose a poor variable name that all my work
was rubbish and I should start over.
That is the official position as still stands right now, no effort has
been made to suggest otherwise (quite the contrary in fact; it has
been double-triple-quadrupled-down on this point that this is the
intended and desirable outcome), and if that's the intended outcome of
the process, then I don't want to participate in something so
unreasonable and unhelpful.


> All of the time and energy spent on contesting the DIP 1016 decision
> should have been at best directed toward improving the proposal.

I never did contest the decision, I contested the reasoning for your
rejection (it was completely wrong) and the way you handled it, and
the refusal to reconsider the DIP with the exception fix and a better
choice of variable name.
It remains insisted that the process is restarted.

> The attitude that DIP rejection is not an acceptable outcome and
> consequently needs to be negotiated in forums, that - that must be
> replaced with an attitude that a setback offers a solid ground for a
> better proposal.

I don't hold that attitude. I *do* hold the attitude that an unfair
review with no opportunity afforded to make a trivial correction is
not a worthwhile outcome.
You were completely bent out of shape over *one variable name*, right
beneath a bold heading that couldn't have made the intended meaning
more clear.
The rewrite to support exceptions proper needs legit fix, but I did
that within a couple of hours of rejection (and the PR was merged,
then reverted).

There's nothing I'm aware I could have done according to the process
where I may have avoided this outcome. I have to accept that a poor
choice of variable name somehow makes a completely incorrect and
unfair "final" review after a couple hundred days in the pipeline just
fine and normal.