ສັນຍາອະນຸຍາດ ແລະ ລິຂະສິດ¶
ເມື່ອປະກອບສ່ວນລະຫັດໂຄງການ, ທ່ານຕົກລົງທີ່ຈະນຳການປ່ຽນແປງ ແລະ ລະຫັດໃໝ່ຂອງທ່ານພາຍໃຕ້ສັນຍາອະນຸຍາດຂອງ Repository, GPL-3.0-or-later, ນອກຈາກຈະມີການລະບຸ ແລະ ຕົກລົງເປັນຢ່າງອື່ນ. ໄຟລ໌ Source ໃໝ່ຄວນປະຕິບັດຕາມຮູບແບບຫົວຂໍ້ລິຂະສິດ ແລະ SPDX ທີ່ມີຢູ່.
ໃຊ້ສັນຍາອະນຸຍາດອື່ນເມື່ອມີເຫດຜົນທີ່ຕັ້ງໃຈໄວ້ເທົ່ານັ້ນ, ເຊັ່ນ: ໄຟລ໌ທີ່ແບ່ງປັນກັບ Repository ທີ່ໃຊ້ສັນຍາອະນຸຍາດທີ່ເປີດກວ້າງກວ່າ.
See also
ສັນຍາອະນຸຍາດ (License) ຂອງ Weblate ອະທິບາຍກ່ຽວກັບສັນຍາອະນຸຍາດຢ່າງລະອຽດເພີ່ມເຕີມ.
ການຂຽນ Patch ທີ່ດີ¶
ຂຽນການປ່ຽນແປງແຍກຕ່າງຫາກ¶
ມັນເປັນເລື່ອງໜ້າຮຳຄານເມື່ອທ່ານໄດ້ຮັບ Patch ໃຫຍ່ໆທີ່ບອກວ່າແກ້ໄຂ 11 ບັນຫາ, ແຕ່ການສົນທະນາ ແລະ ຄວາມຄິດເຫັນບໍ່ເຫັນດີກັບ 10 ບັນຫາໃນນັ້ນ ຫຼື 9 ບັນຫາໃນນັ້ນຖືກແກ້ໄຂໄປແລ້ວໃນແບບອື່ນ. ຈາກນັ້ນ, ຜູ້ທີ່ລວມ (merge) ການປ່ຽນແປງນີ້ຈະຕ້ອງສະກັດ Patch ທີ່ໜ້າສົນໃຈພຽງອັນດຽວຈາກກອງ Source code ມະຫາສານ, ແລະ ນັ້ນສ້າງວຽກເພີ່ມຂຶ້ນຫຼາຍ.
ທາງທີ່ດີ, ການແກ້ໄຂແຕ່ລະອັນທີ່ແກ້ໄຂບັນຫາຄວນຢູ່ໃນ Patch/commit ຂອງມັນເອງ ພ້ອມກັບຄຳອະທິບາຍ/ຂໍ້ຄວາມ Commit ຂອງມັນເອງ ເພື່ອລະບຸຢ່າງຊັດເຈນວ່າພວກມັນແກ້ໄຂຫຍັງ ເພື່ອໃຫ້ການປ່ຽນແປງທັງໝົດສາມາດຖືກເລືອກໃຊ້ໂດຍຜູ້ດູແລ ຫຼື ຜູ້ສົນໃຈອື່ນໆ.
ຍິ່ງໄປກວ່ານັ້ນ, ການປ່ຽນແປງແຍກຕ່າງຫາກຊ່ວຍໃຫ້ການ Bisect ດີຂຶ້ນຫຼາຍສຳລັບການຕິດຕາມບັນຫາ ແລະ Regression ໃນອະນາຄົດ.
ເອກະສານແນະນຳ¶
ເອກະສານອາດຈະເປັນວຽກທີ່ໜ້າເບື່ອໜ່າຍ; ແນວໃດກໍຕາມ, ມັນຈຳເປັນຕ້ອງມີຄົນເຮັດໃຫ້ສຳເລັດ. ມັນຈະງ່າຍຂຶ້ນຫຼາຍຖ້າທ່ານສົ່ງເອກະສານພ້ອມກັບການປ່ຽນແປງລະຫັດ. ກະລຸນາຢ່າລືມຂຽນເອກະສານໃຫ້ກັບ Methods, ບລັອກລະຫັດທີ່ຊັບຊ້ອນ, ຫຼື ຟີເຈີທີ່ຜູ້ໃຊ້ເບິ່ງເຫັນ.
See also
ກໍລະນີທົດສອບ (Test cases)¶
ການທົດສອບຊ່ວຍໃຫ້ພວກເຮົາຢືນຢັນໄດ້ຢ່າງໄວວາວ່າຟີເຈີຕ່າງໆເຮັດວຽກຕາມທີ່ຄວນຈະເປັນ. ເພື່ອຮັກສາສະຖານະການນີ້ ແລະ ປັບປຸງມັນ, ຟີເຈີ ແລະ ຟັງຊັນໃໝ່ທັງໝົດທີ່ເພີ່ມເຂົ້າມາຕ້ອງໄດ້ຮັບການທົດສອບໃນ Test suite. ທຸກຟີເຈີທີ່ເພີ່ມເຂົ້າມາຄວນມີຢ່າງໜ້ອຍໜຶ່ງກໍລະນີທົດສອບທີ່ຖືກຕ້ອງ ເຊິ່ງຢືນຢັນວ່າວຽກງານດັ່ງກ່າວເຮັດວຽກຕາມທີ່ລະບຸໄວ້ໃນເອກະສານ.
ຂໍ້ຄວາມຄອມມິດ (Commit messages)¶
Git commits ຄວນປະຕິບັດຕາມຂໍ້ກຳນົດ Conventional Commits.
ການກວດສອບ Type¶
ລະຫັດໃໝ່ໃດໆຄວນໃຊ້ Type hints ຂອງ PEP 484. ພວກເຮົາໃຊ້ mypy ເພື່ອກວດສອບພວກມັນ ເພາະມັນມີປລັກອິນ Django ທີ່ເຮັດໃຫ້ການກວດສອບ Type ຂອງແອັບ Django ເປັນຈິງໄດ້.
ລະຫັດໃໝ່ ແລະ ລະຫັດທີ່ມີການປ່ຽນແປງບໍ່ຄວນສ້າງຂໍ້ຜິດພາດ mypy ໃໝ່ ໃນຈຸດທີ່ການຮອງຮັບ Django typing ທີ່ມີຢູ່ເຮັດໃຫ້ມັນເປັນຈິງໄດ້. Code base ຍັງບໍ່ທັນໄດ້ຮັບການປົກຄຸມດ້ວຍ Type annotations ຢ່າງສົມບູນ, ແລະ Django constructs ບາງອັນກໍຍາກທີ່ຈະ Annotate ໃຫ້ຊັດເຈນ. ດັ່ງນັ້ນ CI ຈຶ່ງບັງຄັບໃຊ້ mypy ສະເພາະບາງໂມດູນທີ່ເລືອກ ແລະ ລາຍງານຜົນພົບເຫັນອື່ນໆແຍກຕ່າງຫາກ.
ມາດຕະຖານການຂຽນລະຫັດ ແລະ ການກວດສອບ (Linting) ລະຫັດ¶
ລະຫັດຄວນປະຕິບັດຕາມຂໍ້ແນະນຳການຂຽນລະຫັດ PEP 8 ແລະ ຄວນຖືກຈັດຮູບແບບໂດຍໃຊ້ ruff code formatter.
ເພື່ອຕວດສອບຄຸນນະພາບລະຫັດ, ທ່ານສາມາດໃຊ້ ruff, ການຕັ້ງຄ່າຂອງມັນຖືກເກັບໄວ້ໃນ pyproject.toml.
ເມື່ອລະງັບ (suppressing) ການວິນິດໄສຂອງ ruff, ໃຫ້ມັກໃຊ້ # ruff: ignore[rule-name] ພ້ອມກັບຊື່ກົດທີ່ມະນຸດອ່ານເຂົ້າໃຈ. ວາງຄຳຄິດເຫັນໄວ້ໃນແຖວເໜືອຄຳຖະແຫຼງການ ຫຼື ບລັອກທີ່ມີເຫດຜົນເມື່ອມັນບໍ່ໄດ້ຂະຫຍາຍຂອບເຂດການລະງັບ. ໃຫ້ຮັກສາຄຳຄິດເຫັນໄວ້ໃນແຖວດຽວກັນ (inline) ເມື່ອການຍ້າຍມັນຈະປ່ຽນຂອບເຂດ, ສົ່ງຜົນກະທົບຕໍ່ການຈັດລຳດັບ Import, ຫຼື ແຊກລະຫວ່າງຄຳຄິດເຫັນ disable-next ຂອງເຄື່ອງມືອື່ນ ແລະ ລະຫັດທີ່ມັນກຳນົດເປົ້າໝາຍ.
ວິທີທີ່ງ່າຍທີ່ສຸດໃນການບັງຄັບໃຊ້ທັງໝົດນີ້ຄືການຕິດຕັ້ງ prek. ນີ້ແມ່ນການສ້າງຂຶ້ນໃໝ່ (reimplementation) ໂດຍພາກສ່ວນທີສາມຂອງເຄື່ອງມື pre-commit ທີ່ Weblate ໃຊ້. ມັນລວມຢູ່ໃນ Development dependencies ທີ່ປະກາດໃນ pyproject.toml, ສະນັ້ນການຕິດຕັ້ງ Dependencies ເຫຼົ່ານັ້ນຈະເຮັດໃຫ້ prek ສາມາດໃຊ້ງານໄດ້.
ເພື່ອຕວດສອບໄຟລ໌ທັງໝົດດ້ວຍຕົນເອງ, ໃຫ້ດຳເນີນການ:
uv run prek run --all-files
ຖ້າທ່ານມັກ Client pre-commit ເດີມ, ມັນໃຊ້ການຕັ້ງຄ່າດຽວກັນຈາກ .pre-commit-config.yaml.
ການຂຽນລະຫັດຢ່າງປອດໄພ¶
ລະຫັດໃດໆສຳລັບ Weblate ຄວນຖືກຂຽນຂຶ້ນໂດຍຄຳນຶງເຖິງ Security by Design Principles.
ຂໍ້ແນະນຳດ້ານ AI¶
ເມື່ອປະກອບສ່ວນເນື້ອຫາໃຫ້ໂຄງການ, ທ່ານໃຫ້ສິດພວກເຮົາໃນການໃຊ້ເນື້ອຫານັ້ນຕາມສະພາບທີ່ເປັນຢູ່, ແລະ ທ່ານຕ້ອງໃຫ້ແນ່ໃຈວ່າທ່ານໄດ້ຮັບອະນຸຍາດໃຫ້ແຈກຢາຍມັນໃຫ້ພວກເຮົາ. ໂດຍການສົ່ງການປ່ຽນແປງໃຫ້ພວກເຮົາ, ທ່ານຕົກລົງວ່າການປ່ຽນແປງນັ້ນສາມາດ ແລະ ຄວນຖືກນຳມາໃຊ້ໂດຍໂຄງການ ແລະ ຖືກແຈກຢາຍຕໍ່ພາຍໃຕ້ສັນຍາອະນຸຍາດຂອງໂຄງການ. ຜູ້ຂຽນຄວນຮູ້ຢ່າງຊັດເຈນວ່າພາລະຮັບຜິດຊອບເປັນຂອງພວກເຂົາທີ່ຈະຮັບປະກັນວ່າບໍ່ມີລະຫັດທີ່ບໍ່ມີສັນຍາອະນຸຍາດຖືກສົ່ງໃຫ້ໂຄງການ.
ເລື່ອງນີ້ບໍ່ຂຶ້ນກັບວ່າຈະມີການໃຊ້ AI ຫຼື ບໍ່.
ເມື່ອປະກອບສ່ວນ Pull request, ແນ່ນອນວ່າທ່ານຄວນໃຫ້ແນ່ໃຈສະເໝີວ່າຂໍ້ສະເໜີຂອງທ່ານມີຄຸນນະພາບດີ ແລະ ເປັນຄວາມພະຍາຍາມທີ່ດີທີ່ສຸດທີ່ປະຕິບັດຕາມຂໍ້ແນະນຳຂອງພວກເຮົາ. ກົດພື້ນຖານແມ່ນວ່າ ຖ້າໃຜຜູ້ໜຶ່ງສາມາດເບິ່ງອອກວ່າການປະກອບສ່ວນນັ້ນເຮັດຂຶ້ນດ້ວຍການຊ່ວຍເຫຼືອຂອງ AI, ທ່ານຍັງມີວຽກຕ້ອງເຮັດຕື່ມອີກ.
ພວກເຮົາສາມາດຍອມຮັບລະຫັດທີ່ຂຽນດ້ວຍການຊ່ວຍເຫຼືອຂອງ AI ເຂົ້າໃນໂຄງການໄດ້, ແຕ່ລະຫັດນັ້ນຍັງຕ້ອງປະຕິບັດຕາມມາດຕະຖານການຂຽນລະຫັດ, ຂຽນຢ່າງຊັດເຈນ, ມີເອກະສານ, ມີກໍລະນີທົດສອບ, ແລະ ປະຕິບັດຕາມຂໍ້ກຳນົດປົກກະຕິທັງໝົດທີ່ພວກເຮົາມີ.