Category Archives: Discussions

The about:sumo experiment

A while back, the idea of creating an about:sumo newsletter was
proposed. Since then, we’ve been so busy with other parts of SUMO, that
we never got to follow through on that idea.

We haven’t forgotten! In the next three months, we’d like to test out
the idea, and see how it goes. The purpose of the newsletter would be to
provide a digest of news from the SUMO world for those who are not
actively involved, but still interested in knowing what we’re working on.

Over the next three months, we’ll publish a newsletter each month, and
depending on the feedback from the community, we’ll know whether or not
to make the newsletter a regular thing. Stay tuned for more information.

SUMO contributors meeting is Monday and I can’t wait

A few days ago, we blogged that we’ll be having a contributors meeting Monday Jan 12th. I just wanted to write this to say that I’m really excited to hear what everyone has to say about improving SUMO in 2009. We’ll be discussing the year past but focusing on the year ahead. So everyone bring your ideas, thoughts, and brilliant plans! A quick reminder about the meeting:

Monday Jan 12th 2 PM PST/5 PM EST/10 PM GMT:

  • California: 650-903-0800 then extension 92, conference number 280#
  • Toronto: 416-848-3114 then extension 92, conference number 280#
  • Toll-free (US): 800-707-2533 then password 369, conference number 280#
  • Skype (free worldwide): +18007072533 then password 369, conference number 280#

The backchannel (where we post links and share text) is #sumo on irc.mozilla.org and our agenda and notes is on the Mozilla wiki.

If you can’t make the time, never fear, just tell us your thoughts in IRC at any time or come to one of our weekly phone meetings Mondays at 10 AM PST/1 PM EST/6 PM GMT.

Not everyone wants to search

I’ve talked before about the so-called Support Funnel and how the Knowledge Base is the heart of SUMO, ensuring that people find solutions to the most common problems without necessarily having to interact directly with our support community. The reasons why this is important are many:

  • It ensures that the solutions to the most common problems are written in a clear, concise, and straightforward language that is easy for our users to understand.
  • It reduces the pressure of our community of volunteers since most users are self-served.
  • It gives us a powerful way of tracking which problems are the most common with the help of metrics.

The Support Funnel. For more information, see The vision for SUMO – Part 2: Understanding the bigger picture.

So, how do we ensure that people find the solution to their problem in the Knowledge Base? Well, one way of finding the solution is by searching for it — something we try to make very obvious on the start page. The reason why we think searching is the best way of finding the solution is because the Knowledge Base is big. Really big. While we have a list of the most popular support articles right there on the start page, it’s hard to make it obvious that there is a lot more content in the Knowledge Base than what is shown on the start page.

The start page of Firefox Support, clearly emphasizing on the search function.

So, is everyone really comfortable searching? Actually, the almighty and ever so wise chofmann and I have started to see evidence that some people prefer to browse for the solution rather than searching for it. Among the people that visits the Firefox Support start page and doesn’t instantly leaves the page, only roughly half of them actually searches. The other half either clicks on one of the hand-picked popular support articles, or clicks on some other link on the page.

We’re not sure what the reason for that is, or if there are several reasons. It could be that people are unable to accurately describe the problem they’re seeing — considering how many people that are using Firefox today, this is not surprising. Even my older brother, who has been using computers for at least ten years, has problems describing some of the problems he has with his computer, and usually I have to pay him a visit, have a nice cup of coffee, and fix the problem myself.

Another reason could be that people simply prefer to browse a categorized list of articles instead of searching — essentially just clicking on a few links instead of actually typing. I talked to our creative genius John Slater a few weeks ago and he said that he’s usually a little skeptic about internal search engines and that he prefers to just browse.

Francisco Picolinni from the Mozilla Hispano community provided a third possible reason why people are unwilling to search — because they might not think anyone else has the same problem.

Regardless of why not everyone searches, it seems like we should work on providing a good way of browsing the Knowledge Base. We currently have a link at the bottom of the list of popular support articles saying “Browse all Knowledge Base topics.” However, the page that link takes you to is just a long list of all articles ordered by hit count — not exactly easy to navigate.

