groups now have curators and other goodnesss

On, Mozilla’s community directory, there are hundreds of self-organized groups of people based on a variety of interests. The Community Tools team has released some big improvements for how you can create, manage and view groups in order to provide more value in connecting with fellow Mozillians.

Create a curated group

Create a group described with several fields

New ways to curate groups

Starting today, all new groups will have a curator, which is the person who created the group. The curator has the ability to set the general information of the group, manage some settings and moderate the membership of the group.

The general information on curated groups now includes the fields that have been shown on functional area groups for a while. These fields include a description, IRC channel, website, and wiki page. The group curator can also decide if the group is accepting new members by default or only by request.

Group curators can manage the group's settings and members

Group curators can manage the group’s settings and members

In the past, users created groups simply by typing words into a field on their profiles. Now, users create groups from the groups page.

If a group is set to accept new members by request, users can request to join the group and the curator will be able to manage those requests from the group’s page. Also, daily email notifications will be sent out to let the curator know when there are membership requests. Curators are able to filter group members to quickly see who is in the group and who has requested membership.

All the groups previously created still exist, and users can join and leave those groups freely.

Give it a try

I’m excited to see how Mozillians will use the new functionality for groups. You can create a new group from the [Browse Groups] page. Please file bugs for issues and enhancement ideas. If you have questions or feedback, please post on our discussion forum or stop by #commtools on IRC.

How evolved in 2013

Mozilla’s community directory,, saw a lot of changes in 2013. Here are some of the highlights.

New features and code improvements

Development work

Quality Assurance growth

  • During the course of the redesign, the community organized 3 large test initiatives to test new features and design concepts
  • 40+ community contributors, 25 repeatedly were involved in multiple test days and acted as mentors and stewards to the project
  • Mozillians was a nice gateway onto other Mozilla web projects. Often times this was the first project community members decided to get involved with before branching off onto other projects.

Some website metrics

  • 4,809 vouched profiles
  • 1,532 public profiles (32%)
  • 7,369 unvouched profiles
  • 443,052 pageviews
  • 98,527 visits

Looking back

In 2013 evolved from being a useful directory tool to becoming an important platform for all Mozillians. The site underwent a big redesign with improved UX. Apps like Air Mozilla and the Summit app relied on the Mozillians API for people information. New profile fields and privacy controls led to 1,500 Mozillians sharing more information and making their profiles public.

As a team we focused on ways to make a large impact quickly and also set ourselves up for our ambitious community building plans to grow to 1 Million Mozillians. We invested in building new features, paying technical debt, shipping quality releases, mentoring new contributors and improving documentation. The redesign invigorated people to get involved, and over 60 people volunteered by making contributions during the year. That’s a huge change compared to a year ago when there was less momentum and just a few people involved with making better. Now the project and community surrounding it feel vibrant and alive.

What was your favorite change or contribution to in 2013?

Looking forward has the potential to be an even more valuable tool for the Mozilla community. In 2014 we’ll be exploring ways to show contributions on profiles, display badges that demonstrate skills and achievements, provide better location information, make the API even more useful and improve authorization. How can be more useful for your needs?

Thanks to the splendid team, contributors and all Mozillians for an awesome 2013!

How the Mozilla Reps Portal grew in 2013

The Reps Portal, a platform used by our 400 Mozilla Reps to organize and measure activities, continued to be a critical piece to the success of the program in 2013. Here are some of the highlights.

New features and code improvements

Development work

  • 9 contributors and 15 mentored bugs
  • Closed 259 bugs
  • 19 releases with new features, improvements and fixes

Some metrics

  • 74,851 visits
  • 227,909 pageviews
  • 1,145 events organized
  • 401 Reps
  • 49 Mentors
  • 9 Council members

Looking back

We focused 2013 on preparing the Reps Portal to scale in impact. We built two key features (voting and continuous reporting) to that helped us streamline a slow process and better measure activities. The project made progress towards continuous delivery, which will speed up our development cycles in the future. Technical debt was repaid by upgrading frameworks and libraries and also by refactoring a huge number of tests. We spent a lot of time mentoring people contributing code to the portal. Much planning was also done during our UX Sessions in August, the Remo Camp in September and recent work with the Council to set 2014 development priorities.

Looking forward

The Reps Portal is in a position to become more valuable to Reps and all Mozillians in 2014. More people are contributing to the project, our development cycle is getting faster and we have clear priorities. Technical debt has reduced substantially, and we know where we can continue to improve on the technical side.

The Summit app

Two months ago, about 1800 Mozillians met up in three cities for the Summit. In the weeks leading up to the big event, a small group of Mozillians created a web app to help people navigate their way around the event and also interact in some fun ways.

