Başarılı bir InnerSource programını yönetme

Tamamlandı

Burada, herhangi bir yazılım geliştirme kuruluşunda en iyi açık kaynak desenlerinin keyfini çıkarmak için bir InnerSource programını nasıl tasarlayabileceğinizi tartışacağız.

InnerSource nedir?

Herkes açık kaynak yazılımı serbestçe kullanabilir, değiştirebilir ve paylaşabilir. Açık kaynak yazılımı kullanarak, kod paylaşımının daha iyi, daha güvenilir bir yazılıma yol açtığı fikriyle herkes herhangi bir amaçla projeyi görüntüleyebilir, değiştirebilir ve dağıtabilir.

InnerSource , sınırlı hedef kitleye sahip projelere açık kaynak desenleri uygulama uygulamasıdır. Örneğin, bir şirket, yalnızca o şirketin çalışanları tarafından erişilebilir olması dışında, tipik bir açık kaynak projenin yapısını yansıtan bir InnerSource programı kurabilir. Aslında bu, şirketinizin güvenlik duvarının arkasındaki açık kaynaklı bir programdır.

InnerSource avantajları

InnerSource programı, geleneksel kapalı kaynak modellerin sağladığının ötesinde birçok avantaj sunabilir.

İlk olarak, iç görünürlüğü destekler. Diğer şirket projelerinin kaynak koduna erişilmesi, geliştiricilerin kendi projeleri üzerinde çalışırken daha üretken olmasına yardımcı olabilir. Farklı ekiplerin karşılaştıkları sorunlara benzer sorunları nasıl çözdüğünü görebilir ve genellikle yeniden kullanabilecekleri kodu ve diğer varlıkları bulabilirler. Takım sorunlarına, çekme isteklerine ve proje planlarına erişim sayesinde, projenin hızını ve yönünü anlamalarına yardımcı olacak daha iyi veriler elde eder.

İkinci olarak, sürtüşmeleri azaltır. Tüketici ekibinin, farklı bir ekibin sahip olduğu bir projenin hata düzeltmesine veya yeni özelliğine bağımlı olduğunu düşünelim. InnerSource programında, ihtiyaç duydukları değişiklikleri önerebilecekleri bir kanalı vardır. Bu değişiklikler herhangi bir nedenle birleştirilemiyorsa tüketici ekibi, ihtiyaçlarını karşılamak için projeyi çatallama seçeneğine sahiptir.

Son olarak, uygulamaları standartlaştırır. Geliştirme kuruluşlarının karşılaştığı yaygın bir zorluk, farklı takımların faaliyet gösterme şekillerinde farklılık olmasıdır. InnerSource programı oluşturmak, aynı uygulamaları izlemeseler bile her geliştirme ekibinde kullanılabilecek standart kuralları benimsemek için harika bir fırsattır. Örneğin, iki ekip katkıları kabul etmek için farklı süreçleri tercih edebilir. Farklı süreçlerini aktarma şekillerinde standart sağlanması, herkesin katkıda bulunmasını daha da kolaylaştırır.

İpucu

Ekipler arasında InnerSource işbirliğini daha fazla desteklemek için GitHub Tartışmalarını ve GitHub Projelerini kullanmayı göz önünde bulundurun.

Bu örnekler, InnerSource programlarının elde ettiği avantajlardan yalnızca birkaçıdır. Daha fazla bilgi edinmek için bkz. InnerSource’a giriş.

GitHub'da InnerSource programı ayarlama

Depo görünürlüğünü ve izinlerini ayarlama

GitHub depolarını üç görünürlük düzeyiyle yapılandırabilirsiniz. Görünürlük gereksinimini karşılamayan kullanıcılar, deponuza erişmeye çalışırken "bulunamadı" sayfalarını görür. Düzeyler şunlardır:

• Genel depolar herkes tarafından görülebilir. Gerçekten açık kaynaklı olup kuruluşunuzun içindeki ve dışındaki kişilere erişim yetkisi sunan projeler için bu görünürlüğü kullanın.
• İç depolar yalnızca kendilerine sahip olan kuruluş üyeleri tarafından görülebilir.

Uyarı

İç depolar yalnızca GitHub Enterprise müşterileri tarafından kullanılabilir. InnerSource projeleri için bu görünürlüğü kullanın.

• Özel depolar yalnızca bu depoların sahibi tarafından ve depo sahibinin eklediği takımlar veya bireyler tarafından görülebilir. Yalnızca belirli kullanıcıların ve grupların erişmesi gereken projeler için bu görünürlüğü kullanın.

