about:community

If you’ve been wondering why you haven’t received the best in Mozilla’s community news in some weeks, it’s because we’ve been busy redesigning our newsletter in order to bring you even more great content.

Non-profit marketing is no easy feat. Even with our team of experts here at Mozilla, we don’t always hit the bar when it comes to open rates, click through rates, and other metrics that measure marketing success. For our community newsletter, I watched our metrics steadily decrease over the six month period since we re-launched the newsletter and started publishing on a regular basis.

It was definitely time for a makeover.

Our community newsletter is a study in pathways and retention: How do we help people who have already expressed interest in contributing get involved and stay involved? What are some easy ways for people to join our community? How can communities come together to write inspiring content for the Web?

At Mozilla, we put out three main newsletters: Firefox and You (currently on a brief hiatus), the Firefox Student Ambassadors newsletter, and our Mozilla Communities Newsletter (formerly called about:Mozilla)

It was important to me to have the newsletter feel authentically like the voice of the community, to help people find their Mozillian way, and to point people in the direction of others who share their interests, opening up participation to a wider audience.

A peer assist with Andrea Wood and Kelli Klein at the Mozilla Foundation helped me articulate what we needed and stay on-target with the newsletter’s goal to “provide the best in contribution opportunities at Mozilla.” Andrea demonstrated to me how the current newsletter was structured for consumption, not action, and directed me toward new features that would engage people with the newsletter’s content and eventually help them join us.

I also took a class with Aspiration Tech on how to write emails that captivate as well as read a lot about non-profit email marketing. While some of it seemed obvious, my research also gave me an overview of the field, which allowed me to redesign the newsletter according to best practices.

Here’s what I learned:

1. According to M & R, who publishes the best (and most hilarious) study of non-profit email campaigns, our metrics were right on track with industry averages. Non-profit marketing emails have a mean open rate of 13% with a 2.5% deviance in either direction. This means that at between 25% and 15% open rate we were actually doing better than other non-profit emails. What worried me was that our open rate rapidly and steadily decreased, signalling a disengagement with the content.

I came up with similar findings for our click through rates– on par with the industry, but steadily decreasing. (From almost 5% on our first newsletter to less than 1.5% on our last, eek!)

2. While I thought that our 70,000 subscribers put us safely in the “large email list” category, I learned that we are actually a small/medium newsletter according to industry averages! In terms of how we gain subscribers, I’m hoping that an increased social media presence as well as experiments with viral marketing (IE “forward this to a friend!”) will bring in new voices and new people to engage with our community.

3. “The Five Second Rule” is perhaps the best rule I learned about email marketing. Have you captured the reader in three seconds? Can you open an email and know what it’s trying to ask you in five seconds? If not, you should redesign.

4. Stories that asked people to take action were always the most clicked on stories in our last iteration. This is unsurprising, but “learn more” and “read more” don’t seem to move our readers. “Sign this petition” and “Sign up” were always well-received.

5. There is no statistically “best time” to send an email newsletter. The best time to send an email newsletter is “when it’s ready.” While every two weeks is a good goal for the newsletter, sending it slightly less frequently will not take away from its impact.

6. As M & R writes, “For everything, (churn churn churn) there is a season (churn, churn, churn)…” our churn rate on the newsletter was pretty high (we lost and gained subscribers at a high rate.) I’m hoping that our new regular features about teaching and learning as well as privacy will highlight what’s great about our community and how to take action.

And now to the redesign!

The first thing you’ll notice is that our newsletter is now called “Mozilla Communities.” We voted on the new name a few weeks ago after the Grow Mozilla call. Thanks to everyone who gave feedback.

An overview of the newsletter’s new look.

While the overall feel remains the same and is in line with other Mozilla-branded newsletters, the new look incorporates a few “evergreen” opportunities and actions you can take before the fold as well as features a contributor in their own words. (For the draft of the new design, that contributor is me!) The easy actions on the left hand side will rotate out as needed and increase in commitment level as you read down the page. Also, take a look at the awesome logo!

