Planet Webmaker

Introducing Mozilla Campus Clubs

Julia Vallera

Wed Sep 21 2016 15:48:09 GMT+0000 (UTC)


In 2015, The Mozilla Foundation launched the Mozilla Clubs program to bring people together locally to teach, protect and build the open web in an engaging and collaborative way. Within a year it grew to include 240+ Clubs in 100+ cities globally, and now is growing to reach new communities around the world.

Today we are excited to share a new focus for Mozilla Clubs taking place on a University or College Campus (Campus Clubs). Mozilla Campus Clubs blend the passion and student focus of the former Firefox Student Ambassador program and Take Back The Web Campaign with the existing structure of  Mozilla Clubs to create a unified model for participation on campuses!

Mozilla Campus Clubs take advantage of the unique learning environments of Universities and Colleges to bring groups of students together to teach, build and protect the open web. It builds upon the Mozilla Club framework to provide targeted support to those on campus through its:

  1. Structure:  Campus Clubs include an Executive Team in addition to the Club Captain position, who help develop programs and run activities specific to the 3 impact areas (teach, build, protect).
  2. Specific Training & Support: Like all Mozilla Clubs, Regional Coordinators and Club Captains receive training and mentorship throughout their clubs journey. However the nature of the training and support for Campus Clubs is specific to helping students navigate the challenges of setting up and running a club in the campus context.
  3. Activities: Campus Club activities are structured around 3 impact areas (teach, build, protect). Club Captains in a University or College can find suggested activities (some specific to students) on the website here.

These clubs will be connected to the larger Mozilla Club network to share resources, curriculum, mentorship and support with others around the world. In 2017 you’ll see additional unification in terms of a joint application process for all Club leaders and a unified web presence.

This is an exciting time for us to unite our network of passionate contributors and create new opportunities for collaboration, learning, and growth within our Mozillian communities. We also see the potential of this unification to allow for greater impact across Mozilla’s global programs, projects and initiatives.

If you’re currently involved in Mozilla Clubs and/or the FSA program, here are some important things to know:

  • The Firefox Student Ambassador Program is now Mozilla Campus Clubs: After many months of hard work and careful planning the Firefox Ambassador Program (FSA) has officially transitioned to Mozilla Clubs as of Monday September 19th, 2016. For full details about the Firefox Student Ambassador transition check out this guide here.
  • Firefox Club Captains will now be Mozilla Club Captains: Firefox Club Captains who already have a club, a structure, and a community set up on a university/college should register your club here to be partnered with a Regional Coordinator and have access to new resources and opportunities, more details are here.
  • Current Mozilla Clubs will stay the same: Any Mozilla Club that already exists will stay the same. If they happen to be on a university or college campus Clubs may choose to register as a Campus Club, but are not required to do so.
  • There is a new application for Regional Coordinators (RC’s): Anyone interested in taking on more responsibility within the Clubs program can apply here.  Regional Coordinators mentor Club Captains that are geographically close to them. Regional Coordinators support all Club Captains in their region whether they are on campus or elsewhere.
  • University or College students who want to start a Club at their University and College may apply here. Students who primarily want to lead a club on a campus for/with other university/college students will apply to start a Campus Club.
  • People who want to start a club for any type of learner apply here. Anyone who wants to start a club that is open to all kinds of learners (not limited to specifically University students) may apply on the Mozilla Club website.

Individuals who are leading Mozilla Clubs commit to running regular (at least monthly) gatherings, participate in community calls, and contribute resources and learning materials to the community. They are part of a network of leaders and doers who support and challenge each other. By increasing knowledge and skills in local communities Club leaders ensure that the internet is a global public resource, open and accessible to all.

This is the beginning of a long term collaboration for the Mozilla Clubs Program. We are excited to continue to build momentum for Mozilla’s mission through new structures and supports that will help engage more people with a passion for the open web.

How to bring open source to a closed community

Abigail Cabunoc

Tue Sep 20 2016 04:19:23 GMT+0000 (UTC)

This is (roughly) a transcript of my talk at Strange Loop this year! At least, it’s what I meant to say. Watch the video for all the fun Canada facts and nervous rambling.

Slides made using reveal.js. Screenshots captured using Decktape


First off, I want to thank the organizers for this opportunity. Strange Loop is such an amazing conference – I can’t believe I fist attended with an opportunity grant two years ago. The friendships and community I’ve built here have been amazing.

Let’s get started!


Hi, I’m Abby! This is me. I work for the Mozilla Foundation as Lead Developer of Open Source Engagement. This means I with with the open source projects and community around the different programs at the Mozilla Foundation including Open Science, Internet of Things, Women and Web Literacy, Learning and Advocacy.

Also, I’m from Toronto. This is important because Toronto is great.


A bit of history: I came to Mozilla because of the Mozilla Science Lab. Before Mozilla, I was working in research labs where we were dealing with so much data and analysis. It was easy to see how the openness and collaboration available on the web could make science better.


At Mozilla, our mission is to ensure the Internet is a global public resource, open and accessible to all.

The Science Lab is applying Mozilla’s mission to a specific community of practice. Most of the work I’m covering today was done within the Mozilla Science Lab.


So, today we’re talking about bringing open source to a closed community. Slight disclaimer: this is my story! This is not a how-to that will work for everyone.

