Goal:

• Track documentation changes for Manila adoption NFS scenario

Acceptance Criteria:

• Remove NFS known limitation
• Add "ceph cluster create" guide

Mini content journey

**

Reviewers:

• Technical: [name]
• Peer: [Writer name]
• QE: [name]
• Partner/Field (optional): [name]

Is this feature fully supported or technical preview?

• Full support: Documentation will be published on the customer portal
• Tech preview (TP): Documentation is not published
• TP exception (Knowledge Base Article / Doc): 
• If there is a strong customer demand for testing this feature and the writer has capacity, dev/PM can author a KB article or gdoc and if the writer has capacity they can review/edit the article. 
• If the feature is deemed high-impact by the BU/PM and docs must be published, then include the technicalpreview.adoc module in the doc.

**

Does the procedural content need to be tested by QE?

• Yes: QE needs to create a doc testing ticket per How-to Jira with the docs team
• No: Exemption approved by <STAKEHOLDER NAME>

**

Does the documentation epic need a release note in addition to the feature?

• Yes: Writer fills in the Release Note Text and Release Note Type in the doc epic fields. This is not the engineering epic. This RN is usually reserved for documentation epics that trail behind product features or that cover functionality that doesn't have a parent feature (rare but still happens).
• No: The engineering feature or epic might still need a release note. Engineers need to follow the guidance set in[ __ How-to Jira with the docs team|https://spaces.redhat.com/display/RHOSPDOC/How-to-Jira+with+the+RHOS+docs+team].

**

What stage of the user journey are you targeting?

• Discover: Overview, reference, blogs (Find solutions)
• Learn: Validated architectures, reference, FAQ(Gain Knowledge)

• Try: Technical Preview, quickstart (Start, try, test)
• Adopt: Adoption or Greenfield feature (Early stage customer use)
• Expand: Customizations, day 2 operations, troubleshooting, add features to control plane or data plane

**

Who is your target persona?

• RHOSO admin:  Platform Engineer
• OpenStack admin:  Cloud Administrator
• OpenStack user: SysAdmin or Developer

**

What type of information does the user need to know in order to use the feature?

• Procedures to implement or enable the feature
• Procedures to customize or configure the feature after installation
• Procedures or considerations for upgrades, adoption, or minor updates
• Procedures to verify that the feature is enabled and is working as expected
• Procedures to operate or maintain the feature
• Concepts that need to be explained or planning decisions that must be made before the user can perform any of these procedures
• Permissions level required (RHOSO/OCP) or security considerations
• Known issues, limitations, or troubleshooting guidance

**

Are there any existing upstream or internal resources that the writer can use for planning and drafting the content? Consider the situational context of the existing content. Do a Google search for any possible resources that might help.

• <LINKS>
• <If there are no links available at the time of doc planning, writer can create spikes or tasks to collect this information later from the DFG>

Does the content require input from multiple DFGs?

• Yes: Writer creates spikes or stories under this epic and assigns them to the relevant writers for scoping
• No: Stories are not required unless the epic needs to be divided to user stories that can be delivered separately (for personal use, consider sub-tasks instead)

**

Does the content need to be included in any of the following guides?

• Validated architecture (VA) guide: Is the content a part of a VA workflow, such as HCI, NFV, BGP, etc?
• Planning guide: Are there prerequisites or planning decisions to add to the Planning guide? 
• Deployment/Customization guide: Does the feature need to be enabled during the deployment  process, or can it be enabled post-deployment?
• Adoption/minor updates guide: Are there any considerations or impact of this feature on adoption from pre-18 environments or from earlier 18z versions?

**

(Optional) Are there any additional content improvements you can also implement for the user when documenting this goal? Consider any additional actions that might also improve content. For example, restructuring content to better suit the user story.

• <Ideas and suggestions for improvements of existing content>

**

(Optional) Documentation outline If applicable, the writer can start brainstorming about the information design for the content. This is understood to only be a draft placeholder and subject to change as the content is authored and reviewed.

• Module Title (Concept)

• Overview of content required

• Module Title (Concept)

• Overview of content required

• Module Title (Procedure)

• Prerequisites

• Outline of steps

• Module Title (Procedure)

• Prerequisites

• Outline of steps

• Module Title (Reference)

• Outline of parameters/options/data to be included

• Module Title (Reference)

• Outline of parameters/options/data to be included