วิธีที่ง่ายที่สุดในการเข้าสู่โอเพ่นซอร์ส

บทความนี้มีในภาษาเกาหลีด้วย ขอบคุณ Dohyung Ahn!

Thom Parkin ได้แสดงความคิดเห็นในบทความก่อนหน้าของฉันอย่างดีเยี่ยม:

คำแนะนำที่ดี แต่คุณพลาดจุดหนึ่งที่สำคัญมาก [สุดท้าย] เนื่องจากนี่คือโอเพ่นซอร์ส เมื่อคุณทราบรายละเอียดของคุณลักษณะ/ฟังก์ชันนั้นแล้วซึ่งเอกสารประกอบมีเนื้อหาค่อนข้างน้อย คุณควรอัปเดตเอกสารและส่งคำขอดึง ด้วยวิธีนี้ ชุมชนทั้งหมดจะได้รับประโยชน์ และคุณยังสามารถได้รับ “coder cred” สำหรับการมีส่วนร่วมของคุณ!

ดีใจที่ทอมพูดถึงเรื่องนี้ เพราะมันสำคัญมาก . การแก้ไขเอกสารเป็นวิธีที่ง่ายที่สุดในการเริ่มต้นสนับสนุนโครงการที่คุณใช้และชื่นชอบ

การมีส่วนร่วมครั้งแรกของฉันในโครงการอย่าง Rails, Rubinius และ Elixir ล้วนเป็นการแก้ไขเอกสาร ฉันได้ปรับแต่งเล็กๆ น้อยๆ เพื่อทำให้สิ่งต่างๆ ชัดเจนขึ้น อธิบายบางสิ่งที่คุณสามารถค้นพบได้โดยการอ่านโค้ดเท่านั้น แม้กระทั่งแก้ไขการจัดรูปแบบที่เสียหาย ทั้งหมดนี้เป็นวิธีที่ง่ายและรวดเร็วในการช่วยโครงการโอเพ่นซอร์สขนาดใหญ่บางโครงการ แม้ว่าพวกเขาจะเป็นเพียงผลงานเดียวของฉันในโครงการ พวกเขายังคงช่วยเหลือผู้ใช้ในอนาคตและ Future Me และนั่นคือสิ่งที่เกี่ยวกับโอเพนซอร์ส

เหตุใดการแก้ไขเอกสารจึงเป็นวิธีที่ดีในการเริ่มต้น

การแก้ไขเอกสารเป็นวิธีที่น่ากลัวน้อยที่สุดในการมีส่วนร่วมในโครงการขนาดใหญ่ เช่น Rails:

• คุณไม่จำเป็นต้องตั้งค่าโครงการเพื่อแก้ไขข้อบกพร่อง . เนื่องจากคุณเพิ่งอัปเดตเอกสารประกอบ คุณไม่จำเป็นต้องทำการทดสอบหรือเรียกใช้แอป บางครั้ง คุณไม่จำเป็นต้องโคลนโปรเจ็กต์ไปยังเครื่องด้วยซ้ำ คุณทำการเปลี่ยนแปลงได้บน GitHub!

• หากผู้ดูแลขอให้คุณเปลี่ยนแปลงคำขอดึง มักจะเป็นเรื่องของถ้อยคำหรือรสนิยม . การเปลี่ยนแปลงดังกล่าวสามารถทำได้ง่ายกว่าการวิจารณ์โค้ดของคุณ และการเปลี่ยนแปลงนั้นง่ายกว่าสำหรับคุณ เพราะคุณไม่จำเป็นต้องอัปเดตการทดสอบหรือโค้ด เพียงแค่คำพูด

• เอกสาร ยาก สำหรับผู้ดูแลโปรเจ็กต์ ขอแนะนำให้อัปเดต . บ่อยครั้งที่ผู้เขียนอยู่ใกล้กับโค้ดมากเกินไปที่จะเข้าใจว่าส่วนใดที่ทำให้เกิดความสับสน พวกเขาต้องการนักพัฒนารายอื่นที่ใหม่กว่าเพื่อบอกว่าเอกสารต้องการความช่วยเหลือจากที่ใด ต้องใช้การฝึกฝนในการมองโครงการของคุณในฐานะผู้เริ่มต้น และไม่ใช่ทุกคนที่ได้สร้างทักษะนั้น

