Routing

Routing decides who answers each human task and how to reach them. Every decision is stored with the candidates Warpway considered and a reason you can read, and no task is ever dropped because nobody was found. Routing starts at trust level 1 (Assist); at level 0 (Observe), Warpway shows its questions on the pull request but does not send them to anyone.

Where candidates come from

Warpway collects candidates from these sources, in priority order:

An Admin's routing correction ranks above all of these. Two adjustments keep the order meaningful: a catch-all CODEOWNERS entry such as * ranks just after the configured contacts, and for non-engineering questions CODEOWNERS and code history rank below the configured contacts, the linked issue and topic expertise, because owning code says little about product intent. Within the same source, Warpway prefers the stronger signal, agreement between sources, someone reachable on the preferred channel, a linked person over a bare login or team, and people without recent "wrong person" feedback on the topic.

The pull request's author is asked a question only when nobody else can be reached, and never asked to sign off. Inactive people and bots are never asked. Candidates found through review or commit history, linked issues or expertise must already be people in your organization, so a question never goes to an outside contributor found in commit history.

If no source produces a suitable person, the task stays unassigned and visible in GitHub and the dashboard with the reason, instead of disappearing.

Expertise

Warpway keeps professional expertise edges between people and topics, such as billing.cancellation or auth.session-revocation. Each edge records its source (explicit configuration, CODEOWNERS, review history, commit history, ticket history or human feedback), a weight and when it was last observed. Explicit and CODEOWNERS expertise does not fade, while each piece of history-based evidence counts half as much after 90 days, so recent, explicit expertise counts for more than old, inferred expertise. Corrections by Admins and "wrong person" answers feed back into these edges; feedback never changes explicit or CODEOWNERS ownership.

Why you?

Every routing decision includes a human-readable explanation, shown wherever the task appears: in the Slack message, in the details of the Warpway / Review check and in the dashboard. For example:

Routed to Priya Shah on Slack: owner of the Product Semantics lens, answered 3 earlier billing cancellation questions.

Routed to the @acme/security team on GitHub: CODEOWNERS owner of src/auth/**. Team membership is not synced, so the whole team was asked.

When someone who ranked higher could not be reached, or was excluded, the explanation says so.

How people are reached

People asked in Slack are never requested as pull request reviewers, even if they also use GitHub: a product manager answering one question does not need the whole pull request.

Reviewer requests

When a task is best answered by a GitHub user or team and your organization allows it, Warpway requests them as reviewers. Admins can turn this off for the organization, and each repository can limit it:

version: 1
reviewer_requests:
  enabled: true
  max_per_pr: 2

max_per_pr (2 by default) caps the reviewer requests Warpway makes on one pull request. Warpway never requests the pull request's author, a bot, or someone already requested.

Configure routing

Name owners per lens and a default for everything else. Keys under routing are lens keys or default:

version: 1
routing:
  security:
    github_team: "@acme/security"
    slack_group: "security-team"
  product_semantics:
    slack_user_group: "@product-leads"
    prefer_slack: true
  database_safety:
    github_users:
      - dana-dba
      - lee-platform
  default:
    github_team: "@acme/maintainers"

default applies only to lenses without their own entry. A Slack user group (slack_user_group, or its alias slack_group) needs the optional usergroups:read Slack scope so Warpway can see its members; without it, Warpway cannot message the group and moves on to the next candidate.

A rule can name its own owner, the first source Warpway checks for questions that rule raises:

version: 1
rules:
  - id: credits-on-cancellation
    lens: product_semantics
    applies_to:
      paths:
        - billing/**
    instructions: Ask before changing what happens to unused credits when a subscription ends.
    owner: priya@acme.example

An owner can be a GitHub login such as @dana-dba, a GitHub team such as @acme/security, a Slack member ID, or an email address; an email address matches only a person whose verified email it is.

The full list of routing fields is in the configuration reference.

When someone is the wrong person

Anyone can answer I'm not the right person in Slack, or /warpway wrong-person <task ref> on GitHub. Warpway records it, excludes that person from this task, and routes it to the next candidate; the new explanation says who was skipped and why. The answer also lowers that person's expertise on the topic for future questions. A reply that names someone else ("ask Priya") is recorded as a suggestion, never as an automatic reassignment. If the candidates run out, the task becomes unassigned and stays visible.

Correct routing

Admins can reassign any task, edit people's expertise on the People page, and add routing rules in the dashboard. An Admin's correction ranks ahead of every other source for the questions it matches. Corrections apply to future routing and are recorded as feedback, so the same mistake is less likely next time.

Identities

Routing works on people, not accounts. A person can have a GitHub identity, a Slack identity, or both. Slack identities are linked to people only by an explicit link, a verified email match you enabled, or an Admin, never by display name. See Slack installation.