Dit document is ook beschikbaar in dit niet-normatieve formaat: pdf
Dit document valt onder de volgende licentie:
Creative Commons Attribution 4.0 International Public License
Dit document beschrijft het Beheermodel van BOMOS.
Dit is de definitieve versie van dit document. Wijzigingen naar aanleiding van consultaties zijn doorgevoerd.
Dit document beschrijft hoe Logius, afdeling Standaarden (Uitvoeringsorganisatie), BOMOS beheert en hoe de bijbehorende governance is ingericht.
BOMOS staat voor 'Beheer en Ontwikkelmodel Open Standaarden. De methodiek is ontstaan uit een samenwerking met verschillende partijen met expertise m.b.t. het open beheren van standaarden. In 2006 heeft de Werkgroep CMO (Community Model Open Standaarden), een werkgroep bestaande uit TNO, Bureau Forum Standaardisatie en Logius aan dit onderwerp gewerkt, dit vormde het startpunt voor de ontwikkeling van BOMOS versie 1 en 2. De methodiek is sindsdien ondergebracht bij Logius en is toe aan een nieuwe versie. Daarnaast is er behoefte aan tooling (op basis van BOMOS) ter ondersteuning van het beheren van stelsels en standaarden. Logius beheerd stelsels en standaarden met behulp van
BOMOS maar de methodiek zelf wordt momenteel niet actief beheerd. Om de methodiek conform BOMOS actief te beheren en door te ontwikkelen zijn we recent gestart met een werkgroep en het schrijven van dit beheerdocument.
Het nut en de werking van de standaard zijn reeds goed beschreven in BOMOS versie 2.
Met BOMOS worden standaardisatiecommunities ondersteund en geïnspireerd bij het structureel vormgeven van het beheer en verdere ontwikkelingen van standaarden.
Het doel is en blijft een duurzame standaard die een bijdrage levert in interoperabiliteit. Duurzaam kan alleen als het ontwikkel- en beheerproces op een kwalitatief hoogstaand niveau is ingericht. Dit document levert een bijdrage om de ontwikkeling en beheer van de standaard op een hoger plan te krijgen en daarmee duurzame standaarden en Stelsels te realiseren. Uiteraard is een duurzame standaard een open standaard die duurzaam beheerd wordt.
De actuele versie van BOMOS 2.0 is op te vinden op xxx door xxx vastgesteld.
Concept versie BOMOS 3.0 moet nog worden vastgesteld.
De laatste concept versie 3.0 BOMOS is gepubliceerd in twee delen: BOMOS Fundament en BOMOS Verdieping
Logius richt de beheerorganisatie in conform het Beheer en OntwikkelModel voor Open Standaarden (BOMOS). Ook dit beheer document is op basis van BOMOS ingericht.
De rol van beheerder en adviseur wordt steeds belangrijker in de digitale samenleving. Aan de hand van de ervaring van verschillende beheerpartijen, willen we het beheer van de afdeling stelsels en standaarden nog effectiever kunnen inrichten en daarmee het draagvlak en de adoptie van de standaarden verhogen. Nog een belangrijke redenen is om interoperabiliteit na te streven om zo effectiviteit en efficiency in het samenwerken te realiseren met bijvoorbeeld beheerorganisatie, toeleveranciers en klanten in de keten. Drie concrete zaken voor de doorontwikkeling van BOMOS: Een nieuwe versie uitbrengen van BOMOS met nieuwe inzichten en een bredere scope dan de huidige versie (de methode wordt in de nieuwe versie bijvoorbeeld ook toegepast op stelsels)
We willen BOMOS de basis maken van ons standaardenbeheer. Bijvoorbeeld de beheerplannen en governance van standaarden beschrijven volgens BOMOS, alsmede offertes voor eventuele nieuwe standaarden om zo meer uniformiteit aan te brengen in het beheer van de standaarden van onze afdeling. Dit verhoogd de kwaliteit van onze processen en documenten en maakt dat we als team sneller en flexibeler kunnen reageren op verzoeken om nieuwe standaarden in beheer te nemen.
We willen onze kennis delen met andere organisaties, die ook standaarden of stelsels beheren, en met hen kennis uitwisselen. Dit is gunstig bij het blijven actualiseren van de BOMOS.
BOMOS is het Beheer- en OntwikkelModel voor Open Standaarden. Het is een instrument dat helpt bij de inrichting van het beheer van open standaarden. Dit maakt BOMOS als het ware een standaard voor het beheren van standaarden. BOMOS bestaat uit een bundeling van best practices en voorbeelden van goed standaardenbeheer. Het is ontwikkeld door de BOMOS-community en voor iedereen vrij te gebruiken.
Bij het beheer van een open standaard hoort een open governance en een open procedure voor belanghebbenden om te kunnen participeren in het beheer. Logius, afdeling Standaarden neemt hierin de rol van onafhankelijke, duurzame beheerpartij en facilitator.
Logius gaat uit van de governance van de Generieke Digitale Infrastructuur (GDI). De GDI geeft richting aan het Meerjarenprogramma Infrastructuur Digitale Overheid (MIDO). Voor MIDO is een governance opgesteld waarin de stakeholders van Logius richting geven aan de ontwikkelingen bij Logius. Standaardenbeheer sluit aan op deze governance. Bij het beheer van BOMOS worden verschillende gremia onderscheiden die gezamenlijkinvulling geven aan de governance op de standaard:
Het is een Operationeel Overleg met periodieke bijeenkomsten (2 x per maand) waarbij de vragen en doorontwikkel wensen m.b.t. BOMOS worden doorgenomen, geprioriteerd en worden uitgewerkt. Daarnaast wordt door de leden de releaseplanning en de roadmap opgesteld en voorgelegd aan het AG.
Het is een Technisch Overleg met periodieke bijeenkomsten (1 x per kwartaal) waarbij de vragen en doorontwikkel wensen m.b.t. BOMOS worden doorgenomen, geprioriteerd, uitgewerkt en vastgelegd. Dit gremium is verantwoordelijk voor het vaststellen van het van beheermodel van de standaard, de externe publicaties, de doorontwikkel-roadmap en het vaststellen van releases van de standaard, en dient als het voorportaal van het strategisch/besluitvormende gremium.
Dit is het hoogst ambtelijke gremium dat besluit over major releases van de standaard. Major releases die grotere financiele impact hebben gaan via de BG. Het BG is momenteel nog niet actief m.b.t. BOMOS waardoor de UG bij wijzigingen aan de standaard, de nieuwe versie eerst voorlegt aan het AG voor het borgen van een zo breed mogelijke afstemming met verschillende belanghebbenden.
N.B. De definitieve invulling van de strategische laag wordt in 2023 duidelijk.
Dit is het meest operationele gremium waarin iedere belangstellende/belanghebbende vragen kan stellen, advies kan geven en suggesties kan doen voor de doorontwikkeling van BOMOS. Deelname aan de Community is vrij voor eenieder die een belang heeft bij de standaard (overheid, wetenschap en markt ). Dergelijke vragen en suggesties worden door Logius verzameld en voorgelegd aan het UG en AO.
BOMOS sluit aan op de MIDO governance op strategisch niveau. Voor de governance van BOMOS zelf zijn meer governance lagen nodig, met name voor tactisch en operationeel niveau. BOMOS beheer omvat de volgende gremia:
Bestuur groep:
Deelnemers Adviesorgaan/klankboordgroep:
Uitvoeringsgroep:
De BOMOS Community:
Is geen vast gremium, dit kunnen verschillende beheersorganisaties zijn die deel willen nemen aan de BOMOS Community. Alle beheer organisaties mogen hierin mee participeren.
Het huishoudelijk regelement en de besluitvormingsprocessen van de governance zijn beschreven. In deze beschrijving is duidelijk welk gremium over welke onderwerpen gaat. Voor iedereen moet helder zijn op welke manier, binnen welk tijdskader en door wie beslissingen worden genomen. Dit geldt zowel voor de meer strategische besluiten als voor de operationele afstemming. Voor elk onderdeel van de governance moet worden beschreven hoe de besluitvorming is ingericht. Daarbij is alleen meerderheid of consensus besluitvorming toegestaan. Waarbij aangegeven kan worden of er meerdere stemmingsronden mogelijk zijn.
Het Logius adviesorgaan bestaat uit vertegenwoordigers van publieke organisaties, bestaande uit twee standaardisatie specialisten en een aantal adviseurs. De leden werken in verschillende beheerorganisaties zoals hierboven omschreven. Het adviesorgaan adviseert het bestuur over de inhoud en prioriteiten voor het basisprogramma en het beheer van BOMOS. Voor het basisprogramma en het beheer van BOMOS, treedt het adviesorgaan BOMOS AG op als stuurgroep. Het Adviesorgaan AG beoordeelt en beslist over wijzigingsvoorstellen en stelt een nieuwe (versie) van BOMOS vast die bij Logius is in beheer is. Het adviesorgaan is ook aanspreekpunt voor klachten over het beheer van BOMOS door Logius. In de werkgroepen wordt inhoudelijk en praktijkgerichte kennis uitgewisseld, de samenwerking met andere standaardisatieorganisaties is een belangrijk onderdeel voor de doorontwikkeling en beheer van BOMOS.
Er is transparante besturing op strategisch niveau aanwezig die past bij de ambities van de standaard.
Het operationeel beheer van BOMOS wordt uitgevoerd door de beheerorganisatie Logius. Er is een BOMOS community verdeeld in drie lagen met bijbehorende beraden waarin afvaardigingen van deelnemers en dienstverleners van de beheerorganisaties zitting hebben:
Strategisch niveau - OBDO/MIDO (programmeringstafel Infrastructuur), Het bureau Forum Standaardisatie en het Adviesorgaan BOMOS.
Het Adviesorgaan BOMOS heeft ook een formele rol op strategisch niveau en is aanwezig om het bestuur kennis inhoudelijk te ondersteunen.
Tactisch niveau - Porfoliomanager Logius (programmeringstafel Infrastructuur), Het Bureau Forum Standaardisatie en het Adviesorgaan. Het Adviesorgaan BOMOS heeft ook een formele rol op strategisch niveau en is aanwezig om het bestuur kennis inhoudelijk te ondersteunen.
Operationeel niveau- Adviesorgaan BOMOS, Uitvoeringsorganisatie Afdeling Standaarden, Adviesorgaan/klankbord BOMOS en BOMOS Community welke bestaan uit deelnemers van de beheersorganisaties.
Het is duidelijk hoe stakeholders betrokken worden en hoe ze mee kunnen participeren en wat hun rol daarbij is. Relevante typen stakeholders moeten een plek kunnen krijgen ergens in de gekozen structuur van het stelsel, en niet principieel worden buitengesloten. Dat wil niet zeggen dat elk type stakeholder per definitie dezelfde rechten en plichten heeft. Zorg daarnaast ervoor dat binnen die groepen vooral organisaties aangesloten zijn die zich committeren aan de doelstellingen van de standaard.
Betrokkenheid van de Community bij de verdere ontwikkeling van de standaard is voor het gebruik en de draagvlak ervan van groot belang. Voor de standaard geldt dat geen onderscheid wordt gemaakt tussen publieke en private organisaties en bijvoorbeeld kennisinstellingen. Zij vormen samen de community. Aan de inspraak in het wijzigingsproces zijn voor hen geen kosten verbonden. Logius informeert en betrekt de community via de website en de verschillende nieuwsbrieven. Uit de community worden de werkgroepen gevormd op het moment dat dit benodigd is. De vergaderdata en verslagen van deze werkgroepen zijn beschikbaar voor een ieder via BOMOS Fundament en BOMOS Verdieping. Inschrijven voor bijeenkomsten is mogelijk via xxxxx (via toekomstige weblink)
Betrokkenheid van belangenorganisaties is van cruciaal belang vanwege het feit dat ze vaak optimaal hun achterban kunnen bereiken en vertegenwoordigen. Alle relevante belangenorganisaties moeten dan ook betrokken zijn, en waar mogelijk moeten partnerschappen worden gesloten op het gebied van communicatie
De afdeling Standaarden van Logius werkt samen met andere beheerorganisaties, dit kunnen verschillende type beheerorganisaties zijn, hierin wordt geen onderscheid gemaakt. Een brede samenwerking en kennisgebied is in het belang van de standaard maar ook in het belang van de beheerorganisatie zelf. Daarom zorgt de Uitvoeringsorganisatie (afdeling Standaarden) en het Adviesorgaan BOMOS ervoor dat belanghebbende beheerorganisaties worden betrokken bij verschillende activiteiten en overlegvormen. De activiteiten of overleggen kunnen workshops zijn, werkgroep overleggen voor wijzigingen of klankboardgroepen voor het uitwisselen van kennis.
Zowel de opdracht van de werkgroep als de wijze waarop over de resultaten en uitdagingen gerapporteerd wordt zijn beschreven.
Nieuwe ideeën of wijzigingsverzoeken komen binnen bij de Uitvoeringsorganisatie (afdeling Standaarden) van Logius via BOMOS Fundament en BOMOS Verdieping, of via contacten in het netwerk van de medewerkers van de afdeling Standaarden of Stelsels. Zodra een nieuw initiatief zich aandient, in de vorm van een opdracht, zorgt de afdeling Standaarden ervoor dat het adviesorgaan hiervan op de hoogte wordt gesteld en er een werkgroep wordt opgezet.
Jaarlijks wordt bepaald welk deel van de basisfinanciering besteed wordt aan het standaardisatiewerk en daarmee het beheer van de standaarden.
Het beheer van BOMOS standaard wordt gefinancieerd door het ministerie van BZK in het kader van de financiering van Logius dienstverlening.
Deelname aan de community kent geen drempels of restricties. De leden van de community werken in verschillende beheerorganisaties en kunnen alle informatie m.b.t. de standaard en het beheer daarvan inzien via de website en issues of RFC's melden. Het Logius adviesorgaan behandeld deze issues of RFC's. In de community en werkgroepen wordt inhoudelijk en praktijkgerichte kennis uitgewisseld, de samenwerking met andere standaardisatieorganisaties is een belangrijk onderdeel voor de doorontwikkeling en beheer van BOMOS.
De belangrijkste toepassing van BOMOS is als hulpmiddel voor de verdere ontwikkeling van beheerorganisaties. De standaard is een op zichzelf staande open standaard en geen onderdeel van een bovenliggende standaard of stelsel. Er is dus geen afhankelijkheid met andere beheerorganisaties van stelsels of standaarden. De samenwerking met andere standaardisatieorganisaties is wel een belangrijk onderdeel voor de doorontwikkeling en beheer van BOMOS.
Afgeleid van de doelstellingen is voor de standaard een ontwikkelagenda opgesteld waarmee invulling wordt gegeven aan de geformuleerde visie. Uit het overzicht hieronder kun je opmaken welke ontwikkeling op welk moment in de tijd gerealiseerd gaat worden.
Gremium | Accent | Rol participant | Ondersteuning door beheerder (Logius) |
---|---|---|---|
BOMOS Community (omvang onbeperkt Operationeel 2x Per jaar) |
Inhoud – delen | Samen met alle leden van de community: 1. Volgen van ontwikkelingen. 2. Leveren van input voor de doorontwikkeling van de standaard. |
1. Informatie m.b.t. specificaties en beheer open delen met community. 2. Deelnemen aan BOMOS klankbordgroep 3. Organiseren bijeenkomsten. |
BOMOS Klankbordgroep (Tactisch 4x per jaar) |
Inhoud – afstemmen –adviseren en beluit | Samen met andere experts van de beheer organisatie: 1. Inhoudelijk ontwikkelen van standaard onderdelen en bijbehorende documentatie. 2. Voorbereiden van de release-planning. 3. Prioriteiten stellen voor de ontwikkeling, roadmap van nieuwe releases van de standaarden. 4. Goedkeuring van aanpassingen op de standaard. 5. Vaststellen externe publicaties over het standaardenbeleid en releases. 6. Vaststellen beheermodel van de standaard. |
1. Informatie m.b.t. specificaties en beheer open delen met community. 2. Analyseren, ontwerpen en uitwerken van specificaties. 3. Volgen en beïnvloeden van standaarden of modules 4. Organiseren bijeenkomsten. 5. Beschikbaar stellen specificaties en publicaties |
Directie Digitale Samenleving (Strategisch besluitvormend, 2x per jaar) |
Bestuurlijk besluit | Samen met andere bestuurders: 1. Vaststellen budget van BOMOS. 2. Vaststellen beheermodel van de standaard. |
1.Begeleiding van de Adviesraad |
Een pilot is onderdeel van de adoptiestrategie om de verschillende stakeholders te overtuigen van de meerwaarde van de standaard. Dit doen we doormiddel van het aanbieden van een assessment. Hiervoor is tooling ingericht en beschikbaar gesteld op de Logius website. Met deze tool kun je d.m.v. het invullen van een vragenlijst inzicht krijgen in de mate van volwassenheid van het beheer van een standard of stelsel. De resultaten kunnen positief bijdragen aan het draagvlak van een standaard of stelsel en tevens bijdragen aan verbetering van de kwaliteit.
Het gebruik van BOMOS is niet vanzelfsprekend. De toepassing en het beheer ervan in praktijk brengen is ons uiteindelijke doel. De community en werkgroepen zijn hierbij van wezenlijk belang. Voor de adoptie en erkenning van de standaard door het werkveld, heeft Logius, de standaard ook aangeboden ter publicatie aan de beheersorganisatie en aan het Forum Standaardisatie. Zij adviseren ook in het gebruik van de standaarden. In samenwerking met de beheerorganisaties welke deelnemen aan de werkgroepen en aan de community streven wij naar adoptie en erkenning.
De Standaard zelf en dit beheermodel vallen onder de Creative Commons licentie (Creative Commons Attribution 4.0 License) Dit houdt in dat het is toegestaan om deze documenten te gebruiken, verder te verspreiden en aan te passen. Dit werk en de specificaties van de standaard worden royaltee-free ter beschikking gesteld. Organisaties en personen die bijdragen aan de standaard dienen dit onder dezelfde voorwaarden te doen als bij het originele werk. Door bij te dragen aan de standaard verklaren zij hiermee in te stemmen.
Het beheer van de standaard wordt volledig open ingevuld. Dit borgt dat zoveel mogelijk belangstellenden en belanghebbenden betrokken zijn bij wijzigingen en besluitvorming.
Uitbreidingen en aanpassingen in de standaard komen tot stand door participatie van de verschillende belanghebbenden. Belanghebbenden kunnen op vier manieren participeren: als lid van de BOMOS Community en/of de Advies Groep en/of als lid van de Bestuur groep.
RFC's kunnen binnen komen via verschillende kanalen rechtstreeks bij Logius, tijdens overleggen, via de website of mail.
Vanuit verschillende overleggen:
BOMOS Community - Operationeel
Uitvoeringsorganisatie (Uitvoering Groep - UG) Operationeel
Adviesorgaan BOMOS (Advies Groep - AG) Tactisch
Directie Digitale Samenleving (Bestuur groep - BG) Strategisch
RFC's worden als issue's in de repository van het kennisplatform BOMOS op Github:BOMOS Fundament of BOMOS Verdieping geregistreerd als deze vanuit de BOMOS Community of Adviesorgaan binnenkomen. Komt het rechtstreeks vanuit Logius zelf binnen dan worden deze in Confluence of Jira geregistreerd. Om te voorkomen dat er verschillende lijsten met issues en verzoeken ontstaan, is afgesproken dat ieder issue en verzoek als eerste wordt beoordeeld door een lid van de Uitvoeringsorganisatie en BOMOS adviesorgaan zorgt voor het overzicht van de stromen met RFC's.
Dit houdt concreet in dat RFC's die rechtstreeks bij Logius afdeling standaarden worden neergelegd, door een lid van de Uitvoeringsorganisatie en het BOMOS adviesorgaan wordt opgepakt en doorgespeeld aan de BOMOS werkgroep zodat daar de eerste beoordeling kan plaatsvinden.
De procedure van RCF naar daadwerkelijke wijziging ziet er als volgt uit:
Issues die in behandeling worden genomen worden als RFC gelabeld
RFC's worden besproken en uitgewerkt door de Uitvoeringsorganisatie Logius afdeling Standaarden (Uitvoering Groep - UG)
RFC's worden vastgesteld in het Adviesorgaan BOMOS (Advies Groep - AG) Tactisch
RFC worden na vaststelling door de Directie Digitale Samenleving (Bestuur groep - BG) Strategisch geconsulteerd en na vaststelling volgt publicatie van de nieuwe versie van standaard
Logius, afdeling standaarden onderscheidt twee statussen die BOMOS kan hebben:
Afkorting | Status van de standaard | Beschrijving van de status |
---|---|---|
IO | In Ontwikkeling | Een nieuwe release van de standaard is "In Ontwikkeling" wanneer er met medeweten en medewerking van participanten (BOMOS Community en klankbordgroep) aan gewerkt wordt en wanneer dit onderdeel of deze release nog niet voor de buitenwereld is gepubliceerd. |
IG | In Gebruik | Als een nieuwe release van de standaard gereed is, en is bestendigd door de Directie Digitale Samenleving, stelt de BOMOS klankbordgroep de status 'In Gebruik' vast. Hierna wordt de nieuwe release gepubliceerd zodat alle gebruikers hiervan kunnen profiteren. |
Alle documenten m.b.t. de standaard en het beheer van de standaard worden openbaar en zonder drempels voor gebruik, gepubliceerd op logius.nl, Github en Confluence pagina's. Logius publiceert tenminste de volgende documenten:
Versie 3.0 van BOMOS is gepubliceerd op: BOMOS Fundament en BOMOS Verdieping. En vindbaar via de Logius website
Logius biedt momenteel geen opleiding aan, maar borgt dat de informatie m.b.t. de standaard altijd, zonder drempels, toegankelijk is via de Logius website of via Github, zie hiervoor 4.5 Documentatie. Bovendien kunnen geïnteresseerden via verschillende kanalen contact opnemen met Logius in geval van vragen of opmerkingen. Zie hiervoor 5.2 Helpdesk.
Aanvullend organiseert Logius afdeling Stelsels een e-learning waarin handreikingen worden gegeven over het verschil tussen standaarden en stelsels en hoe het beheer op basis van BOMOS ingericht kan worden.
Verder worden er regelmatig overleggen gepland en streven naar een jaarlijkse seminar m.b.t. BOMOS.
Logius biedt ondersteuning en advies via verschillende kanalen:
Online: als reactie op issue's in de Github repository van het Kennisplatform
Algemeen Contactformulier: Algemeen contactformulier Logius
Telefonisch: 0900 - 555 45 55
Per post: Logius, Postbus 96810; 2509 JE Den Haag, (t.a.v. Standaarden).
Met BOMOS worden standaardisatiecommunities ondersteund en geïnspireerd bij het structureel vormgeven van het beheer en verdere ontwikkelingen van standaarden. BOMOS is niet verplicht en is ook geen conformiteitsbeoordeling.
Logius is promotor van de standaard. Zowel intern voor de toepassing van de standaard in Logius voorzieningen als extern, door andere partijen te informeren en adviseren over de mogelijkheden van de standaard. BOMOS wordt via verschillende kanalen gepromoot. Ten eerste via de Logius website en het Kennisplatform BOMOS. Naast communicatie op de website en op het kennisplatform, organiseert Logius als uitvoeringsorganisatie vrij toegankelijke bijeenkomsten voor de community, werkgroep en adviesorgaan. Daarnaast promoot ook Forum Standaardisatie actief het gebruik van BOMOS.
Als een nieuwe versie van BOMOS de status "In Gebruik" heeft, worden verschillende zaken gepubliceerd. Logius publiceert altijd de volledige specificatie van de standaard op een deel van de Logius website. Aanvullend publiceert Logius alle genoemde documentatie.
Klachten over de opzet of de uitvoering van het beheerproces kunnen ingediend worden bij Logius. Dit kan in principe via alle beschikbare kanalen, zie kanalen bij Helpdesk. De indiener van de klacht krijgt zo spoedig mogelijk en altijd terugkoppeling over de voortgang van en beslissing over zijn klacht. Het adviesorgaan BOMOS is aanspreekpunt voor klachten over het beheer van BOMOS door Logius.
Voor publicatie van de standaarden die bij Logius en beheer zijn wordt gebruik gemaakt van ReSpec. ReSpec is een applicatie om technische documentatie te maken die publiceerbaar is op het internet en gemakkelijk kan worden geïndexeerd door zoekmachines om de documentatie vindbaar te maken. Het is ontwikkeld ten behoeve van de documentatie van W3C standaarden. Door gebruik te maken van ReSpec publiceren we documentatie overeenkomstig een (de facto) W3C standaard.
ReSpec is een Javascript applicatie. Input voor ReSpec bestaat uit teksten in HTML of Markdown, zie [RFC7763]. ReSpec combineert een serie input files tot één documentatiedocument in HTML met een duidelijke inhoudsopgave en kruisverwijzingen naar de verschillende secties en figuren.
ReSpec is ontwikkeld door een werkgroep van W3C en wordt actief doorontwikkeld.
Logius heeft een eigen profiel gemaakt op ReSpec om Logius organisatiespecifieke zaken, zoals layout, te ondersteunen. Wijzigingen in de W3C versie worden regelmatig doorgevoerd in de Logius versie.
De Logius ReSpec versie is zo algemeen mogelijk gemaakt zodat deze door andere overheden in Nederland eenvoudig toegepast kan worden. In de Logius versie gebruiken we zoveel mogelijk input in Markdown formaat.
ReSpec maakt gebruik van de online Specref database van Literatuurverwijzingen. Deze database bevat referenties naar, onder andere, referenties voor de W3C documentatie.
Voor Nederlandse documenten die niet in Specref staan maken we gebruik van een standaard literatuurlijst die voor alle documenten gebruikt kan worden en die apart beheerd wordt. Het beheer is onder meer nodig om links naar online documentatie bij te houden.
GitHub biedt functionaliteit om documenten te publiceren vanuit een repository. Logius gebruikt deze functionaliteit om het met ReSpec gegenereerde document te publiceren als HTML-document en een PDF-document. Deze documenten worden automatisch gekopieerd naar een publicatiewebsite onder beheer van Logius.
Het proces zoals beschreven onder operationeel beheer, wensen en eisen wordt voor de Logius standaarden geïmplementeerd door gebruik te maken van GitHub issues. Een issue kan binnen GitHub ingediend worden door iedere (GitHub)gebruiker en wordt bij ontwikkeling van code gebruikt om functionele wensen of gevonden bugs in te dienen zodat deze door ontwikkelaars opgepakt kunnen worden. Een issue kan online besproken worden en uiteindelijk gesloten worden wanneer deze verwerkt is.
Binnen het standaardenbeheer bij Logius maken we gebruik van verschillende branches. De main branch bevat de laatste formeel geaccepteerde versie van een document. De develop branch bevat een werkversie met daarin alle wijzigingen die in een volgende geaccepteerde versie opgenomen moeten worden.
Aanpassingen in de documentatie die voor een specifiek wijzigingsvoorstel gemaakt worden worden in een eigen branch verwerkt. Deze branch wordt gesplitst vanaf de develop branch en wordt nadat het wijzigingsverzoek aangenomen is teruggebracht naar de develop branch. Voorbeeld: een wijzigingsverzoek voor het aanpassen van de architectuurbeschrijving zal in een branche nieuwe architectuur worden verwerkt. Deze wordt gesplitst vanaf, en teruggebracht naar, de develop branch. Door wijzigingen in een eigenaarbranch op te nemen zijn alle wijzigingen op de documentatie inzichtelijk per wijzigingsvoorstel.
De develop branch wordt dus niet gebruikt om wijzigingen op het document te maken maar dient als verzamelbranch voor de verschillende wijzigingen die in een volgende release moeten komen.
Om GitHub issues te classificeren en te agenderen voor het juiste overleg maken we gebruik van een aantal standaard labels. We labelen binnenkomende issues als
TODO: beschrijving patching operationeel
GitHub ondersteunt automatisering van taken door scripts. Standaard is de publicatie via github pages. Binnen de Logius standaarden maken we gebruik van scripts om documenten te publiceren, links te checken en om een paar eenvoudige tests op digitoegankelijkheidseisen uit te voeren.
Deze bijlage beschrijft de versioneringsmethodiek ofwel de standaard manier om om te gaan met versienummers van de standaard. De versioneringsmethodiek is gelijk voor alle 'gepubliceerde standaarden' die onder beheer zijn van Logius (afdeling standaarden) en is gebaseerd op Semver. Semver staat voor Semantisch Versioneren en we gebruiken versie 2.0.0 van de standaard zoals gepubliceerd op specificatie van Semantisch Versioneren (SEMVER).
Dat wil zeggen we kennen een bepaalde betekenis toe aan Major,Minor en Patch wijzigingen voor de standaarden zodanig dat de versienummers informatief zijn voor het type wijziging. Aandachtpunt hierbij is dat semantische versionering voor standaarden anders werkt dan semantische versionering voor software. De versienummers voor standaarden drukken uit of een (implementatie) van een oude versie van de standaard voldoet aan de regels van de nieuwe standaard (en dus compliant is aan de nieuwe versie) of niet. Het voordeel van deze manier van versioneren is dat het versienummer signaleert of een implementatie van een bepaalde versie van de standaard voldoet aan een andere (nieuwe) versie van de standaard of dat er sprake is van nieuwe / gewijzigde regels waar aktie op moet worden ondernomen om compliant te zijn aan deze versie.
De beschreven methodiek is van toepassing op de standaarden die Logius in beheer heeft. In de tekst worden Digikoppeling standaarden als voorbeeld aangehaald maar semantische versienummering is ook op de andere standaarden van toepassing.
Per document wordt met [documentnaam] X.Y.Z
de versie aangegeven.
Met X.Y.Z
wordt gerefereerd aan major (X) en minor (Y) releases en (Z) patches,
dit wordt hieronder toegelicht.
In een patchrelease worden wijzigingen doorgevoerd die de technische specificatie niet raken. Dit kunnen tekstuele wijzigingen zijn of inhoudelijke indelingen van de documenten. De wijzigingen worden vastgelegd in release notes. Een patch releases wordt door de beheerder op eigen initiatief of op aanwijzingen van gebruikers doorgevoerd en gepubliceerd. Een patchrelease wordt aan het Technisch Overleg ter kennisgeving medegedeeld. Een nieuwe patchrelease vervangt een eerdere versie in zijn geheel.
Een minor release geeft aan dat de nieuwe versie van de standaard zodanig is gewijzigd dat een implementatie van de voorgaande versie van de standaard voldoet aan de regels van de nieuwe versie. In een minor release kunnen wijzigingen doorgevoerd worden die de technische specificatie van een koppelvlak raken. Dat kunnen fouten zijn in de specificatie zijn of bv het verlichten van een restrictie. In de SEMVER aanpak voor software zijn minor releases technisch backwards compatible. Voor de uitwisselingsstandaarden zoals Digikoppeling is backwards compatibility lastiger te bepalen omdat uiteindelijk twee partijen met elkaar moeten meebewegen. Minor Releases kunnen dus mogelijk technisch backwards incompatible zijn. Voor Minor Releases wordt een uitgebreid vaststellingsprocedure gevolgd (conform het beheermodel van de standaard) en er kan in overleg met de deelnemers van het Technisch Overleg tot een migratiepad worden besloten. Dit migratiepad wordt in de release meegenomen.
Een major release geeft aan dat de nieuwe versie van de standaard zodanig is gewijzigd dat een implementatie van de voorgaande versie van de standaard niet voldoet aan de regels van de nieuwe versie. Bijvoorbeeld de overgang naar nieuwe externe (meestal internationale) standaarden binnen een bestaand profiel. Als hierbij het functionele toepassingsgebied van de standaard, waarvoor het pas-toe-of-leg-uit regime geldt, verandert, dan wordt eerst de uitgebreide vaststellingsprocedure gevolgd en vervolgens de procedure van het Forum Standaardisatie.
Een versie van een standaard (versie 1.2.0) is compatible met een eerdere versie van een standaard (versie 1.1.0) als uitwerkingen/ implementaties volgens de eerdere versie 1.1.0 ook volledig voldoen aan de normen en eisen van versie 1.2.0 . Wijzigingen in de standaard kunnen impact hebben op de technische werking van implementaties en/of op afspraken die de technische werking van implementaties niet raken bijvoorbeeld organisatorische of proces afspraken;
Voor standaarden is relevant of een realisatie volgens de oude versie van een standaard wel of niet voldoet aan de nieuwe versie van de standaard; Globale regels voor het bepalen van de impact op de versionering:
Voor standaarden waarbij wijzigingen op onderdelen kan verschillen tussen major en minor kan een impactmatrix opgesteld worden waarmee impact op de onderdelen gespecificeerd kan worden.
Wanneer een nieuwe major versie uitkomt zal de oude versie conform de afgestemde migratiepad een einddatum van geldigheid krijgen. In de overgangsperiode kunnen dus meerdere versies gepubliceerd zijn en de status geldig hebben.
Om te kunnen werken aan publicatie-, werk- en voorstelversies van documenten worden Git branches gebruikt.