🌐 Open Source Contribution

Open source contributors need: writing clear issue reports and bug descriptions in English, crafting pull request descriptions that explain the why and how of changes, engaging respectfully in code review discussions, participating in RFC and design discussions, writing or improving documentation and READMEs, and communicating with maintainers professionally — even when disagreeing. Most major open source projects communicate exclusively in English, even if maintainers are not native speakers.

Good issue writing: use the project's issue template if available, provide a minimal reproducible example (MRE) for bugs, separate "observed behaviour" from "expected behaviour", include exact error messages and stack traces, specify versions (OS, language runtime, package version), and add "Steps to reproduce" as a numbered list. For feature requests: explain the use case and current workaround. A clear issue gets faster responses — maintainers are volunteers with limited time.

PR culture vocabulary: LGTM (Looks Good To Me — approval), Nit (minor optional suggestion), Request changes (blocking feedback), WIP (Work In Progress — draft PR), Good first issue (suitable for new contributors), Help wanted (maintainers seeking help), PTAL (Please Take A Look), IIUC (If I Understand Correctly), AFAICT (As Far As I Can Tell), Closes #[n] (automatically closes an issue when merged).

Professional maintainer communication: be patient — maintainers are often unpaid volunteers; be grateful for their time; be specific in your ask; do your research first (read the docs and closed issues before asking); accept "won't fix" decisions graciously; offer to help rather than just requesting. Don't demand rapid responses or complain about project pace. Opening with "Thank you for maintaining this project" and ending with "I'm happy to help with [X]" goes a long way.

CONTRIBUTING.md is the onboarding guide for new contributors: how to set up the development environment, coding standards, commit message format, how to submit PRs, how to report bugs, and the project's code of conduct. Always read CONTRIBUTING.md before your first PR — many projects close PRs that don't follow the guidelines. If CONTRIBUTING.md doesn't exist, check the README and look at merged PRs to understand the project's expectations.

Upstream refers to the original source project — if you fork a repo, your fork is downstream of the original. "Contribute back upstream" means submitting your improvements to the original project. "Sync with upstream" means pulling new changes from the original into your fork. In package ecosystems: if your app depends on lodash, lodash is upstream of your app. Upstream changes can introduce breaking changes in downstream projects — this is why CHANGELOG.md and semantic versioning matter.

Bus factor (also called truck factor) is the minimum number of team members who, if hit by a bus (or truck), would critically disrupt the project. A bus-factor-1 project is extremely fragile — one maintainer's departure ends development. Good open source health: multiple active maintainers, documented processes, low bus factor. In job interviews: "What's the bus factor of your team?" signals awareness of knowledge concentration risk. High bus factor = resilient project/team.

Professional PR response: acknowledge the feedback ("Good catch — I hadn't considered that edge case"), address each comment explicitly, push the changes, and reply to each comment thread with "Done" or "Fixed in [commit hash]". If you disagree: "I see your point, but I kept it this way because [reason] — happy to discuss if you think it's worth changing." Don't go silent, don't be defensive, and don't mark threads as resolved without addressing them. Maintainers value communicative contributors.

A Code of Conduct defines expected behaviour in a project's community — typically: be respectful, no harassment, no discrimination, consequences for violations. The Contributor Covenant is the most widely adopted CoC template. CoCs exist because open source communities are public and diverse — clear expectations reduce toxicity and make projects more welcoming to underrepresented contributors. Violating a CoC can result in issue/PR closure, banning, or moderation action.

Good first issues are tagged by maintainers as suitable for new contributors — they're typically well-scoped, have clear requirements, and don't require deep project knowledge. To start: (1) Browse GitHub's "Good First Issues" filter; (2) Comment "I'd like to work on this" to claim it; (3) Fork the repo; (4) Read CONTRIBUTING.md; (5) Make the change; (6) Submit a PR referencing the issue. Contributing to open source builds your portfolio, English writing practice, and professional network simultaneously.