วิธีการจัดการโปรแกรม InnerSource ที่ประสบความสําเร็จ

เสร็จสมบูรณ์เมื่อ

ที่นี่เรากล่าวถึงวิธีที่คุณสามารถออกแบบโปรแกรม InnerSource เพื่อเพลิดเพลินไปกับรูปแบบโอเพนซอร์สที่ดีที่สุดในองค์กรการพัฒนาซอฟต์แวร์ใด ๆ

InnerSource คืออะไร

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

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

สิทธิประโยชน์ InnerSource

โปรแกรม InnerSource สามารถให้ประโยชน์มากมายนอกเหนือจากสิ่งที่โมเดลปิดแหล่งที่มาแบบดั้งเดิมให้

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

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

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

เคล็ดลับ

พิจารณาใช้ GitHub Discussions และ GitHub Projects เพื่อสนับสนุนการทํางานร่วมกันของ InnerSource ระหว่างทีมเพิ่มเติม

ตัวอย่างเหล่านี้เป็นเพียงสิทธิประโยชน์บางประการที่โปรแกรม InnerSource เพลิดเพลิน หากต้องการเรียนรู้เพิ่มเติม โปรดดู บทนําสู่InnerSource

ตั้งค่าโปรแกรม InnerSource บน GitHub

ตั้งค่าการมองเห็นและสิทธิ์ของที่เก็บ

คุณสามารถกําหนดค่าพื้นที่เก็บ GitHub ด้วยการมองเห็นสามระดับ ผู้ใช้ที่ไม่ตรงตามข้อกําหนดการมองเห็น ให้ดูหน้า "ไม่พบ" เมื่อพวกเขาพยายามเข้าถึงที่เก็บของคุณ ระดับคือ:

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

หมายเหตุ

ที่เก็บภายในมีให้สําหรับลูกค้า GitHub Enterprise เท่านั้น ใช้การมองเห็นนี้สําหรับโครงการ InnerSource

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

เมื่อคุณสร้างการมองเห็นที่เก็บข้อมูล คุณสามารถกําหนดค่าสิทธิ์ในแต่ละบุคคลหรือทีมได้ มีห้าระดับสิทธิ์:

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

เรียนรู้เพิ่มเติมเกี่ยวกับ สิทธิ์การเข้าถึงที่เก็บตามระดับ

สร้างที่เก็บที่ค้นพบได้

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

หลักปฏิบัติที่ดีที่สุดสองสามประการได้แก่:

• ใช้ชื่อที่เก็บคําอธิบาย เช่น warehouse-api หรือ supply-chain-web
• รวมคําอธิบายที่รัดกุม ประโยคหนึ่งหรือสองประโยคควรเพียงพอสําหรับผู้ใช้ที่มีศักยภาพที่จะทราบว่าโครงการอาจเหมาะสมกับความต้องการของพวกเขาหรือไม่
• อนุญาตให้ใช้งานที่เก็บข้อมูลของคุณ เพื่อให้ลูกค้าทราบว่าพวกเขาสามารถใช้ เปลี่ยน และแจกจ่ายซอฟต์แวร์ได้อย่างไร
• รวมไฟล์ README.md ไว้ในที่เก็บ GitHub ใช้ไฟล์นี้เป็นหน้าเริ่มต้นเมื่อผู้คนเยี่ยมชมที่เก็บข้อมูล

เพิ่มไฟล์ README

ไฟล์ README สื่อสารความคาดหวังสําหรับโครงการของคุณและช่วยคุณจัดการการสนับสนุน ไฟล์ README สามารถ:

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

หากคุณใส่ไฟล์ README.md ของคุณในไดเรกทอรีรากของที่เก็บ หรือในไดเร็กทอรีที่ซ่อนอยู่ .githubdocs GitHub จะจดจําและแสดง README ของคุณต่อผู้เยี่ยมชมที่เก็บโดยอัตโนมัติ ถ้าที่เก็บมีไฟล์ README มากกว่าหนึ่งไฟล์ ไฟล์ที่แสดงจะถูกเลือกจากตําแหน่งที่ตั้งตามลําดับต่อไปนี้:

