Kibana: Should we use a stale issue/pr bot?

Created on 19 Sep 2019 · 12Comments · Source: elastic/kibana

Should we configure the stale bot to close issues/prs that haven't seen any activity in 60+ days?

This example config would comment on an issue/pr if it hasn't been touched for 60 days unless it has the pinned label, and if it doesn't get any activity in the next 7 days will close the issue/pr.

# Number of days of inactivity before an issue becomes stale
daysUntilStale: 60
# Number of days of inactivity before a stale issue is closed
daysUntilClose: 7
# Issues with these labels will never be considered stale
exemptLabels:
  - pinned
# Label to use when marking an issue as stale
staleLabel: "auto closed: stale"
# Comment to post when marking an issue as stale. Set to `false` to disable
markComment: >
  This issue has been automatically marked as stale because it has not had
  recent activity. It will be closed if no further activity occurs. Thank you
  for your contributions.
# Comment to post when closing a stale issue. Set to `false` to disable
closeComment: false

Operations discuss

Source

spalger

❤2

Most helpful comment

My goal here was first and foremost to fix the problem of PRs that sit untouched for months. We have many of them, they are unnecessary, and create a minor risk for us in CI. There's a reason why I've been preaching ABC, having a bunch of old branches around that get randomly thrown at CI every once and a while isn't great for us in a couple ways.

Additionally, I think it's clear that there are a lot of neglected issues, community PRs that haven't gotten any attention since they were created, and I think we should do something about those.

Something like stalebot at least gives those of us who actually check github notifications a warning when we've forgotten something. We could make it an important goal to never let issues autoclose. Either close them when they should be closed, or pin/immortalize the issues that should be left open. Then the automation can just publicly shame us when we forget about an issues/pr.

I think it would be ideal if we treated issues/prs as something we were either doing, closing, or marking "someday". Doing that without stalebot or something equally simple probably requires either fantastic discipline across all the teams (which feels like a lofty goal) or more sophisticated automation of some sort.

There are surely better solutions, but I think this solution is better than admit fault and do nothing, which is what it feels like we've been doing for years.

spalger on 20 Sep 2019

👍3 ❤1

All 12 comments

Pinging @elastic/kibana-operations

elasticmachine on 19 Sep 2019

I like it. Is there a label other than wontfix that we can use, just for people who might find the issue/pr later? I'm just thinking about how often I find old, legit issues in other (non-Elastic) projects marked as "Won't Fix" and how it can easily add to frustrations about that project.

brianseeders on 19 Sep 2019

👍1

Is there a label other than wontfix that we can use

Maybe auto closed: stale?

spalger on 19 Sep 2019

Can we separate the number of days for issues and PRs. I think 60 days would make sense for PRs but I would want issues to go stale after maybe 6 months, just thinking about the time between opening an issue, prioritizing it, getting it into a release.

timductive on 19 Sep 2019

👍3

I think it is a good idea, I tried to setup it up something through infra at one time too.

liza-mae on 19 Sep 2019

legrego on 19 Sep 2019

I think there are valid issues and PRs that have been open for a long time, which should be under the radar under some devs, but devs are not taking the time to see when they can bump something. All it would take would be for someone who's responded on a ticket earlier to chime back in and say, "will there be more progress on this?" and if there's no response they can come back and close it.

I am concerned that auto-closing might set a dangerous idea in the devs minds, that they can just let the bot do the work of keeping in touch with the community.

tsullivan on 19 Sep 2019

I am not in favor of auto closing stale issues.

Kibana's issue bloat can not entirely be blamed on stale issues. The growing number of Kibana issues is the result of adding so many new solutions to Kibana that manage their issues in the Kibana repo. Kibana contains issues for APM, SIEM, maps, code, canvas, and more (none of which existed in the repo 18 months ago). Kibana's growing issue count is a result of larger teams and a larger number of products.

Managing issues should really be part of each teams job to cull through their tags and figure out what issues can be closed. Using age/activity to automate this process is too broad.

Issues should be managed by human judgement and reasoning, not a ticking clock.

nreese on 20 Sep 2019

Can we take an iterative approach with this one and just comment on issues before possibly upsetting folks with auto-closing?

tylersmalley on 20 Sep 2019

Additionally, I think it's clear that there are a lot of neglected issues, community PRs that haven't gotten any attention since they were created, and I think we should do something about those.

There are surely better solutions, but I think this solution is better than admit fault and do nothing, which is what it feels like we've been doing for years.

spalger on 20 Sep 2019

👍3 ❤1

The Infra-repo has such a bot, and I have found it very helpful. Either it flags an issue that needs a response, or indeed it is stale and can be closed.

thomasneirynck on 16 Oct 2019

Yeah +1, it's time. We've hit the 5000+ issues mark and we're seeing concerns from users. There's enough noise that it isn't clear what needs to be fixed and what doesn't.

I'd propose we put some effort in a full team wide dedicated triage session before kicking it off, I'm sure there's some unintentional ones stuck in the loop.