Título (lee el source code del markdown para ver los comentarios)
Autores:
1 TL;DR
<!--
párrafo corto que explica qué estas proponiendo
-->
2 Motivación
<!--
¿qué motiva esta decisión y por qué es importante?
el propósito de esta sección es articular de una manera sencilla el valor de la decision que vamos a tomar
-->
3 Propuesta de implementación
<!--
Este es el núcleo de tu propuesta, y su proposito es ayudarte a pensar en la solución. Esto debe ser un wireframe, no un documento perfecto con todos los detalles.
Escribir es pensar https://medium.learningbyshipping.com/writing-is-thinking-an-annotated-twitter-thread-2a75fe07fade
- usa diagramas para ilustrat tus ideas o flujos
- inluye ejemplos de código si estas proponiendo una interfaz o contrato de sistemsa nuevo
- agrega links con las especificaciones de proyectos
El proposito de esta sección se resume en:
"Esta es la dirección en la que nos voy a llevar, alguién ve huecos en mi propuesta o tiene comentarios sobre cómo mejorarla?
-->
4 Métricas
<!--
Que métricas debemos vamos a instrumentar, o monitorear para observar las implicaciónes de esta decisiòn?
Por ejemplo, cuando interactuamos con un sistema externo que tipo de latencia esperariamos o si agregamos una tabla nueva que tan rápido se llenaría?
-->
5 Riesgos e inconvenientes
<!--
¿Hay razones por las que no deberiamos hacer esto?
¿Qué riesgos estamos tomando? Por ejemplo, no tenemos experiencia con esta tecnología nueva o no entendemos la escala aún.
-->
6 Alternativas
<!--
¿Hay otras formas de resolver éste problema?
-->
7 Impacto potencial y dependencias
<!--
¿Qué otros sistemas se verán afectados con esta propuesta?
¿Qué consideraciones de seguridad debemos tener?¿Como pueden explotar esta parte del sistema?
¿Que impacto tiene esta decision sobre soporte al cliente?
Aquí buscamos ser concientes del ambiente en el que operamos y generar empatía hacia otros que pueden verse afectados por nuestra decisión.
-->
8 Preguntas sin resolver
<!--
¿ Qué preguntas no hemos resuelto?
-->
9 Conclusión
10 El proceso (elimina esta sección)
<!--
Al escribir un RFC, estas incluyendo al equipo en la dirección que estas tomando. En muchos casos puede haber multiples soluciones, y tambien opiniones diferentes sobre como atacar un problema. Es posible que en el futuro esta propuesta no sea la mejor solución posible, pero aprenderemos de ella.
Como proponente, estas tomando responsabilidad sobre la dirección que quieres tomar y con este documento buscas que tus otros miembros de nuestro equipo contribuyan con sus comentarios acerca de tu idea, pero ultimamente esta decision es tuya y te apoyamos.
En resumen, este documento es:
- un ejercicio de pensamiento, prototipamos con palabras
- un record historico, y su valor puede disminuir con el tiempo
- un mecanismo para
- una forma de transmitir información
- un mecanismo para construir confianza
- una herramienta de empoderamiento
- un canal de comunicación
Este documento no es
- una solucitud de permiso
- un documento que requiere aprobación
- la representación actual de nuestros sistemas o procesos
-->
Recomendaciones
- Utiliza la etiqueta [WIP] si aún estas refinando detalles
- Utiliza la etiqueta [newbie] si tienes una propuesta en la que tienes poca confianza por tu conocimiento actual
- Si hay areas específicas en las que quieres atencion, etiqueta a personas que consideras que saben algo al respecto y preguntales directamente. "María, impacto crees que va a tener este API sobre tu base de datos?"
- Si tienes dudas, pídele ayuda a tu manager o lider de tecnología
- Es tu decisión
- Ten en cuenta la prioridad de las propuestas que estas haciendo, los RFC no son documentos para proponer rearquitecturas o proyectos "cool" que no se alinean con los objetivos a corto plazo de la empresa