Recognizing roles defined in SIGs and recognizing leaders in SIGs

[dims]

Dear Contribex folks,

Problem Statement:
In general, there is a need to recognize roles and leaders in our SIGs and WGs. If we pick say the SIG-Release README.me there are a quite a few folks who are leading specific initiatives in addition to the chairs and tech leads that the team would like to recognize . Same is true with a bunch of sub project owners as well across all SIGs, as their work is hidden in OWNERS files. Related issue is that what folks do is not documented well either in various SIGs

Ask for the Contribex team is to improve tooling and set up directory structures / markdowns such that:

• Each SIG can define roles and what the roles do/mean.
  • (Why? Individuals will then feel empowered as they are recognized and others can aspire to fill these roles). These roles can be for a specific SIG, they don't need to be across all SIGs. Once some of these roles get popular and adopted across SIGs, we can revisit which roles are applicable across SIGs.
• SIGs can highlight who is currently doing that role in generated markdown
  • (Why? folks can showcase their work in the community to their employers and community in general and its a sign of our faith and trust in this person as well)
• Showcase sub project owners along with the Chairs and Tech Leads in generated markdown
  • (Why? lots of projects like minikube and others do not even show up in governance, lots of people are doing really good work taking care of things and we should be rewarding that)

Note that the above asks do not imply exactly how the sig-contribex should implement the solution :) just that we need this to better appreciate the people and get newer folks excited about things that they can be doing and folks they can be shadowing etc. Don't forget the employer angle too, it helps advocate for their time on the project with their employers.

What say you?

cc @kubernetes/steering-committee in case i missed any points that came up in discussions.

Related to :

• sig-release: Add Lauri Apple as SIG Chair #5563
• Formalize the concept of subprojects steering#200
• https://groups.google.com/a/kubernetes.io/g/steering/c/_QNg-xsawOg/m/al0kl9L8AgAJ

Additional Notes:

• New roles being proposed by sigs would be part of their charter and will be reviewed as a charter update by steering
• "Subproject owner" is defacto standard for now, we can deal with an alternative name outside of this issue if needed

[dims]

/committee steering

[justaugustus]

Thanks for opening this broader discussion issue, @dims!
The PR linked to recognize @LappleApple includes changes to the SIG/WG README generator code.

I can further generalize that to support ad hoc roles! 💕
EDIT: (and pull it into a separate PR for discussion)

[nikhita]

Question about one of the points, lgtm on the idea otherwise.

Showcase sub project owners along with the Chairs and Tech Leads in generated markdown

Did we finalize on the nomenclature for subproject "owners"?

We've discussed about "owners", "coordinators" and "points of contact". Personally, I like "points of contact" because owners or coordinators implies that they have additional powers over people who are already defined in OWNERS, which is not the intent of this role.

[dims]

@justaugustus let's wait for comments/concerns before we churn any further :) Also we should work on the general concepts first and the PR for Lauri would be separate after that please.

[dims]

@nikhita currently we all call them "subproject owner", so that would be status quo. We can take the bikeshed out of this issue if we need to. Let's make sure there is concrete guidance that's actionable here for now for contribex folks.

[lasomethingsomething]

Love to see this discussion--thanks @dims! Let me know if I can assist in any way.

[parispittman]

after convos with many sig chairs, folks have been slow to adopt new roles because they follow sig-governance to a tee mostly with just chair and tech lead. I'm +1 on having another mechanism to collect named roles and display them. Also +1 to listing "suggested and/or optional" roles on sig-governance for things like ppm, triage lead, test lead, etc though we should stress chair and tech lead are the required.

[ehashman]

though we should stress chair and tech lead are the required.

At some point are TL roles going to become a requirement? As they're currently optional.

[lasomethingsomething]

Elana's question raises something I have been wondering about relating to this discussion: If folks think of the TL role as secondary to the chair role, and if so, how to change this to ensure that leads land in the roles best matched to their interests and strengths.

[dims]

@LappleApple hard question, this is not different from when steering knows some specific SIGs are not functioning properly (or showing tendencies unbecoming of open source in general), we end up counseling privately / publicly / through trusted channels .. basically coach folks to do better without actually hauling them in front of the principal which is the final resort.

