Learn to write effective PR templates and PR description language.
0 / 18 completed
1 / 18
What is the purpose of a pull request template (.github/PULL_REQUEST_TEMPLATE.md)?
A PR template pre-fills the PR description with a structure — e.g., Summary, Changes, Testing, Screenshots — guiding contributors to provide context reviewers need.
2 / 18
What is a 'checklist' in a PR template?
A checklist (using - [ ] syntax in Markdown) in a PR template prompts authors to verify: 'Tests pass', 'Documentation updated', 'Breaking changes documented' — improving PR quality.
3 / 18
What is a 'draft pull request' on GitHub?
A draft PR (draft: true or using the 'Draft' button) signals work in progress — CI runs, collaborators can comment, but reviewers know not to do a final review until it is marked 'Ready for review'.
4 / 18
What does 'breaking change' mean in a PR description?
A breaking change is a modification that removes or changes an existing interface in a non-backward-compatible way — requiring downstream consumers to update their code. Must be clearly documented in the PR.
5 / 18
What is a 'review decision' on GitHub?
A review decision is the formal outcome of a GitHub review: Approve (ready to merge), Request changes (must be addressed before merging), or Comment (non-blocking feedback).
6 / 18
Sarah posted this message in the team Slack channel about a pull request:
"Just submitted PR #1234. Looks good to me, but I'm not sure if @Mark needs to know about the new API endpoint we added. Should I just mention it in the description?"
This question tests understanding of PR description best practices. While proactive communication is valued, a pull request's primary purpose is to document code changes. Including extraneous information like @Mark's potential interest can dilute the focus on the technical aspects being reviewed and might be seen as unnecessarily disruptive. The correct answer acknowledges that a brief mention is okay, but emphasizes prioritizing the core review criteria.
7 / 18
Mark just submitted a pull request for the new user authentication service. The PR description is very brief – only stating 'Implemented new auth flow'. During code review, your team lead asks you to improve it. Which of the following additions would be MOST appropriate in the PR description, considering best practices for communicating changes during a code review?
Mark: 'Implemented new auth flow'.
The core purpose of a PR description is to provide sufficient information for reviewers to understand the changes and their potential impact. While stating *what* was done is necessary, simply saying 'Updated JWT signing algorithms' isn't enough; it doesn't convey whether this change introduced any regressions or requires further investigation. Option 3 correctly identifies that including details about testing, limitations, and future considerations significantly improves the description's value during a code review – demonstrating thoroughness and proactive communication is key in development workflows.
8 / 18
Sarah posted this message in the team Slack channel about a pull request:
"Just submitted PR #1234. Looks good to me, but I'm not sure if @Mark needs to know about the new API endpoint we added. Should I just mention it in the description?"
This question tests understanding of PR description best practices. While proactive communication is valued, a pull request's primary purpose is to document code changes. Including extraneous information like @Mark's potential interest can dilute the focus on the technical aspects being reviewed and might be seen as unnecessarily disruptive. The correct answer acknowledges that a brief mention is okay, but emphasizes prioritizing the core review criteria.
9 / 18
Mark just submitted a pull request for the new user authentication service. The PR description is very brief – only stating 'Implemented new auth flow'. During code review, your team lead asks you to improve it. Which of the following additions would be MOST appropriate in the PR description, considering best practices for communicating changes during a code review?
Mark: 'Implemented new auth flow'.
The core purpose of a PR description is to provide sufficient information for reviewers to understand the changes and their potential impact. While stating *what* was done is necessary, simply saying 'Updated JWT signing algorithms' isn't enough; it doesn't convey whether this change introduced any regressions or requires further investigation. Option 3 correctly identifies that including details about testing, limitations, and future considerations significantly improves the description's value during a code review – demonstrating thoroughness and proactive communication is key in development workflows.
10 / 18
Sarah posted this message in the team Slack channel about a pull request:
"Just submitted PR #1234. Looks good to me, but I'm not sure if @Mark needs to know about the new API endpoint we added. Should I just mention it in the description?"
This question tests understanding of PR description best practices. While proactive communication is valued, a pull request's primary purpose is to document code changes. Including extraneous information like @Mark's potential interest can dilute the focus on the technical aspects being reviewed and might be seen as unnecessarily disruptive. The correct answer acknowledges that a brief mention is okay, but emphasizes prioritizing the core review criteria.
11 / 18
Mark just submitted a pull request for the new user authentication service. The PR description is very brief – only stating 'Implemented new auth flow'. During code review, your team lead asks you to improve it. Which of the following additions would be MOST appropriate in the PR description, considering best practices for communicating changes during a code review?
Mark: 'Implemented new auth flow'.
The core purpose of a PR description is to provide sufficient information for reviewers to understand the changes and their potential impact. While stating *what* was done is necessary, simply saying 'Updated JWT signing algorithms' isn't enough; it doesn't convey whether this change introduced any regressions or requires further investigation. Option 3 correctly identifies that including details about testing, limitations, and future considerations significantly improves the description's value during a code review – demonstrating thoroughness and proactive communication is key in development workflows.
12 / 18
Sarah posted this message in the team Slack channel about a pull request:
"Just submitted PR #1234. Looks good to me, but I'm not sure if @Mark needs to know about the new API endpoint we added. Should I just mention it in the description?"
This question tests understanding of PR description best practices. While proactive communication is valued, a pull request's primary purpose is to document code changes. Including extraneous information like @Mark's potential interest can dilute the focus on the technical aspects being reviewed and might be seen as unnecessarily disruptive. The correct answer acknowledges that a brief mention is okay, but emphasizes prioritizing the core review criteria.
13 / 18
Mark just submitted a pull request for the new user authentication service. The PR description is very brief – only stating 'Implemented new auth flow'. During code review, your team lead asks you to improve it. Which of the following additions would be MOST appropriate in the PR description, considering best practices for communicating changes during a code review?
Mark: 'Implemented new auth flow'.
The core purpose of a PR description is to provide sufficient information for reviewers to understand the changes and their potential impact. While stating *what* was done is necessary, simply saying 'Updated JWT signing algorithms' isn't enough; it doesn't convey whether this change introduced any regressions or requires further investigation. Option 3 correctly identifies that including details about testing, limitations, and future considerations significantly improves the description's value during a code review – demonstrating thoroughness and proactive communication is key in development workflows.
14 / 18
David submitted a pull request to add a new feature to the user profile service. In the PR description, he simply states 'Fixed bug'. During code review, your colleague, Emily, asks you to elaborate on the specific bug that was fixed. Which of the following is the MOST appropriate response to include in the PR's comments?
A good PR description should provide context for reviewers. Simply stating 'Fixed bug' is insufficient; a reviewer needs to understand *what* was broken and *how* it was fixed. Including details helps ensure the change aligns with the overall project goals and reduces ambiguity during the review process. Option A directly addresses this need.
15 / 18
Liam is drafting a pull request for a new microservice. He's using GitHub's PR template and includes a checklist. Which of the following best describes the primary purpose of this checklist within the PR?
Checklists in PR templates serve as a guide for both the author and the reviewers. They ensure that key aspects of the change – such as testing, documentation updates, or security considerations – are addressed during the review process. This promotes thoroughness and reduces the risk of overlooked issues. Options 1, 2, and 3 misinterpret the checklist's function.
16 / 18
Chloe is reviewing a pull request for a new API endpoint. The PR description states: 'Implemented the /users endpoint'. During the review, you notice that Chloe doesn't mention whether any error handling or input validation was included. What should Chloe add to her review comments?
A critical aspect of any API implementation is robust error handling and input validation. The PR description should clearly state whether these elements were included. Simply stating that the endpoint 'successfully retrieves user data' provides no insight into the quality or security of the code. Option 2 accurately identifies this missing information.
17 / 18
Ben is preparing to submit a pull request for a significant refactoring of a core library. He realizes that the change introduces a 'breaking change' – meaning existing code relying on the old API will need updates. Which of the following statements BEST describes how Ben should handle this situation when writing the PR description?
Clearly identifying 'breaking changes' in a PR description is crucial for proactive communication. It alerts consumers of the library to the necessary updates they need to make. Option 1 directly acknowledges this and provides the required instruction. Options 2, 3, and 4 are misleading or incomplete.
18 / 18
Sophia is participating in a standup meeting to discuss her progress on a pull request. She says: 'I've finished implementing the new authentication flow and submitted a PR with a brief description.' Her team lead asks if she's considered documenting the changes for future maintainers. What should Sophia respond?
While functionality is paramount, documenting changes is essential for maintainability. A good response would demonstrate that she's considered this aspect. Option 1 reflects a potentially short-sighted approach. Option 2 indicates she *has* included documentation – the ideal outcome. Options 3 and 4 are dismissive of the importance of documentation.
What will I practise in "Pull Request Templates — Writing and Vocabulary"?
Learn to write effective PR templates and PR description language.
How many exercises are in this module?
This module has 18 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more GitHub Platform Language exercises?
Browse the full GitHub Platform Language hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.