Archive:Docs Project Style Guide - General Guidelines

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Gave clearer instructions on appopriate uses for emphasis and gives alternative ways to emphasis material.)
(27 intermediate revisions by 2 users not shown)
Line 11: Line 11:
 
Instructions and rules use an ''active voice'', presenting confidence to the reader without sounding demanding.  An active voice provides clear direction.  It shows the reader what to do and gives expected results.  Active voice leaves the reader with the impression an author stands behind the written work.
 
Instructions and rules use an ''active voice'', presenting confidence to the reader without sounding demanding.  An active voice provides clear direction.  It shows the reader what to do and gives expected results.  Active voice leaves the reader with the impression an author stands behind the written work.
  
{{admon/important|Avoid passive voice unless necessary|Passive voice is completely correct grammatically, but it is a barrier to reader comprehension. The passive voice flips conventional sentence structure around. It moves the verb and direct object forward to the first half of a sentence, and places the main subject in the second half of a sentence. Often a simple restructuring of the sentence makes it active. Long passive sentences frequently take multiple reads before a reader grasps full meaning. }}
+
{{admon/warning|Avoid Passive Voice Unless Necessary|Passive voice is completely correct grammatically, but it is a barrier to reader comprehension. The passive voice flips conventional sentence structure around. It moves the verb and direct object forward to the first half of a sentence, and places the main subject in the second half of a sentence. Often a simple restructuring of the sentence makes it active. Long passive sentences frequently take multiple reads before a reader grasps the full meaning. }}
  
  
Line 29: Line 29:
 
==== Accuracy and Precision ====
 
==== Accuracy and Precision ====
  
Accuracy and precision can make or break any document.  This axiom applies equally to technical and literary accuracy.  Choose words carefully and consider as many usage cases as possible.  In procedures for interface interactions, for example, "go to" is not as precise as "click," and "click" may not be accurate in all usage cases.  The term "select" is accurate in any usage case and is sufficiently precise.  By the same token, it is not necessary to cover all potential usage cases.  Covering rare side cases elongates a document beyond reason, and causes the reader to lose focus.
+
Accuracy and precision make or break any document.  This axiom applies equally to technical and literary accuracy.  Choose words after considering as many usage cases as possible.  For example, "go to" is not as precise as "click," yet "click" may not be accurate for all interface interactions.  The term "select" is accurate in any usage case and sufficiently precise.  Don't become too preoccupied in an attempt to cover all potential usage cases.  Covering rare side cases elongates a document beyond reason, and the reader loses focus.
  
 
==== Tense ====
 
==== Tense ====
  
Select an appropriate tense for the document and adhere to it.  For technical documentation, present tense is usually bestMaintain consistent and accurate tense for each statement.  Present subsequent tasks in a procedure in the same tense.
+
Tense is the time in which language takes place. There are three main tenses: past, present, and future. Select an appropriate tense for the document and adhere to it.  For technical documentation, use the present tense whenever possibleMaintaining the same tense for each statement in a document is vital for clarityKeep the same tense for all sequential tasks in a procedure.
  
 
=== Usage ===
 
=== Usage ===
Line 39: Line 39:
 
==== Contractions ====
 
==== Contractions ====
  
Avoid contractions.  They reduce the readability of a document and make it more difficult to translateThey can also be confusing to readers from other cultures, as each culture and language may use contractions differently.
+
Avoid contractions, the combination of two words with an apostrophe replacing one or more lettersContractions reduce the readability of documents and make translation more difficult.  Other cultures and languages interpret contractions differently, and this confusion conflicts with the goals of the Fedora Documentation Project.
  
 
==== Pronouns ====
 
==== Pronouns ====
 +
 +
Pronouns are words language uses to replace specific noun phrases. Good writers must strike a balance between over-repeating a noun phrase, and using pronouns to stand in for nouns. A general rule to preserve clarity is to never repeat noun substitution with a pronoun in two consecutive sentences. Readers of technical documents need constant reminders on the exact subject the author is writing about. Prevalent use of pronouns cause readers to guess the subject a sentence is referencing. These assumptions reduce the effectiveness of documentation.
  
 
Avoid most personal pronouns in documentation, including the following:
 
