Org: Kubernetes and kubernetes-sigs org membership should be equivalent

[justaugustus]

We currently state policy that membership in the kubernetes org, makes you implicitly eligible for membership to our other non-private orgs, including kubernetes-sigs.

To quote @BenTheElder:

(As a point of clarification, membership to kubernetes implicitly makes you eligible for membership to our other non-hidden orgs, but not the other way around.)

I know this is not the place to discuss this but ... I think we really should not distinguish between kubernetes-sigs and kubernetes as we move things out of the main org to kubernetes-sigs pretty aggressively. It sends a bad / the wrong message that kubernetes-sigs has a different bar as we move projects from kubernetes to kubernetes-sigs...

In any case, @aojea has done a lot of wonderful and woefully understaffed work in both orgs in his spare time, thank you again!

I think that membership at least to those two orgs should be equivalent.

WDYT, @kubernetes/owners?

ref: https://kubernetes.slack.com/archives/C1TU9EB9S/p1561131100303800

[spiffxp]

This is residue leftover from kubernetes-incubator not having as high of a bar for admission.

I am unclear on whether the other orgs were in a similar situation. I'd rather we explicitly reconcile that, and then say, excluding kubernetes-incubator, membership in one is criteria enough for membership in all.

[justaugustus]

@spiffxp -- what would be the concrete action items to determine our bar and reconcile admission?

[BenTheElder]

At minimum perhaps joining / being sponsored into github.com/kubernetes should imply membership into github.com/kubernetes-sigs if the bar is in fact somehow "lower"?

[spiffxp]

@justaugustus to me, reconcile means:

• for each of the other orgs, who is in that org that is not in kubernetes?
• were they added after Sep 20, 2018 (this is the date we serviced the first membership request through the process we use today)
  
  
  
  • if yes, they can be auto-added to kubernetes
  
  
  • if not, they'll need to apply to become kubernetes members
  
  
• at the end of this, everyone is a kubernetes org member