chofmann, John Slater and I recently brainstormed around how we could ensure that as many people as possible find the solution to their problem in the Knowledge Base with minimum effort. Since the Knowledge Base articles are loosely connected with tags like “bookmarks,” “location bar,” etc., one interesting possibility would be to show these tags in a tag cloud that would provide a better sense of the diversity of the content while still pointing to specific, popular topics. Clicking on a tag would filter the list to only show the articles with that particular tag.

Tag cloud

A tag cloud around the topic Web 2.0.

Another problem to solve is making sure that people really understand that they can browse for solutions as an alternative to searching. We want people to understand that Firefox Support has the answer to their problems and that they should stay on the site until the problem is solved. This probably means we have to take a closer look at how the start page is designed to see how we can better communicate this. If you have ideas on how we can achieve this, we are interested in hearing them!

What we really want a user with a problem with Firefox to feel when visiting Firefox Support is: “These people are here for me, and they won’t give up until my problem is solved.”

We just started to work on this, so stay tuned for more…

SUMO Newsletter?

There’s been a discussion in the mozilla.support.planning newsgroup (a place where many of the discussions behind the SUMO project are taking place that for various reasons aren’t happening in the Contributor Forum) about an about:sumo newsletter, similar to how we already have newsletters for Add-ons (about:addons) and the whole Mozilla project (about:mozilla).

SUMO contributor myles7897 originally proposed the idea, and more importantly, created a pretty fantastic mockup of how such a newsletter could look like and include:

We’d like to hear what you think of this idea and whether or not this would be useful to you. The idea is that we would blog about various SUMO related things as we already do, and then collect and package the most interesting bits every month and turn that into this newsletter format.

Thanks to myles7897 for creating the mockup, and to Bubo for proof-reading!

The vision for SUMO – Part 8: Live Chat

We’ve reached the last part of this comprehensive vision for the scope and role of the SUMO project moving forward. This part is dedicated to the most social form of text based user-to-user support: Live Chat.

If a problem isn’t yet covered in the Knowledge Base, or if the instructions in the article are too hard to understand, Live Chat is a powerful way for users to get touch with Firefox experts and get hands-on assistance in solving their problems.

Live Chat can also be a very fun way for contributors to provide support. Contributors helping out with Live Chat don’t just help users, they talk to each other in the backchannel as well, providing assistance to other helpers whenever needed. This means that although you’re usually the only one interacting with the user you’re helping, you’re never alone.

An important aspect — and one of the most interesting in my opinion — about Live Chat is that it is instrumental in detecting new and emerging support issues that are not yet covered in the Knowledge Base. The people helping out with Live Chat, along with helpers of the Support Forum, are those closest of all to what is going on — they really are the ones with their finger on the pulse, if you will.

However, without enough contributors, Live Chat has the risk of giving the user a negative experience, principally because of long waiting times or limited hours of operation. Without contributors, Live Chat can never be successful. We think the two keys to attracting contributors are:

  1. to make contributing as straightforward as possible;
  2. to minimize the load on the contributors by using their time as efficiently as possible – we do this with the support funnel. More specifically, we want to make sure that people search the Knowledge Base (and Support Forum) before turning to Live Chat, so helpers aren’t overwhelmed by the number of users requesting assistance.

I’ve already covered the support funnel in previous blog posts, so this time I’ll focus on how we can make contributing to Live Chat as simple and fun as possible. As always, we already have some ideas, but we really need your feedback as well.

Fully integrated help client

In order to help out with Live Chat today, you need to install an open source Java-based chat client called Spark. This means that unlike the Knowledge Base or the Support Forum, people need to learn how to install, configure, and use a separate application in order to get started with helping people with Live Chat. While the current solution certainly works, it is far from ideal for a number of reasons:

  • It’s an unnecessary technical barrier and yet another application installed on peoples’ computers.
  • It’s poorly integrated with the rest of SUMO, meaning, among other things, that people helping out with Live Chat may not be aware of the support funnel and the most commonly reported problems and solutions already documented in the Knowledge Base.
  • The software isn’t custom-made for our needs, meaning for example that it’s not straightforward for helpers to find the backchannel where other helpers hang out.
  • We rely on good documentation to ensure that helpers understand where they should look for assistance and relevant information.
  • We have a separate log in for Live Chat than the rest of SUMO.