The next section presents rotating features on our privacy and educational initiatives. Privacy and education span a variety of functional areas, so this section could be populated by a variety of community endeavors. At the bottom of these sections, there’s a Facebook post and Tweet that you can post to easily take action, promote our communities, and get social to protect the Internet.

The next section features a story that engages the reader to take action! (In this case it invites readers into our awesome new gear store…) This story about Mozilla communities will rotate out according to the content that you submit. It will also be action-oriented, easy, and fun.

This last story is optional and will be rotated in and out according to testing during the first few issues. (Early feedback feared that there were too many stories.) In the draft design, we’re announcing a new contribution area. This will be a place for new community contribution areas, pathways, and opportunities to connect. The new photo section, “Mozillian Moments,” replaces our “Photo of the Week” section from the last iteration.

Finally, the footer reminds the reader that this newsletter is community-created and community-supported. It also invites readers to join us on social media. In the upcoming issues, the newsletter will also link to the new “Guides” forum that will help contributors find mentorship opportunities and connect with their fellow Mozillians.

What we need from you:

1. We need writers, coders, social media gurus, copy editors, and designers who are interested in consistently testing and improving the newsletter. The opportunity newsletter is a new contribution area on the October 15th relaunch of the Get Involved page (under the “Writing –> Journalism” drop down choice) and I’m hoping that will engage new contributors as well.

2. A newsletter can’t run without content, and we experimented with lots of ways to collect that content in the last few months. Do you have content for the newsletter? Do you want to be a featured contributor? Reach out to mozilla-communities at mozilla dot com.

3. Feedback requested! I put together an Etherpad that asks specific questions about improving the design. Please put your feedback here or leave it in the comments.

The newsletter is a place for us to showcase our work and connect with each other. We can only continue improving, incorporating best practices, and connecting more deeply and authentically through our platforms. Thank you to everyone who helped in the Mozilla Communities redesign and to all of you who support Mozilla communities every day.

Firefox And The Academy

Sep 29 2014

mhoye

It’s September, so a lot of students are joining us in various Mozilla forums, hoping to make a contribution to an open source project. This is always a challenging time of year for Mozilla, and I’d like to say a few things about it. If you’re a student hoping to get involved or – even better – an educator who would like to involve their classes in open source projects or contribute specifically to Mozilla, I hope this will give you a sense of some of the challenges and pitfalls you may be facing and how we can work together to overcome them.

If you’re a veteran of Usenet from the days when Trumpet Winsock was a thing and dinosaurs roamed the earth, you recognize the particular flavor of Mozilla’s comms channels at this time of year. People who want to make a difference in the world want be a part of Mozilla and we’re always excited to hear from them, but September is a challenging time; we get a lot of requests for “student projects” and “easy bugs” that can be difficult to address, and the dropout rate from new participants grabbing “easy” [good first bug]s at this time of year is frustratingly high.

Part of these challenges are structural, of course, and some of those structures are out of our control – courses that are designed around software and development as a discrete, compartmentalizable thing, rather than a messy, rapidly evolving and organic process aren’t really compatible with the day to day process of shipping software. Likewise the benchmarks that make up a traditional academic evaluation process don’t really make sense in our context, so more often than not the goals and schedules of students and educators aren’t well-aligned with ours.

We’re grateful for any effort put in, large or small, to making Firefox better and supporting a free and open Web. Having said that: there are a few things that make working with Firefox in an academic context challenging and you should be aware of them.

The biggest one is that we can’t promise to accept a patch within a certain time frame. This can become a problem for both students and professors when getting the patch accepted into the main product is part of the criteria for a good grade in the course.

This has happened in the past: a student has done great work on a harder-than-expected bug, but it didn’t make it through our process – including testing, feedback, revision and more testing – by the time grades were assigned. Despite their effort, the student was undeservedly graded poorly.

This is bad for everyone when it happens – the student and professor both get discouraged, the value of their work (and of the course) gets harder to see, and if the student doesn’t stick with the patch long enough to carry it over the line, despite all that, Firefox doesn’t benefit and Mozilla’s engineers feel like they’ve wasted their time.

