การมีส่วนร่วมแบบไม่เขียนโค้ดต่อโอเพนซอร์ส
(github.com/readme)การมีส่วนร่วมแบบไม่เขียนโค้ดคือเคล็ดลับสู่ความสำเร็จของโอเพนซอร์ส
- ซาราห์ เรนส์เบอร์เกอร์ ซึ่งเป็นครูสอนคณิตศาสตร์ ไม่ได้ตั้งใจจะเป็นผู้มีส่วนร่วมในโอเพนซอร์สโดยสมัครใจตั้งแต่แรก แต่เริ่มเรียนรู้ JavaScript และการพัฒนาเว็บขณะสร้างเว็บไซต์ของคณะนักร้องประสานเสียงของตนขึ้นมาใหม่
- ระหว่างใช้งาน Astro ซึ่งเป็นเฟรมเวิร์กฝั่งฟรอนต์เอนด์ เธอได้มีส่วนร่วมกับโปรเจ็กต์ด้วยโค้ดชิ้นเล็ก ๆ คือไฟล์คอนฟิก และเมื่อเข้าร่วมกับชุมชนก็รับบทช่วยสนับสนุนผู้ใช้ Astro หน้าใหม่
- ปัจจุบัน เรนส์เบอร์เกอร์เป็นสมาชิกของกลุ่มผู้ดูแลหลักของ Astro แต่ไม่ได้เข้าไปเกี่ยวข้องกับโค้ดเบสมากนัก โดยทำงานด้านเอกสารเป็นหลักและช่วยให้ผู้อื่นเรียนรู้ Astro ได้
งานแบบไม่เขียนโค้ดที่สำคัญต่อโปรเจ็กต์โอเพนซอร์ส
- นอกจากการเขียนโค้ดแล้ว โปรเจ็กต์โอเพนซอร์สยังต้องการงานด้านเอกสาร การแปลและปรับให้เข้ากับท้องถิ่น การตลาด กราฟิกดีไซน์ การทดสอบ การดูแลชุมชน และการจัดการรีลีส
- ความสำคัญของการมีส่วนร่วมแบบไม่เขียนโค้ดนั้นสูงมาก และยิ่งโปรเจ็กต์ซับซ้อนมากเท่าไร ก็ยิ่งต้องการเอกสาร บทช่วยสอน และการสนับสนุนมากขึ้น เพื่อทำให้โค้ดเกิดประโยชน์จริง
- กราฟิกดีไซน์ การสร้างแบรนด์ และการทำ outreach ทำหน้าที่เป็นสัญญาณที่บ่งบอกถึงสุขภาพและความจริงจังของโปรเจ็กต์ จนทำให้โปรเจ็กต์อื่นหรือบริษัทต่าง ๆ สามารถนำไปใช้เป็น dependency ได้
เหตุผลที่ควรเริ่มมีส่วนร่วมแบบไม่เขียนโค้ด
- การมีส่วนร่วมแบบไม่เขียนโค้ดเปิดโอกาสให้ผู้ที่สนใจบทบาทซึ่งไม่เกี่ยวกับการเขียนโปรแกรม เช่น การสื่อสารเชิงเทคนิค กราฟิกดีไซน์ และการออกแบบประสบการณ์ผู้ใช้ ได้สร้างพอร์ตโฟลิโอ
- แม้แต่นักเขียนโปรแกรมเองก็ได้ประโยชน์จากการฝึกฝนทักษะการเขียนและการสื่อสาร และอาจช่วยให้เปลี่ยนไปสู่งานอย่าง developer relations หรือ product management ได้
- โปรเจ็กต์โอเพนซอร์สเปิดโอกาสให้คนทุกระดับทักษะเข้ามามีส่วนร่วม และหากยังไม่เข้าใจโปรเจ็กต์อย่างลึกซึ้ง ก็เป็นเรื่องยากที่จะสร้างการมีส่วนร่วมด้านโค้ดที่มีความหมาย
การหาผู้มีส่วนร่วมแบบไม่เขียนโค้ดและการแสดงความขอบคุณ
- สำหรับผู้ดูแลโปรเจ็กต์ วิธีที่ดีที่สุดในการหาผู้มีส่วนร่วมคือการร้องของานที่เฉพาะเจาะจง พร้อมทั้งสร้างชุมชน และเปิด issue ที่ติดแท็ก "help wanted" และ "good first issue" ซึ่งช่วยได้มาก
- การมีพี่เลี้ยงเป็นหนึ่งในวิธีที่ดีที่สุดในการพาผู้มีส่วนร่วมไปสู่ความสำเร็จ และการให้คุณค่าและการยอมรับต่อผู้มีส่วนร่วมแบบไม่เขียนโค้ดก็ช่วยกระตุ้นผู้มีส่วนร่วมปัจจุบันและดึงดูดผู้มีส่วนร่วมใหม่ได้
ความเห็นของ GN⁺
- ประเด็นสำคัญคือความสำเร็จของโปรเจ็กต์โอเพนซอร์สต้องอาศัยการมีส่วนร่วมที่หลากหลาย มากกว่าการเขียนโค้ดเพียงอย่างเดียว ซึ่งเป็นองค์ประกอบสำคัญต่อความยั่งยืนและการเติบโตของโปรเจ็กต์
- การมีส่วนร่วมแบบไม่เขียนโค้ดเปิดโอกาสให้คนที่ไม่ใช่สายเทคนิคสามารถเข้าร่วมโอเพนซอร์สได้ และยังช่วยพัฒนาความสามารถด้านเทคนิคได้ด้วย
- บทความนี้อาจสร้างแรงบันดาลใจให้ผู้ที่สนใจชุมชนโอเพนซอร์ส และช่วยให้ค้นพบวิธีใช้ทักษะของตนเพื่อมีส่วนร่วมกับชุมชนได้
6 ความคิดเห็น
เป็นคนละประเด็นกันเล็กน้อย แต่เมื่อไม่นานมานี้มีคนเอาการส่ง PR ไปยังไฟล์ README ของ Express.js ไปทำเป็นบทสอน เลยมี PR ไร้ความหมายถูกส่งเข้ามาหลายร้อยรายการ
Pull requests · expressjs/express
สร้างความเดือดร้อน.. ฮือ
PR เกิน 100 อันเลยนะเนี่ย สุดยอด
ตอนแรกก็งงอยู่แวบหนึ่งว่าจะมีส่วนร่วมด้วย 'บาร์โค้ด' ได้ยังไง.. ฮ่าๆ
ถ้ามองอีกมุมหนึ่ง การทำเอกสารอย่างละเอียดมากก็อาจเป็นดาบสองคมได้เหมือนกันนะ
อาจเกิดกรณีที่เอกสารกับภาพหน้าจอละเอียดจนเกินกว่าที่นักพัฒนาจะรับมือไหว จนไม่มั่นใจว่าจะอัปเดตเอกสารได้ เลยล้มเลิกการพัฒนาปรับปรุงไปก็ได้..
("ไม่ใช่") โค้ดครับ)
ความเห็นจาก Hacker News
ในฐานะผู้เขียน/ผู้ดูแลไลบรารีขนาดเล็ก ขอยืนยันว่าหากไม่มีการมีส่วนร่วมจากภายนอก คู่มือคงไม่ดีได้เท่าทุกวันนี้ คู่มือมีส่วนอย่างมากต่อการใช้งานโปรเจ็กต์ได้สะดวก
สิ่งที่อยากได้จากโปรเจ็กต์โอเพนซอร์ส:
แม้เอกสารและทรัพยากรต่างๆ จะสำคัญต่อโอเพนซอร์ส แต่ก็อาจมอบอำนาจให้คนที่ไม่ใช่นักพัฒนาจนทำให้โปรเจ็กต์เสียหายได้
การใช้แพลตฟอร์มแชตอย่าง Discord, Gitter และ Slack เป็นเรื่องที่ดีสำหรับการสร้างคอมมูนิตี้
จากประสบการณ์ในคอมมูนิตี้ WordPress คิดว่าการทำเอกสารตั้งแต่ระยะแรกและเอกสารที่แข็งแกร่งของ Codex มีส่วนอย่างมากต่อการเติบโตของ WordPress
สิ่งที่อยากได้ที่สุดจากโปรเจ็กต์โอเพนซอร์สคือให้ผู้คนใช้งานมัน และทิ้งบันทึกเกี่ยวกับสิ่งที่ตนใช้งานไว้ในรูปแบบใดก็ได้
ไม่แน่ใจว่าการมีส่วนร่วมแบบไม่ใช่โค้ดเป็นกุญแจสู่ความสำเร็จของโปรเจ็กต์หรือไม่ แต่เห็นด้วยว่ามันสำคัญมาก
ในกระบวนการเริ่มต้นโปรเจ็กต์โอเพนซอร์ส มีการคาดการณ์ว่าจะมีวิศวกรที่ใช้ซอฟต์แวร์มากกว่าวิศวกรที่ลงมือเขียนโค้ดจริงถึง 10 เท่า
หากคนที่ไม่ใช่สายเทคนิคสามารถเข้าใจโปรเจ็กต์และเห็นคุณค่าได้ นั่นเป็นตัวชี้วัดที่ดีว่าโปรเจ็กต์มีโอกาสประสบความสำเร็จ
เอกสารมีความสำคัญเมื่อผลิตภัณฑ์ยังไม่เป็นที่รู้จักและกำลังก้าวจากช่วงที่มีแต่แฟนๆ ใช้งาน ไปสู่ช่วงที่ต้องหาผู้ใช้เพิ่มขึ้น