You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Self-driving can label every pull request it opens (#104506, shipped 2026-09-23), but the switch is off by default. A team only gets the label after somebody finds the row in the inbox self-driving settings and turns it on.
That means the common case is still the one #104418 described: self-driving PRs open under the shared app/posthog identity with nothing to filter on. The label is the one thing that lets a GitHub saved search, notification rule, or exclusion tell them apart, and the team that most needs it is the one that never visited the settings page.
The opt-in rationale was that the label lands on a repository the team shares. In practice the label is created if missing, is inert, and is one switch to turn off. The cost of the label being there unasked is far lower than the cost of it being absent.
Proposal
Make pull_request_label_enabled default to true, so every self-driving PR carries the self-driving label unless a team turns it off.
Flip the model default and db_default on SignalTeamConfig.pull_request_label_enabled from False to True (products/signals/backend/models.py), with a migration for the column default.
Backfill existing rows in the same migration: set pull_request_label_enabled = true where it is false. The feature has been live for about a day, so a false today means "never looked at it", not "declined". A false after this ships means declined and stays untouched.
Leave pull_request_label alone. Null still means self-driving via DEFAULT_PULL_REQUEST_LABEL.
Update the serializer help_text ("False by default" becomes on by default) and the settings row copy in SelfDrivingSection.tsx, which currently reads as an opt-in. Regenerate OpenAPI types.
Update the module docstring in pull_request_label.py and the field comment in models.py, which both explain the opt-in reasoning.
Changing the default for github_issue_writeback_enabled or default_open_pull_request_ready. Those write to a public issue thread or spend CI runners, so opt-in is still right for them.
Acceptance
A new team that never opens the settings page gets the self-driving label on its next self-driving PR, given a GitHub integration that can reach the repository.
A team that turns the switch off gets no label and is not flipped back by any later migration.
test_pull_request_label.py gains a case for a team with no config row at all, asserting the label is applied. Today configured_pull_request_label returns None when no row exists, so the flipped default alone is not enough: that function has to treat a missing row as enabled.
test_signal_team_config_api.py asserts the default the API reports is true.
Notes for the implementer
The no-config-row path in configured_pull_request_label is the trap. A model default only helps once a row exists, and many teams reach this code without one. Fall back to the default label when config is None.
Migration: default flip plus a data RunPython (or a single UPDATE) on a boolean column of a small table. Follow /django-migrations. No index or lock concerns.
Storybook story SelfDrivingSection.stories.tsx shows the row on by default after this; check the rendered copy.
Problem
Self-driving can label every pull request it opens (#104506, shipped 2026-09-23), but the switch is off by default. A team only gets the label after somebody finds the row in the inbox self-driving settings and turns it on.
That means the common case is still the one #104418 described: self-driving PRs open under the shared
app/posthogidentity with nothing to filter on. The label is the one thing that lets a GitHub saved search, notification rule, or exclusion tell them apart, and the team that most needs it is the one that never visited the settings page.The opt-in rationale was that the label lands on a repository the team shares. In practice the label is created if missing, is inert, and is one switch to turn off. The cost of the label being there unasked is far lower than the cost of it being absent.
Proposal
Make
pull_request_label_enableddefault totrue, so every self-driving PR carries theself-drivinglabel unless a team turns it off.db_defaultonSignalTeamConfig.pull_request_label_enabledfromFalsetoTrue(products/signals/backend/models.py), with a migration for the column default.pull_request_label_enabled = truewhere it isfalse. The feature has been live for about a day, so afalsetoday means "never looked at it", not "declined". Afalseafter this ships means declined and stays untouched.pull_request_labelalone. Null still meansself-drivingviaDEFAULT_PULL_REQUEST_LABEL.help_text("False by default" becomes on by default) and the settings row copy inSelfDrivingSection.tsx, which currently reads as an opt-in. Regenerate OpenAPI types.pull_request_label.pyand the field comment inmodels.py, which both explain the opt-in reasoning.Out of scope
github_issue_writeback_enabledordefault_open_pull_request_ready. Those write to a public issue thread or spend CI runners, so opt-in is still right for them.Acceptance
self-drivinglabel on its next self-driving PR, given a GitHub integration that can reach the repository.test_pull_request_label.pygains a case for a team with no config row at all, asserting the label is applied. Todayconfigured_pull_request_labelreturnsNonewhen no row exists, so the flipped default alone is not enough: that function has to treat a missing row as enabled.test_signal_team_config_api.pyasserts the default the API reports istrue.Notes for the implementer
configured_pull_request_labelis the trap. A model default only helps once a row exists, and many teams reach this code without one. Fall back to the default label whenconfig is None.RunPython(or a singleUPDATE) on a boolean column of a small table. Follow/django-migrations. No index or lock concerns.SelfDrivingSection.stories.tsxshows the row on by default after this; check the rendered copy.