State of Mozilla Support: 2018 Mid-year Update – Part 3

Hello, present and future Mozillians!

We are continuing our series of mid-year posts regarding the state and future of Mozilla Support. If you missed the previous posts, part one and part two are still online. This time we are going to talk a bit more about (Support) Localization and the plans for the second half of the year.

Over the years, localizer activity on the Support site went up and down, influenced by Firefox popularity, new released on different platforms, and general localization needs across Mozilla. Peaking at over 200 people around three years ago, it is now oscillating at 40-50% of that number.

While Mozilla keep continuously shipping new Firefox releases and experimenting with new ideas, the global audience will keep increasing in numbers and languages – and we want to make sure that the site stays relevant and informative to as many users out there as possible.

Design update of the site

The Support site has long been overdue to get a facelift that would make it on par with the modern and clean look of Recently, we have seen the first (preview & github issue) steps towards that.

At the moment, the preview is not fully localized, but once the updated English wording and new layout are finalized, we will be promoting

You could argue that this is only tangentially related to localization, but it may actually have a significant impact on the site’s usability for speakers of different languages. Therefore, reporting any issues found on the non-English versions of the site is very important for a successful visual refresh of We will also keep tracking site usage and interactions by users around the globe to make sure the changes have not negatively impacted site traffic.

Knowledge Base clean-up

With over 700 individual pieces of content in the Knowledge Base at the moment of writing, it is one of the biggest repositories of useful product information around Mozilla – and probably the most useful one for users of Firefox (and not only) around the world.

Changes to Mozilla’s product strategy and line-up have naturally affected the Knowledge Base and its localization profile over time. Experiments or projects become products, products become obsolete, etc. – and the content we present to the users should be displayed accordingly and evolve with the changes.

This means you can expect (or have already seen) some content going away into the archive (we do our best never to delete anything) – and new products or projects popping up as well. One of the bigger near future additions to the Knowledge Base, for example, will be the Pocket support content, at the moment hosted here.

Locale clean-up

Similarly to products, languages come and go, by popularity. While we do aim to maintain as many languages available as possible, very often the amount of content to be localized across Mozilla is already a big challenge for smaller communities around the world. You can read more about the idea and reasons behind it here. As of the writing of this post:

Locales with a “Top 100” goal before the end of 2018


Locales that need wider community support to not be archived before the end of 2018


Locales that will be archived before the end of 2018

Sorbian (Lower/Upper)

Localization request & community communication optimization

At the moment, because of the distributed nature of product development, marketing, and support, almost all of the requests for each of those separate areas come separately and are not reviewed or prioritized as a unified part of internationalization efforts at Mozilla.

This localization “request firehose” may work for separate teams or tools, but definitely does not make it easier for localization coordinators and localizers in distributed communities. Missing a single “source of truth” for localization needs for each bigger release or project introduces confusion, false expectations, and difficulties in organizing local communities around localization sprints.

Optimizing the way localization requests are filed (including new or updated Support content) through a unified process should, in turn, make it easier for localization coordinators to message contributors around the world using a single, reliable channel (for example, the Localization blog). This could also influence the way resources for organizing localization events are requested (making it easier for everyone to track and handle such requests), and have a positive impact on transparency, expectations, and timely content localization.

In short, less should be more. Less noise and confusion = more fun and better results.

Conversely, it may also mean that in some cases, the localization work for the Support site might be contracted through paid localization agencies in order to expedite the process – but we will never close contribution options for Mozillians around the world.

As all localization coordinators around Mozilla are increasingly working together on streamlining the process, we will be announcing smaller and bigger tweaks to the way localization happens at Mozilla.

The “daily stuff” and the “unplanned future”

Other that the points made above, there is quite a lot of the daily and mundane that will be happening, depending on timing, community engagement and developer support. To name a few:

Support-specific & common resources for localizers

Learning materials for new localizers, global locale style guides, best practices, cool tricks, tweaks to existing tools… and the list can go on. We already have some of these in place, while others still need to be identified, defined, discussed, and experimented with.

Modernized metrics dashboards for Support

Together with the Open Innovation team, we hope to set up an easy to maintain collection of dashboards for the Support site, using Bitergia’s open source software. If the project takes places (pending resource and timing allocation, just like anything else around Mozilla), localization will definitely be a part of it.

