Writing inclusively
Lucidworks documentation is written with a diverse global audience in mind. Lucidworks' customers have a diverse set of needs and come from all walks of life.
Guidelines for writing inclusively are well-documented in the Google Developer Documentation Style Guide. This style guide does not attempt to reproduce their efforts, which you can consult. Instead, this page documents common topics that occur regularly in writing documentation for Lucidworks products.
General guidance
Avoid gendered language. When referring to one person in the third person, use they instead of he or she.
Avoid violent language and figurative language that can be interpreted as violent, such as hang or hit.
The Google Developer Documentation Style Guide’s word list features a full list of words to avoid and what to use instead. The following table shows a sample of the words most likely to occur in the Lucidworks documentation.
| Term to avoid | Term to use |
|---|---|
blacklist |
blocklist |
dummy variable |
placeholder |
hit |
press or click |
master |
main or primary |
whitelist |
allowlist |
Occasionally using a non-inclusive term is unavoidable. This can happen if the term is an established industry term or if the term is contained in a code sample or keyword. An example from the Lucidworks documentation is the use of the spark-master service in Spark job drivers.
If the term is an established industry term and replacing it would cause confusion, use the non-inclusive term in parentheses on the first use. If you need to use the term again in the article, use the inclusive term.
If the term is an established keyword, such as the spark-master service in Fusion, use code format for the non-inclusive term and parentheses when possible.