# Use inclusive technical terms (EK00035)

import { Aside, Badge } from '@astrojs/starlight/components';

Inclusive technical terms describe what each one does, such as `allowlist` for `whitelist` and `main` for `master`, which keeps your documentation precise and aligned with current industry conventions. EkLine flags non-inclusive technical terms and suggests a clearer replacement (rule EK00035).

## Why use inclusive technical terms in documentation?

Terms like "whitelist" and "blacklist" rely on color to signal allowed or blocked, which is less descriptive than "allowlist" and "blocklist". The inclusive alternatives state the function directly, so a new reader understands them without prior context. Major platforms and language ecosystems have already adopted these terms, so matching them keeps your documentation consistent with the tools your readers use.

## What EkLine flags

EK00035 matches non-inclusive technical terms and suggests an inclusive replacement.

- ❌ **Incorrect:** Add the IP to the whitelist.
- ✅ **Correct:** Add the IP to the allowlist.
- ❌ **Incorrect:** Deploy from the master branch.
- ✅ **Correct:** Deploy from the main branch.

## How to fix

Replace the flagged term with the suggested equivalent: "blacklist" becomes "blocklist", "whitelist" becomes "allowlist", "master" becomes "main" or "primary", "slave" becomes "replica" or "secondary", and "grandfathered" becomes "exempt".

<Aside type="note">
When a term names a fixed external element — such as a Git default branch you cannot rename, or a third-party API field — keep the exact name and ignore the rule for that line.
</Aside>

## FAQ

### What should you use instead of "whitelist" and "blacklist"?

Use "allowlist" and "blocklist". These terms state the function directly, so a new reader understands them without prior context.

### What replaces "master" and "slave" in technical writing?

Use "main" or "primary" for "master", and "replica" or "secondary" for "slave". Major platforms and language ecosystems have already adopted these terms.

## Rule details

| Property | Value |
|----------|-------|
| Rule ID | `EK00035` |
| Category | Inclusive language |
| Default severity | <Badge text="Error" variant="danger" /> |
| Enabled by default | Yes |

## Ignore this rule

To keep a flagged term on one line, add an inline comment with a reason:

```markdown
<!-- ekline-ignore-next-line EK00035 -- third-party API field name -->
Set the `master_key` field required by the payment provider.
```

To disable the rule across your project, add it to the `ignore` list in your [configuration file](/reviewer/configuration/ignoring-rules/#ignore).

## Related rules

- [EK00013](/reviewer/rules/ek00013/) — Prefer inclusive phrasing
- [EK00030](/reviewer/rules/ek00030/) — Avoid language that defines people by disability