ການປ່ຽນແປງໂຄ້ດ

ໜ້ານີ້ຈະຊ່ວຍໃຫ້ການປ່ຽນແປງໂຄ້ດຂອງທ່ານຖືກຮວມ (merge) ເຂົ້າສູ່ Ubuntu Touch. ພວກເຮົາມີຂະບວນການກວດສອບໂຄ້ດເພື່ອຄວາມປອດໄພ.

ຂໍ້ຕົກລົງເບື້ອງຕົ້ນ

This page does not include information about how to develop applications or changes to Ubuntu Touch. To learn how to develop Ubuntu Touch components, see the ການພັດທະນາຊອບແວລະບົບ section. To learn how to develop applications, see the ການພັດທະນາແອັບ or ແອັບຯທີ່ຕິດຕັ້ງໄວ້ລ່ວງໜ້າ sections.

ສົມມຸດວ່າທ່ານຮູ້ຈັກການໃຊ້ Git, ການ fork ແລະ ການສ້າງ Pull Request (PR) ຢູ່ແລ້ວ.

ຄຳນິຍາມ

ເນື່ອງຈາກພວກເຮົານຳໃຊ້ທັງ GitHub ແລະ GitLab, ພວກເຮົາອາດຈະໃຊ້ບາງຄຳສັບແທນກັນໄດ້.

ຊຸດການປ່ຽນແປງ (changeset)

ໝາຍເຖິງ GitHub Pull Request (PR) ຫຼື GitLab Merge Request (MR).

ລາຍງານບັນຫາ (issue report)

ໝາຍເຖິງ Issue ໃນ GitHub ຫຼື GitLab.

ເຫດຜົນ

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

ພວກເຮົາຕ້ອງການໃຫ້ແນ່ໃຈວ່າການປ່ຽນແປງນັ້ນ:

• ບັນລຸເປົ້າໝາຍ ເຊັ່ນ: ເພີ່ມຟີເຈີ ຫຼື ແກ້ບັກໄດ້ແທ້

• ບໍ່ເຮັດໃຫ້ເກີດພຶດຕິກຳທີ່ບໍ່ຄາດຄິດ

• ເຮັດໃຫ້ງ່າຍຕໍ່ການພັດທະນາຕໍ່ໃນອະນາຄົດ

ການປະຕິບັດຕາມກົດລະບຽບເຫຼົ່ານີ້ຈະຊ່ວຍໃຫ້ຂະບວນການກວດສອບງ່າຍຂຶ້ນ.

ກົດລະບຽບເຫຼົ່ານີ້ບໍ່ແມ່ນຂໍ້ບັງຄັບຕາຍຕົວ, ແຕ່ຖ້າທ່ານບໍ່ປະຕິບັດຕາມ ທ່ານຕ້ອງມີເຫດຜົນທີ່ອະທິບາຍໄດ້.

ລາຍການກວດສອບການປ່ຽນແປງໂຄ້ດ

ໃຫ້ກວດສອບຕາມລາຍການນີ້ກ່ອນທີ່ຈະສົ່ງມອບ (commit) ການປ່ຽນແປງ.

ຢ່າ commit ໂຄ້ດທີ່ຖືກ comment ໄວ້

As developers, we often comment out code that is only there to help us verify assumptions (like console logging messages). Make sure this never makes it into your commits. If you must disobey this rule, make sure you add a comment explaining why the commented code still exists in the source. If you feel like you must make a // TODO: or // FIXME: comment, consider whether filing an issue report referencing the broken code or TODO item would be better.

ຂຽນການທົດສອບສຳລັບການປ່ຽນແປງຂອງທ່ານ

If a component has a test suite, use it. Make sure that you know how to run the tests for the component and understand the output of those tests. The component's README file should contain this information. If not and you don't know how to find it, ask us. We're happy to help when someone is trying to learn about a component for the first time. However, be prepared to get a pile of links to documentation for a build system or test framework rather than a hand-crafted list of commands for you to run. That may be all we have time to provide. If you're still confused after checking out the materials you've received, feel free to ask again with your new, specific concerns. We would really appreciate it if you added your newfound knowledge to the component's README. The best time to write documentation is after doing something for the first time.

