Starting today we will be beta testing the new groups and private messaging features of Kitsune. We want to start with a small number of people for now, so we are going to cap this at about ten. We will have a test day for everyone on July 8th. If you are interested in testing private messaging and giving feedback on it, please let me know in this thread on the support community forum and I’ll activate it for you.

If you are a localizer, you can also request the group dashboard feature. This will add another tab to your dashboard and those of your team members. That tab will hold your localization dashboard and a message on top that you as the locale leader can change to message your team. Also, your localization group will get a profile page listing the locale leader and every member of the team.

You can see here what the German localization group profile looks like.

For the groups dashboard I wrote a short tutorial that you can see here.

Private messaging should be fairly intuitive. Once the feature is activated, just click on “Inbox” on the upper right corner of the page. Make sure that you only message people who are listed in the forum thread for now.

Please report any issues that you encounter on this etherpad so we can fix them quickly.

And of course, please let me know if you have any questions.

Thanks!
Kadir

SUMO 2.4 moved the last bits of functionality into Kitsune, our Django-based platform. These include user features like login/logout, registration, and profiles.

This represents a significant milestone and success for the SUMO project, and is particularly meaningful to the development team. We’ve been working toward this since January 2010, and seeing it completed is an amazing feeling.

Over the past year we’ve progressively replaced pieces of our old platform with new code:

• In May, we took our first step by transitioning to new Search Result Pages.
• In July, we switched the Discussion Forums, and started authenticating users in both systems.
• In August, we turned on the new Support Forum section.
• In September, we added the new Army of Awesome, built very rapidly on the new platform.
• Just recently, in November, we brought the new Knowledge Base, the largest, and most complex part of SUMO, online.
• And with 2.4, we’ve brought over the last piece, User Accounts.

This final step in the migration to Kitsune opens up a bunch of new doors for features and improvements. For example, user registration is much simpler now. We’re transitioning data internally to be more secure. The entire site is faster and puts a lot less load on our servers, meaning we can serve more traffic with the same hardware.

We are especially happy we were able to complete this transition before the Firefox 4 release. Being entirely on the new platform gives us more confidence in our ability to keep helping users even with traffic spikes from the release.

We devoted 2010 to investing in this new platform, designed specifically to make it easier for our awesome community to help 400 million Firefox users worldwide. In 2011, we’ll start seeing the payoff of that investment, for our developers, contributors, and users, and expect to see SUMO really take off!

There are so many exciting parts to the new Knowledge Base that it’s hard to know what to talk about first. The biggest improvement was also the most requested – speed. With our old KB it was often hard to find out why pages timed out and even harder to actually do anything about it. With the new system we know every detail and can tweak the performance, move things around and make sure that users will see a page in an instant. As has been shown time and time again, speed is the ultimate measure of usefulness. Even a 3 second response time will often lead to users leaving the site or being unsatisfied with the interaction no matter how good the content. So we’ve focused heavily on this.

The latest numbers we have show a huge improvement in response times – to be precise, a 28-fold increase in handled requests per second! That’s incredible indeed. The best part is that it will make the KB more useful for users as well as contributors. Gone are the days of timed out dashboards and slow loading pages.

What you can do!

Of course speed is not the only improvement with this new system. Over the next few weeks leading up to the release, we will write more about specific new features and improvements. But you don’t have to wait for the November 30th release to see for yourself. Take a look at the work-in-progress on our staging server.

If you are interested, help us make it as bug free as possible by joining us for a QA day on November 12th. From 8am to 5pm PST we’ll gather in #sumo on IRC to make sure the KB is ready for the release. We’d love to see you there!

The forums we moved over are

• Contributors
• Off Topic
• Knowledge Base Articles

We did not move the Firefox support forum: that is coming in our next major milestone. These discussion forums join search results as the second component of the site to move over to the new platform.

The new discussion forums are very similar to the old discussion forums. We tried to keep big changes to a minimum. If you see something that doesn’t seem like it’s working right, let us know in the comments here, or in the Contributors’ forum.

The first mockup shows how the questions and replies themselves will look. As you can see, users are now given the option to vote that they have a certain problem as well as vote on whether replies are helpful. To make sure that useful replies don’t get lost after other posts, they’re being summarized below the question. We’ve also moved stuff like System information to the sidebar, adding in tags and related questions to help improve navigation between forum questions. This way, if you’re looking for help with something, you can easily find similar threads if the one you’re looking at doesn’t help. Also, if you’re answering this thread, you may find that you also know the answer to a related question.

We’ll also color certain replies differently: The chosen solution is highlighted in green, posts by the original question-asker are blue and other threads are white.

The second mockup shows how the thread listing will look. To make it easier to browse the forum and find questions you can help with, we’ve added tags, the number of “I have this problem” votes and most importantly a short summary to this view. You’re also shown if you’ve contributed to the thread already and what its status is. We’ve kept the filter buttons at the top, letting you view common views (most recent, solved only etc).

