Upload templates

internal_resources/template_concept.adoc

@@ -0,0 +1,17 @@
+[[concept_module]]
+
+= Concept Template and Guidelines
+
+_In the title, include nouns that are used in the body text -- this helps readers and search engines find information quickly._
+
+A concept module describes and explains things such as a product, subsystem, or feature -- what a customer needs to understand to do a task. A concept module may also explain how things relate and interact with other things. The use of graphics and diagrams can speed up understanding of a concept.
+
+* Look at nouns and noun phrases in related task modules and user story assemblies to find the concepts to explain to users. 
+
+* A concept module in product documentation should explain only things that are visible to users. 
+
+* If a product concept is interesting, but not visible to users, the concept probably does not require explanation in a concept module. 
+
+* A concept module should NOT include numbered steps or other wording that instructs a user to execute a command or perform an action. Instead, put that information in a separate task module or user story assembly.
+
+

internal_resources/template_reference.adoc

@@ -0,0 +1,13 @@
+[[reference_module]]
+
+= Reference Template and Guidelines
+
+_In the title, include nouns that are used in the body text — this helps readers and search engines find information quickly._
+
+A reference module lists things (such as a list of commands) or has a very regimented structure (such as the consistent structure of man pages). A reference module explains the details that a customer needs to know to do a task.  A reference module is well-organized if users can scan it to quickly find the details they want.
+
+* A reference module that is a list of things may be made easier to scan if its content is organized alphabetically or formatted as a table. Think of an alphabetical list of commands that can be used with an application, or of an alphabetical list of system components with brief definitions formatted as a 2-column table.
+
+* If you have a large volume of the same type of information to document, figure out a consistent structure that the information details can fit into and then doument each logical unit of information as 1 reference module. Think of man pages, which document very different information details, but that use consistent titles and formats to present those details in a consistent information structure.
+
+

internal_resources/template_task.adoc

@@ -0,0 +1,59 @@
+[[task_module]]
+
+= Do One Task
+
+_Start title with verb form such as Creating. Use the gerund form (noun form of verb) for titles, not the imperative form._
+
+_Avoid using the word 'Configuring' over and over.  Other words might include:_
+
+* _Specifying_
+* _Adding_
+* _Constructing_
+* _Arranging_
+* _Building_
+* _Setting_
+* _Managing_
+* _Defining_
+* _Customizing_
+* _Or instead of using synonyms (which becomes obvious) 'verb-alize' a word and refactor the heading - limiting (instead of 'setting resource limits')_
+
+_The standard for all Red Hat documentation is title case for all headings and titles._
+
+_A task module is a procedure written with numbered steps -- what a customer needs to do to accomplish a goal successfully._
+
+This paragraph explains why the user performs the task, sets the context of the task, and may explain or list special considerations specific to this task. Keep the information brief and focused on what is needed for this specific task. Suggested length is 1 to 3 sentences, can be longer if needed.
+
+
+.Prerequisites _(if needed)_
+
+* Sentence or a bulleted list of prerequisites that must be in place or done before the user starts this task. 
+
+* Delete section title and bullets if the task has no required prerequisites.
+
+* Text can be a link to a prerequisite task that the user must do before starting this task.
+
+
+.Procedure
+
+_Start title with verb form such as Creating. Use the gerund form (noun form of verb) for titles, not the imperative form._
+
+_Put steps in a numbered list. The step sequence is important to a repeatable successful outcome._
+
+. Start each step with an active verb, because each step corresponds to one user action.
+
+. Include one command or action per step.
+
+. Format the step line as an unnumbered bullet if the procedure includes only 1 step (exception to numbering the steps).
+
+. Include one command or action per step.
+
+. Include one command or action per step.
+
+
+.Related Information _(if needed)_
+
+* Bulleted list of links to concepts, reference, or other tasks closely related to this task. 
+
+* Include only the most relevant items as links, not every possible related item.
+
+* Delete section title and bullets if no related information is needed.

internal_resources/template_task_brief.adoc

@@ -0,0 +1,20 @@
+[[task_module]]
+
+= Do One Task
+
+This paragraph explains why the user performs the task, sets the context of the task, and may explain or list special considerations specific to this task. Keep the information brief and focused on what is needed for this specific task. Suggested length is 1 to 3 sentences, can be longer if needed.
+
+
+.Prerequisites _(if needed)_
+
+* List
+
+
+.Procedure
+
+. List
+
+
+.Related Information _(if needed)_
+
+* List