Skip to content

เตรียมโปรเจกต์ให้คนจากภายนอกสามารถมาร่วม Contribute ได้ ​

ตอนที่เราประชุมเรื่องการพัฒนาเว็บ ELECT Live! ตอนแรกมีคนที่จะทำ Frontend อยู่แค่ประมาณ 5–6 คนเอง

แต่เนื่องด้วยเวลาที่มีเพียง 8 วันก่อนถึงวันเลือกตั้งและนับคะแนน เราจึงเลือกทำให้โปรเจกต์นี้เป็น Open source และทำให้คนสามารถมาช่วยร่วมมือพัฒนาได้ง่าย สุดท้ายแล้วเรามีผู้ร่วมพัฒนาหน้า Frontend ของ ELECT Live! กว่า 20 คน

แต่การทำโปรเจกต์ Open source ไม่ใช่ว่าแค่ปล่อยโค้ดไปบน GitHub แล้ว คนจะเข้ามาร่วมพัฒนาเลย… ถ้าเกิดเข้ามาที่หน้าโปรเจกต์บน GitHub ครั้งแรก แล้วเจอแต่รายชื่อไฟล์แบบนี้​…

…ก็งงไปสิครับ แล้วก็คงกดปิดออกมา

เราจึงทำการเตรียมโปรเจกต์ ELECT Live! ให้คนภายนอกสามารถเข้ามาร่วมพัฒนาได้ โดยการทำหลายๆ อย่าง…

ตั้งเป้าหมายเพื่อสร้างคุณค่าให้ทุกคนที่ผ่านเข้ามา ​

ไหนๆ จะทำโปรเจกต์ให้เป็น Open source ทั้งที ก็เลยกำหนดเป้าหมายสำหรับโปรเจกต์นี้ไว้ว่า…

  1. อยากให้คนที่ร่วมพัฒนาโปรเจกต์นี้ ทั้งในทีมและจากภายนอก ได้เทคนิค เครื่องมือ วิธีการ และแนวคิด ต่างๆ กลับไป และสามารถไปใช้ในงานของตัวเอง
  2. ถึงอาจจะไม่ได้ส่งโค้ดเข้ามา แต่อย่างน้อยก็ควรจะได้ประโยชน์จากการศึกษาโค้ด หรือแนวคิดต่างๆ ของโปรเจกต์นี้
  3. อยากจะเปิดโอกาสให้นักพัฒนาภายนอก สามารถเข้ามาช่วยร่วมพัฒนาได้โดยง่าย

เตรียมคู่มือสำหรับนักพัฒนาใหม่ ​

ไม่ใช่นักพัฒนาทุกคนที่จะรู้เทคนิคต่างๆ ที่เราใช้กันในโปรเจกต์ทั้งหมด จึงเป็นเรื่องที่สำคัญมากที่จะเขียนไว้ในไฟล์ README ให้ชัดเจน ว่าหากต้องการจะร่วมพัฒนาโปรเจกต์นี้ให้ทำยังไง

บางทีมีน้องทักแชทมาถาม ว่าหลังจากโคลนโปรเจกต์มาแล้วทำยังไงต่อ นั่นแปลว่า README ยังเขียนไม่เข้าใจง่ายพอ หลังจากที่ตอบผมก็ไปอัพเดตไฟล์ README ให้ชัดเจนยิ่งขึ้น

แบ่งงานเป็นงานเล็กๆ หางานที่ทำง่ายๆ แล้วปล่อยให้คนที่สนใจมาช่วยทำดู ​

หากผมเป็นนักพัฒนาที่อยากจะลองมาช่วยพัฒนา Open source แล้วกดหน้า Issue เข้าไป แล้วเจอแต่ Issue ยากๆ ที่ต้องใช้เวลาทำนานๆ ก็อาจจะรู้สึกหมดแรงตั้งแต่ยังไม่ได้เริ่ม

