10 คะแนน โดย xguru 2021-11-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักพัฒนา 73 ล้านคน (ผู้ใช้ใหม่ 16 ล้านคนในปี 2021)

  • 84% ของบริษัทใน Fortune 100 ใช้ GitHub Enterprise

  • ปีที่แล้วมีการสร้าง Repo ใหม่ 61 ล้านรายการ

  • มี PR ถูก merge 170 ล้านรายการ

  • การกระจายตัวของผู้ใช้: อเมริกาเหนือ 43.2%, ยุโรป 33.5%, เอเชีย 15.7%, โอเชียเนีย 3.5%, อเมริกาใต้ 3.1%, แอฟริกา 1%

  • ภาษา: JS > Python > Java > TypeScript > C# > PHP > C++ > Shell > C > Ruby

→ แทบไม่เปลี่ยนจากปีก่อน และมีเพียง C กับ Shell ที่สลับอันดับกัน

  • การเปลี่ยนแปลงหลังการระบาดใหญ่

→ การทำงานที่ออฟฟิศลดจาก 41% เหลือ 10.7%

→ แบบไฮบริดที่ทำงานจากบ้านบางส่วนเพิ่มจาก 28.1% เป็น 47.6%

→ รีโมตเต็มรูปแบบเพิ่มจาก 26.5% เป็น 38.8%

  • เพิ่มความยั่งยืนผ่านระบบอัตโนมัติ

→ การลดงานซ้ำๆ ให้ผลลัพธ์ที่ดีขึ้น 27% ในโอเพนซอร์ส และ 43% ในบริษัท

  • การแบ่งปันข้อมูลผ่าน README สำคัญมาก

→ ช่วยหาผู้ร่วมพัฒนาใหม่และทำให้มีประสิทธิภาพมากขึ้น 55%

→ โอเพนซอร์ส 85.9% มี README แต่ Repo ของบริษัท 84% ไม่มี

→ นั่นหมายความว่าสำหรับบริษัท งานทำเอกสารก็อาจเป็นโปรเจกต์หนึ่งได้เช่นกัน

  • ระบบ "PR Wrangling" ที่ Kubernetes Documentation SIG ลองใช้

→ ผู้ร่วมพัฒนาที่มีบทบาทและความรับผิดชอบชัดเจนจนถึงสถานะ "Approver" สามารถอาสาเป็น PR Wrangler รายสัปดาห์ได้

→ คัดแยก GitHub Issue, กำหนดแท็ก, รีวิว PR ว่าปฏิบัติตามคุณภาพและแนวทางหรือไม่, ให้ฟีดแบ็ก และอนุมัติการ merge

→ ด้วยวิธีนี้ ชุมชน Kubernetes จึงรักษาความถูกต้องของเอกสารไว้ได้ ทำให้เอกสารใหม่ซิงก์กันได้ดี และรองรับการแปลท้องถิ่น

รายงานเชิงธีมแบบละเอียด 3 หัวข้อ

  • Writing and Shipping code faster

→ วิธีเพิ่มผลิตภาพของนักพัฒนา

→ ขยายงานด้วยระบบอัตโนมัติ

→ การนำโค้ดกลับมาใช้ซ้ำ

→ การค้นหาช่วยเพิ่มผลิตภาพการพัฒนา

→ เครื่องมือทำงานร่วมกันที่เหมาะสมมีความสำคัญ

→ PR แสดงให้เห็นว่าทีมพัฒนาร่วมงานกันอย่างไร

→ การทำงานเป็นทีมสำคัญ แต่การประสานงานเป็นเรื่องยาก

→ เวลาที่ผู้ร่วมพัฒนาใหม่ใช้กับ PR แรก

→ วิธีจัดการ PR ให้เร็วขึ้น: จำนวน reviewer และระบบอัตโนมัติ

  • Creating documentation to support developers

→ เอกสารสำคัญมากไม่ว่าจะอยู่ในรูปแบบใด แต่กลับมีการลงทุนน้อย

→ หากมีแนวทางสำหรับผู้ร่วมพัฒนา จะช่วยลดความคลุมเครือและแรงเสียดทาน ทำให้เข้าร่วมได้ง่ายขึ้น

→ README สำคัญมาก

→ GitHub Issue ก็เป็นเอกสารเช่นกัน

→ หากมีคู่มือ Good First Issues จะช่วยให้สมาชิกใหม่ทำ contribution แรกได้ง่ายขึ้น

→ เอกสารส่งผลดีต่อทั้งผลิตภาพและวัฒนธรรมการพัฒนา เป็น win-win

  • Supporting stusainable communites

→ การให้คำปรึกษาเป็นทรัพยากรของชุมชนทั้งในโอเพนซอร์สและในบริษัท

→ ความเชื่อใจและความเคารพสร้างวัฒนธรรมที่ดีกว่า

→ ชุมชนที่ปลอดภัยและเป็นมิตรช่วยดึงดูดผู้เข้าร่วมใหม่และส่งเสริมการมีส่วนร่วม (แนวทางการเข้าร่วม, Good First Issues เป็นต้น)

→ ความสนุกและการเรียนรู้เป็นสิ่งดึงดูดสำหรับผู้เข้าร่วมใหม่

1 ความคิดเห็น

 
xguru 2021-11-17