SUMO community discussions
Hi folks,
We just posted a new blog post to explain our content intake workflow. Please take time to read it carefully and share your feedback here.
Thanks, y'all!
When you go to enter a new SUMO KB content bug at https://bugzilla.mozilla.org/enter_bug.cgi?product=support.mozilla.org&component=Knowledge%20Base%20Content the Description section is a lengthy form to fill out, that starts with this: (quote) ## Did you check out the steps and FAQs for submitting requests to the CX content team? (yes or no)? [REQUIRED] **Note: Learn more at https://mozilla-hub.atlassian.net/wiki/spaces/MSS/pages/21430745/Mozilla+Support+Content **
The Learn more link takes you to a login page. I tried to log in with Google, which didn't work. I don't have a Slack account and didn't try the Microsoft or Apple sign-ins. I also tried create an account, and verified my email address, with the same result, a message that I don't have access to Confluence on mozilla-hub.atlassian.net.
Can the "Learn more" link go to a SUMO page or other site available to everyone? I asked about this before in a previous discussion thread that Abby posted almost a year ago, here: https://support.mozilla.org/en-US/forums/contributors/716518#post-86103 Updates to KB content request form in Bugzilla
Links to Atlassian services are closed to staff (and possibly a very small number of contributors with staff equivalent access) only. But I do agree that the "learn more" should be open, either to Kitsune or the Mozilla Wiki.
A couple of questions:
Is there any update on this?
Hi Paul & Alice,
The Learn More page leads to a site we use for internal documentation for internal stakeholders. Because the audience for this form and this page are our internal stakeholders, we want to make sure our form, process, and information about SUMO KB content is discoverable for those staff members that may not even be aware of SUMO. Internally, posting information on Confluence/Atlassian pages is a company best practice.
I understand having this information also visible on SUMO might be helpful. I'll take an action item to find a place within the Contributor KB we can include this info. Here are screenshots of the page so you can get an idea of what's included - it shouldn't include any surprises or anything contributors aren't already aware of.
Paul - in response to your questions:
1. What stops a SUMO contributor from trying to do all the bugs? Technically there is nothing stopping this, but Lucas monitors the queue weekly. If you have specific concerns about this, please let us know. 2. What stops staff treating all requests as confidential? Again, technically there is nothing in place to prevent this, but Lucas is constantly triaging any tickets that come in and will make any adjustments as needed (either to mark as confidential or unmark as confidential, for example).
I hope this is helpful but please let me know if you have any follow-up questions.
Abby said
Hi Paul & Alice, The Learn More page leads to a site we use for internal documentation for internal stakeholders. Because the audience for this form and this page are our internal stakeholders, we want to make sure our form, process, and information about SUMO KB content is discoverable for those staff members that may not even be aware of SUMO. Internally, posting information on Confluence/Atlassian pages is a company best practice. I understand having this information also visible on SUMO might be helpful. I'll take an action item to find a place within the Contributor KB we can include this info. <snip>
Hi, Abby. The new article you created, How to submit a SUMO Knowledge Base content request is still pending approval. See https://support.mozilla.org/en-US/kb/submit-sumo-knowledge-base-content-request/history (Maybe Kiki or another Staff member can approve it?)
AliceWyman said
Hi, Abby. The new article you created, How to submit a SUMO Knowledge Base content request is still pending approval. See https://support.mozilla.org/en-US/kb/submit-sumo-knowledge-base-content-request/history (Maybe Kiki or another Staff member can approve it?)
So sorry about that. The article should be live by now.
Modified by Kiki on
Please can we include the contributor part of the process in that article - currently that element is documented in a blog.
Paul said
Please can we include the contributor part of the process in that article - currently that element is documented in a blog.
I added a FAQ titled How can contributors help with content requests? with a link to the Mozilla Support blog that's pending review. See https://support.mozilla.org/en-US/kb/submit-sumo-knowledge-base-content-request/revision/286227
Would be good to get that content out of the blog and into the KB.
Paul said
Would be good to get that content out of the blog and into the KB.
I agree. This came up in a bugzilla comment where Kiki linked here to the blog for contributor instructions.
SUMO staff should update the How to submit a SUMO Knowledge Base content request article FAQ section, How can contributors help with content requests? (which links to the blog content) and either incorporate the content into the KB article or else create a new article to replace the linked blog content. Besides the fact that the blog content should be part of the Contributor KB, the blog is outdated; for example, the Step 3: Content creation part of the blog still mentions Lucas (who is no longer part of SUMO) as the technical writer responsible for Firefox (desktop, Android, and iOS) content. .
The entire process needs to be re-written. Large parts of it are far more complex than they need to be if not for contributors then for staff requesting edits.
Paul said
The entire process needs to be re-written. Large parts of it are far more complex than they need to be if not for contributors then for staff requesting edits.
You seem to have a good idea of the process from the contributor viewpoint, in that you get many bugs for new or updated KB content assigned to you. Can suggest how to simplify the process for contributors, either in this thread or in a proposed new Contributor process for new or updated KB content requests article?
P.S. One way the process for contributors can be simplified is to eliminate a google doc draft and, instead, use the pending KB article content when an article revision is submitted. This could also apply to SUMO staff. The only situation when a draft might be needed is for new articles, since only the article creator and those with permission to review KB articles can view the KB article content before it is approved.
Modified by AliceWyman on
SUMO KB content staff has made major changes to existing KB articles without going through the process described in the How to submit a SUMO Knowledge Base content request article (filing a bug report, creating a google doc draft, etc.) as evidenced in the recent KB Content Audit, as outlined here.
Contributors also propose changes to KB articles that are more than minor updates without filing a bug report, by simply submitting a pending KB revision that will then be reviewed. For example, see the history of the "Firefox is already running but is not responding" error - How to fix article, approved by Kiki as a major update. The process described in the How to submit a SUMO Knowledge Base content request article and linked blog should explain when a bugzilla request is necessary and when it isn't.
Modified by AliceWyman on
AliceWyman said
<snip>The process described in the How to submit a SUMO Knowledge Base content request article and linked blog should explain when a bugzilla request is necessary and when it isn't.
I think that a bugzilla request and subsequent google doc/other draft should only be required when someone requests a new KB article or article update for the SUMO KB Content team to work on, that they aren't going to submit themselves. It shouldn't be needed when a SUMO contributor or SUMO staff member submits a revision to an existing KB article that will be reviewed by a second party, as outlined in Article review guidelines for KB reviewers.
Whether or not a bugzilla request is needed for a new article proposed by SUMO staff or by a volunteer contributor is another matter but I see no reason why a SUMO contributor or staff new article request and discussion can't occur in the Knowledge Base discussion forum here rather then bugzilla.
P.S. The How to submit a SUMO Knowledge Base content request article and linked blog doesn't mention Thunderbird. Step 3: Content creation of the blog says... Areas of responsibility for SUMO technical writers are:
Are Thunderbird KB articles excluded from the process?
Modified by AliceWyman on
Can staff review the above feedback and suggestions?
See also this recent post by Kiki.... written on March 5, 2026
Separately, we've also been collaborating with the content team on updating the current KB documentation to make things clearer with our KB request workflow. We understand tat many of our current documentations are outdated and we want to make sure that we leave no grey area that caused a lot of confusion. I also want to emphasize that community contribution on the Knowledge Base remain important, including active participation from contributors with KB reviewer permission. We'll announce how we want to improve our collaboration with the KB reviewers along with the documentation update once everything is finalized. Thank you for your patience while we're working on this.
