Fornire una revisione della richiesta pull¶
Siamo sempre felici di ricevere recensioni da parte dei collaboratori, indipendentemente dal loro livello di esperienza.
Perché rivedere i contributi?¶
Ogni contributo inviato deve essere rivisto, indipendentemente dal fatto che sia stato inviato da un membro del team principale o da un collaboratore alle prime armi. Tutti possono sbagliare qualcosa. Il processo di revisione serve a fornire un'ulteriore rete di sicurezza.
Lo scopo del processo di revisione è garantire che tutti i contenuti, compresi codice e documentazione, siano il più possibile privi di bug e facili da mantenere. Qualsiasi cosa possiate fare per promuovere questo obiettivo è un contributo gradito. Può andare da qualcosa di semplice come la correzione di un errore di battitura all'individuazione di casi limite nell'uso dell'API che non vengono rilevati. Potreste identificare i modi in cui il regime di test potrebbe essere più robusto, o suggerire modi per strutturare l'architettura complessiva delle modifiche in modo che siano più facili da mantenere o estendere.
Posso fare una recensione?¶
Sì, puoi offrire una revisione su qualsiasi richiesta di pull che vedi aperta su {{ nome_formale }}.
Se sei un collaboratore alle prime armi, dovresti sentirti libero di esaminare qualsiasi richiesta di pull che trovi, anche se è stata presentata da un membro del team principale. Se siete alle prime armi, potreste perdere qualche contesto più ampio del progetto; ma il nostro obiettivo è mantenere la base di codice accessibile indipendentemente dal vostro livello di esperienza. Se c'è qualcosa nel codice che non ha senso, questo potrebbe indicare che c'è bisogno di più documentazione (nel codice o come documentazione di progetto a sé stante).
Contribuire alla revisione di una richiesta di pull¶
Fornire una revisione della richiesta pull
Tutti sono invitati a rivedere qualsiasi contributo al progetto BeeWare. Ci sono alcune considerazioni importanti da tenere presenti prima di iniziare.
PENSARE prima di recensire¶
Prima di fare una recensione, PENSARE. In qualità di recensori, dobbiamo considerare se la risposta che stiamo per inviare è:
- Vero. Cercate sempre di fornire suggerimenti e informazioni accurate.
- Utile. Stiamo fornendo indicazioni su come migliorare la presentazione; queste indicazioni devono identificare chiaramente la fonte di un problema o di un caso d'uso non considerato e, idealmente, fornire un percorso per risolvere o soddisfare il problema.
- Ispirazione. Sta a noi ispirare l'autore a voler lavorare alle modifiche da noi richieste.
- Necessario. L'aspettativa è che l'autore legga tutto ciò che pubblichiamo; dobbiamo rispettare il suo tempo e il suo impegno pubblicando solo quando è necessario.
- Gentilezza. Ci sono diversi modi per presentare lo stesso feedback; dobbiamo assicurarci di scegliere di essere gentili, solidali e costruttivi con le nostre parole.
È assolutamente possibile PENSARE e allo stesso tempo fornire una recensione efficace. I concetti discussi sopra non precludono la possibilità di segnalare eventuali problemi riscontrati in una PR. I collaboratori non avranno l'opportunità di migliorare il loro contributo se non sono consapevoli delle aree da migliorare. L'importante è rimanere consapevoli del modo in cui si presenta il feedback. Cercate di spersonalizzare la vostra revisione. Invece di dire "Hai commesso un errore", potete dire "Questo codice potrebbe essere migliorato". Esaminate il codice, non l'autore.
È importante ricordare di fornire un feedback positivo oltre a identificare le aree da migliorare. Se, ad esempio, le modifiche sono particolarmente utili, fanno qualcosa di particolarmente intelligente o vi viene presentata un'API che non conoscevate, fatelo sapere all'autore! Non sottovalutate mai l'effetto di far notare qualcosa che qualcuno ha fatto bene o correttamente, nel bel mezzo di una situazione in cui tutto il resto che avete fatto notare sono problemi da risolvere.
Suggerimenti per le revisioni su GitHub¶
L'interfaccia di revisione di GitHub ha un meccanismo per i suggerimenti di modifica, in cui è possibile fornire l'esatta modifica che si sta suggerendo in sostituzione del contenuto esistente. Si tenga presente che, fino a quando non saranno accettate e impegnate, queste modifiche suggerite non saranno sottoposte ai controlli di pre-commit e di linting. Pertanto, questa funzione dovrebbe essere usata per le modifiche più piccole, poiché più grandi sono le modifiche suggerite, più è probabile che introducano problemi.