If you’re involved in shaping your curriculum, a better approach is to combine fixing the bug or delivering the project with a set of reports or presentations about the process. This presentation – maybe even a blog post, because working in the open is important – can be a discussion of what the student is working on and why it’s important, how the work progressed and what the process of getting a patch in looks like, as well as the challenges they’ve faced and what they’ve learned from it.

Making three or four “this is my experience and what I’ve learned so far” reports over the term a more important part of the grading process than the code itself helps enormously, both in terms of keeping everyone involved motivated and in reflecting the open, community-oriented values of the project. There are other options for instructors who are familiar with our processes – breaking up the grade up so that submitting a patch that builds, responding to the first review and so on all count, even if the patch isn’t ultimately accepted, is one possibility.

The second major challenge is finding bugs that are a good fit for their contributors. We’re getting better at that – good first bugs usually tell you what language they rely on ( [lang=c++] in the Bugzilla whiteboard flags, for example) and often have a pretty good outline of what a successful patch would look like and a mentor associated with them. And while we can’t promise to privilege students ahead of any other contributors, we certainly try to hold up our end of the bargain and answer new contributors’ questions promptly.

One thing that takes the edge off there is that class of bug – “good first bugs”, you can search for [good first bug] in the Bugzilla whiteboard – that are a nice, well-defined way to get involved. The idea behind “good first bugs” is that the major challenge of the bug isn’t the code itself, but learning how to get your development environment spun up, participating in development on IRC and Bugzilla, learning how to navigate our patch review and submission process.

It typically takes a few tries for most new contributors to get their patch through. Reviews for code format and quality, suitable tests, that sort of thing can all take an extra week or two to resolve, especially if you’re working on them around other classes. But most of our good first bugs can be resolved within a few weeks, well within a term.

You’ll have to judge for yourself if this is a good fit for your schedule, your students or your institutional goals. On the one hand, though GFBs are generally well-contained, Firefox uses every feature JS and C++ have to offer, so a certain amount of familiarity and comfort with the language is important. On the other, we’ve got a huge variety of Good First Bugs here, ranging from “correct this documentation” to “fix part of a JIT compiler”, so it’s likely that if you want to contribute, we can find a home for your efforts that will make millions of people’s lives just a little bit better.

More generally, if you’re interested in getting people involved with Mozilla in September, get in touch with us in June. Knowing in advance that people will be looking for new bugs or projects gives us time to talk to our team leads and project managers, to let us all find a place to put our efforts that will be helpful and valuable to everyone.

Which is all to say that small first-time bugs are often as inglorious as they are important; while they don’t seem like much, the small patches and first bugs of today come from the Web’s next generation of leaders.

Thank you,

– Mike Hoye – mhoye@mozilla.com

Mozilla CBT Build Principles

Sep 18 2014

Sean Bolton

Making implicit information explicit allows us to grow. We are able to recognize and add to something that works well, while focusing less on what doesn’t work well. Being explicit allows us to talk about something we do and/or experience – it allows this information to be shared and understood by others. When we focus on value and impact, we must be explicit in order to understand what is happening.

During my work on the Community Building Team (CBT) at Mozilla, I have been exposed to several themes of how the team works when success happens. Intrinsically, these are the agreed upon ways by which we do our work. Extrinsically, these are the principles by which we do our work.

I cannot claim to be the single voice for these principles on our team – that would be not Mozilla-like. However, these are things I have been exposed to by working with and reading about the work of all members of the team.

Build Understanding – Demonstrate competence. Seek first to understand. Every engagement is different. We care about people and doing the right thing for them. In order to best help them, we are curious.
Build Connections – Be a catalyst for connection. Our team has a broad reach in the organizations. Sometimes the best way we can build is by connecting what is already there.
Build Clarity – This is important when bringing more people into a project. We seek to navigate through the confusion to create clarity for us, our partners and the community.
Build Trust – This is about having someone’s back. It’s important that the people we work with know that we are in this with them, together.
Build Pilots – Our work is not a one size fits all. We care about the best solution so we test our assumptions to see what works and build from there.
Build Win-Win – Focus on mutual benefit. We engage in win-win partnerships because our success is dependent on others. More people can only sustainably come into a project when it’s mutually beneficial. We want to make our partners look good.

