Cara mengelola program InnerSource yang sukses

Selesai

Di sini, kami membahas bagaimana Anda dapat merancang program InnerSource untuk menikmati pola sumber terbuka terbaik dalam organisasi pengembangan perangkat lunak apa pun.

Apa itu InnerSource?

Siapa pun dapat dengan bebas menggunakan, memodifikasi, dan berbagi perangkat lunak sumber terbuka. Dengan menggunakan perangkat lunak sumber terbuka, siapa pun dapat melihat, memodifikasi, dan mendistribusikan proyek untuk tujuan apa pun dengan gagasan bahwa berbagi kode mengarah ke perangkat lunak yang lebih baik dan lebih andal.

InnerSource adalah praktik menerapkan pola sumber terbuka ke proyek dengan audiens terbatas. Misalnya, perusahaan mungkin membuat program InnerSource yang mencerminkan struktur proyek sumber terbuka yang khas, kecuali bahwa itu hanya dapat diakses oleh karyawan perusahaan tersebut. Akibatnya, ini adalah program sumber terbuka di belakang firewall perusahaan Anda.

Manfaat InnerSource

Program InnerSource dapat menawarkan banyak manfaat di luar apa yang disediakan model sumber tertutup pada umumnya.

Pertama, mereka mendukung visibilitas internal. Akses ke kode sumber proyek perusahaan lain dapat membantu pengembang menjadi lebih produktif saat mengerjakan proyek mereka sendiri. Mereka dapat melihat bagaimana tim yang berbeda memecahkan masalah yang mirip dengan yang mereka hadapi, dan sering menemukan kode dan aset lain yang dapat mereka gunakan kembali. Akses ke masalah tim, permintaan pull, dan rencana proyek juga memberikan data yang lebih baik bagi mereka untuk memahami kecepatan dan arah proyek.

Selanjutnya, mereka mengurangi gesekan. Katakanlah tim konsumen bergantung pada perbaikan bug atau fitur baru untuk proyek yang dimiliki oleh tim yang berbeda. Dalam program InnerSource, mereka memiliki saluran di mana mereka dapat mengusulkan perubahan yang mereka butuhkan. Dan jika perubahan tersebut tidak dapat digabungkan karena alasan apa pun, tim konsumen memiliki opsi untuk menempa proyek untuk memenuhi kebutuhan mereka.

Akhirnya, mereka menstandarkan praktik. Organisasi pengembangan tantangan umum yang dihadapi adalah bahwa tim yang berbeda sering berbeda dalam cara mereka beroperasi. Membangun program InnerSource adalah kesempatan bagus untuk mengadopsi konvensi standar yang dapat digunakan di setiap tim pengembangan, bahkan jika mereka tidak mengikuti praktik yang identik. Misalnya, dua tim mungkin lebih suka proses yang berbeda untuk menerima kontribusi. Membuat mereka menstandarkan cara mereka mengomunikasikan proses yang berbeda membuatnya jauh lebih mudah bagi siapa pun untuk berkontribusi.

Petunjuk / Saran

Pertimbangkan untuk menggunakan Diskusi GitHub dan Proyek GitHub untuk lebih mendukung kolaborasi InnerSource di seluruh tim.

Contoh-contoh ini hanyalah beberapa manfaat yang dinikmati oleh program InnerSource. Untuk mempelajari selengkapnya, lihat Pengantar InnerSource.

Menyiapkan program InnerSource di GitHub

Mengatur visibilitas dan izin repositori

Anda dapat mengonfigurasi repositori GitHub dengan tiga tingkat visibilitas. Pengguna yang tidak memenuhi persyaratan visibilitas melihat halaman "tidak ditemukan" saat mereka mencoba mengakses repositori Anda. Tingkatnya adalah:

• Repositori publik dapat dilihat untuk semua orang. Gunakan visibilitas ini untuk proyek yang benar-benar sumber terbuka dan menawarkan akses ke orang-orang di dalam dan di luar organisasi Anda.
• Repositori internal hanya terlihat oleh anggota perusahaan yang memilikinya.

Nota

Repositori internal hanya tersedia untuk pelanggan GitHub Enterprise. Gunakan visibilitas ini untuk proyek InnerSource.

• Repositori privat hanya terlihat oleh pemilik dan tim atau individu apa pun yang mereka tambahkan. Gunakan visibilitas ini untuk proyek yang hanya dapat diakses oleh pengguna dan grup tertentu.

