defining and scoping the term member

parispittman commented 4 years ago

Problem Statement

The term member is conflated in our various documents, ill-defined, or not defined at all for certain use cases.

Proposed Solution

[ ] have a clear definition and application of when and where we use the term member
- proposing a clear linkable definition of:
- SIG membership (governance) vs GitHub org membership (community-membership.md) TBD vs community membership
[ ] highest priority is picking a different term for member in:
- [x] sig-governance to mean Chair, Tech Lead, and Subproject Owners as a collective. lead, officer, and more suggested in the comments. the documentation lists that for the purpose of that doc they will use member but we've grown a lot since then and need a new word. https://github.com/kubernetes/community/pull/4716. UPDATE: we went with Lead
- [ ] community health check membership questions #153

Open Questions

[x] the anecdote is joining a groups mailing list makes you a member. is that true? if so, let's document it or make it more discoverable. according to community-membership.md membership is tied to being in the GitHub Org. should community-membership.md and sig governance sync with the term member? //steering meeting sept 14th: nothing about mailing list membership means kubernetes membership of any variety (only thing it provides is access to gdocs and calendar invites)
[ ] if membership ("member") in community-membership.md is defined as a github org member, should members of standing in steering committee elections be defined by that with an activity number? (currently only do activity number)
[ ] if its decided sig chairs and owners decide on their own membership definition, where should that be posted and should it be required?

Next Steps

[ ] List the the use cases and where we see member used
- [ ] community-membership.md describes member from the contributor ladder perspective and ties it to GitHub org membership
- [ ] sig-governance.md describes member as someone in a key role to run SIG operations such as Chair or Tech Lead https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md but also talks about 'sig members' and 'organization members' without much clarity
- [ ] committee charters describe their folks as committee members eg https://github.com/kubernetes/community/blob/d1f00a5258bbbe83977a92675fe47c284d72bdb6/committee-code-of-conduct/election.md
- [ ] steering committee elections calls out members of standing which is to be defined on an annual basis by steering and does not take GitHub org membership into consideration as does the member definition in community-membership.md https://git.k8s.io/community/committee-code-of-conduct/election.md
- [ ] this part of the governance doc discusses members of a SIG but we don't define what a member of a SIG is anywhere "Each SIG is comprised of members from multiple companies and organizations..." https://github.com/kubernetes/community/blob/master/governance.md#sigs
[ ] discuss at a steering meeting

Other Considerations, Notes, or References

[ ] having a sig membership definition can help chairs with identifying their members for various activities like voting or reporting.
[ ] in glossary terms code contributor and member: https://github.com/kubernetes/website/blob/master/content/en/docs/reference/glossary/member.md and https://github.com/kubernetes/website/blob/master/content/en/docs/reference/glossary/code-contributor.md

dims commented 4 years ago

I'd say a "member" is someone explicitly added in an "official" roster of some kind (yaml files? github org? github groups? owners_aliases files?)

So "community member" would be someone tracked by being explicitly added to our github org
A "sig member" would be someone added who was added to an owners alias or github group (do we have anything else?)

This would rule out having "i joined a mailing list by myself, so i am a member" scenario. Essentially it's by invitation.

Reminds me of https://quoteinvestigator.com/2011/04/18/groucho-resigns/ :)

nikhita commented 4 years ago

I have added this issue to today's steering committee meeting agenda (4 May 2020).

Dropping some thoughts here to remain async :)

So "community member" would be someone tracked by being explicitly added to our github org

Maybe we call this out as "GitHub membership" explicitly and rename community-membership.md to github-membership.md?

@cblecker and others have mentioned about this in previous contribex calls -- being a member of the GitHub org = getting permissions to lgtm, etc. It shouldn't be necessary to be a part of the GitHub org to feel as a part of the community. IMHO if someone interacts and collaborates with other people about Kubernetes, they are a part of the community. :)

A "sig member" would be someone added who was added to an owners alias or github group (do we have anything else?)

I like this! I would also go ahead and include anyone who has contributed to a repo owned by the SIG or helped with any of the sig-specific non-code contributions.

highest priority is picking a different term for member in sig-governance to mean Chair, Tech Lead, and Subproject Owners as a collective. lead, officer, and more suggested in the comments.

~Maybe if we have explicit terms for "GitHub member" and "SIG member", using just "member" here is ok?~ :thinking: Edit: scratch that, the docs still sound very confusing if "member" is used... Also, is there more context on why the previous SC wasn't supportive of the term "lead"? Trying to understand it better...

if membership ("member") in community-membership.md is defined as a github org member, should members of standing in steering committee elections be defined by that with an activity number? (currently only do activity number)

I think the previous election officers have data (and thoughts!) around how org membership and activity have been related in the past. cc @mrbobbytables @castrojo @idvoretskyi

spiffxp commented 4 years ago

sig-governance to mean Chair, Tech Lead, and Subproject Owners as a collective. lead, officer, and more suggested in the comments.

During the meeting I described how I use the word "Lead" to describe someone who is a member of the union of "Chair, Tech Lead, Subproject Onwers", aka someone who has some decision making power over some part of the project and thus additional accountability, without necessarily scoping the specific decision making power or authority (as that's spelled out in sig-governance).

During the meeting, other members of steering said this is how they undertood the term "Lead"

fejta-bot commented 4 years ago

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

fejta-bot commented 4 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

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 rotten

cblecker commented 4 years ago

/remove-lifecycle rotten

fejta-bot commented 3 years ago

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

fejta-bot commented 3 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

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

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten

fejta-bot commented 3 years ago

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community. /close

k8s-ci-robot commented 3 years ago

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes/steering/issues/160#issuecomment-798793730): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >Send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

kubernetes / steering