ls-bomos

CONCEPT — Let op: Deze skill is geen officieel product van Logius. De beschrijvingen zijn informatieve samenvattingen — niet de officiële standaarden zelf. De definities op forumstandaardisatie.nl en Logius zijn altijd leidend. Overheidsorganisaties die generatieve AI inzetten dienen te voldoen aan het Overheidsbreed standpunt voor de inzet van generatieve AI. Zie DISCLAIMER.md en onze verantwoording.

BOMOS - Beheer- en Ontwikkelmodel voor Open Standaarden

Agent-instructie: Deze skill helpt bij het opzetten en beoordelen van beheermodellen voor open standaarden conform BOMOS. Gebruik het template en de checklist om een beheermodel op te stellen. Gebruik gh commando's om actuele content op te halen uit de BOMOS repos.

Versiemodel

Net als andere Logius-standaarden kent BOMOS twee publicatiekanalen:

• Vastgestelde versie (DEF): officieel goedgekeurd, gepubliceerd op gitdocumentatie.logius.nl
• Werkversie (draft): werk-in-uitvoering, gepubliceerd op logius-standaarden.github.io

BOMOS is geen interoperabiliteitsstandaard en staat niet op de 'pas-toe-of-leg-uit'-lijst van het Forum Standaardisatie. Het is een raamwerk voor het beheren van open standaarden.

Repositories

Kerndocumenten (met vastgestelde versies)

Repository	Beschrijving	Licentie	Vastgesteld	Draft
BOMOS-Fundament	Kernmodel: activiteiten, rollen, structuur	CC-BY-4.0	v3.0.2	Draft
BOMOS-Verdieping	Verdiepende beschrijving van BOMOS activiteiten	CC-BY-4.0	v3.1.0	Draft

Aanvullende modules en documenten (alleen werkversies)

Repository	Beschrijving	Licentie	Publicatie
BOMOS-Aanvullende-Modules	Aanvullende modules voor specifieke aspecten — gearchiveerd	CC-BY-4.0	-
BOMOS-LinkedData	Module: beheer van Linked Data standaarden	CC-BY-4.0	Draft
BOMOS-OpenSource	Module: open source governance — gearchiveerd	W3C Software and Document License	Draft (bevroren)
BOMOS-Stelsels	Module: beheer van stelsels van standaarden	CC-BY-4.0	Draft
BOMOS-Beheermodel	Beheermodel voor BOMOS zelf	CC-BY-4.0	Draft
BOMOS-voorbeeld-beheermodel	Voorbeelddocument voor een beheermodel	CC-BY-4.0	Draft
BOMOS-Community	Community-aspecten van standaardenbeheer	CC-BY-4.0	Draft
Logius-Beheermodel	Overkoepelend beheermodel van Logius	CC-BY-4.0	Draft

Wijzigingsbeheer Workflow

De RFC-procedure (Request for Change) is het kernproces voor wijzigingsbeheer. Gebruik GitHub issues om wijzigingsverzoeken in te dienen en te volgen.

# Open RFC's bekijken
gh issue list --repo logius-standaarden/[STANDAARD] --label RFC

# Nieuwe RFC indienen
gh issue create --repo logius-standaarden/[STANDAARD] \
  --title "RFC: [korte omschrijving]" \
  --label RFC \
  --body "## Probleem\n[beschrijving]\n\n## Voorstel\n[oplossing]\n\n## Impact\n[gevolgen voor implementaties]"

# RFC status opvragen
gh issue view [NUMMER] --repo logius-standaarden/[STANDAARD]

# RFC's op prioriteit sorteren
gh issue list --repo logius-standaarden/[STANDAARD] --label RFC --json number,title,labels,updatedAt

# Zoeken naar goedgekeurde RFC's
gh issue list --repo logius-standaarden/[STANDAARD] --label RFC --label accepted --state closed

Proces: RFC indienen → Community review → Expert beoordeling → Autorisator besluit → Implementatie → Publicatie nieuwe versie

Beheermodel Template

Een BOMOS-conform beheermodel bevat minimaal de volgende secties. Gebruik het BOMOS-voorbeeld-beheermodel als startpunt.

Document Structuur

# Beheermodel [Naam Standaard]

## 1. Strategie
### 1.1 Governance
- Besluitvormingsstructuur (wie beslist over wijzigingen?)
- Samenstelling gremia (technisch overleg, stuurgroep)
- Vergaderfrequentie en besluitvormingsprocedure

### 1.2 Visie
- Doelgroep en toepassingsgebied
- Langetermijnvisie (3-5 jaar)
- Gewenste marktpositie en adoptiegraad

### 1.3 Financiering
- Begrotingsmodel en financieringsbronnen
- Kostenverantwoording

## 2. Tactiek
### 2.1 Architectuur
- Technische en functionele keuzes
- Samenhang met andere standaarden

### 2.2 Specificatiebeheer
- Versiebeheer (semantic versioning)
- Onderhoud van specificatiedocumenten

### 2.3 Wijzigingsbeheer
- RFC-procedure (Request for Change)
- Indienen, beoordelen en doorvoeren van wijzigingen
- GitHub issue workflow

### 2.4 Adoptiestrategie
- Forum Standaardisatie "pas-toe-of-leg-uit"
- Promotie en outreach

### 2.5 Kwaliteitsbeleid
- Kwaliteitscriteria voor de standaard
- Review- en testprocessen

### 2.6 Rechtenmanagement
- Licentiemodel (bijv. CC0, CC-BY)
- Intellectueel eigendom

## 3. Operationeel
### 3.1 Ontwikkelproces
- GitHub-based workflow
- Branch strategie en PR-reviews

### 3.2 Documentatie
- ReSpec publicatie
- Release notes bij elke versie

## 4. Implementatieondersteuning
### 4.1 Helpdesk
- Contactkanalen (GitHub issues, email)
- Responstijden

### 4.2 Referentie-implementaties
- Beschikbare tooling en voorbeelden

### 4.3 Validatie
- Beschikbare testtools en linters

## 5. Communicatie
### 5.1 Publicatie
- Website en GitHub Pages
- Verspreiding via Forum Standaardisatie

### 5.2 Community
- Werkgroepen en bijeenkomsten
- Bijdragerichtlijnen

BOMOS Conformiteit Checklist

• Governance - Besluitvormingsstructuur beschreven
• Visie - Doelgroep en toepassingsgebied vastgelegd
• Financiering - Begrotingsmodel aanwezig
• Architectuur - Technische keuzes en samenhang beschreven
• Specificatiebeheer - Versiebeleid vastgelegd
• Wijzigingsbeheer - RFC-procedure beschreven
• Adoptiestrategie - Plan voor adoptiebevordering
• Kwaliteitsbeleid - Criteria en reviewproces beschreven
• Rechtenmanagement - Licentie en IP-beleid vastgelegd
• Ontwikkelproces - Werkwijze beschreven
• Documentatie - Publicatie- en versieproces vastgelegd
• Helpdesk - Contactkanalen en responstijden
• Referentie-implementaties - Beschikbare tooling beschreven
• Validatie - Testtools en conformiteitstests
• Publicatie - Distributiekanalen beschreven
• Community - Participatiemodel beschreven

Een organisatie werkt conform BOMOS wanneer voor elke activiteit een bewuste beschrijving is opgenomen, ook als die beschrijving is: "deze activiteit vullen wij (nog) niet in."

Achtergrondinfo

Zie reference.md voor het activiteitenmodel, rollen, levensfasen, pressure cooker model, en praktijkvoorbeelden. Zie conflicts.md voor bekende discrepanties tussen GitHub-tags en gepubliceerde versies.