Avoid most personal pronouns in documentation, including the following:
  
* Subjective personal pronouns ("I," "he," "she," "we")
+
* Subjective personal pronouns ("I," "he," "she," "it," "we,")
 
* Objective personal pronouns ("me," "her," "him," "us")
 
* Objective personal pronouns ("me," "her," "him," "us")
 
* Possessive personal pronouns ("my," "her," "his," "our")
 
* Possessive personal pronouns ("my," "her," "his," "our")
Line 53: Line 55:
 
* Reflexive pronouns, such as "yourself" or "himself"
 
* Reflexive pronouns, such as "yourself" or "himself"
 
* Intensive pronouns, such as "he himself" or "(you) do it yourself"
 
* Intensive pronouns, such as "he himself" or "(you) do it yourself"
* Do not use "you", "your", and "one/one's"
+
* Resist overuse of "you", "your", and "one/one's"
  
Some situations require the use of the second person pronoun "you," and its attendant forms, for clarity.  Maintaining the active voice is a higher priority than avoiding these pronouns.  "You" and "your" are sometimes necessary to indicate action or possession on the part of the reader.
+
Occasionally situations require the second personal pronoun "you," and its attendant forms for clarity.  Maintaining an active voice is paramount over avoiding the second personal pronouns.  "You" and "your" are appropriate words to indicate action or possession on the part of the reader.  
  
Finally, avoid indefinite pronouns such as "this" or "that" without an antecedent, especially to start a sentence:
+
Indefinite pronouns such as "this" or "that" without an antecedent make it tough for a reader to follow an author's meaning. Favor writing an exact noun phrase whenever possible over the vague words "this," "these," "those," and "that."
  
 
<pre>
 
<pre>
INCORRECT:  Edit your yum configuration files to use
+
INCORRECT:  Edit your yum configuration files to use geographically close mirrors.  This allows you to
geographically close mirrors.  This allows you to
+
 
update your system faster.
 
update your system faster.
CORRECT:  For faster system updates, edit the yum
+
 
configuration files to use geographically close mirrors.
+
CORRECT:  Edit the yum configuration files to use geographically close mirrors for faster system updates.
 
</pre>
 
</pre>
  
An overlong sentence may result from joining clauses in this fashionIn such a situation, use of "this" or "that" is acceptable ''only'' if you provide a proper antecedent, such as "this procedure."
+
When eliminating indefinite pronouns, a cumbersome long sentence may result from joining too many clauses.  Use indefinite pronouns to break long sentences up to improve clarity, but always provide a proper antecedent.
 +
 
 +
<pre>
 +
INCORRECT: Stay current with recommended updates to your operating system in order to improve functionality of
 +
applications, remove security risks, and automatically resolve performance issues solved from bug reports.
 +
 
 +
CORRECT: Stay current with recommended updates to your operating system. These updates improve functionality of
 +
applications, remove security risks, and automatically resolve performance issues solved from bug reports.
 +
</pre>
  
 
==== Sentence Formation ====
 
==== Sentence Formation ====
  
Avoid using the unnecessary word "then" following an "if" statement. If a sentence begins with an "if" statement, follow it with a comma and complete the sentence with a full statement.
+
Keep sentences as short as possible. Cutting unnecessary words is vital to strengthen meaning. There are a number of common traps technical writers fall into resulting in lengthy sentences.
  
==== Capitalization ====
 
  
In sentences, capitalize the first word.  Do not start sentences with a command, package, or option name, to avoid breaking this rule.
+
''Indirect Discourse''
  
 +
Indirect discourse refers to the use of "that" to attribute a statement, fact, or feeling in a sentence without the use of quotation marks. In regular writing, it weakens statements of fact. Documentation writers can improve the impact of sentences by removing "that" and "which."
 +
 +
