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.

Slide Deck

The slides for this presentation can be downloaded here in

• Designing For Participation PDF Version
• Designing For Participation Keynote Version

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

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

Purpose:

• In this section we attempt to take the lessons learned from the case study and apply them to the area of interest for each participant.
• Another purpose is to give each participant some actionable ideas they can take away from the workshop

Logistical note:

• If participants are all from different parts of Mozilla, they can work on their own worksheet. If they are from the same area/group/module they can work collectively on the problem
• time: about 15-20 minutes (however, if you are not bound to a one hour workshop, this session could last much longer.

Slide 5

• time: about 15-20 minutes

Step 1

• Provide Instructions for the exercise:
  • Introduce the exercise, inform people that you have a worksheet that you think can help structure their thinking and help explore opportunities for how to redesign the work they do at Mozilla to enable greater participation.
  • The worksheet template is a Google Doc template
  • Encourage participants to make a personal copy of the template so they can fill out their own
  • Participants will have about 7 minutes to fill out the form
  • Many ideas are better than a few good ideas

Step 2

• Participants fill out the template
• Generally give the 7 minutes

Generally, filling out the template generates many ideas and serves as a great vehicle for a breakout group & conversation

Step 3

• time: about 7 minutes
• Debrief exercise
• Goal of the debrief is:
  • validate people's ideas
  • share & cross-pollinate
  • gently challenge and push back when ideas don't conform with Mozilla values
• Instructions:
  • Have participants share some of their favourite brainstormed ideas
  • Facilitator should capture ideas in this conversation & share this as a list

Step 4

• time: about 1-2 minutes
• Close out this exercise
• Summarize best ideas you heard
• Share some of your own ideas
• Best practices from across Mozilla include:
  • incentives could be "part of the team," coder "rep", etc.
  • triaging issues - learning what level / skill set is required is a great way to learn how Mozilla works as well as learning to identify skills needed
  • encouraging lurkers - watching people, watching bugs is a great way to learn

Wrap up

• time: about 2-5 minutes
• Purpose: to create a sense of shared value (or determine if the workshop did not create value for participants
• Process:
  • Ask participants to share best thing they learned or heard
  • Ask participants to share one action they intend to take as a result of the workshop
  • 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.
• Logistical questions to consider
  • If there's a follow-up class, share details
  • Invite feedback via email