(Çoğunlukla) terk edilmiş bir GitHub projesine nasıl katkıda bulunmalıyım?


43

Geçenlerde GitHub’da açık kaynaklı işbirliğine girmeye çalıştım ve ilerlemenin tercih edilme şeklinin ne olduğunu merak ediyorum.

Yaklaşık bir ay önce GitHub'da bir süredir kullandığım ve birkaç hata bulduğum (ve düzelttiğim) bir kütüphane için bir proje buldum.

GitHub işbirliğine ilk adım attığımda, en yüksek aktivite hacmine sahip görünen, bir hata düzelten, birim testleri ekleyen, GitHub'a itilmiş ve çekme isteği yapan repo buldum. Birkaç saat içinde, bahsettiğim deponun sağlayıcısı, PR'ı kabul etmiş ve diğer bazı PR'lerle de beklemekte olan diğer kişilerden birleşmiştir.

Buna bağlı olarak, her biri kendi depomun ayrı bir kolunda bulduğum üç hata daha düzelttim ve her biri için ayrı ayrı bir sorun oluşturup talepte bulundum.

Bu sadece bir ay önce oldu ve çekme talepleri o zamandan beri orada dokunulmamış, orada oturuyorlardı. Repo'yu bıraktığım kullanıcı, çok aktif görünmüyor, geçen yıl GitHub’a yalnızca 7 katkı yaptı ve bu repo, yaptığım ilk çekme isteğinden bu yana hiçbir taahhütte bulunmadı.

Öyleyse benim sorum:

Bu durumda kişi nasıl ilerler? İdeal olarak, kendi depomda ana repo ile birleştirilmemiş bir sürü değişiklik yaparak, kütüphanenin parçalanmasını önlemek istemem. Bununla birlikte, hata düzeltmeleri yapmaya ve özellikler eklemeye devam etmek istiyorum, ancak ana şubeme her şeyi birleştirip bu daldaki tüm yeni düzeltmeleri temellendirirsem, o zaman çatalladığım repo sağlayıcısının geri gelmesi durumunda kazandım. Tüm değişikliklerin her özellik / hata düzeltme için ayrı çekme isteklerine bölünmesi mümkün değil (çekme isteklerinin genellikle her özellik veya hata düzeltme için bir çekme isteği olması gerektiğini okudum).

Orijinal repo ile uyumlu olan bir şubeyi tutmalı mıyım, tüm yeni şubelerimi bunlardan uzak tutmalı ve ardından tüm şubelerimi ana şubemde birleştirmeli mi? Her zaman yeni şubeleri bir araya getirmem gerektiğinde, beni bir sürü dalla ve giderek daha ağır bir işle bırakacak gibi görünüyor.

Bunun böyle bir duruma yaklaşmasının tipik yolu nedir? Yeni çekme taleplerini gözden geçirmek üzere olmayan bir projenin asıl katkıda bulunanlarla birlikte terkedilmesi oldukça yaygın görünüyor. Bu, birinin dümeni alması ve onunla koşması gereken bir durum mu? Asıl katkıda bulunanlar bir daha geri gelirlerse ve proje üzerinde tekrar çalışmak isterlerse, parçalanma yaratacak gibi görünüyor.


4
Bu soruyu ilginç bulduğunuzda, yeni bir açık kaynaklı stackexchange sitesi önerisiyle de ilgilenebilirsiniz .
Philipp,

Sadece meraklı izleyiciler için e-posta görüşmesinden çıkanları paylaşmak ister misiniz? :)
winkbrace

@ winkbrace Şimdiye kadar hiçbir şey. Yanıt alamadım, ancak e-postayı yalnızca iki gün önce gönderdim. Bir şey olursa, hepinize haber vereceğim.
JLRishe

Yanıtlar:


39

Henüz böyle bir durum yaşamadım, ama deneyeceğim şey buydu:

Sahibiyle iletişime geçmeyi deneyin

Belki de gerçekten ilgilerini yitirdiler, ancak projeyi başkasına devretmek istiyorlar, özellikle de zaten kaygılı bir taahhütte bulundular.

Fakat belki de sadece başka bir şeyle meşguller (iş, tatil, hastalık, diğer projeler) ve PR'ınızı idare etmek için zamanları yoktu, ancak daha sonra yapmayı planlıyorlar.

Ya da belki de, ne sebeple olursa olsun, proje üzerinde kalıcı olarak çalışmaları durdurdular.

Sormadan, öğrenemezsin.

Toplulukla iletişim kurun

Elbette, projeye katkıda bulunan veya en azından bu projeyi kullanan başka insanlar da var. Projeyi kimin çatalladığını kontrol edin (herhangi bir değişiklik yapmamış olsalar bile, bu projenin gelişmesini görmekle hala ilgilenebilirler); kimin sorun bildirdiğini kontrol et ya da onlara yorum yap. Belki GitHub dışında bir e-posta listesi, forum veya StackOverflow üyeleri de olabilir.

