Een bijdrage aan een project dat niet van jou is, leest als geloofwaardig werk op je cv wanneer de regel precies benoemt wat je daadwerkelijk hebt gedaan: een concrete pull request die is samengevoegd, een bug die je hebt opgespoord en opgelost, een review die je hebt gegeven en die de wijziging van iemand anders heeft vormgegeven, of een maintainer-rol die je in het project vervult, in plaats van alleen een repositorynaam naast een link. Open source werk verschilt op een belangrijk punt van een project dat je zelf hebt gebouwd: je naam staat in de commitgeschiedenis naast die van andere bijdragers, in een project dat al eigen maintainers had voordat je kwam en dat bleef draaien nadat je wijziging was doorgevoerd, dus de regel moet precies jouw specifieke aandeel benoemen in plaats van de lezer te laten aannemen dat je het hele project bezit.
Waarom een open source regel andere bewoording nodig heeft dan een eigen project
Voor een project dat je zelf hebt gebouwd en volledig beheert, beschrijft zijprojecten presenteren op het cv van een software-engineer hoe je omschrijft wat het doet, waarmee je het hebt gebouwd, en wat er is veranderd doordat je het hebt gebouwd. Een open source bijdrage stelt eerst een andere vraag, niet wat het project doet, want dat kan de lezer vaak binnen seconden opzoeken als het project bekend is, maar wat jij specifiek hebt gedaan binnen een project dat al bestond en al zijn eigen richting had. Een vage regel naast de naam van een bekend project, zonder enige beschrijving van je werkelijke betrokkenheid, kan overkomen als een poging om de reputatie van dat project te lenen in plaats van echt werk te beschrijven, precies het tegenovergestelde van wat die regel zou moeten bereiken.
Soorten bijdragen die het waard zijn om specifiek te benoemen
Een samengevoegde pull request is de duidelijkste eenheid van bijdrage om te benoemen, en benoemen wat die veranderde is belangrijker dan alleen vermelden dat hij bestaat: een specifieke bugfix, een nieuwe functie, een prestatieverbetering, of een stuk ontbrekende documentatie. Codereview is echt, waardevol werk aan een actief project en verdient een aparte regel naast je eigen samengevoegde wijzigingen wanneer je er genoeg van hebt gedaan om het te laten meetellen, vooral bij een project waar reviewkwaliteit meeweegt in hoe maintainers de positie van een bijdrager beoordelen. Een maintainer- of triagerol, waarbij je commit-toegang hebt, pull requests van anderen beoordeelt, of issues voor een project beheert, verdient een eigen regel in plaats van op te gaan in een generieke vermelding als "bijdrager", omdat dit iets zegt wat één enkele samengevoegde fix niet zegt: dat andere maintainers doorlopend op jouw oordeel vertrouwen. Terugkerende bijdragen aan hetzelfde project over meerdere maanden zijn het ook waard om als patroon te beschrijven in plaats van alleen de meest indrukwekkende samengevoegde wijziging te noemen, want een patroon leest als blijvende betrokkenheid in plaats van een eenmalige actie.
Voorbeeld ter illustratie: een open source bijdrageregel
Voorbeeld ter illustratie, van vaag naar specifiek. Vaag: "Bijdrager, open source project (github.com/example/project)." Specifiek: "Bijdrager, een open source commandoregeltool voor lokale ontwikkelomgevingen. Loste een bug op die de tool liet vastlopen bij grote configuratiebestanden, en beoordeelde gedurende zes maanden meerdere pull requests van andere bijdragers aan dezelfde repository." De specifieke versie benoemt het doel van het project in één zin, geeft precies aan wat de samengevoegde wijziging daadwerkelijk oploste, en scheidt het reviewwerk van de fix zelf, in plaats van te suggereren dat de hele regel één bijdrage beschrijft.
Gedeeld werk erkennen zonder overdrijven
De meeste samengevoegde wijzigingen in een actief open source project doorlopen doorgaans de review van iemand anders voordat ze worden doorgevoerd, en een cv-regel die suggereert dat je de enige auteur bent van een functie die in werkelijkheid door meerdere maintainers samen is vormgegeven, leest als overdrijving zodra iemand de commitgeschiedenis controleert, wat bij een publieke repository slechts seconden kost. Je specifieke bijdrage benoemen, een fix, een functie, een gebied dat je regelmatig beoordeelt, in plaats van de hele functionaliteit van het project te beschrijven alsof je die in je eentje hebt gebouwd, houdt de regel eerlijk en in de meeste gevallen ook specifieker en geloofwaardiger dan een bredere bewering. Waar meerdere van je bijdragen zich concentreren rond één gebied van een project, zoals de buildtools of de testsuite, informeert het benoemen van dat gebied de lezer vaak beter dan het apart opsommen van meerdere kleine pull requests.
Waarin dit verschilt van een project dat helemaal van jou is
Een zijproject dat je helemaal zelf hebt gebouwd, verdient een regel die het doel en het resultaat ervan beschrijft, omdat jij elke beslissing nam over wat het doet en hoe. Een open source bijdrage verdient een regel die jouw specifieke aandeel beschrijft binnen de beslissingen van iemand anders, want de algehele richting, de architectuur en de scope van het project lagen meestal al vast voordat je erbij kwam. Beide zijn legitiem technisch werk dat een plek op het cv verdient, maar ze door elkaar halen, een open source bijdrage beschrijven zoals je je eigen project zou beschrijven, leidt vaak tot overdrijving van je rol in het gedeelde project of tot onderwaardering van het concrete werk dat je daadwerkelijk hebt verricht.
Waar het op het cv thuishoort
Een significante open source bijdrage, of een maintainer-rol die je gedurende langere tijd hebt vervuld, verdient meestal een eigen regel binnen een projectensectie naast persoonlijke projecten, omdat beide technisch werk buiten een betaalde functie beschrijven. Meerdere kleinere bijdragen aan verschillende projecten laten zich vaak beter groeperen onder één kop, zoals "Open source bijdragen", waarbij je elk project kort benoemt in plaats van vier dunne, bijna identieke regels hetzelfde visuele gewicht te geven als één goed omschreven regel. Het Developer-sjabloon is gebouwd met een projectengebied naast de werkervaring, wat past bij dit soort regel, of die nu uit een baan is voortgekomen of volledig op zichzelf staat.
Voeg het toe aan je cv
Een specifiek beschreven en eerlijk toegeschreven open source bijdrage is echt bewijs van technisch inzicht dat de lezer vaak rechtstreeks kan verifiëren. Begin met een sjabloon dat is gebouwd voor technisch werk en voeg je bijdragen toe in de editor, waar je de formulering kunt blijven verfijnen naarmate er nieuwe bijdragen bijkomen.