Feature proposal: label-based issue routing groups

[brokemac79]

Summary

Proposal for a lightweight issue-routing layer in ClawSweeper.

The goal is not to add another label scheme. OpenClaw already has useful labels such as channel:*, app:*, extensions:*, gateway, cli, agents, docs, priority labels, impact labels, and the newer clawsweeper:* advisory labels.

This proposal is to use those existing labels to group stale or unpicked issues into maintainable area queues.

Short version:

• use existing labels as the source of truth
• add a routing map/config that groups labels into broad areas
• start with dashboard/grouped views only
• add dry-run reports before any notification behavior
• make Discord routing optional and off by default
• do not auto-assign people or ping individuals
• do not route issues immediately after creation
• skip issues that already have linked PRs or recent activity

Why

The current label data is useful, but the issue queue is still large.

For example, an issue might already have:

• channel: telegram
• P1
• clawsweeper:needs-maintainer-review

That tells us the issue probably belongs in a Messaging queue and needs human review, but today it still sits in a broad global issue list unless someone actively filters for it.

The proposed routing layer would turn existing labels into smaller queues such as:

• Messaging needs maintainer review
• Frontend queueable fixes
• Runtime P1/P2 issues
• Providers product decisions
• Docs needs info

Proposed flow

flowchart TD
    A["Issue opened"] --> B["ClawSweeper reviews issue"]
    B --> C["Existing labels applied"]
    C --> D["Routing map groups labels"]
    D --> E["Area queues"]
    E --> F["Dashboard views"]
    E --> G["Optional Discord channels later"]

Loading

The routing map would be internal config. It would not create new GitHub labels.

Example

flowchart LR
    A["Issue: Telegram reply bug"] --> B["channel: telegram"]
    A --> C["P1"]
    A --> D["clawsweeper:needs-maintainer-review"]

    B --> E["Area: Messaging"]
    C --> F["Priority: High"]
    D --> G["State: Needs human review"]

    E --> H["Messaging / Needs Review queue"]
    F --> H
    G --> H

Loading

Example routing map

This is illustrative only. The exact groups and labels should be maintainer-owned.

groups:
  messaging:
    labels:
      - channel: telegram
      - channel: discord
      - channel: slack
      - channel: whatsapp-web
      - channel: signal

  frontend:
    labels:
      - app: web-ui
      - app: android
      - app: ios
      - app: macos
      - tui

  runtime:
    labels:
      - gateway
      - cli
      - agents
      - docker

  providers:
    labels:
      - extensions: openai
      - extensions: anthropic
      - extensions: google
      - extensions: openrouter

  docs:
    labels:
      - docs

Pickup delay / avoid duplicate work

Routing should not happen immediately. Contributors sometimes open an issue first and then create the fix PR themselves.

Recommended behavior:

• wait 24 hours before routing by default
• skip if a linked PR appears
• skip if the issue is closed
• skip if there is recent author activity
• skip if there is recent maintainer activity
• skip if the area cannot be detected confidently

flowchart TD
    A["Issue opened"] --> B["Wait period"]
    B --> C{"Linked PR appeared?"}
    C -->|Yes| D["Skip routing"]
    C -->|No| E{"Recent useful activity?"}
    E -->|Yes| D
    E -->|No| F{"Still needs attention?"}
    F -->|No| D
    F -->|Yes| G["Route to area queue"]

Loading

Candidate eligibility

flowchart TD
    A["Candidate issue"] --> B{"Issue open?"}
    B -->|No| Z["Skip"]

    B -->|Yes| C{"Older than delay?"}
    C -->|No| Z

    C -->|Yes| D{"Linked PR exists?"}
    D -->|Yes| Z

    D -->|No| E{"Recent author or maintainer activity?"}
    E -->|Yes| Z

    E -->|No| F{"Confident area match?"}
    F -->|No| Z

    F -->|Yes| G{"Useful ClawSweeper state?"}
    G -->|No| Z
    G -->|Yes| H["Route"]

Loading

Useful ClawSweeper states could include:

• clawsweeper:needs-maintainer-review
• clawsweeper:needs-product-decision
• clawsweeper:needs-security-review
• clawsweeper:needs-live-repro
• clawsweeper:needs-info
• clawsweeper:queueable-fix

Optional Discord routing

If dashboard grouping proves useful, a later phase could route stale/unpicked issues into opt-in Discord channels.

This may need new channels within the maintainers area/group rather than public project-wide channels. The exact Discord shape should be decided by maintainers/admins based on how they want attention to flow.

Possible maintainer-group channels:

#maintainers-triage-messaging
#maintainers-triage-frontend
#maintainers-triage-runtime
#maintainers-triage-providers
#maintainers-triage-docs
#maintainers-triage-security

