On Wednesday, 27 February 2019 at 03:19:53 UTC, James Blachly wrote:
>
> Ultimately, I agree with other commenters that it could be helpful to have feedback from the language maintainers much earlier in the process than at the very end of a potentially long road. Clearly no one can compel Andrei and Walter to provide more of their limited time, but some additional intervention, whether in pre-review, or shepherding of reviews, may go along way toward alleviating the concerns raised recently.

Would it be useful to have 1 more offical review step?

Step 1: The author creates the DIP
Step 2: The author submits the DIP to the DIP manager (community input already implied)

Step 3: The language maintainers perform a *pre-review*

Step 4: The DIP manager informs the author of the feedback
Step 5: The author actions feedback as needed, submits the DIP to the DIP manager
Step 6: Final review

I realise it's an increase of workload for the language maintainers, but the payoff may well be worth it if we can still get engagement from expert D users like Manu etc.

Jordan

On Tuesday, 26 February 2019 at 18:22:09 UTC, Andrei Alexandrescu wrote:
> On 2/26/19 12:46 PM, Jonathan Marler wrote:
>
> I'm not sure how we can improve this from the top,

You can require the same accuracy and rigour from the review as you do from the DIP. Unless you think that yourself and Walter are infallible then the review process is fundamentally flawed. Dip in, one guy reviews, result out, decision final will result in flawed reviews and disillusioned contributors.

On Wednesday, 27 February 2019 at 04:12:31 UTC, Jordan Wilson wrote:
> Would it be useful to have 1 more offical review step?
>
> Step 1: The author creates the DIP
> Step 2: The author submits the DIP to the DIP manager (community input already implied)
>
> Step 3: The language maintainers perform a *pre-review*
>
> Step 4: The DIP manager informs the author of the feedback
> Step 5: The author actions feedback as needed, submits the DIP to the DIP manager
> Step 6: Final review
>
> I realise it's an increase of workload for the language maintainers, but the payoff may well be worth it if we can still get engagement from expert D users like Manu etc.

But that's the main problem, if you watch old DConfs they always said the same thing: "We have a lack of reviewers".

I pretty sure Walter/Andrei work on other things while at the same time trying to managing everything.

So while nobody with knowledge decide to step in to do a "pre-review" I don't think they will do it.

Donald.

On Wednesday, 27 February 2019 at 14:23:56 UTC, Donald wrote:
> So while nobody with knowledge decide to step in to do a "pre-review" I don't think they will do it.

It may help more to have a detailed checklist of

  * things that reviewers should particularly pay attention to
    in order to ensure a quality review

  * hard lines that are likely to result in a proposal being
    rejected, which both authors and reviewers can take into
    account

Right now too many community reviewers are just sharing opinions and preferences without enough reference to the questions that actually make the difference to whether a proposal is viable or not.

On 2/26/19 11:12 PM, Jordan Wilson wrote:
> On Wednesday, 27 February 2019 at 03:19:53 UTC, James Blachly wrote:
>>
>> Ultimately, I agree with other commenters that it could be helpful to have feedback from the language maintainers much earlier in the process than at the very end of a potentially long road. Clearly no one can compel Andrei and Walter to provide more of their limited time, but some additional intervention, whether in pre-review, or shepherding of reviews, may go along way toward alleviating the concerns raised recently.
> 
> Would it be useful to have 1 more offical review step?
> 
> Step 1: The author creates the DIP
> Step 2: The author submits the DIP to the DIP manager (community input already implied)
> 
> Step 3: The language maintainers perform a *pre-review*
> 
> Step 4: The DIP manager informs the author of the feedback
> Step 5: The author actions feedback as needed, submits the DIP to the DIP manager
> Step 6: Final review
> 
> I realise it's an increase of workload for the language maintainers, but the payoff may well be worth it if we can still get engagement from expert D users like Manu etc.

That should already be the case, with a revision loop between steps 3 and 5. Mike, perhaps the iteration and revision system could be emphasized and clarified further in the guidelines.

On Wednesday, 27 February 2019 at 04:12:31 UTC, Jordan Wilson wrote:
>
>
> Step 3: The language maintainers perform a *pre-review*
>

I'll say that personally, and I stress *personally*, I have no problem with this on the surface. It would need to be understood by everyone that if we did implement this step, no feedback from Walter and/or Andrei at this stage would mean approval is guaranteed.

We do have to take into consideration the amount of time it will add to an already lengthy process. Consider that this could potentially add even more work for the author (not to mention the rest of us involved in the process) with no guarantee that the DIP will be accepted. I don't know if that would actually be an improvement.

