Backlog discussion
Current situation
Today, when we talk about prioritization, and working on Backlog issues, the Technical Writing team typically refers to open issues for docs improvements that are already assigned to them, for the groups where they are the named TW. This presents a number of challenges:
- When TW group assignments change, issues have to get reassigned to the incoming TW.
- Unassigned issues may be more urgent or deliver higher value to users, however they are not regularly reviewed or triaged.
- A shared, regularly reviewed backlog may provide more opportunities for issues suitable for community contributions.
- Resource planning does not take the full backlog of docs debt into account.
Backlog snapshots
In the gitlab
project, taking a snapshot in time of 2022-07-13, we could use the following two filters as a starting point for a shared documentation backlog clean up (excludes UI text). Excludes projects gitlab-runner
, omnibus-gitlab
, charts
, gitlab-docs
, gitlab-development-kit
, and technical-writing
.
We'd probably need at least two filters:
1. Milestone = Backlog
- Number of open issues: 663
- documentation
Milestone = Backlog
-
!=
typefeature -
!=
typebug - Link
2. Milestone = None
- Number of open issues: 1,277
- documentation
Milestone = None
-
!=
typefeature -
!=
typebug - Link
Note: The issues for filters 1 & 2 go back to 2015.
Other filters considered but rejected for initial cleanup:
(3) Filter option with technical writing and milestone !=
to 15.2:
- Number of open issues: 567
documentation
Technical Writing
Milestone != 15.2
- Link
(4) Filter option with technical writing and milestone=Backlog:
- Number of open issues: 351
documentation
Technical Writing
Milestone = Backlog
- Link
(5)Filter option where Assignee = None
- Number of open issues: 300
documentation
Technical Writing
Assignee = None
- Link |
(6) GitLab Analytics
Use the GitLab.org Analytics. For example:
- Total (last 12 months): 159
- Average per month: 10
documentation
Technical Writing
Milestone = Backlog
- Link
Backlog snapshots by stage
Using Filter 1 (Milestone = Backlog) and Filter 2 (Milestone = None), snapshot on 2022-07-14 of the distribution across Product Stages.
Stage | Backlog | None | Stage total |
---|---|---|---|
devopsmanage | 40 | 135 | 175 |
devopsplan | 35 | 47 | 82 |
devopscreate | 121 | 105 | 226 |
~"devops::ecosystem" | 41 | 33 | 74 |
devopsverify | 152 | 65 | 217 |
devopspackage | 12 | 3 | 15 |
~"devops::release" | 10 | 15 | 25 |
~"devops::configure" | 23 | 43 | 66 |
devopsmonitor | 20 | 21 | 41 |
devopssecure | 43 | 39 | 82 |
~"devops::protect" | 2 | 1 | 3 |
~"devops::analytics" | 8 | 6 | 14 |
devopsgrowth | 4 | 7 | 11 |
devopsfulfillment | 6 | 5 | 11 |
devopssystems | 49 | 227 | 276 |
~"devops::data_stores" | 11 | 38 | 49 |
Total | 577 | 790 | 1367 |
This view also highlights that there are a number of issues with no stage label.
How a shared backlog helps
- If an issue is not actively being worked on in the current of a near future milestone, it should not have a TW Assignee.
- If an issue is suitable for new or community contributors, it should be labelled and promoted with the community.
- If it is a valid issue, but with no plan to address it in an upcoming milestone, the Milestone is set to
Backlog
. - The issue should have a clear stage and group label so that it easy to review priorities by stage and group.
- Part of regularly reviewing backlog items includes triaging, scoping and applying workflowready for development type labels so that it is easier for team members and community contributors to move quickly to MRs.
- A shared, prioritized backlog gives TW team members the opportunity to work outside their assigned groups or pair with other team members on cross-group or cross-stage issues.