ໃຫ້ຂຽນການທົດສອບໃຫ້ຄອບຄຸມຟີເຈີໃໝ່ທີ່ທ່ານເພີ່ມເຂົ້າໄປ.

ຖ້າພົບວ່າສ່ວນປະກອບໃດບໍ່ມີຊຸດການທົດສອບ, ທ່ານສາມາດແຈ້ງບັກ ຫຼື ຊ່ວຍເພີ່ມມັນເຂົ້າໄປໄດ້.

ປະຕິບັດຕາມຄູ່ມືຮູບແບບທີ່ມີຢູ່

ຖ້າມີຄູ່ມືຮູບແບບ (style guide) ໃຫ້ປະຕິບັດຕາມ. ຖ້າບໍ່ມີ ໃຫ້ຂຽນຕາມຮູບແບບເດີມຂອງໄຟລ໌ນັ້ນ.

ລາຍການກວດສອບການຄອມມິດ (Commit checklist)

ຂໍ້ຄວາມຄອມມິດ (Commit message) ແມ່ນສິ່ງສຳຄັນທີ່ຈະຊ່ວຍໃຫ້ຄົນອື່ນເຂົ້າໃຈວ່າເປັນຫຍັງທ່ານຈຶ່ງປ່ຽນແປງໂຄ້ດແບບນັ້ນ.

For an example of a series of commits that follows these guidelines very well, see the three commits at the top of the git log leading to 840777f in Lomiri. Not every change requires such an in-depth description as these examples. Lean on the side of more detail; someday, you are the one looking back at your commits and wondering why you made them.

ຕອບຄຳຖາມທີ່ສຳຄັນໃນຂໍ້ຄວາມຄອມມິດ

ໃຫ້ຕອບຄຳຖາມວ່າ "ແມ່ນຫຍັງ?", "ເປັນຫຍັງ?" ແລະ "ແນວໃດ?" ເພື່ອໃຫ້ຄົນອື່ນເຂົ້າໃຈບໍລິບົດໄດ້ໄວ.

ພະຍາຍາມຕອບຄຳຖາມເຫຼົ່ານີ້ໃນ metadata ຫຼື ເນື້ອຫາຂອງການຄອມມິດ ຕາມລຳດັບຄວາມສຳຄັນດັ່ງນີ້:

ແມ່ນຫຍັງ?

Answer this question with the first few lines of your commit message. "What does your commit do?" "Optimize wallpapers for load times and memory use".

ເປັນຫຍັງ?

ບອກເຫດຜົນເບື້ອງຫຼັງການປ່ຽນແປງສະເໝີ ເຊັ່ນ: ແກ້ບັກໃດ, ເພີ່ມຟີເຈີຫຍັງ ແລະ ໃຫ້ລິ້ງອ້າງອີງຖ້າມີ.

ໃຜ?

Git ຝັງຊື່ ແລະ ທີ່ຢູ່ອີເມວຂອງທ່ານໃນຖານະຜູ້ commit (committer) ການປ່ຽນແປງຂອງທ່ານ. ຖ້າຄົນອື່ນໄດ້ຊ່ວຍທ່ານຂຽນການປ່ຽນແປງ, ທ່ານຄວນເພີ່ມພວກເຂົາດ້ວຍແຖວ Co-Authored-By: ຊື່ຂອງພວກເຂົາ <their-email@example.com> ໃນຂໍ້ຄວາມ commit ຂອງທ່ານ.

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

ສະຫຼຸບແລ້ວ, ໃຫ້ແນ່ໃຈວ່າທ່ານໄດ້ຄາດການຄຳຖາມໃດໆທີ່ທ່ານເອງ ຫຼື ຄົນອື່ນອາດຈະມີກ່ຽວກັບໂຄດຂອງທ່ານໃນອະນາຄົດ ແລະ ຕອບຄຳຖາມເຫຼົ່ານັ້ນ.

ເຮັດໃຫ້ commits ນ້ອຍທີ່ສຸດເທົ່າທີ່ຈະເປັນໄປໄດ້, ແຕ່ບໍ່ໃຫ້ມັນນ້ອຍເກີນໄປ

