Escribiendo su primer parche para Django

Introducción

¿Interesado en dar un poco a la comunidad? Quizás ha encontrado un bug en Django que le gustaría ver solucionado, o quizás hay una pequeña característica que quiera agregar.

Contribuir con Django en sí es la mejor forma de ver abordadas tus propias inquietudes. Esto puede parecer intimidante al principio, pero en realidad es bastante simple. Te guiaremos a través de todo el proceso para que puedas aprender mediante ejemplos.

¿Para quién es este tutorial?

Ver también

Si usted está buscando una referencia sobre cómo presentar parches, consulte la documentación Submitting patches.

Para este tutorial, esperamos que comprenda al menos el funcionamiento básico de Django. Esto significa que usted no tendría problemas estudiando los tutoriales existentes para crear su primera aplicación Django. Adicionalmente, debería tener una buena comprensión de Python. Si no es así, `Dive into Python`__ es un libro fantástico (y gratuito) disponible en línea para los programadores que comienzan en Python.

Aquellos de ustedes que no están familiarizados con los sistemas de control de versiones y Trac encontrarán que este tutorial y sus vínculos incluyen información suficiente para empezar. Sin embargo, es probable que quiera leer un poco más acerca de estas diferentes herramientas si usted planea contribuir a Django con regularidad.

Sin embargo, en su mayor parte, este tutorial trata de explicar tanto como sea posible, de modo que pueda ser de utilidad para la audiencia más amplia.

Dónde obtener ayuda:

Si presentas problemas leyendo este tutorial, por favor envíe un mensaje a django-developers o visita `#django-dev en irc.freenode.net`__ para chatear con otros usuarios de Django que podrían ayudarte.

¿Qué cubre esta guía?

Te mostraremos cómo contribuir con parches para Django por primera vez. Al final de este tutorial, contará con un entendimiento básico sobre las herramientas y procesos implicados. Específicamente, cubriremos lo siguiente:

• Instalando Git.
• Cómo descargar una copia de desarrollo de Django.
• Conjunto de pruebas de funcionamiento de Django.
• Escribiendo una prueba para su parche.
• Escribiendo el código para su parche.
• Probando su parche.
• Enviar una solicitud de pull.
• Dónde buscar más información.

Una vez que haya terminado el tutorial, puede revisar el resto de la documentación para contribuir con Django. Contiene una gran cantidad de información de lectura obligatoria para todo el que desee convertirse en colaborador habitual de Django. Si tiene preguntas, es probable que obtenga las respuestas.

¡se requiere Python 3!

La versión actual de Django no soporta Python 2.7. Obtén Python 3 en la página de descargas de Python o con el gestor de paquetes de tu sistema operativo.

Para los usuarios de Windows

Al instalar Python en Windows, asegúrese de revisar la opción «Añadir python.exe a la Ruta», de modo que que siempre esté disponible en la línea de comandos.

Código de Conducta

Como un colaborador, usted puede ayudarnos a mantener abierta e inclusiva la comunidad Django. Por favor lea y siga nuestro Código de conducta.

Instalando Git

Para este tutorial, necesitará instalar Git para descargar la versión actual de desarrollo de Django y generar archivos de revisión de los cambios que realice.

Para revisar si tiene o no instalado Git , ejecute git en la línea de comandos. Si recibe un mensaje diciendo que el comando no pudo ser encontrado, tendrá que descargarlo e instalarlo, consulte `la página de descarga de Git`__.

Para los usuarios de Windows

Al instalar Git en Windows, se recomienda que usted seleccione la opción «Git Bash» para que Git se ejecute en su propia shell. Este tutorial asume que usted lo ha instalado de esa forma.

Si no estás familiarizado con Git, siempre se puede encontrar más información sobre sus comandos (una vez instalado) escribiendo git help en la línea de comandos.

Obtener una copia de la versión de desarrollo de Django

El primer paso para contribuir con Django es obtener una copia del código fuente. Primero, haz un fork a Django en GitHub. Después, desde la línea de comandos, utiliza en comando cd para navegar hasta el directorio donde querrás que se aloje tu copia local de Django.

Descargue el repositorio de código fuente de Django con el siguiente comando:

$ git clone [e-mail]:YourGitHubName/django.git

Ahora que usted tiene una copia local de Django, puede instalarla como instalaría cualquier paquete utilizando pip. La forma más conveniente de hacerlo es mediante la utilización de un entorno virtual (o virtualenv) que es una característica integrada en Python que permite mantener un directorio independiente de los paquetes instalados para cada uno de sus proyectos para que no interfieran entre sí.