1. ได .github เรกทอรี
2. ไดเรกทอรีรากของที่เก็บ
3. ได docs เรกทอรี

ลองดูตัวอย่าง Awesome README

เมื่อเปิดโครงการให้ใช้อีเมลและช่องเครือข่ายอื่น ๆ เพื่อเลื่อนระดับ การเข้าถึงกลุ่มเป้าหมายที่เหมาะสมสามารถทําให้เกิดการมีส่วนร่วมของโครงการได้อย่างมาก

เรียนรู้เพิ่มเติมเกี่ยวกับไฟล์ README ในเอกสารประกอบ GitHub

จัดการโครงการบน GitHub

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

เมื่อต้องการแก้ไขปัญหานี้เชิงรุก GitHub ค้นหาไฟล์ CONTRIBUTING.md ในราก (หรือ /docs หรือ /.github) ของที่เก็บ ใช้ไฟล์นี้เพื่ออธิบายนโยบายการสนับสนุนสําหรับโครงการ รายละเอียดที่แน่นอนอาจแตกต่างกัน แต่ควรให้ผู้สนับสนุนที่มีศักยภาพทราบว่าโครงการมีรูปแบบใดดังต่อไปนี้ ตัวอย่างเช่น ที่ทีมกําลังค้นหาคําขอดึงข้อมูล รายละเอียดอะไรบ้างที่ร้องขอสําหรับรายงานบั๊ก และอื่น ๆ

ถ้ามี CONTRIBUTING.md อยู่ GitHub จะแสดงลิงก์เมื่อผู้ใช้สร้างปัญหาหรือดึงคําขอเพื่อสนับสนุนให้พวกเขาติดตาม

ลองดูตัวอย่าง CONTRIBUTING.md ที่ยอดเยี่ยม

นอกจากนี้ พิจารณา เพิ่มไฟล์ CODEOWNERS ไปยังที่เก็บเพื่อกําหนดบุคคลหรือทีมที่รับผิดชอบในการตรวจสอบการแก้ไขโค้ด

สร้างประเด็นและดึงเทมเพลตคําขอ

GitHub สนับสนุนเทมเพลตเริ่มต้นสําหรับปัญหาใหม่และคําขอดึงข้อมูล ใช้เทมเพลตเหล่านี้เพื่อให้ข้อความคําอธิบายเริ่มต้นสําหรับปัญหาหรือคําขอดึงข้อมูลที่สร้างขึ้นใหม่

ตัวอย่างเช่น ถ้าโครงการของคุณมี .github/ISSUE_TEMPLATE.mdทุกครั้งที่ผู้ใช้เริ่มกระบวนการสร้างปัญหา พวกเขาจะเห็นเนื้อหานี้ แทนที่จะต้องอ้างอิงรายละเอียดที่จําเป็นจาก CONTRIBUTING.mdอย่างต่อเนื่อง พวกเขาสามารถเพียงแค่กรอกปัญหาเช่นฟอร์มโดยใช้ข้อความเทมเพลต

ซึ่งเหมือนกับคําขอดึงข้อมูล ยกเว้นว่าเส้นทางคือ .github/PULL_REQUEST_TEMPLATE.md

ตรวจสอบปัญหา GitHub ที่ยอดเยี่ยม & เทมเพลตคําขอดึงข้อมูล

กําหนดเวิร์กโฟลว์

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

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

ความสําเร็จของโปรแกรมการวัด

ทีมใด ๆ ที่เข้าร่วม InnerSource ควรคิดถึงชนิดของเมตริกที่พวกเขาต้องการติดตามเพื่อวัดความสําเร็จของโปรแกรมของพวกเขา ในขณะที่เมตริกแบบดั้งเดิมเช่น "เวลาที่จะทําตลาด" และ "รายงานบั๊ก" ยังคงใช้ได้ แต่ไม่จําเป็นต้องอธิบายผลประโยชน์ที่สามารถทําได้ผ่าน InnerSource

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

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

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

เรียนรู้เกี่ยวกับความสําเร็จที่ผู้อื่นมีความสุขในกรณี InnerSource