I am a supporter of the intentions and sentiment behind the General Data Protection Regulation (GDPR) that came into force last month. However, it comes with some side effects.
Take community calls for the open source community, for example. Here’s how they often work:
- Agenda — someone with a level of responsibility within the project creates an agenda using a service you don’t have to login to access and to which everyone can contribute (e.g. Etherpad)
- Synchronous call — at the appointed time, those wishing to participate connect to some kind of audio and/or video conferencing services (e.g. Zoom)
- Recordings — those who are interested in the project but couldn’t participate at the time catch up via the agenda and recording.
I’ve been running community calls using this kind of approach for the last five years or so. It’s an effective method and a process I do so automatically, I didn’t even think about the GDPR implications.
Yesterday, however, I was informed (very nicely!) by Carlo Polizzi, Moodle’s DPO and Legal Counsel, that I needed to delete the data I’d collected in this way and find a new way to do this.
GDPR requires that (unless community members contribute anonymously) we must, at the very least:
- Inform individuals what that data will be used for and how long we will be storing it.
- Give them the option of withdrawing that consent at any time and having their data deleted.
This means, of course, that community members are going to have to register and then log in to a system that tracks them over time. I’ve written before about creating an architecture of participation for episodic volunteering. This certainly prevents more of a challenge for the ‘easy onboarding’ part of that.
So, not sure what to do, put up the Bat-Signal and asked my network. Out of that came suggestions to use:
- An encrypted etherpad solution that auto-deletes after a specified amount of time (e.g. CryptPad)
- Forum software that feels quite ‘realtime’ (e.g. Discourse)
- A Moodle course with guest access open (e.g. MoodleCloud)
On a more meta level, I also had some feedback that synchronous communication discriminates users for whom English isn’t their first language and/or who are disabled.
For now, given the above feedback, we’re going to end community calls in their current guise. I’ve met with Mary Cooch, Moodle’s community educator to discuss a few options for how we could do things differently, and we’re going to explore using the existing MoodleNet discussion forum at moodle.org along with BigBlueButton.
If you’ve got any questions, comments, or suggestions, I’d love to hear them, as this is something that many other open source projects are going to have to grapple with, as well!
Image CC BY-SA opensource.com