Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formation of WG Naming #4884

Merged
merged 5 commits into from
Jul 1, 2020
Merged

Formation of WG Naming #4884

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
b0010e6
slack: Create WG Naming channel
justaugustus Jun 24, 2020
53e7d0a
wg-naming: Hello World!
justaugustus Jun 24, 2020
3b35f49
wg-naming: Implement all existing suggestions from PR
celestehorgan Jun 26, 2020
3ee9e82
wg-naming: Address additional comments
celestehorgan Jun 26, 2020
0bfd6f7
wg-naming: Add post-formation discussion points
justaugustus Jun 30, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions OWNERS_ALIASES
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -126,6 +126,11 @@ aliases:
wg-multitenancy-leads:
- srampal
- tashimi
wg-naming-leads:
- celestehorgan
- jdumars
- justaugustus
- zacharysarah
wg-policy-leads:
- ericavonb
- hannibalhuang
Expand Down
2 changes: 1 addition & 1 deletion committee-code-of-conduct/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ The [charter](charter.md) defines the scope and governance of the Code of Conduc
* Aeva van der Veen (**[@AevaOnline](https://github.com/AevaOnline)**), Microsoft
* Jennifer Rondeau (**[@Bradamant3](https://github.com/Bradamant3)**), Stripe
* Carolyn Van Slyck (**[@carolynvs](https://github.com/carolynvs)**), Microsoft
* Jaice Singer DuMars (**[@jdumars](https://github.com/jdumars)**), Google
* Jaice Singer DuMars (**[@jdumars](https://github.com/jdumars)**), Apple
* Tasha Drew (**[@tashimi](https://github.com/tashimi)**), VMware

## Contact
Expand Down
1 change: 1 addition & 0 deletions communication/slack-config/channels.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -370,6 +370,7 @@ channels:
- name: wg-lts
- name: wg-machine-learning
- name: wg-multitenancy
- name: wg-naming
- name: wg-onprem
archived: true
- name: wg-policy
Expand Down
3 changes: 2 additions & 1 deletion sig-list.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -58,6 +58,7 @@ When the need arises, a [new SIG can be created](sig-wg-lifecycle.md)
|[LTS](wg-lts/README.md)|* API Machinery<br>* CLI<br>* Node<br>|* [Dhawal Yogesh Bhanusali](https://github.com/imkin), VMware<br>* [Quinton Hoole](https://github.com/quinton-hoole), Huawei<br>* [Tim Pepper](https://github.com/tpepper), VMware<br>* [Nick Young](https://github.com/youngnick), VMWare<br>|* [Slack](https://kubernetes.slack.com/messages/wg-lts)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-wg-lts)|* Regular WG Meeting: [Tuesdays at 09:00 PT (Pacific Time) (bi-weekly)](https://zoom.us/j/473177294)<br>
|[Machine Learning](wg-machine-learning/README.md)|* Apps<br>* Node<br>|* [Klaus Ma](https://github.com/k82cn), Huawei<br>* [Kenneth Owens](https://github.com/kow3ns), Google<br>* [Vishnu Kannan](https://github.com/vishh), Google<br>|* [Slack](https://kubernetes.slack.com/messages/wg-machine-learning)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-wg-machine-learning)|* Regular WG Meeting: [Thursdays at 13:00 PT (Pacific Time) (biweekly)](https://zoom.com.cn/j/103404077)<br>
|[Multitenancy](wg-multitenancy/README.md)|* API Machinery<br>* Auth<br>* Network<br>* Node<br>* Scheduling<br>* Storage<br>|* [Sanjeev Rampal](https://github.com/srampal), Cisco<br>* [Tasha Drew](https://github.com/tashimi), VMware<br>|* [Slack](https://kubernetes.slack.com/messages/wg-multitenancy)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-wg-multitenancy)|* Regular WG Meeting: [Tuesdays at 11:00 PT (Pacific Time) (biweekly)](https://zoom.us/my/k8s.sig.auth)<br>
|[Naming](wg-naming/README.md)|* Architecture<br>* Contributor Experience<br>* Docs<br>|* [Celeste Horgan](https://github.com/celestehorgan), CNCF<br>* [Jaice Singer DuMars](https://github.com/jdumars), Apple<br>* [Stephen Augustus](https://github.com/justaugustus), VMware<br>* [Zach Corleissen](https://github.com/zacharysarah), Linux Foundation<br>|* [Slack](https://kubernetes.slack.com/messages/wg-naming)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-wg-naming)|
|[Policy](wg-policy/README.md)|* Architecture<br>* Auth<br>* Multicluster<br>* Network<br>* Node<br>* Scheduling<br>* Storage<br>|* [Erica von Buelow](https://github.com/ericavonb), Red Hat<br>* [Howard Huang](https://github.com/hannibalhuang), Huawei<br>|* [Slack](https://kubernetes.slack.com/messages/wg-policy)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-wg-policy)|* Regular WG Meeting: [Wednesdays at 16:00 PT (Pacific Time) (weekly)](https://zoom.us/j/7375677271)<br>
|[Security Audit](wg-security-audit/README.md)|* Auth<br>|* [Aaron Small](https://github.com/aasmall), Google<br>* [Craig Ingram](https://github.com/cji), Salesforce<br>* [Jay Beale](https://github.com/jaybeale), InGuardians<br>* [Joel Smith](https://github.com/joelsmith), Red Hat<br>|* [Slack](https://kubernetes.slack.com/messages/wg-security-audit)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-wg-security-audit)|* Regular WG Meeting: [Mondays at 12:00 PT (Pacific Time) (weekly)](https://docs.google.com/document/d/1RbC4SBZBlKth7IjYv_NaEpnmLGwMJ0ElpUOmsG-bdRA/edit)<br>

Expand All @@ -72,7 +73,7 @@ When the need arises, a [new SIG can be created](sig-wg-lifecycle.md)

| Name | Label | Members | Contact |
|------|--------|---------|---------|
|[Code of Conduct](committee-code-of-conduct/README.md)|code-of-conduct|* [Aeva van der Veen](https://github.com/AevaOnline), Microsoft<br>* [Jennifer Rondeau](https://github.com/Bradamant3), Stripe<br>* [Carolyn Van Slyck](https://github.com/carolynvs), Microsoft<br>* [Jaice Singer DuMars](https://github.com/jdumars), Google<br>* [Tasha Drew](https://github.com/tashimi), VMware<br>|* [Private Mailing List]([email protected])
|[Code of Conduct](committee-code-of-conduct/README.md)|code-of-conduct|* [Aeva van der Veen](https://github.com/AevaOnline), Microsoft<br>* [Jennifer Rondeau](https://github.com/Bradamant3), Stripe<br>* [Carolyn Van Slyck](https://github.com/carolynvs), Microsoft<br>* [Jaice Singer DuMars](https://github.com/jdumars), Apple<br>* [Tasha Drew](https://github.com/tashimi), VMware<br>|* [Private Mailing List]([email protected])
|[Product Security](committee-product-security/README.md)|product-security|* [CJ Cullen](https://github.com/cjcullen), Google<br>* [Craig Ingram](https://github.com/cji), Salesforce<br>* [Joel Smith](https://github.com/joelsmith), Red Hat<br>* [Luke Hinds](https://github.com/lukehinds), Red Hat<br>* [Micah Hausler](https://github.com/micahhausler), Amazon<br>* [Tim Allclair](https://github.com/tallclair), Google<br>|* [Private Mailing List]([email protected])
|[Steering](committee-steering/README.md)|steering|* [Christoph Blecker](https://github.com/cblecker), Red Hat<br>* [Derek Carr](https://github.com/derekwaynecarr), Red Hat<br>* [Davanum Srinivas](https://github.com/dims), VMware<br>* [Lachlan Evenson](https://github.com/lachie83), Microsoft<br>* [Nikhita Raghunath](https://github.com/nikhita), VMware<br>* [Paris Pittman](https://github.com/parispittman), Apple<br>* [Aaron Crickenberger](https://github.com/spiffxp), Google<br>|* [Slack](https://kubernetes.slack.com/messages/steering-committee)<br>* [Mailing List](https://groups.google.com/a/kubernetes.io/forum/#!forum/steering)<br>* [Private Mailing List]([email protected])
<!-- BEGIN CUSTOM CONTENT -->
Expand Down
27 changes: 26 additions & 1 deletion sigs.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2650,6 +2650,31 @@ workinggroups:
contact:
slack: wg-multitenancy
mailing_list: https://groups.google.com/forum/#!forum/kubernetes-wg-multitenancy
- dir: wg-naming
name: Naming
justaugustus marked this conversation as resolved.
Show resolved Hide resolved
stakeholder_sigs:
- Architecture
- Contributor Experience
- Docs
label: naming
leadership:
chairs:
- github: celestehorgan
name: Celeste Horgan
company: CNCF
- github: jdumars
name: Jaice Singer DuMars
company: Apple
- github: justaugustus
name: Stephen Augustus
company: VMware
- github: zacharysarah
name: Zach Corleissen
company: Linux Foundation
meetings: []
contact:
slack: wg-naming
mailing_list: https://groups.google.com/forum/#!forum/kubernetes-wg-naming
- dir: wg-policy
name: Policy
mission_statement: >
Expand Down Expand Up @@ -2809,7 +2834,7 @@ committees:
company: Microsoft
- github: jdumars
name: Jaice Singer DuMars
company: Google
company: Apple
- github: tashimi
name: Tasha Drew
company: VMware
Expand Down
80 changes: 80 additions & 0 deletions wg-naming/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
<!---
This is an autogenerated file!

Please do not edit this file directly, but instead make changes to the
sigs.yaml file in the project root.

To understand how this file is generated, see https://git.k8s.io/community/generator/README.md
--->
# Naming Working Group


## Stakeholder SIGs
* SIG Architecture
* SIG Contributor Experience
* SIG Docs



## Organizers

* Celeste Horgan (**[@celestehorgan](https://github.com/celestehorgan)**), CNCF
* Jaice Singer DuMars (**[@jdumars](https://github.com/jdumars)**), Apple
* Stephen Augustus (**[@justaugustus](https://github.com/justaugustus)**), VMware
* Zach Corleissen (**[@zacharysarah](https://github.com/zacharysarah)**), Linux Foundation

## Contact
- Slack: [#wg-naming](https://kubernetes.slack.com/messages/wg-naming)
- [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-wg-naming)
- [Open Community Issues/PRs](https://github.com/kubernetes/community/labels/wg%2Fnaming)
<!-- BEGIN CUSTOM CONTENT -->

**The following section will be reworked and formalized as a charter once the
Working Group has been approved by the Steering Committee.**

## Goals

- Evaluate language and naming choices within the Kubernetes project, with
a specific initial focus of:
- Removing barriers to contribution and adoption by replacing harmful language with neutral terms whenever possible, including but not limited to language linked to racism, sexism, homophobia, transphobia, ableism, or discrimination against any protected or historically underrepresented group.
- Improving clarity of codebases and documentation by replacing idioms,
metaphors and slang specific to the English language
- Create a list of harmful terms with proposed replacements
- Define how any member of the Kubernetes project can
recommend language, how others can evaluate that proposal, and how to
implement replacements across all codebases.
- Provide an easily findable location for language recommendations and
follow-up issues, similar to an architectural decision record
- Define long-term ownership of this process
- Work with stakeholder SIGs to implement the changes recommended. We
anticipate the following:
- Provide stakeholder SIGs with guidance on naming, language conventions, and
processes
- Collaborate with SIG Architecture and other stakeholders on an
implementation timeline and strategies for dealing with follow-up issues
from renaming, like deprecations
- Collaborate with SIG Docs and SIG Contributor Experience on documenting
language recommendations and processes
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this also involve renaming the master branch for all repos and would renaming the branch be a criteria for dissolution? It's heavily tied to how quickly and widely GitHub responds so I just want us to be cognizant of that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment, CNCF is planning to wait for GitHub to roll out changes regarding master branch naming. We're hoping that waiting on GitHub to make changes centrally results in less tooling issues down the line.

Ultimately the choice lies with the community, but I would strongly recommend Kubernetes take the same tactic. Personally I would not include this discussion in the WG's domain – the WG should focus on Kubernetes and related projects only, not the wording in the tooling, code language or libraries Kubernetes uses.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we're waiting for GitHub's lead here, and they should have a response soon.
(Discussed during the 6/25 GitHub Administration meeting.)

I'm taking point on this from the WG Naming side and will open an issue for this later in the week.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Added as a post-formation discussion point.)

- Work with the Code of Conduct Committee to add code architecture to the COC
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will help find a good home for this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Added as a post-formation discussion point.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@justaugustus As this was added to the post-formation discussion point, should this line still exist in the goals?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cblecker -- intentionally duplicated, so we'd know where to edit the language later

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not very clear on what this point means.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neither am I. @justaugustus @celestehorgan @zacharysarah Could you elaborate on this point?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@deads2k @cblecker The goal is for inclusive naming in software architecture, not just in docs. For example, replacing "master/slave" terminology in docs but not in functions, classes, variables, etc. is an empty gesture.

What's a more accurate way to refer to code in this specific context?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may need the full @kubernetes/code-of-conduct-committee to weigh in on this. One could argue that code is language as much as an issue or Slack conversation. That would cover future cases, but remediation of existing code would have to be handled by individuals in the OWNERS files IMO, much like if someone trashes a GitHub issue, we (the CoC Committee) ask the Kubernetes GitHub admin team to remove the offending comments. I still believe the existing CoC covers this, as we collectively define the edges of what is acceptable or not. From the CoC specifically:

We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I don't think the CoC needs to be modified here. Perhaps this goal can be changed to "Review with CoCC guidelines and polices around use of language/terminology in code" or something similar?

The idea being:

  • I honestly don't believe any of the terminology currently used in code was placed there intentionally to harass anyone (if this was the case, it would already be CoC covered)
  • We still want to be able to make binding policies around how to remediate language used in code, to ensure it doesn't bring harm. How do we do that? (I agree with the binding part, but I'm not sure the CoC is the right tool)

But bringing it back to how to we approve this WG, I'd suggest changing this to "review" as I've suggested above will allow the freedom to explore this question throughly with the CoCC to answer if the CoC is or is not the right tool to address this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now, I suggest we remove any mention of the COCC from this WG, and put it as an agenda item for the WG's work.

That said, per later discussion in this thread: @jdumars is joining us in this initiative, so involvement from that quarter will be there.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Added as a post-formation discussion point.)


## Dissolution Criteria

Once the Kubernetes community has:

- A process in place to evaluate language changes on an ongoing basis
- A binding list of terms to avoid in codebases across the project
- A timeline on which to replace component names in the kubernetes/kubernetes
Copy link
Contributor

@deads2k deads2k Jun 24, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like sustainability after this working group disbands would require that the process create above and the future owners of that process, be able to handle identification, implementation, and timeline. Could we use that process and those owners to drive the first set of changes as well? If not, can we have confidence that this effort will be self-sustaining over time?

See the comment from Celeste in this PR about avoiding the need to reform this group for the next cultural moment: https://github.com/kubernetes/community/pull/4884/files#r445043710

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "on which to replace" mean for such a timeline in an OpenSource project? Who drives it? Who contributes the resources to implement changes? I could imagine that the wg will output a plan with parties committed to implement it. I guess that's what this means, and not an order to be finished by date X.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Working with the stakeholders and code owners will be key. Yes, this effort will need to be resourced. We've had lots of interest and volunteers to help with this, but ensuring we do this in a way that doesn't introduce bugs/regressions will need effort from code owners.

What that timeline is and how it will be resourced is an open question for the working group (and one they can answer after formation IMO)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I offer to program-manage this effort to the extent of bringing the stakeholders and parties together to discuss a strategy for getting the work moving, tracking the work (including visualisations and self-reporting documents), and updating on progress.

One of my first steps would be to bring folks together to discuss implementation strategy — how and where does the work start from a technical perspective.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Added as a post-formation discussion point.)

codebase
Comment on lines +66 to +67
Copy link
Member

@nikhita nikhita Jun 24, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few questions here:

  • Would this WG focus only on k/k? My understanding was that it would look at naming practices across all our repos (even k-sigs, k-csi, k-client), docs, etc.

  • Maybe it would be better to rename "component names" to something slightly more...generic? Just to ensure that we don't tie the dissolution criteria to only component names... 🤔

  • Would the WG disband after a timeline has been agreed upon or would it disband after all the changes have been made as per the timeline?

Copy link
Member

@spiffxp spiffxp Jun 26, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I personally would find it helpful if the group stuck around until changes have been made. The model I have is WG-Apply, which existed until server side apply was implemented.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't conferred with @justaugustus on this, so he may disagree, but here's my thoughts:

Would this WG focus only on k/k? My understanding was that it would look at naming practices across all our repos (even k-sigs, k-csi, k-client), docs, etc.

Per an earlier comment, we're changing the wording in this WG to address the Kubernetes project – so presumably.. everything? 😅

Maybe it would be better to rename "component names" to something slightly more...generic? Just to ensure that we don't tie the dissolution criteria to only component names... 🤔

+1! "feature names?" "method names"? I'm unsure. I'll brainstorm on this for a bit.

Would the WG disband after a timeline has been agreed upon or would it disband after all the changes have been made as per the timeline?

Personally I'd like to stick around until work is executed for accountability's sake. This isn't high priority work in relation to new releases, for example, but I think it's high importance and I think having the WG around to see the work through would be good.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Added as a post-formation discussion point.)

Copy link
Member Author

@justaugustus justaugustus Jun 30, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per an earlier comment, we're changing the wording in this WG to address the Kubernetes project – so presumably.. everything? sweat_smile

Agreed that the goal is to serve across the project, not just kubernetes/kubernetes.

Maybe it would be better to rename "component names" to something slightly more...generic? Just to ensure that we don't tie the dissolution criteria to only component names... thinking

+1! "feature names?" "method names"? I'm unsure. I'll brainstorm on this for a bit.

Yep. We can workshop the language post-formation.

Personally I'd like to stick around until work is executed for accountability's sake. This isn't high priority work in relation to new releases, for example, but I think it's high importance and I think having the WG around to see the work through would be good.

Agreed. I also intend to action on changes ahead of WG dissolution.

- Defined long-term ownership of the policies and processes this WG creates

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-blocking nit: whitespace

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cblecker -- intentional. see the next line.

this WG will dissolve.

## Post-formation Discussion Points

- Discuss appropriate process for branch renaming with GitHub Administration
subproject (SIG ContribEx)
- Work with the Code of Conduct Committee to add code architecture to the COC
- A timeline on which to replace component names in the kubernetes/kubernetes
- Clarify that WG should not dissolve until after changes have been made

<!-- END CUSTOM CONTENT -->