www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The DIP Process

reply Mike Parker <aldacron gmail.com> writes:
Given the nature of the feedback on the DIP process lately, I 
thought it prudent to explain how I, as DIP manager, view things.

The core of the process looks like this:

Step 1: The author creates the DIP
Step 2: The author submits the DIP to the DIP manager
Step 3: The language maintainers review the DIP
Step 4: The DIP manager informs the author of the verdict

That's what the heart of the process is, an interaction between 
the DIP author and Walter & Andrei, facilitated by me.

Every language has a process for improvement proposals. At their 
core, they are all the same, even if they have different ways for 
getting there. Take a look at the documenetation for Python 
Enhancement Proposals:

https://www.python.org/dev/peps/pep-0001/#start-with-an-idea-for-python

The core of the process is the same. What they add to it is this:

"The PEP champion (a.k.a. Author) should first attempt to 
ascertain whether the idea is PEP-able. Posting to the 
comp.lang.python newsgroup (a.k.a. python-list python.org mailing 
list) or the python-ideas python.org mailing list is the best way 
to go about this.

Vetting an idea publicly before going as far as writing a PEP is 
meant to save the potential author time. Many ideas have been 
brought forward for changing Python that have been rejected for 
various reasons. Asking the Python community first if an idea is 
original helps prevent too much time being spent on something 
that is guaranteed to be rejected based on prior discussions 
(searching the internet does not always do the trick). It also 
helps to make sure the idea is applicable to the entire community 
and not just the author. Just because an idea sounds good to the 
author does not mean it will work for most people in most areas 
where Python is used."

TL;DR, they require the author to ask the community if the 
concept of the proposal is something that should be put through 
their process.

Look around at other languages and you will find a number of 
variations on the core process, all involving some form of 
community feedback.

In our process, we take the community feedback as a review of the 
written proposal. We have implemented multiple feedback rounds to 
get this done. The purpose here is *not* to allow the community 
to preliminarily approve a proposal, or to vote on it. The 
decision to accept or reject rests squarely with Walter and 
Andrei. The purpose of the Community Reviews is to reduce the 
burden on the author of crafting a proposal that will meet Walter 
and Andrei's standards.

The people who visit participate in DIP reviews do not represent 
a small fraction of the D user base, but their backgrounds are 
diverse enough that there are strong odds of receiving valuable 
feedback.

The Community Review rounds help the DIP author sound out the 
proposal, or kick the tires if you will. Reviewers are free to 
leave their opinions of the proposed feature, the details of the 
proposal, to identify structural flaws or other opportunities for 
enhancement, etc. If the author makes significant revisions, I 
will almost certainly call for another round of Community Review 
based on how signficant I judge the revisions to be.

In the Final Review round, the emphasis is on helping the DIP 
author identify structural issues. Anything overlooked in 
previous rounds or introduced as a result of any revisions along 
the way. We aren't interested in personal opinions at this point.

The keywords in both the previous paragraphs are "help/helping 
the DIP author".

In the end, it is entirely up to the DIP author to accept or 
reject any or all of the feedback provided in any community 
review round. It is not up to me, as DIP manager, to block a DIP 
from progressing if the author chooses to make no revisions. I 
always ask the DIP manager to respond to feedback in the review 
thread as far as explaining why a set of related criticisms will 
result in a revision or none at all, but I do not require the 
author to actually make revisions. I am not the final arbiter of 
what does or does not constitute a solid proposal. So I see any 
complaints that a DIP "should not have progressed out of 
Draft/Community review" as missing the point.

My experience with the process has both evolved my understanding 
of it and helped me identify flaws. Early on, I did not see the 
process quite as I describe it above. I mismanaged a couple of 
DIPs (specifically 1006 and 1011) and that led to an overhaul of 
both my understanding and the process document. I looked at how 
other languages handle their processes and revised Dicebot's 
initial work with a goal of preventing my initial mistakes and 
and clarifying the purpose of each review round.

I'm still open to revising the process. We want a process that 
helps us produce the best DIPs we can so that Andrei and Walter 
have all the information they need to render their verdict. But 
any revisions to the process *must not* lose sight of these two 
basic facts:

* the burden of producing the proposal lies with the author
* the burden of reviewing the proposal lies with Walter and Andrei

Any process in between should be aimed at helping to reduce the 
burden for either party. I'm already going to implement two 
changes in my part of the process based on lessons I've learned 
through recent reviews:

* I will no longer simply *ask* DIP authors to respond to 
feedback in the review threads, I will *require* it. Note that 
this does not mean I will require the author to make any 
revisions, nor does it mean that I will pull the DIP if the 
opinions of the proposal are overwhelmingly negative. Again, 
that's not my role. It means the author must leave responses to 
feedback in the thread agreeing or disagreeing with each unique 
criticism and the decision to proceed lies entirely with the 
author. That includes Walter and Andrei if either of them are the 
sole author of a DIP. Previously, I didn't even ask them to 
respond as they are the ones rendering the final verdict anyway, 
but I now recognize it's important that all DIP authors express 
their opinions of the feedback they receive.

* I will do my best to provide more detailed summaries of the 
Formal Assessment. Walter and Andrei tend to deliver their 
opinions of a proposal informally, either tersely or over a long 
email discussion. I do my best to summarize their thoughts at the 
bottom of the DIP. After the response to the review of DIP 1016, 
I discussed with Walter and Andrei how I can provide more 
detailed summaries and we will work to make that happen going 
forward.

Again, we're all open to suggestions on how to improve the 
process, so feel free to leave feedback here or email me directly.

Thanks!
Feb 26 2019
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
Something we could do differently is to create a list of actionable 
items that should occur before the next review.

Each item should be kept pretty loose and open. So that the item doesn't 
dictate what the DIP author should do with it.

As a wiki article anybody could add items. For the purpose of being heard.

It would effectively be a to do list. Which might eliminate quite a bit 
of concern from the community at large over issues being ignored 
(potentially unknowingly).

I am concerned about how much work it could add to people's roles. But 
perhaps we can make it more of a community lead thing? To get others 
involved in the DIP process more.
Feb 26 2019
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 26 February 2019 at 11:28:56 UTC, Mike Parker wrote:

 I'm still open to revising the process.


Good I'm sure that people will have plenty of things to say at 
Dconf/the foundation meeting at dconf


 * I will no longer simply *ask* DIP authors to respond to 
 feedback in the review threads, I will *require* it.


Good, that strikes one item off the dconf foundation meeting 
agenda.


 Note that this does not mean I will require the author to make 
 any revisions, nor does it mean that I will pull the DIP if the 
 opinions of the proposal are overwhelmingly negative. Again, 
 that's not my role. It means the author must leave responses to 
 feedback in the thread agreeing or disagreeing with each unique 
 criticism and the decision to proceed lies entirely with the 
 author. That includes Walter and Andrei if either of them are 
 the sole author of a DIP. Previously, I didn't even ask them to 
 respond as they are the ones rendering the final verdict 
 anyway, but I now recognize it's important that all DIP authors 
 express their opinions of the feedback they receive.


Good.


 * I will do my best to provide more detailed summaries of the 
 Formal Assessment. Walter and Andrei tend to deliver their 
 opinions of a proposal informally, either tersely or over a 
 long email discussion. I do my best to summarize their thoughts 
 at the bottom of the DIP. After the response to the review of 
 DIP 1016, I discussed with Walter and Andrei how I can provide 
 more detailed summaries and we will work to make that happen 
 going forward.


Thanks!
Feb 26 2019
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
“The people who visit participate in DIP reviews do not represent 
a small fraction of the D user base” => The people who 
participate in DIP reviews represent a small fraction of the D 
user base

“I always ask the DIP manager to respond to feedback” => I always 
ask the DIP author to respond to feedback
Feb 26 2019
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 26 February 2019 at 11:28:56 UTC, Mike Parker wrote:


 Again, we're all open to suggestions on how to improve the 
 process, so feel free to leave feedback here or email me 
 directly.


One thing I should add regarding this bit of the procedure:

"the DIP Manager or the Language Maintainers may allow for 
exceptions which waive requirements or responsibilities at their 
discretion"

I don't see anything inherently unfair in this. And I think 
allowing such flexibility is necessary for a healthy process. 
That said, it's not an option intended to be used frequently.

DIP 1010 (static foreach) was fast-tracked through each stage of 
the process, but before 1018, no part of the process was skipped 
for any DIP.

In this case, Walter and Andrei were both heavily involved in the 
drafting of the DIP and in the review of the implementation:

https://github.com/dlang/dmd/pull/8688

The DIP went through extensive Draft review:

https://github.com/dlang/DIPs/pull/129

And as far as I can see there were no major structural 
deficiencies identified in the community review:

https://forum.dlang.org/post/eoqddfqbjtgfydajozsn forum.dlang.org

Given that the purpose of the intermediate review rounds is 
intended to improve the odds the DIP will meet the standards of 
Walter and Andrei, that both were involved in the development of 
the DIP and its implementation, and that they see it as an 
important feature that they'd like to ship ASAP, the decision to 
skip the Final Review shouldn't be controversial.

All DIPs are subject to that possibility of any part of the 
process being skipped or abbreviated, so there's nothing 
inherently unfair that it happened here. Especially considering 
that Andre and Walter felt the DIP was already at a stage where 
they could accept it.

So I won't be removing the quoted line from the procedure 
document. What I can do is say that Walter and Andrei have had 
enough respect for the process that they have never 
demanded/ordered/required me to fast-track or skip a review 
round. In this case, they asked me if it was possible to do. 
Given the circumstances I've described, I saw no harm in it, 
especially given their timeline. If I had recommended we not do 
it and provided a rational reason, I'm confident we would have 
had a final review round.

Again, this is something that should be rare, but when the 
circumstances warrant it, it shouldn't be prohibited.
Feb 26 2019
prev sibling next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Tuesday, 26 February 2019 at 11:28:56 UTC, Mike Parker wrote:

 Again, we're all open to suggestions on how to improve the 
 process, so feel free to leave feedback here or email me 
 directly.

 Thanks!


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.

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.

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.

To Walter and Andrei:

The amount of decision-making power you hold needs to be matched 
by the amount of involvement you have in the process.  There's no 
such thing as a free lunch, you can't just punt the work to 
everyone else for so long and then expect everything to work out 
great when all that work is completely rejected.  This is a gross 
misuse of people's time and a good way to foster a hostile 
community. When you leave early feedback, you're likely to trade 
a years worth of debate and revision between many people for a 
few minutes of your time.

Since you asked for suggestions, here's how I would revise the 
process:

Step 1: Research your proposal, search through the forums/DIP 
repo/github/Google
Step 2: Create a forum post with your proposal,  Walter or Andrei 
is required to either accept or reject whether the proposal 
warrants the effort to formalize it.
Step 3: If formalization is accepted, the author does so

We are now at Step 1 of the current DIP process.  I would then 
follow the current process as it exists with the modification 
that Walter and Andrei be involved throughout.  DIPs should be a 
document that contains the research and results of a proposal 
that includes feedback from the entire community, including 
Walter and Andrei. Seeing it as a document created by the 
community to be presented to Walter and Andrei with no feedback 
from them results in the problems I discussed above.
Feb 26 2019
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.
Feb 26 2019
next sibling parent reply James Blachly <james.blachly gmail.com> writes:
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.


 Until we have an army of competent reviewers, we can't consider 
 this.


Extending this analogy, these reviews are typically done by 
associate editor.
Feb 26 2019
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.
Feb 26 2019
parent reply James Blachly <james.blachly gmail.com> writes:
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.
Feb 26 2019
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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.
Feb 26 2019
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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?
Feb 26 2019
parent reply James Blachly <james.blachly gmail.com> writes:
On 2/26/19 5:09 PM, Andrei Alexandrescu wrote:

 On 2/26/19 3:09 PM, James Blachly wrote:

 On Tuesday, 26 February 2019 at 19:49:52 UTC, Andrei Alexandrescu wrote:

 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?


I acknowledge and apologize. I misinterpreted your terseness as tacit 
dismissal based on a preformed negative impression without getting to 
know you personally. Mea culpa.

To return to the analogy, from the perspective of an outsider [to the 
DIP process], the scientific article (I am speaking here of 
hypothesis-driven research) submission/peer referee process and the DIP 
submission/revision process appear quite similar, as you pointed out.

To clarify further, rejection after review and possibly multiple rounds 
of revision is a disappointing, but expected outcome. In this sense it 
is like the DIP process and I believe even Manu has said that this is an 
acceptable outcome, so long as the review was fair.

Upthread, J. Marler made the suggestion that a suitable authority or 
designee may be able to provide a "pre-review". This is indeed common in 
biomedicine: a journal's associate editor may provide an estimate of 
suitability of the study in question, before the manuscript is formatted 
to the journal's specific requirements or before final supplementary 
experiments and figures are compiled. If one is lucky, some general 
guidance about suggested experiments that might be necessary prior to 
acceptance may be given. If I know that _Nature Genetics_ is not at all 
interested in my manuscript (due to editorial priorities, or study 
scope, or whatever) I can save a lot of time. In the sense that I have 
multiple options (perhaps formatting and targeting instead _Genome 
Biology_) this is dissimilar to DIP.

Even more importantly, **after each round of revisions in the scientific 
paper submission process, the editor or associate editor provides 
commentary regarding the reviews as received (and as a scientist 
themself is responsible for recognizing inappropriate, inaccurate, or 
unfair peer review) and makes a judgement about whether to accept the 
manuscript, proceed pending  additional minor or major revisions, or 
reject.** This I find key, and could make the most improvement in the 
DIP review process.

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.

Offered in a spirit of helpfulness,
James Blachly
Feb 26 2019
parent reply Jordan Wilson <wilsonjord gmail.com> writes:
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
Feb 26 2019
next sibling parent reply Donald <donald gmail.com> writes:
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.
Feb 27 2019
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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.
Feb 27 2019
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
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.
Feb 27 2019
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
Feb 27 2019
parent Olivier FAURE <couteaubleu gmail.com> writes:
On Wednesday, 27 February 2019 at 21:02:44 UTC, Mike Parker wrote:

 no feedback from Walter and/or Andrei at this stage would mean 
 approval is guaranteed.


