A presentation given by Adrienne Moherek, Developer Experience Technical Leader, Cisco, at our 2024 Austin API Summit, March 12-13.
Session Description: Heard of suss? You can suss out more information or you can find someone’s information to be suss. “Suss” shows the flexibility of language. It’s an ongoing process to change how we use certain words. It’s important to choose words carefully to convey the correct meaning and avoid harmful subtext or exclusion. Let’s explore some of the tools and triage methods that it takes from an engineering viewpoint to make bias-free choices. How can you ensure that biased words do not sneak into code, UI, docs, configurations, or our everyday language? First, let’s walk through how to take an inventory of assets from code to config files to API specifications to standards. Next, by placing those findings into categories, prioritize the work to substitute with inclusive alternatives. Let’s examine some examples using both API and code assets. Next is a demonstration of how to automate analyzing your source code or documentation with a linter, looking for patterns based on rules that are fed into the tool. What’s in the future for these efforts? Inclusive language should expand beyond English and North America efforts. To do so, let’s organize the work with automation tooling, as engineers do.
Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...
Inclusive, Accessible Tech: Bias-Free Language in Code and Configurations - Adrienne Moherek, Cisco
1. Adrienne Moherek, Developer Experience Technical Leader, Cisco
Austin API Summit
March 13, 2024
Bias-Free Language in Code and Configurations
Inclusive, Accessible Tech:
9. Human Rights
Impacts in our operations and
supply chain
Accessibility
Advise & Train Product Teams on
Accessibility throughout the Product
Development Lifecycle
Inclusive Language
• 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
12. Integrate human rights and inclusion across our
business
10. Inclusivity encompasses multiple aspects
• Gender neutrality including pronouns, non-binary typing
• Respectful language without drawing upon stereotypes
• People first, humans are humans not abilities or diagnoses
• Inclusive representation and avoiding idioms
• Accessibility including screen reader experiences
20. Category #1
Variable names
or comments that
are internal to
code. No impact
to customers and
no external
visibility.
Asset Categories
Category #2
CLI (config, show),
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.
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.
Code and Configuration Examples