However, IMO, it would be more fruitful if we could start looking for volunteers to act as "advisers" to DIP authors throughout the process. This could potentially provide more focus on revising the DIP based on technical merit without the pollution of personal opinions, particularly if we could have, say, two or three people doing it. Then by the time it gets to community review it could be in much better shape than it otherwise would have been.

The problem, as always, is getting people to fill the role. The more involvement we require from Walter and Andrei in the process, the less time they have to spend on other tasks that need doing.

On 02/26/2019 11:46 PM, NaN wrote:
> On Tuesday, 26 February 2019 at 18:22:09 UTC, Andrei Alexandrescu wrote:
>> On 2/26/19 12:46 PM, Jonathan Marler wrote:
>>
>> I'm not sure how we can improve this from the top,
>
> You can require the same accuracy and rigour from the review as you do
> from the DIP. Unless you think that yourself and Walter are infallible
> then the review process is fundamentally flawed. Dip in, one guy
> reviews, result out, decision final will result in flawed reviews and
> disillusioned contributors.

Thanks for writing. We are not able, and should not aspire, to provide a review at the same level of accuracy as the DIP. The onus to convince is squarely on the DIP. This is in keeping for all related review processes I know of.

However, this is good pressure for us to produce good DIPs, together with all other proposers.

I understand rejection of a DIP creates frustration, but at a level it needs to be understood by the community that it is a normal and expected part of the process. The cure is improving the quality of DIPs. The main liability in accepting a DIP that is not suitable is it creates precedent for other unsuitable DIP to get in, in a descending spiral of quality.

On 2/26/19 7:06 PM, Joseph Rushton Wakeling wrote:

> 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.)

Sounds to me like the key is the lack of a "For the love of ****, basic common sense shall always prevail over rigid adherence to process!" amendment.

On Wednesday, 27 February 2019 at 23:13:47 UTC, Andrei Alexandrescu wrote:
> On 02/26/2019 11:46 PM, NaN wrote:
>> On Tuesday, 26 February 2019 at 18:22:09 UTC, Andrei Alexandrescu wrote:
>>> On 2/26/19 12:46 PM, Jonathan Marler wrote:
>>>
>>> I'm not sure how we can improve this from the top,
>>
>> You can require the same accuracy and rigour from the review as you do
>> from the DIP. Unless you think that yourself and Walter are infallible
>> then the review process is fundamentally flawed. Dip in, one guy
>> reviews, result out, decision final will result in flawed reviews and
>> disillusioned contributors.
>
> Thanks for writing. We are not able, and should not aspire, to provide a review at the same level of accuracy as the DIP.

No but the review of DIP1016 shows a large gap between the desired accuracy of the DIP and the actual accuracy of the review given.

> The onus to convince is squarely on the DIP. This is in keeping for all related review processes I know of.

A DIP is only as good as the feedback it receives. DIP 1016 had many issues fixed with it throughout its review, the fact that no-one picked up on any issues w.r.t e.g. exceptions is a fault of the community review (Manu doesn't use exceptions and it is unreasonable to expect him to a priori take that into account) and it is a _good thing_ it was discovered in the formal review. The way that it was _handled_ was not good.

> However, this is good pressure for us to produce good DIPs, together with all other proposers.
>
> I understand rejection of a DIP creates frustration, but at a level it needs to be understood by the community that it is a normal and expected part of the process.

For the Nth time: the problem is NOT that the DIP was rejected, but the reasons given and that the way that it was handled. These are symptoms of issues with process.

See also https://forum.dlang.org/post/mailman.7201.1551219386.29801.digitalmars-d@puremagic.com

Please read the whole thing, Manu says it much better than I can.

> The cure is improving the quality of DIPs.

A DIP is only as good as the feedback it receives.

> The main liability in accepting a DIP that is not suitable is it creates precedent for other unsuitable DIP to get in, in a descending spiral of quality.

The main liability in giving unhelpful and wrong reviews is that it pisses everyone off and wastes a whole lot of time (further extended by the length of the entire process).
I'm going to make bloody well sure _that_ doesn't set a precedent.

On Thursday, 28 February 2019 at 02:49:01 UTC, Nick Sabalausky (Abscissa) wrote:
> On 2/26/19 7:06 PM, Joseph Rushton Wakeling wrote:
>
>> 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.)
>
> Sounds to me like the key is the lack of a "For the love of ****, basic common sense shall always prevail over rigid adherence to process!" amendment.

Indeed. A bit of common courtesy would go a long way too.