Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

(WIP) Triage of issues

Brian Clifton edited this page Nov 21, 2017 · 8 revisions

This guide is intended to help assess priority when reviewing open issues for browser-laptop.

Getting started

Issues which are needing triage are assigned to the Triage Backlog milestone: https://github.com/brave/browser-laptop/milestone/48

These issues are needing to be looked at. At Brave Software, we have a weekly 1 hour meeting on Tuesdays at 10am PST with the purpose of going through the issues.

Assessing Priority

We should be triaging issued based on a set of criteria which involves the user. Let's continue to refine and expand this list to make triaging any issue easy.

  • P1 - Blocks development or testing. Product cannot run.
    • Issues labelled P1 need to be fixed immediately
    • These would be shipped in the next release
  • P2 - Crashes. Loss of data. Severe memory leak.
  • P3 - Major loss of function.
  • P4 - Minor loss of function. Workaround usually present.
  • P5 - Cosmetic. Spelling, copy, layout.
    • if issue is requesting a new feature, it likely falls here
    • for new features, let's try to match up to an initiative

Once an issue is assigned a priority, please move it to the prioritized backlog: https://github.com/brave/browser-laptop/milestone/88

Tying issues to initiatives

Feature requests can be difficult to judge based on the above criteria. For these, we want to tie them to a Brave Software initiative. For example, issues with website compatibility would be a great candidate for initiative/web-compat. Please label the issue with these

Assigning milestone

Assigning a milestone should typically be avoided. The triage process should focus on:

  • establishing a priority
  • assigning an initiative label(s)
  • moving issue to prioritized backlog

There are times where the issue is required for a release and it also blocks the release. If folks agree this should be looked at, we can choose to assign to a given release milestone and add the release blocking label.

How to add/remove labels

DO

  • Add bug to any bug (this will make it easy to find issues which should be fixed actually)
  • Add Info-needed to issues which additional information should be provided
  • Remove Info-needed from issues which additional information was provided
  • Add Duplicate to duping issues
  • Add QA\no qa needed to issues and PRs which do not require QA tests
  • Add labels under feature to major features (eg. feature/autofill)
  • Add labels under misc to minor or general features (eg. misc/favicon)
  • Add labels under OS to issues which are specific to each platform (eg. OS/Windows)

DO NOT

  • Remove the other labels, if any, from issues labelled with Duplicate
  • Add labels under OS to multi-platform issues

Vertical Side Tabs Tab Suspender

Clone this wiki locally