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.
42 readers like this
42 readers like this
Global citizens unite to improve housing with open design and development

Opensource.com

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.

What to read next
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.

Comments are closed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.