As our Knowledge Base workflow evolves, we want to create clearer boundaries around when content requests may be assigned to community contributors.

We deeply value your 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.

These guardrails are designed to:

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

These changes are about creating sustainable collaboration between staff and contributors.

Before you start

Before proceeding, please note that we follow different workflows for minor and major updates.

Please review Minor vs major changes to understand what qualifies under each category and see Submit a minor update in a Knowledge Base article for guidance on submitting minor updates directly.

These guardrails apply only to new content or major update requests for support articles. They do not apply to other article categories or to minor revisions to support articles submitted directly to the Knowledge Base.

Content process for new content requests and major updates

The following process applies to new content requests and major updates submitted via Bugzilla. Note that the submission process also applies to Mozilla staff, as well as to contributors.

• Step 1: Submission

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

• Step 2: Triage and assignment
  • Triage: All new content requests go through a triage process to determine priority and assignment. Contributors are encouraged to get involved, provided the request aligns with the assignment criteria outlined in the section below. To express interest, please comment directly on the Bugzilla ticket.
  • Assignment: The CX team is responsible for the entire content request process, regardless of product ownership and will assign the bug to either contributor/Technical Writer. Please do not start drafting until a CX staff member confirms your assignment. Once assigned, the Community Manager or another CX team member will guide you through the process.
  • Time expectation: Triage is conducted on a weekly basis, and contributors can expect a response within 5 business days of the initial request.
• Step 3: Content creation
  • Content draft: Carefully review the ticket to fully understand the request, scope, and expected outcome. 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.
  • Escalation:
    • If you’re unable to obtain the required information from the requester, reach out to a CX Product Support Manager or a Community Manager for support (check this article for reference on who to contact).
    • If you can’t meet the deadline expected by the requester, please notify the CX team as soon as possible by updating the Bugzilla ticket or contacting a CX staff member directly.
• Step 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 is using a custom Wiki syntax, so ensure that your content is formatted correctly if you copy the content from a Google Doc.
  • Content review: Contributors must wait for a KB review from a staff member or a KB reviewer (other than the author) for quality assurance and markup appropriation.
  • Ticket closure: Once the KB article has been published, the Bugzilla ticket can be closed by marking it as Resolved — Fixed.

Content approval vs content review

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 complements the approval by focusing on the quality and presentation of the article. This includes:

• Ensuring correct syntax and formatting (including wiki markup)
• Improving clarity, readability, and structure
• Verifying alignment with editorial and content guidelines

Together, content approval and review ensure that articles are both accurate and user-friendly before publication.

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 days 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 the revision requires a faster turnaround, such as an urgent product change, ongoing incidents, or critical inaccuracies, you may email kb-reviewers@mozilla.com to request an expedited review.

Where to look for incoming content requests

Contributors are encouraged to get involved on non-confidential content requests. Here’s how you can look for incoming content requests:

• Manual monitoring

Keep an eye on new content request bugs by checking the incoming requests that haven’t been assigned here. When you find one you’re interested in, please directly comment on the bug to notify the CX team that you want to help out with the request.

• Stay updated

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.

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 communication, security, and 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.