On Tuesday, 26 February 2019 at 19:45:40 UTC, James Blachly wrote:
> In my fields (medicine and genomics), it is extremely common that high impact journals offer a pre-review/estimate of suitability to authors prior to submission.

Let's say for example someone ask Andrei/Walter about adding X feature in the language, and they both say it sounds good.

Then the DIP is written and proposed, but unfortunately it has flaws and in the end it's rejected.

So I think that your suggestion will not change much the final result.

The way I see there is a lack of reviewers to take care or participate in the DIP during it's development, so it will only be reviewed at the end.

Now the "proposers" need to understand that it may be rejected, yes it's hard but it can happen.

Finally for what I've saw from the past cases, the reviewers pointed their concerns, and you would expect then that the "proposers" to fix their DIPs.

Donald.

On Tuesday, 26 February 2019 at 20:09:31 UTC, James Blachly wrote:
> I am not at all describing “case reports,” and your thoughtless dismissal of earnest feedback/suggestion really underlines the criticisms others have leveled against you specifically, and perhaps the process generally.

Even if one is talking full blown research papers, though, there is an important difference: if a seriously flawed research paper gets published, whatever the field, it is generally very unlikely that it will have any meaningful consequences.  The infamous exceptions don't exclude the fact that most research papers of any kind, correct or not, vanish with little real impact.

On the other hand when one compares to the process for getting new drugs approved for use (where any mistake can have VERY serious impacts on human health), it's a much longer, more time-consuming and involved process, spanning many years.  Given the fact that a problematic change to the D language or core libraries can cause a lot of pain for established users, the process needed for DIPs is inevitably going to err on the more stringent and inclined to reject side of things.

That's not to say that there isn't some merit in getting earlier feedback from those with veto power, but the trouble is, the real merit of an idea often isn't clear until the hard work has been done, and in any case, it's quite possible that people will react to early rejection by just feeling they need to add more detail and putting the work in on a full DIP in any case.

On 2/26/19 3:09 PM, James Blachly wrote:
> On Tuesday, 26 February 2019 at 19:49:52 UTC, Andrei Alexandrescu wrote:
>> On 2/26/19 2:45 PM, James Blachly wrote:
>>> On Tuesday, 26 February 2019 at 18:22:09 UTC, Andrei Alexandrescu wrote:
>>>> 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.
>>>
>>> In my fields (medicine and genomics), it is extremely common that high impact journals offer a pre-review/estimate of suitability to authors prior to submission.
>>>
>>> For example, one does not typically submit to NEJM or Nature without discussing with an editor first.
>>
>> Yah, I know of the process from my wife. There are quite a few differences between the fields. One is that in medicine a case presentation is in and by itself publishable material, and all the editor needs to do is assess the rarity and relevance of the material.
> 
> I am not at all describing “case reports,” and your thoughtless dismissal of earnest feedback/suggestion really underlines the criticisms others have leveled against you specifically, and perhaps the process generally.

Didn't that escalate a bit quick? You wrote the goings in your field with no further argument as to how the process would be translated to our case. I shared the little insight I had, too, in expectation of more detail. How is one a earnest feedback/suggestion and the other thoughtless dismissal?

On Tue, Feb 26, 2019 at 10:25 AM Andrei Alexandrescu via Digitalmars-d <digitalmars-d@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.

On Tuesday, 26 February 2019 at 17:46:32 UTC, 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.  A years worth of waiting, debate and revision that are now wasted and could have easily been avoided if language maintainers left their feedback early on.  Walter and Andrei should be involved in the process throughout, not just render judgement at the end.

It's worth making a comparison to how new features are incorporated into other languages, such as C++, or Rust, or Fortran, or Haskell.  In every case, it's hard -- years of work trying out different designs, different implementation attempts, balancing costs against benefits.  D is if anything far more flexible than many of its counterparts when it comes to accepting new ideas.

Obviously it's not great if something goes through multiple rounds of feedback and revision only to be rejected at the very end, but sometimes it's only _because_ of those multiple rounds of feedback and revision that a proposal is clear enough to take that kind of decision on it.  Early feedback doesn't help with that.