<pre>
 +
INCORRECT: Fedora is an open source operating system that is upstream for many other open source projects.
 +
 +
CORRECT: Fedora is an upstream open source operating system for many other open source projects.
 +
</pre>
 +
 +
 +
''Other Unnecessary Word Combinations''
 +
 +
Avoid using the unnecessary word "then" following an "if" statement.  When a sentence begins with an "if" statement, follow it with a comma and complete the sentence with a full statement.
 +
 +
<pre>
 +
INCORRECT: If an email client will not send or receive messages, then check under the File Menu and
 +
verify "Work Offline" mode is unselected.
 +
 +
CORRECT: If an email client will not send or receive messages, check under the File Menu and
 +
verify "Work Offline" mode is unselected.
 +
</pre>
 +
 +
 +
Many words we use in everyday conversation reduce impact in printed materials because they "leave a way out." These are words preceding verbs and nouns to minimize the sentence's influence. This is not an exhaustive list, but mindful documentation writers will reduce using these words and those of a similar nature.
 +
 +
{{admon/warning|Avoid Reducing Impact With Unnecessary Words| The following words minimize the impact of the verb or noun clause within a sentence. Other words also fit into this category, but this short list is aimed at helping documentation writers identify words of this nature and eliminate them from their writing:
 +
'''should, could, may, might, perhaps, some, many, most, numerous, few, somewhat, whatever, possibly, can, occasionally, and frequently.''' }}
 +
 +
 +
''Sentence Variation''
 +
 +
For the strongest impact, keep the first and last sentences of a paragraph as short as possible. Varying sentence length within a paragraph and through the entire document keeps a reader's attention. A short and simple fact is easy to grasp and use to analyze the next sentence's topic. There is nothing wrong with using longer sentences to explain complex ideas and concepts. Try to use a simple synopsis sentence at the end of each paragraph to give readers a reprieve and recap of any important information. A short final sentence stays with the reader to the next section.
 +
 +
==== Capitalization ====
 +
 +
In sentences, capitalize the first word.  Do not start sentences with a command, package, or option name.
 
<pre>
 
<pre>
 
INCORRECT: <code>smolt</code> provides hardware profiling.
 
INCORRECT: <code>smolt</code> provides hardware profiling.
Line 82: Line 125:
 
</pre>
 
</pre>
  
In headings, capitalize the first word and any other word that is not an article ("a," "an," or "the"), a short preposition ("in," "of," "for," "with," "at," "on"), or a conjunction ("and," "but," "or").  Examples:
+
In headings, always capitalize the first word regardless of the type of speech. All subsequent words are also capitalized other than articles ("a," "an," or "the"), short prepositions ("in," "of," "for," "with," "at," "on"), or conjunctions ("and," "but," "or").   
 +
 
 +
Examples:
  
 
* Avoid Using Contractions in Technical Writing
 
* Avoid Using Contractions in Technical Writing
 
* Try to Do the Right Thing
 
* Try to Do the Right Thing
 
* Find the Right Way to Say What You Mean
 
* Find the Right Way to Say What You Mean
 +
* The Grass is Always Greener on the Other Side of the Fence
  
 
==== Punctuation ====
 
==== Punctuation ====
  
Avoid the following punctuation in sentences:
+
Punctuation is a crucial component of understanding prose. A misplaced comma, period, or an improper punctuation mark changes a sentence's meaning entirely. Punctuation marks are the fasteners in a writer's toolbox. Readers are accustomed to the regular nails and screws, like commas and periods. Start throwing in lots of flashy hinges or braces like semicolons or ellipsis, and the unfamiliar notations easily distract readers. Complex punctuation marks are not universal, hindering translation efforts of Fedora Documentation.
 +
 
 +
Minimize the following punctuation marks in documentation:
 +
 
 +
* '''Parentheses or "em dashes."''' To compensate, rearrange the sentence, or break it into two complete thoughts.
 +
 
 +
