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? 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.

A new homepage for

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

There are two big changes to, our community directory, this week. We launched a new design for the homepage and we also updated the style across the whole site.

The new Mozillians homepage allows you to search for Mozillians with public profiles.

The new Mozillians homepage allows you to search for Mozillians with public profiles.

A redesigned homepage

Public search: A few months ago we rolled out the ability to have public profiles, and now you can search for those profiles without logging into the site. If you haven’t already, now is a good time to edit your profile so it shows up in public search results. This will make it easier for Mozillians as well as your friends and family to see your profile.

Better browsing: Browsing through groups and functional areas is improved, including the option to sort groups in different ways.

Announcements: To better share future changes to, we have added an announcements section on the homepage for logged-in users. When there aren’t any announcements to show, you’ll see some fun facts about Mozillians based on information in the database.

    The new logged-in view lets you browse groups more easily and also shows announcements.

The new logged-in view lets you browse groups more easily and also shows announcements.

A new look

As we were redesigning the homepage, it also made sense to update the styles on the whole site. We worked with the fantastic Brand Engagement team on the visuals and direction. We especially love their Style Guide, which made the styling much easier for us.

Take it for a spin

As with many site redesigns, this is a large release with big changes to our codebase. If you see anything that looks weird, we’d like to make it better. Please file a bug and we’ll look into it.

Mozillians, this site is for you. All 3,500+ Mozilla volunteers and paid staff. We hope you enjoy the new homepage and styles for the site. And we’ve just begun. We’ll be fixing minor UI bugs and giving profiles some attention in a redesign soon.


A round of applause to Kaustav Das Modak, Michał Frontczak, Sambit Roy, Vuyisile Ndlovu, John Kim, and Tomer Cohen as well as the Community Tools team who helped with this release.

You can now have a public Mozillians profile

[This is a re-post of a post that originally appeared on the Mozilla about:community blog], our community directory, is a great way for core Mozilla contributors to find and contact each other. Several Mozillians have asked for an option to share their profiles with others, and you can now display your profile publicly by using the new privacy controls.

If you have a account, your profile is still visible to only Mozillians. To make you profile public, go to Edit Your Profile, mark at least one field as Public, and click the Update button. Then you will have a publicly viewable profile showing all the information you have set as public. If you want your profile to remain visible to only Mozillians, you do not need to make any changes.

You can now change the visibility for each profile field when editing your profile.

You can now change the visibility for each profile field when editing your profile.

Who can see your profile? View your profile and select the different groups — Public, Mozillians, or Myself — to see what information is visible to each group. For now, the information displayed when viewing your profiles as a Mozillian or Myself is the same.

Quickly check who can see your profile information with the 'View as' dropdown menu.

Quickly check who can see your profile information with the ‘View as’ dropdown menu.

If you have at least one profile field marked as public, you will have a publicly viewable profile showing all the information you have set as public.

Making your profile public lets the world know that you’re a Mozillian. It makes your association with Mozilla discoverable on search engines, and it lets you share a link to your profile with people who aren’t Mozillians. I encourage you to make at least part of your profile public. It is a great way to share your profile with family and friends. Also, making your name, website and IRC username public allows others to easily contact you. Here’s my profile for example.

Mozillians do amazing things every day, and having public profiles allows information about individuals to be easily discovered. We’ll soon be adding badges and new fields to profiles, so you’ll be able to better connect and learn about other Mozillians. To follow along or participate in our plans, take a look at our project wiki and discussion forum.