The mobile experience at the Summit

The mobile experience at the Summit – photo by Viking Karwur

The app was created by a team of designers, engineers, and product folks: Harald Kirschner, Jen Fong-Adwent, Bill Walker, Lee Tom, Andrei Hajdukewycz, Giorgos Logiotatidis, Matt Brandt, Justin Crawford, Barry Munsterteiger, and myself.

The app was heavily used at the Summit – over 1700 Mozillians visited the app an average of 10 times each (20,000 visits total).

So, what does the app do? The app has four views

  • Schedule: a daily list of events
  • Random tips and bits: general information for participating and getting around the event.
  • Healthy Dialog: a breakfast conversation activity where each day Mozillians are matched into groups, which are identified by icons and colors.
  • 3 Questions: a response form asking about your current mood, anything you want to share with your fellow Mozillians and input box for recording who has had a positive impact on you.

Designing the app

We worked with the Summit planning team to learn how an app could best support the Summit. It quickly became clear that having a dynamic schedule was going to be the critical feature. Since session information was going to be added and changed up until the event, we needed any easy way for a dozen organizers to be able to update the schedule and have those changes shown to participants quickly. We used a Google Spreadsheet for the schedule content, and then the server and app pulled information from that spreadsheet every few minutes.

To help the Summit experience team, we also wanted to get a sense of how people were feeling and reacting to the Summit sessions. The 3 Questions form gave us a lightweight way to do that, by asking people to respond at least once a day. We also planned a big surprise based on how people answered the third question, “Who have you recently met that had a positive impact on you?”

Why we built an app

While we initially looked at some white-label event apps, we chose to create our own so that we could integrate it with our own technologies (Persona, API) and provide the Healthy Dialog and 3 Questions activities. Ultimately, the app was a great way for us to dogfood and improve our own services.



The Summit app gave us the ability to quickly update the schedule for all three cities and get the latest schedule to participants in minutes. We also used the responses from the 3 Questions form to give a prize to the Mozilla volunteer in each Summit city who had the biggest positive impact.

At the closing ceremony, the Fox presented an award to those three people. The award is a trip to any Mozilla Space in the world for a few days, to visit and meet our community there. Congratulations to Cliff Argwings, Vuyisile Ndlovu, and Irvin Chen for making the greatest impact on us (we can’t wait to hear about your trips!).

Cliff receives his award from The Fox in Brussels

Cliff receives his award from The Fox in Brussels – photo by Doug Belshaw

Hack on it

Check out the source code on Github and play with it. A forked version of the app was used at the Mozilla Festival, and there is potential to use this at other Mozilla events or any event you are organizing.

Give feedback

Did you find the Summit app valuable? What worked well? What you improve for next time?

Add your name to the monument to Mozillians in San Francisco!

[This is a re-post of a post that originally appeared on the Mozilla about:community blog]

Mozillians, imagine an awesome, fun, concrete way to show the world the thousands of people who contribute to Mozilla. The more the better! Your name can be added to a Mozilla monument, and we need your help to get the names of other Mozillians added too. That’s right, it’s true. We’re working to construct a 14 foot (4.26 meters) structure that will sit outside of our new San Fransisco space (check out the concept photos). Onto this monument, oh yes, we will attempt to include the names of every Mozillian.

Wide view of the Mozilla monument

Action Required: If you are a current or past contributor and would like to be a permanent part of Firefox, your name etched, literally, on the structure, you need to tell us by October 31. To do that:

If you have a vouched profile, sign-in and click the ‘Join Group’ button on the SF Monument group page. Joining that group means you would like your name, as it appears on your profile1, to appear on our public art installation.

If you don’t have a vouched profile or are unable to access it, fill out this form and we will help you get added to the monument.

And while you are adding your name for the monument, we also encourage you to add your name to about:credits. It’s a great way to show the world you have contributed to Mozilla, and the easy directions can be found at the bottom of the about:credits page.

We will include the names of contributors listed in about:credits, though you can opt-out by October 31. Just fill out the form below.

Spread the word to Mozillians: We know there are many Mozillians, past and present, who will not see this post on their own. Please share this post with those people. We ask that contributors who do not have a vouched profile fill out this form and we will help them get added.

Barry Munsterteiger and William Reynolds

IRC #mozillians

1 We are using the Open Sans font to print the names on the monument, so there are limits to which characters can be printed. Take a look at the characters available, and if your profile name is not printable in Open Sans, please email the characters you would like printed for your name to

Detailed view of the monument and side panel profiles are now even more awesome