Depo görünürlüğünü oluşturduktan sonra izinleri bireysel veya ekip temelinde yapılandırabilirsiniz. Beş izin düzeyi vardır:

• Projeyi görüntülemek veya tartışmak isteyen kodsuz katkıda bulunanlar için okuma düzeyi önerilir.
• Değerlendirme düzeyi, yazma erişimi olmadan proaktif şekilde sorunları ve çekme isteklerini yönetmesi gereken katkıda bulunanlar için önerilir.
• Yazma düzeyi, etkin şekilde projeye gönderimde bulunan katkıda bulunanlar için önerilir.
• Bakım düzeyi, hassas veya yıkıcı eylemlere erişimi olmadan depoyu yönetmesi gereken proje yöneticileri için önerilir.
• Yönetici düzeyi, güvenliği yönetme veya depoyu silme gibi hassas ve yıkıcı eylemler de dahil olmak üzere, projeye tam erişim elde etmesi gereken kişiler için önerilir.

Düzeye göre depo erişim izinleri hakkında daha fazla bilgi edinin.

Keşfedilebilir depolar oluşturma

Bir InnerSource programı büyüdükçe, depo sayısı büyük olasılıkla önemli ölçüde artar. Tüm bu varlıkların kuruluşun kullanımına sunulması harika olsa da, içeriği verimli şekilde bulmak zor olabilir. Bu sorunu proaktif bir şekilde çözmek için, ekiplerin başkalarının depolarını bulmasını ve depolarıyla çalışmasını kolaylaştırmak için neler yapabileceklerini göz önünde bulundurması en iyi yöntemdir.

Birkaç en iyi yöntem arasında şunlar yer alır:

• warehouse-api veya supply-chain-web gibi açıklayıcı bir depo adı kullanın.
• Kısa bir açıklama ekleyin. Olası kullanıcıların, projenin ihtiyaçlarına uygun olup olmayabileceğini bilmesi için bir veya iki cümle yeterli olmalıdır.
• Müşterilerin yazılımı nasıl kullanabileceklerini, değiştirebileceklerini ve dağıtabileceklerini bilmeleri için deponuzun lisansını alın.
• Depoya bir README.md dosya ekleyin. GitHub, kişiler depoyu ziyaret ettiğinde giriş sayfası olarak bu dosyayı kullanır.

BENİOKU dosyası ekleme

README dosyası projeniz için beklentileri iletir ve katkıları yönetmenize yardımcı olur. BENIOKU dosyaları:

• Olası tüketicilerin, projenin ihtiyaçlarına uygun olup olmadığını anlaması için projenin amacını ve vizyonunu ifade edin.
• Projeyi uygulamalı olarak göstermek için ekran görüntüsü veya kod örnekleri gibi görsel yardımcılar sunun.
• Gözden geçirebilmek için uygulamanın üretim veya tanıtım sürümünün bağlantılarını ekleyin.
• Ön koşullara ve dağıtım yordamlarına yönelik beklentileri belirleyin.
• Bağlı olduğunuz projelere başvurular ekleyin. Bu başvurular, başkalarının çalışmalarını teşvik etmek için iyi bir yoldur.
• Okuyuculara düzgün biçimlendirilmiş içerikte yol göstermek için Markdown'ı kullanın.

README.md dosyanızı deponuzun kök dizinine veya gizli .github veya docs dizine koyarsanız GitHub, BENIOKU dosyanızı depo ziyaretçilerine tanır ve otomatik olarak gösterir. Bir depoda birden fazla BENİOKU dosyası varsa, gösterilen dosya konumlardan aşağıdaki sırayla seçilir:

1. Dizin .github
2. Deponun kök dizini
3. Dizin docs

Bazı Olağanüstü BENİOKU örnekleri’ne göz atın.

Proje başlatıldıktan sonra, e-postayı ve diğer ağ kanallarını kullanarak yükseltin. Uygun bir hedef kitleye ulaşmak, proje katılımında önemli bir artış sağlayabilir.

GitHub belgelerinde BENIOKU dosyaları hakkında daha fazla bilgi edinin.

GitHub'da projeleri yönetme

Projeler ilgi çektikçe, kullanıcıların ve katkıların akını yönetmek için çok fazla çalışma gerektirebilir. Projeye bağlı olarak, yalnızca proje katılımcılarının beklentilerini yönetmek için önemli miktarda çalışma gerekebilir.