Recognition of your work

Always a hot topic across Mozilla, it is no different for localization. Swag goes only so far (and some of you don’t necessarily like t-shirts or stickers, which we can absolutely understand), so a bit of experimentation and soul-searching on our side may be required to make sure we show how much we appreciate your involvement in all the languages that Mozilla speaks, thanks to you.

That’s it, then (more or less)! Please, stay tuned for more updates from the world of Support and localization – and remember that your work to make Mozilla happen in so many languages does not pass unnoticed. Thank you for being there for the millions of users who can experience the internet in an open source way thanks to you all :)

State of Mozilla Support: 2018 Mid-year Update – Part 2

Hello, present and future Mozillians!

Last time we had a closer look at a metrics-based report analysis from the Analysen & Tal agency that took a deep dive into’s historical data.

Today, we are going to continue sharing external insights into our community and support model with a summary of the comparative study conducted for us by a team of the Copenhagen Institute of Interaction Design from Denmark. While we were not exactly looking for the essence of hygge, we found quite a few interesting nuggets of wisdom and inspiration that we’d like to share with you below. You can find the presentation here.

(Please note: this content has already been shared with the Support contributors on our forums, but now we are making it more public through this post).

The study’s goals were to help the Support team and community understand how Mozilla’s approach to helping users compares to other similar organizations, and what possible future approaches could help meeting the increasing demand for high quality help.

The methodology for the study was a mix of a series of interviews, case studies, and design explorations. The people interviewed came from external organizations and groups, as well as from Mozilla’s support community. The three entities chosen for the comparative study were the user communities around, Arduino, and Kaggle.

In general, when compared to our Support community,’s is more centralized and controlled, even if on average among the three case studies it resembles our own structures the most.

The contribution forums and Slack channels are used to discuss and escalate important issues. Similarly to /r/firefox, there is also an active subreddit for WordPress that’s self-moderated and open to non-support content, if necessary. Slack seems to be a place for fruitful conversations, so we may be exploring this idea in the near future for more engaged contributors.

Another interesting aspect is that the support site, apart from community-owned-and-driven support, offers full time employees of Automattic/ a chance to do rotations in the open source community. This, while tried by us in the past, has not been something we have considered as a long-standing project, but it could drive more engagement and knowledge share on all levels.

The primary incentives for contribution seem to be status and connecting with others, which we understand to be also present in our own community. However, we still need to get better at identifying the incentives for joining and staying as a long-term Support contributors to continue delivering community-driven support at scale.


Arduino’s support community, focusing on a plethora of open source software and hardware uses “in the wild”, is definitely way more decentralized and ad hoc in its practices than Mozilla’s Support.

The nature of the environment in which the community operates makes a concentrated and concerted support effort much harder, but the main activity happens across the official community forum, a StackExchange Q&A forum, and Arduino’s main Project Hub.

At the time of the study, the community forum show little conscious effort in organization from Arduino’s staff, serving a more social function with its open nature. On the other hand, the StackExchange based support forum has a well developed peer-driven reputation system, with the community moderators being voted in and gaining access and privileges based on their long-standing contributions. The StackExchange model is by far more successful and useful for support in Arduino’s case.

Finally, the Project Hub is a content creation and maintenance space that centers support-related content (for example documentation and instructables) around specific projects. Quality content is encouraged by official contests and rewards for contributors. Additionally, language and interactions presented on the site encourage a positive and inclusive community approach. As a result and thanks to the self-learning and guided aspect of using Arduino products, quality content is easier to find and produce.


Kaggle’s community model is an unusual hybrid of competitiveness and collaboration, fueled by commercially supported projects. With the community being the core and the product of Kaggle’s business model, the platform it lives on is highly sophisticated and the interactions within it appear to be meticulously engineered.

To this end, gamification of competing and collaborating is one of the main driving forces behind, encouraging high quality contributions and teamwork. The design of the community environment shows sharp focus on its key functions. The community is not directed to activities not considered core. That said, a large part of community engagement and motivation is happening outside of official forums, within self-created and user-governing communities. What’s interesting, many returning contributors consider their voluntary involvement a stepping stone towards their own professional careers.

Insights and Observations

