www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.internals - The Phantom Zone

reply Walter Bright <newshound2 digitalmars.com> writes:
The issue that there are too many aged PRs on github that sit around for years 
comes up again and again. I've resisted just closing them, because closing them 
is tantamount to termination with prejudice:

https://en.wikipedia.org/wiki/Termination_of_employment#Rehire_following_termination

and the PR is never seen again. This is squandering our resources. A PR may 
remain open, but is not pulled, for several reasons:

1. it needs work, but the author has left the field
2. it's a good idea whose time has not yet come
3. it's a good idea, but a not good enough implementation, but the PR still 
contains valuable insight, details, and test cases that would be useful for a 
more acceptable implementation
4. it's large and complex and nobody has been willing to expend the effort to
do 
a proper review.

But github has a feature we can use for this. We tag these PRs with "Phantom 
Zone" and then close them.

http://superman.wikia.com/wiki/The_Phantom_Zone
(People with terminal diseases would get put in the Phantom Zone until a cure 
could be found.)

They can then be viewed via this link:

https://github.com/dlang/dmd/pulls?q=is%3Apr+is%3Aclosed+label%3A%15Phantom+Zone%15

PRs banished to the Phantom Zone would have to have an explanatory comment 
saying why.

Andrei has suggested calling it "Limbo".
Jan 14 2018
next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Monday, 15 January 2018 at 01:10:58 UTC, Walter Bright wrote:
 The issue that there are too many aged PRs on github that sit 
 around for years comes up again and again. I've resisted just 
 closing them, because closing them is tantamount to termination 
 with prejudice:

 https://en.wikipedia.org/wiki/Termination_of_employment#Rehire_following_termination

 and the PR is never seen again. This is squandering our 
 resources.
In general, I agree.
 A PR may remain open, but is not pulled, for several reasons:
 1. it needs work, but the author has left the field
If the PR has potential, we should invest in it; not close it. I and others have done this recently by adopting PRs and shepherding them through the process. IMO this has been quite successful.
 2. it's a good idea whose time has not yet come
In this case, I suggest documenting the idea in Bugzilla with a link to the PR, then close the PR. I believe the PR will still remain in GitHub's history so it can be revisited when its time comes.
 3. it's a good idea, but a not good enough implementation, but 
 the PR still contains valuable insight, details, and test cases 
 that would be useful for a more acceptable implementation
In this case, we should be investing in the contributor. Help the contributor get it right. Not only will we get a better contribution out of the process, but we'll have gained a better contributor that could potentially become a profitable asset.
 4. it's large and complex and nobody has been willing to expend 
 the effort to do a proper review.
Help the contributor break it up. * Give them advice on how they can make it easier to review. * Create a roadmap of reviewable steps that the contributor can follow to see the implementation through to completion, and reviewers can refer to to understand what role each submission plays in the larger goal.
 But github has a feature we can use for this. We tag these PRs 
 with "Phantom Zone" and then close them.
I need to think about this some more, but at the moment, the idea doesn't appeal to me. I would like for us, before we submit a new contribution, look at the existing contributions and ask "Is it possible for me to invest in one those existing contributions before submitting a new one?". Sometimes, however, a new contribution is exactly what the existing PRs need. For example fixing this bug (https://issues.dlang.org/show_bug.cgi?id=18191) would help me revive https://github.com/dlang/dmd/pull/7388 Iain recently mentioned on slack that he has a couple more like this that are currently in the PR queue. But, you get the idea: We should be doing more to remove obstacles for others before adding more work to the queue. All that being said, we also need to remove obstacles that are preventing a PR from being closed. If a PR is just not a good idea, or the investment to get the implementation into shape would be too great, we should do our best to close it quickly and diplomatically, so it doesn't compete for resources with more high-value contributions. This might include: 1. Politely rejecting the idea with justification 2. Suggesting a potential alternative 3. Thoroughly documenting the idea in Bugzilla and suggesting it be revisited at a later time 4. etc... Mike
Jan 14 2018
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
On Monday, 15 January 2018 at 01:10:58 UTC, Walter Bright wrote:
 But github has a feature we can use for this. We tag these PRs 
 with "Phantom Zone" and then close them.

 http://superman.wikia.com/wiki/The_Phantom_Zone
 (People with terminal diseases would get put in the Phantom 
 Zone until a cure could be found.)

 They can then be viewed via this link:

 https://github.com/dlang/dmd/pulls?q=is%3Apr+is%3Aclosed+label%3A%15Phantom+Zone%15

 PRs banished to the Phantom Zone would have to have an 
 explanatory comment saying why.

 Andrei has suggested calling it "Limbo".
