Upcoming Changes

[lindsey (Lindsey Fogle)]

The Upcoming Changes system helps admins understand, test, and manage new features and changes coming to Discourse before they’re fully deployed.

Accessing Upcoming Changes

Navigate to Admin > Upcoming Changes (or visit /admin/config/upcoming-changes).

Understanding Upcoming Changes

Each upcoming change displays four key pieces of information:

1. Name and description

A brief explanation of the change to describe its impact in your community. In this section, you’ll also find links to image previews, which illustrate the change, and to a Meta topic where you can learn more and leave feedback.

2. Status

The status indicates where the change is in the development lifecycle and determines whether it’s opt-in, opt-out, or mandatory.

• Experimental: Early-stage development or testing. The feature may evolve significantly or be discontinued. These changes are opt-in only.
• Alpha: Tested and safe to use, though minor design or functionality updates may still occur. These changes are opt-in only.
• Beta: Tested, safe, and unlikely to change significantly before becoming stable or permanent. Beta changes are automatically enabled for most users unless you’ve previously opted in, but you can still opt out.
• Stable: Completed and ready for general use, but still opt-out.
• Permanent: Mandatory for all sites; cannot be disabled. (See note below.)
• Inactive: Abandoned experiment; cannot be enabled.

Changes don’t always progress linearly through these statuses. Some may start at alpha or beta, and others may remain at stable indefinitely rather than becoming permanent. There’s no fixed timeline for how long changes remain at each status. The progression depends on testing results, community feedback, and the nature of the change itself.

Notifications

Admins receive notifications when:

• A new change becomes available to try (typically at alpha status)

• A change has been automatically enabled for your site (typically at beta)

Admins will see a problem check when they have disabled a change that will soon become mandatory (when the change is stable but soon to be permanent) to ensure you have adequate time to test the impact of the change while you can still easily turn it off, before it is made permanent in your community.

3. Impacted users

Describes which users in your community will see or interact with the change:

• Admins: Only visible to site administrators

• Staff: Visible to administrators and moderators

• All members: Visible to all users on your site

• Developers: Only noticeable to those working with code in core, themes, or plugins

4. Enabled for

Controls who has access to the change on your site:

• No one: Disables the change for everyone

• Everyone: Enables for all users, including anonymous visitors (this is the default when changes auto-enable at beta status)

• Staff only: Enables for administrators and moderators only

• Specific groups: Enables for selected user groups

Note: How you enable the change does not impact who might be impacted by it. For example, the following change only impacts staff, but it’s been enabled for everyone — however, only staff have access to category creation so average members won’t see changes.

Managing changes

You can use the “Enabled for” dropdown to control how changes roll out in your community. This allows you to:

• Test changes with staff before wider deployment

• Enable features for specific user groups to gather feedback

• Temporarily disable changes while you update site customizations, processes, or documentation

• Inform your community about upcoming changes before they go live

Seeing which changes a user has enabled

It may be necessary for admins to understand why some user can or cannot see a change or be affected by it. If you head to the admin user page at /admin/users/:id/:username you will see this section, which explains if the change is enabled for a user and why: