Ga naar hoofdinhoud

Voorbereidingsfase

In het kort

In de voorbereidingsfase leg je alle specificaties en beslissingen vast voordat de component wordt ontwikkeld. Je inventariseert bekende issues, bepaalt welke varianten en design tokens worden meegenomen, stelt de toegankelijkheidscriteria vast, en vertaalt alles naar testbare acceptatiecriteria. Het resultaat is een compleet plan van aanpak dat je deelt met de community voor feedback.

Wat doe je in deze fase?

  • Bekende issues en problemen inventariseren
  • Varianten bepalen en eventueel splitsen
  • Anatomie, semantiek en API vastleggen
  • Design tokens en toegankelijkheidscriteria bepalen
  • Acceptatiecriteria vertalen naar testcases
  • Plan van aanpak delen met de community

Hoelang duurt deze fase? Ongeveer 2-4 weken, afhankelijk van de complexiteit van de component.

Inventariseer bekende issues

Doel: Voorkomen dat bekende bugs en problematische API's worden overgenomen in de Candidate component. Vooraf weten welke breaking changes zijn uitgesteld.

Acties

  1. Verzamel input uit de Community (repositories, Open Hours)
  2. Bepaal welke features meegenomen worden (bespreek met DS Lead en Product Manager, let op consistentie met andere componenten)
  3. Leg vast welke toegankelijkheidsproblemen voorkomen moeten worden
  4. Vertaal hoe bugs voorkomen moeten worden in acceptatiecriteria
  5. Bepaal welke API wijzigingen doorgevoerd worden (risicovolle wijzigingen eerst in community testen)

Documenteer in GitHub Discussion

Zijn er issues bekend?

## Openstaande issues die worden meegenomen voor Candidate


We hebben gekeken bij X Y en Z en de volgende issues zijn bekend voor {naam-component}.


- Link naar issue 1
- Link naar issue 2


We hebben besloten om issue 1, 2, en 3 mee te nemen. Issues 4 en 5 nemen we niet mee want...

Geen issues bekend?

## Openstaande issues die worden meegenomen voor Candidate


We hebben geen openstaande issues gevonden.


### Hebben we een issue gemist?


Laat het in deze Discussion weten.

Zet uitkomsten ook in de GitHub issue:

## Extra features


...


## Extra design tokens


...

🚩 Checkpoint: Bekende issues geïnventariseerd

Versimpel of splits de component

Doel: Versimpel of splits de component zodat er componenten over blijven met een duidelijke use case.

Waarom belangrijk? Dit voorkomt complexe APIs en zorgt ervoor dat de documentatie helder blijft.

Acties

  1. Verzamel alle varianten in een tabel - Maak een overzichtsdocument (bijvoorbeeld in Miro of Figma), verzamel varianten uit implementaties en GitHub discussion, geef naam en beschrijving, voeg screenshots toe.

    Voorbeeld voor Paragraph:

    Paragraph Amsterdam Den Haag DUO Open Formulieren Open Gemeenten Rotterdam RVO Utrecht
    Lead/Big/Header paragraph/Intro-text