Knowledge Base reviewers help ensure that Mozilla Support articles remain accurate, clear, and easy to understand. This guide explains your responsibilities, how to review revisions, and where to find articles that need attention.

Your responsibilities

As a Knowledge Base reviewer, your primary responsibility is to ensure that every approved revision:

• Is accurate and up-to-date.
• Uses clear, consistent language and tone.
• Follows SUMO editorial guidelines.
• Uses correct formatting, links, and wiki markup.
• Follows accessibility and localization best practices.
• Meets the scope of the article and supported product version.

Remember that most revisions are submitted by volunteers. Always assume good intentions, thank contributors for their work, and provide constructive feedback when improvements are needed.

Before you review

Which revisions can contributors review?

In general, contributors with Knowledge Base reviewer permissions may review most English (en-US) revisions.

Mozilla staff review is only required on the following types of revisions:

• New articles (unless the ask is coming from staff members without KB review permission)
• Updates explicitly marked as “Staff review required” in the revision notes
• Articles related to Subscription and Premium products

Finding articles to review

There are multiple ways you can find revisions waiting for review:

• Knowledge Base Overview: Browse articles by popularity and review status. Check the Status column to look for articles with pending revision to review.
• Unreviewed Changes: Review pending revisions and sort by pageviews or submission date.
• Most Visited: Prioritize updates to high-traffic articles. Check the Status column to look for articles with pending revision to review.

Prioritization

When deciding what to review first, prioritize:

• Article with high pageviews: Articles with a high number of views must be prioritized to ensure users are accessing the most accurate and up-to-date information. You can easily identify these by sorting the Unreviewed Changes list by view count.
• Article linked within the product: If you are part of one of the contribution groups (Forum, KB, L10n) or the “Staff” group, you may see an indicator showing that an article is linked within the product. These articles should generally take priority, as they have a direct impact on the user experience.

  

Special articles

• Templates include content that is reused across multiple articles and should be considered as high priority due to their broader impact. All templates, including those that need review, are listed in this board. For guidelines on how to use templates within articles, please refer to Using Templates.
• Canned Responses are standardized responses used in the Community Forums. Because they are reused frequently, any updates should be coordinated with the Community team. A list of all forum responses, including those that need review, is available in this other board. For additional guidelines on creating or improving common responses, see Create or improve common forum responses.

Reviewing a revision

When reviewing a revision:

• Pay attention to the updated section. Check the diff.
• Confirm the technical accuracy.
• Review formatting, links, and readability.
• Decide whether the revision should be approved or deferred.

Checking differences

When reviewing a revision, the review page highlights the differences between the proposed revision and the existing approved version of the article.

• Red highlights indicate content that has been removed.
• Green highlights indicate content that has been added or modified.

Review these highlighted changes carefully to verify that the proposed updates are accurate, complete, and appropriate before approving the revision.

Approving a revision

When approving a revision, choose the revision level that best reflects the scope of the changes. The selected revision level determines whether the article is eligible to be marked Ready for Localization (RFL).

• Minor details that don't affect the instructions: Use this for maintenance changes such as fixing typo, formatting, or other edits that do not affect user instructions. Revisions marked with this are not eligible to be marked Ready for Localization.
• Content changes that don't require immediate translation: Use this for updates that improve or expand the content without immediately invalidating existing translations. These revisions are eligible to be marked Ready for Localization.
• Major content changes that will make older translations inaccurate: Use this when the revision significantly changes user instructions or product behavior. These revisions are eligible to be marked Ready for Localization and indicate to localizers that existing translations may need to be updated promptly.

Ready for Localization (RFL)

An article can only be translated after its English version has been marked Ready for Localization (RFL). This prevents localizers from translating content that is still being updated.

When approving an English revision, a reviewer can mark it as Ready for Localization. Once marked, the article:

• Appears in localization dashboards.
• Sends an email notification to contributors watching the article, letting them know that it is ready for localization.

For detailed guidance, see Ready for Localization.

Marking an article RFL

Localization is a lot of work and is often handled by one person. Before marking an article as Ready for Localization (RFL), make sure the English content is complete and unlikely to change. This helps avoid unnecessary rework for localizers.

There are 2 ways you can mark an article as Ready for Localization:

1. When reviewing a revision

You can mark an article as RFL when reviewing a revision by selecting the Ready for localization checkbox on the review dialog.

2. Marking RFL post-review

You can also mark a revision as RFL from the article history page. Simply click on the ✕ symbol (indicate that it’s not ready for localization) under the R column on the article history and confirming. Revisions that have been marked RFL have a checkmark symbol ✓.

RFL protocols

All contributor reviewers must adhere to the following localization protocols:

• All Mozilla staff and contributor reviewers may mark a net-new article or an article update as ready for localization.
• All net new articles and revisions that introduce new or changed information must be marked for localization, unless otherwise specified by Product teams based on regional availability.
• In some cases, Mozilla staff may leave comment syntax or a revision comment in an article to indicate that a translation is already being submitted for internal localization in certain locales. If the comment syntax indicates that an article or revision is already being submitted for internal localization, contributors must not localize it independently.

Reviewing major revisions

When reviewing a major revision, make sure to complete the following steps:

• Verify that a Bugzilla ticket exists. Every major revision must be associated with a Bugzilla content request. If you encounter a major revision without a Bugzilla ticket, contact the revision author and ask them to submit one before the revision is approved.
• Check the Bugzilla ticket for outstanding issues. Before approving the revision, confirm that any requested changes or unresolved concerns in the Bugzilla discussion have been addressed.
• Confirm product validation. Ensure that the technical aspects of the updated content have been confirmed by the appropriate product stakeholders. This helps ensure the article accurately reflects the intended product behavior before publication. In most cases, this validation should already be complete by the time the revision is submitted for review, but it's always worth verifying.
• Update the Bugzilla ticket. Once the revision has been approved, leave a comment in the Bugzilla ticket to let the assignee know that the Knowledge Base review is complete and the ticket can be resolved, if no other work remains.