GitHub, bu sorunu proaktif olarak çözmek için CONTRIBUTING.md bir deponun kökünde (veya /docs veya /.github) bir dosya arar. Projenin katkı ilkesini açıklamak için bu dosyayı kullanın. Tam ayrıntılar farklılık gösterebilir, ancak olası katkıda bulunanlara projenin hangi kuralları izlediğini bildirmek iyi bir fikirdir. Örneğin, ekibin çekme isteklerini nerede aradığı, hata raporları için hangi ayrıntıların istendiği vb.

CONTRIBUTING.md Varsa, kullanıcılar sorun oluşturduğunda veya çekme istekleri oluşturduğunda GitHub bu bağlantının bağlantısını sunarak onları takip etmeye teşvik eder.

Bazı Olağanüstü CONTRIBUTING.md örnekleri’ne göz atın

Ayrıca, kod değişikliklerini gözden geçirmekle sorumlu olan bireyleri veya ekipleri tanımlamak için depoya bir CODEOWNERS dosyası eklemeyi göz önünde bulundurun.

Sorun ve çekme isteği şablonları oluşturma

GitHub, yeni sorunlar ve çekme istekleri için başlangıç şablonlarını destekler. Yeni oluşturulan bir sorunun veya çekme isteğinin ilk açıklama metnini sağlamak için bu şablonları kullanın.

Örneğin, projenizde .github/ISSUE_TEMPLATE.mdvarsa, bir kullanıcı sorun oluşturma işlemini başlattığında bu içeriği görür. bir 'den CONTRIBUTING.mdgerekli ayrıntılara sürekli başvurmak zorunda kalmak yerine, şablon metnini kullanarak sorunu form gibi doldurabilir.

Çekme istekleri için de aynıdır; tek fark olarak, bunun yolu .github/PULL_REQUEST_TEMPLATE.md şeklindedir.

Bazı Olağanüstü GitHub sorun ve çekme isteği şablonları’na göz atın.

İş akışlarını tanımlama

Dışarıdan katkıları teşvik eden projeler için, projenin hangi iş akışını izlediğini belirttiğinizden emin olun. İş akışı, hatalar ve özellikler için dalların nerede ve nasıl kullanılması gerektiğiyle ilgili ayrıntıları içermelidir. Ayrıca çekme isteklerinin nasıl açılması gerektiğini ve depo ekibi dışındaki kişilerin kod göndermeden önce bilmesi gereken diğer tüm ayrıntıları da içermelidir. Henüz aklınızda bir iş akışı yoksa, GitHub akışını göz önünde bulundurmanız gerekir.

Yayınları ve dağıtımları yönetmeye ilişkin bir strateji aktarmanız gerekir. İş akışının bu bölümleri günlük dallanmayı ve birleştirmeyi etkiler, bu nedenle bunları katkıda bulunanlara iletmek önemlidir. Bunların Git dallanma stratejinizle ilgisi hakkında daha fazla bilgi edinin.

Program başarısını ölçme

InnerSource’u düşünen tüm takımlar, programlarının başarısını ölçmek için ne tür ölçümleri izlemek istediğini düşünmelidir. "Pazara giriş süresi" ve "bildirilen hatalar" gibi geleneksel ölçümler halen geçerli olsa da, InnerSource’un sağlayacağı avantajları göstermek zorunda değildir.

Bunun yerine, dış katılımın proje kalitesini nasıl artırdığını gösteren ölçümler eklemeyi göz önünde bulundurun. Depo, hataları düzelten ve özellikler ekleyen dış kaynaklardan çekme istekleri alıyor mu? Proje ve geleceğiyle ilgili tartışmalarda aktif katılımcılar var mı? Program, kuruluşun başka bir noktasındaki avantajları destekleyen bir InnerSource genişlemesine ilham kaynağı oluyor mu?

Kısacası ölçümler, özellikle bireysel ve takım katkılarının değerini ve etkisini ölçme konusunda zordur. Ölçümler yanlış kullanılırsa, kültüre, mevcut süreçlere zarar verebilir ve kuruluşa veya liderlik takımına yönelik kolektif duyguları azaltabilir. InnerSource benimsemesini ölçmeyi düşünürken ölçümlerle ilgili aşağıdaki yönergeleri göz önünde bulundurun:

• Çıktı değil ölçüm işlemi
  • Kod incelemesinin döngü süresi
  • Çekme isteği boyutu
  • Süren iş
  • Açılış süresi
• Mutlak değerlere değil, hedeflere karşı ölçüm yapma
• Bireyleri değil ekipleri ölçme
  • Bir projeye yönelik benzersiz katkıda bulunanların sayısı
  • Kodu yeniden kullanan proje sayısı
  • Takımlar arası @mentions sayısı

Bu InnerSource örnek olay incelemelerinde başkalarının keyif aldığı başarılar hakkında bilgi edinin.