Plan for organizing the kata issue backlog
Hi everyone. As part of the work we are doing to reduce and organize the issue backlog we have thought about a potential split of the open issues into *buckets* and a proposed plan to work on these buckets. Overall there are currently 1,019 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+sort%3Arepository+> . Out of these there are 106 open issues with attached PRs <https://github.com/issues?page=1&q=is%3Aissue+is%3Aopen+org%3Akata-containers+linked%3Apr+sort%3Arepository> and as Christophe suggested, these issues will be moved into an in-progress on the issue backlog board <https://github.com/orgs/kata-containers/projects/23> and will not be part of our backlog grooming work. Looking at the remaining issues we propose to split them as follows: - Issues opened this year (333 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+>) and everything else (686 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3C%3D2020-01-01+> ) - Another split of issues opened this year which are bugs (112 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+label%3Abug+-linked%3Apr+sort%3Arepository+>) and not bugs (174 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+-label%3Abug+-linked%3Apr+sort%3Arepository+> ) - For not bugs splitting to kata-2.0-features (45 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+-label%3Abug+label%3Akata-2.0-features+-linked%3Apr+sort%3Arepository+>) and not (129 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+-label%3Abug+-label%3Akata-2.0-features+-linked%3Apr+sort%3Arepository+> ) - Once we finish with this years issues we will move on to handle the previous year issues *Our proposed approach is as following:* - Every week we will focus as a community on one of the buckets and will also use the bi-monthly backlog review meetings to help focus - For each issue reviewed the reviewer should check if that issue can be closed (duplicate, not relevant, etc...) or is a valid issue - If you believe this is a valid issue remove the "needs-review" label to indicate the issue has been triaged (or ping James/me to to do it) - Later on once we have finished with reviewing the issue backlog we can then move on to decide on adding new labels (such as MVP) and removing/joining old labels *Propose timeframe:* - 2nd week of August - issues opened this year which are not bugs and are labeled kata-2.0-features (45 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+-label%3Abug+label%3Akata-2.0-features+-linked%3Apr+sort%3Arepository+> ) - 3rd week of August - issues opened this year which are bugs (112 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+label%3Abug+-linked%3Apr+sort%3Arepository+> ) - 4th week of August - issues opened this year which are not bugs and are not labeled kata-2.0-features (129 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+-label%3Abug+-label%3Akata-2.0-features+-linked%3Apr+sort%3Arepository+> ) - 1st week of September - starting to work on issues from previous years depending on our progress Let us know if this plan makes sense, if you have comments or other suggestions. Thanks.
SGTM - thanks for driving this! On Mon, Aug 10, 2020 at 10:20 AM Ariel Adam <aadam@redhat.com> wrote:
Hi everyone. As part of the work we are doing to reduce and organize the issue backlog we have thought about a potential split of the open issues into *buckets* and a proposed plan to work on these buckets.
Overall there are currently 1,019 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+sort%3Arepository+> . Out of these there are 106 open issues with attached PRs <https://github.com/issues?page=1&q=is%3Aissue+is%3Aopen+org%3Akata-containers+linked%3Apr+sort%3Arepository> and as Christophe suggested, these issues will be moved into an in-progress on the issue backlog board <https://github.com/orgs/kata-containers/projects/23> and will not be part of our backlog grooming work.
Looking at the remaining issues we propose to split them as follows:
- Issues opened this year (333 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+>) and everything else (686 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3C%3D2020-01-01+> ) - Another split of issues opened this year which are bugs (112 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+label%3Abug+-linked%3Apr+sort%3Arepository+>) and not bugs (174 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+-label%3Abug+-linked%3Apr+sort%3Arepository+> ) - For not bugs splitting to kata-2.0-features (45 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+-label%3Abug+label%3Akata-2.0-features+-linked%3Apr+sort%3Arepository+>) and not (129 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+-label%3Abug+-label%3Akata-2.0-features+-linked%3Apr+sort%3Arepository+> ) - Once we finish with this years issues we will move on to handle the previous year issues
*Our proposed approach is as following:*
- Every week we will focus as a community on one of the buckets and will also use the bi-monthly backlog review meetings to help focus - For each issue reviewed the reviewer should check if that issue can be closed (duplicate, not relevant, etc...) or is a valid issue - If you believe this is a valid issue remove the "needs-review" label to indicate the issue has been triaged (or ping James/me to to do it) - Later on once we have finished with reviewing the issue backlog we can then move on to decide on adding new labels (such as MVP) and removing/joining old labels
*Propose timeframe:*
- 2nd week of August - issues opened this year which are not bugs and are labeled kata-2.0-features (45 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+-label%3Abug+label%3Akata-2.0-features+-linked%3Apr+sort%3Arepository+> ) - 3rd week of August - issues opened this year which are bugs (112 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+label%3Abug+-linked%3Apr+sort%3Arepository+> ) - 4th week of August - issues opened this year which are not bugs and are not labeled kata-2.0-features (129 open issues <https://github.com/issues?q=is%3Aissue+is%3Aopen+org%3Akata-containers+created%3A%3E2020-01-01+-label%3Abug+-label%3Akata-2.0-features+-linked%3Apr+sort%3Arepository+> ) - 1st week of September - starting to work on issues from previous years depending on our progress
Let us know if this plan makes sense, if you have comments or other suggestions.
Thanks.
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
On Mon, 10 Aug 2020 at 18:21, Ariel Adam <aadam@redhat.com> wrote:
- Later on once we have finished with reviewing the issue backlog we can then move on to decide on adding new labels (such as MVP) and removing/joining old labels
Regarding reviewing the labels, this should help explain the current
situation and summarise our current labels, hence if you're interested in helping review the labels, please have a read: https://github.com/kata-containers/tests/issues/2778 I think the standard set of GitHub labels are a little too minimal for a project of this size and complexity. However, you could argue that our current set of labels is too large :-) What we're aiming for I think is a balance between intuitiveness and flexibility; in an ideal world those on the Kata rota would be able to quickly categorise a new issue with a small set of labels. That would pay dividends as we'd then be able to "data mine" metrics based on the labels. As we start to use features like GitHub actions more we could potentially auto-add labels (a good example being adding a sizing to a PR ("size/huge" to "size/tiny") which could be auto-derived by the CI based on LOC changed / cyclomatic complexity for example). 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.
It's really appreciated. ------------------------------------------------------------------ From:Ariel Adam <aadam@redhat.com> Send Time:2020年8月11日(星期二) 01:20 To:kata-dev <kata-dev@lists.katacontainers.io> Subject:[kata-dev] Plan for organizing the kata issue backlog Hi everyone. As part of the work we are doing to reduce and organize the issue backlog we have thought about a potential split of the open issues into buckets and a proposed plan to work on these buckets. Overall there are currently 1,019 open issues. Out of these there are 106 open issues with attached PRs and as Christophe suggested, these issues will be moved into an in-progress on the issue backlog board and will not be part of our backlog grooming work. Looking at the remaining issues we propose to split them as follows: Issues opened this year (333 open issues) and everything else (686 open issues) Another split of issues opened this year which are bugs (112 open issues) and not bugs (174 open issues) For not bugs splitting to kata-2.0-features (45 open issues) and not (129 open issues) Once we finish with this years issues we will move on to handle the previous year issues Our proposed approach is as following: Every week we will focus as a community on one of the buckets and will also use the bi-monthly backlog review meetings to help focus For each issue reviewed the reviewer should check if that issue can be closed (duplicate, not relevant, etc...) or is a valid issue If you believe this is a valid issue remove the "needs-review" label to indicate the issue has been triaged (or ping James/me to to do it) Later on once we have finished with reviewing the issue backlog we can then move on to decide on adding new labels (such as MVP) and removing/joining old labels Propose timeframe: 2nd week of August - issues opened this year which are not bugs and are labeled kata-2.0-features (45 open issues) 3rd week of August - issues opened this year which are bugs (112 open issues) 4th week of August - issues opened this year which are not bugs and are not labeled kata-2.0-features (129 open issues) 1st week of September - starting to work on issues from previous years depending on our progress Let us know if this plan makes sense, if you have comments or other suggestions. Thanks.
participants (4)
-
Ariel Adam
-
Eric Ernst
-
Hunt, James O
-
Xu Wang