Annual Reports Actions and Wrap Up

[parispittman]

Issue to collect our notes from the summary and meetings about actions we need to take for next year as well as topics that need to have follow up:

Build:

• creating a template and a generator of some kind so it's not a manual add for the summary by steering and better user experience for the survey taker
  • cc/ @cblecker
• script or some other automated way that suggests folks to promote into owners files and who is no longer active to help sig leaders
  • https://github.com/cncf/devstats/issues/299 - can we get this one done?
• ?

Look into:

• how to do better outreach to inform chairs and deadlines
  • post schedule to markdown in policy and then link to #chairs-and-techleads, leads@, steering@
  • make sure there are clear actions and steps
  • link up with contributor-comms
  • create: k8s.dev/reports
• creating a devstats dashboard for each sig with the populated dashboards that steering cares about and automation around the things we have APIs for like YouTube and automate the entire "operational" section
  • https://github.com/cncf/devstats/issues/229 - should we play off of this?
  • could we use lfx mentees or other mentoring groups?
• ?

Follow up:

• ask psc member / sig security to come to a chair/tl meeting for how to handle a cve response and q&a/feedback between groups (this came from annual reports from multiple sig chairs)
  • Paris asked Tabitha and Tim their thoughts and trying to schedule for Dec Chairs/TLs meeting
• ?

Discussion needed; Decisions to follow up in PRs:

• some wgs don't report into all of their sponsoring sigs; does this matter? some wgs have many - can we help streamline this?
• more meeting cadence: do sigs that are in a near maintenance mode need to have the same requirements?
• ?

[cblecker]

/assign

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[justaugustus]

/remove-lifecycle stale /lifecycle frozen

[tpepper]

A couple notes:

some wgs don't report into all of their sponsoring sigs; does this matter? some wgs have many - can we help streamline this?

I definitely think this matters. As a (singular) project we need to all give some attention to cohesion. IMHO WGs must keep their sponsor, and just "adjacent", SIGs informed.

As a past SIG and WG chair I really wished for a standard way of setting a reminder, a cron job of sorts, for all sorts of coordination activities, eg: check in with my sponsor/adjacent SIG, check for newly activated folks who might should be reviewers, check for reviewer-to-approver promotion candidates, annual check for new TL or Chair candidates, etc., etc. There is a tonne of leadership activity that is ongoing, but easily always at the end of the to-do list and thus not done as regularly as it should be. Sure this may just come down to a personal need to be well organized. But could we do some automated reminders? Would that help, or just get lost in the noise?

more meeting cadence: do sigs that are in a near maintenance mode need to have the same requirements?

I can see giving some (informal?) allowance, if the SIG/WG has formally indicated it has slowed but still has some outstanding deliverable which is not easily shifted under another SIG as a subproject. I worry that the allowance alone becomes a causal/contributing source of silence and shutdown, instead of being a trailing recognition of pending shutdown. If established folks think things are mostly done, but newcomers don't have a place to voice their ideas, we risk prematurely ending collaboration possibilities.

[justaugustus]

Assigning Jordan and myself for this agenda doc item:

Jordan+Stephen: look at last year’s reports, specifically note the things for which there was not a tool and that meant human toil, give concrete ask instead of broad help to devstats dev

/assign @liggitt @justaugustus

[liggitt]

for https://github.com/kubernetes/steering/issues/207#issuecomment-984871009, I did a quick pass over the questions in the annual report template from last year, noting questions that seemed likely targets for partial or complete automation:

"Meeting recordings up to date?"

• full: should be able to pull this info automatically from the community group playlist

"When was your last public community-wide update? (provide link to deck and/or recording)"

• full: should be able to pull this info from community meeting schedule

"Are all listed SIG leaders (chairs, tech leads, and subproject owners) active?"

• partial: should be able to determine if there's complete inactivity by intersecting devstats and sigs.yaml

"Does the group have contributors from multiple companies/affiliations? Can end users/companies contribute in some way that they currently are not?"

• partial: could measure this somewhat by checking company affiliation in leads/subproject owners in sigs.yaml
• partial: could measure this somewhat by checking company affiliation of authors/reviewers/approvers for issues/PRs tagged with the sig

"Current initiatives"

• "Currently underway"
  • partial: could generate a skeleton of open enhancement issues for the sig, grouped by maturity level / release added / last release targeted / etc
• "Year to date KEP work"
  • full: should be able to be generated

"How does the group get updates, reports, or feedback from subprojects? "Same question as above but for working groups."

• This is unstructured now, so there isn't a way to generate an answer to this, but a common theme was sigs losing touch with their subprojects / working groups
• If subproject/wg report/check-in was structured, that could help close the communication gap and make the answer to this automatable for annual reports

"Are there any [subprojects, wgs] springing up or being retired?"

• partial: Delta over the last year should be automatically deriveable from sigs.yaml

"Are OWNERS.md files up to date in these areas [subprojects, wgs]?"

• partial: Tooling to flag inactive folks in OWNERS files could help with a baseline here

[parispittman]

quick notes re: @liggitt comments above, numbered by bullet

1 - add to liaison duties 2 - we don't have community meeting requirements anymore so liaison will need to ask this question and then pull whatever it is - kubecon, email to sig list, etc. 3 - add to liaison duties 4 - add to liaison duties to pull devstats for the sig; keep the second half of the question open since that's a key part of the summary since the audience is most end users and heavy contributors 5 - if we add to liaison duties - how can they pull that easily? 6 - same question as 5 7 and 8 - add to liaison duties to help their sig come up with a process for subproject check ins 9 - add to liaison list to pull a delta of changes from sigs.yaml 10 - @dims to solidify tooling and advertise

228 - related

[parispittman]

we have open issues or it's done so this is safe to close

/close

[k8s-ci-robot]

@parispittman: Closing this issue.

In response to [this](https://github.com/kubernetes/steering/issues/207#issuecomment-1018069537): >we have open issues or it's done so this is safe to close > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.