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