Towards More Inclusive Infrastructure

This post will be short, because it really is that simple. My team builds platform services that underlie the multiple projects within the Emerging Technology and Incubation team at Cisco.  Our mission is to build 'paved roads' for developers; we create common reusable patterns and services that any engineer or venture needs to deliver an application. Recently, one of my peers pinged me via WebEx Teams and pointed out that someone on my team had just announced the expansion of our CI build environment with the addition of "slaves 10-15". She inquired about the use of the term “slave” and I immediately knew she was pointing to a form of microaggression in code and something not in line with our values. She is right.  It's not only inappropriate to perpetuate the use of terms that are harmful to our diverse employees, it's also specifically against Cisco Policy to do so: Since these hosts had been created via "infrastructure as code", it was a simple matter to send a pull request to the repo containing that code with more inclusive - and indeed more descriptive - names, and re-deploy. But, since we are an SRE team, we are conditioned to ask "how could we prevent this from happening again?" Policy is fine as far as it goes, but we like to fix things in code. We enforce computer language standards and security policies via "linters" in our pipelines, so why not insensitive language? Again, it really is this simple. To make our platform more inclusive:

rules + audit = change + progress

Indeed, a quick web search turns up not just one, but several open source projects. I posted a request to my team that afternoon, and when I got back into the office in the morning I found one of my platform engineers had already done a quick survey of the available tools and added a stage to our common build pipeline. More "X-as-code" for the win. We didn't have to modify hundreds of builds, but simply updated our common pipeline code which is already in place to do security, licensing, and other types of scans. This is where things became even more interesting. When announcing the change to let all of our engineering teams (SRE and product) know that they would be seeing warnings from the inclusive linter in their build outputs, we were immediately met with resistance. That then prompted a very healthy discussion around the "why" and the underlying context. What was even more interesting was the response from the global team - it turns out that our linter is very US-centric and is missing language that is problematic to our international community. Yes, there is more to be done – working with upstream projects, expanding to the wider Cisco community, reporting back to our Office of Inclusive Futures, improving tools, and the list goes on. But, the most important thing is just take the first step. This has been an incredibly rewarding experience; in one simple exercise, we have seen the power of infrastructure as code, the open source community, and robust collaboration technology that "powers an inclusive future for all". Tools:

• Woke
• inclusivelint-lib

References:

• InclusiveNaming.org
• Linux Kernel inclusive-terminology
• Cisco Social Justice Beliefs and Actions