Need standard policy on stale issues and repos

[Frijol]

Edit:

Checklist of repos that need this policy applied:

• overview
• edgi-scripts
• edgi-hubot-halpy
• web-monitoring-processing
• eis-search
• web-monitoring-versionista-scraper
• web-monitoring-ops
• web-monitoring-db
• web-monitoring (Add stale issue policy web-monitoring#127)
• web-monitoring-ui
• matterbridge-heroku
• edgi-website
• archivers-greetingslack
• halpy-ng
• 100days
• awesome-website-change-monitoring
• edgi-acronym-expander-browser-ext
• video-call-landing-page
• eot-nomination-tool

---

I proposed in an Archiving meeting that we have a policy on closing stale issues and archiving stale repos. This issue is to design that policy.

Why?

A standard policy on what is "stale" accomplishes:

• We don't have a buildup of issues & guilt we'll never get to– we instead build things that have some urgency or continuing interest, letting old ideas for issues pass into the archives
• Repos that aren't actively being maintained/developed reflect that outwardly
• For new contributors to the project, it is clear what issues & repos are relevant (because the others have been closed/archived)
• For maintainers, there is no need to understand the history of a repo or issue in order to close it– there's a standard process (and therefore maintainer work can be done by a greater body of people)

How?

Some open source orgs use 2 years as a "stale" metric. We aren't yet two years old, and already have issues that have been stale a while– so I propose something shorter than that. @b5 proposed 180 days, which sounds like a good straw-person default.

Here are two versions of policy we could adopt:

Simple

(Designed for easy maintenance)

• Any issue that has had no activity in the last (issue_stale_time) gets labeled "stale" and closed
• If anybody objects to the issue being closed, they can request it to be re-opened

Considered

(Designed to make sure each action is thoughtful)

• Any issue that has had no activity in the last (issue_stale_time) gets labeled "stale" and receives a comment such as "This issue will be closed as stale if there is no activity in the next week"
• If there is still no activity within the next week, it gets closed

Extending the policy to repos

I'd also like to propose that we extend this policy to archive stale repos, though maybe with a separate repo_stale_time, which I'll arbitrarily set as 6 months for this proposal.

The process could essentially follow either of the other two policies above, but instead of a "stale" label, there would be an issue, and instead of closing the issue, we would use Github's repo archiving feature (about).

What's next?

Seeking discussion on this issue on the following questions:

1. Do you like 180 days as issue_stale_time?
2. "Simple" vs. "Considered" from above? Or something else?
3. Should we use the same policy for archiving repos, or is a different policy needed? In this case, is 6 months a good amount of time?

I'll post this issue on our Slack channels. Once discussion stops, I'll use the consensus to make a PR adopting this policy into the project guidelines doc.

[dcwalk]

1. 180 days seems as good as any other limit to start
2. given the scale of our repos I feel like "Simple" might be enough with lower effort, but no strong preference
3. I think there should be a policy that is distinct for Repos. In particular we have a couple (e.g., 100 days) where there isn't active development, but the site is still served (therefore not "stale") and it seems that the repo should remain active? For content that appears stale, I think there should be conversation and if it is no longer active, then updates to the readme and using the "Archived" feature make sense.

[Mr0grog]

1. I’m down with 180 days.

2. I’d prefer the “considered” approach, especially since I know we have quite a few old issues that are important in Web Monitoring. I think this GitHub app will do all that for us (plus tagging!) and it’s free: https://probot.github.io/apps/stale/

3. Agree with @dcwalk that we need to distinguish between a dead/unmaintained/unused repo and one that is largely idle, but maintained (like 100 days report).

   I think creating an issue based on time (excepting repos we already know are “idle-but-maintained”) is a good start. We should probably also bring these up on Slack and at the next archiving and monitoring WG meetings before actually archiving them, too. (Since archiving is a pretty impactful action, it seems worth putting it through a little more process.)

[lightandluck]

1. +1 180 days
2. I also would prefer the "considered" approach, because progress moves so slowly that I wouldn't want issues that are important but lagging, to be closed automatically.
3. It sounds like we need to come to agreement on what repos need to be archived and do it manually rather than have an automated process for them.

[Frijol]

Sounds good! Based on this feedback, I'll make a PR to the project guidelines doc incorporating:

1. 180 day policy
2. "Considered" approach
3. Not include policy for repo archiving, that can be done case by case

I'll implement per @Mr0grog's excellent suggestion of https://probot.github.io/apps/stale/ (update: someone has to approve it, but I've requested it be added)

[Frijol]

Reopening because although this policy is piloted here on the Overview repo, it should be applied across all open repos to truly be resolved.

[Mr0grog]

👍 would you please add a checklist of repos to the original post? That way we can all see what needs to be done where and pitch in. (And having it in the original post means it shows up as “x of y subtasks done” in the issue listing page.)

[Frijol]

@Mr0grog yes, good idea! I think we should resolve #217 to get a full list of repos this should apply to. Will add the ones I'm certain of, in the meantime

[Mr0grog]

Done for all the web-monitoring-* repos.

[Frijol]

How to contribute to this issue

1. Pick an unchecked repo from the list above
2. Make a pull request to add .github/stale.yml to that repo, tagging this issue in the commit message
3. Merging the PR will automatically enable the stalebot on the repo! It will immediately begin to comment on stale issues.

[Frijol]

Have been finding this pretty cool so far, had an old issue pop up in my notifications recently that I would otherwise have completely forgotten about :)

[Frijol]

ok, I think I have PRs in for all of the active repos. It would be a good idea to stagger merges so that we don't have a deluge of stale issues to check over!