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:


- 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

is incremented and hash gets updated


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:


 - 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

 is incremented and hash gets updated


 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