Make your first useful contribution.
Start where you can verify something. A precise bug reproduction or careful documentation fix can be more useful than an ambitious patch nobody can review.
1. Choose a project you can run.
Pick a project whose purpose you understand and whose development environment you can reproduce. Wallet developers might explore BDK; integration developers might start with BTCPay Server documentation; designers can explore the Bitcoin Design community.
Read the project’s contribution guide, issue templates and recent discussions. Look for evidence of how maintainers want help. Check whether somebody already owns the task before investing heavily in the same change.
2. Start with a bounded question.
Examples: Can a fresh installation follow this setup guide? Does this error message explain the next action? Can you reproduce a reported problem on the current version? Each question has an observable result and a small scope.
Keep a local notebook with the repository, commit, environment, commands and result. A failure to reproduce can still be useful if the conditions are clear. Do not turn uncertainty into an assertion that the report is wrong.
3. Learn how review works.
Bitcoin Core PR Review Club and LDK PR Review Club offer past discussions and prepared material. Choose an archived review near your skill level. Inspect the change, run the relevant test and compare your understanding with the discussion.
For Bitcoin Core itself, follow the current contribution instructions. A review should say what you checked: a particular commit, an execution path or a test result. Avoid generic approval comments that add no evidence.
4. Make the contribution easy to assess.
- Explain the concrete problem and how to reproduce it.
- Keep the change focused and avoid unrelated formatting.
- Describe the resulting behavior and relevant tradeoffs.
- Include appropriate tests or a before/after demonstration.
- Respond to feedback with updated evidence.
For a documentation change, run the documented steps. For a design contribution, connect the proposed change to a task and explain its states. For a code patch, understand the modified behavior well enough to answer a reviewer’s questions.
5. Keep a truthful contribution record.
Distinguish proposed, reviewed, merged and released work. Those states mean different things. A useful record includes the public link, your role, the date, what you verified and the outcome. An unmerged contribution can still demonstrate learning, but should be labeled accurately.
When a tool helps produce code or writing, you remain responsible for understanding the submitted work and following the project’s policies. Submit evidence you have checked, and use the project’s disclosure process for sensitive security findings.
A realistic first contribution plan
Use your first sessions to set up the project and reproduce a documented example. Next, investigate one bounded issue or review exercise. Then prepare a small contribution with its evidence. Leave room for maintainers’ response times; a merge is not something a newcomer can schedule unilaterally.
Once you have a body of useful public work, compare the funding programs with your actual experience and intended contribution.
Keep the evidence.
Download a worksheet to record what you tried, what happened and what you would improve.
Download evidence worksheet ↓