* '''Semicolons''' Good to use only if two thoughts are related, must be joined for clarity, and removes the need for a conjunction.
  
* Parentheses or "em dashes," which usually indicate the writer should restructure a sentence, possibly into two or more sentences
+
* '''Colon''' If there are more than three items, use a bulleted list for easy comprehension.
  
* Semicolons, which usually indicate the writer should break a sentence in two, or use bullets or a numbered procedure in place of a sequential list
+
* '''Ellipsis''' Do not use for stylistic emphasis... only to denote an indefinite continuation of content in an example.
  
* Ellipsis, except where used to denote an indefinite continuation of the same or similar content in an example
+
* '''Exclamation points''' In technical writing this is accepted for use only as a most dire "warning" admonition, not for emphasis.
  
* Exclamation points, except in the most dire "warning" admonitions
+
* '''Ampersands''' The word "and" is to be written out, and this mark only reserved if it is part of a computer command.
  
* Ampersands, for which the writer should use the word "and"
+
* '''Slashes''' Do not use slashes for a short hand version of "he or she" by using he/she, instead use the words "and," "or," or "either." Slashes are commonly used in file paths and using them otherwise will create confusion.
  
* Slashes, as in "he/she," "s/he," and "and/or," for which the writer should find an alternate sentence construction, or use the word "or"
+
=== Other Writing Questions ===
  
=== The Unknown ===
+
Every writer hits writing obstacles. It becomes difficult to adequately phrase something, or the words just do not "sound right." This is why the Fedora Documentation Project is a team effort. Call on fellow documentation writers in the mailing list or chat room for help with wording and formatting issues. Another trick professional writers use everyday is time away from the project. Take a break away from the document. Returning to a troublesome spot with fresh eyes is often all that is needed to overcome the writing hindrance.
  
Every writer encounters issues that are difficult to solve. When such an issue arises, do research to find an adequate solution for present and future instances of the issue, or write around the issue instead.  For example, if it is unclear whether to use a comma in a sentence, rewrite the sentence differently, or split it into two sentences to avoid the issue entirely.
+
The overall goal of the Fedora Documentation Project is to provide assistance to Fedora users in easy-to-understand language. You do not have to write to impress an English professor, or show off your expertise in a subject matter. Short sentences, frequent definitions of new and unfamiliar terms, and reference links are all aids our audience appreciates most. Write with your target audience in mind, and it will be your documentation contributions with the highest visits of users in need of answers.
 +
[[Category:Docs Project process]][[Category:Documentation]]

Revision as of 02:54, 26 February 2009

DocsProject Header docTeam1.png


Contents

General Guidelines

The following sections provide guidelines for both sentence composition and syntax usage. Follow these guidelines to ensure your document's tone is consistent with that of other Fedora documentation.

Composition

Voice

Instructions and rules use an active voice, presenting confidence to the reader without sounding demanding. An active voice provides clear direction. It shows the reader what to do and gives expected results. Active voice leaves the reader with the impression an author stands behind the written work.

Warning (medium size).png
Avoid Passive Voice Unless Necessary
Passive voice is completely correct grammatically, but it is a barrier to reader comprehension. The passive voice flips conventional sentence structure around. It moves the verb and direct object forward to the first half of a sentence, and places the main subject in the second half of a sentence. Often a simple restructuring of the sentence makes it active. Long passive sentences frequently take multiple reads before a reader grasps the full meaning.


ACTIVE:  Select a strong password to improve personal security.
PASSIVE: Personal security improves by a strong password being selected.

Context

Avoid writing out of context. Adhere carefully to the subject matter of the document, chapter, section, and paragraph. Use references as appropriate, structuring documents so each new part builds upon the last. Avoid making the reader skip ahead to put current parts in context. Provide a link to related documentation if the reader may need it for clarification.

Emphasis

Emphasis is most effective when used sparingly. Use methods of emphasis such as boldface, underlining, or oblique text to draw attention to a new term. Use admonitions to set off notable material. Another acceptable way to emphasize a point is with varying sentence formation or word choice. The best documentation writers plan ahead for emphasis, applying it with careful consistency throughout the document.

