Mozilla’s Knowledge Base remains open for everyone who wants to contribute. Anyone can submit a minor revision to correct or update our support articles without needing special permissions.

This document describes the workflow for new content requests and major updates that are coordinated through Bugzilla. These requests follow a different process because they often require collaboration with product teams and other stakeholders.

If you're unsure which workflow applies to your change, please see the Rule of thumb section below or check out Minor vs major changes to understand which category your proposed change falls into.

Why Bugzilla?

We use Bugzilla to coordinate discussions around new content requests and major updates because this process often involves multiple stakeholders.

Using a single collaboration space helps ensure that conversations remain transparent and accessible to everyone involved. We intentionally use Bugzilla instead of Knowledge Base article discussions because many of our product stakeholders already work in Bugzilla as part of their normal workflow, while comparatively few are familiar with the Knowledge Base discussion system.

Bugzilla also provides clear task ownership and progress tracking. Since content creation is a collaborative effort between Mozilla staff and community contributors, it's important that everyone can easily see who is responsible for a request, what decisions have been made, and what work remains. This helps avoid duplicate effort, reduces confusion, and makes it easier to keep release-related documentation on schedule.

Rule of thumb

As a general rule, you can ask yourself the following question:

Does this change require input or validation from the product team?

• If yes, create or work through a Bugzilla ticket so the appropriate stakeholders can participate in the discussion.
• If not, you're generally free to submit the change directly as a minor Knowledge Base update.

In other words, if your proposed change doesn't require product stakeholder involvement and falls within the scope of a minor revision, there's no need to go through Bugzilla.

Why this process exists

This process is intended to support community contributions. It helps us:

• Protect release timelines
• Clarify ownership and accountability
• Preserve healthy collaboration
• Avoid friction caused by unclear expectations

We deeply value contributor expertise. Long-standing product knowledge within the community is incredibly valuable. At the same time, content work tied to product releases and cross-functional collaboration requires clear ownership, predictable timelines, and structured coordination so that we can ensure the timely delivery of accurate and helpful content to support Mozilla’s global user base.

Workflow for content requests through Bugzilla

The following process applies to new content requests and major updates submitted via Bugzilla.

Content requests generally fall into two categories:

• On-train requests: Content tied to a scheduled Firefox release. These requests are time-sensitive and must follow the release schedule.
• Off-train requests: Content that isn't tied to a scheduled Firefox release. These requests may still have a target deadline, but generally allow more flexibility.

For a full preview, please open the image in a new tab.

1. Submission

All major content updates must be submitted via a Bugzilla ticket.

2. Triage and assignment

Triage: All new content requests go through a triage process to determine priority and assignment. Triage happens on a weekly basis on Thursday.

Content requests that are open to contributors will be marked with the sumo-contributors keyword in Bugzilla. If you’re interested in helping out with one of these requests, feel free to express your interest by commenting directly on the Bugzilla ticket.

Assignment: A CX staff member will assign the bug to either a contributor or Technical Writer. Once assigned, the Community Manager or other CX team member will guide you through the process. Please do not start drafting until a CX staff member confirms your assignment.

Time expectation: Triage is conducted on a weekly basis, and contributors can expect a response to their assignment request within five business days.

• On-train requests: Assignment for on-train requests is time-sensitive. If a release-related request is open to contributors but remains unassigned after the next triage cycle (5 working days), the CX team may assign it to a Technical Writer to ensure the release schedule isn't delayed.

• Off-train requests: Off-train requests generally allow more flexibility and may remain available for contributor assignment for longer, depending on the requested deadline.

3. Content creation

Content draft: Carefully review the ticket to understand the request, scope, target release or deadline, and expected outcome before beginning your work.

Once the bug is assigned to you, you may start creating the content. If a draft is provided by the product team, use it as a starting point. Otherwise, you may begin drafting the content in Google Docs. If Google Docs isn’t an option, you may attach your draft directly to the Bugzilla ticket for review.

Be sure to post the link to your draft in the Bugzilla ticket and set the document permissions to allow stakeholders to comment.

Content approval: Collaborate closely with the requester or product stakeholders to ensure that the article is complete and accurate. If any information you need to complete the work is missing, use the “Request information from…” option in Bugzilla to gather additional details.

You may check the last line of the Bugzilla form description to see if a formal approver has been identified for the draft.

Time expectation:

• On-train requests: Should be treated as high priority. Unless progress is blocked by dependencies on other stakeholders, the CX team may reassign on-train requests if a meaningful draft isn’t ready for review within a week after the assignment or a week before the target release day. This helps ensure content is ready in time for the release.

• Off-train requests: The draft should generally be ready for stakeholder review at least one week before the requested deadline.

Escalation:

• If you don't think you'll be able to meet the expected timeline, please notify the CX team as soon as possible by updating the Bugzilla ticket or contacting a CX staff member directly. Early communication gives us time to adjust the plan or find additional support without delaying publication.
• If you’re unable to obtain the required information from the requester, reach out to the CX staff member who assigned the bug for help obtaining the information you need.

4. Content publishing

Publish content: Once the draft is finalized and approved by the stakeholders, you can submit the content as a new revision on the actual Knowledge Base article.

