ການຈັດຕັ້ງຂະບວນການເຮັດວຽກຂອງ Docs

ທີມງານເອກະສານ Fedora <https://discussion.fedoraproject.org/tag/docs-team> Last review: 2023-04-24
ຄູ່ມືນີ້ແນະນຳສະມາຊິກ Docs ແລະ ຜູ້ທີ່ສົນໃຈຢາກຊ່ວຍເຫຼືອ ກ່ຽວກັບລາຍຊື່ຂອງປ້າຍກຳກັບ ແລະ ໝວດໝູ່ທີ່ກ່ຽວຂ້ອງກັບ ບັນຫາ (Issues) ແລະ ຄຳຮ້ອງຂໍຮວມການປ່ຽນແປງ (Merge Requests) ໃນຄັງເກັບຂໍ້ມູນ GitLab Docs.

ທີມງານ Fedora Docs ໄດ້ຕົກລົງເຫັນດີກ່ຽວກັບການຈັດຕັ້ງຂະບວນການເຮັດວຽກ, ເຊິ່ງລວມສູນຢູ່ໃນສອງໜ້າຫຼັກຄື:

ແຜງຄວບຄຸມ GitLab

ລາຍການຄຳຮ້ອງຂໍຮວມການປ່ຽນແປງທີ່ເປີດຢູ່ຂອງ GitLab

ກະດານບັນຫາ ແລະ ປ້າຍກຳກັບ

ມີສີ່ປ້າຍກຳກັບທີ່ໃຊ້ຈັດແບ່ງສະຖານະຂອງບັດບັນຫາ (issue ticket).

  • Triage (ການກວດສອບເບື້ອງຕົ້ນ): ບັນຫາຖືກຕິດປ້າຍກຳກັບແລ້ວ, ແຕ່ຍັງບໍ່ທັນມີໃຜຖືກມອບໝາຍເທື່ອ. ທ່ານຕ້ອງການຮັບຜິດຊອບບໍ່? ສາມາດມອບໝາຍໃຫ້ຕົນເອງໄດ້ເລີຍ ແລະ ປ່ຽນສະຖານະບັນຫາເປັນ “In progress”.

  • In progress (ກຳລັງດຳເນີນການ): ມີຄົນຖືກມອບໝາຍໃຫ້ຈັດການບັນຫານີ້ແລ້ວ ແລະ ກຳລັງຢູ່ໃນຂັ້ນຕອນການເຮັດວຽກ.

  • Support needed (ຕ້ອງການຄວາມຊ່ວຍເຫຼືອ): ມີບາງຢ່າງຖືກເຮັດໄປແລ້ວ, ແຕ່ຕ້ອງມີຄົນມາຊ່ວຍຜູ້ທີ່ຖືກມອບໝາຍຢູ່ກ່ອນ ຫຼື ຮັບຊ່ວງຕໍ່ການມອບໝາຍທັງໝົດ.

  • Approval needed (ຕ້ອງການການອະນຸມັດ): ນີ້ແມ່ນການປ່ຽນແປງໃຫຍ່ ແລະ ຕ້ອງການການອະນຸມັດຈາກບຸກຄົນອື່ນທີ່ບໍ່ແມ່ນຜູ້ຮັບຜິດຊອບວຽກນັ້ນ. ສາມາດເຂົ້າມາກວດສອບ ແລະ ອະນຸມັດ ເພື່ອໃຫ້ຜູ້ຮັບຜິດຊອບສາມາດຮວມວຽກ (merge) ໄດ້ໃນພາຍຫຼັງ.

"Open Merge Requests" (ຄຳຮ້ອງຂໍຮວມການປ່ຽນແປງທີ່ເປີດຢູ່) ຈະບໍ່ມີແຜງຄວບຄຸມ. ທ່ານສາມາດເຫັນປ້າຍກຳກັບທັງໝົດຂອງ MR ທີ່ເປີດຢູ່ໄດ້ທັນທີເມື່ອເປີດໜ້າ "Open Merge Requests".

