A meaningful PR is not measured by lines changed. It is measured by clarity, testability, and respect for maintainer time — the same bar Btrust/Chaincode-style BOSS programs expect.
Complete Step 1 // Required reading in the study plan above, then continue here.
Step 2 — Context: the ship bar
| Row | 0 | 1 | 2 |
|---|---|---|---|
| Problem fit | Vague / wrong repo | Plausible issue | Confirmed with maintainers or clear GOOD FIRST ISSUE + skill match |
| Scope | Kitchen-sink | Slightly wide | Minimal diff that solves one stated problem |
| Correctness | Untested claim | Manual check only | Automated test, scripted repro, or documented verification steps |
| Communication | Drive-by dump | Basic description | Context, motivation, alternatives, and how to review |
| Citizenship | Ignores guide | Skims CONTRIBUTING | Follows CONTRIBUTING, style, CI, and review norms |
Ship bar: total ≥ 8/10 before you request maintainer review.
When you submit contribution progress on Pull, include:
- Issue / PR URLs
- Rubric self-score
- What you tested (commands, CI link, or Polar/regtest notes)
- Open questions for reviewers
Done when: You can recite the five rows and the ≥ 8/10 ship bar.
Step 3 — Practice: score your plan (lab)
Pick a real issue. Write a one-page approach. Score each row 0–2 with notes. Draft the issue comment or PR body you would post.
Checklist / anti-patterns
- No drive-by refactors unrelated to the issue
- No “LGTM” without reading
- No demanding merge timelines
- No mainnet experiments as “proof”
Done when: Lab evidence (issue + score table + draft comment/PR) is complete.
Next lesson
Maintainer Collaboration — take a substantive contribution through feedback cycles.