The past eight years of my career, I’ve been working on open source projects for researchers and thinking of ways to bring more open source to academia. I want to share some of the lessons I’ve learned and hear from you as we start to expand to other Mozilla Foundation programs.


My story starts with open source. I actually wrote open source code for years before I fully understood this movement.


I find it’s helpful to look at origins of terms and words to help give some cultural context around what this meant at the time.

‘Open source’ is interesting because the free software movement predates this term by over a decade.


In 1997, Eric Raymond published an essay on the state of free software at the time, “The Cathedral and the Bazaar”. He saw two types of free software:

  • The Cathedral is a public space where anyone is welcome to attend a service, but the experience is put on by a small group of people in charge. They decide what happens and when. This is like a development team working on software among their trusted group, then releasing a new version to the public.
  • The Bazaar is an open space where people come along, setup tables and start bartering and selling whatever goods they have. Anyone can come and shape the experience in this space. Raymond saw this happening in Linux at the time, a diverse group full of differing agendas that was able to work together to build a stable system.

Also, I can’t be sure, but it looks like there might be a fire in this Bazaar. Metaphor for open source? :)


This essay inspired the Netscape Corporation to release the Netscape browser suite as free software the following year. This became the basis of the Mozilla Project and inspired the term open source.


I don’t know if you all remember the early 2000s, but there were no browser wars then – Internet Explorer was everywhere. The fact that a group of passionate open source contributors were able to come together and build Firefox, the browser that toppled the giant, was really amazing.


At the heart of open source is the idea that a diverse group working on a problem is better.

But how do we get there? How do we work in a way that brings this diverse group together in the first place?


At Mozilla, we call this “Working Open”, being public and participatory. This requires structuring efforts so that “outsiders” can meaningfully participate and become “insiders” as appropriate.

For me, this way of thinking helped me understand what open source should look like in our day-to-day work.


For the official definition of open source, the Open Source Initiative has ten points outlining what exactly open source software is. Having this comprehensive definition along with the OSI has helped the open source movement stay strong today.


The next part of my story is Science! I worked in research labs writing scientific software for most of my career.


Sometimes, trying to participate in research can feel like this. As soon as I left academia I lost access to most published research in academic journals. Even within academia, institutions can feel like ivory towers where only the invited few can participate.

These drawings are by John McKiernan for “Why Open Research?”


On the other side of the wall, there can be a lot of fear around getting scooped or someone stealing your data. This stems from a lack of knowledge around open licensing options.

Contrasted with my experience in open source, this helped me see that on both sides of the wall, there’s a need for culture change if academia is going to work openly.


One of the first projects I worked on when I joined Mozilla Science was Collaborate, a collection of open source software for scientists. This was a great way to highlight some of the work going on in this community, but after watching these projects for awhile, I learned that researchers weren’t very good at open source.

In general, the projects weren’t as welcoming as they could be. Sometimes, requests from potential contributors for more information would be ignored for weeks. This list of projects still exists today and helps the open science space tremendously, but we thought we could make this better.


This brings us to the final part of my story (and most of this talk): Fueling the movement.


I couldn’t find a definition of 'movement’ that I liked, so I defined it here as “mobilizing a community around a shared purpose”.

One of my favourite visual representations of a movement is a this clip of a dancing guy fro Derek Siver’s TED talk on leadership and movements.

One guy dancing enthusiastically slowly mobilizes those around him. Once you hit critical mass, you have a movement! You watch him change the culture here in a few minutes.


This is a figure from Marshall Ganz’s essay “Public narrative, collective action, and power”. A key part of a movement is mobilizing people to action. This diagram shows how we need both the strategy and narrative (head + heart) to take action.

Working with researchers, many of them want to be working open and collaborating more – you can see how many open source for science projects wanted to be listed in 'Collaborate’. However, there’s a lack of knowledge or strategy around how to do this effectively. This is when we realized we need to make resources outlining the steps involved in running an open source project.


So we started to think about how we can best fuel the open source movement within academia. I think we can summarize it in these three steps:

  1. Resources: Creating the resources needed to mobilize others
  2. Leaders: Selecting leaders in our community. Use the resources we created to mobilize them.
  3. Mentorship: Helping our leaders mobilize others through mentorship.

First up, resources!


To create resources, we did an exercise focusing on the “Working Open” aspect of open source. How do outsiders become insiders on our projects? We’re going to do this exercise now as the audience participation section of the talk!


Think of a place you felt welcomed the first time you visited. This can be in person or online. I’ll give you a minute to think of a place in your head.

Okay, what places did you think of?

Some of the answers:

  • Strange Loop
  • Canada
  • College
  • Niagara Falls


Now, what made it welcoming?

Some of the answers:

  • Strange Loop
    • Everyone is friendly and wants to know where you’re from and what you do. >> friendly, human welcome
    • Food and snacks. >> takes care of our needs
    • Smaller Preconf events >> makes it easy to find connections
    • Opportunity grants >> makes it easy to get involved
  • College
    • Orientation week >> orient people to their new environment, show them where they can get involved and make friends


How can we apply these to software projects?

Some of the answers:

  • friendly, human welcome
    • say hi and welcome new people in chat, mailing list, etc
  • take care of our needs
    • clear installation instructions, contributing guidelines
  • make it easy to get involved
    • good README, starter issues for new people


