BMAD-METHOD/expansion-packs/bmad-technical-writing/checklists/inclusive-language-checklis...

81 lines
2.8 KiB
Markdown

# Inclusive Language Checklist
Use this checklist to ensure writing is inclusive, welcoming, and accessible to all readers.
## Gender-Neutral Language
- [ ] Use "they/them" instead of "he/she" for generic references
- [ ] Avoid gendered job titles (use "developer" not "programmer/programmeress")
- [ ] Use "people" instead of "guys" or "mankind"
- [ ] Avoid unnecessary gender specification
- [ ] Examples include diverse names from various cultures
## Ableist Language
- [ ] Avoid "sanity check" → use "confidence check" or "validation"
- [ ] Avoid "dummy" → use "placeholder" or "sample"
- [ ] Avoid "crippled" → use "restricted" or "limited"
- [ ] Avoid "crazy/insane" → use "unexpected" or "unusual"
- [ ] Avoid "blind spot" → use "gap" or "oversight"
## Cultural Sensitivity
- [ ] Examples include names from diverse cultural backgrounds
- [ ] Avoid cultural stereotypes or assumptions
- [ ] Consider international audience (not US-centric)
- [ ] Dates formatted clearly (avoid ambiguous MM/DD vs DD/MM)
- [ ] Time zones considered when relevant
## Technical Terminology
- [ ] Replace "master/slave" with "primary/replica" or "leader/follower"
- [ ] Replace "whitelist/blacklist" with "allowlist/blocklist"
- [ ] Replace "grandfathered" with "legacy" or "existing"
- [ ] Use industry-standard inclusive alternatives
## Reader Background Assumptions
- [ ] Don't assume reader's educational background
- [ ] Don't assume reader's geographic location
- [ ] Don't assume reader's work environment
- [ ] Don't assume reader's native language is English
- [ ] Explain acronyms and jargon
## Skill Level Language
- [ ] Avoid "obviously" or "clearly" (may not be obvious to all)
- [ ] Avoid "just" minimizing difficulty ("just do X")
- [ ] Avoid "simple" or "easy" (relative terms)
- [ ] Encourage learning without shaming lack of knowledge
- [ ] Use "you may already know" instead of "you should know"
## Inclusive Examples
- [ ] Character names represent diverse backgrounds
- [ ] Example scenarios avoid stereotypes
- [ ] User personas include diverse characteristics
- [ ] Visual representations include diversity
- [ ] Example data includes international contexts
## Age and Experience
- [ ] Avoid ageist language ("young developer", "digital native")
- [ ] Don't assume readers are career programmers
- [ ] Welcome career changers and self-taught developers
- [ ] Respect different learning paces and styles
## Socioeconomic Considerations
- [ ] Don't assume access to expensive tools (suggest free alternatives)
- [ ] Don't assume high-end hardware availability
- [ ] Consider readers with limited internet access
- [ ] Provide low-cost or free learning resources
## Tone and Voice
- [ ] Welcoming and encouraging tone
- [ ] Avoid condescension or talking down
- [ ] Celebrate different paths to programming
- [ ] Support diverse learning styles
- [ ] Foster growth mindset