Most work must have an issue because other processes like release notes and QA are based off of knowing there is an issue for all work.

We do carve out exceptions for these cases:

• docs
• CODEOWNER
• Work that doesn't require QA and doesn't require release notes

This list may grow, but it is not acceptable to carve out other exceptions unless this documentation is updated first.

It is possible to have a single pull request close out multiple issues. It is acceptable to keep an issue open if it describes work that is done over multiple pull requests. But at the point that QA or release note are needed, the issue should be closed.

When there is no issue created, the PR in question should have enough context linked (the "why" and "what" that’s usually in the issue). This is needed for smoother review and for developers that come across old PRs when using git blame on the code base.

If you'd like to set priority on an issue, use a priority label described below.

• Every time a release happens for something on the Release channel, there is a sign-off on Slack by QA in the #release channel.
• There is 1 milestone per release, but as noted below, a milestone is often based on another milestone in a chain like fashion. Only one milestone per branch is opened at any given time.

• There is no difference between an Android milestone and a Desktop milestone. There should just be for example a 1.13.x milestone.
• If there is a second release within a particular branch (e.g. the 1.13.x branch), then we number it 1.13.x Release #2. If there's a third, 1.13.x Release #3.
• Each milestone within a particular branch, is based on the one before it. The description of the milestone should link to the milestone before it.
• The description of these milestones will be updated as things are released for them. QA will make sure that the whole chain of milestones -are tested for the release on the platform that's happening.
• As an example, we can have a 1.13.x Release #2 as the title. And the description could even be:

  Based on 1.13.x Release <link>
  Desktop Hotfix 2
  Android Release 1 
  

• Pull requests should go into milestones matching the branch name for where they are landing. For master see src/brave/package.json for the milestone version.

• Issues only get assigned to a milestone once they are completed and merged into that milestone.
• Milestones generally do not track open issues.
  • If an issue should be locked into a particular milestone, and it is not implemented yet, then put a release/blocking label on it. This should be rare though. E.g. a security critical bug, a big regression, 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).

• Project boards track areas of work, they should be 1:1 with Pods.
• A list of all project boards can be found here: https://github.com/brave/brave-browser/projects
• Project boards are a great way to organize priorities (via labels) for a given functional area of work.

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

• 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, one PR per channel.
• 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.
• It is possible that a PR that is being uplifted has no associated issue. That means by definition QA and release notes will not be done for that pull request. It is the responsibility of the dev author to make sure what they are landing has an issue if it should be tested or mentioned in release notes.
• There is a handy script you can use for uplifting! Check out the docs here
• The person doing the original request must see that the PR actually gets merged.
• This person must only merge, after they see their change in Nightly and test that it works.

• Current approvers are @rebron @kjozwiak @Sri @clifton (Slack usernames).
• There is a formal GitHub team for the approvers
• 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.

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