Böcek Takibi Görgü Kuralları - Nezaketsizlik mi, Kopya mı?

İstenen geliştirmeyi yapmak için gerekli araçların bulunmamasından dolayı "çözüldü (düzeltilmiyor)" olarak işaretlenmiş bir açık kaynak projesinde hata izleyicide gerçekten eski (2 + yıl) bir özellik isteği sorunuyla karşılaştım. Bu belirleme yapıldıktan sonra geçen sürede, çözümlenmesini sağlayacak yeni araçlar geliştirildi ve bu uygulamanın topluluğunun dikkatine sunulmasını istiyorum.

Ancak, böyle durumlarda, genel olarak kabul edilen görgü kurallarının böcek izlemesi için ne olduğundan emin değilim. Açıkça, eğer sistem açıkça çoğaltılmayacağını belirtirse ve aktif olarak yeni öğeleri kopya olarak işaretler (SE sitelerinin yaptığı gibi), o zaman cevap sistemin söylediklerini takip etmek olacaktır. Ancak, sistem açıkça şunu söylemediğinde, ya da yeni bir kullanıcı sistemin tercihi olan bir yeri kolayca bulamadığında ne olur? Çoğalmanın ya da büyülüğün yanında hata yapmak daha iyi kabul edilir mi? Bu, bir hata mı yoksa özellik isteği mi olduğuna bağlı olarak değişir mi?

Buna yeterince cevap verebilecek tek şey kuruluşunuzun sürecidir. Bu durum tanımlanmazsa, her gerçekleştiğinde tutarlı olacak şekilde tanımlanmalıdır.

Eskisini yeniden açmanızı ve uygun şekilde yeni bilgiler eklemenizi öneririm. Ölçümler / ölçümler perspektifinden bakıldığında, bu muhtemelen en az zararlı olacaktır - yeni şey yeni bir kusur veya iyileştirme değil, eski olanı tekrar gözden geçirmek. Gelen değişiklik talepleri için sorumlu tarafın kim tarafından gözden geçirilmesi gerektiğini belirten bir durum olmalıdır. Devleti buna geri döndürerek tarihi (daha önce bir kez ertelenmiş olduğu gerçeğini) ve aynı zamanda yeni bilgiyi de kolayca görebilirler.

Yaptığım (ve geçmişte yapmış olduğum) yeni bir hata yaratmak (alaka vermek için), olası / yeni düzeltmeyi not etmek ve geçmişe referans / izleme için eskisine link vermek.

bu aynı zamanda hataya bağlıdır ... hata şu anda bir "özellik" olabilir veya insanların 2 yıl boyunca kullandıkları ve çözüme kavuşturulacak olan köklü çalışmalara sahip olabilir.

Temel olarak, hatayı ve potansiyel düzeltmeyi araştırıp incelemelisiniz ve hala düzeltilmesi gerektiğini düşünüyorsanız, hatayı günlüğe kaydedin.

Bir programcı olarak, bilgilerin kopyalanmasının genellikle kötü bir şey olduğunu ve mümkün olduğunda kaçınılması gerektiğini düşünüyorum. Hata izci veritabanında bir tablo "Sorunlar" düşünün. Bu tablodaki her kayıt benzersiz bir sorunu temsil etmelidir. Aynı hata için ikinci kayıt eklediğinizde, aslında bir hatanın kendisini değil, bazı kullanıcıların onu keşfettiği ve bir tarih ve saatte yayınladığı gerçeğidir. Gerçek şu ki, mevcut sorun hakkında bazı ek bilgiler yayınladınız. Bu bilgi "IssueComments" tablosu veya benzeri bir şey gibi farklı bir yerde saklanmalıdır.

Benim bakış açıma göre, büyüsellik daha az kötüdür. Eğer büyücülük bir sorunsa, büyücülüğün kendisiyle değil, soruna neden olan bir şeyle mücadele etmeliyiz (eski böcek hakkında yeni bir bilgi bulduysanız, bunun nesi yanlış? Bu tamamen doğal). Örneğin, biri eski kapalı hata hakkında yorum gönderirse, bu bir şekilde ilgili tüm kullanıcıların dikkatini çekmelidir.

Belki de yeni bir hata raporu açıp eskisine bağlayabilirsin. Düzeltmek isteme nedenlerinizi gerekçelendirin. Bu düzeltmenin mevcut davranışı bozması (ikili uyumluluk veya uygulama ile çalışma şeklini değiştirmesi) ve düzeltmenin değersizden daha fazla soruna neden olabileceği durum olabilir. Düzeltmenin minimal etkisi varsa, düzeltilmesi için herhangi bir itiraz olmayabilir.

Tam olarak neden ilk başta düzeltmemeye karar verildiğine karar vermelisin.

Bunun hata ve özellik isteği arasında farklı olduğunu söyleyebilirim.

Bugtracker'da bir hata raporu oluşturduğunuzda, genellikle belirtileri açıklarsınız. Bununla birlikte, altta yatan nedenin aynı veya hatta benzer olduğu anlamına gelmez. Özellikle de dahili kullanıcılar son kullanıcıdan gizlenmişse ve bir şeylerin yanlış gittiği andaki tek şey genel bir hatadır. Bu gibi durumlarda, doğaçlama, dış semptomlar benzer görünse de, olayı tamamen farklı bir hatadır. Eski böceği yeniden açacak olursanız, geliştirici muhtemelen eski nedenini araştırmaya başlayacak ve bu da onu tamamen yanlış yöne ve gevşek bir zamana götürebilir.

Reddedilen özellik isteği ve reddetme nedenleri artık geçerli değil, yanlışlık gitmenin yolu olduğunu söyleyebilirim. Bu durumda, yeni bilet oluşturmanın tam kopya oluşturacağınızı biliyorsunuzdur.