Issue Triage — Vocabulary and Communication Language
Learn vocabulary for triaging GitHub issues: labels, priority, reproducibility, and communication.
0 / 22 completed
1 / 22
What is 'issue triage' in GitHub workflow?
Triage evaluates new issues: verifying they are real, reproducible, and well-described; applying labels (bug/feature/question); assigning priority; and assigning to the right team or milestone.
2 / 22
What does 'needs-reproduction' label mean on a GitHub issue?
'needs-reproduction' signals that the maintainer could not reproduce the issue with the provided information and needs the reporter to provide more context, a minimal reproduction case, or clarification.
3 / 22
What is a 'good first issue' label?
'good first issue' marks well-scoped, approachable issues with sufficient context — designed to help new contributors make their first contribution without needing deep codebase knowledge.
4 / 22
What is 'issue priority' in triage vocabulary?
Issue priority reflects business impact and urgency: Critical (production down, no workaround), High (major feature broken), Medium (significant inconvenience), Low (minor or cosmetic). Drives sprint planning.
5 / 22
What is 'stale issue' management in GitHub?
Stale issue management (often automated with the stale bot) labels issues inactive for e.g. 60 days as 'stale', warns they will be closed in 14 days, and closes them if no response — keeping the backlog manageable.
6 / 22
Sarah: "Hey team, I've just created a PR with a minor bug fix for the user authentication module. It's been sitting here for a couple of days and no one has commented on it. Should I bump its priority?"
Sarah is correctly recognizing a need to proactively manage her PR. While waiting for review is often part of the process, in this scenario, the PR addresses authentication – a critical area. Immediately escalating its priority demonstrates awareness and ensures it receives timely attention without simply passively waiting; it's about influencing the flow.
7 / 22
Alex: 'I've just created a pull request to update the API endpoint for fetching user profiles. The response time has increased significantly, and I've attached a screenshot of the performance metrics. It seems like a potential bottleneck.'
Ben (responding in Slack) asks: 'Okay, that sounds important. Should I mark this as 'high priority'?' What is the most appropriate response for you to give Ben?
The key here is understanding that prioritizing isn't automatic. While slow API responses *are* important, Ben's question indicates he wants to know if it warrants immediate attention. Marking it 'high priority' without further investigation might be premature. The best approach – asking for more details – demonstrates a methodical and responsible approach to triage. Ben is seeking validation before committing to a prioritization; the correct response acknowledges this and encourages a deeper understanding of the issue before assigning urgency.
8 / 22
Alex just reported a significant performance degradation in an API endpoint update via a pull request. He's attached screenshots of performance metrics showing increased response times. Ben suggests immediately marking this as 'high priority'. What is the most appropriate response to give Ben?
Option A: 'Absolutely, mark it high priority! Performance issues are always critical.'
Option B: 'That sounds concerning, but let's first investigate *why* the performance has degraded. High priority might be premature without understanding the root cause.'
Option C: 'Don't worry about it; increased response times are normal during updates and won't affect users.'
Option D: 'Mark it as 'urgent' – that will ensure someone addresses it immediately.'
This scenario highlights the importance of a measured approach to issue triage. Immediately assigning 'high priority' without investigation can lead to misallocation of resources and potentially unnecessary panic. The correct response acknowledges the concern but emphasizes understanding the underlying problem before escalating it – this aligns with best practices for efficient issue resolution, focusing on *why* the performance is degraded rather than simply reacting to the symptom (increased response time).
9 / 22
Sarah: "Hey team, I've just created a PR with a minor bug fix for the user authentication module. It's been sitting here for a couple of days and no one has commented on it. Should I bump its priority?"
Sarah is correctly recognizing a need to proactively manage her PR. While waiting for review is often part of the process, in this scenario, the PR addresses authentication – a critical area. Immediately escalating its priority demonstrates awareness and ensures it receives timely attention without simply passively waiting; it's about influencing the flow.
10 / 22
Alex: 'I've just created a pull request to update the API endpoint for fetching user profiles. The response time has increased significantly, and I've attached a screenshot of the performance metrics. It seems like a potential bottleneck.'
Ben (responding in Slack) asks: 'Okay, that sounds important. Should I mark this as 'high priority'?' What is the most appropriate response for you to give Ben?
The key here is understanding that prioritizing isn't automatic. While slow API responses *are* important, Ben's question indicates he wants to know if it warrants immediate attention. Marking it 'high priority' without further investigation might be premature. The best approach – asking for more details – demonstrates a methodical and responsible approach to triage. Ben is seeking validation before committing to a prioritization; the correct response acknowledges this and encourages a deeper understanding of the issue before assigning urgency.
11 / 22
Alex just reported a significant performance degradation in an API endpoint update via a pull request. He's attached screenshots of performance metrics showing increased response times. Ben suggests immediately marking this as 'high priority'. What is the most appropriate response to give Ben?
Option A: 'Absolutely, mark it high priority! Performance issues are always critical.'
Option B: 'That sounds concerning, but let's first investigate *why* the performance has degraded. High priority might be premature without understanding the root cause.'
Option C: 'Don't worry about it; increased response times are normal during updates and won't affect users.'
Option D: 'Mark it as 'urgent' – that will ensure someone addresses it immediately.'
This scenario highlights the importance of a measured approach to issue triage. Immediately assigning 'high priority' without investigation can lead to misallocation of resources and potentially unnecessary panic. The correct response acknowledges the concern but emphasizes understanding the underlying problem before escalating it – this aligns with best practices for efficient issue resolution, focusing on *why* the performance is degraded rather than simply reacting to the symptom (increased response time).
12 / 22
Sarah: "Hey team, I've just created a PR with a minor bug fix for the user authentication module. It's been sitting here for a couple of days and no one has commented on it. Should I bump its priority?"
Sarah is correctly recognizing a need to proactively manage her PR. While waiting for review is often part of the process, in this scenario, the PR addresses authentication – a critical area. Immediately escalating its priority demonstrates awareness and ensures it receives timely attention without simply passively waiting; it's about influencing the flow.
13 / 22
Alex: 'I've just created a pull request to update the API endpoint for fetching user profiles. The response time has increased significantly, and I've attached a screenshot of the performance metrics. It seems like a potential bottleneck.'
Ben (responding in Slack) asks: 'Okay, that sounds important. Should I mark this as 'high priority'?' What is the most appropriate response for you to give Ben?
The key here is understanding that prioritizing isn't automatic. While slow API responses *are* important, Ben's question indicates he wants to know if it warrants immediate attention. Marking it 'high priority' without further investigation might be premature. The best approach – asking for more details – demonstrates a methodical and responsible approach to triage. Ben is seeking validation before committing to a prioritization; the correct response acknowledges this and encourages a deeper understanding of the issue before assigning urgency.
14 / 22
Alex just reported a significant performance degradation in an API endpoint update via a pull request. He's attached screenshots of performance metrics showing increased response times. Ben suggests immediately marking this as 'high priority'. What is the most appropriate response to give Ben?
Option A: 'Absolutely, mark it high priority! Performance issues are always critical.'
Option B: 'That sounds concerning, but let's first investigate *why* the performance has degraded. High priority might be premature without understanding the root cause.'
Option C: 'Don't worry about it; increased response times are normal during updates and won't affect users.'
Option D: 'Mark it as 'urgent' – that will ensure someone addresses it immediately.'
This scenario highlights the importance of a measured approach to issue triage. Immediately assigning 'high priority' without investigation can lead to misallocation of resources and potentially unnecessary panic. The correct response acknowledges the concern but emphasizes understanding the underlying problem before escalating it – this aligns with best practices for efficient issue resolution, focusing on *why* the performance is degraded rather than simply reacting to the symptom (increased response time).
15 / 22
Sarah: "Hey team, I've just created a PR with a minor bug fix for the user authentication module. It's been sitting here for a couple of days and no one has commented on it. Should I bump its priority?"
Sarah is correctly recognizing a need to proactively manage her PR. While waiting for review is often part of the process, in this scenario, the PR addresses authentication – a critical area. Immediately escalating its priority demonstrates awareness and ensures it receives timely attention without simply passively waiting; it's about influencing the flow.
16 / 22
Alex: 'I've just created a pull request to update the API endpoint for fetching user profiles. The response time has increased significantly, and I've attached a screenshot of the performance metrics. It seems like a potential bottleneck.'
Ben (responding in Slack) asks: 'Okay, that sounds important. Should I mark this as 'high priority'?' What is the most appropriate response for you to give Ben?
The key here is understanding that prioritizing isn't automatic. While slow API responses *are* important, Ben's question indicates he wants to know if it warrants immediate attention. Marking it 'high priority' without further investigation might be premature. The best approach – asking for more details – demonstrates a methodical and responsible approach to triage. Ben is seeking validation before committing to a prioritization; the correct response acknowledges this and encourages a deeper understanding of the issue before assigning urgency.
17 / 22
Alex just reported a significant performance degradation in an API endpoint update via a pull request. He's attached screenshots of performance metrics showing increased response times. Ben suggests immediately marking this as 'high priority'. What is the most appropriate response to give Ben?
Option A: 'Absolutely, mark it high priority! Performance issues are always critical.'
Option B: 'That sounds concerning, but let's first investigate *why* the performance has degraded. High priority might be premature without understanding the root cause.'
Option C: 'Don't worry about it; increased response times are normal during updates and won't affect users.'
Option D: 'Mark it as 'urgent' – that will ensure someone addresses it immediately.'
This scenario highlights the importance of a measured approach to issue triage. Immediately assigning 'high priority' without investigation can lead to misallocation of resources and potentially unnecessary panic. The correct response acknowledges the concern but emphasizes understanding the underlying problem before escalating it – this aligns with best practices for efficient issue resolution, focusing on *why* the performance is degraded rather than simply reacting to the symptom (increased response time).
18 / 22
Sarah is frustrated because her PR about fixing a user authentication bug hasn't received any comments or attention. She wants to make it more visible. Which of the following options best describes what she should do?
Sarah needs to prioritize her PR to get it reviewed promptly. A high priority ensures that reviewers are aware of the issue and can address it efficiently. Ignoring the situation is not an effective strategy for ensuring timely feedback.
19 / 22
In incident triage, 'severity' refers to the impact of a problem on the system or users. A high severity issue would typically…
Severity in incident triage denotes the degree of impact. A high severity issue represents a serious problem with potentially major consequences – this is key to understanding prioritization and resource allocation.
20 / 22
Alex reports a significant performance degradation in an API endpoint update. He includes screenshots of metrics showing increased response times. Ben suggests marking the issue as 'urgent'. What does 'urgent' likely mean in this context?
'Urgent' in this scenario indicates that the performance degradation is causing immediate problems. It requires swift action to mitigate the impact on users or systems. This aligns with a critical incident response approach.
21 / 22
Explain in your own words what a 'blocker' issue is during triage and give an example of one you might encounter when working on a new feature.
A blocker issue is one that completely halts progress – it stops you from moving forward with other work. For example, if the main database server goes down, all development tasks relying on that database would be blocked.
22 / 22
You're reviewing a PR description. The author writes: 'Fixed a bug where users couldn't log in. Seems straightforward.' Which of the following is the MOST helpful addition to this description?
A good PR description needs enough detail for reviewers to understand the problem, the solution, and how to verify it. Linking to the changes provides immediate context and allows reviewers to quickly assess the fix's impact.
What will I practise in "Issue Triage — Vocabulary and Communication Language"?
Learn vocabulary for triaging GitHub issues: labels, priority, reproducibility, and communication.
How many exercises are in this module?
This module has 22 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.