Saltar al contenido

En GitHub, ¿cuál es la diferencia entre revisor y asignado?

Hola, tenemos la respuesta a lo que necesitas, has scroll y la verás aquí.

Solución:

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.

Por “revisor”: alguien que desea revisar el código. No necesariamente la persona responsable de esa área o responsable de fusionar la confirmación. Puede ser alguien que haya trabajado antes en ese fragmento de código, como sugiere automáticamente GitHub.

Por “cesionario”: depende del equipo/mantenedor del proyecto lo que significa y no hay una definición estricta. Puede ser el abridor de relaciones públicas, o alguien responsable de esa área (que va a aceptar la relación pública después de que se haya realizado la revisión o simplemente cerrarla). No depende de GitHub definir qué es lo que deja abierto para los mantenedores de proyectos qué se adapta mejor a su proyecto.

Respuesta anterior:

Ok, seguiré adelante y responderé mi propia pregunta.

Para relaciones públicas 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 (código de revisión), siendo esta una persona 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í mismo (u otro miembro con privilegios de escritura) para revisar el PR (Revisor). El cesionario está en blanco.

Para relaciones públicas inconclusas de colaboradores externos: el miembro con acceso de escritura tomaría el trabajo sin terminar y se lo asignaría. Ella será la encargada de terminar la tarea, siendo la Cesionario. Dado que la razón principal de los RP es revisar los cambios, 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 la revisión de cualquiera de los mantenedores. Incluso pueden establecer una opción para que la solicitud de extracción se pueda fusionar solo si la revisa uno de los mantenedores con acceso de escritura.

De acuerdo con la documentación oficial de github, el Asignatario es una persona que trabaja en problemas específicos y solicitudes de incorporación de cambios. 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 asignado 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 respuesta aceptada. Sí, “asignado” tiene una definición más flexible y se puede usar de manera diferente para satisfacer las necesidades de un equipo.

En nuestro equipo de 8 desarrolladores, en la mayoría de las RP tenemos 1 revisor, que sugiere cambios y, en última instancia, aprueba la RP. Durante la fase de revisión, “cesionario” es la persona que abrió el PR; más tarde, si otro desarrollador selecciona PR, se agrega un nuevo “cesionario”. Una vez que se aprueba la RP y está lista para el control de calidad o la fusión directa, se agrega un nuevo “cesionario” de control de calidad. De esta manera crece la lista de “asignados”.

Usamos “cesionario” para designar a las siguientes personas colectivamente:

  1. Autor de solicitud de extracción
  2. Autor trabajando en sugerencias de cambio de relaciones públicas (normalmente igual que 1)
  3. Persona de control de calidad involucrada
  4. Persona responsable de la fusión (generalmente la misma que 2 o 3)

El uso de “cesionario” ayuda a localizar fácilmente el 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 solo author:raya-dumas para encontrar todos los elementos creados por el autor (problemas, PR)

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.

Captura de pantalla de Github, cuarto trimestre de 2017

Comentarios y puntuaciones del tutorial

Recuerda algo, que puedes aclarar si diste con el arreglo.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *