🗂️ แนวทางการจัดการโปรเจกต์และ QA ของ iBrowe คู่มือนี้สรุปแนวปฏิบัติที่ดีที่สุดสำหรับการจัดการ Issue, Milestone, QA และกระบวนการ Release ในการพัฒนา iBrowe โดยดัดแปลงจากโปรโตคอลภายในของ Brave และปรับให้เข้ากับวิธีทำงานของ iBrowe

📝 ข้อกำหนดสำหรับ Issue งานทุกชิ้น ต้องมี GitHub Issue ยกเว้นในกรณีต่อไปนี้:

• อัปเดตเฉพาะเอกสาร (Documentation-only updates)
• การแก้ไขไฟล์ .github/CODEOWNERS

ถ้างานของคุณไม่อยู่ในข้อยกเว้นเหล่านี้ ต้องสร้าง Issue ก่อนจะส่ง PR

🎯 Priority Labels (ป้ายบอกลำดับความสำคัญ) ใช้จัดลำดับงานตามความสำคัญ:

• priority/P1 → Bug สำคัญมาก อาจต้องออก Hotfix
• priority/P2 → ปัญหารุนแรง อาจต้องยกขึ้น Release Channel ที่สูงขึ้น
• priority/P3 → Feature หรือ Bugfix ปกติ รวมอยู่ใน Release ตามรอบ
• priority/P4 → งานที่วางแผนไว้ใน Backlog
• priority/P5 → ยังไม่มีกำหนดการ ไม่มี Timeline ตอนนี้ ห้ามปรับลด Priority ของ Issue ของคนอื่น โดยไม่หารือกับทีมก่อน

🛳️ การจัดการ Milestone & Release

• ทุก Release Milestone จะถูกกำหนดตาม Branch (เช่น 1.13.x, 1.13.x Release #2)
• QA จะต้องตรวจสอบและอนุมัติ Release ใน Slack ช่อง #release
• คำอธิบาย Milestone ต้องใส่ลิงก์ไปยัง Milestone ก่อนหน้า
• Issue จะถูกกำหนดเข้า Milestone หลัง Merge แล้ว ยกเว้นเป็น Release Blocking เช่น Security bug หรือปัญหาใหญ่

Pull Request Milestones

• PR ต้องระบุ Milestone ให้ตรงกับ Branch ที่จะ Merge เข้าไป
• ถ้าเป็น Branch main ให้ใช้เวอร์ชันที่ระบุใน src/ibrowe/package.json

📌 นโยบาย Uplift โดยปกติ PR ทุกอันจะเข้า Branch main ก่อน ถ้าต้องการ Uplift ไปยัง Dev/Beta/Release ต้องทำตามนี้:

• สร้าง PR ไปยัง Version Branch ที่ต้องการ (เช่น 1.13.x)
• ใส่ลิงก์ไปยัง Issue ต้นฉบับในเนื้อหา PR
• ต้องได้รับอนุมัติจาก Uplift Approver

มีแค่ Uplift Approvers เท่านั้นที่สามารถอนุมัติ PR ไปยัง Versioned Branch ได้ ได้แก่:

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

ต้องเช็คให้มั่นใจว่า Uplift ถูก Merge และแสดงใน Nightly แล้วก่อนถือว่างานเสร็จ

🗃️ Project Boards

• Board ใช้ติดตามงานตาม Functional Area (เชื่อมกับ Pods โดยตรง)
• อ้างอิง: iBrowe Projects

ระหว่างทำ Triage:

• ย้าย Issue จากซ้าย ➜ ขวาตามความคืบหน้า
• เคลียร์ Column “Untriaged Backlog” ให้หมด
• ติดป้าย Priority (P1–P5) ให้ถูกต้อง

🧪 QA Guidelines QA Labels

• ต้องระบุ Label QA/Yes หรือ QA/No ทุกครั้ง
• ใช้ QA/No กรณี:
• Issue เฉพาะ Internal/tooling
• Meta Issue (Issue ที่เอาไว้รวมปัญหาเฉย ๆ)
• งานที่ถูกทดสอบผ่าน Issue อื่นที่มี Test Plan ครอบคลุมแล้ว

Platform-specific Testing หากจำเป็นต้องทดสอบหลาย Platform ให้ใช้ Label เหล่านี้:

• QA/Test-All-Platforms → ต้องทดสอบทุก OS
• QA/Test-All-Device-Types → เช่น Phone, Tablet เป็นต้น

สำหรับยืนยันผลทดสอบบนแต่ละ Platform ให้ใช้:

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

QA สามารถ Query หา Issue ที่ยังไม่มี Label เหล่านี้ด้วยคำสั่ง: is:issue is:closed milestone:“1.13.x Release #2” -label:“QA/No” -label:“QA/QA Pass-Win64”

📝 Release Notes Issue ทุกอันต้องมี Label อย่างใดอย่างหนึ่ง:

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

ตรวจสอบว่ามี Issue ไหนขาด Label เหล่านี้ได้ด้วย: is:issue milestone:“1.13.x - Beta” -label:“release-notes/include” -label:“release-notes/exclude”

Release Notes ควร:

• ร่างตั้งแต่ช่วง Beta
• บันทึกในไฟล์ CHANGELOG.md ที่ Root Directory
• แนบลิงก์หรือคัดลอกเนื้อหาไปไว้ใน GitHub Release Entry

🧑‍🔬 การขอใช้ QA Resources

• ใช้ QA Resources Project
• สร้าง Issue ใหม่ที่: https://github.com/ibrowe/qa-resources/issues/new/choose
• กำหนด Project เป็น: QA Work Priority List
• ถ้าเรื่องด่วน ให้ใช้ Priority P1 และแจ้ง QA ที่ Slack ช่อง #testers

วงจร QA:

• Requested ➜ Upcoming ➜ In Progress ➜ Completed

หมายเหตุ: Release ที่ถูกกำหนดตามตาราง จะอ้างอิง iBrowe Release Schedule และ QA จะทำ Triage และจัดลำดับ Hotfixes ผ่านระบบเดียวกันนี้

📎 ที่มา: ดัดแปลงจากเอกสารการจัดการ Engineering และ QA ภายในของ Brave และปรับโครงสร้างให้เหมาะกับกระบวนการทำงานของ iBrowe