Please remember that our KB uses custom wiki syntax, so ensure that your content is formatted correctly when transferring it from Google Docs or another tool you’re using to draft the content.

Content review: Contributors must wait for their KB revision to be reviewed by a staff member or a KB reviewer other than the author. At this stage, the review primarily focuses on quality assurance and proper markup, rather than validating the accuracy of the underlying product information.

Time expectation:

• On-train requests: The Bugzilla ticket may specify a planned publication date aligned with the Firefox release schedule. Please submit the KB revision for review at least two days before the target publication date, unless progress has been blocked by dependencies on other stakeholders. This gives reviewers enough time to complete the final quality and markup review without putting the release deadline at risk.

• Off-train requests: Publication should follow the deadline agreed upon in the Bugzilla ticket.

Escalation: If you need assistance with reviewing a Knowledge Base revision, you may contact the KB reviewers by sending an email to kb-reviewers@mozilla.com.

Ticket closure: Once the KB article has been published, the Bugzilla ticket can be closed by marking it as Resolved — Fixed.

Understanding content approval vs. content review

Historically, Knowledge Base contributors are only familiar with the KB review process, where anyone with KB reviewer permissions can review and approve or reject article revisions.

When working through Bugzilla, however, there are two distinct checkpoints:

1. Content approval: Completed by the appropriate product stakeholders during the content creation process in Bugzilla.
2. Content review: Completed by Knowledge Base reviewers before the article is published.

Although both are important, they serve different purposes.

Content approval by stakeholders

The primary goal of content approval is validating the substance and intent of the content with product stakeholders. This includes ensuring that the content draft is:

• Technically accurate and reflects the intended product behavior
• Aligned with approved product terminology and naming conventions
• Consistent with Mozilla’s brand voice and messaging

Content review by KB reviewer

Content review complements the approval by focusing on the quality and presentation of the article. During this stage, Knowledge Base reviewers verify that the article:

• Uses correct syntax and formatting, including wiki markup
• Is clear, well-structured, and easy to follow
• Follows Mozilla’s editorial and content guidelines

Together, these two steps help ensure that every article is both technically accurate and easy for users to understand before it is published.

Additional guidelines for contributors

• Assignment fairness

Contributors who have direct relationships with product teams may be aware of upcoming requests before they are formally submitted. However, please do not begin work or request assignment before the content request is created and triaged. This ensures that opportunities to contribute remain open and equitable for all contributors.

• Respect the triage process

Please allow the CX team the full 5-business-day triage window to review and assign Bugzilla tickets. Avoid requesting or pressuring for assignment decisions before this period has passed.

• Communicate availability changes

We understand that unexpected situations can arise. If you’re unable to meet a deadline you’ve committed to, please notify the CX team as soon as possible so we can adjust accordingly.

• Bugzilla ticket reopening policy

Please do not reopen a resolved Bugzilla content request ticket to request review of revisions that are not directly related to the original request. For related updates, add a new comment to the existing ticket instead of reopening it. If you don’t have permission to comment, please escalate your request to the kb-reviewers mailing list (see below).

Reopening tickets without meeting this standard may result in the request being dismissed. Please follow Bugzilla Etiquette to maintain productive and respectful collaboration.

• Expedited review requests

If a new article or a revision requires a faster turnaround, such as an urgent product change, ongoing incident, or critical inaccuracy, you may email kb-reviewers@mozilla.com to request an expedited review.

Finding content requests to work on

Contributors are encouraged to get involved with content requests through Bugzilla as long as they align with the criteria described in the next section. Here’s how you can look for incoming content requests:

• Manual monitoring

You can keep an eye on new content requests by checking the list of unassigned content requests. If you find a request you’d like to work on, simply leave a comment on the bug to let the CX team know you’re interested.

After triage, content requests that are open for community contributions will be tagged with the sumo-contributors keyword in Bugzilla. You can use this keyword to track ongoing requests that are available for contributors.

• Stay updated

If you’d like to get notifications about 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 in the product selection, select Knowledge Base Content in the Component field, and click the Add button to save your changes.

Assignment criteria

A content request may be assigned to a contributor when it meets the following conditions:

• Does not include confidential information

Content requests involving embargoed information or sensitive content will remain staff-owned.

• Does not involve tight internal dependencies

Requests that involve messaging sensitivity, compliance review, or evolving specs and require active coordination with legal, marketing and communications, security, or external partners will also remain with staff members.

• Not related to paid products

Content requests related to subscription products and paid features must remain staff-owned due to legal, compliance, testing, and cross-functional coordination requirements. These requests often involve contractual, billing, or release-sensitive information that requires centralized accountability.

• Not time-sensitive

Content requests with a turnaround time of less than 5 days will remain with staff to ensure timely delivery and alignment with release schedules.

• Contributor capacity

Contributors are limited to a maximum of 3 active assignments at a time. This helps ensure focused execution and prevents workload imbalance. We recognize that some requests may be delayed due to technical dependencies. If a request remains blocked on product-side dependencies for more than two weeks, the ticket may be considered inactive (stale) and excluded from contributor workload expectations.

Additional clarifications:

• This only applies to requests via Bugzilla and doesn’t apply to minor KB revisions.
• This doesn’t apply to the creation of common forum responses.
• Staff retain final accountability for published content.