ນອກຈາກນັ້ນ, ຍັງມີອີກສາມປ້າຍກຳກັບທີ່ໃຊ້ຈັດແບ່ງປະເພດຂອງບັດບັນຫາ.

  • Major change (ການປ່ຽນແປງໃຫຍ່): ນີ້ແມ່ນການປ່ຽນແປງທີ່ສຳຄັນໃນໜ້າ Docs. ມັນຕ້ອງມີຄຳຮ້ອງຂໍຮວມການປ່ຽນແປງ (MR) ແລະ ຕ້ອງໄດ້ຮັບການອະນຸມັດຈາກບຸກຄົນອື່ນກ່ອນທີ່ຈະຮວມໄດ້.

  • Minor change (ການປ່ຽນແປງເລັກນ້ອຍ): ນີ້ແມ່ນການປ່ຽນແປງພຽງເລັກນ້ອຍໃນໜ້າ Docs. ມັນບໍ່ຈຳເປັນຕ້ອງມີການອະນຸມັດ ແລະ ສາມາດ commit ໂດຍກົງໄດ້ເລີຍ (ບໍ່ຈຳເປັນຕ້ອງສ້າງ MR).

  • Internal task (ວຽກພາຍໃນ): ນີ້ແມ່ນວຽກພາຍໃນຂອງ Fedora Docs ທີ່ບໍ່ແມ່ນການປ່ຽນແປງ, ການແກ້ໄຂ ຫຼື ການອັບເດດເນື້ອຫາ Docs. (ຕົວຢ່າງ: ການກຽມກອງປະຊຸມ ຫຼື ການປະເມີນຜົນແບບສຳຫຼວດ).

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

ນອກຈາກປ້າຍສະຖານະ ແລະ ປ້າຍປະເພດແລ້ວ, ບັດບັນຫາ ແລະ MR ຍັງສາມາດຕິດປ້າຍ "good first issue" (ບັນຫາທີ່ເໝາະສຳລັບຜູ້ເລີ່ມຕົ້ນ). ທ່ານຢາກຊ່ວຍເຫຼືອ Fedora Docs ບໍ່? ນີ້ແມ່ນໂອກາດຂອງທ່ານ. ສາມາດສະແດງຄວາມຄິດເຫັນໃນບັນຫາເຫຼົ່ານີ້ວ່າທ່ານຕ້ອງການຮັບຜິດຊອບວຽກດັ່ງກ່າວ.

ນອກຈາກນັ້ນ, ຍັງມີປ້າຍກຳກັບເພີ່ມເຕີມສຳລັບ MR ທີ່ອາດຈະສົ່ງຜົນກະທົບຕໍ່ຫຼາຍກວ່າໜຶ່ງສາຂາ (branch), ເຊິ່ງໝາຍຄວາມວ່າພວກມັນຕ້ອງການການຮວມວຽກຕໍ່ເນື່ອງ ຫຼື ການ cherry-pick. ປ້າຍ multiple MR likely ຊ່ວຍໃຫ້ແນ່ໃຈວ່າສາຂາທີ່ໄດ້ຮັບຜົນກະທົບທັງໝົດຖືກລະບຸ ແລະ ອັບເດດ, ແລະ ຈະບໍ່ມີການຮວມ MR ໂດຍບໍ່ໄດ້ຜ່ານການກວດສອບ.

ວິທີການສ້າງບັດບັນຫາ ແລະ ຄຳຮ້ອງຂໍຮວມການປ່ຽນແປງ