What other projects are occasionally doing is a mass exodus of all (stale) PRs. Asking people (via comment) to create new ones (hurdle) if they still care enough. I've seen this many times, sometimes because repos are migrated (good reason), sometimes just because it's too many. I'd suggest that someone plans a friendly spring-cleaning with a helpful message. It won't be very disturbing IMO. Making sure to get all the right stalled PRs is another task. Maybe just take everything > 12 month or so. Some research into PR stats would be helpful, e.g. likelihood of merge after X days, to inform a good value. Tagging closed PRs as phantom zone is a good idea. Let's just no do it continuously, but as properly communicated mass cleaning. Overall this sounds like a couple of bash lines, candidate for https://github.com/MartinNowak/github_scripts.
Jan 15 2018
parent reply Brad Roberts <braddr puremagic.com> writes:
On 1/15/2018 7:50 PM, Martin Nowak via Dlang-internal wrote:
 On Monday, 15 January 2018 at 01:10:58 UTC, Walter Bright wrote:
 But github has a feature we can use for this. We tag these PRs with 
 "Phantom Zone" and then close them.

 http://superman.wikia.com/wiki/The_Phantom_Zone
 (People with terminal diseases would get put in the Phantom Zone 
 until a cure could be found.)

 They can then be viewed via this link:

 https://github.com/dlang/dmd/pulls?q=is%3Apr+is%3Aclosed+label%
A%15Phantom+Zone%15 


 PRs banished to the Phantom Zone would have to have an explanatory 
 comment saying why.

 Andrei has suggested calling it "Limbo".
What other projects are occasionally doing is a mass exodus of all (stale) PRs. Asking people (via comment) to create new ones (hurdle) if they still care enough. I've seen this many times, sometimes because repos are migrated (good reason), sometimes just because it's too many. I'd suggest that someone plans a friendly spring-cleaning with a helpful message. It won't be very disturbing IMO. Making sure to get all the right stalled PRs is another task. Maybe just take everything > 12 month or so. Some research into PR stats would be helpful, e.g. likelihood of merge after X days, to inform a good value. Tagging closed PRs as phantom zone is a good idea. Let's just no do it continuously, but as properly communicated mass cleaning. Overall this sounds like a couple of bash lines, candidate for https://github.com/MartinNowak/github_scripts.
What I'd like to see as a first step is to draw a line in the sand, every new pull request as of 1/1/2018 should be handled to resolution, period.  Don't let them get stale.  If really necessary, maybe taking the PZ action, but that'd really be more of a failure than success, but less so than just letting it age into the lower depths of the queue. Hopefully that first step can be taken and successfully pulled off. If so, then some effort can be put towards shrinking the backlog. But I haven't seen any real evidence out side of short flurry of activity that we can even keep up.
Jan 15 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/15/2018 8:41 PM, Brad Roberts wrote:
 What I'd like to see as a first step is to draw a line in the sand, every new 
 pull request as of 1/1/2018 should be handled to resolution, period.  Don't
let 
 them get stale.
We've tried that again and again. It presupposes that all PRs have a resolution. They do not - I mentioned 4 common reasons why in the opening post. There is another problem here. I just got back from POPL 2018 with a list of ideas I want to get going on. I have made zero progress on any of them, because I spend all the time reviewing other peoples' work, dealing with can you please look at these bug reports, and one entire evening rebasing PRs due to the torrent of refactorings. You're asking me to redouble my efforts at looking at PRs. It's just not possible.
Jan 16 2018
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 1/16/2018 3:13 AM, Walter Bright via Dlang-internal wrote:
 On 1/15/2018 8:41 PM, Brad Roberts wrote:
 What I'd like to see as a first step is to draw a line in the sand, 
 every new pull request as of 1/1/2018 should be handled to resolution, 
 period.  Don't let them get stale.
