Làm thế nào để quản lý một chương trình InnerSource thành công

Đã hoàn thành

Ở đây, chúng tôi thảo luận về cách bạn có thể thiết kế một chương trình InnerSource để tận hưởng tốt nhất của các mô hình mã nguồn mở trong bất kỳ tổ chức phát triển phần mềm nào.

InnerSource là gì?

Bất cứ ai cũng có thể tự do sử dụng, sửa đổi và chia sẻ phần mềm nguồn mở. Bằng cách sử dụng phần mềm mã nguồn mở, bất kỳ ai cũng có thể xem, sửa đổi và phân phối một dự án cho bất kỳ mục đích nào với ý tưởng rằng mã chia sẻ dẫn đến phần mềm tốt hơn, đáng tin cậy hơn.

InnerSource thực hành áp dụng các mẫu mã nguồn mở cho các dự án có lượng người xem hạn chế. Ví dụ: một công ty có thể thiết lập chương trình InnerSource phản chiếu cấu trúc của dự án mã nguồn mở điển hình, ngoại trừ việc chỉ nhân viên của công ty đó mới có thể truy nhập. Trên thực tế, đây là chương trình mã nguồn mở đằng sau tường lửa của công ty bạn.

Lợi ích InnerSource

Một chương trình InnerSource có thể cung cấp nhiều lợi ích ngoài những gì mô hình nguồn đóng truyền thống cung cấp.

Đầu tiên, chúng hỗ trợ khả năng hiển thị nội bộ. Truy nhập vào mã nguồn của các dự án khác của công ty có thể giúp nhà phát triển làm việc hiệu quả hơn khi làm việc trên các dự án của riêng họ. Họ có thể thấy các nhóm khác nhau giải quyết các vấn đề tương tự như nhóm họ đang gặp phải như thế nào và thường tìm mã cũng như các tài sản khác mà họ có thể sử dụng lại. Truy cập vào các vấn đề nhóm, yêu cầu kéo và kế hoạch dự án cũng cung cấp dữ liệu tốt hơn để họ hiểu được tốc độ và hướng đi của dự án.

Tiếp theo, chúng giảm ma sát. Giả sử nhóm người tiêu dùng phụ thuộc vào bản sửa lỗi hoặc tính năng mới cho dự án thuộc sở hữu của một nhóm khác. Trong một chương trình InnerSource, họ có một kênh mà qua đó họ có thể đề xuất những thay đổi mà họ cần. Và nếu những thay đổi đó không thể được sáp nhập vì bất kỳ lý do nào, nhóm người tiêu dùng có tùy chọn tăng cấp dự án để đáp ứng nhu cầu của họ.

Cuối cùng, họ sẽ chuẩn hóa các phương pháp. Một thách thức phổ biến mà các tổ chức phát triển phải đối mặt là các nhóm khác nhau thường phân kỳ theo cách họ hoạt động. Xây dựng một chương trình InnerSource là một cơ hội tuyệt vời để áp dụng các quy ước tiêu chuẩn có thể được sử dụng trong tất cả các nhóm phát triển, ngay cả khi họ không tuân theo các thực tiễn giống nhau. Ví dụ: hai nhóm có thể thích các quy trình khác nhau để chấp nhận đóng góp. Việc họ chuẩn hóa cách họ truyền đạt các quy trình khác nhau của họ sẽ giúp mọi người đóng góp vào một trong hai quy trình đó dễ dàng hơn nhiều.

Tiền bo

Cân nhắc sử dụng GitHub Discussions và GitHub Projects để hỗ trợ thêm cho sự cộng tác của InnerSource giữa các nhóm.

Những ví dụ này chỉ là một vài trong số những lợi ích được hưởng bởi innerSource chương trình. Để tìm hiểu thêm, hãy giới thiệu về InnerSource.

Thiết lập chương trình InnerSource trên GitHub

Đặt khả năng hiển thị và quyền kho chứa

Bạn có thể đặt cấu hình kho GitHub với ba mức hiển thị. Người dùng không đáp ứng yêu cầu về khả năng hiển thị sẽ thấy các trang "không tìm thấy" khi họ cố gắng truy nhập vào kho lưu trữ của bạn. Các mức độ là:

• kho lưu trữ công cộng được hiển thị cho tất cả mọi người. Sử dụng khả năng hiển thị này cho các dự án thực sự là nguồn mở và cung cấp quyền truy nhập cho những người bên trong và bên ngoài tổ chức của bạn.
• Kho lưu trữ nội bộ chỉ hiển thị cho các thành viên của doanh nghiệp sở hữu chúng.

Lưu ý

Kho lưu trữ nội bộ chỉ có sẵn cho khách hàng GitHub Enterprise. Sử dụng khả năng hiển thị này cho các dự án InnerSource.

