1# Language style 2 3Following our [Code of Conduct](code_of_conduct.md) the project aims to 4be a space where people are considerate in natural language communication: 5 6There are terms in computing that were probably considered benign when 7introduced but are uncomfortable to some. The project aims to de-emphasize 8such terms in favor of alternatives that are at least as expressive - 9but often manage to be even more descriptive. 10 11## Political Correctness 12 13A common thread in discussions was that the project merely follows some 14fad, or that this is a "political correctness" measure, designed to please 15one particular "team". While the project doesn't exist in a vacuum and 16so there are outside influences on project members, the proposal wasn't 17made with the purpose of demonstrating allegiance to any given cause - 18except one: 19 20There are people who feel uncomfortable with some terms being used, 21_especially_ when that use takes them out of their grave context 22(e.g. slave when discussing slavery) and applies them to a rather benign 23topic (e.g. coordination of multiple technical systems), taking away 24the gravity of the term. 25 26That gets especially jarring when people aren't exposed to such terms 27in abstract sociological discussions but when they stand for real issues 28they encountered. 29 30When having to choose between using a well-established term that 31affects people negatively who could otherwise contribute more happily 32and undisturbed or an alternative just-as-good term that doesn't, the 33decision should be simple. 34 35## Token gesture 36 37The other major point of contention is that such decisions are a token 38gesture that doesn't change anything. It's true: No slave is freed 39because coreboot rejects the use of the word. 40 41coreboot is ambitious enough as-is, in that the project offers 42an alternative approach to firmware, sometimes against the vested 43interests (and deep pockets) of the leaders of a multi-billion dollar 44industry. Changing the preferred vocabulary isn't another attempt at 45changing the world, it's one thing we do to try to make coreboot (and 46coreboot only) a comfortable environment for everybody. 47 48## For everybody 49 50For everybody, but with a qualifier: We have certain community etiquette, 51and we define some behavior we don't accept in our community, both 52detailed in the Code of Conduct. 53 54Other than that, we're trying to accommodate people: The CoC lays out 55that language should be interpreted as friendly by default, and to be 56graceful in light of accidents. This also applies to the use of terms 57that the project tries to avoid: The consequence of the use of such 58terms (unless obviously employed to provoke a reaction - in that case, 59please contact the arbitration team as outlined in the Code of Conduct) 60should be a friendly reminder. The project is slow to sanction and that 61won't change just because the wrong kind of words is used. 62 63## Interfacing with the world 64 65The project doesn't exist in a vacuum, and that also applies to the choice 66of words made by other initiatives in low-level technology. When JEDEC 67calls the participants of a SPI transaction "master" and "slave", there's 68little we can do about that. We _could_ decide to use different terms, 69but that wouldn't make things easier but harder, because such a deliberate 70departure means that the original terms (and their original use) gain 71lots of visibility every time (so there's no practical advantage) while 72adding confusion, and therefore even more attention, to that situation. 73 74Sometimes there are abbreviations that can be used as substitutes, 75and in that case the recommendation is to do that. 76 77As terms that we found to be best avoided are replaced in such 78initiatives, we can follow up. Members of the community with leverage 79in such organizations are encouraged to raise the concern there. 80 81## Dealing with uses 82 83There are existing uses in our documentation and code. When we decide to 84retire a term that doesn't mean that everybody is supposed to stop doing 85whatever they're doing and spend their time on purging terms. Instead, 86ongoing development should look for alternatives (and so this could come 87up in review). 88 89People can go through existing code and docs and sort out older instances, 90and while that's encouraged it's no "stop the world" event. Changes 91in flight in review may still be merged with such terms intact, but if 92there's more work required for other reasons, we'd encourage moving away 93from such terms. 94 95This document has a section on retired terms, presenting the rationale 96as well as alternative terms that could be used instead. The main goal is 97to be expressive: There's no point in just picking any alternative term, 98choose something that explains the purpose well. 99 100As mentioned, missteps will happen. Point them out, but assume no ill 101intent for as long as you can manage. 102 103## Discussing words to remove from active use 104 105There ought to be some process when terminology is brought up as a 106negative to avoid. Do not to tell people that "they're feeling wrong" 107when they have a negative reaction to certain terms, but also try to 108avoid being offended for the sake of others. 109 110When bringing up a term, on the project's mailing list or, if you don't 111feel safe doing that, by contacting the arbitration team, explain what's 112wrong with the term and offer alternatives for uses within coreboot. 113 114With a term under discussion, see if there's particular value for us to 115continue using the term (maybe in limited situations, like continuing 116to use "slave" in SPI related code). 117 118Once the arbitration team considers the topic discussed completely and 119found a consensus, it will present a decision in a leadership meeting. It 120should explain why a term should or should not be used and in the latter 121case offer alternatives. These decisions shall then be added to this 122document. 123 124## Retired terminology 125 126### slave 127 128Replacing this term for something else had the highest approval rating 129in early discussions, so it seems pretty universally considered a bad 130choice and therefore should be avoided where possible. 131 132An exception is made where it's a term used in current standards and data 133sheets: Trying to "hide" the term in such cases only puts a spotlight 134on it every time code and data sheet are compared. 135 136Alternatives: subordinate, secondary, follower 137