I think you dropped a "not" here.
Feb 28 2019
prev sibling parent Donald <donald gmail.com> writes:
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.
Feb 26 2019
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
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.
Feb 26 2019
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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.
Feb 26 2019
parent reply Manu <turkeyman gmail.com> writes:
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.
Feb 26 2019
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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.
Feb 26 2019
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 27 February 2019 at 00:06:14 UTC, Joseph Rushton 
Wakeling wrote:

 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.


;)


 revise-and-appeal


That seems to have already been the case with DIP1009 
(expressions based contracts) or at least something like it.
Feb 26 2019
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
Feb 27 2019
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Feb 27 2019
prev sibling next sibling parent reply Donald <donald gmail.com> writes:
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.
Feb 26 2019
parent reply Manu <turkeyman gmail.com> writes:
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.
Feb 26 2019
parent reply Donald <donald gmail.com> writes:
On Wednesday, 27 February 2019 at 00:15:02 UTC, Manu wrote:

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


Well this is a bit tricky. Because the way you showed above, you 
fixed what others pointed but not what W&A pointed.

I'm not here to take any sides, but yes in DIP 1080 Andrei/Walter 
were more active there, and maybe that's is the trickiest part.

In your case just after you presented DIP 1016 that Walter/Andrei 
appeared.

Finally I know you are an old member and trying to help, so 
please don't take this DIP rejection personally, I still think 
you should try one more time, with what W&A pointed and even 
highlight it in the document and re-applied again.

Donald.
Feb 26 2019
parent Manu <turkeyman gmail.com> writes:
On Tue, Feb 26, 2019 at 5:05 PM Donald via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 27 February 2019 at 00:15:02 UTC, Manu wrote:

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


 Well this is a bit tricky. Because the way you showed above, you
 fixed what others pointed but not what W&A pointed.


Okay, I've repeated this a bunch now, but I'll do it again.
 1. They pointed out the exception problem, which I patched within an
hour or 2 (and was later reverted because 'final'). 'fixing what they
pointed out' is explicitly not welcome according to the process.
 2. Everything else in that text is wrong. I can't address criticism
that's not actually true.


 In your case just after you presented DIP 1016 that Walter/Andrei
 appeared.

 Finally I know you are an old member and trying to help, so
 please don't take this DIP rejection personally, I still think
 you should try one more time, with what W&A pointed and even
 highlight it in the document and re-applied again.


There's nothing in the rejection text other than the exception issue,
which I patched within hours (it was reverted).
The rest of it is completely wrong.

One of the cores of my struggle here beyond getting a re-assessment
with a word changed, was also getting the rejection text revised to be
*true*.
I would appreciate it be on record the reasons that the DIP was
rejected, and not the fantasy that caused it to be rejected. Then
there's clear and visible detail of the path forwards which everyone
can see.
Right now, anybody who goes to that document can read the rejection
text, and they'll assume that it's not just all made up, and that it
somehow represents technical reasons it was rejected.
I appealed for this outcome many times, and it's overtly and
repeatedly denied. Review is 'final', and the rejection text "is what
it is, and we don't owe anybody anything else" (like being correct).
Feb 26 2019
prev sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Tuesday, 26 February 2019 at 22:16:09 UTC, Manu wrote:

 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.


We strongly disagree on this one.

Your opinion is, explicitly, that the only criticisms of the DIP 
were about the lack of exception support and the "ref to implicit 
cast" issue (your "bad choice of variable name"), and that the 
DIP would have been accepted if not for them. You especially 
insist on the "one word" part, and seem pretty confident that 
this word completely changed the final result.

This is *not* what W&A have said. In that, they have said, 
multiple times, that these problems were *symptoms* of the lack 
of polish of the proposal, and that the DIP couldn't be accepted 
until that lack of polish was corrected.

Notably, Andrei has said:


 So if we rejected the DIP, we didn't do so on account of one 
 word that can be so easily changed; we did so on account of a 
 DIP that as a whole failed to clarify what it purports to do 
 (and equally importantly, to not do).


