The IETF has a good write-up on potentially oppressive language that is widely used in technical contexts: https://tools.ietf.org/id/draft-knodel-terminology-00.html. The two specific areas that are addressed in that document are “master/slave” and “whitelist/blacklist”. We have some limited uses of the term “whitelist”, which is worth revisiting, but I think the biggest one for FDB is the term “master”, which is used widely due to the presence of the master role. Changing the master role would be a large undertaking, but I think it’s worth considering.
I think it’s worth considering a new name for the master role for a couple of different reasons. On reason is that, though the master role is not being used in a master/slave context explicitly, it does bring with it that connotation, which could be offputting to some in our community. A second reason is that the term “master” doesn’t seem to clearly define the tasks associated with this process. From informal discussions I’ve had in the past, it seems like the name made more sense when the master process had more of an active role in controlling other process, but has become anachronistic as FoundationDB’s architecture has changed over the years. It could be good to take an opportunity to consider alternative names that would communicate the role’s intent more clearly to people using and developing FoundationDB.
Another use of the term, which the IETF document does not directly address, is the use of “master” as the default branch name. I know that that usage has a different context, though I don’t fully understand the etymology. It’s still worth considering whether the “master branch” is the best name, given how it can be tied into connotations that we don’t want. I’m partial to “main” as an alternative name, since it is equally clear or even clearer, and also shorter. I recommended this for our Kubernetes operator repo: https://github.com/FoundationDB/fdb-kubernetes-operator/issues/253. I think it’s worth considering for our other repos as well.
I’d love to get everyone’s feedback on whether these are worthwhile changes, and if there’s other terminology that we can improve on in our codebase.