search

kubernetes / steering

The Kubernetes Steering Committee
Apache License 2.0
86 stars 61 forks source link

SC Elections: COCC members should automatically be voters #226

Closed jberkus closed 2 years ago

jberkus commented 2 years ago

Per the 2021 Election Retro:

The outgoing Election Officers propose that, for future elections, CoCC and SRC members should automatically be added to the eligible voters list, regardless of whether they meet devstats thresholds or not.

These two committees are consistent sources of granted voter exceptions, so it makes sense to just include them in the future.

liggitt commented 2 years ago

would it make sense to generalize this and say all current leaders listed in https://github.com/kubernetes/community/blob/master/sigs.yaml are eligible voters?

parispittman commented 2 years ago

+1 to @liggitt - I was going to say all named roles but sigs.yaml helps that a bit

jberkus commented 2 years ago

That would be fine, let's vote it in.

justaugustus commented 2 years ago

@kubernetes/steering-committee to leave comments (from 12/6 Steering public meeting)

liggitt commented 2 years ago

I'm in favor of leads in sigs.yaml being automatically included in eligible voters, as long as there are processes (e.g. elections or annual reports) in place that are followed for affirming or verifying leads are active.

cblecker commented 2 years ago

+1 to all named folks in sigs.yaml

k8s-triage-robot commented 2 years ago

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:

You can:

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

/lifecycle stale

jberkus commented 2 years ago

Hey, we didn't get a majority of SC voting this in.

Adding to the next SC agenda.

/remove lifecycle-stale

justaugustus commented 2 years ago

+1

dims commented 2 years ago

+1

tpepper commented 2 years ago

+1

justaugustus commented 2 years ago

Pulling together a few things discussed on 3/21 @kubernetes/steering-committee meeting (and I believe in a prior meeting), and on Slack:

From @dims in https://kubernetes.slack.com/archives/CPNFRNLTS/p1646791624379689:

hmm, shouldn't we be voting in a PR that asserts that change?

  1. It's fine to propose changes on issues, but Steering should vote on proposed changes once they're in pull request form

I'm in favor of leads in sigs.yaml being automatically included in eligible voters, as long as there are processes (e.g. elections or annual reports) in place that are followed for affirming or verifying leads are active.

  1. Let's start with all committee members and then extend further out to sigs.yaml
jberkus commented 2 years ago

OK, sounds like I should do two different PRs -- which will happen AFTER I move the elections files folder -- one which adds COCC+KSC, and another that adds sigs.yaml, and Steering can vote on each.

k8s-triage-robot commented 2 years ago

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:

You can:

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

/lifecycle stale

cblecker commented 2 years ago

/remove-lifecycle stale

tpepper commented 2 years ago

I lean initially toward https://github.com/kubernetes/community/pull/6757 because it is more explicit, but it is very broad and as Jordan has noted it may enable non-active folks to vote. Then I also lean toward #6756 because it is a simpler, more narrow change, but it is currently ambiguous on "member". Could there be a middle ground like 6756 but with more explicit wording (eg: Member == "chairs in sigs.yaml" for the two specified bodies)? I have commented on that PR around this. The two committees do have an active incentive to curate their tightly controlled membership due to the confidentiality and urgency of information handling for which the members are responsible. But also if we're comfortable that process (eg: annual reports) encourages that housekeeping across all of sigs.yaml, 6757's good enough.

liggitt commented 2 years ago

Could there be a middle ground like 6756 but with more explicit wording (eg: Member == "chairs in sigs.yaml" for the two specified bodies)?

https://github.com/kubernetes/community/pull/6756 with the sigs.yaml membership made explicit sounds good to me. Members of those two specific committees are the most likely to need voting exceptions because much of their activity is private and not counted by devstats.

dims commented 2 years ago

+1 to what @liggitt said.

liggitt commented 2 years ago

fixed in https://github.com/kubernetes/community/pull/6756