(https://forum.dlang.org/post/q2u429$1cmg$1 digitalmars.com)

in a post that you haven't answered.

Now, I agree with you that there were problems in the process, 
and that the rejection rationale posted on Github was pretty 
unhelpful, and just plain bad.

But that idea you have that "W&A stubbornly refuse to reconsider 
their decision based on a few lines they misunderstood" is just 
inaccurate.


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


During the whole process, you've insisted a lot that "we're 
talking about r-values, so obviously [ref to cast of lvalue] 
doesn't apply".

But there is no strict definition, as-is, of what is or isn't a 
rvalue. In fact, Walter has said:


 That's why it's problematic to have a rule that rvalues can be 
 implicitly converted, but not lvalues. There's not a hard line 
 between lvalues and rvalues.


(https://forum.dlang.org/post/q2vr50$1lga$1 digitalmars.com)

The DIP as it stands doesn't address how to differentiate lvalues 
from rvalues in cases like "symbol[expr]", "symbol.symbol", 
"symbol.symbol[expr]", "cast(type)expr", etc.

Now, you might say (and have said in the past) "Well that's 
obvious, you just need to do X, unless Y, in which case Z", but 
the point is that all these considerations *need to be in the 
proposal*.

As it is, the proposal doesn't have any negative space. That is, 
it explains what the feature should look like, but it doesn't 
define boundaries, where the feature is or isn't allowed to be 
used.

Defining negative space is important because it's how you find 
corner cases, cases where the correct behavior seems obvious, and 
yet when you spell it out it turns out everyone disagrees on how 
it should be handled.

Right now, the DIP doesn't address at all potential corner cases 
like alias this, return ref, auto ref, refs in foreach, casts, 
etc.

---

tl;dr: There were major problems in how W&A handled DIP 1016, but 
saying it was rejected because of "a single world" is inacurate. 
It had major structural problems that could not be fixed with a 
few minor changes.
Feb 28 2019
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 1 March 2019 at 00:27:23 UTC, Olivier FAURE wrote:

 On Tuesday, 26 February 2019 at 22:16:09 UTC, Manu wrote:

 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.


 We strongly disagree on this one.

 Your opinion is, explicitly, that the only criticisms of the 
 DIP were about the lack of exception support and the "ref to 
 implicit cast" issue (your "bad choice of variable name"), and 
 that the DIP would have been accepted if not for them. You 
 especially insist on the "one word" part, and seem pretty 
 confident that this word completely changed the final result.

 This is *not* what W&A have said. In that, they have said, 
 multiple times, that these problems were *symptoms* of the lack 
 of polish of the proposal, and that the DIP couldn't be 
 accepted until that lack of polish was corrected.

 Notably, Andrei has said:


 So if we rejected the DIP, we didn't do so on account of one 
 word that can be so easily changed; we did so on account of a 
 DIP that as a whole failed to clarify what it purports to do 
 (and equally importantly, to not do).


 (https://forum.dlang.org/post/q2u429$1cmg$1 digitalmars.com)

 in a post that you haven't answered.

 Now, I agree with you that there were problems in the process, 
 and that the rejection rationale posted on Github was pretty 
 unhelpful, and just plain bad.

 But that idea you have that "W&A stubbornly refuse to 
 reconsider their decision based on a few lines they 
 misunderstood" is just inaccurate.


The point is that that is not _actionable_, for two reasons:
1) the rejection rationale is wrong and until the reasons for 
rejection reflect the problems nothing can be done to improve the 
DIP, and
2) attempts to do so have been rejected


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


 During the whole process, you've insisted a lot that "we're 
 talking about r-values, so obviously [ref to cast of lvalue] 
 doesn't apply".

 But there is no strict definition, as-is, of what is or isn't a 
 rvalue. In fact, Walter has said:


 That's why it's problematic to have a rule that rvalues can be 
 implicitly converted, but not lvalues. There's not a hard line 
 between lvalues and rvalues.


 (https://forum.dlang.org/post/q2vr50$1lga$1 digitalmars.com)

 The DIP as it stands doesn't address how to differentiate 
 lvalues from rvalues in cases like "symbol[expr]", 
 "symbol.symbol", "symbol.symbol[expr]", "cast(type)expr", etc.


They could all be reasonable categorised a rvalue that arise from 
lvalues.


 Now, you might say (and have said in the past) "Well that's 
 obvious, you just need to do X, unless Y, in which case Z", but 
 the point is that all these considerations *need to be in the 
 proposal*.


I agree, but see point 2 above.



 As it is, the proposal doesn't have any negative space. That 
 is, it explains what the feature should look like, but it 
 doesn't define boundaries, where the feature is or isn't 
 allowed to be used.

 Defining negative space is important because it's how you find 
 corner cases, cases where the correct behavior seems obvious, 
 and yet when you spell it out it turns out everyone disagrees 
 on how it should be handled.


That is a really great analogy, I like it!


 Right now, the DIP doesn't address at all potential corner 
 cases like alias this, return ref, auto ref, refs in foreach, 
 casts, etc.

 ---

 tl;dr: There were major problems in how W&A handled DIP 1016, 
 but saying it was rejected because of "a single world" is 
 inacurate.


A hyperbole yes...


 It had major structural problems that could not be fixed with a 
 few minor changes.


... but the DIP is very sensitive (in the mathematical sense: 
∂|review|/∂|DIP| (where || is the edit distance) is absolutely 
massive) and no recourse was given. What would the required edit 
distance be? Hard to say, because it is currently in the domain 
of the review is at fault. That _must_ be fixed before the DIP 
can be improved, but see point 2 above.
Feb 28 2019
prev sibling parent Manu <turkeyman gmail.com> writes:
On Thu, Feb 28, 2019 at 4:30 PM Olivier FAURE via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 26 February 2019 at 22:16:09 UTC, Manu wrote:

 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.


 We strongly disagree on this one.

 Your opinion is, explicitly, that the only criticisms of the DIP
 were about the lack of exception support and the "ref to implicit
 cast" issue (your "bad choice of variable name"), and that the
 DIP would have been accepted if not for them.


No, I'm saying those 2 trivial issues are things that we KNOW blocked
acceptance.
Any further critical issues that blocked acceptance are unknown, and I
have no path to address them. The point is, as it rested, the DIP is
left in the dark in terms of how to move forward.
I made the point: "I amend those things, and then what? We wait a year
and find out what the actual issue is?"

The feedback does not address any critical issues with the DIP that if
resolved, would move it forwards. The only take-away value that I
learned from the rejection was that I'm an idiot, and someone
competent should do this instead. There's nothing actionable there
past small self-contained fixes, which I did submit a PR for, which
was reverted.


 You especially
 insist on the "one word" part, and seem pretty confident that
 this word completely changed the final result.


No, I'm being misunderstood over and over again.
I'm saying that if I changed that word, it would affect **the
rejection text**, that is, in order to reject the DIP, they would have
had to write something more useful, instead of rejecting it on the
basis of something which took minutes to amend.
If there was a revision cycle where the blindingly obvious issues
could have been amended, then the rejection would necessarily have had
to have been something worthwhile instead.


 This is *not* what W&A have said. In that, they have said,
 multiple times, that these problems were *symptoms* of the lack
 of polish of the proposal, and that the DIP couldn't be accepted
 until that lack of polish was corrected.


But that's entirely vague.
"Language Maintainers found other issues with the proposal, most of
which may have been remedied through simple revision"
I don't know what to do with that. I don't feel that way, it seems
pretty straight forward to me.
I had to spawn a chaotic thread where I got insulted a lot while
trying to convince people it didn't say what they thought it said
before I was able to reveal anything useful. And useful feedback did
indeed exist, but it was hard to dig out, and it certainly isn't
written anywhere near the rejection text. It's effectively lost if
anyone does want to understand why the DIP was rejected.


 So if we rejected the DIP, we didn't do so on account of one
 word that can be so easily changed; we did so on account of a
 DIP that as a whole failed to clarify what it purports to do
 (and equally importantly, to not do).




The DIP does what it purports to do and it's exactly the thing I want
as far as I can tell... so I don't know how to correct that without
actionable feedback.
In terms of process (which is on discussion here), that whole
follow-up thread is what's wrong. As Walter finally made clear in his
last post here, the rejection text SHOULD contain details on how to
move forward.
The process shouldn't require a follow-up thread like that one to
discover details that are actionable, and more than simple
revision-worthy changes.
Feb 28 2019
prev sibling parent reply NaN <divide by.zero> writes:
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.
Feb 26 2019
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.
Feb 27 2019
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Feb 27 2019
parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Thursday, 28 February 2019 at 03:06:37 UTC, Nicholas Wilson 
wrote:

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


You're saying this like it's self-evident, but it seems very 
clear to me that it's the very root of your disagreement with 
Andrei: you believe that the process should involve the reviewers 
making an effort proportional to the DIP author, whereas Andrei 
believes that the process should minimize reviewer effort.

Now, neither of these ideas are inherently invalid, but you have 
to realize they're a trade-off. You're not going to convince 
Andrei to change the DIP process by saying "The current process 
wastes the time of DIP authors!", because Andrei is already aware 
of that. The problem is that is that a process with a heavier 
involvement from W&A would waste/spend more of *their* time, 
which Andrei considers a bad trade-off.

(personally, I can see where he's coming from; there are a lot of 
people writing DIPs, and only two W&A; any process which requires 
more involvement from them is going going to see them spending 
less time on maintaining the compiler, designing features, and 
whatever else it is they're doing)

(that said, the current process could definitely stand to be 
improved, and I like the direction Mike is going for)
Feb 28 2019
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 28 February 2019 at 23:15:30 UTC, Olivier FAURE 
wrote:

 On Thursday, 28 February 2019 at 03:06:37 UTC, Nicholas Wilson 
 wrote:

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


 You're saying this like it's self-evident, but it seems very 
 clear to me that it's the very root of your disagreement with 
 Andrei: you believe that the process should involve the 
 reviewers making an effort proportional to the DIP author, 
 whereas Andrei believes that the process should minimize 
 reviewer effort.

 Now, neither of these ideas are inherently invalid, but you 
 have to realize they're a trade-off. You're not going to 
 convince Andrei to change the DIP process by saying "The 
 current process wastes the time of DIP authors!", because 
 Andrei is already aware of that. The problem is that is that a 
 process with a heavier involvement from W&A would waste/spend 
 more of *their* time, which Andrei considers a bad trade-off.


Thank you for making that observation.

Yes it is a tradeoff, but we are at one extremum at the moment. I 
don't think I suggested that the effort of W&A put in prior to 
the formal assessment should match that of the author, sorry for 
the confusion if it came across that way. Perhaps I should have 
said "A DIP improves only as much as the feedback it receives."

(Pedantically I suppose the improvements are bounded by the 
feedback it receives, since that didn't help 1017 at all.)


 (personally, I can see where he's coming from; there are a lot 
 of people writing DIPs, and only two W&A; any process which 
 requires more involvement from them is going going to see them 
 spending less time on maintaining the compiler, designing 
 features, and whatever else it is they're doing)


Maximising the return on investment of having reviews is 
important and I believe that there is a lot of low hanging fruit, 
but the PRIMARY issue it that this whole debacle could have been 
avoided if W&A had said "We've found some significant issues with 
this DIP please edit the DIP to fix them." Instead there was no 
communication at all, they got confused by ambiguities in the DIP 
and delivered the right verdict (in the sense that e.g. exception 
handling needs to be accounted for) for COMPLETELY the wrong 
reasons. Their behaviour that followed was less than stellar.


 (that said, the current process could definitely stand to be 
 improved, and I like the direction Mike is going for)


Yes, I'm expecting quite a few changes to the process in response 
to issues identified with DIPs 1000, 1015-18 at the DConf 
Foundation meeting.
Feb 28 2019
prev sibling parent Manu <turkeyman gmail.com> writes:
On Wed, Feb 27, 2019 at 3:15 PM Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> 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. 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,


What's frustrating is how people keep misrepresenting the conversation this way.


 but at a level it
 needs to be understood by the community that it is a normal and expected
 part of the process.


We're not talking about rejection, we're talking about the process
alone, and how it's configured to practically assure failure unless
you're reviewing them along the way.
Without a single feedback cycle from the stakeholders, and in light of
positive community reviews, there's literally nothing I can do to have
more or less confidence.
It's at your whim to misinterpret a variable name and lose your
mind... or not. I can't know what you're going to do on that morning,
and at that stage, the process says I have absolutely no recourse for
correction, and I was repeatedly told to start over at the back of the
queue, despite the review being almost totally wrong on account of one
word and no provision for amendment.


 The cure is improving the quality of DIPs.


This is a function of feedback. I had zero feedback cycles, and you
got all hung up on one word... so, I change that word, and then what?
We wait a year and see if there was something else?


 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.


Nobody has ever suggested at any time that an unsuitable DIP should be accepted.
Are you deliberately misrepresenting this conversation?

Anyway, Walter's on this now. Fortunately, he'll have his own feedback
along the way. I don't expect he'll require that he wait a year to fix
a typo.
Feb 28 2019
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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!
Feb 26 2019
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Tuesday, 26 February 2019 at 22:56:40 UTC, Joseph Rushton 
Wakeling wrote:

 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.


You said "but sometimes it's only _because_ of those multiple 
rounds of feedback and revision that a proposal is clear enough". 
  Which DIPs are you referring to?  I can't identify any proposal 
that falls into this case.


 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.


I agree with what you're saying here but doesn't really speak to 
the point which is that the process would be much better if 
Walter and Andrei were involved earlier in the process.  The 
system as it exists today is almost comically flawed, take a 
whole year and a lot of people's time to put together a proposal 
for 2 people without any feedback from them until the end.  
Feedback is the most important part of any successful system, 
without it, the system can quickly diverge and go off on an path, 
and the longer it goes without feedback to correct itself, the 
worse and worse it gets.  A year is too long to go without any 
feedback or course correction.


 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? :-)


Depends on the subject.  There have been times when I've had to 
explain something to Walter and/or Andrei, they don't know 
everything.  Languages are very hard to get right and even the 
smartest people in the world can have completely opposite 
opinions on things.  I have my own opinion on their strengths and 
weaknesses, but I think everyone will agree with me that they do 
have blindspots and weakness, including them.  Well, I suppose 
you may not agree with me based on what you said :) In general 
it's not good to base the merit of an idea on who is giving it, 
humans are very flawed creatures when it comes to completely 
objective logical discourse no matter how smart someone is.  
Instead, merit should be based on the content of an idea, not who 
gives it.
Feb 26 2019
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 27 February 2019 at 00:44:26 UTC, Jonathan Marler 
wrote:

 You said "but sometimes it's only _because_ of those multiple 
 rounds of feedback and revision that a proposal is clear 
 enough".
  Which DIPs are you referring to?  I can't identify any 
 proposal that falls into this case.


FWIW Walter has said that if alias this had been proposed today 
that it would be rejected because it has too many nasty corner 
cases. I happen to believe alias this is awesome but I do see 
where he's coming from and I've been reviewing a lot of Razvan's 
PRs fixing those corner cases so I know they do exist. One of the 
points on the agenda for the DLF meeting at dconf is a review of 
the state of alias this.
Feb 26 2019
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, February 26, 2019 5:53:51 PM MST Nicholas Wilson via 
Digitalmars-d wrote:

 On Wednesday, 27 February 2019 at 00:44:26 UTC, Jonathan Marler

 wrote:

 You said "but sometimes it's only _because_ of those multiple
 rounds of feedback and revision that a proposal is clear
 enough".

  Which DIPs are you referring to?  I can't identify any

 proposal that falls into this case.


 FWIW Walter has said that if alias this had been proposed today
 that it would be rejected because it has too many nasty corner
 cases. I happen to believe alias this is awesome but I do see
 where he's coming from and I've been reviewing a lot of Razvan's
 PRs fixing those corner cases so I know they do exist. One of the
 points on the agenda for the DLF meeting at dconf is a review of
 the state of alias this.


It's one of those features that's occasionally useful, but in general, I'm
inclined to think that it causes way more trouble than it's worth. Honestly,
implicit conversions in general tend to be problematic much as they can be
really nice to have sometimes. They're particularly bad when templates get
involved.

- Jonathan M Davis
Feb 26 2019
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 26, 2019 at 06:12:45PM -0700, Jonathan M Davis via Digitalmars-d
wrote:

 On Tuesday, February 26, 2019 5:53:51 PM MST Nicholas Wilson via 
 Digitalmars-d wrote:


[...]

 FWIW Walter has said that if alias this had been proposed today that
 it would be rejected because it has too many nasty corner cases. I
 happen to believe alias this is awesome but I do see where he's
 coming from and I've been reviewing a lot of Razvan's PRs fixing
 those corner cases so I know they do exist. One of the points on the
 agenda for the DLF meeting at dconf is a review of the state of
 alias this.


 
 It's one of those features that's occasionally useful, but in general,
 I'm inclined to think that it causes way more trouble than it's worth.
 Honestly, implicit conversions in general tend to be problematic much
 as they can be really nice to have sometimes. They're particularly bad
 when templates get involved.


[...]

I'm a pretty heavy user of alias this, and would be quite unhappy if the
present semantics were to change or become deprecated or otherwise cease
being supported.  I understand there are some dark corner cases where
it's not at all obvious what the "correct" behaviour is, but still,
alias this does offer significant value for arithmetical types and
wrapper types.  I'd even say that in many cases, it *helps* with
templates because it lets you make your custom type work with a template
that doesn't (and shouldn't) know about the specifics of your type.

Where it breaks down is when templates are written with assumptions that
don't come directly from introspection.  Then you start getting into
ambiguous corner cases and other nasty unexpected behaviours.

Anyway, if anything were to change with alias this, we'd better have a
darned good replacement for it, because I'll be expecting it!


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.
Feb 26 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/26/2019 5:34 PM, H. S. Teoh wrote:

 Anyway, if anything were to change with alias this, we'd better have a
 darned good replacement for it, because I'll be expecting it!


Any discussion of alias this should be in a separate thread, but for here it 
suffices to say it was admitted into the language without nearly enough review.
Feb 27 2019
prev sibling parent Manu <turkeyman gmail.com> writes:
On Tue, Feb 26, 2019 at 5:34 PM H. S. Teoh via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tue, Feb 26, 2019 at 06:12:45PM -0700, Jonathan M Davis via Digitalmars-d
wrote:

 On Tuesday, February 26, 2019 5:53:51 PM MST Nicholas Wilson via
 Digitalmars-d wrote:


 [...]

 FWIW Walter has said that if alias this had been proposed today that
 it would be rejected because it has too many nasty corner cases. I
 happen to believe alias this is awesome but I do see where he's
 coming from and I've been reviewing a lot of Razvan's PRs fixing
 those corner cases so I know they do exist. One of the points on the
 agenda for the DLF meeting at dconf is a review of the state of
 alias this.


 It's one of those features that's occasionally useful, but in general,
 I'm inclined to think that it causes way more trouble than it's worth.
 Honestly, implicit conversions in general tend to be problematic much
 as they can be really nice to have sometimes. They're particularly bad
 when templates get involved.


 [...]

 I'm a pretty heavy user of alias this, and would be quite unhappy if the
 present semantics were to change or become deprecated or otherwise cease
 being supported.  I understand there are some dark corner cases where
 it's not at all obvious what the "correct" behaviour is, but still,
 alias this does offer significant value for arithmetical types and
 wrapper types.  I'd even say that in many cases, it *helps* with
 templates because it lets you make your custom type work with a template
 that doesn't (and shouldn't) know about the specifics of your type.

 Where it breaks down is when templates are written with assumptions that
 don't come directly from introspection.  Then you start getting into
 ambiguous corner cases and other nasty unexpected behaviours.

 Anyway, if anything were to change with alias this, we'd better have a
 darned good replacement for it, because I'll be expecting it!


I use `alias this` a lot, but that's just because it's the only tool we have.
` implicit` constructors (and/or cast operators) would resolve all
uses I can think of, and I think the rules on those would be much
simpler.
Feb 26 2019
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
I propose that rejecting a DIP is NOT wasted effort.

Most language ideas come up again and again. If an idea is rejected early in
the 
process, it will come up again and people will have to rediscover the thought 
process for why it was rejected. The worst case will be not rediscovering the 
why, then implement it, and find out the hard way.

For example, we were pretty far along in the automatic ref counting thing until 
Timon found a fundamental flaw in it that everyone missed. It sunk the whole 
thing, we couldn't find a way to make it memory safe.

ARC keeps coming up again and again. But we don't have a DIP to point to to
show 
the fatal flaw, and we just have to remember to point it out again.

A rejected DIP comes with a rationale, so anyone trying to resurrect the idea 
will have a starting point for both the new proposal and will be prepared to 
surmount the objections, which will save a lot of grief. If they've got nothing 
new to add, they'll save a lot of time repeating the failure.

Rejected DIPs also form a basis and a standard for future DIPs. Andrei and I 
have both noticed that C++ proposals have gotten steadily better over the years.
DIPs - rejected and accepted - form the corpus of knowledge that make up what 
and why D is what it is.

For another example, analyzing failed military campaigns is just as useful as 
studying successful ones.

---

Tl,Dr: Rejecting a completed DIP wastes time in the short term, but saves time 
in the long term.
Feb 27 2019
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 28 February 2019 at 06:03:00 UTC, Walter Bright 
wrote:

 I propose that rejecting a DIP is NOT wasted effort.


Not a priori, no...


 Most language ideas come up again and again. If an idea is 
 rejected early in the process, it will come up again and people 
 will have to rediscover the thought process for why it was 
 rejected. The worst case will be not rediscovering the why, 
 then implement it, and find out the hard way.

 For example, we were pretty far along in the automatic ref 
 counting thing until Timon found a fundamental flaw in it that 
 everyone missed. It sunk the whole thing, we couldn't find a 
 way to make it memory safe.

 ARC keeps coming up again and again. But we don't have a DIP to 
 point to to show the fatal flaw, and we just have to remember 
 to point it out again.


... and yes, this establishes that equivalence to memory unsafety 
as a basis for rejection of proposals, ...


 A rejected DIP comes with a rationale,


... but it helps no-one if the rationale has no basis in fact, 
especially if that rationale is left as is.


 Rejected DIPs also form a basis and a standard for future DIPs. 
 Andrei and I have both noticed that C++ proposals have gotten 
 steadily better over the years.
 DIPs - rejected and accepted - form the corpus of knowledge 
 that make up what and why D is what it is.


Yes. And? This misses the point, yet again, that the problem is 
NOT the _outcome_ of the DIP (the DIP does have problems, e.g. 
exception handling), the problem is the _process_ that results in 
rejection on a false basis.


 Tl,Dr: Rejecting a completed DIP wastes time in the short term, 
 but saves time in the long term.


... if, and only if, the process is amended to avoid the problems 
observed with the process as a result of the DIP.
Feb 27 2019
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Wed, Feb 27, 2019 at 10:05 PM Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 I propose that rejecting a DIP is NOT wasted effort.

 Most language ideas come up again and again. If an idea is rejected early in
the
 process, it will come up again and people will have to rediscover the thought
 process for why it was rejected. The worst case will be not rediscovering the
 why, then implement it, and find out the hard way.

 For example, we were pretty far along in the automatic ref counting thing until
 Timon found a fundamental flaw in it that everyone missed. It sunk the whole
 thing, we couldn't find a way to make it memory safe.

 ARC keeps coming up again and again. But we don't have a DIP to point to to
show
 the fatal flaw, and we just have to remember to point it out again.

 A rejected DIP comes with a rationale, so anyone trying to resurrect the idea
 will have a starting point for both the new proposal and will be prepared to
 surmount the objections, which will save a lot of grief. If they've got nothing
 new to add, they'll save a lot of time repeating the failure.

 Rejected DIPs also form a basis and a standard for future DIPs. Andrei and I
 have both noticed that C++ proposals have gotten steadily better over the
years.
 DIPs - rejected and accepted - form the corpus of knowledge that make up what
 and why D is what it is.

 For another example, analyzing failed military campaigns is just as useful as
 studying successful ones.

 ---

 Tl,Dr: Rejecting a completed DIP wastes time in the short term, but saves time
 in the long term.


Wow...
I'm speechless.

How can you write this email with a straight face?
You can't possibly write this and then not go back and correct your
rejection text. There's an exception issue; easily amendable, and then
the rest was a misreading due to a misunderstood variable name and
then a gloss over anything else ("found other issues with the
proposal, most of which may have been remedied through simple
revision"); completely unhelpful.

"it will come up again and people will have to rediscover the thought
process for why it was rejected" - WB
"A rejected DIP comes with a rationale" - WB
"so anyone trying to resurrect the idea will have a starting point for
both the new proposal and will be prepared to surmount the objections"
- WB

I'd also like to know why it was rejected, and I think that should be
clearly stated at the bottom. I feel like it's not the first time I've
said this.
What's written there now is worthless to posterity.

Anyway, it's your DIP now.
Feb 28 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/28/2019 12:31 AM, Manu wrote:

 Anyway, it's your DIP now.


Indeed, and you, Nicholas and everyone else will have the opportunity to
destroy it.
Feb 28 2019
prev sibling next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 28 February 2019 at 06:03:00 UTC, Walter Bright 
wrote:

 I propose that rejecting a DIP is NOT wasted effort.

 Most language ideas come up again and again. If an idea is 
 rejected early in the process, it will come up again and people 
 will have to rediscover the thought process for why it was 
 rejected. The worst case will be not rediscovering the why, 
 then implement it, and find out the hard way.

 For example, we were pretty far along in the automatic ref 
 counting thing until Timon found a fundamental flaw in it that 
 everyone missed. It sunk the whole thing, we couldn't find a 
 way to make it memory safe.

 ARC keeps coming up again and again. But we don't have a DIP to 
 point to to show the fatal flaw, and we just have to remember 
 to point it out again.

 A rejected DIP comes with a rationale, so anyone trying to 
 resurrect the idea will have a starting point for both the new 
 proposal and will be prepared to surmount the objections, which 
 will save a lot of grief. If they've got nothing new to add, 
 they'll save a lot of time repeating the failure.

 Rejected DIPs also form a basis and a standard for future DIPs. 
 Andrei and I have both noticed that C++ proposals have gotten 
 steadily better over the years.
 DIPs - rejected and accepted - form the corpus of knowledge 
 that make up what and why D is what it is.

 For another example, analyzing failed military campaigns is 
 just as useful as studying successful ones.

 ---

 Tl,Dr: Rejecting a completed DIP wastes time in the short term, 
 but saves time in the long term.


 From one side, there's the need to attract more 'voluntary' work 
towards the D ecosystem, and from the other side there's the need 
to save time of who is already involved, and that's reasonable.

Most of the DIP work is done by voluntaries, in their spare time, 
reality is that they are not payed researchers submitting papers 
to payed journals reviewer.

I know that you are a really pragmatic man, so I will suggest you 
and Andrei to just use a pragmatic and simple way of moving.

I'm assuming that the DIP is _already_ in a good shape, or the 
community review process has something wrong, which does not seem 
to me the case, actually.

Give credits, to the author and to the community: if it seems so 
strange to you that, eg. Manu, have not seen the "big hole" 
that's involved in the DIP, simply contact him during the review, 
and ask for clarification to dispel the doubts. Open a channel.

If you both agree that the DIP has the _potential_ of having 
value, just provide feedback and encourage the author to emend 
the part that are not yet perfectly shaped, and mentor him during 
that part.

You have foreseen value, a LOT of work was already done by the 
community, now it's W&A turn to contribute with the final 
touches, that the community was not able to property see and 
handle. That's is almost always not a big work to do, shape 
together the DIP towards the final accepted shape.

There's not better time spent that working side by side with a 
volunteer on that, IMHO, and it's a great way to thanks them for 
the effort they have put in the process.

Respectfully,
Paolo
Feb 28 2019
prev sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Thursday, 28 February 2019 at 06:03:00 UTC, Walter Bright 
wrote:

 A rejected DIP comes with a rationale, so anyone trying to 
 resurrect the idea will have a starting point for both the new 
 proposal and will be prepared to surmount the objections, which 
 will save a lot of grief. If they've got nothing new to add, 
 they'll save a lot of time repeating the failure.


If that's the direction you're going for, then the rejection 
rationale needs to be a little more polished than DIP-1016's was.

I understand that reviewer time is limited, but the rejection 
rationale is especially important, not just for the sake of the 
DIP author, but for the sake of everyone comes after him.

In particular, at some point in the post-rejection debate, Andrei 
wrote:


 It must be clear that the reason of this misunderstanding is 
 squarely due to the DIP itself. It has multiple problems of 
 informality and vague language that have worked together to 
 cause said misunderstanding.

 [...]

 So the code with my_short was open to interpretation. Cool. In 
 a thorough submission, however, there would have been many 
 places that clear that up:

 * Use of a distinct notation (non-code non-text font for 
 metalanguage, i.e. general expressions);

 * Description of the typechecking process, with examples of 
 code that passes and code that fails;

 * A clarification that lowering proceeds not against all 
 expressions, but only against rvalues;

 * Several places in text in which it is explained that rvalues 
 resulted from implicit conversions are not eligible;

 * etc. etc. etc.


Now, this? This is *exactly* what the rejection rationale should 
have been in the first place. The current rejection rationale 
gives a few points of contention, but they're almost secondary. 
The quote above actually points out the root cause of the 
rejection, and what steps need to be taken to fix it.

Again, I understand there's a trade-off at work, but if you want 
the quality of submitted DIPs to increase over time, you need to 
put some effort into explaining why you reject certain DIPs.
Feb 28 2019
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/28/2019 3:17 PM, Olivier FAURE wrote:

 If that's the direction you're going for, then the rejection rationale needs
to 
 be a little more polished than DIP-1016's was.


I agree that the rejection rationale needs to be more detailed and thorough.
Feb 28 2019
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 28 February 2019 at 23:17:15 UTC, Olivier FAURE 
wrote:

.

 If that's the direction you're going for, then the rejection 
 rationale needs to be a little more polished than DIP-1016's 
 was.


That's mostly on me. I take the informal feedback they give and 
craft the summary. I've committed to providing more detailed 
review summaries in the future and they've committed to helping 
me do so.
Feb 28 2019
prev sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Tuesday, 26 February 2019 at 22:56:40 UTC, Joseph Rushton 
Wakeling wrote:

 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? :-)


Without being that extreme, yeah, the community has a tendency to 
immediately assume "W&A are missing something obvious" instead of 
"W&A are seeing something I'm not".

The fact that W&A seem somewhat bad at communicating their 
viewpoint (and understanding other people's viewpoint) doesn't 
help.
Feb 28 2019
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 28 February 2019 at 23:17:49 UTC, Olivier FAURE 
wrote:

 On Tuesday, 26 February 2019 at 22:56:40 UTC, Joseph Rushton 
 Wakeling wrote:

 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? :-)


 Without being that extreme, yeah, the community has a tendency 
 to immediately assume "W&A are missing something obvious" 
 instead of "W&A are seeing something I'm not".


The fact the they caught that the DIP doesn't specify how it is 
supposed to behave under exception is a good thing...


 The fact that W&A seem somewhat bad at communicating their 
 viewpoint (and understanding other people's viewpoint) doesn't 
 help.


... therein lies the problem. The good thing is we can fix this 
by fixing the DIP process to prescribe what should and shouldn't 
happen when DIP breaking behaviour is discovered post final. 
Communication with the DIP author is a good start.
Feb 28 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/28/2019 3:17 PM, Olivier FAURE wrote:

 Without being that extreme, yeah, the community has a tendency to immediately 
 assume "W&A are missing something obvious" instead of "W&A are seeing
something 
 I'm not".


Despite repeated attempts and examples, Andrei and I have been unable to 
communicate the implicit rvalue conversion problem. I don't know what to do 
about that. I wish I had Herb Sutter's / Scott Meyers' skills, but I don't.


 The fact that W&A seem somewhat bad at communicating their viewpoint (and 
 understanding other people's viewpoint) doesn't help.
Feb 28 2019
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 2/28/19 8:52 PM, Walter Bright wrote:

 
 Despite repeated attempts and examples, Andrei and I have been unable to 
 communicate the implicit rvalue conversion problem. I don't know what to 
 do about that. I wish I had Herb Sutter's / Scott Meyers' skills, but I 
 don't.


(Disclaimer: No intention of being contentious here, just a genuine 
question) Could someone point me to some of these attempts/examples? I'm 
curious to take a look at them.
Feb 28 2019
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/28/2019 9:04 PM, Nick Sabalausky (Abscissa) wrote:

 Could someone point me to some of these attempts/examples? I'm curious to take
a 
 look at them.



https://digitalmars.com/d/archives/digitalmars/D/announce/DIP_1016--ref_T_accepts_r-values--Formal_Assessment_54145.html

Just look for my posts.
Feb 28 2019
prev sibling parent Olivier FAURE <couteaubleu gmail.com> writes:
On Friday, 1 March 2019 at 05:04:05 UTC, Nick Sabalausky 
(Abscissa) wrote:

 (Disclaimer: No intention of being contentious here, just a 
 genuine question) Could someone point me to some of these 
 attempts/examples? I'm curious to take a look at them.


I think he's referring to these posts:
- https://forum.dlang.org/post/q2vr50$1lga$1 digitalmars.com
- https://forum.dlang.org/post/q2ubds$1r6e$1 digitalmars.com
- https://forum.dlang.org/post/q2rfug$7af$1 digitalmars.com
Mar 01 2019
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, February 26, 2019 6:34:04 PM MST H. S. Teoh via Digitalmars-d 
wrote:

 On Tue, Feb 26, 2019 at 06:12:45PM -0700, Jonathan M Davis via 


Digitalmars-d wrote:

 On Tuesday, February 26, 2019 5:53:51 PM MST Nicholas Wilson via



 Digitalmars-d wrote:


 [...]


 FWIW Walter has said that if alias this had been proposed today that
 it would be rejected because it has too many nasty corner cases. I
 happen to believe alias this is awesome but I do see where he's
 coming from and I've been reviewing a lot of Razvan's PRs fixing
 those corner cases so I know they do exist. One of the points on the
 agenda for the DLF meeting at dconf is a review of the state of
 alias this.


 It's one of those features that's occasionally useful, but in general,
 I'm inclined to think that it causes way more trouble than it's worth.
 Honestly, implicit conversions in general tend to be problematic much
 as they can be really nice to have sometimes. They're particularly bad
 when templates get involved.


 [...]

 I'm a pretty heavy user of alias this, and would be quite unhappy if the
 present semantics were to change or become deprecated or otherwise cease
 being supported.  I understand there are some dark corner cases where
 it's not at all obvious what the "correct" behaviour is, but still,
 alias this does offer significant value for arithmetical types and
 wrapper types.  I'd even say that in many cases, it *helps* with
 templates because it lets you make your custom type work with a template
 that doesn't (and shouldn't) know about the specifics of your type.

 Where it breaks down is when templates are written with assumptions that
 don't come directly from introspection.  Then you start getting into
 ambiguous corner cases and other nasty unexpected behaviours.


Basically, if your template constraint tests for an implicit conversion, it
then needs to force that implicit conversion rather than assuming that the
type provided acts like the target type. If you don't force the conversion,
then some operations may act like the target type and some may not (it may
even do the conversion with some operations and use the actual type in
others), and you could get some pretty weird bugs. It can work work if you
force the implicit conversion, but really, if you're dealing with implicit
conversions and templated code, you have to be careful, and in general, it's
far less error-prone to just not use implicit conversions with templated
code and require that the caller do the conversion.


 Anyway, if anything were to change with alias this, we'd better have a
 darned good replacement for it, because I'll be expecting it!


I'd be very surprised if alias this got axed at this point.

- Jonathan M Davis
Feb 26 2019
prev sibling next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 2/26/19 6:28 AM, Mike Parker wrote:

 https://www.python.org/dev/peps/pep-0001/#start-with-an-idea-for-python
 
 The core of the process is the same. What they add to it is this:
 
 "The PEP champion (a.k.a. Author) should first attempt to ascertain 
 whether the idea is PEP-able. Posting to the comp.lang.python newsgroup 
 (a.k.a. python-list python.org mailing list) or the 
 python-ideas python.org mailing list is the best way to go about this.


I strongly agree that's the right way to do things. In fact, we already 
do it that way in D. But there's one key difference between the way 
Python does that and the way D does it: When *we* do that here in D, the 
post is immediately followed by a public lynching at having had THE 
NERVE to suggest an idea change without writing both a complete DIP and 
PR first.
Feb 28 2019
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
My take on all this (not that it counts for anything):

See? This is what happens when you introduce bureaucracy/red-tape to 
problems. You get the same problems, just with much slower progress.

Frankly, I think we already have far better mechanisms that anything a 
supposedly-improved DIP process could ever provide: Github reviews and 
CI tests.

Looking at DIP1016 in particular:

1. Using the same Github code review process we already use to get 
things done instead of this "The DIP Process" contrivance would have 
allowed the DIP the flexibility necessary to receive W&A feedback sooner 
AND respond to such feedback without the "Too bad, go back to start, try 
again" formality-for-the-sake-of-formality worthlessness.

2. The test suite is going to do a ****FAAAAARRRR**** better job of 
rooting out technical problems than five years of human-review. Does 
anyone seriously think it *wouldn't* have caught the issues with 1016 
right away? And even if so, does that say more about the DIP process, or 
does it say more about the test suite?
Feb 28 2019
next sibling parent reply Elronnd <elronnd elronnd.net> writes:
On Friday, 1 March 2019 at 05:24:25 UTC, Nick Sabalausky 
(Abscissa) wrote:

 See? This is what happens when you introduce 
 bureaucracy/red-tape to problems. You get the same problems, 
 just with much slower progress.


Bureaucracy is arguable unavoidable.  At this kind of scale 
(really, more than 5-10 people or so), what we need is _maximally 
efficient_ bureaucracy.  We can't get rid of the cruft, the 
arbitrariness, the red tape, only replace it with new cruft 
that's hopefully smaller.  The solution space is constrained to 
bureaucratic solutions



 The test suite is going to do a ****FAAAAARRRR**** better job 
 of rooting out technical problems than five years of 
 human-review.


This requires a disproportionate amount of work to implement the 
DIP, which is wasted if the DIP is not accepted.  Not to mention, 
it raises the barrier of entry to a would-be DIP author -- now, 
you have to know or learn compiler internals too!
Feb 28 2019
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 3/1/19 2:02 AM, Elronnd wrote:

 On Friday, 1 March 2019 at 05:24:25 UTC, Nick Sabalausky (Abscissa) wrote:

 The test suite is going to do a ****FAAAAARRRR**** better job of 
 rooting out technical problems than five years of human-review.


 
 This requires a disproportionate amount of work to implement the DIP, 
 which is wasted if the DIP is not accepted.  Not to mention, it raises 
 the barrier of entry to a would-be DIP author -- now, you have to know 
 or learn compiler internals too!


Chicken vs egg... :(
Feb 28 2019
prev sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 1 March 2019 at 05:24:25 UTC, Nick Sabalausky 
(Abscissa) wrote:

 My take on all this (not that it counts for anything):

 See? This is what happens when you introduce 
 bureaucracy/red-tape to problems. You get the same problems, 
 just with much slower progress.

 Frankly, I think we already have far better mechanisms that 
 anything a supposedly-improved DIP process could ever provide: 
 Github reviews and CI tests.

 Looking at DIP1016 in particular:

 1. Using the same Github code review process we already use to 
 get things done instead of this "The DIP Process" contrivance 
 would have allowed the DIP the flexibility necessary to receive 
 W&A feedback sooner AND respond to such feedback without the 
 "Too bad, go back to start, try again" 
 formality-for-the-sake-of-formality worthlessness.

 2. The test suite is going to do a ****FAAAAARRRR**** better 
 job of rooting out technical problems than five years of 
 human-review. Does anyone seriously think it *wouldn't* have 
 caught the issues with 1016 right away? And even if so, does 
 that say more about the DIP process, or does it say more about 
 the test suite?


I completely agree with this.  Languages are very hard and the 
DIP process has been put in place as a result.  Walter and Andrei 
want to be sure that any language changes we make going forward 
are thoroughly researched and vetted.  The DIP process was put in 
place so they could leverage the community's efforts rather than 
having to do all the work themselves and leverage the large 
experience/viewpoint pool that comes with large group. However, 
the process itself has sorely missed the mark in achieving this.

For some reason, someone decided that rather than having the 
entire community work together on a DIP, it should be everyone 
except Walter and Andrei.  So now the original goal of

   "Let's research and vet a new proposal as a community to see if 
it's good for D"

Has now become:

   "Go spend a year writing a proposal for your idea to convince 
Walter and Andrei that your proposal is a good idea. And do all 
this without any feedback from them during this time.  Then at 
the end, they'll look over the proposal and either accept it or 
reject it, maybe they'll give you some good feedback, maybe they 
won't.  Oh and if they don't accept it, you'll need to start the 
whole process over again.  And if they give bad feedback, too 
bad, the process doesn't account for this or give you any 
recourse and we MUST FOLLOW THE PROCESS TO THE LETTER.  Why? 
Well...because it's the process."

Now I'm not saying that processes are all inherently bad.  They 
are an attempt to provide a set of rules to facilitate a final 
goal.  Processes become a hindrance when people start to rigidly 
adhere to them no matter what, and they forget the original goal 
of why the process was created in the first place.  The DIP 
process is now suffering from the "rigid adherence" problem but 
also has a second problem.  The DIP process as it's designed is 
horribly flawed because it has left out the 2 most important 
people in the community in most of the process.

To fix this we need to fix the process, and also fix people's 
mindsets.  Keep the original goal in mind.  When the process 
contradicts the original goal don't just adhere to the process 
anyway, feel free to break it.  And lastly, fix the process.  
Don't write Walter and Andrei out until the end.  The communities 
efforts will be much more effective if they are guided by its 
leaders rather than forcing them to go in a direction for an 
entire year that may be completely in the wrong direction.
Mar 01 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
When I get involved early in the DIP process, what happens is the author quits 
and leaves it to me to finish, which usually means doing 98% of the work.

Most proposals to improve process with D revolve around asking myself and
Andrei 
to do most of the work. It just doesn't scale.

The point of the DIP process is to mobilize the community to do the work,
demand 
a high standard, and vet the work.

As mentioned before, this has been successful in the C++ community in that the 
standard of proposals has steadily risen. I've spoken with Mike Parker about 
picking out a couple of approved DIPs to be presented as a "gold standard" on 
how to do a DIP. We expect to replace them with better ones over time, to keep 
on raising the bar on quality.

Having such examples makes it much easier to review a DIP and bounce it back as 
"not good enough".

---

On a final note it doesn't matter to the DIP approval process how hard anyone 
works on the proposal, or how much time they spent on it, etc. Only results 
matter. By the same token, I don't expect anyone to care how much time I spend 
on D, I don't expect anyone to use D because people worked hard on it, etc. The 
only thing that matters is how good D is.

It's a bit like the Olympics. Nobody cares how hard/long an athlete trained. 
Only that they win. Who would want it any other way?
Mar 01 2019
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 1 March 2019 at 21:23:10 UTC, Walter Bright wrote:


 On a final note it doesn't matter to the DIP approval process 
 how hard anyone works on the proposal, or how much time they 
 spent on it, etc. Only results matter. By the same token, I 
 don't expect anyone to care how much time I spend on D, I don't 
 expect anyone to use D because people worked hard on it, etc. 
 The only thing that matters is how good D is.


Oh Walter, this is soo plain wrong! I adopted D in my company, 
more than 15 years ago, exactly for the opposite reason...

/P
Mar 01 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/1/2019 1:38 PM, Paolo Invernizzi wrote:

 Oh Walter, this is soo plain wrong! I adopted D in my company, more than 15 
 years ago, exactly for the opposite reason...


I suppose there is always a counterexample :-)

But I do hope you found D to be good for your company.
Mar 01 2019
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 1 March 2019 at 21:40:51 UTC, Walter Bright wrote:

 On 3/1/2019 1:38 PM, Paolo Invernizzi wrote:

 Oh Walter, this is soo plain wrong! I adopted D in my company, 
 more than 15 years ago, exactly for the opposite reason...


 I suppose there is always a counterexample :-)

 But I do hope you found D to be good for your company.


For sure! It was not good, it was great, and think about all the 
mess we cross in that 15 years of D development...

  I just hope for more pragmatism, like your way moving, and MORE 
vision.... just don't underestimate that...

Sincerely, Paolo
Mar 01 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/1/2019 1:54 PM, Paolo Invernizzi wrote:

 For sure! It was not good, it was great, and think about all the mess we cross 
 in that 15 years of D development...


That is wonderful news!


   I just hope for more pragmatism, like your way moving, and MORE vision.... 
 just don't underestimate that...


And I shall continue...
Mar 01 2019
prev sibling next sibling parent Rubn <where is.this> writes:
On Friday, 1 March 2019 at 21:23:10 UTC, Walter Bright wrote:

 On a final note it doesn't matter to the DIP approval process 
 how hard anyone works on the proposal, or how much time they 
 spent on it, etc. **Only results matter **. By the same token, 
 I don't expect anyone to care how much time I spend on D, I 
 don't expect anyone to use D because people worked hard on it, 
 etc. The only thing that matters is how good D is.

 It's a bit like the Olympics. Nobody cares how hard/long an 
 athlete trained. Only that they win. Who would want it any 
 other way?


I see, wise words... Now to hold someone at gun point to write a 
DIP..
Mar 01 2019
prev sibling next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 1 March 2019 at 21:23:10 UTC, Walter Bright wrote:

 When I get involved early in the DIP process, what happens is 
 the author quits and leaves it to me to finish, which usually 
 means doing 98% of the work.


This doesn't make sense.  If you leave feedback and the author 
quits you don't have to take over the work.  Let someone else 
take it over.  Even better, since you left feedback, the new 
owner can take your feedback and improve the DIP with it.  If no 
one takes it over, then the DIP isn't worth anyone's time and 
you've now saved a years worth of the author's and community's 
time from researching/revising and debating worthless DIP.


 Most proposals to improve process with D revolve around asking 
 myself and Andrei to do most of the work. It just doesn't scale.

 The point of the DIP process is to mobilize the community to do 
 the work, demand a high standard, and vet the work.


This is misrepresentation of what we are proposing.  We are not 
proposing that you "baby" each DIP through the whole process.  We 
are proposing that you stay involved along the process just like 
all the other reviewers.  This means that if you see a new DIP 
and it definitely will never get into the language, take a minute 
to respond immediately with why it won't be accepted.  Not every 
proposal will need your intervention either.  If you take a look 
at a DIP and it looks fine but needs some polish, let the 
community do that.  If you see a DIP and there's a question you 
can already answer such as a general direction it should take, 
then give that direction.  All we're asking for is feedback and 
direction from you.  Since you are the decision maker, you're the 
only one that can do this job.

What's worse is it sounds like you and Andrei are actually using 
the DIP process to go out of your way not to leave any feedback 
at all.  I have no idea why either of you would think this is a 
good idea.


 As mentioned before, this has been successful in the C++ 
 community in that the standard of proposals has steadily risen. 
 I've spoken with Mike Parker about picking out a couple of 
 approved DIPs to be presented as a "gold standard" on how to do 
 a DIP. We expect to replace them with better ones over time, to 
 keep on raising the bar on quality.

 Having such examples makes it much easier to review a DIP and 
 bounce it back as "not good enough".


The C++ standard is a good goal to work towards but trying to 
force it on a community that hasn't matured yet will not produce 
the results you want.  In my opinion, the DIP process should 
start with yours and Andrei's involvement and evolve naturally 
into what the C++ community has.  As the community interacts with 
you and Andrei on the proposals, certain people will start to 
stand out as those who can implement your standards and who have 
similar opinions as you.  Over time, you should find that you 
just don't need to spend as much time because your "lieutenants" 
will already be giving the feedback that you would have given.

Trying to force this heirarchy without the necessary foundation 
of transferring knowledge and expertise to the community will 
result in a "foundation-less" process where no one is able to 
know what you and Andrei want so in your eyes the quality 
suffers.  That's exactly what we are seeing today.



 ---

 On a final note it doesn't matter to the DIP approval process 
 how hard anyone works on the proposal, or how much time they 
 spent on it, etc. Only results matter. By the same token, I 
 don't expect anyone to care how much time I spend on D, I don't 
 expect anyone to use D because people worked hard on it, etc. 
 The only thing that matters is how good D is.


Agreed.  We are not complaining about the amount of work.  We are 
complaining that there is no feedback to the work we are doing so 
we are "wasting work".  The "amount of work" is not a problem.  A 
large community with a good process can do amazing things, but 
with a bad process will just be a waste of everyone's time as it 
does not produce any results and takes everyone's work away from 
what could be productive tasks.


 It's a bit like the Olympics. Nobody cares how hard/long an 
 athlete trained. Only that they win. Who would want it any 
 other way?


Exactly.  With the current process everyone is doing alot of work 
and producing no results.  We are proposing to change the process 
not to save work, but to turn the work we are already doing into 
effective results.
Mar 01 2019
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/1/2019 2:01 PM, Jonathan Marler wrote:

 Exactly.  With the current process everyone is doing alot of work and
producing 
 no results.  We are proposing to change the process not to save work, but to 
 turn the work we are already doing into effective results.


Dip1016 is not "no result". It's clear that rvalues to ref parameters is the
way 
forward. I'm now writing the DIP for it.
Mar 01 2019
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Saturday, 2 March 2019 at 03:51:00 UTC, Walter Bright wrote:

 On 3/1/2019 2:01 PM, Jonathan Marler wrote:

 Exactly.  With the current process everyone is doing alot of 
 work and producing no results.  We are proposing to change the 
 process not to save work, but to turn the work we are already 
 doing into effective results.


 Dip1016 is not "no result". It's clear that rvalues to ref 
 parameters is the way forward. I'm now writing the DIP for it.


Out of all the things I said...you chose to respond to this?

I suppose I shouldn't be surprised.  If we've learned anything 
from the way you respond on the forums and the way you give DIP 
feedback, it seems to be a pattern of yours to ignore the major 
points of what someone writes, then respond to a minor part of it 
and think that's adequate.

I have a hard time seeing how someone can justify this behavior 
to themselves, unless you don't realize what you're actually 
doing; or maybe you just don't think a full response is worth 
your time.

Because of these poor responses we can never seem to get 
resolution.  We just keep arguing and coming back to the same 
things over and over.  I'd rather spend time my time programming 
but for some reason I still have hope that this community will 
get better.  Maybe I'm delusional.
Mar 02 2019
next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 3/2/19 4:50 AM, Jonathan Marler wrote:

 On Saturday, 2 March 2019 at 03:51:00 UTC, Walter Bright wrote:

 On 3/1/2019 2:01 PM, Jonathan Marler wrote:

 Exactly.  With the current process everyone is doing alot of work and 
 producing no results.  We are proposing to change the process not to 
 save work, but to turn the work we are already doing into effective 
 results.


 Dip1016 is not "no result". It's clear that rvalues to ref parameters 
 is the way forward. I'm now writing the DIP for it.


 
 Out of all the things I said...you chose to respond to this?
 
 I suppose I shouldn't be surprised...


Meh, as long as he agrees "rvalues to ref parameters is the way forward" 
and is working on a DIP, I'm satisfied.
Mar 02 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/2/2019 1:50 AM, Jonathan Marler wrote:

 Out of all the things I said...you chose to respond to this?


I've been on forums for several decades. I've done the point-by-point responses 
endlessly. They never result in understanding nor resolution. They just spawn 
another point-by-point riposte, which demands another point-by-point response, 
which goes on and on until someone gives up from sheer exhaustion. Few forum 
readers ever seem to read these chains, either.

Instead, I choose to respond to what seems like the overarching point of the 
message. It seems to work better.



 you don't realize what you're actually doing


Please maintain professional demeanor.
Mar 02 2019
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Saturday, 2 March 2019 at 22:42:55 UTC, Walter Bright wrote:

 On 3/2/2019 1:50 AM, Jonathan Marler wrote:

 Out of all the things I said...you chose to respond to this?


 I've been on forums for several decades. I've done the 
 point-by-point responses endlessly. They never result in 
 understanding nor resolution. They just spawn another 
 point-by-point riposte, which demands another point-by-point 
 response, which goes on and on until someone gives up from 
 sheer exhaustion. Few forum readers ever seem to read these 
 chains, either.

 Instead, I choose to respond to what seems like the overarching 
 point of the message. It seems to work better.



 you don't realize what you're actually doing


 Please maintain professional demeanor.


Oh sorry, how would I say that statement in a more professional 
demeanor? I genuinely wasn't sure whether or not you were are of 
this pattern. I admit one of my weaknesses is not always knowing 
how to say something in the most tactful way. I find people are 
more sensitive than myself so I have a hard time knowing when 
I've said something insensitive, or how to say it in a way that's 
more tactful. How could I have said that in a professional manner?
Mar 02 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/2/2019 4:16 PM, Jonathan Marler wrote:

 Oh sorry, how would I say that statement in a more professional demeanor? I 
 genuinely wasn't sure whether or not you were are of this pattern. I admit one 
 of my weaknesses is not always knowing how to say something in the most
tactful 
 way. I find people are more sensitive than myself so I have a hard time
knowing 
 when I've said something insensitive, or how to say it in a way that's more 
 tactful. How could I have said that in a professional manner?


Thanks for asking.

You could say that what I responded to wasn't the salient part of the post, and 
summarize what you consider to be the most important.

---

In general, the following would be considered inappropriate in a professional 
setting (not just here, really anywhere):

1. impugning the motives of others

2. questioning others' intelligence, competence or mental stability

3. believing one's argument is so compelling that others must have been
secretly 
convinced, and are continuing to disagree out of dishonesty, cussedness or 
attempts to save face

4. obsequiousness

It's discouraged because it is highly unlikely to produce useful results.

BTW, I'll often write a rant, then put it in my drafts folder. Looking at it an 
hour later, I almost always sigh and just delete it.
Mar 02 2019
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Sunday, 3 March 2019 at 02:33:26 UTC, Walter Bright wrote:

 On 3/2/2019 4:16 PM, Jonathan Marler wrote:

 Oh sorry, how would I say that statement in a more 
 professional demeanor? I genuinely wasn't sure whether or not 
 you were are of this pattern. I admit one of my weaknesses is 
 not always knowing how to say something in the most tactful 
 way. I find people are more sensitive than myself so I have a 
 hard time knowing when I've said something insensitive, or how 
 to say it in a way that's more tactful. How could I have said 
 that in a professional manner?


 Thanks for asking.

 You could say that what I responded to wasn't the salient part 
 of the post, and summarize what you consider to be the most 
 important.

 ---

 In general, the following would be considered inappropriate in 
 a professional setting (not just here, really anywhere):

 1. impugning the motives of others

 2. questioning others' intelligence, competence or mental 
 stability

 3. believing one's argument is so compelling that others must 
 have been secretly convinced, and are continuing to disagree 
 out of dishonesty, cussedness or attempts to save face

 4. obsequiousness

 It's discouraged because it is highly unlikely to produce 
 useful results.

 BTW, I'll often write a rant, then put it in my drafts folder. 
 Looking at it an hour later, I almost always sigh and just 
 delete it.


Thanks for taking the time to respond to this one. I'm putting up 
a wiki:

https://wiki.dlang.org/?title=Guidelines_for_Professional_Conduct

The rest of this response is an effort to get clarification on 
your guidelines and hopefully put together a good wiki for them.

As I read these and think about them I'm having a hard time 
understanding some of these guidelines.  For example, "impugning 
the motives of others".  In simple terms I understand this to 
mean "accusing someone of having sinister motives".  In my mind, 
if someone is behaving in a way that appears to be caused by 
sinister motives, wouldn't you want to point that out and ask 
them about it? Either you want to bring those sinister motives to 
light or hopefully they explain what their motives actually are 
and it bring better cooperative understanding.  How do you 
rectify this and remain professional?

In the wiki I rewrote number 2 as "Avoid personal attacks.  Avoid 
insulting another's intelligence, competence or mental 
stability.".  Feel free to modify it of course.


 3. believing one's argument is so compelling that others must 
 have been secretly convinced, and are continuing to disagree 
 out of dishonesty, cussedness or attempts to save face


This one is confusing to me.  It doesn't appear to be a guideline 
for professional conduct, more like a guideline to life and how 
to view other people.  It sounds like you're saying we should 
assume that people are always "open minded" and that they never 
let pride get in the way of things.  Is this correct or did I 
misunderstand?  If so then this doesn't really match my own life 
experience with myself or other people.  I try my best to remain 
open minded but I realize my mind constantly wants to "pick a 
side" and I have to actively fight that tendency.  My own 
experience seems very consistent with how I see other people 
behave as well.  Do you hold a different view on this?



 4. obsequiousness


Had to look this one up, but even after that I'm not sure what 
you meant by this one.
Mar 03 2019
next sibling parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Sunday, 3 March 2019 at 16:29:03 UTC, Jonathan Marler wrote:


 Thanks for taking the time to respond to this one. I'm putting 
 up a wiki:

 https://wiki.dlang.org/?title=Guidelines_for_Professional_Conduct

 The rest of this response is an effort to get clarification on 
 your guidelines and hopefully put together a good wiki for them.



 4. obsequiousness


 Had to look this one up, but even after that I'm not sure what 
 you meant by this one.


It means, don't suck up to Walter/Andrei to curry favour with 
them.

Jonathan, you have a high signal to noise ratio and you are 
usually very 'professional'. I think your time would be better 
spent thinking/designing/coding than updating wiki pages about 
social issues.

But in any case, I'll add a few personal thoughts on my own rules 
for contributing to forums, perhaps others will find them 
beneficial.

1) Don't post when you are angry.

