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 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 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 heb ik een toelichting gemaakt die je vindt in bestand 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

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.

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.

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

Jan Sepp