• Before writing a patch, developer

• Before writing a patch, developers should first make sure that it indeed addresses an issue within the project’s scope and relevant to the project’s focus (Section III-A).
• Instead of solely focusing on whether the patch fixes the target bug, developers should also be careful of not introducing new bugs, which will be expensive in terms of patch review efforts and the long-term maintainability of the project (Section IV-B).
• Instead of solely focusing on whether the patch works, developers should also consider whether it works well and whether there are better alternative solutions. Patch reviewers appear to be more serious about suboptimal patches than patch writers expect (Section IV-A).
• Developers should check whether their patches are “more” or “less”: “more” as in including unnecessary or irrelevant changes and “less” as in not including certain use cases and being incomplete(SectionIII-A).
• Developers should include or update necessary documentation in their patches. For reviewers, a patch with inconsistent or misleading documentation is highly unacceptable (Section III-B).
• Developers should minimize the high-level impact of a patch on the project schedule and avoid delaying the development of other features (Section III-A).
• Developers should actively communicate with other team members before and after submitting their patches, which increases the chance of the patches being accepted (Section III-A).

ผลลัพธ์ (ไทย) 1:

•ก่อนการเขียนโปรแกรม นักพัฒนาควร first ทำให้แน่ใจว่า มันจริงอยู่ประเด็นภายในขอบเขตของโครงการ และเกี่ยวข้องกับความสำคัญของโครงการ (ส่วนที่ III-A) •แทนเท่านั้นเน้นว่า fixes แก้ไขข้อผิดพลาดเป้าหมาย นักพัฒนาควรจะต้องระวังไม่แนะนำข้อบกพร่องใหม่ ซึ่งจะแพงความพยายามตรวจทานแก้ไขและ maintainability ระยะยาวของโครงการ (ส่วน IV-B) •แทนเท่านั้นเน้นว่าการทำงานของโปรแกรมปรับปรุง พัฒนาควรว่าทำงาน ดี และว่ามีวิธีอื่นดีกว่า ผู้ตรวจทานแก้ไขจะ จะรุนแรงมากขึ้นเกี่ยวกับการปรับปรุงสภาพกว่าเขียนโปรแกรมปรับปรุงที่คาดไว้ (ส่วน IV-A) •นักพัฒนาควรตรวจสอบว่า ซอฟต์แวร์ของพวกเขาจะ "เพิ่มเติม" หรือ "น้อย": "เพิ่มเติม" ในรวมทั้งไม่จำเป็น หรือเกี่ยวข้องกับการเปลี่ยนแปลง และ "น้อย" ในไม่รวมบางกรณีการใช้และการ incomplete(SectionIII-A) •นักพัฒนาควรรวม หรือปรับปรุงเอกสารที่จำเป็นในการปรับปรุง สำหรับผู้ตรวจทาน แพทช์กับเอกสารเหมือนเดิม หรืออาจจะไม่สามารถยอมรับสูง (ส่วน III-B) •นักพัฒนาควรลดผลกระทบของโปรแกรมปรับปรุงตามกำหนดการโครงการระดับสูง และหลีกเลี่ยงการล่าช้าการพัฒนาคุณลักษณะอื่น ๆ (ส่วนที่ III-A) •พัฒนาควรกำลังสื่อสารกับสมาชิกอื่น ๆ ในทีมก่อน และ หลังการส่งซอฟต์แวร์ของพวกเขา ซึ่งเพิ่มโอกาสของการปรับปรุงผ่านการยอมรับ (ส่วนที่ III-A)

ผลลัพธ์ (ไทย) 2:

•ก่อนที่จะเขียนแพทช์นักพัฒนาควร fi แรกตรวจสอบให้แน่ใจว่ามันแน่นอนอยู่เป็นปัญหาอยู่ในขอบเขตของโครงการและที่เกี่ยวข้องกับการมุ่งเน้นของโครงการ (มาตรา III-A).
•แทนการ แต่เพียงผู้เดียวโดยมุ่งเน้นที่ว่าสายแพทช์ Xes ข้อผิดพลาดเป้าหมายที่นักพัฒนาควร นอกจากนี้ยังต้องระวังไม่แนะนำข้อบกพร่องใหม่ซึ่งจะมีราคาแพงในแง่ของความพยายามในการตรวจสอบแพทช์และการบำรุงรักษาในระยะยาวของโครงการ (มาตรา IV-B).
•แทนการ แต่เพียงผู้เดียวโดยมุ่งเน้นที่ไม่ว่าจะเป็นผลงานของแพทช์ที่นักพัฒนาควรพิจารณา ไม่ว่าจะทำงานได้ดีและไม่ว่าจะมีทางเลือกที่ดีกว่าการแก้ปัญหา แสดงความคิดเห็นที่แพทช์ดูเหมือนจะรุนแรงมากขึ้นเกี่ยวกับแพทช์ด้อยกว่านักเขียนแพทช์คาดหวัง (มาตรา IV-A).
•นักพัฒนาควรตรวจสอบว่าแพทช์ของพวกเขา "มากกว่า" หรือ "น้อย": "มากขึ้น" ในขณะที่รวมทั้งการเปลี่ยนแปลงที่ไม่จำเป็นหรือไม่เกี่ยวข้องและ "น้อย "ในขณะที่ไม่รวมถึงกรณีการใช้งานบางอย่างและความไม่สมบูรณ์ (SectionIII-A).
•นักพัฒนาควรมีการปรับปรุงหรือเอกสารที่จำเป็นในแพทช์ของพวกเขา สำหรับการแสดงความคิดเห็นที่แพทช์ที่มีเอกสารที่ไม่สอดคล้องกันหรือทำให้เข้าใจผิดเป็นที่ยอมรับไม่ได้สูง (มาตรา III-B).
•นักพัฒนาควรลดผลกระทบระดับสูงของแพทช์ในกำหนดการของโครงการและหลีกเลี่ยงการล่าช้าในการพัฒนาของคุณสมบัติอื่น ๆ (มาตรา III-A) .
นักพัฒนา•ควรแข็งขันในการติดต่อสื่อสารกับสมาชิกในทีมอื่น ๆ ก่อนและหลังการส่งแพทช์ของพวกเขาซึ่งจะเป็นการเพิ่มโอกาสของแพทช์ที่ได้รับการยอมรับ (มาตรา III-A)

ผลลัพธ์ (ไทย) 3:

- ก่อนที่จะเขียนแพทช์ , นักพัฒนาควรจึงตัดสินใจเดินทางไปตรวจสอบให้แน่ใจว่ามันมีปัญหาจริงที่อยู่ภายในขอบเขตของโครงการและที่เกี่ยวข้องกับโฟกัสของโครงการ ( ส่วน iii-a )
- แทนเพียงเน้นว่าแพทช์จึงกแมลงเป้าหมาย นักพัฒนาควรระมัดระวังไม่แนะนำข้อบกพร่องใหม่ซึ่งจะแพงในแง่ของแพทช์ทบทวนความพยายามและ maintainability ระยะยาวของโครงการ ( มาตรา IV - B )
- แทนเพียงเน้นว่า งานปะ , นักพัฒนาควรพิจารณาว่า มันใช้งานได้ดี และไม่ว่าจะมีโซลูชั่นทางเลือกที่ดีกว่า แก้ไขความคิดเห็นที่ปรากฏจะร้ายแรงมากเกี่ยวกับแพทช์ suboptimal กว่านักเขียนแพทช์คาดว่า ( มาตรา iv-a )
- นักพัฒนาควรตรวจสอบว่าซอฟต์แวร์ของตน " มากกว่า " หรือ " น้อยกว่า " : " มากกว่า " ที่เป็นรวมทั้งการเปลี่ยนแปลงที่ไม่จำเป็นหรือที่ไม่เกี่ยวข้องและ " น้อย " ใน ไม่รวมกรณีการใช้ที่แน่นอน และการไม่สมบูรณ์ ( sectioniii-a )
- นักพัฒนาควรรวมหรือปรับปรุงเอกสารที่จําเป็นในซอฟต์แวร์ของพวกเขา สำหรับผู้ตรวจทานแพทช์ด้วยที่ไม่สอดคล้องกันหรือทำให้เข้าใจผิดเอกสารขอรับไม่ได้ ( มาตรา iii-b )
- นักพัฒนาควรลดผลกระทบระดับสูงของแพทช์ในโครงการ กำหนดการ และหลีกเลี่ยงการชะลอการพัฒนาคุณสมบัติอื่น ๆ ( ส่วน iii-a )
- นักพัฒนาควรงานสื่อสารกับสมาชิกในทีมอื่น ๆก่อนและหลังการส่งซอฟต์แวร์ของพวกเขาซึ่งจะเพิ่มโอกาสของการได้รับการยอมรับ ( แพทช์

ส่วน iii-a )