Hata düzeltme eki kimin sorumluluğundadır?

Açık kaynaklı projelerde birkaç kez ortaya çıkan bir durum şöyle:

1. Konuşlandırmamızda bir hata fark ettim ve hızlı bir kesmek yaması buldum. (Örneğin, gerçekten ihtiyacımız olmayan kodu yorumlamak yeterlidir.)
2. Gerçek hatayı bulmak, bir yama bulmak ve bir Git çekme isteği veya benzeri bir yolla göndermek için biraz fazla çaba harcıyorum.
3. Çekme isteğim reddedildi. Belki de yama mükemmel değildi (örneğin, içermemesi gereken satırlar dahil), belki kodlama stilini ihlal etti, belki de başka sonuçları vardı. Ya da Git'te yanlış bir şey yaptım - çekme isteği yeniden temel almalıydı. Bir destekçi, yamanın nasıl geliştirileceği hakkında geri bildirim sağlar ve yeniden göndermemi ister.

Bu noktada ne kadar ilerlemem gerektiği konusunda kafam karıştı. Bildiğim kadarıyla bir sorunum yok: 1. adımda düzelttim. Sorunu bildirdim, başkaları için düzeltmek için bile adımlar attım. Ama bunun "benim" çekme isteğim olduğunu düşünmüyorum, bu yüzden yamayı geliştirme sorumluluğunun bana gelmesi gerektiğini düşünmüyorum.

Beni rahatsız eden belirli bir durum, yamamın başarısızlıkları hakkında tartışmadan sonra, bir posta listesinde doğru yamanın ne olacağı konusunda anlaşmaya varıyoruz (yani, nasıl davranılması gerektiği, bazen her kod satırı dahil). Daha sonra, yamayı gerçekten oluşturmak ve göndermek benim sorumluluğum olarak kabul ediliyor.

Bu durumlarda standart bir görgü kuralları var mı? Nasıl çözülür? Tepkim sıra dışı mı? Hata düzeltmenizi almak için ne kadar ilerlemeniz bekleniyor?

("Açık kaynak projesi" dediğimde, bunlardan bazıları çok küçüktür, ancak hobiler olmayabilir - sadece geliştirici kaynaklarını üzerinde çalışmak isteyen birçok kuruluş için kullanılan küçük yazılım projeleri. "düzeltme ekini düzelt ve yeniden gönder", işverenimin kendileri için yararlı olabilecek şeyler üzerinde çalışma sorumluluğum olduğunu anlıyorum. Bizi etkilemeyen bir hatayı düzeltmek için zaman harcamak yanlış olur ...)

Endişe ettiğim kadarıyla, bir hata bulursanız veya bir geliştirme isteğiniz varsa, projeye katkıda bulunmazsanız ve uygun kanallar aracılığıyla bir kusur raporu gönderdiyseniz, işiniz bitti demektir. Topluma geri dönme açısından, açık kaynaklı bir proje kullanan ve bir kusur bulan herkes bunu rapor etmelidir.

Bir çözüm bulmayı, tasarlamayı ve uygulamayı denemek projeye bir bonus. Bunu yaptıysanız, bir çekme isteği yoluyla veya belki de çalışacakları bir şey vermek için geliştirme raporuyla birlikte geliştirme ekibine dosya deltaları göndermek yoluyla göndermek iyi bir fikir olabilir. Ancak, projeye katkınızı kabul etme yükümlülüğü yoktur.

Bir kullanıcının yamalara katkıda bulunmasını beklemek bana yanlış geliyor. Bir sorun hakkında bir tartışmaya katılmak oldukça kolaydır, ancak bir çözüm bulmak çok daha büyük bir zaman yatırımıdır. Hiçbir proje, katkıda bulunmayanların tek bir sorunu çözmek için katkıda bulunmasını beklememelidir.

Buna katlanmak istediğiniz kadar ilerleyin. Yamanızı düzeltmek ve ana gövdede dünyayla paylaşmak güzel olurdu, ancak bakımcı istemiyorsa omuz silkin. Sorununuzu ve bununla ilgili yamayı bir yere gönderebilirsiniz, böylece aynı teknedeki diğerleri bir çözüm arayabilir.

Ve sen problemsiz değilsin. Yamanız bir sonraki yükseltmede olmayacak. Bu nedenle, yeni bir sürüm aldığınızda yeniden yüklemeniz ve çalışmasını veya yerine masaj yapmasını ummanız gerekir. Yani ana projeye dahil olmak sizi ve şirketinizi uzun vadede zamandan tasarruf ettirecektir.