For more information about the Bugzilla workflow, see Contributor assignments for content requests.

To learn how content updates are classified as minor or major based on their scope and impact, see Minor vs major changes.

Leaving feedback for the revision author

When reviewing an article, you have the opportunity to leave feedback for the revision author(s). Thoughtful feedback not only helps improve the current revision, but also encourages contributors to continue participating.

When approving a revision

When approving a revision, consider leaving a short message to thank the contributor for their work or share positive feedback about their writing.

If the revision is generally ready but contains a minor issue (such as a typo or formatting mistake), you can approve it and use the feedback field to ask the author to fix the issue. Otherwise, you can submit a follow-up revision yourself to fix it and ask a fellow KB reviewer to review.

When deferring a revision

When deferring a revision, use the opportunity to:

• Thank the contributor for taking the time to submit the revision.
• Explain what needs to be changed from the previous edit.
• Provide specific, constructive feedback as much as you can.
• Include links to any relevant documentation or guidelines that may help the contributor revise their work.

Constructive feedback helps contributors improve and encourages future participation.

What if additional updates are still needed?

Sometimes, a revision is ready to be approved even though there are still improvements that should be made in the future. In these cases, you can use the Needs Change option to document follow-up work:

• Select the Needs Change checkbox when approving the revision.
• Leave a brief description of the remaining work in the comment field that appears.
• When everything specified in the “Needs change” comment has been taken care of, clear the Needs Change checkbox and remove the comment.

Using the Needs Change field helps reviewers and contributors keep track of follow-up work without delaying publication of an otherwise acceptable revision.

Reviewing multiple revisions

When multiple revisions are pending approval, make sure to approve or defer all earlier revisions, starting from the oldest one, before approving a newer revision. It’s important to note that you can't review older revisions when a newer revision has been approved. You will see that they are still pending approval, but it won't be possible to review them.

Giving credit

Sometimes people that participate in a discussion about an article make significant contributions to a revision even if they weren't the one to actually edit the wiki. In cases like this, you can edit the list of contributors to an article (on the article history page) to include them. Bonus points for letting them know you did this!

How to give credit to a contributor in the KB

• To add a contributor, go to the Show History page of an article
• Scroll down under the revisions and click the Edit contributors link
• Type the contributor name and then click Add Contributor

Handling spam and mistaken edits

In the case of spam, you should simply delete the revision by clicking the trash can icon in the article revision history and confirming. In the case of mistaken submissions (no changes) and misplaced help requests (the edit is basically a support question), you should defer and include this message in your comments:

Hi.

It appears you may have been trying to get help with Firefox. If that is the case, please ask your question again here, https://support.mozilla.org/questions/new so that we can better help you.

Sorry for the inconvenience.

Once you've done that, you can delete the revision.

Need help?

Not all KB reviewers actively monitor KB Discussions. If you need assistance from the reviewer group, please email: kb-reviewers@mozilla.com.

If your question relates to a Bugzilla content request, continue the discussion in the associated Bugzilla ticket so all stakeholders remain informed.

Content related to subscription or premium products

Content submission

If you would like to suggest new content or propose changes, please file a Bugzilla ticket or reach out to a staff member. You can contact us either on Matrix or in the #sumo-team channel on Slack (for contributors with Slack access).

KB review and approval

All revisions related to Subscription or Premium products require review and approval by Mozilla staff. This requirement also applies to Templates and Canned Responses associated with these products.

For reference, current Subscription or Premium products include:

• Mozilla VPN
• Firefox Relay
• Mozilla Monitor
• MDN Plus

Release readiness

To make sure that we are ready to support upcoming Firefox on-train releases, we follow a release readiness timeline for articles (including new articles or content updates) related to upcoming releases.

The following timeline outlines when release-related content should be drafted, reviewed, published, and localized.

Firefox release calendar

Release readiness timeline

4 weeks before the next release

• Begin planning and drafting content for the upcoming release; no work for localizers yet.
• All existing articles remain open for editing and localization as usual.

1-2 weeks before the next release

• Draft content for the upcoming release may be ready internally; however, publication typically waits until the official release date to account for any last-minute changes.
• If the content requires localization prior to release, the product team must notify the CX staff so we can coordinate with the localization community to ensure deadlines are met.

Release day

• Content changes should be published in the en-US Knowledge Base. Localizers should prioritize translating articles related to the new release.

Role evaluation

Creating content that is accurate, consistent and relevant is important, and maintaining that quality over time requires shared standard and ongoing alignment.

As a Knowledge Base reviewer, you play an important role in upholding those standards. To ensure our reviewer group stays active and aligned with current practices, the Community team conducts a light annual review based on participation and adherence to guidelines.

To retain your KB reviewer permission, we ask that you:

• Stay aligned: Adhere to the Community Participation Guidelines and the KB reviewer guidelines outlined in this article.
• Stay active: Review at least three (3) revisions within a six-month period.

If you haven’t been active or if questions arise about guidelines adherence, the Community team may reach out to you to check in before taking any action. Our goal is not to remove permissions, but to ensure reviewers feel engaged, supported and aligned with current processes.

If circumstances change and you need to step back, we completely understand. Since this is a volunteer role, your time and availability may naturally shift. Don’t hesitate to let the Community team know when that happens. We’re always happy to reconnect when you’re ready to re-engage.

By working together and involving others in the review and approval process, we can maintain the highest standards of quality and ensure that our content is top-notch.

Thank you for your cooperation, and let's continue to create amazing revisions for our users!