ມີສອງວິທີໃນການສ້າງບັດບັນຫາ ແລະ MR: ຄືຈາກພາຍນອກ ແລະ ຈາກພາຍໃນ.

  • ຫາກຖືກສ້າງຈາກພາຍນອກ, ແມ່ນສ້າງໂດຍບຸກຄົນທີ່ຢູ່ນອກທີມງານ Fedora Docs ຜ່ານ GitLab ຫຼື ໃຊ້ປຸ່ມ "Report an issue" (ສ້າງບັດບັນຫາ) / "Edit this page" (ສ້າງ MR) ຢູ່ເທິງໜ້າເອກະສານ Fedora Docs (ປຸ່ມຢູ່ມຸມຂວາເທິງ). ບັດບັນຫາຈະປະກົດຢູ່ໃນລາຍການ "Open" ໃນແຜງຄວບຄຸມໂດຍບໍ່ມີປ້າຍກຳກັບ. ສ່ວນ MR ຈະປະກົດຢູ່ໃນໜ້າ Open Merge Requests ໂດຍບໍ່ມີປ້າຍກຳກັບເຊັ່ນກັນ.

  • ຫາກຖືກສ້າງຈາກພາຍໃນ, ສະມາຊິກທີມງານ Docs ເປັນຜູ້ເປີດເອງ. ໂດຍປົກກະຕິ, ສະມາຊິກຜູ້ນັ້ນຈະຕິດ ປ້າຍປະເພດ ແລະ ຍ້າຍບັດບັນຫາໄປໄວ້ໃນລາຍການ "Triage" ເພື່ອລໍຖ້າຄົນມາຮັບຜິດຊອບ. ສຳລັບ MR ກໍ່ເຊັ່ນດຽວກັນ, ເຖິງແມ່ນວ່າຈະບໍ່ມີລາຍການແບບລາກວາງ (drag & drop) ແຕ່ກໍ່ຕ້ອງຕິດປ້າຍ "Triage" ດ້ວຍຕົນເອງ. ອີກທາງເລືອກໜຶ່ງ, ຜູ້ສ້າງສາມາດມອບໝາຍຜູ້ຮັບຜິດຊອບໄດ້ທັນທີ ແລະ ຍ້າຍໄປທີ່ລາຍການ "In progress" (ເຊິ່ງຈະເປັນການຕິດປ້າຍ "In progress" ໂດຍອັດຕະໂນມັດ) ຫຼື ຕິດປ້າຍດ້ວຍຕົນເອງຫາກເປັນ MR.

ໃນແຜງຄວບຄຸມ, ບັດບັນຫາສາມາດຍ້າຍໄປມາລະຫວ່າງລາຍການຕ່າງໆໄດ້ດ້ວຍການລາກວາງ, ເຊິ່ງປ້າຍສະຖານະຈະປ່ຽນໄປຕາມນັ້ນ. ດັ່ງນັ້ນ, ມີພຽງແຕ່ປ້າຍກຳກັບປະເພດຄົງທີ່ເທົ່ານັ້ນທີ່ຕ້ອງຕັ້ງດ້ວຍຕົນເອງໃນຕອນເລີ່ມຕົ້ນ. ສິ່ງນີ້ບໍ່ລວມເຖິງ MR ໃນໜ້າ Open Merge Request. ເມື່ອສ້າງບັດບັນຫາໃນແຜງຄວບຄຸມ, ທ່ານຈະຖືກຖາມວ່າຕ້ອງການສ້າງໄວ້ບ່ອນໃດ. ຫາກບໍ່ແນ່ໃຈ, ໃຫ້ເລືອກ Fedora / Fedora Docs / Docs Website / Fedora Docs pages. ທ່ານຈະເຫັນສິ່ງນີ້ໃນລາຍການ "Projects" ຕອນທີ່ຄລິກສ້າງບັນຫາ, ເຊິ່ງຕໍ່ມາຈະສະແດງເປັນ "fedora/docs/docs-website/pages".

ຂະບວນການເຮັດວຽກ

ການປ່ຽນແປງເລັກນ້ອຍ

ຫາກດຳເນີນການໂດຍສະມາຊິກ Docs ແລະ ເປັນ "ການປ່ຽນແປງເລັກນ້ອຍ" ທີ່ຊັດເຈນ, ສາມາດເຮັດການ commit ໄດ້ໂດຍກົງ ໂດຍບໍ່ຕ້ອງມີ MR ຫຼື ບັດບັນຫາ. ຫາກຄົນພາຍນອກສ້າງ MR ທີ່ເປັນການປ່ຽນແປງເລັກນ້ອຍ, ສະມາຊິກ Docs ຈະຮວມວຽກທັນທີຫຼັງຈາກກວດສອບແລ້ວ. ແຕ່ຕ້ອງກວດເບິ່ງສະເໝີວ່າການປ່ຽນແປງນັ້ນມີຜົນຕໍ່ຫຼາຍສາຂາ (branch) ຫຼື ບໍ່.