Replacing Spark with something integrated into the SUMO website itself would give us a solution that is pre-configured for our particular needs, do away with the need for separate software, and seamlessly integrate information about weekly common issues and other things relevant for our helpers. The barrier of entry would be reduced significantly.

Simple scheduling solution

Today we have specific times of the day when we’re sure to be open — our “hours of operation” for Live Chat. This is helpful for contributors as they know when they can expect other people to be online. After all, just like many other things in life, Live Chat shouldn’t be a solitary activity.

The ideal solution would be if people could just log in and help out whenever they wanted to, but that would require lots and lots of helpers. We’re not quite there yet, and in the meantime we need a way to make the existing helpers gather around certain scheduled hours naturally. However, the hours of operation might not fit everyone, so we need something that will allow people to commit to specific time slots that are convenient for them, while still seeing which slots other people have offered to take or would like to take — think of it as a shared calendar.

This would give helpers the ability to plan ahead of time when they want to help out, based on what time slots other helpers have already committed to. We think this will encourage collaboration and make Live Chat even more fun. Furthermore, the official hours of operation could then be based on the confirmed schedule time slots, rather than predefined hours we’re using today. And from a user’s point of view, the relevant info is when Live Chat will open next, not a predictable weekly schedule.

Other improvements

Of course, integrating the help client and adding a capability to assist volunteers in being able to plan their contribution of time are just a couple of things we can do to make things simpler. Here are some other things we have in mind:

  • Support for other languages than English — Both users and helpers often speak more than one language. Ideally, users would simply select which languages they understand from the list of currently available languages. That list of available languages would itself be based on which helpers are currently logged on.
  • Add a lower limit of the number of helpers that needs to be logged on before Live Chat opens, to ensure a good support experience. This way, we can control the helper/user ratio and thus avoid helpers burnout. In other words, if there are lots of users in need of help, we’d need more helpers before we opened Live Chat, to ensure that the waiting times are not unreasonable.
  • Automatically save chat logs, along with user happiness rating and whether or not the problem was solved. This would allow us to make better use of the Live Chat stats about common Firefox problems. It would also allow us to tell which helpers are doing a great job, and which ones need a little more training.

Have you tested Live Chat already? If so, what did you like about it, and what would you want to change? We’d love to hear your thoughts, and whether or not you think our ideas are in line with what you’re seeing, or if you have other ideas we haven’t covered here.  And if you haven’t tried it yet, consider this a written invitation. :)

The vision for SUMO – Part 7: Support Forum

The Support Forum is a way for users to ask direct support questions about problems not (yet?) covered in the Knowledge Base, as described previously as the support funnel. It is also an important place to detect new or emerging issues and make sure those issues are dealt with in the best possible way.

The Firefox 3.0.2 release is a very good example of this importance; shortly after the 3.0.2 update started to roll out in Europe, Carsten Book from the QA team noticed early signs of users having problems with the Password Manager from various places such as support forums on Heise, and Hendrix. It was then quickly confirmed to be a frequent issue in the Support Forum of SUMO as well.

In a matter of hours, this went from early signs from our different user channels to a solid plan to release an update of Firefox (due out today or tomorrow) to fix it, as well as a new Knowledge Base support article about the issue. SUMO was just one player in this great and efficient teamwork, but it highlights well our ability to “extend our tentacles” during releases to ensure that we keep doing what we do so well: listening to our users — in this case as an early warning system, if you will.

For contributors, the Support Forum is an exciting place to be, since you can take part of this early warning system, while at the same time making other people happy by helping them with their problems. It’s a good place to start helping since you can simply browse through the posted questions and see if there is anything you know the answer to. There are no obligations to respond if you don’t know the answer.

Reaching out to the people in need

One of our current challenges with the Support Forum is that while we have an incredibly helpful community answering a large number of questions, we don’t have a good way of ensuring that the user asking the question actually comes back to read the answer. This means that we don’t really know if the user’s problem was actually solved or not, only that we at least tried to help.

