Danger: Add QA labeling requirement to all PRs

[Sidnioulz]

What I did

Modified team process for QA requirements. Instead of labeling all QA worthy PRs at the end of a cycle, and then removed the QA label post QA, we'll now indicate on each PR whether it is QA worthy or not at the time of authoring. Then, the release team will go through all QA worthy PRs and label them as successful post-QA. This should help:

• Limit the risk of missing a QA-worthy PR
• Save time for project team members as they no longer need to recheck all their PRs at the end of a cycle
• Better track when QA was done and by whom, to help with postmortem in case of release incidents

Checklist for Contributors

Manual testing

N/A

Documentation

N/A

Checklist for Maintainers

• When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli-storybook/src/sandbox-templates.ts

• Make sure this PR contains one of the labels below:

  Available labels

  • bug: Internal changes that fixes incorrect behavior.
  • maintenance: User-facing maintenance tasks.
  • dependencies: Upgrading (sometimes downgrading) dependencies.
  • build: Internal-facing build tooling & test updates. Will not show up in release changelog.
  • cleanup: Minor cleanup style change. Will not show up in release changelog.
  • documentation: Documentation only changes. Will not show up in release changelog.
  • feature request: Introducing a new feature.
  • BREAKING CHANGE: Changes that break compatibility in some way with current major version.
  • other: Changes that don't fit in the above categories.

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook publish.yml --field pr=<PR_NUMBER>

Summary by CodeRabbit

• Chores
  • PR validation now requires exactly one QA label for non-release PRs; validation fails with clear instructions if none or multiple are present.
  • Pull request template updated with a checklist item asking maintainers to declare manual QA for the next release via qa:needed or qa:skip.

[Copilot]

Pull request overview

Updates the repo’s Danger.js PR checks to require explicit QA labeling on pull requests, aligning labeling with a “declare QA needs at authoring time” workflow.

Changes:

• Added a new allowed QA label set: qa:needed, qa:skip, qa:success.
• Extended checkRequiredLabels() to fail PRs missing a QA label, or having multiple QA labels.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 97c8956c-560d-41fd-a91f-c56633363981

📥 Commits

Reviewing files that changed from the base of the PR and between 05e49cd and 124dc46.

📒 Files selected for processing (1)

• .github/PULL_REQUEST_TEMPLATE.md

✅ Files skipped from review due to trivial changes (1)

• .github/PULL_REQUEST_TEMPLATE.md

---

📝 Walkthrough

Walkthrough

This PR adds a qaLabels set and updates Danger.js to require exactly one QA label on non-release PRs; it also adds a maintainer checklist checkbox in the PR template to mark qa:needed or qa:skip.

Changes

QA Label Enforcement

Layer / File(s)	Summary
Define QA labels and validation scripts/dangerfile.js	Adds a qaLabels array and extends non-release PR validation to compute foundQALabels and fail the check when zero or multiple QA labels are present.
PR template QA checkbox .github/PULL_REQUEST_TEMPLATE.md	Adds a maintainer checklist item instructing maintainers to mark qa:needed or qa:skip for the next release.

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• storybookjs/storybook#34076: Also modifies scripts/dangerfile.js’s QA/manual-testing validation flow.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}