Participation/Resources/Designing for participation/Documentation

Anyone at Mozilla - module owner, newcomer, veteran, staff, volunteer should feel welcome to initiate or run the Designing for Participation Workshop.

How to Use this Manual

The purpose of this wiki page is to enable interested parties in leading - or simply drawing the lessons of - the Designing for Participation Workshop. As such this page is a manual of form. Please read the entire page and familiarize yourself with the lessons and goals. The better prepared you are, the more fun and rewarding the workshop will be, both for yourself, and for others participating in it.

That said, here are some high level guidelines for using this manual:

• While a lot of thought has gone into creating the syllabus and lessons, everything here is hackable, you need to run a workshop that speaks to your needs.
• Reach out to others who have run this - at the very least that will include David Eaves
• With luck others will have added content, examples to reference, or new lessons, to this page, please make use of them and add your own!
• Most importantly, have fun and be open to the unexpected.

Why Run or Participate in Designing for Participation

There are lots of reasons one might want to run or participate in Designing for Participation. Some of the more common reasons include:

• We are starting a new product/activity/function and want to think about how we can encourage community participation
• I've just moved to/been assigned as a manager to a new area and we want to expand how we can encourage community participation
• I'm a long time contributor with lots of thoughts about how to encourage participation, I wonder if others at the corporation or foundation have similar thoughts?
• I need to expand the scope of our work without increasing the financial resources I have
• I'm a manager and I'd like some tools for thinking about how to evaluate how effectively those who work for me create space and opportunity for community participation.

Purpose & Goals

- what's the goal of this workshop?

- who are some potential audiences?

- learning objectives for each audience

Module owners and those creating a project

Managers who want to learn what their employees should be doing to encourage greater participation from community members

People who want to contribute more

Pull out "Goals" slide (#3)

Understand:

- What makes for a good volunteer contributor?

- What motivates a contributor

- How to architect tasks to make it easier for volunteers

Explore: structured way for thinking about these issues that might help create an action plan

• How to do a round of introductions (esp. with a large group)

• Notes on how to bring humour to online learning

Redo Community Building Scenario slide - text no longer works for SUMO.

- go find a good example. Here are 3 examples that were great in Nov 2013…

- find an equivalent to the Superheroes Wanted page

Question:

What are some of the ways that Sumo has structured itself (and its work) to make it easy for people to contribute?

some answers:

"Do as much or as little as you can or want to do"

"Get involved - there's no barrier to entry - and you can also talk to us"

" language assumes that you're competent" - you don't have to prepare/train. If you're here, you're competent to contribute.

Lessons from this conversation:

- treat people like they're competent.

- make things easy to find; don't try to test your users at this point

- leaving tasks undefined/open can be daunting to some potential contributors.

Point to slide of key takeaways.

- e.g. ability to work on discrete tasks, asynchronously.

- range of incentives/motivations

Community Building Scenario

- Google Doc template - encourage people to make a copy so they can edit without creating chaos

- purpose: give people - if they write it down, they have some structured thinking they can take away from the workshop

- also a great vehicle for a breakout group & conversation.

Core team:

- core FF for Android team has no volunteer contributors

- incentives could be "part of the team," coder "rep", etc.

- triaging issues - what level / skill set is required. - helping to identify skills needed

- encouraging lurkers - watching people, watching bugs

Goal of debrief is:

- validate people's ideas

- share & cross-pollinate

- gently challenge and push back when ideas don't conform with Mozilla values

Facilitator should capture ideas in this conversation & share this as a list

Wrapping up:

- If there's a follow-up class, share details

- Ask each participant to name one thing they're taking away from the workshop that was useful, and one thing they want to learn more about.

- Invite feedback via email