Question asked in the Support Forum.

We’d like to change this by making it easier for users to find their way back to the forum thread they posted. When a user asks a question in the Support Forum, we should offer the ability to get an e-mail notification when someone responds to the question. This way, people don’t have to worry about how our support site works or what page to bookmark — we will reach out to the user instead of the user finding its way back to us.

Making the forum easier to use for our community

Of course, in order to reach out to our users we need to make sure there are people who want to help others in our forum. :) We already have a group of really amazing people in the forum who help a lot of the users who turn to the forum with their Firefox support questions. However, we definitely need more contributors to cope with the load.

One important thing to focus on in order to make it more pleasant to hang out in the forum is to make the site easier to use for our contributors. We have a few ideas:

  • Give contributors credit for solving problems — Allow the user posting the original question to tell us whether or not an answer from a contributor solved the problem, giving contributors credit for their help. Readers of the earlier parts of this blog series might remember the discussion about a contributor karma system in part 3.
  • Highlight the solution to a problem — Some forum threads quickly grow long, making finding the actual solution to the posted problem hard to find. Other people who stumble across the thread in search for a similar (or same) problem typically want to get straight to the solution, which could be buried on page 4 of a very long thread. We should make that solution easily discoverable at the start of the thread, by allowing the original poster of the thread to mark a particular response in it as the solution to the problem. This will benefit not just our users, but our contributors as well.
  • RSS feed for incoming support questions — Instead of having to log in to SUMO in order to read the latest incoming support questions, a convenient alternative would be to just subscribe to an RSS feed (also known as Live Bookmark in Firefox). This way, people could set their mail client (e.g. Thunderbird) to notify whenever a new question is posted.
  • Smart forum thread filters — When browsing the forum today, all questions are listed, including the ones that are already answered. Many contributors are more interested in looking at threads that haven’t been answered yet. Others might want to see only the threads they’ve responded in. We should allow for an easy way to filter the forum view based on what’s relevant for our visitors.
  • Localization — This is a big one. We currently only have an English support forum and we’re starting to get more questions posted in other languages as the visibility of SUMO increases. For the locales that have enough contributors a need for it, we should definitely create a support forum in that language.

What other ideas can you think of that would make the forum more pleasant to use for you? We would love to hear from you about your experiences with the SUMO Support Forum so we could use your feedback to improve the site for everyone.

The vision for SUMO – Part 6: Knowledge Base

The Knowledge Base is the heart of SUMO and consists of a large collection of support articles largely written by the community. The key focus and scope of the Knowledge Base is troubleshooting — solving people’s problems with Firefox — as well as teaching people how to use Firefox and, by extension, the web.

The Knowledge Base is meant to be the primary method of getting support, since it already contains the answers to the most common Firefox issues. Because of this, the articles in the Knowledge Base need to be:

  1. easy to find,
  2. easy to understand, and
  3. easy for contributors to edit.

Let’s cover them one by one — easy as 1-2-3!

1 – Better search

Searching is central to the support funnel –- we want people to search for their problems first. Because of this intended flow through the funnel, it’s critical that the search function is working well and serving the right results.

There are some problems with our current search engine. Most importantly, we don’t have fine-grained control over its behavior, and we can’t control the frequency of its reindexing (the process of making sure all articles are searchable). This means that it might take weeks after a new article is created until it appears in the search results, which is really not ideal.

  • The search engine should index the Knowledge Base article on a daily basis to ensure up-to-date search results.
  • When a new article is published, the search engine should automatically re-index to include it. Being able to quickly ensure new information is accessible to our users is critical if e.g. a new issue is discovered after a new release.
  • Search rating should primarily be based on the frequency of the reported problem, the article tags it contains, and its description. It should also support manual tweaking to ensure new and critical issues are getting a top search result listing even before they’re naturally picked up by popularity.

We could also do a better job of integrating the provided solutions to problems from the Support Forum with the search results. For example, when a user searches the Knowledge Base, we could offer a simple way to extend the search to include answered threads in the forum as well.

Another area of improvement is with locale specific searches. Today we include matches in English articles too, but there’s no clear distinction between the content available in the local language and the English (still untranslated) content.

All in all, this should make articles easier for users to find.

2 – Screencasts

Some users resort to the Support Forum or Live Chat simply because they don’t understand the contents of a Knowledge Base article and need some hand-holding to solve their problem. Screencasts (essentially videos) is a powerful visual medium that helps translate and communicate technical concepts to a wider audience. Even for users who are perfectly capable of following written instructions, watching a screencast can speed up the problem solving process significantly.

Frequent readers know that we already have a bunch of screencasts ready to be used in the Knowledge Base — we just need to get the infrastructure up so we can actually provide them to our readers. Specifically, we need:

  • an easy way to upload and embed screencasts into Knowledge Base articles, and
  • an elegant way of presenting them in the articles themselves, for example a simple “Show me how” link, expanding into a full screen video view upon clicking; no annoying pop-up windows; all embedded into the page à la Web 2.0.

Once we have this up and running, articles should be easier for users to understand.

3 – Streamlined article editing

Since the Knowledge Base is our most powerful tool to provide efficient support for our users, it’s equally important that this tool is as simple for contributors to use as possible. We have some ideas:

  • What You See Is What You Get (WYSIWYG) editing — editing a Knowledge Base article should be as simple as writing a blog post. This is easier said than done, but it’s definitely worth investigating the possibilities, as it would dramatically simplify things for casual Knowledge Base contributors that just want to correct a typo without having to learn a whole new wiki syntax language.
  • No-nonsense editing process — remove buttons and options that are just confusing. Right now there are a lot of them, and they’re laid out in a somewhat confusing way.
  • Other ideas? This is where you come in. Chris Ilias started a thread to discuss this item more thoroughly, and we’d love to hear your feedback!

With these improvements, Knowledge Base articles should be easier for our contributors to edit, allowing more people to participate.

And that ends part six. As simple as Do Re Mi.

The vision for SUMO – Part 5: Localization

Approximately half of our users are running an English (US, British, or other) version of Firefox. This is why localization is such a critical part of Mozilla, because it enables us to reach that other (significant!) half.

Shrep presenting percentage of Firefox locales. Photo (c) Martin Creutziger.

Localizing SUMO is not just about translating English articles to another language — it’s about making the Firefox support experience truly local, while also participating in the mission to further refine the quality of our support.

Let’s take an example: a localizer might start translating an English article into her own language, but while doing that she spots an error in the English article that needs to be corrected. By making that correction in the English article herself, or by notifying an English article editor (e.g. by posting feedback at the bottom of the article), the overall quality of our work improves, which of course everyone benefits from.

Another example is if the localizer is able to express herself in a clearer way than the original English article reads. In this case she could make sure that improvement is shared with the English half of our users in a similar way as described above. The Knowledge Base is far from perfect — there are lots of opportunities to improve the readability of the articles, and localizers have a great opportunity in this ongoing work by either writing a better localized version (and inform English contributors about the improvements), or by simply updating the English article directly.

One aspect of localization in the context of support is that some support topics only really apply to specific locales. For example, a popular German news site (e.g. spiegel.de) might have problems working correctly in Firefox for some reason (highly unlikely, considering the popularity of Firefox in Germany). In this case, a German SUMO contributor could just create a Knowledge Base article for that problem even though it doesn’t yet exist in English. Depending on the nature or severity of the problem, an English article might still be warranted, but the German localizer shouldn’t feel obligated to do that work him/herself.

Of course, for people that are comfortable with just translating an English article to their own language, SUMO can help there as well by providing tools that help determine which articles are the most important to translate. By sharing the weekly stats about the most commonly reported problems or requested features with localizers, we should be able to provide a clear overview of which articles to focus on first.

Clear locale overview

Speaking of a clear overview, here are some specific things we can do to improve SUMO for localizers:

  • It should be easy to see the translation status of a SUMO locale. A localizer should be able to log in and be presented with a dashboard summarizing the overall status of the contents available for his or her locale. We should use things like pie charts, colors, tables, etc to paint a clearer picture to everyone participating.
  • The priorities should be clear — it should be easy for localizers to see which articles should be translate first. If there are some articles that users read more often than others, these articles should be clearly marked as in need of translation.