We've tried that again and again. It presupposes that all PRs have a resolution. They do not - I mentioned 4 common reasons why in the opening post.
They do, since closing with some tagging as a way to find them later is one of the possible resolutions, just as a last resort.
 There is another problem here. I just got back from POPL 2018 with a 
 list of ideas I want to get going on. I have made zero progress on any 
 of them, because I spend all the time reviewing other peoples' work, 
 dealing with can you please look at these bug reports, and one entire 
 evening rebasing PRs due to the torrent of refactorings.
Yup, pretty standard life of a senior developer. I'm sure you're used to it.
 You're asking me to redouble my efforts at looking at PRs. It's just not 
 possible.
This isn't about you but rather the entire group of D developers. I'm not sure how to effect the change, but imho, keeping the pull request queue clean needs to be higher priority than producing additional pulls. It's not that the bug fixing, code cleanup, new features, etc aren't important, but that they're one step behind making sure existing hard work is appreciated and followed through on. Every single place I've ever worked getting code reviewed and checked in has taken precedence over writing new code. ---- I guess I should ask a question: What's your goal with the PZ? Is it to have the github pull queues kept to a tiny number of open and active requests? Great, that's exactly what I just suggested with the primary difference being just focusing on the ones from the start of the year as a trial run before applying the same policies to the rest of the queue. If not, then what is the goal and what's the differences that you envision?
Jan 16 2018
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/16/2018 12:35 PM, Brad Roberts wrote:
 What's your goal with the PZ?
The current system is a binary "it's good enough to merge now" and "it has zero merit whatsoever and should never be looked at again." There's a continuum in between those poles, and that is what the PZ is for. I listed 4 reasons a PR may fall in that continuum.
 Is it to have the github pull queues kept to a tiny number of open and active
requests?
One is to keep the autotester from wasting resources on those. The other is the political/marketing issue of "what are those old PRs doing there? They should just be merged or closed!"
Jan 16 2018
parent reply Brad Roberts <braddr puremagic.com> writes:
On 1/16/2018 2:22 PM, Walter Bright via Dlang-internal wrote:
 On 1/16/2018 12:35 PM, Brad Roberts wrote:
 What's your goal with the PZ?
The current system is a binary "it's good enough to merge now" and "it has zero merit whatsoever and should never be looked at again."
What? It's far from binary today. I don't understand this assertion at all. Particularly since you directly counter it immediately. Did you mean something closer to: The current system has two extremes... ? If so, then I don't agree with the starting point of "good enough" either.
 There's a continuum in between those poles, and that is what the PZ is 
 for. I listed 4 reasons a PR may fall in that continuum.
The PZ formalizes an option which effectively adds to the set of paths a PR can take. The issue is that if it just becomes a new place to house roughly the same set of pull request then all that's been accomplished is hiding the problem a layer deeper and pissing off submitters even more. Now, not only is their hard work not being looked at, it's actively (be it by a human or automation) been pushed even further into the shadows. For what it's worth, I'm not trying to say that there's NO pulls for which closing is the right answer, clearly some need to be. I'm also not saying that for some of that set that there's enough value in the pull requests that making sure it's easy to look back isn't a good idea. What I'm trying to say is that those should be extremely rare. Rare enough that they don't make up a meaningful percentage of the current queue.
 Is it to have the github pull queues kept to a tiny number of open and 
 active requests?
One is to keep the autotester from wasting resources on those.
No resources are wasted in the auto-tester due to old requests. Stale requests are further down in the queue. Time spent on them is time that if it wasn't building those it would sit idle.
 The other is the political/marketing issue of "what are those old PRs 
 doing there? They should just be merged or closed!"
Much like the size of the bugzilla db, from a basic PR standpoint, I don't care all that much. I care a whole lot more about the effect to the author of a PR who's work has not progressed. The end results might be the same, but the motivation is very different. That said, I'm not an active developer and my opinion shouldn't be weighed all that heavily here. Go ahead, try it. I suspect you're not going to be satisfied with the results.
Jan 16 2018
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/16/2018 6:57 PM, Brad Roberts wrote:
 What I'm trying to say is that those should be extremely rare.
Let's frame it another way. There have been 7733 PRs for dmd. Of these, 140 are open. Let's say 100 of those are stale and candidates for the PZ. 100/7733 is 1.3% accumulated over a period of what, 10 years? Isn't that "extremely rare"? But people do not look at the resolved PR counts, just the count of unresolved ones, and perceive it as a big problem.
Jan 16 2018
parent Rubn <where is.this> writes:
On Wednesday, 17 January 2018 at 03:23:31 UTC, Walter Bright 
wrote:
 On 1/16/2018 6:57 PM, Brad Roberts wrote:
 What I'm trying to say is that those should be extremely rare.