[This is a re-post of a post that originally appeared on the Mozilla about:community blog]

We have added some new profile fields on, our community directory, to answer common questions Mozillians often have for each other. Take 2 minutes to update your profile and add your timezone, other accounts, when you got involved with Mozilla, what you do for Mozilla and your t-shirt size. Plus, make sure you have a nice profile photo showing your face, which is especially helpful for finding Mozillians at events like the Summit.

You can edit your profile to add more information

You can edit your profile to add more information

The new profile fields make it easier to see how people contribute for Mozilla, add external accounts to collaborate with Mozillians and share your t-shirt with people who make t-shirts. With these new fields we have added a privileged privacy level and multi-value fields. Here’s are the new fields you can add:

  • Timezone
  • Accounts on other websites (like Bugzilla and Github)
  • When did you get involved with Mozilla?
  • T-Shirt Size

T-shirts and privileged information

When you set your t-shirt size, your size will only be visible to a few people thanks to our new ‘privileged’ visibility level. Only those who need sizes for ordering t-shirts and admins will be able to view your t-shirt size. I’m especially excited about this field, since we will no longer need to ask Mozillians for their t-shirt size, and those who make t-shirts for Mozillians will have accurate sizing information.

T-shirts! You can add your size to your profile and it is only visible to a few trusted t-shirt people

T-shirts! You can add your size to your profile and it is only visible to a few trusted t-shirt people

Multi-value fields for accounts

We have added accounts for other sites and services that Mozillians often use. We created multi-value fields for the accounts section, so you can add multiple accounts for each service. For example, if you have two Twitter usernames, you can add both of them.

Give it a try

That’s a lot of new goodness for profiles. Be sure to edit your profile to include this information – it only takes a moment. If you see any issues with these site, file a bug and we’ll look into it. profiles are now filled with more useful information profiles are now filled with more useful information

Recap of Events UX sessions for

The other week the Mozilla Reps website team met to improve the user experience for interacting with events on the website. Holly Habstritt Gaal from the Mozilla UX team guided us through the process in a series of four sessions, and this post shares a high-level view of what we created.

Discussing new UX concepts

Discussing new UX concepts

Our sessions took us through the user experience design process we adapted from Design Staff, and each session covered one stage — Understand, Diverge, Decide, and Prioritize. The group included people who work on back-end development, front-end development, quality assurance, visual design, product management, web product management and program management.

We started the first session by considering our goals, success metrics and user types. We then reviewed website analytics, research and user feedback to give us additional information. Based on that context we were able to create a problem statement:

We are not making events easy to organize, discover, or measure. We will design a better experience for the core needs of Reps and Mozillians, such as gaining new contributors and supporting Mozilla initiatives.

In our second session, we identified six types of tasks for improving events:

  • Organize. Make it easy for Mozilla Reps to create and manage events.
  • Discover. Make it easy for people to find relevant events.
  • Measure and validate. Demonstrate the impact of events and how those events further Mozilla initiatives.
  • Integrate. Improve information flow with internal/external services.
  • Promote. Add ways for users to share events.
  • Call to action. Add new calls to action (CTAs) for users.

With these tasks in mind, we individually sketched ideas using markers and paper to brainstorm solutions to these tasks. We held another round of sketching to refine the ideas, and then we shared our concepts with the group and discussed them to raise concerns, assumptions and alternative solutions.

Sharing a sketch

Sharing a sketch

Our last two sessions helped us solidify our ideas and decide how we would prioritize them. For our third session we reviewed our seven concepts in more detail and talked through user stories for them. In our last session we prioritized these tasks amongst each other and also talked about how we want to sequence them as part of our work during the rest of this year (Q3 and Q4).

As we wrapped up our sessions on day two, we had a clear understanding of what we want to accomplish and the priorities for implementing those concepts. We will now create specifications for those ideas, prioritize them amongst our other non-events projects and identify any other resources we need. In a short amount of time, we certainly accomplished a lot!

A framework for designing a better user experience

The Mozilla Reps website team recently met to plan how to make our event tools easier and more valuable. We are a bootstrapping team, so this is the first time that we have worked closely with user experience and visual design experts Holly and Lee. This opportunity was a special treat for our team, and I think it also gives us a strong framework for improving the user experience in other areas of the Reps Portal. I am going to use this post to share the process we used, and I believe other teams can benefit from using this approach as well.

Defining our process

To guide us through our sprint, we adapted the product design sprint five-day recipe from the good people at Design Staff. We changed the recipe a bit since we were meeting remotely and not creating a prototype just yet. Overall the team really liked this approach.


