Update Meeting Times and Cadence

[jeremyrickard]

trafficstars

As discussed in the 24 May Release Engineering Meeting, we should consider merging the SIG Release Meeting and the Release Engineering subproject meetings. Along with this, we should take a moment and consider alternate times or alternating meeting times.

Some items mentioned in the releng meeting:

• Often the SIG Release and Release Engineering meetings have topics that skew toward the other meeting
• The current time slot is not especially friendly to those in Pacific Time
• The current time slot competes with other relevant meetings, including OpenSSF things

Proposal:

• Combine SIG Release and releng meetings
• Alternate time slots (1 aligned with EU/Eastern US, 1 aligned more with Pacific Time)
• Explicitly document and clarify conditions for cancelling meetings based on lack of agenda

TODO:

[ ] Communicate to mailing list(s) [ ] Determine new time(s) [ ] Update calendar invites [ ] Update / merge meeting notes [ ] Update community documentation [ ] Work to better follow agenda cutoff

/sig release /kind documentation /priority important-soon

[jeremyrickard]

cc: @justaugustus @saschagrunert @puerco @cpanato

[saschagrunert]

I generally like the proposal 👍

Additionally I’d like to clarify when and under which conditions meetings get cancelled.

For example: We propose in slack to cancel the meetings if no agenda item is available around 1 day before they happen. If folks still want to meet and walk the board, or for example have a late agenda item, then we will use that conversation to negotiate.

[jrsapi]

I'm in agreement with the proposal.

My hope by staggering the hours we can be more time zone exclusive for those who are not able to attend the current time.

[JamesLaverack]

👍

Agree that SIG Release and Release Engineering meetings, in their current form, kind of merge together. I'm in support of this proposal.

[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

[jeremyrickard]

/remove-lifecycle stale

[jeremyrickard]

Going to close this one out, since we've updated all the things.

/close

[k8s-ci-robot]

@jeremyrickard: Closing this issue.

In response to this:

Going to close this one out, since we've updated all the things.

/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.