1. Grundfilosofi & Arbetssätt
Vi bygger ETERNA enligt principen Community-driven utveckling. Det innebär att vi suddar ut gränsen mellan leverantör och kund. Alla som använder systemet har möjlighet att direkt påverka och förbättra det. För att detta ska fungera i praktiken vilar vårt samarbete på tre pelare:
Total Transparens
Vi tror att de bästa lösningarna byggs i dagsljus.
- Öppen Källkod: All källkod är tillgänglig för granskning. Det bygger förtroende och gör att vi snabbare hittar buggar.
- Inga dolda agendor: Roadmaps, backlog och prioriteringar är publika på GitHub. Alla vet vad som byggs och varför.
- Dokumentation: GitHub Issues och ETERNA Forum är vår primära källa till sanning. Beslut som fattas i möten måste dokumenteras där för att vara giltiga ("Om det inte står på GitHub, har det inte hänt").
Säkerhet & Kvalitet (The Gatekeeper Model)
Eftersom ETERNA hanterar kritisk information (e-arkiv) kan vi inte kompromissa med stabiliteten. Därför tillämpar vi en strikt "Grindvakt-modell":
- Frihet under ansvar: Vem som helst får föreslå ändringar och skriva kod (i en egen fork).
- Strikt kontroll: Ingenting släpps in i huvudprodukten (main branch) utan att ha passerat en rigorös Code Review och godkänts av White Red.
- White Reds ansvar: White Red agerar garant för att koden som mergeas är säker, underhållbar och följer arkitekturen. Detta möjliggör att ni kan ha supportavtal på en produkt som utvecklas av communityt.
Gyllene regeln: Issue First
För att undvika onödigt arbete och spretiga lösningar har vi en ovillkorlig regel:
- Ingen kod utan diskussion: Innan en enda rad kod skrivs ska det finnas en Issue på GitHub som beskriver problemet och den tänkta lösningen.
- Förankring: Detta ger communityt och arkitekterna en chans att ge feedback innan någon lägger tid på implementering. Det förhindrar "snickarglädje" som inte gagnar helheten.
2. Utvecklingsprocessen (Steg för Steg)
Processen följer ett cirkulärt flöde för att säkra kvalitet och transparens.
- Skapa Issue: Vem som helst (publikt) kan skapa en issue för en bugg eller ny funktionalitet.
- Använd färdiga mallar för issues.
- Prioritering & Planering:
- Issues prioriteras av produktråd/produktspecialist tillsammans med communityt.
- Teamet plockar uppgifter ("tasks") från prioriterade issues vid planeringsmöten.
- En "Definition of Done" (DoD) och beskrivning måste finnas innan arbetet påbörjas.
- Utveckling (Fork & Branch):
- Fork: Arbeta alltid i en egen kopia (fork) av repot.
- Branch: En feature = En branch. Namngivning ska ske enligt
feat/namn.
- Miljö: Utvecklingsmiljön måste köras på Linux (rekommenderat Ubuntu LTS).
- Testning:
- Ny större funktionalitet bör ha enhetstester (JUnit/Mockito).
- Pull Request (PR):
- När koden är klar skickas den in för granskning via en PR.
- Bifoga dokumentation om logik har förändrats.
- Code Review & Merge:
- Koden granskas av utpekat team samt White Red.
- Merge: Endast White Red har behörighet att merga koden till huvudgrenen ("grindvakt").
3. Prioriteringsmodell
All input – från community, kunder och interna källor – värderas gemensamt utifrån användarvärde, strategisk betydelse, genomförbarhet, affärsvärde, regelefterlevnad och säkerhet, där communitys behov väger tungt samtidigt som lagkrav och kritiska problem prioriteras särskilt högt.
Se mer information här
4. Teknisk Standard & Stack
För att säkerställa att koden är kompatibel och säker gäller följande stack och regler:
- Språk & Ramverk: Java, Spring Boot
- Web & API: Jersey, Jetty
- Data: Apache Solr
- Kodstil: Följ projektets kodregler som finns definierade i GitHub (
code-style).
- Breaking Changes: Får ej göras utan gemensam diskussion vid planeringsmöte.
5. Kommunikation & Governance
Beslutsfattande
Vi strävar efter konsensus, men vid konflikter gäller följande trappa:
- Teknisk diskussion i communityt.
- Försök till kompromiss.
- Beslut: White Red har sista ordet om enighet inte nås.
Mötesstruktur
- Månadsmöten: Vi ses via Teams (oftast sista tisdagen i månaden) för avstämning och planering. Mötesinbjudan ligger på forumet och alla kan delta genom att använda en länk.
- Fysisk träff: 1 gång per år.
- Kanaler: GitHub Discussions för kommunikation kring kod, forum för mer generella eller användarfrågor
6. Säkerhet & Juridik
- Sårbarheter: Ska aldrig rapporteras publikt som en issue. Rapportera direkt enligt instruktion i
SECURITY.md. White Red ansvarar för att rapportera vidare till CERT.
- Licens: GNU LGPLv3 (Copyleft). Alla bidrag täcks automatiskt av en patentlicens för att skydda användarna.
- Ansvar: Koden levereras "i befintligt skick". White Red agerar grindvakt genom Code Review för att minimera risker i produktion.