• สุดท้าย คุณกำลังเริ่มสร้างความสัมพันธ์กับผู้ดูแล โดยมีการเปลี่ยนแปลงที่มีผลกระทบน้อย . คุณไม่ได้เปลี่ยนทิศทางของโปรเจ็กต์ เช่นเดียวกับที่คุณทำหากคุณมีส่วนร่วมในฟีเจอร์ทั้งหมด เพื่อให้ผู้ดูแลตรวจสอบการเปลี่ยนแปลงของคุณได้ง่ายขึ้น และมักจะตอบกลับคุณเร็วขึ้น คำขอรวมของคุณจะไม่ค้างอยู่ในส่วน "นี่เป็นความคิดที่ดีหรือไม่" เฟส.

ในขณะที่คุณสร้างความสัมพันธ์นั้นต่อไป คุณจะเริ่มถูกมองว่าเป็นผู้มีส่วนร่วมที่เชื่อถือได้ คำขอดึงของคุณจะได้รับการตรวจสอบเร็วขึ้น และคุณทั้งคู่จะพูดคุยถึงคำขอฟีเจอร์ที่ซับซ้อนและการแก้ไขข้อบกพร่องได้ง่ายขึ้น

เริ่มง่ายกว่า ทำง่ายกว่า และมักจะรวมเข้าด้วยกันเร็วกว่า เหตุใดการบริจาคครั้งแรกของคุณจึงไม่เป็นการแก้ไขเอกสาร

วิธีเริ่มส่งเอกสารที่อัปเดตกลับคืน

มีวิธีที่สำคัญในการสนับสนุนการอัปเดตเอกสารเหมือนกับการแก้ไขข้อบกพร่อง:ทั้งคู่พึ่งพาความอ่อนไหวต่อสิ่งที่รู้สึกผิด . คุณต้องให้ความสนใจ

เมื่อคุณพบพฤติกรรมที่คุณไม่คาดคิด อาจถึงเวลาที่ต้องอัปเดตเอกสาร หากคุณต้องดำดิ่งลงไปในโค้ดเพื่อแก้ปัญหา คุณอาจต้องการบอกคนอื่นเกี่ยวกับเรื่องนี้ด้วย คุณควรมีความอ่อนไหวต่อการจัดรูปแบบที่ไม่สมบูรณ์และการพิมพ์ผิดในเอกสารที่คุณอ่าน ถ้าคุณไม่คิดจะแก้ไข ใครจะแก้ไข

เมื่อคุณมีความคิดที่ดีแล้วว่าจะเปลี่ยนแปลงที่ไหนและต้องการใช้ถ้อยคำอย่างไร ให้ทำการเปลี่ยนแปลงและส่งคำขอดึงผ่าน GitHub

หากคุณยังคงตัดสินใจเกี่ยวกับวิธีที่ดีที่สุดในการอัปเดตเอกสาร ให้เปิดปัญหาใน GitHub อาจเป็นดังนี้:

“เฮ้ สิ่งนี้ทำให้ฉันสับสน ฉันกำลังคิดที่จะอัปเดตให้มีลักษณะดังนี้:… คุณคิดอย่างไร มีอะไรที่ฉันควรพูดถึงอีกไหม?” คุณสามารถสร้างถ้อยคำที่ถูกใจทุกคนได้

สุดท้าย อย่าท้อแท้หากคุณไม่ได้รับคำตอบ โปรเจ็กต์ขนาดใหญ่มีจำนวนมากที่กำลังดำเนินอยู่ ดังนั้นจึงเป็นเรื่องง่ายสำหรับการมีส่วนร่วมของคุณที่จะหลุดพ้นจากรอยแตกร้าว ในหนึ่งสัปดาห์หรือประมาณนั้น หากคุณยังไม่ได้รับการติดต่อจากใครเลย ให้ถามผู้ดูแลอีกครั้ง .

เอกสารมักจะเป็นสิ่งแรกที่คุณพบเมื่อคุณทำงานกับห้องสมุด ดังนั้นจึงเป็นเรื่องสำคัญที่ต้องมีรายละเอียดและชัดเจน

ดังนั้นเมื่อคุณสับสนเกี่ยวกับรหัสที่คุณใช้หรือต้องเจาะลึกถึงแหล่งที่มา ให้ทำให้มันง่ายขึ้นสำหรับบุคคลต่อไป เขียนการอัปเดตอย่างรวดเร็วและสนับสนุนกลับ เป็นวิธีที่ง่ายที่สุดที่ฉันรู้จักในการเป็นผู้สนับสนุนโอเพนซอร์ส

เดิมทีบทความนี้ถูกส่งถึงคนที่อยู่ในรายชื่อของฉัน หากต้องการอ่านเพิ่มเติม ลงชื่อสมัครใช้ที่นี่!