To build on that post, I’d like to explain the kinds of tools and spaces that can create a positive architecture of participation. Please note that, in and of themselves, merely using a tool or creating a space does not guarantee participation. Rather, the tools and spaces help as part of a more holistic approach to encouraging contribution.

When I run projects, as I am doing for Moodle as of this week (more specific details on that in a future post), the following are the kinds of tools I tend to use and the spaces I look to create. It’s worth pointing out that my guiding principle is always the ‘scaffolding’ of people’s attention, and that my mental model for this is influenced by the ‘alternative’ version of the RACI matrix:

Responsible
Those responsible for the performance of the task. There should be exactly one person with this assignment for each task.

Assists
Those who assist completion of the task

Consulted
Those whose opinions are sought; and with whom there is two-way communication.

Informed
Those who are kept up-to-date on progress; and with whom there is one-way communication.

A) Index

I’ve written before about why you need a single place to point people towards when discussing your project. Not only does it mean a single place for potentially-interested parties to bookmark and remember, but it ensures that the project team only have to perform the administrative duties of updating and curating links once.

Ideally, the URL you give out is a domain that you or your organisation owns, and which points to a server that you, or someone at your organisation, has direct control over. The specific software you choose to run that almost doesn’t matter, as it’s an index — a jumping off point to access spaces where things are actually happening.

Having a canonical URL for the project is useful to everyone in the RACI matrix, from the person responsible for its success, right through to those just being kept informed.

B) Documentation

Every project needs a flexible, easy-to-update space where the roadmap can be shared, decisions can be recorded, and an overall sense of the project can be gained.

Wikis are perfect for this task, although increasingly there are tools with wiki-like functionality (e.g. revision history, on-the-fly rearrangement of categories) that do the job, too. Ideally, you’re looking for something that allows your project to look good enough to encourage contribution in someone new, while you don’t have to spend ages making everything look pretty.

Again, documentation is useful for everyone involved in the project, whether responsible, assisting, consulted, or informed.

C) Tracker

One of the biggest things that people want to know about a project is the current status of its constituent parts. There are lots of ways of doing this, from a straightforward kanban approach, to a much more powerful (but potentially more confusing) ticket/issue-based system. The latter are favoured by those doing software development, as it helps avoid unhelpful ambiguity.

My time at Mozilla convinced me that there’s huge value of having everyone at an organisation, or at least on a particular project, using the same tool for tracking updates. The value of this is that you can see what is in progress, who’s working on it, what’s been completed, any questions/problems that have been raised, and so on.

While the tracker might only be used rarely by those being kept informed of the project, it’s invaluable for those responsible, assisting, or being consulted.

D) Asynchronous reports

Producing regular updates ensures that there is a regular flow of information to all parties. In my experience, it’s ‘out of sight, out of mind’ when it comes to digital projects. You have to keep reminding people that work is ongoing and that progress is being made on the project.

One way to do this is to blog about the project. Another way is to send out a newsletter. There are plenty of ways of doing this, and it’s worth experimenting with differing timescales as to the frequency of updates. While a bit of (appropriate) colour and humour is always appreciated, so is getting to the point as quickly as possible in these updates.

Reports are primarily for the benefit of those being kept informed about the project. It’s worth remembering that these people may, depending on changes in project direction (or their interest/free time), be in a position to assist or be consulted.

A word about social media. Sending out updates via Twitter, Facebook, and the like is great, but I find following the POSSE(Publish Once, Self-Syndicate Everywhere) approach works best. Use social networks for what they’re best at: surfacing and linking to information in a just-in-time fashion. I wouldn’t use them for the actualy content itself.

E) Synchronous meetings

Depending on the size of the project team and the nature of the project, you may decide to run synchronous meetings more or less regularly. You should certainly run some, however, as they afford a different kind of dynamic to asynchronous, text-based approaches.

There are plenty of tools that allow you to have multiple people on a synchronous audio (and/or video) call, ‘dialling-in’ from wherever they are in the world. It goes without saying that you should be mindful of the timezones of potential contributors when scheduling this. You should also all be looking at an agenda that can be updated as the meeting progresses. The project’s documentation area can be used for this, or something like Etherpad(one of my favourite tools!)

What have I missed? I’ve still lots to learn from those more experienced than me, so I’d welcome encouragement, pushback, and any other comments in the section below!

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:

Yesterday I was in Durham presenting on Radical Participation. At the start of the session each participant was given a couple of index cards. During my keynote I stopped and asked them to write or draw something on one of the four sides.

Today, I scanned in three of the four sides (the final one involved personal info that people may not have wanted to share more widely) and uploaded the images to this Flickr album. The header image is one person’s view of their institution’s ‘architecture of participation’. Interesting!

I did use Quicktime to record my screen during the presentation. That can be found on Vimeo. However, the audio is difficult to hear in places when I strayed away from the microphone.

1. What’s your organisation’s mission?

2. What would constitute ‘radical participation’ in this session?

3. Draw your organisation’s architecture of participation.

Many thanks to Malcolm Murray and team for inviting me to take part in such a great event. Also: I got to stay in a castle! 😀

@dajbelshaw It was a great keynote. Currently blogging about it and thinking about voluteering for @mozilla

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

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.

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

Last week I attended the inaugural EduWiki conference run by Wikimedia UK. It was a curious mix of Wikipedians, educators and academics who came together to discuss how Wikipedia could be used in more formal educational settings.

Martin Poulter, the organiser of the conference, was at pains to point out that Wikipedia isn’t phenomenally successful just because it allows anyone to edit. There’s a structure, albeit a fluid one, behind it all.

It got me thinking about an article from 2004 by Tim O’Reilly. He talks in that article about the importance of designing in ways for users to contribute effectively:

I’ve come to use the term “the architecture of participation” to describe the nature of systems that are designed for user contribution.

Tim’s focus is upon the architecture of the web and how openness of both attitude and technology allows for participation by more than just geeks:

HTML, the language of web pages, opened participation to ordinary users, not just software developers. The “View Source” menu item migrated from Tim Berners-Lee’s original browser, to Mosaic, and then on to Netscape Navigator and even Microsoft’s Internet Explorer. Though no one thinks of HTML as an open source technology, its openness was absolutely key to the explosive spread of the web. Barriers to entry for “amateurs” were low, because anyone could look “over the shoulder” of anyone else producing a web page. Dynamic content created with interpreted languages continued the trend toward transparency.

Any project starts off relatively small and needs enthusiastic individuals (and usually some money) to get things started. Wikipedia, for example, had Jimmy Wales and the money he had made from previous ventures. But even if you do get initial funding, you still have to make things sustainable:

In this context, it’s worth noting an observation originally made by Dan Bricklin in his paper, The Cornucopia of the Commons. There are three ways to build a large database, wrote Dan. The first, demonstrated by Yahoo, is to pay people to do it. The second, inspired by lessons from the open source community, is to get volunteers to perform the same task. The Open Directory Project, an open source Yahoo competitor, is the result. (Wikipedia provides another example.) But Napster demonstrates a third way. Because Napster set its defaults to automatically share any music that was downloaded, every user automatically helped to build the value of the shared database.

We at Mozilla are hoping to help create a generation of Webmakers. By this we mean people who can not only elegantly consume, but help make the Web. To do this we need to get things right from the start: by building stuff, handing it over to the community, and supporting their efforts.