Or, if the project wants broader contributor visibility later:

#triage-messaging
#triage-frontend
#triage-runtime
#triage-providers
#triage-docs
#triage-security

These should be attention streams, not ownership or assignment. People can join or mute the channels they care about. No pings or role mentions in v1.

A lower-noise first Discord mode could be a scheduled digest/link post instead of one message per issue. For example, every 8 hours ClawSweeper could post a short summary and a hyperlink to the relevant dashboard/GitHub filtered view for currently unassigned or unpicked items:

Messaging triage queue update

8 unassigned/unpicked issues need attention:
- 3 need maintainer review
- 2 need product decision
- 2 need live repro
- 1 is queueable but has no linked PR

Open queue: https://clawsweeper.openclaw.ai/triage?group=messaging&status=unpicked

This keeps Discord as an attention signal while avoiding per-issue message spam. Individual issue posts could remain a later option if maintainers prefer them.

Example message:

Issue needs Messaging eyes

#83521 [Bug] Telegram thread replies stop posting
https://github.com/openclaw/openclaw/issues/83521

Why routed:
- Area: Messaging (`channel: telegram`)
- State: needs maintainer review
- Priority: P1
- Age: 28h
- No linked PR found

ClawSweeper summary:
Source-reproducible path exists, but maintainer decision is needed before a fix should be queued.

GitHub-only fallback

If Discord routing feels too noisy or too process-heavy, this could stay GitHub-only:

• grouped dashboard views
• scheduled dry-run report artifacts
• weekly Markdown digest
• optional digest comments on a single tracking issue

Relationship to gitcrawl

Vincent pointed at openclaw/gitcrawl and the gitcrawl portable-store/field-notes model. This proposal should not duplicate that work.

From a quick read, gitcrawl already provides the local-first GitHub mirror/search layer: SQLite sync of issues and PRs, labels, authors, comments, PR details, local search, clustering, durable local governance, and portable stores for sharing a refreshed cache across agents or machines.

That overlaps with the data/source side of this proposal, especially:

• finding open issues by label/state without repeatedly spending GitHub Search quota
• keeping a shared snapshot of what the project knew at a point in time
• powering grouped dashboard views from a local/cache-backed source
• producing dry-run reports from structured issue/PR data

The remaining gap this proposal is trying to explore is the routing/product layer on top:

• maintainer-owned area grouping config
• ClawSweeper dashboard views for unpicked/unassigned queues
• optional digest/link posts into maintainer Discord channels
• no new labels, no auto-assignment, no per-issue spam by default

Implementation-wise, phase 1 should check whether gitcrawl/portable-store data can be used as the backing read model before adding any new GitHub crawler logic to ClawSweeper.

Suggested rollout

flowchart LR
    A["Phase 1: Dashboard grouping"] --> B["Phase 2: Dry-run routing report"]
    B --> C["Phase 3: Discord digest/link posts, no mentions"]
    C --> D["Phase 4: Optional role mentions"]
    D --> E["Phase 5: Optional assignment"]

Loading

Phase 1: Dashboard grouping only

• add routing-group config
• map existing labels into broad groups
• add grouped views/counts to the issue triage dashboard
• show matched group and matched labels on each issue
• no Discord posting
• no assignments
• no new labels

Phase 2: Dry-run routing report

Report what would have been routed, without posting anywhere.

Example:

Would route:
- 12 issues to Messaging
- 5 issues to Frontend
- 3 issues to Runtime

Skipped:
- 8 had linked PRs
- 4 had recent author activity
- 2 had no confident area

Phase 3: Discord digest/link posts, no mentions

Only after dry-run reports look useful. Posting should be disabled by default and enabled through repo variables. The first live mode could be an 8-hour digest/link post to the relevant area channel, rather than one Discord message per issue.

Phase 4: Optional role mentions

Only if maintainers explicitly want it.

Phase 5: Optional assignment

Assignment should be a later policy decision, not part of the first implementation.

Non-goals

• Do not add a new area:* label scheme in v1.
• Do not auto-assign issues.
• Do not ping individual maintainers.
• Do not replace existing ClawSweeper labels.
• Do not route issues immediately after creation.
• Do not route issues that already have linked PRs.

Open questions

1. Do these broad groups feel right?
2. Should phase 1 be dashboard-only?
3. Is 24 hours a reasonable routing delay?
4. Which ClawSweeper states should qualify for routing?
5. Would Discord channels be useful, and should they live inside the maintainer group first, or should this stay GitHub-only?
6. Should Discord start as an 8-hour digest/link to unassigned or unpicked queues, rather than individual issue posts?
7. Should channels ever mention roles, or should they remain silent feeds?