> For the complete documentation index, see [llms.txt](https://docs-developers.juiced.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs-developers.juiced.io/processes.md).

# Processes

## Juiced uses 2 waterfall processes to add or fix features.

### Add

1. **Suggest** = a user, 3rd party, or an internal party may suggest a new feature.
2. **Suggest review** = a suggestion that has received a high amount of upvotes or demand will be reviewed by the CTO, CFO, CEO, and CPO.
3. **Requirements** = if a suggestion is approved, the CTO and CPO will update our documentation to provide instructions on what is required.
4. **Design** = once the requirements are set, the designer will begin the design.
5. **Design review** = upon completing the design, the design will be reviewed by the CPO and other people involved with the feature.
6. **Code** = once the design is approved, the developers will begin coding.
7. **Code review** = once the code is written, the CTO will review the code and make sure the code has been written in line with our build standards.
8. **Testing** = once the code has been approved, the quality assurance developer will run thorough tests on a test app.
9. **Final review** = finally, once the code has been reviewed and the QA has done the tests, the CPO will do a final review.
10. **Partial roll-out** = after the first 9 stages, the feature should be rolled out to a batch of users based on a relative cohort. For example, you can do regional role-outs, interest-based role-outs, etc. 
11. **Full roll-out** = once the partial roll-out has been successful for over 2 weeks without any complaints or bugs, a full roll-out can happen, making the feature available to all users. 
12. **Maintenance** = shortly after the full roll-out, maintenance efforts should be put in place.

### Fix

1. **Report** = a user, 3rd party, or an internal party may report a bug.                                                   *--- OR ---*
2. **Detect** = ai or automation will detect potential flaws, outages, or bugs.
3. **Identify** = within 1-2 hours of detection or reports of issues, developers need to identify the cause of the issue.
4. **Patch** = once the issue is identified, within 30 minutes the bug will need to be patched.
5. **Test** = upon patching the issue, a test should be performed to see if any other issues have come up as a result of the patch or if any other issues are active as a result of the identified cause.