เนื่องจากเราใช้ PDD เราจึงสามารถย่อยงานจนเหลืองานที่เล็กมากๆ ทำไม่ยาก แต่ต้องการคนทำ เช่น

เวลาผมทำงานแล้วเจอกับงานละเอียดพวกนี้ แทนที่จะทำมันไปเลย (ซึ่งอาจจะใช้เวลาหลายนาที เพราะเป็นงานละเอียด) ผมใส่ // @todo เข้าไปแทน แล้วก็เขียนคำอธิบายใน Issue หรืออัพโหลดภาพ Design เพิ่มเติม หลังจากนั้นก็ใส่ label “help wanted” และสำหรับ Issue ที่คิดว่าถึงเป็นคนภายนอกก็สามารถทำได้ไม่ยาก ก็จะใส่ label “good first issue” เข้าไป ระหว่างนั้นผมก็สามารถไปทำงานส่วนอื่นที่สำคัญและเร่งด่วนกว่า

เมื่อผมมี Issue ที่เป็น “good first issue” จำนวนหนึ่งแล้ว ก็เริ่มเชิญชวนเพื่อนครับ…

  • เพื่อนบางคนที่อาจจะยังเขียนโค้ดไม่ค่อยแข็ง และอยากฝึกฝีมือการเขียนโค้ดกับโปรเจกต์ที่ใช้งานจริงๆ
  • เพื่อนบางคนที่อาจจะทำงานแล้วอยู่แต่กับ Stack เดิมๆ ไม่มีโอกาสได้มาลองเล่นกับ Stack ใหม่ๆ ครั้นจะลองเองก็ต้องใช้เวลาเยอะ และไม่รู้จะหาคำแนะนำจากไหน
  • เพื่อนบางคนที่อาจจะอยากลองเริ่ม Contribute ให้โปรเจกต์ Open source แต่ไม่รู้ว่าจะเริ่มต้นยังไงดี
  • …หรือคนอื่นๆ ที่ผมอาจจะไม่รู้จักด้วยซ้ำ

ทำให้คนรู้สึกดีเมื่อเข้ามาร่วมพัฒนา ​

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

1. ตั้งโจทย์บนปัญหาที่คนจำนวนมากสนใจและได้รับผลกระทบ ​

"... you're not just trying to solve problems. You're trying to solve problems that [people] care about." (Paul Graham, 2004)

เมื่อโจทย์คือ “ทำอย่างไรให้คนทั่วไปสามารถติดตามผลการเลือกตั้ง และวิเคราะห์ผลการเลือกตั้งได้ด้วยตนเอง” ทำให้ความร่วมมือไม่ต้องยึดติดกับ technology stack ใดๆ เปิดโอกาสให้นักพัฒนาที่หลากหลายเข้ามามีส่วนร่วมได้ ไม่ว่าจะเป็น frontend, backend, designer, data scientist ไปจนถึงนักกฎหมายและสื่อมวลชน

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

2. มีภาพเป้าหมาย และ deadline ที่ชัดเจนและกระชั้นชิด 😂 ​

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

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

3. เห็นผลลัพธ์ทันท่วงที (quick wins) ​

พอตัวโปรเจกต์ถูกตั้งขึ้นมาให้ deploy ได้ง่าย ไม่นานหลังจาก PR ถูก approve และ merge เราก็จะเห็นความเปลี่ยนแปลงนั้นบน production ทันที ทำให้ผู้ร่วมพัฒนารู้สึกว่าสิ่งที่เขาช่วยทำเกิดผลลัพธ์จริงๆ แถมยังสามารถแชร์กับเพื่อนๆ ได้ว่าได้เข้ามาร่วมโปรเจกต์นี้ ทำให้โปรเจกต์ได้ PR value ไปในตัวด้วย

4. เห็นผู้เข้าร่วมที่เป็นที่รู้จักหรือได้รับการยอมรับ ​

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

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

5. ได้รับเครดิตจากผลงานที่ทำ ​

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