Having these principles allows others people and teams to understand how the CBT works and what things are a valued when doing that work. It allows allow members of the team to have a toolkit to reference when entering into a new engagement and builds a level of consistency about interaction – creating clear expectations for others. All this leads to the sustainable success of the CBT.

I’ve places these into a nice PDF format below.

[Post also appeared on Sean Bolton’s blog.]

Exploring Contributor Motivation

Sep 15 2014

Sean Bolton

Why does understanding motivation for open source matter? This allows community builders to design more fulfilling experiences for contributors. It allows a contributor to be recognized in way he or she prefers. It allows community builders to advocate for projects that would be exciting to contributors.

The challenge of studying motivation (and thus recognition) is that our internal biases are strong. I can easily assume that the things I am motivated by are what others are motivated by and the ways I want to be recognized are the ways others want to be recognized. These ideas are deeply engrained – it is our internal motivation mechanism after all.

To find some objectivity in this area, I took from academic writing and did my own user research. The results are were synthesized from Organizing for Open Innovation by Wallin (2010) and countless contributor interviews and interactions I’ve had during my exposure to Mozilla. Some of these interviews were done during Summit 2013 and my Europe trip in early 2014.

Six main areas arose (in no particular order):

Intrinsic – This is an internal motivator focused on personal growth and self-actualization. Here people contribute because it is fun for its own sake and because they grow personally from it.
Extrinsic – This is an external motivator focused on material recognition such as a badge that a person can point to as a representation and/or certification of their contribution.
Community – This motivator is based on our human need to feel part of a larger group that shares our view of the world – having a sense of belonging. (See Why Do People Join and Stay Part Of a Community for a deeper exploration here.)
Preemptive Generosity – This motivator is about giving something before it is asked for. It could be anything and it’s tied to our feelings of reciprocity. In a broad perspective, open source itself often follows this rule by releasing code before others know to ask for it.
Social Value – Motivation here is about feeling as if your contributions create a better world. There needs to be a clear and strong sense of impact. As Jimmy Wales once put it, “Usually, when people have an eight-hour binge of editing Wikipedia they think, well, I made the world a little bit better place than it was when I started.”
Helpfulness – This motivator is based purely on the desire to help others and give back. This is less about changing the world per se and more about having an impact in a person’s life. Similar but different.

When we can be explicit around these motivators, we can design contributor experiences that support them. That creates a more fulfilling experience for contributors and allows a project to grow while remaining meaningful.

Below is a PDF I put together to explore these motivators as they relate to Mozilla (it’s certainly incomplete). However, these should be relevant in all community driven projects and be non-unique to Mozilla.

[Post also appeared on Sean Bolton’s blog.]

July 1st about:Mozilla Issue: Protect Net Neutrality, Safe Browsing for Domestic Violence Survivors, and more…

Sep 5 2014

jhalperin

In this issue, you’ll find out how to raise your voice in support of net neutrality, read about exciting new contribution opportunities, and learn about a new way to map your career path.

Thanks for advocating for the free Web!

— The about:Mozilla Team Continue reading …

Nourish your community, nourish yourself.

Sep 4 2014

mmarovich

Food is vitally important to nourish the body you live in. Recognition is how we help feed our communities and nourish them as they make us strong. Recognition, like food, is for everyone to partake in, and to share.

The tools, processes, and systems we use to identify people making contributions in our project vary widely. It’s a situation created by valuing freedom of systems over efficiency of systems, and that isn’t something that Mozillians are willing to give up. It makes it very hard to know who to give access and recognition to. The Community Building team is working long term on this problem. I’m here to ask you to nourish your community members, on an ongoing basis, by using vouching as a quick and easy way to give meaningful recognition.

