Alex: Welcome back. Bonus D is all about Notifications, and you may also see the issue describe it as Notification Mastery.

Jamie: I like this topic because notifications sound small until they take over your day.

Alex: Exactly. GitHub notifications are how GitHub tells you that something may need your attention: a mention, a review request, an assignment, a reply, or a failed check. The goal is to stay reachable without letting every repository become an interruption machine.

Jamie: So this is not about getting to inbox zero for the sake of it. It is about knowing which signals deserve attention and which ones can wait.

---

Alex: This bonus is web-first. The main place to practice is the GitHub notification inbox at github.com/notifications, not your email app. Email can be useful, but it depends on spam filters, mail servers, personal settings, and other things the workshop cannot control.

Jamie: That makes sense. If two learners have different email providers, they could do the same GitHub work and still have completely different email results.

Alex: Right. The reliable workflow is to use the notification bell or go straight to github.com/notifications. Bonus D unlocks after Challenge 15, along with Challenge 16 and Bonus Challenges A through E. And the Day 1 practice that this builds on happens in your own Learning Room repository, where you created an issue, branch, commit, pull request, and merge.

Jamie: And Chapter 10 itself is guided practice, not an autograded bot check, correct?

Alex: Correct. Notification settings live at the account level, so the Learning Room PR bot cannot safely validate them. The original Chapter 10 walkthrough is short, about five to eight minutes, and the evidence is a structured comment on your assigned challenge issue.

---

Jamie: Before we touch settings, what actually causes a GitHub notification?

Alex: Several things. Someone can type @your-username in an issue, pull request, or discussion. You can be requested as a reviewer on a pull request, assigned to an issue or pull request, or subscribed to a thread because you commented on it. You can also get notified when a continuous integration check fails on your pull request, or when a release is published in a repository you are watching for that kind of activity.

Jamie: That explains why review requests are such a common notification. They are not just chatter; they are a specific request for your attention.

Alex: Yes, and unexpected mentions deserve a calm check too. Sometimes someone tags you by mistake, and sometimes they really do need your input. Open the thread, decide whether to respond, mute it, or leave it in your workflow, and do not assume every mention is equally urgent.

---

Jamie: The Watch button is where a lot of notification overload starts, right?

Alex: It is. Each repository has a subscription level. Participating and @mentions means you hear about threads where you commented, were assigned, were requested, or were mentioned. All Activity means every issue, comment, and pull request can come to you. Ignore means no notifications from that repo, and Custom lets you choose categories like issues, pull requests, or releases.

Jamie: If I am in my Learning Room repository, how do I change that without relying on a mouse?

Alex: On the repository page, the Watch control is near Star and Fork. With NVDA or JAWS on Windows, use button navigation, often the B key, until you hear Watch or Unwatch, press Enter, move through the options with the arrow keys, and press Enter on the level you want. With VoiceOver on macOS, use Quick Nav to find the Watch button, open it with VO+Space, move through the choices, and select with VO+Space. The button label should update, which confirms the change.

Jamie: And starring is different from watching, which is an easy thing to mix up.

Alex: Very easy. Starring is more like bookmarking or showing interest in a repository. Watching changes what notifications you receive. A good workshop default is Participating and @mentions for most repositories, All Activity only for repositories you actively maintain or contribute to every day, Custom for repositories you read occasionally, and Unwatch for repositories you are finished with.

---

Jamie: Once the watch level is reasonable, the inbox itself becomes much less scary.

Alex: Yes. Open github.com/notifications, or use the notification bell in the GitHub header. If GitHub keyboard shortcuts are enabled for your account, G then N can also open notifications. The page is organized around tabs, filters, and a list of notification items.

Jamie: What should a screen reader user expect to hear in that list?

Alex: Each notification is a link or row that usually announces the title, the repository, and the reason, such as mention, review requested, or assignment. You can move through the list with your usual reading commands or link navigation, then press Enter to open one. For practice, use the Review requested filter to find pull requests asking for your review, clear that filter, then use Assigned to find issues or pull requests assigned to you. If you open a pull request notification, check the conversation and status area so you know whether review, tests, or another action is needed.

