Github sorunları (öncelik vb.) Nasıl yönetilir? [kapalı]


49

Github'da yeniyim ve sorunların nasıl yönetileceği konusunda tavsiye arıyorum. Öncelik ve diğer sipariş seçeneklerine sahip olmaya alışkınım ama hiçbiri olmadığını görüyorum.

Diğerleri bir hatanın / özelliğin kullanım ömrü boyunca sorunları nasıl yönetir?

Şimdiden teşekkürler.


1
Cevaplara göre, aşırı görüşe dayalı görünmüyor - ilk ikisi hemen hemen aynı ayrıntıları ele alıyor (üçte biri birkaç kez daha aynı cevapları içeren cevaplarla - birkaç ipucu ve püf noktası sonrası - ve eksik özelliklerin daha fazlasını ekleyebilecek bir üçüncü taraf servisi için bir gönderi). - SO'nun soru-cevap formatı için çok uygun gibi görünüyor, hiç bir fikre dayanmıyor, sadece "X'in özelliği nerede" ve insanlar cevap verdi. - Umarım bu soru tekrar açılır, böylece birileri cevaplayıcı kredisi alabilir.
BrainSlugs83 9

Yanıtlar:


52

Sorun türleri , sorun öncelikleri , sorun durumları , sürüm etiketleri ve daha fazlası gibi farklı etiket gruplarını tanımlayabilirsiniz . Bir etiketin hangi gruba ait olduğunu anında görebilmek için, benzeri bir adlandırma kuralını kullanabilirsiniz <label-group>:<label-name>.

Böyle bir adlandırma kuralının kullanılması, Github sorunlarını yönetmeyi çok daha kolay hale getirmeli ve başkalarının sorunları daha hızlı "anlamalarına" yardımcı olacaktır. Okunabilirliğe daha da fazla katkıda bulunabilecek etiketlere de renk atayabileceğinizi unutmayın (Her etiket grubu için belirli bir renk kullanırdım). Ancak bu etiketleri el ile / sorunlara manuel olarak atamanız / atamanız gerektiğinden, genel grup / etiket listesini küçük tutmak isteyebilirsiniz.

Yukarıda önerilen şemaya göre grupları ve ilgili etiketleri aşağıdaki gibi tanımlayabilirsiniz.

'sorun türü' grubu

  • Türü: Hata
  • Türü: özellik
  • Türü: Fikir
  • Türü: geçersiz
  • Türü: Destek
  • Türü: Görev

'sorun önceliği' grubu

  • prio: düşük
  • prio: Normal
  • prio: Yüksek

'sorun durumu' grubu

(Bu etiketler bir konunun tanımlanmış bir iş akışındaki durumunu tanımlar.)

  • Durum: Onaylandı
  • Durum: Ertelenmiş
  • Durum: düzeltme-taahhüt
  • Durum devam ediyor
  • Durum: Eksik
  • Durum: reddedilen
  • Durum: çözüldü

'yayın bilgisi' grubu

  • bilgi: geribesleme ihtiyaç duyulan
  • bilgi: help ihtiyaç duyulan
  • bilgi: ilerleme-25
  • bilgi: ilerleme-50
  • bilgi: ilerleme-75

'sürüm etiketi' grubu

  • ver: 1.x
  • ver: 1.1

2
Ancak bu sıralama çözmez, değil mi?
Pavel S.

4
Merhaba, MSO sorunuzu farkettim. Reddedilen bir taşıma işlemi olduğundan soru otomatik olarak silindi. Bununla birlikte, Yığın Taşması ile ilgili orijinal kopya da silinmiştir, bu nedenle sorunun ya da yanıtlarının kopyası kalmamıştır. Etrafında en az bir kopyasının olmaması, hatta kapalı olması için hiçbir neden göremiyorum, bu yüzden bu dosyayı sildim. Bir dahaki sefere tartışmak istediğiniz bir Programcıya özel bir konunuz olduğunda, lütfen Meta Programlayıcıları gündeme getirin , sadece MSO sorunuzu kazara gördüm.
yannis

@YannisRizos: Kesinlikle mükemmelsin (+1). Hızlı yanıtınız, geri aldığınız ve açıklamalarınız için teşekkür ederiz :)
Jonny Dee

Sadece şu bilgilere sahip olduğumuzu eklemek isterim: progress-X aşırıdır. Bir bilgi ile aynı fikirdeyim: ilerleme içinde ama ilerlemeyi ölçmek biraz gerginlik. % 90 bitmiş olduğumu düşündüğüm birkaç sorun yaşadım ve sonra bir şey gördüm ve sadece% 50 bitmiş olduğumu biliyordum. Şimdi bunun github'da olması bence sadece zaman kaybı olur.
AntonioCS

22

GitHub sorunu izci oldukça esnektir. Gerçekten de öncelik yok, sipariş yok. Üç ana sütun etrafında döner: Atamalar , etiketler ve kilometre taşları .

  • Oluşturduğunuz etiketlerle ilgili sorunları "etiketleyebilirsiniz" (Gmail etiketlerinden benzer şekilde). Örneğin: "bug", "feature-request", "todo", "question", ... Bir sorun farklı etiketlerle etiketlenebilir.

  • Birkaç konuyu " dönüm noktası " olarak paketleyebilirsiniz . Bir başlık (örneğin bir sürüm numarası) ve isteğe bağlı bir teslim tarihinden oluşur.

  • Her konu havuzun bir ortak çalışanına (katkıda bulunan veya kuruluş üyesi) atanabilir . Git'de bir ortak çalışmasını hatta @GitHub girişini takip eden bir yorumda toplayabilirsiniz .