The Community Tools team implemented Mozillians.org as a first step in allowing people to self identify as supporters or contributors to the Mozilla project. The vouching system is one of the major ways we identify people who make actual contributions to the project. Read more about that here.

Being a vouched Mozillian means something. It means you can be invited to large events like our Summit . It means you can get access to internal calls . It means you are visible to the project, as a Mozillian helping us move forward. It means we trust you. Let’s make our words reflect that trust.

Since the vouching change was implemented we’ve seen some vouches like:

“ Karl has been around a long time.”

“Cindy makes things.”

We can do better than that. That is like skipping breakfast. You get through it, but nothing nourishing happens.

For example, compare the vouches above, to this:

“Lindsey worked nights and weekends to help the Release Engineering team finish the release on time – it went out on time with much higher quality thanks to her extra effort!”

Ask yourself:

Which one will make Lindsey feel valued?
Which one demonstrates the higher level of trust and access that being a vouched Mozillian gives her?

If you want to know more: go to the Vouching page on the wiki to see some additional examples.

We should all see vouching as a form of recognition. Use it to tell people what they did was meaningful. Help them understand that the additional access and trust we are giving them comes from the impact of their contribution. Encourage them to keep contributing by saying thank you.

If that isn’t enough for you, do it because it helps us build the OSS community we need… a community where contribution is valued, regularly, in public.

So here is the request:

1) Create a Mozillians account if you don’t have one. Talk to three people you know and trust in your regional community– ask them to vouch for your work. You need to be vouched three times before you can vouch for others.

2) If you have an account and three vouches, go vouch for others. Yes, you, even you. This is a change that our unpaid contributors should drive. You know your regions, your groups, and your people best. Take the leadership to recognize them for the impact they are making in their areas. Take the time to make that mean something in our context.

3) Come back here, and share your story in the comments.

How did it feel to vouch?
How did it feel to receive a vouch that shared your impact, thanked you, or celebrated your contributions?

And always, keep being awesome!

Mozilla Voices has a new name!

Sep 4 2014

Anthony Duignan-Cabrera

Hey gang, Anthony Duignan-Cabrera here, Editor in Chief of what was originally known as Mozilla Voices.

It was felt that the initiative needed a new name, one that made it clear to the audience that this online news and content platform wasn’t ABOUT Mozilla, but about our mission and support of open systems and a free and healthy Internet.

We opened it up to the community and we received dozens of great ideas, some generating wonderful conversations.

But there was one that just jumped out and caused us to pause and take note: The Open Standard

It completely captured the spirit of what we want to accomplish. Not just as a play on words, but one steeped in both the great journalism traditions and Mozilla’s overall mission.

The name was suggested by Justin Crawford, Product Manager for Developer Relations, and when I asked what inspired him, he sent me the most wonderful explanation:

“I love old newspaper names, the ones that use bold words to try and explain what a newspaper is about. It’s a “Monitor” or a “Camera” or it is the “Times” or an “Inquirer” or it is the “Globe”. Those are aspirational names: They say, “A newspaper is not just school board minutes, it’s not about ads. A newspaper is a camera on the times, monitoring the globe, inquiring after facts.”

My dad (Rocky Mountain News circa 1968-1981) has a belt with the word “Newsman” swooping across it like the word “Superman” in old comic books. Maybe the news business isn’t what it was in the 20th century, but at its best, the news did and does live up to its bold self-image. It holds us all to higher standards than our natures might otherwise cleave to. This is what I also admired about Mozilla when I decided to join: We make standards, and we make products that embody standards, and we do it in the open. We do what we do for the sake of standards.

“The Open Standard” is a cute play on words (“Standard” is an old newspaper name, and “open standards” are … well, you know), and that’s what initially brought it to mind. But this name is more than cute. The Open Standard will be a beacon, a tribune. It will rally and inform. In its finest hour it will live up to its name.”

I couldn’t have said it better. Thank you, Justin.

ADC