This RFC proposes to remove some non-inclusive language from the existing TVM codebase and documentation. It also proposes to introduce a linting script to CI that will prevent these non-inclusive terms from being re-introduced.
In order for TVM to be an open and inclusive community it is important that we are mindful of the language we use in our code and documentation. In particular, we should try where possible to avoid using terminology that other contributors may find offensive.
In TVM we try where possible to avoid using the following terms:
Some suggested replacements are:
In order to prevent non-inclusive language from inadvertently being added to the codebase or documentation, a linting script is run on the CI system for each PR and use of such terms will result in a CI failure.
The first part of the proposal is to manually replace any existing use of non-inclusive terms in the codebase and documentation.
It will attempt to replace the following non-inclusive terms with suitable replacements:
We acknowledge that it will not be possible to replace instances of non-inclusive terms in every single case. In particular, where there is a dependency on a third party tool or library that uses such terms, it may not be possible to make a replacement. This is the case for many URLs in the existing codebase that include the word “master”, since they exist on the “master” branch in some repository. In this case these terms will be left as they are.
The second part of the proposal involves using the blockint command line utility for finding non-inclusive terms.
The blocklint command line utility will be installed in the ci_lint docker image.
A CI script will be created that passes the following terms to blocklint in the blocklist parameter:
It doesn't seem practical to pass gender specific pronouns in the blocklist since these seem to generate many false positives. Instead we propose that the use of gender-specific pronouns when gender is irrelevant or unknown be monitored during code reviews.
Since it is not possible to always replace non-inclusive terms e.g. in the case of references to third party tools, a list of files to skip during linting will be passed in the skiplist parameter to blocklint. In addition, blocklint can be instructed to ignore a particular occurrence of a blocked word, by including a comment “blocklint: pragma” on the same line. Some examples of this use can be seen in the pragma tests for blocklint.
The following open source projects have implemented broadly similar initiatives w.r.t. inclusive language: