diff --git a/README.md b/README.md
index f5b1e39..d2feb16 100644
--- a/README.md
+++ b/README.md
@@ -17,6 +17,13 @@ Omdat ik (Jan Sepp) nu anderhalf jaar de ledenadministratie draai heb ik een goe
 
 Ik denk dat de beste volgorde om de documenten te lezen is: eerst de Requirements, dan het plaatje DataDescription en dan het document over Datastructuren.
 
+## Hoe doe je mee?
+
+Wie mee wil denken: graag. Je kunt zonder ingelogd te zijn alle markdown bestanden (dus de bestanden die eindige op .md) lezen. De .png en .odt bestanden kun je downloaden. 
+Maar om commentaar te geven moet je een account hebben en ingelogd zijn. Je kunt dan, desgewenst, de hele repository dupliceren met een pull request. En, belangrijker nog, je kunt in de repository commentaar geven. Ik wil dat voorlopig doen via de issues tracker, in de knoppenbalk bovenaan deze pagina. Dus geen wijzigingen uploaden alsjeblieft, maar opmerkingen plaatsen in de Issues.
+
+Als je nog geen account hebt, en je bent wel lid van de NLUUG, dan kun je een account aanvragen bij de [beheersgroep van de NLUUG](mailto:beheer@nluug.nl?subject=Aanvraag%20NLUUG%20Git%20account). 
+
 ## Wat we graag willen
 
 Voor alle zekerheid: we kiezen nu dus nog niet voor de ene of de andere oplossing, we beschrijven eerst wat we nodig hebben.
@@ -25,7 +32,7 @@ Ik ben een zeer ervaren ledenadministrateur, en dus ervaringsdeskundige. Ik ben
 
 ## Volgende stappen
 
-Aan de hand van het commentaar van de leden maken we nieuwe versies van deze documenten, net zo lang tot we (min of meer) concensus hebben over een werkbare specificaties/requirements. Met de definitieve requirements kunnen we de boer op en de relevante open source (in eerste instantie) software leveranciers benaderen of zij zo'n oplossing hebben / willen realiseren. Als dat niet zo is kunnen we hetzelfde doen met proprietary software leveranciers. Als dat ook niets oplevert zouden we zelf een pakket kunnen schrijven - in eerste instantie voor onszelf, maar met in het achterhoofd de gedachte dat we dat willen kunnen open sourcen.
+Aan de hand van het commentaar van de leden in de issues maken we nieuwe versies van deze documenten, net zo lang tot we (min of meer) concensus hebben over een werkbare specificaties/requirements. Met de definitieve requirements kunnen we de boer op en de relevante open source (in eerste instantie) software leveranciers benaderen of zij zo'n oplossing hebben / willen realiseren. Als dat niet zo is kunnen we hetzelfde doen met proprietary software leveranciers. Als dat ook niets oplevert zouden we zelf een pakket kunnen schrijven - in eerste instantie voor onszelf, maar met in het achterhoofd de gedachte dat we dat willen kunnen open sourcen.
 
 Amsterdam, 11 oktober 2024