dims commented 3 years ago

//note: issue has been broken down into three and this one will reflect the mechanism of selection only; other two: #5886 #5890

Currently there is no standard mechanism, some SIGs have chairs who have been there for a while, some SIGs are able to get fresh blood in, some SIGs have even held an election.

We need to:

A standard way for someone to be chosen - say an election
Track in a easy to consume form, who was has served from when
Ensure all mandatory roles in a SIG are filled (are TL's mandatory?)
Who participates in the process to choose a new chair/tl (also see https://github.com/kubernetes/community/issues/5854)
Term Limits : what kind of limits (time served? count?)

This also helps with:

Contributor ladder: folks have roles to look forward to in the community
Chairs and Leads are forced to think about succession and their own legacy

dims commented 3 years ago

/committee steering

nimbinatus commented 3 years ago

As a side note, defined term limits would also help folks plan when discussing becoming a chair/lead with their managers or when trying to decide if they have the ability to commit for a time period should they be considering any life-altering moves (e.g., family, career, personal).

parispittman commented 3 years ago

I'm a fan of term limits for any named leadership role, including chair (re: https://github.com/kubernetes/steering/pull/175). I did a 2 year term as a Chair and after reflection think that 3-5 years can be a debatable term limit period.

re: are TLs mandatory? Every SIG should have one TL and one Chair as two different people. its hard to have one person lead a meeting that is also the maintainer of the thing its representing, especially in cases where there are heavy debates and technical back and forth.

parispittman commented 3 years ago

4586 is relevant to SIG voting

BenTheElder commented 3 years ago

I want to clarify the language a bit here: "term limit" (https://en.wikipedia.org/wiki/Term_limit) usually refers to a limit on the number of terms an official can serve, where a term is a fixed length of time stint in office. I think that some of what people are referring to as "term limits" is actually just having terms / a limited period of time served after being elected, instead of unlimited time in the position.

I'm not sure if term limits / restricting how much total time one can serve is what we want (I could see arguments for requiring fresh leadership, but on the other hand if people are doing a good job and everyone is happy ... 🤔 ), but having terms of finite length after which the SIG re-evaluates (votes again) seems like an obvious move to me at least ...

Additionally: Very interested in seeing leadership be elected instead of the current ad-hoc processes that often involve nominating your own replacement. (see slack thread that spawned this issue https://kubernetes.slack.com/archives/CPNFRNLTS/p1624308886040400)

As for why I think this is important:

SIG chairs come to mind. Steering delegates a lot to SIGs but SIG leadership is frequently not exactly elected and has no expiration

We have democratically elected leadership but in turn delegate to what is mostly essentially BDFLs over broad area organization. I think SIG leadership should be elected similar to steering.

Also, having terms and voting I think will encourage people to step down (and perhaps even come back later!) rather than hanging on forever, even through burn out etc. Since currently it's pretty much a one time opportunity and you keep it for life ...

ehashman commented 3 years ago

My 2c:

Chairs should be elected on 2 year terms
We should have a 4 year consecutive term limit
TLs should be mandatory, selected by Chairs in a method of their choice (e.g. could be an advisory election)

Elections are tricky. SIG Instrumentation currently tracks our SIG members through a combination of meeting attendance and devstats. I don't think meeting attendance would scale to larger SIGs.

Devstats currently doesn't work very well for k/k because there's no way to filter contributions by SIG label. I think that might be a prereq for getting better member/voter data.

Edit: just saw https://github.com/kubernetes/community/issues/5854. I think that is a prereq for this issue.

sftim commented 3 years ago

If a SIG has say three co-chairs and no tech leads, should that SIG be forced to appoint a tech lead?

BenTheElder commented 3 years ago

I think it could be reasonable to simple set org members as the list of possible voters for SIG leadership.

I'm not sure it's best to limit it to "sig members" which seems likely to be a more arbitrary bar than the reasonable org membership bare we have today, and I think folks nominally focused on other SIGs still have a vested interest in the health of all SIGs. I don't think meeting attendance in particular is a very inclusive approach ... I've spoken quite a bit about that already.

Also unclear on the techlead requirement, I think that's maybe a distinct thread.

sunstonesecure-robert commented 3 years ago

is this a real problem or hypothetical? (details not needed) I am genuinely (academically) curious since I have been discussing the open source culture with academics and other "culture" SMEs and it's fascinating how human psych and social group dynamics permeates all aspects of a relatively technical environment :)

neolit123 commented 3 years ago

everything right now is a best effort including who is a SIG lead and how much time they can participate as a lead. people come and go, change jobs and so on. tracking that seems like overadministration to me.

the numbers of regular / active participants are not that high. if we had dozens of active participants in SIGs pushing to climb ladders and more and more wanting to join, it feels better administration would be needed. but since that is not the case, it feels like we would be just complicating our administrative procedures.

i don't think we even have a definition what is a SIG member exactly; what is the criteria? joins zoom meetings, responds on slack / mailing list / tickets, reviews code / docs / KEPS PRs - all of these perhaps?

seems the current method of existing leads nominating existing qualified contributors as leads has evolved naturally. voting for new SIG leads seems fine, but who would be eligible and knowledgeable enough to vote? SIG members presumably?

ehashman commented 3 years ago

If a SIG has say three co-chairs and no tech leads, should that SIG be forced to appoint a tech lead?

Yes, I think so.

I don't think meeting attendance in particular is a very inclusive approach ... I've spoken quite a bit about that already.

Re: meeting attendance, our goal is to additionally, not exclusively, recognize people who have been regularly contributing in non-code ways, such as attending meetings, participating, and helping with notes. We actively encourage people who have regularly been attending our meetings but have been shy to get more involved in the project to submit PRs and apply for org membership. Having a diverse set of ways to participate makes our community more accessible.

BenTheElder commented 3 years ago

is this a real problem or hypothetical? (details not needed) I am genuinely (academically) curious since I have been discussing the open source culture with academics and other "culture" SMEs and it's fascinating how human psych and social group dynamics permeates all aspects of a relatively technical environment :)

IMO: Yes. The folks in this thread are not known for spending their time on hypothetical problems 🙃

The current process lacks any sort of re-evaluation of leadership other than folks choosing to permanently step down of their own accord. SIGs have pretty broad ownership in the project but the community may not really have buy-in here. People burn out or otherwise become inactive but stay in their roles, and members who are doing a lot to effectively lead SIGs are not given the chance to formally lead.

If I nominate a replacement, I do so on a public mailinglist. I have literally never seen anyone speak against a nomination, because doing so is to publicly speak against the person, which would be ... quite rude.

Whereas the steering committee being elected, participants in the project privately ranked-choice vote for the leadership periodically. This is going well, and I would say that we have less of a burn-out issue in steering than in SIG leadership.

seems the current method of existing leads nominating existing qualified contributors as leads has evolved naturally.

Yes, but IMO it is not a good solution. See above response. Making it a regularly recurring process to select new leads ensures that inactive leads will eventually be replaced and helps encourage leads to consider their position finite and consider stepping down earlier over clinging to it.

voting for new SIG leads seems fine, but who would be eligible and knowledgeable enough to vote? SIG members presumably?

I think org membership should be sufficient for this purpose, we have a well established and reasonable process for managing org members for other useful purposes (such as adding them to the literal github organization wihch allows the CI systems to automaitcally trust trust them, as github actions also does). I don't think we will reach an easy and fair distinction of "being in a SIG" and this is ultimately a distraction from the core selection process improvements.

https://github.com/kubernetes/community/blob/master/community-membership.md

If a SIG has say three co-chairs and no tech leads, should that SIG be forced to appoint a tech lead?

Yes, I think so.

I'm not sure I agree, but I also think making this position mandatory is a completely distinct conversation and we should not distract this thread. We should file a separate issue to discuss changing the TL role to mandatory. It is explicitly optional at the moment and making it non-optional doesn't have much bearing on changing the selection process.

neolit123 commented 3 years ago

I think org membership should be sufficient for this purpose, we have a well established and reasonable process for managing org members for other useful purposes (such as adding them to the literal github organization wihch allows the CI systems to automaitcally trust trust them, as github actions also does). I don't think we will reach an easy and fair distinction of "being in a SIG" and this is ultimately a distraction from the core selection process improvements.

https://groups.google.com/d/msgid/kubernetes-dev/9bdfaaa5-9664-4293-bded-256798ad7a99n%40googlegroups.com?utm_medium=email&utm_source=footer

^ Jeffrey Sica recently stepped down as a SIG UI chair and appointed Shu M. as someone who can take over the position. personally, as an org member, i do not know Shu M. (we may have interacted at some point), but i would assume that they are active in SIG UI and Jeffrey made a good choice. this is an example where SIG outsiders, but org members might be eligible but not knowledgeable for a vote.

this means we'd need a voting process similar to steering but arguable slightly more demanding to educate voters about candidate bios, list of prior works, recommendations by existing leads, about the schedule and everything else.

this can result in cases where someone is just a better lead, has more time, and is recommended by existing leads, but another person wins the public vote as they were "educated" better about them.

BenTheElder commented 3 years ago

Nothing prevents candidates from being nominated by prior leads. That sounds like a hypothetical problem. You can also just choose not to vote if you are not informed sufficiently.

AevaOnline commented 3 years ago

(wearing my open source ecosystem hat)

is this a real problem or hypothetical? (details not needed) I am genuinely (academically) curious since I have been discussing the open source culture with academics and other "culture" SMEs and it's fascinating how human psych and social group dynamics permeates all aspects of a relatively technical environment :)

Broadly, yes. The aphorism that "a tech company ships their org chart" applies to F/OSS as well: in the absence of corporate hierarchy, the open source org chart follows from a project's method of (s)electing leaders and organizing workstreams into groups (SIGs and WGs, for instance) that produce artefacts (code, docs, binaries, etc).

There are pros and cons to both Terms (mandatory election cycle of N months) and Term Limits (maximum number of N terms in a given office).

In my experience, the primary problem with election cycles / Terms on all leadership roles is that elections often turn into popularity contests. A secondary problem: it also becomes harder to get difficult engineering work done, where by difficult I mean spans more than one election cycle. (Yes, I'm speaking from experience on this, and happy to provide concrete examples if necessary.) However, I think it's a healthy evolution and good for open source.

The real question around Terms should be: how do you define the electorate (set of people who have a vote in an election)? If the electorate is actively engaged, then sound decisions are often made and it's not a popularity contest; when an electorate becomes only distantly aware of who the nominees are, then aspects of reputation come more into play, and the balance tips towards popularity.

So, on the topic of Terms, I would suggest everyone think very carefully on how the electorate is determined. That's the best "lever" to pull. Term lengths is a good one, too (6mo? 12mo? 24mo?)

However, I would advise against enforced Term Limits, and suggest a cultural approach to encouraging rotation. When there is only one person in a role, the risk of institutional knowledge loss is greater when there is a limit to their length in office. There could, for instance, be external circumstances which remove the most eligible candidate at a moment in time when a current lead can no longer run due to a term limit, leaving a project without good leadership, when it would be better for the project for the current lead to stay around for one more cycle before handing off.

Just my 2c ...

neolit123 commented 3 years ago

this can result in cases where someone is just a better lead, has more time, and is recommended by existing leads, but another person wins the public vote as they were "educated" better about them.

Nothing prevents candidates from being nominated by prior leads. That sounds like a hypothetical problem. You can also just choose not to vote if you are not informed sufficiently.

today i cannot think of sufficiently active candidates to nominate or such that can step up and have the time to do it. so if a term is fixed and votable rotation is mandatory, maybe candidates should self-nominate?

for distributed SIGs, then we enter subproject inner-SIG political voting, where participant in subproject Foo would receive all the votes from subproject Foo participants, because A) they know who they are and B) they would think the candidate would defend the interests of subproject Foo (even if there is not much to defend, really). even if the subproject Bar representative is more appropriate.

concrete example for SIG CL is voting where minikube vs Cluster API candidates compete and the Cluster API person wins because there are just more people voting from one of the subprojects.

i'm +1 for writing a guideline for how SIG leadership can operate ideally, but my vote would be for it to be opt-in and a best effort follow.

lavalamp commented 3 years ago

I think org membership should be sufficient for this purpose, we have a well established and reasonable process for managing org members for other useful purposes (such as adding them to the literal github organization wihch allows the CI systems to automaitcally trust trust them, as github actions also does). I don't think we will reach an easy and fair distinction of "being in a SIG" and this is ultimately a distraction from the core selection process improvements.

I don't think having people vote for leadership of a SIG without having inside context on that SIG is going to work out very well.

I usually would err on the side of trusting people on things, but in this case trusting them not to vote on SIG leadership when they lack context seems like a recipe for a popularity contest as mentioned above by @AevaOnline; even if 75% of such people realize they shouldn't vote, the remaining 25% of people can easily overwhelm the votes of those who do have context.

... sounds like a hypothetical problem

Let's be careful slinging that one, that's a fully general counter argument: all replacement systems are counterfactual and all problems with them will therefore be hypothetical. The argument is really over how close of an analogy there is with an actually experienced (by someone) problem. But it is entirely possible for new systems to permit classes of problems with which no one has personal experience. In fact, the search for a new system that no one says bad things about will cause most new systems to fall into this category.

lavalamp commented 3 years ago

In response to the OP, I think that leadership selection mechanism and getting "fresh blood" in are both worthy of discussion, but I'm not convinced they are the same problem or that they should be solved by the same mechanism. I think it would be a good exercise to zoom in one level of abstraction and list the elements of each that are problematic, in advance of determining a category of solution to think about.

In regards to leadership, I'd say from my perspective the biggest missing piece is a backup system to make sure our current leadership structure is functioning everywhere. Right now we don't have many (any?) engagement levels between "going with the status quo" and "make giant waves". (An election system might solve this problem if implemented extremely carefully. A non-carefully implemented system can easily leave things unchanged or worse.)

In regards to getting fresh blood, at least for my SIG, what we do is pretty involved and people who can make good headway on it are usually gainfully employed by some BigCo. It's not the sort of OSS that's a fun diversion on your nights and weekends. I wish it weren't this way, but sometimes it's genuinely the territory that's complicated, not just the map. Please, anyone who can answer this riddle hit me up on slack.

BenTheElder commented 3 years ago

However, I would advise against enforced Term Limits, and suggest a cultural approach to encouraging rotation. When there is only one person in a role, the risk of institutional knowledge loss is greater when there is a limit to their length in office.

We don't have a single person in any of the roles discussed in this thread, FYI. SIGs must have multiple.

concrete example for SIG CL is voting where minikube vs Cluster API candidates compete and the Cluster API person wins because there are just more people voting from one of the subprojects.

The chairs of the SIG are already not minikube maintainers, so this seems somewhat moot. I'm also not sure it's a problem to have SIGs focus on most highly staffed efforts.

EDIT: I also don't think voting should be restricted to "sig members" though as opposed to project members. SIGs are not insular components of the project, or they shouldn't be.

I don't think having people vote for leadership of a SIG without having inside context on that SIG is going to work out very well.

I think it's rather presumptuous to say that one cannot have context on a SIG without being a listed member. I also think it is wrong.

Further: the whole project has buy-in to ensure all SIGs are well run. This does not require deep technical knowledge of a given SIG or anything like that.

Let's be careful slinging that one,

I mean, I do not seem evidence that it is non-hypothetical or actually problematic, so I stand by this.

A non-carefully implemented system can easily leave things unchanged or worse.

Without specific examples of how voting will be worse, this is difficult to refute.

In response to the OP, I think that leadership selection mechanism and getting "fresh blood" in are both worthy of discussion, but I'm not convinced they are the same problem or that they should be solved by the same mechanism. I think it would be a good exercise to zoom in one level of abstraction and list the elements of each that are problematic, in advance of determining a category of solution to think about.

We've already selected voting as the suitable mechanism for steering, where time and energy was put into this instead of something that organically happened over the course of the project. I'm not sure how much effort needs to be put into this.

In regards to getting fresh blood, at least for my SIG, what we do is pretty involved and people who can make good headway on it are usually gainfully employed by some BigCo. It's not the sort of OSS that's a fun diversion on your nights and weekends. I wish it weren't this way, but sometimes it's genuinely the territory that's complicated, not just the map. Please, anyone who can answer this riddle hit me up on slack.

Chairship is not about being an expert on the technical details. It's about organizing the SIG. Technical Lead is perhaps another matter. I don't think "bigco fulltime engineers apply only" is a great answer to anything.

sunstonesecure-robert commented 3 years ago

Chairship is not about being an expert on the technical details. It's about organizing the SIG

as a co-chair on a very small WG (policy) I agree with that! it's about the logistics and getting speakers and creating PRs and responding to various TOC requirements and minutiae - very little time left over for technical stuff, and then it's filling the gaps that others didn't want to cherry pick :)

I can imagine what a larger SIG chair load must be like! I would presume that - like me - most do it as a labor of love (emphasis on the labor) and not for glory. It's not like BigCo Distinguished Fellow or something like that.

We recently had a "call for chairs" and no one else stepped forward.

1000% agree that actively soliciting and encouraging others to chair is a best practice. But if no one else wants to do the scud work...

logicalhan commented 3 years ago

In SIG Instrumentation, we've already discussed this (both fixed terms and term limits) and we had moderate support for both. Personally, I also believe and support the democratic ideal in the open-source community (I think I was the one to bring up both topics originally for debate in our SIG).

However, I don't really think that the answer is quite black and white. There is a lot that goes into chairing and TL-ing and having a bad chair or a bad TL can be terrible for the community, engagement, and also technical direction of the SIG. There are can be a lot of unintended consequences. That being said, I agree that the current haphazard way of doing this is arbitrary and possibly not super healthy either. I don't really have a great response for all this.

logicalhan commented 3 years ago

Also SIGs are by nature quite different and a one-size fits all strategy may not be the best thing in the end.

jayunit100 commented 3 years ago

Overall good idea I've advocated for this in the past also.... but based on the timing I'd say "yes but not right this minute" bc currently Lubomir's comment is pretty important to contextualize --- right now burn out is high in tech and in k8s in general- and new rules just increase it even more even if the rules are well intentioned.

PushkarJ commented 3 years ago

Sharing a point of view of what a good process would look like from someone (me) who is neither a SIG chair or a tech lead (yet):

Agree with elections becoming a popularity contest, when the electorate is large like all org members. Perhaps org members can share their non-binding votes to ensure their voice is heard. Steering committee members and all SIG's chairs can have a binding vote on selection of any SIG chair (and Tech Lead).
Existing chairs should nominate new chairs and tech leads for their SIG. However, there should be a process for reporting any instances, where a contributor of a SIG, feels unfairly excluded in nominations in spite of their contributions.
Max. limits in terms of elections every 2 years with total limit of 4 years as a chair or tech lead, makes sense. Having a Tech Lead as a mandatory role, will encourage Chairs to groom people who can be future chairs (by being tech leads first)
In situations, where no suitable candidates can be nominated as chair and the max. term limit has run out, emeritus chair can temporarily take ownership of the role to ensure no disruption in day to day activities. They should also work with steering committee and other SIG's chairs to identify a Chair and then go back to emeritus status when the new chair is elected.

BenTheElder commented 3 years ago

All voting is, to an extent, a popularity contest.

Org membership is 100% intended to be a trust domain within the project. I'm sad and concerned that we apparently do not actually trust our members.

EDIT:

[...] right now burn out is high in tech [...]

I think without processes to allow people to step down and come back, burn out is worse. Please see https://github.com/kubernetes/community/issues/5855#issuecomment-867070327

There is a lot that goes into chairing and TL-ing and having a bad chair or a bad TL can be terrible for the community, engagement, and also technical direction of the SIG. There are can be a lot of unintended consequences.

This seems like an argument for why we should ensure we regularly re-evaluate leadership ..? (I.E. introduce terms)

PushkarJ commented 3 years ago

My two cents, there is no lack of trust in org members. But there is definitely a need to contextualize the candidate and their contribution considering the size of the org.

It reminds me of @AevaOnline and @mrbobbytables talking about Dunbar number when explaining how "Social groups have scalability problems too" in Kubecon EU 2021 talk: https://youtu.be/aVZWOMGE5q8?t=233

Having said that, I really appreciate this being an open discussion where everyone can share their opinions :)

celestehorgan commented 3 years ago

So what are the next steps forward here @dims? Does this need more feedback/commentary?

dims commented 3 years ago

@celestehorgan we add it to the steering agenda for discussion. ( cc @parispittman )

parispittman commented 3 years ago

https://github.com/kubernetes/community/issues/5886 -> broke this issue into another one for terms and/or term limits. I'll collect feedback from above there.

jayunit100 commented 3 years ago

re dunbars number: I think there's a pareto distribution (a small handful of 2 or 3 people are doing the leadership in different areas for the sigs wether or not they have titles), multiplied by 20 or 30 sigs, it seems like 40 to 60 people shouldnt be too hard to have some kind of passing relationship with in the community ?

k8s-triage-robot commented 3 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:

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 commented 3 years ago

/remove-lifecycle stale /lifecycle frozen

kubernetes / community

Better Process of selection of SIG Chairs and Technical Leads #5855

4586 is relevant to SIG voting