Designing first PRs that do not require a local environment

duct-tape2 — Fri, 10 Jul 2026 05:10:23 +0000

A "good first issue" is not actually beginner-friendly if a contributor must install a mobile app, an API, two speech engines, and model files before changing one sentence.

I ran into this while preparing ai-language-partner, a local-first Japanese speaking practice app for Korean learners. The full stack includes Expo/React Native, FastAPI, local STT, local TTS, and pre-authored dialogue packs. That is useful for the product, but it is a poor prerequisite for someone's first pull request.

Separate contribution lanes by setup cost

I split the work into three lanes:

Browser-only: wording, documentation, API examples, accessibility copy, Korean/Japanese review, and dialogue content.
Standard development: Expo or FastAPI changes with focused package-level checks.
Full local voice stack: work that genuinely needs STT/TTS engines and generated assets.

The browser-only lane is not a typo farm. Each task has user value, a linked issue, a source file, acceptance criteria, and a direct GitHub edit link.

Make the next action explicit

Each no-install task tells a contributor:

where the source file is
what a useful pull request looks like
how to claim the issue
what title and closing reference to use
when no local test is required
where to ask for help

The project currently has 27 browser-only tasks within 52 scoped public issues.

Automate guidance, not judgment

Automation responds to a claim command, posts a first-PR guide, and prepares a review packet. It does not decide whether a contribution is meaningful.

The maintainer still checks:

user value
issue linkage
focused scope
honest authorship
tests where applicable
no trivial pull-request splitting

Count people only after useful work merges

I am intentionally not optimizing for raw PR volume. One contributor with one useful merged PR counts. Maintainer-authored PRs, bots, duplicate identities, and split typo PRs do not.

That policy makes growth slower, but the public contribution record is real and auditable.

What I am testing next

The open question is whether reducing setup cost is enough to turn discovery into completed contributions. I am tracking claims, opened PRs, review latency, and merged external contributors rather than only stars.

The repository and hosted demo are public:

If you maintain a project with a heavy local setup, which tasks have worked well as genuinely useful browser-only contributions?