2) Target / address all the readers of the comment, not just the 
person who posted the comment you are replying to. Trying to 'win 
the argument' with the poster who you are replying to is nearly 
always a waste of time and just ends up in aggravation and even 
lost sleep.

3) Always be polite even when someone is being gratuitously rude 
and insulting.

4) Give people the benefit of the doubt.

Readers will notice, these rules are not a recipe to win a 
technical argument. Technical discussion is the interesting part 
of the debate, but in the absence of the social rules it can 
quickly descend into a slanging match.
Mar 03 2019
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Sunday, 3 March 2019 at 20:16:11 UTC, Abdulhaq wrote:

 On Sunday, 3 March 2019 at 16:29:03 UTC, Jonathan Marler wrote:


 Thanks for taking the time to respond to this one. I'm putting 
 up a wiki:

 https://wiki.dlang.org/?title=Guidelines_for_Professional_Conduct

 The rest of this response is an effort to get clarification on 
 your guidelines and hopefully put together a good wiki for 
 them.



 4. obsequiousness


 Had to look this one up, but even after that I'm not sure what 
 you meant by this one.


 It means, don't suck up to Walter/Andrei to curry favour with 
 them.

 Jonathan, you have a high signal to noise ratio and you are 
 usually very 'professional'. I think your time would be better 
 spent thinking/designing/coding than updating wiki pages about 
 social issues.


