Update: templates varianten bepaald en anatomie (#1091)

Co-authored-by: Yolijn <mail@yolijn.com>

Author: jeffreylauwers

.github/ISSUE_TEMPLATE/202-📝-varianten-bepaald.md

@@ -15,7 +15,6 @@ Component is, waar nodig, versimpeld of opgesplitst. Zodat er één of meerdere
 - [ ] Verzamel input uit de Community
 - [ ] Besluit welke varianten Candidate worden
 - [ ] Documenteer besluit in de GitHub Discussion
-- [ ] Documenteer besluit in de Candidate repository
 - [ ] Zet de checkpoint in het GitHub projectbord op de juiste status
 
 ### Verzamel input uit de Community
@@ -114,41 +113,137 @@ Voorbeeld hypothese voor RVO met 4 verschillende formaten voor font-size:
 
 ### Besluit welke varianten Candidate worden
 
-- Overleg de naam en beschrijving met het kernteam
-- Bepaal samen met de Design System Lead welke varianten in de Candidate component moeten worden opgenomen
-- Notuleer de besproken beredeneringen op, deze heb je nodig in de volgende stap.
+- Overleg de naam en beschrijving met het kernteam.
+- Bepaal samen met de Design System Lead welke varianten in de Candidate component moeten worden opgenomen.
+- Is het een variant die hoort bij een standaard HTML attribuut? Bepaal dan welke varianten wel worden ondersteund en ook geadviseerd worden, welke ondersteund worden maar niet geadviseerd worden en welke er niet ondersteund worden.
+- Notuleer de besproken beredeneringen. Deze heb je nodig in de volgende stap. Dat doe je met een comment in dit GitHub issue met een comment:
+
+```md
+## Input type
+
+### ondersteund:
+
+- text
+- search
+- tel
+- url
+- email
+- password
+
+### ondersteund maar niet geadviseerd:
+
+- hidden
+- :not([type])
+- date
+- month
+- week
+- time
+- datetime-local
+- number
+
+### niet ondersteund:
+
+- color
+- range
+- radio
+- checkbox
+- file
+- submit
+- image
+- reset
+- button
+```
 
 ### Documenteer besluit
 
-- Optioneel: splits, in overleg met de Design System Lead, de component op in meerdere componenten en zet de extra componenten met logica die we daarin gaan opnemen op de Backlog.
+- Optioneel: splits, in overleg met de Design System Lead, de component op in meerdere componenten. Zet de extra componenten, met logica die we daarin gaan opnemen, op de Backlog.
 - Documenteer in de GitHub Discussion welke varianten wel en niet worden meegenomen voor de Candidate implementatie en waarom.
 
 ```md
 ## Candidate voorbereidingsfase: Versimpeld of gesplitst
 
-De varianten voor de Candidate component zijn bepaald, dat hebben we gedaan op basis van alle voorbeelden die we in deze Discussion hebben gezien. Als een variant veel voor komt, dan is het een algemeen nuttige variant!
+De varianten voor de Candidate component zijn bepaald, dat hebben we gedaan op basis van alle voorbeelden die we in deze Discussion hebben gezien. Als een variant veel voorkomt, dan is het een algemeen nuttige variant!
 
-### Deze varianten nemen we mee:
+### Deze varianten ondersteunen we:
 
-**{variant-groep}** - {enum / boolean / string)
+**{variant-groep}** - (enum / boolean / string)
 
+- {variant-naam}(default)
 - {variant-naam}
 - {variant-naam}
-- {variant-naam}
 
-### Deze varianten nemen we niet mee:
+### Deze varianten ondersteunen we niet:
+
+optioneel: welke varianten hebben we besloten om niet te supporten? Zie hiervoor de notulen in dit GitHub issue.
 
-{optioneel: welke varianten zijn zo smerig dat we ze niet hebben meegenomen? Beschrijf ook waarom}
+### Deze varianten ondersteunen we, maar raden we niet aan:
+
+optioneel: welke varianten supporten we omdat ze standaard in HTML zitten, maar gaan we niet documenteren, niet beschikbaar maken in Figma en alleen meenemen in de test Storybook? Zie hiervoor de notulen in dit GitHub issue
 
 ### Mis je een variant?
 
 Laat het in deze Discussion weten als er uit gebruikersonderzoek naar voren is gekomen dat deze design beslissing een hele verbetering zou zijn.
 
 **💡 Tip**
-Je kunt varianten ook als extentie toevoegen aan de component. Documentatie hoe je dan kunt doen volgt. Vraag ons er gerust naar.
+Je kunt [varianten ook als extensie toevoegen](https://www.nldesignsystem.nl/handboek/componenten-vinden/#ik-mis-een-functionaliteit-binnen-een-candidate-of-hall-of-fame-component-wat-nu) aan een component.
+```
+
+Zijn er geen varianten? Documenteer dat dan ook in de GitHub Discussion.
+
+```md
+## Candidate voorbereidingsfase: Versimpeld of gesplitst
+
+Er zijn meerdere implementaties van {component-naam} bekeken en met elkaar vergeleken. Op basis daarvan is besloten dat er géén specifieke varianten nodig zijn voor de Candidate component.
 ```
 
-- Zet de naam en beschrijving van de varianten die we gaan meenemen naar Candidate in de GitHub Backlog issue van de component. Maak acceptatiecriteria voor alle varianten die in de component worden meegenomen. Voeg deze toe aan de `acceptance-criteria.md` van de component in de Candidate repository.
+#### Voeg de besluiten toe aan de acceptatiecriteria
+
+Maak acceptatiecriteria voor alle varianten die in de component worden meegenomen. Voeg deze toe aan de `acceptance-criteria.md` van de component in de Candidate repository.
+
+```md
+## Welke varianten ondersteunen we voor deze component
+
+Deze varianten worden ondersteund. Wanneer ze standaard in HTML zitten worden ze in Typescript gedefinieerd door de attributen het standaard HTMLElement te gebruiken. Wanneer ze niet standaard in HTML zitten wordt deze type extended. Deze varianten worden gedocumenteerd op de website, in de README en in de standaard Storybook. Deze varianten worden beschikbaar gemaakt in Figma.
+
+**{variant-groep}** - (enum / boolean / string / number)
+
+{
+Is het een enum? Noteer dan de waardes en of er een default is
+
+- {variant-naam}(default)
+- {variant-naam}
+- {variant-naam}
+
+Is het een boolean? Noteer dan de twee opties en welke de default is
+
+- true (default)
+- false
+
+Is het een string of number? Laat deze dan leeg
+}
+
+### Deze varianten ondersteunen we niet:
+
+{
+optioneel:
+
+Deze varianten die standaard in HTML zitten worden niet ondersteund. Ze worden uit de HTMLElement type gehaald met Omit bij het definieren van de properties van de component in Typescript.
+
+Deze varianten worden ook niet gedocumenteerd en niet meegenomen in Figma.
+
+Documenteer de niet ondersteunde varianten op basis van de notulen in dit GitHub issue.
+}
+
+### Deze varianten ondersteunen we, maar raden we niet aan:
+
+{
+optioneel:
+
+Deze varianten supporten we omdat ze standaard in HTML zitten door de HTMLElement type te extenden in Typescript. Deze varianten worden meegenomen in de test Storybook. Deze varianten worden niet gedocumenteerd op de website of in de README, niet beschikbaar in Figma en niet meegenomen in de standaard Storybook.
+
+Documenteer de ondersteunde, maar niet aangeraden varianten op basis van de notulen in dit GitHub issue.
+}
+```
 
 🚩 Checkpoint
 📝 Varianten bepaald: Done

.github/ISSUE_TEMPLATE/205-📝-anatomie-bepaald.md

@@ -16,16 +16,16 @@ type: Task
 - [ ] Maak een voorstel voor de anatomie
 - [ ] Bepaal of de anatomie zo kan worden meegenomen in de Candidate implementatie
 - [ ] Stem af met Design System Lead
-- [ ] Documenteer besluit in de Candidate repository
+- [ ] Documenteer besluit in de GitHub Discussion
 - [ ] Zet de checkpoint in het GitHub projectbord op de juiste status
 
-### Bepaal welke onderdelen de component uit kan bestaan
+### Bepaal uit welke onderdelen de component kan bestaan
 
 Bepaal op basis van de "Component gebruikt", "WCAG-input", "Issues bekend" en "Versimpeld of opgesplitst" fases uit welke onderdelen de component kan bestaan.
 
 ### Maak een voorstel voor de anatomie
 
-Is er een anatomie nodig? Leg deze dan in de volgende stappen vast en maak een schets om deze uit te leggen. Dat mag op papier, met een foto. Het mag in Figma, het mag in code. Het doel is dat we als kernteam weten wat ons te doen staat als we de component maken. We leggen het vast om voor beheer als alles nóg een keer gemaakt zou moeten worden in een heel andere techniek het makkelijk te maken om dezelfde afwegingen niet nog een keer te hoeven maken
+Is er een anatomie nodig? Leg deze dan in de volgende stappen vast en maak een schets om deze uit te leggen. Dat mag op papier, met een foto. Het mag in Figma, het mag in code. Het doel is dat we als kernteam weten wat ons te doen staat als we de component maken. We leggen het vast om voor beheer als alles nóg een keer gemaakt zou moeten worden in een heel andere techniek het makkelijk te maken om dezelfde afwegingen niet nog een keer te hoeven maken.
 
 #### Welke richtlijnen volg je bij het besluiten van de anatomie?
 
@@ -44,25 +44,23 @@ Maak een schets van de anatomie op een manier die voor jou het best werkt. Dat k
 >
 > **Stappen voor Figma**
 >
-> - Open de Documentatie website afbeeldingen Figma file.
+> - Open de ['Documentatie website afbeeldingen' Figma file](https://www.figma.com/design/0Y9Tbb373u6QGxGT6mqUnm/NL-Design-System---Doc-website---Afbeeldingen?node-id=3-23&t=RFNr3Ko3v4JUtIvr-1).
 > - Dupliceer een reeds bestaande page.
 > - Geef de page de naam van de component.
 > - Geef het frame de naam anatomy.
-> - Plaats de component vanuit de 'NL Design System - Bibliotheek' op het frame.
 > - Gebruik de 'Annotation number' en 'Annotation line' om onderdelen een te wijzen en nummeren. Probeer 48 spacing aan te houden tussen 'Annotation number' en de gehele component.
-> - Exporteer het frame als plaatje en voeg deze toe aan de betreffende Backlog issue van de component.
 
 ### Bepaal of de anatomie zo kan worden meegenomen in de Candidate implementatie
 
 Zorg voor een meeting waar tenminste een designer, een developer, een toegankelijkheidsspecialist en de Design System Lead uit het kernteam bij aanwezig zijn. Besluit op basis van het voorstel of deze onderdelen inderdaad in de component moeten zitten, of er onderdelen missen en of iedereen het met de naamgeving eens is.
 
 Tip: Zorg dat iedereen genoeg informatie heeft om niet alleen hun eigen expertise te gebruiken, maar ook alle relevante input die uit de community is verzameld in de eerdere stappen voor Candidate.
 
-### Leg de anatomie vast in het GitHub issue
+### Leg de anatomie vast in de GitHub Discussion
 
 Let op: Anatomie is niet altijd nodig. Soms bestaat de component maar uit 1 onderdeel. Check dus eerst met elkaar of de component écht uit meerdere onderdelen bestaat voordat je dieper op de anatomie ingaat.
 
-Voeg de schets toe aan de Backlog issue van de component in combinatie met de beschreven Anatomie uit de vorige stappen.
+Voeg de schets toe aan de GitHub Discussion van de component in combinatie met de beschreven Anatomie uit de vorige stappen.
 
 Tip: heb je de schets gemaakt met een tool waarvan je de URL kan delen voor het geval deze ooit moet worden aangepast? Deel deze dan ook bij het plaatje.