Open Source Contribution English: PRs, Issues, and Community Interaction

Introduction

Contributing to open source projects is an excellent way to build your portfolio, improve your skills, and connect with the global developer community. However, open source communication happens almost entirely in written English, and the norms can be confusing if you are not familiar with the vocabulary and etiquette. A well-written issue or pull request signals that you are a professional contributor worth collaborating with. A poorly written one may be ignored or closed, even if the underlying work is excellent. This guide teaches you the language of open source collaboration.

Issue Etiquette: Reporting Bugs and Requesting Features

Before you open an issue, always search existing issues to make sure yours has not already been reported. Duplicate issues frustrate maintainers and slow down triage.

A good bug report follows a clear structure. Almost all major open source projects use the same three sections:

• Steps to reproduce: A numbered list of exactly what you did before the bug appeared.
• Expected behaviour: What you thought would happen.
• Actual behaviour: What actually happened instead.

Example of a well-written bug report:

Steps to reproduce:

1. Install version 3.2.1 of the package.
2. Call client.connect() with a timeout value of 0.
3. Observe the terminal output.

Expected behaviour: The client should throw a TimeoutError immediately.

Actual behaviour: The client hangs indefinitely without throwing an error or logging a message.

Environment: Node.js 20.11, macOS 14.4, package version 3.2.1.

Useful phrases for issues:

• “I believe this may be related to issue #234, but the root cause seems different.”
• “I have been able to reproduce this consistently on Node.js 20 but not on Node.js 18.”
• “Would the maintainers be open to a PR for this? I am happy to take a look if so.”

For feature requests, explain the problem you are trying to solve before proposing a solution: “Currently, there is no way to configure the retry delay. This makes it difficult to use the library in environments with strict rate limits. Would it be possible to add a retryDelay option?”

Writing Pull Request Descriptions

A good PR description saves reviewers time and increases the chance of your contribution being merged quickly. Always include:

1. What this PR does — one or two sentences. “This PR addresses the memory leak reported in issue #412 by releasing the event listener in the cleanup method.”
2. Why you chose this approach — “I chose this approach because it avoids touching the public API and is consistent with how the library handles cleanup elsewhere.”
3. How to test it — “To verify the fix, run npm test -- --grep 'cleanup'. You can also reproduce the original leak by reverting this commit and watching memory usage in Activity Monitor.”
4. Related issues — Use the phrase “Closes #412” to automatically close the linked issue when the PR merges.

Common PR description phrases:

• “This PR addresses…”
• “This change introduces…”
• “I chose this approach because…”
• “This is a breaking change — see migration notes below.”
• “Fixes #[issue number]” / “Closes #[issue number]” / “Related to #[issue number]”

If your PR is still in progress and not ready for review, mark it as a draft PR. This signals to maintainers that you want feedback but the work is not complete.

Responding to Maintainers and Reviewers

Code review in open source can feel harsh at first. Comments are often short and direct. Learning to read them correctly and respond professionally is an important skill.

Common review shorthand you will encounter:

• LGTM — “Looks Good To Me.” The reviewer approves your change.
• nit — Short for “nitpick.” A very minor suggestion, often optional. “nit: could rename this variable to connectionPool for clarity.”
• blocking — A comment that must be addressed before the PR can merge.
• non-blocking — A suggestion or question that does not prevent merging.

When responding to review feedback, always acknowledge the comment before explaining your decision:

• “Thanks for the feedback — I’ve updated the variable name in the latest commit.”
• “Good catch — I’ve added a null check for that edge case.”
• “I considered that approach, but went with the current one because it avoids an extra database call. Happy to discuss if you think the trade-off is not worth it.”

When a maintainer closes your issue or declines your PR, respond graciously. The community is small and your reputation follows you:

• “Thanks for the explanation — that makes sense. I’ll follow up on the mailing list if I find a different approach.”

Key Vocabulary

Term	Definition
pull request (PR)	A proposal to merge your code changes into a project’s main codebase
issue triage	The process of reviewing, labelling, and prioritising open issues
upstream	The original repository that a fork was created from
fork	A personal copy of a repository where you make changes before submitting a PR
LGTM	”Looks Good To Me” — an informal approval from a reviewer
nit	A very minor, often optional code style suggestion left in a review
breaking change	A change that is incompatible with previous versions of the software
good first issue	A label used by maintainers to mark issues suitable for new contributors

Practice Tips

1. Start with “good first issue” labels. Most major projects tag beginner-friendly issues. Search GitHub for label:"good first issue" plus your language or framework of interest.
2. Read the CONTRIBUTING.md file before opening anything. Projects have specific rules about how to format commits, run tests, and write PR descriptions. Ignoring this file is the fastest way to have your contribution rejected.
3. Write your issue or PR description in a plain text editor first. Reading it back before submitting helps you catch unclear sentences and missing information.
4. Be patient with response times. Most open source maintainers are volunteers. Waiting one to two weeks before a polite follow-up is considered normal: “Just following up on this — happy to answer any questions or make changes if needed.”

Conclusion

Open source contribution is as much about communication as it is about code. When your issues are clearly structured, your PR descriptions explain both what and why, and your review responses are professional and collegial, you build a reputation as a contributor that maintainers are glad to work with. The vocabulary in this guide is a foundation — the more you participate, the more natural it will become.