Nombre de la Funcionalidad: (rellénalo con un identificador único, mi_funcionalidad_asombrosa)
Fecha de Inicio: (rellénalo con la fecha de hoy, YYYY-MM-DD)
Propietarios nominados: (Representantes de las áreas técnicas afectadas por el RFC. A menudo serán líderes técnicos, pero pueden delegar. Los RFC no pueden ser aceptados hasta que todos los propietarios nominados hayan dado su aprobación.)
Explicación en un párrafo de la funcionalidad.
Esta sección es esencial para permitirnos aprender de las cosas que estamos implementando.
¿Cuándo es la retrospectiva?
[ ] ¿Retro completada?
(¿dónde/cómo se llevará a cabo, cómo pueden las personas involucrarse, dónde están los resultados?)
¿Por qué estamos haciendo esto? ¿Qué casos de uso soporta? ¿Cuál es el resultado esperado?
Explica la propuesta como si ya existiera y la estuvieras enseñando a otro ingeniero. Eso generalmente significa:
Introducir nuevos conceptos nombrados.
Explicar la funcionalidad en gran medida en términos de ejemplos.
Explicar cómo los ingenieros deben pensar sobre la funcionalidad. Debe explicar el impacto lo más concretamente posible.
Si aplica (por ejemplo, propuesta de código/arquitectura), proporcionar mensajes de error de muestra, advertencias de desaprobación o guía de migración.
Si aplica, describir las diferencias entre enseñar esto a ingenieros existentes y nuevos ingenieros.
Para los RFC orientados a la implementación, esta sección debe centrarse en cómo los contribuyentes deben pensar sobre el cambio y dar ejemplos de su impacto concreto. Para los RFC de políticas/procesos, esta sección debe proporcionar una introducción basada en ejemplos a la política/proceso y explicar su impacto en términos concretos.
Esta es la parte técnica del RFC. Explica el diseño con suficiente detalle para que:
Su interacción con otras funcionalidades sea clara.
Sea razonablemente claro cómo se implementaría la funcionalidad.
Los casos extremos sean disecados por ejemplo.
La sección debe volver a los ejemplos dados en la sección anterior y explicar más completamente cómo la propuesta detallada hace que esos ejemplos funcionen.
¿Por qué no deberíamos hacer esto?
¿Por qué este diseño es el mejor en el espacio de posibles diseños?
¿Qué otros diseños se han considerado y cuál es la razón para no elegirlos?
¿Cuál es el impacto de no hacer esto?
Discute el arte previo, tanto lo bueno como lo malo, en relación con esta propuesta. Algunos ejemplos de lo que esto puede incluir son:
Para lenguaje, librería, herramientas, etc.: ¿Existe esta funcionalidad en otros lugares y qué experiencia ha tenido su comunidad?
Para propuestas comunitarias: ¿Esto lo hace alguna otra comunidad y cuáles fueron sus experiencias con ello?
Para otros equipos: ¿Qué lecciones podemos aprender de lo que otras comunidades han hecho aquí?
Artículos: ¿Hay algún artículo publicado o publicaciones destacadas que discutan esto? Si tienes algunos artículos relevantes a los que referirte, esto puede servir como un trasfondo teórico más detallado.
Esta sección está destinada a alentarte como autor a pensar en las lecciones de otros lugares, proporcionar a los lectores de tu RFC una imagen más completa. Si no hay arte previo, está bien - tus ideas nos interesan ya sean completamente nuevas o una adaptación de otros lugares.
¿Qué partes del diseño esperas resolver a través del proceso de RFC antes de que esto se fusione?
¿Qué partes del diseño esperas resolver a través de la implementación de esta funcionalidad antes de la estabilización?
¿Qué problemas relacionados consideras fuera del alcance de este RFC que podrían abordarse en el futuro independientemente de la solución que surja de este RFC?
Piensa en cuál sería la extensión y evolución natural de tu propuesta y cómo afectaría a los equipos y proyectos en su conjunto de manera holística. Trata de usar esta sección como una herramienta para considerar más plenamente todas las posibles interacciones con el proyecto y los equipos en tu propuesta. También considera cómo encaja todo esto en la hoja de ruta del proyecto y del sub-equipo relevante. Esta también es un buen lugar para "volcar ideas", si están fuera del alcance del RFC que estás escribiendo pero de otro modo relacionadas. Si has intentado y no puedes pensar en ninguna posibilidad futura, simplemente puedes decir que no puedes pensar en nada. Ten en cuenta que tener algo escrito en la sección de posibilidades futuras no es una razón para aceptar el RFC actual o futuro; tales notas deben estar en la sección de motivación o razonamiento en este o en RFCs posteriores. La sección simplemente proporciona información adicional.