Which PR title follows Conventional Commits format correctly?
Conventional Commits format: `type(scope): description` in lowercase imperative mood. Types: fix, feat, chore, docs, refactor, test, ci. The scope (auth) identifies the module. The description explains what the commit does (imperative: "prevent", not "prevented"). This format enables automated changelog generation and communicates intent to reviewers at a glance.
2 / 20
"Closes #142" in a PR description does what on GitHub?
GitHub magic words (Closes, Fixes, Resolves) followed by an issue number automatically close the referenced issue when the PR merges into the default branch. This is the standard way to link work to reported issues. Keywords are case-insensitive. The issue is not closed when the PR is opened — only on merge.
3 / 20
Your PR adds a new feature that is not backward-compatible. Which PR description element is most important to add?
Breaking changes must be explicitly flagged in PR descriptions and commit messages. Conventional Commits specifies: add `!` after the type (`feat!:`) or include a `BREAKING CHANGE:` footer. This enables semantic versioning tools to automatically bump the major version. Maintainers and downstream users need explicit migration instructions — not just a note that something changed.
4 / 20
The "What / Why / How / How to test" PR description structure — what belongs in the "Why" section?
"Why" = the motivation behind the change. It must include: the issue reference (so the reviewer can read the full context), and the root cause or business motivation (so the reviewer understands why this specific fix was chosen). "Why" answers "should this change exist?" before the reviewer even reads the code.
5 / 20
A maintainer asks you to "squash your commits before merging". What does this mean?
Squashing combines multiple commits into one, producing a clean, atomic commit in the project history. This is common in projects that prefer a linear history. Before squashing, write a final commit message that summarises the complete change using Conventional Commits format. Many projects squash automatically on merge via GitHub's "Squash and merge" button — but maintainers may ask you to do it manually if they want you to write the final message.
6 / 20
Alice from the Phoenix team is reviewing your PR. She comments: 'This looks great, but it would be helpful to know *why* you chose this particular implementation.' Which of the following best describes what Alice is requesting in her comment?
Alice is asking for context and justification. The 'Why' section of a PR description focuses on the reasoning behind the changes, not just *what* was done or *how*. Options A and C are irrelevant to the core request; option D asks for testing, which belongs in the 'How to test' section.
7 / 20
You're drafting a Slack message to announce the merge of your PR. The PR addressed a critical bug in the user authentication module. Which of the following messages is most appropriate?
This message clearly communicates the impact of the PR—a critical fix for user authentication. Option A is too terse and lacks context. Option C is overly generic. Option D simply states the PR was merged without explaining its significance.
8 / 20
Your team uses GitHub Actions for automated testing. A failing test in your PR indicates a problem with the new API endpoint you've implemented. The error message from the GitHub Action shows: `HTTP 400 Bad Request - Invalid JSON`. Which element should you *most* prominently include in your PR description to guide the reviewer?
The core issue is the bad JSON. Providing a concrete example of the failing request directly demonstrates the problem and allows the reviewer to quickly reproduce it. While options A, C, and D are helpful, they don't directly address the immediate cause indicated by the error message.
9 / 20
You're writing a PR description for a new feature that improves performance. The 'What / Why / How / How to test' structure is being used. In the 'Why' section, you should primarily focus on:
The 'Why' section answers the question 'why' this change was made. It needs to explain the problem being solved and its importance – what need does the new feature fulfill? Options A, C, and D belong in other sections of the description.
10 / 20
Ben from the Backend team sends you a Slack message: 'Hey, just to clarify, when you say this PR fixes #237, are you explicitly addressing the root cause of the intermittent crashes we've been seeing?' What is Ben primarily asking about?
Ben is questioning the link between the PR and the original issue (#237). Conventional Commits often include 'Closes #...' which signifies that the PR resolves a specific issue. It's crucial to ensure the fix directly addresses the problem described in the issue tracker, not just a related symptom.
11 / 20
David from the Frontend team is reviewing your PR. He says: 'This resolves #342, but I'm not entirely clear on *why* we're using this specific CSS approach. Can you elaborate?' Which of the following best explains David's request?
David's comment is focused on the 'Why' aspect of PR descriptions – understanding the motivation behind the change. He isn't asking about implementation details (the 'How') or just a simple disagreement; he needs to know the reasoning driving your design decision. Selecting option B accurately reflects this request.
12 / 20
Sarah in QA is reviewing your PR and notes: 'I've run all tests, and everything appears to pass. However, the PR description doesn't include details about how this feature impacts existing users or potential edge cases.' What information should you add to the PR description to address Sarah's concerns?
Sarah's feedback highlights the importance of considering the broader implications of a change. The 'Why' section of a PR description should address potential impacts on users and highlight any risks or considerations – specifically, testing edge cases is critical for ensuring stability. Option C directly addresses this need.
13 / 20
Mark from the DevOps team is reviewing your PR description and says: 'I see you've linked this to #567. To help with deployment, could you add a note about any environment-specific configurations that might be required?' What information should you include in the PR description regarding environment configurations?
Deployment often relies on specific configurations, and this is particularly crucial when changes impact different environments. The 'Why' section should address any environment-specific considerations to ensure a smooth deployment process – detailing differences in configurations is key here.
14 / 20
Liam from the Security team is reviewing your PR. He comments: 'I appreciate the clear commit messages, but I'm struggling to understand how this change addresses potential XSS vulnerabilities.' Considering Conventional Commits best practices, which sentence would be MOST appropriate for you to add to the PR description?
Conventional Commits emphasizes clarity and context. When a reviewer raises a concern like XSS vulnerabilities, it indicates a need for more detail about how the change addresses security risks. The correct option highlights that the description should proactively explain the mitigation strategy, aligning with the 'Why' principle of the PR description structure.
15 / 20
During a standup meeting, you're explaining your recent PR. Your team lead asks: 'Can you briefly explain the reasoning behind choosing to use React Hooks in this component?' Which part of the 'What / Why / How / How to test' PR description structure is MOST relevant here?
The core of this question is understanding the 'Why' section of a PR description. The team lead's query specifically asks for the *reasoning* behind a technical decision (hooks). While other sections are important, the 'Why' section directly addresses this need for justification.
16 / 20
You're reviewing a PR that implements a new API endpoint. The GitHub Action running tests returns an HTTP 500 error. The logs show a NullPointerException in your code. Which of the following should you add to the PR description to help the reviewer understand and debug this issue?
When debugging issues reported through automated tests like GitHub Actions, providing immediate context and actionable information is crucial. The correct answer clearly states the problem (500 error) and points the reviewer to the relevant logs for further investigation. It's more helpful than vague statements about availability or future fixes.
17 / 20
You're reviewing a PR describing a change to the user authentication flow. The author has included the following in the PR description: 'This PR updates the JWT signing algorithm to SHA256 for improved security.' Which of the following best describes why this information is crucial for reviewers?
The core purpose of PR descriptions is to provide context. Explaining the *why* – in this case, the security update – allows reviewers to fully understand the implications and potential risks associated with the change. Simply stating code changes isn't sufficient for critical updates like this.
18 / 20
Sarah from the QA team is reviewing a PR that introduces a new feature: 'This PR adds support for two-factor authentication via SMS.' She asks you, 'Can you provide details on how this integrates with our existing security protocols and what measures are in place to mitigate potential risks?' Which part of your PR description should you *immediately* expand upon?
Sarah's question directly targets the *why* behind the change. The 'How to test' section is important for verification, but it doesn't address the fundamental security concerns raised. Providing a detailed explanation of integration and risk mitigation belongs in the 'Why' section.
19 / 20
You are writing a PR description for a bug fix that addresses intermittent database connection issues. The PR includes a single commit message: 'Fix DB connection errors'. What addition to the PR description is MOST important?
While a concise commit message is good practice, it lacks crucial context. The most important addition is explaining the *root cause* of the problem – without that, reviewers won't understand the scope or potential for recurrence of the issue.
20 / 20
You're reviewing a PR that implements a new feature: 'This PR adds support for dark mode'. The PR description is minimal. Your team lead comments: 'I'm not seeing any information about how this affects the existing UI components or if there are any potential accessibility issues.' What should you *immediately* add to the PR description?
Accessibility is paramount when introducing UI changes. The PR description must address potential impact on existing components *and* whether any accessibility issues (e.g., color contrast) were considered. Design specs are a good starting point for this discussion.
What will I practise in "📝 Writing PR Descriptions"?
This module focuses on Open Source Contribution — real workplace phrasing you'll use on the job. It contains 20 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 20 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.