The CIID researchers, based on their study of external support models listed above and .interviews with various members of different communities, gathered a set of recommendations or paths to explore for our community’s consideration.

Structured communities always leak

Simple explanation: Whatever we define as “Mozilla Support” will always see activity or interest outside of what we think is the “main” place where it happens.

Regardless of the community setup at the core of the experience, there will always be engagement and involvement taking place outside of centrally defined features or tasks. There is an opportunity in allowing bottom-up organization of people, while keeping the support tasks clear and accessible for everyone willing to participate. The Support site should still be the main place where supporting Mozilla’s users happens, but it should not be rigorously the only one out there.

The main challenge here is distributing our knowledge and expertise in an accessible way to other places on the web where users look for support.

Gamed incentives are valves, not pipes

Simple explanation: Gamification is a tool to improve or guide working contribution mechanisms, not to create new contribution mechanisms.

Any attempts at gamification should be modelled to embrace and enhance existing behaviours and interactions – not to create completely new ones. It is also better when it focuses on quality rather than quantity. Rewarding expertise over volume drives engagement from or creates opportunities for subject matter experts.

Here, the main challenge is to encourage positive behaviours and interactions at scale and in real time, as much as possible. This may mean looking into “high touch automation” (like bots or scripts) or rolling out a focused education/certification offering to increase quality contributions.

Contributors have ownership without agency

Simple explanation: Support contributors have great impact on how users perceive Firefox (as a browser and brand), but this is not clearly shown in the way Firefox is improved or marketed to users.

While our community is at the front line in receiving feedback from the users (and acting upon it), we do not have comparable impact on what is going on in the product world, mostly through lack of a strong enough feedback loop into the product organization, but also a lack of connection and understanding of what it is that we do from the creators and promoters of Firefox.

It would be hard to prove the impact of continuous support efforts without transparent and meaningful metrics at hand, so finding a way to collate and present such data is key for this concept to work. With our community’s work validated and acknowledged, it should be much easier to incorporate our feedback into the development and marketing process of Firefox.

Contributors aren’t born – they’re made

Simple explanation: New contributors can be found in more places than just among Mozillians not already contributing to Support

Many people decide to contribute to Mozilla’s mission based on their own strong beliefs in the future of the web – but many others get on board because they have received support from our community and would like to give back to Mozilla and its other users through activities that they can easily participate in. Supporting others very often proves to be just that (when compared to coding or web development, for example).

Encouraging casual users or those looking for help to give a try to helping others (or get involved with Mozilla’s mission in other ways) could be key to growing our community over all upcoming releases and finding new core contributors among the many people who already chose to use Firefox on a daily basis.

Support the supporters

Simple explanation: Community members should have access to knowledge and tools that allow them to work together and support each other regardless of administrator presence and support.

As the admin team for Support is quite small and each of its members specializes in a different aspect of the site, sometimes contributor questions or emergency escalations may go unnoticed for a while. This increases community fragility and pressure on single points of failure.

In order to address that, our community could consider developing a simple (but complete) escalation and reaction system that is transparent for everyone involved in supporting users. This could increase the resilience and cohesiveness of the Support community, regardless of personal experience or community roles held by various community members involved in escalating or responding to support requests.

Leverage the properties of each channel

Simple explanation: Each tool or resource should have a clear and defined role and purpose. The community needs useful tools, rather than access to all tools used by everyone else for other reasons.

With several places that our community uses for communication and support purposes, it is important to keep the roles and methods of using these separate tools clear and focused. We sometimes tend to “hop on the bandwagon” and try to be everywhere and use everything to be more in line with other teams at Mozilla.

This may not be the best use of everyone’s energy and time, so reviewing the tools we have and the ways they are used is an important step towards empowering contributors and streamlining processes that at this moment may not be working as optimal as possible.

Workshop Outcomes

As part of the working session, we sat all together and invested a few hours into a collaborative synthesis workshop, based on the data and research presented by our external partners. The output of the workshop was a series of project ideas that could influence the future Support strategy. The goal of these ideas is to improve what’s out there already and make Support ready for Mozilla’s future needs.

After a ton of small team work, three projects emerged:

Support Propaganda

