www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Formal review of DIP1002

reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Formal review of DIP1002

--PRFeaUwmroNpQAru2eXxwVpVupqT7Em4p
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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


--PRFeaUwmroNpQAru2eXxwVpVupqT7Em4p--
Nov 17 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 17 2016
parent reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: DIP document maintenance
References: <o0k4p6$139d$1 digitalmars.com> <o0kar5$2dfl$1 digitalmars.com>
In-Reply-To: <o0kar5$2dfl$1 digitalmars.com>

--QaS0kCcAa5vwaO1x1XKNaXppacxEdXDGQ
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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 wou=
ld
 need to be include qualitatively new motivation/evidence of usefulness=
=2E
 Please follow the link for the full review text / rationale:
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review
=20 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. -- An=
drei 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=3Doneline 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? --QaS0kCcAa5vwaO1x1XKNaXppacxEdXDGQ--
Nov 17 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 17 2016
parent reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: DIP document maintenance
References: <o0k4p6$139d$1 digitalmars.com> <o0kar5$2dfl$1 digitalmars.com>
 <o0ke4h$2j0s$1 digitalmars.com> <o0kf9c$2kvi$1 digitalmars.com>
In-Reply-To: <o0kf9c$2kvi$1 digitalmars.com>

--kPErlS3ctdTpQD2ITGVHJ4bH11RSrsTWx
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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=3Doneline DIPs/DIP1002.md | wc -l).

 Same goes for update of reviews - everything is tracked in git history=
=2E
 At any given point of time you simply throw away everything old and ke=
ep
 only most recent versions.
=20 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?" "Wel=
l
 it's revision 38." "Would that be before or after the third review?" et=
c. 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 peopl=
e
 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. --kPErlS3ctdTpQD2ITGVHJ4bH11RSrsTWx--
Nov 17 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 17 2016
prev sibling next sibling parent Kagamin <spam here.lot> writes:
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
Nov 17 2016
prev sibling next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
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...
Nov 17 2016
parent reply Dicebot <public dicebot.lv> writes:
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.
Nov 17 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 17 2016
prev sibling parent reply pineapple <meapineapple gmail.com> writes:
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
There should be no need for me to repeat the arguments against the DIP process already made by others. I will be submitting no more DIPs or engaging in the process in any way unless and until it is significantly changed.
Nov 18 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/18/16 11:09 AM, pineapple wrote:
 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
There should be no need for me to repeat the arguments against the DIP process already made by others.
You'd actually did us a huge favor if you did. I don't recall any standing requests, so links to past discussions would be helpful. This is a new process and Dicebot, myself, and Walter are very open to suggestions on how to improve it.
 I will be submitting no more DIPs or engaging in the process in any
 way unless and until it is significantly changed.
What could we have done in the particular case of DIP2002 to make things better? Thanks, Andrei
Nov 18 2016
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/18/16 12:10 PM, Andrei Alexandrescu wrote:
 What could we have done in the particular case of DIP2002 to make things
 better?
s/2002/1002/
Nov 18 2016
prev sibling parent Jonathan M Davis via Digitalmars-d-announce writes:
On Friday, November 18, 2016 12:10:53 Andrei Alexandrescu via Digitalmars-d-
announce wrote:
 On 11/18/16 11:09 AM, pineapple wrote:
 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
There should be no need for me to repeat the arguments against the DIP process already made by others.
You'd actually did us a huge favor if you did. I don't recall any standing requests, so links to past discussions would be helpful. This is a new process and Dicebot, myself, and Walter are very open to suggestions on how to improve it.
Yeah. This new process is a direct result of concerns and complaints about the way we've handled DIPs historically and is a huge improvement. All of the complaints that I remember seeing have to do with how DIPs have been handled historically. We can't improve things if we don't know what the problems are. Regardless, I have to say that dicebot really deserves our thanks for getting the DIP process to where it is now. The way it was going, DIPs were almost always simply DOA, because they almost never went beyond the initial newsgroup discussion. Now, we have an actual process that leads to a resolution - even if it's not necessarily the resolution that the person creating the DIP wants. - Jonathan M Davis
Nov 18 2016
prev sibling parent Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: Formal review of DIP1002
References: <o0k4p6$139d$1 digitalmars.com>
 <orkchqmhbwvwrcvoyvrn forum.dlang.org>
In-Reply-To: <orkchqmhbwvwrcvoyvrn forum.dlang.org>

--a5uHktRn8UPdcU5faKiuGXwmwEn6kXu4J
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/18/2016 06:09 PM, pineapple wrote:
 There should be no need for me to repeat the arguments against the DIP
 process already made by others. I will be submitting no more DIPs or
 engaging in the process in any way unless and until it is significantly=
 changed.
There seems to be a recurring misconception that submitting a DIP is somehow doing language developers a service. It is exactly other way around - the whole DIP process is designed to help those who are willing to commit hard and selfless work to get something into language. There is hardy any lack of ideas about language improvements at any time. I consider DIP process to fail when one of specific case happens: there is someone willing to commit but that person doesn't get deserved feedback. That was very clearly said in my explanations of the rationale which got published on dlang blog and yet seems to come as surprise. --a5uHktRn8UPdcU5faKiuGXwmwEn6kXu4J--
Nov 19 2016