Proposal: Shorten github auto-close PR bot to 2 months of inactivity


during the last PR reviewers meeting, we noticed that the 6 months of inactivity for foreman core PRs is probably not good enough in order to bring the list of active PRs down. We are running a bot which politely closes inactive PRs encouraging authors to reopen them later.

I hereby propose to shorten this down a bit. What we are hoping for is to poke people earlier that they should be returning to their PRs sooner and not letting them die, we believe that half year of inactivity is way too much for both author and reviewer to get back into the context, rebasing can be tough and also users who landed on the PRs can be less confused or can ask earlier about why something was not moving.

Let’s do some voting then!

  • Keep 6 months
  • Set 5 months
  • Set 4 months
  • Set 3 months
  • Set 2 months
  • Set 1 month
  • What the hell, set 2 weeks

0 voters

Cooindicently, we had a nice chat today with @Bryan_Kearney and research from @Gwmngilfen shows that roughtly 80 % of our core PRs get merged in 3 months. Just saying, if we set the new threshold to 3 months we at least know that 80 % of PRs should get though.

Merged date and inactive PRs are different metrics, so it’ll be considerably more than 80% :smiley:

@sean797 it was actually survival rate, and Greg showed that at about 85 days 20% of the PRs are still open.

See, now you’re going to make me write a long post with graphs ‘n’ stuff… (as if I need much excuse!)

So here is the data @Bryan_Kearney refers to (seriously, you could have posted this :stuck_out_tongue: )

I think most of you have seen this type of curve before, but to recap - Y is the “chance of survival”, i.e. how likely a PR is to still be open after X days. Since it’s a curve, you can pick any value you’re interested in - I like 80% as it maps nicely to the old 80/20 saying. That gives you ~83 days (95% CI: 63 - 110 days)

Now there’s a few assumptions here, which you should take into account. Firstly, this ignores closed PRs, so things that sit around and then get rejected aren’t considered. That may skew the number down. Second, there’s no treatment of the type of PR (labels/categories/lines-of-code etc) so a large number of short, successful PRs will again skew this down (I’m assuming inactive PRs tend to be larger ones that need work).

So, for the purposes of this discussion, I would take that 85 days as being an underestimate. If there’s an appropriate GitHub label to stratify on, then I can do something more rigourous that models inactive PRs vs the rest.


Let’s wrap it up:

  • 4 votes for 2 months
  • 4 votes for 3 months
  • 2 votes for 4 months

The winner is 3 months. Speak up now, or never.