Chris Howse has made many more detailed mockups showing various views and button states. You can check them all out in the following two bugs:

• Mockups for the individual question view
• Mockups for the thread listing view

We hope you enjoyed this view into the future of the forums. What do you think? We’ll give another update as more development happens, so stay tuned.

So what comes first and when does it happen?

• SUMO 2.0 – Search results: April 2010.
• SUMO 2.1 – Contributors forum and the Off-topic forum: May 2010.
  These are general discussion forums, and the goal is to move off of TikiWiki code while retaining functionality.
• SUMO 2.2 – Support forum: June 2010.
  The Support forum has many features specifically designed for providing software support and is coded separately. Part of this goal is to redesign the support forum to make it easier for users to find answers without cluttering the forum with “me too” posts. Another part is to make it easier for community members to get involved and become contributors. If you are a regular reader of this blog, you know that the work has already begun on the redesign. For more information, see the PRD, and the previous blog posts.
• SUMO 2.3 – Wiki: Summer and Autumn 2010.
  The wiki is what is used for the Knowledge Base, and other documentation (including localization). This is the most complex component and therefore we expect it to require the most time. We’ll also be taking this opportunity to redesign the KB as well, So for the next three months we will start working with the community to draft the details. More information about that process will be posted soon.
• SUMO 2.4 – User management: Winter 2010.
  This last component covers items like login, log out, and preferences. For technical reasons, all other components need be done before this can be transitioned.

Once that last user management piece is in place, we will be fully transitioned to Kitsune. Any bugs found in the new code will likely need to wait (unless they’re severe) until the entire transition is finished before being addressed.

Since development resources are limited and a project like this requires that we scrutinize our priorities, we’d like to make it clear that we will devote as much time as possible to Kitsune development. As a result, any work on the previous (Tiki) code will strictly be for maintenance purposes: unless a bug in the previous code simply must be fixed as soon as possible, it will likely not be worked on.

We will be making some changes to the SUMO milestones:

• The SUMO 1.6 milestone is going be canceled. Any current 1.6 bugs will be moved to “Future”, but we will go through that list of bugs to make sure urgent bugs are fixed soon.
• Any future maintenance releases to the current code will be updates to SUMO 1.5.x (1.5.3, 1.5.4, etc.).
• All new Kitsune work is being targeted for SUMO 2.0 and newer versions.

This is going to require some patience from all of us who are waiting for a certain feature or a minor bug to be fixed. Most, if not all of those concerns can be fixed in Kitsune, and the sooner we switch to it, the sooner we will have a much faster and more reliable support platform.

We will blog more about the roadmap for Kitsune soon.

• There are no longer two distinct areas for discussion vs solutions. Instead there is a chronological order of posts. (Like a traditional forum.)
• The most useful post in a thread will be highlighted rather than shifted to the top to prevent breaking up discussions.
• Posts by the original thread author will also be highlighted.

You can see these in the mockup below:

Here’s the rationale for these changes: When we looked at a sampling of solved threads, we found that the vast majority (30-to-1) were solved in one or two replies. This seemed to suggest that the benefit of bubbling up the top solutions was small since there weren’t many solutions for forum users to sort through. On the other hand, a chronological ordering would simplify the user interface and may promote discussion and community building between contributors.

Please give us your feedback on this design/mockup. What additional features would you like to see, what would you like to see done differently?

The mockup also shows a three-tiered voting system for posts with “this was helpful”, “this was helpful but didn’t fix my problem” and “this wasn’t helpful”. Please let us know what you think of it.

A number of websites that have been set up specifically with the goal of answering questions actually don’t use the traditional forum format.  For example, Yahoo! Answers, Get Satisfaction and Stack Overflow all use a more problem-solution based approach. We’d like to take cues and ideas from these sites and redesign the way users and contributors interact on our support forums to make it more fun and engaging to help users.

We’ve started to draft up how this redesigned support forum would look and would like your input on how to make the final support forum best fit your needs as contributors as well as those of our users. Note that we are talking about the English Support forum on SUMO here — it will not apply to the Contributors or Off-topic forums, which have different needs.

Our proposal
The key objectives of this redesign are:

• To make it easier for users to identify the solution to their problem.
• To make it easier for contributors to focus on the questions that matter to them — for example, only questions asked by Linux users.
• To make the forum much faster and more enjoyable to use.

The key element to the new design will be the ability for a user to vote up (or “me too”) threads which adds him to the notification list.  If a user sees a problem description that matches his own, he can vote it up, thereby giving it more attention and increasing the chances of good solutions.  We can then make sure that these questions are shown more prominently in the thread listing.

Answers to questions can also be voted on — not just by the original asker, but by everyone.  That way, the best solution for the majority of people will bubble up to the top.

Lastly, we want to provide an area of the page to get followup information from the original person with the question.  Asking for more information is a key part of the troubleshooting process, but it’s important that the information is readily available near the original question, and not buried somewhere in a lengthy discussion thread.

