Licencia y derecho de copia¶
When contributing project code, you agree to put your changes and new code under the repository license, GPL-3.0-or-later, unless stated and agreed otherwise. New source files should follow the existing copyright and SPDX license header style.
Use a different license only when there is a deliberate reason, such as files shared with repositories using more permissive licenses.
Ver también
Licencia de Weblate explica licencia con más detalles.
Escritura de un buen parche¶
Escribe cambios separados¶
Es molesto cuando obtienes un parche masivo que es dicho para reparar problemas extraños, pero discusiones y opciones no están de acuerdo con 10 de ellos o 9 de ellos ya estaban corregidos diferentemente. Entonces, la persona que fusiona este cambio tiene que extraer el único parche interesante de algún lugar dentro de la enorme pila de fuentes, y eso genera mucho trabajo adicional.
Preferiblemente, cada corrección que aborde una incidencia debería estar en su propio parche/commit con su propia descripción/mensaje de commit indicando exactamente lo que corrigen para que todos los cambios puedan ser aplicados selectivamente por el mantenedor u otras partes interesadas.
Además, los cambios separados permiten una disección mucho mejor para el seguimiento de incidencias y regresiones en el futuro.
Documentación¶
Documentar puede ser una tarea tediosa; sin embargo, es necesario que alguien la complete. Es mucho más fácil enviar la documentación junto con los cambios de código. Recuerda documentar los métodos, los bloques de código complejos o las funciones visibles para el usuario.
Ver también
Casos de prueba¶
Las pruebas nos permiten verificar rápidamente que las características funcionan correctamente. Para mantener y mejorar esta situación, todas las características y funciones nuevas que se añadan deben probarse en el conjunto de pruebas. Cada característica añadida debe contar con al menos un caso de prueba válido que verifique su funcionamiento según lo documentado.
Mensajes de consigna¶
Las consignas de Git deben seguir la especificación Conventional Commits.
Comprobación de tecleo¶
Any new code should utilize PEP 484 type hints. We are using mypy to check them because it has a Django plugin that makes type checking of Django apps practical.
New and changed code should not introduce new mypy failures where current Django typing support makes that practical. The code base is not yet completely covered by type annotations, and some Django constructs are difficult to annotate precisely. CI therefore enforces mypy only for selected modules and reports other findings separately.
Codificar estándar y enlazar el código¶
El código seguiría PEP 8 codificando líneas de guía y sería formateado utilizando formateador de código ruff.
Para comprobar la calidad del código, puede utilizar ruff, su configuración está almacenada en pyproject.toml.
La forma más sencilla de garantizar todo esto es instalar prek. Se trata de una re‐implementación de terceros de la herramienta pre-commit utilizada por Weblate. Está incluida en las dependencias de desarrollo declaradas en pyproject.toml, por lo que al instalar dichas dependencias, prek estará disponible.
Para comprobar todos los archivos manualmente, ejecute:
uv run prek run --all-files
Si prefiere el pre-commit original del cliente, utilice la misma configuración desde .pre-commit-config.yaml.
Codificar con seguridad¶
Cualquier código escrito para Weblate debe crearse teniendo en mente los principios de seguridad por naturaleza.
Directrices de IA¶
Al contribuir con contenido al proyecto, nos autorizas a usarlo tal cual y debes asegurarte de tener permiso para distribuirlo. Al enviarnos un cambio, aceptas que el proyecto pueda y deba adoptarlo y redistribuirlo bajo la licencia del proyecto. Los autores deben ser conscientes de que tienen la responsabilidad de garantizar que no se envíe código sin licencia al proyecto.
Esto es independiente de si se utiliza IA o no.
Al contribuir con una solicitud de incorporación de cambios, siempre debe asegurarse de que la propuesta sea de buena calidad y se esfuerce al máximo, siguiendo nuestras directrices. Como regla general, si alguien detecta que la contribución se realizó con ayuda de IA, tendrá más trabajo por delante.
Podemos aceptar código escrito con la ayuda de IA en el proyecto, pero el código aún debe seguir los estándares de codificación, estar escrito con claridad, estar documentado, presentar casos de prueba y cumplir con todos los requisitos normales que tenemos.