To help us prepare for the meetings, Holly shared guide documents detailing the sessions and included questions for us to think about in advance. We also created a quick survey for Mozilla Reps, our main users, to give us feedback and ideas about event functionality on the Reps Portal. The responses we received gave us some great insights that drove our discussion and concepts. Before the meetings each of us was asked to look at other event sites for inspiration as well.


We met for four two-hour sessions on Monday and Tuesday, and each session was focused on a different stage of the user experience design process. During these meetings we discussed, brainstormed, sketched, conceptualized and identified assumptions and concerns. We started by defining our opportunity and finished by prioritizing our new concepts and solutions. This is a thorough process that helps the team gain a common understanding of what we want to accomplish and then find solutions we can use. Here’s what we set out to do in each session:

  • Understand. Dig into the design problem through research, competitive review, and strategy exercises. End up with user story that we all agree on to move forward.
  • Diverge. Rapidly develop as many solutions as possible.
  • Decide. Choose the best ideas and hammer out our user stories.
  • Prioritize. Choose what order to work on ideas.

Working virtually

Our team is spread out around the world, so we used Vidyo video conferencing to meet in a virtual room and we created a shared folder of documents and images for each step in the process. Because our team spans eight timezones, not everyone could join every session, but at the start of each session we reviewed our previous work so everyone had the same context.

Sharing our ideas over video

Sharing our ideas over video

To share our designs and ideas, we made heavy use of screen sharing and showing paper sketches using webcams. While we took lots of notes, I found the paper sketches to be the most useful tool for our sessions. In a few minutes we could draw out ideas and share concepts with each other. We also took photos of all the sketches that we added to our shared documents folder.

Next steps

Now that we have a solid understanding of how we want to improve our event tools, we can start executing on our concepts. In the next week we will start creating specifications and filing bugs. We’ll prioritize our events work amongst our other Reps Portal projects as well.

State of the Reps Portal

There are lots of exciting things happening with the Mozilla Reps website, and I want to give an update on where things stand and share what’s coming next. continues to be a key way for Mozilla Reps to organize and report their activities continues to be a key way for Mozilla Reps to organize and report their activities

The Reps Portal gets about 250 visitors each day, which is pretty impressive considering there are just under 400 Reps. The average person visits the site for 4 minutes 18 seconds. Amazingly, Reps are organizing and participating in over 1,000 events each year. Reps are organizing more events than any other group in Mozilla.

The core functionality of the Reps Portal is composed of profiles, events, monthly reports and a dashboard. Most recently, we have released a voting feature so Reps can vote and comment on polls, which help different groups and the program as a whole make decisions. We’re also planning to use the voting feature to approve swag and budget requests for events.

Some of the most useful tools are highly specific. Here are two powerful features that you may not have noticed yet:

  • You can automatically add events that interest you to your calendar. On the events page, search for a location or any keyword, click the Advanced Options icon, and choose Export iCalendar. This will add a feed of those events to your personal calendar.
  • You can send an email to Mozillians attending an event. On an event page, simply click on Mail attendees.

Even with a great site, there is plenty more we can do. We are working to improve how you interact with events on the site, switch to a better reporting system, and show more insights and actionable items on your dashboard.

The team working on the Reps Portal continues to grow, and we have 14 people contributing to the site. Take a look at our team page to get to know everyone, and stop by #remo-dev on IRC or post on our discussion forum. We are a fun group!

Preparing for continuous delivery

The Mozilla Reps web development team is starting to move toward continuous delivery so that we can deliver features faster while maintaining or increasing the quality of code deployed to

Continuous deployment is the holy grail of application development. It reduces bottlenecks between stages of the development process, allowing the team to move faster and be pretty confident in the quality of the code. Once in place, it can also reduce the work to test and release new functionality. We think it’s a win for everyone.

It also means pushing every code change to a production environment (that’s the deployment part). Our team is interested in a variation of this called continuous delivery, which means that we have the ability to push to production at any time. This will give us more flexibility, since we’ll be able to separately make code changes and update the site when it is most convenient for the team.

What do we need to build to move to continuous delivery?

  • Continuous integration server
  • Source control commit check
  • Simple deployment script
  • Real-time alerting
  • Root cause analysis
  • Dark Launch and Feature Flipping
  • Redefine relationship between QA and WebDev
  • Re-evaluate branch management and staging environments
  • Higher standards for code reviews

Giorgos has provided more information about each of these, and I will publish another post that goes into detail about each one.

This is a big undertaking, and it will take us several months to fully implement continuous delivery. If you’d like to give feedback or ask questions about this project, please post in the discussion forum or stop by #remo-dev on IRC. You can also follow along with the project by watching our tracking bug.