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