ຫາກມີຫຼາຍສາຂາໄດ້ຮັບຜົນກະທົບ, ທ່ານຈະສາມາດ merge/commit ໂດຍກົງໄດ້ກໍ່ຕໍ່ເມື່ອທ່ານເຮັດການ commit ແລະ cherry-pick ໄປຍັງທຸກສາຂາທີ່ກ່ຽວຂ້ອງພ້ອມກັນໃນບາດດຽວ. ຫາກບໍ່ແນ່ໃຈ, ໃຫ້ຕິດປ້າຍ "multiple MR likely" ເພີ່ມຕື່ມ ແລະ ເປີດ MR ຄ້າງໄວ້ເພື່ອປຶກສາຫາລື.

ອີງຕາມການປຶກສາຫາລື, ປ້າຍ "multiple MR likely" ຈະຖືກຖອນອອກຫາກບໍ່ມີສາຂາອື່ນກ່ຽວຂ້ອງ ແລະ ຈາກນັ້ນຈຶ່ງເຮັດການ merge ໄດ້. ແຕ່ຫາກມີສາຂາອື່ນກ່ຽວຂ້ອງ, ຕ້ອງເຮັດ cherry-pick ໄປຍັງສາຂາເຫຼົ່ານັ້ນທັນທີພ້ອມກັບການ merge. ເປົ້າໝາຍແມ່ນເພື່ອບໍ່ໃຫ້ MR ຫາຍໄປຈາກໜ້າ Open Merge Request ຈົນກວ່າທຸກສາຂາຈະຖືກອັບເດດຄົບຖ້ວນ.

ຖ້າຫາກວ່າການສົນທະນາເກີດຂຶ້ນພາຍໃນປີ້ບັນຫາ (ໂດຍການໃຊ້ commit ແທນ Merge Request, ຫຼື ໃຊ້ຫຼາຍ Merge Request ທີ່ຖືກໂຮມເຂົ້າກັນພາຍໃນປີ້ດຽວ) ແລະ ບໍ່ແມ່ນພາຍໃນ Merge Request ດຽວ, ການ commit ແລະ ການ cherry-pick ແມ່ນສາມາດເຮັດແຍກກັນໄດ້.

