Sensitive terminology in Zowe (TSC)

[solsu01]

With the current climate, it was brought to my attention that it might be prudent to proactively avoid terms like whitelist/blacklist or master/slave in open source projects. Examples: https://github.com/rails/rails/issues/33677 https://www.postgresql.org/message-id/4DC14C0F-2211-48A5-A45E-3671BF97E9D6%40excoventures.com

Here are results from a quick github search for zowe: https://github.com/search?q=org%3Azowe+whitelist+OR+blacklist+OR+slave&type=Code

[1000TurquoisePogs]

Given our target users, it doesn't help to follow the crowd without analyzing the familiarity and understand-ability of proposed terminology changes. I'm curious about what terms veteran mainframers know, versus millennials, and how can we satisfy them both without invoking a protest. One of the UI proposals we had in the beginning of Zowe was a form of "internationalization" in which you could switch the terminology of the UI around on the fly, such that some people would see "STCs" and "cylinders" while others would see "services" and "bytes", or similar.

My recommendation is to collect a list of terminologies the world is currently being sensitive about, and see what words with similar meanings exist. Then, send out a survey to find out what our end users understand, because for example, replacing whitelist/blacklist with rejectlist/acceptlist is bizarre to me. I've never seen rejectlist/acceptlist. On the other hand, I have seen include/exclude, and would find those to be equal in meaning. Let's collect a list of such things before making changes while the world is still uncertain as to what is hit or miss.

[1000TurquoisePogs]

Thanks for the zowe search. I thought we had no use of 'slave', but we do with Jenkins! I was just thinking about how some words we cannot change if they are a part of a library we use rather than our code itself. For example, nodejs https://nodejs.org/dist/latest-v12.x/docs/api/cluster.html#cluster_cluster_ismaster Interestingly, their terminology is master&worker. master has different meanings, such as with branches where master has nothing to do with slave. so I'd say master alternatives should be broken down by topic:

master as a source code terminology: primary default main (weird svn terminology) trunk release <- my favorite because we as a community agreed that work happens on "staging", and our current master branches are supposed to be untouched, just containing release quality code.

master & slave software references: master and worker leader and worker leader and follower ... primary and secondary is not valid. it implies a failover architecture, which is not what master & slave designs do. They are more about delegator & delegatee, or orchestrator & follower... and many other clunky words. leader, worker, and follower are all pretty simple to me.

[1000TurquoisePogs]

I just ran a test, and it appears that git understands what branch is considered the default, so you can have master not exist without implicit git clone commands suddenly failing.

Not sure how far github has gone with renaming, as their instructions when making a new repo currently say this:

echo "# main-test" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin git@github.com:1000TurquoisePogs/main-test.git
git push -u origin master

[pdubz3]

I'd like to revisit this as part of the next ZLC call. Broadcom feels very strongly about eliminating the use of inappropriate and insensitive terminology, especially focused on but not limited to those related to black/white and master/slave. Our Mainframe Software Division is making this a priority as are the other divisions of Broadcom because it's the right thing to do. I would imagine that a significant number of members and leaders within the Zowe community likely feel the same way. I'd like to request that the ZLC provide guidance to the squads to complete their own analysis of the effort required and come back with an estimate of when they feel they would be able to complete it. I'm not suggesting setting a deadline or causing anyone to miss any committed targets. I'm simply arguing for guidance to make "language matters" a priority to all of the squads. @armstro if you could please queue this up for next Wednesday I'd appreciate it. Thank you!

[armstro]

Happy to add this to the next ZLC agenda - I guess I ask for some "prep" questions for the discussion to make this actionable -

• I think Doc squad has already taken some actions on this - need to confirm and understand what has been done - maybe @nannanli or @brandon.jenkins@broadcom.com can report
• Doc is only one aspect and the code itself is another - I am unclear what tools exists to help with the code (I'm assuming just like security scans or license scans there is (or will be) sensitivity scans?
• I recall @jmertic thinking OMP might have a panel for guidance - maybe he can update us
• Since we are getting ready to update zowe.org - would be good to try any tools or scans to try to catch issues before we go live
• If there are not OMP or other public tools - can we see if any of our participating companies have something to contribute we could use
• Is there some education we can offer the community - maybe a badge - to help increase awareness in the community (and not rely on tools to catch issues after the fact but prevent issues)

So happy to add to agenda - just want to provide useful guidance.

[nannanli]

@armstro The doc squad discussed the following terms and replacements that's suggested by IBM. We searched for these terms in the docs and found some occurrences of master in docs which all refer to master branch. However, master is a default term in GitHub (such as master branch but it's not paired with slave). Listing them here so they could be discussed in the ZLC call.	Prohibited terms	Suggested replacements	Guidance
blacklist	blocklist
whitelist	allowlist
slave	Use the appropriate replacement for your domain, such as such as "worker", "child", "helper", "replica", "follower", or "secondary [server, node, process, or other noun]".
master (when paired with slave)	Use the appropriate replacement for your domain, such as "controller", "leader", "manager", "main", "coordinator", "parent", or "primary [server, node, process, or other noun]".	Certain uses of the term "master" are acceptable when it is not paired with the term "slave". If the term master is used in a context such as "Master Data Management" where there is no "Slave Data Management" counterpart, then that use of the term master is considered acceptable and not offensive. Additional examples where the term master is acceptable, assuming it is not used in conjunction with a related term including the word slave: masterpiece, Scrum Master (can consider change to Scrum Leader however)

[armstro]

Discussed in today's ZLC.....squads were asked to assess in this PI the size the effort for any terminology changes in the source code for prioritization in future PI. Doc squad already well on the way of changes listed above.

[markjhollands]

Following on from @nannanli comment above.

On October 1st GitHub changed the default branch name from master to main, meaning any new repositories will have this as default. On the ZLC call someone also mentioned Git itself will make this change soon.

It would be worth each squad also investigating what would be required to make this change as well.

[jmertic]

I will note that there is a launch of the Inclusive Naming Initiative today which might be useful for this effort to engage with. The first community meeting will be held via https://www.twitch.tv/cloudnativefdn. More details on the initiavite are at https://inclusivenaming.org/

[dkelosky]

https://inclusivenaming.org/language/word-list/ has guidance that is a bit different than the guidance listed above. Do we have guidance that has been agreed upon?

[balhar-jakub]

Would it be possible to link the issues created in the squad repos to this issue, so that it's simple to see the status?

The API ML squad one is: https://github.com/zowe/api-layer/issues/934

[jmertic]

Is this still ongoing?

[balhar-jakub]

According to LFX insights, there is still some sensitive terminology used somewhere.

I don't think this will ever stop, but do we need to have the issue for it? Probably not.

[balhar-jakub]

According to the LFX Security we still have some sensitive words used across the place.

[balhar-jakub]

The existence of the issue isn't very useful, as such I will close the issue.

The aim is instead on a yearly basis to go through the LFX Insights and remove newly found issues.