--- # System prepended metadata title: DAOhaus Bug Triage Flow tags: [magesmiths] --- --- title: DAOhaus Bug Triage Flow tags: magesmiths --- # DAOhaus Bug Triage Flow The objective here is to create an efficient and scalable process to surface identify, triage, prioritise and fix bugs on the DAOhaus platform. A clear process should help us to: 1. Provide customer support & raise bugs where necessary 2. Gather the right information for prioritisation & bug-fixing 3. Prioritise bug fixes based on severity 4. Streamline workflows for Devs to start work ## Personas & Platforms **Personas** 1. User 2. Support Contributor 3. Product Contributor 4. Devs Contributor **Platforms** 1. Discord #support channel 2. Github Issue ## What success looks like This process would be successful if: 1. **User** get their fix or tickets ready for investigation within a few hours 2. **Support** Contributor can easily submit bug reports to Magesmiths (within a few hours) 3. **Product** Contributor have clearly prioritize and schedule bug reports (mostly) on their own within 1-2 days 4. **Devs** Contributor have a bug list that are prioritized & well-substantiated without too much context-switching ## Process Here's a preview of how the process would look like ![](https://cdn.discordapp.com/attachments/858813469809967164/935627517988069416/unknown.png) **Support Flow** This flow focuses on helping users find a fix to their issues or logging un-fixable issues to Magesmiths quickly. At the end of this flow, users should either have fixed their issues or have them logged on Github within a few hours | Step | Phase | User/Contributor | Platform | Time | | ---- | ----------------------------------------------------------------------------------------------------------------------- | --------------------------- | -------- | ---------------- | | 1 | **Customer Support**: When bug is raised, we suggest known or related solutions to the issue | Support Contributor | Discord | Within few hours | | 2 | **Log Bug**: IF step 1 fails, create a Github Issue with (1) steps to reproduce (2) affected DAOs & URLs | Support Contributor or User | Github | Within few hours | **Product Flow** This flow helps the Product Contributors to investigate, prioritise and schedule bug fixes for Dev Contributors. Ideally, the Product Contributors should be able to complete the above to arrive at **Fix Now / This Sprint / Next Sprint** start times. As much as possible, the process should help Product Contributors do this on their own, so we minimize the need for Dev Contributors to context-switch between bug investigation & dev work. At the end of this flow, the Dev & Product team should have bugs sorted according to priority and scheduled to start work. | Step | Phase | User/Contributor | Platform | Time | | ---- | ------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | -------- | ------------------------------------------- | | 1 | **Investigation**: When a new bug report is submitted, we review & ensure that information collected is sufficient for prioritisation | Product Contributor | Discord | Within 1-2 days | | 2 | **Prioritisation**: Based on the Prioritisation Matrix, we prioritise the bugs & set a timeline to start fixing (not due) | Product &/or Dev Contributor | Clickup | Depends, could be faster if high priority | | 3 | **Schedule for fix**: We move the tickets on Clickup based on the priority & assign to Dev Contributors | Product &/or Dev Contributor | Clickup | Depends, could be faster if higher priority | | 4 | **Fix** the bug | Dev Contributor | Clickup | Depends on Dev's discretion | > The Prioritisation Matrix helps us decide the order & urgency of starting the fix, not estimating effort and timeline to complete the fix. For most tasks, a Product contributor should be able to prioritise without touching the Devs. >![](https://i.imgur.com/8WlGgNe.png) > The Prioitisation Matrix has 2 axes: Usability x 'Core-ness'to the DAOhaus UX. > > 1. **Core-ness: This helps us filter between the many features & use cases in the DAOhaus app (some are more periphery than the rest).** Here we answer - "For this use case, how significant is this in the UX of accessing & doing things with a DAO?" For instance, a security/data availability issue or inability to load the DAOhaus app would be very core, as compared to a bug in a DAOhaus Boost > 2. **Usability: This dives deeper into the particular use case & assesses how broken / unusable the feature is.** For instance, an inability to load the Proposals would be highly unusable as compared to a typo or UI issue on Proposal cards. Here is how the start times for bug fixes would look like: - Fix Now: Bug fixes should start by D+0 (within few hours) or D+1 - Fix This Sprint: Bug fixes should start by D+2 or 3 - Fix Next Sprint: Bug fixes should start by D+7 and above --- # Appendix > Disclaimer: The following numbers track # Clickup tasks tagged as `bugs`. The measurement may not include: > - Bugs surfaced & fixed but not created on Clickup > - Bug fixed but not updated on Clickup From April to Dec 2021, there were 47 Clickup `bugs` created. As of January 26 2021, we shipped **57% (27/47) of all bugs**. **21% of all bugs are ready but not started yet**. ![](https://i.imgur.com/F5oq5qs.png) Among all 27 bugs shipped, there was a wide spread in the days to fix. However the average days to fix was around 2 weeks+ at **18.8 days**. ![](https://i.imgur.com/godEY0v.png)