Es una buena idea guardar todos sus entornos virtuales en un lugar, por ejemplo, en .virtualenvs/ en su directorio principal. Créelo si todavía no existe:

$ mkdir ~/.virtualenvs

Ahora cree un nuevo virtualenv ejecutando:

$ python3 -m venv ~/.virtualenvs/djangodev

La ruta es donde se guardará el nuevo entorno en su computadora.

Para los usuarios de Windows

Utilizar el módulo incorporado venv no funcionará si también está usando el Git Bash shell en Windows, ya que los scripts de activación se crean sólo para el shell del sistema (.bat) y PowerShell (.ps1). Utilice en cambio el paquete virtualenv:

$ pip install virtualenv
$ virtualenv ~/.virtualenvs/djangodev

Para los usuarios de Ubuntu

En algunas versiones de Ubuntu el comando anterior podría fallar. Utilice en cambio el paquete virtualenv, primero asegúrese de que tiene pip3:

$ sudo apt-get install python3-pip
$ # Prefix the next command with sudo if it gives a permission denied error
$ pip3 install virtualenv
$ virtualenv --python=`which python3` ~/.virtualenvs/djangodev

El último paso para instalar su virtualenv es activarlo:

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

Si el comando source no está disponible, puede intentar usar un punto en su lugar:

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

Para los usuarios de Windows

Para activar su virtualenv en Windows, ejecute:

$ source ~/virtualenvs/djangodev/Scripts/activate

Tiene que activar el virtualenv cada vez que abre una nueva ventana de terminal. virtualenvwrapper es una herramienta útil para hacer esto más fácil.

Todo lo que usted instala a través de pip a partir de ahora será instalado en su nuevo virtualenv, aislado de otros entornos y paquetes de todo el sistema. Además, el nombre del virtualenv actualmente activado se muestra en la línea de comandos para ayudarle a saber cuál está utilizando. Continúe e instale la copia de Django previamente clonada:

$ pip install -e /path/to/your/local/clone/django/

La versión instalada de Django está señalando su copia local. Inmediatamente verá los cambios que le realice a la misma, lo cual será de gran ayuda cuando escriba su primer parche.

Restaurar una versión previa de Django

Para este tutorial, vamos a utilizar el ticket: ticket:24788 como caso de estudio, por lo que vamos a rebobinar el historial de versiones de Django en git hasta antes de que se aplicara el parche de dicho ticket. Esto nos permitirá revisar todos los pasos necesarios para escribir ese parche desde cero, incluyendo la ejecución del conjunto de pruebas de Django.

Recuerde que aunque estaremos usando una revisión anterior del repositorio central de Django para los propósitos del tutorial a continuación, ¡Usted siempre debería usar la revisión actual de desarrollo de Django cuando trabaje en su propio parche para un ticket!

Nota

El parche para este ticket fue escrito por Paweł Marczewski, y se aplicó a Django como `commit 4df7e8483b2679fc1cba3410f08960bac6f51115`__. Por lo tanto, estaremos utilizando la revisión de Django inmediatamente anterior a ese, `commit 4ccfc4439a7add24f8db4ef3960d02ef8ae09887`__.

Navegue en el directorio raíz de Django (es el único que contiene django, docs, tests, AUTHORS, etc.). Usted puede después ver la revisión anterior de Django que estaremos utilizando en el tutorial a continuación:

$ git checkout 4ccfc4439a7add24f8db4ef3960d02ef8ae09887

Ejecutando el conjunto de pruebas de Django por primera vez

Al contribuir con Django es muy importante que las modificaciones de su código no introduzcan bugs en otras áreas de Django. Una manera de comprobar que Django todavía funciona después de que usted realice las modificaciones es ejecutar el conjunto de pruebas de Django. Si todavía todas las pruebas pasan, entonces usted puede estar razonablemente seguro de que sus modificaciones no descompusieron por completo a Django. Si usted nunca antes ha ejecutado el conjunto de pruebas de Django, es una buena idea ejecutarlas una vez con anterioridad para familiarizarse con lo que se supone sería su resultado.

Antes de ejecutar el conjunto de pruebas, instale sus dependencias, primero cambiándo al directorio tests/ de Django y después ejecutando:

$ pip install -r requirements/py3.txt

Si encuentra un error durante la instalación, puede que su sistema carezca de alguna dependencia para uno o más de los paquetes de Python. Consulte la documentación del paquete que falla o busque en la web el mensaje de error que encuentre.