We went through this exercise and came up with a bunch of ways to make open source projects more welcoming. We came up with these seven points and put together handouts for each point.

I think we came up with a lots of these in the exercise we just did!

  1. Public repository: make sure your code, history, and discussion is public and available on the web.
  2. Open license: this goes back to the official Open Source definition. Make sure your code is licensed in a way that others can legally contribute and remix your work.
  3. README: Especially with GitHub, this is often the people’s first introduction to a project. Be welcoming!
  4. Roadmap: At the very least, break down what you plan to do in issues. This way people know how can get involved and what work you’re looking for.
  5. Code of Conduct: Collaboration is hard and collaboration with a diverse group can be messy. A code of conduct is a good step towards making people feel safe and outlining the behaviour expected in the group.
  6. This is another file that has become more important because of the GitHub experience. Your contributing guidelines can outline how a new contributor can participate in your community.
  7. Mentorship: This is a larger topic that covers both the attitude and strategy needed to make something welcoming and fuel a movement.

I’ll be sharing more about each of these steps later in the talk.


Next part of 'Fueling the Movement’ is investing and mobilizing leaders. We can use the resources we just created to mobilize some of our more involved community members.


We did this at our first Working Open Workshop in February in Berlin. We brought together some of our existing project leads and more active community members. This was a group of people passionate about what we’re doing and eager to learn skills that would help their work be more open.

We put on a two day workshop going over most of the lessons from the Open Source Checklist. We built in lots of time for group work where participants could start applying the lessons they’ve learned to their open source projects.

This was a great start, but we wanted to keep up momentum after the workshop. We’ve all done weekend courses and workshops where we leave with the best intentions, but then life gets in the way and we forget. To combat this, we offered 1:1 mentorship after the workshop.

We planned this workshop to happen three months before our Global Sprint, a two day hackathon on open source and open data projects. The 1:1 mentorship would occur over the three months preparing the projects for the Sprint.

Now we’re going to draw out the movement in action!


We start here with Abby (that’s me!) and Aurelia, Community Lead for the Mozilla Science Lab. Aurelia is also a strong open source developer in her own right. The two of us decided to offer mentorship to all Working Open Workshop (WOW) participants.


27 people attended WOW.


25 of them signed up for 1:1 mentorship. We called this group the Open Leadership Cohort (OLC).


We met with each project every two weeks for a quick 30min check-in.

We started our mentorship meetings by setting goals. WOW was fresh in their minds! We helped set goals around:

  • Their community: what do they want their contributor base / user base to look like?
  • Their product: Will they ship a new feature or release an MVP at the sprint?

Then, we set a loose plan around how to accomplish this over three months. This set us up to be able to do lightweight check-ins every two weeks to see how things are going and where we need to troubleshoot.


As soon as we started, 8 new people were added to the program since many projects had co-leads who wanted to join in.


The yellow nodes are all the people that made significant contributions to mentored projects at the Global Sprint at the end of this round of mentorship. The contributions were significant enough that the project lead decided to give them a shout-out on the Mozilla Science Project Call.

It was great to see the project leads start to engage and mentor new contributors on their projects.


For a bit more background on the Global Sprint, here’s a picture from our 2015 Global Sprint. This year, we had 40 sites around the world all hacking from 9-5 in their time zones.


We saw a massive increase in participation through GitHub activity this year. I think this is directly linked to the resources we made on working openly which we offered to all participating project.


Now that we mobilized the leaders, we wanted to work with them as they mobilized others. We do this through more mentorship.


We selected a few of the people we mentored to become mentors in round 2. We intentionally kept the group of mentors small as we tested this out.


We wanted to test our this type of mentorship around open source in other programs. We asked each program to nominate a few community members for mentorship. We have participants from Open Science, Internet of Things, Internet Policy & Advocacy and more. We paired each mentor with 1-2 participants.

This round of the program started mid-August and is running till the Mozilla Festival (MozFest), Oct 28-30 in London UK. MozFest is the world’s leading event for and by the open Internet movement. All the participants and mentors in the program will be running sessions at MozFest – we’re using this program to help prepare their projects for the festival.


Now we’re going to look at a few stories and lessons we’ve learned going through this experience.


I’m going to go through each lesson from the Open Source Checklist and tell you a story about how that lesson affected someone in the mentorship program.


First up is having a Public Repository and looking at Achintya’s story.


Achintya is a science communicator at CERN and a PhD student in scicomm at UWE Bristol. We’re going to talk about how GitHub usage helped him centralize and organize efforts around his project.


Achintya has an interesting project, Open Cosmics: Cosmis-ray physics for everyone!

For a bit of science background: cosmic rays are high-energy particles that bombard the earth’s atmosphere. This produces showers of particles that we can detect on the earth’s surface. You can even detect these particles with your phone by installing CRAYFIS. You can also get a pocket sized detector from Cosmic Pi.

The problem that Achintya is tackling is that there are all sorts of ways to measure cosmic-rays, but each project stores the data in different formats. Achintya’s project, Open Cosmics, attempts to bring together all these efforts and help with interoperability and data standards.

You may have noticed in the “movement graph” that Achintya brought on three additional projects leads to this project. He was in a unique position where he acted a facilitator between all the projects collecting cosmic-ray data.

At the end of our first round of mentorship, when we asked Achintya was most helpful he said it was learning how to use GitHub for project management. GitHub gave his community a central place to community and the tools he needed to organize and discuss.

