ແນວທາງການຕິດຕາມບັນຫາ (Issue-Tracking Guidelines)

ເອກະສານນີ້ອະທິບາຍເຖິງຂະບວນການມາດຕະຖານໃນການຈັດການກັບບັນຫາໃນໂຄງການ UBports. (ຢ່າສັບສົນກັບ ຄູ່ມືການຂຽນລາຍງານບັກທີ່ດີ.)

ບັກຖືກຕິດຕາມຢູ່ໃສ?

ເຄື່ອງມືຕິດຕາມບັນຫາຫຼັກສຳລັບ Ubuntu Touch ແມ່ນ ໂຄງການ ubports/development/ubuntu-touch ໃນ GitLab. ໂຄງການນີ້ຕິດຕາມບັນຫາລະບົບ Ubuntu Touch ທັງໝົດໃນລະດັບລະບົບ, ແລະ ເປັນຈຸດເລີ່ມຕົ້ນສຳລັບຜູ້ໃຊ້ໃນການລາຍງານບັນຫາທີ່ພວກເຂົາພົບພໍ້.

ໃນຂະນະດຽວກັນ, ໂຄງການອື່ນໆໃນກຸ່ມກໍມີເຄື່ອງມືຕິດຕາມບັນຫາຂອງຕົນເອງທີ່ເປີດໃຊ້ງານເຊັ່ນກັນ:

• ບັນຫາສະເພາະຂອງອຸປະກອນຖືກຕິດຕາມພາຍໃຕ້ໂຄງການຂອງແຕ່ລະອຸປະກອນໃນກຸ່ມ ubports/porting.

• ແອັບພລິເຄຊັນຫຼັກພາຍໃຕ້ ubports/development/apps ຕິດຕາມບັນຫາຂອງຕົນເອງ.

• ບັນຫາລະບົບຍັງສາມາດຖືກຍື່ນຕໍ່ແຕ່ລະອົງປະກອບພາຍໃຕ້ ubports/development/core ໂດຍກົງໄດ້ເຊັ່ນກັນ, ຖ້າຫາກວ່າມັນຈະແຈ້ງວ່າອົງປະກອບໃດທີ່ຮັບຜິດຊອບຕໍ່ບັນຫານັ້ນ.

GitLab ອະນຸຍາດໃຫ້ສະແດງ ບັນຫາທົ່ວທັງກຸ່ມ, ການອ້າງອີງບັນຫາຂ້າມໂຄງການ, ແລະ ການໂອນຍ້າຍບັນຫາລະຫວ່າງໂຄງການ, ເຮັດໃຫ້ໂຄງການທີ່ແນ່ນອນທີ່ບັນຫາຖືກຍື່ນນັ້ນມີຄວາມສຳຄັນໜ້ອຍລົງ. ຖ້າບັນຫາສະເພາະຂອງພອດ ຫຼື ເວັບໄຊທ໌ໄປຕົກຢູ່ໃນໂຄງການ ubports/development/ubuntu-touch, ພວກມັນສາມາດຖືກຍ້າຍໄປຍັງໂຄງການທີ່ເໝາະສົມໄດ້.

ປ້າຍກຳກັບ (Labels)

ທຸກບັນຫາ — ເຖິງແມ່ນວ່າບັນຫາທີ່ປິດໄປແລ້ວ — ຄວນຖືກຕິດປ້າຍກຳກັບເພື່ອອະນຸຍາດໃຫ້ໃຊ້ການກັ່ນຕອງຂອງ GitLab ໄດ້. ຕົວຢ່າງເຊັ່ນ, ນີ້ແມ່ນ ບັນຫາທີ່ຕິດປ້າຍກຳກັບ 'Kind: enhancement' ພາຍໃນກຸ່ມ ubports/development. ສຶກສາ ໜ້າຊ່ວຍເຫຼືອຂອງ GitLab ເພື່ອຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບການຄົ້ນຫາ ແລະ ການກັ່ນຕອງ.