We’ve put together a rough mockup of how this may look to give you a better sense of what these mean.  Once we’ve finalized on the list of features, we’ll be redrafting it to actually look good, too.

What do you think?  What kinds of features do you think are necessary in this kind of new support system?  We’ve got ideas like tagging, custom dashboards, as well as savable views.  However, we’d love to hear your thoughts and ideas to make sure we aren’t missing something here.

So, if you have feedback, please let us know.  You can edit the PRD or just comment in this blog.  Thanks!

When I joined the SUMO team six months ago, the team was just starting a discussion of “where do we go from here?”  SUMO was built on a CMS called TikiWiki, and had diverged pretty significantly in two years. (David Tenser wrote a more detailed history if you’re interested.)

After a few months of talking and testing—and a few changes of direction—we’ve decided that SUMO will follow our colleagues on AMO and move to a custom web application, built on Django, a development framework in Python.

Why are we committing to such a dramatic new direction? Three major reasons. Keep in mind that SUMO was built on TikiWiki 1.10, a little more than two years out of date.

Performance

TikiWiki is a very feature-rich application. An unfortunate trade-off for us is performance, especially on a site serving 16 million users every week. As our European users in particular know, SUMO can be unacceptably slow at times, especially when editing articles. Many of the changes we made to the platform—most of which were contributed back over the past few months—were to improve performance via tools like output caching, database replication, and just refactoring. When we evaluated the latest version of TikiWiki, we found that performance was around the same, on average.

In the new platform, we’ll be taking advantage of techniques now available, including query and template/fragment caching and expect to see dramatic performance improvements. We’ll also be avoiding some of the performance pitfalls that TikiWiki fell into over the years with improvements to the security, database, and templating layers, among others.

But the biggest performance impact—I expect—will be moving from a general-purpose CMS to a dedicated web application, focused on providing the SUMO experience.

Hackability

To work on SUMO, you have to overcome a steep learning curve. Components tend to be tightly-coupled, or grouped in unintuitive ways, and are not as extensible as we’d like. The lack of a comprehensive test suite leaves changes to important sections of code open to introducing regressions in otherwise unrelated, dependent areas. SUMO 1.x also fails to function without a relatively complete copy of its database, which makes it difficult for community members outside the company to contribute.

With the new platform, and some discipline from the team, our goal is to improve all of these and make it easier for someone to get started hacking on SUMO.

• We’ll be striving to keep code loosely-coupled and extensible—including using existing or external libraries whenever possible, and turning our own contributions into external libraries where possible.
• We’re adopting a test-driven development workflow to ensure that our components are easier to safely hack, and lighten the load on our QA team by reducing regressions.
• TDD and Django will make it easier to work without a copy of the database, using fixtures and migrations to minimize the dependence on real data.

The net effect of these decisions will be to lower the barrier to entry to SUMO development, and hopefully make useful code available to other projects. Wil Clouser listed more strengths of Django as a platform when the AMO team decided to switch.

Strength in Numbers

By using the same platform as AMO, both teams will benefit from sharing code and resources. We’re already using the same template adapter, database router, caching layer, and HTML sanitizer. As open source developers often say: “with enough eyes, all bugs are shallow,” and by sharing code we get more eyes on it. We’ll benefit from insights the AMO team has gleaned by starting the process of moving from a PHP framework to Python just ahead of us. We’ll even be able to send code reviews across teams and benefit from deeper knowledge of the various problem domains we share: have a question about localization? Both teams can share expertise and best-practices.

Solving problems once and sharing the solution directly reduces the amount of work both teams have to do. And when SUMO writes code in such a way that AMO can use it, we can also release it separately so others can benefit from our solutions—and point out flaws and contribute improvements.

Other Changes

Also among the changes coming in the next year:

• Version Control System. Though we don’t have a specific plan in place, it seems likely that SUMO will be moving from SVN to Git for source control. Because Git is distributed, it allows us to use a more collaborative workflow, and it’s easier for us to push our code to public repositories like Github.
• Continuous Integration. We’ll be using Hudson for continuous integration, which will automate our tests and alert us to potential issues and regressions. The web QA team has also been working to make sure our Selenium tests can run through Hudson, greatly increasing test coverage for a web application like SUMO.
• Interface Localization. One of the ways we plan to improve the SUMO experience this year is by moving our interface localization to gettext, which is an industry-standard tool for localization. As we move parts of the site from TikiWiki to Django, those new sections will be localized via gettext, which helps us take advantage of our great community with tools like Verbatim.

A Foundation for the Future

The goal of all of this work—and it will be a lot of work—is to put SUMO on a solid foundation for future growth and, at the same time, improve the experience for everyone—from developers to contributors to localizers to visitors. We have a daunting and aggressive road ahead of us, but I’m confident that we’ll emerge in a better place.

SUMO 2 is codenamed Kitsune, and is already up on Github.

Comments or questions? Head on over to James’ original blog post and comment there!