Thanks for the feedback.  Unfortunately this isn't the first time 
or the first person who has accused me of being "unprofessional". 
  Because of this I take it seriously and I'm trying to be better. 
  I think it can be good to take some time to self-reflect and 
possibly re-adjust yourself.


 But in any case, I'll add a few personal thoughts on my own 
 rules for contributing to forums, perhaps others will find them 
 beneficial.

 1) Don't post when you are angry.

 2) Target / address all the readers of the comment, not just 
 the person who posted the comment you are replying to. Trying 
 to 'win the argument' with the poster who you are replying to 
 is nearly always a waste of time and just ends up in 
 aggravation and even lost sleep.

 3) Always be polite even when someone is being gratuitously 
 rude and insulting.

 4) Give people the benefit of the doubt.

 Readers will notice, these rules are not a recipe to win a 
 technical argument. Technical discussion is the interesting 
 part of the debate, but in the absence of the social rules it 
 can quickly descend into a slanging match.


These are good tips. I know you said I shouldn't spend time on 
the wiki but I think it's worth the effort to include them.  I've 
added a "Tips" section.
Mar 04 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/3/2019 8:29 AM, Jonathan Marler wrote:

 Thanks for taking the time to respond to this one. I'm putting up a wiki:
 
 https://wiki.dlang.org/?title=Guidelines_for_Professional_Conduct