Bu senin için acı ama topluma katkıda bulunuyorsun. Katkıda bulunanların yaptığı tüm çalışmaları kesinlikle takdir ediyorum. Kaliteli yazılım gibi değil sadece sihirli bir şekilde genesis kitlelerden. Birisi işi yapmak zorunda. (Peki kim harika? Sen harikasın). Eğer bunu hissetmiyorsanız, topluluğa nasıl olması gerektiği konusundaki tartışmayı takdir ederken, bunu yapmak için çok meşgul olduğunuzu bildirin. Yani, ne yapacaklar? Maaşını mı kesiyorsun?

Açık kaynak kültürünün anlaşılmasını kolaylaştıran bir ilke vardır: işi yapan kişi ne üzerinde çalışılacağına karar verir. Bu, geliştiricilerin günlük işleriyle karşılaştırıldığında itirazlarından biridir. # 1 önceliğiniz biriktirme listesinde # 50 olabilir. Çekme talebinizi düzeltmezseniz, sonunda muhtemelen yukarı doğru damlar ve bununla ilgilenir. Ancak, onlar için yeterince kolaylaştırırsanız, şimdi ilgileneceklerdir.

Çekme talebinizi düzeltmenizi istedikleri diğer neden daha büyük. Katkılarınız için olabildiğince küçük bir kredi almanızı istiyorlar. Düzeltmeyi yaparsanız, adınız, taahhüdün yazar alanındaki addır. Çoğu insan bunu görmek isteyecek katkılarından gurur duyuyor, bu yüzden koruyucunun varsayılan modus operandi onlara izin vermektir.

İşvereninize karşı sorumluluğunuza göre, işiniz bu koda bağlıysa, onlara bir kötülük yapmazsınız. İşverenler, aletlerini keskinleştirmek için zaman alan bir işçinin faydasını bilirler.

AFAIK, açık kaynak yolu, hataların düzeltilmesinin sorumluluğunun, düzeltildiğinden emin olmak için yükü halletmek için hatayı yeterince önemseyen kişiye bırakılmasıdır. Koşullara bağlı olarak, bir sorunu görmezden gelmekten savaşa kadar (yamaları sağlayarak kabul edilmelerini savunarak) düzeltildiğinden emin olmak için her şeyi yaptım.

Her şey doğru, sadece projeyi yöneten insanların sizden yanlış bir şey beklemelerine izin vermeyin (yani, tartışma seçeneklerini kullanarak sorunu doğru bir şekilde çözeceğinizi ve sonra hiçbir şey yapamayacağınızı ummalarını sağlayın), muhtemelen onlardan daha fazla sorunun farkındalar. kendilerini idare edebilir ve eğer mümkünse tekrarlayan bir katkıda bulunmaya çalışacaktır.

Orijinal hata sadece sizi etkileyebilir, bu nedenle yamanızı uygun hale getirmek için gerekli olan her şeyi yaparak teslim almak çok önemlidir. Aksi takdirde çektiğiniz bir sonraki sürümde (başka düzeltmelere ihtiyacınız olduğu için) düzeltmeniz eksik olacaktır.

Projenin her yeni kopyasını çektiğinizde uygulamanız gereken yamaların bir listesini tutmak istemezsiniz - bu çok fazla sorun. Biraz ekstra zaman ayırın ve kalıcı olarak sabitleyin, böylece tekrar uğraşmanıza gerek kalmaz.

Açık kaynaklı bir geliştirici için iki tür sorun vardır:

• (a) düzeltme eki olmayan sorunlar
• (b) bir yamadan kaynaklanan sorunlar

Çoğu açık kaynaklı paket koruyucusunun / geliştiricisinin yamaları olmayan bir hızlandırıcıya yardımcı olma fikrini SEVİYORUM.

Bununla birlikte, birincil hedefleri tip-b problemlerinin sayısını en aza indirmektir. Bu yüzden bar oldukça yüksek.

Bazı insanlar bunu aştı. Katkıda bulunanlar, hatta belki de çekirdek katkıda bulunanlar olurlar. Diğerleri pes eder. Açık Kaynak için belirli bir Darwinci doğa var - en uygun olanın hayatta kalması.

Katkılarınızı ekibin kabul ettiği noktaya bastırmaya ve tükürmeye teşvik ediyorum. Birkaç katkı yaptıktan sonra size daha fazla güveneceklerdir, ancak yine de katkılarınızın kusursuz olduğundan emin olmalısınız.

Sonuç tamamen buna değer. "Kod yazıyor muyum? Evet ... Her gün yazdığım bir şeyi çalıştırıyorsunuz" gibi şeyler.