Upcoming Changes

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

The name and description give you a brief explanation of the change and will link to related Meta topic for additional information and a place to collect feedback.

2 - Status

The status communicates its position in the development lifecycle. Status directly impacts whether the change is opt-in (i.e. off by default, but you can turn it on), opt-out (i.e. on by default, but you can turn it off), or forced on (i.e. on, and you can’t turn it off).

We use the following statuses in Upcoming Changes:

  • Experimental: A potential change that is in early development / testing and is expected to evolve rapidly, or may be removed altogether if we end the experiment (at which point it will move to Inactive status; see below). You may opt-in to Experimental changes to test them out.

  • Alpha: A tested change that is safe to use, though there may be some minor updates to its design or functionality. You may opt-in to Alpha changes to use them early.

  • Beta: A tested change that is safe to use, and is unlikely to change much before moving to Stable or possibly Permanent status.

    • :information_source: For most sites on our hosting, and for self-hosted sites, Beta changes are automatically turned on for everyone (if you haven’t previously enabled it), but you may still opt-out.
  • Stable: A completed change

    [1] , but is still opt-out (i.e. admins can disable it). Admins will be warned on their dashboard when they have opted-out of a Stable change.

  • Permanent: A change that has completed testing, and is forced on (i.e. admins cannot disable it). Permanent changes will no longer appear in the upcoming changes list, instead they will be shown on the /admin/whats-new page.

  • Inactive: An abandoned experiment. You cannot opt-in.

Sometimes, changes will move linearly through these statuses (i.e. start in Experimental and end in Permanent), but not always. Some changes may be introduced in Alpha or Beta status, and some will end in Stable status. Changes that are of the type “site setting default” will not be moved to Permanent, since they are only changing the default value of an existing setting.

There is no set time for how long it will take a particular change to progress from one status to another, but admins will be notified when:

  • A new change is available to try out
    • These are sent at most once per week to avoid notification fatigue. If you prefer not to receive these notifications, you can disable them in /my/preferences/notifications
  • A change has been enabled automatically
  • When you have disabled a change that will soon be forced on
    • This will be shown as an admin dashboard warning

3 - Impacted users

The impacted users tag describes which users in your community can see or interact with the change in some way. To put it simply — who might notice this change? There are several types of impacted users:

  • Admins: The change is only visible to admins.
  • Staff: The change is only visible to admins and moderators.
  • All members: The change is visible to all members on your site.
  • Developers: In rare cases, a change will only be noticeable to those who are interacting with code in core, themes, or plugins.

Impact type

A subset of impacted users, and not shown in the list, is the impact type. The impact type describes how the change will affect your community in a broad sense:

  • Feature: The change introduces a new feature or functionality to your community, or modifies existing functionality.
  • Site setting default: The change modifies the default value of an existing site setting. Admins who have already changed the setting off its old default will not be affected. No admin dashboard warning will be shown for this change once it reaches Stable.
  • Other: Any other change that doesn’t fit into the above categories.

4 - Enabled for…

This drop-down is where you, as the site admin, can control whether and how to introduce this change to your community by enabling it for:

  • No one: Disables the change for everyone on the site.
  • Everyone: Enables the change for everyone on the site, including anonymous users. When the change is automatically turned on (typically at Beta status), it will be for Everyone.
  • Staff only: Enables the change for site staff (i.e. admins and moderators).
  • Specific groups: Enables the change for the selected group(s).

:information_source: Some upcoming changes may have restricted “Enable for” options. The available options in the “Enabled for” dropdown are determined by the change’s configuration. For example, certain changes might only allow Everyone and No one options, since limited group testing would be infeasible for the change.

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:


  1. Insofar as any software is complete! ↩︎

6 Likes