we can then treat kubernetes org as the source of truth, add to it by default regardless of what other orgs are requested, and consider trying to mirror org membership across orgs (ref: https://github.com/kubernetes/test-infra/issues/13107)

[justaugustus]

@nzoueidi -- Is this something you'd be able to work on?

[nzoueidi]

yep, thank you @justaugustus for pinging me.

/assign

[cblecker]

Before we get started on actual reconciling work, we need consensus on the plan. I'm not entirely convinced that @spiffxp's plan is all we need to take care of.

• We really need to address inactive members, and pulling back permissions from those that are inactive. We're asking for problems from a security prospective by not doing this.
• Because members can be sponsored by the org that they are trying to join, there are people added after that that were sponsored by those who may have been adhoc added to those orgs.

I'm not saying we necessarily need to untangle all of that, but we do need to discuss and address "if we care" about those things.

I guess maybe a good first start is identifying how many users are we talking about.. how many users do we have that are in one of the subsidiary orgs (-incubator, -client, -sigs, -csi), but not in the primary org.

[BenTheElder]

Agree that we need consensus :upside_down_face:

Regarding these specific points:

We really need to address inactive members, and pulling back permissions from those that are inactive. We're asking for problems from a security prospective by not doing this.

Which security perspective, exactly? Are we just talking about org membership here or rights beyond that like being a repo admin or OWNER?

I don't think this issue has anything to do with the extended permissions or OWNERS, and the former (merely being an org member) is not really a viable "security" bar...

Again not sure if you meant this, but we should deal with those extended permissions, just not here, that's a bit orthogonal.

Because members can be sponsored by the org that they are trying to join, there are people added after that that were sponsored by those who may have been adhoc added to those orgs.

I'm unable to parse what the issue is here. Can you elaborate please?

[cblecker]

Man, I didn't do a great job explaining what I meant in that last comment haha.

I don't think this issue has anything to do with the extended permissions or OWNERS, and the former (merely being an org member) is not really a viable "security" bar...

So my thought was, we shouldn't grant new permissions to inactive folks. I don't want to auto or mass invite someone from k-sigs to k/ if they're inactive, or vice versa. Culling inactive folks prevents this.

I'm unable to parse what the issue is here. Can you elaborate please?

Okay, so Alice, Bob, and Charlie:

• Bob is a participant in subproject A. Was added to k-sigs with no bar/sponsors, and only works on that subproject with his fellow employees.
• Bob sponsors Alice to join k-sigs, but Bob himself may not be eligible to be a sponsor.
• Can Alice sponsor Charlie? Should any of these folks automatically qualify for membership to Kubernetes?

This is more a mental exercise than a major concern (knowing that the bar is pretty low to get in), but I just want to flush out all these angles before we set a policy.

[BenTheElder]

Ah I understand now, thanks! Culling inactive members makes sense in that context.

For "Alice, Bob, and Charlie" one of the suggestions above was to replicate from the main org out, in which case I don't think any of those concerns apply.

I currently think only joining github.com/kubernetes should imply membership / invites for other orgs (namely github.com/kubernetes-sigs) and require some sponsorship. The other orgs are sort of special cases as far as I know, and anyone wanting to be in kubernetes + kubernetes-sigs should apply to be a project member / kubernetes -> both.

In that case:

Can Alice sponsor Charlie? Should any of these folks automatically qualify for membership to Kubernetes?

They can invite people to kubernetes-sigs maybe (if we do think we need a lower bar and seperate process there?), but no short cutting the normal membership progress for Kubernetes (the main org). If they get sponsored to join Kubernetes they should also be invited to whatever other orgs we are actively encouraging new projects to exist in (including kubernetes-sigs).

WDYT? I think that's pretty simple and solves the standard case of "I'd like to join the project to work on \ and I have \." => get invited to our active orgs at once instead of applying once per org. We can encourage new members to follow this route.

It might be reasonable to treat Kubernetes as the one with a "higher bar" during the switch, but for future membership this seems pointless.

I'm not super convinced we need a lower bar for joining any of the orgs going forward. I think that just complicates things and I'm not sure why it would be valid. E.G.

Bob is a participant in subproject A. Was added to k-sigs with no bar/sponsors, and only works on that subproject with his fellow employees.

If subproject A is a valuable SIG project I don't see why Bob wouldn't be eligible to be a _Kubernetes_ member, as long as they have appropriate sponsors and follow the process. Do we have a requirement that you need to work on N projects or certain "better" projects?

[justaugustus]

@BenTheElder -- I think the implication @cblecker was trying to make was that because Bob's membership was not vetted/sponsored that the chain of people he may sponsor afterwards could be considered "tainted".

[BenTheElder]

@justaugustus I don't think bob's status is in question if we are having people join Kubernetes, sponsored by Kubernetes org members (and additionally gaining kubernetes-sigs invites) -- bob never was and still won't be eligible to sponsor for github.com/kubernetes and we don't need to propogate membership in the reverse direction.

We can just suggest that people who aren't in Kubernetes yet should apply through the existing process.
Future applications should go to combined membership rather than special foo-org membership, and sponsors can simply be identified as those with github.com/kubernetes membership.

I'm not sure why a lower bar needs to exist, the current bar for github.com/kubernetes seems relatively low... Interested in counterpoints :-)

[cblecker]

I'm not sure why a lower bar needs to exist

It doesn't need to exist. But if we are going to explicitly say "It doesn't exist" then as I said, we just need to tackle all the angles. Will review again tomorrow when my brain works better lol

[justaugustus]

(Also, fuzzy-brained on this :/)

[mrbobbytables]

Just to provide some data, here is a spreadsheet of the current membership data (as of 2019-07-16 6pm ET) across orgs.

https://docs.google.com/spreadsheets/d/1crsIfA-PhjKYDiX4klsX4zhtL1XU2MVG5JPso2I27Vc/edit#gid=0

Some interesting observations:

• 87 Members across orgs are not in the Kubernetes Org
• 29 Members in incubator are not in the Kubernetes Org
• 43 Members in kubernetes-sigs that are not in the Kubernetes Org

For reference - I used a terrible yq/jq command to generate the raw column data 😬

yq '.admins + .members' \
  config/kubernetes/org.yaml \
  config/kubernetes-client/org.yaml \
  config/kubernetes-csi/org.yaml \
  config/kubernetes-incubator/org.yaml \
  config/kubernetes-sigs/org.yaml \
  | jq -s 'add | .[] | ascii_downcase' | jq -s 'sort | unique | .[]' \
  | sed -e 's/"//g' > members.txt

[spiffxp]

/priority important-soon

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[mrbobbytables]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[nikhita]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[cblecker]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[mrbobbytables]

This may be worth revisiting now that incubator has been deprecated. It's been awhile since I ran a diff, but IIRC there wasn't too many that existed in k-sigs alone.

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[nzoueidi]

/remove-lifecycle stale

[spiffxp]

Needs a refresh on the policy we are comfortable with and steps to reconcile. If someone wants to recap / summarize from above into proposed next steps, I think this can be straightforward to implement. Can either review said next steps or maybe write them up if I find time

[BenTheElder]

I'd love to see data about how many people are in the kubernetes org but not in kubernetes-sigs (and therefore have an extra hurdle whenever we shift work there, it looks like data above is the opposite direction), will try to get to this at some point ...

[mrbobbytables]

last I looked there were very few people in k-sigs that weren't in
kubernetes. Would need to do a pull again to compare.

On Mon, Mar 8, 2021 at 3:23 PM Benjamin Elder [e-mail]
wrote:

I'd love to see data about how many people are in the kubernetes org but
not in kubernetes-sigs (and therefore have an extra hurdle whenever we
shift work there, it looks like data above is the opposite direction), will
try to get to this at some point ...

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/org/issues/966#issuecomment-793048320, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRTD747I7WCCLRG5UNR653TCUW47ANCNFSM4H3WI2AQ
.

[spiffxp]

Another reason to push for this: allow support for "same" team across multiple orgs (ref: https://github.com/kubernetes/org/issues/2559)

I think @kubernetes/release-engineering could benefit from this

[mrbobbytables]

This bubbled up again here - https://github.com/kubernetes/org/pull/2637

[mrbobbytables]

I did a quick analysis of our org membership numbers (As of 4/18/2021).

• 1288 unique members across all our orgs
• 1145 members in the kubernetes org
• 600 members in the kubernetes sigs org
• 131 members that are in kubernetes-sigs, but not kubernetes

Outside of looking at org member activity I think the diff is small enough, and the need arises frequently enough (especially for CI jobs...) where we can make the case that org membership should be equivalent.