Ansible emphasizes inclusive language in new release | Opensource.com

Ansible emphasizes inclusive language in new release

The project is working to eliminate racism and other harmful prejudices from the project's code and community.

Two diverse hands holding a globe
Image by : 
Opensource.com
x

Subscribe now

Get the highlights in your inbox every week.

During this development cycle, the Ansible project has made significant progress in its goals to make the community and code more welcoming and inclusive. With the release of Ansible Core 2.11, harmful terminology in the Ansible codebase is deprecated and it comes with new replacement terms. These changes will follow our standard deprecation cycle to give users time to adapt.

Why this? Why now?

Summer 2020 was a watershed moment in world culture that placed a very stark spotlight on inequities around the world, lingering societal remnants of the past, and present effects of racism and other harmful prejudices. Ansible recognizes that racism comes in many forms and that some of the most prevalent and insidious forms are found in how our history intersects with everyday language.

In the spirit of harm reduction, and in keeping with a saying we have: "Be kind, Be open, Be accountable, Be Ansible," a coalition within the Ansible community reviewed the Ansible codebase and documentation and made alternative terminology recommendations across the board. This effort will continue to be introspective and sensitive to the effects of language and terminology on our community and the broader world.

What changes were made?

Master branches are now "main"

Over the summer, we updated the branch naming for the collections maintained by Ansible. Going forward, "main" will be the default branch for all repositories in the Ansible and Ansible collections GitHub organizations.

Deprecated terminology

We reviewed the Ansible Core codebase for harmful language and made changes where we found these terms in the code and the documentation. Harmful language will remain available via aliases for a full deprecation cycle (four releases) to ensure users have an opportunity to update their Ansible configurations and usage. These changes include:

Deprecated term New term available in Ansible Core 2.11
whitelist (e.g., callback_whitelist, DEFAULT_CALLBACK_WHITELIST) enabled (e.g., callback_enabled, CALLBACKS_ENABLED)
blacklist (e.g., BLACKLIST_EXTS, BLACKLIST_DIRS) reject (e.g., REJECT_EXTS, REJECTLIST_DIRS)
master machine / node controller machine / node

When

These changes will be included in the Ansible 4.0 package, which will be released on May 18th, 2021.

How to get involved

The Ansible community maintains a large number of repositories and codebases. We do not believe our work is complete, and the effort to eradicate harmful language from the project will continue. Red Hat is proud to be a participating organization in the Inclusive Naming Initiative. The Ansible project looks forward to continuing to work with the community to make Ansible the most welcoming and inclusive space it can be.

We invite members of the Ansible community to join in this effort by connecting with our Diversity and Inclusion working group.

plastic game pieces on a board

Learn how developers can support assistive technology projects and inclusivity.
Two diverse hands holding a globe

Drupal's Diversity & Inclusion Group is taking an innovative approach to bringing attention to underrepresented groups in open source.
Diversity team meeting

From Kubernetes to Linux, women share their expertise in tech.

About the author

Jill Rouleau - Jill is a Principal Software Engineer at Red Hat and a member of the Ansible Steering Commitee. Previously a sysadmin for almost 15 years, they now work to make sysadmins' everyday lives easier by day and bakes amazing pastry at night.