Now, Achintya is mentoring two other projects!


So, make sure your code is available! At the Mozilla Foundation we rely a lot of GitHub and have produced some trainings on GitHub for collaboration. But there are many other services you can use for your public repository.


Next, we’re going to look at having an open license and how that helped Rob.


This is Rob! He was fairly new to open source when he joined us.


This is a blurry Rob at our Working Open Workshop. We’re all doing the 'Open Web Stretch’ here. I believe they’re all “leaning left to avoid the NSA”.


Rob’s project was creating a tool built around PubMed Central, a repository for life science and biomedical research. He created PMC-ref, a tool where you input a paper, then it checks which references in the paper are free to read.

It’s a pretty simple tool that can have a huge impact for a life sciences researcher. Especially if they don’t have access to all the big journals.


I mentioned Rob with this lesson, because going through his GitHub repo, he added an open license days after the Working Open Workshop. Yay MIT license!


If you see the yellow dot linked to him, Rob received his first open source contribution ever during the Global Sprint! The contributor, Deborah, actually wrote a blog post about her experience at the Global Sprint and contributing to this project. The fact that he had an open license made this possible and legal.

Rob is now mentoring Minn. Minn is running an interesting session at MozFest around facial recognition to create art and generate metadata.

open-source-strangeloop-2016-063.png is a great resource for picking an open license for your software. For something easy, Mozilla Science recommends MIT or BSD.


Next we have Kirstie who really embraced writing a great README and having welcoming project communication.


This is Kirstie! She’s a postdoctoral researcher in the Brain Mapping Unit at the University of Cambridge.


We recently announced that Kirstie is one of the new Mozilla Fellows for Science this year! Mozilla Science has a fellowship program for researchers who want to influence the future of open science and data sharing within their communities. Fellows spend 10 months as community catalysts at their institutions and building lasting change in the global open science community.


During the first mentorship round, Kirstie worked on her project STEMM Role Models - inspire future generations by providing the most exciting and diverse speakers for your conference. She built a simple database of great speakers for conference organizers to use when planning an event.

Kirstie took to heart the idea that to make our projects as welcoming as possible, we need to have clear and friendly communication. Even here, on her draft landing page, she makes a real effort to welcome everyone at the top.


Looking back at the mentorship graph, Kirstie did such a great job explaining her project she was able to engage a couple contributors who did significant work building an MVP (minimum viable product). Kirstie has a background in neuroscience (not web development!), so watching her bring technologists and designers together to build something she is passionate about was really inspiring!

Now, as Kirstie begins her fellowship, she’s mentoring two projects including a group from the Detroit Community Technology Project. They’re addressing gentrification through storytelling technology and plan to have a booth at MozFest.


We have a few resources designed to help you write a good README and communicate your project.


First is the Open Project Communication handout.


In the handout, we include the Open Canvas, a tool I find very helpful when starting an open source project. Open Canvas is remixed from Lean Canvas, a popular tool from the startup world that helps you make a one page business plan.

I worked with Jordan Mayes from Top Hat, to remix this for open source projects. We removed some boxes that didn’t apply and added more thinking around community and contributors. You can read more about the process of creating Open Canvas in his blog post.

The Canvas forces you to think through the problems you’re addressing and your proposed solution. We divide the canvas in two main sections, Product and Community, to get people to think about their community, what they’re building, and how others will get involved.


Next in our checklist is writing a roadmap, featuring Bastian.


Here’s Bastian!


When I first email introduced Bastian to his new mentee, his mentee replied with “Thanks for introducing the Mark Zuckerberg of open-source genetics! What a great mentor to have!” and linked to this article. I had no idea this article existed! But I am not surprised considering Bastian’s project.


Bastian is a PhD student in bioinformatics, and was working on openSNP (pronounced open snip). SNP stands for Single Nucleotide Polymorphism, a type of mutation that can occur in your DNA. openSNP let’s you upload your 23andMe (or any other genotyping service) results online. You can learn more about your results, find others with similar genetic variations, and help scientists discover more genetic associations.

When Bastian first uploaded his genetic data on GitHub (before he made openSNP), he received an email from someone who found the data online and analyzed his genetic report. The analysis said he might have an increased risk of prostate cancer. Since this type of mutation is inherited, he told his dad to go to the doctor. They found a tumour growing in his dad’s prostate, but they were able to catch it in early. His dad is alive and well today.

OpenSNP benefited greatly from going through the Roadmapping exercise! I worked with Bastian and Philipp (co-lead on the project) to plan out a few features and fixes that needed to be done. This helped then identify the need for new volunteers and shaped up a few projects they could submit to Google Summer of Code (GSoC).

By making a roadmap, they were able to accomplish a tremendous amount in a few short months. You can read about their GSoC experience on the openSNP blog.


We have a couple exercise you can go through to write a roadmap for your project. Writing down what you plan on working on helps new contributors know where they can get involved.

A roadmap can be a simple as a collection of issues in your issue tracker to a comprehensive wiki outlining the future of your project.


This handout walks you through picking a few milestones and breaking down the tasks needed to get there.


Next up is code of conducts with Richard.


You might notice from the graph that Richard wasn’t part of the first round of mentorship. Richard was actually a 2015 Mozilla Fellow for Science. He did some amazing open source work during his fellowship year, I thought he would be a great mentor.

