Proporcionar una revisión de solicitud de extracción¶
Siempre nos alegra recibir opiniones de colaboradores, independientemente de su nivel de experiencia.
¿Por qué revisar las contribuciones?¶
Todas las contribuciones deben ser revisadas, independientemente de que hayan sido enviadas por un miembro del equipo central o por un colaborador novato. Todos podemos pasar algo por alto. El proceso de revisión está pensado para ofrecer una red de seguridad adicional.
El objetivo del proceso de revisión es garantizar que todo el contenido, incluido el código y la documentación, esté libre de errores y sea lo más fácil de mantener posible. Cualquier cosa que pueda hacer para avanzar en ese objetivo es una contribución bienvenida. Puede ser algo tan sencillo como corregir una errata o encontrar casos extremos en el uso de la API que no se hayan detectado. Podrías identificar formas en que el régimen de pruebas podría ser más robusto, o hacer una sugerencia de formas de estructurar la arquitectura general de los cambios para que sean más fáciles de mantener o ampliar.
¿Puedo revisar?¶
Sí, puedes ofrecer una revisión de cualquier pull request que veas abierto en BeeWare.
Si es la primera vez que colaboras, no dudes en revisar cualquier pull request que encuentres, incluso si ha sido enviada por un miembro del equipo central. Si eres un novato, puede que te estés perdiendo algo del contexto del proyecto, pero nuestro objetivo es mantener el código base accesible independientemente de tu nivel de experiencia. Si hay algo en el código que no tiene sentido, eso podría indicar que hay una necesidad de más documentación (ya sea en el código, o como documentación de diseño independiente).
Contribuir a la revisión de una pull request¶
Proporcionar una revisión de solicitud de extracción
Todo el mundo es bienvenido a revisar cualquier contribución al proyecto BeeWare. Hay algunas consideraciones importantes que conviene tener en cuenta antes de empezar.
PIENSE antes de revisar¶
Antes de emprender una crítica, PIENSE. Como revisores, debemos considerar si la respuesta que vamos a enviar es:
- Cierto. Esfuércese siempre por ofrecer sugerencias e información precisas.
- Útil. Estamos proporcionando orientación sobre cómo mejorar la presentación; esta orientación debe identificar claramente la fuente de un problema o un caso de uso no considerado, e idealmente proporciona un camino a seguir para lo que resolvería o satisfaría la preocupación.
- Inspirar. Depende de nosotros inspirar al autor para que quiera realizar los cambios que le pedimos.
- Necesario. Se espera que el autor lea todo lo que publicamos; debemos respetar su tiempo y esfuerzo publicando sólo cuando sea necesario.
- Amable. Hay muchas formas de presentar el mismo comentario; debemos asegurarnos de que nuestras palabras son amables, comprensivas y constructivas.
Es perfectamente posible PENSAR y, al mismo tiempo, realizar una crítica eficaz. Los conceptos expuestos anteriormente no excluyen la posibilidad de señalar cualquier problema que encuentre en un RP. Los colaboradores no tendrán la oportunidad de mejorar su contribución si no son conscientes de las áreas que necesitan mejoras. Lo importante es ser consciente de cómo se presenta esta retroalimentación. Intenta despersonalizar tu crítica. En lugar de: "Has cometido un error", puedes decir: "Este código podría mejorarse". Revisa el código, no al autor.
Es importante recordar que, además de identificar las áreas que necesitan mejoras, hay que hacer comentarios positivos. Si, por ejemplo, los cambios son especialmente útiles, hacen algo particularmente inteligente o te presentan una API que no conocías, ¡házselo saber al autor! Nunca subestimes el efecto de señalar algo que alguien ha hecho correctamente o bien, en medio de una situación en la que todo lo demás que has señalado son problemas que hay que resolver.
Sugerencias de revisión en GitHub¶
La interfaz de revisión de GitHub tiene un mecanismo para sugerencias de cambios, en el que puedes proporcionar el cambio exacto que estás sugiriendo como reemplazo del contenido existente. Tenga en cuenta que, hasta que sean aceptados y confirmados, estos cambios sugeridos no se someterán a comprobaciones previas a la confirmación ni a las comprobaciones de linting. Por lo tanto, esta función debe utilizarse para cambios pequeños, ya que cuanto mayor sea el cambio sugerido, más probable es que introduzca problemas.