Let's frame it another way. There have been 7733 PRs for dmd. Of these, 140 are open. Let's say 100 of those are stale and candidates for the PZ. 100/7733 is 1.3% accumulated over a period of what, 10 years? Isn't that "extremely rare"? But people do not look at the resolved PR counts, just the count of unresolved ones, and perceive it as a big problem.
It is a problem, reducing it to a percentage doesn't do it justice. Let's say you are in a house and in that house there are 50 zombies and those are the only zombies that exist on Earth. Does it really matter if that's only 0.0000006718624% of the population? No, you are still going to have to fight through 50 zombies to get out of the house. Clearing 140 pull requests is no small task, especially for how few people there are. That's time and effort that is going to have to be redirected from other tasks. Not only that, but because some of these pull requests are years old, it's going to take even longer for them to be fixed up and brought up to date. Percentages have their place, this isn't the place for it right now.
Jan 17 2018
prev sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 17 January 2018 at 02:57:38 UTC, Brad Roberts wrote:

 Much like the size of the bugzilla db, from a basic PR 
 standpoint, I don't care all that much.  I care a whole lot 
 more about the effect to the author of a PR who's work has not 
 progressed.  The end results might be the same, but the 
 motivation is very different.

 That said, I'm not an active developer and my opinion shouldn't 
 be weighed all that heavily here.  Go ahead, try it.  I suspect 
 you're not going to be satisfied with the results.
I agree with Brad: Dlangland desperately need to motivate active developers, and grow them to core developers. Again, I strongly suggest to concentrate the effort on that, instead of loosing time in what Walter called "marketing". But as Brad, I'm not an active developer, neither a contributor, I've just followed the D communiti since a decade: but I've the same suspect, you're not going to be satisfied with results. /Paolo
Jan 17 2018
prev sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 16 January 2018 at 20:35:30 UTC, Brad Roberts wrote:

 There is another problem here. I just got back from POPL 2018 
 with a list of ideas I want to get going on. I have made zero 
 progress on any of them, because I spend all the time 
 reviewing other peoples' work, dealing with can you please 
 look at these bug reports, and one entire evening rebasing PRs 
 due to the torrent of refactorings.
Yup, pretty standard life of a senior developer. I'm sure you're used to it.
+1000
 You're asking me to redouble my efforts at looking at PRs. 
 It's just not possible.
Every single place I've ever worked getting code reviewed and checked in has taken precedence over writing new code.
+1000 /Paolo
Jan 17 2018
prev sibling parent Martin Nowak <code dawg.eu> writes:
On Tuesday, 16 January 2018 at 11:13:35 UTC, Walter Bright wrote:
 On 1/15/2018 8:41 PM, Brad Roberts wrote:
 What I'd like to see as a first step is to draw a line in the 
 sand, every new pull request as of 1/1/2018 should be handled 
 to resolution, period.  Don't let them get stale.
We've tried that again and again. It presupposes that all PRs have a resolution. They do not - I mentioned 4 common reasons why in the opening post. There is another problem here. I just got back from POPL 2018 with a list of ideas I want to get going on. I have made zero progress on any of them, because I spend all the time reviewing other peoples' work, dealing with can you please look at these bug reports
We all know this by heart. This is counter-productive to the extend of questioning GitHub as development model. Don't get me wrong, contributions are great, and we received an amazing amount of talented work this way. It becomes problematic though when it prevents us from setting an agenda and follow that through. Focus is the most precious resource we have, but contributions tend to come as random streams of particular interests. What works for me, is to batch issues and work on one and only one domain at a time for a prolonged period (~2 weeks). Working 2 weeks only on PRs, but then having 4 or 6 full weeks for planned work would be a useful approach. For this to work we need to align better, so that most of the time we have someone working on PRs. Another barrier with this approach, our current review pipe is so clogged that it's hard to sustain pace during a focused effort. To overcome this we also need to plan for review time alongside focused work. For example I already know that my planned work on limited lifetimes will need a lot of feedback from you, and that I'll roughly start to work on it early February. Likewise I gave Sönke a heads-up to soon expect plenty of dub and dub-registry pulls. Just join us on dlang.slack.com, it's a very undisturbing way for an informal notice. To address the backlog we prolly should prioritize every PR that cannot be reviewed within a minute. This is actually rather simple work once you start to batch it. I went through dlang-bot's bug tracker yesterday, took less than an hour to prioritize https://github.com/dlang-bots/dlang-bot/issues (on topic https://github.com/dlang-bots/dlang-bot/issues/47). And lastly a reminder that we should give early approvals when there are only nits and clearly request specific changes or close PRs with fundamental design issues. There is nothing worse than getting a bit of review, only to get the rest of it once you come back with the requested changes.
Jan 16 2018
prev sibling next sibling parent reply qznc <qznc web.de> writes:
On Monday, 15 January 2018 at 01:10:58 UTC, Walter Bright wrote:
 PRs banished to the Phantom Zone would have to have an 
 explanatory comment saying why.