Setelah membuat visibilitas repositori, Anda dapat mengonfigurasi izin secara individual atau tim. Ada lima tingkat izin:

• Tingkat baca direkomendasikan untuk kontributor nonkode yang ingin melihat atau mendiskusikan proyek.
• Tingkat triase direkomendasikan untuk kontributor yang perlu secara proaktif mengelola masalah dan menarik permintaan tanpa akses tulis.
• Tingkat tulis direkomendasikan untuk kontributor yang secara aktif mendorong ke proyek.
• Tingkat pemeliharaan direkomendasikan untuk manajer proyek yang perlu mengelola repositori tanpa akses ke tindakan sensitif atau merusak.
• Tingkat admin direkomendasikan untuk orang-orang yang membutuhkan akses penuh ke proyek, termasuk tindakan sensitif dan merusak seperti mengelola keamanan atau menghapus repositori.

Pelajari selengkapnya tentang izin akses repositori menurut tingkatannya.

Membuat repositori yang dapat ditemukan

Seiring bertambahnya program InnerSource, jumlah repositori kemungkinan akan meningkat secara signifikan. Meskipun sangat bagus untuk memiliki semua aset ini tersedia untuk organisasi, itu bisa menjadi tantangan untuk menemukan konten secara efisien. Untuk mengatasi masalah ini secara proaktif, ini adalah praktik terbaik bagi tim untuk mempertimbangkan apa yang dapat mereka lakukan untuk memudahkan orang lain menemukan dan bekerja dengan repositori mereka.

Beberapa praktik terbaik meliputi:

• Gunakan nama repositori deskriptif, seperti warehouse-api atau supply-chain-web.
• Sertakan deskripsi singkat. Satu atau dua kalimat harus cukup bagi calon pengguna untuk mengetahui apakah proyek mungkin sesuai dengan kebutuhan mereka.
• Lisensikan repositori Anda sehingga pelanggan tahu bagaimana mereka dapat menggunakan, mengubah, dan mendistribusikan perangkat lunak.
• Sertakan README.md file di repositori. GitHub menggunakan file ini sebagai halaman arahan ketika orang mengunjungi repositori.

Menambahkan file README

File README mengkomunikasikan harapan untuk proyek Anda dan membantu Anda mengelola kontribusi. File README dapat:

• Mengartikulasikan tujuan dan visi proyek sehingga calon konsumen memahami apakah itu sesuai dengan kebutuhan mereka.
• Menawarkan bantuan visual, seperti cuplikan layar atau sampel kode, untuk mengilustrasikan proyek dalam tindakan.
• Sertakan tautan ke versi produksi atau demo aplikasi untuk ditinjau.
• Tetapkan harapan untuk prasyarat dan prosedur penyebaran.
• Sertakan referensi ke proyek tempat Anda bergantung. Referensi ini adalah cara yang baik untuk mempromosikan pekerjaan orang lain.
• Gunakan Markdown untuk memandu pembaca melalui konten yang diformat dengan benar.

Jika Anda meletakkan file README.md di direktori akar repositori Anda, atau di direktori atau .github tersembunyidocs, GitHub mengenali dan secara otomatis menampilkan README Anda ke pengunjung repositori. Jika repositori berisi lebih dari satu file README, maka file yang ditampilkan dipilih dari lokasi dalam urutan berikut:

1. .github Direktori
2. Direktori akar repositori
3. docs Direktori

Lihat beberapa contoh README yang mengagumkan.

Setelah proyek diluncurkan, gunakan email dan saluran jaringan lainnya untuk mempromosikannya. Menjangkau audiens yang sesuai dapat menghasilkan peningkatan yang signifikan dalam partisipasi proyek.

Pelajari selengkapnya tentang file README dalam dokumentasi GitHub.

Mengelola proyek di GitHub

Ketika proyek mendapatkan traksi, masuknya pengguna dan kontribusi dapat memerlukan banyak pekerjaan untuk dikelola. Tergantung pada proyek, sejumlah besar pekerjaan mungkin diperlukan hanya untuk mengelola harapan peserta proyek.

