Contribuir a los proyectos de código abierto de Ultralytics#
¡Bienvenido! Nos encanta que estés considerando contribuir a nuestros proyectos de código abierto de Ultralytics. Tu participación no solo ayuda a mejorar la calidad de nuestros repositorios, sino que también beneficia a toda la comunidad de visión por computador. Esta guía proporciona directrices claras y mejores prácticas para ayudarte a empezar.
Watch: How to Contribute to Ultralytics Repository | Ultralytics Models, Datasets and Documentation 🚀
🤝 Código de conducta#
Para garantizar un entorno acogedor e inclusivo para todo el mundo, todos los colaboradores deben cumplir nuestro Code of Conduct. El respeto, la amabilidad y la profesionalidad son el núcleo de nuestra comunidad.
🚀 Contribuir mediante pull requests#
Agradecemos enormemente las contribuciones en forma de pull requests (PRs). Para que el proceso de revisión sea lo más fluido posible, sigue estos pasos:
- Haz un fork del repositorio: Empieza haciendo un fork del repositorio de Ultralytics correspondiente (por ejemplo, ultralytics/ultralytics) en tu cuenta de GitHub.
- Crea una rama: Crea una nueva rama en tu repositorio bifurcado con un nombre claro y descriptivo que refleje tus cambios (por ejemplo,
fix-issue-123,add-feature-xyz). - Realiza tus cambios: Implementa tus mejoras o correcciones. Asegúrate de que tu código cumpla con las directrices de estilo del proyecto y no introduzca nuevos errores ni advertencias.
- Prueba tus cambios: Antes de enviarlos, prueba tus cambios localmente para confirmar que funcionan como se espera y no provocan regresiones. Añade tests si vas a introducir nueva funcionalidad.
- Haz un commit de tus cambios: Haz un commit de tus cambios con mensajes concisos y descriptivos. Si tus cambios solucionan un problema específico, incluye el número de la incidencia (por ejemplo,
Fix #123: Corrected calculation error.). - Crea una pull request: Envía una pull request desde tu rama a la rama
maindel repositorio original de Ultralytics. Proporciona un título claro y una descripción detallada que explique el propósito y el alcance de tus cambios.
📚 Cambios en la documentación#
El código fuente de la documentación se encuentra en docs/en/. Desde la raíz del repositorio, instala las dependencias de desarrollo y ejecuta la validación estricta completa antes de abrir un PR:
uv pip install -e ".[dev]"
python docs/build_docs.pyLa validación prepara las referencias generadas, macros y páginas de comparación antes de ejecutar zensical build --strict. Para una vista previa en directo más rápida de las páginas que no utilizan macros, ejecuta zensical serve.
📝 Firma del CLA#
Antes de que podamos fusionar tu pull request, debes firmar nuestro Contributor License Agreement (CLA). Este acuerdo legal garantiza que tus contribuciones tienen la licencia adecuada, lo que permite que el proyecto siga distribuyéndose bajo la AGPL-3.0 license.
Después de enviar tu pull request, el bot del CLA te guiará durante el proceso de firma. Para firmar el CLA, simplemente añade un comentario en tu PR indicando:
I have read the CLA Document and I sign the CLA✍️ Docstrings al estilo Google#
Al añadir nuevas funciones o clases, incluye Google-style docstrings para obtener una documentación clara y estandarizada. Encierra siempre las entradas y salidas types entre paréntesis (por ejemplo, (bool), (np.ndarray)).
Este ejemplo ilustra el formato estándar de docstring al estilo Google. Observa cómo separa claramente la descripción de la función, los argumentos, el valor de retorno y los ejemplos para lograr la máxima legibilidad.
def example_function(arg1, arg2=4):
"""Example function demonstrating Google-style docstrings.
Args:
arg1 (int): The first argument.
arg2 (int): The second argument.
Returns:
(bool): True if arguments are equal, False otherwise.
Examples:
>>> example_function(4, 4) # True
>>> example_function(1, 2) # False
"""
return arg1 == arg2✅ Pruebas de CI con GitHub Actions#
Todas las pull requests deben superar las pruebas de Continuous Integration (CI) de GitHub Actions antes de poder fusionarse. Estas pruebas incluyen el análisis de código (linting), pruebas unitarias y otras comprobaciones para garantizar que tus cambios cumplan con los estándares de calidad del proyecto. Revisa la salida de CI y soluciona cualquier problema que surja.
✨ Mejores prácticas para contribuciones de código#
Al contribuir con código a los proyectos de Ultralytics, ten en cuenta estas mejores prácticas:
- Evita la duplicación de código: Reutiliza el código existente siempre que sea posible y minimiza los argumentos innecesarios.
- Realiza cambios pequeños y específicos: Céntrate en modificaciones concretas en lugar de en cambios a gran escala.
- Simplifica siempre que puedas: Busca oportunidades para simplificar el código o eliminar partes innecesarias.
- Considera la compatibilidad: Antes de realizar cambios, valora si podrían romper el código existente que utiliza Ultralytics.
- Usa un formato coherente: Herramientas como Ruff Formatter pueden ayudarte a mantener la coherencia de estilo.
- Añade los tests adecuados: Incluye tests para las nuevas características para garantizar que funcionan como se espera.
👀 Revisión de pull requests#
Revisar pull requests es otra forma valiosa de contribuir. Al revisar PRs:
- Comprueba las pruebas unitarias: Verifica que el PR incluya pruebas para nuevas funciones o cambios.
- Revisa las actualizaciones de la documentación: Asegúrate de que la documentation está actualizada para reflejar los cambios.
- Evalúa el impacto en el rendimiento: Considera cómo los cambios pueden afectar al performance.
- Verifica los tests de la CI: Confirma que todas las Continuous Integration tests pasan correctamente.
- Proporciona comentarios constructivos: Ofrece comentarios específicos y claros sobre cualquier problema o duda.
- Reconoce el esfuerzo: Reconoce el trabajo del autor para mantener un ambiente de colaboración positivo.
🐞 Informar de errores#
Valoramos enormemente los informes de errores, ya que nos ayudan a mejorar la calidad y la fiabilidad de nuestros proyectos. Al informar de un error a través de GitHub Issues:
- Comprueba los problemas existentes: Busca primero para ver si el error ya ha sido reportado.
- Proporciona un Minimum Reproducible Example: Crea un fragmento de código pequeño y autónomo que reproduzca el problema de forma sistemática. Esto es fundamental para una depuración eficiente.
- Describe el entorno: Especifica tu sistema operativo, la versión de Python, las versiones de las librerías relevantes (por ejemplo,
torch,ultralytics) y el hardware (CPU/GPU). - Explica el comportamiento esperado frente al real: Indica claramente qué esperabas que ocurriera y qué ocurrió realmente. Incluye cualquier mensaje de error o rastro (traceback).
📜 Licencia#
Ultralytics utiliza la GNU Affero General Public License v3.0 (AGPL-3.0) para sus repositorios. Esta licencia fomenta la openness, la transparency y el collaborative improvement en el desarrollo de software. Garantiza que todos los usuarios tengan la libertad de usar, modificar y compartir el software, promoviendo una sólida comunidad de colaboración e innovación.
Animamos a todos los colaboradores a familiarizarse con los términos de la AGPL-3.0 license para contribuir de forma eficaz y ética a la comunidad de código abierto de Ultralytics.
🌍 Publicar tu proyecto YOLO bajo AGPL-3.0#
¿Vas a usar modelos o código de Ultralytics YOLO en tu proyecto? La AGPL-3.0 license exige que toda tu obra derivada también sea de código abierto bajo la licencia AGPL-3.0. Esto garantiza que las modificaciones y los proyectos más grandes construidos sobre cimientos de código abierto sigan siendo abiertos.
Por qué es importante el cumplimiento de la AGPL-3.0#
- Mantiene el software abierto: Garantiza que las mejoras y obras derivadas beneficien a la comunidad.
- Requisito legal: El uso de código con licencia AGPL-3.0 vincula tu proyecto a sus términos.
- Fomenta la colaboración: Incentiva el intercambio y la transparencia.
Si prefieres no hacer que tu proyecto sea de código abierto, valora la posibilidad de obtener una Enterprise License.
Cómo cumplir con la AGPL-3.0#
Cumplir significa poner el código fuente completo correspondiente de tu proyecto a disposición del público bajo la licencia AGPL-3.0.
-
Elige tu punto de partida:
- Haz un fork de Ultralytics YOLO: Haz un fork directo del Ultralytics YOLO repository si vas a construir tu proyecto muy cerca de él.
- Usa la plantilla de Ultralytics: Empieza con el Ultralytics template repository para obtener una configuración limpia y modular que integre YOLO.
-
Licencia tu proyecto:
- Añade un archivo
LICENSEque contenga el texto completo de la AGPL-3.0 license. - Añade un aviso en la parte superior de cada archivo de código fuente indicando la licencia.
- Añade un archivo
-
Publica tu código fuente:
- Haz que el código fuente de todo tu proyecto sea accesible públicamente (por ejemplo, en GitHub). Esto incluye:
- La aplicación o sistema completo más grande que incorpore el modelo o código YOLO.
- Cualquier modificación realizada en el código original de Ultralytics YOLO.
- Scripts para entrenamiento, validación e inferencia.
- Model weights si se han modificado o ajustado (fine-tuned).
- Configuration files, configuraciones del entorno (
requirements.txt,Dockerfiles). - Código de backend y frontend si forma parte de una web application.
- Cualquier third-party libraries que hayas modificado.
- Training data si es necesario para ejecutar/reentrenar y es redistribuible.
- Haz que el código fuente de todo tu proyecto sea accesible públicamente (por ejemplo, en GitHub). Esto incluye:
-
Documenta claramente:
- Actualiza tu
README.mdpara indicar que el proyecto cuenta con la licencia AGPL-3.0. - Incluye instrucciones claras sobre cómo configurar, compilar y ejecutar tu proyecto a partir del código fuente.
- Atribuye la autoría a Ultralytics YOLO de forma adecuada, enlazando al original repository. Ejemplo:
This project utilizes code from [Ultralytics YOLO](https://github.com/ultralytics/ultralytics), licensed under AGPL-3.0.
- Actualiza tu
Ejemplo de estructura de repositorio#
Consulta el Ultralytics Template Repository para ver una estructura de ejemplo práctica:
my-yolo-project/
│
├── LICENSE # Full AGPL-3.0 license text
├── README.md # Project description, setup, usage, license info & attribution
├── pyproject.toml # Dependencies (or requirements.txt)
├── scripts/ # Training/inference scripts
│ └── train.py
├── src/ # Your project's source code
│ ├── __init__.py
│ ├── data_loader.py
│ └── model_wrapper.py # Code interacting with YOLO
├── tests/ # Unit/integration tests
├── configs/ # YAML/JSON config files
├── docker/ # Dockerfiles, if used
│ └── Dockerfile
└── .github/ # GitHub specific files (e.g., workflows for CI)
└── workflows/
└── ci.ymlAl seguir estas directrices, garantizas el cumplimiento de la AGPL-3.0, apoyando el ecosistema de código abierto que hace posibles herramientas potentes como Ultralytics YOLO.
Conclusión#
Gracias por tu interés en contribuir a los proyectos YOLO de código abierto de Ultralytics. Tu participación es fundamental para dar forma al futuro de nuestro software y construir una comunidad dinámica de innovación y colaboración. Ya sea que estés mejorando código, informando de errores o sugiriendo nuevas características, tus contribuciones son de un valor incalculable.
Nos emociona ver cómo cobran vida tus ideas y agradecemos tu compromiso con el avance de la tecnología de object detection. Sigamos creciendo e innovando juntos en este apasionante viaje del código abierto.
FAQ#
Contribuir a los repositorios de código abierto de Ultralytics YOLO mejora el software, haciéndolo más robusto y rico en funciones para toda la comunidad. Las contribuciones pueden incluir mejoras de código, corrección de errores, mejoras en la documentación y la implementación de nuevas características. Además, contribuir te permite colaborar con otros desarrolladores expertos y especialistas en la materia, mejorando tus propias habilidades y tu reputación. Para obtener detalles sobre cómo empezar, consulta la sección Contributing via Pull Requests.
Para firmar el Acuerdo de Licencia de Contribuyente (CLA), sigue las instrucciones proporcionadas por el bot del CLA después de enviar tu pull request. Este proceso garantiza que tus contribuciones tengan la licencia adecuada bajo la licencia AGPL-3.0, manteniendo la integridad legal del proyecto de código abierto. Añade un comentario en tu pull request indicando:
I have read the CLA Document and I sign the CLAPara más información, consulta la sección CLA Signing.
Las Google-style docstrings proporcionan una documentación clara y concisa para funciones y clases, mejorando la legibilidad y el mantenimiento del código. Estas docstrings describen el propósito de la función, los argumentos y los valores devueltos con reglas de formato específicas. Al contribuir a Ultralytics YOLO, seguir Google-style docstrings garantiza que tus adiciones estén bien documentadas y se entiendan fácilmente. Para ver ejemplos y directrices, visita la sección Google-Style Docstrings.
Antes de que tu pull request pueda ser fusionada, debe superar todas las pruebas de Integración Continua (CI) de GitHub Actions. Estas pruebas incluyen análisis de código (linting), tests unitarios y otras comprobaciones para asegurar que el código cumple con los estándares de calidad del proyecto. Revisa la salida de la CI y soluciona cualquier problema. Para obtener información detallada sobre el proceso de la CI y consejos de resolución de problemas, consulta la sección GitHub Actions CI Tests.
Para informar de un error, proporciona un Minimum Reproducible Example claro y conciso junto con tu informe de error. Esto ayuda a los desarrolladores a identificar y solucionar el problema rápidamente. Asegúrate de que tu ejemplo sea mínimo pero suficiente para replicar el problema. Para obtener pasos más detallados sobre cómo informar de errores, consulta la sección Reporting Bugs.
Si utilizas código o modelos de Ultralytics YOLO (con licencia AGPL-3.0) en tu proyecto, la licencia AGPL-3.0 exige que todo tu proyecto (la obra derivada) también deba tener la licencia AGPL-3.0 y que su código fuente completo se ponga a disposición pública. Esto garantiza que la naturaleza de código abierto del software se preserve en todas sus derivadas. Si no puedes cumplir estos requisitos, debes obtener una Enterprise License. Consulta la sección Open-Sourcing Your Project para obtener más detalles.