Notice the moss beard in his avatar.


Sadly, he doesn’t walk around with a moss beard in real life. This is a picture of Richard and his partner Steph at MozFest 2015. MozFest is so awesome that we had capes, buttons, and fox masks. You should come.

I listed Richard under code of conducts since he has an incredibly thoughtful approach when writing documentation for communities.


You can see the code of conduct Richard wrote in the last link, Slidewinder Code of Conduct.

In this particular code of conduct, he has a section called “Open [Source/Culture/Tech] Citizenship” that outlines the goals of having an open culture and encourages others to reward welcoming behaviour. I think this is incredibly important as we’re trying to build welcoming communities.


If you get stuck, Mozilla Science has a CC0 code of conduct you’re free to take, remix, and use however you like!


Next is Contributor guidelines and Tim.


Tim was a physicist at CERN when we started the program. He recently moved to Zurich and is now a tech consultant.


Tim was working on Everware, a project trying to address reproducibility in scientific software. Everware uses Docker to launch an instance of a jupyter notebook directly from a GitHub repository.

Tim cares a lot about reseach reproducibility. I first met him at a hackathon a CERN where he first launched Everware and ruffled some feathers with his insistence that we need to focus on better research reproducibility.

Now, Tim’s mentoring two other groups including one looking at research reproducibility, ReFigure.

Tim and the other Everware developers wrote some great contributing guidelines that helped quite a few people get involved before and during the Global Sprint.


For resources, we have a guide that walks you through creating your contributing guidelines.


The file should be named and placed in your root directory.


We break down the different parts of your contributing guidelines in the exercise.

Open with some cheer! You should celebrate someone looking to contribute to your project. Then, introduce the document and explain what these guidelines are for.

The bulk of the document should be some how to guides on contributing, along with expected norms the group follows, like a style guide.


The naming convention has become popular since GitHub integrates this in their interface. If there’s a file in the root directory of a project, GitHub will display this notice as the top of the page whenever someone opens a new issue or pull request.


The last step is our catch-all for attitude and process, Mentorship. Here, I’m highlighting Madeleine since she’s done a great job including and delegating to others.


Right off the bat, you can see how connected her node is in the graph since she’s been able to bring so many people into her work.

Madeleine is a PhD student at the University of Toronto. Madeleine not only runs an open source project with us, but she also runs a weekly open science meetup at her school, the UofT scientific coders.


Madeleine (on the left) actually spoke about running events at our Working Open Workshop because of her experience with the UofT scientific coders.


Her project is phageParser which uses open data to better understand CRISPR systems. CRISPR is all the rage nowadays because it’s opened the door for faster and cheaper targeted gene editing.


CRISPR stands for Clustered Regularly Interspaced Short Palindromic Repeats. In the diagram the black diamonds are repeating DNA. In between the repeats are spacers. Spacers are pieces of DNA from a virus that attacked the system. The CRISPR system saves the virus DNA so that if it comes across the virus again, it can recognize it and cut it out, hence targeted gene editing.

Madeleine’s group realized that there are many openly published genomes with CRISPR systems. Her project is trying to collect and analyze these systems to try to find patterns and learn more about CRISPR.


Madeleine was able to engage so many people during the Global Sprint that she ran out of tasks for new contributors. I’ve noticed that Madeleine is naturally good at finding tasks and asking others for help, both in her project and with the UofT scientific coders.

At her first UofT scientific coders meeting, she delegated registering a club, managing the GitHub repository, and baking cookies for next week. Most of those people are now the green dots co-leading the group.

For those of us who need some instructions on how to delegate and involve others, we have a few exercises to help you start thinking about mentorship.


Good first bugs can be a great way to give a new contributor a small win when they first start working on your project. Identify a few smaller issues that would be appropriate for someone completely new to the project. Ideally the hardest part of completeing this issue would be setting up their development environment.

This helps you reward new contributors sooner.

Another exercise that helps you think about a contributors progression through a project is the Personas & Pathways exercise. This gets you to create a persona of an ideal contributor. Then, you can outline their pathway from when they first hear about the project, to their first contribution, to becoming a maintainer, to maybe even running the project when you’re ready to hand it off.


To summarize, these resources are helping us mobilize leaders in the open source movement.


Combined with trainings and mentorship, we’re working to fuel the open source movement in science, advocacy, learning, IoT and more.


I mentioned MozFest a few times, you should all come! It’s a lot of fun and you can meet a lot of people and projects I highlighted in this talk.


MozFest really is a place where “you can make things that matter”


Huge thanks to the many people that took part of the mentorship program as participants, mentors, and content creators. There’s a lot of people that made this happen.


You’ve all been awesome!


Thank you!

I talk about projects from a lot of different fields in this presentation. I’m not an expert in all these fields, so I may have explained something wrong here. Happy to make corrections! Please be kind!

PhD Fieldwork, Day 1: A Researcher in Residence at the Tate (^.^)

Kat Braybrooke

Fri Sep 16 2016 15:24:09 GMT+0000 (UTC)

