# TL;DR
Our issue backlog is huge. We intend to resolve this. If you'd like to get involved, please let us know!
# Background
As discussed in the Architecture Committee meeting earlier today, we're planning to attack the issue backlog as it hasn't been reviewed holistically for... maybe ever!
I've added details on the issues to the Kata Rota wiki page [1], so if you are on the rota it would be great if you could start looking at issues too.
We currently have 1,023 open issues [2], 922 of which don't have associated PRs (meaning they are _not_ "in progress") so we have a bit of work to do! ;-)
# Work done so far
1) Ariel and I have had a brainstorming session to come up with a simple plan for attacking the backlog.
2) We've created a new GitHub project Kanban board [3] with the intention of using this to manage the issue backlog.
3) We've written a simple CLI tool using hub [6] that can add issues to github projects.
# The plan
1) Make use of one of the GitHub actions [4][5] that can be used to auto-add newly opened issues from *all* the Kata repos into the new project.
2) Run the hub script as a "one off" to add the existing open issues in all the repos into the new project.
3) Hold a regular (probably weekly) meeting to review the backlog on the Kanban board [3].
3.1) Consider re-enabling the stalebot [3.1] trigger [3.2] that used to auto-close issues that hadn't seen activity for a long time [3.3].
4) Start making better use of labels to allow us to categorise and data-mine the backlogs.
For example, more intelligent handling of bug and feature issues for example, ensuring they are applied and also back-ported and forward-ported as appropriate. We actually have a YAML database that documents all our GitHub labels [7] along with some simple tooling to keep the list of labels across the repos in sync.
4.1) We probably need to review the (rather large) list of labels and refine it slightly.
Once we have a more refined set of labels, we should consider trying to make better use of them (for issues and PRs) particularly at the issue triage stage to categorise the issues.
5) Report back to the Architecture Committee on progress and findings.
6) Consider creating a Kanban board for the PR backlog to make that easier to manage too.
7) Share what we've learnt with the community
Explain the new Kanban process and best practises for labelling issues.
# Feedback
The task of actually reducing the issue backlog could take some time and we may need to modify our approach as we learn more.
As always, if anyone has thoughts on the above, please let us know. We'll assume "silence means compliance"! :-)
# Willing helpers (that means you!)
If you'd like to get involved in any of the above (particularly the actual reviewing of issues), again, please let us know ;-)
Cheers,
James
[3.3] - Maybe; I'd like to think that we won't need to use such a feature if we can reduce the backlog down to a more manageable size.
---
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.