Todos pueden contribuir con OpenXLA y valoramos las contribuciones de todos. Existen varias formas de contribuir, como las siguientes:
Respuestas a preguntas en foros de debate de OpenXLA (openxla-discuss)
Mejora o expansión de la documentación de OpenXLA
Contribución a la base de código de OpenXLA
Contribuir de cualquiera de las formas anteriores al ecosistema más amplio de bibliotecas compiladas en OpenXLA
El proyecto OpenXLA sigue los Lineamientos de la Comunidad de código abierto de Google.
Antes de comenzar
Firma el Contrato de Licencia para Colaboradores
Las contribuciones a este proyecto deben estar acompañadas por un Contrato de Licencia para Colaboradores (CLA). Tú o tu empleador retienen los derechos de autor de la contribución; esto simplemente nos da permiso para usar y redistribuir tus contribuciones como parte del proyecto.
Si tú o tu empleador actual ya firmaron el CLC de Google (incluso si era para otro proyecto), es probable que no tengas que volver a hacerlo.
Visita <https://cla.developers.google.com/> para ver tus acuerdos actuales o firmar uno nuevo.
Revisar el Código de Conducta
Este proyecto sigue el Código de Conducta de TensorFlow.
Proceso de contribución
Guía para desarrolladores
Para ver una guía sobre cómo configurar un entorno de desarrollo para OpenXLA, incluido cómo obtener un código, compilarlo, ejecutar pruebas y enviar cambios, consulta la Guía para desarrolladores.
Estándares de código
Estilo de codificación: Seguimos la guía de estilo de código de Google. Consulta específicamente las guías de C/C++ y Python. Todo el código que envíes debe cumplir estrictamente con estas guías de estilo.
Cambios compactos: Seguimos las prácticas de ingeniería de Google. En particular, consulta la guía sobre cómo escribir cambios compactos. Si lo haces, aumentarás en gran medida la velocidad a la que puedes combinar tu código, ya que mejorará la capacidad de revisión y reducirá la probabilidad de que se produzcan efectos secundarios no intencionales. Incluso si tienes un cambio grande, hay muchas estrategias para dividirlo en cambios más incrementales.
Cobertura de pruebas: Todos los cambios deben incluir pruebas de unidades adecuadas. Las pruebas de unidades no deben depender de los tiempos específicos de hardware (CPU, GPU, etc.), y deben hacer un uso copioso de simulaciones y simulaciones para realizar pruebas deterministas y enfocadas. Los cambios que buscan extender el código existente que actualmente son difíciles de probar deberían implementar mejoras adecuadas en la capacidad de prueba.
Todos los cambios deben incluir los resultados comparativos adecuados, así como en el título del cambio, para garantizar que se entiendan los beneficios con claridad.
Si tienes dudas respecto de las convenciones del código, siempre es una buena idea examinar el código preexistente y tratar de seguir los patrones que ya se implementaron en OpenXLA.
Revisión del proceso
Todas las entregas, incluidas las de los miembros del proyecto, requieren revisión. Para ello, usamos solicitudes de extracción de GitHub. Consulta la Ayuda de GitHub para obtener más información sobre el uso de solicitudes de extracción.
El código debe seguir todos los estándares mencionados anteriormente antes de su revisión. Estos no son opcionales y es fundamental que el remitente se asegure de que su código se ajuste antes de solicitar una revisión para garantizar la aceptación oportuna de los cambios.
Se deben aprobar todas las pruebas. Si una prueba falla y el problema no está relacionado con tu entorno de compilación ni con tus cambios, comunícate con los encargados de mantenimiento.
Intenta evitar la corrupción del alcance durante el proceso de revisión. Esta es responsabilidad del remitente y del revisor. Si un cambio comienza a ser demasiado grande, considera dividirlo en varios cambios.
Antes de combinar un cambio, este se someterá a pruebas internas que usan código interno de Google y otros proveedores de hardware. Esto puede agregar pasos adicionales al proceso de revisión si hay fallas en las pruebas internas que nuestra CI pública no detecta. El Googler que revise el cambio comunicará cualquier falla en la prueba interna y describirá lo que debe corregirse.
Preguntas frecuentes
"Este cambio de infraestructura no está relacionado con mi RR.PP. ¿Por qué debería hacerlo?"
El equipo de XLA no tiene un equipo de infraestructura dedicado, por lo que depende de nosotros compilar bibliotecas auxiliares y evitar deudas técnicas. Consideramos que es una parte habitual de los cambios en XLA y se espera que todos participen. Por lo general, compilamos infraestructura según sea necesario cuando escribimos código.
Es posible que los revisores de XLA te pidan que crees infraestructura (o que hagas un gran cambio en una RR.PP.) junto con una RR.PP. que hayas redactado. Esta solicitud puede parecer innecesaria u ortogonal para el cambio que intentas realizar. Es probable que esto se deba a una discrepancia entre tus expectativas sobre la infraestructura que debes compilar y las expectativas del revisor al respecto.
No hay problema con las expectativas. Esto es normal cuando eres nuevo en un proyecto (y a veces nos pasa incluso a nosotros). Es probable que los proyectos en los que trabajaste en el pasado tengan expectativas diferentes. ¡Eso también está bien y eso también está bien y es lo que se espera! No significa que ninguno de estos proyectos tenga un enfoque equivocado; son diferentes. Te invitamos a participar en las solicitudes de infraestructura junto con todos los demás comentarios de revisión como una oportunidad para saber qué esperamos de este proyecto.
"¿Puedo abordar tu comentario en una reunión de comunicado de prensa en el futuro?"
Una pregunta frecuente con respecto a las solicitudes de infraestructura (o alguna otra gran solicitud) en las solicitudes de PR es si el cambio se debe realizar o no en la solicitud de extracción original o si se puede hacer a modo de seguimiento en una solicitud de publicación futura.
En general, XLA no permite que los autores de relaciones públicas se encarguen de los comentarios de las opiniones con una solicitud de extracción de seguimiento. Cuando un revisor decide que algo debe abordarse en una RR.PP. determinada, por lo general, esperamos que los autores lo aborden en esa RR.PP., incluso si lo que se solicita es un cambio grande. Este estándar se aplica de manera externa y también interna en Google.
Hay varias razones por las que XLA adopta este enfoque.
Confianza: Ganarse la confianza del revisor es un componente clave. En un proyecto de código abierto, los colaboradores pueden aparecer u desaparecer cuando lo deseen. Después de que aprobamos una RR.PP., los revisores no tienen forma de garantizar que se realicen los seguimientos prometidos.
Impacto en otros desarrolladores: Si enviaste una solicitud de extracción que toca una parte en particular de XLA, es muy probable que otras personas estén considerando la misma parte. Si aceptamos una deuda técnica en tu solicitud de Relaciones Públicas, entonces todos los que estén revisando este archivo se verán afectados por esta deuda hasta que se envíe el seguimiento.
Ancho de banda del revisor: Aplazar un cambio en un seguimiento implica varios costos a nuestros revisores ya sobrecargados. Es probable que los revisores se olviden de qué se trataba la primera RR.PP. mientras esperan el seguimiento, lo que dificulta la próxima revisión. Además, los revisores deberán realizar un seguimiento de los seguimientos esperados para asegurarse de que realmente sucedan. Si el cambio se puede realizar de modo que sea realmente independiente de la RR.PP. original de modo que otro revisor pueda revisarlo, el ancho de banda sería menos un problema. Según nuestra experiencia, rara vez es el caso.