We should formalize our policy around exclusionary language in SIG-Security. I have added it as an agenda item for the upcoming 12/9/2020 meeting.
In recent times these have all been commented in an ad-hoc way, but we should make it explicit in the contributor and member guide. This includes not allowing the following phrases:
master/slave (use primary/replica instead)
blacklist (use deny list instead)
whitelist (use allow list instead)
There are some usages of the above terms in the repo and security assessments that can be easily cleaned and we can use this as a tracking issue for that.
We should also decide on whether we want to rename the master branch in the repository to something else like main.
There is a whole list of other language that should not be used.
TODO: (PRs should reference this Issue number)
References:
These could be also added into lint checks being created: https://github.com/cncf/sig-security/issues/311
I am a bit worried about renaming master branch, im not sure if all the tooling works well with a new convention.
@lumjjb we need to work towards this goal. if that means analysing the tooling we currently use for compatibility, lets add it to the list.
I think we can work with an alternative naming for the master branch, like main. Based on my experience playing with it so far, I don't believe the tooling in #311 will be impacted, we'll just need to be aware of the new convention.
Happy to help with this effort
@TheFoxAtWork @ultrasaurus @pragashj there is interest in pursuing this work. Am adding the project tag.
Folx - i've gone ahead and added this to the project board. Individuals interested in helping out on this should submit small PRs over large ones.
@pragashj @ultrasaurus recommend we identify a Co-chair for this as i believe can go on our monthly TOC slide.
Also need to identify a project lead, @anvega ?
FWIW in the last meeting there was broad support for adopting https://inclusivenaming.org as the canonical reference specifically. Worth linking to in contributor/new member pages to that effect. Great stuff!
For the master branch renaming tooling, i am leaning towards CNCF doing that investigation, i suspect that since they control the organization, they kind of control the tooling as well. @amye are there plans to look at this for the CNCF git repos?
I'd like to reinvigorate this. the TOC has made the change, we need to as well.
There are automation tools to support language that might be useful, one example is Vale (this example is Google's naming guide): https://github.com/errata-ai/Google
The master branch has been renamed to main.
For this to be a "project" we need a project lead and some one from leadership team to sponsor it. Alternately, we could just make it a governance issue and label it "help wanted." Though I do think it would be ideal, if someone could step up an itemize the set of things that need to get done, so we can add a checklist to the top and have someone on deck who will review PRs and make a call as to when this is done.
Most helpful comment
There are automation tools to support language that might be useful, one example is Vale (this example is Google's naming guide): https://github.com/errata-ai/Google