Ahora estamos listos para ejecutar el conjunto de pruebas. Si estás utilizando GNU/Linux, macOS o alguna otra distribución de Unix, ejecuta:

$ ./runtests.py

Ahora siéntese y relájese. Todo el conjunto de pruebas de Django tiene más de 9.600 pruebas diferentes, por lo que puede tomar de 5 a 15 minutos para ejecutarse, dependiendo de la velocidad de su computadora.

Mientras que el conjunto de pruebas de Django se esté ejecutando, usted verá una cadena de caracteres que representa el estado de cada prueba mientras se ejecuta. La E indica que se produjo un error durante una prueba, y la F indica que los asertos de una prueba fallaron. Ambos se consideran errores de pruebas. Mientras tanto, la x y la s indican errores esperados y pruebas omitidas respectivamente. Los puntos indican las pruebas aprobadas.

Las pruebas omitidas se deben usualmente a la ausencia de bibliotecas externas requeridas para la ejecución de los test; ver Running all the tests para la lista de dependencias y estar seguro de instalar aquellas relacionadas con los cambios que estás haciendo (no necesitamos ninguna para esta tutorial). Algunas pruebas son especificas de un backend de base de datos particular y serán omitidas si no se está probando ese backend. SQLite es el backend por defecto para las pruebas. Para ejecutar las pruebas con un backend diferente ver Using another settings module.

Una vez que las pruebas finalicen, deberías recibir un mensaje que informa si el conjunto de pruebas pasó o falló. Dado que aún no has realizado ningún cambio en el código de Django, todo el conjunto de pruebas debería pasar. Si obtienes fallos o errores asegúrate de que has seguido correctamente todos los pasos anteriores . Ver :ref: running-unit-tests para más información. Si estas usando Python 3.5+ habrá algunas fallas relacionadas con alertas de código obsoleto que pueden ser ignoradas. Estas fallas han sido corregidas en Django.

Tenga en cuenta que el último trunk de Django no siempre puede ser estable. Cuando se desarrolla sobre trunk se pueden verificar `las construcciones de integración continuas de Django`__ para determinar si las fallas son específicas de su computadora o si también están presentes en las builds oficiales de Django. Si hace clic para ver una build en particular, usted puede ver la «Matriz de configuración», que muestra los fallos analizados por la versión de Python y el backend de la base de datos.

Nota

Para este tutorial y el ticket en el que estamos trabajando, es suficiente probar contra SQLite, sin embargo, es posible (y a veces necesario) ejecutar las pruebas utilizando una base de datos diferente.

Crear una rama para su parche

Antes de hacer ningún cambio, cree una nueva rama para el ticket:

$ git checkout -b ticket_24788

Puedes escoger el nombre que quieras para la rama, por ejemplo «ticket_24788». Todos los cambios que hagas en esta rama serán específicos del ticket y no van a afectar la copia principal del código que hemos clonado antes.

Escribiendo algunas pruebas para su reporte

En la mayoría de los casos, para que un parche sea aceptado en Django tiene que incluir pruebas. Para los parches de corrección de bugs, esto significa escribir una prueba de regresión para asegurar que el bug no sea reintroducido en Django más adelante. Una prueba de regresión debe ser escrita de forma tal que falle mientras que todavía exista el bug y pase una vez que el bug se haya corregido. Para los parches que contienen nuevas características, tendrás que incluir pruebas que garanticen que dichas características estén funcionando correctamente. Los parches también deben fallar cuando la nueva característica no esté presente y por lo tanto, pasar una vez que haya sido aplicada.

Una buena forma de hacer esto, es escribir primero sus nuevas pruebas antes de realizar cualquier cambio en el código. Este estilo de desarrollo se llama `desarrollo guiado por pruebas`__ y se puede aplicar tanto a proyectos completos como a parches individuales. Después de escribir sus pruebas, ejecútelas para asegurarse de que en efecto fallan (ya que aún no ha corregido ese bug o añadido esa característica). Si sus nuevas pruebas no fallan, tendrá que arreglarlas de manera que lo hagan. Después de todo, una prueba de regresión que pasa sin importar si un error está presente, no es muy útil en prevenir que ese error se repita en el futuro.

Ahora a nuestro ejemplo práctico.

Escribiendo algunas pruebas para el ticket #24788

Ticket #24788 propone una pequeña adición de característica: la capacidad para especificar el atributo de nivel de la clase prefix en las clases de formularios, de modo que:

