Add definition of ready and done (#3031)

* Add definition of ready and done

* Update text

CONTRIBUTING.md

@@ -8,6 +8,9 @@ Contributing encompasses repository specific requirements.
 
 To review the ODH requirements, please refer to the [dev setup documentation].
 
+## Definition of Ready
+Before beginning development on an issue, please refer to our [Definition of Ready](/docs/definition-of-ready.md).
+
 ## Writing code
 
 ### Running locally
@@ -219,3 +222,7 @@ npm run make:deploy
 ```
 
 you will deploy all the resources located in the `manifests` folder alongside the image you selected in the previous step.
+
+
+## Definition of Done
+Once the elements defined in the [Definition of Done](/docs/definition-of-done.md) are complete, the feature, bug or story being developed will be considered ready for release.

docs/definition-of-done.md

@@ -0,0 +1,37 @@
+# Definition of Done
+When the elements in the Definition of Done are complete, the feature, bug or story being developed will be considered ready for release.
+
+## Code completion
+- The code has been reviewed by an advisor and another member of the dashboard team, ran it locally and approved it.
+- Any new Dashboard Pod Endpoints has an architectural review -- thus avoiding security holes introduced in the backend.
+- Reviewer will identify any code that might behave differently upstream and downstream and ensure developer has adequately tested these scenarios.
+- Any code change has appropriate automated tests (cypress, unit) before the code can be merged.
+- UI visual changes match designs proposed by UX.
+
+## Testing and verification
+- For feature work - a demo has been created and recorded (and linked to in the relevant Jira issue).  For bugs - screenshots should be added to the pull request and linked to from Jira for reference.
+- All changes (fixes, new features...) have been tested at least manually (ideally automated) using a built image.  This can be a nightly ODH image or an RC build.
+- Information about how the changes were tested should be added to the relevant Jira issue (epic, bug or story with no epic parent).
+- All code has been merged to the downstream branch and automated quality gates have successfully passed.
+
+## Jira status
+- Screenshots of the updated UI should be captured in the Jira history/comments (or link to GitHub Pull Request with these screenshots) to illustrate work that was completed.
+- All related UX stories are closed.
+- Any blocking, dependent or child issues are all closed in Jira.
+- Epic has fix version set, any bugs or stories that do not have an Epic parent have the fix version set.
+- Any follow-up issues that were identified during testing or review but do not block the release have been created in Jira and linked to the original issue.
+- Any issues needing release notes are identified and information provided to the docs team.
+
+## Stakeholder acceptance/review
+- A link to a working cluster with the code is provided for UXD, PM and Docs to try out the feature.
+- Link to the demo created above is also made available to stakeholders to assist during the acceptance process.
+- UI visual changes have been reviewed and/or tested by UX.
+- UI microcopy has been reviewed.
+- Any new feature must conform to the Dashboard Architect's approval.
+- PM has reviewed and signed off on the functionality.
+
+Once all of the above bullets are completed - the epic, story or bug that is being considered will be ready for release.
+
+More details at:  [What is the Definition of Done?](https://www.agilealliance.org/glossary/definition-of-done/)
+
+

docs/definition-of-ready.md

@@ -0,0 +1,30 @@
+# Definition of Ready
+When the elements defined in the Definition of Ready are complete, the product team can begin its implementation of the deliverables identified
+
+## Requirements clear
+
+1. Jira exists and all requirements have been refined and written as a user story (i.e. “As an <user> I want <feature> so that <solves the problem>”) for example in a living Google document attached to the JIRA until fully refined and moved back into JIRA.  The stories should be assigned points before work can begin.
+2. Teams that will work on the JIRA are identified - the teams will create the child JIRAs to capture the work based on the requirements
+3. Acceptance criteria, incl. a description of acceptance tests, exist and are understood by the team
+4. Dependencies have been identified so that they would not block the JIRA from being completed - dependencies will be tracked in linked JIRAs
+5. All stakeholders (PM, BU, Eng/QE, CCS, UX) reviewed the requirement and there are no outstanding questions
+6. Any new feature has been reviewed and approved by the Dashboard Architect.
+7. An owner is identified and is responsible for communicating the status to all stakeholders
+8. All stakeholders provided time and resource estimates for the work/task that needs to be done - Eng, Docs, QE, UX, feature owners are identified
+9. Changes to requirements during the design, development, and testing phases must be promptly communicated and justified to impacted stakeholders who must promptly review
+10. UX designs have been reviewed and signed off by stakeholders with no major changes to be expected. These designs need to be in a state where the work can be scoped by the dashboard team, though not necessarily complete. Small details can be worked on as we start allowing the team to discover minor implementation details about the flow during development.
+11. API (REST and CRD) requirements for the feature should be clearly documented and reviewed with one of the advisors on the Dashboard team.
+12. Feature implementation document including API requirements and any high level implementation points that are critical should be created and reviewed by an advisor on the Dashboard team.
+13. Dependencies and backend component APIs should be fully ready (including v2 Operator support built-in).  These features could be enabled via DevFlags if needed but should not be installed via scripts or yaml files provided by the backend team.  
+14. The backend team should provide a demo of how to use the resources for the feature and provide sample data to use for the feature development.
+
+## Non-functional requirements clear
+
+1. Security, Performance, Disconnected, Interoperability, and Usability expectations are reviewed and any impacts that teams must consider during development and testing are captured.
+
+## Infrastructure defined
+
+1. A CI (Continuous Delivery) platform to deliver nightly builds with the new features/bug fixes is defined
+2. Environment for cross-product/layered-product/interoperability testing is identified and prepared (e.g. Integreatly, or hardware)
+
+More details at:  [What is the Definition of Ready?](https://www.agilealliance.org/glossary/definition-of-ready/)