Sonunda projeyi gerçekten ele geçirirsin, onların desteğini isteyebilirsin. Ve yeni ana deponun nerede olduğunu bilmeleri gerekir.

İyi çekme istekleri yapmaya devam et

Bu, hem sahibi hem de topluluğa bu konuda ciddi olduğunuzu gösterir ve onların katkılarınızı yargılamasına izin verin.


1
Teşekkür ederim. Biraz daha arama yaptıktan sonra, bu tavsiye npm paketleri ile bu tür bir durum için mevcut yönergelere benzer görünüyor . Sadece sahibine e-posta gönderdim ve ne yanıt verdiğini göreceğim.
JLRishe

Belirli bir repo için PR'leri onaylama yeteneğine sahip birini bulmak çok zor, ancak repo "sahibi" aslında onlarca kişiden oluşan bir organizasyon.
cowlinator

15

Özgün reponun sahibi hiçbir yerde bulunmazsa ve kayda değer bir şey yoksa, kendi havuzumu projenin farklı bir sürümü olarak yayınlarım.

Bununla, kütüphanenin gelişiminin öncülüğünü devralır ve bir daha asla güncellenmeden köşesinde ölmeye bırakmazsın. Asıl mal sahibi repoyu kapatırsa, dünya hala çatallı sürümü kullanabilir.


1
Evet, sadece forkproje ve içinde README.md, asıl sahibine bir referans ve "teşekkür" bırakın.
Jared Burrows,

Cevabınız için teşekkür ederiz (+1). Kesinlikle iyi puanlar verirsin. Nihayetinde buna başvurabilirim, ama şimdilik, oefe'in tavsiyelerine uyacağım ve e-posta yoluyla repo sahibiyle temasa geçip geçemeyeceğime bakacağım.
JLRishe

Tabii ki, sadece deponun unutulmasına izin vermeyin. Orijinal malların artık yok olması nedeniyle Github'un derinliklerinde bir sürü gizli kodun saklanması gerekiyor.
cllamach

Benzer bir durumdayım ve bu seçeneği kullanmam gerekebilir - bir projenin orijinal sahibi tekrarlanan temas denemelerine cevap vermedi. Projenin adını saklamak ve sürüm numarasını son resmi sürümden arttırmaya devam etmek koşuşturucu mu? Adı değiştirirsem, projenin mevcut kullanıcılarının bulmasının zor olacağını düşünüyorum.
pericynthion

1
Ben de o durumda olabilirim. Ancak orijinal proje zaten Bower'a kayıtlı. Adı saklamak, asıl yazarın sizin adınıza kaydını kaldırmasını sağlamak veya Bower'lı bakıcılarla iletişim kurmak ve müdahale etmelerini istemek anlamına gelir. Ancak ikincisini yapmak umrumda değil. Yeniden adlandırma en iyi seçenek olabilir.
Lawrence I. Siden

0

Bugünlerde küçük ve orta ölçekli Serbest ve Açık Kaynak projeleri çoğu github, gitlab veya benzeri yerlerde barındırıldığından, bazı işlemlerin Web API'lerini kullanarak otomatikleştirilmesi mümkün olacaktır .

Orijinal reponun olduğu varsayılırsa, https://github.com/someUserX/projectY/süreç şöyle görünebilir:

  1. ("el kitabı") Orijinal yazara, en azından git müşteri e-postası ve bir sorun (eğer etkinse) aracılığıyla farklı şekillerde ulaşın.

    Birkaç hafta içinde alınan bir izin veya hiç yanıt alınmaması durumunda, aşağıdaki gibi adımları gerçekleştirmek için barındırma Web API'sini kullanacak bir komut dosyası çalıştırılabilir:

  2. adlı yeni bir Git (GitHub) organizasyonu oluşturun projectYve orjinal repo'yu çatallayın ->https://github.com/projectY/projectY/

  3. Orijinal yöneticiyi ve tüm çekme isteklerinin yazarlarını (zaten birleştirilmiş ve hala açık) kuruluş yöneticileri olarak ekleyin
  4. yeni depodaki orijinal depodan tüm (açık) çekme isteklerini yeniden oluşturun
  5. (açık) konularla aynı şeyi yapın
  6. Yeni deponun tüm yöneticilerine bildirir.
  7. eski depoya son bir çekme isteği oluştur, "terk edilmiş" / "arşivlenmiş" bir bildirim ekleyerek ve README'nin üstündeki yeni depoya bağlantı ekle

Bu yaklaşımla karşılaştığım asıl mesele, bazı "kötü" katkı yapanların yönetici erişimine sahip olabileceği, ancak Özgür Yazılım habercisi Pieter Hintjens'in açıkladığı gibi (örneğin bu konuşmada) kötü sözler geri alınabiliyor ve hiçbir konu açmıyor Hayatta olan ve zaman zaman kötü niyetli firmanın iyi bir proje olmasına yardımcı olabilecek bir proje.
hoijui
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.