Hello, SUMO community members!
If you contribute to the Knowledge Base in SUMO, please read this blog post carefully as we explain how others can request content from the SUMO team.
Historically, we didn’t have a structured workflow for content requests, relying on personal engagement or public groups to act reactively. With a larger content team, establishing a proper workflow is essential for task distribution and transparency within the team.
In general, the content intake workflow can be summarized in 4 steps:
Step 1: Submitting a content request
The process begins with submitting a content request through a Bugzilla form. Typically, feature/product owners make these requests, but anyone with ideas for improving support content can submit, including contributors. Documenting requirements helps us act appropriately.
This is a crucial step, and we require each field in the form to be filled out. Each piece of information helps us determine the necessary steps moving forward. All internal teams must use the Bugzilla form for SUMO content requests, whether for new articles or updates. Exceptions are for minor fixes, which can be submitted directly in the KB article. To learn more about what we consider as minor fixes, please see this.
Step 2: Determining content access restrictions
After submission, the workflow diverges based on the content access restriction chosen:
- Non-confidential: All bugs and drafts within these requests are visible to anyone with a link and can receive comments and suggestions, benefiting from community contributions.
- Confidential: These bugs are restricted and will be handled internally by staff members, due to sensitive information, such as upcoming features yet to be publicly announced, or information related to partnerships or other business strategies.
Step 3: Content creation
Once the necessary information is provided, the content team assigns the bug to a responsible person. This usually involves creating a draft in Google Docs before publishing it as a revision. The content team also creates in-product links if needed. Areas of responsibility for SUMO technical writers are:
- Lucas: Firefox (desktop, Android, and iOS)
- Dayani: Privacy & Security products, Pocket, Firefox Accounts
Step 4: Publishing & resolution
Once the content draft is ready and approved by all parties, the person responsible for it can submit it as a new revision.
How contributors can help
Contributors remain essential to the article creation process. With this update, we’re aiming to make sure that the contribution workflow is integrated and aligned with our internal workflow.
For non-confidential content requests, contributors are encouraged to get involved. And here’s how you can help:
- Identify a content request: Keep an eye on new content request bugs. When you find one you’re interested in, please directly comment on the bug to notify the content team that you want to help out with the request. If you’d like to get notifications on new content requests, consider watching the Knowledge Base Content component on Bugzilla. To do this, go to your Bugzilla profile → Edit Profile & Preferences → Component Watching. Choose support.mozilla.org on the product selection and select Knowledge Base Content for the Component field. And don’t forget to click on the Add button to save your changes.
- Get assigned: Wait for the content team to assign the ticket before starting. Please do not work on the actual content creation before the content team assigns the ticket to you.
- Content creation:
- Review the ticket: Make sure to review the ticket thoroughly and understand the request. Also, ensure you can complete the work by the due date for publication. If anything changes, and you can’t finish the content on time, let the content team know as soon as possible.
- Create a draft: Use Google Docs to start working on the draft. If it’s not possible, you can also share the content file as an attachment in Bugzilla for others to review.
- Get Feedback:
- Share the draft: Post the link to your draft in the Bugzilla ticket for review.
- Open for comments: Ensure that the Google Docs settings allow for comments.
- Work with the requester: Collaborate closely with the requester to cover all points in the article. If any information you need to complete the work is missing, don’t hesitate to reach out to the requester directly for additional details.
- Final review: Once the draft is finalized and approved by all parties, including the requester, you can submit the content as a new revision on the actual Knowledge Base article. Once the KB revision is submitted, please also assign the ticket back to the technical writer responsible for the product.
- Publication: The technical writer will review and publish the content.
If you have questions about this update, please submit your comments in this contributor discussion thread!