บทความนี้มีภาษาเกาหลีด้วย ขอบคุณ Dohyung Ahn!
Thom Parkin ทำจุดสำคัญใน comments บทความก่อนหน้าของผม:
คำแนะนำดี แตคุณพลาดจุดสำคัญ [สุดท้าย] หนึ่งจุด เนื่องจากเป็น Open Source เมื่อคุณเข้าใจรายละเอียดของ feature/function ที่ documentation น้อย คุณ ควร อัปเดต DOCS และ SUBMIT PULL REQUEST ดังนั้นชุมชนทั้งหมดได้ประโยชน์ และคุณได้ "coder cred" จากการมีส่วนร่วม!
ผมยินดีที่ Thom กล่าวถึง เพราะมันสำคัญมาก การแก้ documentation เป็นวิธีง่ายที่สุดเริ่ม contribute กลับไปให้ projects ที่คุณใช้และชอบ
การ contribute ครั้งแรกของผมไปยัง projects เช่น Rails, Rubinius, Elixir ทั้งหมดเป็น doc fixes ทำ tweaks เล็กๆ ให้ชัดเจน อธิบายสิ่งที่ค้นพบได้แค่จากการอ่านโค้ด แค่แก้ broken formatting ทั้งหมดเป็นวิธีเร็ว ง่าย ช่วย projects ใหญ่ แม้จะเป็น contribution เดียวของผมใน project นั้น ก็ยังช่วย future users และ Future Me และนั่นคือ open source ทั้งหมด
ทำไม Doc Fixes จึงเป็นวิธีเริ่มที่ดี
Doc fixes เป็นวิธีที่ intimidating น้อยที่สุด contribute ไปยัง project ใหญ่ เช่น Rails:
ไม่ต้อง setup project เพื่อแก้ bug เนื่องจากแค่ update documentation ไม่ต้องรัน tests หรือ app บางครั้งแตก clone project ไม่ต้อง - แก้ได้บน GitHub เลย!
ถ้า maintainer ขอแก้ pull request มักเป็นเรื่อง wording หรือรสนิยม การเปลี่ยนแปลงแบบนี้ทนง่ายกว่าการ criticize โค้ด และแกง่ายกว่า เพราะไม่ต้อง update tests หรือ code แค่คำศัพท์
Documentation ยาก สำหรับ maintainer ดังนั้น updates จึงได้รับการชื่นชม บ่อยครั้ง authors ใกล้โค้ดเกินไปจนไม่เห็นจุดสับสน พวกเขาต้องการ newer developers บอกว่า docs ต้องช่วยที่ไหน ต้องฝึกดู project จากมุมมอง beginner ไม่ทุกคนมี skill นี้
สุดท้าย คุณเริ่มสร้างความสัมพันธ์กับ maintainer ด้วย low-impact change ไม่ได้เปลี่ยนทิศทาง project เหมือน contribute feature ใหญ่ ดังนั้น change ง่ายต่อการ review และ maintainer มักตอบเร็ว PR ไม่ติดใน phase "Is this a good idea?"
พอสร้างความสัมพันธ์ต่อ คุณจะเริ่มถูกมองว่า reliable contributor PRs จะได้ review เร็วขึ้น และทั้งคู่คุย feature requests และ bug fixes ที่ซับซ้อนได้ง่ายขึ้น
เริ่มง่าย ทำง่าย merge เร็ว ทำไม first contribution ไม่ใช่ doc fix?
เริ่ม Contribute Documentation ที่อัปเดตแล้ว
มีวิธีสำคัญที่ contribute doc updates คล้าย fix bugs: ทั้งคู่พึ่งพา sensitivity ต่อสิ่งที่รู้สึกผิด ต้องให้ความสนใจ
เวลาเจอพฤติกรรมที่คาดไม่ออก อาจถึงเวลา update docs ถ้าต้องดำดิ่งลง code เพื่อแก้ปัญหา อาจอยากบอกคนอื่นด้วย ควร sensitive กับ broken formatting และ typos ใน documentation ที่อ่าน ถ้าคุณไม่แก้ ใครจะแก้?
พอมี idea ชัดเจนว่าจะแก้ที่ไหน และ wording ยังไง ทำการเปลี่ยนแปลงและส่ง pull request ผ่าน GitHub
ถ้ายังตัดสินใจไม่ได้ว่า update docs ยังไง ดีที่สุด เปิด issue บน GitHub อาจเป็นแบบนี้:
"Hey, นี้สับสนผม เห็นว่าจะ update ให้เป็นแบบนี้: … คิดยังไง? มีอะไรควรเพิ่มไหม?" พร้อมกันหา wording ที่ทำให้ทุกพอใจ
สุดท้าย อย่าผิดหวังถ้าไม่ได้ response Projects ใหญ่มีอะไรเยอะ contribution อาจหลุดรอย ในหนึ่งสัปดาห์ ถ้ายังไม่มีข่าว ถาม maintainer อีกครั้ง
Documentation มักเป็นสิ่งแรกที่เจอตอนทำงานกับ library จึงสำคัญที่จะ detailed และ clear
ดังนั้นเวลาสับสนกับโค้ดที่ใช้ หรือต้องดำดิ่งลง source ทำให้คนต่อไปง่ายขึ้น เขียน quick update และ contribute กลับ นี่คือวิธีง่ายที่สุดที่ผมรู้จักให้กลายเป็น open source contributor
บทความนี้ส่งไปให้คนใน list เดิม สมัครรับ email เหล่านี้ทุกวันศุกร์ได้ที่นี่!
