Jak zarządzać problemami z github (priorytet itp.)? [Zamknięte]

Jestem nowym użytkownikiem github i szukam porady na temat zarządzania problemami. Jestem przyzwyczajony do posiadania priorytetów i innych opcji zamawiania, ale widzę, że żadne nie istnieje.

Jak inni zarządzają problemami podczas cyklu życia błędu / funkcji?

Z góry dziękuję.

Można zdefiniować różne grupy etykiet takich rodzajów emisji , priorytetów emisji , emisji statusów , znaczniki wersji , a może i więcej. Aby móc natychmiast zobaczyć, do której grupy należy etykieta, możesz użyć konwencji nazewnictwa, takiej jak <label-group>:<label-name>.

Korzystanie z takiej konwencji nazewnictwa powinno znacznie ułatwić zarządzanie problemami z Github i pomóc innym „zrozumieć” problemy znacznie szybciej. Pamiętaj, że możesz także przypisywać kolory do etykiet, które mogą jeszcze bardziej zwiększyć czytelność (użyłbym określonego koloru dla każdej grupy etykiet). Ponieważ jednak nadal musisz ręcznie przypisywać / cofać te etykiety do / z problemów, ogólna lista grup / etykiet może być mała.

Zgodnie z sugerowanym powyżej schematem możesz zdefiniować grupy i odpowiadające im etykiety w następujący sposób.

grupa „typ emisji”

• typ: błąd
• typ: funkcja
• typ: pomysł
• typ: niepoprawny
• typ: wsparcie
• typ: zadanie

grupa „priorytet wydania”

• prio: niski
• prio: normalny
• prio: wysoki

grupa „status wydania”

(Te etykiety opisują stan problemu w zdefiniowanym przepływie pracy).

• Status: potwierdzony
• status: odroczony
• status: zatwierdzony przez poprawkę
• status: w trakcie
• status: niekompletny
• status: odrzucony
• status: rozwiązany

grupa „informacji o problemie”

• informacje: potrzebne informacje zwrotne
• info: potrzebna pomoc
• informacje: postęp-25
• info: progress-50
• info: progress-75

grupa „tag wersji”

• wersja: 1.x
• wersja: 1.1

Narzędzie do śledzenia problemów GitHub jest dość elastyczne. Rzeczywiście nie ma priorytetu ani porządku. Obejmuje on trzy główne filary: zadania , etykiety i kamienie milowe .

• Możesz „tagować” problemy z tworzonymi przez siebie etykietami (w podobny sposób jak etykiety Gmaila). Na przykład: „błąd”, „żądanie funkcji”, „todo”, „pytanie”, ... Jeden problem można oznaczyć różnymi etykietami.

• Możesz „spakować” kilka kwestii w kamień milowy . Kamień milowy składa się z tytułu (na przykład numeru wersji) i opcjonalnej daty dostawy.

• Każde wydanie może być przypisane do współpracownika (współtwórcy lub członka organizacji) repozytorium. Możesz nawet wezwać współpracownika w komentarzu, używając @znaku logowania GitHub.

Ostatecznie, dzięki paskowi bocznemu, możesz „przefiltrować” listę problemów, aby pomóc Ci nią zarządzać.

Pełny post na blogu „Issues 2.0” na ten temat daje bardziej szczegółowy widok funkcji.

Używam huboard.com do reprezentowania problemów z github na tablicy Kanban, a następnie sortuję je, przeciągając i upuszczając wewnątrz huboard. Działa całkiem dobrze, jeśli interesuje Cię tylko wizualizacja priorytetu i wiedza, co dalej.

W rzeczywistości zapisuje priorytet w samym numerze, jako komentarz HTML:

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

Przykład wykorzystania etykiet na githubie do zarządzania naszymi projektami

Etykiety kategorii (można również użyć wszystkich znaków do wizualnego rozdzielenia)

• Zadanie
• Pluskwa
• Funkcja
• Dyskusja

Etykieta priorytetowa

• PILNE

Uważamy, że wszystko ma normalny priorytet i tak naprawdę nie widzimy potrzeby „niskiego”. Tak więc pozostawia tylko jedną etykietę do oznaczania rzeczy, które wymagają natychmiastowej uwagi.

Etykiety stanu

• sprawdzone (cesjonariusz ją przeczytał)
• w kolejce (cesjonariusz wkrótce będzie nad tym pracował)
• praca w toku (cesjonariusz pracuje nad tym teraz)
• niepoprawny (jeśli błąd nie jest powtarzalny)
• potrzebujesz informacji zwrotnej (sygnał nietoperza, aby zachęcić ludzi do czytania, komentowania lub udzielania pomocy)

Całą dokumentację przechowujemy na wiki, która zawiera instrukcje, architekturę, infrastrukturę, studia przypadków, planowanie i wymagania.

Żądania ściągania służą do recenzji kodu i dyskusji na temat funkcji, jeśli jest on częścią oddziału

Dzięki kreatywnemu wykorzystaniu filtrowania możemy znaleźć pracę, którą musimy wykonać na dany dzień. „Zadanie + PILNE” lub „Błąd + PILNE” zawsze sprawdzają problemy oznaczone jako „potrzebują opinii” i zostawiają komentarz, nawet jeśli nie masz nic do dodania. Oczywiście działa to z naszym pięcioosobowym zespołem, ale prawdopodobnie niewiele więcej.

W kwestiach GH wybieram dwa rodzaje etykiet - pierwszy dotyczy rodzaju problemu, a drugi dotyczy priorytetu:

• pluskwa
• funkcja - (nowe rzeczy)
• ulepszenie - (ulepszanie istniejących rzeczy)
• pytanie / dyskusja - (omawianie rzeczy)

Pytanie / dyskusja mogą nie być konieczne, jeśli dobrze korzystasz z Wiki. Ale podoba mi się to, ponieważ pozwala mi skierować pytanie lub pomysł do konkretnej osoby.

Istnieją trzy naprawdę proste etykiety priorytetowe:

• teraz
• wkrótce
• później

Łatwe, prawda?

Oprócz sugerowanych powyżej rozwiązań w zakresie tagowania, mamy blockingi blockedjako etykiety.

Problem musi być najpierw przypisany do właściwej osoby, ale jeśli ta osoba nie jest w stanie pracować nad problemem, dopóki inne problemy nie zostaną zakończone, problem jest oznaczony jako blocked. A drugi problem jest przywoływany za pomocą znacznika skrótu.

Podobnie, jeśli zadanie blokuje komuś pracę nad czymś, powinno być oznaczone jako blockingodniesienie do innego problemu.

Odkrywanie, jak wyświetlić listę przedmiotów przypisanych do konkretnej osoby, było trochę trudne.

Rozwiązaniem jest kliknięcie ikony „wyszukiwania” (bez wpisanych kryteriów wyszukiwania), a na stronie wyników po lewej stronie znajduje się menu rozwijane.