🗂️ iBrowe Project Management & QA Guidelines

This guide outlines best practices for managing issues, milestones, QA, and releases in the iBrowe development process. It is adapted from Brave’s internal protocols and customized for iBrowe’s workflows.

📝 Issue Requirements

All work must have a GitHub issue unless it falls into these exceptions:

  • Documentation-only updates
  • .github/CODEOWNERS file changes

If your change doesn’t fall under these, create an issue before submitting a PR.

🎯 Priority Labels

To prioritize tasks:

  • priority/P1 → Critical bug, potential hotfix needed
  • priority/P2 → Serious issue, may require uplifting
  • priority/P3 → Standard feature/bugfix, goes with the release train
  • priority/P4 → Planned backlog item
  • priority/P5 → No timeline, not currently scheduled

Do not downgrade another issue’s priority without team alignment.

🛳️ Milestone & Release Management

  • Every release milestone is defined per branch (e.g. 1.13.x, 1.13.x Release #2)
  • QA signs off on each release in the #release Slack channel
  • Milestone descriptions must link to the prior milestone
  • Issues are assigned to a milestone after they land, unless they’re marked release/blocking (e.g. security bugs, major regressions)

Pull Request Milestones

  • PRs must target the milestone matching the branch they’re merging into
  • For main, use the version listed in src/ibrowe/package.json

📌 Uplift Policy

All PRs land in main by default. Uplifting to Dev/Beta/Release requires:

  1. Creating a PR against the version branch (e.g. 1.13.x)
  2. Linking the original issue in the PR body
  3. Getting approval from an uplift approver

🛑 Only uplift approvers may approve PRs to versioned branches:

  • @rebron
  • @kjozwiak
  • @Sri
  • @clifton

Always confirm your uplift is merged and visible in Nightly before considering it done.

🗃️ Project Boards

Boards track functional areas (1:1 with Pods).
Reference: iBrowe Projects

During triage:

  • Move issues from left ➜ right based on progress
  • Clear the “Untriaged Backlog” column
  • Label issues with priority/P1–P5 appropriately

🧪 QA Guidelines

QA Labels

  • Always add either QA/Yes or QA/No
  • Use QA/No for:
    • Internal-only/tooling issues
    • Meta issues
    • Items already fully covered by another issue with a test plan

Platform-specific Testing

Use these labels if required:

  • QA/Test-All-Platforms → Requires testing across all OSes
  • QA/Test-All-Device-Types → Phone, tablet, etc.

To mark platform verification:

  • QA/QA Pass-Win64
  • QA/QA Pass-macOS
  • QA/QA Pass-Linux

QA can query issues missing these labels with:

is:issue is:closed milestone:"1.13.x Release #2" -label:"QA/No" -label:"QA/QA Pass-Win64"

📝 Release Notes

Every issue must have one of:

  • release-notes/include
  • release-notes/exclude

Check missing tags with:

is:issue milestone:"1.13.x - Beta" -label:"release-notes/include" -label:"release-notes/exclude"

Release notes should be:

  • Drafted early in Beta
  • Logged in CHANGELOG.md in the root directory
  • Linked or copied to the GitHub release entry

🧑‍🔬 Requesting QA Resources

Use the QA Resources Project:

  1. Create an issue using: https://github.com/ibrowe/qa-resources/issues/new/choose
  2. Assign to project: QA Work Priority List
  3. Use P1 if urgent and notify QA in #testers

QA lifecycle:

  • Requested ➜ Upcoming ➜ In Progress ➜ Completed

Note: Scheduled releases follow the iBrowe Release Schedule. QA will continue triaging and prioritizing hotfixes through the same system.

📎 Source: Adapted from Brave’s internal engineering and QA documentation. All protocols restructured for iBrowe project governance.