Contribución a los proyectos de código abierto Ultralytics

Le damos la bienvenida. Estamos encantados de que esté pensando en contribuir a nuestro proyecto Ultralytics de código abierto. Su participación no sólo 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 las mejores prácticas para ayudarle a empezar.

Observa: Cómo contribuir al repositorio de Ultralytics | Modelos, conjuntos de datos y documentación Ultralytics 🚀

🤝 Código de conducta

Para garantizar un entorno acogedor e integrador para todos, todos los colaboradores deben cumplir nuestro Código de Conducta. El respeto, la amabilidad y la profesionalidad están en el corazón 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, siga estos pasos:

1. Crear el repositorio: Comience por bifurcar el repositorio de Ultralytics correspondiente (por ejemplo, ultralytics) en su cuenta de GitHub.
2. Crea una rama: Cree una nueva rama en su repositorio bifurcado con un nombre claro y descriptivo que refleje sus cambios (por ejemplo, fix-issue-123, add-feature-xyz).
3. Haga sus cambios: Implementa tus mejoras o correcciones. Asegúrate de que tu código cumple las directrices de estilo del proyecto y no introduce nuevos errores o advertencias.
4. Pruebe los cambios: Antes de enviar los cambios, pruébalos localmente para confirmar que funcionan como se espera y no causan regresiones. Añade pruebas si introduces nuevas funciones.
5. Confirme los cambios: Confirma tus cambios con mensajes de confirmación concisos y descriptivos. Si sus cambios se refieren a un problema específico, incluya el número de problema (por ejemplo, Fix #123: Corrected calculation error.).
6. Crear un pull request: Envíe una solicitud de pull desde su rama a main del repositorio original Ultralytics . Proporcione un título claro y una descripción detallada que explique el propósito y el alcance de sus cambios.

📝 Firma de CLA

Antes de que podamos fusionar su pull request, debe firmar nuestro Acuerdo de Licencia de Colaborador (CLA). Este acuerdo legal garantiza que sus contribuciones están debidamente licenciadas, lo que permite que el proyecto siga distribuyéndose bajo la licenciaAGPL-3.0 .

Después de enviar su pull request, el bot CLA le guiará a través del proceso de firma. Para firmar el CLA, simplemente añada un comentario en su PR indicando:

I have read the CLA Document and I sign the CLA

✍️ Docstrings Google

Al añadir nuevas funciones o clases, incluya Docstrings Google para una documentación clara y estandarizada. Incluya siempre tanto la entrada como la salida types entre paréntesis (p. ej, (bool), (np.ndarray)).

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

def example_function(arg1, arg2=4):
    """
    Example function demonstrating Google-style docstrings.

    Args:
        arg1 (int): The first argument.
        arg2 (int): The second argument.

    Returns:
        equals (bool): True if arguments are equal, False otherwise.

    Examples:
        >>> example_function(4, 4)  # True
    """
    equals = arg1 == arg2
    return equals

def example_function(arg1, arg2=4):
    """
    Example function demonstrating Google-style docstrings.

    Args:
        arg1 (int): The first argument.
        arg2 (int): The second argument.

    Returns:
        equals (bool): True if arguments are equal, False otherwise.
        added (int): Sum of both input arguments.

    Examples:
        >>> equals, added = example_function(2, 2)  # True, 4
    """
    equals = arg1 == arg2
    added = arg1 + arg2
    return equals, added

Returns:
   (np.ndarray): Predicted masks with shape HxWxN.
   (list): Confidence scores for each instance.

Returns:
   (tuple): Tuple containing:
       - (np.ndarray): Predicted masks with shape HxWxN.
       - (list): Confidence scores for each instance.

def example_function(arg1: int, arg2: int = 4) -> bool:
    """
    Example function demonstrating Google-style docstrings.

    Args:
        arg1: The first argument.
        arg2: The second argument.

    Returns:
        True if arguments are equal, False otherwise.

    Examples:
        >>> example_function(1, 1)  # True
    """
    return arg1 == arg2

def example_small_function(arg1: int, arg2: int = 4) -> bool:
    """Example function with a single-line docstring."""
    return arg1 == arg2

✅ Pruebas de CI de las acciones de GitHub

Todas las pull requests deben pasar las pruebas de Integración Continua (IC) de las Acciones de GitHub antes de ser fusionadas. Estas pruebas incluyen linting, pruebas unitarias y otras comprobaciones para asegurar que tus cambios cumplen los estándares de calidad del proyecto. Revise los resultados de la integración continua y solucione los problemas que surjan.

✨ Buenas prácticas para las contribuciones de código

Cuando contribuya con código a los proyectos Ultralytics , tenga en cuenta estas prácticas recomendadas:

• Evite la duplicación de código: Reutiliza el código existente siempre que sea posible y minimiza los argumentos innecesarios.
• Realice cambios más pequeños y específicos: Céntrese en modificaciones específicas en lugar de cambios a gran escala.
• Simplifique cuando sea posible: Busca oportunidades para simplificar el código o eliminar partes innecesarias.
• Considere la compatibilidad: Antes de realizar cambios, considere si podrían romper el código existente que utiliza Ultralytics.
• Utiliza un formato coherente: Herramientas como Ruff Formatter pueden ayudar a mantener la coherencia estilística.
• Añada las pruebas adecuadas: Incluye pruebas de las nuevas funciones para asegurarte de que funcionan como se espera.

👀 Revisión de Pull Requests

Revisar pull requests es otra forma valiosa de contribuir. Cuando revises PRs:

• Compruebe si hay pruebas unitarias: Verifica que el PR incluye pruebas para las nuevas características o cambios.
• Revisar las actualizaciones de la documentación: Asegurarse de que la documentación se actualiza para reflejar los cambios.
• Evalúe el impacto en el rendimiento: Considera cómo pueden afectar los cambios al rendimiento.
• Verifique las pruebas de integración continua: Confirme que todas las pruebas de integración continua están pasando.
• Proporcione comentarios constructivos: Ofrezca información clara y concreta sobre cualquier problema o preocupación.
• Reconocer el esfuerzo: Reconozca el trabajo del autor para mantener una atmósfera de colaboración positiva.

🐞 Informar de errores

Valoramos mucho los informes de errores, ya que nos ayudan a mejorar la calidad y fiabilidad de nuestros proyectos. Al informar de un error a través de GitHub Issues:

• Comprueba los problemas existentes: Busca primero para ver si ya se ha informado del fallo.
• Proporcione un ejemplo mínimo reproducible: Cree un pequeño fragmento de código autocontenido que reproduzca el problema de forma coherente. Esto es crucial para una depuración eficaz.
• Describe el entorno: Especifique su sistema operativo, la versión de Python , las versiones de las bibliotecas pertinentes (por ejemplo, torch, ultralytics), y hardware (CPU/GPU).
• Explique el comportamiento esperado frente al real: Explica claramente lo que esperabas que ocurriera y lo que ocurrió en realidad. Incluye cualquier mensaje de error o rastreo.

Licencia 📜

Ultralytics utiliza la Licencia Pública General Affero GNU v3.0 (AGPL-3.0) para sus repositorios. Esta licencia promueve la apertura, la transparencia y la mejora colaborativa en el desarrollo de software. Garantiza que todos los usuarios tengan la libertad de utilizar, modificar y compartir el software, fomentando una sólida comunidad de colaboración e innovación.

Animamos a todos los colaboradores a familiarizarse con los términos de la licenciaAGPL-3.0 para contribuir de forma eficaz y ética a la comunidad de código abierto Ultralytics .

🌍 Open-Sourcing de su proyecto YOLO bajo AGPL-3.0

¿Utiliza modelos o códigoYOLO Ultralytics en su proyecto? La licencia AGPL-3.0 exige que todo su trabajo derivado sea también de código abierto bajo AGPL-3.0. De este modo se garantiza que las modificaciones y los proyectos de mayor envergadura construidos sobre bases de código abierto permanezcan abiertos.

Por qué es importante cumplir AGPL-3.0

• Mantiene el software abierto: Garantiza que las mejoras y los trabajos derivados beneficien a la comunidad.
• Requisito legal: El uso de código con licencia AGPL-3.0 vincula su proyecto a sus términos.
• Fomenta la colaboración: Fomenta el intercambio y la transparencia.

Si prefiere que su proyecto no sea de código abierto, considere la posibilidad de obtener una licencia de empresa.

Cómo cumplir la AGPL-3.0

Cumplirlo significa poner a disposición del público el código fuente completo correspondiente de su proyecto bajo la licencia AGPL-3.0 .

1. Elija su punto de partida:

   • Fork Ultralytics YOLO: Fork directo del repositorioUltralytics YOLO si se construye sobre él.
   • Utilice la plantilla Ultralytics : Comience con el repositorio de plantillas de Ultralytics para obtener una configuración limpia y modular que integre YOLO.

2. Licencia para su proyecto:

   • Añadir un LICENSE que contiene el texto completo del Licencia AGPL-3.0.
   • Añada un aviso en la parte superior de cada archivo fuente indicando la licencia.

3. Publique su código fuente:

   • Haga su todo el código fuente del proyecto de acceso público (por ejemplo, en GitHub). Esto incluye:
     • La aplicación o sistema completo más grande que incorpora el modelo o código YOLO .
     • Cualquier modificación realizada en el código original Ultralytics YOLO .
     • Scripts de entrenamiento, validación e inferencia.
     • Ponderación de los modelos si se modifican o afinan.
     • Archivos de configuraciónconfiguración del entorno (requirements.txt, Dockerfiles).
     • Código backend y frontend si forma parte de una aplicación web.
     • Cualquier librería de terceros que hayas modificado.
     • Datos de entrenamiento si son necesarios para ejecutar/reentrenar y redistribuibles.

4. Documente con claridad:

   • Actualice su README.md para indicar que el proyecto tiene una licencia AGPL-3.0.
   • Incluya instrucciones claras sobre cómo configurar, construir y ejecutar su proyecto a partir del código fuente.
   • Atribuya Ultralytics YOLO adecuadamente, enlazando de nuevo con el repositorio original. Ejemplo:

     This project utilizes code from [Ultralytics YOLO](https://github.com/ultralytics/ultralytics), licensed under AGPL-3.0.
     

Ejemplo de estructura de un repositorio

Consulte el repositorio de plantillas deUltralytics para ver un ejemplo práctico de estructura:

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

Siguiendo estas directrices, se asegura el cumplimiento de AGPL-3.0, apoyando el ecosistema de código abierto que permite potentes herramientas como Ultralytics YOLO.

🎉 Conclusión

Gracias por su interés en contribuir a Ultralytics proyectos de código abierto de YOLO . Su participación es esencial para dar forma al futuro de nuestro software y construir una vibrante comunidad de innovación y colaboración. Ya sea mejorando el código, informando de errores o sugiriendo nuevas funciones, sus contribuciones son inestimables.

Nos entusiasma ver cómo sus ideas cobran vida y apreciamos su compromiso con el avance de la tecnología de detección de objetos. Juntos, sigamos creciendo e innovando en este apasionante viaje de código abierto. ¡Feliz programación! 🚀🌟

PREGUNTAS FRECUENTES

¿Por qué debería contribuir a los repositorios de código abierto de Ultralytics YOLO ?

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 del código, correcciones de errores, mejoras de la documentación e implementaciones de nuevas funciones. Además, contribuir le permite colaborar con otros desarrolladores cualificados y expertos en la materia, mejorando sus propias habilidades y reputación. Para más información sobre cómo empezar, consulte la sección Contribuir mediante Pull Requests.

¿Cómo firmo el Acuerdo de Licencia de Contribuidor (CLA) para Ultralytics YOLO ?

Para firmar el Acuerdo de Licencia de Contribuidor (CLA), siga las instrucciones proporcionadas por el bot CLA después de enviar su pull request. Este proceso garantiza que sus contribuciones están debidamente licenciadas bajo la licencia AGPL-3.0 , manteniendo la integridad legal del proyecto de código abierto. Añada un comentario en su pull request indicando:

I have read the CLA Document and I sign the CLA

Para más información, consulte la sección Firma CLA.

¿Qué son los docstrings de estilo Google y por qué son necesarios para las contribuciones a Ultralytics YOLO ?

Google-proporcionan documentación clara y concisa para funciones y clases, mejorando la legibilidad y el mantenimiento del código. Estos docstrings describen el propósito de la función, los argumentos y los valores de retorno con reglas de formato específicas. Cuando contribuya a Ultralytics YOLO , siga el estilo de documentación de Google y se asegurará de que sus aportaciones estén bien documentadas y sean fáciles de entender. Para ver ejemplos y directrices, visite la sección Google-Style Docstrings.

¿Cómo puedo asegurarme de que mis cambios superan las pruebas de GitHub Actions CI?

Antes de que tu pull request pueda fusionarse, debe superar todas las pruebas de Integración Continua (IC) de las Acciones de GitHub. Estas pruebas incluyen linting, pruebas unitarias y otras comprobaciones para asegurar que el código cumple con los estándares de calidad del proyecto. Revise el resultado de la integración continua y corrija cualquier problema. Para obtener información detallada sobre el proceso de CI y consejos para la solución de problemas, consulte la sección Pruebas de CI de GitHub Actions.

¿Cómo puedo informar de un error en los repositorios de Ultralytics YOLO ?

Para informar de un fallo, proporcione un Ejemplo Mínimo Reproducible claro y conciso junto con su informe de fallo. Esto ayuda a los desarrolladores a identificar y solucionar rápidamente el problema. Asegúrese de que su ejemplo es mínimo pero suficiente para reproducir el problema. Para obtener información más detallada sobre la notificación de errores, consulte la sección Notificación de errores.

¿Qué significa la licencia AGPL-3.0 0 si utilizo Ultralytics YOLO en mi propio proyecto?

Si utiliza el código o los modelos Ultralytics YOLO (con licencia AGPL-3.0) en su proyecto, la licencia AGPL-3.0 exige que todo su proyecto (la obra derivada) también tenga licencia AGPL-3.0 y que su código fuente completo se ponga a disposición del público. De este modo se garantiza que la naturaleza de código abierto del software se mantenga en todos sus derivados. Si no puede cumplir estos requisitos, deberá obtener una licencia de empresa. Consulte la sección Open-Sourcing de su proyecto para más detalles.

Creado hace 1 año ✏️ Actualizado hace 1 mes

Comentarios