NLUUG_LedenadminNG

Deze repository bevat de stukken over de vernieuwing van de ledenadministratie van de NLUUG

De NLUUG is voornemens een nieuwe ledenadministratie in te voeren. Die moet "hetzelfde kunnen als de huidige ledenadministratie" en meer. De kernvraag is: kunnen we toe met een (liefst Open Source) bestaand ledenadministratiepakket, of moeten we zelf iets schrijven? Voordat we daarop een antwoord op kunnen geven - en voordat we een bestaand pakket kunnen kiezen - zullen we eerst inzicht moeten hebben in wat we eigenlijk nodig hebben.

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:

• 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 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. 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.
• 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 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.

Volgorde

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.

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.

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!

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.

Amsterdam, 11 oktober 2024

Jan Sepp