Co zrobić z porzuconymi problemami w GitHub?

Jeśli ktoś otworzy problem w GitHub, ale więcej informacji w celu odtworzenia błędu zostanie zapytany i nigdy nie podany, jaka jest normalna procedura? Przykład .

Tutaj autor stwierdza, że ​​„nawigacja się psuje”. Chociaż uważam, że jest to naprawione, chciałbym od autora wiadomości, aby upewnić się, że mówimy o tym samym. Ale czasami reporter problemu po prostu znika. Czy ustalanie daty wygaśnięcia porzuconych problemów jest dobrą / powszechną praktyką ?

Coś takiego jak te warunki:

• Pojawia się pytanie, aby móc go debugować.
• Minęło ponad 2-6 miesięcy od ostatniego pytania / komentarza od zespołu programistów.
• Błąd nie może zostać odtworzony w momencie jego zamknięcia (z jakiegokolwiek powodu, być może nigdy nie będzie można go odtworzyć).
• Ostrzeżenie jest wydawane 2 tygodnie przed jego zamknięciem.

Co zwykle robią projekty? Nie mogłem nic znaleźć w Google. Jak mam to udokumentować? Czy wystarczy prosta notatka w pliku README.md z wyszczególnieniem powyższych punktów oraz komentarz w numerze wyjaśniający, dlaczego jest zamknięty?

Uwaga: różni się od tego pytania, ponieważ błąd może być nadal istotny (lub nie), jednak brakuje informacji.

Jest to dylemat: nie można zamknąć problemu jako „naprawionego”, ponieważ tak naprawdę nie wiesz, czy został on naprawiony, a przynajmniej jeśli jakiś problem został naprawiony, tak naprawdę nie wiesz, czy to był problem zgłaszającego mówił o. Z drugiej strony nie chcesz pozostawiać problemu, który mógł zostać rozwiązany jako otwarty, szczególnie jeśli nigdy nie będziesz w stanie go zamknąć, ponieważ nigdy nie otrzymasz potwierdzenia.

Więc należy go zamknąć, ale prawdopodobnie nie jako „stałe”. Możesz wymyślić niestandardowy powód „może zostać naprawiony” lub „niepotwierdzony”, jeśli chcesz być pozytywny lub „reportervanished”, jeśli nie. Możesz też po prostu powiedzieć „nie można odtworzyć” i poczekać, aż wyskoczy ten sam błąd dla bardziej responsywnego reportera.

Nie powinieneś jednak wydawać zasobów na błąd, w przypadku którego nigdy nie dowiesz się, czy został on naprawiony, czy nie.

Odpowiedzi na twoje główne pytanie zostały już udzielone, ale zapytałeś także o dokumentację procesu, który również wymaga odpowiedzi.

Rozwiązaniem, które widziałem w wielu projektach, nie jest umieszczenie go w README.md projektu, ale w specjalnym wkładzie README - plik README dla autorów. Ten plik opisuje wszystko, co chcesz, aby ludzie, którzy wnoszą swój projekt, wiedzieli - czy to o kodzie (konwencje nazewnictwa, organizacja modułów itp.), Czy o procesie (jak pisać commity, jak obsługiwać bilety itp.). Ten plik może być innym .MDplikiem w projekcie lub umieszczony w zupełnie innym repozytorium (dzięki czemu można go udostępniać wszystkim projektom). Tylko nie zapomnij link do niego z głównego README.md!

Oddzielenie tych informacji od głównego README polega na tym, że zwykle tylko niewielka część użytkownika projektu ma do nich bezpośredni udział. Większość użytkowników nie musi się nudzić tymi informacjami - muszą tylko wiedzieć, co robi Twój projekt i jak z niego korzystać, i to powinien zawierać główny plik README. W przypadku twojego projektu sekcja poświęcona wkładowi jest bardzo mała, więc nie obciąża głównego pliku README - ale jeśli udokumentujesz wszystkie przepływy pracy, które chcesz wnieść do współtwórców, nie będzie już tak ładnie ...

Pamiętaj, że każdy użytkownik może otworzyć błąd, więc jeśli masz specjalne wymagania dotyczące otwierania błędów, powinieneś umieścić je w głównym pliku README (choć staraj się go nie zmieniać - w przeciwieństwie do autorów kodu, zgłaszający błędy prawdopodobnie będą mniej skłonni do dokładania wszelkich starań) studiować i przestrzegać swoich zasad). Jednak osoba, która faktycznie naprawia błąd i zamyka bilet (czy to ty, czy jeden z współautorów, których potwierdziłeś) jest bezpośrednim współtwórcą i można oczekiwać, że przeczyta wkład README - więc proces zamykania biletów, gdy reporter to zrobi nie odpowiadać należy tam opisać.

