Contributed by Alex Earl
Back in 2016, the Jenkins project realized that some changes needed to be made. The terms “master” and “slave” were, even then, determined to be out of line with what Jenkins wanted to be as a project. A big effort was put in place to rectify the usage of the term “slave” as a first step in moving the terminology forward.
Throughout these past four years, several members of the Jenkins community have been heavily involved in removing the term “slave” from user interfaces, documentation, blog posts, and other areas. There is still work to do, but we have come a long way on that front. As we are looking at ways to make changes to code, since the code is available easily on GitHub, we also wanted to start looking at moving away from some of the other terms that are not in line with where we want to be. Terms such as “master”, “blacklist” and “whitelist” are terms which we are tackling next.
For the terms “whitelist” and “blacklist” we are following what others in the software industry are doing and going with “allowlist” and “denylist”. This will not be a direct search and replace, as context in some cases matter. Instead of replacing “allowlist” or “denylist” in certain circumstances, we may replace it with an actual text description that is longer to give users more information. We are planning on starting an epic in Jira to track these changes and will be reporting to the community as we make updates.
The term “master” in and of itself can be used in many ways. A master carpenter is one who has put in long hours of work to get to the level that they can do many things, understand problems and put into action plans to craft the object they want to craft. If the usage of “master” had been in this sort of context, there probably wouldn’t be a push to change the term. However, the term “master” was used in Jenkins along with the term “slave,” so the connotation is different and thus the desire of the project to make the change. This also gives us an opportunity to clarify various aspects of Jenkins as we make these changes to reduce confusion on what is the function or functions of these pieces of a Jenkins installation. Again, similar to “whitelist/blacklist” changes, we plan to create an epic in Jira to track the necessary changes.
We’ve solicited feedback from the community for ideas on what we replace the term “master” with because we want it to be something that makes sense in different languages and with what we are trying to describe. We had an online poll at Condorcet to get input from the community on specific terms that have been deemed viable for replacements. The poll was used in a recent Jenkins Governance Board meeting as the basis for a vote on the final term to use. The winner, both in the poll and in the Governance Board meeting vote, was the term “controller.” The work has already started to create issues in Jira to track modifications for the term. In fact, the Jenkins Security team modified a very large portion of their advisories to use the new term within a few days of the decision. More work on the blog posts, normal jenkins.io content and so forth will be coming soon!
One of the things that I have been asked a few times is, “will this actually make things better?” Will changing a few words in an open-source project actually make a difference. I think that it will make some difference, but what’s most important is for people to stand up and work to destroy racism in the world. The difference these terms can make is how comfortable a developer feels in being part of the Jenkins community. I have lived a privileged life. I am a white, cis, male. I don’t fully and completely understand things that people of different races, sex, religions, etc. feel. I do know that if these small changes can make someone feel more comfortable, or more included in the Jenkins community, then it is well worth the effort. Let me state that a different way, even if just ONE person feels more comfortable or more accepted in our community then any effort we can make is well worth it.
There are challenges with this effort going forward. We have classes in the code of Jenkins and it’s plugins that include some of these terms. This will take a significant amount of effort so that we can maintain backward compatibility and not break users, but it is something that we will do.
We are always looking for people to help with these efforts. Members of the community can help by creating issues in Jira with information about where these terms occur, filing pull requests to fix them, and participating in the conversation about how we can make Jenkins a more inclusive community. Jenkins is driven by the community, with contributions from many people around the world. We have a community of dedicated people and we welcome anyone who would like to contribute.
