# A Credible Path To 10,000 Stars
Ten thousand stars cannot be engineered as a release checkbox. They can be earned by making one promise unusually clear and dependable: **15 focused minutes a day to become productive in another programming language, entirely from the terminal.**
This plan uses public project signals and opt-in feedback. Practicode will not add in-app analytics, accounts, streak pressure, referral popups, or telemetry to chase a vanity metric.
## Product Standard
Before promotion, every release should preserve:
- a one-command install that does not compile Rust;
- a useful first session in under one minute;
- executable, independently reviewed curriculum copy in all five UI languages;
- deterministic offline mastery, review, and judging;
- a responsive `60x16` minimum-terminal experience and clear keyboard help;
- transparent AI/privacy boundaries;
- reproducible release assets and checksums.
Stars follow retention and trust. If those standards regress, pause promotion and fix the product.
## Milestones
| 0 → 1,000 | 0.2.0 prebuilt install, polished 30-second demo, clean first session | Coordinated launch post with one promise and one command | Fast bug triage, label precise starter issues |
| 1,000 → 3,000 | Publish opt-in learner stories and lesson corrections | Technical posts comparing one concept across four languages | Document the lesson-review workflow; recognize contributors in releases |
| 3,000 → 10,000 | Stable releases, public curriculum quality report, strong install reliability | Educator/team case studies, conference demos, translated launch material | Recurring focused correction/accessibility sprints without expanding scope |
## Launch Package
Each announcement should contain only what a developer needs to decide in 30 seconds:
1. The 15-minute switching-languages promise.
2. A short terminal recording showing Predict → Exercise → Result → review scheduling.
3. `npm install -g practicode && practicode`.
4. Four concrete trust facts: 110 lessons, 337 cases, five localized curricula and core learning loops, no account/telemetry.
5. One focused request: try a language you already know and report the first inaccurate or awkward lesson.
Reuse the same factual launch package on the GitHub release, project website/readme, developer communities, and social posts. Change the introduction for each audience; do not manufacture engagement or mass-post identical spam.
## Feedback Flywheel
- Turn a precise report into a small, linked issue within 48 hours when possible.
- Add a regression case before changing executable lesson behavior.
- Record independent content review and exact hashes in the manifest.
- Ship a concise release note that names the corrected learner outcome.
- Invite the reporter to verify the fix, without asking for a star.
This converts attention into visible product quality and makes future contributors confident that lesson corrections are taken seriously.
## Privacy-Safe Scoreboard
Review monthly using only public or opt-in evidence:
- GitHub stars, forks, contributors, issue response time, and release downloads;
- npm and crates.io public download counts;
- CI/release success rate and launcher failure reports;
- opt-in survey answers for first-session completion and seven-day return;
- number and severity of independently verified lesson corrections.
Do not infer learner behavior from local progress files or add telemetry. A large star count with broken installs, unresolved lesson errors, or slow triage is not success.
## Scope Guardrails
Until the four existing courses show strong completion evidence, do not dilute the product with extra languages, cloud sync, social leagues, plugin marketplaces, or streak mechanics. Improve lesson accuracy, onboarding, accessibility, release reliability, and contributor turnaround first.