Change Details

### Tytuł rewizji Jaki jest tytuł rewizji? Tytuł powinien być zwięzły, ale zawierać kluczowe informacje, w kolejności: 1. co się zmieniło w projekcie, 2. jakiego projektu dotyczy dana rewizja. Kolejność jest istotna, ponieważ tytuł rewizji staje się tytułem commita w repozytorium. Jeżeli najpierw w tytule commita byłaby nazwa projektu, to lista commitów wyglądałaby mało użytecznie: ``` * sealpage - lorem ipsum * sealpage - set dolomet * sealpage - foo bar ``` Lepiej jest: ``` * Lorem ipsum w sealpage * Set dolomet w sealpage * Foo bar w sealpage ``` Informacja `w sealpage` jest nadmiarowa w tytułach commitów, ale jest przydatna w tytułach rewizji, ponieważ łatwiej wtedy na liście rewizji określić, która rewizja dotyczy którego projektu gdy jest ich bardzo dużo, co zdarza się nierzadko. Dlatego informacja o nazwie projektu nie musi znaleźć się w tytule commita przy lądowaniu rewizji - można ją ręcznie usunąć przed lądowaniem. Tytuły rewizji mogą być pisane albo po polsku, albo po angielsku - zależnie od tego, jaki język jest używany do pisania tytułów commitów w danym repozytorium. Jeżeli w repozytorium powiązanym z rewizją nie widać ustalonego języka tytułów diffów, to trzeba to zgłosić na forum, ustalić jedną opcję i umieścić informację o wybranej opcji w README.md danego repozytorium. Należy także sprawdzić, czy tytuł rewizji nie zawiera błędów ortograficznych lub literówek. Przykłady dobrych tytułów rewizji: * "Komponent członków zespołu na stronie sealcode" * "Galeria zdjęć w sealpage" Przykłady złych tytułów rewizji: * "Sealpage - galeria zdjęć" (zła kolejność informacji) * "checkpoint" * "Kopmoment członków zespołu na stronie sealcode" (literówka) ### Podpięte taski Sprawdź, czy rewizja ma podpięte taski. Każda rewizja powinna mieć podpięty co najmniej jeden task. Sprawdź, czy podpięty task jest zgodny z tytułem i treścią rewizji. Task możesz podpiąć do rewizji dając w jego Description coś takiego: ``` Ref T123 ``` lub po utworzeniu rewizji możesz dodać taski wyklikując to z poziomu Sealhuba ### Description Jeżeli rewizja implementuje jakiś graficzny komponent, to w Description powinien znaleźć się screenshot z rezultatem. Dzięki temu recenzentom łatwiej jest załapać kontekst przy przeglądaniu wielu diffów w jednej serii. ### Test Plan Tutaj powinny się znaleźć instrukcje dla osoby testującej poprawność działania napisanego w danej rewizji kodu. Warto się tutaj rozpisać i zawrzeć w szczególności takie informacje, jak: * komendy, które należy odpalić w terminalu, * podstrona, na którą należy wejść, * co należy kliknąć, * co powinno się stać/pokazać, jaki jest oczekiwany rezultat, * jakie dane wpisać, itp.

### Tytuł rewizji Jaki jest tytuł rewizji? Tytuł powinien być zwięzły, ale zawierać kluczowe informacje, w kolejności: 1. co się zmieniło w projekcie, 2. jakiego projektu dotyczy dana rewizja. Kolejność jest istotna, ponieważ tytuł rewizji staje się tytułem commita w repozytorium. Jeżeli najpierw w tytule commita byłaby nazwa projektu, to lista commitów wyglądałaby mało użytecznie: ``` * nazwa-projektu - lorem ipsum * nazwa-projektu - set dolomet * nazwa-projektu - foo bar ``` Lepiej jest: ``` * Lorem ipsum w nazwa-projektu * Set dolomet w nazwa-projektu * Foo bar w nazwa-projektu ``` Informacja `w nazwa-projektu` jest nadmiarowa w tytułach commitów, ale jest przydatna w tytułach rewizji, ponieważ łatwiej wtedy na liście rewizji określić, która rewizja dotyczy którego projektu gdy jest ich bardzo dużo, co zdarza się nierzadko. Dlatego informacja o nazwie projektu nie musi znaleźć się w tytule commita przy lądowaniu rewizji - można ją ręcznie usunąć przed lądowaniem. Tytuły rewizji mogą być pisane albo po polsku, albo po angielsku - zależnie od tego, jaki język jest używany do pisania tytułów commitów w danym repozytorium. Jeżeli w repozytorium powiązanym z rewizją nie widać ustalonego języka tytułów diffów, to trzeba to zgłosić na forum, ustalić jedną opcję i umieścić informację o wybranej opcji w README.md danego repozytorium. Należy także sprawdzić, czy tytuł rewizji nie zawiera błędów ortograficznych lub literówek. Przykłady dobrych tytułów rewizji: * "Komponent członków zespołu na stronie sealcode" * "Galeria zdjęć w nazwa-projektu" Przykłady złych tytułów rewizji: * "Nazwa-Projektu - galeria zdjęć" (zła kolejność informacji) * "checkpoint" * "Kopmoment członków zespołu na stronie sealcode" (literówka) ### Podpięte taski Sprawdź, czy rewizja ma podpięte taski. Każda rewizja powinna mieć podpięty co najmniej jeden task. Sprawdź, czy podpięty task jest zgodny z tytułem i treścią rewizji. Task możesz podpiąć do rewizji dając w jego Description coś takiego: ``` Ref T123 ``` lub po utworzeniu rewizji możesz dodać taski wyklikując to z poziomu Sealhuba ### Description Jeżeli rewizja implementuje jakiś graficzny komponent, to w Description powinien znaleźć się screenshot z rezultatem. Dzięki temu recenzentom łatwiej jest załapać kontekst przy przeglądaniu wielu diffów w jednej serii. ### Test Plan Tutaj powinny się znaleźć instrukcje dla osoby testującej poprawność działania napisanego w danej rewizji kodu. Warto się tutaj rozpisać i zawrzeć w szczególności takie informacje, jak: * komendy, które należy odpalić w terminalu, * podstrona, na którą należy wejść, * co należy kliknąć, * co powinno się stać/pokazać, jaki jest oczekiwany rezultat, * jakie dane wpisać, itp.

