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.

Purpose & Goals

what's the goal of this workshop?

Designing for Participation was created in order to get Mozilla community members to think about how they can structure the work Mozilla does to better enable contributions from anywhere. As such the workshop has three goals:

• impart on participants some best practices about how to design tasks to better enable participation
• foster a conversation where best practices and ideas can be surfaced and critically assessed, particularly around how suggestion may or may not be relevant to areas the participants work on
• provide participants with action items they can take back to where they contribute to Mozilla that will help increase opportunities for participation from community members
• share differing experiences around the possibilities and obstacles to participation between managers, employees, staff, volunteers, newcomers and veteran contributors.

who should participate?

Almost anyone at Mozilla should feel like this is open to them. "Roles" that might want to participate or lead this workshop include:

• module owners
• newcomers
• veterans
• staff
• volunteers
• managers

Some of the more common questions participants often have that make them a good fit for the course 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.
• I'm a contributor and I'd love to expand how much I contribute or have been trying to explore new parts of the project to contribute to with little success.

assumptions

It is worth noting that this course is not for everyone. Participants in this course are assumed to know what an open source project is and, at a high level at least, how it works.

Logistics

A few things to note before sending out invites:

• this course works best with something between 3-25 participants. Anything more than that and it gets unwieldy, especially if you are not used to facilitating/teaching
• please ensure that participants have access to the internet so they complete the workshop, or print them out in advance

Basic Tips on Facilitation

Link?

Syllabus breakdown

The course is broken down into four parts:

• introduction
• case study and debrief
• application to personal situation and debrief
• wrap up

Introduction

This short part of the workshop is to enable people to quickly get to know one another and align around the shared goals of the workshop.

Slide 1: introductions

• this should ideally take no more than 5 minutes
• Introductions are important, it helps foster a sense of community and a sense of shared space where people feel it is safe to share their stories, questions or ideas.
• Make introductions brief - we only have one hour
• Ask each participant to share their name, their role/title in the Mozilla community and 3 words about open source projects, this always generates great feedback
• Model good behaviour by going first (and adhering to whatever guidelines you set out

Slide 2: Goals Slide

• this slide should take no more than 5 minutes (including Q&A)
• goal: get everyone aligned around common objectives for the workshop
• see if there are other goals that people have
• good communication about the goals BEFORE the workshop is key to ensure that this slide does not turn into a large debate

Case Study

The goal of the case study is to tease out some best (and/or possible poor) practices to seed a discussion and get participants thinking about designing for contribution.

For the purposes of this syllabus we are using SUMO as the case study, however an alternative case study can be used. The key elements of a good case study are:

• it is an example of good designing for participation
• it has a webpage or place where participants (both of Mozilla in general and the workshop participants) can go and interact with
• it can be broadly understood in about 3-5 minutes of reading (which frankly - is a best practice of a website that is trying to engage new contributors)

Slide 3: Introduce Case Study

• this slide should take about 15-20 minutes to discuss

Step 1

• introduce your case study
• share that you think they are doing a wonderful job, but do not share too many details (the participants should be allowed to discover things on their own
• if possible, interview someone working or volunteering for the group the case study is based on, a quote from them that discusses the impact of their ability to support broad participation can be powerful. It can also help you provide better facilitation by being more familiar with the case.

Step 2

• instructions - get them to go to the link you provide and:
  • look at the site
  • read its content
  • take 3-5 notes about why it might be effective in attracting participants

Step 3

• Give participants a solid 5 minutes to read and thing

Step 4

• debrief
• ask: What are some of the ways that Sumo has structured itself (and its work) to make it easy for people to contribute?
• facilitate the conversation, try not to share your thoughts, let others share

• some best practices
  • "The language assumes that you're competent" - you don't have to prepare/train. If you're here, you're competent to contribute.
  • Clear actions
  • Virtually no barrier to entry, you just need to sign up
  • make things easy to find; don't try to test your users at this point
  • leaving tasks undefined/open can be daunting to some (especially first time) contributors.

Slide 4

• 5 minutes of additional discussion
• this is where you get to share your insights and summarize what you have heard that is particularly effective
• this slide has key best practices, but feel free to edit

Personal Application

Slide 5

• time

- 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