Skip to content

Add guideline for handling A/B tests and feature rollouts - #30486

Open
ddbeck wants to merge 1 commit into
mdn:mainfrom
ddbeck:add-guideline-for-handling-a-b-tests-and-feature/xzrnqzwtxtsy
Open

ddbeck wants to merge 1 commit into
mdn:mainfrom
ddbeck:add-guideline-for-handling-a-b-tests-and-feature/xzrnqzwtxtsy

Conversation

@ddbeck

@ddbeck ddbeck commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

Summary

Document our approach to setting version_added or version_removed, when a feature is subject to a randomized trial (A/B test, phase in, phase out, etc.).

Test results and supporting details

This was inspired by the discussion Florian and I had on #30433. The guideline evolved a little when I had to to put it into our typical style.

Alternatives considered:

  • Assume least capability. This makes sense for feature additions, but is probably confusing for feature removals, which tend to have very small percentage removals at first (e.g., where a fraction of a percent lose the feature) and therefore not caught by the Collector or noticed by developers.
  • Assume most capability. This is hardest to test for as you have to be aware of and enrolled in all (potentially very low-percentage) feature roll outs but never enrolled in a feature removal.
  • Majority rule, where we take the larger of the experimental and control groups. This requires knowing the distribution of the experiment (which may not be public information), assumes predictable and stable experiments (i.e., that experiments aren't dynamically adjusted and never terminate early), and requires a tie breaker.

Related issues

@github-actions github-actions Bot added the docs Issue or pull request concerning project documentation. label Sep 11, 2026
@ddbeck
ddbeck force-pushed the add-guideline-for-handling-a-b-tests-and-feature/xzrnqzwtxtsy branch from 55784c2 to b331d26 Compare September 11, 2026 12:15
@github-actions github-actions Bot added the size:s Pull request changing 7-24 lines of code. label Sep 11, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

@ddbeck ddbeck added the meeting agenda Issue or pull request requiring discussion in a project meeting. label Sep 14, 2026

@caugner caugner left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, LGTM. A few nits:

  1. Could we add one or two concrete examples, as we do elsewhere, along with guidance on where to find evidence of gradual feature rollouts or removals?

  2. Could we explain this in plainer terms? My understanding is that the guideline recommends using the version in which an added feature becomes available to all users, or a removed feature is no longer available to any users. Is that correct?

  3. Should we acknowledge that the exact version may not always be identifiable? I believe some features are retroactively disabled in stable releases, often without public disclosure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Issue or pull request concerning project documentation. meeting agenda Issue or pull request requiring discussion in a project meeting. size:s Pull request changing 7-24 lines of code.

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

2 participants