Jeśli chcesz przyczynić się do rozwoju WMIAdventure, prosimy wybrać istniejące issue gotowe do implementacji. Możesz stworzyć również nowe issue na którym będziemy wspólne dyskutować nad daną zmianą. Wspólnie stwierdzimy, czy proponowany feature wpisuje się w wizję WMI Adventure.
Proszę również przeczytać kodeks postępowania znajdujący się w pliku CODE_OF_CONDUCT.
Issue są bardzo wartościowe dla naszego projektu. Na ich podstawie sporządzamy zadania do naszego backlog'a. Prosimy o tworzenie nowych issue jeśli:
- Masz jakiekolwiek pytanie związane z projektem.
- Zauważyłeś coś w produkcie, co warto poprawić.
- Chcesz przedyskutować potencjalną modyfikacje, którą zamierzasz wprowadzić.
Proszę tworzyć nowe issue zgodnie z przeznaczonymi do nich schematami.
Serdecznie dziękujemy za każde stworzone issue.
Pull requesty to genialna metoda do wprowadzania własnych zmian dla repozytorium. Będziemy akceptować pull requesty spełniające następujące wymagania:
- Zmiany lub nowe funkcjonalności zawarte w p.r. (pull request) będą zgodne z wizją projektu oraz wymaganiami projektowymi napisanych przez twórców lub w dalszej perspektywie zmodyfikowanych przez społeczność WMIAdventure.
- Kod wchodzący w skład p.r. będzie wystarczająco dobrej jakości, aby otrzymać zatwierdzenie od jednego z twórców lub późniejszych kontrybutorów z odpowiednimi uprawnieniami.
- Kod p.r. dotyczący warstwy frontend w katalogu frontend/ będzie sformatowany za pomocą formatera eslint.
- Kod p.r. warstwy backend w katalogu backend/ będzie sformatowany za pomocą formatera PEP.
- Nowy p.r. będzie pomyślnie przechodzić przez testy automatyczne.
- Funkcjonalny zakres p.r. zostanie odpowiednio przetestowany przez jednego z twórców lub późniejszych kontrybutorów z odpowiednimi uprawnieniami.
Proszę w treści każdego commit'u załączać numer/numery issue do którego dany commit się odnosi za pomocą "#(numer issue)".
Na przykład git commit -m "#812 Setup django-ratelimit".
Dzięki temu podczas code review łatwiej nam ustalić jaki problem rozwiązuje dany commit.
Tytuł p. r. powinien wyraźnie opisywać wprowadzoną funkcjonalność.
W opisie należy zapisać jakie issue rozwiązujemy naszym p. r. za pomocą closes #(numer issue).
- Analiza kodu (code review).
- Testowanie wprowadzonych zmian.
- Utworzenie komentarza w przypadku niejasności (opcja comment w p. r.).
- Zarządzanie zmian w przypadku błędów lub możliwości ulepszenia kodu (opcja request changes w p. r.).
- Akceptacja zmian, gdy wszystko jest zrobione prawidłowo (opcja approve podczas code review w p. r.).
- Zmergowanie zmian na główną gałąź main.
- Po zmergowaniu modyfikację zostaną automatycznie opublikowane na środowisku testowym.
- Środowisko produkcyjne (wmi-adventure.pl) zostanie zaaktualizowane o nowe zmiany przy najbliższym release.