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?

[ezzoueidi]

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 🙃

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 <things> and I have <appropriate sponsors and existing work>." => 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 :-)