Today is a big day in the web-wolf glitter land that is my PhD. After a crazy and wonderful year of reading, discussing, traveling and (over!)thinking everything there is to think about spaces for digital making, cultural institutions, methodologies and open creative practices, I start the pilot stage of my doctoral fieldwork at the Tate Britain, situated within the ever-colourful Taylor Digital Studio as its new Researcher-in-Residence. I have consent forms ready from the University of Sussex, about a thousand web broswer windows open on the Tate’s computers, a T4 file full of community photos and about 20 pages of to-do’s - and yet, it feels no small task to get started.

As a part of the study I’m undertaking with the Tate and other cultural institutions in the UK, my aim in hanging out, messing around and geeking out at these spaces, in addition to implementing more formal qualitative methods like participant observation and interviews, is to engage with the situated knowledges and actor-network theories of Donna Haraway, Bruno Latour, Doreen Massey and other great thinkers as a user myself - not as an “objective” researcher, seemingly removed from the environments I am actually an active part of. This is because when we make things in a space like the Tate’s Digital Studio together, we all become connected - whether we happen to be a computer, a workshop participant, a gallery curator or an observer. We all help make these sites what they are. Without these interactions, a makerspace is just a conglomeration of infrastructures, plaster and walls alone, without meaning or identity.

This project’s data collection starts, perhaps fittingly, with making. From September to December, I’ll be spending my Fridays in the Studio, collaborating with other PhD and researcher groups and with the Tate’s excellent Digital Learning team members, while playing the role of both researcher and designer through a few different hands-on projects. The first intervention I’ll be working on is SPACEHACKER, an evolving artwork that I’ll be launching as part of MozEx, an exhibit curated by the Tate and the V&A as part of this year’s Mozilla Festival in London. SPACEHACKER implements critical and speculative design models by asking participants to sketch out their imaginaries of a digital space that members of their community would feel welcome at. For those interested in getting involved (I’d love collaborators on this project!), I’ll be presenting it along with a few other (mega talented!) MozEx artists in this public pop-up at the Tate on October 10th-11th.

Community making at a workshop entitled “Wandering Ruins” in 2014.

While learning about speculative user imaginations of digital spatiality through this artwork, I’ll also be working with Tate teams as a design practitioner, building a digital mosaic website on the ever-excellent Tumblr platform that highlights the many workshops and community happenings that have occurred at the Digital Studio since it opened in November 2013. Through these hands-on methods and more traditional qualitative observation and interviews, I hope to help build a public-minded narrative of the myriad experiences of users at this site, and the groups who have helped bring them to life - while building an understanding of the politics and institutional apparatuses of access, ownership and power that may also weave themselves around these interactions. My goal with this multi-level approach is to keep the research process as open, iterative and participatory as possible - which makes blog posts like this (and the discussions they bring about) just as important to me as formal academic journal articles and conference presentations. It just wouldn’t feel right to not share this work openly with the communities of makers, thinkers, curators and users who are actually involved in it!

As you can probably tell from my e-tone, I’m massively excited to be getting started on fieldwork this autumn with the Tate and other institutions who are quickly becoming pioneers of digital participation by mixing spaces for making with cultural spaces. I will keep sharing work here as it evolves, and in the meantime I’ll be heading to Johannesburg for a few days to see whether there are similar-minded initiatives that merge culture with digital learning and making in their communities (have any ideas? Please let me know!), and I’ll also be talking about these ideas and others on a panel entitled “Who is the digital revolution for?” in Brighton at the end of this month for those who are in town. Summer may be winding down and the days of sun getting shorter, but it’s shaping up to be an exciting autumn - and I’m already looking forward to meeting, making and thinking these ideas over with many of you throughout it!

Share your expertise with Mozilla Clubs around the world!

Julia Vallera

Wed Sep 14 2016 13:21:51 GMT+0000 (UTC)

Club guides are an important part to the Mozilla Clubs program as they provide direction and assistance for specific challenges that clubs may face during day-to-day operation. We are looking for volunteers to help us author new guides and resources that will be shared globally. By learning more about the process and structure of our guides, we hope that you’ll collaborate on a Mozilla club guide soon!


In early 2015, Mozilla Clubs staff began publishing a series of guides that provide Club leaders with helpful tips and resources they need to maintain their Clubs. Soon after, community members began assisting with, collaborating on and authoring these guides alongside staff.

Guides are created in response to inquiries from Club Captains and Regional Coordinators around challenges they face within their clubs. Some challenges are common across Clubs and others are specific to one Club. In either case, the Mozilla Clubs team tries to create guides that assist in overcoming those challenges. Once a guide is published, it is listed as a resource on the Mozilla Clubs’ website.

Club guide created by Simeon Oriko, Carolina Tejada Alvarez, Kristina Gorr and the Mozilla Clubs team

Screenshot of a guide co-authored by Simeon Oriko, Carolina Tejada Alvarez, Kristina Gorr and the Mozilla Clubs team

How are club guides used around the world?

At Mozilla Clubs, there is a growing list of guides and resources that help Club participants maintain Club activity around the world. These guides are in multiple languages and cover topics related to teaching the web, sustaining communities, growing partnerships, fostering collaborations and more.

Guides should be used and adapted as needed. Club leaders are free to choose which guides they use and don’t use. The information included in each guide is drawn from experienced community leaders that are willing to share their expertise. Guides will continue to evolve and we welcome suggestions for how to improve them. The source code, template and content are free and available on Github.

