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 support.mozilla.org’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 WordPress.org, Arduino, and Kaggle.
WordPress.org
In general, when compared to our Support community, WordPress.org’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/Wordpress.com 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
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
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.
Methods:
- 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
Methods:
- 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
Methods:
- 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!