Hey there, fellow helpful Mozillians :-)
Last week, three of the support.mozilla.org administrators and coordinators (Rachel, Madalina, Michał) met in Berlin to talk about our status and plans for 2018. We would like to share some of the most important points and decisions taken after five days of talks and invite you to ask questions or voice your opinions about the state & trajectory of Mozilla’s Support.
To set your expectations before you dig in – we are going to talk about many of the points made below during our upcoming All Hands, so outlining detailed and complete plans at this stage does not make sense, as after next week there could be many more factors “on the table” to consider and include in our 2018 planning. What you see on this page is rather a general outline of where we see Mozilla’s community (when talking about user support) in 2018.
That said, if you have any questions about the content of this post, please use the Discourse thread if you have something to share regarding the contents of this post.
We’re done with the introduction… Let’s dig into it!
The main focus of the agenda was community, and the organization of the discussion was (more or less) as follows:
- Current state of the community and challenges we face
- Tools and resources at our disposal
- Teams and people to talk to
- Defining “community”
- Community goals for different aspects of Support
- Defining “community health”
- Community building
- Delegating / sharing tasks & responsibilities with contributors
- Reporting
- Events
- Contributor paths
- Reviewing the Firefox Quantum release
- Goals for 2018
Let’s start at the end, shall we? ;-) Our main goals for 2018, in no particular order, are to be able to say that we:
- …have a way to segment contributors and identify personal profiles that will help us make strategic decisions. We want to have a better idea about who the people in our community are.
- One of the ways we want to try to achieve this is conducting research with the help of Open Innovation/Participation and setting up a survey for new contributors.
- …can cooperate with and within a self-sufficient community or a set of self-sufficient communities.
- This relies a lot on the progress and decisions made by the steering group for the non-coding Mozillians project.
- …have identified and implemented metrics that are accessible and relevant to both other project teams at Mozilla and to anyone outside Mozilla.
- Talking to people about the numbers they need and crunching numbers is the name of the game here.
- …have identified community management tasks that we (as admins) cannot completely take care of and the people who can help us with that. Also, have successfully delegated some (all?) of such tasks to people interested in getting involved at a higher level.
- We are working on a team list of tasks and we hope to share it with you soon enough. If you’re interested in this part already, let us know through the usual channels.
- …have identified neighbouring expert networks that contribute help us fulfil all the needs of our contributors and users.
- This means investigating internal and external networks of specialists and experts in areas that enable support. We want to have more smart people out there working with us on making it better for everyone.
- …have identified and cleaned up all existing legacy content regarding user support at Mozilla.
- Expect some centralisation and purging of content across several places. We keep producing too much noise and not enough signal in some areas of our activity as administrators – and we need to clear up our act in order to make it easier for Mozillians old and new to find their way.
- …have participated (together with contributors) in at least one large (and impactful) event every quarter (on average), representing Mozilla and our support efforts.
- Mozilla’s support was presented at different events in the past, with varied degree of success. We want to take this up a notch and involve you, whenever it makes logistical sense.
- …have permeated the community with a “one Mozilla” attitude.
- Break all the silos! Once again, a lot here depends on where we see ourselves in the non-coding Mozillians project.
We have also identified several “big” issues that have an impact on our part of the project that we want to provide solutions (or a way forward) for – not necessarily before the next year ends. Here are the key ones:
- Kitsune is an old (if reliable) platform and it is unlikely we will be able to recruit full-time developers to fully support and develop it in the near future. We need to address this in order to provide continuous support options for users and a platform for contribution for Mozillians.
- keywords: community developers, community dashboards, Discourse, Pontoon
- We do not have enough resources to run a staff only support model. We want to have a self-sufficient community that can function with minimum admin help in order to grow and scale beyond our current numbers, while keeping users supported and contributors engaged.
- keywords: research, survey, community health, non-coding Mozillians
- Due to our team’s size limitations, we need to adopt a global approach to building and maintaining relationships with Mozillians supporting our users, based on the expertise and resources from teams we have historically not been continuously collaborating with.
- keywords: non-coding Mozillians, one Mozilla, Community Participation Guidelines,
- Administrators cannot focus on community needs and projects as much as they should, as our main focus is (and will be) user support. Because of that, we will almost always prioritize user support tasks before community management and that will have a negative impact on our community relationships.
- keywords: Bugzilla reports, escalations, task delegation
- We need to improve our communication channels within and outside of Mozilla to avoid bottlenecks and delays in daily and emergency situations.
- keywords: universal “who is who”, more meet & greet, communication procedures
- We do not have enough participation in online discussions from all contributors – the forums feel dominated by a few voices. We need to encourage participation in community building through discussion and avoiding bias.
- keywords: anonymous team persona, Discourse
- We need a central, scalable, and transparent way to track and engage contributors for each release across the functional areas.
- keywords: release newsletter, readiness check-in, active contributor list, task delegation
- We do not feel fully aligned with other Mozilla project teams, especially those that could be directly relying on our performance.
- keywords: conversations, metrics, expectations, reporting, positioning
Once again – if any of the above sounds terribly cryptic, the Discourse discussion is your best place to ask for clarification.
Finally, we also discussed the Firefox Quantum release from the support perspective, and here are the observations we want to share with you:
“The good”:
- We have 12 Mozilla staff members active in social support!
- We had good communication channels with Product, Marketing & other teams involved in the release – no bottlenecks or confusion, no feeling of “going solo” through it.
- We had great community participation, especially in the first days after the release. The number of contributions grew exponentially with the number of incoming user questions.
- Our legacy platform performed well, despite the huge increase in traffic.
- Several new contributors appeared, helped out, and remained very active.
- The volume was our main challenge; we had no unexpected emergency or reasons to panic – preparation was key here.
“Could have been better”:
- Contribution levels matched incoming user traffic – when incoming user traffic dropped, you could see contributions dropping as well. We’d love to keep contributors engaged for longer.
- The forum structure encouraged multiple contributor replies to questions that have already been replied to. This could be more streamlined in order to improve coverage and decrease frustration.
- Fringe top 20 (and beyond) locales in some cases did not rally for Quantum (this is a long-standing issue that requires addressing outside of just the support project).
- We did not have a clear process for managing internal requests, so some team members faced disproportionate workloads and communication overload – we want to address this through smart delegation of tasks for the next release. It was also a challenge to deliver all the data or feedback requested in a timely manner. If we have a defined release requirement list before the next release, we can deliver the requested data more consistently.
- It was not always easy to clearly understand what was the best solution for a popular issue and address user feedback or set best practices for community contributors to follow (e.g. with chrome.css edits). A point of contact in the Product team or Marketing who could offer a final decision or solution for issues is a necessity – we can’t ignore tough questions only if we lack clear answers; we can’t have clear answers without a confirmation from subject matter experts.
- We noticed cases of people being on PTO/AFK, who were still working during that period – this should not be happening for obvious reasons – “on call” work has legal/work implications.
- Emergency internal messaging during the release period was not organized enough and may have caused additional confusion or tension within and around the team.
“Still an issue”:
- Following up on reported bugs – we could do better through having a clear hand-off procedure with clear expectations from the team we file bug against. We can’t let open bugs stew longer than necessary (e.g. as with a malware issue during previous releases). A clear process with the Product team in which we push for an answer or resolution that can later be taken back to people affected and contributors is definitely necessary. It is still better for us to hear “I don’t know” or “This is not a priority at this moment” from the right people, than to hear nothing and second-guess what is going to happen or what the best response could be.
A final reminder here: use the Discourse thread to discuss any of the above and let us know there if you need any more information. We are happy to provide as much of it as we have at this moment.
(And if you think that this summary is a lot to digest, imagine how many pages of notes we produced over five days…) (Probably more than you’d like to read ;D)
Thank you for getting through this post all the way to the bottom… and thank you for being there for other Mozillians and users around the world! You make Mozilla happen! Keep rocking the helpful web :-)
P.S. On a slightly less serious note, Madalina tried to keep us in Berlin a bit longer, using an escape room as an excuse… but we have successfully escaped thanks to concerted team work!