En GitHub, ¿cuál es la diferencia entre revisor y asignado?
Una característica agregada el 7 de diciembre de 2016, anunciada en el blog de GitHub, introdujo la opción de agregar revisores a una solicitud de extracción.
Ahora puede solicitar una revisión explícitamente a los colaboradores, lo que facilita especificar quién le gustaría que revise su solicitud de extracción.
También puede ver una lista de las personas de las que está esperando revisión en la barra lateral de la página de solicitud de extracción, así como el estado de las revisiones de aquellos que ya las dejaron.
Sin embargo, la configuración explícita de un revisor para un RP ya se realizaba mediante la asignación de personas ( opción de asignatarios ).
Ahora que ambas opciones están disponibles, ¿cuál es la función de cada opción ya que ambas comparten el mismo objetivo final?
EDITAR:
Después de discutir con varios mantenedores de OSS, revisores se define como lo que se supone que es la palabra: revisar (el código de alguien) y "asignado" tiene una definición más flexible que se explica a continuación.
Para "revisor" : alguien a quien desea revisar el código. No necesariamente el responsable de esa área o responsable de fusionar el compromiso. Puede ser alguien que haya trabajado antes en ese fragmento de código, como sugiere automáticamente GitHub.
Para "cesionario" : depende del equipo/mantenedor del proyecto lo que significa y no existe una definición estricta. Puede ser el abridor de relaciones públicas o alguien responsable de esa área (quien aceptará las relaciones públicas una vez finalizada la revisión o simplemente las cerrará). No depende de GitHub definir qué es lo que deja abierto a los mantenedores del proyecto qué se adapta mejor a su proyecto.
Respuesta anterior:
Ok, seguiré adelante y responderé mi propia pregunta.
Para PR de usuarios con acceso de escritura: el Cesionario sería la misma persona que abrió el PR, y el revisor reemplazaría la antigua función de cesionario (revisión de código), siendo esta alguien a elección del cesionario.
Para relaciones públicas de usuarios sin acceso de escritura (colaboradores externos): alguien con acceso de escritura se asignaría a sí misma (u otro miembro con privilegios de escritura) para revisar el PR (revisor). El cesionario está en blanco.
Para relaciones públicas inacabadas de contribuyentes externos : el miembro con acceso de escritura tomaría el trabajo inacabado y lo asignaría por ella. Ella será la responsable de finalizar la tarea, siendo la Cesionaria . Dado que la razón principal de los RP es revisar los cambios, ella seleccionaría a otras personas para revisar los cambios.
En GitHub, un revisor es una persona que revisa la solicitud de extracción. El propietario de un proyecto puede solicitar una revisión a cualquiera de los mantenedores. Incluso puede configurar una opción para que la solicitud de extracción se pueda fusionar solo si es revisada por uno de los mantenedores con acceso de escritura.
Según la documentación oficial de github , el asignado es una persona que trabaja en problemas específicos y solicitudes de extracción. A veces se confunde como revisor. En realidad, está destinado a usarse con problemas en lugar de solicitudes de extracción, de modo que cuando recibamos un problema podamos asignar a alguien para que lo solucione. En una solicitud de extracción, un responsable se refiere a una persona que está a cargo de fusionar esa solicitud de extracción después de recibir comentarios y solicitudes de cambio de otros mantenedores.
Según la respuesta aceptada. Sí, "cesionario" tiene una definición más flexible y puede usarse de manera diferente para adaptarse a las necesidades del equipo.
En nuestro equipo de 8 desarrolladores, en la mayoría de los RP tenemos 1 revisor, que sugiere cambios y finalmente aprueba el RP. Durante la fase de revisión, "cesionario" es la persona que abrió el RP; Más adelante, si otro desarrollador elige PR, se agrega un nuevo "asignatario". Una vez que el PR se aprueba y está listo para el control de calidad o la fusión directa, se agrega un nuevo "asignado" de control de calidad. De esta manera la lista de "cesionarios" crece.
Usamos "cesionario" para designar colectivamente a las siguientes personas:
- Autor de la solicitud de extracción
- Autor que trabaja en sugerencias de cambios de relaciones públicas (normalmente igual que 1)
- Persona de control de calidad involucrada
- Persona responsable de fusionar (generalmente igual que 2 o 3)
El uso de "cesionario" ayuda a localizar fácilmente al RP en el futuro. Uno de mis proyectos tiene> 3000 PR.
is:open is:pr author:raya-dumas
is:closed is:pr assignee:raya-dumas
O simplemente author:raya-dumaspara encontrar todos los elementos creados por el autor (problemas, relaciones públicas)
y otras consultas similares para facilitar el proceso de búsqueda. Los "hitos" también son muy útiles para facilitar la búsqueda de relaciones públicas.
La mayor diferencia entre "revisores" y "asignados" es que los revisores en realidad tienen un estado rastreado según GitHub: ¿ya revisaron el PR o no?
Cuando agrega un revisor, lo que realmente hace es crear una "solicitud de revisión" :
El revisor recibe una notificación (como lo haría un "asignado") pero ahora en realidad tiene una tarea que puede completar , que es proporcionar una "revisión" en una solicitud de extracción:
Después de que el revisor deja una reseña (aprobando o solicitando cambios), esa información se rastrea en la API y la interfaz de GitHub :
Con los asignados, puedes asociar personas con un PR, pero más allá de eso, a GitHub realmente no le importa lo que eso significa o lo que esas personas deben hacer. Con los revisores, puede utilizar nuevas consultas de búsqueda , "proteger" ramas , asignar revisores con CODEOWNERS y crear integraciones API más profundas en torno a la asignación de revisiones y los flujos de trabajo manualmente o mediante herramientas como PullApprove .
Antes, GitHub solo tenía un campo de asignado y ningún campo de revisor. En aquel entonces no había distinción, por lo que el campo del asignado se usaba más comúnmente como campo del revisor.
Pero utilícelos de la forma que mejor se adapte a su proyecto.