[lasomethingsomething]

Poking around pages today and wondering if my PM role description might eventually fit here: https://github.com/kubernetes/community/blob/master/contributors/guide/non-code-contributions.md

[cblecker]

don't see a bunch of folks who are doing the work and are not being recognized for it

I have an issue with this part of the problem statement. Why is "being in sigs.yaml" the definition of recognition here? These folks are supposed to be the initial points of contact. There are many people doing all kinds of work all over the project.. is it scalable to put them all in sigs.yaml? Do we want to reenforce an idea that if you aren't in sigs.yaml, your work isn't being recognized?

[dims]

@cblecker i've updates the language and dropped that statement. Please review.

[dims]

@mrbobbytables i've updated the text to make it clear that the new roles are essentially things that will be part of a charter update to the sigs that would like to list them out

[jeremyrickard]

I wanted to drop some feedback on this issue and touch on the comment from @cblecker up above. On behalf of SIG Release, @lappleapple submitted a form recommending a nominee to the 1.22 Lead Mentoring Cohort. She is not listed in the sigs.yaml file, however, because she holds the program manager role and we don't currently officially recognize that as a role within that file. Since she was not in the sigs.yaml file, she was not able to nominate the candidate. This lack of recognition for her CURRENT leadership position seems like a rather unfortuante technical blocker to the process of nominating someone for that mentoring cohort, among other things.

[jeremyrickard]

Ooops, hit comment too soon. Obviously, I'm a +1 on this issue, I think it's needed.

[dims]

thanks @jeremyrickard!

[dims]

/cc @kubernetes/steering-committee

[dims]

/assign @liggitt @cblecker @parispittman @mrbobbytables @nikhita @derekwaynecarr

[cblecker]

Okay, so before I get into my more detailed thoughts, let me address the situation around the 1.22 Lead Mentoring Cohort:
The requirements to nominate someone for the Lead Mentoring cohort is you need to yourself be a SIG Lead. Governance defines this as a SIG Chair or a SIG Technical Lead. This issue would not solve this situation in Lauri's case as she would be listed as a PM and there is no clear guidance on "what does a PM role mean as far as do they get to speak on behalf of the SIG". The correct path here would be either:

1. If Lauri wants to do the job of a SIG leader, and the SIG wants to have her speak on behalf of the SIG, there are roles like Chair for that.
2. If Lauri does not want to be a SIG Chair, then she can bring her nomination to the existing chairs, and they can decide if they should nominate on the individual on behalf of the SIG.

The reason it should be done this way IMO, is we have so many community groups, and when one SIG is interacting with another party, there needs to be some predefined way of knowing "does this person have the authority to speak on behalf of the SIG".

Now getting to the heart of the issue:
SIGs are decentralized and can create roles within them. There are many examples of this across the project, including the Release Team in SIG-Release, the API Reviewers team in SIG-Arch, the GitHub Administration team in SIG-ContribEx, etc.

However, having some sort of common nomenclature as to the key leadership positions allows other SIGs to know who can speak on behalf of a SIG, without having to understand the intricacies as to how each SIG organizes.

SIG Release has a PM role, that's great. They can even add that role to their readme in the <!-- BEGIN CUSTOM CONTENT --> section. But we don't need to add tooling around these roles, because there isn't uniformity between SIGs unless we define it in sig-governance.md. A PM in one SIG might be different from another.

sigs.yaml is a tool for enforcing uniformity. It was always designed that way. It's not a recognition or appreciation tool, which was how this whole thing was/is framed.

The one part of this that may be useful: Adding subproject contacts, instead of or in addition to the OWNERS file. This would allow us to highlight that certain subprojects may have key subproject OWNERS who are facilitating that subproject owner role, instead of all approvers in an OWNERS file.

Save for that subproject contacts piece, I am explicitly -1 to the remainder of this proposal (both as a SC member, and as a ContribEx owner for the sigs.yaml generator tool).

[justaugustus]

#5563 (comment)