[…] forms which ship with apps could effectively namespace themselves such
that N overlapping form fields could be POSTed at once and resolved to the
correct form.

Para resolver este ticket, vamos a añadir un atributo prefix a la clase BaseForm. Cuando se crean instancias de esta clase, pasar un prefijo al método __init__() todavía asignará ese prefijo en la instancia creada. Sin embargo, no pasar un prefijo ( o pasar None) usará el prefijo de nivel de clase. No obstante, antes de realizar esas modificaciones, vamos a escribir varias pruebas para comprobar que nuestra modificación funciona correctamente y seguirá funcionando en el futuro.

Navegue a la carpeta tests/forms_tests/tests/ de Django y abra el archivo test_forms.py. Agregue el siguiente código en la línea 1674 antes de la función test_forms_with_null_boolean:

def test_class_prefix(self):
    # Prefix can be also specified at the class level.
    class Person(Form):
        first_name = CharField()
        prefix = 'foo'

    p = Person()
    self.assertEqual(p.prefix, 'foo')

    p = Person(prefix='bar')
    self.assertEqual(p.prefix, 'bar')

Esta nueva prueba comprueba que asignar un prefijo de nivel de clase funciona como se esperaba, y que pasar un parámetro prefix cuando se crea una instancia también funciona todavía.

Pero este asunto de las pruebas parece un poco difícil…

Si usted nunca había tenido que lidiar con las pruebas anteriormente, pueden parecer un poco difíciles de escribir a primera vista. Afortunadamente, las pruebas son un tema muy importante en la programación, así que hay mucha información disponible:

• Un buen primer vistazo a las pruebas de escritura para Django se puede encontrar en la documentación en: doc:/topics/testing/overview.
• Inmersión en Python (un libro en línea gratis para los desarrolladores principiantes de Python) incluye una gran `introducción a las pruebas unitarias`__.
• Después de leer esos, si quieres algo un poco mas sustancioso para hincar el diente, siempre está la documentación de unittest de Python.

Ejecutando su nueva prueba

Recuerde que no hemos hecho todavía ninguna modificación al BaseForm, así que nuestras pruebas van a fallar. Vamos a ejecutar todas las pruebas en la carpeta forms_tests para asegurarnos de que es lo que realmente sucede. Desde la línea de comandos, cambiemos cd al directorio tests/ de Django y ejecutemos:

$ ./runtests.py forms_tests

Si las pruebas se ejecutaron correctamente, usted debería ver tres fallos correspondientes a cada uno de los métodos de prueba que hemos añadido. Si todas las pruebas pasan, entonces usted querrá asegurarse de que ha agregado la nueva prueba mostrada arriba a la carpeta y clase apropiadas.

Escribiendo el código para su ticket

A continuación vamos a estar agregando la funcionalidad descrita en el ticket #24788 a Django.

Escribiendo el código para el ticket #24788

Navegue a la carpeta django/django/forms/ y abra el archivo forms.py. Encuentre la clase BaseForm en la línea 72 y agregue el atributo de clase prefix justo después del atributo field_order:

class BaseForm:
    # This is the main implementation of all the Form logic. Note that this
    # class is different than Form. See the comments by the Form class for
    # more information. Any improvements to the form API should be made to
    # *this* class, not to the Form class.
    field_order = None
    prefix = None

Comprobando que ahora su prueba pase

Una vez que haya terminado de modificar Django, tenemos que asegurarnos de que las pruebas que escribimos anteriormente pasan para que podamos ver si el código que escribimos arriba funciona correctamente. Para ejecutar las pruebas en la carpeta forms_tests, cambie al directorio tests/ de Django y ejecute:

$ ./runtests.py forms_tests

¡Vaya, que bien que escribimos esas pruebas! Aún debe ver 3 fallos con la siguiente excepción

AssertionError: None != 'foo'

Olvidamos agregar la sentencia condicional en el método __init__. Continúe y modifique self.prefix = prefix que ahora está en la línea 87 de django/forms/forms.py, añadiendo una sentencia condicional:

if prefix is not None:
    self.prefix = prefix

Vuelva a ejecutar las pruebas y todas deben pasar. Si no es así, asegúrese de que ha modificado correctamente la clase BaseForm como se muestra arriba y que ha copiado las nuevas pruebas correctamente.

Ejecutando el conjunto de pruebas de Django por segunda vez