General goal: increase awareness and impact of Support across Mozilla.


  • Opening up participation in Support to all Mozillians (especially new hires for any position at Mozilla)
  • Creating a deeper connection between Support, Product, and Marketing through highlighting what Support does to help Product and Marketing deliver quality to users (data driven insights)

Switchboard Operator

General goal: High-touch targetted support for Mozilla’s software users across the web


  • Gathering information and insights about all major locations where conversations are happening about Firefox (within the context of support)
  • Reaching the users with the right support information wherever they are

Alchemist’s Journey

General goal: Quality self-directed learning resources and trainings for future generations of casual or core contributors


  • First wave trial resources developed in collaboration with existing core contributors
  • Second wave researched resources developed based on experiences from the first wave and input from external online education experts

Next Steps

There are more updates to come that should show you how the above work is influencing what direction we think the future of Support at Mozilla should look like.

We will keep working together with Open Innovation (closely and directly) and CIID (for future research projects) and informing you of what is up with Support at Mozilla.

We will also keep you informed (and engaged) in the future of Support at Mozilla.

Thank you for being a vital part of Mozilla’s mission for an open and helpful web!

State of Mozilla Support: 2018 Mid-year Update – Part 1

Hello, present and future Mozillians!

As you may have heard, Mozilla held one of its All Hands biannual meetings, this time in San Francisco. The Admin team was there as well, along with several members of the support community.

The All Hands meetings are meant to be gatherings summarizing the work done and the challenges ahead. San Francisco was no different from that model. The four days of the All Hands were full of things to experience and participate in. Aside from all the plenary and “big stage” sessions – most of which you should be able to find at Air Mozilla soon – we also took part in many smaller (formal and informal) meetings, workshops, and chats.

By the way, if you watch Denelle’s presentation, you may hear something about Mozillians being awesome through helping users ;-).

This is the first in a series of posts summarizing what we talked about regarding, together with many (maaaaaany) pages of source content we have been working on and receiving from our research partners over the last few months.

We will begin with the summary of quite a heap of metrics, as delivered to us in by the analytics and research consultancy from Copenhagen – Analyse & Tal (Analysis & Numbers). You can find all the (105!) pages here but you can also read the summary below, which captures the most important information.

The A&T team used descriptive statistics (to tell a story using numbers) and network analysis (emphasizing interconnectedness and correlations), taking information from the 11 years of data available in Kitsune’s databases and 1 year of Google Analytics data.

Almost all perspectives of the analysis brought to the spotlight the amount of work contributed and the dedication of numerous Mozillians over many years. It’s hard to overstate the importance of that for Mozilla’s mission and continuous presence and support for the millions of users of open source software who want an open web. We are all equally proud and humbled that we can share this voyage with you.

As you can imagine, analyzing a project as complex and stretched in time as Mozilla’s Support site is quite challenging and we could not have done it without cooperation with Open Innovation and our external partners.

Key Takeaways

  • In the 2010-2017 period, only 124 contributors were responsible for 63% of all contributions. Given that there are hundreds of thousands of registered accounts in the system, there is a lot of work to do for us to make contributions easier and more fun.
  • There are quite a few returning contributors who contribute steadily over several years.
  • There are several hundreds of contributors who are active within a short timeframe and even more very occasional helpers. In both cases, making sure long-term contributing is appealing to them.
  • While our community has not shown to be worryingly fragile, we have to make sure we understand better how and why contributions happen and what can be done to ensure a steady future for Mozilla’s community-powered Support.
  • The Q&A support forums on the site are the most popular place for contributions, with the core and most engaged contributors present mostly there.
  • On the other hand, the Knowledge Base, even if it has fewer contributors, sees more long-term commitment from returning contributors.
  • Contributors through Twitter are a separate group, usually not engaged in other support channels and focusing on this external platform.
  • Firefox is the most active product across all channels, but Thunderbird sees a lot of action as well. Many regular contributors are active supporting both products.
  • Among other Firefox related products, Firefox for Android is the most established one.
  • The top 15 locales amount to 76 percent of the overall revisions in the Knowledge Base, with the vast majority of contributions coming from core contributors mostly.
  • Based on network analysis, Russian, Spanish, Czech, and Japanese localization efforts are the most vulnerable to changes in sustainability.

What’s Next?

