Disposition: REJECT. A proposal for a similar or identical feature would need to be include qualitatively new motivation/evidence of usefulness.

Please follow the link for the full review text / rationale: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review

On 11/17/2016 06:37 AM, Dicebot wrote:
> Disposition: REJECT. A proposal for a similar or identical feature would
> need to be include qualitatively new motivation/evidence of usefulness.
>
> Please follow the link for the full review text / rationale:
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review

Thanks Dicebot for carrying the process through. I think we need a versioning mechanism for DIPs. In the general case we'll have the disposition "Changes Requested", which will prompt the DIP authors to revise the DIP. The DIP will keep its number but will receive a new revision (either a newer commit or, more likely, an entirely new document). That revision will receive a new, separate review etc. -- Andrei

On 11/17/2016 03:20 PM, Andrei Alexandrescu wrote:
> On 11/17/2016 06:37 AM, Dicebot wrote:
>> Disposition: REJECT. A proposal for a similar or identical feature would need to be include qualitatively new motivation/evidence of usefulness.
>>
>> Please follow the link for the full review text / rationale: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review
> 
> Thanks Dicebot for carrying the process through. I think we need a versioning mechanism for DIPs. In the general case we'll have the disposition "Changes Requested", which will prompt the DIP authors to revise the DIP. The DIP will keep its number but will receive a new revision (either a newer commit or, more likely, an entirely new document). That revision will receive a new, separate review etc. -- Andrei

Don't think I understand the process you have in mind. Right now there are two possible cases for updating DIP:

1) It was rejected and someone wants to submit a drastically different proposal on same topic. This has to come as brand new DIP document with own number.

2) It is a regular update. In that case revision number is simply git history. For example DIP1002 is currently at revision 7 (git log --pretty=oneline DIPs/DIP1002.md | wc -l).

Same goes for update of reviews - everything is tracked in git history. At any given point of time you simply throw away everything old and keep only most recent versions.

Am I missing something in your requirements?

On 11/17/2016 09:16 AM, Dicebot wrote:
> 2) It is a regular update. In that case revision number is simply git
> history. For example DIP1002 is currently at revision 7 (git log
> --pretty=oneline DIPs/DIP1002.md | wc -l).
>
> Same goes for update of reviews - everything is tracked in git history.
> At any given point of time you simply throw away everything old and keep
> only most recent versions.

OK, so we're just using git for versioning, which should work fine. The one potential issue I see with it is the version number is not indicative of how many review cycles have been passed. E.g. DIP1002 is already at revision 7, which is an irrelevant number to the casual reader. "What do you think of DIP2749?" "Which revision you mean?" "Well it's revision 38." "Would that be before or after the third review?" etc.

I'd like to have a simple tag a la DIP2749 v1 for the first review round, DIP2749 v2 for the second review round, and so on. So then people can refer to "DIP2749 v3" in casual conversation. Is this feasible?


Andrei

On Thursday, 17 November 2016 at 11:37:09 UTC, Dicebot wrote:
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review

We do exception tests like this: http://dpaste.com/0EAZQE4

On Thursday, 17 November 2016 at 11:37:09 UTC, Dicebot wrote:
> Disposition: REJECT. A proposal for a similar or identical feature would need to be include qualitatively new motivation/evidence of usefulness.
>
> Please follow the link for the full review text / rationale: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review

Regardless of the outcome, I just want to commend whoever wrote the rejection text* on doing such a clear and comprehensive job. I'm sure it must be disappointing for a DIP author to have it rejected, but detailed, constructive criticism like this would - for me at least - make the experience worthwhile and encourage further contributions of higher quality.

* I see dicebot committed, but I'm presuming Walter &| Andrei had a lot of input and I think i detect recent exposure to the academic review process...

On Thursday, 17 November 2016 at 15:26:21 UTC, John Colvin wrote:
> Regardless of the outcome, I just want to commend whoever wrote the rejection text* on doing such a clear and comprehensive job. I'm sure it must be disappointing for a DIP author to have it rejected, but detailed, constructive criticism like this would - for me at least - make the experience worthwhile and encourage further contributions of higher quality.
>
> * I see dicebot committed, but I'm presuming Walter &| Andrei had a lot of input and I think i detect recent exposure to the academic review process...

