blog: Towards More Inclusive Infrastructure #47
Conversation
|
Thank you @xmulligan, fixes incorporated and added intro sentence. |
|
please stand by for a version that is less corporate-y |
|
Since the hanging image is now gone, would it make sense to move
|
justaugustus
changed the title
There was a problem hiding this comment.
Thank you so much for this contribution, @rquelle! I've left you some comments and suggestions!
|
|
||
| My team builds platform services that underlie the multiple projects within the Emerging Technology and Incubation team. 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. |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
Questions:
- What more inclusive names did you use in this case?
- Who decided what was more "inclusive"?
There was a problem hiding this comment.
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.
| --- | ||
| Posted by Reinhardt Quelle, Dir. Site Reliability Engineering for Cisco Emerging Technolgies and Incubation | ||
|
|
||
| This post will be short, because it really is _that simple_. |
There was a problem hiding this comment.
| 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.
There was a problem hiding this comment.
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.
|
|
||
| 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: |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
Could you provide a list of the projects your team found?
There was a problem hiding this comment.
They are in the links below; I was trying to keep the text concise.
|
|
||
| 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. |
There was a problem hiding this comment.
Can you provide examples as to what kind of resistance you faced?
There was a problem hiding this comment.
@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"
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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!
|
@celestehorgan, thanks for the edits. I incorporated many of them, but left the "simple" and related as I really wanted to emphasize that it really is straightforward to take that first step. Different folks will be at different levels of maturity, to be sure, but hopefully this will inspire folks to use the tools they already use to make progress. |
@edwarnicke