I would suggest an alternative approach: Automate it. 1. When there is no activity on a PR for one month, the bot pings the author and asks for the status. 2. When there is no activity on a PR for four months, the bot pings three random other people and asks them to adopt the PR. Maybe it can be more clever then "random" and look at what files are touched or something. 3. When there is no activity on a PR for half a year, the bot leaves a short comment "no activity for half a year." and closes the PR. If someone wants to keep a PR alive it only takes single comment every six months. I doubt that there is any PR which got zero activity for six months, yet was successfully merged later.
Jan 16 2018
next sibling parent reply Sebastian Wilzbach <seb wilzba.ch> writes:
On 2018-01-16 19:32, qznc via Dlang-internal wrote:
 On Monday, 15 January 2018 at 01:10:58 UTC, Walter Bright wrote:
 PRs banished to the Phantom Zone would have to have an explanatory 
 comment saying why.
I would suggest an alternative approach: Automate it. 1. When there is no activity on a PR for one month, the bot pings the author and asks for the status. 2. When there is no activity on a PR for four months, the bot pings three random other people and asks them to adopt the PR. Maybe it can be more clever then "random" and look at what files are touched or something.
The bot currently marks a PR has stalled if there hasn't been any activity within three months
 3. When there is no activity on a PR for half a year, the bot leaves a
 short comment "no activity for half a year." and closes the PR.
This would be trivial to implement, but I haven't done this so far, because there hasn't been a consensus on this.
 If someone wants to keep a PR alive it only takes single comment every
 six months.
 
 I doubt that there is any PR which got zero activity for six months,
 yet was successfully merged later.
Hehe, it does happen sometimes, e.g. https://github.com/dlang/dmd/pull/4988 https://github.com/dlang/dmd/pull/2480 But obviously not too often.
Jan 16 2018
parent Martin Nowak <code dawg.eu> writes:
On Tuesday, 16 January 2018 at 20:04:35 UTC, Sebastian Wilzbach 
wrote:
 On 2018-01-16 19:32, qznc via Dlang-internal wrote:
 On Monday, 15 January 2018 at 01:10:58 UTC, Walter Bright 
 wrote:
 PRs banished to the Phantom Zone would have to have an 
 explanatory comment saying why.
I would suggest an alternative approach: Automate it. 1. When there is no activity on a PR for one month, the bot pings the author and asks for the status. 2. When there is no activity on a PR for four months, the bot pings three random other people and asks them to adopt the PR. Maybe it can be more clever then "random" and look at what files are touched or something.
The bot currently marks a PR has stalled if there hasn't been any activity within three months
 3. When there is no activity on a PR for half a year, the bot 
 leaves a
 short comment "no activity for half a year." and closes the PR.
This would be trivial to implement, but I haven't done this so far, because there hasn't been a consensus on this.
 If someone wants to keep a PR alive it only takes single 
 comment every
 six months.
 
 I doubt that there is any PR which got zero activity for six 
 months,
 yet was successfully merged later.
