Participation/Resources/Designing for participation/Documentation: Difference between revisions

Participation/Resources/Designing for participation/Documentation (view source)

Revision as of 23:08, 27 November 2013

2,567 bytes added , 27 November 2013

no edit summary

David a eaves

Confirmed users

288

edits

@@ Line 41: / Line 41: @@
 =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=
-Pull out "Goals" slide (#3)
+The course is broken down into four parts:
+*introduction
-Understand:
+*case study and debrief
+*application to personal situation and debrief
-- What makes for a good volunteer contributor?
+*wrap up
-- 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.
+==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.
-Lessons from this conversation:
+===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
-- treat people like they're competent.
+===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
-- make things easy to find; don't try to test your users at this point
+==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.
-- leaving tasks undefined/open can be daunting to some potential contributors.
+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.
-Point to slide of key takeaways.
+'''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
-- e.g. ability to work on discrete tasks, asynchronously.
+'''Step 3'''
+*Give participants a solid 5 minutes to read and thing
-- range of incentives/motivations
+'''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
-Community Building Scenario
+==Personal Application==
+===Slide 5===
+*time
 - Google Doc template - encourage people to make a copy so they can edit without creating chaos