Feedback
Sign in./start

Site navigation

Theme

Learn

  • Roadmaps

Build

  • Projects
  • Developer Tools

Contribute

  • Open Source Projects
  • Issues
  • Reviews
  • First Contribution
  • BountiesSoon
  • Feedback

Prove

  • Builders

Ecosystem

  • Partners
  • Get Funded↗
  • HackathonsSoon
Sign in./start-building

Become an Open Source Builder. Learn. Build. Contribute. Prove.

Feedback welcome — open a GitHub issue.

Learn

RoadmapsStart Building

Build

ProjectsDeveloper Tools

Contribute

Open Source ProjectsIssuesReviewsFirst ContributionSupportFeedback

Prove

Builders Directory

Account

Sign in

Legal

PrivacyTermsCredits

© 2026 Pull // code MIT · curriculum CC BY-SA 4.0

PrivacyTermsCredits

lesson // bitcoin

Contribution Rubric

Shared bar for a meaningful first open-source contribution on Pull - scope, quality, and maintainer-ready communication.

intermediate3 days

Public lesson — sign in to track progress on this roadmap.

./sign-in

On this page

Learning objectives

  • Score a contribution attempt against an explicit meaningful-PR rubric
  • Separate docs/tests/good-first issues from drive-by noise
  • Write maintainer-ready issue comments and PR descriptions

study // plan

Lessons are primers. Start with Step 1 (required reading) when present, then follow the numbered steps in the article. Depth comes from primary sources, labs, reflection, and evidence.

Research on Bitcoin Search
contribution qualitymeaningful PRreview rubric

Step 1 // Required reading

Complete these before the numbered steps in the lesson body. Links are listed here once — not repeated below.

  • docsBitcoin Core CONTRIBUTING
  • articleConventional comments

Reflection prompts

  1. Which rubric rows would your last (or planned) PR fail today, and how will you fix them before asking for review?
  2. What evidence would convince a maintainer this change is safe to land?
  3. How will you respond to a NACK or request for deeper tests without derailing?

Lab // Rubric self-score

Complete Steps 2–3. Pick a real issue on a Bitcoin or Lightning repo. Write a one-page plan and self-score it 0–2 on each rubric row before coding (or before requesting review).

evidence required

  • ·Issue URL and your approach doc
  • ·Rubric score table (0–2 per row) with notes
  • ·Draft first issue comment or PR body
  1. 01

    Worked mental model

    Re-read the diagrams in this lesson once out loud in plain language. If you cannot explain the flow to a friend without jargon, pause and revisit the Mastering Bitcoin / Mastering Lightning chapters linked in Resources. Chapter references are intentional, not decorative.

  2. 02

    Hands-on habit

    Every protocol idea should be paired with one local experiment. That habit turns reading into builder instinct.

    1. Reproduce the happy path on regtest (or Polar for Lightning)
    2. Break it on purpose (wrong fee, expired invoice, offline peer)
    3. Write down what error you saw and which layer produced it (wallet, node, mempool, peer)
  3. 03

    Glossary check

    Pick three terms from this lesson and define them in one sentence each without opening notes. Weak definitions mean the lesson is not finished yet.

  4. 04

    Resource order

    Use Resources in order: narrative book chapter first, then BIP/BOLT for precision, then implementation docs for commands. Jumping straight to RPC flags without the mental model creates brittle knowledge.

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

Row012
Problem fitVague / wrong repoPlausible issueConfirmed with maintainers or clear GOOD FIRST ISSUE + skill match
ScopeKitchen-sinkSlightly wideMinimal diff that solves one stated problem
CorrectnessUntested claimManual check onlyAutomated test, scripted repro, or documented verification steps
CommunicationDrive-by dumpBasic descriptionContext, motivation, alternatives, and how to review
CitizenshipIgnores guideSkims CONTRIBUTINGFollows CONTRIBUTING, style, CI, and review norms

Ship bar: total ≥ 8/10 before you request maintainer review.

further reading

  • articleBitcoin Optech: Contribution culture

progress // sign in

Reading is public. Sign in to mark lessons complete, sync across devices, and unlock your roadmap.

./sign-in-to-track

discussion

Discussion

prevCode Review PracticenextMaintainer Collaboration

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.

When you submit contribution progress on Pull, include:

  1. Issue / PR URLs
  2. Rubric self-score
  3. What you tested (commands, CI link, or Polar/regtest notes)
  4. Open questions for reviewers

Docs and tests count

Documentation, vectors, and test coverage are first-class contributions — often better first PRs than consensus code.

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.

No questions yet — be the first to ask.