Other improvements?

What more can we do to make the localization experience as smooth as possible? Probably a lot of things. We should definitely make sure the UI of the site is fully and easily localizable using established file formats (*.po files anyone?), and more generally, we should connect with localization teams and individuals to gather more feedback.

If you’re a localizer, please help us by providing your feedback; it will really help us verify that we’re on the right track and thus allow us to move forward faster. Thank you in advance!

The vision for SUMO – Part 4: Having our finger on the pulse

I’ll start part four of this blog series with an important question: Are our Firefox users happy about their browsing experience? If they are, exactly how happy are they? Can we measure that somehow? If they’re actually not happy, can we figure out why so we can do something about it?

By looking at the right set of metrics, SUMO can really have a finger on the pulse of the large Firefox user base. Analyzing and understanding the data we’re gathering is critical to the continued success of Firefox and will undoubtedly benefit the Mozilla project as a whole.

SUMO is a great source of information here because it’s the obvious channel for mainstream users to look for support and documentation. We are already analyzing the data we’re gathering, but we’re not really there yet. Some information that would help paint a clearer picture:

  • Track search terms that have increased in popularity in recent time, rather than just looking at the fairly static list of top search terms as we’re doing today. That could give us early warnings about emerging issues or trends.
  • Thorough data mining –- if we dig deeper to understand how our users use the site by tracking data like “Which articles did users read and what did they search for before ending up in the forum/chat?”, we would gain a much better understanding of how well our SUMO website works for our users. This knowledge could give us a clear idea of how to improve Knowledge Base articles and search results.

Today we’re doing a lot of the information gathering manually. To speed this up and allow us to focus on analyzing the data instead, we should automate the information gathering as much as possible:

  • Automatically track specific keywords related to “badware” (spyware, adware, trojans, etc.) to ensure we can become proactive against new issues.
  • Add alarm triggers when signs of unusual traffic emerges, e.g. excessive reports of tracked keywords.
  • Automatically collect metrics to be analyzed daily/weekly.

Measuring SUMO performance

There are many things we can measure to get a better understanding of our strengths and areas of improvement, such as:

  • average rating of Knowledge Base article (poll “Was this article easy to understand?”)
  • average response waiting time in the Support Forum
  • ratio of threads resolved in the Support Forum
  • average Live Chat session length and waiting time
  • ratio of Live Chat sessions resolved

We are already measuring some of these, but not all of them. Apart from getting all this data in the first place, we should put more focus on presenting it to our contributors, and analyzing it to better understand how we can continuously improve our support and as a result get happier users.

Measuring user happiness

Back to the original question: are our users happy, and how can we measure it? Well, what we can do is measure how well SUMO meets our users’ expectations. If we’re doing well according to our users, that means we have happy users.

To get an overview of our quality of support and whether or not it’s improving over time, we should start measuring customer satisfaction, but since we don’t have customers, let’s just call this user happiness instead! With this data, we will be able to tell how well we meet or surpass our user’s expectations. It can also indicate how well the various components of the site perform.

  • The data could show a total average of our user’s happiness level with SUMO as a whole, but it could also show per-component (KB/forum/chat), and even per-article (KB) data, to give us both an overview of, and detailed insights about how well we’re doing.
  • The data should be collected automatically and shared quarterly with e.g. marketing team, who are also keen on getting deeper insights about our user satisfaction.

With all of the above, the SUMO community should be able to tell — with confidence — whether or not our users are as happy as we want them to be.

The vision for SUMO – Part 3: Increasing community participation

In the past, there has been some discussion about how SUMO interfaces with existing local community work. SUMO has been in place for one year now and we have shown many ways where local communities are working directly on support issues for end users. As SUMO grows, we need to be even more efficient as we work together.

SUMO and the local support communities

