Release Team: Explore the idea of "an issue triage team"

[furkatgofurov7]

What would you like to be added (User Story)?

Explore the idea of "an issue triage team" - a team that is responsible for triaging issues that come into the repo.

Detailed Description

We could consider having a dedicated team in the Release Team to track down the issues in the milestone and make sure they are making their way on time. More in detail, it includes keeping an eye on upcoming new features/KEPs planned to be implemented in the release cycle early to be able to evaluate how much work will be coming later in the release cycle, start pinging issue/PR authors in the milestone asking for updates and informing them about important dates, i.e code freeze, test freeze etc so that they are aware of deadlines and act accordingly (push forward the issues/PRs or trying it for the next release cycle).

Anything else you would like to add?

Based on my best knowledge and experience being a Bug Triage Shadow (v1.27) and Bug Triage Lead (v1.28) for the k8s release team, the team should be responsible for things, such as:

• Listing open issues and PRs targeted for the ongoing release cycle
• Communicating with relevant assignees, owners, and SIG leads of issues/PRs to get the status
• Updating issues/PRs, clarifying situations, enabling next level decision making
• Presenting summary reports at release team meetings
• keeping track of issues/PRs against the current milestone

Usually, team responsibilities overlap with CI team responsibilities and much of the work is automated. There is a dedicated GH board for the Bug Triage Team where new issues and PRs that target the current release milestone are automatically added with a a prow job. The prow job is defined in kubernetes/test-infra and the script can be found in kubernetes/sig-release.

v1.28 v1.29 Bug Triage team has been will be the last one and starting from v1.29 v1.30 CI and Bug Triage Teams will be merged into one and will be called (Release Signal Team), xref: kubernetes/sig-release#2209 & https://kubernetes.slack.com/archives/C2C40FMNF/p1683653821820689.

More info on k8s Bug Triage team: https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/bug-triage/README.md

I am just not sure if we should have a bug triage team in CAPI, considering the amount of issues/PR we get and how efficient would team be. We could perhaps make use of milestones more frequently compared to now and so there will be more work to do, but we do not have currently complicated schedule as k8s has and even they decided to merge the team into one.
On the other hand, we could expand current CI teams responsibilities with more of bug triage team responsibilities I listed above and have single team as we have now which aligns with coming v1.29 v1.30 k8s Release team 🙂

However, I am open to hearing other opinions and discussions!

Label(s) to be applied

/kind documentation
/area release

Tracked in: #9104

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[furkatgofurov7]

@kubernetes-sigs/cluster-api-release-team
cc @killianmuldoon @CecileRobertMichon @sbueringer since this was the sub-task I wanted to discuss during our triaging call but we could not make time for it.

[furkatgofurov7]

/assign

[killianmuldoon]

AFAIU there's two different sets of tasks described here:

1. Track issues related to the milestone
2. Track and triage bugs

IMO there's no real scope for (1) right now. CAPI doesn't normally have a roadmap or a discrete set of features set for a release at the outset of a release. Having some sort of roadmap process is a pre-requisite to having a set of tasks relating to tracking, following progress on and updating individual PRs in relation to a milestone. If we want to try to have the roadmap discussion again we should bring it up in the community meeting.

For (2) I think it could be interesting to add something like bug triage to the CI team's tasks. Currently that triage is mostly done by a small group of reviewers - but that group is also the group that tends to fix the bugs.

If the CI team were to take on triage what improvements could we expect from the current state?

[furkatgofurov7]

2. Track and triage bugs

To be clear and sorry if it was not clear, k8s Bug Triage Team did not have to triage issues themselves (it is most or all of the time the responsibility of the SIG leads where the change is proposed in the codebase), but rather track them in the GH board, ping corresponding SIG leads (over issue/slack or mailing list) if they are not responding and make sure bug is resolved on a timely manner.

For (2) I think it could be interesting to add something like bug triage to the CI team's tasks. Currently, that triage is mostly done by a small group of reviewers - but that group is also the group that tends to fix the bugs.

That is interesting, but I am not sure we could ask CI team members to triage the bugs since as you are already pointing out it is not trivial and tied to a small set of ppl usually from my experience. Instead, we could propose and expand the team tasks so that the team makes sure to track the upcoming issues in the milestone fully (same responsibilities as k8s team)?

If the CI team were to take on triage what improvements could we expect from the current state?

I don't have a definite answer to this at this point tbh

[furkatgofurov7]

/cc @fabriziopandini

[sbueringer]

As of today 90%+ of all incoming issues are handled by the same 2-3 people (situation for PR reviews is very similar btw). If we want to establish something around issue triage I think it has to have a clear benefit for these folks.

If it would come down to having a team that puts more pressure on these folks that are already entirely overloaded I don't think that would be a good idea.

Currently I don't see how "sig-level" triaging/routing would help in CAPI.

To be clear, I would be delighted to get help there, but it has to actually help 😀

[furkatgofurov7]

My take on this is, that we might not need a whole dedicated team for triaging issues in CAPI, because the volume of issues coming into the project can't be comparable to the k8s, and even k8s project RT itself went down the path of merging the team into CI signal.

Currently I don't see how "sig-level" triaging/routing would help in CAPI.

it won't obviously, we don't have such a process and that was an example given on how incoming issues mostly triaged and handled in k8s

[fabriziopandini]

Most of the issues are not relevant for cutting release: if they make it, good, otherwise next release.
Based on this observation, IMO it doesn't make sense for the release team to triage and track all of them, while it could make sense to track some issue the maintainer points out as a release blocking.

But, if someone on the release team, or some individual wants to pick up some issues and help in getting rid of them, this will be really appreciated.

[furkatgofurov7]

Thanks everyone for responses.

Based on the conversations, I feel like we need to stick to current processes we defined, where CI team should help with release blocking issues pointed out by maintainer, but it is not the responsibility of the team to track all issues in the repo. Since the former one is already documented in our release team tasks doc, I will go ahead and close this issue.

/close

[k8s-ci-robot]

@furkatgofurov7: Closing this issue.

In response to this:

Thanks everyone for responses.

Based on the conversations, I feel like we need to stick to current processes we defined, where CI team should help with release blocking issues pointed out by maintainer, but it is not the responsibility of the team to track all issues in the repo. Since the former one is already documented in our release team tasks doc, I will go ahead and close this issue.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.