volunteering – Open Thinkering

Badge Wiki: start of 30-day feedback period on Terms of Use and Privacy Policy

Posted on June 21, 2017June 21, 2017 by Doug Belshaw

Earlier this year, I wrote about the importance of thinking about a project’s architecture of participation when encouraging contribution from a new or existing community of people.

In that post, I included a checklist containing eight points to consider. I think I’ve got another one to add: get your policies right by soliciting feedback on them.

We Are Open Co-op is currently in the first phase of creating Badge Wiki, a knowledge base for the Open Badges community. It’s a project made possible through the support of Participate.com.

As part of this process, we have to come up with several policies, perhaps the two most important of which are the Terms of Use and Privacy Policy. We decided to use the Wikimedia Foundation’s openly-licensed policies as a starting point, adapting them to our needs.

This has thrown up some interesting issues and considerations from an architecture of participation point of view. After all, if people don’t agree to the Terms of Use and Privacy Policy, they can’t use Badge Wiki. There are three important ways in which our draft policies differ from the original Wikimedia Foundation source policies:

CC BY – we propose that Badge Wiki use a Creative Commons Attribution 4.0 International license instead of the CC BY-SA license used on other wikis, including Wikipedia. Although we would encourage them to do so, we recognise that some people may not be in a position to share material they reuse and remix from Badge Wiki under an open license.
Register to edit – we propose that, in order to edit Badge Wiki, you must have a registered user account, approved by an administrator. This is to prevent valuable contribution time being taken up by wiki vandalism, trolling, and other anti-social behaviours caused by anonymous editing.
Real name policy – we propose that members of Badge Wiki use their real names on their profile pages, as well as provide a short bio. This is to prevent accusations of sabotage, given that the Open Badges ecosystem includes commercial interests.

You can access the draft Terms of Use and Privacy Policy for Badge Wiki at the links below:

You’re welcome to leave feedback on the posts themselves, in relevant Open Badges Google Group thread, or directly to us: [email protected].

Thanks in advance for your participation and contribution. Remember, comments expressing support and broad agreement are as valuable as expert nitpicking!

Image by madebydot

Towards an architecture of participation for episodic volunteering

Posted on October 10, 2014October 10, 2014 by Doug Belshaw

Recently I heard a talk by someone looking for more volunteers for a thing. The context isn’t particularly important – I don’t want to get hung up on that. The point is that the talk had the desired effect: I wanted to volunteer. I wanted to help both in terms of giving money and lending time.

A couple of weeks later, I’ve done neither. Why? I’d suggest it’s because the group involved has a weak ‘architecture of participation’.

This week there’s been a discussion on the Mozilla Community Building Team list about ‘episodic volunteering’. It quoted this document (PDF) from the National Volunteer and Philanthropy Centre in Singapore:

Another recent trend has been a shift away from regular, long-term volunteering to more episodic or one-time service. While this has created significant challenges for many organizations that depend on consistently available volunteers (think mentoring, health services, etc.), the reality is that more and more volunteers are looking for ways to get engaged in a short-term capacity. This is especially true given that episodic volunteering may not always be about time availability but rather time of year – for example, lots of people seek to volunteer during the holiday season of November and December.

This got me thinking about Tim O’Reilly’s post The Architecture of Participation from 10 years ago:

I’ve come to use the term “the architecture of participation” to describe the nature of systems that are designed for user contribution. Larry Lessig’s book, Code and Other Laws of Cyberspace, which he characterizes as an extended meditation on Mitch Kapor’s maxim, “architecture is politics”, made the case that we need to pay attention to the architecture of systems if we want to understand their effects.

Any time you’re asking someone else to chip in who doesn’t have an obligation to help you, then you need an architecture of participation. You need easy onboarding, a way from them going from donating zero percent of their time to many hours a week. You also need a way for them to drop their number of hours – potentially back down to zero – if their life circumstances dictate. The closest analogy I can think of are easy in / easy out terms advertised for office space.

You also need to create a modular system to have an architecture of participation. There needs to be ways for people to work on one part of the whole project and not on others. As Tim puts it in the context of building software, “Anyone can create a participating, first-class component.”

This requires leadership. I’ve never seen a strong architecture of participation without strong leadership. Sometimes this can look like a benign dictatorship, especially when the number of people involved is small. But to get to any kind of scale, this leadership needs to be distributed.

Creating distributed leadership requires a clear mission. The mission – which should be written down as early as possible in the form of a manifesto or terms of reference is the reason the group of people is collaborating. This prevents scope-creep and helps realign the group should a subset try and hijack it for a tangential purpose.

The easiest way to create a strong architecture of participation is to work openly. This may be constrained by considerations around safeguarding, but information should not be hard to come by for those already part of the group. At the very least, calendars and contact details should be shared. There should be a default, canonical place to go/ask to find out an authoritative answer.

You’ll need to meet regularly in ways that don’t always involving working on the thing you’re all meeting to make better in the world. Sometimes that’s called a social. But it might just mean that one of the weekly meetings you have every month is devoted to ‘lighter’ or other issues. Mix things up a bit so it doesn’t become ‘samey’.

Finally, it’s entirely reasonable that there should be a shift towards episodic volunteering. If we create architectures of participation that allow ‘newbies’ to slot in quickly to existing projects, then they may stick around long-term. Some would call that a ‘contribution funnel’. It’s unreasonable for us to expect them to make that commitment immediately. In fact, we should thank them regularly for their contribution. We’re often good at being excited about new contributors when we should be equally thankful for the ‘old-timers’.

What have I missed? Add a comment below!