Czytam to jako pytanie o praktyki związane z obsługą niezweryfikowanego błędu (za pomocą narzędzia do śledzenia problemów github) niż cokolwiek innego.

Dla mnie jest to dość prosta odpowiedź w oparciu o inne narzędzia do śledzenia problemów, z których korzystałem. Github nie zmusza nikogo do korzystania z żadnego przepływu pracy, co czyni go bardzo elastycznym ... i raczej bezużytecznym w domyślnej konfiguracji.

Patrząc na domyślny przepływ pracy Bugzilli, otrzymujemy:

Wskażę tam bardzo ważną rzecz - rozwiązuje się ją jako naprawioną, zanim zostanie zamknięta po weryfikacji . Podstawowy przepływ pracy w Github pokazuje tylko stany czerwony (otwarty) i zielony (zamknięty).

Dlatego jednym z podejść jest użycie etykiet w Github ( etykiety aplikacji ), aby spróbować wyświetlić dodatkowe informacje. Możesz utworzyć parę etykiet „niezweryfikowanych” i „zweryfikowanych”, które zostaną zastosowane po zamknięciu problemu. Pamiętaj, że jest to tylko jedno podejście - jeśli szukasz, możesz znaleźć dziesiątki różnych podejść do korzystania z etykiet. Tutaj pytanie Jak zarządzać problemami z github (priorytet itp.)? rozwiązuje to.

Naprawiłeś to, z punktu widzenia dewelopera jest to zrobione. Zamknij problem na Github. Zastosuj do niego etykietę „niezweryfikowany”. Gdy ktoś zaznajomiony z błędem w poprzedniej wersji powie „tak, to naprawiło”, możesz zmienić etykietę na „zweryfikowana”. Jeśli powiedzą, że tak się nie stało, to otwórz je ponownie.

Zauważ też, że istnieją inne rozstrzygnięte stany oprócz „naprawionych”. Istnieje „wontfix” (poprawki jest coś, czego po prostu nie da się zrobić przy obecnej strukturze) i „worksforme” (błędu nie można odtworzyć) i „nieprawidłowy” (zgłaszasz błąd dotyczący systemu operacyjnego, a nie rodzaj aplikacji).

Przyjąłbym jeden z dwóch poglądów, w zależności od tego, jak byłem pewien, że mówię o tym samym, co oryginalny reporter:

1) Ponieważ reporter nie jest już dostępny, należy uznać, że dany błąd oznacza wszystko, co naprawiłeś. Jeśli to pomoże, dołącz przypadki testowe, aby wyjaśnić znalezione błędy. Opisz szczegółowo w zgłoszeniu błędu, co naprawiłeś, i zostaw notatkę w stylu: „Wierzę, że to właśnie oznacza„ przerwa w nawigacji ”, otwórz ponownie lub podnieś nowy błąd, jeśli nie to miałeś na myśli”. Oznacz błąd jako naprawiony.

2) Ponieważ reporter nie jest już dostępny, należy uznać, że błąd nie może być (znany) jako powielany, ponieważ tylko słowo reportera dla niego potwierdzi, że zgłosił to samo. Podnieś nowy błąd, aby opisać naprawioną przez Ciebie rzecz, aby wspomnieć o tym, że zaobserwowano go w warunkach opisanych przez nieobecnego reportera, zwróć uwagę na oba, że mogą to być duplikaty, zaznacz nowy naprawiony błąd i oznacz ten jeden jako nieprawidłowy lub nie można odtworzyć z napisem: „Nie mogę zrozumieć, co masz na myśli przez„ łamanie nawigacji ”, ale rozwiązałem problem, który znalazłem. Otwórz ponownie lub podnieś nowy błąd, jeśli nawigacja nadal się psuje, opisując w więcej szczegółów, co pójdzie nie tak ".

Jeśli chodzi o ramy czasowe, myślę, że powinno to zależeć od projektu. Jeśli reagujesz bardzo szybko i radzisz sobie z tym błędem w ciągu kilku dni od jego zgłoszenia, ludzie powinni zrozumieć, że nie będziesz czekał tygodni na odpowiedź przed rozwiązaniem problemu. Z drugiej strony, jeśli był na twoim błocie od miesięcy, może siedzieć otwarty przez kolejny miesiąc lub dwa, nie powodując żadnych problemów.

Z tego powodu nie sądzę, aby istniał jeden konkretny termin, który stanowi „dobrą praktykę”, lub że musisz opublikować swoją politykę i trzymać się jej. Z pewnością nie chciałbyś odnotować, że nie można się skontaktować z reporterem, dopóki nie podejmiesz wysiłku, aby się z nim skontaktować. Ale nie widzę też sensu, aby wiele ostrzeżeń odliczało się do ostatecznego terminu: albo ponownie zobaczą błąd i chcą coś powiedzieć, albo nie chcą.