Hehe, it does happen sometimes, e.g. https://github.com/dlang/dmd/pull/4988 https://github.com/dlang/dmd/pull/2480 But obviously not too often.
It actually quite common (https://github.com/dlang-bots/dlang-bot/pull/109 ;)). Someone has a good and jumps to work on it, then gets distracted, becomes busy with sth. else, or the problem turned out much more complicated. Now the initial motivation is gone and the PR gets abandoned. But a year or so later the topic comes up again and the PR is revived. See dub watch for example, it's almost 3 years old https://github.com/dlang/dub/pull/446. The initial design was wrong, but the PR still contains lots of useful information and code. It could also help someone else to pick up the task. Sure we could just close it, but it feels like abandoning that idea altogether.
Jan 16 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/16/2018 10:32 AM, qznc wrote:
 On Monday, 15 January 2018 at 01:10:58 UTC, Walter Bright wrote:
 PRs banished to the Phantom Zone would have to have an explanatory comment 
 saying why.
I would suggest an alternative approach: Automate it.
Banishment to the PZ requires judgement.
Jan 16 2018
parent John Gabriele <jgabriele fastmail.fm> writes:
On Tuesday, 16 January 2018 at 22:23:41 UTC, Walter Bright wrote:
 On 1/16/2018 10:32 AM, qznc wrote:
 On Monday, 15 January 2018 at 01:10:58 UTC, Walter Bright 
 wrote:
 PRs banished to the Phantom Zone would have to have an 
 explanatory comment saying why.
I would suggest an alternative approach: Automate it.
Banishment to the PZ requires judgement.
Oh my. Banishment, phantoms, judgement day... It's not even Halloween!
Jan 16 2018
prev sibling next sibling parent reply Andrew Benton <Andrew.Benton675 gmail.com> writes:
On Monday, 15 January 2018 at 01:10:58 UTC, Walter Bright wrote:
[snip]
 Andrei has suggested calling it "Limbo".
I'd like to throw my hat in the ring with "PRgatory".
Jan 16 2018
parent Martin Nowak <code dawg.eu> writes:
On Tuesday, 16 January 2018 at 23:02:09 UTC, Andrew Benton wrote:
 I'd like to throw my hat in the ring with "PRgatory".
Very nice idea :). We should stick to Italian though, PRgatorio. http://www.worldofdante.org/media/images/more/full/Purgatorio.jpg
Jan 17 2018
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Monday, 15 January 2018 at 01:10:58 UTC, Walter Bright wrote:
 The issue that there are too many aged PRs on github that sit 
 around for years comes up again and again. I've resisted just 
 closing them, because closing them is tantamount to termination 
 with prejudice:

 https://en.wikipedia.org/wiki/Termination_of_employment#Rehire_following_termination

 and the PR is never seen again. This is squandering our 
 resources. A PR may remain open, but is not pulled, for several 
 reasons:

 1. it needs work, but the author has left the field
 2. it's a good idea whose time has not yet come
 3. it's a good idea, but a not good enough implementation, but 
 the PR still contains valuable insight, details, and test cases 
 that would be useful for a more acceptable implementation
 4. it's large and complex and nobody has been willing to expend 
 the effort to do a proper review.

 But github has a feature we can use for this. We tag these PRs 
 with "Phantom Zone" and then close them.

 http://superman.wikia.com/wiki/The_Phantom_Zone
 (People with terminal diseases would get put in the Phantom 
 Zone until a cure could be found.)

 They can then be viewed via this link:

 https://github.com/dlang/dmd/pulls?q=is%3Apr+is%3Aclosed+label%3A%15Phantom+Zone%15

 PRs banished to the Phantom Zone would have to have an 
 explanatory comment saying why.

 Andrei has suggested calling it "Limbo".
https://issues.dlang.org/show_bug.cgi?id=17839 You may have noticed that all those old PRs with a number < 6000 are assigned to me. https://github.com/dlang/dmd/pulls?q=is%3Aopen+is%3Apr+no%3Aassignee+sort%3Acreated-asc Most are either Daniel's or Kenji's, so I hope you find it understanding when I say they take a while to sift through and make sense of.
Feb 07 2018
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wednesday, 7 February 2018 at 17:39:24 UTC, Iain Buclaw wrote:
 https://github.com/dlang/dmd/pulls?q=is%3Aopen+is%3Apr+no%3Aassignee+sort%3Acreated-asc

 Most are either Daniel's or Kenji's, so I hope you find it 
 understanding when I say they take a while to sift through and 
 make sense of.
Whoops, that should be: https://github.com/dlang/dmd/pulls?q=is%3Aopen+is%3Apr+sort%3Acreated-asc+assignee%3Aibuclaw
Feb 07 2018