The Mozilla Support Knowledge Base (KB) is the foundation that makes our entire support effort scale to serve hundreds of millions of users. But articles don't come without a cost. Each one has to be written, reviewed, localized and maintained.

For that reason, thoughtful content management is essential. Before adding new content or modifying visibility, please review the guidelines below.

Content ownership and discretion

Most SUMO content falls under the discretion of the Content team within Customer Experience (CX).

The following categories are exceptions and are managed by the Community team:

• How to contribute
• Canned responses

These areas are owned by the Community team to ensure alignment with contributor workflows and practices. To learn more about each team and their roles, please check out the Meet the Team article.

As such, updates to the How to contribute or Canned responses articles are managed directly by the Community team and are exempt from the standard content workflow.

Adding and archiving articles

Proposing new articles

In many cases, improving or expanding an existing article is more effective than creating a new one.

Net new articles should only be created under one of the following conditions:

• The topic is not already covered in existing SUMO documentation.
• The article serves to clarify new or existing information that is insufficient or unclear to users, or is anticipated to be technically advanced enough to influence support volume.
  • Some user-facing features are likely to generate a lot of interest and questions from users. This may be an inherent aspect of the feature, a result of marketing and in-product links, or a combination of the two.
• There is a new, complex issue with one of our products that has surfaced frequently in recent threads and votes in the support forum.
  • This can include critical, time-sensitive issues that need temporary documentation (e.g., Firefox startup crash with G DATA security software).
• The article is explicitly required by a Mozilla staff member, or is required as part of release readiness work.

Archiving articles

To ensure our Knowledge Base remains focused on the most current and pressing user inquiries, we periodically review and archive articles that no longer reflect the latest versions of Mozilla products or services user concerns. Archiving is not the end of an article; it's a way to signal that the content might be outdated or less relevant to our current user base, while still preserving its historical value and access for those who might need it.

How it works

Staff and contributors with reviewer privileges can mark an article as obsolete. This is how it is done:

• Visit the article page and click on the Edit Article Metadata menu under Editing Tools.
• Mark the article as Obsolete by adding a checkmark to it.
• Click the Save button.

An archived article is removed from all dashboards, including localization dashboards, and it won't appear in normal search results. However, any existing direct links to the article will still work. A banner will be displayed at the top of the article to inform readers that it is no longer being maintained and might be out of date. Archiving is reversible. Should the need arise, contributors can revisit the Edit Article Metadata page and uncheck the Obsolete option, bringing the article back into active status.

Considerations before archiving

• Low views: Articles attracting less than 1500 visits per month are candidates for archiving.
• Few recent reports: The lack of recent threads or votes in the support forum suggests the article addresses a lesser concern.
• Low impact: Articles whose removal is unlikely to cause significant issues.
• Product changes: Articles related to issues that have been resolved or features that have changed significantly.

Guidelines for archiving KB articles

When deciding to archive an article, consider the following to ensure the decision aligns with the best interests of our user base and the accuracy of our Knowledge Base:

• Obsolescence and irrelevance: Articles should be archived if the content is no longer relevant to the current versions of Mozilla products or services. For details, see Firefox version support policy for Knowledge Base content.
• Redundancy: Content that has been superseded by more comprehensive articles or duplicated across multiple articles without adding unique value should be archived to streamline the knowledge base.
• Historical content: Articles that serve more as a historical record rather than providing practical, current support may be archived to keep the active knowledge base focused on user support.

Restrict visibility

The Restrict Visibility feature is a recent addition aimed at enhancing the flexibility of content management within the SUMO platform. It allows specific articles to be visible only to designated groups, such as staff members or certain contributors, enabling the distribution of sensitive or early-stage content in a controlled manner.

How it works

Restrict visibility empowers staff and contributors with KB reviewer privileges to manage the accessibility of articles to specific audiences. This feature is important in controlling the dissemination of sensitive or early-stage information that's not yet intended for the broader public. Here's how it operates:

• Setting restrictions: A staff member or contributor with the necessary privileges can restrict an article's visibility. This is achieved by navigating to the article's Description page and selecting the appropriate visibility settings from the "Edit Article Metadata" section found under Editing Tools.
• Impact of restriction: Once an article is set to restricted visibility, it becomes inaccessible to the general public and only visible to staff members and designated groups (like specific contributor circles, NDA'd contributors, etc). This action removes the article from general search results and public dashboards, though direct links to the article remain functional for those with access.
• Visibility indicators: Articles with restricted visibility will feature indicators or banners to clarify their status to viewers who have access. This alerts them that the content is restricted and may contain information not yet public or intended for a specific audience.
• Reversibility and Adjustment: The restrict visibility setting is not permanent and can be adjusted as the need for restriction changes. Staff and contributors with the appropriate privileges can return to the article's metadata settings to modify visibility restrictions, making the article available to a broader audience or adjusting the groups that have access.

Considerations before restricting visibility:

Before applying the Restrict Visibility feature to an article, it's crucial to weigh the following to ensure the feature is used effectively:

• Audience necessity: Ensure the content is indeed intended for a specific audience and not beneficial for the wider user base.
• Content sensitivity: Assess the sensitivity of the information to determine if restricted visibility is warranted.
• Impact on forum support: Consider whether restricting the visibility of the article could negatively impact users who might otherwise benefit from the information, and if so, seek alternative methods to address any concerns.
• Temporal relevance: For content that is only temporarily sensitive (for example, features under embargo until a certain date), plan to adjust visibility settings once the information is no longer restricted.

Guidelines for restricting visibility

• Pre-release content: Ideal for articles detailing upcoming features or products that are not yet public.
• Targeted communication: Enables the sharing of information with specific groups within our community, such as NDA'd contributors or locale leaders, without making the content public.
• Sensitive information management: Useful for content that, due to its sensitive nature, requires restricted access.