docs: new style guide - Inclusive Language

docs/style-guide/inclusive-language.md

@@ -0,0 +1,78 @@
+title: Inclusive Language style guide
+Description: This style guide outlines the guideline for using inclusive language in documentation.
+---
+
+# Inclusive Language
+
+While writing documentation we are directly speaking to thousands of people all around the globe. 
+Thus, we must ensure that our diverse audience can connect with our information. 
+
+## 1. Culturally inclusive language
+
+Certain phrases and words are commonly used in specific regions of the world. Avoid using region-specific language in the documentation. 
+Some examples of Region Specific Language are -
+- “It’s not rocket science” is commonly used in the USA, and non-US people might not be able to relate to it as intended.
+- Phrases written in regional languages instead of English.
+- “It’s a piece of cake” is commonly used in the USA, and non-US people might not be able to relate to it as intended.
+- Terms like "gypsy" is considered derogatory in Romani community, "eskimo" is considered offensive in artic community.
+- Terms like "tipping point" is considered offensive in African American cultures.
+
+## 2. Gender neutral language
+
+Some phrases and words target men or men/women specifically, resulting in other gender groups feeling left out while reading our documentation. Using only male pronouns also make women in technology feel excluded or overlooked.
+Similarly, we should also try to include non binary group of people with our writing.
+Some examples of Gender Neutral Language are -
+- Using “they/them” instead of “his/him” or “she/her”.
+- Using “Hello everyone” instead of “Hello guys”.
+- Using “Chairperson” instead of “Chairman” or “Chairwoman”.
+- Using "people", "guests" or "folks" instead of "ladies and gentlemen".
+- Using "Mx" or "Ms" instead of using "Mr" or "Mrs".
+- Using "humankind" instead of "mankind".
+- Avoid using sterotypes such as linking "male" with "strength", "women" with "care work", "male homosexuality" with "sensitivity".
+
+## 3. Accessibility and Disability 
+
+The placement of the word “People” matters a lot when it comes to writing documentation. 
+Using the word “People” in the beginning makes it more pleasant as the problem is not displayed in the beginning.
+The phrasing of sentences should not be in a manner that depicts Ableism or discrimination against individuals with disabilities or 
+the assumption that people with disabilities are inferior to those without disabilitie.
+
+Some examples of Gender Neutral Language are -
+- Using “People with a mental health condition” instead of “Mentally Unstable People”.
+- Using “Deaf” instead of “Person with deafness”.
+- Using "People with a disability" instead of "Disabled people".
+- Using "Wheelchair Users" instead of "Wheelchair bound".
+- Using "People experiencing homelessness" instead of "Homeless people"
+- Avoid using derogatory terms that refer to people with disabilities like "crazy", "retarded", spaz, and "lame".
+- Try using phrases like "overlook" or "ignore" instead of "turn a blind eye", or using "unheard" or "unnoticed" instead of saying "falling on deaf ears".
+
+## 4. Slang free language 
+
+While framing the documentation, we must ensure that we are not including any vulgar language even if those are included indirectly in our work. We should be mindful of inadvertently including slang words within phrases that may have unintended or inappropriate connotations.
+Some examples include -
+- Using “simple” or “easy" instead of “no-brainer”.
+- Using "simple" or "straightforward" instead of "easy-peasy".
+- Avoid using any racist, sexist, or any discriminatory language like "stupid" or "retarted".
+- Using "easy" or "simple" instead of "piece of cake".
+- Using "excellent" or "impressive" instead of "dope"
+
+## 5. Ageism free language   
+
+When constructing the documentation, avoiding words or phrases that may disproportionately emphasize a specific age group is important, making other age groups feel excluded.
+Some examples include -
+- Avoid mentioning the exact age like “60 years” old.
+- Using "experienced" instead of "old-timer"
+- Avoid phrases like "you are too old to understand" or "you are too yound to understand"
+- Using “lively” instead of “young”.
+- Avoid making assumptions about a person's abilities or interests based on their age, like assuming an older adult will not be tech savvy.
+
+## 6. Knowledge level assumption free language
+
+While building the documentation, we should always assure that we don’t presume the knowledge level of the readers. 
+This is because if we assume that our readers are highly skilled or have advanced experience, we might inadvertently skip explaining or linking some important concepts. Also, we should avoid labelling some steps as “easy”, 
+because this might make some readers question their technical abilities.
+Some examples include -
+- Using “fixing the navbar is good to start with” instead of “fixing the navbar is very easy”.
+- Linking complex topics which most of our audience won’t be able to understand.
+- Avoid using phrases like "As you already know, the Fourier series is a mathematical method used to represent periodic functions."
+- Avoid including phrases like "You're probably familiar with the concept of compound interest, so I won't go into too much detail about it."