Inclusive, Accessible Tech: Bias-Free Language In Code And Configurations

The presentation discusses the importance of removing problematic language from code and documentation in order to promote inclusivity and avoid potential legal issues. It provides examples of how to categorize and prioritize the work of removing problematic language, as well as tools and strategies for doing so.

• Problematic language in code and documentation can create legal and ethical issues and exclude certain groups of people
• Categorizing and prioritizing the work of removing problematic language can help teams plan and execute the work more effectively
• Tools such as VS Code extensions and automation checks can help identify and eliminate problematic language
• Product documentation can work ahead of product development in some cases
• Compliance with language policies should be defined clearly and consistently across products and teams

The presenter gives an example of finding the term 'slave' in a Yang model and having to work with the standards body to remove it. They also discuss upgrading a training course to use 'main' instead of 'master' in order to promote more modern Git practices.

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 American-centered efforts. To do so, let's organize the work with automation tooling, as engineers do.