[kata-dev] Issue backlog
Hunt, James O
james.o.hunt at intel.com
Tue Aug 4 16:17:26 UTC 2020
Our issue backlog is huge. We intend to resolve this. If you'd like to get
involved, please let us know!
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 , 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 , 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  with the intention
of using this to manage the issue backlog.
3) We've written a simple CLI tool using hub  that can add issues to
# The plan
1) Make use of one of the GitHub actions  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.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  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.
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 ;-)
 - https://github.com/kata-containers/community/wiki/Review-Team-Rota
 - https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers
 - https://github.com/orgs/kata-containers/projects/23
[3.1] - https://github.com/apps/stale
[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.
 - https://github.com/marketplace/actions/assign-to-one-project
 - https://github.com/marketplace/actions/github-project-automation
 - https://github.com/github/hub
https://katacontainers.io/ | https://github.com/kata-containers
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kata-dev