8 exercises — welcoming first-time contributors, closing out-of-scope requests, triage, stale issues, breaking-change announcements, governance, and bus factor.
0 / 17 completed
1 / 17
Which response best welcomes a first-time contributor who submitted a PR with an issue?
Good maintainer communication thanks the contributor, acknowledges what is right, provides specific actionable feedback, and offers support. This encourages continued contribution.
2 / 17
How would a maintainer professionally close a feature request that is out of scope?
Professional scope rejection thanks the requester, explains the project's focus, closes with a reason, and offers an alternative path. This maintains community goodwill even when declining.
3 / 17
What does 'project governance' mean in an open-source context?
Governance defines decision-making power: who is a maintainer, how new maintainers are added, how disputes are resolved. Clear governance prevents conflict and makes the project more trustworthy for adopters.
4 / 17
Which sentence correctly describes 'triage' in an open-source issue tracker?
Issue triage is essential for maintainable projects. Without it, the issue tracker becomes a dumping ground. Triage labels (bug, enhancement, question, duplicate) help contributors and maintainers navigate the backlog.
5 / 17
What is a 'stale issue' and how should maintainers communicate about it?
Polite stale issue communication explains the reason for potential closure, gives the reporter a chance to respond, and maintains a clean issue tracker. Automated stale bots use similar language.
6 / 17
How would a maintainer communicate a breaking change in a new release?
Breaking changes require proactive, detailed communication: what changed, who is affected, how to migrate, and where to find help. This reduces friction for upgraders and support requests.
7 / 17
What does 'LGTM' mean in a code review comment on a PR?
LGTM (Looks Good To Me) is a widely used code review abbreviation indicating approval. It originated in open-source projects and is now standard in both open-source and corporate engineering.
8 / 17
What is 'bus factor mitigation' strategy for open-source maintainers?
Open-source projects with a single maintainer are fragile. Mitigating bus factor means bringing in co-maintainers, documenting everything, and distributing permissions — so the project survives if the primary maintainer becomes unavailable.
9 / 17
Sarah, a new contributor, recently submitted a pull request (PR) with the message: 'Fixes bug #123 - Incorrect date formatting'. The maintainer, David, replies with:
'Hi Sarah, thanks for submitting this PR! Could you provide more context on which date formats were incorrect and what the expected format is?' Which of the following responses best welcomes a first-time contributor who submitted a PR with an issue?
Option A is too terse and doesn't encourage collaboration. Option B creates unnecessary pressure and might discourage further contributions. Option C provides a polite opening, asks for clarification, and demonstrates a willingness to help – exactly what's needed when interacting with someone new to the project. Option D assumes the PR is ready for merging without proper review.
10 / 17
As a maintainer of an open-source library, you've received numerous requests to add support for a rarely used programming language. After reviewing the project's roadmap and current priorities, you determine this feature is outside its scope. How would a maintainer professionally close a feature request that is out of scope?
Option A is dismissive and unhelpful. Option B politely explains the decision without being negative. Option C provides closure by reiterating the roadmap and inviting further suggestions – a key part of open-source communication. Option D introduces unnecessary complications (funding) that aren't relevant to scope.
11 / 17
During the weekly project standup meeting, Alex asks: 'What does 'project governance' mean in an open-source context?' Which of the following best explains this concept?
Option A offers a superficial understanding. Option B provides an accurate definition – project governance encompasses rules, processes, and decision-making to maintain a healthy community. Option C only addresses one aspect of governance. Option D is simply the name of a repository.
12 / 17
As a maintainer of an open-source project with a single core developer (the 'bus factor'), you notice that no one has updated the documentation for the last six months. What is a 'stale issue' and how should maintainers communicate about it?
Option A demonstrates a lack of awareness and risk mitigation. Option B highlights the potential consequences of inaction – stale issues can lead to confusion and hinder adoption. Option C shifts responsibility inappropriately. Option D accepts an unacceptable state of affairs within open-source development.
13 / 17
John, a maintainer for the Phoenix library, receives this Slack message from a contributor: 'This code is beautiful! LGTM.' What does LGTM signify in this context?
LGTM is an abbreviation for 'Looks Good To Me.' It's a common shorthand used in code reviews to indicate that a reviewer has examined the code and approves it without requesting modifications. Misinterpreting it as a command or licensing term demonstrates a misunderstanding of standard code review practices – crucial for effective open-source collaboration.
14 / 17
Maria, a maintainer on the Nova project, receives a PR with a large amount of new code and a brief description: 'Adds support for Python 3.9.' What is the MOST appropriate response to ensure this contribution aligns with the project's goals?
The best approach here is a measured response that prioritizes strategic alignment. Simply requesting more documentation isn't sufficient; Maria needs to evaluate the broader implications of adding Python 3.9 support. Discussing it in a meeting allows for a thoughtful assessment of user impact and maintainability—a key aspect of responsible open-source contribution. The other options represent either overly prescriptive feedback or a lack of critical evaluation.
15 / 17
David, a maintainer for the Quantum framework, notices that an issue labeled 'Documentation Update' has been open for over three months with no activity. What does this constitute in terms of open source maintenance?
A stale issue—one that remains unaddressed for an extended period—is a significant concern. It signals neglect and can negatively impact the community's perception of the project's health. This situation requires proactive intervention from maintainers to understand why the documentation hasn't been updated and to determine appropriate next steps, demonstrating commitment to long-term sustainability.
16 / 17
Emily is reviewing a PR for the Velocity project. The author has included a detailed explanation of why they've made significant changes to the core API. Which statement best describes Emily's role in this situation?
A critical aspect of code review is ensuring understanding. Emily's role involves actively engaging with the author to clarify any ambiguities in their explanation. This doesn't mean she needs to be an expert; it means she must fully grasp *why* the changes were made—critical for maintaining code quality and consistency within the project, preventing future misunderstandings.
17 / 17
Robert, a maintainer of the Zenith library, receives a request to add support for a niche programming language. The project's roadmap focuses on core functionality and has no allocated resources for new languages. What is the MOST appropriate response?
Maintaining realistic project priorities is crucial. Robert needs to politely but firmly decline the request, explaining that it doesn't align with the current roadmap and resource constraints. This demonstrates strategic thinking and helps manage expectations within the community – a fundamental aspect of open-source governance.
What will I practise in "Maintainer Communication"?
This module focuses on Open Source Contribution — real workplace phrasing you'll use on the job. It contains 17 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 17 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Open Source Contribution exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around open source contribution — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Open Source Contribution exercises?
See the Open Source Contribution hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.