5 exercises — know when to reply in a thread, when to post in the main channel, when to DM, and how to keep async communication discoverable by your whole team.
The core decision framework
Thread: replies to an existing topic, operational updates during an incident, sub-discussions, debate under a decision post
Main channel: new topics, important decisions/resolutions that everyone needs to see, incident alerts, announcements
DM: personal/sensitive messages, messages only relevant to one person, minor corrections
Rule of thumb: if the answer benefits more than one person → channel; if it's only for one person → DM
0 / 26 completed
1 / 26
A developer posts in #engineering (40 members): "Hey, anyone know if we support HTTP/2 server push? Quick question."
Two colleagues reply. A third wants to answer. What should the third colleague do?
Reply in the thread. When a message already has replies, continuing in that thread is the correct Slack/Teams etiquette:
① Context stays together — all responses are nested under the original question; anyone who searches later finds the full conversation in one place ② Channel noise is reduced — 40 people in #engineering won't be notified for every follow-up reply; only those who have joined the thread get pinged ③ Scannable channel history — the main channel shows the original question + a "3 replies" indicator; anyone interested can join the thread; others can skip it
When to post in the main channel instead of a thread: If your message is a NEW topic, or if you want to deliberately re-surface something for everyone's attention (e.g., "thread resolved — the answer is: YES, we do support HTTP/2 push, see architecture doc [link]").
Sending a DM: only appropriate if the question is sensitive or only relevant to that one person. Creating a new channel: only for ongoing, recurring topics — not for one-off questions.
2 / 26
It's 14:03. A P1 incident is in progress. The on-call engineer posts in #incidents: "🚨 P1 — payments API returning 502. Investigating."
Where should live incident updates go?
A mix: thread for continuous updates, main channel for major breakthroughs. This is the standard SRE/DevOps incident communication pattern:
Thread (under the original alert): • "14:07 — checking nginx logs on prod-west-1" • "14:09 — metrics spike at 14:01, correlates with deploy #4412" • "14:12 — rolling back deploy #4412 now" These are operational updates for the incident team — they don't need to interrupt the whole #incidents audience.
Main channel (new top-level post): • "✅ 14:18 — P1 resolved. Root cause: bad config in deploy #4412, rolled back. Full post-mortem to follow." This gets maximum visibility — everyone following #incidents should see the resolution.
Why not all in thread? Resolution announcements buried in a thread risk being missed by stakeholders who are watching but not scrolling into the thread. Why not all in main channel? 15 status updates in #incidents each generating notifications for 60 people would cause significant notification fatigue.
3 / 26
A product manager posts in #team-alpha: "Quick decision needed: should we delay the v3.2 release by one week to include the search feature, or ship on schedule without it? Please share your thoughts 🙏"
Six engineers respond with opinions, creating a long discussion. What is the best practice here?
All replies in the thread — this is the right approach for a discussion that started in a specific message and is expected to generate multiple responses.
Why thread works well here: ① Decision traceability — the full thread (original question + all responses) becomes the record of how the decision was made. Future team members can find it by searching for "v3.2 release" ② Channel stays scannable — not everyone in #team-alpha needs to follow this decision; they can see "14 replies" and join only if relevant ③ Threading signals closure — once the PM posts the final decision in the thread, everyone who participated is notified; those who didn't join won't be disrupted
When does a decision discussion need a top-level channel post? When the outcome is important for everyone, the PM should summarise the decision as a NEW top-level message: "✅ Decision: we'll delay v3.2 by one week. Thread has the reasoning. New ship date: [date]." This ensures even those who didn't follow the thread see the outcome.
4 / 26
A developer is about to send a Slack message. They can't decide between posting in a channel or sending a DM. Which scenario is most appropriate for a direct message (DM) rather than a channel?
The typo heads-up is the right DM scenario. DMs are appropriate when:
① The message is only relevant to one person — a typo fix note for the PR author doesn't need to be seen by all of #backend ② The message is minor / could be embarrassing if public — pointing out a small error can feel awkward; a DM is a kindness ③ It's personal feedback — performance feedback, sensitive observations, or anything you'd say privately in person
Why channel is better for the other three: • "Staging CI failing" — technical debugging benefits from multiple eyes; someone in the channel may know immediately. Channel → thread • "Deploy at 17:00. All good?" — this is a team-status check; relevant to everyone in #devops; belongs in channel • "Who owns the auth service?" — a routing question; asking in channel gets the fastest answer and may be useful for others who had the same question
The DM vs channel rule of thumb: If the answer would benefit more than one person → channel. If the message is personal/sensitive/only for one person → DM.
5 / 26
Your team uses Slack. A colleague has been sending long technical design explanations as direct messages to team members one at a time. Other team members are unaware of these discussions and duplicating work. What is the correct feedback?
Design discussions belong in a channel or thread — not DMs. This is one of the most common async communication mistakes in distributed teams, with real organisational costs:
Problems with DM-based design discussions: ① Knowledge siloing — information lives only between two people; the rest of the team can't benefit, challenge, or build on it ② Duplicated effort — as described in the scenario, team members reinvent decisions that were already made in a DM conversation they didn't know about ③ No searchable record — a DM thread between two people about a design decision is invisible to anyone hired in 6 months; a channel thread is searchable forever ④ Reduced team trust — teams that primarily use DMs can feel fragmented; channel-first communication builds shared context
Best practice: • Start design discussions in a relevant channel (e.g., #architecture, #team-alpha) • Use threads to keep sub-discussions tidy • Share decisions as top-level messages with a brief summary • Post a TL;DR if the thread becomes long: "TL;DR: we're going with approach B. Reasoning in the thread above."
6 / 26
John just submitted a pull request to fix a bug in the authentication service. The PR description reads: 'Fixed issue where users couldn't log in after password reset. Updated validation logic.' A reviewer, Sarah, comments on the PR with: 'Looks good! 👍'. John replies to Sarah with: 'Thanks! Just ran tests and everything seems to be working as expected.'
Which of the following responses is the most professional and helpful for John to send in this situation?
Option B is the best response because it acknowledges Sarah's review and expresses gratitude for her time. Simply stating 'No problem' or 'Just letting you know' lacks context and doesn't demonstrate a professional exchange. Providing a direct link to test results adds valuable information and shows proactive communication – a key element of effective code reviews, especially when confirming functionality.
7 / 26
David is working on a new feature for the user profile service. He's using Slack to discuss design choices with his team. He sends a message in #design-reviews: 'Thinking of using React Context for this. Thoughts?' Maria replies immediately: 'Sounds good!' But then Ben thinks about it and asks, 'Why not use Redux? It's more predictable.' David responds with: 'React Context is simpler to set up.' What should David do next to continue the discussion constructively?
The key here is acknowledging differing opinions while maintaining a collaborative tone. Option A is too dismissive and doesn't value Ben's input. Option B is overly assertive and risks escalating the discussion. While option D (a DM) can be useful for more complex explanations, it fragments the conversation and isn't ideal for initial design feedback. Option 3 demonstrates active listening, respectfully presents David's rationale, and invites further dialogue – a far better approach than simply pushing his preference. It allows for a productive exchange of ideas rather than a single-sided argument.
8 / 26
Alex is reviewing a PR for a new microservice. The PR description states: 'Implemented the user authentication flow using OAuth 2.0 and JWTs.' During the review, Alex notices that the code doesn't handle rate limiting. He wants to point this out to the developer, Mark.
Which of the following is the most effective way for Alex to provide feedback in a Slack channel?
The best approach here is to post a comment in the PR's Slack thread. This keeps the discussion visible to the entire team, allows others to contribute ideas, and provides context for Mark. Sending a DM might isolate Mark, and replying directly to the commit message isn't standard practice; emailing is generally too formal for quick code review feedback. This maintains transparency and collaboration which are key to effective development.
9 / 26
Mark just submitted a pull request to update the user authentication microservice. The PR description reads: 'Implemented OAuth 2.0 and JWTs for user authentication.' Alex, the reviewer, notices that Mark hasn't included any documentation on how to use the new API endpoints. Which of the following is the MOST appropriate way for Alex to address this in a Slack channel?
Option A: "Hey Mark, great work on the auth implementation! Just wanted to flag that we need some documentation around these new endpoints – it'll make things much easier for anyone using them."
This question assesses understanding of constructive feedback within a code review context. Option A is ideal because it acknowledges the positive work done while directly addressing the issue – lack of documentation – and offers a helpful suggestion. Options B and C are overly critical or dismissive, while option D avoids public discussion and doesn't provide actionable guidance. The goal is to offer feedback in a way that encourages improvement rather than demoralizing the developer.
10 / 26
John just submitted a pull request to fix a bug in the authentication service. The PR description reads: 'Fixed issue where users couldn't log in after password reset. Updated validation logic.' A reviewer, Sarah, comments on the PR with: 'Looks good! 👍'. John replies to Sarah with: 'Thanks! Just ran tests and everything seems to be working as expected.'
Which of the following responses is the most professional and helpful for John to send in this situation?
Option B is the best response because it acknowledges Sarah's review and expresses gratitude for her time. Simply stating 'No problem' or 'Just letting you know' lacks context and doesn't demonstrate a professional exchange. Providing a direct link to test results adds valuable information and shows proactive communication – a key element of effective code reviews, especially when confirming functionality.
11 / 26
David is working on a new feature for the user profile service. He's using Slack to discuss design choices with his team. He sends a message in #design-reviews: 'Thinking of using React Context for this. Thoughts?' Maria replies immediately: 'Sounds good!' But then Ben thinks about it and asks, 'Why not use Redux? It's more predictable.' David responds with: 'React Context is simpler to set up.' What should David do next to continue the discussion constructively?
The key here is acknowledging differing opinions while maintaining a collaborative tone. Option A is too dismissive and doesn't value Ben's input. Option B is overly assertive and risks escalating the discussion. While option D (a DM) can be useful for more complex explanations, it fragments the conversation and isn't ideal for initial design feedback. Option 3 demonstrates active listening, respectfully presents David's rationale, and invites further dialogue – a far better approach than simply pushing his preference. It allows for a productive exchange of ideas rather than a single-sided argument.
12 / 26
Alex is reviewing a PR for a new microservice. The PR description states: 'Implemented the user authentication flow using OAuth 2.0 and JWTs.' During the review, Alex notices that the code doesn't handle rate limiting. He wants to point this out to the developer, Mark.
Which of the following is the most effective way for Alex to provide feedback in a Slack channel?
The best approach here is to post a comment in the PR's Slack thread. This keeps the discussion visible to the entire team, allows others to contribute ideas, and provides context for Mark. Sending a DM might isolate Mark, and replying directly to the commit message isn't standard practice; emailing is generally too formal for quick code review feedback. This maintains transparency and collaboration which are key to effective development.
13 / 26
Mark just submitted a pull request to update the user authentication microservice. The PR description reads: 'Implemented OAuth 2.0 and JWTs for user authentication.' Alex, the reviewer, notices that Mark hasn't included any documentation on how to use the new API endpoints. Which of the following is the MOST appropriate way for Alex to address this in a Slack channel?
Option A: "Hey Mark, great work on the auth implementation! Just wanted to flag that we need some documentation around these new endpoints – it'll make things much easier for anyone using them."
This question assesses understanding of constructive feedback within a code review context. Option A is ideal because it acknowledges the positive work done while directly addressing the issue – lack of documentation – and offers a helpful suggestion. Options B and C are overly critical or dismissive, while option D avoids public discussion and doesn't provide actionable guidance. The goal is to offer feedback in a way that encourages improvement rather than demoralizing the developer.
14 / 26
John just submitted a pull request to fix a bug in the authentication service. The PR description reads: 'Fixed issue where users couldn't log in after password reset. Updated validation logic.' A reviewer, Sarah, comments on the PR with: 'Looks good! 👍'. John replies to Sarah with: 'Thanks! Just ran tests and everything seems to be working as expected.'
Which of the following responses is the most professional and helpful for John to send in this situation?
Option B is the best response because it acknowledges Sarah's review and expresses gratitude for her time. Simply stating 'No problem' or 'Just letting you know' lacks context and doesn't demonstrate a professional exchange. Providing a direct link to test results adds valuable information and shows proactive communication – a key element of effective code reviews, especially when confirming functionality.
15 / 26
David is working on a new feature for the user profile service. He's using Slack to discuss design choices with his team. He sends a message in #design-reviews: 'Thinking of using React Context for this. Thoughts?' Maria replies immediately: 'Sounds good!' But then Ben thinks about it and asks, 'Why not use Redux? It's more predictable.' David responds with: 'React Context is simpler to set up.' What should David do next to continue the discussion constructively?
The key here is acknowledging differing opinions while maintaining a collaborative tone. Option A is too dismissive and doesn't value Ben's input. Option B is overly assertive and risks escalating the discussion. While option D (a DM) can be useful for more complex explanations, it fragments the conversation and isn't ideal for initial design feedback. Option 3 demonstrates active listening, respectfully presents David's rationale, and invites further dialogue – a far better approach than simply pushing his preference. It allows for a productive exchange of ideas rather than a single-sided argument.
16 / 26
Alex is reviewing a PR for a new microservice. The PR description states: 'Implemented the user authentication flow using OAuth 2.0 and JWTs.' During the review, Alex notices that the code doesn't handle rate limiting. He wants to point this out to the developer, Mark.
Which of the following is the most effective way for Alex to provide feedback in a Slack channel?
The best approach here is to post a comment in the PR's Slack thread. This keeps the discussion visible to the entire team, allows others to contribute ideas, and provides context for Mark. Sending a DM might isolate Mark, and replying directly to the commit message isn't standard practice; emailing is generally too formal for quick code review feedback. This maintains transparency and collaboration which are key to effective development.
17 / 26
Mark just submitted a pull request to update the user authentication microservice. The PR description reads: 'Implemented OAuth 2.0 and JWTs for user authentication.' Alex, the reviewer, notices that Mark hasn't included any documentation on how to use the new API endpoints. Which of the following is the MOST appropriate way for Alex to address this in a Slack channel?
Option A: "Hey Mark, great work on the auth implementation! Just wanted to flag that we need some documentation around these new endpoints – it'll make things much easier for anyone using them."
This question assesses understanding of constructive feedback within a code review context. Option A is ideal because it acknowledges the positive work done while directly addressing the issue – lack of documentation – and offers a helpful suggestion. Options B and C are overly critical or dismissive, while option D avoids public discussion and doesn't provide actionable guidance. The goal is to offer feedback in a way that encourages improvement rather than demoralizing the developer.
18 / 26
John just submitted a pull request to fix a bug in the authentication service. The PR description reads: 'Fixed issue where users couldn't log in after password reset. Updated validation logic.' A reviewer, Sarah, comments on the PR with: 'Looks good! 👍'. John replies to Sarah with: 'Thanks! Just ran tests and everything seems to be working as expected.'
Which of the following responses is the most professional and helpful for John to send in this situation?
Option B is the best response because it acknowledges Sarah's review and expresses gratitude for her time. Simply stating 'No problem' or 'Just letting you know' lacks context and doesn't demonstrate a professional exchange. Providing a direct link to test results adds valuable information and shows proactive communication – a key element of effective code reviews, especially when confirming functionality.
19 / 26
David is working on a new feature for the user profile service. He's using Slack to discuss design choices with his team. He sends a message in #design-reviews: 'Thinking of using React Context for this. Thoughts?' Maria replies immediately: 'Sounds good!' But then Ben thinks about it and asks, 'Why not use Redux? It's more predictable.' David responds with: 'React Context is simpler to set up.' What should David do next to continue the discussion constructively?
The key here is acknowledging differing opinions while maintaining a collaborative tone. Option A is too dismissive and doesn't value Ben's input. Option B is overly assertive and risks escalating the discussion. While option D (a DM) can be useful for more complex explanations, it fragments the conversation and isn't ideal for initial design feedback. Option 3 demonstrates active listening, respectfully presents David's rationale, and invites further dialogue – a far better approach than simply pushing his preference. It allows for a productive exchange of ideas rather than a single-sided argument.
20 / 26
Alex is reviewing a PR for a new microservice. The PR description states: 'Implemented the user authentication flow using OAuth 2.0 and JWTs.' During the review, Alex notices that the code doesn't handle rate limiting. He wants to point this out to the developer, Mark.
Which of the following is the most effective way for Alex to provide feedback in a Slack channel?
The best approach here is to post a comment in the PR's Slack thread. This keeps the discussion visible to the entire team, allows others to contribute ideas, and provides context for Mark. Sending a DM might isolate Mark, and replying directly to the commit message isn't standard practice; emailing is generally too formal for quick code review feedback. This maintains transparency and collaboration which are key to effective development.
21 / 26
Mark just submitted a pull request to update the user authentication microservice. The PR description reads: 'Implemented OAuth 2.0 and JWTs for user authentication.' Alex, the reviewer, notices that Mark hasn't included any documentation on how to use the new API endpoints. Which of the following is the MOST appropriate way for Alex to address this in a Slack channel?
Option A: "Hey Mark, great work on the auth implementation! Just wanted to flag that we need some documentation around these new endpoints – it'll make things much easier for anyone using them."
This question assesses understanding of constructive feedback within a code review context. Option A is ideal because it acknowledges the positive work done while directly addressing the issue – lack of documentation – and offers a helpful suggestion. Options B and C are overly critical or dismissive, while option D avoids public discussion and doesn't provide actionable guidance. The goal is to offer feedback in a way that encourages improvement rather than demoralizing the developer.
22 / 26
Sarah is reviewing a code comment attached to a recent pull request. The comment reads: 'This fix addresses the issue where users were experiencing intermittent login failures.' She notices the commit message is just 'Fix login'. What's the best response?
The key here is clarity for future developers. A good commit message should explain *why* the change was made (the bug) and briefly describe *how* it was fixed. Option 1 highlights this lack of detail, whereas options 2, 3 and 4 are all acceptable descriptions.
23 / 26
Alex is drafting a Slack message to his team regarding a potential performance issue with a newly deployed API endpoint. The endpoint consistently returns responses slower than expected during peak hours. What's the most appropriate phrasing for this situation?
A good Slack message needs to convey the problem clearly *and* suggest next steps. Simply stating 'API is slow' isn't helpful. The correct answer emphasizes the need for more details (peak hours, endpoint name) and potential investigation.
24 / 26
Mark is writing a PR description for a feature that adds support for multiple file uploads. He wants to ensure the reviewer understands the scope of his work. Which of the following descriptions is MOST effective?
The PR description should clearly state what the change *does*. It needs to include details about the new functionality (multiple file uploads) and acknowledge potential impacts or limitations. This allows the reviewer to assess whether the implementation meets the requirements.
25 / 26
John is reviewing a pull request that implements a new user authentication flow. The code includes detailed comments explaining each step of the process. However, the PR description simply states: 'Implemented OAuth 2.0 and JWTs'. What should John do?
The PR description serves as a high-level overview. The *details* are contained in the code comments. A good reviewer will use both to fully understand the changes made and ensure they align with the overall design.
26 / 26
Maria is reviewing a pull request for a database migration script. The script updates several tables and adds new indexes. The PR description says: 'Updated database schema'. What further information should Maria request from the author to ensure proper validation?
The PR description lacks specifics about *which* tables were updated and *what* indexes were added. This level of detail is crucial for verifying that the migration script doesn't introduce unintended consequences or break existing functionality.
What does the "Slack & Email Thread Etiquette — English for IT" exercise cover?
Practise professional async communication: when to use threads vs main channels, DMs vs channels, and how to keep team conversations tidy. 5 exercises.
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.
How many questions are in "Slack & Email Thread Etiquette — English for IT"?
This exercise has 26 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Email & Writing exercises?
Browse the full Email & Writing hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.