Skip to content

chore: consistent formatting for advanced topics #774

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jaredlockhart merged 1 commit into from
Feb 9, 2026
Merged

chore: consistent formatting for advanced topics #774

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions docs/advanced/enrollment-state-machine.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,8 @@ title: Enrollment State Machine
slug: /advanced/enrollment-state-machine
---

The possible enrollment states and transitions within the Nimbus SDK, including reasons for each state change.

## Possible States

Within the Nimbus SDK there are multiple states, most of which have a "reason" associated with them.
Expand Down
4 changes: 2 additions & 2 deletions docs/advanced/first-run-experiments.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ While the concept of First Run Experiments is also supported by Firefox for Desk

:::

## What is a First Run Experiment?
## What Is a First Run Experiment?

A First Run Experiment is one that needs to enroll clients on their first launch of the application. All First Run Experiments bundled with a particular app version would be evaluated for enrollment on the very first run of the application after it is installed.

Expand Down Expand Up @@ -87,7 +87,7 @@ Many use cases for First Run Experiments require advanced targeting configuratio

Please follow the contributing guidelines when opening PRs to Experimenter. If you require assistance, please reach out in the #ask-experimenter channel on Slack.

## How do I know if an experiment should be first run?
## How Do I Know If an Experiment Should Be First Run?

In short, if your experiment makes changes to onboarding, needs data from brand-new clients, or otherwise relates to clients who are using Firefox on their device for the first time, then your experiment should most likely be a First Run Experiment.

Expand Down
2 changes: 1 addition & 1 deletion docs/advanced/notifications.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ Notifications exist on [Experimenter](https://experimenter.services.mozilla.com/

These notifications do not necessitate action on the owners' part, but are a reminder to check the enrollment numbers and live monitoring to see if actions can be taken at the proposed dates.

### Non-owner subscribers
## Non-Owner Subscribers

Non-owners can now subscribe to the same notification emails that experiment owners receive.

Expand Down
10 changes: 5 additions & 5 deletions docs/advanced/warnings.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ slug: /advanced/warnings

There are a number of warning messages that you may encounter on Experimenter in the course of launching your experiment. These warnings are listed below, along with any restrictions that they may impose on an experiment.

## Rollout bucketing warning
## Rollout Bucketing Warning

:::tip
See the [Rollout FAQ](/advanced/rollouts) for general rollout information
Expand All @@ -31,25 +31,25 @@ To prevent this situation, check the "Prevent enrollment if users have changed a
<img style={{border:"1px solid grey"}} title="SetPrefs prevent enrollment" src="/img/faq/setpref-prevent-enrollment.png" align="center"/>


## Audience overlap
## Audience Overlap

There are cases where the audience of two experiments/rollouts will overlap in ways that Experimenter can predict. Audience overlap will generally result in under enrollment which can potentially invalidate an experiment. There are three scenarios where we can detectable cases of audience overlap so that experiment owners can adjust their [sizing][2] accordingly.

The warnings list the `slugs` of the experiments that overlap with yours (the `slug` of an experiment is the hyphenated name listed underneath the experiment title). Easily navigate to one of these experiments by replacing the slug in your URL with one copied from the warning: https://experimenter.services.mozilla.com/nimbus/put-the-slug-here/summary.

These warnings do not prevent experiments from being launched.

#### Live experiments exist on a previous iteration of a namespace
### Live Experiments Exist on a Previous Iteration of a Namespace

<img style={{border:"1px solid grey"}} title="Live experiments in namespace warning" src="/img/faq/prev-namespace-warning.png" align="center"/>
<p/>

#### Live multi-feature experiments exist on this feature
### Live Multi-Feature Experiments Exist on This Feature

<img style={{border:"1px solid grey"}} title="Live multfeature experiments warning" src="/img/faq/multifeature-warning.png" align="center"/>
<p/>

#### An experiment excludes other live deliveries
### An Experiment Excludes Other Live Deliveries

<img style={{border:"1px solid grey"}} title="Excludes live deliveries warning" src="/img/faq/excluded-warning.png" align="center"/>

Expand Down