CONTRIBUTING.md

Riktlinjer för bidrag

Välkommen! Vi är glada över att du vill bidra till vårt projekt!

Här är vad du behöver veta:

Bidra

Som ny är det ett värdefullt tillfälle för återkoppling. Exempelvis genom att:

• Fixa eller rapportera en bugg.
• Föreslå förbättringar av kod, tester och dokumentation.
• Rapportera eller fixa problem som upptäcks under installation eller i utvecklingsmiljöer.
• Föreslå nya funktioner eller förbättringar.

Uppförandekoder

Var trevlig och respektfull mot varandra.

Vi följer Contributor Covenants uppförandekod.

Att skapa ett ärende

Innan du skapar ett nytt ärende, vänligen kontrollera om ett liknande redan finns.

Om så är fallet kan du lägga till din information som en kommentar till det befintliga ärendet.

Att rapportera fel

Att rapportera programfel är ett värdefullt sätt att bidra:

1. Öppna ett ärende som sammanfattar felet.
2. Sätt etiketten till "bug".

Föreslå en förbättring

För att begära en ny funktion:

1. Öppna ett ärende som sammanfattar den önskade funktionaliteten och dess användningsfall.
2. Sätt etiketten till "feature" eller "enhancement".

Bidra med kod, dokumentation och mer

För att bidra med kod, dokumentation eller andra förbättringar:

1. Diskutera dina planer i förväg för att säkerställa att de stämmer överens med projektmålen.
2. Kontrollera listan över öppna ärenden, saknas ett ärende för det tänkta bidraget skapar du ett nytt.
3. Tilldela dig själv ett befintligt ärende genom att kommentera ärendet.
4. Följ projektkonventioner för tester, kodstil, dokumentation och commit-meddelanden.
5. Förstå att bidrag kan avslås om de inte överensstämmer med projektets riktlinjer eller mål.
6. Bekanta dig med Pull Request-livscykeln.
7. Godkänn "inbound=outbound"-normen: dina bidrag kommer att vara under samma licens som projektet.
8. Signera dina commits.

Kom igång med "good first issues", de har en begränsad omfattning och en tänkt lösning som redan har diskuterats inom projektet. Lämpligt för nya utvecklare som vill bidra och få bättre förståelse för bidragsprocessen.

Det finns också ärenden taggade med "ready to take", vilket är ärenden som redan har blivit åtminstone delvis lösta i diskussioner, så pass att det är tydligt vad som behöver göras härnäst.

Självklart kan du arbeta med vilket annat ärende du vill – "good first" och "ready to take" ärenden är bara de där omfattning och tidsram ofta är tydligare definierade. Pull requests för andra ärenden, eller helt nya problem, kan ta lite längre tid att granska om de inte passar in i vår nuvarande utvecklingscykel och det finns en risk att någon i teamet redan arbetar på ärendet.

Om du bestämmer dig för att lösa ett ärende, se till att kolla kommentarsfältet för att se om någon redan arbetar på en lösning. Om ingen gör det just nu, lämna gärna en kommentar där du skriver att du har börjat arbeta med det, så att andra inte råkar göra samma jobb.

Om någon har tagit på sig ett ärende men inte följer upp inom en vecka, går det bra att ta över – men lämna ändå en kommentar. Om det inte har varit någon aktivitet på ärendet på 7 till 14 dagar är det rimligt att anta att ingen jobbar på det.

Återkoppling på ärenden och Pull Requests

Projektunderhållare kommer att göra sitt bästa för att granska och svara på ärenden inom fem arbetsdagar.

Kvaliteten på informationen i ditt ärende eller pull request kommer att påverka feedbackslingan.

För icke-triviala bidrag, vänligen diskutera med projektteamet först.

Om projektet inte är listat som arkiverat underhålls det.

Pull Request-livscykel

Vi använder Fork-and-Pull-modellen:

1. Forka repositoriet från senaste release-tag.
2. Skapa en ämnesgren från din forks huvudgren.
3. Pusha dina ändringar till ämnesgrenen i din fork.
4. Öppna en ny pull request till huvudprojektet.
5. Svara på eventuell feedback från projektunderhållare.

Commit-riktlinjer

DCO - Signoff och signering av en commit

Signoff (DCO-godkännande)

En Signoff försäkrar projektet om att du har rätt att bidra med ditt innehåll +

Lägg till en signoff till din commit med flaggan -s eller --signoff:

git commit --signoff -m 'fix: lägg till fix för superbug x'

Signera

En signatur försäkrar att commiten kom från dig

Signera din commit med -S eller --gpg-sign:

git commit --signoff --gpg-sign -m "fix: lägg till fix för buggen"

Commit-standard

• Använd Conventional Commit-standarden.
• Gruppera relevanta ändringar i commits.
• Skriv tydliga, lättlästa commit-meddelanden.

Rapportera säkerhetsproblem

För säkerhetssårbarheter, följ riktlinjerna i vår Säkerhetsinformation.

Skrivstil och översättningar

• Håll dokumentationen lättläst.
• Använd punktlistor för tydlighet.
• Var koncis och länka till externa resurser vid behov.
• Följ en-mening-per-rad-principen i Markdown eller AsciiDoc.

Svenska är det primära språket.

FOSS-standarder

Vi strävar efter att följa följande standarder och bästa praxis:

• REUSE Licensspecifikation

  • Säkerställer tydlig och standardiserad licensefterlevnad i hela projektet.

• Conventional Commits-format

  • Ger en tydlig och strukturerad projekthistorik genom standardiserade commit-meddelanden.

• Keep-A-Changelog-format

  • Upprätthåller en tydlig och användarvänlig versionshistorik.

• Contributor Covenant-riktlinjer

  • Upprättar ett socialt kontrakt för respektfullt och inkluderande samarbete.

• OpenSSF Scorecard

  • Hjälper till att bedöma och förbättra säkerhetshälsan i vårt projekt.

• PublicCode.yml

  • Underlättar enkel metadataindexering för bättre upptäckbarhet av vårt projekt.

• Standard for Public Code

  • Säkerställer att projektet uppfyller kriterier för offentlig kodkvalitet och hållbarhet.

Bidragsgivare uppmuntras att bekanta sig med dessa riktlinjer och hjälpa oss att upprätthålla dessa standarder i sina bidrag.