Przeglądanie wniosków o wprowadzenie zmian¶
Zawsze cieszymy się z recenzji autorów, niezależnie od ich poziomu doświadczenia.
Dlaczego warto recenzować artykuły?¶
Każdy przesłany wkład musi zostać sprawdzony, niezależnie od tego, czy został przesłany przez członka głównego zespołu, czy przez osobę, która po raz pierwszy wnosi swój wkład. Każdy może coś przeoczyć. Proces sprawdzania ma na celu zapewnienie dodatkowego zabezpieczenia.
Celem procesu weryfikacji jest zapewnienie, że cała zawartość, w tym kod i dokumentacja, jest jak najbardziej wolna od błędów i łatwa w utrzymaniu. Wszelkie działania, które mogą przyczynić się do osiągnięcia tego celu, są mile widziane. Mogą one obejmować zarówno proste czynności, takie jak poprawianie literówek, jak i wyszukiwanie nie wykrytych przypadków skrajnych w użyciu API. Można również wskazać sposoby na ulepszenie procedur testowych lub zaproponować rozwiązania dotyczące struktury ogólnej architektury zmian, tak aby były one łatwiejsze w utrzymaniu lub rozbudowie.
Czy mogę wystawić opinię?¶
Tak! Możesz wystawić recenzję każdego otwartego pull requestu, który widzisz na BeeWare.
Jako osoba, która po raz pierwszy wnosi swój wkład, możesz swobodnie przeglądać wszystkie zgłoszenia pull request, nawet jeśli zostały one przesłane przez członka głównego zespołu. Jeśli jesteś nowicjuszem, możesz nie rozumieć niektórych szerszych kontekstów projektu, ale staramy się, aby kod źródłowy był przystępny niezależnie od poziomu doświadczenia. Jeśli coś w kodzie nie ma sensu, może to oznaczać, że potrzebna jest dodatkowa dokumentacja (w kodzie lub jako samodzielna dokumentacja projektowa).
Przeglądanie wniosków o wprowadzenie zmian¶
Przeglądanie wniosków o wprowadzenie zmian
Zapraszamy wszystkich do przeglądania wszelkich wkładów w projekt BeeWare. Przed rozpoczęciem należy jednak wziąć pod uwagę kilka ważnych kwestii.
ZASTANÓW SIĘ, zanim wystawisz opinię¶
Przed przystąpieniem do recenzji ZASTANÓW SIĘ. Jako recenzenci powinniśmy rozważyć, czy odpowiedź, którą zamierzamy wysłać, jest:
- To prawda. Zawsze staraj się dostarczać trafne sugestie i informacje.
- Pomocne. Udzielamy wskazówek dotyczących poprawy zgłoszenia; wskazówki te powinny jasno określać źródło problemu lub nieuwzględniony przypadek użycia, a w idealnym przypadku wskazywać sposób rozwiązania lub zaspokojenia danej kwestii.
- Inspirujące. To od nas zależy, czy zainspirujemy autora do wprowadzenia zmian, o które prosiliśmy.
- Konieczne. Oczekuje się, że autor przeczyta wszystko, co publikujemy; musimy szanować jego czas i wysiłek, publikując tylko wtedy, gdy jest to konieczne.
- Życzliwość. Istnieje wiele sposobów przekazania tej samej informacji zwrotnej; musimy zadbać o to, aby nasze słowa były życzliwe, wspierające i konstruktywne.
Całkowicie możliwe jest MYŚLENIE, a jednocześnie zapewnienie skutecznej recenzji. Omówione powyżej koncepcje nie wykluczają wskazywania wszelkich problemów, które znajdziesz w PR. Współtwórcy nie będą mieli możliwości ulepszenia swojego wkładu, jeśli nie będą świadomi obszarów wymagających poprawy. Ważne jest, aby być świadomym jak przedstawiasz tę informację zwrotną. Postaraj się, aby Twoja recenzja była bezosobowa. Zamiast „Popełniłeś błąd”, możesz powiedzieć „Ten kod można poprawić”. Recenzuj kod, a nie autora.
Ważne jest, aby pamiętać o przekazywaniu pozytywnych opinii, oprócz wskazywania obszarów wymagających poprawy. Jeśli na przykład zmiany są szczególnie pomocne, wykonano coś wyjątkowo sprytnego lub zapoznałeś się z API, o którym nie wiedziałeś, poinformuj o tym autora! Nigdy nie lekceważ efektu wskazania komuś, co zrobił dobrze lub poprawnie, w sytuacji, gdy wszystko inne, na co zwróciłeś uwagę, to kwestie wymagające rozwiązania.
Sugestie dotyczące recenzji GitHub¶
Interfejs recenzji GitHub posiada mechanizm sugerowania zmian, w którym można podać dokładną zmianę, którą sugerujesz jako zamiennik istniejącej treści. Należy pamiętać, że dopóki nie zostaną one zaakceptowane i zatwierdzone, sugerowane zmiany nie zostaną poddane kontroli przed zatwierdzeniem i sprawdzeniu poprawności. Dlatego też funkcja ta powinna być używana w przypadku mniejszych zmian, ponieważ im większa jest sugerowana zmiana, tym większe jest prawdopodobieństwo pojawienia się problemów.