Open Source Contributions: PR & Community Communication Phrases
5 exercises on open source communication phrases. Choose the most natural and professional option.
0 / 5 completed
1 / 5
You've discovered a bug in a popular open source library and want to report it professionally. What's the best opening line in your issue?
"I found a bug in X — when Y, Z happens" is the model bug report opener: it names the component, the trigger, and the symptom. This gives maintainers everything they need to triage without back-and-forth. Real examples: "I found a bug in the router — when the path ends with a trailing slash, the handler is called twice"; "Found a bug in the serialiser: Unicode characters above U+FFFF are corrupted on Windows." Options A/B are blunt and unhelpful. Option D is the most useless — it doesn't say what goes wrong, when, or where.
2 / 5
A maintainer has opened an issue for a feature. You want to express interest in contributing without over-committing. What do you say?
"Happy to take this on if there's still interest" is the polite open-source contribution opener. It signals enthusiasm without claiming ownership, checks that the issue is still active, and offers a small preview of your approach. Real examples: "Happy to take this on if there's interest — I'm thinking we handle it at the middleware level"; "Happy to take this on — would a PR with just the core change be useful, or do you want docs too?" Options B/C/D sound assertive but skip the collaborative check — the issue may already be assigned or stale.
3 / 5
Before writing code, you want to confirm the maintainer would welcome a contribution. What do you ask?
"Would a PR be welcome?" is the canonical open-source etiquette phrase. It respects maintainer time (they don't have to review unwanted PRs) and shows you're aware that contributions have a cost. Adding "fits the project direction" demonstrates maturity. Real examples: "Would a PR be welcome? I don't want to spend a week on something that's out of scope"; "Would a PR be welcome for adding TypeScript types? Happy to do the work if it aligns with your roadmap." Options A-C are shorter but miss the context-setting that makes Option D so professional.
4 / 5
A reviewer has requested changes on your PR. You've made the changes and pushed. What do you comment?
"I've addressed the review comments in the latest push" is the professional re-review request. It confirms you acted on the feedback, summarises what specifically changed, and invites a second look without being demanding. Real examples: "Addressed all comments in the latest push — the main change was splitting the god class into three smaller ones"; "I've addressed the review comments — I also added a CHANGELOG entry as suggested." Option A is too terse. Option C sounds slightly demanding. Option D ("PTAL" = Please Take Another Look) is a valid shorthand but provides no summary of what changed.
5 / 5
A maintainer says they prefer contributors to discuss proposals before submitting code. How do you correctly respond when starting a new contribution?
"Should I open an issue first?" is the correct issue-first etiquette question. It shows you've read the contributing guidelines and understand the process. In many projects, an accepted design in an issue prevents wasted work on rejected PRs. Real examples: "Should I open an issue first, or is there already one tracking this?"; "Happy to open an issue outlining the approach before writing any code — let me know if you'd prefer that." Option B creates parallel work unnecessarily. Option C is exactly the attitude contributing guides warn against. Option D asks where, not whether — skips the key question.