# 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/label... --- 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.
On 4 Aug 2020, at 18:17, Hunt, James O <james.o.hunt@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/label... --- 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@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
Hi Christophe, On Wed, 5 Aug 2020 at 10:59, Christophe de Dinechin <cdupontd@redhat.com> wrote:
Could you add me to the reviewer rota for EMEA?
Thanks! And done: https://github.com/kata-containers/community/wiki/Review-Team-Rota Aside: I've also swapped Penny with Jianyong Wu after Penny's recent post, but feel free to update the wiki if you'd like Penny/Jianyong!
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.
I like this idea. We already have a stale label and we can just tweak the stalebot config to specify "daysUntilClose = flase" to only add the "stale" label.
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?
I'm not sure I follow what you mean here?
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.
Thanks very much Christophe! ;) Cheers, James --- 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.
On 5 Aug 2020, at 13:02, Hunt, James O <james.o.hunt@intel.com> wrote:
Hi Christophe,
On Wed, 5 Aug 2020 at 10:59, Christophe de Dinechin <cdupontd@redhat.com> wrote:
Could you add me to the reviewer rota for EMEA?
Thanks! And done:
https://github.com/kata-containers/community/wiki/Review-Team-Rota
Aside: I've also swapped Penny with Jianyong Wu after Penny's recent post, but feel free to update the wiki if you'd like Penny/Jianyong!
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. I like this idea. We already have a stale label and we can just tweak the stalebot config to specify "daysUntilClose = flase" to only add the "stale" label.
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?
I'm not sure I follow what you mean here?
Normally, we have a PR and the issue that the PR addresses. I understood your point 6 above as having a Kanban board specifically for PRs. But I think it would be helpful if we found a way, when creating the PR, to automatically move the issue(s) the PR addresses to some special "PR" state. In JIRA, you can have multiple states in the same column, so you could consider "PR" as a kind of "in progress" state. Or it could have its own column.
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. Thanks very much Christophe! ;)
Cheers,
James --- https://katacontainers.io/ | https://github.com/kata-containers Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
On Wed, 5 Aug 2020 at 12:49, Christophe de Dinechin <dinechin@redhat.com> wrote:
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?
I'm not sure I follow what you mean here?
Normally, we have a PR and the issue that the PR addresses.
I understood your point 6 above as having a Kanban board specifically for PRs.
But I think it would be helpful if we found a way, when creating the PR, to automatically move the issue(s) the PR addresses to some special "PR" state. In JIRA, you can have multiple states in the same column, so you could consider "PR" as a kind of "in progress" state. Or it could have its own column.
Ah - I see what you mean. Yes, that would be useful. The simplest solution would be to have automation to move the issue from the "To do" column to the "In progress" column if the issue satisfies the "linked:pr" GitHub query. You can already do this dynamically to see a subset of the backlog by just typing "linked:pr" into the "filter cards" text box on [1], but making that the default view show these two separate categories of issue (those with an associated PR, and those without) visually may be best for clarity. Any thoughts on this Ariel? Cheers, James [1] - https://github.com/orgs/kata-containers/projects/23 --- 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.
On Wed, Aug 5, 2020 at 4:02 PM Hunt, James O <james.o.hunt@intel.com> wrote:
On Wed, 5 Aug 2020 at 12:49, Christophe de Dinechin <dinechin@redhat.com> wrote:
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?
I'm not sure I follow what you mean here?
Normally, we have a PR and the issue that the PR addresses.
I understood your point 6 above as having a Kanban board specifically for PRs.
But I think it would be helpful if we found a way, when creating the PR, to automatically move the issue(s) the PR addresses to some special "PR" state. In JIRA, you can have multiple states in the same column, so you could consider "PR" as a kind of "in progress" state. Or it could have its own column.
Ah - I see what you mean. Yes, that would be useful. The simplest solution would be to have automation to move the issue from the "To do" column to the "In progress" column if the issue satisfies the "linked:pr" GitHub query. You can already do this dynamically to see a subset of the backlog by just typing "linked:pr" into the "filter cards" text box on [1], but making that the default view show these two separate categories of issue (those with an associated PR, and those without) visually may be best for clarity. Any thoughts on this Ariel?
I think that's a really good idea :-). We could argue that an issue can be "in progress" without a PR associated yet however for simplicity it makes sense that moving an issue from "to do" to "in progress" would be triggered by an attached PR. We could then simplify our "quick filters" (the searches using different labels and fields) to split issues into buckets without constantly adding PR yes/no.
Cheers,
James
[1] - https://github.com/orgs/kata-containers/projects/23 --- 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. _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
Hi All, # Testing some GitHub Actions I tested the following GitHub actions which all claim to be able to assign issues to projects. Here are the super-brief results: - https://github.com/marketplace/actions/assign-to-one-project Result: FAIL Detail: Weird 'yq' command errors. - https://github.com/marketplace/actions/github-project-automation Result: FAIL Detail: Doesn't understand the difference between the three different GitHub project types. Crucially, it only seems to work with repo-level projects, but our new issue backlog project [1] is an organisation-level project. - https://github.com/marketplace/actions/automate-projects Result: PASS Details: It works! ;-) Rationale: License is APACHE-2.0. It supports org-level GitHub projects. Code looks simple and the config allows the clear specification of the project and the project board column to add the issues to. # Next steps I've raised a PR [2] on the throttler repo to enable the "automate projects" action [3]. Once that lands and we've tested that it DTRT [4], I'll go ahead and raise similar PRs for all the other repos (1.x and 2.x). # Review request I've reviewed the licence and the code for [3], but I'd like others to do the same please. Further details are on the PR [2]. Cheers, James [1] - https://github.com/orgs/kata-containers/projects/23 [2] - https://github.com/kata-containers/ksm-throttler/pull/158 [3] - https://github.com/marketplace/actions/automate-projects [4] - I've already tested this with another GitHub organisation but let's be cautious.
participants (4)
-
Ariel Adam
-
Christophe de Dinechin
-
Christophe de Dinechin
-
Hunt, James O