Open Thinkering

Menu

Month: June 2018

Open source community calls in the wake of GDPR

Posted on by Doug Belshaw

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:

  1. Gain consent from each individual that we can store their personal data and that they agree to our privacy policy.
  2. Inform individuals what that data will be used for and how long we will be storing it.
  3. 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

Weeknote 23/2018

Posted on by Doug Belshaw

This week I’ve been:

  • Sending out Issue #306 of my Thought Shrapnel newsletter. This one was called ‘Bachelor lifestyle’. Thanks to the 36 patrons who back me via Patreon plus those who are supporters via Gumroad!
  • Recording, editing and releasing Episode 103 of the Today In Digital Education (TIDE) podcast with my co-host Dai Barnes. We entitled this episode ‘Innovation != progress’ and discussed radical technologies, product management, the MoodleNet project, health, personal learning networks, academic innovation, systems change, off-grid networking, and more!
  • Working on the MoodleNet project:
    • Starting the first MoodleNet two-week sprint with Mayel de Borniol. It’s a meta-sprint as we figure out the best way to work together and run the project.
    • Leading our monthly MoodleNet community call. You can catch up with what we discussed and access the recording here.
    • Updating the MoodleNet overview slide deck to v0.6 (in progress!)
    • Taking a great Udemy course on product management. I’ve done plenty of project management before, but this has some great insights from someone who’s a product manager at Soundcloud.
    • Getting set up in a separate (hosted) GitLab with Mayel.
    • Figuring out the best way to set up our Trello board.
    • Using Whimsical to create a flowchart for community contribution to the project. I’ve also tidied up the project home page a bit.
    • Writing up the sociocratic design sprint process Outlandish took us through.
    • Catching up with remote colleagues in the weekly Wednesday virtual office hangout.
  • Curating interesting things I came across on the Thought Shrapnel blog. This week I collected some quotations and commented on the following:
  • Sorting out car lease stuff. After being messed around a bit by our local Toyota dealer, we’ve hired a car and are looking at other options.
  • Responding to a couple of requests for consultancy work through We Are Open co-op. I also worked on a proposal for follow-up work with CET Israel‘s digital literacy MOOC.
  • Updating the privacy notice on the website of the local Scout group and watching my son (who’s a Scout) try to surf at Longsands, Tynemouth. 😂
  • Writing:

Next week I’m working from home on Moodle-related things from Monday to Thursday, and then co-op and consultancy things on Friday.

 

Sociocratic design sprints

Posted on by Doug Belshaw

Update: Check out Kayleigh’s more comprehensive post on this at the Outlandish blog!

I wanted to take a moment to record a great twist that Outlandish made to the now-classic Google Ventures design sprint.

The week-long process, as documented in The Sprint Book, requires a ‘decision-maker’ with authority to sign things off. The reasoning?

Without a Decider, decisions won’t stick. If your Decider can’t join the entire sprint, have her appoint a delegate who can

On the very first day of the recent MoodleNet design sprint, Outlandish introduced us to a way of making decisions without recourse to a single person. That process is sociocracy (or ‘dynamic governance’) and something that, as a co-operative, Outlandish uses on a daily basis.

Sociocracy process

Here’s how it works:

  1. Appoint a Chair and Note-taker
  2. Agree time boundary
  3. Invite proposal
  4. Clarifying round
  5. Initial reactions
  6. Test for consent
  7. Draw out concerns
  8. Group concerns
  9. Resolve one group at a time
  10. Test for consent on each resolution
  11. Repeat until consent is gained

In practice, over the week-long design sprint, it was more like:

  1. Invite proposal (e.g. “MoodleNet should use the same colour scheme as Moodle core”)
  2. Clarifying round (e.g. “Do you mean the exact same colour orange?”)
  3. Draw out concerns (e.g. “I’m concerned that people will get confused between our products”)
  4. Test for consent (e.g. “I don’t have any critical concerns”)
  5. Invite new proposal (e.g. “MoodleNet should use similar brand guidelines to Moodle core”)
  6. (repeat)

There are several benefits to this process, which becomes quicker and more natural the more times you do it:

  • The group gets used to giving consent despite having small concerns
  • ‘Critical’ concerns from individuals can lead to modified (and improved) proposals
  • The group can quickly move forward without getting stuck on opinions

I’ve read quite a bit about sociocracy in theory, but it was so good to see the approach working in practice. Not only did it make the week more democractic, but it actually accelerated things! The Outlandish team got us testing on Thursday instead of Friday, which meant we spent a day iterating and focusing on next steps.

css.php