Mini Content Journey

• Docs
  • The two procedures are documented as separate from each other (OpenStack update, system update).
  • We should warn that customizing the package list for updating within OpenStack update can result in updates of RPMs that would require a reboot - customizations of that package list should be validated by the customer.
  • The system update procedure documentation mentions that the procedure is optional – alternatively tools like Satellite can be used to update the system. The docs should warn that the system update should happen within the EUS stream. (So that users don't go updating to RHELs we don't support.)

Reviewers:

• Technical: Jiri Stransky, Mikolaj Ciecierski
• Peer: [Writer name]
• QE: tech preview, if it gets QE'd it would be Archana Singh
• 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.
• This will be TP exception - doc published as a KCS. Add TP disclaimer to top, or add it to top of module that introduces this procedure.

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>
• Not necessarily prior to the release. It can be tested if there's capacity. OSPRH-16795 

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].
• Does not need a release note.

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
• Try / day 2 operations.

Who is your target persona?

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

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.

• https://docs.google.com/document/d/1V9ZCAi9Eu41Jzr6QLPOnBag467MA-WlipV12-nsA6V8/edit?tab=t.0#heading=h.hnx6tfshjvhq 

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)
• No

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?
• Minor update guide. Probably a link to a KCS.

(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