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.

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

CI Docs: Using an inclusive linter #726

Merged
merged 7 commits into from
Oct 20, 2021
Merged
Changes from 5 commits
Commits
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
37 changes: 37 additions & 0 deletions docs/continuous-integration/inclusive-linting.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# Inclusive Linting
Copy link
Contributor

Choose a reason for hiding this comment

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

Love to see this guidance for CI. Thanks to propose and create the document.


As software professionals we should strive to promote an inclusive work environment, which naturally extends to the code and documentation we write. It's important to keep the use of inclusive language consistent across an entire project or repository.

To achieve this, we recommend using a text file analysis tool such as an inclusive linter and including this as a step in your CI pipelines.

## What to Lint for

The primary goal of an inclusive linter is to flag any occurrences of non-inclusive language within source code (and optionally suggest some alternatives). Non-inclusive words or phrases in a project can be found anywhere from comments and documentation to variable names.

An inclusive linter may include its own dictionary of "default" non-inclusive words and phrases to run against as a good starting point. These tools can also be customizable, oftentimes offering the ability to omit some terms and/or add your own.

The ability to add additional terms to your linter has the added benefit of enabling linting of sensitive language on top of inclusive linting. This can prevent things such as customer names or other non-public information from making it into your git history, for instance.

## Getting Started with an Inclusive Linter

### [`woke`]

One inclusive linter we recommend is `woke`. It is a language-agnostic CLI tool that detects non-inclusive language in your source code and recommends alternatives. While `woke` automatically applies a [default ruleset] with non-inclusive terms to lint for, you can also apply a custom rule config (via a yaml file) with additional terms to lint for. See [`example.yaml`] for an example of adding custom rules.
madossan01 marked this conversation as resolved.
Show resolved Hide resolved

jeremydelacruz marked this conversation as resolved.
Show resolved Hide resolved
Running the tool locally is relatively straightforward:

```sh
$ woke test.txt

test.txt:2:2-11: `guys` may be insensitive, use `folks`, `people` instead (warning)
* guys
^
```

`woke` can be run locally on your machine or CI/CD system and is also available as a [GitHub Action]. For more information about configuration and usage, see the official [docs].

[`woke`]: https://github.com/get-woke/woke
[default ruleset]: https://github.com/get-woke/woke/blob/main/pkg/rule/default.yaml
[`example.yaml`]: https://github.com/get-woke/woke/blob/main/example.yaml
[GitHub Action]: https://github.com/marketplace/actions/run-woke
[docs]: https://docs.getwoke.tech/
jeremydelacruz marked this conversation as resolved.
Show resolved Hide resolved
jeremydelacruz marked this conversation as resolved.
Show resolved Hide resolved