Las solicitudes de extracción son como la sangre de un repositorio. Mantienen todo en buen estado y en movimiento. En esta página, se detalla cómo crear una solicitud de extracción que esté completa y sea fácil de revisar, lo que aumenta las probabilidades de que se combine una solicitud de extracción.
Aquí hay algunas medidas que puedes tomar para asegurarte de crear el mejor RR.PP. posible.
- Cómo comunicarte
- Prepárate
- Que sea pequeño
- Mantén la limpieza
- Prueba tu cambio
- Comunicación (parte 2)
Comunícate
Antes de empezar a escribir código, es útil que te comuniques con el equipo central para que sepan lo que te interesa.
Si hay un problema que te interesa, déjalo como comentario para decir que comenzarás a trabajar en él. Esto nos asegura que no tengamos varias personas trabajando en lo mismo. Un miembro del equipo confirmará que es tuyo.
Si tienes una idea que no está cubierta por un problema, redacta una antes de comenzar a trabajar. Esto le brinda al equipo la oportunidad de analizar cuál es la mejor manera de compilar el cambio antes de comenzar a compilar, lo que ahorra trabajo a largo plazo.
Prepárate
Si es la primera vez que contribuyes a las muestras de Blockly o Blockly, comienza en la página de configuración de desarrollo.
Mantenlo pequeño
Siempre intenta que los cambios sean pequeños y estén enfocados. Preferimos revisar varios PR más pequeños que uno gigante. Algunas buenas reglas generales son:
- Soluciona un problema. No intentes abordar varios problemas a la vez.
- Limita el alcance. Por lo general, una solicitud de extracción debería tardar menos de 8 horas (según el nivel de familiaridad con la base de código).
- Usa confirmaciones. Si crees que tu solicitud de extracción es un poco grande, divide los cambios en grupos lógicos con confirmaciones de Git.
Limpieza
¿Por qué es importante el estilo de código? Estamos de acuerdo a largo plazo, y el estilo coherente facilita el mantenimiento. El estilo se refiere a la forma en que nombras las variables, pero también abarca la estructura del código y la escritura de comentarios, entre otros aspectos. Siempre que sea posible, utilizamos herramientas como Eslint para automatizar las verificaciones de diseño.
Además de usar el eslint, sigue estas guías:
- Guía de estilo de JavaScript de Google
- Guía de mensajes de confirmación
- Lineamientos sobre el uso de las APIs de Blockly
- Guía de estilo del codelab
Prueba tu cambio
Antes de crear una solicitud de extracción, siempre debes probar que tus cambios funcionen, de modo que no tengas que volver y arreglar cosas más tarde. Aquí hay algunas ideas para probar las diferentes categorías de proyectos:
- En el caso de los complementos, escribe pruebas de Mocha automatizadas que abarquen los cambios.
- Para obtener ejemplos, prueba manualmente todas las funciones demostradas.
- En los codelabs, ejecuta todo el instructivo en un entorno limpio y prueba cualquier código de ejemplo que proporciones.
Comunícate
Esta es la última parte (y probablemente la más importante) de crear un PR: escribir el resumen.
Escribir un excelente resumen de relaciones públicas ayuda a otros desarrolladores a revisar los cambios, lo que aumenta las probabilidades de que se los acepte más rápido.
El resumen debe incluir, por ejemplo, lo siguiente:
- ¿Con qué problema se relaciona tu RR. PP.?
- ¿Qué cambio implica tu comunicado de prensa?
- Cómo probaste el cambio
- Cualquier cosa que quieras que los revisores analicen.
- Cualquier otra información que creas que necesitan los revisores
Si sigues la plantilla de PR cuando creas tu solicitud, no deberías tener problemas. Solo recuerda ser lo más conciso y completo posible.
¡Feliz codificación!