---
title: "Writing your first contribution for Django"
version: 5.1
locale: pl
source: https://docs.djangoproject.com/pl/5.1/intro/contributing/
canonical: https://djangodocs.dev/pl/5.1/intro/contributing/
---
# Writing your first contribution for Django

## Wprowadzenie

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.

Pomoc 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 jest to przyjemna droga z dokumentacją, narzędziami i wsparciem społeczności. Przeprowadzimy Cię przez cały proces na przykładzie, abyś mógł się nauczyć tego w praktyce.

### Dla kogo jest ten tutorial?

> **See also**
>
> Jeśli szukasz informacji o szczegółach wprowadzania zmian w kodzie, obejrzyj dokumentację [Contributing code](/pl/5.1/internals/contributing/writing-code/).

For this tutorial, we expect that you have at least a basic understanding of
how Django works. This means you should be comfortable going through the
existing tutorials on [writing your first Django app](/pl/5.1/intro/tutorial01/).
In addition, you should have a good understanding of Python itself. But if you
don’t, [Dive Into Python](https://diveintopython3.net/) is a fantastic (and free) online book for beginning
Python programmers.

Ci 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.

Celem 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.

> **Gdzie szukać pomocy:**
>
> If you’re having trouble going through this tutorial, please post a message
> on the [Django Forum](https://forum.djangoproject.com/) or drop by the [Django Discord server](https://chat.djangoproject.com) to chat with
> other Django users who might be able to help.

### Co zawiera ten przewodnik?

We’ll be walking you through contributing to Django for the first time.
By the end of this tutorial, you should have a basic understanding of both the
tools and the processes involved. Specifically, we’ll be covering the following:

- Instalacja Gita.
- Pobieranie kopii wersji rozwojowej Django
- Uruchamianie zestawu testów Django.
- Writing a test for your changes.
- Writing the code for your changes.
- Testing your changes.
- 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](/pl/5.1/internals/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.

> **Wymagany Python 3!**
>
> Bieżąca wersja Django nie wspiera Pythona 2.7. Pobierz Pythona 3 ze [strony pobrań Pythona](https://www.python.org/downloads/) lub za pomocą menadżera pakietów swojego systemu operacyjnego.

> **Dla użytkowników Windows**
>
> W dokumentacji [Instalacja Pythona](/pl/5.1/howto/windows/#install-python-windows) w systemie Windows znajdziesz dodatkowe wskazówki.

## Kodeks postępowania

Jako 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](https://www.djangoproject.com/conduct/).

## Instalacja Gita

For this tutorial, you’ll need Git installed to download the current
development version of Django and to generate a branch for the changes you
make.

Aby 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](https://git-scm.com/download).

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ń.

## Pobranie kopii wersji rozwojowej Django

Pierwszym krokiem do współtworzenia Django jest uzyskanie kopii kodu źródłowego. Najpierw [rozwidlij Django na GitHubie](https://github.com/django/django/fork). 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:

```console
$ git clone https://github.com/YourGitHubName/django.git
```

*Windows*

```doscon
...\> git clone https://github.com/YourGitHubName/django.git
```

> **Połączenie o niskiej przepustowości?**
>
> Możesz dodać argument `--depth 1` do `git clone`, aby ominąć pobieranie całej historii commitów Django, co zmniejsza transfer danych z ~250 MB do ~70 MB.

Kiedy już masz lokalną kopię Django, możesz go zainstalować tak jak zainstalowałbyś dowolny pakiet za pomocą `pip`a. Najwygodniejszym sposobem, aby to zrobić, jest użycie *środowiska wirtualnego*, 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 wirtualnych środowisk w jednym miejscu, na przykład w `.virtualenvs/` w Twoim katalogu domowym.

Stwórz nowe środowisko wirtualne uruchamiając:

```console
$ python3 -m venv ~/.virtualenvs/djangodev
```

*Windows*

```doscon
...\> py -m venv %HOMEPATH%\.virtualenvs\djangodev
```

Ścieżką jest miejsce gdzie nowe środowisko zostanie zapisane na Twoim komputerze:

Ostatnim krokiem w procesie konfigurowania twojego środowiska wirtualnego jest jego aktywacja:

```console
$ source ~/.virtualenvs/djangodev/bin/activate
```

Jeśli komenda `source` nie jest dostępna, możesz spróbować zamiast niej użyć kropki:

```console
$ . ~/.virtualenvs/djangodev/bin/activate
```

Musisz aktywować swoje środowisko wirtualne zawsze, kiedy otwierasz nowe okno terminala.

> **Dla użytkowników Windows**
>
> Aby aktywować swoje środowisko wirtualne w systemie Windows, uruchom:
>
> ```doscon
> ...\> %HOMEPATH%\.virtualenvs\djangodev\Scripts\activate.bat
> ```

Nazwa obecnie aktywnego środowiska wirtualnego jest wyświetlana w linii komend, aby pomóc śledzić, którego środowiska używasz. Cokolwiek, co zainstalujesz `pip`em, gdy ta nazwa się wyświetla, zostanie zainstalowane w tym wirtualnym środowisku, wyizolowane od innych środowisk i pakietów systemowych.

Śmiało, zainstaluj wcześniej sklonowaną kopię Django:

```console
$ python -m pip install -e /path/to/your/local/clone/django/
```

*Windows*

```doscon
...\> py -m pip install -e \path\to\your\local\clone\django\
```

The installed version of Django is now pointing at your local copy by installing
in editable mode. You will immediately see any changes you make to it, which is
of great help when writing your first contribution.

### Tworzenie projektów z lokalną kopią Django

It may be helpful to test your local changes with a Django project. First you
have to create a new virtual environment, [install the previously cloned
local copy of Django in editable mode](#intro-contributing-install-local-copy),
and create a new Django project outside of your local copy of Django. You will
immediately see any changes you make to Django in your new project, which is
of great help when writing your first contribution, especially if testing
any changes to the UI.

W [tutorialu](/pl/5.1/intro/tutorial01/) znajdziesz pomoc w tworzeniu projektu Django.

## Uruchomienie zestawu testów Django po raz pierwszy

Dają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 działają i nie popsuły innych części Django. Jeśli nigdy wcześniej nie uruchamiałeś zestawu testów Django, dobrym pomysłem jest uprzednio uruchomienie ich raz po to, abyś zaznajomił się z ich efektem.

Przed uruchomieniem zestawu testów, wejdź do katalogu `tests/` Django używając komendy `cd tests` i zainstaluj zależności dla testów uruchamiając:

```console
$ python -m pip install -r requirements/py3.txt
```

*Windows*

```doscon
...\> py -m pip install -r requirements\py3.txt
```

Jeś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ś.

Now we are ready to run the test suite:

```console
$ ./runtests.py
```

*Windows*

```doscon
...\> runtests.py
```

Teraz usiądź i odpręż się. Cały zestaw testów Django ma ich tysiące a ich wykonanie może zająć co najmniej kilka minut, w zależności od szybkości twojego komputera.

Kiedy uruchomisz zestaw testów Django, zobaczysz strumień znaków oznaczających status każdego testu po jego zakończeniu. `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 wymaganych do uruchomienia testu; zobacz [Running all the tests](/pl/5.1/internals/contributing/writing-code/unit-tests/#running-unit-tests-dependencies), 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](/pl/5.1/internals/contributing/writing-code/unit-tests/#running-unit-tests-settings).

Kiedy 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](/pl/5.1/internals/contributing/writing-code/unit-tests/#running-unit-tests).

Zwróć uwagę, że najnowsza wersja brancha „main” Django może nie zawsze być stabilna. Kiedy dewelopujesz z użyciem „maina”, możesz sprawdzić [Django’s continous integration builds](https://djangoci.com), 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.

> **Note**
>
> Na potrzeby tego tutorialu i zgłoszenia, nad którym pracujemy, testowanie z użyciem SQLite wystarczy, chociaż jest możliwe (i czasem niezbędne), aby [uruchomić testy używając innej bazy danych](/pl/5.1/internals/contributing/writing-code/unit-tests/#running-unit-tests-settings). Przy zmianach interfejsu, przyda ci się [uruchomienie testów Selenium](/pl/5.1/internals/contributing/writing-code/unit-tests/#running-selenium-tests).

## Praca nad funkcjonalnością

Na potrzeby tego tutoriala będziemy pracowali nad „sztucznym zgłoszeniem” jako studium przypadku. Tutaj są fikcyjne szczegóły:

> **Zgłoszenie #99999 – Umożliwić tworzenie toastów**
>
> Django powinno zawierać funkcję `django.shortcuts.make_toast()`, która zwraca `'toast'`.

Teraz zaimplementujemy tę funkcjonalność i związane z nią testy.

## Creating a branch

Przed wprowadzeniem jakichkolwiek zmian, stwórz nowy branch dla zgłoszenia:

```console
$ git checkout -b ticket_99999
```

*Windows*

```doscon
...\> git checkout -b ticket_99999
```

Możesz wybrać dowolną nazwę dla brancha, na przykład „ticket\_99999”. 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.

## Pisanie testów do twojego zgłoszenia

In most cases, for a contribution to be accepted into Django it has to include
tests. For bug fix contributions, this means writing a regression test to
ensure that  the bug is never reintroduced into Django later on. A regression
test should be written in such a way that it will fail while the bug still
exists and pass once the bug has been fixed. For contributions containing new
features, you’ll need to include tests which ensure that the new features are
working correctly. They too should fail when the new feature is not present,
and then pass once it has been implemented.

A good way to do this is to write your new tests first, before making any
changes to the code. This style of development is called
[test-driven development](https://en.wikipedia.org/wiki/Test-driven_development) and can be applied to both entire projects and
single changes. After writing your tests, you then run them to make sure that
they do indeed fail (since you haven’t fixed that bug or added that feature
yet). If your new tests don’t fail, you’ll need to fix them so that they do.
After all, a regression test that passes regardless of whether a bug is present
is not very helpful at preventing that bug from reoccurring down the road.

Pora na nasz praktyczny przykład.

### Pisanie testu do zgłoszenia #99999

Aby rozwiązać to zgłoszenie, dodamy funkcję `make_toast()` do modułu `django.shortcuts`. Najpierw dodamy test, który próbuje użyć funkcji i sprawdza, że jej wynik wygląda poprawnie.

Przejdź do folderu `tests/shortcuts` Django i stwórz nowy plik `test_make_toast.py`. Dodaj następujący kod:

```
from django.shortcuts import make_toast
from django.test import SimpleTestCase

class MakeToastTests(SimpleTestCase):
    def test_make_toast(self):
        self.assertEqual(make_toast(), "toast")
```

Ten test sprawdza, że `make_toast()` zwraca `'toast'`.

> **Ale to całe testowanie wygląda na dość ciężkie…**
>
> Jeśli nie miałeś nigdy wcześniej do czynienia z testami, mogą wyglądać na trochę trudne do pisania na pierwszy rzut oka. Na szczęście testowanie jest *bardzo* dużym tematem w programowaniu komputerów, więc można znaleźć na jego temat wiele informacji:
>
> - Dobry artykuł na początek o pisaniu testów do Django można znaleźć w dokumentacji: [Writing and running tests](/pl/5.1/topics/testing/overview/).
> - Dive Into Python (darmowa książka online dla początkujących Python-deweloperów) zawiera świetny [wstęp do testów jednostkowych](https://diveintopython3.net/unit-testing.html).
> - Po ich przeczytaniu, jeśli chcesz zanurzyć zęby w czymś bardziej mięsistym, jest zawsze dokumentacja [`unittest`](https://docs.python.org/3/library/unittest.html#module-unittest) Pythona.

### Uruchomienie twojego nowego testu

Jako że nie wprowadziliśmy jeszcze żadnych zmian do `django.shortcuts`, nasz test powinien się nie powieźć. Uruchommy wszystkie testy w folderze `shortcuts`, aby upewnić się, że tak naprawdę się dzieje. `cd`-uj do katalogu `tests/` Django i uruchom:

```console
$ ./runtests.py shortcuts
```

*Windows*

```doscon
...\> runtests.py shortcuts
```

Jeśli testy uruchomiły się poprawnie, powinieneś zobaczyć jedną porażkę odpowiadającą metodzie testowej, którą dodaliśmy, z tym błędem:

```pytb
ImportError: cannot import name 'make_toast' from 'django.shortcuts'
```

Jeśli wszystkie testy przeszły, wtedy musisz upewnić się, że dodałeś nowy test pokazany powyżej do odpowiedniego folderu i pliku o odpowiedniej nazwie.

## Pisanie kodu do twojego zgłoszenia

Następnie dodamy funkcję `make_toast()`.

Przejdź do folderu `django/` i otwórz plik `shortcuts.py`. Na jego końcu dodaj:

```
def make_toast():
    return "toast"
```

Teraz powinniśmy się upewnić, że test, który napisaliśmy wcześniej, przechodzi, abyśmy zobaczyli, czy kod, który dodaliśmy, działa poprawnie. Znów przejdź do katalogu `tests/` Django i uruchom:

```console
$ ./runtests.py shortcuts
```

*Windows*

```doscon
...\> runtests.py shortcuts
```

Wszystko powinno przejść. Jeśli nie przeszło, upewnij się, że poprawnie dodałeś funkcję do odpowiedniego pliku.

## Uruchamianie zestawu testów Django drugi raz

Once you’ve verified that your changes and test are working correctly, it’s
a good idea to run the entire Django test suite to verify that your change
hasn’t introduced any bugs into other areas of Django. While successfully
passing the entire test suite doesn’t guarantee your code is bug free, it does
help identify many bugs and regressions that might otherwise go unnoticed.

Aby uruchomić zestaw testów Django w całości, wejdź `cd` w katalog `tests/` Django i uruchom:

```console
$ ./runtests.py
```

*Windows*

```doscon
...\> runtests.py
```

## Pisanie dokumentacji

To nowa funkcjonalność, więc powinna zostać udokumentowana. Otwórz plik `docs/topics/http/shortcuts.txt` i dodaj co następuje na końcu tego pliku:

```rst
``make_toast()``
================

.. function:: make_toast()

.. versionadded:: 2.2

Returns ``'toast'``.
```

Jako że ta nowa funkcjonalność będzie w nadchodzącym wydaniu, dodamy ją również do informacji na temat wydania dla następnej wersji Django. Otwórz informacje o wydaniu dla ostatniej wersji w `docs/releases/`, która w momencie pisania to `2.2.txt`. Dodaj notatkę pod nagłówkiem „Minor Features”:

```rst
:mod:`django.shortcuts`
~~~~~~~~~~~~~~~~~~~~~~~

* The new :func:`django.shortcuts.make_toast` function returns ``'toast'``.
```

Po więcej informacji na temat pisania dokumentacji, wliczając wyjaśnienie o co chodzi w cząstce `versionadded`, odsyłamy do [Writing documentation](/pl/5.1/internals/contributing/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.

## Podgląd twoich zmian

Now it’s time to review the changes made in the branch. To stage all the
changes ready for commit, run:

```console
$ git add --all
```

*Windows*

```doscon
...\> git add --all
```

Następnie wyświetl różnice między twoją bieżącą kopią Djang (z twoimi zmianami) i rewizją, którą pierwotnie zcheck-outowałeś wcześniej w tym tutorialu, używając:

```console
$ git diff --cached
```

*Windows*

```doscon
...\> git diff --cached
```

Użyj klawiszy strzałek, aby przesuwać się do góry i w dół.

```diff
diff --git a/django/shortcuts.py b/django/shortcuts.py
index 7ab1df0e9d..8dde9e28d9 100644
--- a/django/shortcuts.py
+++ b/django/shortcuts.py
@@ -156,3 +156,7 @@ def resolve_url(to, *args, **kwargs):

     # Finally, fall back and assume it's a URL
     return to
+
+
+def make_toast():
+    return 'toast'
diff --git a/docs/releases/2.2.txt b/docs/releases/2.2.txt
index 7d85d30c4a..81518187b3 100644
--- a/docs/releases/2.2.txt
+++ b/docs/releases/2.2.txt
@@ -40,6 +40,11 @@ database constraints. Constraints are added to models using the
 Minor features
 --------------

+:mod:`django.shortcuts`
+~~~~~~~~~~~~~~~~~~~~~~~
+
+* The new :func:`django.shortcuts.make_toast` function returns ``'toast'``.
+
 :mod:`django.contrib.admin`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~

diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
index 7b3a3a2c00..711bf6bb6d 100644
--- a/docs/topics/http/shortcuts.txt
+++ b/docs/topics/http/shortcuts.txt
@@ -271,3 +271,12 @@ This example is equivalent to::
         my_objects = list(MyModel.objects.filter(published=True))
         if not my_objects:
             raise Http404("No MyModel matches the given query.")
+
+``make_toast()``
+================
+
+.. function:: make_toast()
+
+.. versionadded:: 2.2
+
+Returns ``'toast'``.
diff --git a/tests/shortcuts/test_make_toast.py b/tests/shortcuts/test_make_toast.py
new file mode 100644
index 0000000000..6f4c627b6e
--- /dev/null
+++ b/tests/shortcuts/test_make_toast.py
@@ -0,0 +1,7 @@
+from django.shortcuts import make_toast
+from django.test import SimpleTestCase
+
+
+class MakeToastTests(SimpleTestCase):
+    def test_make_toast(self):
+        self.assertEqual(make_toast(), 'toast')
```

When you’re done previewing the changes, hit the `q` key to return to the
command line. If the diff looked okay, it’s time to commit the changes.

## Committing the changes

Aby scommitować zmiany:

```console
$ git commit
```

*Windows*

```doscon
...\> git commit
```

Powoduje to otwarcie edytora tekstu do wpisania „commit message”. Zrealizuj [zalecenia commit message’y](/pl/5.1/internals/contributing/committing-code/#committing-guidelines) i napisz notatkę w ten sposób:

```text
Fixed #99999 -- Added a shortcut function to make toast.
```

## Pushowanie commita i tworzenie pull requesta

After committing the changes, send it to your fork on GitHub (substitute
„ticket\_99999” with the name of your branch if it’s different):

```console
$ git push origin ticket_99999
```

*Windows*

```doscon
...\> git push origin ticket_99999
```

Możesz stworzyć pull request odwiedzając [stronę Django na GitHubie](https://github.com/django/django/). Zobaczysz swój branch pod „Your recently pushed branches”. Kliknij „Compare & pull request” obok niego.

Please don’t do it for this tutorial, but on the next page that displays a
preview of the changes, you would click „Create pull request”.

## Następne kroki

Gratulacje, 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](/pl/5.1/internals/contributing/writing-code/working-with-git/).

Teraz możesz dobrze wykorzystać te umiejętności pomagając ulepszać bazowy kod Django.

### Więcej informacji dla nowych kontrybutorów

Before you get too into contributing to Django, there’s a little more
information on contributing that you should probably take a look at:

- You should make sure to read Django’s documentation on
  [claiming tickets and submitting pull requests](/pl/5.1/internals/contributing/writing-code/submitting-patches/).
  It covers Trac etiquette, how to claim tickets for yourself, expected
  coding style (both for code and docs), and many other important details.
- Ci, którzy mają styczność pierwszy raz z wnoszeniem wkładu do kodu, powinni przeczytać też [dokumentację Django dla nowych kontrybutorów](/pl/5.1/internals/contributing/new-contributors/). 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](/pl/5.1/internals/contributing/). Zawiera tonę przydatnych informacji i powinna być twoim pierwszym źródłem, odpowiadającym na każde pytanie, które możesz mieć.

### Znajdowanie twojego pierwszego prawdziwego zgłoszenia

Once you’ve looked through some of that information, you’ll be ready to go out
and find a ticket of your own to contribute to. Pay special attention to
tickets with the „easy pickings” criterion. These tickets are often much
simpler in nature and are great for first time contributors. Once you’re
familiar with contributing to Django, you can start working on more difficult
and complicated tickets.

If you just want to get started already (and nobody would blame you!), try
taking a look at the list of [easy tickets without a branch](https://code.djangoproject.com/query?status=new&status=reopened&has_patch=0&easy=1&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority) and the
[easy tickets that have branches which need improvement](https://code.djangoproject.com/query?status=new&status=reopened&needs_better_patch=1&easy=1&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority). If you’re familiar
with writing tests, you can also look at the list of
[easy tickets that need tests](https://code.djangoproject.com/query?status=new&status=reopened&needs_tests=1&easy=1&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority). Remember to follow the guidelines about
claiming tickets that were mentioned in the link to Django’s documentation on
[claiming tickets and submitting branches](/pl/5.1/internals/contributing/writing-code/submitting-patches/).

### Co dalej po stworzeniu pull requesta?

After a ticket has a branch, it needs to be reviewed by a second set of eyes.
After submitting a pull request, update the ticket metadata by setting the
flags on the ticket to say „has patch”, „doesn’t need tests”, etc, so others
can find it for review. Contributing doesn’t necessarily always mean writing
code from scratch. Reviewing open pull requests is also a very helpful
contribution. See [Triaging tickets](/pl/5.1/internals/contributing/triaging-tickets/) for details.