Recibir una revisión de solicitud de extracción¶

Su pull request ha sido enviada y aprobada por CI. Ahora está listo para ser revisado.

tl;dr - El proceso de revisión¶

La versión resumida del proceso de revisión:

Espera una revisión.
Responder a los comentarios.
Si se solicitan cambios:
Trabaje para completar los cambios solicitados.
Presente todos los cambios solicitados.
Vuelva a solicitar una revisión cuando se hayan presentado todos los cambios solicitados.
Repita la sección tres hasta que no sea necesario realizar más cambios.
Espere a que su pull request sea aprobado y fusionado.

Enhorabuena. ¡Acabas de hacer una contribución a BeeWare!

He enviado mi pull request, ¿qué sigue?¶

Después de enviar su pull request, tendrá que esperar a que se revise su contribución. El proceso de revisión tiene dos vertientes: proporcionar una revisión y recibir una revisión.

Revisar las expectativas

Debe esperar que cualquiera que revise sus envíos siga estas directrices, incluidas las revisiones de los miembros del equipo central. También debe seguir estas directrices cuando revise propuestas de otros.

Si cree que su revisor se está desviando de estas expectativas, y se siente cómodo planteando el problema usted mismo en el pull request, puede hacerlo. Si no se siente cómodo, por favor póngase en contacto con el Equipo de Respuesta al Código de Conducta de BeeWare. Revisaremos su informe y nos pondremos en contacto con su revisor. El seguimiento reflejará la acción reportada; una transgresión menor puede resultar en una discusión, mientras que una violación mayor puede resultar en algo más serio.

Proporcionar una revisión¶

Todo el mundo es bienvenido a revisar cualquier pull request. Estas directrices describen lo que esperamos de una revisión, independientemente de si la realiza un miembro del equipo central o un miembro de la comunidad.

Siempre será necesario que un miembro del equipo central realice la revisión final, pero las revisiones de los miembros de la comunidad pueden ser una forma útil de agilizar el proceso: lo ideal sería que la revisión del equipo central fuera una formalidad después de que las revisiones de la comunidad hayan identificado todos los problemas principales.

Recibir una revisión¶

Recibir una revisión implica tres pasos básicos:

Comentarios y preguntas iniciales.
Solicitudes de cambio.
Aprobación y fusión.

A continuación se detalla cada paso. Si en algún momento del proceso tiene alguna pregunta, no dude en planteárnosla. Estaremos encantados de ayudarle.

Calendario y comentarios iniciales¶

El equipo central se esfuerza por garantizar que todas las pull requests reciban una revisión en un plazo de diez días laborables. Sin embargo, en el caso de envíos más complicados, o cuando se envía una pull request cuando parte del equipo está de vacaciones, ese plazo puede ampliarse.

Normalmente mantenemos la continuidad con los revisores en cada pull request, es decir, es probable que trabajes con el mismo revisor durante toda la revisión. Esto significa que su revisor tendrá contexto a lo largo del proceso, y usted será capaz de aprender qué esperar en términos de cadencia de respuesta y estilo de revisión. Si tu revisor inicial identifica que no tiene la experiencia necesaria para revisar tus pull requests, o sabe que no estará disponible por alguna razón, puede pasar la responsabilidad de tu pull request a otro miembro del equipo.

Le responderemos en un plazo de diez días laborables. Responder a los comentarios y preguntas es una parte esencial del proceso de revisión. Esperamos su respuesta antes de pasar al siguiente paso del proceso.

Solicitudes de cambio¶

La mayoría de las veces, tu revisor va a solicitar cambios en tu pull request. Esto no es necesariamente un reflejo de tu trabajo, es simplemente parte del proceso.

Si la revisión inicial revela un número significativo de problemas, la primera revisión puede no ser exhaustiva. En su lugar, se centrará en proporcionar una orientación de alto nivel sobre el trabajo necesario para conseguir que la pull request se encuentre en un estado fusionable. El proceso de revisión puede incluir preguntas para aclarar el propósito y el alcance del trabajo que se ha intentado realizar.

Trabajar en los cambios solicitados¶

Su revisor enviará comentarios a su pull request. Estos comentarios pueden ser generales, sobre un archivo específico, o sobre una línea o líneas específicas de código. A veces incluirán directamente sugerencias de cambios que puedes aplicar a tu pull request a través de la interfaz de GitHub. Normalmente, serán preguntas, solicitudes de aclaración u orientación sobre actualizaciones.

Marcar una conversación como resuelta

Durante la parte de discusión del proceso de retroalimentación, nunca debe marcar una conversación iniciada por su revisor como "resuelta". Marcar la conversación como resuelta es responsabilidad del revisor. Es él quien debe determinar si el problema identificado se ha resuelto.

Si la revisión revela un problema sistemático (por ejemplo, una incoherencia en la nomenclatura del código), puede que el revisor no destaque todos los casos del problema. En su lugar, puede elegir un par de ejemplos del problema e indicar que otros casos también deben corregirse. Si un revisor destaca un problema en un lugar y usted cree que puede aplicarse a otro, debe corregirlo dondequiera que ocurra. Si no está seguro, pida aclaraciones al revisor.

Presentar todos los cambios solicitados¶

Una vez que haya realizado todos los cambios solicitados, puede enviar una actualización a su pull request. Esto desencadenará una nueva ejecución de CI; una vez que haya confirmado que CI sigue pasando, publique un comentario solicitando una revisión actualizada y el equipo central echará otro vistazo a su pull request.

Empuja, no fuerces ni rebases.

Cuando estés actualizando tu pull request durante una revisión, es importante dejar el historial de commits intacto. No importa si hay una enorme lista de commits; todos son aplastados cuando fusionamos el pull request. Si fuerza el push o rebase de su pull request en medio de una revisión, puede estar eliminando contexto importante necesario para su revisor.

Volver a solicitar una revisión¶

Una vez que haya resuelto todos los cambios solicitados en una revisión determinada, y CI vuelva a pasar, puede volver a solicitar una revisión a su revisor. Si un problema es particularmente complicado, y la solución de uno afectará a otra cosa, usted puede pedir una revisión de la pieza específica que ha actualizado. Se supone que cualquier solicitud de revisión es una solicitud de revisión completa. Si no estás preparado para una revisión completa, asegúrate de especificar exactamente lo que estás buscando.

Aprobación y fusión de pull requests¶

Una vez que haya respondido a todas las solicitudes de cambio se han completado, el pull request será aprobado. En la mayoría de los casos, una vez aprobada una pull request, la fusionaremos inmediatamente. En algunos casos, puede haber circunstancias atenuantes, como depender de otra pull request aún no fusionada, que provoquen un retraso. Lo comunicaremos en los comentarios, para que conozcas la situación.