ການປ່ຽນແປງບາງຢ່າງຮຽກຮ້ອງໃຫ້ມີຫຼາຍຂັ້ນຕອນຕາມລຳດັບເຫດຜົນເພື່ອໃຫ້ສຳເລັດ. ຖ້າເປັນກໍລະນີນີ້, ໃຫ້ແບ່ງຂັ້ນຕອນເຫຼົ່ານີ້ອອກເປັນ commits ແຍກກັນ. ແຕ່ລະ commit ຄວນປະຕິບັດຕາມລາຍການກວດສອບ commit ທັງໝົດ. ມັນບໍ່ຄວນຕ້ອງການ commit ໃດໆທີ່ມາຫຼັງຈາກມັນເພື່ອ build ຫຼື ຜ່ານການທົດສອບ.

ສົມມຸດວ່າທ່ານກຳລັງພັດທະນາວິທີການໃໝ່ໃນການຄົ້ນຫາເບີໂທລະສັບໃນແອັບຯ Dialer. ການປ່ຽນແປງຂອງທ່ານຕ້ອງການສາມຂັ້ນຕອນທີ່ແຕກຕ່າງກັນ:

1. ແກ້ໄຂບັກ (bug) ໃນການຄົ້ນຫາເບີໂທລະສັບປັດຈຸບັນ

2. ເພີ່ມ API ໃໝ່ເພື່ອຮອງຮັບການຄົ້ນຫາເບີໂທລະສັບໃໝ່ຂອງທ່ານ

3. ເພີ່ມອົງປະກອບ UI ເພື່ອໃຊ້ການຄົ້ນຫາໃໝ່ຂອງທ່ານ

ຖ້າທ່ານເຮັດການປ່ຽນແປງທັງໝົດນີ້ໃນ commit ດຽວ ແລະ ມີບັນຫາໃນຂັ້ນຕອນທີສາມ, ພວກເຮົາຈະປະຕິເສດຊຸດການປ່ຽນແປງ (changeset) ທັງໝົດ. ຖ້າທ່ານແບ່ງການປ່ຽນແປງອອກເປັນ commits ແຍກກັນ, ການແກ້ໄຂບັກ ແລະ API ໃໝ່ສາມາດຖືກເພີ່ມເຂົ້າໃນຊອບແວຫຼັກ (mainline) ໃນຂະນະທີ່ທ່ານຍັງເຮັດວຽກອອກແບບ UI ຂອງທ່ານໃໝ່.

Rebase ການປ່ຽນແປງຂອງທ່ານໃນລະຫວ່າງການກວດສອບ, ຖ້າເປັນໄປໄດ້

ມັນເປັນເລື່ອງປົກກະຕິສຳລັບບັນທຶກ commit (commit log) ໃນ GitHub ທີ່ຈະເປັນແບບນີ້:

• ແກ້ໄຂບັກໃນການຄົ້ນຫາເບີໂທລະສັບ

• ເພີ່ມການຮ້ອງຂໍ API ໃໝ່ສຳລັບການຄົ້ນຫາເບີໂທລະສັບໃໝ່

• ເພີ່ມ UI ສຳລັບການຄົ້ນຫາເບີໂທລະສັບໃໝ່

• ແກ້ໄຂ UI

• ແກ້ໄຂການແກ້ໄຂບັກ

• ກວດສອບການປ່ຽນແປງ

• ແກ້ໄຂ API ຫຼັງຈາກໄດ້ຮັບຄຳເຫັນຈາກຜູ້ກວດສອບ

ຖ້າທ່ານຕ້ອງໄດ້ກັບມາເບິ່ງບັນທຶກ commit ນີ້ໃນອະນາຄົດ, ທ່ານຈະສັບສົນໃນທັນທີ. ຜູ້ກວດສອບເວົ້າຫຍັງ, ມີຫຍັງຜິດພາດກັບ UI ແລະ ການແກ້ໄຂບັກ?

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

