Following up on a question from @Andrea_W (thanks for the input!) I did some research, and want to propose some small changes to the ASBL processes. Calling @reef-full for input and opinions.
Simplifying the registry of members
The registry of members is a legal obligation for a Belgian ASBL. We can simplify ours in two ways:
Only list full members. It is not necessary to include associate members.
Only list names and addresses. NRNs and other data are not an obligation.
NRNs were included originally for disambiguation purposes. But it turns out we will probably never have to disambiguate between two people with the same name, so should we follow the principle of data minimization and do not collect personal data that are not necessary to our statutory purposes.
We also have been using the registry of members to also keep track of other things, like dietary restrictions. This makes sense, but I propose to strictly separate legal compliance from other documents. So, I would like to move to a registry of members that implements 1 and 2 above. We can move to a different file the other information.
Accepting associate members
So far, we have been using GAs to accept members, both associate and full. The logic is that we want membership to be a consensus decision, since it amounts to deciding to spend many years together. This is obviously still true, but we probably went too far and took un unnecessary paperwork. I would propose that accepting associate members becomes a simple decision by consent of the full members. Accepting full members should still be a consensus decision. Doing it via a GA makes it more formal and solemn, but it is not a legal requirement.
In view of the above, I propose no more GAs for new memberships. The full members meeting continues to deliberate on new members candidatures. New associate members are approved by consent. New full members are approved by consensus.
In principle, I agree. A Q though: where would we keep the registry (can be just names) of exploratory members & associate members then? in the separate file under the Onboarding group?
My proposal would be to keep the current file, remove the NRNs and move it to the Onboarding folder. This way we keep a file with all the useful information, which can be added on a voluntary basis. And maybe we can add a column for birthdays?
Then we could ask the Secretary (deputised by yours truly for the moment) to create a register that meets the legal requirement of having a list with the names of the full members and their addresses.
@alberto is that something you can work with? @reef-recruitment shall we maybe add it to the agenda (3 minutes) to confirm the way forward?
Good point! I looked it up and it’s Article 5 and 6, both §1b. It does speak about agreement of the GA after a written request for membership, but I guess we can also interpret it along the lines of “we’ll hold a GA every 4 months and approve all the memberships that we already agreed on informally”. Does that work for you?
Asbl full members register: in the asbl folder, only keeping name, address and email (I opted for the lazy version and kept in the data on the associate members who are about to become full members)
Registry of members: column with NRNs removed + file moved to Onboarding > Learning more about the Reeflings
Checklist updated, point 1.8 “onboarding documents” > “registry”: “filling in the registry is optional”
GA minutes temporarily moved to my private Nextcloud
Action points:
Someone in Team R&O: follow-up with Team IT on the Nexcloud documents memory
@ChrisM and/or @mieke: add an additional step in the membership administration manual in the full membership stage, so that we add full members’ names and addresses to the asbl full members registry (internal link: https://c301.nl.tabdigital.eu/f/97871)
I need to do some Word juggling when I am not on the couch (“save as” and what not + change the links in all the documents that have links). Once that’s done I’ll let you know, including how to update the manual so that we can avoid this kind of juggling in the future.
I saved the latest version of these documents with a “v2” mention in their file name. This means it’s the same file, but minus the Nextcloud memory.
I corrected the links to these documents in the checklist, point 1.8
Can you please take over from here?
Can you please add a line in your manual that requests that every 3-4 months (or as often as you like) we delete the versions in Nextcloud as described by Alberto above?
If people find out that a link to the old version is broken, can you please fix it? Cursing me is optional but welcome, as long as you bear in mind that this operation (hopefully a one-off) is saving us from having to delete hundreds of versions
