External Contributor Issues

External contributor issue picker (Axelix)

Help maintainers shortlist open GitHub issues that are a good fit for external contributors: people donating spare time, with limited insider context, who want work that feels worth doing—not unpaid project maintenance.

This skill does not replace code review or maintainer judgment. It produces a reasoned candidate list; a human should still confirm scheduling, design direction, and “are we OK if this never ships.”

Audience assumptions (read before scoring)

Treat every candidate issue as if the assignee is:

1. Unpaid and asynchronous — They may stop mid-flight or never open a PR. The project must not depend on them for a date or a release.
2. Low tribal knowledge — They do not know historical decisions, internal naming, or which modules secretly interact. Prefer work that is locally understandable from the issue text plus nearby code/docs.
3. Motivation-sensitive — They opted in for something interesting or compelling. Chores, mechanical refactors, backports, and “just align with X” tasks are poor fits unless the write-up reframes them as a clear, rewarding problem (rare).

Rubric — three gates (all should lean “yes”)

When scoring or ranking issues, apply these gates. If an issue fails a gate hard, it usually should not be recommended for volunteers (or needs rewriting first).

Gate A — Local context (“can a newcomer find the edges?”)

Prefer issues where:

• The surface area is bounded: one app area (front-end/, master/, one sbs/ module, docs/), or a small number of files with obvious entry points.
• The issue states acceptance criteria or repro steps so someone can tell when they are done without a design meeting.
• Discovery work is hours, not days of archaeology across the whole monorepo.

Be cautious when:

• The ticket assumes cross-cutting changes (security, auth, deployment, shared protocol between master and starters) without a spelled-out plan.
• It references undocumented contracts, private services, or “ask the team in Slack” workflows.

Verdict: Favor issues you can summarize as: “If you read these paths and the issue, you mostly understand the task.”

Gate B — Stakes (“nice to have,” not release load-bearing)

Prefer issues that are clearly optional quality, polish, developer experience, small user-visible improvements, or isolated enhancements where slipping or abandoning the work does not block the core team.

Deprioritize for volunteers when:

• The issue is tied to a near-term milestone or reads like release gating (“must ship in vX”, “blocker”, “P0”).
• It is labeled or described as security, data loss, production outage, or compliance unless maintainers explicitly want community help and have scoped it tightly.
• Assignees or project fields show it is actively owned by the core team for an imminent deliverable.

Verdict: Favor “we’d love this” over “we need this by Tuesday.” When unsure, ask the maintainer or mark the issue as conditional in your report.

Gate C — Interest (“would a volunteer thank you for the suggestion?”)

Strong fits often look like:

• A small feature with a visible result (UI improvement, better error message, CLI output, docs that teach a real workflow).
• A bug with repro and a plausible localized fix.
• Tooling that makes developers or users happier in an obvious way.

Poor fits for unprompted volunteer routing:

• Refactors for consistency only, renames across the tree, dependency bumps without a motivating bug/feature.
• Backports or “match behavior in other module” mechanical work.
• Test-only churn or mass formatting unless the issue explains a concrete payoff (flaky test fixed, coverage for a known regression).

Verdict: If the issue title sounds like homework, do not push it to volunteers without maintainer consent and a reframed description.

Heuristics from metadata (GitHub labels, milestones, text)

Use labels and titles as weak signals—always reconcile with the issue body and quick code search when possible.