Participation/Resources/Identifying contributors/Documentation

Anyone at Mozilla - module owner, newcomer, veteran, staff, volunteer should feel welcome to initiate or run the Identifying Contributors 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 Identifying Contributors Workshop. As such this page is a sort of loose manual or guide. 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?

The Identifying Contributors workshop is a sequel to the Designing For Participation workshop. The Identifying Contributors workshop was created in order to get Mozilla community members to think about how to better reach out and engage new contributors. As such the workshop has these goals:

• impart on participants some best practices around who and how to reach out to when trying to build a contributor community
• 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'd like to better understand what motivates current contributors to my project so that I can help them more
• I'd like to better understand what might motivate contributors so that I can attract more of them
• 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
• How do I grow the community around the work I do strategically so that it maximizes its leverage

Slide Deck

The slides for this presentation can be downloaded here in

• Identifying Contributors PDF Version
• Identifying Contributors Keynote Version

Assumptions

Some assumptions about both participants and facilitators:

• 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.
• It is nice if participants (and facilitators) have taken the Designing For Participation workshop however it is not a prerequisite.
• IMPORTANT FOR FACILITATORS: One of the key goals of this workshop is to introduce participants to the concept of personas as a way to create an archetypes they can use to help design tools, campaigns, talking points, activities, etc… to engage contributors. In order to lead this session is it imperative that the facilitator be at least casually familiar with the idea of a persona. For some good background reading on the subject please consider the links below:
  • ?
  • ??
  • ???

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
• opening exercise
• using personas for community building
• application of personas to current projects
• 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

Opening Exercise

The goal of the Opening Exercise is to prompt participants to think about contributors as a “type.” The point here is not to define that type or come to a conclusion, but rather seed an idea and prompt a discussion that get participants thinking.

For the purposes of this syllabus I use the Mozillans Community Directory for this exercise, however an alternative resource could be used. The key elements of a resource are:

• it is a place where one might find a list of contributors to Mozilla (or another project or organization)
• there is enough biographical information about those contributors that something about them could be inferred
• it is relatively easily accessible to the workshop participants, ideally so they can browse it individually

Slide 3: Introduce Case Study

• this slide should take about 10 minutes to discuss
• ask participants to head over to the Mozillans Community Directory and login.
• have each participants find either the “group” and/or “skill” that most closely overlaps with the work around which they would like to build community (note: it is interesting if there is no group that overlaps with their work).
• give participants 2-4 minutes to ask themselves:
  • is everyone in the Community Directory staff?
  • are there volunteers?
  • among the volunteers - are there common traits between them?
  • are these volunteers representative of what you think your community is? could be? should be?

Slide 4: Facilitate Discussion

• call the participants “back to order”
• open the discussion with some opening questions such as:
  • any overall thoughts?
  • observations about who is here in the Community Directory?
  • who is not here
  • who could be there
  • common traits among those present

Goals and Risks

• Risk to manage: There can be a risk that this discussion becomes about the Community Directory (its feature set, usefulness, etc…). Minimize this by acknowledging the limits and benefits of the Directory and focusing the conversation back on “who are your contributors at the moment.”
• Purpose of the discussion is to get people to:
  • start thinking about who their current contributors are
  • what do they know about them
  • have they ever thought of them as “a group”
  • sharing what they have learned about their contributors

Using Personas for Community Building

Please read the Assumptions section above BEFORE leading this session section Purpose:

• Introduce the concept of personas and how they could apply to open source community development
• Have participants create a persona of a contributor for the work they do at Mozilla right now

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 20-30 minutes (however, if you are not bound to a one hour workshop, this session could last much longer.

Slide 5

• Time: 5 minutes
• Introduce the concept of personas
  • The creation of an archetype, a strong example of the type of person you are trying to engage
  • We use personas to help us design tools, communications, websites, activities so that they will appeal more immediately to our target community
  • Applying personas to open source communities is a nice way to focus you around trying to attract the people that will:
    • have the skill sets most relevant to your work
    • be most interested and/or rewarded in your work
    • add the most value to the work you are doing

Slide 6

• Time: 2-3 minutes
• Introduce participants to the persona worksheet (don’t let them access it, just show the slide)
• Walk participants through the basic questions in the template
  • What do the think and feel
  • What do the hear
  • What do they say and do
  • What do they see

Slide 7

‘’Step 1’’

• Ask participants to read over the completed sample persona worksheet
• Time 2-4 minutes
• This worksheet was created for SUMO by David Eaves
• Based on the profiles of the people who volunteer for support in the Community Directory

‘’Step 2’’

• Time 4-5 minutes
• Debrief the completed sample persona worksheet
• Core question: Does this workshop give you a sense of how to complete a worksheet like this?
  • What do you like about the worksheet?
  • What do you find challenging

Application of Personas to Current Projects

Slide 8

’*Share with participants link to the persona worksheet

• ask them to complete:
  • Part 1: Defining Characteristics; and
  • Part 2: Empathy Map
• Instructions for the exercise:
  • Note that worksheets can help structure people’s thinking and help explore opportunities. They also make it easier for people from disparate parts of Mozilla to compare their work
  • 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
• Participants working on common projects or in the same group can work together on a common sheet, or separately and compare their work afterwards

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

Slide 9

Step 2’’

• 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

Slide 10

• time: about 5 minutes
• Complete Part 3: Next Steps

Slide 11

• time: about 5 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

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