• lưu trữ chỉ hiển thị cho chủ sở hữu và bất kỳ nhóm hoặc cá nhân nào mà họ thêm vào. Sử dụng khả năng hiển thị này cho các dự án mà chỉ những người dùng và nhóm cụ thể mới có quyền truy nhập.

Một khi bạn thiết lập khả năng hiển thị kho lưu trữ, bạn có thể đặt cấu hình quyền trên cơ sở cá nhân hoặc nhóm. Có năm mức cấp phép:

• đọc được đề xuất cho những người đóng góp phi mã muốn xem hoặc thảo luận về dự án.
• cấp độ phân được khuyến khích cho những người đóng góp cần chủ động quản lý các vấn đề và kéo yêu cầu mà không cần truy cập ghi.
• viết đề xuất cho những người đóng góp tích cực đẩy vào dự án.
• duy trì được khuyến khích cho người quản lý dự án cần quản lý kho mà không cần truy cập vào các hành động nhạy cảm hoặc phá hoại.
• quản được đề xuất cho những người cần truy nhập đầy đủ vào dự án, bao gồm các hành động nhạy cảm và phá hoại như quản lý bảo mật hoặc xóa một kho lưu trữ.

Tìm hiểu thêm về truy nhập kho lưu trữ theo cấp độ.

Tạo kho lưu trữ có thể phát hiện

Khi một chương trình InnerSource phát triển, số lượng kho lưu trữ có khả năng mở rộng đáng kể. Mặc dù thật tuyệt vời khi có tất cả các tài sản này sẵn có cho tổ chức, nhưng nó có thể trở thành một thách thức để tìm nội dung một cách hiệu quả. Để chủ động giải quyết vấn đề này, cách tốt nhất để các nhóm cân nhắc những gì họ có thể làm để giúp người khác dễ dàng tìm và làm việc với các kho lưu trữ của họ hơn.

Một số biện pháp tốt nhất bao gồm:

• Sử dụng tên kho chứa mô tả, chẳng hạn như warehouse-api hoặc supply-chain-web.
• Bao gồm một mô tả ngắn gọn. Một hoặc hai câu sẽ đủ để người dùng tiềm năng biết liệu dự án có thể phù hợp với nhu cầu của họ hay không.
• cấp phép kho lưu trữ để khách hàng biết cách họ có thể sử dụng, thay đổi và phân phối phần mềm.
• Bao gồm một README.md dữ liệu trong kho. GitHub sử dụng tệp này làm trang đích khi mọi người truy cập vào kho lưu trữ.

Thêm tệp README

Tệp README truyền đạt các kỳ vọng cho dự án của bạn và giúp bạn quản lý đóng góp. Tệp README có thể:

• Nêu rõ mục đích và tầm nhìn của dự án để người tiêu dùng tiềm năng hiểu được liệu dự án có phù hợp với nhu cầu của họ hay không.
• Cung cấp công cụ hỗ trợ trực quan, chẳng hạn như ảnh chụp màn hình hoặc mẫu mã, để minh họa cho dự án đang hoạt động.
• Bao gồm các liên kết đến phiên bản sản xuất hoặc demo của ứng dụng để xem lại.
• Đặt kỳ vọng cho các điều kiện tiên quyết và quy trình triển khai.
• Bao gồm tham chiếu đến các dự án mà bạn phụ thuộc. Những tài liệu tham khảo này là một cách hay để thúc đẩy công việc của người khác.
• Sử dụng Markdown để hướng dẫn người đọc qua nội dung được định dạng đúng.

Nếu bạn đặt tệp README.md của mình vào thư mục gốc của kho lưu trữ hoặc trong thư mục ẩn hoặc .github thư docs mục, GitHub sẽ nhận dạng và tự động hiển thị README của bạn cho khách truy cập kho lưu trữ. Nếu một kho lưu trữ chứa nhiều tệp README, thì tệp được hiển thị sẽ được chọn từ các vị trí theo thứ tự sau:

1. Thư .github mục
2. Thư mục gốc của kho lưu trữ
3. Thư docs mục

Hãy xem một số ví dụ về README tuyệt vời.

Sau khi dự án khởi chạy, hãy sử dụng email và các kênh mạng khác để quảng bá dự án. Tiếp cận đối tượng thích hợp có thể tạo ra sự gia tăng đáng kể trong việc tham gia dự án.

Tìm hiểu thêm về các tệp README trong tài liệu GitHub.

Quản lý dự án trên GitHub

Khi các dự án đạt được sức hút, dòng người dùng và đóng góp có thể đòi hỏi rất nhiều công việc để quản lý. Tùy thuộc vào dự án, một lượng công việc đáng kể có thể được yêu cầu chỉ để quản lý kỳ vọng của người tham gia dự án.

