Shall we have a policy about stale issues?

[kytrinyx]

TODO

• draft issue (see below in Shall we have a policy about stale issues? #128 (comment))
• post to issues to all repos using hub
• (on April 10th) install https://github.com/integration/probot-stale

---

original issue

The exercism/exercism.io has a lot of very old issues.

A colleague of mine recently built a GitHub integration that will automatically close stale issues (well, it first adds a comment, then closes it if there's no activity in the N days after the comment).

https://github.com/integration/probot-stale

I would like to suggest that we do this for the exercism/exercism.io repository.

The argument for this is that:

1. If it's important, it will come up again.
2. It can always be reopened.
3. It will make it much easier to see what is actually being worked on.

My goal for the project is for every issue to be actionable. Eventually that will mean doing better at labeling (some issues might be worth keeping open even if they are stale), but I think it would be helpful to start by defaulting to "close" and then when we run into things where we don't like that, we can discuss it to see what we should be doing instead.

[kytrinyx]

Oh, one more thing. We could totally start by marking "stale" as 1 year, then reduce to 6 months, then reduce to 3 months, and then finally (if we think it's useful/necessary), reduce to 1 month. We don't have to jump straight to the most extreme.

[kotp]

I had also started using Zenhub Board to start going through them as well, placing some in backlog. It has been a while since I have been able to do that though.

[kytrinyx]

One of the things that appeals to me about closing (rather than putting it in a backlog) is that it gives us a sanity check about how important it is: if nobody brings it up again, maybe it's not important.

I have a tendency to save ALL the ideas out of fear of losing anything.

[kotp]

That and the backlog is not viewable by those that aren't using zenhub.

[ErikSchierboom]

@kytrinyx Closing issues that are stale seems like an excellent idea, for all the reasons you already mentioned.

[treiff]

I like this idea. Sometimes I find it overwhelming combing through all the open issues looking to help out. When looking through the older issues, It's tough to know what is really "important" or perhaps not valid anymore.

[jtigger]

This discussion reminds me of the notion of "inventory" in Lean thinking. Our contributors'/maintainers' time is a limited treasure. People like @treiff burning time as he described is pure waste (i.e. we get nothing for the effort).

It's doubly positive when we consider how much more inviting it is to engage with a lean project (where nearly all issues have import) than those that have apparent clutter.

[kytrinyx]

This discussion reminds me of the notion of "inventory" in Lean thinking.

This is an excellent point.

OK, based on the discussion so far, I am convinced that this will be a good thing.

How do you all feel about starting with 6 months as the "stale" threshold?

[ErikSchierboom]

Sounds reasonable.

[kytrinyx]

The next step on this is to draft an issue that can be submitted to every single Exercism repository that describes:

• the reasoning behind installing probot/stale
• describe the .github/stale.yml file where maintainers can override defaults https://github.com/probot/stale#usage
• give a deadline (1 week? 2 weeks) to get the github/stale.yml into their repository (any repository without a github/stale.yml will get the defaults).

Then, on the deadline I will install probot/stale integration on the Exercism org, for all repositories.

[kytrinyx]

Here's my draft:

Per the discussion in https://github.com/exercism/discussions/issues/128 we
will be installing the probot/stale integration on the Exercism organization on
April 10th, 2017.

By default, probot will comment on issues that are older than 60 days, warning
that they are stale. If there is no movement in 7 days, the bot will close the issue.
By default, anything with the labels `security` or `pinned` will not be closed by
probot.

If the defaults are fine for this repository, then there is nothing further to do.
You may close this issue.

If you wish to override these settings, create a .github/stale.yml file as described
in https://github.com/probot/stale#usage before April 10th.

I didn't put the arguments for doing this directly in the issue draft, but rather link back to the original discussion.

[kytrinyx]

To get the list of repo names in the org:

> for n in 1 2 3 4; do curl "https://api.github.com/orgs/exercism/repos?type=all&page=$n" | jq .[].name >> repos.txt; done

Then we can loop through the repos in repos.txt and submit issues using hub.

[kytrinyx]

OK, I've done this. Since turning it on doesn't affect repositories that have not added a .github/stale.yml file, I think we're fine to close this, and each repository can decide whether or not to add the file.

[Insti]

Just confirming, this will also close stale pull requests?

[kytrinyx]

Yepp, that's correct: https://github.com/exercism/exercism.io/blob/master/.github/stale.yml#L21