ປ້າຍກຳກັບຕໍ່ໄປນີ້ຖືກໃຊ້ພາຍໃນໂຄງການ UBports. ເນື່ອງຈາກ merge requests (MRs) ໃນ GitLab ໃຊ້ຊຸດປ້າຍກຳກັບດຽວກັນ, ປ້າຍກຳກັບບາງອັນຂ້າງລຸ່ມນີ້ອາດຈະນຳໃຊ້ກັບ merge requests ໄດ້ເຊັ່ນກັນ.

ສິ່ງທີ່ຕ້ອງເຮັດ (Todo)

ພິຈາລະນາຂຽນເອກະສານກ່ຽວກັບຂະບວນການຈັດການກັບ merge requests ດ້ວຍ.

• Kind: ອະທິບາຍລັກສະນະຂອງບັນຫາ

  • Kind: bug: ບັນຫານີ້ອະທິບາຍບາງສິ່ງທີ່ເຮັດວຽກບໍ່ຖືກຕ້ອງ.

  • Kind: enhancement: ບັນຫານີ້ແມ່ນການຮ້ອງຂໍຟີເຈີ ຫຼື ອະທິບາຍບາງສິ່ງທີ່ສາມາດປັບປຸງໄດ້.

  • Kind: maintenance: ບັນຫານີ້ອະທິບາຍເຖິງໜີ້ສິນທາງເຕັກນິກ; ບາງສິ່ງທີ່ພວກເຮົາຈຳເປັນຕ້ອງໄດ້ທຳຄວາມສະອາດ.

  • Kind: FTBFS: ບັນຫານີ້ອະທິບາຍເຖິງບັນຫາ "Fails To Build From Source" (ຄຳຫຍໍ້ຈາກ Debian).

  • Kind: process: ບັນຫານີ້ແມ່ນບັນຫາການຕິດຕາມສຳລັບຂະບວນການໃດໜຶ່ງ. ຕົວຢ່າງເຊັ່ນ, ຂະບວນການໃນການປ່ອຍເວີຊັນ Ubuntu Touch.

  • Kind: question: ບັນຫານີ້ແມ່ນການຮ້ອງຂໍການສະໜັບສະໜູນ ຫຼື ຄຳຖາມທົ່ວໄປ. ມັນຄວນຈະຖືກສົ່ງໄປທີ່ເວທີສົນທະນາແທນ.

• Needs: ອະທິບາຍການກະທຳບາງຢ່າງທີ່ສາມາດ/ຕ້ອງໄດ້ເຮັດ

  • Needs: help from community: ຜູ້ບຳລຸງຮັກສາໃນປະຈຸບັນບໍ່ມີຄວາມສາມາດໃນການແກ້ໄຂບັນຫານີ້ ແລະ ຕ້ອງການຄວາມຊ່ວຍເຫຼືອຈາກຊຸມຊົນ.

  • Needs: confirmation/more info: ບັກຕ້ອງການການຢືນຢັນ ແລະ / ຫຼື ລາຍລະອຽດເພີ່ມເຕີມໂດຍຜູ້ໃຊ້ທີ່ໄດ້ຮັບຜົນກະທົບ.

  • Needs: feedback from author: ໃຊ້ເພື່ອໝາຍ merge request ທີ່ຕ້ອງການຄຳຕິຊົມຈາກຜູ້ຂຽນຫຼັງຈາກການກວດສອບ. ນີ້ແຕກຕ່າງຈາກ Needs: confirmation/more info ເຊິ່ງມີຈຸດປະສົງທີ່ຈະໃຊ້ກັບບັນຫາ.

  • Needs: discussion: ມັນບໍ່ຈະແຈ້ງວ່າຈະແກ້ໄຂບັນຫານີ້ແນວໃດ ແລະ ຕ້ອງການການສົນທະນາເພີ່ມເຕີມ.

  • Needs: rebase: merge request ນີ້ຕ້ອງໄດ້ rebase, ແຕ່ຜູ້ບຳລຸງຮັກສາບໍ່ມີສິດໃນການ push ໄປຍັງສາຂາຕົ້ນທາງ.

• Severity: ບັນຫາມີຄວາມຮຸນແຮງເທົ່າໃດ.

  • Severity: critical: ບັນຫານີ້ຮຸນແຮງຫຼາຍ ແລະ ຄວນຢຸດຢັ້ງການປ່ອຍເວີຊັນ (ກຳນົດໂດຍ milestone ຂອງມັນ).

