Jesteś zainteresowany odwdzięczeniem się odrobinę społeczności? Może znalazłeś błąd w Django, który chciałbyś, by był rozwiązany, lub jest jakaś mała funkcjonalność, którą chciałbyś, by była dodana.
\nPomoc w rozwoju Django jest najlepszym sposobem na rozwiązanie napotkanych przez Ciebie problemów. Na początku może to wydawać się zniechęcające, ale tak naprawdę jest całkiem proste. Przeprowadzimy Cię przez cały proces na przykładzie, abyś mógł się nauczyć tego w praktyce.
\nNa potrzeby tego tutorialu oczekujemy posiadanie co najmniej podstawowego rozumienia, jak działa Django. To znaczy, że czytelnik powinien być już obeznany z istniejącymi tutorialami na temat pisania jego pierwszej aplikacji Django. Dodatkowo, powinien dobrze rozumieć samego Pythona. W przypadku jeśli tak nie jest, Dive Into Python jest fantastyczną (i darmową) książką online dla początkujących programistów Pythona.
\nCi z was, którzy nie są zaznajomieni z systemami kontroli wersji i Trakiem przekonają się, że w tym poradniku i jego odnośnikach znajdą wystarczająco informacji, aby zacząć pracę. Pomimo tego, prawdopodobnie będziecie potrzebować przeczytać nieco więcej o tych różnych narzędziach, jeśli planujecie regularnie współtworzyć Django.
\nCelem tego poradnika w głównej mierze jest wytłumaczenie wszystkiego najdokładniej jak to możliwe, aby mógł być on używany przez szerokie grono odbiorców.
\n\nPrzeprowadzimy cię przez pierwsze tworzenie poprawki do Django. Pod koniec tego tutoriala, powinieneś(nnaś) rozumieć podstawy zarówno narzędzi jak i wykorzystanych procesów. W szczególności poruszymy następujące tematy:
\nInstalacja Gita.
Jak pobrać rozwojową wersję Django.
Uruchamianie zestawu testów Django.
Pisanie testu dla twojej poprawki.
Pisanie kodu dla twojej poprawki.
Testowanie twojej poprawki.
Wysyłanie prośby o pull.
Gdzie szukać więcej informacji.
Kiedy tutorial jest już za tobą, możesz przejrzeć resztę Django’s documentation on contributing. Zawiera ona wiele dobrych informacji i jest lekturą obowiązkową dla każdego, kto chciałby zostać stałym współtwórcą Django. Jeśli masz pytania, tam prawdopodobnie są odpowiedzi.
\n\n\nJako współtwórca możesz pomóc nam utrzymać społeczność Django otwartą i zintegrowaną. Przeczytaj i postępuj zgodnie z naszym Kodeksem Postępowania.
\nDo tego poradnika będziesz potrzebował mieć zainstalowanego Gita, aby pobrać aktualną wersję rozwojową Django i wygenerować pliki poprawek dla zmian, które dokonasz.
\nAby sprawdzić, czy posiadasz zainstalowanego Gita, wpisz git w wiersz poleceń. Jeśli otrzymasz informację, że taka komenda nie została znaleziona, będziesz musiał go pobrać i zainstalować. Zobacz stronę pobierania Gita.
Jeśli nie jesteś zaznajomiony z Gitem, możesz zawsze znaleźć więcej informacji na temat komend (kiedy Git jest zainstalowany) wpisując git help w wiersz poleceń.
Pierwszym krokiem do współtworzenia Django jest uzyskanie kopii kodu źródłowego. Najpierw rozwidlij Django na GitHubie. Następnie użyj polecenia cd w linii poleceń, aby przejść do katalogu, gdzie będziesz chciał trzymać swoją lokalną kopię Django.
Pobierz repozytorium kodu źródłowego Django używając poniższego polecenia:
\n$ git clone git@github.com:YourGitHubName/django.git\nKiedy już masz lokalną kopię Django, możesz go zainstalować tak jak zainstalowałbyś dowolny pakiet za pomocą pip-a. Najwygodniejszy sposób, aby to zrobić jest użyć virtual environment (inaczej virtualenv) które jest funkcjonalnością wbudowaną w Pythona, która pozwala ci trzymać oddzielny katalog zainstalowanych pakietów dla każdego z twoich projektów, aby nie wchodziły ze sobą w konflikt.
Dobrą praktyką jest przechowywanie wszystkich swoich virtualenv w jednym miejscu, na przykład w .virtualenvs/ w Twoim katalogu domowym. Utwórz ten katalog jeśli jeszcze nie istnieje:
$ mkdir ~/.virtualenvs\nNastępnie utwórz nowe środowisko wirtualne uruchamiając:
\n$ python3 -m venv ~/.virtualenvs/djangodev\nŚcieżką jest miejsce gdzie nowe środowisko zostanie zapisane na Twoim komputerze:
\n\n\nOstatnim krokiem w procesie konfigurowania Twojego środowiska wirtualnego jest jego aktywacja:
\n$ source ~/.virtualenvs/djangodev/bin/activate\nJeśli komenda source nie jest dostępna, możesz spróbować zamiast niej użyć kropki:
$ . ~/.virtualenvs/djangodev/bin/activate\nMusisz aktywować swoje środowisko wirtualne zawsze, kiedy otwierasz nowe okno terminala. virtualenvwrapper jest przydatnym narzędziem ułatwiającym ten proces.
\nWszystko, co zainstalujesz poprzez pip od teraz będzie instalowane w Twoim nowym środowisku wirtualnym, odizolowane od innych środowisk i pakietów w systemie. Ponadto nazwa aktualnie aktywowanego środowiska wirtualnego jest wyświetlana w wierszu poleceń, aby ułatwić Ci śledzenie, którego z nich używasz. Śmiało zainstaluj wcześniej sklonowaną kopię Django:
$ pip install -e /path/to/your/local/clone/django/\nZainstalowana wersja Django od teraz wskazuje na Twoją lokalną kopię. Dzięki temu natychmiastowo będziesz widział wszelkie zmiany, których dokonasz co jest bardzo przydatne podczas pisania Twojej pierwszej poprawki.
\nNa potrzeby tutoriala, użyjemy zgłoszenia #24788 jako studium przypadku, więc przewiniemy historię wersji Django w git’cie do momentu zanim dodana została poprawka tego zgłoszenia. To pozwoli nam przejść wszystkie kroki składające się na napisanie tej poprawki od podstaw, włączając uruchomienie pakietu testów Django.
\nZwróć uwagę, że mimo iż będziemy używać starszej wersji trunka Django na potrzeby poniższego tutoriala, powinieneś zawsze używać bieżącej wersji deweloperskiej Django pracując nad poprawką do zgłoszenia!
\n\nWejdź do głównego katalogu Django (to ten, który zawiera django, docs, tests, AUTHORS itd.). Następnie możesz zcheckoutować starszą wersję Django, którą będziemy używać w poniższym tutorialu:
$ git checkout 4ccfc4439a7add24f8db4ef3960d02ef8ae09887\nDając wkład w kod Django, bardzo ważne jest, aby twoje zmiany nie wprowadzały błędów w innych obszarach Django. Jednym ze sposobów, aby sprawdzić, czy Django nadal działa po twoich zmianach jest uruchomienie zestawu testów Django. Jeśli wszystkie testy nadal przechodzą, wtedy masz podstawy, by sądzić, że twoje zmiany nie popsuły kompletnie Django. Jeśli nigdy wcześniej nie uruchamiałeś zestawu testów Django, dobrym pomysłem jest uprzednio uruchomienie ich raz, tylko po to, abyś zaznajomił się, jak powinien wyglądać ich efekt.
\nPrzed uruchomieniem modułu testów zainstaluj jego zależności przed z``cd``owanie do katalogu tests/ Django a następnie uruchomienie:
$ pip install -r requirements/py3.txt\nJeśli napotkasz błąd w trakcie instalacji, może to oznaczać, że w twoim systemie brakuje zależności dla jednego lub więcej pythonowych pakietów. Sprawdź dokumentację pakietów, które zgłaszają błąd lub przeszukaj sieć z komunikatem błędu, który napotkałeś.
\nJesteśmy gotowi do uruchomienia zestawu testów. Jeśli używasz GNU/Linuksa, macOS-a lub innego rodzaju Uniksa, uruchom:
\n$ ./runtests.py\nTeraz usiądź i odpręż się. Cały zestaw testów Django ma ich ponad 9600, więc ich wykonywanie może zająć coś pomiędzy 5 a 15 minutami, w zależności od szybkości twojego komputera.
\nKiedy uruchomisz zestaw testów Django, zobaczysz strumień znaków oznaczających status każdego testu w trakcie uruchomienia. E oznacza, że został zgłoszony błąd podczas testu, F oznacza, że asercje testu nie zostały spełnione. Obie z nich są traktowane jako porażki testów. Jednocześnie x i s oznaczają kolejno spodziewane porażki i ominięte testy. Kropki oznaczają pomyślne przechodzenie testu.
Testy omijane są zazwyczaj z powodu brakujących zewnętrznych bibliotek wymaganaych do uruchomienia testu; zobacz Running all the tests, aby obejrzeć listę zależności i upewnij się, że zainstalowałeś te, które są związane ze zmianami, które wprowadzasz (nie będziemy potrzebować żadnej w tym tutorialu). Niektóre testy są właściwe dla wybranego back-endu bazodanowego i zostaną ominięte, jeśli test nie odbywa się z tym back-endem. Aby uruchomić testy z użyciem innego back-endu, sprawdź Using another settings module.
\nKiedy testy się skończą, powinieneś zobaczyć komunikat informujący, czy zestaw testów udał się czy odniósł porażkę. Nie zrobiłeś żadnych zmian w kodzie Django, więc cały zestaw testów powinien się udać. Jeśli otrzymujesz porażki lub błędy upewnij się, że poprzednie kroki wykonałeś odpowiednio. Zobacz więcej informacji w Running the unit tests. Jeśli używasz Pythona 3.5+, zobaczysz kilka porażek związanych z ostrzeżeniami o dezaktualizacji, które możesz zignorować. Te błędy zostały już poprawione w Django.
\nZwróć uwagę, że najnowsza wersja trunka Django może nie zawsze być stabilna. Kiedy dewelopujesz z użyciem trunka, możesz sprawdzić Django’s continous integration builds, aby zweryfikować czy porażki są specyficzne dla twojej maszyny czy są również obecne w oficjalnych buildach Django. Jeśli klikniesz, aby zobaczyć poszczególny build, możesz zobaczyć „Configuration Matrix”, która pokazuje porażki uzyskane w poszczególnych wersjach Pythona i bazodanowego backendu.
\n\nPrzed wprowadzeniem jakichkolwiek zmian, stwórz nowy branch dla zgłoszenia:
\n$ git checkout -b ticket_24788\nMożesz wybrać dowolną nazwę dla brancha, na przykład „ticket_24788”. Wszystkie zmiany zrobione w tym branchu będą specyficzne dla zgłoszenia i nie wpłyną na główną kopię kodu, którą wcześniej sklonowaliśmy.
\nW większości przypadków, aby poprawka została wcielona do Django, musi zawierać testy. Dla poprawek błędów znaczy to napisanie testu regresyjnego, aby upewnić się, że bug nie zostanie wprowadzony z powrotem w przyszłości. Test regresyjny powinien zostać napisany w taki sposób, aby nie przechodził jeśli bug nadal istnieje i aby przechodził wtedy, kiedy bug zostanie naprawiony. Dla poprawek zawierających nowe funkcjonalności, musisz załączyć testy, które pozwolą się upewnić, że ta nowa funkcja działa poprawnie. One też powinny nie przechodzić kiedy nie ma nowej funkcji i przechodzić wtedy, kiedy zostanie ona zaimplementowana.
\nDobrym sposobem na to jest napisanie twoich testów najpierw, przed jakimikolwiek zmianami w kodzie. Taki styl pracy jest nazywany test-driven development i może być zastosowany zarówno do całych projektów jak i pojedynczych poprawek. Po napisaniu testów możesz je uruchomić, aby upewnić się, że nie przechodzą (bo przecież nie naprawiłeś tego błędu lub nie dodałeś tej funkcjonalności). Jeśli twoje nowe testy przechodzą pomyślnie, musisz poprawić je, aby nie przechodziły. Koniec końców test regresyjny, który przechodzi pomyślnie niezależnie od obecności buga w kodzie, nie pomoże za bardzo w ochronie przed pojawieniem się go w przyszłości.
\nPora na nasz praktyczny przykład.
\nZgłoszenie #24788 jest propozycją dodania małej funkcjonalności: możliwości ustalenia atrybutu prefix na poziomie klasy dla klas From, aby:
[…] forms which ship with apps could effectively namespace themselves such\nthat N overlapping form fields could be POSTed at once and resolved to the\ncorrect form.\nAby rozwiązać zgłoszenie, dodamy atrybut prefix do klasy BaseForm. Podczas tworzenia instancji tej klasy, podanie prefiksu do metody __init__() nadal będzie ustawiać ten prefiks na tworzonej instancji. Lecz nie podanie prefiksu (lub podanie None) spowoduje użycie prefiksu na poziomie klasy. Ale zanim wprowadzimy te zmiany, napiszemy kilka testów, aby zweryfikować, że nasze modyfikacje działają poprawnie i będą działać poprawnie w przyszłości.
Przejdź do folderu Django tests/forms_tests/tests/ i otwórz plik test_forms.py. Dodaj poniższy kod w linii 1674, tuż przed funkcją test_forms_with_null_boolean:
def test_class_prefix(self):\n # Prefix can be also specified at the class level.\n class Person(Form):\n first_name = CharField()\n prefix = 'foo'\n\n p = Person()\n self.assertEqual(p.prefix, 'foo')\n\n p = Person(prefix='bar')\n self.assertEqual(p.prefix, 'bar')\nTen nowy test sprawdza czy ustawienie prefiksu na poziomie klasy działa zgodnie z oczekiwaniami i czy przekazanie parametru prefix podczas tworzenia instancji też nadal działa.
Pamiętaj, że nie wprowadziliśmy jeszcze żadnych zmian do BaseForm, więc nasze testy się powiodą. Uruchommy wszystkie testy w katalogu forms_tests, aby upewnić się, że to rzeczywiście się dzieje. Z linii komend, wejdź cd do katalogu tests/ Django i odpal:
$ ./runtests.py forms_tests\nJeśli testy przebiegły poprawnie, powinieneś zobaczyć jeden błąd związany z metodą testującą, którą dodaliśmy. Jeśli wszystkie testy przeszły bez błędów, upewnij się, że dodałeś nowy test pokazany powyżej do odpowiedniego folderu i klasy.
\nNastępnie będziemy dodawać do Django funkcjonalność opisaną w zgłoszeniu #24788.
\nPrzejdź do folderu django/django/forms i otwórz plik forms.py. Znajdź klasę BaseForm (linia 72.) i dodaj atrybut klasy prefix tuż za atrybutem field_order:
class BaseForm(object):\n # This is the main implementation of all the Form logic. Note that this\n # class is different than Form. See the comments by the Form class for\n # more information. Any improvements to the form API should be made to\n # *this* class, not to the Form class.\n field_order = None\n prefix = None\nGdy już skończysz modyfikować Django, musimy się upewnić, że testy, które napisaliśmy wcześniej przechodzą, aby sprawdzić czy kod, który napisaliśmy powyżej działa poprawnie. Aby uruchomić testy w folderze forms_tests, wejdź cd w katalog tests/ Django i uruchom:
$ ./runtests.py forms_tests\nUps, całe szczęście że napisaliśmy te testy! Powinieneś widzieć dalej jedną porażkę z następującym wyjątkiem:
\nAssertionError: None != 'foo'\nZapomnieliśmy dodać wyrażenie warunkowe w metodzie __init__. Zmień self.prefix = prefix, które jest teraz w linii 87. pliku django/forms/forms.py, dodając wyrażenie warunkowe:
if prefix is not None:\n self.prefix = prefix\nUruchom ponownie testy, wszystko powinno przejść. Jeśli nie przejdzie, upewnij się, że poprawnie zmodyfikowałeś klasę BaseForm jak jest pokazane powyżej i skopiowałeś poprawnie nowy test.
Kiedy zweryfikowałeś, że twoje poprawki i testy działają poprawnie, dobrym pomysłem jest uruchomić cały zestaw testów Django, aby zweryfikować tylko, czy twoja zmiana nie wprowadziła żadnych bugów w innych obszarach Django.
\nAby uruchomić zestaw testów Django w całości, wejdź cd w katalog tests/ Django i uruchom:
$ ./runtests.py\nJeśli nie widzisz żadnych błędów, śmiało możesz iść dalej.
\nTo nowa funkcjonalność, więc powinna zostać udokumentowana. Dodaj następującą sekcję w linii 1068. (na końcu pliku) w pliku django/docs/ref/forms/api.txt:
The prefix can also be specified on the form class::\n\n >>> class PersonForm(forms.Form):\n ... ...\n ... prefix = 'person'\n\n.. versionadded:: 1.9\n\n The ability to specify ``prefix`` on the form class was added.\nJako że ta nowa funkcjonalność będzie w nadchodzącym wydaniu, dodajemy ją też do informacji o wydaniu dla Django 1.9, w linii 164. w sekcji „Forms” w pliku docs/releases/1.9.txt:
* A form prefix can be specified inside a form class, not only when\n instantiating a form. See :ref:`form-prefix` for details.\nPo więcej informacji na temat pisania dokumentacji, wliczając wyjaśnienie o co chodzi w cząstce versionadded, odsyłamy do Writing documentation. Ta strona zawiera również wyjaśnienie jak zbudować lokalnie kopię dokumentacji, aby móc obejrzeć HTML, który zostanie później wygenerowany.
Teraz przejrzyjmy wszystkie zmiany, które wprowadziliśmy przy naszej poprawce. Wyświetl różnice pomiędzy swoją kopią Django (z twoimi zmianami) a wersją, którą pierwotnie zcheckoutowałeś wcześniej w tym tutorialu:
\n$ git diff\nUżyj klawiszy strzałek, aby przesuwać się do góry i w dół.
\ndiff --git a/django/forms/forms.py b/django/forms/forms.py\nindex 509709f..d1370de 100644\n--- a/django/forms/forms.py\n+++ b/django/forms/forms.py\n@@ -75,6 +75,7 @@ class BaseForm(object):\n # information. Any improvements to the form API should be made to *this*\n # class, not to the Form class.\n field_order = None\n+ prefix = None\n\n def __init__(self, data=None, files=None, auto_id='id_%s', prefix=None,\n initial=None, error_class=ErrorList, label_suffix=None,\n@@ -83,7 +84,8 @@ class BaseForm(object):\n self.data = data or {}\n self.files = files or {}\n self.auto_id = auto_id\n- self.prefix = prefix\n+ if prefix is not None:\n+ self.prefix = prefix\n self.initial = initial or {}\n self.error_class = error_class\n # Translators: This is the default suffix added to form field labels\ndiff --git a/docs/ref/forms/api.txt b/docs/ref/forms/api.txt\nindex 3bc39cd..008170d 100644\n--- a/docs/ref/forms/api.txt\n+++ b/docs/ref/forms/api.txt\n@@ -1065,3 +1065,13 @@ You can put several Django forms inside one ``<form>`` tag. To give each\n >>> print(father.as_ul())\n <li><label for="id_father-first_name">First name:</label> <input type="text" name="father-first_name" id="id_father-first_name" /></li>\n <li><label for="id_father-last_name">Last name:</label> <input type="text" name="father-last_name" id="id_father-last_name" /></li>\n+\n+The prefix can also be specified on the form class::\n+\n+ >>> class PersonForm(forms.Form):\n+ ... ...\n+ ... prefix = 'person'\n+\n+.. versionadded:: 1.9\n+\n+ The ability to specify ``prefix`` on the form class was added.\ndiff --git a/docs/releases/1.9.txt b/docs/releases/1.9.txt\nindex 5b58f79..f9bb9de 100644\n--- a/docs/releases/1.9.txt\n+++ b/docs/releases/1.9.txt\n@@ -161,6 +161,9 @@ Forms\n :attr:`~django.forms.Form.field_order` attribute, the ``field_order``\n constructor argument , or the :meth:`~django.forms.Form.order_fields` method.\n\n+* A form prefix can be specified inside a form class, not only when\n+ instantiating a form. See :ref:`form-prefix` for details.\n+\n Generic Views\n ^^^^^^^^^^^^^\n\ndiff --git a/tests/forms_tests/tests/test_forms.py b/tests/forms_tests/tests/test_forms.py\nindex 690f205..e07fae2 100644\n--- a/tests/forms_tests/tests/test_forms.py\n+++ b/tests/forms_tests/tests/test_forms.py\n@@ -1671,6 +1671,18 @@ class FormsTestCase(SimpleTestCase):\n self.assertEqual(p.cleaned_data['last_name'], 'Lennon')\n self.assertEqual(p.cleaned_data['birthday'], datetime.date(1940, 10, 9))\n\n+ def test_class_prefix(self):\n+ # Prefix can be also specified at the class level.\n+ class Person(Form):\n+ first_name = CharField()\n+ prefix = 'foo'\n+\n+ p = Person()\n+ self.assertEqual(p.prefix, 'foo')\n+\n+ p = Person(prefix='bar')\n+ self.assertEqual(p.prefix, 'bar')\n+\n def test_forms_with_null_boolean(self):\n # NullBooleanField is a bit of a special case because its presentation (widget)\n # is different than its data. This is handled transparently, though.\nKiedy skończysz oglądać patch, kliknij przycisk q, aby wyjść i wrócić do linii komend. Jeśli treść patcha wyglądała w porządku, czas na scommitowanie zmian.
Aby scommitować zmiany:
\n$ git commit -a\nPowoduje to otwarcie edytora tekstu do wpisania „commit message”. Zrealizuj zalecenia commit message’y i napisz notatkę w ten sposób:
\nFixed #24788 -- Allowed Forms to specify a prefix at the class level.\nPo skomitowaniu patcha, wyślij go do swojego forka na GitHubie (zamień „ticket_24788” z nazwą swojego brancha, jeśli jest inna):
\n$ git push origin ticket_24788\nMożesz stworzyć pull request odwiedzając stronę Django na GitHubie. Zobaczysz swój branch pod „Your recently pushed branches”. Kliknij „Compare & pull request” obok niego.
\nProsimy nie rób tego z powodu tego tutoriala, ale na następnej stronie, która prezentuje podgląd zmian, kliknąłbyś „Create pull request”.
\nGratulacje, nauczyłeś się tworzyć pull requesty do Django! Szczegóły bardziej zaawansowanych technik, których możesz potrzebować są w Working with Git and GitHub.
\nTeraz możesz dobrze wykorzystać te umiejętności pomagając ulepszać bazowy kod Django.
\nZanim za bardzo wsiąkniesz w pisanie patchy Django, jest trochę więcej informacji o dawaniu wkładu, na które prawdopodobnie powinieneś spojrzeć:
\nPowinieneś się upewnić, że przeczytałeś dokumentację Django na temat tworzenia zgłoszeń i wysyłania patchy. Zawiera ona etykietę Traca, jak przypisywać sobie zgłoszenia, oczekiwany styl kodowania w patchach i wiele innych ważnych szczegółów.
Ci, którzy mają styczność pierwszy raz z wnoszeniem wkładu do kodu, powinni przeczytać też dokumentację Django dla nowych kontrybutorów. Zawiera wiele dobrych rad dla tych, którzy są nowi w pomaganiu w Django.
Dalej, jeśli wciąż jesteś głodny informacji o współtworzeniu, zawsze możesz przejrzeć resztę dokumentacji Django na temat współtorzenia. Zawiera tonę przydatnych informacji i powinna być twoim pierwszym źródłem, odpowiadającym na każde pytanie, które możesz mieć.
Kiedy już przejrzałeś trochę z tych informacji, będziesz gotowy iść i znaleźć zgłoszenie, do którego napiszesz patcha. Zwróć szczególną uwagę na zgłoszenia z kryterium „easy pickings”. Te zgłoszenia często są z natury dużo prostsze i są świetne dla pierwszorazowych kontrybutorów. Gdy już będziesz zaznajomiony z wnoszeniem wkładu w Django, możesz iść dalej i pisać patche do trudniejszych i bardziej skomplikowanych zgłoszeń.
\nJeśli po prostu już chcesz zacząć (nikt nie będzie cię winił!), spróbuj rzucić okiem na listę łatwych zgłoszeń, które potrzebują patchy i łatwych zgłoszeń, które mają patche potrzebujące poprawy. Jeśli umiesz pisać testy, możesz też spojrzeć na listę łatwych zgłoszeń, które potrzebują testów. Pamiętaj tylko przestrzegać wskazówek dotyczących przypisywania zgłoszeń, o czym było wspomniane w odnośniku do dokumentacji Django na temat przypisywania zgłoszeń i wgrywaniu patchy.
\nPo tym, jak ticket ma patcha, musi zostać przejrzany przez drugą parę oczu. Po wysłaniu pull requesta zaktualizuj metadane ticketu ustawiając na tickecie flagi, które mówią „has patch”, „doesn’t need tests” i tak dalej, aby inni mogli go znaleźć do przejrzenia. Wnoszenie wkładu niekoniecznie zawsze znaczy pisanie patcha od zera. Przeglądanie istniejących patchy jest również bardzo pomocnym wkładem. Zobacz Triaging tickets po szczegóły.
\n