Rollen en doorlopend werk
Beheer en doorontwikkeling nuts-node
Status: loopt Waar: #development en #releases
Wat het is
De nuts-node is het kernproduct van de community en draait in productie bij deelnemers. Beheer en doorontwikkeling staan als doorlopend werk in het jaarplan. Binnen dit werk is één rol formeel belegd: het producteigenaarschap, op 13 oktober 2025 met consent bij Rein Krul, als opvolger van Tomas Harreveld en daarvoor Wout Slakhorst. Bij dat besluit is de rol omschreven als aanspreekpunt en verantwoordelijk voor het product in de brede context: techniek, ontwikkeling en support. Wat de rol precies omvat is daarna niet uitgewerkt.
Deze pagina is een reconstructie van de bestaande praktijk, samengesteld uit de GitHub-repositories en de Slack-kanalen. Het is een beschrijving van wat er gebeurt, geen voorstel tot verandering.
Opdracht
Doel. Een nuts-node die veilig, actueel en bruikbaar is voor de partijen die hem in productie draaien, met een voorspelbaar release- en ondersteuningsbeleid.
Scope. De opdracht omvat:
- Backlog en prioritering op basis van lopende projecten, de behoefte van de kring Toepassingen en projecten van de kring zelf
- Releases en versiebeheer, waaronder release candidates wanneer een externe partij een versie moet kunnen vastpinnen, bijvoorbeeld voor een pentest
- Security, waaronder het patchen van CVE's en het beheer van kwetsbaarheden in de images
- Deprecation en migratie, waaronder het uitfaseren van did:nuts en het gRPC-netwerk, en de migratiedocumentatie van v5 naar v6
- Ondersteuning aan node-beheerders en implementaties in het veld, van configuratie- en certificaatvragen tot performanceonderzoek
- Technische documentatie van de node
- Functionele voorstellen met consultatie in de community voordat ze op de backlog komen
- Communicatie richting node-beheerders over releases, kwetsbaarheden en het ondersteuningsbeleid
Buiten scope vallen: het beheer van individuele nodes bij deelnemers, de toepassingen die op de node draaien, en het beheer van de samenwerkingsmiddelen zelf zoals de GitHub-organisatie en de toegangsrechten daarop.
Resultaat. Doorlopend werk zonder einddatum. De kring stuurt via prioritering en kaders, niet via besluiten per issue.
Belegging. Producteigenaar: Rein Krul. Ontwikkeling: Rein Krul en Steven van der Vegt. Externe bijdragen via pull requests staan open voor iedereen. De producteigenaar prioriteert binnen deze opdracht en is aanspreekpunt voor het product; het aanwijzen van mensen en het beleggen van uren is aan de kring.
Werk met een financieel gevolg dat niet in de begroting is voorzien, zoals een security scan of een groter stuk ontwikkelwerk, wordt afgestemd met de producteigenaar. Gaat het om werk van substantiële omvang, dan meldt degene die het oppakt dat in de kring. De inschatting daarvan ligt bij de betrokkene zelf; het gaat om navolgbaarheid achteraf, niet om toestemming vooraf.
Werkwijze. Vragen en meldingen komen binnen via #development en via GitHub-issues. Releases en kwetsbaarheden worden aangekondigd in #releases; node-beheerders wordt gevraagd zich daarop te abonneren. Bij functionele wijzigingen die gebruikers raken wordt eerst een voorstel in de community gelegd voordat het op de backlog komt.
De producteigenaar kan taken uit deze opdracht vrij delegeren, bijvoorbeeld tijdens vakantie of bij piekbelasting. De verantwoordelijkheid voor de rol blijft daarbij bij de producteigenaar; delegatie van de rol zelf is een besluit van de kring.
Vastgelegd beleid
Beleid dat in de praktijk geldt en dat hier expliciet wordt gemaakt:
- Ondersteunde versies. CVE's worden gepatcht op de laatste minor van de twee ondersteunde major-versies. Wie op een lagere minor zit, moet upgraden om security- en bugfixes te ontvangen. Minor-upgrades zijn niet-breaking.
- Major-versies worden bepaald door breaking changes op de API en op de deployment. Een major kan dus ook een enkele noodzakelijke configuratiewijziging zijn.
- Aankondiging. Releases en kwetsbaarheden worden aangekondigd in het releases-kanaal. Node-beheerders zijn zelf verantwoordelijk voor het volgen daarvan.
Te besluiten
- Bevestigt de kring de opdracht zoals hierboven beschreven, als beschrijving van de bestaande praktijk?
- Welke repositories en ondersteunende software vallen onder deze opdracht, en welke zijn deprecated of niet ondersteund? Voorstel is die lijst als bijlage vast te stellen, zodat voor deelnemers duidelijk is waar zij op kunnen bouwen.
- Waar landen inhoudelijk-beleidsmatige besluiten over de node? Het jaarplan constateert dat besluiten over de node vaak grote impact hebben op de kring Toepassingen, maar nergens expliciet als corrigeerbaar beleidsbesluit worden genomen. Het technisch convergentieoverleg in oprichting kan hierin een rol spelen: het brengt de toepassingsverantwoordelijken en de kring bij elkaar en kan besluiten die om een kaderkeuze vragen voorbereiden voor de kring.
- Bevestigt de kring het beleid hierboven, zodat deelnemers zich erop kunnen verlaten?
- Bevestigt de kring de ontwikkelaars zoals hierboven genoemd, en hoe worden nieuwe mensen toegevoegd? Op dit moment volgt dat uit de schrijfrechten op de repositories en niet uit een besluit. Dit hangt samen met de open punten uit het jaarplan over de gedeelde ontwikkelinzet en over de vraag of de uitvoerende ontwikkeling in een subkring hoort.
Samenhang met andere trajecten
- v6-migratie. Het uitfaseren van did:nuts en het gRPC-netwerk raakt het beheer van de node rechtstreeks; de migratiedocumentatie komt uit deze opdracht voort.
- PKIOverheid G4-transitie. De analyse en de eventuele aanpassingen lopen via het producteigenaarschap.
- Technisch convergentieoverleg in oprichting. Beoogde plek om node-besluiten met impact op toepassingen voor te bereiden.
- COT en het knooppunt. De node en het knooppunt worden deels door dezelfde mensen ontwikkeld; de afbakening tussen beide is niet vastgelegd.
- Community-tooling. Het beheer van de GitHub-organisatie, de toegangsrechten en de kanalen valt onder dat werkpakket en niet onder deze opdracht.
- Vernieuwing van de technische documentatie. De node-documentatie valt binnen deze opdracht en binnen het procesvoorstel van het COT.
Bronnen
| Wat | Waar |
|---|---|
| Besluit producteigenaarschap, 13 oktober 2025 | Logboek Kring Techniek |
| Ondersteuningsbeleid voor CVE's en minor-versies, 25 maart 2026 | Slack, #development |
| Toelichting op major-versies en het ontbreken van v7-plannen, 7 mei 2026 | Slack, #kikv-v6-migratie |
| Migratiedocumentatie v5 naar v6 | readthedocs |
| Release notes | readthedocs |
| Repositories | github.com/nuts-foundation |
Wie erbij betrokken zijn
| Rol | Wie |
|---|---|
| Producteigenaar nuts-node | Rein Krul |
| Ontwikkeling | Rein Krul en Steven van der Vegt |
| Achtervang | Steven van der Vegt |
Hoe haak je aan
Vragen over het draaien van een node en meldingen van problemen gaan naar #development. Draai je een node in productie, abonneer je dan op #releases en zorg dat de meldingen daadwerkelijk bij je binnenkomen.
Community-tooling en samenwerkingsmiddelen
Status: loopt Waar: #kring-techniek-aanspreekpunt
Wat het is
De kring ondersteunt de community met de middelen die samenwerking en kennisdeling mogelijk maken: de wiki, de website, de code-repositories, de project-boards, Slack en de bijbehorende accounts, domeinen en certificaten. Dit staat als doorlopend werk in het jaarplan en volgt uit punt 3 en punt 5 van het mandaat.
Deze pagina is een reconstructie van de bestaande praktijk. Het is een beschrijving van wat er is en wat er gebeurt, geen voorstel tot verandering.
Overzicht van de middelen
| Middel | Waar het draait | Waarvoor | Beheer |
|---|---|---|---|
| Wiki | BookStack op Google Cloud | Kringpagina's, documentatie en overzichten | Steven van der Vegt |
| Website | GitHub Pages | Publieke informatie over Nuts | Rein Krul, ondersteunend aan de kring Gezamenlijk Belang |
| Code-repositories | GitHub | Broncode, specificaties, issues en de FHIR IG-builds van de toepassingen | Steven van der Vegt (toegang en security) |
| Project-boards | GitHub | Backlog en voortgang per project | volgt de repositories |
| Docker Hub | Docker Hub | Publicatie van de images | Rein Krul en Steven van der Vegt |
| Slack | Slack | Dagelijkse samenwerking en community-kanalen | Steven van der Vegt |
| Specificaties en RFC's | GitBook | RFC's, bolts en leveranciersspecificaties | Steven van der Vegt |
| Node-documentatie | Read the Docs | Deployment- en beheerdocumentatie van de nuts-node | Steven van der Vegt (omgeving), inhoud volgt het producteigenaarschap |
| Google Workspace | Mailboxen, Docs en Drive | Steven van der Vegt | |
| Domeinnamen, DNS en certificaten | TransIP als registrar | nuts.nl en bijbehorende subdomeinen, de DNS-records en de certificaten daarvoor | Steven van der Vegt |
Van deze middelen zijn Google Workspace, Google Cloud en de domeinnamen betaald. De overige omgevingen zijn kosteloos in gebruik omdat onze software open source is.
Opdracht
Doel. Werkende, veilige en toegankelijke samenwerkingsmiddelen voor de community, met duidelijk beheer en zonder onnodige afhankelijkheden.
Scope. De opdracht omvat:
- Beheer en beschikbaarheid van de middelen hierboven, inclusief het oplossen van storingen
- Toegangsbeheer: wie heeft toegang tot welke omgeving, en het herstellen of intrekken daarvan
- Security op de omgevingen, waaronder de eisen aan twee-factor-authenticatie op de GitHub-organisatie en het rechtenbeheer op de repositories
- Accounts, abonnementen, domeinnamen, DNS en certificaten, inclusief tijdige verlenging en betaling
- Inrichting en structuur van de wiki en de kanalen, zodat informatie vindbaar blijft
- Ondersteuning aan de andere kringen bij het gebruik van deze middelen
Buiten scope valt de inhoud die in deze middelen wordt gepubliceerd. Elke kring en elke opdracht is zelf verantwoordelijk voor de eigen pagina's, documentatie en berichten. De website is daarvan het duidelijkste voorbeeld: het domein communicatie en website ligt bij de kring Gezamenlijk Belang, wij leveren de technische ondersteuning. Ook de PKIoverheid- en UZI-certificaten die deelnemers voor hun eigen node gebruiken vallen hier niet onder; dit gaat om de certificaten van onze eigen omgevingen.
Resultaat. Doorlopend werk zonder einddatum.
Belegging. Zie de kolom Beheer in het overzicht hierboven.
Werkwijze. Verzoeken en storingen komen binnen via #kring-techniek-aanspreekpunt en rechtstreeks bij de beheerders. Waar een wijziging wordt aangekondigd, hangt af van wie hem merkt: bij de gebruikers van de betreffende tool, in #general als het de hele community raakt, en in de kring als het om beleid of om een structurele verandering gaat. Voor de website loopt de afstemming via #website, samen met de kring Gezamenlijk Belang.
Recent beleid
- Twee-factor-authenticatie op de GitHub-organisatie moet via een veilig middel. Sms is niet toegestaan. (april 2026)
- Rechten op repositories zijn aangescherpt. Wie toegang mist die eerder wel bestond, vraagt die aan bij de beheerder. (mei 2026)
Aandachtspunten
De wiki draait op een Google Cloud-omgeving en moet daar weg. Dit is het meest concrete punt op deze pagina. Wat daarvoor nodig is: een keuze voor de nieuwe omgeving, een migratiepad met behoud van de inhoud en de links, en helderheid over wie de omgeving daarna beheert en betaalt.
Afhankelijkheid van Google. Naast de wiki lopen ook de mailboxen, Docs en Drive via Google Workspace. Dat is geen acuut probleem, maar het is de moeite waard om te weten wat de afhankelijkheid is en wat een alternatief zou kosten, mede gezien de uitgangspunten van Nuts.
Beheer hangt op enkele personen. Vrijwel alle omgevingen worden door één persoon beheerd. Er is geen achtervang vastgelegd. Bij domeinnamen, DNS en certificaten weegt dat zwaarder dan elders, omdat een gemiste verlenging direct zichtbaar is voor de hele community.
Te besluiten
- Bevestigt de kring de opdracht zoals hierboven beschreven, als beschrijving van de bestaande praktijk?
- Wie is achtervang per omgeving, zodat beheer niet op één persoon rust?
- Waar gaat de wiki naartoe, en wie werkt dat uit? Voorstel is dit als aparte opdracht te beleggen, met een voorstel terug in de kring.
Samenhang met andere trajecten
- Beheer en doorontwikkeling nuts-node. De repositories, Docker Hub en de node-documentatie worden gebruikt vanuit die opdracht; het beheer van de omgevingen zelf valt hier.
- Toepassingen op Nuts. De FHIR IG-builds van de toepassingen draaien op onze GitHub-omgeving.
- Vernieuwing van de technische documentatie. Het procesvoorstel van het COT raakt de keuze voor tooling en structuur van de documentatie.
- Kring Gezamenlijk Belang. Die kring heeft het domein communicatie en website; de samenwerking daarover loopt via #website.
Hoe haak je aan
Mis je toegang, werkt iets niet, of wil je meehelpen aan het beheer van een van deze middelen, laat het weten in #kring-techniek-aanspreekpunt.