🗂️ Hướng dẫn Quản lý Dự án & Kiểm thử Chất lượng (QA) cho iBrowe

Tài liệu này trình bày các phương pháp tốt nhất trong việc quản lý issue, milestone, kiểm thử chất lượng và phát hành trong quy trình phát triển của iBrowe. Nội dung được điều chỉnh từ quy trình nội bộ của Brave, và tùy biến theo mô hình làm việc của iBrowe.

📝 Yêu cầu đối với Issue

Mọi công việc đều phải có issue trên GitHub, trừ các trường hợp sau:

  • Cập nhật tài liệu (documentation-only)
  • Thay đổi trong file .github/CODEOWNERS

Nếu thay đổi của bạn không thuộc các ngoại lệ trên, hãy tạo issue trước khi gửi Pull Request (PR).

🎯 Nhãn Ưu tiên (Priority Labels)

Sử dụng nhãn ưu tiên để sắp xếp thứ tự công việc:

  • priority/P1 → Lỗi nghiêm trọng, có thể cần phát hành nóng (hotfix)
  • priority/P2 → Vấn đề nghiêm trọng, có thể cần nâng cấp thủ công (uplift)
  • priority/P3 → Tính năng/bug thông thường, theo tiến độ phát hành chính
  • priority/P4 → Mục tồn đọng đã được lên kế hoạch
  • priority/P5 → Không có mốc thời gian, chưa được lên lịch

Không hạ cấp độ ưu tiên của issue khác mà không có sự thống nhất với nhóm.

🛳️ Quản lý Milestone & Phát hành

  • Mỗi milestone phát hành gắn với nhánh riêng (ví dụ: 1.13.x, 1.13.x Release #2)
  • QA xác nhận từng bản phát hành thông qua kênh Slack #release
  • Mô tả milestone cần liên kết đến milestone trước đó
  • Issue được gán vào milestone sau khi đã merge, trừ khi là release/blocking (ví dụ lỗi bảo mật, lỗi nghiêm trọng)

Milestone cho Pull Request

  • PR phải nhắm đúng milestone tương ứng với nhánh được merge
  • Với nhánh main, dùng phiên bản được chỉ định trong src/ibrowe/package.json

📌 Chính sách Uplift

Mặc định, tất cả PR sẽ merge vào nhánh main. Để nâng cấp lên nhánh Dev/Beta/Release, cần:

  1. Tạo PR nhắm đến nhánh phiên bản cụ thể (ví dụ: 1.13.x)
  2. Liên kết issue gốc trong phần mô tả PR
  3. Được duyệt bởi người có quyền uplift

🔐 Người duyệt uplift chỉ định:

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

⚠️ Hãy xác nhận PR uplift đã được merge và hiển thị trên bản Nightly trước khi coi như hoàn tất.

🗃️ Bảng Dự Án (Project Boards)

  • Các bảng quản lý được chia theo khu vực chức năng (1:1 với nhóm Pod)
  • Tham khảo: [iBrowe Projects]

Trong quá trình phân loại (triage):

  • Di chuyển issue từ trái ➜ phải dựa trên tiến độ
  • Dọn sạch cột “Untriaged Backlog”
  • Gắn nhãn priority/P1–P5 tương ứng

🧪 Hướng dẫn Kiểm thử (QA)

Nhãn QA

  • Luôn gắn QA/Yes hoặc QA/No

  • Sử dụng QA/No nếu:

    • Chỉ dùng nội bộ / công cụ hỗ trợ
    • Là meta issue
    • Đã được kiểm thử đầy đủ qua issue khác có test plan

Kiểm thử theo nền tảng

  • Sử dụng nhãn sau nếu cần:

    • QA/Test-All-Platforms → Kiểm thử trên mọi hệ điều hành
    • QA/Test-All-Device-Types → Điện thoại, máy tính bảng, v.v.

Xác nhận kiểm thử nền tảng:

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

🔍 Truy vấn các issue chưa có nhãn kiểm thử:

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

📝 Ghi chú Phát hành (Release Notes)

Mỗi issue phải có một trong các nhãn:

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

🔍 Truy vấn issue thiếu tag:

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

✅ Ghi chú phát hành nên được:

  • Soạn thảo sớm trong giai đoạn Beta
  • Ghi lại trong file CHANGELOG.md ở thư mục gốc
  • Được liên kết hoặc sao chép vào phần mô tả phát hành trên GitHub

🧑‍🔬 Yêu cầu Tài nguyên QA

Sử dụng dự án QA Resources:

Vòng đời QA:

Requested ➜ Upcoming ➜ In Progress ➜ Completed

📌 Lưu ý: Các bản phát hành theo lịch trình tuân theo [Lịch phát hành iBrowe]. QA vẫn sẽ tiếp tục phân loại và ưu tiên các bản sửa lỗi khẩn cấp theo hệ thống này.

📎 Nguồn: Điều chỉnh từ tài liệu kỹ thuật và QA nội bộ của Brave. Tất cả quy trình đã được tái cấu trúc để phù hợp với cơ chế quản trị dự án của iBrowe.