ความท้าทายหลักของโครงการโอเพนซอร์สคือการหาวิธีทำงานร่วมกันของผู้มีส่วนร่วมที่ดีที่สุด
หนึ่งในความท้าทายหลักที่โครงการโอเพนซอร์สต้องเผชิญคือการสื่อสารระหว่างผู้มีส่วนร่วม มีตัวเลือกมากมาย: ฟอรั่ม ช่องแชท ปัญหา รายการอีเมล คำขอดึง ฯลฯ เราควรเลือกใช้อันไหนที่เหมาะสม และเราจะทำอย่างไร?
น่าเสียดายที่โครงการมักไม่เต็มใจตัดสินใจอย่างเด็ดขาด แต่เลือก “ทั้งหมดข้างต้น” นี่นำไปสู่ชุมชนที่แตกสลาย: บางคนใช้ Slack/Mattermost/IRC บางคนใช้ฟอรั่ม บางคนใช้รายการอีเมล บางคนอยู่ในปัญหา มีคนน้อยมากที่อ่านเนื้อหาจากทุกช่องทางเหล่านี้
ในองค์กรที่ฉันช่วยสร้างชุมชนภายในและภายนอก นี่เป็นปัญหาทั่วไป เราจะเลือกช่องทางใด และเพื่อวัตถุประสงค์อะไร? นอกจากนี้ เมื่อไหร่ที่ควรปฏิเสธพวกเขาอย่างใดอย่างหนึ่ง?
นี่คือสิ่งที่ฉันต้องการสำรวจอย่างลึกซึ้งที่นี่
โครงสร้างและไม่มีโครงสร้าง
ฉันไม่ใช่คนฉลาด ดังนั้นฉันมักแบ่งปัญหาออกเป็นส่วนเล็กๆ เพื่อให้เข้าใจได้ดีขึ้น ในทำนองเดียวกัน ฉันมักแยกย่อยตัวเลือกต่างๆ ในสถานการณ์หนึ่งออกเป็นส่วนเล็กๆ เพื่อเข้าใจวัตถุประสงค์ของพวกมันดีขึ้น ฉันใช้วิธีนี้กับการเลือกช่องทางการสื่อสารเช่นกัน
ฉันคิดว่ามีช่องทางการสื่อสารสองประเภทหลัก: โครงสร้างและไม่มีโครงสร้าง
ช่องทางโครงสร้างมีจุดเน้นเฉพาะเจาะจงมากในแต่ละหน่วยการสื่อสาร ตัวอย่างเช่น ปัญหา ของ GitHub / GitLab / Jira ปัญหาหนึ่งเป็นข้อมูลเฉพาะเจาะจงมากเกี่ยวกับบั๊กหรือฟีเจอร์ หลังจากโพสต์ปัญหาเริ่มต้นแล้ว การสนทนาที่ตามมามักมุ่งเน้นไปที่หัวข้อเฉพาะนั้นมาก และจะมีผลลัพธ์ (เช่น การแก้ไขบั๊กหรือแผนฟีเจอร์ขั้นสุดท้าย) ผลลัพธ์มักสะท้อนในสถานะ (เช่น “FIXED”, “WONTFIX” หรือ “INVALID”) นี่หมายความว่าคุณสามารถเข้าใจจุดเริ่มต้นและจุดสิ้นสุดของการสื่อสารโดยไม่ต้องอ่านเนื้อหาตรงกลาง
ในทำนองเดียวกัน คำขอดึง / คำขอผสานก็มีโครงสร้างเช่นกัน พวกมันมุ่งเน้นไปที่การมีส่วนร่วมประเภทเฉพาะ (มักเป็นโค้ด) หลังจาก คำขอดึง / คำขอผสานเริ่มต้น การสนทนาจะมุ่งเน้นไปที่ผลลัพธ์มาก: ทำให้การมีส่วนร่วมตรงตามข้อกำหนดและผสานเข้ากับคลังโค้ด
อีกตัวอย่างหนึ่งคือโพสต์ถามตอบเช่น StackOverflow/AskBot โพสต์เหล่านี้เริ่มต้นด้วยคำถาม จากนั้นถูกแก้ไขและตอบเพื่อให้คำตอบที่แม่นยำสำหรับคำถามนั้น
ผ่านกลไกโครงสร้างเหล่านี้ มักจะไม่เบี่ยงเบนจากโครงสร้างเดิม คุณจะไม่เห็นใครถามคนอื่นในปัญหา คำขอดึง หรือหัวข้อถามตอบว่าลูก/แมว/สุนัข/ครอบครัวของพวกเขาทำอะไรอยู่ การเบี่ยงเบนหัวข้อเป็นสิ่งที่ยอมรับไม่ได้ในชุมชน นี่เป็นส่วนหนึ่งของพลังของสื่อโครงสร้าง: มันมุ่งเน้นและ (มัก) มีประสิทธิภาพ
ในทางกลับกัน สื่อไม่มีโครงสร้างรวมถึงช่องแชทและฟอรั่ม ในสภาพแวดล้อมเหล่านี้ มักจะมีหัวข้อ (เช่น หัวข้อของช่องหรือฟอรั่มย่อย) แต่การสนทนามีความสัมพันธ์กับผลลัพธ์หรือข้อสรุปเฉพาะน้อยกว่ามาก และโดยทั่วไปอาจกว้างขวางกว่า ตัวอย่างเช่น ในรายการอีเมลนักพัฒนา คุณจะเห็นการสนทนาหลากหลายรวมถึงคำถามทั่วไป ความคิดสำหรับฟีเจอร์ใหม่ การโต้เถียงเรื่องสถาปัตยกรรม และการสนทนาที่เกี่ยวข้องกับการดำเนินงานของชุมชนเอง แต่ละการสนทนาหวังว่าผู้เข้าร่วมจะรักษาการสนทนาให้มุ่งเน้น มีหัวข้อ และมีประสิทธิภาพในการทำงาน แต่คุณสามารถจินตนาการได้ว่า สถานการณ์มักไม่เป็นเช่นนั้น การสนทนาอาจเบี่ยงเบนจากผลลัพธ์ที่เป็นประโยชน์
ผลกระทบของการบันทึก
นอกจากความแตกต่างที่ละเอียดอ่อนระหว่างการสื่อสารแบบโครงสร้างและไม่มีโครงสร้างแล้ว ผลกระทบจากสิ่งที่บันทึกและวิธีค้นหาก็สำคัญเช่นกัน
โดยทั่วไป ช่องทางโครงสร้างทั้งหมดถูกบันทึก ผู้คนสามารถอ้างอิงบั๊กในอดีต คำถามจาก StackOverflow สามารถถูกนำกลับมาใช้ซ้ำได้ คุณสามารถค้นหาสิ่งต่างๆ แม้จะมีการสนทนา คำถามที่พบบ่อย คำขอดึง หรือคำถามมากมาย พวกมันจะถูกอัปเดตเพื่อสะท้อนข้อสรุปสุดท้าย
นี่เป็นจุดสำคัญ: เราต้องการขุดปัญหาเก่า/คำถาม/คำขอดึง ฯลฯ ได้อย่างรวดเร็วและง่ายดาย และเชื่อมโยงและอ้างอิงพวกมัน ส่วนสำคัญอย่างหนึ่งที่นี่คือเราแปลงเนื้อหานี้เป็นวัสดุที่สามารถอ้างอิงได้ ซึ่งสามารถใช้เพื่อศึกษาและแจ้งผู้คนเกี่ยวกับความรู้ในอดีต เมื่อชุมชนเติบโต การสื่อสารแบบโครงสร้างของเรากลายเป็นคลังความรู้ที่สามารถแจ้งอนาคตจากประสบการณ์ในอดีต
ในขณะที่การสื่อสารแบบไม่มีโครงสร้างแย่ลงเรื่อยๆ ในแง่หนึ่ง การค้นหาฟอรั่มมักง่ายและมีประสิทธิภาพ แต่พวกมันเต็มไปด้วยการสนทนาที่ไม่มีโครงสร้าง ดังนั้นสิ่งที่คุณกำลังมองหาอาจถูกฝังอยู่ในการสนทนา ตัวอย่างเช่น ชุมชนหลายแห่งใช้ฟอรั่มเป็นเครื่องมือสนับสนุน แม้นี่เป็นแพลตฟอร์มที่แข็งแกร่งกว่า แต่ปัญหาคือคำตอบสำหรับคำถามหนึ่งอาจอยู่ในชั้นความคิดเห็นที่ 16 หรือ 340 เมื่อมีข้อมูลมากขึ้นจากแหล่งต่างๆ (เช่น Twitter) เรามีความอดทนน้อยลงในการอ่านวัสดุจำนวนมาก นี่อาจเป็นปัญหาสำหรับสื่อที่ไม่มีโครงสร้าง
กรณีพิเศษที่น่าสนใจคือการแชทแบบเรียลไทม์ ในประวัติศาสตร์ เป็นเวลาหลายปี IRC เป็นเส้นทางสำหรับการแชทแบบเรียลไทม์ สำหรับผู้ใช้ IRC ส่วนใหญ่ มีความคิดเรื่องการบันทึกการสนทนาเหล่านี้น้อยมาก (ถ้ามี) จริงๆ แล้ว โครงการบางโครงการ (เช่น Ubuntu) บันทึกบันทึก IRC แต่โดยทั่วไปนี่ไม่ใช่ทรัพยากรที่มีประโยชน์ ดังที่เพื่อน Atwood ของฉันเคยบอกว่า: “ถ้าคุณต้องค้นหาสิ่งบางอย่างในการแชท คุณแพ้แล้ว”
แม้ว่า IRC จะมีข้อบกพร่องในการบันทึก แต่ Slack และ Mattermost ดีกว่า การสื่อสารจะถูกเก็บถาวร แต่ปัญหายังคงอยู่: ทำไมคุณต้องการค้นหาจุดที่คนๆ หนึ่งเสนอในข้อความแชทจำนวนมาก? ช่องทางอื่นสามารถอ้างอิงการสนทนาก่อนหน้าได้ดีกว่า
อย่างไรก็ตาม นี่สร้างโอกาสที่น่าสนใจ การแชทมีข้อดีอย่างสม่ำเสมอเหนือสื่ออื่นคือแสดงให้เห็นว่าคนๆ นี้เป็นอย่างไร ช่องทางโครงสร้าง แม้แต่ช่องทางที่ไม่มีโครงสร้างเช่นฟอรั่มและรายการอีเมล ไม่สนับสนุนการพูดคุยแบบไม่เป็นทางการมากนัก แต่การแชทใช่ เมื่อแชทคุณถามว่า “สุดสัปดาห์ของคุณเป็นอย่างไร?” “คุณเคยเห็นเกมนี้ไหม?” และ “คุณจะไปดู Testament, Sepultura และ Prong สัปดาห์หน้าไหม?” (โอเค บางทีอาจมีแค่ฉันที่ถามคำถามสุดท้าย)
ดังนั้น แม้ว่าการแชทแบบเรียลไทม์อาจมีประสิทธิภาพน้อยกว่าวิธีข้างหน้า แต่มันช่วยเสริมสร้างความสัมพันธ์ระหว่างผู้คนจริงๆ
คุณต้องการดื่มอะไร
ดังนั้น กลับไปที่คำถามเริ่มต้นของเราสำหรับชุมชนโอเพนซอร์ส: เราจะเลือกอันไหน?
แม้ว่าคำตอบนี้จะแตกต่างกันสำหรับแต่ละโครงการ แต่ฉันต้องการคิดในสองระดับ
ก่อนอื่น โดยทั่วไปคุณควรให้ความสำคัญกับการสื่อสารแบบโครงสร้าง นี่คือที่ที่งานที่จับต้องได้เสร็จสมบูรณ์: ปัญหา/ปัญหา คำขอดึง การสนทนาถามตอบ ฯลฯ ถ้าคุณมีทรัพยากรจำกัด การมุ่งเน้นที่ช่องทางเหล่านี้จะทำให้คุณได้ผลลัพธ์ที่มีประสิทธิภาพจากชุมชนด้วยการใช้เวลาและเงินน้อยลง
ประการที่สอง ถ้าคุณกระตือรือร้นที่จะสร้างชุมชนที่กว้างขวางซึ่งมุ่งเน้นไปที่วิศวกรรม การประชาสัมพันธ์ การแปล เอกสาร ฯลฯ การสำรวจว่าจะแนะนำช่องทางที่ไม่มีโครงสร้างหรือไม่ก็มีความหมาย ชุมชนไม่เพียงแต่เพื่อทำงานให้เสร็จ แต่ยังเพื่อสร้างความสัมพันธ์และมิตรภาพ สนับสนุนซึ่งกันและกันในการทำงาน และช่วยให้ผู้คนเติบโตและเข้มแข็งในชุมชน การสื่อสารที่ไม่มีโครงสร้างเป็นเครื่องมือที่มีประโยชน์
แน่นอน ฉันเพียงแคะผิวในหัวข้อใหญ่นี้ แต่ฉันหวังว่าฉันได้ให้ข้อมูลเชิงลึกบางอย่างเกี่ยวกับวิธีประเมินและเลือกคุณค่าของช่องทางการสื่อสาร จำไว้ น้อยกว่าคือมากกว่า: อย่าถูกล่อลวงด้วยความคิดที่จะมีช่องทางทั้งหมด มิฉะนั้นคุณจะได้ชุมชนที่แตกสลาย เหมือนร้านอาหารที่ว่างเปล่า
ขอให้พลังอยู่กับคุณ และโปรดบอกฉันว่าคุณทำอย่างไร คุณสามารถติดต่อฉันได้ผ่านเว็บไซต์และอีเมล jono@jonobacon.com
(ภาพประกอบ: Opensource.com)
ข้อมูลผู้เขียน:
Jono Bacon เป็นผู้จัดการชุมชนชั้นนำ วิทยากร นักเขียน และพอดแคสต์เตอร์ เขาเป็นผู้ก่อตั้ง Jono Bacon Consulting ให้บริการกลยุทธ์/การดำเนินงานชุมชน เวิร์กโฟลว์นักพัฒนา และบริการอื่นๆ เขาเคยดำรงตำแหน่งผู้อำนวยการชุมชนของ GitHub, Canonical, XPRIZE, OpenAdvantage และเคยให้คำปรึกษาและที่ปรึกษาแก่องค์กรมากมาย
โปรดระบุแหล่งที่มา: ความสัมพันธ์นักพัฒนา »
