SIG Testing Project Board

[BenTheElder]

FYI @spiffxp and I have been keeping the sig-testing kubernetes-org project board fairly up to date.

In particular we're tracking "help wanted" issues in this column along with issues that need triage, our backlog, and issues in progress.

PTAL! If you need help picking up an issue or think we've missed something, shoot me a note :-)

Also curious if anyone has any feedback on the board, how it's being used, etc.

@spiffxp brought up some points about how we might interact with it better at our last SIG meeting, but we haven't really followed up on that discussion yet.

[dims]

cc @supriya-premkumar

[supriya-premkumar]

Thank you @dims, picked up an issue.

[BenTheElder]

thank you! :-)

[spiffxp]

@BenTheElder raised the point that org-level project boards don't support cross-org issues

So now we have two boards:

• sig-testing issues
  • admin given to @kubernetes/sig-testing-leads
  • write given to anyone in the org (add/move/update cards)
• sig-testing issues (kubernetes-sigs)
  • admin given to @kubernetes-sigs/{foo}-admins where foo is "boskos", "e2e-framework", "kind", "kubetest2"
  • write given to anyone in the org (add/move/update cards)

I tacked on "issues" on their names to repeat what I said in the meetings: tracking issues is the intent, not PR's. If a PR's not getting attention, post an update saying as much on the relevant issue (and/or move issue to blocked, poke your reviewers/approvers if it's been a few days, etc.)

I think I'd rather setup a @kubernetes-sigs/sig-testing-leads for consistency (ref: kubernetes/org#2559), but also have no strong opinions

[spiffxp]

FYI @amwat I moved in any open issues in kubetest2, moved anything that had a milestone out of "to triage" to "backlog
FYI @BenTheElder I only moved in kind issues that were milestoned, put in "backlog"

Made me notice neither of these repos have sig/testing on their issues. Would be good to do that to use GitHub queries consistently across the orgs. Maybe update issue templates to default to adding the label (e.g. https://github.com/kubernetes/k8s.io/issues/new?assignees=&labels=wg%2Fk8s-infra&template=general-support.md)

[BenTheElder]

Made me notice neither of these repos have sig/testing on their issues. Would be good to do that to use GitHub queries consistently across the orgs. Maybe update issue templates to default to adding the label (e.g. https://github.com/kubernetes/k8s.io/issues/new?assignees=&labels=wg%2Fk8s-infra&template=general-support.md)

Yeah, I recently realized we were relying on this in kubernetes org but didn't bother to add this yet because we couldn't put them into the project board anyhow.

It's really too bad we can't do these cross org.

[BenTheElder]

A lot of issues in test-infra are not tagged with a SIG either, should we be tagging issues with sig-testing there?

[spiffxp]

It's a tough call. I'm not sure that literally everything in there needs to be sig testing. Lots of job changes and such. Is it better to go through and remove the label after the fact, or periodically add it?

[spiffxp]

Triaging / grooming these boards regularly is still something I find:

• I am barely doing
• is largely invisible
• is Ben and I following our own instincts vs. documented rules in a playbook

I took a good look at "help wanted" a few weeks back to ensure issues were fresh/relevant/wanted. That may be the right cadence for adding/pruning.

But everything else I find myself wishing I had more time for. If we were to commit to periodic grooming once every N weeks, what's the right cadence?

• once every 1 weeks: keep things moving async off-cycle from meeting
• once every 2 weeks: line up with meeting cadence
• once every 4 weeks: line up with ~release dates (plan this cycle / KEPs, review progress, freeze/burndown pruning)

Whether it be boards, a meeting, triage party, or something else, I feel like we owe it to ourselves to write down something in the guidelines-to-playbook spectrum