Most of the findings in the report support many anecdotal observations we have had, giving us a very powerful set of perspectives grounded in over 7 years’ worth of data. Based on the analysis, we are able to create future plans for our community that are more realistic and based on facts.

The A&T team provided us with a list of their recommendations:

  • Understanding the motivations for contributing and how highly dedicated contributors were motivated to start contributing should be a high priority for further strategic decisions.
  • Our metrics should be strategically expanded and used through interactive dashboards and real time measurements. The ongoing evolution of the support community could be better understood and observed thanks to dynamic definitions of more detailed contributor segments and localization, as well as community sustainability scores.
  • A better understanding of visitors and how they use the support pages (more detailed behaviour and opinions) would be helpful for understanding where to guide contributors to ensure a both a better user experience and an enhanced level of satisfaction among contributors.

Taking our own interpretation of the data analysis and the A&T recommendations into account, over the next few weeks we will be outlining more plans for the second half of the year, focusing on areas like:

  • Contributor onboarding and motivation insights
  • A review of metrics and tools used to obtain them
  • Recruitment and learning experiments
  • Backup and contingency plans for emergency gaps in community coverage
  • Tailoring support options for new products

As always, thank you for your patience and ongoing support of Mozilla’s mission. Stay tuned for more post-All Hands mid-year summaries and updates coming your way soon – and discuss them in the Contributors or Discourse forum threads.

Proposal: Knowledge Base Spring Cleaning at SUMO – June 2018

Hi everyone,

People say that spring is a good time to try new things and refresh one’s body and mind. While our site does not really have a body (unless you count the HTML tags…) and its collective mind is made up of all of us (including you, reading these words), it does need refreshing every now and then, mostly due to the nature of the open, living web we are all part of.

That said, let’s get to the details, some of which may sound like Rosana’s post from about 4 years ago.

What’s the proposal about?

The localization coordinators across Mozilla want to consolidate Mozillians and our resources around active locales. In the context of SUMO’s Knowledge Base, this means taking a closer look at the Knowledge Base, which at the moment is available for 76 locales (at least “on paper”).

The proposal is to redirect the mostly inactive locales of the SUMO Knowledge Base to English (or another best equivalent locale). You can find the proposed (draft) list of all the locales here.

  • 23 locales will remain active, with localizers providing good coverage both via Pontoon and SUMO’s Knowledge Base – and no action will be required for them.
  • In 30 cases, the existing (and historically active) localizers will be contacted to decide on reviving the localization effort for SUMO content. If there is enough interest, they will remain active (with a plan to update content). If there is not enough interest, they will be redirected at the end of June.
  • In 23 cases, the locales will be redirected at the end of June due to little or no localization activity over an extended period of time. These can also be reactivated at a later time, if need be.

It is important to note that no content created so far would be deleted.

Why do we want to do this?

There are several reasons behind this proposal:

  1. Fewer locales mean more administrator focus on actually active locales – more time for joint projects or experiments, more attention to the needs of localizers putting a lot of time and effort into making SUMO global on a continuous basis.
  2. Firefox and the main Mozilla pages have a higher priority than SUMO, so for many localizers it’s better to focus on these projects, rather than getting involved with Knowledge Base localization.
  3. The “long tail” locales on SUMO are accessed by a very small number of users each month, so there is little need for serving them at this point.
  4. Revisiting this initiative in 6 months will help us see progress made by local communities in building up their active localizer numbers.

What are the next steps?

The 23 locales counted as “no change” will keep functioning as usual, with more locally driven activities coming this year – check the last section of this L10n blog post for just one of the many possibilities.

During April and May, I will reach out to all the contributors listed in SUMO and Pontoon for the 30 locales that are listed as candidates for the clean up – using Private Messages on SUMO or emails listed in Pontoon. Depending on the answers received, we may be keeping some of these locales online, and coming up with a realistic (but ambitious) localization progress timeline for each of them.

At the end of June (after the All Hands), all the locales that are not active will be redirected to English (or another best equivalent locale).

After that, localization for the redirected locales will be focused on Firefox and other Mozilla properties. If there is interest in reactivating a locale, it will happen according to a “re/launch plan” – including creating or participating in a SUMO Knowledge Base sprint event aimed at localizing at least the 20 most popular articles in the Knowledge Base as the minimum requirement, and additional sprints to localize an additional 80 most popular articles.

