Den som inte är så kunnig om fotboll tycker säkert att det ser konstigt ut när en spelare sparkar ut bollen över sidlinjen, trots att den spelaren inte alls är under attack från en motståndare. Den som är mer initierad vet att det beror på att någon annan spelare ligger ner skadad och kanske behöver läkarvård.

Det är en oskriven regel som trots att den aktivt motarbetats av de styrande i fotbollsvärlden fortfarande följs av många.

Det finns oskrivna regler även inom systemutveckling, inte minst i öppen källkodskretsar. Den som vill bli accepterad i ett öppet projekt gör bäst i att följa dem, inte minst som nykomling i ett projekt. Här presenterar IDG News sex sådana regler:

1. Läs på innan du kastar dig in i ett projekt
Innan du tar kontakt med ett community, inom öppen källkod eller i andra sammanhang, så bör du ta reda på vad det har för syfte och undersöka vad du kan bidra med. Alla vill bidra med kod, men långt färre utvecklare är beredda att göra slitgöra som att testa uppdateringar, granska andras kod, skriva dokumentation, rätta fel, och göra andra saker som krävs för att ett projekt ska bli framgångsrikt.

Läs också: Nytt verktyg rensar bort hårdkodade lösenord i applikationer

2. Skaffa dig en bred bild av projektet
Innan du sätter i gång med dina egna bidrag till ett projekt bör du skaffa dig en bred förståelse för projektet och dess kodbas. Förutom att det bidrar till din utveckling som utvecklare i största allmänhet så får du bättre förståelse för hur din kod påverkar projektet i helhet.

Ett exempel kan vara att du bygger en nätverksmodul. Du testar den och den fungerar bra, så du skickar i väg den för fler tester. Då visar det sig att den medför säkerhetsproblem eller problem med lagring. Sådana problem kan undvikas om man studerar hela kodbasen för ett projekt och inte bara de delar som vid en första anblick verkar ha direkt bäring på den egna koden. Om du skaffar dig sådan kunskap kommer dina bidrag att bli mer uppskattade.

3. Patchbombning är inte OK
Din insats är inte klar bara för att du skickar i väg en ny modul. Den kommer att undersökas, testas och diskuteras innan den accepteras. Se till att du lagt ner jobb på att skicka iväg en så färdig modul som möjligt, så slipper du att göra din kod och en massa patchar som du tvingas skicka till en börda för andra projektdeltagare.

4. Hjälp andra innan du hjälper dig själv
Öppna projekt är inte tävlingsarenor, utan handlar om att stärka ett projekts värde snarare än individernas. ”Laget före jaget”, för att dra till med en sportklyscha.

Om du vill öka dina chanser att bli sedd som en värdefull projektdeltagare, och få din kod accepterad, bör du hjälpa andra projektdeltagare. Om du till exempel är duktig på nätverkslösningar så kan du granska andras bidrag inom det området. Använd din expertis för att förbättra hela kodbasen. Det är ingen slump att de flitigaste kodgranskarna i projekt ofta också är flitigast med att bidra med kod. Ju mer du hjälper andra, desto mer uppskattad blir du.

5. Skriv kod som ingen vill tacka nej till
Som ny utvecklare i ett öppet projekt är det troligt att du adresserar ett specifikt problem i projektet. Det kanske inte finns stöd för ditt favoritoperativ eller du kanske brinner för modernisera säkerhetslösningarna i projektet.

Läs också: Github har fått en ny konkurrent i Go-baserade Gitea

Det bästa sättet att få förändringar accepterade, speciellt stora sådana, är att se till att det blir omöjligt att tacka nej till dem. Se till att kunna kodbasen så bra att du har tänkt igenom varje potentiellt problem. Lägg till nya funktioner utan att förstöra existerande. Se till att leverera kompletta bidrag.

6. Ge inte upp
Det finns gott om tillfälliga besökare bland deltagarna i öppna projekt, men med långsiktighet kommer trovärdighet. Ge inte upp i ett projekt bara för att en patch inte blir accepterad. Ta reda på varför den inte godkändes, åtgärda problemen och försök igen. Se till att ha koll på förändringar i kodbasen under tiden som du jobbar med dina egna modifieringar och att dina patchar kan inlemmas i projektet smärtfritt.

Lämna inte till andra att patcha dina patchar.