For many locales, I believe SUMO can really add value to their communities because we can provide things like a solid server infrastructure and an established wiki with a useful review system. But it really doesn’t stop there. SUMO is designed from the ground up to be a platform specialized on support. With the already existing SUMO community, we have shared access to a lot of interesting things, such as an overview of our most critical issues with Firefox, and a way to determine the quality of our content. We also have a pretty close collaboration with the rest of the Mozilla project, such as the amazing QA team. They can provide us with a lot of useful information, and we can do the same thing for them.

How does this relate to the support for your locale? For one thing, it gives you a better overview of what our users are most frequently asking, which helps determining what support content we should focus on. It also gives you the ability to determine the overall quality of your support by looking at things like which articles users find hard to understand. By working more closely with other Mozilla teams like QA and Firefox development, it might also help making your local community feel more involved with the rest of the Mozilla community.

On a more general note, I think we should all think about Mozilla as one united community. The important thing should be the fact that we come together to do all the great things that we do, not on what domain or server our accomplishments take place.

That said, for communities that still prefer to keep their support on their own infrastructure, how can we better promote that content on SUMO? Right now we’re linking to these sites on the “Other Firefox Support” menu item on the start page. Is that enough, or can we do other things to make it easier for our users to get help?

SUMO and Firefox

Another concern some local communities have with SUMO, or at least have had in the past, is its Firefox-centric focus. Readers of my personal blog might have already read my post The scope of SUMO, where I explained the reasons for starting with Firefox, and my thoughts on the project expanding in the future. Let me quote a part of it that I think summarizes it well:

In the future, when Firefox Support is doing really well, I could definitely see the scope being expanded to make the solution work for other Mozilla projects as well (and with the open source nature of the knowledge base and forums, it could even be used by other non-Mozilla projects, just like Bugzilla is used by almost every open-source project out there).

The work we’re doing on SUMO now is there to be done for other projects as well and will come in time. We’re not limiting ourselves to Firefox because we don’t care about the other projects, but because we need to focus on where our resources are needed the most first, and then broaden the scope.

Since that was written, the Thunderbird team has expressed interest in using the SUMO infrastructure to build a similar support site. What this means is that SUMO is not the equivalent of Firefox Support — SUMO really stands for Open Source Support.

How can we make the SUMO community stronger?

Let’s get back to the vision for SUMO. What can we do to strengthen and ignite our already amazing community? Well, an obvious answer would be to just ask the community members, and we’ve obviously done that a lot over the year. I’ve also talked to people at Mozilla closely involved with community building in other projects, to get their feedback. Based on that, we have some ideas to start with:

Understanding the bigger picture

I’ve already covered this in part two of this blog series, but this is definitely very related to building our community. To summarize:

  • Work together – Closer collaboration with QA and developers to get a shared understanding of our users.
  • Get everyone on the same page – Clear escalation paths for emerging issues that should be handled by other areas of the Mozilla project.

Karma

An online moderation/rating system –- also known as “karma” –- is important for a couple of reasons. First of all, it’s a way to encourage participation and allow contributors to really take pride in their work. How many users have you helped using Live Chat? How many have you helped in the Support Forum?

The other interesting thing a karma system would give us is better knowledge about which contributors are our most valuable. This is very useful information when e.g. surveying contributors about how we can improve the site — before making changes to the Knowledge Base article editor, which contributors have the most experience using it?

Showing more gratitude

What impact does a person writing a Knowledge Base article for SUMO make for fellow Firefox users around the world? The answer is, without a doubt, more than most people think. How can we make that clearer? Some things I’d love to see:

  • Make the community more personal – Allow contributors to have a personalized profile with info such as full name, location, photo, and description. Make the people behind SUMO more than just a username.
  • Show a photo of each contributor at the bottom of each Knowledge Base article under “Contributors to this article” — if they want to show their picture, that is. Make it more obvious to our readers that the content is written by people just like them!
  • Add a plain and simple thank you note where appropriate, for example under “Contributors to this article” at the end of each Knowledge Base article.

A thank you note might seem trivial, but it really highlights some of the fundamental elements of a community: helpfulness, friendliness, and appreciation of each other. We’re not like any typical corporate support division. The motivator here isn’t money — it’s gratitude, appreciation, recognition, and a feeling of belonging to the community that motivate people to make a difference by helping people with Firefox.

SUMO is all about that.