Product - Guidelines

This guide outlines different product boards and how we use them internally to track and prioritize the issues, and feature requests.

The tool we use:

We used [Github Projects] previously. As of now, we use Zenhub to track and manage issues in Chatwoot.

Quick Links:

Do you like to contribute any changes to this doc? Engage in the discussion here.

Properties of a GitHub Issue:

Title & Description: Each issue should have a proper title and detailed instructions explaining the problem (or context about the feature request)
Reported Date: Every issue added to Github would have a reported date, this can be the date when the issue was created or even before that in case of live chat or email support queries.
Due Date: Once the issue is triaged, if it is a bug, it should have a due date added to it.
Estimated Points: Once the issue is triaged, points should be added to the ticket.
Release version (Milestone): Based on the requirements, every ticket should have an associated milestone and should be prioritized in a sprint.

General guidelines:

All issues should be triaged and estimated before picking them up.
Each issue should have a clear description and a to-do and it should follow the issue templates.
8 and 5-pointer tickets should be broken down into 2 or 3-pointer tickets.

Triaging an issue:

The goal is to triage an issue as soon as possible and to make sure that there is a consistent response from the Chatwoot team to the customers and to the community.

Triaging a bug

Every issue would be considered untriaged unless it has a **ready-for-pickup** or **need-more-info** or **need-discussion** or **investigation** label.
If the issue is reported as a bug, the assignee should try to reproduce the issue and make sure that the case is valid or mark it as need-more-info by requesting the information from the person who created the issue.
If the bug is confirmed then it should have a severity label as defined here.
If the issue requires more time to be investigated, the assignee can mark it as an **investigation** ticket. We should make sure that the issues are not in the investigation queue for a long time.
If the request is a feature request and you cannot immediately respond, add the labels **need-discussion** and **feature-request**.

Working on new features:

Every feature request needs a product spec. This is done to make sure that we have collected enough information to move ahead and that there is no confusion around the feature when we are trying to build one.

Whenever you need input from the design team, add the label need-design.
Once the design is complete and the product spec is complete, there can a discussion on how this would be split into multiple smaller engineering issues. (These discussions should be done async, create a meeting only if absolutely required)
Once smaller engineering issues are created, this can be prioritized for pickup in the upcoming sprints.

Weekly progress retro:

Look at the previous week's issues, and see if we have missed anything.
Follow the template of What went wrong / What can be improved / What went well to discuss the previous week's progress.
Look at the list of customer-reported issues on the call. Prioritize the issues based on the requirements.
Where do we stand on the milestone? (Look at tagged issues for the milestone, and see if we need to move something)

Creating and managing issues:

Paid Customer Requests:

Goals:

Every issue should be triaged within one business day.
Severity 1 & 2 bugs should be fixed within a week.

What should be done:

When a customer (cloud or paid) reports an issue:

Create the issue in either the Chatwoot main repo or the product repo depending on the information that will be shared. If it has sensitive information, then create it in the product repo.
Tag the issue with customer-reported-issues the label.
Add it to the project Engineering Board.

In most cases, this would be done by the people who are talking to the customers directly.

What is expected:

Triage the issue. Can you confirm whether the issues exist or not?
Assess the severity of the bug if it exists. Assign the severity label to the ticket.

Where to track:

You can view all the issues here: Link to the Engineering Board - Customer Reported Issues. Every team member has to check the board every working day so that there are no issues unattended for a longer period of time.

Community Requests:

Goals:

Every issue should be triaged within four business days.
Severity 1 & 2 bugs should be fixed within the next release.

What is expected:

A team member would be assigned to the ticket automatically in a round-robin fashion.
Triage the issue. Can you confirm whether the issues exist or not?
Assess the severity of the bug if it exists. Assign the severity label to the ticket.