The aim of ticket gardening is to ensure that items tracked on GitLab stay relevant and contain helpful information for bringing a task to completion. To achieve this goal contributors and teams need to be made aware of the existence of issues that need their input so they can self-organize and prioritize their work. Issues that are not relevant anymore should be closed.

This work should be done twice per year.

Tasks

Manual tasks

Go through relevant GitLab views

  • T:Wait label: check if what was blocking was eventually resolved outside of Tails. Issues should either have an assignee, their T: label requalified, be rejected, or stay in this state.

  • WIP without assignee: identify issues that have a majority of work completed and could somewhat easily be finished. Create a list of those issues and send them to the responsible team; if that team cannot handle these issues, set the status label to something other than Doing.

Identify and fix inadequate milestone

XXX: the missed:$VERSION GitLab label, added by the RM when postponing issues and MRs, would allow us to automate this.

Some issues are missed by our automated setup. These issues are those whose milestone has been postponed after the N last releases by the Release Manager: every such milestone bump counts as an update so there's no chance the issue will ever be identified as stalled. Hence we need to do a manual session of ~2 hours twice a year to drop the milestone on some issues. To select the corresponding issues, we will thus select those that have the next release as their milestone, and triage them using the following criteria:

Situations when dropping the milestone would be inadequate:

  • If the issue was (re)assigned to the assignee recently.
  • If there's been progress but it's not documented on the issue.
  • If it's part of a sponsor deliverable.
    • If the official deadline is in the future, most of the time we don't want to touch the milestone.

Whether it's appropriate to drop the milestone depends on:

  • When the last action on the issue by the assignee was performed. For example, if they did not update the issue since 3 months or more.
  • If the issue was recently postponed be the RM and not by the assignee themselves — the latter would suggest they have it in mind and are updating their plans.
  • Whether there's an assignee. If there's none but the issue was postponed a few times, then:
    • Either it's important and it should be put on the plate of a core team.
    • Or it's unimportant and the milestone should be dropped: keeping it has little value but forces the RMs to do extra work. If someone wants to track those issues, there surely are better ways.
  • Whether the issue is blocked by anything (other issues or what not) that's out of the hands of the assignee.
  • How safe/privileged is the assignee's position in Tails. For contributors that hold more power than average we can assume they know how to revert our changes.

We have a template message that we can use as a basis to explain why we're removing the milestone.

Existing automation

  • WIP stalled for a while

    Issues assigned to somebody, labeled Doing, and not updated in the last 180 days.

    An email reminder sends everyone the list of such issues that are assigned to them, asking them if they think they can realistically come back to it and finish the work in the next 6 months. If yes, they should set a suitable milestone and when relevant, the relevant "Core work: $team" label. Else, the contributor should clear the Assignee field and bring it to the attention of the relevant team.

  • Stalled merge requests

    Merge requests assigned to somebody not updated in the last 45 days.

    An email reminder sends everyone the list of such MRs that are assigned to them, suggesting them to take a look there.