Una vez que haya verificado que su parche y su prueba funcionan correctamente, es una buena idea ejecutar todo el conjunto de pruebas de Django sólo para comprobar que su cambio no ha introducido ningún bug en otras áreas de Django. A pesar de que pasar con éxito todo el conjunto de pruebas no garantiza que su código está libre de errores, sí ayuda a identificar muchos bugs y regresiones que de otro modo podrían pasar desapercibidos.

Para ejecutar todo el conjunto de pruebas de Django, cambie al directorio tests/ de Django y ejecute:

$ ./runtests.py

Siempre y cuando no haya fallos, ya está listo para arrancar.

Escribiendo la documentación

Esta es una nueva característica, por lo tanto se debe documentar. Agregue la siguiente sección en la línea 1068 (al final del archivo) de django/docs/ref/forms/api.txt`:

The prefix can also be specified on the form class::

    >>> class PersonForm(forms.Form):
    ...     ...
    ...     prefix = 'person'

.. versionadded:: 1.9

    The ability to specify ``prefix`` on the form class was added.

Dado que esta nueva característica estará en una próxima versión también se añade a las notas de la versión de Django 1.9, en la línea 164 debajo de la sección «Formularios» en el archivo docs/releases/1.9.txt:

* A form prefix can be specified inside a form class, not only when
  instantiating a form. See :ref:`form-prefix` for details.

Para obtener más información sobre escribir la documentación, incluyendo una explicación de lo que se trata el fragmento versionadded, consulte Writing documentation. Esa página incluye también una explicación de cómo generar una copia de la documentación localmente, por lo que puede obtener una vista previa del código HTML que se generará.

Previsualizar sus cambios

Ahora es tiempo de revisar todos los cambios hechos en nuestro parche. Para ver las diferencias entre tu copia de Django(con tus cambios) y la revisión obtenida inicialmente en este tutorial:

$ git diff

Use las flechas del teclado para moverse arriba y abajo.

diff --git a/django/forms/forms.py b/django/forms/forms.py
index 509709f..d1370de 100644
--- a/django/forms/forms.py
+++ b/django/forms/forms.py
@@ -75,6 +75,7 @@ class BaseForm:
     # information. Any improvements to the form API should be made to *this*
     # class, not to the Form class.
     field_order = None
+    prefix = None

     def __init__(self, data=None, files=None, auto_id='id_%s', prefix=None,
                  initial=None, error_class=ErrorList, label_suffix=None,
@@ -83,7 +84,8 @@ class BaseForm:
         self.data = data or {}
         self.files = files or {}
         self.auto_id = auto_id
-        self.prefix = prefix
+        if prefix is not None:
+            self.prefix = prefix
         self.initial = initial or {}
         self.error_class = error_class
         # Translators: This is the default suffix added to form field labels
diff --git a/docs/ref/forms/api.txt b/docs/ref/forms/api.txt
index 3bc39cd..008170d 100644
--- a/docs/ref/forms/api.txt
+++ b/docs/ref/forms/api.txt
@@ -1065,3 +1065,13 @@ You can put several Django forms inside one ``<form>`` tag. To give each
     >>> print(father.as_ul())
     <li><label for="id_father-first_name">First name:</label> <input type="text" name="father-first_name" id="id_father-first_name" /></li>
     <li><label for="id_father-last_name">Last name:</label> <input type="text" name="father-last_name" id="id_father-last_name" /></li>
+
+The prefix can also be specified on the form class::
+
+    >>> class PersonForm(forms.Form):
+    ...     ...
+    ...     prefix = 'person'
+
+.. versionadded:: 1.9
+
+    The ability to specify ``prefix`` on the form class was added.
diff --git a/docs/releases/1.9.txt b/docs/releases/1.9.txt
index 5b58f79..f9bb9de 100644
--- a/docs/releases/1.9.txt
+++ b/docs/releases/1.9.txt
@@ -161,6 +161,9 @@ Forms
   :attr:`~django.forms.Form.field_order` attribute, the ``field_order``
   constructor argument , or the :meth:`~django.forms.Form.order_fields` method.

+* A form prefix can be specified inside a form class, not only when
+  instantiating a form. See :ref:`form-prefix` for details.
+
 Generic Views
 ^^^^^^^^^^^^^

diff --git a/tests/forms_tests/tests/test_forms.py b/tests/forms_tests/tests/test_forms.py
index 690f205..e07fae2 100644
--- a/tests/forms_tests/tests/test_forms.py
+++ b/tests/forms_tests/tests/test_forms.py
@@ -1671,6 +1671,18 @@ class FormsTestCase(SimpleTestCase):
         self.assertEqual(p.cleaned_data['last_name'], 'Lennon')
         self.assertEqual(p.cleaned_data['birthday'], datetime.date(1940, 10, 9))

+    def test_class_prefix(self):
+        # Prefix can be also specified at the class level.
+        class Person(Form):
+            first_name = CharField()
+            prefix = 'foo'
+
+        p = Person()
+        self.assertEqual(p.prefix, 'foo')
+
+        p = Person(prefix='bar')
+        self.assertEqual(p.prefix, 'bar')
+
     def test_forms_with_null_boolean(self):
         # NullBooleanField is a bit of a special case because its presentation (widget)
         # is different than its data. This is handled transparently, though.

Cuando hayas terminado de revisar el parche presiona q para volver a la línea de comandos. Si el contenido del parche se veía bien es tiempo de consumar los cambios.

Consumar los cambios en el parche

Para consumar los cambios:

$ git commit -a

Esto abre un editor de texto para escribir el mensaje del commit. Sigue las guías para mensajes del commit y escribe un mensaje como:

Fixed #24788 -- Allowed Forms to specify a prefix at the class level.

Empujar el commit y hacer una solicitud de pull

Después de consumar el parche envíalo a tu fork en GitHub (reemplaza «ticket_24788» con el nombre de tu rama si es que es distinto):

$ git push origin ticket_24788

Puedes crear una solicitud de pull visitando La página GitHub de Django. Vas a ver tu rama en «Your recently pushed branches». Has clic en «Compare & pull request».

Por favor no lo hagas para este tutorial, pero en la siguiente página muestra una vista previa del parche, deberías hacer clic en «Create pull request».

Próximos pasos

¡Enhorabuena, ha aprendido cómo hacer una solicitud de pull a Django! Encontrará detalles de técnicas más avanzadas que puede necesitar en Working with Git and GitHub.

Ahora puedes dar un buen uso a esas habilidades ayudando a mejorar la base de código de Django.

Más información para los nuevos colaboradores

Antes de que se involucre mucho en la escritura de parches para Django, hay algo más de información sobre cómo contribuir a la que probablemente debería echarle un vistazo:

• Debe asegurarse de leer la documentación de Django sobre reclamar tickets y enviar parches. Esta incluye la etiqueta de Trac, cómo reclamar tickets para uno mismo, el estilo esperado de codificación para parches y muchos otros detalles importantes.
• Las personas que colaboran por primera vez también deben leer la documentación para los colaboradores principiantes de Django. Tiene muchos buenos consejos para aquellos de nosotros que somos nuevos en esto de colaborar con Django.
• Después de ellos, si todavía quiere más información sobre cómo contribuir, siempre se puede navegar por el resto de la documentación de Django sobre cómo contribuir. Este contiene un montón de información útil y debe ser su primera fuente para responder a cualquier pregunta que pueda tener.

Encontrando su primer ticket real

Una vez que haya revisado parte de esa información, estará listo para salir y encontrar un ticket al cual escribirle un parche. Preste especial atención a los tickets con el criterio de «easy pickings». Estos tickets son a menudo de carácter mucho más simples y son geniales para los que colaboran por primera vez. Una vez que esté familiarizado con como contribuir con Django, puede pasar a escribir parches para los tickets más difíciles y complicados.

Si lo que desea es empezar ya (¡Y nadie lo culparía!), trate de echar un vistazo a la lista de `los tickets sencillos que necesitan parches`__ y `los tickets sencillos que tienen parches que necesitan mejoras`__. Si se siente cómodo con la escritura de pruebas también puede ver la lista de “tickets sencillos que necesitan pruebas`__. Sólo recuerde seguir las directrices sobre cómo reclamar tickets que se mencionaron en el enlace a la documentación de Django sobre reclamar tickets y enviar parches.

¿Qué hay después de crear una solicitud de pull?

Después de que un ticket tiene un parche, necesita ser revisado por un segundo par de ojos. Después de enviar una solicitud de pull asegúrese de actualizar los metadatos del ticket mediante el establecimiento de banderas en el ticket para decir «tiene parche», «no necesita pruebas», etc, para que otros puedan encontrarlo para su revisión. Contribuir no necesariamente siempre significa escribir un parche desde cero. Revisar parches existentes es también una contribución muy útil. Consulte: doc:/internals/contributing/triaging-tickets para más detalles.