Please don't. We're about D, we're not about being any sort of authority on 
manners. I particularly don't want to codify things in a way that becomes 
something written in a lawyerly fashion for people looking to conform to the 
letter yet violate the spirit.

I suggest anyone looking for an authority on it to pick out one of the "Emily 
Post" books on Amazon.



 TFor example, "impugning the motives of others".  In simple 
 terms I understand this to mean "accusing someone of having sinister motives".
 
 In my mind, if someone is behaving in a way that appears to be caused by 
 sinister motives, wouldn't you want to point that out and ask them about it?


No. It is extremely rude to do so, and in every case I know of the accuser was 
wrong about it.



 3. believing one's argument is so compelling that others must have been 
 secretly convinced, and are continuing to disagree out of dishonesty, 
 cussedness or attempts to save face


 
 This one is confusing to me.  It doesn't appear to be a guideline for 
 professional conduct, more like a guideline to life and how to view other 
 people.


The two are the same.



 It sounds like you're saying we should assume that people are always 
 "open minded" and that they never let pride get in the way of things.  Is
this 
 correct or did I misunderstand?


It's a misunderstanding. It's not about the Bob continuing to disagree, it's
about Fred asserting that Bob couldn't honestly disagree, that Bob must be 
trying to save face.

I've seen (3) many times in this forum, and don't care to see it again. No, I'm 
not going to identify particular instances.

I'm reminded of something a lawyer told me long ago:

1. When the law is on your side, argue the law.
2. When justice is on your side, argue for justice.
3. When neither the law nor justice is on your side, engage in character 
assassination.
Mar 03 2019
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Monday, 4 March 2019 at 06:41:36 UTC, Walter Bright wrote:

 On 3/3/2019 8:29 AM, Jonathan Marler wrote:

 Thanks for taking the time to respond to this one. I'm putting 
 up a wiki:
 
 https://wiki.dlang.org/?title=Guidelines_for_Professional_Conduct


 Please don't. We're about D, we're not about being any sort of 
 authority on manners. I particularly don't want to codify 
 things in a way that becomes something written in a lawyerly 
 fashion for people looking to conform to the letter yet violate 
 the spirit.


I can appreciate this argument as earlier in this thread I was 
just using the same argument to describe a problem with the 
current DIP process.  That people are rigidly adhering to the 
process and forgetting the spirit of it.

My issue here is that these guidelines are not obvious to me and 
I've seen others question what they are as well. That being said, 
I think your concern of "rigid adherence" can be addressed by 
being careful with how the guidelines are presented. This is why 
I changed the wording in your response from

     "do not do X".

to
     "avoid X" and "consider X"


Because of your concern, I've also added a statement that these 
are not rules to be followed to the letter and included a list of 
"goals" to describe the "sprit of the guidelines".  I'm not sure 
what these goals are so I just included one and am hoping for it 
to be filled in by the leadership.


 I suggest anyone looking for an authority on it to pick out one 
 of the "Emily Post" books on Amazon.


At work I have also been known to be "intimidating" at times and 
can come off as rude and insensitive.  I know you are probably 
shocked!  I don't want to be this way and I try hard not to be.  
I take this stuff seriously and I am taking your suggestions 
seriously.  I see a fair number of books, which ones would you 
specifically recommend?


 TFor example, "impugning the motives of others".  In simple 
 terms I understand this to mean "accusing someone of having 
 sinister motives".  In my mind, if someone is behaving in a 
 way that appears to be caused by sinister motives, wouldn't 
 you want to point that out and ask them about it?


 No. It is extremely rude to do so, and in every case I know of 
 the accuser was wrong about it.


This is very interesting to me. To clarify, you're saying that if 
you suspect someone has sinister motives that you shouldn't say 
anything about it. This is very contradictory to my current world 
view. I've come to believe that if something is wrong then you 
should bring it out in the open so that it can be resolved rather 
than letting it simmer and get worse. However, I also believe 
that the way in which you discuss it is VERY IMPORTANT and is 
often the deciding factor in whether or not it can be resolved.  
So if I understand you correctly, you're saying that some things 
should never be discussed.  Futhermore, if you think someone has 
bad motives, you're probably wrong, so you should drop it and not 
ask the person what their motives actually are. This is so 
fundamentally different to how I think. I will have to think on 
this more and reconsider my current beliefs I listed above.


 3. believing one's argument is so compelling that others must 
 have been secretly convinced, and are continuing to disagree 
 out of dishonesty, cussedness or attempts to save face


 
 This one is confusing to me.  It doesn't appear to be a 
 guideline for professional conduct, more like a guideline to 
 life and how to view other people.


 The two are the same.



 It sounds like you're saying we should assume that people are 
 always "open minded" and that they never let pride get in the 
 way of things.  Is this correct or did I misunderstand?


 It's a misunderstanding. It's not about the Bob continuing to 
 disagree, it's
 about Fred asserting that Bob couldn't honestly disagree, that 
 Bob must be trying to save face.

 I've seen (3) many times in this forum, and don't care to see 
 it again. No, I'm not going to identify particular instances.

 I'm reminded of something a lawyer told me long ago:

 1. When the law is on your side, argue the law.
 2. When justice is on your side, argue for justice.
 3. When neither the law nor justice is on your side, engage in 
 character assassination.


I think you're reasoning here matches that previous one.  You're 
saying that if you suspect someone isn't being convinced by your 
argument because of some other reason besides your argument, 
you're probably wrong.  It's unlikely that the person who 
disagrees with you is doing so because they dislike you or 
because they have an agenda. You shouldn't ask them about it 
because doing so would be rude and it's unlikely that it's true. 
So just assume you're suspicions are wrong and continue.