Here are a few examples of how guides have been used:

  • A new Club Captain is wondering how to teach their Club learners about open practices so they read the “Teaching Web Literacy in the Open” guide for facilitation tips and activity ideas.
  • A librarian is interested in starting a Club in a library and uses the “Hosting a Mozilla Club in your Library” guide for tips and event ideas.
  • A Club wants to a make a website, so they use the “Creating a website” guide to learn how to secure a domain, choose a web host and use a free website builder.

What is the process for creating club guides?

The process for creating guides is evolving and sometimes varies on a case-by-case basis. In general, it goes something like this:

Step 1: Club leaders make suggestions for new guides on our discussion forum.

Step 2: Mozilla Club staff respond to the suggestion and share any existing resources.

Step 3: If there are no existing resources, the suggestion is added to a list of upcoming guides.

Step 4: Staff seek experts from the community to contribute or help author the guide (in some cases this could be the person who made the suggestion).

Step 5: Once we find an expert (internal to Mozilla or a volunteer from the community) who is interested in collaborating, the guide is drafted in as little or as much time as needed.

We currently have 50+ guides and resources available and look forward to seeing that number grow. If you have ideas for guides and/or would like to contribute to them, please let us know here.

Some tips for local Hacks/Hackers organizers

Erika Owens

Tue Sep 13 2016 04:10:38 GMT+0000 (UTC)

My favorite meetup! Dana and Sean facilitating Balloon Mapping Workshop (Photo: Todd Davenport)

Five years ago Dana Bauer and I started the Philadelphia chapter of Hacks/Hackers. She thought there would be interest in bringing together journalists, techies, and data lovers to share stories and learn from each other. She was right. There continues to be enthusiasm for figuring out how technology and journalism can help our community.

Over the past five years, I've also had the chance to work with other Hacks/Hackers chapters around the world, from Buenos Aires to Berlin. Some communities have more journalists, some have more techies; some have a ton of skeptics, while others have sell-out events. But there's a few tactics that seem to be helpful in every setting:

  • Have a co-organizer. It is essential to have at least one co-organizer, and possibly even a small committee. It helps share the work, think through ideas, and keeps you accountable. In addition, it's great to have co-organizers with connections to different communities. Dana was well-connected in the tech sector, whereas my connections were more in the journalism community.
  • Collaborate with other meetups. Make the organizing work even easier by co-hosting events with other organizations. It can help reach a new audience, cut down on the organizing logistics, and bring expertise to your community. Dana was also an organizer for Philly Python Users Group, which made it easy to organize. We mostly stuck to closely related groups like the local Code for America brigade, open data, and mapping groups.
  • Take advantage of other events. Nothing like a news hook for getting a meetup off the ground. A local event can be a great way to build excitement--Philly Tech Week is always a busy time here. A national event that happens to be in your town can be a great hook to either share work or just have a social event so people can welcome the out-of-towners. Also, those out-of-towners are potential speakers who may bring a new perspective or expertise to your group. Events elsewhere are also great fodder for a meetup--invite a couple folks who attended a conference to share what they learned.
  • Build on existing resources. There may already be journalism groups in your area that have a budget for trainings and would love to share more technical skills with their members. Organizations like OpenNews have supported journalism tech events around the world, and we're not the only ones. Dana organized a balloon mapping workshop with resources from the Public Lab, which included tools and planning support. You don't have to start the planning for every event from scratch.
  • Remember the people. Thinking about the details goes a long way to sustaining a healthy, active community. If you have food, make sure it's not literally pizza and beer, but has non-alcoholic and diet-inclusive options. Ensure that speakers are representative of your community. Consider different times and formats of meetups so people with different family and schedule needs can participate. And don't forget to invite people. Especially when starting a chapter, or rebooting, personal invitations are critically important. Meetup's automated emails are pretty convenient, but easily ignored. Reaching out to your friends, colleagues, and broader network will certainly increase attendance, plus it's just nice to get to hang out with your friends talking about cool stuff.

And as you think about the participants, also be kind to yourself. A lot of Hacks/Hackers chapters go through busy and quiet periods as the lives of the organizers change, or when organizers move away. That's ok. Momentum of regular events is really fantastic once you get into the swing of it, but if you suddenly look up and it's been 6 months since your last event, trust me. You're in good company.

If you're looking to get started or re-start a chapter. Go ahead and start slow. Maybe a social event. Or a reportback from a conference. Your community members will probably have ton of ideas after they see the chapter is moving, and hey, maybe one of them will even join in on the organizing fun. Best of luck!

Thanks to Paola Mosso for encouraging me to write this post. Thanks to Dana for being such a wonderful friend and collaborator.

And if you don't want to stop at a meetup, never fear, I also have a guide to organizing a whole journalism hackation.


Zephyr Berlin launching on Kickstarter

Michelle Thorne

Sat Sep 10 2016 20:24:26 GMT+0000 (UTC)

We’re making a pair of pants. The idea: look great and travel lightly with one pair of pants.

We’ve been testing the women’s and men’s styles for the last few months. It’s been loads of fun seeing it all come together, and we wanted to share that with you!

Our Kickstarter launches on September 14.


We are making two models of pants—one for women, one for men—that travel really well, are incredibly comfortable, and look great no matter where you go. The pants are ethically made and made to last.

We use sustainability-certified performance fabric that is water and dirt repellent, wrinkle-free and breathable. The pants are tailored in a classic European tradition in black that flatters many body types. They will be produced for fair wages in Berlin.

