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 :-)

[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

[spiffxp]

/milestone v1.23

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 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 rotten

[justaugustus]

/remove-lifecycle rotten

[BenTheElder]

Another example of the friction this introduces kubernetes/test-infra#24814 (comment)

[BenTheElder]

I still think we should just make these equivalent and automatically add users to both organizations.

Projects are semi-arbitrarily in one org or the other as a matter of history and working on many things involves code spanning both orgs.

[mrbobbytables]

They are equiv now, but nothing automatic for adding users.

[zvonkok]

@mrbobbytables Just checked I am not a member of kubernetes but kubernetes-sigs per this comment I should have been auto-added:

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

[mrbobbytables]

@zvonkok we are not doing any automatic syncing the orgs. The policy is changed so that you are no longer applying to a specific org, you are applying to be a member of the project .

If you are a member of one org you can join the others without sponsors or going through further due-diligence. E.g. if you're currently a member of kubernetes-sigs and want to be a member of kubernetes, you can open a PR adding yourself (following our commit msg structure) or fill out a form requesting it and it'll be processed in the next batch.

[mrbobbytables]

Changes have been merged into our membership guidelines:
kubernetes/community#6330

EDIT: accidentally hit the button too soon. With the changes merged, I'm going to go ahead and close out this issue. 👍

/close

[BenTheElder]

Should we do a one time catchup sync?