Triage Guidelines

General guidelines

• All work has an issue.
• If you'd like to have an issue schedule to a particular release, add it to the closest matching project board for triage. If you aren't sure use the project called General. A list of all project boards can be found here: https://github.com/brave/brave-browser/projects
• Issues only get assigned to a milestone once they are completed and merged into that milestone.
• Issues that should be locked into a particular milestone without consultation to the person putting it there, should get the release/blocking label added to it and can go into a milestone while the issue is still open. This should be rare though. E.g. a security critical bug, or a Chromium upgrade.
• Please do not change milestones/priority/boards on issues labeled security without consulting the security team in Slack (#security or #security-discussion).
• High level summaries should be maintained on this Roadmap wiki for at least everything up to and including the version which is on master: https://github.com/brave/brave-browser/wiki/Roadmap.
• We have weekly triage meetings which includes the following schedule:
  • Go through the projects listed here https://github.com/brave/brave-browser/projects
    • Get a status on each issue
    • Move issues along the process from the left most column to the right most depending on status.
    • Make sure the Untriaged Backlog column is empty and we add appropriate priority/p1 - priority/p5 labels
  • Some Projects may have a special triage meeting only for that project.
  • Projects will be added and removed over time.

Uplifting

• By default everything is PR'ed against master and only lands in master.
• If something is wanted in Dev, Beta, or Release channel, then a PR must be made to the current version branch and it must get an approval from someone on the uplift approvers list below. That PR must contain the issue link.
• Milestone on the issue should match only the smallest version where it is landed currently and NOT where you want it ideally.
• Milestones on the PRs should match only the version branch that the PR is being merged to.

Uplift approvers

• Current approvers are @rebron @kjozwiak @Sri @bbondy @clifton (Slack usernames).
• If you are not an approver, do NOT approve any requests made to a Beta or Release branch
• Approvers should be working to keep PRs to version branches at 0 issues.
• The person doing the original request must see that the PR actually gets merged.

Priority labels

We use priority labels from 1-5 as a way to describe which issues should be worked on next. The general principle is:

• if there's a P1 issue you could work on, you should do that at your earliest possible convenience
• don't start work on a P(n+1) issue if there's a P(n) issue you could start working on instead

The rest of this is a rough rubric about how to prioritize issues.

• priority/P1: A very extremely bad problem. We might push a hotfix for it. [This should only be for a very few rare issues.]
• priority/P2: A bad problem. We might uplift this to the next planned release. [We don't expect to see many of these.]
• priority/P3: The next thing for us to work on. It'll ride the trains. [Our bread and butter work.]
• priority/P4: Planned work. We expect to get to it "soon". [A larger backlog of things we're getting to.]
• priority/P5: Not scheduled. Don't anticipate work on this any time soon. [Not necessarily wontfix, but not in the work queue at all.]

Ultimately, go by the expectation that folks will pick up issues in priority order. If you're noting a task to add to your team's backlog: probably P4. If you're noting a new important task, probably P3 unless unusually severe. If you're triaging a suggestion which shouldn't edge out anything we've already planned: P5.

QA triage

• Never remove QA/Yes and QA/No labels
• Things that should get a QA/No label: Things that are internal or tooling related only, things that are impossible for QA to test, meta issues, things that are covered by something else fully with a test plan in the same milestone.
• These labels are expected to be added when a PR is submitted, but it gets missed sometimes.
• QA should block a release if there are any issues with neither of those tags using a search query similar to this one but with an appropriate milestone defined: is:issue is:closed milestone:"Releasable builds 0.55.x" -label:"QA/No" -label:"QA/Yes".
• QA should ping people as needed to make sure things have one of those labels.
• Add labels for checked once an issue is checked on an OS. If a certain OS is not needed then indicate it in a comment and mark it as checked too.
• QA should use a search like this to find things that are not yet checked:
  • Linux: is:issue is:closed milestone:"Releasable builds 0.55.x" -label:"QA/QA Pass-Linux" -label:"QA/No"
  • macOS: is:issue is:closed milestone:"Releasable builds 0.55.x" -label:"QA/QA Pass-macOS" -label:"QA/No"
  • Windows: is:issue is:closed milestone:"Releasable builds 0.55.x" -label:"QA/QA Pass-Win64" -label:"QA/No"

Release notes

• Every issue should be tagged with either release-notes/include or release-notes/exclude.
• You can use a search term like this to see all unlabeled issues: is:issue milestone:"0.56.x - Beta" -label:"release-notes/include" -label:"release-notes/exclude"
• Releases shouldn't go out without release notes.
• Ask QA to generate output when ready.
• PR team should get a rough draft at the start of the Beta period of what will be included in the Beta release.
• Release notes should be included in a file on the root of brave-browser named CHANGELOG.md.
• On each release, release notes (or a link to release notes) should also be included in the published release.