I would say I agree with this up to a point.  I personally try to 
give people the "benefit of the doubt" when it comes to these 
things.  However, I would stipulate that if you see what appears 
to be repeated vindictive behavior then at some point it should 
be addressed and discussed between the parties.
Mar 04 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/4/2019 5:03 AM, Jonathan Marler wrote:

 Because of your concern, I've also added a statement that these are not rules
to 
 be followed to the letter and included a list of "goals" to describe the
"sprit 
 of the guidelines".  I'm not sure what these goals are so I just included one 
 and am hoping for it to be filled in by the leadership.


I don't wish to get into any debate that nitpicks about what is and is not 
professional conduct. It's a hopeless debate, as hopeless as trying to codify 
the difference between art and porn. As far as the forums go, the decision will 
be made by the moderators. It's usually pretty clear, and we'll discuss among 
ourselves any problematic cases.



 I suggest anyone looking for an authority on it to pick out one of the "Emily 
 Post" books on Amazon.


 
 At work I have also been known to be "intimidating" at times and can come off
as 
 rude and insensitive.  I know you are probably shocked!  I don't want to be
this 
 way and I try hard not to be. I take this stuff seriously and I am taking your 
 suggestions seriously.  I see a fair number of books, which ones would you 
 specifically recommend?


For starters, "How To Win Friends and Influence People" by Carnegie is a 
long-standing classic for good reason.

And, "Emily Post's Etiquette".

When I was growing up, I noticed something interesting. I was able to recognize 
people that were less "mature" than I was, but not more "mature". I could only 
see my maturation in hindsight. I think it's similar with manners.

BTW, I think it's very good of you to recognize issues and work to resolve
them. 
I have a lot of respect for that. But don't expect to just read a book and get 
better at it. It's a lifelong struggle. I've been working on mine since I first 
read HTWFaIP as a teenager.



 This is very interesting to me. To clarify, you're saying that if you suspect 
 someone has sinister motives that you shouldn't say anything about it. This is 
 very contradictory to my current world view. I've come to believe that if 
 something is wrong then you should bring it out in the open so that it can be 
 resolved rather than letting it simmer and get worse. However, I also believe 
 that the way in which you discuss it is VERY IMPORTANT and is often the
deciding 
 factor in whether or not it can be resolved. So if I understand you correctly, 
 you're saying that some things should never be discussed.  Futhermore, if you 
 think someone has bad motives, you're probably wrong, so you should drop it
and 
 not ask the person what their motives actually are. This is so fundamentally 
 different to how I think. I will have to think on this more and reconsider my 
 current beliefs I listed above.


Even if you're right about their motives, you'll never resolve it by bringing
it 
out into the open. You'll just make them mad at you.



 However, I would 
 stipulate that if you see what appears to be repeated vindictive behavior then 
 at some point it should be addressed and discussed between the parties.


Vindictive behavior is something entirely different from failing to find one's 
argument compelling.
Mar 04 2019
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Mar 04, 2019 at 02:25:01PM -0800, Walter Bright via Digitalmars-d wrote:
[...]

 When I was growing up, I noticed something interesting. I was able to
 recognize people that were less "mature" than I was, but not more
 "mature".  I could only see my maturation in hindsight. I think it's
 similar with manners.


[...]

And also with programming languages.  Cf. the Blub paradox:

	http://www.paulgraham.com/avg.html


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Mar 04 2019
prev sibling next sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Monday, 4 March 2019 at 22:25:01 UTC, Walter Bright wrote:

 On 3/4/2019 5:03 AM, Jonathan Marler wrote:

 [...]


 For starters, "How To Win Friends and Influence People" by 
 Carnegie is a long-standing classic for good reason.

 And, "Emily Post's Etiquette".

 When I was growing up, I noticed something interesting. I was 
 able to recognize people that were less "mature" than I was, 
 but not more "mature". I could only see my maturation in 
 hindsight. I think it's similar with manners.

 BTW, I think it's very good of you to recognize issues and work 
 to resolve them. I have a lot of respect for that. But don't 
 expect to just read a book and get better at it. It's a 
 lifelong struggle. I've been working on mine since I first read 
 HTWFaIP as a teenager.


Thanks for the suggestions, I've ordered them and look forward to 
what I can learn from them.


 [...]


 Even if you're right about their motives, you'll never resolve 
 it by bringing it out into the open. You'll just make them mad 
 at you.


Well you've got a point there.  I wouldn't say I'm convinced that 
in most cases if you present it in the right way that you can 
actually discuss things like that so long as you do it the right 
way.  But I could be wrong. In any case this is a new perspective 
I will try to consider in the future, and now I know where you 
stand on the subject as well.
Mar 04 2019
prev sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Monday, 4 March 2019 at 22:25:01 UTC, Walter Bright wrote:

 BTW, I think it's very good of you to recognize issues and work 
 to resolve them. I have a lot of respect for that. But don't 
 expect to just read a book and get better at it. It's a 
 lifelong struggle.


Frankly-

at several points in this thread it seems that your response to a 
complaint that something was not done or not attempted has been 
"I've tried doing that, and it has not worked, so I no longer try 
to do that."

I don't see how a process that relies on feedback can function 
when one of the participants has given up on feedback. I don't 
see how DIPs can work if you've given up on supporting DIPs!

I think asking you to put in all of the effort in implementing a 
feature, pushing a DIP through to completion is unreasonable. 
However, providing no feedback and letting the DIP author develop 
in the wrong direction and finally giving a verdict a year into 
the process is *also* unreasonable. Letting others try to push 
effort off onto you is unreasonable, but it's not fair to the 
developers of current DIPs to punish them for the bad behavior of 
previous developers.

If you have given up on providing feedback during the process, 
then

1. this should be clearly documented on the relevant Wiki pages, 
and
2. you should probably expect very few dips and a high rate of 
burnout.

You, W&A, are not the Standards Committee. D is not C++. We do 
not have so large a community that we can select the very best 
and most important of DIPs and still have DIPs be a meaningful 
mechanism for driving the language forward.

If DIPs should be limited to either trivial features or highly 
dedicated, enthusiastic and ascetic developers who can work for 
months to years in radio silence, get a terse rejection and keep 
trucking - saints - then the current course of action is 
appropriate. Frankly, if I worked on a feature for a year and got 
the response that Manu got, I'd fork the project.

But if the point of DIPs is to get moderate changes to the 
language proposed, reviewed, implemented and included - the sort 
of thing where if you go wrong in the beginning, you can spend a 
long time and a lot of effort walking in the wrong direction - 
then there absolutely must be, not equitability, but some amount 
of sane proportion between the effort put in by W&A and the 
effort *not wasted* by the DIP author. It is grossly 
disproportionate that a few lines of feedback can invalidate 
months of work *done within the lines drawn by the process*. That 
is a bad process, and it will not work, and in its failure it 
will drive people away from contributing at all.

It's okay to not have a DIP process. But a broken process that 
absorbs community effort for no gain is a danger to the entire 
project.
Mar 06 2019
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 6 March 2019 at 15:48:12 UTC, FeepingCreature wrote:



 highly dedicated, enthusiastic and ascetic developers who can 
 work for months to years in radio silence



 if I worked on a feature for a year



 a few lines of feedback can invalidate months of work


I keep seeing variations of this "months of effort" claim. 
There's simply no such thing. It's more like "months of waiting".

The effort on a DIP is front-loaded. The majority of it goes into 
getting the initial draft ready for the Draft Review stage. Some 
DIPs receive more feedback than others in Draft Review, but even 
those that have long discussions tend to get them out of the way 
early on, with a little more feedback trickling in now and again 
while the author waits for me to move the DIP to the next round, 
but very little revision after the initial couple of weeks or so.

When I do initiate the next phase, I do a couple of editing 
passes to get the grammar and the language in decent shape and 
then we do the Community Review. Some DIPs require revision 
subsequent to the review, some do not. But if there are any, they 
are relatively minor. Then there's more waiting until the Final 
Review. Usually, there are no subsequent revisions here. Then the 
DIP goes to Walter and Andrei.

I'm not trying to minimize the amount of effort involved. Some 
DIPs do require more work than others. But let's not exaggerate 
the scale -- the lion's share of the effort is up front. The rest 
of the time is spent waiting.

As for Walter and Andrei's feedback, I've thought about this 
quite a bit lately and I really don't think it reasonable to 
require it up front. Imagine they flat out tell a DIP author in 
Draft Review that the DIP has zero chance of being approved. The 
DIP author closes the PR and then we'll never know. Because there 
was no Community Review, the community lost the opportunity to 
debate and improve the DIP. There is no chance to change Walter 
or Andrei's mind. And yes, they have approved a DIP before that 
they expected to reject.

If, on the other hand, Walter and Andrei provide editorial 
feedback to strengthen the DIP, this will easily lead to the 
impression that they are likely to approve it. How does the DIP 
author feel, then, when they get to the end and it's rejected?

What if we wait and instead ask them for feedback during the 
Community Review? Now they can see the debate, see the 
improvements. So... should they reject a bad DIP now? Should they 
suggest their own improvements? Again, what if they do suggest 
improvements and then reject the DIP in the end? At this point, 
why bother with the Final Review or Formal Assessment at all?

I appreciate the sentiment behind the suggestions throughout this 
thread. The goal is to increase the likelihood of acceptance 
while giving an early out to DIPs that won't be accepted. I agree 
we can do more of the former, but not the latter.

The DIP process is long, but it absolutely should be. And anyone 
going into it needs to understand that up front and that they 
might not agree with the end result. But again, the majority of 
the effort goes into the initial draft, so having a long process 
does not add a significant burden of effort on the DIP author. It 
may test the author's patience, but that's something else 
entirely.

A long process also means that people aren't going to submit DIPs 
willy nilly. There needs to be a substantial amount of thought 
that goes into one, so the bar should be high. The stages of 
review are there so that the community can put their collective 
deliberation into it and try to persuade the author to 
change/fix/enhance the DIP in one way or another. This isn't 
always going to produce a DIP that's up to standard, but that 
doesn't mean rejection. Walter and Andrei have accepted DIPs 
conditionally and sent them back to the author for modification 
before, and they likely will again.

So the TL;DR from me is, Walter and Andrei should not be involved 
in the process until the end. As I suggested before, however, we 
could absolutely use a couple of people at the beginning who have 
the background needed to nudge a DIP toward the standard of 
technical soundness Walter and Andrei are looking for.

My focus is on grammar, vocabulary, that sort of thing. Given a 
couple of people who have received instruction from Walter and 
Andrei and with whom I can consult to ensure the DIP is hitting 
all the right notes at different stages of the review, we can 
produce higher quality DIPs and hopefully make the process more 
efficient.
Mar 06 2019
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 6 March 2019 at 18:40:57 UTC, Mike Parker wrote:

 On Wednesday, 6 March 2019 at 15:48:12 UTC, FeepingCreature 
 wrote:



 highly dedicated, enthusiastic and ascetic developers who can 
 work for months to years in radio silence



 if I worked on a feature for a year



 a few lines of feedback can invalidate months of work


 I keep seeing variations of this "months of effort" claim. 
 There's simply no such thing. It's more like "months of 
 waiting".

 The effort on a DIP is front-loaded. The majority of it goes 
 into getting the initial draft ready for the Draft Review 
 stage. Some DIPs receive more feedback than others in Draft 
 Review, but even those that have long discussions tend to get 
 them out of the way early on, with a little more feedback 
 trickling in now and again while the author waits for me to 
 move the DIP to the next round, but very little revision after 
 the initial couple of weeks or so.


I don't think you're giving the proper weight to the amount of 
time and effort that it takes to go through the DIP process.  
We're not just talking the time it takes to write the DIP readme 
file.  There's the time it takes for everyone that is involved to 
read it, think about it, discuss it on the forums, research it, 
create test cases, look at code to see how to implemented it, 
etc.  Alot of time and effort goes into a DIP that isn't shown in 
the final readme document, and it takes that time away from many 
people, not just the author and manager of the DIP.


 As for Walter and Andrei's feedback, I've thought about this 
 quite a bit lately and I really don't think it reasonable to 
 require it up front. Imagine they flat out tell a DIP author in 
 Draft Review that the DIP has zero chance of being approved. 
 The DIP author closes the PR and then we'll never know.


If Walter and Andrei say a DIP has 0% chance of being approved, 
then we've just saved alot of people alot of time, argument and 
potentially hurt feelings.  Walter and Andrei aren't required to 
give a final ruling at this time, but it would be great if they 
could give feedback like:

     "I'm not sure about this feature, we'll need some good 
rational and examples to be convinced."

     "I really want this feature in D in some form, let's do some 
good research to make sure there are no nasty corner cases and 
that we get a very good implementation".

     "I don't see any path for this particular feature to be 
accepted."

I think W&A can tell the difference between a poorly written DIP 
and a poor idea.  If a DIP is poorly written they can say "I 
think there's a good idea here but the DIP is poorly written".


 there was no Community Review, the community lost the 
 opportunity to debate and improve the DIP. There is no chance 
 to change Walter or Andrei's mind. And yes, they have approved 
 a DIP before that they expected to reject.


You're talking like W&A are children who rush to judgement and 
can't keep an open mind.  I don't think this is the case, and if 
it is, we got bigger problems on our hands :) I think they are 
capable of giving reasonable feedback without unnecessarily 
rushing to judgment.


 If, on the other hand, Walter and Andrei provide editorial 
 feedback to strengthen the DIP, this will easily lead to the 
 impression that they are likely to approve it. How does the DIP 
 author feel, then, when they get to the end and it's rejected?


It's all in the way the response is worded.  If they're not sure 
about the idea yet and are waiting for more research from the 
community then they can indicate that.

     "Not sure whether or not this feature would be good for D at 
this time. Would like to see some more rational/research from the 
community on this one."


 What if we wait and instead ask them for feedback during the 
 Community Review? Now they can see the debate, see the 
 improvements. So... should they reject a bad DIP now? Should 
 they suggest their own improvements? Again, what if they do 
 suggest improvements and then reject the DIP in the end? At 
 this point, why bother with the Final Review or Formal 
 Assessment at all?


Should they reject the DIP now?  It depends on what they think of 
it. If they know it will never be accepted then yes.  If not, 
then why would they reject it?