ການແກ້ໄຂ commits ຮຽກຮ້ອງໃຫ້ຮຽນຮູ້ເຄື່ອງມືໃໝ່ໃນ Git. ແກ້ໄຂຊຸດຂອງ commits ດ້ວຍ git-rebase. ສົ່ງ (Push) ການປ່ຽນແປງທີ່ໄດ້ຮັບດ້ວຍ force push, ຫຼື ສ້າງ branch ໃໝ່ ແລະ ເປີດຊຸດການປ່ຽນແປງໃໝ່.

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

ແຕ່ລະ commit ຕ້ອງສາມາດ build, ແລ່ນ, ແລະ ຜ່ານການທົດສອບໄດ້ຫຼັງຈາກການປ່ຽນແປງຂອງທ່ານ.

ຈັດຮູບແບບຂໍ້ຄວາມ commit ຂອງທ່ານໃຫ້ຖືກຕ້ອງ

ຮັກສາແຖວທຳອິດຂອງຂໍ້ຄວາມ commit ຂອງທ່ານ (ບົດສະຫຼຸບ) ໃຫ້ຢູ່ໃນ 50 ຕົວອັກສອນ ຫຼື ໜ້ອຍກວ່າ. ທຸກໆແຖວອື່ນໃນຂໍ້ຄວາມ commit ຄວນຈະເປັນ 72 ຕົວອັກສອນ ຫຼື ໜ້ອຍກວ່າ. ມັນບໍ່ເປັນຫຍັງຖ້າທ່ານຕ້ອງຝ່າຝືນກົດລະບຽບ — ເພາະການປ່ຽນແປງບາງຢ່າງບໍ່ສາມາດສະຫຼຸບໄດ້ໃນ 50 ຕົວອັກສອນ, ແລະ ລິ້ງບາງອັນກໍຍາວກວ່າ 72 ຕົວອັກສອນ.

ລາຍການກວດສອບຄຳອະທິບາຍຊຸດການປ່ຽນແປງ

ໃຫ້ແນ່ໃຈວ່າຊຸດການປ່ຽນແປງຂອງທ່ານໄດ້ຕອບຄຳຖາມຕໍ່ໄປນີ້ໃນຄຳອະທິບາຍຂອງມັນ.

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

ຊຸດການປ່ຽນແປງຂອງທ່ານແກ້ໄຂບັນຫາຫຍັງ?

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

ຕົວຢ່າງ:

ແກ້ໄຂ https://gitlab.com/ubports/development/ubuntu-touch/-/issues/1

ທ່ານໄດ້ທົດສອບແນວໃດວ່າການປ່ຽນແປງນັ້ນປະສົບຜົນສຳເລັດ?

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

ຕົວຢ່າງ:

