No GitHub, qual é a diferença entre revisor e responsável?


187

Um recurso adicionado em 7 de dezembro de 2016, anunciado no blog do GitHub, apresentou a opção de adicionar revisores a uma solicitação de recebimento

Opção de revisão do GitHub

Agora você pode solicitar uma revisão explicitamente aos colaboradores, facilitando a especificação de quem você deseja revisar sua solicitação de recebimento.

Você também pode ver uma lista de pessoas das quais você está aguardando revisão na barra lateral da página de solicitação de recebimento, bem como o status das revisões daqueles que já as deixaram.

No entanto, a configuração explícita de um revisor para um PR já foi feita através da atribuição de pessoas ( opção de responsáveis ).

Com as duas opções agora disponíveis, qual é o papel de cada opção, pois ambas compartilham o mesmo objetivo final?


1
quando o "recurso designado" é lançado pela primeira vez? Existe algum artigo que o introduz?
babeyh 18/01

Respostas:


135

EDITAR:

Após discutir com vários mantenedores do OSS, os revisores são definidos como o que a palavra deveria ser: revisar (código de alguém) e "cessionário" tem uma definição mais flexível explicada abaixo.

Para "revisor" : alguém que você deseja revisar o código. Não necessariamente a pessoa responsável por essa área ou responsável por mesclar o commit. Pode ser alguém que trabalhou nesse pedaço de código antes, como o GitHub sugere automaticamente.

Para "cessionário" : cabe à equipe / mantenedor do projeto o que significa e não há uma definição estrita. Pode ser o abridor de relações públicas ou alguém responsável por essa área (que aceitará o relações públicas depois que a revisão for concluída ou apenas fechá-la). Não cabe ao GitHub definir o que está deixando em aberto para os mantenedores do projeto o que melhor se adequa ao seu projeto.

Resposta anterior:

Ok, eu vou em frente e respondo minha própria pergunta.

Para PR de usuários com acesso de gravação: o cessionário seria a mesma pessoa que abrisse o PR e o revisor substituiria a função antiga do cessionário (código de revisão), sendo este alguém da escolha do cessionário.

Para PR de usuários sem acesso de gravação (colaboradores externos): alguém com acesso de gravação se designaria (ou outro membro com privilégio de gravação) a revisar o PR (Revisor). O responsável está em branco.

Para relações públicas inacabadas de colaboradores externos : o membro de acesso de gravação pegaria o trabalho inacabado e a designaria para ela. Ela será responsável por terminar a tarefa, sendo a Cessionária . Como o principal motivo dos PRs é revisar as alterações, ela selecionaria outras pessoas para revisá-las.


24
Para cada novo membro da equipe, devo enviar um link para esta resposta para explicar como lidar com os responsáveis ​​e revisores. O que me leva a pensar que há algo fundamentalmente errado aqui :(
Andrey Kuleshov

Um responsável precisa ter acesso de gravação?
Emre Sülün

existe uma diferença no comportamento de notificação por email entre os dois?
jxramos 18/03

26

No GitHub, um revisor é uma pessoa que analisa a solicitação de recebimento. Um proprietário do projeto pode solicitar a revisão de qualquer um dos mantenedores. Eles podem até definir uma opção para que a solicitação de recebimento possa ser mesclada apenas se for revisada por um dos mantenedores com acesso de gravação.

De acordo com a documentação oficial do github , o Responsável é uma pessoa que está trabalhando em questões específicas e recebe solicitações. Às vezes, é confundido como revisor. Na verdade, ele deve ser usado com problemas, em vez de solicitação pull, para que, quando recebermos um problema, possamos designar alguém para corrigi-lo. Em uma solicitação de recebimento, um responsável se refere a uma pessoa encarregada de mesclar essa solicitação de recebimento após receber comentários e solicitações de alteração de outros mantenedores.


2
Obrigado pela resposta, mas não acho que ela resolva a questão completamente. Você pode atribuir um problema a alguém (para que ela seja o responsável pelo problema), mas quando o PR for enviado, alguém seria o revisor (responsável pelo PR) e, neste momento, ainda não estou claro sobre a diferença entre o responsável e revisor.
Cezar Augusto

14

Conforme resposta aceita. Sim, "cessionário" tem uma definição mais flexível e pode ser usado de maneira diferente para atender às necessidades de uma equipe.

Em nossa equipe de 8 desenvolvedores, na maioria dos RP, temos 1 revisor, que sugere alterações e, finalmente, aprova o RP. Durante a fase de revisão, "cessionário" é a pessoa que abriu o PR; mais tarde, se PR for escolhido por outro desenvolvedor, um novo "cessionário" será adicionado. Depois que o PR é aprovado e está pronto para o controle de qualidade ou mesclagem direta, um novo "cessionário" de controle de qualidade é adicionado. Dessa forma, a lista "cessionário" aumenta.

Usamos "cessionário" para designar as seguintes pessoas coletivamente:

  1. Autor da solicitação de recebimento
  2. Autor que trabalha nas sugestões de alteração de relações públicas (geralmente igual a 1)
  3. Pessoa de controle de qualidade envolvida
  4. Pessoa responsável pela fusão (geralmente igual a 2 ou 3)

O uso do "cessionário" ajuda a localizar o PR no futuro facilmente. Um dos meus projetos tem> 3000 PRs.

is:open is:pr author:raya-dumas

is:closed is:pr assignee:raya-dumas

Ou apenas author:raya-dumaspara encontrar todos os itens criados pelo autor (problemas, PRs)

e outras consultas semelhantes para facilitar o processo de pesquisa. "marcos" são bastante úteis de usar também para facilitar a pesquisa de relações públicas.

Captura de tela Github, quarto trimestre de 2017


Muito bem explicado.
Nitin Gaur

Deve ser mencionado que você pode simplesmente procurar autor: my-github-handle para encontrar o PR é uma pessoa criada
Wisienkas

1

Antes, o GitHub tinha apenas um campo de responsável e nenhum campo de revisor. Não havia distinção na época; portanto, o campo de destinatário era mais comumente usado como campo de revisor.

Mas use-os da maneira que melhor se adequar ao seu projeto.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.