Linux Kernel Preparing New Guidelines For Using Inclusive Terminology
Prominent upstream Linux kernel developers are working on adding "inclusive terminology" guidelines to the Linux kernel coding style requirements.
The new inclusive terminology documentation applies to new code being contributed to the Linux kernel but ultimately in hopes of replacing existing code with words deemed not inclusive. The exception being granted though is where changing the terminology could potentially break the user-space ABI given the kernel's longstanding guarantees on not breaking that interface.
These new guidelines for Linux kernel developers call for initially avoiding words including "slave" and "blacklist" to instead use words like subordinate, replica, follower, performer, blocklist, or denylist.
These changes are being worked on as for the Linux kernel coding style in that non-inclusive terminology is said to be a distracting effect.
The inclusive terminology documentation being currently discussed can be found via this kernel mailing list thread.
The new inclusive terminology documentation applies to new code being contributed to the Linux kernel but ultimately in hopes of replacing existing code with words deemed not inclusive. The exception being granted though is where changing the terminology could potentially break the user-space ABI given the kernel's longstanding guarantees on not breaking that interface.
These new guidelines for Linux kernel developers call for initially avoiding words including "slave" and "blacklist" to instead use words like subordinate, replica, follower, performer, blocklist, or denylist.
These changes are being worked on as for the Linux kernel coding style in that non-inclusive terminology is said to be a distracting effect.
The inclusive terminology documentation being currently discussed can be found via this kernel mailing list thread.
205 Comments