Skip to content

Commit db9e5cb

Browse files
sjrddarjutak
authored andcommitted
Add the Inclusive Language Guide.
1 parent 7d55a21 commit db9e5cb

File tree

3 files changed

+143
-0
lines changed

3 files changed

+143
-0
lines changed

conduct.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -124,3 +124,7 @@ Adapted from and/or inspired by multiple successful Codes of Conduct, including:
124124
### License
125125

126126
This Code of Conduct is distributed under a [Creative Commons Attribution-ShareAlike license](https://creativecommons.org/licenses/by-sa/3.0/).
127+
128+
### See also
129+
130+
* Our [inclusive language guide](../contribute/inclusive-language/)
Lines changed: 132 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,132 @@
1+
---
2+
title: Inclusive Language Guide
3+
layout: inner-page-no-masthead
4+
includeTOC: true
5+
permalink: /contribute/inclusive-language/
6+
---
7+
8+
We are committed to providing a friendly, safe and welcoming environment for
9+
all, regardless of age, body size, disability, ethnicity, sex characteristics,
10+
gender identity and expression, level of experience, education, socio-economic
11+
status, nationality, personal appearance, race, religion, sexual identity
12+
and orientation, or other such characteristics.
13+
14+
Language is a powerful vehicle of ideas and representations, and as such, can highlight, accentuate, or blur certain characteristics of the world.
15+
Language -- in its use and structure -- may bias our perception of the world, sometimes to the disadvantage of some people.
16+
Different language strategies have therefore been suggested to promote more inclusive forms of language, echoing the need for more equal treatment for all.
17+
18+
This inclusive language guide is therefore intended to help us adopt a more inclusive way of communicating.
19+
Although the present guide does not exhaustively cover all issues pertaining to non-inclusive language, it covers the most important issues we are currently aware of.
20+
21+
Contributions made to the core Scala projects and their documentation -- including to this website -- should follow this guide.
22+
23+
## Non gendered language
24+
25+
The use of *He*, *Him*, *His*, *Man* and *Men* should be avoided.
26+
Although these terms are intended to refer to any genders (male, female, other, unknown or irrelevant), they imply that the subject is male and therefore excludes all other genders.
27+
Instead, use the singular *they*, as already used by famous authors like Jane Austen.
28+
29+
Example of the use of singular they:
30+
31+
> When a developer wants to contribute to a project, they open a pull request.
32+
33+
Although *they* refers to a single person, we conjugate the verb with the plural form.
34+
This is similar to the polite form of pronouns in certain languages, such as "Sie" in German or "vous" in French.
35+
36+
When possible, avoid (combined) words that refer to a specific gender, and use gender-neutral alternatives instead.
37+
For example:
38+
39+
* *man* or *woman* -> *person*
40+
* *chairman* -> *chairperson*
41+
42+
## The words easy, simple, quick, and trivial
43+
44+
What might be easy for you might not be easy for others.
45+
The same applies to other words like *quick* or *simple*.
46+
When used in the positive or superlative forms, try eliminating this word from sentences because usually the same meaning can be conveyed without it.
47+
48+
Example of a positive form:
49+
50+
> You can then simply execute the program with the `run` command.
51+
52+
can be replaced with
53+
54+
> You can then execute the program with the `run` command.
55+
56+
without changing the meaning of the sentence.
57+
58+
Example of a superlative form:
59+
60+
> The foobar method is the easiest way to get started with our library.
61+
62+
can be replaced with
63+
64+
> We show here how to use the foobar method to get started with our library.
65+
66+
However, the comparative form of these adjectives and adverbs can be used when relevant.
67+
68+
Example of a comparative form:
69+
70+
> The foobar method is quicker to get started with than the baz method.
71+
72+
Similarly, the word *just* is usually redundant and can be removed without altering the meaning.
73+
74+
Example:
75+
76+
> You can just add these settings to your build.
77+
78+
can be replaced with
79+
80+
> You can add these settings to your build.
81+
82+
Of course, every situation is different, and there may be cases where using "the easy words" is still the best thing to do.
83+
In that case, it should be a deliberate decision to use them, taking the above considerations into account.
84+
85+
## Specific loaded words
86+
87+
Some words may have a derogatory connotation and/or have clear oppressive origins.
88+
Avoid these words to the greatest extent possible, and use neutral alternatives instead.
89+
Currently, the following words, used for common computer science concepts, are discouraged.
90+
This list is neither comprehensive nor definitive, and it can evolve over time.
91+
92+
* **blacklist/whitelist** \
93+
While the etymology of these words has no relation to racism, their use suggests an association between the color black and some form of badness or exclusion, and between the color white and some form of goodness or inclusion.
94+
Prefer alternatives when possible.
95+
Several alternatives have been proposed but none sticks as "the one". We suggest using the pair *excludelist*/*includelist*, as it is generic enough to replace all uses of *blacklist*/*whitelist*.
96+
* **master/slave** \
97+
Never use *slave*.
98+
Never use *master* in conjunction with *slave*.
99+
Depending on the specific architecture, use one of the following alternatives instead: *controller*/*worker*, *primary*/*secondary*, *leader*/*follower*, etc.
100+
When in doubt, if you cannot choose, *primary*/*secondary* is always a decent fallback. \
101+
When used with the meaning of *teacher*, *expert*, *guide*, or *reference*, the word *master* is not specifically discouraged.
102+
For example, the term *Master of the arts* is acceptable. \
103+
Note: there exists a broader movement of using `main` instead of `master` as the default git branch, led by GitHub and the git project themselves, and which we encourage people to follow as well.
104+
* **sanity check** \
105+
Prefer *confidence check*.
106+
* **segregated** \
107+
Computer science concepts like the *interface segregation principle* and *segregated networks* present segregation as being desirable, instead of bad.
108+
Prefer alternatives like *separation of concerns* and *segmented networks*.
109+
* **guru** \
110+
While a *guru* initially refers to a respected spiritual leader, it also designates the chief of a sect.
111+
Both are of a spiritual nature and are ambiguous.
112+
If possible, use a more precise term such as *teacher* or *expert*.
113+
114+
A good source with explainers and references can be found at [https://github.com/dialpad/inclusive-language](https://github.com/dialpad/inclusive-language).
115+
116+
Keep in mind that your particular application domain may contain its own share of domain-specific loaded words.
117+
We encourage you to research inclusive language guidelines applicable to your domain.
118+
119+
You may want to use automated software like [In Solidarity](https://github.com/apps/in-solidarity) to steer contributors away from loaded words.
120+
121+
## Backward compatibility
122+
123+
Sometimes, we have existing code, APIs or commands that do not follow the above recommendations.
124+
It is generally advisable to perform renamings to address the issue, but that should not be done to the detriment of backward compatibility (in particular, backward binary compatibility of libraries).
125+
Deprecated aliases should be retained when possible.
126+
127+
Sometimes, it is not possible to preserve backward compatibility through renaming; for example for methods intended to be overridden by user-defined subclasses.
128+
In those cases, we recommend to keep the old names, but document (e.g., in Scaladoc comments) that they are named as they are for historical reasons and to preserve compatibility, and what their intended name should be.
129+
130+
## See also
131+
132+
* Our [code of conduct](../../conduct/).

contribute/index.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -27,6 +27,13 @@ Coordination of contribution efforts takes place on
2727

2828
{% include column-list-of-items.html collection=site.contribute_resources %}
2929

30+
### Guidelines
31+
32+
When contributing, please follow:
33+
34+
* The [Scala Code of Conduct](../conduct/)
35+
* The [Inclusive Language Guide](./inclusive-language/)
36+
3037
### Community Tickets
3138

3239
All issues can be found in the [Scala bug tracker](https://github.com/scala/bug). Most issues are labeled

0 commit comments

Comments
 (0)