Open Stack

[Resend from hopefully the correct address]

> On 4 Aug 2020, at 18:17, Hunt, James O <james.o.hunt at intel.com> wrote:
> 
> # 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.

Could you add me to the reviewer rota for EMEA?

> 
> 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].

Could we mark them with a "stale" label rather than auto-close?

Often, really old stuff is still relevant. It takes a human reviewer to determine if it's for example a bug that nobody reproduced, in which case auto-close makes sense, or a feature that nobody implemented, but that we all see as useful, in which case auto-close is counter-productive.

> 
> 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.

Do you think it's possible to also move the original issue to a "PR" state?

> 
> 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 ;-)

I will try to spend a bit more time on reviewing. These tools help.

> 
> 
> 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+
> [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
> Open Source Technology Center
> Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20200805/da5f8d01/attachment-0001.html>