jsepp/NLUUG_LedenadminNG
1
0
Fork 0
Code Issues 1 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Paragraaf "Hoe doe je mee" toegevoegd.

Browse source
This commit is contained in:
Sepp 2024-10-13 10:29:03 +02:00
parent 5c7bbba6a5
commit c7b5f8d7df
1 changed files with 8 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
README.md
View file

@ -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. 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 ## 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. 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 ## 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 Amsterdam, 11 oktober 2024