[parispittman]

#5736 -> I drew up what I'm thinking here; introduction of "other roles" with examples and a MUST be listed in the SIGs README

[celestehorgan]

In general, I'm in support of the proposal to recognize roles specific to a given SIG, as well as to formalize them in .yaml(1). I think this for the following reasons:

• For cross-cutting SIGs like SIG Docs, a simple Chair/Tech Lead dichotomy doesn't capture the complexity of the roles they need to function. For example, for SIG Docs, there are actually many more leads than currently exist in the YAML: each translation has a lead, and each of those leads has, for example, Netlify access. Thinking purely in terms of keeping track of who has access to what, (and whose access might need to be revoked if push came to shove), it would be useful to capture non-standard SIG roles in YAML.
• For feature area SIGs, I think there's also an argument for more specialized roles as the team sees fit?

All of the above addresses the technical reasons you might want to do this, but there's a far more compelling human reason: recognition and named roles help people's careers. One of the most important reasons for someone who doesn't work upstream full-time or even part-time to take on upstream roles is that it's great on a resume. Named roles in groups are important for that reason too, and we should be aiming to help people's careers.

(1) That said, maybe adding them to the main sigs.yaml file isn't the best solution?

[nikhita]

Personally, I'm a +1 for recognizing roles within SIGs.

sigs.yaml is a tool for enforcing uniformity. It was always designed that way. It's not a recognition or appreciation tool, which was how this whole thing was/is framed.

That said, maybe adding them to the main sigs.yaml file isn't the best solution?

Tooling wise, I agree that roles should not be within sigs.yaml. We could formulate:

• sigs.yaml - tooling to introduce uniformity within SIGs with Chairs and TL roles
• a roles.yaml within each SIG directory such that the roles defined in roles.yaml get added to the SIG README.md under a separate Roles section - tooling for recognition and appreciation with custom roles for each SIG

[jayunit100]

Don't know this whole subjects history but I'd say this makes sense. it stands to incentivize a broader contribution model then just code which is cool

[jberkus]

Personally, I'd settle for just listing the subproject owners by name. I'm pretty tired of looking up OWNERS files and disambiguating people's GH handles when I need to ask something.

[ehashman]

+1 to adding subproject leads to sigs.yaml. For format, I would love to see something like:

subproject_leads:
- github: @jane-doe
  name: Jane Doe
  company: ACME Inc.
  subproject: Metrics Server

[celestehorgan]

Tooling wise, I agree that roles should not be within sigs.yaml. We could formulate:

* `sigs.yaml` - tooling to introduce uniformity within SIGs with Chairs and TL roles

* a `roles.yaml` within each SIG directory such that the roles defined in `roles.yaml` get added to the SIG README.md under a separate `Roles` section - tooling for recognition and appreciation with custom roles for each SIG

I was thinking of suggesting something like this too, but if sigs.yaml can allow for freeform parsing of entries then maybe it's overkill.

I really like @ehashman's suggested yaml! :)

[jberkus]

@celestehorgan what's the technical issue with putting the names in sigs.yaml? I didn't quite follow that.

[cblecker]

The Steering Committee met and discussed this issue. We have come to a few conclusions on this which should help us to move forward:

• We are currently working on Add 'other roles' to sig-governance.md  #5736 to document how SIGs can create roles, and where they should be documented.
• These SIG-specific roles should not be added to sigs.yaml
• New roles should allow for a lazy consensus period of 1 week, and should be sent both to the sig list and k-dev
• If a new role includes delegation of responsibilities from a defined sig-governance role (e.g. Chair or Tech Lead), that delegation should be documented in the SIG's charter

[mrbobbytables]

(with steering hat on) I am +1 on enumerating subproject leads/points of contact.

[ehashman]

@cblecker I realize your conclusions above did not mention Subproject Leads, which are not SIG specific---were there any objections to adding those to sigs.yaml?

[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

[mrbobbytables]

/remove-lifecycle stale

[parispittman]

now that #5736 has merged, what's left on this issue @dims ?

[dims]

@parispittman thanks. yes, we can close this out.