ຂະບວນການເຮັດວຽກສຳລັບ ການປ່ຽນແປງເລັກນ້ອຍ ມີດັ່ງນີ້:

  1. ຫາກເປັນພຽງການ commit ທີ່ເປັນການປ່ຽນແປງເລັກນ້ອຍ, ກໍ່ໃຫ້ເຮັດໄດ້ເລີຍ. ຫາກທ່ານຮູ້ວ່າສາຂາໃດແດ່ທີ່ໄດ້ຮັບຜົນກະທົບ ແລະ ສາມາດເຮັດ cherry-pick ໄດ້ທັງໝົດ, ກໍ່ໃຫ້ດຳເນີນການຕໍ່. ແຕ່ຫາກທ່ານບໍ່ມີເວລາພຽງພໍທີ່ຈະເຮັດໃຫ້ສຳເລັດ, ໃຫ້ປະຕິບັດດັ່ງນີ້:

  2. ກຳນົດປະເພດ ແລະ ຕິດປ້າຍກຳກັບປະເພດທີ່ກ່ຽວຂ້ອງ ("ການປ່ຽນແປງເລັກນ້ອຍ", "ການປ່ຽນແປງຄັ້ງໃຫຍ່", "ວຽກງານພາຍໃນ". ໃນນີ້ແມ່ນ: ການປ່ຽນແປງເລັກນ້ອຍ) ໃຫ້ກັບ Merge Request ທີ່ມີຢູ່ ຫຼື ໃບແຈ້ງບັນຫາທີ່ມີຢູ່, ຫຼື ຖ້າຍັງບໍ່ມີ: ໃຫ້ສ້າງຂຶ້ນມາໃໝ່! ຖ້າທ່ານບໍ່ແນ່ໃຈວ່າຄວນສ້າງຫຍັງ, ໃຫ້ສ້າງໃບແຈ້ງບັນຫາ.

  3. ຍ້າຍບັນຫາໃໝ່ໄປທີ່ລາຍການ "Triage" (ເຊິ່ງຕາມທີ່ໄດ້ອະທິບາຍໄວ້ຂ້າງເທິງ, ມັນຈະກຳນົດປ້າຍກຳກັບສະຖານະ "Triage" ໃຫ້ໂດຍອັດຕະໂນມັດ), ຫຼື ເພີ່ມປ້າຍກຳກັບ "Triage" ດ້ວຍຕົນເອງ ຫາກມັນແມ່ນການຮ້ອງຂໍການລວມ (Merge Request).

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

  5. ມີບາງທາງເລືອກດັ່ງນີ້.

    1. ຜູ້ຮັບຜິດຊອບເຮັດວຽກໃຫ້ສຳເລັດ ແລະ ຍ້າຍສະຖານະຈາກປັດຈຸບັນໄປເປັນ "Closed" (ປິດ). ຫາກມີຫຼາຍສາຂາຕ້ອງປ່ຽນແປງ ແລະ ຈັດການພາຍໃນ MR ດຽວ, ທຸກສາຂາຕ້ອງຖືກປ່ຽນແປງພ້ອມກັນ.

    2. ອີກທາງເລືອກໜຶ່ງ, ຫາກຜູ້ຮັບຜິດຊອບຕ້ອງການຄວາມຊ່ວຍເຫຼືອ ຫຼື ຄວາມຄິດເຫັນເພີ່ມເຕີມ: ໃຫ້ຍ້າຍບັດໄປທີ່ "Support needed". ເມື່ອໄດ້ຜູ້ຊ່ວຍແລ້ວ, ໃຫ້ຍ້າຍກັບມາທີ່ "In progress". ໃຊ້ສະຖານະນີ້ເພື່ອຊຸກຍູ້ໃຫ້ເກີດການສົນທະນາ. ເມື່ອວຽກສຳເລັດແລ້ວ ຈຶ່ງຍ້າຍໄປ "Closed". ສະມາຊິກສາມາດມອບໝາຍວຽກໃຫ້ຜູ້ອື່ນໄດ້ຫາກຜູ້ນັ້ນມີປະສົບການ ຫຼື ມີເວລາຫຼາຍກວ່າ.

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

ການປ່ຽນແປງໃຫຍ່

"Multiple MR likely" ສາມາດໃຊ້ກັບ "ການປ່ຽນແປງໃຫຍ່" ໄດ້, ເຊິ່ງຕ້ອງມີບັດບັນຫາ ຫຼື MR.

ຂະບວນການເຮັດວຽກສຳລັບ ການປ່ຽນແປງໃຫຍ່ ມີດັ່ງນີ້:

  1. ກຳນົດປະເພດ ແລະ ປ່ຽນປ້າຍກຳກັບ MR ຫຼື ບັດບັນຫາເປັນ Major change.

  2. ຍ້າຍບັນຫາໃໝ່ໄປທີ່ລາຍການ "Triage", ຫຼື ຕິດປ້າຍ "Triage" ດ້ວຍຕົນເອງຫາກເປັນ MR.

  3. ໃບແຈ້ງບັນຫາ ຫຼື ຄຳຮ້ອງຂໍລວມ (Merge Request) ສາມາດມອບໝາຍຄືນໃໝ່ໃຫ້ສະມາຊິກຄົນອື່ນໄດ້. ເມື່ອມີຜູ້ຖືກມອບໝາຍແລ້ວ, ໃບແຈ້ງນັ້ນຈະປ່ຽນສະຖານະເປັນ "ກຳລັງດຳເນີນການ" (ການປ່ຽນເປັນ "ກຳລັງດຳເນີນການ" ແມ່ນຕ້ອງເຮັດດ້ວຍຕົນເອງສຳລັບຄຳຮ້ອງຂໍລວມ).

  4. ມີບາງທາງເລືອກດັ່ງນີ້.

    1. ເມື່ອຜູ້ຮັບຜິດຊອບເຮັດວຽກສຳເລັດແລ້ວ, ໃຫ້ຍ້າຍສະຖານະໄປເປັນ "Approval needed" (ຕ້ອງການການອະນຸມັດ).

    2. ຫາກຕ້ອງການຄວາມຊ່ວຍເຫຼືອ, ໃຫ້ຍ້າຍໄປ "Support needed". ເມື່ອໄດ້ຜູ້ຊ່ວຍແລ້ວຈຶ່ງຍ້າຍກັບມາ "In progress". ເມື່ອທຸກຢ່າງຮຽບຮ້ອຍ, ໃຫ້ຍ້າຍໄປ "Approval needed". ສາມາດປ່ຽນຜູ້ຮັບຜິດຊອບໃຫ້ເປັນຜູ້ທີ່ມີປະສົບການຫຼາຍກວ່າໃນຂັ້ນຕອນຕໍ່ໄປໄດ້.

