Giters

kubernetes / steering

The Kubernetes Steering Committee

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Annual Reports Actions and Wrap Up

parispittman opened this issue · comments

commented

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
  • script or some other automated way that suggests folks to promote into owners files and who is no longer active to help sig leaders
  • ?

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
  • ?

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?
  • ?
commented

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

commented

/remove-lifecycle stale
/lifecycle frozen

commented

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.

commented

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

commented

for #207 (comment), 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
commented

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

commented

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

/close

commented

@parispittman: Closing this issue.

In response to this:

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. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.