Un contributo a un progetto che non possiedi si legge come lavoro credibile sul curriculum quando la voce indica con precisione cosa hai fatto davvero: una pull request specifica che è stata unita, un bug che hai individuato e corretto, una revisione che hai dato e che ha influenzato la modifica di qualcun altro, o un ruolo di maintainer che ricopri nel progetto, invece di un semplice nome di repository accanto a un link. Il lavoro open source si differenzia da un progetto che hai costruito tu in un punto importante: il tuo nome compare nella cronologia dei commit accanto a quello di altri contributori, in un progetto che aveva già i suoi maintainer prima del tuo arrivo e che ha continuato a funzionare dopo che la tua modifica è stata integrata, quindi la voce deve indicare con precisione la tua parte specifica invece di lasciare che il lettore presuma che tu possieda l'intero progetto.
Perché una voce open source richiede una formulazione diversa da un progetto tuo
Per un progetto che hai costruito e controlli interamente, presentare progetti personali sul curriculum di un ingegnere software spiega come descrivere cosa fa, con cosa l'hai costruito e cosa è cambiato perché l'hai costruito. Un contributo open source pone prima una domanda diversa, non cosa fa il progetto, perché il lettore spesso può verificarlo in pochi secondi se il progetto è conosciuto, ma cosa hai fatto tu specificamente all'interno di un progetto già esistente e con una propria direzione già definita. Una riga vaga accanto al nome di un progetto conosciuto, senza alcuna descrizione del tuo reale coinvolgimento, può leggersi come un tentativo di prendere in prestito la reputazione di quel progetto invece di descrivere un lavoro reale, esattamente il contrario di ciò che quella voce dovrebbe ottenere.
I tipi di contributo che vale la pena nominare con precisione
Una pull request unita è l'unità di contributo più chiara da nominare, e indicare cosa ha cambiato conta più che limitarsi a menzionare che esiste: una correzione di un bug specifico, una nuova funzionalità, un miglioramento delle prestazioni, o una parte di documentazione mancante. La revisione del codice è un lavoro reale e prezioso su un progetto attivo, e merita una riga separata dalle proprie modifiche unite quando ne hai fatte abbastanza da renderla significativa, in particolare su un progetto dove la qualità delle revisioni fa parte di come i maintainer giudicano la posizione di un contributore. Un ruolo di maintainer o di triage, in cui hai accesso in scrittura, revisioni le pull request di altri, o gestisci gli issue di un progetto, merita una riga propria invece di confondersi in una menzione generica come "contributore", perché dice qualcosa che una singola correzione unita non dice: che altri maintainer si fidano del tuo giudizio in modo continuativo. I contributi ricorrenti allo stesso progetto nell'arco di più mesi meritano anch'essi di essere descritti come uno schema, invece di elencare solo la modifica unita più impressionante, perché uno schema si legge come un coinvolgimento sostenuto piuttosto che un episodio isolato.
Esempio illustrativo: una voce di contributo open source
Esempio illustrativo, da vago a specifico. Vago: "Contributore, progetto open source (github.com/example/project)." Specifico: "Contributore, uno strumento a riga di comando open source usato per ambienti di sviluppo locali. Ha corretto un bug che bloccava lo strumento con file di configurazione di grandi dimensioni, e ha revisionato diverse pull request di altri contributori nello stesso repository nell'arco di sei mesi." La versione specifica nomina lo scopo del progetto in una frase, indica con precisione cosa ha effettivamente corretto la modifica unita, e separa il lavoro di revisione dalla correzione stessa, invece di lasciare intendere che l'intera riga descriva un unico contributo.
Riconoscere il lavoro condiviso senza esagerare
La maggior parte delle modifiche unite su un progetto open source attivo di solito passa attraverso la revisione di qualcun altro prima di essere integrata, e una voce del curriculum che lascia intendere di essere l'unico autore di una funzionalità che in realtà diversi maintainer hanno definito insieme si legge come un'esagerazione non appena qualcuno controlla la cronologia dei commit, cosa che per un repository pubblico richiede solo pochi secondi. Nominare il tuo contributo specifico, una correzione, una funzionalità, un'area che revisioni regolarmente, invece di descrivere l'intera funzionalità del progetto come se l'avessi costruita da solo, mantiene la voce onesta e, nella maggior parte dei casi, più specifica e credibile di un'affermazione più generica. Quando diversi tuoi contributi si concentrano in un'area del progetto, come i suoi strumenti di build o la sua suite di test, nominare quell'area spesso informa il lettore più di quanto farebbe elencare singolarmente diverse piccole pull request.
In cosa differisce da un progetto interamente tuo
Un progetto personale costruito da zero merita una riga che ne descriva lo scopo e il risultato, perché hai preso ogni decisione su cosa fa e come. Un contributo open source merita una riga che descriva la tua parte specifica all'interno delle decisioni di qualcun altro, perché la direzione generale, l'architettura e l'ambito del progetto sono di solito già stati definiti prima del tuo arrivo. Entrambi sono lavoro tecnico legittimo che merita un posto sul curriculum, ma confonderli, descrivere un contributo open source nello stesso modo in cui descriveresti un tuo progetto, tende a esagerare il tuo ruolo nel progetto condiviso oppure a sminuire il lavoro concreto e specifico che hai effettivamente svolto.
Dove metterlo sul curriculum
Un contributo open source significativo, o un ruolo di maintainer mantenuto nel tempo, merita di solito una riga propria all'interno di una sezione progetti accanto ai progetti personali, poiché entrambi descrivono lavoro tecnico al di fuori di un impiego retribuito. Diversi contributi più piccoli su progetti differenti spesso si raggruppano meglio sotto un unico titolo, come "Contributi open source", nominando brevemente ogni progetto invece di dare a quattro righe sottili e quasi identiche lo stesso peso visivo di una voce ben descritta. Il modello Developer è costruito con un'area progetti accanto allo storico lavorativo, adatta a questo tipo di voce, sia che derivi da un impiego sia che sia del tutto indipendente.
Aggiungilo al tuo curriculum
Un contributo open source, descritto con precisione e attribuito onestamente, è una prova reale di giudizio tecnico che il lettore può spesso verificare direttamente. Parti da un modello costruito per il lavoro ingegneristico e aggiungi i tuoi contributi nell'editor, dove puoi continuare a rifinire la formulazione man mano che arrivano nuovi contributi.