The text was sent to me by Andrei, though I presume Walter did take part in making the decision :)

Hopefully such high quality and detailed feedback will provide a much more clear picture about expectations from DIP content and overall chances for various kinds of proposals to be approved.

On 11/17/2016 04:36 PM, Andrei Alexandrescu wrote:
> On 11/17/2016 09:16 AM, Dicebot wrote:
>> 2) It is a regular update. In that case revision number is simply git history. For example DIP1002 is currently at revision 7 (git log --pretty=oneline DIPs/DIP1002.md | wc -l).
>>
>> Same goes for update of reviews - everything is tracked in git history. At any given point of time you simply throw away everything old and keep only most recent versions.
> 
> OK, so we're just using git for versioning, which should work fine. The one potential issue I see with it is the version number is not indicative of how many review cycles have been passed. E.g. DIP1002 is already at revision 7, which is an irrelevant number to the casual reader. "What do you think of DIP2749?" "Which revision you mean?" "Well it's revision 38." "Would that be before or after the third review?" etc.

Hm, my understanding was that there are not supposed to be multiple formal reviews. Either DIP is marked with "Information Requested" and mentions informal checklist of improvements to be done, or it actually undergoes final judgment and there is only way to "Approved" or "Rejected" from there.

If you want to incorporate multiple iterations, some adjustments may indeed be necessary.

> I'd like to have a simple tag a la DIP2749 v1 for the first review round, DIP2749 v2 for the second review round, and so on. So then people can refer to "DIP2749 v3" in casual conversation. Is this feasible?

Yes. Assuming you do want multiple review iterations support, I can imagine something like this:

- new "review candidate #" field is added to the header
- it is set to 0 on initial merge and to 1 after incorporating initial
NG feedback
- it also references specific DIP version hash matching time of
incrementing the version
- changes to DIP are made in a regular manner. When author is done, rc #
is incremented and hash gets updated
- included reviews refer to specific rc #

If that sounds good, I'll make a PR to update README and ping you from there.

On 11/17/2016 10:43 AM, Dicebot wrote:
> Yes. Assuming you do want multiple review iterations support, I can
> imagine something like this:
>
> - new "review candidate #" field is added to the header
> - it is set to 0 on initial merge and to 1 after incorporating initial
> NG feedback
> - it also references specific DIP version hash matching time of
> incrementing the version
> - changes to DIP are made in a regular manner. When author is done, rc #
> is incremented and hash gets updated
> - included reviews refer to specific rc #
>
> If that sounds good, I'll make a PR to update README and ping you from
> there.

Yes, it does sound good. I think in general the "Information Requested" stage may contain one or more hefty reviews and also ask for arbitrarily complex information. So we need to allow submitters the opportunity to submit a distinct version of the same DIP with significant enhancements that is essentially a new document (with its own review!) save for the DIP number. Thanks! -- Andrei

On 11/17/2016 7:30 AM, Dicebot wrote:
> On Thursday, 17 November 2016 at 15:26:21 UTC, John Colvin wrote:
>> Regardless of the outcome, I just want to commend whoever wrote the rejection
>> text* on doing such a clear and comprehensive job. I'm sure it must be
>> disappointing for a DIP author to have it rejected, but detailed, constructive
>> criticism like this would - for me at least - make the experience worthwhile
>> and encourage further contributions of higher quality.
>>
>> * I see dicebot committed, but I'm presuming Walter &| Andrei had a lot of
>> input and I think i detect recent exposure to the academic review process...
>
> The text was sent to me by Andrei, though I presume Walter did take part in
> making the decision :)
>
> Hopefully such high quality and detailed feedback will provide a much more clear
> picture about expectations from DIP content and overall chances for various
> kinds of proposals to be approved.

I too am pleased that Andrei has set the bar pretty high on both the thoughtfulness and care with which a proposal is evaluated.

Although I agree with Andrei on the points raised and conclusions drawn, the wording is all his as is the work put into it.

And a big thanks to Dicebot for putting this review process in place and managing it.