We’ve been obsessed with having pants like this, so we went ahead and made some!

Learn more at our website:

IMG_8240_cleaned up

IMG_9084_cleaned up copy


A pants party in Berlin

To celebrate, we’re hosting a launch party on Wednesday, September 14 at our studio in Berlin Neukölln.

There will be pants to try on, conversations about minimalist fashion, and a chance to throw water on the fabric and watch it fly off!

The money raised from the early supporter discounted Kickstarter pre-sales will fund the production of 100 pairs of pants. Secure your pair when our campaign goes live on September 14. By pre-ordering on the Kickstarter page, you are giving us invaluable support to continue pushing forward on this project.

Thank you!

We really appreciate your support. If you like to stay up to date, feel free to subscribe to our newsletter over at If you know someone else who might like a pair, feel free to pass this along!


Pop-Up Remix during #HipHopEd

Greg McVerry

Thu Sep 08 2016 00:05:11 GMT+0000 (UTC)

In a recent post on my backstage blog (I use it to describe process or half baked thoughts) I explained my excitement for #HipHopEd in order to gather some song lyrics. I am pop culture deficient yet carry some knowledge of early hip hop. I got there on a strange path long after the original tracks dropped..but that is another story.

I was excited for the chat just to archive cool crowdsourced lyrics. I would have the chance to grow a collection from people who recognize the literacy practices of all youth while recognizing that education is central to social movements.

 Gear Up

Our Gear Up students, are entering the eleventh grade–a crucial year for the college bound. This year I want to transition our text message outreach from parents (who will receive reminders and event updates) to students. We Use Remind. I will set up new classes for youth. I am thinking a motivational quote throwdown will be a fun activity.

Meme Making

Quotes make great memes and memes make great tools for learning basic HTML and CSS. In fact I shared a template I had remixed from Mozilla Learning. I hope to use these during #EDU106. o I decided to make on the fly. As I saw quotes I made a series of remixes for participants in the chat.

screenshot-2016-09-07-19-14-20 screenshot-2016-09-07-19-14-03 screenshot-2016-09-07-19-13-47

In each remix I used a creative commons image from Flickr. Using Alan Levine’s Flickr CC Attribution helper I was able to use a legally licensed image while providing some amazing artists credit. In the train picture I actually remixed two images. It isn’t much of a composition. I was constrained by time as I was trying to make a few memes while also participating in the chat.All I used was the eraser and the opacity tools…Still looks pretty cool. I may keep working on it.

I hope others in the #HipHopEd community takes up the call to #teachtheweb. Hip Hop has a long history of digital arts. We need to grow this legacy while getting mroe students of color to code. Do I believe every kid should code. No, but everyone should have the opportunity to explore their identities across the web while mastering skills that can open up opportunities that have been closed off for the first three decades of our online world.

With love from Barcelona: A year of PhD making, thinking + fun.

Kat Braybrooke

Fri Sep 02 2016 16:43:03 GMT+0000 (UTC)


A little while ago, I wrote my first public Medium post 6 months into my PhD at the University of Sussex, describing the experience of taking a crazy leap of faith, moving from Vancouver to London and leaving a full-time job in tech to do so. A whirlwind year later, I now find myself past my first doctoral upgrade as a somewhat official-feeling PhD candidate, many amazing conversations, eureka moments and unexpected travels(!) later. So, without further ado, here is my new piece on Medium about that first year. My hope is that posts like this will give others the extra encouragement they may need to take the plunge and dive into the research they’re passionate about. I know it helped me a great deal when I was considering my next move.

And in a word, it’s all been amazing. Highlights have included seeing Bruno Latour discuss his thoughts on gaia (and blow out a birthday cake!) after presenting my first-ever academic paper at this year’s Society for the History of Technology meeting in Singapore, where the always-inspiring Sally Jane Norman and I also organized a digital artifact workshop in this glorious psychedelic rainbow room at the city’s new ArtScience Museum, heading to Santa Cruz with Sussex Humanities Lab colleagues for this digital media exchange to play with Arduinos while meeting a group of talented art/tech practitioners there, and generally getting to hang out back in the UK with fascinating humans (and libraries!) in Brighton, Oxford and London while learning everything I could about theories of spatiality, making and community.

I’m writing this today from beautiful, sunny Barcelona, where I’ve been lucky enough to attend this year’s excellent 4S/EASST “Science and Technology By Other Means” conference on scholarship from EASST and the Sussex Digital Humanities Lab. In addition to being a discussant about “careers by other means” at its Doctoral Day, I also presented a paper I’ve submitted to Digital Culture & Society with Tim Jordan which critically examines key technomyths about the maker movement as part of an excellent panel convened by Adrian Smith, Maxigas and other great thinkers in this space entitled “Digital Fabrications Amongst Hackers, Makers and Manufacturers: Whose Industrial Revolution?”.

While presenting to a packed room of STS scholars was one of the more intimidating(!) moments of my academic career so far, the resulting discussion and ideas I received from such an engaged (and thoughtful!) audience made all the stress 100% worth it. I’m very grateful to everyone who came to listen and provide advice. Moments like these, where you get to share your research with the makers, hackers and thinkers who have helped inspire it the first place, are especially wonderful ones. Here’s to more beautiful memories in the sun (and studio) for all of us!