{{Header}} {{title|title= Documentation Guidelines }} {{#seo: |description=Suggestions and recommendation for best authoring practices. }} {{intro| Suggestions and recommendation for best authoring practices. }} Authors are encouraged to use a formatting and grammatical style that is consistent with existing wiki entries and templates. Please refer to the suggestions below when completing entries. Note: These suggestions are recommendations for best authoring practices and do not constitute absolute rules. {{project_name_long}} welcomes contributions from people who are willing to invest their time to help improve the wiki. Therefore, use this information as a guide only in the first instance. Wiki Formatting Style Preferred: * Use preexisting wiki templates where possible. * If editing templates, check edits suitably match existing wiki entries with the /wiki/Special:WhatLinksHere/Template:NAME command. * Reference all sources and quotes. * Do not submit copyrighted work without the necessary permission or attribution. * Use sudo rather than root instructions. * Standardize file path references in italics. For example: "Open /etc/apt/preferences.d/debian-pinning.pref in an editor.". * Standardize command line function references in italics. For example: "Run needrestart.". * Conservatively use bold text for warnings or other critical information. For example: "'''Warning:''' Do not use X in {{project_name_short}}!". * Use mediawiki chapter / sub-chapter headings (where appropriate) for long instructions or to break up large blocks of text. * Use bold text for titling where it is otherwise required. * Number steps for long wiki entries where it is appropriate. * Do not use colons in the last sentence preceding actual user steps; use a full stop / period. For example: ** "Complete the following steps.". ** Not "Complete the following steps:". * Use CodeSelect for copy and paste instructions, for example command line functions. * Use blockquote for quoting text verbatim. * Use code for highlighting special instructions, for example navigating browser menus, application settings and so on. * Use pre for other highlighted text that does not require special formatting for cut and paste purposes. * Use ref for footnoting minor issues. * Use br for necessary breaks in block-quoted or other text. * Use box for special text or instructions that need to be differentiated from the rest of the entry. * Embed internal or external links for important issues for reader consideration. For example: ** "Read and apply the [[System Hardening Checklist]].". ** "This should not be confused with [https://en.wikipedia.org/wiki/Hardware_Trojan hardware/circuit trojans].". * Use tables where possible for large wiki entries defining / discussing / comparing multiple variables, categories, features, options or other data. * Use recent screenshots if it is appropriate and feasible for the wiki entry. * Use definite, specific, concrete language and instructional steps to minimize reader confusion. * Use specific examples like sample configuration files, system messages and commands when writing instructional steps to minimize reader confusion. * Write for an audience with an expected high-school graduate education. Use https://simple.wikipedia.org as a guide for the intended audience. Grammatical Considerations Preferred: * American English. For example, American spelling and phrasing. * Spell-checked text. * Check hyphenation use is appropriate. * Avoid "e.g.", "i.e.", "etc." and other abbreviations. Instead use "For example / like ", "that is", "and so on". * Capitalize and check the accuracy of acronyms. * Do not use acronyms without first defining them. * Use double, rather than single quotation marks in general. * Avoid apostrophes or contractions in general. For example: "It is" not "It's". * Avoid the use of pronouns. For example: I, you, your, me, us, we, he, she, they, mine, ours, yourself, myself, themselves and so on. Use "the" instead. * Capitalize the first letter of words in chapter headings and titles (in general). * Capitalize the first letter of the first word in bullet points that form complete sentences. * End bullet points with a full stop / period (in general). * Capitalize the first letter of words following colons, except for sentences forming lists or expounding on an idea in the first portion of the sentence. For example: ** "Warning: Do not use the {{project_name_gateway_long}} for user activities!". ** "Multiple risks are faced by the user: deanonymization, browser fingerprinting and infection of the {{project_name_workstation_long}}.". * Capitalize proper nouns. * Avoid overuse of brackets and parentheses. Either write the text in a full sentence or footnote minor points. * Write in the active voice. * Avoid slang or common English terms. * Avoid shortening words and use the full spelling, for example "distributions" vs "distros". * Make sure all referents are clear, for example "This theory...", "That checked option...", "Those settings..." and so on. * Avoid long sentences. Break ideas into simpler, shorter sentences for clarity. * Avoid run-on sentences. For example: ** "Firefox is hardened against fingerprinting. It is patched to prevent leaking of several attributes." ** Not "Firefox is hardened against fingerprinting, it is patched to prevent leaking of several attributes." * Avoid sentence fragments. For example: ** "{{project_name_short}} helps to prevent SUID binaries.". ** Not "Prevents SUID binaries.". * Use declarative statements in preference to rhetorical statements. For example: ** "Few users are likely to set a proxy with Firefox.". ** Not "How many users are likely to set a proxy with Firefox?". * Write statements in the positive, rather than negative form. For example: ** "What is happening...". ** Not "What is not happening...". * Nouns and verbs are preferable to adjectives and adverbs. * Avoid the use of qualifiers e.g. pretty, very, rather, little and so on. * Omit needless words to improve sentence clarity. = See Also = * [[Dev/Documentation Markup Format Converters]] = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Development]] [[Category:Design]]