Accuracy and Precision

Accuracy and precision make or break any document. This axiom applies equally to technical and literary accuracy. Choose words after considering as many usage cases as possible. For example, "go to" is not as precise as "click," yet "click" may not be accurate for all interface interactions. The term "select" is accurate in any usage case and sufficiently precise. Don't become too preoccupied in an attempt to cover all potential usage cases. Covering rare side cases elongates a document beyond reason, and the reader loses focus.

Tense

Tense is the time in which language takes place. There are three main tenses: past, present, and future. Select an appropriate tense for the document and adhere to it. For technical documentation, use the present tense whenever possible. Maintaining the same tense for each statement in a document is vital for clarity. Keep the same tense for all sequential tasks in a procedure.

Usage

Contractions

Avoid contractions, the combination of two words with an apostrophe replacing one or more letters. Contractions reduce the readability of documents and make translation more difficult. Other cultures and languages interpret contractions differently, and this confusion conflicts with the goals of the Fedora Documentation Project.

Pronouns

Pronouns are words language uses to replace specific noun phrases. Good writers must strike a balance between over-repeating a noun phrase, and using pronouns to stand in for nouns. A general rule to preserve clarity is to never repeat noun substitution with a pronoun in two consecutive sentences. Readers of technical documents need constant reminders on the exact subject the author is writing about. Prevalent use of pronouns cause readers to guess the subject a sentence is referencing. These assumptions reduce the effectiveness of documentation.

Avoid most personal pronouns in documentation, including the following:

  • Subjective personal pronouns ("I," "he," "she," "it," "we,")
  • Objective personal pronouns ("me," "her," "him," "us")
  • Possessive personal pronouns ("my," "her," "his," "our")

Also avoid:

  • Reflexive pronouns, such as "yourself" or "himself"
  • Intensive pronouns, such as "he himself" or "(you) do it yourself"
  • Resist overuse of "you", "your", and "one/one's"

Occasionally situations require the second personal pronoun "you," and its attendant forms for clarity. Maintaining an active voice is paramount over avoiding the second personal pronouns. "You" and "your" are appropriate words to indicate action or possession on the part of the reader.

Indefinite pronouns such as "this" or "that" without an antecedent make it tough for a reader to follow an author's meaning. Favor writing an exact noun phrase whenever possible over the vague words "this," "these," "those," and "that."

INCORRECT:  Edit your yum configuration files to use geographically close mirrors.  This allows you to
update your system faster.

CORRECT:  Edit the yum configuration files to use geographically close mirrors for faster system updates.

When eliminating indefinite pronouns, a cumbersome long sentence may result from joining too many clauses. Use indefinite pronouns to break long sentences up to improve clarity, but always provide a proper antecedent.

INCORRECT: Stay current with recommended updates to your operating system in order to improve functionality of 
applications, remove security risks, and automatically resolve performance issues solved from bug reports.

CORRECT: Stay current with recommended updates to your operating system. These updates improve functionality of 
applications, remove security risks, and automatically resolve performance issues solved from bug reports.

Sentence Formation

Keep sentences as short as possible. Cutting unnecessary words is vital to strengthen meaning. There are a number of common traps technical writers fall into resulting in lengthy sentences.


Indirect Discourse

Indirect discourse refers to the use of "that" to attribute a statement, fact, or feeling in a sentence without the use of quotation marks. In regular writing, it weakens statements of fact. Documentation writers can improve the impact of sentences by removing "that" and "which."

INCORRECT: Fedora is an open source operating system that is upstream for many other open source projects.

CORRECT: Fedora is an upstream open source operating system for many other open source projects.


Other Unnecessary Word Combinations

Avoid using the unnecessary word "then" following an "if" statement. When a sentence begins with an "if" statement, follow it with a comma and complete the sentence with a full statement.

INCORRECT: If an email client will not send or receive messages, then check under the File Menu and 
verify "Work Offline" mode is unselected.

