diff --git a/README.md b/README.md index 84eb127..f5b1e39 100644 --- a/README.md +++ b/README.md @@ -6,12 +6,12 @@ De NLUUG is voornemens een nieuwe ledenadministratie in te voeren. Die moet "het ## Bestanden -Omdat ik (Jan Sepp) nu anderhalf jaar de ledenadministratie draai heb ik een goed inzicht in wat werkt en wat niet werkt. Ik heb een aantal documenten gemaakt die ons inzicht moeten geven in wat de nieuwe ledenadministratie zou moeten doen: +Omdat ik (Jan Sepp) nu anderhalf jaar de ledenadministratie draai heb ik een goed inzicht in wat werkt en wat niet werkt. Ik heb een aantal documenten gemaakt die ons een overzicht moeten geven in wat de nieuwe ledenadministratie zou moeten doen: - Ik ben begonnen met het beschrijven van de processen en (deels) de bestanden in de huidige ledenadministratie. Het resultaat staat op de [NLUUG Wiki pagina's](https://wiki.nluug.nl/doku.php?id=buro:start) onder buro. Eerlijk gezegd is dit meer een handleiding voor een toekomstige ledenadministrateur dan een analyse document, maar het schrijven ervan heeft me wel veel inzicht gegeven. - Daarna heb ik een tekstuele analyse gemaakt van wat we nodig hebben. Dat is niet mijn vak (ik ben van huis uit Unix systeembeheerder) dus daar zal wel wat op aan te merken zijn. Ik hoor het graag. Het bestand staat in deze repository als [RequirementsNLUUG.md](https://git.nluug.nl/jsepp/NLUUG_LedenadminNG/src/branch/main/RequirementsNLUUG.md). Commentaar en verbeteringen zijn van harte welkom. - Vervolgens heb ik een plaatje gemaakt van welke datastructuren ik graag zou zien in een volgende versie van de ledenadministratie. Dat is ook niet mijn vak, maar ik heb geleerd van een eerder project en ik denk dat het plaatje redelijk compleet is. Het staat in deze repository als [NLUUG-Data_Description.png](https://git.nluug.nl/jsepp/NLUUG_LedenadminNG/src/branch/main/NLUUG-Data-Description.png). -- Ik merkte dat, als ik dat plaatje moet uitleggen ik heel veel woorden nodig heb. Dus ben ik bezig met een toelichting die je vindt in bestand [Datastructuren.odt]( https://git.nluug.nl/jsepp/NLUUG_LedenadminNG/src/branch/main/Datastructuren.odt) Mijn excuses dat dat bestand in LO Writer formaat is, maar het werd een geweldige rommel in markdown, dus moet het maar zo. Ook hier geldt weer voor dat positieve kritiek van harte welkom is. +- Ik merkte dat, als ik dat plaatje moet uitleggen ik heel veel woorden nodig heb. Dus heb ik een toelichting gemaakt die je vindt in bestand [Datastructuren.odt]( https://git.nluug.nl/jsepp/NLUUG_LedenadminNG/src/branch/main/Datastructuren.odt) Mijn excuses dat dat bestand in LibreOffice Writer formaat is, maar het werd een geweldige rommel in markdown, dus moet het maar zo. Ook hier geldt weer voor dat positieve kritiek van harte welkom is. ## Volgorde @@ -21,11 +21,11 @@ Ik denk dat de beste volgorde om de documenten te lezen is: eerst de Requirement Voor alle zekerheid: we kiezen nu dus nog niet voor de ene of de andere oplossing, we beschrijven eerst wat we nodig hebben. -Wat ik van de lezers vraag is om de documenten door te nemen en vanuit hun specifieke kennis en achtergrond te becommentariëren. Wat zien we tot nu toe over het hoofd? Zijn er meer of betere datastructuren nodig? Opbouwende kritiek is van harte welkom! +Ik ben een zeer ervaren ledenadministrateur, en dus ervaringsdeskundige. Ik ben geen programmeur of analist. Wat ik van de lezers vraag is om de documenten door te nemen en vanuit hun specifieke kennis en achtergrond te becommentariëren. Wat zien we tot nu toe over het hoofd? Zijn er meer of betere datastructuren nodig? Opbouwende kritiek is van harte welkom! Misschien kunnen we tot een werkgroepje komen met een vast aantal leden? ## 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) conccensus hebben over een werkbare specificaties/requirements. Daarmee 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. Als dat niet zo is kunnen we zelf een pakket 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 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