Feature Overview (mandatory - Complete while in New status)

Seed example creation (qna file creation) is a crucial piece of the knowledge pipeline. So far, this process has been manual, time-consuming and error prone because users are expected to write yaml files and come up with relevant contexts, qna pairs. 

Goals (mandatory - Complete while in New status)

Provide high-level goal statement, providing user context and expected user outcome(s) for this Feature

• Users can easily run the notebook 
• Clearly explain the different fields in the qna.yaml (purpose of the domain, document outline, context etc) 
• Allow for domain, document outline, use case, end-user expertise to be user-input based and we can use them to inform the generation of qna
• document outline best practices to highlight: 
  • all documents related to a particular topic, pertaining to the same information, or coming from the same source should fall under one document outline and can be used to generate one or more qna.yamls
  • should be a summary of documents 
  • what can fall under the same document outline? FBI cargo theft information for 2014-2019 (because it covers similar information for different years), documentation for iPhone and iPad (similar source, potentially similar information) 
  • what ideally should be under different document outlines? RHEL and RHEL AI/OpenShift AI/OpenShift documentation - likely will cover very different information etc 
  • ideally, we can try to make this process extremely intuitive - rather than using keywords familiar to us, we can ask them questions to inform behavior and generate qna yamls
• For this flow, we expect users to want to generate one of more qna.yaml files for a set of documents related to one document outline 
• So, for docs that will be significantly different or goal is to teach model different things, users will have to run through the notebook multiple times. 

Requirements (mandatory -_ Complete while in Refinement status):
A list of specific needs, capabilities, or objectives that a Feature must deliver to satisfy the Feature. Some requirements will be flagged as MVP. If an MVP gets shifted, the Feature shifts. If a non MVP requirement slips, it does not shift the feature.
 

Done - Acceptance Criteria (mandatory - Complete while in Refinement status):
Acceptance Criteria articulates and defines the value proposition - what is required to meet the goal and intent of this Feature. The Acceptance Criteria provides a detailed definition of scope and the expected outcomes - from a users point of view.

• Ensure it passes UX reviews ([reqs documented here|https://github.com/instructlab/examples/blob/main/Notebook-UX-Review-Template.md])

Use Cases - i.e. User Experience & Workflow: (Initial completion while in Refinement status):
Include use case diagrams, main success scenarios, alternative flow scenarios.
<your text here>

Out of Scope {}{}(Initial completion while in Refinement status):
High-level list of items or persona’s that are out of scope.
<your text here>

Documentation Considerations {}{}(Initial completion while in Refinement status):
Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation..
<your text here>

Questions to Answer {}{}(Initial completion while in Refinement status):
Include a list of refinement / architectural questions that may need to be answered before coding can begin.
<your text here>

Background and Strategic Fit (Initial completion while in Refinement status):
Provide any additional context is needed to frame the feature.
<your text here>

Customer Considerations {}{}(Initial completion while in Refinement status):
Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.
<your text here>

Team Sign Off (Completion while in Planning status)

• All required Epics (known at the time) are linked to the this Feature
• All required Stories, Tasks (known at the time) for the most immediate Epics have been created and estimated
• Add - Reviewers name, Team Name
• Acceptance == Feature as “Ready” - well understood and scope is clear - Acceptance Criteria (scope) is elaborated, well defined, and understood
• Note: Only set FixVersion/s: on a Feature if the delivery team agrees they have the capacity and have committed that capability for that milestone

• …