Goal:

<-- Notes for defining an appropriate Epic goal  - remove these notes before saving -->

• Provide high-level goal statement, providing user context and expected user outcome(s) for this Epic
• Derived from one or more of the Use Cases/Scenarios or Acceptance Criteria from the parent Feature (or Initiative)
• 2-3 sentences... 

Acceptance Criteria:

<-- Notes for defining Acceptance Criteria  - remove these notes before saving -->

• Acceptance Criteria articulates and defines the value proposition - what is required to meet the goal and intent of this Epic 
• The Acceptance Criteria provides a detailed definition of scope and the expected outcomes - from a users point of view
• ... 

Open questions:

<-- Capture any open questions and resolutions relating to the goal/acceptance criteria - remove these notes before saving -->

From doc planning template:

• 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, release note only
• TP exception: 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.

• 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 doc epic need a release note in addition to the parent feature?

• Yes - Writer fills in the Release Note Text and Release Note Type in the doc epic fields (not the engineering epic)
• 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].

• Are there any upstream or internal resources that the writer can use for planning and drafting the content?

• <LINKS>
• <If there are no links available at the time of doc planning, writer creates 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 assign 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)

• 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

• 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?