Skip to content

Cleaning up stale training issues in Support Training

Request for comments: Cleaning up stale training issues in Support Training

Need

The Support Training project has 800+ open issues, some dating back to 2017. Many are assigned to people who've left the team or moved departments, others are just forgotten. This makes it hard to see what's actually being worked on.

Approach

Use gitlab-triage (the same tool we use in request-for-help) to automatically clean up stale issues.

If a training issue hasn't been updated in 1 month, it gets a comment asking if it's still relevant. If no one responds within a week, it gets closed automatically.

We'd set up a .triage-policies.yml file similar to what's already working in the Request for Help project, then let it run on a schedule. Issues that are still important will get a quick response when reminded.

Benefit

This follows a pattern that's already proven to work in our organization, requires minimal setup time, and runs itself once configured. It gives people a reasonable chance to respond (1 month is plenty of notice) while steadily reducing the backlog without any ongoing manual effort from the team.

The main win is that we'll finally be able to see what's actually active versus what's just legacy clutter, and new team members won't be overwhelmed by ancient issues that no one cares about anymore.

A nudge from the bot may also encourage team members to complete training issues as well.

Competition / Alternatives

  1. Do nothing
  2. Do this manually as a one off, but the problem would eventually return

Questions

  1. Is 1 month too much time or not enough?
  2. Should we exclude certain types of issues from this initiative?
  3. Do you have any concerns about the auto close approach proposed?

Due date for feedback is 2025-07-04.