Untuk mengatasi masalah ini secara proaktif, GitHub mencari CONTRIBUTING.md file di akar (atau /docs ) /.githubrepositori. Gunakan file ini untuk menjelaskan kebijakan kontribusi untuk proyek. Detail yang tepat mungkin bervariasi, tetapi ada baiknya untuk memberi tahu kontributor potensial tentang konvensi apa yang diikuti proyek. Misalnya, di mana tim mencari permintaan pull, detail apa yang diminta untuk laporan bug, dan sebagainya.

CONTRIBUTING.md Jika ada, GitHub menyajikan tautan ke sana saat pengguna membuat masalah atau menarik permintaan untuk mendorong mereka untuk mengikutinya.

Lihat beberapa contoh CONTRIBUTING.md mengagumkan

Selain itu, pertimbangkan untuk menambahkan file CODEOWNERS ke repositori untuk menentukan individu atau tim yang bertanggung jawab untuk meninjau modifikasi kode.

Membuat masalah dan menarik templat permintaan

GitHub mendukung templat pemula untuk masalah baru dan permintaan pull. Gunakan templat ini untuk memberikan teks deskripsi awal untuk masalah yang baru dibuat atau permintaan pull.

Misalnya, jika proyek Anda memiliki .github/ISSUE_TEMPLATE.md, kapan saja pengguna memulai proses pembuatan masalah, mereka akan melihat konten ini. Daripada harus terus-menerus mereferensikan detail yang CONTRIBUTING.mddiperlukan dari , mereka hanya dapat mengisi masalah seperti formulir menggunakan teks templat.

Ini sama untuk permintaan pull, kecuali bahwa jalurnya adalah .github/PULL_REQUEST_TEMPLATE.md.

Lihat beberapa masalah GitHub yang Mengagumkan & templat permintaan pull.

Menentukan alur kerja

Untuk proyek yang mendorong kontribusi eksternal, pastikan untuk menentukan alur kerja apa yang diikuti proyek. Alur kerja harus mencakup detail tentang di mana dan bagaimana cabang harus digunakan untuk bug dan fitur. Ini juga harus mencakup bagaimana permintaan pull harus dibuka, dan detail lain yang harus diketahui orang di luar tim repositori sebelum mereka mendorong kode. Jika Anda belum memiliki alur kerja, Anda harus mempertimbangkan alur GitHub.

Anda harus mengomunikasikan strategi untuk mengelola rilis dan penyebaran. Bagian alur kerja ini memengaruhi percabangan dan penggabungan sehari-hari, jadi penting untuk mengomunikasikannya kepada kontributor. Pelajari selengkapnya tentang bagaimana mereka berhubungan dengan strategi percabangan Git Anda.

Mengukur keberhasilan program

Setiap tim yang berkelana ke InnerSource harus memikirkan jenis metrik yang ingin mereka lacak untuk mengukur keberhasilan program mereka. Meskipun metrik tradisional seperti "waktu ke pasar" dan "bug yang dilaporkan" masih berlaku, metrik tersebut tidak selalu menggambarkan manfaat yang dicapai melalui InnerSource.

Sebagai gantinya, pertimbangkan untuk menambahkan metrik yang menunjukkan bagaimana partisipasi eksternal meningkatkan kualitas proyek. Apakah repositori menerima permintaan pull dari sumber eksternal yang memperbaiki bug dan menambahkan fitur? Apakah ada peserta aktif dalam diskusi sekeliling proyek dan masa depannya? Apakah program ini menginspirasi ekspansi InnerSource yang mendorong manfaat di tempat lain dalam organisasi?

Singkatnya, metrik sulit, terutama dalam hal mengukur nilai dan efek kontribusi individu dan tim. Jika disalahgunakan, metrik dapat membahayakan budaya, proses yang ada, dan mengurangi sentimen kolektif terhadap organisasi atau tim kepemimpinan. Saat berpikir untuk mengukur adopsi InnerSource, pertimbangkan panduan berikut tentang metrik:

• Mengukur proses, bukan output
  • Waktu penyelesaian tinjauan kode
  • Ukuran permintaan pull
  • Pekerjaan sedang berlangsung
  • Waktu untuk membuka
• Mengukur terhadap target dan bukan absolut
• Mengukur tim dan bukan individu
  • Jumlah kontributor unik untuk proyek
  • Jumlah proyek yang digunakan kembali kode
  • Jumlah lintas tim @mentions

Pelajari tentang keberhasilan yang dinikmati orang lain dalam studi kasus InnerSource ini.