Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reducing update meeting policy #4874

Merged
merged 1 commit into from
Jul 8, 2020

Conversation

parispittman
Copy link
Contributor

@parispittman parispittman commented Jun 22, 2020

drawing out what the policy would look like if we were to reduce the community group requirement from quarterly to once a year.
why?

  • less than half of the groups we have meet this requirement now (and haven't for the last year); let's make it something that everyone can meet without being a burden
  • addition of the annual report
  • it's not possible to have all groups go even twice a year based on 12 meetings with 4 slots and 37 community groups.
  • the language in there now for how to meet the requirement with sending an update to k-dev or using the KubeCon update isn't straightforward and also paints a picture that we should change it
  • most give updates at least one KubeCon a year

@parispittman parispittman added kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. sig/contributor-experience Categorizes an issue or PR as relevant to SIG Contributor Experience. committee/steering Denotes an issue or PR intended to be handled by the steering committee. labels Jun 22, 2020
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Jun 22, 2020
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: parispittman

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 22, 2020
@spiffxp
Copy link
Member

spiffxp commented Jun 23, 2020

/lgtm
/hold
for any input from other steering members

Once a year feels too infrequent but I would rather document the state of today than continue to pretend these policies are adhered to as currently written

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 23, 2020
@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jun 23, 2020
Comment on lines -25 to -29
present, your SIG will need to figure out two other options to deliver on SIG
updates to meet the quarterly reporting requirement:
a. During KubeCon + CloudNativeCon or
b. A presentation or summary update sent to the kubernetes-dev
mailing list.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we make this twice a year instead of quarterly/once a year?

This would mean:

  1. One community meeting update, notes published to k-dev by the meeting host
  2. SIGs send a summary or presentation update to the k-dev mailing list

While this doesn't happen today, this seems like a good middle ground to me....thoughts?

Copy link
Contributor Author

@parispittman parispittman Jun 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we will need to give them a schedule of when each is due or else its not going to happen. when we were smaller and could do quarterly, there was the prompt from the community meeting host that they were due. @castrojo can we make it work by adding them to the schedule as 'k-dev' so when the host prompts community meeting, they prompt those that also need to do a k-dev update?

[talked about this at ContribEx; we can have host prompt kdev and live meeting update so twice a year is possible. just need to account in annual report and stuff like that.]

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when we were smaller and could do quarterly, there was the prompt from the community meeting host that they were due.

Was this just a couple of years ago? Seems so long ago haha...

Lgtm to do this in a follow-up, please don't treat my comment as a blocker. 👍

@tpepper
Copy link
Member

tpepper commented Jun 24, 2020

/lgtm
to capture current reality and iterate on figuring out a pragmatic/proactive middle between quarterly and annual.

@cblecker
Copy link
Member

/lgtm

@dims
Copy link
Member

dims commented Jul 6, 2020

/lgtm

@spiffxp
Copy link
Member

spiffxp commented Jul 8, 2020

/hold cancel
I feel like we've had enough steering eyes on this

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 8, 2020
@k8s-ci-robot k8s-ci-robot merged commit e751972 into kubernetes:master Jul 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. committee/steering Denotes an issue or PR intended to be handled by the steering committee. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. lgtm "Looks good to me", indicates that a PR is ready to be merged. sig/contributor-experience Categorizes an issue or PR as relevant to SIG Contributor Experience. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants