Open Stack

# 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

[1] - https://github.com/kata-containers/community/wiki/Review-Team-Rota
[2] - https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers
<https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+>+
[3] - https://github.com/orgs/kata-containers/projects/23
[3.1] - https://github.com/apps/stale
[3.2] -
https://github.com/kata-containers/.github/blob/master/.github/stale.yml
[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.
[4] - https://github.com/marketplace/actions/assign-to-one-project
[5] - https://github.com/marketplace/actions/github-project-automation
[6] - https://github.com/github/hub
[7] -
https://github.com/kata-containers/tests/blob/master/cmd/github-labels/labels.yaml.in
---
https://katacontainers.io/ | https://github.com/kata-containers
<https://github.com/clearcontainers>
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3
1RJ.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20200804/1b284166/attachment.html>