ຫາກມີຫຼາຍສາຂາໄດ້ຮັບຜົນກະທົບ, ໃຫ້ຕິດປ້າຍ "multiple MR likely". ຕ້ອງລະບຸທຸກສາຂາທີ່ກ່ຽວຂ້ອງໃນການສົນທະນາ. ໃນຕອນທ້າຍ, MR ຈະຕ້ອງຖືກສົ່ງຕໍ່ໄປຍັງທຸກສາຂາຜ່ານ cherry-picks ໂດຍຕ້ອງເຮັດທັງໝົດພ້ອມກັນ.

ຫ້າມໃຊ້ສາຂາ "stg" ສຳລັບເນື້ອຫາ. ໃຫ້ເຮັດວຽກໃນ fork ແລະ branch ທີ່ແຍກອອກມາສະເພາະສຳລັບບັນຫານັ້ນໆ.

ວຽກພາຍໃນ

ວຽກພາຍໃນແມ່ນມີຄວາມຢືດຢຸ່ນ. ໂດຍເລີ່ມຈາກ "Open" ຫຼື "Triage" ແລະ ຍ້າຍຜ່ານຂັ້ນຕອນຕ່າງໆຈົນເຖິງ "Closed".

ບົດບາດຂອງການປະຊຸມປະຈຳອາທິດ

ການປະຊຸມ Docs ປະຈຳອາທິດຊ່ວຍລະບຸ ແລະ ແກ້ໄຂບັນຫາທີ່ບໍ່ປົກກະຕິ. ໃນຂະນະທີ່ການຈັດຕັ້ງຂະບວນການເຮັດວຽກແມ່ນມີໄວ້ເພື່ອຈັດການວຽກງານປະຈຳວັນທີ່ເປັນມາດຕະຖານຂອງ Fedora Docs.

ລາຍການບັນຫາ ແລະ ຄຳຮ້ອງຂໍລວມໂຄດໃນປັດຈຸບັນຂອງການຈັດຕັ້ງຂະບວນການເຮັດວຽກ ສາມາດກາຍເປັນຫົວຂໍ້ສົນທະນາປະຈຳໃນການປະຊຸມປະຈຳອາທິດ.

  • ກວດເບິ່ງວ່າມີສິ່ງໃດທີ່ເກີດຂຶ້ນນອກເໜືອແຜນການໃນຂະບວນການເຮັດວຽກທີ່ຕ້ອງໄດ້ປຶກສາຫາລືກັນຫຼືບໍ່.

  • ລະບຸ ແລະ ມອບໝາຍບັດບັນຫາ ແລະ MR ທີ່ຍັງບໍ່ມີຜູ້ຮັບຜິດຊອບເກີນສອງອາທິດ, ແລະ ປຶກສາຫາລືກ່ຽວກັບລາຍການທີ່ຍັງເປີດຄ້າງໄວ້ເກີນໜຶ່ງເດືອນຫຼັງຈາກຖືກມອບໝາຍ.

  • ໃຊ້ປ້າຍກຳກັບ Meeting ສຳລັບບັນຫາ ຫຼື MR ທີ່ຈະນຳມາປຶກສາຫາລືໃນການປະຊຸມ Docs.

Want to help? Learn how to contribute to Fedora Docs ›