Sonunda, kenar çubuğu sayesinde, sorunların listesini yönetmenize yardımcı olmak için "filtreleyebilirsiniz".

Bu konuda tam bir blog yazısı "Issues 2.0" , size özelliklerin daha ayrıntılı bir görünümünü verecektir.


1
Çok yararlı, teşekkür ederim. 'Eski' sorunlarımı yönetme yöntemimi öğrenmem gerekecek gibi görünüyor. Sadece önceliklendirme nosyonundan vazgeçiyor musunuz? Normalde bir hata listesini gözden geçirir, daha sonra geliştiricilere atanacak öncelikleri atardım. Yönetici olarak düşüncemi nasıl değiştiririm? Zaten inceledim ve önceden düşünüldüğüm sorunları gözden geçirmek için daha fazla zaman harcamak zorunda kalacağımı hissediyorum. Öneriler veya belki de örneklere bir gösterici takdir edilecektir.
djf

1
Johnny Dee'nin cevabında olduğu gibi @djf, öncelik atamak için etiketleri kullanabilirsiniz.
David Brown

8

Kullandığım huboard.com Kanban kurulu şekilde github sorunlarını temsil etmek ve sonra sürükleyip huboard içinde bırakarak sıralayabilirsiniz. Yalnızca önceliği görselleştirmek ve daha sonra ne çalışacağını bilmekle ilgileniyorsanız, oldukça iyi çalışıyor.

Bir HTML yorumu olarak, gerçekte konunun içindeki önceliği saklar:

Your normal issue text here...
<!---
@huboard:{"order":465.0}
-->

Şimdi bu amaçla waffle.io kullanıyorum. Biraz daha hoş.
joseph.hainline

5

Projelerimizi yönetmek için github'ta etiketleri nasıl kullandığımıza örnek

Kategori Etiketleri (görsel olarak ayırmak için tüm büyük harfleri de kullanabilir)

  • Görev
  • böcek
  • özellik
  • Tartışma

Öncelikli Etiket

  • ACİL

Her şeyin normal önceliği olduğunu düşünüyoruz ve gerçekten "düşük" bir ihtiyaç görmüyoruz. Böylece bu, hemen ilgilenilmesi gereken şeyleri işaretlemek için yalnızca bir etiket bırakır.

Durum Etiketleri

  • incelendi (atanan okudu)
  • sıraya alındı ​​(görevli yakında işe yarayacak)
  • devam eden iş (görevli şimdi üzerinde çalışıyor)
  • geçersiz (eğer hata yeniden üretilemezse)
  • geri bildirime ihtiyaç duymak (insanların okumalarını ve yorum yapmalarını veya yardım sağlamalarını sağlamak için yarasa sinyali)

Tüm belgeleri, nasıl yapılacağını, mimariyi, altyapıyı, vaka incelemelerini, planlamayı ve gereksinimleri içeren bir wikide tutuyoruz.

Çekme-İstekler bir kodun parçasıysa kod incelemeleri ve özellik tartışması içindir

Filtrelemenin yaratıcı bir şekilde kullanılmasıyla, gün için yapmamız gereken işleri bulabiliriz. "Görev + ACİL" veya "Hata + ACİL" her zaman "geribildirim gerekir" olarak etiketlenmiş sorunları gözden geçirir ve eklemek istediğiniz bir şey olmasa bile yorum bırakır. Tabii ki bu beş kişilik ekibimizle çalışıyor ama muhtemelen bundan daha fazlası değil.


1

GH konularında iki tür etikete gidiyorum - ilk konu türüyle, ikincisi öncelikle ilgili:

  • böcek
  • özellik - (yeni şeyler)
  • geliştirme - (mevcut işleri iyileştirme)
  • soru / tartışma - (tartışma)

Wiki'yi iyi kullanırsanız, soru / tartışma gerekli olmayabilir. Ama hoşuma gidiyor çünkü belirli bir kişiye bir soru veya bir fikir yönlendirmemi sağlıyor.

O zaman gerçekten üç basit öncelik etiketi var:

  • şimdi
  • yakında
  • sonra

Kolay değil mi?


1

Yukarıda önerilen etiketleme çözümleri yanı sıra, elimizdeki blockingve blockedetiketler gibi.

Bir sorunun ilk önce doğru kişiye atanması gerekir, ancak bu kişi, başka bir konu tamamlanana kadar konu üzerinde çalışamazsa, konu olarak işaretlenir blocked. Ve diğer konu bir karma etiketi kullanılarak belirtilir.

Benzer şekilde, bir görev bir başkasının bir şey üzerinde çalışmasını engelliyorsa blocking, diğer konuya referansla işaretlenmelidir .

Belirli bir kişiye atanan öğelerin nasıl listeleneceğini bulmak biraz zor buldum;

Çözüm, 'arama' simgesine tıklamak (girilen arama kriterleri olmadan) ve sonuçlar sayfasında sol tarafta bir açılır pencere var.

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.