RoadmapsProjects
Sign in./start

Learn

RoadmapsProjects

Contribute

DiscoverIssuesOpen Source Guide

Account

Sign in./start-building

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

Learn

RoadmapsProjectsStart Building

Contribute

DiscoverIssues

Account

Sign inDashboardSettings

Legal

PrivacyTermsCredits

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

PrivacyTermsCredits

lesson // lightning

Code Review Practice

Review peer pull requests on Lightning implementations and learn maintainer expectations.

intermediate5 days

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

./sign-in

On this page

Learning objectives

  • Review diffs for correctness, tests, and clarity
  • Leave actionable comments without noise
  • Connect chapter concepts to real implementation changes

study // plan

Lessons are primers. Depth comes from required reading, interactive labs, reflection, and a hands-on check with evidence — the BOSS study pattern.

Research on Bitcoin Search

Reflection prompts

  1. Explain Code Review Practice to a teammate without jargon — what problem does it solve?
  2. What would break in production if you misunderstood Code Review Practice?
  3. Which implementation doc is authoritative for the repo you reviewed, and what did you verify there?

Lab // Contribution artifact

Produce a contribution artifact for Code Review Practice: pick a Review Club PR, leave a constructive comment (or draft review notes), and paste the URL in your evidence.

evidence required

  • ·GitHub PR or issue URL reviewed
  • ·Written review notes using the meaningful-PR checklist
  • ·Link to /discover or /issues if you shortlist follow-up work
  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.

Reviewing is how Lightning implementations stay safe. You will learn more from careful review than from rushing another feature PR.

Use Pull's Review Club picks on this lesson, or browse open issues filtered for Lightning tracks.

What to check

  1. Does it solve the claimed problem?
  2. Are there tests?
  3. Are edge cases handled?
  4. Is the diff minimal?

Loading diagram…

Description → diff → tests → informed ACK or change request.

Be precise

Prefer "This breaks HTLC timeout handling because X" over "Hmm not sure."

Tie reviews to what you learned

When reviewing channel, routing, or BOLT changes, name the concept explicitly: inbound capacity, preimage flow, onion privacy, etc. Maintainers reward reviewers who connect behavior to protocol rules.

Next steps

Score your own future PRs with the contribution rubric before opening them.

further reading

  • docsLND CONTRIBUTING
  • articleConventional comments
  • docsCore Lightning CONTRIBUTING

review // club

Review club

Practice on real Lightning OSS changes tied to this chapter. Read the diff, use the checklist, and optionally paste your review comment URL in your lab notes.

  • Recent LND PR for review practice

    Pick a small open PR and leave a conventional comment on one concrete improvement.

    pr review
    correctnesstestsscope
    45 min·intermediateopen on GitHub
review checklist
  1. Does the change solve the stated problem?
  2. Are edge cases and rollout behavior covered?
  3. Are tests or test vectors included?
  4. Is the diff minimal and clearly explained?

More repos and GFIs on /discover and /issues.

progress // sign in

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

./sign-in-to-track
prevContribution DiscoverynextContribution Rubric

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.