CORRECT: If an email client will not send or receive messages, check under the File Menu and 
verify "Work Offline" mode is unselected.


Many words we use in everyday conversation reduce impact in printed materials because they "leave a way out." These are words preceding verbs and nouns to minimize the sentence's influence. This is not an exhaustive list, but mindful documentation writers will reduce using these words and those of a similar nature.

Warning (medium size).png
Avoid Reducing Impact With Unnecessary Words
The following words minimize the impact of the verb or noun clause within a sentence. Other words also fit into this category, but this short list is aimed at helping documentation writers identify words of this nature and eliminate them from their writing: should, could, may, might, perhaps, some, many, most, numerous, few, somewhat, whatever, possibly, can, occasionally, and frequently.


Sentence Variation

For the strongest impact, keep the first and last sentences of a paragraph as short as possible. Varying sentence length within a paragraph and through the entire document keeps a reader's attention. A short and simple fact is easy to grasp and use to analyze the next sentence's topic. There is nothing wrong with using longer sentences to explain complex ideas and concepts. Try to use a simple synopsis sentence at the end of each paragraph to give readers a reprieve and recap of any important information. A short final sentence stays with the reader to the next section.

Capitalization

In sentences, capitalize the first word. Do not start sentences with a command, package, or option name.

INCORRECT: <code>smolt</code> provides hardware profiling.
CORRECT: The <code>smolt</code> package provides hardware profiling.

In headings, always capitalize the first word regardless of the type of speech. All subsequent words are also capitalized other than articles ("a," "an," or "the"), short prepositions ("in," "of," "for," "with," "at," "on"), or conjunctions ("and," "but," "or").

Examples:

  • Avoid Using Contractions in Technical Writing
  • Try to Do the Right Thing
  • Find the Right Way to Say What You Mean
  • The Grass is Always Greener on the Other Side of the Fence

Punctuation

Punctuation is a crucial component of understanding prose. A misplaced comma, period, or an improper punctuation mark changes a sentence's meaning entirely. Punctuation marks are the fasteners in a writer's toolbox. Readers are accustomed to the regular nails and screws, like commas and periods. Start throwing in lots of flashy hinges or braces like semicolons or ellipsis, and the unfamiliar notations easily distract readers. Complex punctuation marks are not universal, hindering translation efforts of Fedora Documentation.

Minimize the following punctuation marks in documentation:

  • Parentheses or "em dashes." To compensate, rearrange the sentence, or break it into two complete thoughts.
  • Semicolons Good to use only if two thoughts are related, must be joined for clarity, and removes the need for a conjunction.
  • Colon If there are more than three items, use a bulleted list for easy comprehension.
  • Ellipsis Do not use for stylistic emphasis... only to denote an indefinite continuation of content in an example.
  • Exclamation points In technical writing this is accepted for use only as a most dire "warning" admonition, not for emphasis.
  • Ampersands The word "and" is to be written out, and this mark only reserved if it is part of a computer command.
  • Slashes Do not use slashes for a short hand version of "he or she" by using he/she, instead use the words "and," "or," or "either." Slashes are commonly used in file paths and using them otherwise will create confusion.

Other Writing Questions

Every writer hits writing obstacles. It becomes difficult to adequately phrase something, or the words just do not "sound right." This is why the Fedora Documentation Project is a team effort. Call on fellow documentation writers in the mailing list or chat room for help with wording and formatting issues. Another trick professional writers use everyday is time away from the project. Take a break away from the document. Returning to a troublesome spot with fresh eyes is often all that is needed to overcome the writing hindrance.

The overall goal of the Fedora Documentation Project is to provide assistance to Fedora users in easy-to-understand language. You do not have to write to impress an English professor, or show off your expertise in a subject matter. Short sentences, frequent definitions of new and unfamiliar terms, and reference links are all aids our audience appreciates most. Write with your target audience in mind, and it will be your documentation contributions with the highest visits of users in need of answers.