No-Install First PRs
These tasks can be started in the GitHub web editor. They are useful for contributors who can review Korean/Japanese wording, learner notes, setup docs, or beginner dialogue content but do not want to install Expo, FastAPI, local STT/TTS engines, or generated voice assets.
Choose a focused change that improves the learner experience or the project. Keep related corrections together instead of splitting trivial typos across separate PRs.
How To Send A Browser-Only PR
- Pick one issue from the table below.
- Comment
/claimon the issue if you want to avoid duplicate work. - Open the linked source file.
- Click the pencil icon on GitHub, or use the direct edit link.
- Make one focused improvement.
- Use a PR title like
docs: improve Korean backend mock quickstart. - In the PR body, write
Closes #ISSUE_NUMBERand mention that the change is docs/content review.
No command-line check is required for plain wording review. If you edit
story.json or variants.csv, CI runs Dialogue Pack Sources automatically
to validate schema, stable IDs, references, and safety; keep the existing
structure unchanged. YAML and TypeScript edits still need the relevant project
check when practical.
Useful issue searches:
first-timers-only:https://github.com/duct-tape2/ai-language-partner/issues?q=is%3Aissue+is%3Aopen+label%3Afirst-timers-onlyup-for-grabs:https://github.com/duct-tape2/ai-language-partner/issues?q=is%3Aissue+is%3Aopen+label%3Aup-for-grabs
The generated issue-comment text is tracked in
NO_INSTALL_FIRST_PR_COMMENTS.md.
For the shortest path with PR title/body examples, use the five-minute first PR guide. For Japanese/Korean wording, dialogue, or cultural-safety review, use the language review first PR kit.
Best Browser-Only Issues
| Issue | Good PR shape | Source file | Direct edit link |
|---|---|---|---|
| #1: Korean quick-start for backend mock mode | Add or clarify Korean setup notes for running the backend in mock mode | docs/backend/API_RUNBOOK.md |
edit |
| #2: Japanese quick-start for mobile mock mode | Add Japanese notes for running the mobile app without local engines | docs/ja/index.md |
edit |
| #3: whisper.cpp setup on macOS | Clarify ffmpeg, model path, env vars, and fallback behavior for local STT setup | docs/backend/API_RUNBOOK.md |
edit |
| #4: AivisSpeech and VOICEVOX-compatible setup | Clarify local TTS engine process setup, licensing boundaries, and the /speakers probe |
docs/backend/API_RUNBOOK.md |
edit |
| #5: architecture glossary for dialogue-bank terms | Define learner-facing terms such as dialogue bank, pack, node, line, fallback | docs/ARCHITECTURE.md |
edit |
| #6: API curl examples for Daily Talk endpoints | Add curl examples for packs, match, unmatched, voices, and provider status | docs/backend/API_RUNBOOK.md |
edit |
| #7: yui v1 Korean translation review | Review beginner Korean translations without touching generated audio | packs/yui/v1/story.json |
edit |
| #8: yui v1 Japanese naturalness review | Review Japanese dialogue for natural beginner-safe wording while keeping line IDs stable | packs/yui/v1/story.json |
edit |
| #11: Korean learner notes on particle mistakes | Add concise Korean notes about common Japanese particle mistakes | docs/ko/index.md |
edit |
| #12: cultural note review checklist | Add a short checklist for reviewing cultural notes without stereotypes or overgeneralization | docs/community/CONTRIBUTOR_LANDING.md |
edit |
| #16: mock mode indicators | Document how fixture-backed mock mode differs from live API-backed mode | docs/ARCHITECTURE.md |
edit |
| #18: Korean UI string consistency | Review Korean labels and suggest consistent wording | apps/mobile/src/i18n.ts |
edit |
| #19: provider-status example response | Add example /v1/providers/status responses for mock, fallback, and local engine modes |
docs/backend/API_RUNBOOK.md |
edit |
| #20: dialogue match threshold explanation | Explain match, confirm, and fallback thresholds in learner-friendly language | docs/ARCHITECTURE.md |
edit |
| #23: Redis rate-limit optional setup | Document optional Redis rate-limit setup for local and production use without exposing secrets | docs/backend/API_RUNBOOK.md |
edit |
| #24: OpenAPI examples for auth device trust | Add or improve OpenAPI examples for self-attested and public-key device trust flows | contracts/openapi_v0.yaml |
edit |
| #29: issue-label taxonomy document | Clarify when to use each public issue label | docs/community/LABELS.md |
edit |
| #31: no-runtime-LLM FAQ | Add a short FAQ answer explaining the local-first dialogue-bank design | docs/index.md |
edit |
| #34: Korean backend dependency troubleshooting | Add Korean troubleshooting notes for Python dependency install failures | docs/backend/API_RUNBOOK.md |
edit |
| #35: Japanese no-runtime-LLM design explanation | Add neutral Japanese explanation of cost, privacy, latency, and quality-control tradeoffs | docs/ja/index.md |
edit |
| #36: restaurant preference examples | Add beginner-safe examples for expressing restaurant preferences | packs/yui/v1/variants.csv |
edit |
| #41: provider fallback labels | Explain honest provider labels such as mock and voicevox_compat_fallback_* |
docs/backend/API_RUNBOOK.md |
edit |
| #44: first PR walkthrough | Improve this repo’s first-PR instructions for new contributors | docs/community/FIRST_PR_WALKTHROUGH.md |
edit |
| #45: maintainer review checklist | Improve the checklist maintainers use before merging focused external PRs | docs/community/MAINTAINER_PR_REVIEW_RUNBOOK.md |
edit |
| #46: Korean notes for sentence-final particles | Add beginner-safe Korean explanations for よ, ね, よね, and かな | docs/ko/index.md |
edit |
| #47: cultural-safety review examples | Add examples of stereotype-prone or context-sensitive wording to review carefully | apps/mobile/src/culture/cultureNotes.ts |
edit |
| #50: dialogue-bank pack roadmap | Add a public roadmap for persona, topic, JLPT, and language-review pack areas | docs/community/CONTRIBUTOR_GROWTH_PLAN.md |
edit |
Review Notes
- Keep changes small and issue-linked.
- Do not add
.wav,.zip,.npy,.sqlite, screenshots, local engines, or private files. - Avoid generated text dumps. Human language review and clear docs are the point of this lane.
- If a file looks too technical, ask in the First PR help desk.