Choose a bounded problem.
One failure, one missing behaviour, or one piece of documentation is enough. State what is outside the change too.
Contributing / practical work
Make one change. Show why it works.
The most useful contribution is not the largest one. It is a focused change with a reproducible problem, a clear boundary, and enough evidence for another person to review it.
Before writing code
Start where the work is visible.
Check the repository README and open issues first. If the scope is unclear, start a public discussion before spending a day on an implementation that may not fit the project.
Reproduce it first.
Record the platform, build, steps, expected result, and actual result. A failure that cannot be repeated is hard to fix safely.
Find the repository contract.
Build commands, formatting, tests, and platform requirements belong to each repository. Its README and contribution files are the source of truth.
The review contract
Leave a trail another engineer can follow.
A pull request should reduce uncertainty, not move it into the reviewer’s hands.
Name the behaviour.
Describe the user or engine problem in plain language, link the relevant issue, and explain why this scope is the right size.
Run the smallest honest test.
Use a focused automated test when possible. For UI or real-site work, include the exact journey and the evidence that was inspected.
Say what helped produce it.
If AI assisted the work, say where it was used. The contributor still owns the code, the verification, and every claim in the change.
Ready for review
Small, tested, and honest about the gaps.
Before opening a pull request, remove unrelated changes, run the repository’s checks, and describe anything you could not verify. Screenshots help with visual work; retained logs and test output help with engine work.
Review may change the design or reject the approach. That is part of building a browser in public, not a failure of the contribution.