Inclusive Naming Criteria

Owned by Bobbi Muscara
Sept 23, 2021
2 min read

Context

The Hyperledger DCI Working Group would like to propose best practices to be adopted by Hyperledger projects and labs around inclusive naming. Hyperledger continuously promotes "all are welcome here" to its community. The DCI Working Group believes one way for Hyperledger to continue to improve is by encouraging inclusive language across all of its projects. We believe language matters, especially when fostering an open source community. Updating language across the projects to be more inclusive is a powerfuk step in continuing to foster and promote diversity and inclusion in its community. This blog post provides additional context for those interested.

The DCI Working Group is recommending the Technical Steering Committee to approve the following proposal with each of these recommendations. These are recommended best practices for projects that we would suggest them to implement.

Recommendations

Recommendation #1:  We recommend all Hyperledger projects and labs update their contributor and/or documentation guidelines to have a statement referencing and encouraging inclusive language in the community's work. One example from Besu found on the Documentation Style Guide is below. Every project and lab is encouraged to copy and paste this suggestion into their contributions.

Inclusive Language: 

  • Consider that users who will read the docs are from different background and cultures and that they have different preferences.
  • Avoid potential offensive terms and, for instance, prefer "allow list and deny list" to "white list and black list".
  • We believe that we all have a role to play to improve our world, and even if writing inclusive doc might not look like a huge improvement, it's a first step in the right direction.
  • We suggest to refer to Microsoft bias free writing guidelines and Google inclusive doc writing guide as starting points.

Recommendation #2: We recommend all Hyperledger projects and labs make these specific language changes to their projects. While the DCI Working Group understands that projects should make decisions, we wanted to provided some specific examples they can change to encourage more inclusivity. To implement these changes, they can make updates manually or they can use the dci-lint tool (see recommendation #3) to automate these updates.

  • master → main
  • slave → replicas
  • blacklist → denylist
  • whitelist → allowlist

Recommendation #3:  We recommend that the dci-lint tool that Peter Somogyvari wrote be implemented across all Hyperledger repos. The goal of the dci-lint tool is for projects to be able to detect any language changes. This tool helps remove a barrier to entry for updating language in the projects to be more inclusive. Hyperledger staff is prepared to push this out across the various repos with no effort from maintainers. The tool does not specify which language changes to make, but it makes the process easier to implement any changes the projects would like.

Recommendation #4: Include Inclusive language as one badge in the Project Badging Proposal. This recommendation is assuming the TSC makes the decision to move forward with a project badging system. If projects meet the recommendations #1, #2, and #3 above, they can gain a badge for Inclusive Language best practices.