Jamie: What if the inbox is empty? That can feel like you did something wrong.

Alex: An empty inbox is fine. You may simply have no current notifications. You can switch to Done to look at older items, or ask a facilitator to model one notification action live. If filters show nothing, clear active filters first, then apply one filter at a time, including repository or organization filters when you need to narrow a busy inbox.

---

Jamie: Okay, so I have a notification in front of me. What are the main actions?

Alex: You can mark a notification as done, mark it read or unread, mute a thread, or open it and respond. In the browser inbox, E commonly marks an item done, I toggles read and unread, and GitHub's shortcut help may show mute as M or Shift+M depending on the current interface. If a screen reader captures the shortcut, move focus to the notification row or use the visible action menu instead.

Jamie: I always wonder about the difference between done and mute.

Alex: Done removes it from your inbox for now, but future activity can notify you again. Mute says you do not want future updates from that thread, so save it for noisy or no-longer-relevant conversations. For a large backlog, mark all as done can be useful after you have checked for review requests and assignments, but do not use it to hide work you actually need to do.

Jamie: That is the balance: reduce noise, but do not make yourself unreachable.

Alex: Exactly. A practical daily routine is to check filtered notifications once or twice a day, handle review requests and assignments first, then mute or finish the rest intentionally.

---

Jamie: Bonus D also sends learners to github.com/settings/notifications. What changes are worth considering there?

Alex: Start with the defaults and change one thing at a time. A common configured setup is email on and web on for Participating, because replies to your own conversations matter. For Watching, many people turn email off and keep web on, so watched repository activity waits in GitHub instead of interrupting their email. For GitHub Actions, successful runs usually do not need email, while failed runs can be worth sending because they may block a pull request.

Jamie: And if someone uses more than one email address?

Alex: They can use custom routing. For example, organization notifications for Community-Access can go to a workshop email, while personal project notifications go to a personal address. If they use the GitHub mobile app, they can also tune push notifications there, but mobile is a reference option, not required. VS Code can show notification-related items through the GitHub Pull Requests extension, GitHub Desktop does not manage notifications, and the browser inbox remains the shared workshop path.

---

Jamie: What does a good Bonus D evidence comment include?

Alex: It should describe your notification configuration and your strategy. Answer how you will know when someone requests your review, how you will avoid being overwhelmed by busy repositories, and how you plan to use the GitHub inbox: read everything, triage with filters, or check specific categories first. The checklist asks you to review email notifications, web notifications, repository watching, custom routing if you have multiple emails, and mobile push settings if you use the app. In Chapter 10, your completion comment can also say your watch level, the filters you tested, and whether you muted or marked a thread done, then you close the assigned challenge issue.

Jamie: So completion is not a perfect screenshot of every setting. It is proof that you made intentional choices and can explain them.

Alex: Yes. If you changed at least one default setting and can explain how that keeps you informed while reducing noise, you have met the heart of the bonus. If you cannot find settings, go to github.com, open your profile menu, choose Settings, then Notifications in the left sidebar. If there are too many options, start with review request email or web notifications, then adjust watching. For current details, use the official GitHub documentation and GitHub's changelog, because interface labels can change over time.

---

Jamie: This also wraps up a lot of Day 1 skills, doesn't it?

Alex: It does. By this point, you have practiced the flow of noticing work, opening the right GitHub page, taking an action, and leaving evidence. If it was your first time using these tools, the confidence check is simple: can you find work assigned to you, find review requests, change a watch level, and quiet a noisy thread?

Jamie: And Day 2 adds more collaboration where that matters: reviews, ongoing issues, and planning contributions without losing track of conversations.

Alex: Exactly. Notification hygiene is part of being a dependable contributor. You are not trying to hear everything. You are building a system that helps you hear what matters when it matters.