• Area: ບັນຫານີ້ກ່ຽວຂ້ອງກັບພື້ນທີ່ໃດໜຶ່ງຂອງ Ubuntu Touch (ເຊັ່ນ: HAL, middleware, UI). ປ້າຍກຳກັບຂອງຄຳນຳໜ້ານີ້ສາມາດສ້າງຂຶ້ນໄດ້ຕາມຄວາມເໝາະສົມ.

• Topic: ບັນຫານີ້ກ່ຽວຂ້ອງກັບຫົວຂໍ້ທີ່ສົນໃຈໃດໜຶ່ງ (ເຊັ່ນ: VoLTE, contact backend migration). ປ້າຍກຳກັບຂອງຄຳນຳໜ້ານີ້ກໍສາມາດສ້າງຂຶ້ນໄດ້ຕາມຄວາມເໝາະສົມ.

• Resolution: ໃຊ້ເມື່ອບັນຫາຖືກປິດດ້ວຍເຫດຜົນອື່ນນອກເໜືອຈາກບັນຫາຖືກແກ້ໄຂແລ້ວ.

  • Resolution: unable to confirm: ພວກເຮົາບໍ່ສາມາດເຮັດໃຫ້ບັນຫາເກີດຂຶ້ນຊ້ຳໄດ້ ແລະ ຂໍ້ມູນທີ່ໃຫ້ມານັ້ນບໍ່ພຽງພໍ.

  • Resolution: not our bug: ບັນຫານີ້ບໍ່ແມ່ນບັນຫາໃນ Ubuntu Touch, ແຕ່ເປັນບັນຫາໃນຊອບແວຂອງບຸກຄົນທີສາມທີ່ຜູ້ໃຊ້ຕິດຕັ້ງ.

  • Resolution: won't fix: ບັກທີ່ບໍ່ສົມເຫດສົມຜົນທີ່ຈະແກ້ໄຂ, ເນື່ອງຈາກວ່າມັນອາດຈະແກ້ໄຂຕົວມັນເອງ, ເປັນວຽກຫຼາຍເກີນໄປ, ບໍ່ສາມາດແກ້ໄຂໄດ້, ຫຼື ອົງປະກອບພື້ນຖານກຳລັງຈະປ່ຽນແປງໃນໄວໆນີ້.

  • Resolution: work as intended: ພຶດຕິກຳທີ່ອະທິບາຍໃນບັນຫາ ແມ່ນພຶດຕິກຳທີ່ຕັ້ງໃຈໃຫ້ເປັນຂອງຊອບແວ.

• Backport to: <branch name>: ຖືກໃຊ້ໂດຍລະບົບອັດຕະໂນມັດເພື່ອ backport MR ໄປຍັງສາຂา stable release ໂດຍອັດຕະໂນມັດ.

• ປ້າຍກຳກັບເບັດຕະເລັດ

  • Good first issue: ລາຍງານມີຄຳແນະນຳ ຫຼື ຄຳໃບ້ທີ່ຈຳເປັນໃນການແກ້ໄຂມັນ. ມັນເປັນບ່ອນທີ່ດີເລີດສຳລັບມືໃໝ່ທີ່ຈະຮຽນຮູ້ກ່ຽວກັບໂຄງການໂດຍການແກ້ໄຂບັນຫາຕົວຈິງ.

  • Hotfix: MR/issue ນີ້ຈັດຢູ່ໃນປະເພດທີ່ຈະຖືກລວມເຂົ້າ/ແກ້ໄຂ ເປັນສ່ວນໜຶ່ງຂອງການປ່ອຍ point release ຂອງ Ubuntu Touch

Note

ຖ້າ repository ທີ່ຕິດຕາມບັນຫາຢູ່ໃນທ້ອງຖິ່ນກຳນົດປ້າຍກຳກັບຂອງຕົນເອງ, ພວກມັນຄວນຈະຖືກບັນທຶກໄວ້ໃນ README.md.

Status

Status field is used to indicate the progress of the issue. We've defined the following statuses:

