Your first pull request is not judged only by the code. Maintainers also look at the description, the tests, the size of the change, and how you respond when they ask questions.

That may sound intimidating, but most of it comes down to making the review easy. A small, focused fix with a clear description, any expected tests, and respectful responses to feedback gives the maintainer confidence. The code matters, but the way you present and handle the pull request often determines how smoothly it moves.

A good first pull request does three things: it follows the project's rules, explains the change clearly, and handles review well.

Following the rules starts with the contribution guide. Many active projects have a CONTRIBUTING.md file or a section in the README that explains how to set up the project, run tests, format commits, and open a pull request. Read it before you start. It saves both you and the reviewer time.

Explaining the change means writing a description that answers the reviewer's basic questions: what changed, why it changed, and how to test it. Reviewers are busy. If they can understand the pull request quickly, it is easier for them to review.

Handling review means treating feedback as part of the process, not as a personal judgment. A maintainer may ask for tests, a different style, a smaller change, or a different approach. That is normal. Responding clearly and making reasonable changes gives the pull request a much better chance of moving forward.

Remember that the maintainer is responsible for the health of the project. Their questions and requests usually come from that responsibility. Make the review easy to follow, keep the change focused, and stay calm and respectful in the back-and-forth.

The path from idea to merge looks like this. The review step is a loop, not a single gate. A maintainer may ask for changes more than once before the pull request is ready.

The steps below walk through the process in order.

Read the contribution guide first

Find CONTRIBUTING.md or the contributing section in the README. Look for setup steps, branch naming, commit format, test commands, linters, and any pull request checklist. Follow the project's instructions even if they differ from how you usually work.

Fork, branch, and name the branch sensibly

Fork the repository, create a branch from the default branch, and give it a descriptive name like fix-quickstart-flag instead of patch-1. Keep your change focused on the issue you claimed. Do not mix unrelated cleanup or formatting changes into the same pull request.

Make the change and match the existing style

Write your fix so it looks like the code around it: same patterns, naming, formatting, and level of abstraction. A pull request that matches the project style is easier to review. Run the project's formatter or linter if one exists.

Write commit messages in the project's convention

Some projects use a specific commit format. Others are more casual. Check the contribution guide and recent commit history. Use a clear summary that explains the change in plain language.

Add or update tests where the project expects them

For a bug fix, the best test is one that would fail before your change and pass after it. For documentation-only changes, tests usually are not needed. If you are unsure, look at nearby code or similar pull requests to see what the project expects.

Write a pull request description that explains the change

Use the template below: what changed, why it changed, how to test it, and screenshots if the change affects the UI. Link the issue it closes. Your goal is for a reviewer to understand and verify the change without having to guess.

Respond to review clearly

When a maintainer requests changes, make them when reasonable and reply briefly when you have pushed the update. If you disagree, explain your reasoning once and stay open to their decision. If the maintainer goes quiet, one polite follow-up after a week or two is fine. Repeated reminders usually do not help.

A clear description answers the questions a reviewer is likely to ask. This structure works for most first pull requests.

Why this works: It explains what changed, why it matters, and how to verify it. Linking the issue with "Closes #123" ties the pull request to the original discussion and can close the issue automatically when the pull request is merged.

How you handle the review tells maintainers what it would be like to work with you again. Here is the difference.

Poor response:

Strong response:

Why the strong response works: It treats the request as part of the review process, makes the change, and confirms what was updated. The poor response may be understandable, especially when you are new, but it makes the reviewer spend more energy defending a reasonable request. When you genuinely disagree, explain once, politely, and let the maintainer make the final call.

Each item below costs you an extra review round-trip, turning a one-day merge into a week of back-and-forth before a maintainer even looks at the code.