📙 [TH] การมีส่วนร่วมใน Bitcoin Core ( Github )
แปลโดย : Claude 3.7 Sonnet / source : https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md
การมีส่วนร่วมใน Bitcoin Core
โครงการ Bitcoin Core ดำเนินงานในรูปแบบโมเดลผู้มีส่วนร่วมแบบเปิด ซึ่งทุกคนสามารถมีส่วนร่วมในการพัฒนาผ่านการตรวจสอบโดยเพื่อนร่วมงาน การทดสอบ และการส่ง patches เอกสารนี้อธิบายกระบวนการและแนวทางปฏิบัติสำหรับการมีส่วนร่วม
ประการแรก ในแง่ของโครงสร้าง ไม่มีแนวคิดเฉพาะเกี่ยวกับ "นักพัฒนา Bitcoin Core" ในความหมายของบุคคลที่มีสิทธิพิเศษ โอเพนซอร์สมักจะหมุนรอบ meritocracy โดยธรรมชาติ ซึ่งผู้มีส่วนร่วมจะได้รับความไว้วางใจจากชุมชนนักพัฒนาเมื่อเวลาผ่านไป อย่างไรก็ตาม จำเป็นต้องมีลำดับชั้นบางอย่างเพื่อวัตถุประสงค์ในทางปฏิบัติ ดังนั้น จึงมีผู้ดูแล repository ที่รับผิดชอบในการรวม pull requests วงจรการเผยแพร่ และการกำกับดูแล
การเริ่มต้น
ยินดีต้อนรับผู้มีส่วนร่วมใหม่และเป็นที่ต้องการ
การตรวจสอบและการทดสอบมีคุณค่าสูงและเป็นวิธีที่มีประสิทธิภาพที่สุดที่คุณสามารถมีส่วนร่วมในฐานะผู้มีส่วนร่วมใหม่ นอกจากนี้ยังจะสอนคุณเกี่ยวกับโค้ดและกระบวนการมากกว่าการเปิด pull requests โปรดดูที่ส่วนการตรวจสอบโดยเพื่อนร่วมงานด้านล่าง
ก่อนที่คุณจะเริ่มมีส่วนร่วม ทำความคุ้นเคยกับระบบการสร้าง Bitcoin Core และการทดสอบ โปรดดูเอกสารใน repository เกี่ยวกับวิธีการสร้าง Bitcoin Core และวิธีการเรียกใช้ unit tests, functional tests และ fuzz tests
มีประเด็นที่เปิดอยู่หลายประเด็นที่มีระดับความยากหลากหลายรอการแก้ไข หากคุณกำลังมองหาที่เริ่มต้นมีส่วนร่วม ตรวจสอบรายการ good first issue หรือการเปลี่ยนแปลงที่เปิดให้จับจอง บางส่วนอาจไม่สามารถใช้ได้อีกต่อไป ดังนั้นหากคุณสนใจแต่ไม่แน่ใจ คุณอาจต้องการแสดงความคิดเห็นในประเด็นก่อน
คุณอาจเข้าร่วมใน Bitcoin Core PR Review Club ด้วย
ป้าย Good First Issue
วัตถุประสงค์ของป้าย good first issue คือเพื่อเน้นประเด็นที่เหมาะสำหรับผู้มีส่วนร่วมใหม่ที่ไม่มีความเข้าใจอย่างลึกซึ้งเกี่ยวกับ codebase
อย่างไรก็ตาม good first issues สามารถแก้ไขได้โดยทุกคน หากยังไม่ได้รับการแก้ไขเป็นเวลานาน ผู้มีส่วนร่วมประจำอาจจัดการกับปัญหาเหล่านั้น
คุณไม่จำเป็นต้องขออนุญาตเพื่อเริ่มทำงานกับประเด็น อย่างไรก็ตาม คุณควรแสดงความคิดเห็นหากคุณวางแผนที่จะทำงานกับมัน นี่จะช่วยให้ผู้มีส่วนร่วมคนอื่น ๆ ติดตามประเด็นที่กำลังได้รับการจัดการอย่างแข็งขันและยังเป็นวิธีที่มีประสิทธิภาพในการขอความช่วยเหลือหากและเมื่อคุณต้องการ
ช่องทางการสื่อสาร
การสื่อสารส่วนใหญ่เกี่ยวกับการพัฒนา Bitcoin Core เกิดขึ้นบน IRC ในช่อง #bitcoin-core-dev บน Libera Chat วิธีที่ง่ายที่สุดในการมีส่วนร่วมบน IRC คือใช้ web client, web.libera.chat บันทึกประวัติการแชทสามารถพบได้ที่ https://www.erisian.com.au/bitcoin-core-dev/ และ https://gnusha.org/bitcoin-core-dev/
การอภิปรายเกี่ยวกับการปรับปรุง codebase เกิดขึ้นใน GitHub issues และ pull requests
รายชื่อเมลของนักพัฒนาควรใช้เพื่ออภิปรายการเปลี่ยนแปลง consensus หรือ P2P protocol ที่ซับซ้อนหรือมีข้อโต้แย้งก่อนที่จะทำงานกับชุด patch บันทึกสามารถพบได้ที่ https://gnusha.org/pi/bitcoindev/
ขั้นตอนการทำงานของผู้มีส่วนร่วม
codebase ได้รับการดูแลโดยใช้ "contributor workflow" ซึ่งทุกคนโดยไม่มีข้อยกเว้นมีส่วนร่วมในการเสนอ patch โดยใช้ "pull requests" (PRs) สิ่งนี้ช่วยให้การมีส่วนร่วมทางสังคม การทดสอบที่ง่าย และการตรวจสอบโดยเพื่อนร่วมงาน
เพื่อมีส่วนร่วมใน patch ขั้นตอนการทำงานมีดังนี้:
Fork repository (เฉพาะครั้งแรก)
สร้าง topic branch
Commit patches
สำหรับประเด็นหรือ pull requests ที่เกี่ยวข้องกับ GUI ควรใช้ repository https://github.com/bitcoin-core/gui สำหรับประเด็นและ pull requests อื่น ๆ ทั้งหมด ควรใช้ repository โหนด https://github.com/bitcoin/bitcoin
branch หลักสำหรับ monotree repositories ทั้งหมดเหมือนกัน
เป็นกฎทั่วไป ทุกอย่างที่แก้ไขเฉพาะ src/qt เป็น pull request เฉพาะ GUI อย่างไรก็ตาม:
สำหรับ global refactoring หรือการเปลี่ยนแปลง transversal อื่น ๆ ควรใช้ repository โหนด
สำหรับการเปลี่ยนแปลงระบบการสร้างที่เกี่ยวข้องกับ GUI ควรใช้ repository โหนดเพราะการเปลี่ยนแปลงต้องการการตรวจสอบโดยผู้ตรวจสอบระบบการสร้าง
การเปลี่ยนแปลงใน src/interfaces ต้องไปที่ repository โหนดเพราะอาจส่งผลต่อส่วนประกอบอื่น ๆ เช่น wallet
สำหรับการเปลี่ยนแปลง GUI ขนาดใหญ่ที่รวมถึงการเปลี่ยนแปลงระบบการสร้างและอินเทอร์เฟซ แนะนำให้เปิด pull request กับ repository GUI ก่อน เมื่อมีการตกลงที่จะดำเนินการกับการเปลี่ยนแปลง สามารถส่ง pull request พร้อมการเปลี่ยนแปลงระบบการสร้างและอินเทอร์เฟซไปยัง repository โหนดได้
ต้องปฏิบัติตามข้อกำหนดการเขียนโค้ดของโครงการในบันทึกของนักพัฒนา
การ Commit Patches
โดยทั่วไป commits ควรเป็นแบบ atomic และ diffs ควรอ่านง่าย ด้วยเหตุนี้ อย่าผสมการแก้ไขการจัดรูปแบบหรือการย้ายโค้ดกับการเปลี่ยนแปลงโค้ดจริง
ต้องแน่ใจว่าแต่ละ commit เป็นแบบ hygienic: มันสามารถสร้างได้สำเร็จด้วยตัวเองโดยไม่มี warnings, errors, regressions หรือการล้มเหลวของการทดสอบ
ข้อความ commit ควรมีรายละเอียดโดยปกติ ประกอบด้วยบรรทัดหัวข้อสั้น ๆ (สูงสุด 50 ตัวอักษร) บรรทัดว่าง และข้อความอธิบายโดยละเอียดเป็นย่อหน้าแยกต่างหาก เว้นแต่ว่าชื่อเรื่องเพียงอย่างเดียวจะอธิบายตัวเองได้ (เช่น "Correct typo in init.cpp") ซึ่งในกรณีนี้บรรทัดชื่อเรื่องเพียงบรรทัดเดียวก็เพียงพอ ข้อความ commit ควรเป็นประโยชน์ต่อผู้ที่อ่านโค้ดของคุณในอนาคต ดังนั้นจึงอธิบายเหตุผลสำหรับการตัดสินใจของคุณ คำอธิบายเพิ่มเติมที่นี่
หาก commit เฉพาะอ้างอิงถึงประเด็นอื่น โปรดเพิ่มการอ้างอิง ตัวอย่างเช่น: refs #1234 หรือ fixes #4321 การใช้คำสำคัญ fixes หรือ closes จะทำให้ประเด็นที่เกี่ยวข้องถูกปิดเมื่อมีการรวม pull request
ข้อความ commit ไม่ควรมี @ mentions (ชื่อผู้ใช้ที่นำหน้าด้วย "@") ใด ๆ
โปรดดูคู่มือ Git สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ Git
Push การเปลี่ยนแปลงไปยัง fork ของคุณ
สร้าง pull request
การสร้าง Pull Request
ชื่อของ pull request ควรมีคำนำหน้าด้วย component หรือพื้นที่ที่ pull request มีผลกระทบ พื้นที่ที่ถูกต้องเป็น:
consensus สำหรับการเปลี่ยนแปลงโค้ดที่สำคัญต่อ consensus
doc สำหรับการเปลี่ยนแปลงเอกสาร
qt หรือ gui สำหรับการเปลี่ยนแปลง bitcoin-qt
log สำหรับการเปลี่ยนแปลงข้อความ log
mining สำหรับการเปลี่ยนแปลงโค้ดการขุด
net หรือ p2p สำหรับการเปลี่ยนแปลงโค้ดเครือข่าย peer-to-peer
refactor สำหรับการเปลี่ยนแปลงโครงสร้างที่ไม่เปลี่ยนพฤติกรรม
rpc, rest หรือ zmq สำหรับการเปลี่ยนแปลง RPC, REST หรือ ZMQ APIs
contrib หรือ cli สำหรับการเปลี่ยนแปลงสคริปต์และเครื่องมือ
test, qa หรือ ci สำหรับการเปลี่ยนแปลง unit tests, QA tests หรือโค้ด CI
util หรือ lib สำหรับการเปลี่ยนแปลง utils หรือ libraries
wallet สำหรับการเปลี่ยนแปลงโค้ด wallet
build สำหรับการเปลี่ยนแปลง CMake
guix สำหรับการเปลี่ยนแปลงการสร้าง GUIX reproducible
ตัวอย่าง:
consensus: Add new opcode for BIP-XXXX OP_CHECKAWESOMESIG
net: Automatically create onion service, listen on Tor
qt: Add feed bump button
log: Fix typo in log message
เนื้อหาของ pull request ควรมีคำอธิบายที่เพียงพอว่า patch ทำอะไร และที่สำคัญยิ่งกว่าคือทำไม พร้อมเหตุผลและคำอธิบาย คุณควรรวมการอ้างอิงไปยังการอภิปรายใด ๆ (เช่น ประเด็นอื่น ๆ หรือการอภิปรายทางรายชื่อเมล)
คำอธิบายสำหรับ pull request ใหม่ไม่ควรมี @ mentions ใด ๆ คำอธิบาย PR จะถูกรวมในข้อความ commit เมื่อมีการรวม PR และผู้ใช้ที่กล่าวถึงในคำอธิบายจะได้รับการแจ้งเตือนที่น่ารำคาญทุกครั้งที่ fork ของ Bitcoin Core คัดลอกการรวม แทนที่จะทำเช่นนั้น ให้กล่าวถึงชื่อผู้ใช้ในความคิดเห็นถัดไปของ PR
การเปลี่ยนแปลงคำแปล
โปรดทราบว่าไม่ควรส่งคำแปลเป็น pull requests กรุณาดู Translation Process สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการช่วยเหลือในการแปล
การเปลี่ยนแปลงที่อยู่ระหว่างดำเนินการและคำขอความคิดเห็น
หากไม่ต้องการให้พิจารณา pull request สำหรับการรวม (ยัง) โปรดเพิ่มคำนำหน้าชื่อด้วย [WIP] หรือใช้ Tasks Lists ในเนื้อหาของ pull request เพื่อระบุงานที่กำลังรอดำเนินการ
การตอบสนองต่อข้อเสนอแนะ
ในขั้นตอนนี้ คุณควรคาดหวังความคิดเห็นและการตรวจสอบจากผู้มีส่วนร่วมคนอื่น ๆ คุณสามารถเพิ่ม commits เพิ่มเติมใน pull request ของคุณโดย commit พวกมันในเครื่องและ push ไปยัง fork ของคุณ
คุณควรตอบกลับความคิดเห็นการตรวจสอบใด ๆ ก่อนที่จะรวม pull request ของคุณ คุณอาจอัปเดตโค้ดหรือปฏิเสธข้อเสนอแนะหากคุณไม่เห็นด้วย แต่คุณควรแสดงออกในการตอบกลับ หากมีข้อเสนอแนะที่ยังไม่ได้รับการตอบสนองและคุณไม่ได้ทำงานกับมันอย่างแข็งขัน pull request ของคุณอาจถูกปิด
โปรดดูที่ส่วนการตรวจสอบโดยเพื่อนร่วมงานด้านล่างสำหรับรายละเอียดเพิ่มเติม
การ Squash Commits
หาก pull request ของคุณมี fixup commits (commits ที่เปลี่ยนบรรทัดโค้ดเดียวกันซ้ำๆ) หรือ commits ที่ละเอียดเกินไป คุณอาจถูกขอให้ squash commits ของคุณก่อนที่จะได้รับการตรวจสอบ ขั้นตอนการทำงาน squashing พื้นฐานแสดงด้านล่าง
โปรดอัปเดตข้อความ commit ที่ได้หากจำเป็น มันควรอ่านเป็นข้อความที่สอดคล้องกัน ในกรณีส่วนใหญ่ นี่หมายความว่าไม่เพียงแค่แสดงรายการ commits ระหว่างกาล
หากการเปลี่ยนแปลงของคุณมี merge commit ขั้นตอนการทำงานข้างต้นอาจไม่ทำงานและคุณจะต้องลบ merge commit ก่อน ดูส่วนถัดไปสำหรับรายละเอียดเกี่ยวกับวิธีการ rebase
โปรดงดเว้นการสร้าง pull requests หลายรายการสำหรับการเปลี่ยนแปลงเดียวกัน ใช้ pull request ที่เปิดอยู่แล้ว (หรือถูกสร้างก่อนหน้านี้) เพื่อแก้ไขการเปลี่ยนแปลง การทำเช่นนี้จะรักษาการอภิปรายและการตรวจสอบที่เกิดขึ้นก่อนหน้านี้สำหรับชุดการเปลี่ยนแปลงที่เกี่ยวข้อง
ระยะเวลาที่ต้องการสำหรับการตรวจสอบโดยเพื่อนร่วมงานไม่สามารถคาดเดาได้และจะแตกต่างกันไปในแต่ละ pull request
การ Rebase การเปลี่ยนแปลง
เมื่อ pull request ขัดแย้งกับ branch เป้าหมาย คุณอาจถูกขอให้ rebase มันบน branch เป้าหมายปัจจุบัน
โครงการนี้มีเป้าหมายที่จะมีประวัติ git ที่สะอาด ซึ่งการเปลี่ยนแปลงโค้ดจะทำเฉพาะใน non-merge commits เท่านั้น นี่ทำให้การตรวจสอบง่ายขึ้นเพราะสามารถสมมติได้ว่า merge commits ไม่มีการเปลี่ยนแปลงโค้ดตามอำเภอใจ Merge commits ควรถูกลงนาม และ git tree hash ที่ได้ต้องมีความเป็นตรรกะและสามารถทำซ้ำได้ สคริปต์ใน /contrib/verify-commits จะตรวจสอบสิ่งนี้
หลังจาก rebase ขอแนะนำให้ผู้ตรวจสอบลงนามใน force push นี่ควรจะค่อนข้างตรงไปตรงมาด้วยเครื่องมือ git range-diff ที่อธิบายไว้ในหมายเหตุเกี่ยวกับผลิตภาพ เพื่อหลีกเลี่ยงการตรวจสอบที่ไม่จำเป็น ผู้ดูแลจะรวม pull requests ที่ได้รับความสนใจในการตรวจสอบมากที่สุดก่อน
ปรัชญาของ Pull Request
ชุด patches ควรมีจุดเน้นเสมอ ตัวอย่างเช่น pull request อาจเพิ่มฟีเจอร์ แก้ไขบัก หรือ refactor โค้ด แต่ไม่ใช่การผสมผสานกัน โปรดหลีกเลี่ยง pull requests ขนาดใหญ่ที่พยายามทำมากเกินไป มีขนาดใหญ่เกินไป หรือซับซ้อนเกินไป เนื่องจากทำให้การตรวจสอบยากลำบาก
ฟีเจอร์
เมื่อเพิ่มฟีเจอร์ใหม่ ต้องคำนึงถึง technical debt ระยะยาวและการบำรุงรักษาที่ฟีเจอร์นั้นอาจต้องการหลังจากรวมเข้ามา ก่อนที่จะเสนอฟีเจอร์ใหม่ที่จะต้องมีการบำรุงรักษา โปรดพิจารณาว่าคุณเต็มใจที่จะบำรุงรักษามันหรือไม่ (รวมถึงการแก้ไขบัก) หากฟีเจอร์ถูกทอดทิ้งโดยไม่มีผู้ดูแลในอนาคต พวกมันอาจถูกลบโดยผู้ดูแล Repository
การ Refactor
การ refactor เป็นส่วนที่จำเป็นของวิวัฒนาการของโครงการซอฟต์แวร์ใด ๆ แนวทางต่อไปนี้ครอบคลุม pull requests การ refactor สำหรับโครงการ
มีการ refactor สามประเภท:
การย้ายเฉพาะโค้ด (code-only moves)
การแก้ไขรูปแบบโค้ด (code style fixes)
การ refactor โค้ด (code refactoring)
โดยทั่วไป pull requests การ refactor ไม่ควรผสมกิจกรรมทั้งสามประเภทนี้เพื่อให้ pull requests การ refactor ตรวจสอบได้ง่ายและไม่เป็นที่ถกเถียง ในทุกกรณี PRs การ refactor ต้องไม่เปลี่ยนพฤติกรรมของโค้ดภายใน pull request (บักต้องถูกเก็บไว้ตามเดิม)
ผู้ดูแลโครงการมีเป้าหมายที่จะตอบสนองอย่างรวดเร็วต่อ pull requests การ refactor ดังนั้นเมื่อเป็นไปได้ควรทำให้สั้น ไม่ซับซ้อน และตรวจสอบได้ง่าย
pull requests ที่ refactor โค้ดไม่ควรทำโดยผู้มีส่วนร่วมใหม่ มันต้องการระดับประสบการณ์หนึ่งเพื่อรู้ว่าโค้ดควรอยู่ที่ไหนและเข้าใจผลกระทบทั้งหมด (รวมถึงความพยายามในการ rebase ของ pull requests ที่เปิดอยู่)
pull requests ที่ไม่สำคัญหรือ pull requests ที่ refactor โค้ดโดยไม่มีประโยชน์ที่ชัดเจนอาจถูกปิดทันทีโดยผู้ดูแลเพื่อลดภาระงานที่ไม่จำเป็นในการตรวจสอบ
กระบวนการ "การตัดสินใจ"
สิ่งต่อไปนี้ใช้กับการเปลี่ยนแปลงโค้ดของโครงการ Bitcoin Core (และโครงการที่เกี่ยวข้องเช่น libsecp256k1) และไม่ควรสับสนกับการเปลี่ยนแปลง consensus ของ Bitcoin Network Protocol โดยรวม
การที่ pull request จะถูกรวมเข้ากับ Bitcoin Core หรือไม่ขึ้นอยู่กับผู้ดูแลการรวมโครงการ
ผู้ดูแลจะพิจารณาว่า patch อยู่ในแนวทางเดียวกับหลักการทั่วไปของโครงการหรือไม่ ตรงตามมาตรฐานขั้นต่ำสำหรับการรวมหรือไม่ และจะตัดสินฉันทามติทั่วไปของผู้มีส่วนร่วม
โดยทั่วไป pull requests ทั้งหมดต้อง:
มีกรณีการใช้งานที่ชัดเจน แก้ไขบักที่สามารถแสดงให้เห็นได้ หรือเป็นประโยชน์ต่อโครงการโดยรวม (เช่น การ refactor สำหรับการแบ่งเป็นโมดูล)
ได้รับการตรวจสอบโดยเพื่อนร่วมงานอย่างดี
มี unit tests, functional tests และ fuzz tests ตามความเหมาะสม
ปฏิบัติตามแนวทางรูปแบบโค้ด (C++, functional tests)
ไม่ทำให้ชุดการทดสอบที่มีอยู่เสียหาย
ในกรณีที่มีการแก้ไขบัก ควรมี unit tests ที่แสดงบักและพิสูจน์การแก้ไขด้วย เท่าที่เป็นไปได้ ซึ่งช่วยป้องกันการถดถอย
เปลี่ยนความคิดเห็นและเอกสารที่เกี่ยวข้องเมื่อพฤติกรรมของโค้ดเปลี่ยนไป
Patches ที่เปลี่ยนกฎ consensus ของ Bitcoin มีความซับซ้อนมากกว่าปกติเพราะมันส่งผลกระทบต่อระบบนิเวศทั้งหมด ดังนั้นจึงต้องมีการอภิปรายในรายชื่อเมลอย่างกว้างขวางก่อนและมี BIP ที่มีหมายเลข แม้ว่าแต่ละกรณีจะแตกต่างกัน แต่ควรเตรียมพร้อมที่จะใช้เวลาและความพยายามมากกว่าสำหรับ patches ประเภทอื่น ๆ เนื่องจากความต้องการในการตรวจสอบโดยเพื่อนร่วมงานที่เพิ่มขึ้นและข้อกำหนดในการสร้างฉันทามติ
การตรวจสอบโดยเพื่อนร่วมงาน
ทุกคนอาจมีส่วนร่วมในการตรวจสอบโดยเพื่อนร่วมงาน ซึ่งแสดงออกโดยความคิดเห็นใน pull request โดยทั่วไปผู้ตรวจสอบจะตรวจสอบโค้ดเพื่อหาข้อผิดพลาดที่ชัดเจน รวมถึงทดสอบชุด patch และแสดงความคิดเห็นเกี่ยวกับข้อดีทางเทคนิคของ patch ผู้ดูแลโครงการจะคำนึงถึงการตรวจสอบโดยเพื่อนร่วมงานเมื่อกำหนดว่ามีฉันทามติในการรวม pull request หรือไม่ (โปรดจำไว้ว่าการอภิปรายอาจกระจายอยู่ใน GitHub รายชื่อเมล และการสนทนา IRC)
การตรวจสอบโค้ดเป็นส่วนที่เป็นภาระแต่สำคัญของกระบวนการพัฒนา และด้วยเหตุนี้ pull requests บางประเภทจึงถูกปฏิเสธ โดยทั่วไป หากการปรับปรุงไม่คุ้มค่ากับความพยายามในการตรวจสอบที่จำเป็น PR มีโอกาสสูงที่จะถูกปฏิเสธ เป็นหน้าที่ของผู้เขียน PR ที่จะโน้มน้าวผู้ตรวจสอบว่าการเปลี่ยนแปลงคุ้มค่ากับความพยายามในการตรวจสอบ และหากผู้ตรวจสอบกำลัง "Concept NACK" PR ผู้เขียนอาจต้องนำเสนอข้อโต้แย้งและ/หรือทำการวิจัยเพื่อสนับสนุนการเปลี่ยนแปลงที่แนะนำ
การตรวจสอบเชิงแนวคิด
การตรวจสอบอาจเป็นการตรวจสอบเชิงแนวคิด ซึ่งผู้ตรวจสอบแสดงความคิดเห็น
Concept (N)ACK หมายถึง "ฉัน(ไม่)เห็นด้วยกับเป้าหมายทั่วไปของ pull request นี้"
Approach (N)ACK หมายถึง Concept ACK แต่ "ฉัน(ไม่)เห็นด้วยกับแนวทางของการเปลี่ยนแปลงนี้"
NACK ต้องรวมเหตุผลว่าทำไมการเปลี่ยนแปลงจึงไม่คุ้มค่า NACKs ที่ไม่มีเหตุผลประกอบอาจถูกละเลย
การตรวจสอบโค้ด
หลังจากมีข้อตกลงเชิงแนวคิดเกี่ยวกับการเปลี่ยนแปลง สามารถให้การตรวจสอบโค้ดได้ การตรวจสอบเริ่มต้นด้วย ACK BRANCH_COMMIT โดย BRANCH_COMMIT คือส่วนบนของ PR branch ตามด้วยคำอธิบายว่าผู้ตรวจสอบทำการตรวจสอบอย่างไร ภาษาต่อไปนี้ใช้ภายในความคิดเห็นของ pull request:
"ฉันได้ทดสอบโค้ดแล้ว" ซึ่งเกี่ยวข้องกับการทดสอบด้วยตนเองเฉพาะการเปลี่ยนแปลง นอกเหนือจากการเรียกใช้ unit tests, functional tests หรือ fuzz tests และในกรณีที่ไม่ชัดเจนว่าการทดสอบด้วยตนเองทำอย่างไร ควรมีการอธิบาย
"ฉันยังไม่ได้ทดสอบโค้ด แต่ฉันได้ตรวจสอบแล้วและดูเหมือนจะดี ฉันเห็นด้วยว่าสามารถรวมได้"
"nit" หมายถึงปัญหาเล็กน้อย มักไม่ใช่ปัญหาที่ปิดกั้น
ผู้ดูแลโครงการสงวนสิทธิ์ในการชั่งน้ำหนักความคิดเห็นของผู้ตรวจสอบเพื่อนร่วมงานโดยใช้วิจารณญาณสามัญสำนึกและอาจชั่งน้ำหนักตามความสามารถด้วย ผู้ตรวจสอบที่แสดงให้เห็นถึงความมุ่งมั่นและความเข้าใจที่ลึกซึ้งต่อโครงการเมื่อเวลาผ่านไปหรือผู้ที่มีความเชี่ยวชาญในโดเมนที่ชัดเจนอาจมีน้ำหนักมากขึ้นโดยธรรมชาติ ซึ่งเป็นสิ่งที่คาดหวังได้ในทุกแง่มุมของชีวิต
ในกรณีที่ชุด patch ส่งผลกระทบต่อโค้ดที่สำคัญต่อ consensus เกณฑ์จะสูงขึ้นมากในแง่ของข้อกำหนดในการอภิปรายและการตรวจสอบโดยเพื่อนร่วมงาน โดยคำนึงว่าข้อผิดพลาดอาจมีค่าใช้จ่ายสูงสำหรับชุมชนในวงกว้าง รวมถึงการ refactor โค้ดที่สำคัญต่อ consensus
ในกรณีที่ชุด patch เสนอให้เปลี่ยนแปลง Bitcoin consensus จะต้องมีการอภิปรายอย่างกว้างขวางในรายชื่อเมลและ IRC มี BIP ที่มีการอภิปรายอย่างกว้างขวางและมีฉันทามติทางเทคนิคที่รับรู้กันโดยทั่วไปว่าเป็นการเปลี่ยนแปลงที่คุ้มค่าตามการตัดสินของผู้ดูแล
การหาผู้ตรวจสอบ
เนื่องจากผู้ตรวจสอบส่วนใหญ่เป็นนักพัฒนาที่มีโปรเจกต์ของตัวเองด้วย กระบวนการตรวจสอบจึงอาจใช้เวลาค่อนข้างนาน และต้องใช้ความอดทนพอสมควร หากคุณพบว่าคุณได้รอให้ pull request ได้รับความสนใจเป็นเวลาหลายเดือน อาจมีหลายสาเหตุที่ทำให้เกิดกรณีนี้ ซึ่งบางอย่างคุณสามารถแก้ไขได้:
อาจเป็นเพราะมี feature freeze เนื่องจากกำลังจะมีการ release เวอร์ชันใหม่ ในช่วงเวลานี้ จะพิจารณาเฉพาะการแก้ไขบัก หาก pull request ของคุณเป็นฟีเจอร์ใหม่ จะไม่ได้รับการจัดลำดับความสำคัญจนกว่าจะมีการ release เสร็จสิ้น ให้รอจนกว่าจะมีการ release
อาจเป็นเพราะการเปลี่ยนแปลงที่คุณเสนอไม่เป็นที่สนใจ แทนที่จะได้รับคำวิจารณ์เล็กๆ น้อยๆ ซึ่งแสดงว่าพวกเขาใส่ใจและเต็มใจที่จะใช้เวลากับการมีส่วนร่วมของคุณ ความเงียบที่เกิดขึ้นอาจเป็นสัญญาณที่ดีของการไม่ชอบการเปลี่ยนแปลงนั้นๆ อย่างกว้างขวาง (เพราะคนมักไม่คิดว่าคนอื่นจะไม่ชอบข้อเสนอ) อย่าเอามาเป็นเรื่องส่วนตัว! แทนที่จะทำเช่นนั้น ให้มองอย่างวิเคราะห์อีกครั้งกับสิ่งที่คุณเสนอและดูว่ามันเปลี่ยนแปลงมากเกินไปหรือไม่ กว้างเกินไปหรือไม่ ไม่เป็นไปตาม developer notes หรือไม่ อันตรายหรือไม่ปลอดภัยหรือไม่ เขียนรกรุงรังหรือไม่ ฯลฯ ระบุและแก้ไขปัญหาที่คุณพบ จากนั้นถามความคิดเห็นเกี่ยวกับแนวคิดนั้นบน IRC หรือช่องทางอื่น
อาจเป็นเพราะโค้ดของคุณซับซ้อนเกินไปสำหรับทุกคนยกเว้นไม่กี่คน และคนเหล่านั้นอาจไม่รู้ว่า pull request ของคุณมีอยู่ วิธีที่ดีในการหาคนที่มีคุณสมบัติและสนใจในโค้ดที่คุณแก้ไขคือฟีเจอร์ Git Blame เพียงแค่ดูว่าใครแก้ไขโค้ดที่คุณกำลังเปลี่ยนแปลงล่าสุด และดูว่าคุณสามารถหาพวกเขาและกระตุ้นพวกเขาได้หรือไม่ อย่าพยายามกระตุ้นมากเกินไป
สุดท้าย หากทุกอย่างล้มเหลว ให้ถามบน IRC หรือที่อื่นๆ เพื่อให้มีคนมาดู pull request ของคุณ หากคุณคิดว่าคุณได้รอนานเกินไป (เช่น มากกว่าหนึ่งเดือน) โดยไม่มีเหตุผลเฉพาะ (เปลี่ยนแปลงเพียงไม่กี่บรรทัด ฯลฯ) นี่เป็นเรื่องปกติ พยายามตอบแทนเมื่อคนอื่นขอความคิดเห็นเกี่ยวกับโค้ดของพวกเขา และจักรวาลจะสมดุล
จำไว้ว่าสิ่งที่ดีที่สุดที่คุณสามารถทำในขณะที่รอคือการให้การตรวจสอบแก่ผู้อื่น!
Backporting
การแก้ไขความปลอดภัยและบักสามารถทำ backport จาก master ไปยัง release branches ได้ ผู้ดูแลจะทำ backports เป็นชุดและใช้ป้าย Needs backport (...) ที่เหมาะสมเมื่อจำเป็น (ผู้เขียนเดิมไม่จำเป็นต้องกังวลเกี่ยวกับเรื่องนี้)
backport ควรมี metadata ต่อไปนี้ใน commit body:
ดูตัวอย่าง backport PR ได้ที่ [example backport PR] ดูเพิ่มเติมที่สคริปต์ backport.py
ลิขสิทธิ์
โดยการมีส่วนร่วมในที่เก็บข้อมูลนี้ คุณตกลงที่จะให้สิทธิ์การใช้งานผลงานของคุณภายใต้ใบอนุญาต MIT เว้นแต่จะระบุไว้เป็นอย่างอื่นใน contrib/debian/copyright หรือที่ด้านบนของไฟล์เอง ผลงานใดๆ ที่คุณมีส่วนร่วมโดยที่คุณไม่ใช่ผู้เขียนดั้งเดิมจะต้องมีส่วนหัวใบอนุญาตพร้อมกับผู้เขียนดั้งเดิมและแหล่งที่มา
Last updated