• New: This is the status for a newly-opened issue. This indicates that this issue is untriaged; Developers and triagers are encouraged to triage issues, assigns kind and other labels, decide whether this issue warrants a milestone, etc. Alternatively, if an issue is a work item, a tracking issue, or something similar filed by developers, this status can be skipped.

• Ready to be worked on: Indicates that this issue is triaged and can be worked on.

Note

This status replaces default "To do" status.

• Blocked: Indicates that something else has to be solved outside of this issue before this issue can progress.

• In progress: Indicates that a developer is actively working on the issue. The issue should be assigned to that developer.

• Has MR: A non-draft MR exists that will fix this issue.

• Done: The issue has been fixed in the main branch.

• Duplicate: The issue is a duplicate. GitLab sets this status automatically when the issue is marked as a duplicate.

• Won't do: The issue is closed for other reason than the issue being fixed. It should have "Resolution: *" labels to explain the reason (see above).

ຈຸດໝາຍສຳຄັນ (Milestones)

Milestones ຖືກໃຊ້ເພື່ອກຳນົດວ່າບັນຫາໃດນຶ່ງມີເປົ້າໝາຍຢູ່ທີ່ການປ່ອຍເວີຊັນໃດ. ໃນເວລາໃດໜຶ່ງ, ຈະມີ milestones ເປີດຢູ່ສູງສຸດ 3 ອັນ:

• Milestone ສຳລັບການປ່ອຍເວີຊັນ stable ທີ່ກຳລັງຈະມາເຖິງ ເຊັ່ນ 'Ubuntu Touch 24.04-1.1'.

• Milestone ສຳລັບການປ່ອຍເວີຊັນ major ທີ່ກຳລັງພັດທະນາ ເຊັ່ນ 'Ubuntu Touch 24.04-2.0'.

• ເມື່ອການປ່ອຍເວີຊັນທີ່ກຳລັງພັດທະນາເຂົ້າສູ່ໄລຍະເຮັດໃຫ້ສະຖຽນ, Milestone ສຳລັບການປ່ອຍເວີຊັນ major ຕໍ່ໄປ (ເຊັ່ນ 'Ubuntu Touch 24.04-3.0') ກໍສາມາດຖືກສ້າງຂຶ້ນໄດ້.

ນັກພັດທະນາຖືກຊຸກຍູ້ໃຫ້ຫຼີກລ່ຽງການມອບໝາຍບັນຫາຫຼາຍເກີນໄປໃຫ້ກັບ milestone; milestone ທີ່ລົ້ນເກີນໄປຈະເຮັດໃຫ້ milestone ນັ້ນບໍ່ມີປະໂຫຍດເທົ່າທີ່ຄວນ ໃນການຕິດຕາມຄວາມຄືບໜ້າຂອງການປ່ອຍເວີຊັນ.

ຜູ້ໄດ້ຮັບມອບໝາຍ

ເພື່ອໃຫ້ມີຄວາມໂປ່ງໃສວ່າໃຜກຳລັງເຮັດວຽກກັບບັນຫາໃດໜຶ່ງ, ນັກພັດທະນາຄວນຖືກມອບໝາຍໃຫ້. ສິ່ງນີ້ຍັງອະນຸຍາດໃຫ້ໃຊ້ການກັ່ນຕອງທົ່ວໂລກຂອງ GitHub ເປັນປະເພດຂອງລາຍການ TODO ໄດ້.

ນັກພັດທະນາຖືກຊຸກຍູ້ໃຫ້ຮັກສາລາຍການຂອງເຂົາເຈົ້າໃຫ້ສັ້ນ ແລະ ອັບເດດສະຖານະຂອງບັນຫາຂອງເຂົາເຈົ້າ.

ກະດານບັນຫາ GitLab

We use GitLab's issue boards to visualize progress of issues in each milestone. The boards are kanban boards, where each column corresponds to each defined status (new, ready to be worked on, blocked, in progress, has MR, done, duplicate, won't do).

GitLab epic

ພວກເຮົາໃຊ້ epics ຂອງ GitLab ເພື່ອໝາຍເຖິງຫົວຂໍ້ທີ່ອາດຈະກວມເອົາ milestones/releases ດຽວ ຫຼື ຫຼາຍອັນ. ສິ່ງນີ້ຊ່ວຍຈັດຕັ້ງເປົ້າໝາຍໄລຍະຍາວບາງຢ່າງທີ່ໃຫຍ່ເກີນໄປທີ່ຈະປະຕິບັດໃນຄັ້ງດຽວ.

