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


**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.
>
> 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**.


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**.