Ten behoeve van het beheer van de code is het noodzakelijk om afspraken te maken, zodat iedereen weet waar men aan toe is.
Binnen het Open Webconcept hanteren we de volgende uitgangspunten:
- WordPress
- Open architectuur:
- Vrije marktwerking
- Open samenwerking
- Pragmatisch
Intentieverklaring op: https://OpenWebconcept.nl/intentieverklaring/
Binnen het Open Webconcept delen we functionaliteiten door middel van bouwblokken. Hiervoor gelden de volgende uitgangspunten:
- Te gebruiken in WordPress
- Common Ground gedachte
- Delen met anderen
- Helpen met fouten
- Het is een Datadienst of een Toepassing
Voor deze bouwblokkken kunnen we dan ook bepaalde eisen ophalen:
- WordPress: Open Source
- Toegankelijk voor nieuwe nieuwe partijen die willen participeren
- Pragmatische insteek, alleen formeel wanneer het nodig is
- Ook een reeële manier om weer te verlaten
- Garanties ten opzichte van elkaar
- Bouwblokken hebben altijd een publiccode.yaml
- Bouwblokken staan bij voorkeur op github.com/openwebconcept
- Losse componenten:
- Code deelbaar
- Zelfde licentie
- 2e-lijns support op de code (bugs/changes)
- Eén jaar aangeven dat support vervalt
- Eén plek waar alle bouwblokken te vinden zijn
- Signaal wanneer er een nieuwe versie is
Per bouwblok:
- Is deze te vinden op https://github.com/OpenWebconcept/
- De licentie is EUPL
- Er is één repository met die bloknaam
- De gemeente is de beheerder van het bouwblok
- De leverancier plaatst de code en maakt de aanpassingen. Een gemeente kan ook een leverancier zijn.
- De beheerder kan een leverancier zijn of gemeenten maar MOET zijn opgenomen in de publicode.yaml
- De eigenaar kan een gemeente zijn of leverancier maar MOET zijn opgenomen in de publicode.yaml
- Issues en changes worden actief opgepakt
- De beheerder van een bouwblok is verantwoordelijk voor de ondersteuning van andere partijen, ook als dit directe concurrenten zijn
- Aanpassingen worden aangeleverd op basis van Pull Requests en bij voorkeur door een andere leverancier of gemeente goedgekeurd
- Een bouwblok mag geen afhankelijkheden hebben op closed source software, tenzij expliciet vermeld in de readme
- Versiebeheer conform semver
- Bij iedere nieuwe versie wordt er ook een GitHub release aangemaakt
- Bij iedere nieuwe GitHub release wordt ook een package aangemaakt (zodat oudere versies later nog te downloaden en gebruiken zijn)
- Het is installeerbaar via de WordPress plugin structuur (dus WordPress update checker implementeren)
- Naast plugin structuur moet ook installatie via Composer worden ondersteund
- Een bouwblok moet standaard vertalingsopties ondersteunen
- De blokken kunnen met elkaar draaien op dezelfde server, maar mogen ook los geïnstalleerd worden
- Een bouwblok is voorzien van correcte en passende linters
- Er is een workflow die bij PR's controleert of branches voldoen aan linters en andere voorwaarden
- De algemene codestijl is de WordPress coding standaard. Een repository mag hiervan afwijken, maar moet dit dan documenteren
- Een plugin zou alle tests van de Plugin Check moeten doorstaan
- Documentatie over bouwblokken moet zijn opgenomen bij de code (repository) van het bouwblok
- De readme moet aangeven waar je terecht kunt met issues / vragen
- Documentatie over de code en technische documentatie is in het Engels
- Gebruiksdocumentatie is in het Nederlands
- De voorkant van een bouwblok is in ieder geval beschikbaar in het Nederlands
- Beheert https://github.com/OpenWebconcept
- Beheert afspraken (https://github.com/OpenWebconcept/Afspraken/)
- Aanmaken repositories
- Rechten aan gemeenten geven op repository
- Rechten aan leveranciers geven op repository
- Voor iedere organisatie (gemeente of leverancier) wordt een GitHub team aangemaakt
- Rechten aan leverancier geven op repository
- Garant staan voor de repository
- Plaatst de code in de betreffende repository
- Zorgt dat de bugs worden opgelost
- Handelt de issues / changes af
Alle bijdragen moeten voldoen aan de architectuur principes