Su GitHub, qual è la differenza tra revisore e assegnatario?

187

Una funzionalità aggiunta il 7 dicembre 2016, annunciata sul blog di GitHub, ha introdotto l'opzione per aggiungere revisori a una richiesta pull

Ora puoi richiedere una recensione esplicitamente ai collaboratori, rendendo più semplice specificare chi desideri rivedere la tua richiesta pull.

Puoi anche visualizzare un elenco di persone in attesa di revisione nella barra laterale della pagina di richiesta pull, nonché lo stato delle recensioni di coloro che le hanno già lasciate.

Tuttavia, l'impostazione esplicita di un revisore per un PR è stata già effettuata assegnando persone ( opzione assegnatari ).

Con entrambe le opzioni ora disponibili, qual è il ruolo di ciascuna opzione in quanto entrambi condividono lo stesso obiettivo finale?

github pull-request

— Cezar Augusto
fonte

1

quando "funzione assegnatario" viene rilasciato per la prima volta? C'è qualche articolo che lo introduce?

— babeyh

135

MODIFICARE:

Dopo aver discusso con diversi manutentori di OSS, i revisori sono definiti come ciò che la parola dovrebbe essere: rivedere (il codice di qualcuno) e "assegnatario" ha una definizione più libera spiegata di seguito.

Per "revisore" : qualcuno che desideri rivedere il codice. Non necessariamente la persona responsabile di quell'area o responsabile della fusione dell'impegno. Può essere qualcuno che ha lavorato su quel pezzo di codice prima, come suggerisce automaticamente GitHub.

Per "cessionario" : dipende dal team / manutentore del progetto cosa significa e non esiste una definizione rigorosa. Può essere l'apri PR o qualcuno responsabile di quell'area (che accetterà il PR dopo aver eseguito la revisione o semplicemente lo chiuderà). Non sta a GitHub definire ciò che lo sta lasciando aperto per i manutentori del progetto che si adatta meglio al loro progetto.

Risposta precedente:

Ok vado avanti e rispondo alla mia domanda.

Per le PR degli utenti con accesso in scrittura: l'assegnatario sarebbe la stessa persona che ha aperto la PR e il revisore sostituirà la vecchia funzione assegnatario (revisione del codice), essendo questa una persona a scelta dell'assegnatario.

Per le PR degli utenti senza accesso in scrittura (collaboratori esterni): qualcuno con accesso in scrittura assegnerebbe a se stesso (o altro membro con privilegi di scrittura), di rivedere il PR (Revisore). Il cessionario è vuoto.

Per le PR non finite di collaboratori esterni : il membro con accesso in scrittura prendeva il lavoro incompiuto e le assegnava. Sarà responsabile del completamento dell'attività, essendo l' assegnatario . Poiché il motivo principale delle pubbliche relazioni sta esaminando le modifiche, selezionerebbe alcune altre persone per esaminarle.

— Cezar Augusto
fonte

24

Per ogni nuovo membro del team dovrei inviare un link a questa risposta per spiegare come trattare con assegnatari e revisori. Il che mi porta a pensare che qualcosa di fondamentalmente sbagliato qui :(

— Andrey Kuleshov,

Un cessionario deve avere accesso in scrittura?

— Emre Sülün,

c'è una differenza nel comportamento delle notifiche e-mail tra i due?

— jxramos il

26

In GitHub un revisore è una persona che esamina la richiesta pull. Il proprietario di un progetto può richiedere la revisione da uno dei manutentori, può anche impostare un'opzione in modo che la richiesta pull possa essere unita solo se viene esaminata da uno dei manutentori con accesso in scrittura.

Secondo la documentazione ufficiale di github , il cessionario è una persona che sta lavorando su questioni specifiche e richiama richieste. A volte è confuso come revisore. In realtà è pensato per essere utilizzato con problemi piuttosto che pull request in modo che quando riceviamo un problema possiamo assegnare qualcuno per risolverlo. In una richiesta pull, un cessionario si riferisce a una persona che è responsabile della fusione di tale richiesta pull dopo aver ricevuto commenti e richieste di modifica da altri manutentori.

— Gautam Krishna R
fonte

2

Grazie per la risposta, ma non credo che risolva completamente la domanda. Puoi assegnare un problema a qualcuno (quindi lei sarà l'assegnatario del problema), ma quando viene inviato il PR qualcuno sarebbe il revisore (assegnatario del PR), e a questo punto, non sono ancora chiaro sulla differenza tra cessionario e recensore.

— Cezar Augusto,

14

Come da risposta accettata. Sì, "assegnatario" ha una definizione più libera e può essere utilizzato in modo diverso per soddisfare le esigenze di una squadra.

Nel nostro team di 8 sviluppatori, nella maggior parte dei PR abbiamo 1 revisore, che suggerisce cambiamenti e alla fine approva il PR. Durante la fase di revisione, "cessionario" è la persona che ha aperto il PR; in seguito se PR viene raccolto da un altro sviluppatore, viene aggiunto un nuovo "cessionario". Una volta che il PR è approvato e pronto per il QA o l'unione diretta, viene aggiunto un nuovo "assegnatario" del QA. In questo modo l'elenco "assegnatario" aumenta.

Utilizziamo "cessionario" per designare collettivamente le seguenti persone:

Pull Request Author
Autore che lavora su suggerimenti di modifica PR (in genere uguale a 1)
Persona di controllo qualità coinvolta
Persona responsabile della fusione (in genere uguale a 2 o 3)

L'uso di "assegnatario" consente di individuare facilmente le PR in futuro. Uno dei miei progetti ha> 3000 PR.

is:open is:pr author:raya-dumas

is:closed is:pr assignee:raya-dumas

O semplicemente author:raya-dumasper trovare tutti gli articoli creati dall'autore (numeri, PR)

e altre query simili per facilitare il processo di ricerca. "pietre miliari" sono molto utili da usare anche per facilitare la ricerca di PR.

— lal
fonte

Molto ben spiegato.

— Nitin Gaur,

Va detto che puoi semplicemente cercare l'autore: my-github-handle per trovare ciò che PR è una persona creata

— Wisienkas,

1

Prima GitHub aveva solo un campo assegnatario e nessun campo revisore. Allora non c'era distinzione, quindi il campo degli assegnatari era più comunemente usato come campo revisore.

Ma usali nel modo che preferisci al tuo progetto.

— ericcurtin
fonte