Esta página se ha traducido con Cloud Translation API.

El proceso RFC de TensorFlow

Cada nueva característica de TensorFlow comienza como una Solicitud de comentario (RFC).

Un RFC es un documento que describe un requisito y los cambios propuestos para solucionarlo. Específicamente, el RFC:

Estar formateado según la plantilla RFC .
Enviarse como una solicitud de extracción al directorio community/rfcs .
Estar sujeto a discusión y reunión de revisión antes de la aceptación.

El propósito de una Solicitud de comentarios (RFC) de TensorFlow es involucrar a la comunidad de TensorFlow en el desarrollo, obteniendo comentarios de partes interesadas y expertos, y comunicando ampliamente los cambios de diseño.

Cómo enviar un RFC

Antes de enviar un RFC, analice sus objetivos con los contribuyentes y mantenedores del proyecto y obtenga comentarios tempranos. Utilice la lista de correo de desarrolladores del proyecto en cuestión (developers@tensorflow.org, o la lista del SIG correspondiente).
Redacte su RFC.
- Lea los criterios de revisión del diseño.
- Siga la plantilla RFC .
- Asigne a su archivo RFC YYYYMMDD-descriptive-name.md , donde YYYYMMDD es la fecha de envío y descriptive-name se relaciona con el título de su RFC. (Por ejemplo, si su RFC se titula Parallel Widgets API , puede usar el nombre de archivo 20180531-parallel-widgets.md .
- Si tiene imágenes u otros archivos auxiliares, cree un directorio con el formato YYYYMMDD-descriptive-name en el que almacenar esos archivos.
Después de escribir el borrador del RFC, obtenga comentarios de los mantenedores y contribuyentes antes de enviarlo.
Escribir código de implementación no es un requisito, pero puede ayudar a diseñar discusiones.
Recluta un patrocinador.
- Un patrocinador debe ser un mantenedor del proyecto.
- Identificar al patrocinador en el RFC, antes de publicar el PR.
Puedes publicar un RFC sin patrocinador, pero si dentro de un mes de publicar el PR todavía no hay patrocinador, se cerrará.
Envíe su RFC como una solicitud de extracción a tensorflow/community/rfcs .
Incluye la tabla de encabezado y el contenido de la sección Objetivo en el comentario de tu solicitud de extracción, usando Markdown. Para ver un ejemplo, consulte este RFC de ejemplo . Incluya los identificadores de GitHub de coautores, revisores y patrocinadores.
En la parte superior del PR, identifique cuánto durará el período de comentarios. Esto debería ser un mínimo de dos semanas desde la publicación del PR.
Envíe un correo electrónico a la lista de correo de desarrolladores con una breve descripción, un enlace al PR y una solicitud de revisión. Sigue el formato de envíos anteriores, como puedes ver en este ejemplo .
El patrocinador solicitará una reunión del comité de revisión, no antes de dos semanas después de la publicación del RFC PR. Si la discusión es animada, espere hasta que se haya calmado antes de proceder a la revisión. El objetivo de la reunión de revisión es resolver problemas menores; Es necesario alcanzar de antemano un consenso sobre las cuestiones más importantes.
La reunión puede aprobar el RFC, rechazarlo o requerir cambios antes de que pueda ser considerado nuevamente. Los RFC aprobados se fusionarán en community/rfcs y los RFC rechazados tendrán sus RP cerrados.

participantes del RFC

Muchas personas participan en el proceso RFC:

Autor de RFC : uno o más miembros de la comunidad que escriben un RFC y se comprometen a defenderlo durante el proceso.
Patrocinador del RFC : un mantenedor que patrocina el RFC y lo guiará a través del proceso de revisión del RFC.
Comité de revisión : grupo de mantenedores que tienen la responsabilidad de recomendar la adopción del RFC.
Cualquier miembro de la comunidad puede ayudar proporcionando comentarios sobre si el RFC satisfará sus necesidades.

Patrocinadores del RFC

Un patrocinador es un mantenedor del proyecto responsable de garantizar el mejor resultado posible del proceso RFC. Esto incluye:

Abogar por el diseño propuesto.
Orientar al RFC para que se adhiera a las convenciones de diseño y estilo existentes.
Guiar al comité de revisión para llegar a un consenso productivo.
Si el comité de revisión solicita cambios, asegúrese de que se realicen y solicite la aprobación posterior de los miembros del comité.
Si el RFC pasa a la implementación:
- Garantizar que la implementación propuesta se adhiera al diseño.
- Coordinar con las partes apropiadas para una implementación exitosa de la tierra.

Comités de revisión de RFC

El comité de revisión decide por consenso si aprueba, rechaza o solicita cambios. Son responsables de:

Garantizar que se hayan tenido en cuenta los elementos sustanciales de la retroalimentación pública.
Agregar sus notas de la reunión como comentarios al RP.
Proporcionando razones para sus decisiones.

La constitución de un comité de revisión puede cambiar según el estilo particular de gobernanza y liderazgo de cada proyecto. Para TensorFlow principal, el comité estará formado por contribuyentes al proyecto TensorFlow que tengan experiencia en el área de dominio en cuestión.

Los miembros de la comunidad y el proceso RFC

El propósito de los RFC es garantizar que la comunidad esté bien representada y atendida por los nuevos cambios en TensorFlow. Es responsabilidad de los miembros de la comunidad participar en la revisión de los RFC cuando tengan interés en el resultado.

Los miembros de la comunidad que estén interesados en un RFC deben:

Proporcione comentarios lo antes posible para permitir el tiempo adecuado para su consideración.
Lea detenidamente los RFC antes de enviar comentarios.
Sea civilizado y constructivo .

Implementando nuevas características

Una vez que se ha aprobado un RFC, puede comenzar la implementación.

Si está trabajando en un código nuevo para implementar un RFC:

Asegúrese de comprender la característica y el diseño aprobados en el RFC. Haga preguntas y analice el enfoque antes de comenzar a trabajar.
Las nuevas funciones deben incluir nuevas pruebas unitarias que verifiquen que la función funciona como se esperaba. Es una buena idea escribir estas pruebas antes de escribir el código.
Siga la guía de estilo del código TensorFlow
Agregue o actualice la documentación API relevante. Haga referencia al RFC en la nueva documentación.
Siga cualquier otra guía establecida en el archivo CONTRIBUTING.md en el repositorio del proyecto al que está contribuyendo.
Ejecute pruebas unitarias antes de enviar su código.
Trabaje con el patrocinador de RFC para obtener con éxito el nuevo código.

Manteniendo el listón alto

Si bien alentamos y celebramos a todos los contribuyentes, el listón para la aceptación del RFC se mantiene intencionalmente alto. Una nueva característica puede ser rechazada o necesitar una revisión importante en cualquiera de estas etapas:

Conversaciones iniciales de diseño en la lista de correo relevante.
No conseguir un patrocinador.
Objeciones críticas durante la fase de retroalimentación.
No lograr consenso durante la revisión del diseño.
Preocupaciones planteadas durante la implementación (por ejemplo: incapacidad para lograr compatibilidad con versiones anteriores, preocupaciones sobre el mantenimiento).

Si este proceso funciona bien, se espera que los RFC fallen en las primeras etapas, no en las posteriores. Un RFC aprobado no es garantía de un compromiso de implementación, y la aceptación de una implementación RFC propuesta aún está sujeta al proceso habitual de revisión del código.

Si tiene alguna pregunta sobre este proceso, no dude en preguntar en la lista de correo de desarrolladores o presentar un problema en tensorflow/community .