Candidate stappenplan samenbrengen

[jeffreylauwers]

TLDR

We hebben de eerste Candidate componenten staan en tijdens dit proces veel geleerd. En er is documentatie per Checkpoint geschreven. Nu is het tijd om dit samen te brengen zodat er 1 document is voor het Candidate stappenplan dat op de documentatie website getoond kan worden.

Acties

• Documentatie die is geschreven verzamelen.
• Met het team de Checkpoints en bijbehorende documentatie doorlopen. Dat doen we door vooraf 'huiswerk' mee te geven in Slack canvas. Het huiswerk is het huidige stappenplan in zijn geheel doornemen en de volgende vragen te beantwoorden:
  • Wat kan er beter?
  • Wat moet anders?
  • Wat mist er nog?
  • Klopt de volgorde van de checkpoints of moeten ze veranderd worden?
  • Wie kan/moet iets reviewen? Denk aan code en design.
  • Hoeveel tijd heb je nodig?
• Moment inplannen om bij elkaar te komen om het huiswerk te bespreken.
• Documentatie bijschaven.
• Documentatie laten tegenlezen door het team.
• Feedback verwerken.
• Documentatie op nldesignsysten.nl plaatsen.

Acceptatie criteria

• Team heeft input geleverd op huidig stappenplan.
• Er is op het droge geoefend met 1 of 2 componenten.
• Het stappenplan staat op nldesignsystem.nl

Eventuele vervolgacties zijn als issue aangemaakt.

Overwegingen

• Is het verstandig om het gesprek over wat er beter kan fysiek te voeren?
• Wat is het juiste moment om nog eens 'op het droge' te oefenen om 1 of 2 componenten door het stappenplan heen te praten.
• Ik zou dit liever niet als enige oppakken. Ik kan goed wat hulp gebruiken van Rozerin (notuleren en schrijfwijze) en Yolijn (proces en vervolgacties).
• Behoort de README documentatie ook ergens in het stappenplan?
• Zijn er nog acties nodig die het stappenplan ondersteunen?
  • Common tokens? Uitkristalliseren van de common tokens #1909
  • Oplossing voor icons in front-end?
  • Bepaling welk/hoe component in aanmerking komt voor Candidate?

Handige links

• Templates per checkpoint
• PR's van geschreven documentatie per Checkpoint
• Candidate Projecten bord
• Back-up documentatie 'Aliassen' Jeff
• Back-up documentatie 'Anatomie' Jeff
• Back-up documentatie 'Figma NLDS' Jeff (onjuist gelinkt)
• Back-up documentatie 'Figma link documentatie' Jeff
• Back-up documentatie 'Figma in lijn' Jeff
• Back-up documentatie 'Coverage features' Jeff

Documentatie verzameling

• Ingezet door 2 of meer organisaties met verschillende huisstijlen.
  • Huidige documentatie
• De NL Design System Figma bibliotheek komt overeen met de implementatie van de component in code wat betreft varianten, states, design tokens en naamgeving.
  • Huidige documentatie
• Aliassen van alternatieve namen voor de component zijn vastgelegd in documentatie.
  • Huidige documentatie
• Anatomie van de component is vastgelegd.
  • Huidige documentatie
  • PR Hidde
• Component is, waar nodig, versimpeld of opgesplitst. Zodat er één of meerdere componenten over blijven met een duidelijke use case en documentatie.
• Geen organisatie specifieke API's meer, alle API's zijn gebaseerd op een gemeenschappelijke use case.
• API volgt conventies en is geprefixed met 'nl'.
• Design tokens volgen conventies en zijn geprefixed met 'nl'.
• Hergebruik van logische common tokens is geïmplementeerd om theming makkelijk te houden.
• Alle design tokens zijn algemeen nuttig voor de thema's van bestaande publieke organisaties.
• Beschikbaar in de NL Design System Storybook.
• Beschikbaar in de NL Design System Figma bibliotheek.
• Component heeft dezelfde documentatie op de website en Storybook over gebruik.
• Figma verwijst naar de documentatie op de website.
• Storybook stories, Figma voorbeelden en unit tests hebben coverage van alle features.
• Verwijzing beschikbaar naar extern gebruikersonderzoek die tot de keuze van dit component leiden.
• Accessibility en inclusie documentatie beschikbaar voor de overwegingen die van toepassing zijn.
• Semantiek (roles, names, states in HTML/ARIA) is goedgekeurd door het kernteam.
• Implementatie en documentatie is op toegankelijkheid getest door leden van het kernteam.
• Getest op geschiktheid voor internationalisatie.
• Component kan omgaan met verschillende soorten content: bijvoorbeeld korte tekst, veel woorden, lange woorden, of juist ontbrekende content.
• Codebase gebruikt linting en automatische code-formatting met Prettier volgens NL Design System configuraties.
• Gepubliceerd op NPM in de scope: @nl-design-system-unstable.
• Changelog wordt gepubliceerd bij nieuwe versies.
• Documentatie is getest bij de doelgroepen en goed bevonden.
• Status bijgewerkt naar naar Candidate.

[jeffreylauwers]

Ontbrekende onderdelen aan de hand van de vragen die Aline stelde op Slack:

• Documentatie over gemaakte keuzes waarover binnen 'Help Wanted' of 'Community' verschillen zijn vastgelegd in de GitHub Discussion van de betreffende component wanneer deze Candidate wordt gemaakt. Bij de bevestiging dat een component Cadidate is geworden zouden we direct de oproep kunnen doen dat als men functionaliteit of tokens mist, zij dit kunnen melden.
• De stap om de Candidate implementatie toe te voegen aan de documentatie website ontbreekt. De verwijzing naar de implementatie zou boven de Community implementaties moeten staan.

[jeffreylauwers]

Om eventuele discussies rondom de aanpak van het stappenplan Candidate, die mogelijk gaan over Hall of Fame, te kunnen opvangen is het handig om de Checkpoints van Hall of Fame ook zichtbaar te hebben. Zodat we hier notities aan kunnen toevoegen die dan weer bijdragen aan het uitschrijven van het stappenplan voor Hall of Fame.