repos are getting archived that shouldn't be

[afeld]

…for some definition of "shouldn't." The script seems to be working as expected, but we have gotten feedback that some repositories that haven't been updated recently still shouldn't be archived. Common examples are example codebases for cloud.gov or login.gov.

Options that come to mind:

• https://github.com/18F/ghad/issues/27
• Extending from 90 days of inactivity
• Excluding select repositories in some way (a list in here, a topic, etc)

Let's do a bit of user research to figure out what the best option would be.

[its-a-lisa-at-work]

@afeld can we make this a little more broad around Repo Archiving? There have been a few folks asking recently asking if certain repos can be un-archived, and I'm not sure if there are questions I should be asking before doing that as an admin, or I should just blindly oblige with their request.

[its-a-lisa-at-work]

@afeld do you plan on answering https://github.com/18F/handbook/pull/1837/files#r379527111 with this update or earlier?

My 2 cents: I would say the caveat is that if you're going to unarchive a repository; you are now responsible for updating the dependencies.

[afeld]

do you plan on answering https://github.com/18F/handbook/pull/1837/files#r379527111 with this update

No, this issue is purely around the automated archiving that ghad's doing.

if you're going to unarchive a repository; you are now responsible for updating the dependencies

I'd say that's true for any non-archived repository (like, not just upon unarchiving), yeah. Should we add to the Handbook page?

[adborden]

Data.gov is also running into this, we have a lot of infrequently touched repos, but it's important that these repos stay un-archived so that we continue to get security alerts for dependencies.

Putting on my :thought_balloon: :tophat: I think https://github.com/18F/ghad/issues/27 is onto something that the owner needs to be notified. BUT, it's not about notifying that an archive happened, it's about notifying the owner that an action needs to be taken and :crossed_fingers: letting a human act before it's archived.

I would write this as:

In order to keep my GSA repositories up to date as per the 90-day GH repo bitrot policy, GH repo owners need to be notified that a repo is stale before the automated archive action takes place.

And what I would love to see (in BDD-style acceptance criteria format):

• [ ] GIVEN a repo I own is T-30 days stale (e.g 60 days without activity) AND ghad opens a GH issue on my repo explaining the policy and that if no action is taken the repo is archived WHEN I respond and close the issue opened by ghad THEN the stale timer resets and I have another 90 days before the repo is archived.
• [ ] GIVEN a repo I own is T-30 days stale (e.g 60 days without activity) AND ghad opens a GH issue on my repo explaining the policy and that if no action is taken the repo is archived WHEN I take no action on the issue opened by ghad after 30 more days THEN the repo is archived.

In other words, I would LOVE if ghad notified me by GH issue (because for active repos, any GH issues should be monitored) that an action needs to be taken. In an ideal world, we'd only have to close the issue as the action, but if we had to make a git commit --allow-empty to reset the timer, that would work too.

So the simplest implementation could be at the T-30 days mark, open an issue on the repo explaining that a commit (or whatever counts as activity) needs to happen or the repo will be archived in 30 days.

[afeld]

Have not been hearing a lot of complaints about this recently, so closing.

[bengerman13]

cloud.gov frequently runs into this, and we'd prefer to not have this auto-archive happen. For a few reasons, we have many repos that are infrequently updated, but are regularly used. Archiving these has several downsides for us:

• we stop getting dependabot alerts
• our users (internal and external) get confused: did I find the right repo, is this project still active, is it replaced by another project
• when we do want to make a change to a project, it creates extra work to unarchive it

This repo references the 18F Open Source Policy as rationale for why it does what it does, be the Open Source Policy says repos should be archived when they're no longer useful, not when they go a certain length of time without being updated

[afeld]

Does the new "Archive repositories…unless they have the MAINTAINED topic" feature solve that problem?

[bengerman13]

Technically, yes. But we manage over 200 repositories, and don't see any value from the auto-archive function, so putting the burden on us seems backwards to me

[adborden]

FYI Additional conversation in #infrastructure.

Personally, I think the MAINTAINED topic solution isn't ideal but better than the current state. I feel like part of the value of ghad should be providing a notification to teams... "hey, are you still paying attention to dependabot alerts, issues, and new PRs in this repo?". The MAINTAINED topic allows stale repos to exist indefinitely.

I think to @bengerman13 's point, the notification workflow doesn't quite help... unless the timeout was configurable, more like a year. There's still value in getting notified about really stale repositories, no?

[bengerman13]

There's probably some value in getting notified that a repository looks stale, but:

• 90 days seems too short. A year seems more reasonable for us
• it should be a notification, not an automated action

[bengerman13]

I'd like to keep this conversation going because this causes us work on a frequent (one or more times per week) basis, and means it's less likely that we'll get security notifications for code currently running on production systems. I'd really like a solution that does not put the burden on cloud.gov, because this functionality was added to our github organization without consultation or even notification. Creating work for our understaffed team to clean it up now seems unreasonable.