Should they suggest their own improvements?  Of course, why not?  
If they still end up rejecting the DIP that's a much better 
process than if they left no feedback at all during the whole 
process, and now the DIP will contain more relevant points that 
matter rather than focusing on things that don't since it wasn't 
given any guidance.


 I appreciate the sentiment behind the suggestions throughout 
 this thread. The goal is to increase the likelihood of 
 acceptance while giving an early out to DIPs that won't be 
 accepted. I agree we can do more of the former, but not the 
 latter.


Increasing acceptance is most certainly 100% NOT the goal. I 
don't remember anyone saying that. The goal is to leverage the 
community to vet new features for D.  Our suggestions help with 
that goal by

1) directing people's efforts towards fruitful endeavors rather 
than wasting time on pointless ones
2) maintaining a positive community by showing we value people's 
time by taking our own time to leave feedback and give direction


 A long process also means that people aren't going to submit 
 DIPs willy nilly. There needs to be a substantial amount of 
 thought that goes into one, so the bar should be high. The 
 stages of review are there so that the community can put their 
 collective deliberation into it and try to persuade the author 
 to change/fix/enhance the DIP in one way or another. This isn't 
 always going to produce a DIP that's up to standard, but that 
 doesn't mean rejection. Walter and Andrei have accepted DIPs 
 conditionally and sent them back to the author for modification 
 before, and they likely will again.


I keep hearing these rules and justifications like

     A long process also means that people aren't going to submit
     DIPs willy nilly

It's true that people are detured from things if they take 
longer, but that's not justification to implement such a rule. 
They would also be detured if they had to hand out their social 
security number and perform a double-backflip on the trampoline 
before they could submit a DIP :)  Instead, we should let the 
process evolve naturally and only intervene with rules when 
problems occur, and even then, creating a new rule should be a 
last resort since it's very hard to write a rule that is good in 
all cases.


 So the TL;DR from me is, Walter and Andrei should not be 
 involved in the process until the end. As I suggested before, 
 however, we could absolutely use a couple of people at the 
 beginning who have the background needed to nudge a DIP toward 
 the standard of technical soundness Walter and Andrei are 
 looking for.

 My focus is on grammar, vocabulary, that sort of thing. Given a 
 couple of people who have received instruction from Walter and 
 Andrei and with whom I can consult to ensure the DIP is hitting 
 all the right notes at different stages of the review, we can 
 produce higher quality DIPs and hopefully make the process more 
 efficient.


Though I see your reasoning I think you can see from my responses 
that I very much disagree with your conclusion.  What we're 
saying is, at the very minimum, there should not be a rule to 
exclude Walter and Andrei till the end.  You provided one example 
where them leaving feedback early on would cause a DIP to fail.  
This is exactly what we want.  We don't want to waste people's 
time if Walter and Andrei already know they're going to reject 
the DIP.  In the case where they don't know whether or not it 
will succeed, then you're example doesn't apply since Walter and 
Andrei wouldn't leave feedback indicating the DIP is Dead on 
Arrival.

As to whether Walter and Andrei should be required to leave 
feedback, I would argue "yes" but I know that's a more radical 
change to the current process.  However, I strongly believe they 
shouldn't be pushed out of the process until the end.  Each DIP 
will be unique, let each one be handled in the proper way.  If 
W&A think a DIP is viable and want to wait for community feedback 
and revision that's fine.  If they have suggestions/guidance for 
it, even better.  If they know it's a waste of time, then I 
recommend they say something and point the author towards better 
endeavors.
Mar 06 2019
parent Arun Chandrasekaran <aruncxy gmail.com> writes:
On Wednesday, 6 March 2019 at 19:54:23 UTC, Jonathan Marler wrote:

 As to whether Walter and Andrei should be required to leave 
 feedback, I would argue "yes" but I know that's a more radical 
 change to the current process.  However, I strongly believe 
 they shouldn't be pushed out of the process until the end.  
 Each DIP will be unique, let each one be handled in the proper 
 way.  If W&A think a DIP is viable and want to wait for 
 community feedback and revision that's fine.  If they have 
 suggestions/guidance for it, even better.  If they know it's a 
 waste of time, then I recommend they say something and point 
 the author towards better endeavors.


+1
Mar 06 2019
prev sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 6 March 2019 at 18:40:57 UTC, Mike Parker wrote:

 the lion's share of the effort is up front. The rest of the 
 time is spent waiting.


1. You missed the vast amount of political effort required to get 
to the bottom of why it was rejected.


 As for Walter and Andrei's feedback, I've thought about this 
 quite a bit lately and I really don't think it reasonable to 
 require it up front. Imagine they flat out tell a DIP author in 
 Draft Review that the DIP has zero chance of being approved. 
 The DIP author closes the PR and then we'll never know.


Not quite that harshly, but 
https://github.com/dlang/DIPs/pull/101#issuecomment-414803648 ...


 Because there was no Community Review, the community lost the 
 opportunity to debate and improve the DIP.


Not entirely, there is still draft review.


 There is no chance to change Walter or Andrei's mind.


...the author agreed to withdraw it.


 And yes, they have approved a DIP before that they expected to 
 reject.


Out of curiosity, which one?


 If, on the other hand, Walter and Andrei provide editorial 
 feedback to strengthen the DIP, this will easily lead to the 
 impression that they are likely to approve it.


You should it imply that? If they see a problem or a direction 
they fell the DIP should go in


 How does the DIP author feel, then, when they get to the end 
 and it's rejected?


That depends entirely on _why_ is was rejected. In the case of 
1015 or 1016, disappointed would be an understatement, although 
for different reasons.


 What if we wait and instead ask them for feedback during the 
 Community Review? Now they can see the debate, see the 
 improvements. So... should they reject a bad DIP now?


If the DIP is beyond salvaging, or the author has failed to fix 
any problems previously identified *chough* 1017 *cough*.


 Should they suggest their own improvements?


Yes!


 Again, what if they do suggest improvements and then reject the 
 DIP in the end?


Then they will have their reasons, and those reasons will be 
available for all to see (and possibly ridiculed if they are 
completely wrong (e.g. 1015/16), and rightly so).


 At this point, why bother with the Final Review or Formal 
 Assessment at all?


It may pick up something the community has missed.


 I appreciate the sentiment behind the suggestions throughout 
 this thread. The goal is to increase the likelihood of 
 acceptance while giving an early out to DIPs that won't be 
 accepted. I agree we can do more of the former, but not the 
 latter.


2. It should be a trivial effort for W&A to answer:
at the end of the draft stage, reading _just_ the title and the 
abstract, "If this thing is well specified something we _think_ 
would benefit from having in the language?"
at the end of community: is this well specified? Has the answer 
above changed? What issues that have been identified, must be 
resolved?


 The DIP process is long, but it absolutely should be.


No, it should be thorough. One of the sections of the DConf 
foundation meeting is to provide a platform for rigorous review 
and feedback to cut down the amount of time it takes.


 And anyone going into it needs to understand that up front and 
 that they might not agree with the end result. But again, the 
 majority of the effort goes into the initial draft, so having a 
 long process does not add a significant burden of effort on the 
 DIP author. It may test the author's patience, but that's 
 something else entirely.


See point 1.


 A long process also means that people aren't going to submit 
 DIPs willy nilly.


s/long/thorough


There needs to be a substantial amount of
 thought that goes into one, so the bar should be high. The 
 stages of review are there so that the community can put their 
 collective deliberation into it and try to persuade the author 
 to change/fix/enhance the DIP in one way or another. This isn't 
 always going to produce a DIP that's up to standard, but that 
 doesn't mean rejection.


Unfortunately just because a DIP is up to standard and the 
community endorses it, doesn't mean that it will be accepted, see 
1015.


 Walter and Andrei have accepted DIPs conditionally and sent 
 them back to the author for modification before, and they 
 likely will again.

 So the TL;DR from me is, Walter and Andrei should not be 
 involved in the process until the end.


I couldn't disagree more. Their involvement means we can avoid 
process errors like:
1015 (wrong outcome)
1016 (poor handling of the response)
1017 (everything, but principally wasting time reviewing a DIP 
that contains all of its flaws)
1018  implicit, ideally they would have taken the hint a bit 
sooner but they eventually fixed it, which is was matters, even 
it if detracted from the review.


 As I suggested before, however, we could absolutely use a 
 couple of people at the beginning who have the background 
 needed to nudge a DIP toward the standard of technical 
 soundness Walter and Andrei are looking for.


Thats all well and good, but as long as W&A are the ones that 
have the final say, it is them who need to answer point 2.
Mar 06 2019
prev sibling parent reply Rubn <where is.this> writes:
On Monday, 4 March 2019 at 06:41:36 UTC, Walter Bright wrote:

 I'm reminded of something a lawyer told me long ago:

 1. When the law is on your side, argue the law.
 2. When justice is on your side, argue for justice.
 3. When neither the law nor justice is on your side, engage in 
 character assassination.


That's doesn't sound like a very good lawyer. Law is just someone 
made up and justice is whatever people perceive it to be. There's 
plenty you can do other than those 3 things.
Mar 04 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/4/2019 2:34 PM, Rubn wrote:

 That's doesn't sound like a very good lawyer.


It's the order in which you argue a case to a judge. Judges prefer to rule
based 
on the law, because it's easier. It's much easier to win a case when the law is 
on your side. It's much harder to argue that justice should override the law.
Mar 04 2019
prev sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 1 March 2019 at 22:01:03 UTC, Jonathan Marler wrote:

 On Friday, 1 March 2019 at 21:23:10 UTC, Walter Bright wrote:

 When I get involved early in the DIP process, what happens is 
 the author quits and leaves it to me to finish, which usually 
 means doing 98% of the work.


 This doesn't make sense.  If you leave feedback and the author 
 quits you don't have to take over the work.  Let someone else 
 take it over.  Even better, since you left feedback, the new 
 owner can take your feedback and improve the DIP with it.  If 
 no one takes it over, then the DIP isn't worth anyone's time 
 and you've now saved a years worth of the author's and 
 community's time from researching/revising and debating 
 worthless DIP.


Case in point 
https://github.com/dlang/DIPs/pull/101#issuecomment-414803648
Mar 01 2019
prev sibling parent reply Elronnd <elronnd elronnd.net> writes:
On Friday, 1 March 2019 at 21:23:10 UTC, Walter Bright wrote:

 On a final note it doesn't matter to the DIP approval process 
 how hard anyone works on the proposal, or how much time they 
 spent on it, etc. Only results matter. By the same token, I 
 don't expect anyone to care how much time I spend on D, I don't 
 expect anyone to use D because people worked hard on it, etc. 
 The only thing that matters is how good D is.

 It's a bit like the Olympics. Nobody cares how hard/long an 
 athlete trained. Only that they win. Who would want it any 
 other way?


Oh come on.  This comparison makes no sense, the olympics are 
nothing like a programming language.  Specifically, a programming 
language is changing (it's not static)--which is very relevant 
considering we're talking about proposals to change it!  It 
absolutely is worth considering (and is considered) if a 
programming language you want to use is maintained by people who 
care enough about it to do their very best at maintaining it.  I 
have always balked at the assumption that a leader should *have* 
to love what they do, but there needs to be *some* sort of reason 
to believe that a project will be well-led, and that it will 
continue to progress intelligently as time goes on; passion and 
hard work are as good a reason as any.
Mar 01 2019
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02.03.19 07:15, Elronnd wrote:

 On Friday, 1 March 2019 at 21:23:10 UTC, Walter Bright wrote:

 On a final note it doesn't matter to the DIP approval process how hard 
 anyone works on the proposal, or how much time they spent on it, etc. 
 Only results matter. By the same token, I don't expect anyone to care 
 how much time I spend on D, I don't expect anyone to use D because 
 people worked hard on it, etc. The only thing that matters is how good 
 D is.

 It's a bit like the Olympics. Nobody cares how hard/long an athlete 
 trained. Only that they win. Who would want it any other way?


 
 Oh come on.  This comparison makes no sense, the olympics are nothing 
 like a programming language.


It's an analogy. The point was merely that results matter, not effort.
Mar 06 2019
next sibling parent Elronnd <elronnd elronnd.net> writes:
On Thursday, 7 March 2019 at 02:33:11 UTC, Timon Gehr wrote:

 It's a bit like the Olympics. Nobody cares how hard/long an 
 athlete trained. Only that they win. Who would want it any 
 other way?


 
 Oh come on.  This comparison makes no sense, the olympics are 
 nothing like a programming language.


 It's an analogy. The point was merely that results matter, not 
 effort.


Community-building matters.  If you don't provide positive 
feedback to other people who are putting great effort to help 
your project, they are unlikely to continue putting effort into 
your project.
Mar 07 2019
prev sibling parent NaN <what sup.com> writes:
On Thursday, 7 March 2019 at 02:33:11 UTC, Timon Gehr wrote:

 On 02.03.19 07:15, Elronnd wrote:

 On Friday, 1 March 2019 at 21:23:10 UTC, Walter Bright wrote:

 On a final note it doesn't matter to the DIP approval process 
 how hard anyone works on the proposal, or how much time they 
 spent on it, etc. Only results matter. By the same token, I 
 don't expect anyone to care how much time I spend on D, I 
 don't expect anyone to use D because people worked hard on 
 it, etc. The only thing that matters is how good D is.

 It's a bit like the Olympics. Nobody cares how hard/long an 
 athlete trained. Only that they win. Who would want it any 
 other way?


 
 Oh come on.  This comparison makes no sense, the olympics are 
 nothing like a programming language.


 It's an analogy. The point was merely that results matter, not 
 effort.


People are not pointing out the effort involved because they want 
"medals for effort", what they want is the race to be run well, 
for a high speed camera at the finish line not some old guy 
squinting through one eye.

The point is that you need to respect the effort they put in by 
making sure the DIP process is fair and accurate.
Mar 08 2019
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 26 February 2019 at 11:28:56 UTC, Mike Parker wrote:

 * I will no longer simply *ask* DIP authors to respond to 
 feedback in the review threads, I will *require* it. Note that 
 this does not mean I will require the author to make any 
 revisions, nor does it mean that I will pull the DIP if the 
 opinions of the proposal are overwhelmingly negative.


Exactly how it should be, in my opinion. This is a step forward.
Mar 01 2019