Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

blog: Towards More Inclusive Infrastructure #47

Merged
merged 9 commits into from
Apr 20, 2021
51 changes: 51 additions & 0 deletions content/blog/_posts/inclusive-infra.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
---
title: "Towards More Inclusive Infrastructure"
date: 2021-04-14
slug: inclusive-infra
author: Reinhardt Quelle
---

This post will be short, because it really is _that simple_.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This post will be short, because it really is _that simple_.

I get what you're trying to drive at by putting this line front and center, but "simple" is actually a pretty loaded term – what's simple for me might be complex and difficult for someone else to undertake.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We had a fair bit of discussion on this, and the emphasis was intentional. Inclusion is complex. Infrastructure management is complex. Conversations are difficult. But, given the complicated things we already undertake - IaaS, linting, common pipelines, and so on, making incremental progress is not just possible, but... simple.

Later, I note "there is much left to do", and there is, but the first step, as outlined below, is straightforward when we leverage the tools we have.


My team at Cisco builds platform services that underlie the multiple projects within the Emerging Technology and Incubation group.  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 in chat 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Recently, one of my peers pinged me in chat 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.
Recently, one of my peers 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cisco version (on our blog site) lists specific tool (teams). Leaving as it is accurate and specific to the casual, immediate nature of the query.



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 our company [policy](https://www.cisco.com/c/en/us/about/social-justice/inclusive-language-policy.html) 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Since these hosts had been created using an infrastructure as code approach, all they had to do was send me a pull request to the repo containing that code with more inclusive - and indeed more descriptive - names, and re-deploy.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Questions:

  1. What more inclusive names did you use in this case?
  2. Who decided what was more "inclusive"?

Copy link
Contributor Author

@rquelle rquelle Apr 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving as is, as specifics of the pull request are less relevant. Early draft had more details (including a nerdy sed 's/slave/node' build-hosts.tf ), but my earlier editors thought it detracted from the "keep it simple" and the tools (and in fact new terms) were very environment-specific and not necessary.


But, since we are site reliability engineers, we are conditioned to ask "how could we prevent this from happening again?" Policy is fine, but we like to fix things in code. We enforce computer language standards and security policies via linters in our pipelines, so why not inclusive language?

Again, it really is this simple. To make our platform more inclusive:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Again, it really is this simple. To make our platform more inclusive:
So, we decided to use that approach 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you provide a list of the projects your team found?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are in the links below; I was trying to keep the text concise.


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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you provide examples as to what kind of resistance you faced?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Nytelife26 given our discussion on #45 I thought you might be interested in "it turns out that our linter is very US-centric and is missing language that is problematic to our international community"

Copy link
Contributor Author

@rquelle rquelle Apr 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't want to go into specific details, as it could come across as public shaming, but included

  • "why bother, its so deeply ingrained there is no point"
  • "what, are we everyone's nanny?"
  • "we're too busy, we should be focussing on other things"
  • "your choice to use tool X was dumb, you should have used Y"
  • after replacing X with Y... "your choice to use tool Y was dumb, you should have used X"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@edwarnicke Exactly correct. English, specifically the United States variant, is considered the world's lingua franca, and as such is the target of many programs. I experienced that myself when trying to find writing plugins for NeoVim.

As such, the primary concern of my focus on the inclusive terminology initiatives is that replacement terms should be translatable and accessible to those of other linguistic backgrounds.

@rquelle, what linter did you use? As part of my case I can raise issues and pull requests with them to get the international community closer to a point of consideration when replacing these terms.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have experimented with inclusive-lint (which was the one with US English focus). We are now experimenting with woke. I didn't think it appropriate to 'endorse' a particular one, yet.

Besides the relatively straightforward exercise of expanding dictionaries, I expect we'll have to work on context over time, which is of course more challenging.

Amusing aside... we added the linter as a default step in builds, which adversely impacted the publishing of our own blog. "slaves 10-15" in our Hugo blog publishing, was expected, but the linters are not particularly efficient at crawling through the entire text of a web site!


Yes, there is more to be done – working with upstream projects, expanding to the other groups in our company, reporting back to our Office of Inclusive Futures, improving tools, and the list goes on. But, the most important thing is to 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".

This was cross-posted from our [Cisco Tech Blog](https://ciscotechblog.com/blog/inclusive-infrastructure/). We are excited to be a part of the [Inclusive Naming Initiative](https://inclusivenaming.org) and we are looking forward to working with this community. Through the INI and the open source community at large, we believe we can illuminate and amplify the efforts happening across our whole industry.


Reinhardt Quelle
Director, Site Reliability Engineering, Cisco Emerging Technolgies and Incubation

---

Tools:

* [woke](https://github.com/get-woke/woke)
* [inclusivelint-lib](https://github.com/inclusivelint/inclusivelint-lib)

References:

* [Inclusive Naming Initiative](https://inclusivenaming.org)
* [Linux Kernel inclusive-terminology merge tag](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb)
* [Cisco Social Justice Beliefs and Actions ](https://www.cisco.com/c/en/us/about/social-justice.html)

rquelle marked this conversation as resolved.
Show resolved Hide resolved