### Tytuł rewizji Jaki jest tytuł rewizji? Tytuł powinien być zwięzły, ale zawierać kluczowe informacje, w kolejności: 1. co się zmieniło w projekcie, 2. jakiego projektu dotyczy dana rewizja. Kolejność jest istotna, ponieważ tytuł rewizji staje się tytułem commita w repozytorium. Jeżeli najpierw w tytule commita byłaby nazwa projektu, to lista commitów wyglądałaby mało użytecznie: ``` * sealpage* nazwa-projektu - lorem ipsum * sealpage* nazwa-projektu - set dolomet * sealpage* nazwa-projektu - foo bar ``` Lepiej jest: ``` * Lorem ipsum w sealpagenazwa-projektu * Set dolomet w sealpagenazwa-projektu * Foo bar w sealpagenazwa-projektu ``` Informacja `w sealpage`nazwa-projektu` jest nadmiarowa w tytułach commitów, ale jest przydatna w tytułach rewizji, ponieważ łatwiej wtedy na liście rewizji określić, która rewizja dotyczy którego projektu gdy jest ich bardzo dużo, co zdarza się nierzadko. Dlatego informacja o nazwie projektu nie musi znaleźć się w tytule commita przy lądowaniu rewizji - można ją ręcznie usunąć przed lądowaniem. Tytuły rewizji mogą być pisane albo po polsku, albo po angielsku - zależnie od tego, jaki język jest używany do pisania tytułów commitów w danym repozytorium. Jeżeli w repozytorium powiązanym z rewizją nie widać ustalonego języka tytułów diffów, to trzeba to zgłosić na forum, ustalić jedną opcję i umieścić informację o wybranej opcji w README.md danego repozytorium. Należy także sprawdzić, czy tytuł rewizji nie zawiera błędów ortograficznych lub literówek. Przykłady dobrych tytułów rewizji: * "Komponent członków zespołu na stronie sealcode" * "Galeria zdjęć w sealpage"nazwa-projektu" Przykłady złych tytułów rewizji: * "Sealpage* "Nazwa-Projektu - galeria zdjęć" (zła kolejność informacji) * "checkpoint" * "Kopmoment członków zespołu na stronie sealcode" (literówka) ### Podpięte taski Sprawdź, czy rewizja ma podpięte taski. Każda rewizja powinna mieć podpięty co najmniej jeden task. Sprawdź, czy podpięty task jest zgodny z tytułem i treścią rewizji. Task możesz podpiąć do rewizji dając w jego Description coś takiego: ``` Ref T123 ``` lub po utworzeniu rewizji możesz dodać taski wyklikując to z poziomu Sealhuba ### Description Jeżeli rewizja implementuje jakiś graficzny komponent, to w Description powinien znaleźć się screenshot z rezultatem. Dzięki temu recenzentom łatwiej jest załapać kontekst przy przeglądaniu wielu diffów w jednej serii. ### Test Plan Tutaj powinny się znaleźć instrukcje dla osoby testującej poprawność działania napisanego w danej rewizji kodu. Warto się tutaj rozpisać i zawrzeć w szczególności takie informacje, jak: * komendy, które należy odpalić w terminalu, * podstrona, na którą należy wejść, * co należy kliknąć, * co powinno się stać/pokazać, jaki jest oczekiwany rezultat, * jakie dane wpisać, itp.