ຂ້ອຍໄດ້ທົດສອບການປ່ຽນແປງ dialer ນີ້ໃນ Nexus 5. ມັນຄວນຈະເຮັດວຽກໃນທຸກອຸປະກອນ ເນື່ອງຈາກມັນບໍ່ໄດ້ດັດແກ້ສິ່ງທີ່ສະເພາະເຈາະຈົງກັບອຸປະກອນ, ແຕ່ການທົດສອບເພີ່ມເຕີມຈະໄດ້ຮັບການຂອບໃຈ. ເພື່ອແກ້ໄຂບັກ, ຂ້ອຍຕ້ອງແຕະຕ້ອງໂຄດເລັກນ້ອຍໃນພື້ນທີ່ຄົ້ນຫາເບີໂທລະສັບ (#53). ຂ້ອຍບໍ່ແນ່ໃຈວ່າຈະທົດສອບສິ່ງນັ້ນສຳລັບ regressions ແນວໃດ.

ມີການປ່ຽນແປງໃດໆທີ່ຕ້ອງໄດ້ຮັບການລວມເຂົ້າ (merged) ກ່ອນ ຫຼື ຫຼັງຈາກຊຸດການປ່ຽນແປງນີ້ບໍ່?

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

ຕົວຢ່າງ, ສົມມຸດວ່າທ່ານໄດ້ສົ່ງສາມ Merge Requests ໃນ GitLab, ubports/core/docs!1, ubports/core/code!2, ແລະ ubports/core/infrastructure!3. ພວກມັນຕ້ອງຖືກລວມເຂົ້າຕາມລຳດັບນັ້ນ. ໃນກໍລະນີນັ້ນ, ຄຳອະທິບາຍ MR ຂອງທ່ານຈະມີບາງຢ່າງທີ່ຄ້າຍຄືກັນກັບສິ່ງນີ້ລວມຢູ່:

• ໃນ ubports/core/docs!1:

  ubports/core/code!2 ແລະ ubports/core/infrastructure!3 ຂຶ້ນກັບ MR ນີ້.

• ໃນ ubports/core/code!2:

  ubports/docs!1 ຕ້ອງຖືກລວມເຂົ້າກ່ອນ MR ນີ້. ubports/core/infrastructure!3 ຂຶ້ນກັບ MR ນີ້.

• ໃນ ubports/core/infrastructure!3:

  ubports/docs!1 ແລະ ubports/core/infrastructure!3 ຕ້ອງຖືກລວມເຂົ້າກ່ອນ MR ນີ້.

ສ່ວນຕິດຕໍ່ຜູ້ໃຊ້ (interface) ເບິ່ງຄືແນວໃດກ່ອນ ແລະ ຫຼັງການປ່ຽນແປງ?

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

ການສົ່ງ ແລະ ການກວດສອບ

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

ພວກເຮົາເຄົາລົບທ່ານ

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

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

ພວກເຮົາຖາມຫຼາຍຄຳຖາມ

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

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

ພວກເຮົາຮ້ອງຂໍການປ່ຽນແປງ

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

ພວກເຮົາອາດຈະຮ້ອງຂໍການປ່ຽນແປງຂະໜາດໃຫຍ່

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

ທ່ານສາມາດບອກພວກເຮົາວ່າພວກເຮົາຜິດ

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

ການລວມ (Merge) ແລະ ການບຳລຸງຮັກສາ

ຫຼັງຈາກໃຫ້ແນ່ໃຈວ່າຊຸດການປ່ຽນແປງຂອງທ່ານກົງກັບຄວາມຕ້ອງການທັງໝົດຂອງພວກເຮົາ, ມັນຈະກາຍເປັນສ່ວນໜຶ່ງຂອງ Ubuntu Touch. ຂໍຂອບໃຈ! ທ່ານເປັນສະມາຊິກຂອງກຸ່ມຄົນຂະໜາດນ້ອຍທີ່ປະກອບສ່ວນເຂົ້າໃນຊຸມຊົນທີ່ສວຍງາມ. ຢ່າງໃດກໍຕາມ, ນີ້ບໍ່ແມ່ນຈຸດສິ້ນສຸດຂອງວຽກງານ.

ບາງຄັ້ງການປ່ຽນແປງຂອງທ່ານເຮັດໃຫ້ຟັງຊັນຂອງ Ubuntu Touch ເສຍຫາຍ ເຖິງແມ່ນວ່າພວກເຮົາຈະພະຍາຍາມຢ່າງເຕັມທີ່ແລ້ວກໍຕາມ. ທ່ານອາດຈະຖືກຮຽກຮ້ອງໃຫ້ຊ່ວຍສືບສວນແຫຼ່ງທີ່ມາຂອງບັນຫາ ແລະ ກະກຽມການແກ້ໄຂຖ້າສິ່ງນີ້ເກີດຂຶ້ນ. ການປ່ຽນແປງຂອງທ່ານອາດຈະຖືກຍົກເລີກ (reverted) ຖ້າພວກເຮົາພົບວ່າການປ່ຽນແປງຂອງທ່ານແມ່ນສາເຫດໂດຍກົງຂອງບັກ ແລະ ພວກເຮົາບໍ່ສາມາດຕິດຕໍ່ທ່ານໄດ້.

ຜູ້ປະກອບສ່ວນໃໝ່ອາດຈະສັງເກດເຫັນວ່າທ່ານໄດ້ເຮັດວຽກກັບອົງປະກອບທີ່ພວກເຂົາຕ້ອງການເຮັດວຽກນຳ. ພວກເຮົາຈະຂອບໃຈຖ້າທ່ານຊ່ວຍສອນພວກເຂົາກ່ຽວກັບສິ່ງທີ່ທ່ານໄດ້ຮຽນຮູ້ໃນລະຫວ່າງຂະບວນການນີ້.

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