Mozilla Study Groups

The First Four Events

Starting a Mozilla Study Group can be a great way to share skills and bring your community together. Here's a step-by-step guide to getting your own off the ground.

Made by the Mozilla Science Lab

Part 1: Getting Set Up

  1. Set up the website. Follow the instructions here to get your website and message board set up, and set up a chat room by following the instructions here; if you have any trouble, don't hesitate to ask for help! Also, let us know you're starting a study group by opening an issue, and we'll put you and your website on the Study Group Map.
  2. Book your first event. Make it a hacky hour to invite people to come out and discuss this new Study Group's goals and plans. Instructions for listing an event on your website are in the README of the repository you forked in the previous step, or you can see them here.
  3. Start your outreach communication.
    • Get an announcement about your new Study Group into the next departmental email. Here's a template to get you started - feel free to remix!
    • Announce on mailing lists of groups you think will be interested.
    • Look for opportunities to mention your Study Group in other meetings or events.
    • One week before your first event, tweet a link to the details daily, at different prominent Twitter users in your field & local region.
    • All communications should have a link to your website, a link to the issue tracker in your repository encouraging people to start conversations there as well as watch that repo, a pointer to your Code of Conduct, and a reminder that beginners are very welcome.

Part 2: Your First Events

  1. Event 1: Welcome Hacky Hour (Week 0) This is the event you booked in part 1, step 2 above. Make sure the community knows that all are welcome, and that you'll be discussing starting a Study Group for coding in research.
    Your Goals:
    • Identify co-facilitators & delegate. The people who come out to an initial event are likely to be enthusiastic and good candidates for people to collaborate with on organizing your Study Group; try and find as many as possible at this stage to help organize and get the word out. Remember to add them as Collaborators on your GitHub repo!
    • Find out what the community wants. Take the opportunity to talk to people about what they would find most useful in a Study Group. What languages are interesting to your community? Do they want more guided lessons, or more coworking opportunities?
    • Set the tone. Your first event will set the tone for your Study Group. Hand out copies of your code of conduct, and do not underestimate the power of baking cookies.
  2. Event 2: Intro Code Along (Week 1) For your first classroom event, organize a code-along for beginners; for this event, the simpler the content, the better, in order to include as many curious people as possible.
    Your Goals:
    • Start the event by going around the room with lightning introductions: name and current research interest (tweet length!)
    • Let everyone at the event know what the goals of the Study Group are.
    • Make sure they know how to find your chat room and issue tracker, encourage them to ask questions & make suggestions there, and watch your repository so they get email updates of new events.
    • Invite everyone to lead a code-along or suggest an event.
    • If the demo leader creates a new lesson for this session, make sure the notes get posted somewhere on GitHub, and add the link to a list of lesson material in your repository.
  3. Event 3: Topic Code Along (Week 2-3) Encourage one of the people who suggested or volunteered a code-along on a particular package or tool to lead a demo. Make sure the event is listed on the website with date, place and any dependencies needed at least a week in advance.
    Your Goals:
    • Before the lesson, have a chat with the demo leader about audience: this session should be interesting for intermediate users who would like an introduction to the package in question, but also be explicit enough to be followed by a beginner.
    • Remember to encourage the demo leader to post their lessons somewhere you can link to, or submit them to the Mozilla Science Lab if people don't want to host them themselves.
    • As always, encourage everyone to propose or lead a session on the issue tracker.
  4. Event 4: Coworking Session & Hacky Hour (Week 3-4) The week following your first couple of code-alongs, try out a coworking session, and follow it up with another hacky hour.
    Your Goals:
    • At the start of the coworking session, ask ask everyone to call out what they're working on that day, and what tools they're using.
    • During the session, keep an eye out for someone who might need help, and take the time to work with them in order to set an example of collaborating and asking questions.
    • At the end of the coworking session, ask everyone to give a quick update on what they worked on, and invite them to show a demo if they like.
    • Reconvene at the pub for hacky hour - make sure to announce beforehand when hacky hour is starting, so those who can't make the coworking session can meet you there.

After completing this first month of activities, you should have an idea of what your community likes, a pattern of communication about your events established, and a group of people helping co-organize. From here on, you're in the driver's seat! Remember to make sure everyone feels included and welcome, and let us know how things are going.