Jak pracujemy nad taskiem w trybie review.

Faza 1. - Tworzenie zmian (autor)

1. Zidentyfikuj taska, nad którym pracujesz - przykładowo, T123
2. Zcheckoutuj się na brancha roboczego w danym repozytorium (w tym przykładzie - alpha)
   
   git checkout alpha

3. Spulluj zmiany z repozytorium:
   
   git pull

4. Stwórz nowego brancha, o nazwie opisującej taska, nad którym pracujesz. Nazwa brancha nie będzie częścią Review, jest tylko dla Ciebie.
   
   git checkout -b t123-nowy-layout

5. Zacznij pracę nad zmianami w plikach projektu. Jeżeli chcesz, możesz robić dowolną ilość commitów. Miej na uwadze, że wszystkie commity zostaną zesquashowane w jeden duży pod koniec procesu.
   
   git commit -a -m "checkpoint"

6. Gdy prace nad Review są skończone, użyj Arcanista aby utworzyć nowego Diffa:
   
   arc diff origin/alpha
   
   (alpha to nazwa roboczego brancha w danym repozytorium)

7. Uzupełnij dane, o które spyta Cię Arcanist. Pamiętaj, aby w opisie umieścić referencje do wszystkich tasków, których tyczy się dany Review (może być więcej niż jeden)
   
   Ref T123 T125
   
   W polu "Test plan" opisz, jak należy funkcjonalnie przetestować poprawność wykonania zadania (co kliknąć, jaki url odwiedzić, itp). Jeżeli zmiany wymagają np. przeinstalowania node_modules lub innych kroków przed odpalaniem projektu, informację o tym zawrzyj również w tym polu.

8. Po potwierdzeniu Arcanist wyśle Diffa na Sealhuba i wyświetli link do niego w terminalu.

Faza 2. - Review (recenzent)

1. Odwiedź stronę Diffa, np: D100
2. Zapoznaj się z treścią tasków, do których jest przypięty dany Review - jeżeli nie ma żadnych tasków, skonsultuj się z autorem Diffa i poproś o zaktualizowanie danych
3. Zapoznaj się z Test Planem i wykonaj go. Aby uruchomić kod na swojej lokalnej maszynie, zcheckoutuj się u siebie na brancha roboczego i wykonaj:
   
   arc patch D100
   
   Zostanie utworzony nowy, lokalny, tymczasowy branch, zawierający zmiany opisane w danym Diffie. Aby powrócić do stanu przed patch, po prostu zcheckoutuj się na innego brancha.

4. Przeczytaj uważnie kod Diffa - czy jest czytelny? Czy można go jakoś poprawić? Czy spełnia standardy kodu?
5. Wszelkie uwagi umieść w komentarzach (ogólnych lub dotyczących konkretnych linijek). Komentarze możesz oznaczyć hasłami:
   • "(must)" - komentarz krytyczny, zaadresowanie go jest kluczowe do poprawności wykonania taska
   • "(should)" - komentarz niekrytyczny, ale nie można zamknąć Diffa bez konsensusu co do sprawy w nim zawartej
   • "(could)" - komentarz niekrytyczny, opcjonalny. Drobne sugestie, które nie blokują akceptacji diffa.
6. Jeżeli Diff jest gotowy do zaakceptowania (rozwiązane zostały już komentarze "must" i "should"), zaznacz Diffa jako "Accepted". (następuje przejście do Fazy 4. - Lądowanie). W przeciwnym wypadku oznacz go jako "Request Changes" (następuje Faza 3. - Poprawki).

Faza 3. - Poprawki (autor)

Jeżeli Twój branch zostanie oznaczony jako "Changes Requested" (co jest jak najbardziej OK), czas wprowadzić zmiany i ustosunkować się do umieszczonych w Diffie komentarzy.

1. Faza 4. - Lądowanie