ປ້າຍກຳກັບ, milestone ແລະ ອື່ນໆ ຖືກນຳໃຊ້ແນວໃດ?

ໃຫ້ຄິດວ່າປ້າຍກຳກັບ, milestone, ແລະ ຊ່ອງຂໍ້ມູນອື່ນໆ ເປັນເຄື່ອງມືທີ່ຄົນເຮົາສາມາດໃຊ້ເພື່ອສື່ສານຢ່າງມີປະສິດທິພາບກັບຜູ້ລາຍງານ, ນັກພັດທະນາຄົນອື່ນໆ, ແລະ ຝ່າຍທີ່ສົນໃຈ. ພວກມັນສາມາດຖືກນຳໃຊ້ໃນສອງສາມວິທີ:

• ເນື່ອງຈາກຊ່ອງຂໍ້ມູນເຫຼົ່ານັ້ນສະແດງຢູ່ໃນລາຍການບັນຫາ, ມັນສາມາດໃຫ້ຂໍ້ມູນໂດຍຫຍໍ້ກ່ຽວກັບບັນຫາ, ຊ່ວຍໃຫ້ນັກພັດທະນາເຂົ້າໃຈບັນຫາໄດ້ຢ່າງໄວວາ. ຕົວຢ່າງເຊັ່ນ, ນັກພັດທະນາສາມາດເບິ່ງບັນຫາໃນລາຍການ, ສັງເກດເຫັນວ່າບັນຫາມີປ້າຍກຳກັບ "needs discussion", ແລະ ຕັດສິນໃຈເຂົ້າໄປໃຫ້ຄຳເຫັນ.

• ຊ່ອງຂໍ້ມູນສາມາດຖືກໃຊ້ເພື່ອກັ່ນຕອງສະເພາະບັນຫາທີ່ສົນໃຈ. ຕົວຢ່າງເຊັ່ນ, ສະມາຊິກຊຸມຊົນທີ່ຕ້ອງການປະກອບສ່ວນໃນການຢືນຢັນບັນຫາ ສາມາດກັ່ນຕອງສະເພາະບັນຫາທີ່ມີປ້າຍກຳກັບ "needs confirmation" ແລະ ເລີ່ມເຂົ້າໄປຊ່ວຍໄດ້.

• ຊ່ອງຂໍ້ມູນຍັງສາມາດຖືກໃຊ້ເພື່ອກັ່ນຕອງບັນຫາທີ່ບໍ່ສົນໃຈອອກໄປ. ຕົວຢ່າງເຊັ່ນ, ເມື່ອນັກພັດທະນາຕ້ອງການຊອກຫາບັນຫາທີ່ຈະເຮັດວຽກ, ເຂົາເຈົ້າອາດຈະຕ້ອງການກັ່ນຕອງປ້າຍກຳກັບ "Kind: process" ອອກ (ໃຊ້ສຳລັບ ເຊັ່ນ: ການຕິດຕາມບັນຫາສຳລັບການປ່ອຍເວີຊັນ).

ເນື່ອງຈາກພວກເຮົາບໍ່ມີຄົນທີ່ຈະມາຄັດແຍກບັນຫາ ແລະ ຕັ້ງປ້າຍກຳກັບເຫຼົ່ານັ້ນໂດຍສະເພາະ, ນັກພັດທະນາຈຶ່ງຖືກຊຸກຍູ້ໃຫ້ຕັ້ງຄ່າຊ່ອງຂໍ້ມູນທັງໝົດເຫຼົ່ານັ້ນໃນຂະນະທີ່ພວກເຂົາເຮັດວຽກກັບບັນຫາ. ສິ່ງນີ້ຈະຊ່ວຍສື່ສານວ່າໄດ້ເຮັດຫຍັງແດ່ກັບບັນຫານັ້ນ, ແລະ ຍັງຊ່ວຍສະຫຼຸບບັນຫາເພື່ອຄວາມເຂົ້າໃຈທີ່ໄວຂຶ້ນ.