Is anything else being cleaned up at this stage?

No, the Knowledge Base is a big enough project for now.

Still, this is just the start of this year’s clean up – we will also look into reviewing and reorganizing our contributor documentation, English Knowledge Base, and other properties containing content relevant to SUMO (for example our MozWiki pages).

Please let us know what you think about this in the comments or on our forums: SUMO / Discourse.

15 days in feedback at the group “Mozilla Social Support”

I had the pleasure of working with Christophe Villeneuve aka hellosct1in the beginning of February this year and he wrote a great review about his experience during the first two weeks in the Social Support Program. If you are on the fence about joining the Social Support program, check out this testimonial for what to expect in the first 15 days of the program. It can not only be rewarding it can be pretty easy to get started.

To get started check out the guidelines page to get started.

This is a good read for those of you that are interested in what the program is like.

From the desk of Christophe:

Since I joined the group “Mozilla Social Support” at the end of January 2018, I realized that I was already doing user support without really contributing to the support part. This was reflected mainly through my presence at events, media (press, radio…), answering questions after my talks or just just with my presence in some shows.

I’m going to give you a little feedback on my 15 days of activities, impressions and the process that I have in place at home to answer all the messages.

Before 2018

Before, of incorporating the team, I have been busy since the launch of Firefox OS in France in 2013, I took care of answering technical messages to arrive little by little to contribute directly on the Twitter accounts of @mozilla_fr and @firefox_fr. In addition, I do the same thing with the Facebook account FrMozilla and the Mastodon account

I noticed that the majority of messages that arrive on these accounts were not tagged #fxhelp.


Tooling is important to answer easily, and it is not uncommon to have hundreds of tabs when we follow the news or make support. (On average I have 800 to 1,200 tabs).

That’s why, I pinned some tabs to avoid looking for them in my favorites or containers, like this I pinned Tweetdeck, the forums of mozfr (Mozilla fr), etc.

The point is to be able to quickly, and from time to time consult important pages to view new messages.

By the way, I installed alerts using IFTTT to retrieve the messages coming from these networks because I am not always connected with my computer. These alerts arrive directly on my Telegram account that I also use on my mobile phone, so I can react quickly, instead of waiting several hours (or days) for the person who is waiting for his answer.



Since my arrival, 2 weeks ago, I have already closed more than 220 messages. This happens as follows:

I continue to respond on twitter, which is the first resource of my habits and I answer through the official accounts (@mozilla_fr, @firefox_fr) with serious answers. I do the same thing for Facebook and Mastodon.

Then I go to the ‘army of awesome’ page to answer the tagged questions #fxhelp and here I use my nick @hellosct1.

I can note a small regret [in the Army of Awesome app] about the number of characters available for the answer because I find the input area quite small compared to a twitter account that accepts 280 characters.

Finally, I go to the site ‘Buffer reply’ to process messages that are in French, and answer the different Firefox questions – my answers are made with my @hellosct1. In addition, from this account, I can check if all the questions have been answered and thus close the conversation.

Note the Army of Awesome app is still planned to be removed, the development of this has been post boned. Currently further development has not been prioritized.


Sometimes the user answers a question I asked for more information, or to thank me or to rest another. During the exchanges, we lose the hashtag #fxhelp that I try to put back if I answer, but it is not always intuitive, which means that there is a point to improve on the follow-up.

One of the ideas would be to replace the #fxhelp with @fxhelp with the risk of having an increase in the traffic or the volume of the messages.

During the exchanges, it is necessary to test more thoroughly a problem or a question that has been raised, until declaring it in bugzilla if the problem could be reproduced and qualified.

In summary

The Firefox browser must be pre-configured with the pinned tabs, allowing quick access to the media interfaces, which are for me:

  • Tweetdeck
  • Army of Awesome
  • Buffer Reply
  • etc.

Of course, this is a first comeback because I have little perspective on this activity, it is always possible to question me or to have more details.

Christophe Villeneuve aka hellosct1

  • Mozilla Reps
  • Team WebExtensions / Addons
  • Team Mozilla Social Champion
  • Team community Communication French
  • Team MDN Web Docs
  • Team Mozilla Social Support

Already a social contributor? Leave your feedback here