“We must help bridge gaps of inequity by using our technology, extended ecosystem, and the expertise of our teams, while creating more opportunities for more people, and acting responsibly to drive change.”
Chuck Robbins, CEO of Cisco
Human Rights by Design
- Advise & Train Product Teams on Human Rights throughout the Product Development Lifecycle
- Where might the product be hurtful?"
Accessibility by Design
- Advise & Train Product Teams on Accessibility throughout the Product Development Lifecycle
- Can you point a screen reader and get an ability for someone to read the documentation? Can you read a webpage with a screen reader?
- Implement Cisco’s Inclusive Language Policy
- Build Employee Awareness about Inclusive Language
- Drive Compliance across Cisco’s Functions
- Engage Community and share Best Practices
- Embed a Culture of Belonging via Governance Models
- Making sure that the company has an inclusive language policy, the teams know about the policy, the policy can be implemented, and teams have the necessary tools to implement them.
- Driving compliance requires that we know what compliance means - and define the boundaries.
- Being assistive and not punitive.
- Engaging humanity, making sure teams know each other, and knowing what each team tackles.
Policy to Practice
- Goal: promote and facilitate replacing harmful and exclusionary language in tech.
- If you’re a single writer in an organization and you don’t even know where to start, visit the Inclusive Naming Initiative and take a look at the words list.
- Mitigate and make sure these words are not creeping back into your code: automated checks in CI/CD.
Look at these word lists as an API contract:
- Version-locked; users know which version to expect the change,
- Documents the dates to expect the change,
- Backwards compatibility means no breaking changes due to a word change,
- Communicates a roadmap for future word changes.
What else did the team do?
Categorization exercise - Asset categories
- Category #1: Variable names or comments that are internal to code. No impact to customers and no external visibility.
- Category #2: CLI (Actual configuration files), API or schema use. Deprecate the old use, and create a new one with a text alias. This is complex and customer-facing, new and old must work and you have to communicate it.
- Category #3: Logs, telemetry, monitoring: Support old and new (don’t break customer scripts). Deprecate the old but cutover to new.
- Category #4: Documentation changes: Simple cases are easy to do. Complex cases (like documenting a CLI) must follow product changes.
Unintended side effects you need to take care of:
- Sometimes the place where the words need to be changed is not just in the code comments but actually in a standard use - what is your plan to change that?
- It’s not just in the documentation: Docker file, interactive documentation, cascading upgrades that have to happen (e.g., Git, Python).
Product documentation: until the product changes, the product documentation can’t change that word.
New Terms and Impact on Code vs.Culture
- Goal: Centralized governance for policy and language decisions
- Which terms are critical enough to justify a company-wide change in code, and why? And how?
- US vs. Global intake process – Why wouldn’t we include global terms in our policy? Set up a framework so this could be done in non-English languages and for non-English and non-North American cultures.
- Scale – How do we meet all language needs for all roles?
What can you do to advance Inclusive Language?
- Take an inventory of your engineering assets (code, log files, telemetry data, standards).
- Take a moment to reflect on your own use of language.
- Consider what you can do in your role, and with your unique skills,
- Take a Linux Foundation training on inclusive speaking.