On the other hand, one can flip the problem on its head: perhaps the problem is less that Walter and Andrei can come in at the end with a rejection, than that things they are going to reject get put in front of them in the first place.  That suggests that either the review process may be ineffective at weeding out problematic proposals, or that DIP authors may be too strongly biased towards revising and resubmitting their proposals rather than withdrawing them when problems are identified.

> In the years I've been here I have found that feedback from anyone other than Walter and Andrei has very little bearing on what Walter and Andrei will think.  The entire community can think an idea is great, but then Walter or Andrei completely reject it.  And the opposite is true as well, I've seen W&A champion an idea that the community generally rejects. Designing a process to ask many people to create and perfect a proposal for a year catered to 2 specific people without any feedback from them is mind-boggling to me.

I'm going to say something comically rude here, but with the serious intent of provoking everyone to reflect a bit.

Which is: have you considered the possibility that Walter and Andrei are the only people who really know what they're talking about, and everyone else is a [expletive] idiot? :-)

Clearly whenever a tiny number of people wield absolute veto power, there is a risk of a certain amount of arbitrariness or preference-of-the-moment-based decision making (or, perhaps more problematically, the perception of such, even when it isn't the case).  But there are very few people in the D community with a breadth and depth of experience to match Walter and Andrei either as individuals or together, so it's hardly surprising that they might regularly perceive the advantages and disadvantages of a course of action differently from the majority.

After all, where subtle technical decisions are concerned, it's highly likely that a small number of domain experts are going to be able to make a better decision than the majority of users.

I'd also question how one establishes that "the entire community can think an idea is great".  We make a big mistake if we assume that the opinion of the self-selecting group of people who post on forums, or are active on GitHub, is representative of the wider D community of often silent users.

In fact, that's the kind of thing it's worth asking both Walter and Andrei: what kinds of demonstrable consensus (and of whom?) do you think might cause you to change your minds about something you would otherwise have vetoed?

> Based on my observations, my guess is that the DIP process was designed to alleviate the amount of work needed from Walter and Andrei, but look what it's produced.

Returning to the point earlier -- perhaps what it has produced is something that is inadequate at reducing the amount of work they have to do.

It's surely nice if we can find ways to reduce the amount of time and effort DIP authors need to put in before getting a clear decision on their work.  But part of the problem here is seeing that time and effort as wasted if a DIP is rejected.

If instead we were to focus on seeing a DIP as a learning experience through which everyone (authors, reviewers, and language maintainers) get a better understanding of what things are possible, what things are practical or useful, and why, then a rejected DIP isn't an adversarial or problematic outcome, or a waste of anyone's time: it's a collaborative effort that established the lack of viability of a particular course of action.  Just as in science or medicine, clearly identifying _negative_ results is not a bad thing -- it's a valuable (and too often undervalued) contribution!

On Tuesday, 26 February 2019 at 22:16:09 UTC, Manu wrote:
> 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*

This seems an important point: what are the avenues of appeal if the decision to reject a DIP is based on problematic reasoning?

It seems very reasonable that rejected DIPs should have one (but only one!) automatic "right of appeal" via which the authors can respond to the rationale for the rejection, and if needed offer potential fixes, and get a reappraisal without having to go all the way back to the beginning of the process.  That should reduce the scope for rejections based on misunderstandings, miscommunications, or trivially fixed flaws, while not overly increasing the decision-makers' burden.

This is much more likely to reduce wasted time or demotivation than early feedback, because most ideas only reveal their merit after thorough investigation -- but it is very frustrating and time consuming to have a well-worked-out idea knocked a long way back when the concerns may be simple to address.

By the way, that's also something that exists in scientific publishing: if the referees have severely misunderstood or mis-assessed a piece of work, it's quite normal to request that the editor seek a fresh opinion.

On Tuesday, 26 February 2019 at 22:16:09 UTC, Manu wrote:
> ...
> 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.

Sorry but I don't buy it. I mean if it would be so simple as you say, like in matter of seconds to fix it, why not just do it?

So you decided that because the way the process is you shouldn't do it?

It think that was a huge mistake of your part. You should have made all the fixes and proposed it again, just to see the aftermath.

Doing this in my opinion would be the way to adjust the process, not just give up.

Donald.

On Tue, Feb 26, 2019 at 3:40 PM Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Tuesday, 26 February 2019 at 22:16:09 UTC, Manu wrote:
> > 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*
>
> This seems an important point: what are the avenues of appeal if the decision to reject a DIP is based on problematic reasoning?
>
> It seems very reasonable that rejected DIPs should have one (but only one!) automatic "right of appeal" via which the authors can respond to the rationale for the rejection, and if needed offer potential fixes, and get a reappraisal without having to go all the way back to the beginning of the process.  That should reduce the scope for rejections based on misunderstandings, miscommunications, or trivially fixed flaws, while not overly increasing the decision-makers' burden.
>
> This is much more likely to reduce wasted time or demotivation than early feedback, because most ideas only reveal their merit after thorough investigation -- but it is very frustrating and time consuming to have a well-worked-out idea knocked a long way back when the concerns may be simple to address.
>
> By the way, that's also something that exists in scientific publishing: if the referees have severely misunderstood or mis-assessed a piece of work, it's quite normal to request that the editor seek a fresh opinion.

Right, I mean, it's also offensive that W&A tried to pacify me by
saying "don't worry, 1018 had a lot of amendments too!", which is
insulting because *they were reviewing and iterating feedback*!
They were involved in that process along the way, to such a degree
that it didn't even need acceptance, it was pre-accepted!
Yet, I didn't even have a single opportunity to present how it was
misread, and then have it reconsidered on amendment of one word!

Anyway, follow-on conversation did eventually reveal action points, but by that point, the process has already self-defeated and I'm grumpy and disengaged at this point. The process was the problem here for me, not the verdict.

On Tuesday, 26 February 2019 at 23:50:12 UTC, Manu wrote:
> Anyway, follow-on conversation did eventually reveal action points, but by that point, the process has already self-defeated and I'm grumpy and disengaged at this point. The process was the problem here for me, not the verdict.

Adding a fast-track revise-and-appeal seems a straightforward process revision.  If that were to be given a trial in this case as a goodwill gesture, do you think it might have a chance of de-grumpifying you?  (Obviously it's not in my hands to offer that, but raising the idea seems useful.)

If I understand right Nicholas Wilson has proposed a process to deal with this at DConf, so no worries if you would rather follow that route.

On Tue, Feb 26, 2019 at 3:45 PM Donald via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Tuesday, 26 February 2019 at 22:16:09 UTC, Manu wrote:
> > ...
> > 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.
>
> Sorry but I don't buy it. I mean if it would be so simple as you say, like in matter of seconds to fix it, why not just do it?

I did, and the amendment was merged, and then it was reverted because
the document was finalised.
I was told to start over, end of story, no more to say.

> So you decided that because the way the process is you shouldn't do it?

Yes, I don't want to participate in that machine.
I am a volunteer spending my free time; I don't want to do something
that makes me upset and angry, I would rather do something that makes
me feel good.

> It think that was a huge mistake of your part. You should have made all the fixes and proposed it again, just to see the aftermath.

I did make the key fix (fix the exception issue), and it was merged,
and then it was reverted.

> Doing this in my opinion would be the way to adjust the process, not just give up.

Bear in mind, this period of the process was also loaded with series of personal insults describing the various ways that I was incompetent on at least 3 different accounts, which really doesn't help keep a level head.

Consider DIP 1080:

W&A: this needs work, fix this
W&A: this needs work, fix this
W&A: this needs work, fix this
W&A: this is great, it's pre-accepted

And DIP 1016:

Others: this needs work, fix this
Others: this needs work, fix this
Others: this seems fine
W&A: I'm confused by this word, eject the whole thing into space,
start again, you're an idiot, this is final, come back 1 year!

Like, this meant to be funny, but it's actually accurate.