Để chủ động giải quyết vấn đề này, GitHub tìm kiếm một tệp CONTRIBUTING.md trong gốc (hoặc /docs hoặc /.github) của một kho lưu trữ. Sử dụng tệp này để giải thích chính sách đóng góp cho dự án. Các chi tiết chính xác có thể khác nhau, nhưng bạn nên cho những người đóng góp tiềm năng biết những quy ước mà dự án tuân theo. Ví dụ: trong đó nhóm đang tìm kiếm yêu cầu kéo, thông tin chi tiết được yêu cầu cho báo cáo lỗi, v.v.

Nếu tồn CONTRIBUTING.md, GitHub sẽ trình bày một liên kết đến liên kết đó khi người dùng tạo ra các vấn đề hoặc kéo yêu cầu để khuyến khích họ làm theo.

Hãy xem một số ví tuyệt vời CONTRIBUTING.md dụ về

Ngoài ra, hãy cân thêm tệp CODEOWNERS vào kho để xác định các cá nhân hoặc nhóm chịu trách nhiệm xem xét các sửa đổi mã.

Tạo sự cố và kéo mẫu yêu cầu

GitHub hỗ trợ mẫu khởi động cho các vấn đề mới và yêu cầu kéo. Sử dụng các mẫu này để cung cấp văn bản mô tả ban đầu cho sự cố hoặc yêu cầu kéo mới được tạo.

Ví dụ: nếu dự án của bạn đã .github/ISSUE_TEMPLATE.md, bất cứ khi nào người dùng bắt đầu quy trình tạo sự cố, họ sẽ thấy nội dung này. Thay vì phải liên tục tham chiếu các chi tiết bắt buộc từ CONTRIBUTING.md, họ có thể chỉ cần điền vào sự cố như biểu mẫu bằng văn bản mẫu.

Nó giống nhau cho các yêu cầu kéo, ngoại trừ rằng đường dẫn là .github/PULL_REQUEST_TEMPLATE.md.

Hãy xem qua một vấn đề Awesome GitHub về & mẫu yêu cầu kéo.

Xác định dòng công việc

Đối với các dự án khuyến khích sự đóng góp từ bên ngoài, hãy đảm bảo chỉ định dòng công việc mà dự án tuân theo. Dòng công việc nên bao gồm chi tiết về vị trí và cách thức sử dụng nhánh cho lỗi và tính năng. Nó cũng nên bao gồm cách yêu cầu kéo nên được mở ra, và bất kỳ chi tiết khác những người bên ngoài nhóm kho nên biết trước khi họ đẩy mã. Nếu bạn chưa ghi nhớ dòng công việc, bạn nên cân nhắc việc tạo dòng GitHub.

Bạn nên truyền đạt một chiến lược để quản lý các bản phát hành và triển khai. Những phần này của dòng công việc ảnh hưởng đến việc phân nhánh và phối hàng ngày, vì vậy điều quan trọng là phải giao tiếp với những người đóng góp. Tìm hiểu thêm về cách chúng liên quan đến chiến lược phân nhánh git của bạn.

Đo lường thành công chương trình

Bất kỳ đội ngũ mạo hiểm vào InnerSource nên suy nghĩ về các loại số liệu họ muốn theo dõi để đánh giá sự thành công của chương trình của họ. Mặc dù các số liệu truyền thống như "thời gian tiếp thị" và "lỗi được báo cáo" vẫn có thể áp dụng, nhưng chúng không nhất thiết phải minh họa những lợi ích đạt được thông qua InnerSource.

Thay vào đó, hãy cân nhắc việc thêm số liệu cho thấy sự tham gia của bên ngoài đã cải thiện chất lượng dự án như thế nào. Kho chứa có nhận được yêu cầu kéo từ các nguồn bên ngoài sửa lỗi và thêm tính năng không? Có người dự tích cực nào trong các cuộc thảo luận về dự án và tương lai của dự án không? Chương trình này có truyền cảm hứng cho việc mở rộng InnerSource thúc đẩy lợi ích ở nơi khác trong tổ chức không?

Nói ngắn gọn, các số liệu là khó khăn, đặc biệt là khi nói đến việc đo lường giá trị và hiệu quả của đóng góp cá nhân và nhóm. Nếu sử dụng sai, các số liệu có thể gây hại cho văn hóa, quy trình hiện tại, và giảm tình cảm tập thể đối với tổ chức hoặc đội ngũ lãnh đạo. Khi nghĩ về việc đo lường việc áp dụng InnerSource, hãy xem xét hướng dẫn sau về số liệu:

• Đo quy trình, không phải đầu ra
  • Thời gian thay thế xem lại mã
  • Kích cỡ yêu cầu kéo
  • Đang thực hiện công việc
  • Đã đến lúc mở
• Đo lường chống lại mục tiêu và không tuyệt đối
• Đo lường các nhóm và không phải cá nhân
  • Số người đóng góp duy nhất cho một dự án
  • Số dự án đang sử dụng lại mã
  • Số lượng thành viên nhóm @mentions

Tìm hiểu về những thành công những người khác được hưởng trong các nghiên trường hợp InnerSource.