Notifications and Mentions
Managing your notification inbox, @mentions, and strategies for avoiding overload.
Listen
Transcript
Alex: Welcome back. Today we're talking about GitHub notifications, which are the little signals GitHub sends when something might need your attention.
Jamie: And I am glad we are doing this, because notifications can feel like a second inbox that nobody warned you about.
Alex: Exactly. GitHub can notify you because you participated in a thread, because someone mentioned you, because you were assigned, because someone requested your review, or because something happened on a repository you chose to watch.
Jamie: So participating and watching are not the same thing.
Alex: Right. Participating means GitHub sees you as directly involved. You commented, opened the issue or pull request, got assigned, were requested as a reviewer, or someone typed your username with an at sign. Watching is a repo-level choice that can add more notifications, sometimes a lot more.
Jamie: That explains why one repository can be quiet and another can suddenly flood you.
Alex: Yes. Common notification reasons include a mention, a review request, an assignment, activity on a subscribed thread, a failed CI check on your pull request, or a release from a repo you watch for all activity. CI means continuous integration, the automated checks that run tests or validation after code changes.
Jamie: For the workshop, what are learners actually expected to do with this?
Alex: Chapter 10 is guided practice, not an autograded automation task. Notification settings belong to your GitHub account, so the Learning Room bot cannot reliably grade them. The pattern is configure, filter, and act, then leave evidence in your assigned Chapter 10 challenge issue.
Jamie: And this uses the GitHub website, not email, right?
Alex: Right. The practice happens at github.com/notifications, or by using the bell icon in the GitHub header. You do not need email delivery to complete it, because email depends on mail settings, spam filters, and other things outside the workshop. The web inbox is consistent, and the habits transfer later if you choose to use email or mobile notifications.
Jamie: This also connects back to Challenge 09, the Day 1 stretch, because final pull request readiness depends on seeing review signals and knowing when a PR is ready to merge.
Alex: Yes. Challenge 09 is where you pay attention to review requests, status checks, merging, and verifying that a linked issue closes. Chapter 10 gives you the inbox skills behind that work, and Bonus Challenge D goes deeper into notification hygiene, mentions, subscriptions, and avoiding overload.
Alex: Start in your Learning Room repository on GitHub.com. That repo is provisioned for your Day 1 practice, including issues, branches, commits, pull requests, and merges. Near the top right of the repository page, in the same general area as Star and Fork, find the Watch control.
Jamie: What should screen reader users listen for there?
Alex: With NVDA or JAWS, you can move by buttons until you hear Watch, Unwatch, or something similar. Press Enter to open the dropdown, move through the choices with the arrow keys, and press Enter on the level you want. With VoiceOver on macOS, use Quick Nav or VO navigation to find the Watch button, use VO+Space to open it, move through the choices, and use VO+Space to choose.
Jamie: And the recommended choice for most workshop repos is Participating and @mentions.
Alex: Yes. That keeps you informed when you are involved, without subscribing to every comment on every issue. Other levels matter too: All activity means every issue, PR, and comment; Ignore means no notifications from that repository; Custom lets you pick certain types, like issues, pull requests, or releases. You may also hear not watching in GitHub language, which usually means you are not asking for broad repo updates, though direct participation can still reach you.
Jamie: Where does starring fit? I have definitely confused Star and Watch before.
Alex: A star is a bookmark or a public signal that you like or want to find a repository later. Watching changes notifications. A common mistake is starring a repo you like, then also choosing too many watch updates by accident. If that happens, go back to the Watch dropdown and choose Participating and @mentions, Custom, or Ignore, depending on how quiet you need it to be.
Jamie: Once the watch level is set, the action moves to the inbox.
Alex: Yes. Go to github.com/notifications, use the bell icon, or, if GitHub keyboard shortcuts are active for your account, press G then N. The page usually has navigation and filters around the list, with tabs or controls for unread, done, and saved notifications.
Jamie: What does each notification sound like when you move through the list?
Alex: The list is made of links and controls. A notification normally announces the title, the repository, and the reason, such as mention, review requested, assignment, or status. Open one by activating its title link, read enough to understand why it appeared, then return to the inbox.
Jamie: And then there are actions: read, done, saved, and mute.
Alex: Right. Marking read or unread changes whether it appears as new. Marking done removes it from the active inbox, but future activity can bring it back. Saving keeps something available for later. Muting or unsubscribing from a thread stops future updates unless something directly pulls you back in, such as a new mention, depending on GitHub's current rules.
Alex: Filtering is where the inbox becomes useful instead of noisy. In the Chapter 10 walkthrough, activate the Review requested filter first, then clear it and activate Assigned.
Jamie: Review requested is probably the one people will use constantly in real projects.
Alex: Absolutely. It shows pull requests where someone wants your review. Assigned shows issues or PRs assigned to you. You can also filter by repository or organization, which is helpful when your personal work, class work, and open source work all share the same inbox.
Jamie: What about a pull request where the notification is really about a failing check?
Alex: Open the notification, go to the pull request, and look for the checks or status area. If a CI check failed, you are not just reading a message; you are deciding whether the failure needs your action before merge. That is especially important during final PR readiness work in Challenge 09.
Jamie: Let's talk about mentions, because typing someone's username feels simple, but it can also be a little loaded.
Alex: A mention is written as @ followed by a GitHub username, like @alex-example. It is a direct attention signal, so use it when you need that person to see the comment. A team mention looks like @org/team-name, and it notifies members of that team according to their organization settings and permissions.
Jamie: So a mention is not decoration. It is more like saying, please look at this.
Alex: Exactly. Good mentions include context, such as what you need reviewed, what decision is blocked, or what question you are asking. If you receive a mention you did not expect, first check whether it needs action. If it was accidental or no longer relevant, it is fine to reply briefly, mark it done, or unsubscribe from the thread.
Alex: When your inbox grows, do not try to treat every notification the same way. First handle the things that directly name you: mentions, assignments, and review requests. Then scan repo or organization filters for anything you chose to follow.
Jamie: I get nervous about mark all as done. It sounds like deleting everything.
Alex: It is not deletion. Done means the notification leaves the active inbox, but the issue or PR still exists, and future activity can notify you again if you are still subscribed. Still, use mark all as done only after a quick scan, and save anything you truly need to revisit.
Jamie: Where do account settings come in?
Alex: In GitHub Settings, you can configure notification preferences for web, email, and other delivery choices. Email can be useful, but it is optional for this challenge. The web inbox is the shared baseline, and the GitHub mobile app is a useful reference if you want notifications on your phone later.
Jamie: So mobile is allowed as a personal workflow, but it is not the thing being tested here.
Alex: Correct. And if your screen reader intercepts a shortcut like E, I, M, or Shift+M, focus the notification row or use the visible action menu instead. NVDA, JAWS, and VoiceOver each have their own browsing modes, so the reliable path is: find the notification, confirm the title and reason, then choose the action intentionally.
Jamie: What if someone wants a command-line style workflow too?
Alex: The gh CLI can help with notification-like checks, even though the browser inbox is still the focus here. You can list pull requests requesting your review, view issues assigned to you, check the status of a pull request, and open the notification page in your browser with gh browse. For example, gh pr list with a review-requested search, gh issue list assigned to you, and gh pr checks can help you find work without hunting through pages.
Jamie: And VS Code?
Alex: With the GitHub Pull Requests extension, VS Code can show items needing attention and open related issues or pull requests. GitHub Desktop is different; it is great for commits, branches, and syncing, but it does not manage the notification inbox. For notification triage, use the browser, the GitHub mobile app if you choose, or CLI-supported checks.
Alex: To complete the Chapter 10 practice, change the watch level on your Learning Room repository, test the Review requested and Assigned filters, and perform one inbox action on a non-critical thread. That action can be mute, unsubscribe, mark done, mark read or unread, or save, depending on what is available and appropriate.
Jamie: Then the evidence is a comment on the assigned challenge issue.
Alex: Yes. Post a short completion comment that says Chapter 10 completed, the watch level you set, the filters you tested, and the inbox action you performed with a brief thread description. Then close your Chapter 10 challenge issue.
Jamie: And if the inbox is empty or the filters show nothing?
Alex: That is okay. Check the Done tab for older notifications, clear active filters before trying a new one, and ask a facilitator to model an inbox action if you need to hear the workflow once. If you are unsure how this connects to merge readiness, compare your final PR checks with the Challenge 9 reference solution.
Jamie: The confidence check is pretty practical: can you reduce noise, find review requests, find assigned work, and choose what to do with a notification?
Alex: Exactly. If this was your first time, you have already learned a professional maintenance habit: set sane watch levels, filter for signal, act on each item, and keep a daily rhythm that does not depend on panic. Between days, keep the Learning Room inbox manageable, and when Day 2 adds broader collaboration, you will have a calmer way to notice what needs you.
Workshop Content
Companion Podcast and Transcript
Use audio and transcript companions to review concepts in a conversational format.
Notifications and Mentions
Companion audio: this episode reinforces key ideas and may not be a word-for-word reading of this page.
Open audio file (external) Full transcript source (external)
Transcript preview
Alex: Welcome back. Today we're talking about GitHub notifications, which are the little signals GitHub sends when something might need your attention.
Jamie: And I am glad we are doing this, because notifications can feel like a second inbox that nobody warned you about.
Alex: Exactly. GitHub can notify you because you participated in a thread, because someone mentioned you, because you were assigned, because someone requested your review, or because something happened on a repository you chose to watch.
Jamie: So participating and watching are not the same thing.
Notifications
Listen to Episode 10: Notifications and Mentions - a conversational audio overview of this chapter. Listen before reading to preview the concepts, or after to reinforce what you learned.
Related appendices: Appendix T: Community and Social | Appendix U: Discussions and Gists | Appendix V: GitHub Mobile Authoritative sources: GitHub Docs: About notifications
Managing Your GitHub Notification Inbox
See also: Appendix V: GitHub Mobile for managing notifications on your phone.
GitHub notifications are how GitHub tells you when something needs your attention. This guide teaches you to keep the inbox useful - not overwhelming - using only your keyboard and screen reader.
Workshop Recommendation (Chapter 10)
For this workshop, Chapter 10 is a guided practice chapter, not a graded automation chapter.
- Challenge count: 1 guided walkthrough
- Automation check: none - notification settings are account-level and cannot be validated by the Learning Room PR bot
- Evidence: structured completion comment on your assigned challenge issue
- Pattern: configure, filter, act
Important Note: This Challenge Uses GitHub's Web Notification Inbox
This challenge focuses on GitHub's web-based notification inbox (at github.com/notifications), not email notifications. You do NOT need to configure email delivery, and you do NOT need to receive emails to complete this challenge.
Why we focus on the web inbox:
- Email delivery depends on your mail server, ISP, spam filters, and account settings—factors outside our control
- GitHub's web notification inbox is always available and works the same way for everyone
- Professional developers typically check notifications in the GitHub app or web UI rather than waiting for emails
- The skills you learn (filtering, muting, managing noise) apply whether you eventually enable email or not
What you will do:
- Use GitHub's web notification inbox to view and filter notifications
- Configure repository watch levels to control what notifications you receive
- Practice managing your inbox with GitHub's built-in actions (mute, mark done)
If you have already configured email notifications on your GitHub account, that is fine—but this challenge does not require or test email delivery. Focus on the web inbox workflow instead.
Chapter 10 Challenge Set
- Configure notifications and practice inbox management - set your watch level, use filters to find relevant notifications, and perform one inbox action.
Challenge 10.1 Step-by-Step: Notification Inbox Walkthrough
Goal: Set up a useful notification workflow so you can keep up with reviews, mentions, and assignments without inbox overload.
Where you are working: the GitHub.com notifications page and your Learning Room repository settings.
Estimated time: 5-8 minutes.
- Open your Learning Room repository on GitHub.com.
- Find the Watch button near the top-right of the repository page (next to Star and Fork).
- Activate the Watch dropdown and select Participating and @mentions. This means you only get notified when someone @mentions you or you are directly participating in a thread.
- Open the notifications inbox by navigating to
https://github.com/notifications(or activate the bell icon in the GitHub header). - In the notification filters, activate the Review requested filter. This shows only notifications where someone has asked you to review their PR.
- Clear that filter and activate the Assigned filter. This shows notifications for issues and PRs assigned to you.
- Open one notification by activating its title link. Read it briefly, then navigate back to the inbox.
- Perform one inbox action on a non-critical notification thread:
- Press
Mto mute the thread (you will not receive future updates), or - Press
Eto mark done (removes it from inbox but you can still get future updates).
- Press
Screen reader tip: The notification list is a standard list of links. Each notification announces its title, repository, and reason (mention, review request, assignment). Use arrow keys to move between notifications and Enter to open one.
You are done when: You have changed your watch level, used two different filters, and performed one inbox action (mute or done).
Completing Chapter 10: Submit Your Evidence
Open your assigned Chapter 10 challenge issue and post a completion comment:
Chapter 10 completed:
- Watch level set to: Participating and @mentions
- Filters tested: Review requested, Assigned
- Inbox action performed: [mute / mark done] on [thread description]
Close your Chapter 10 challenge issue when done.
Expected Outcomes
- Student can configure repository watch levels to reduce noise.
- Student can find review requests and assigned work quickly using filters.
- Student can reduce notification noise with mute or done actions.
If You Get Stuck
- Can't find the Watch button? It is near the top-right of the repository page, in the same row as Star and Fork.
- Notification inbox is empty? You may not have any notifications yet - that is fine. Switch to the Done tab and practice the mute/done action flow on an older notification.
- Keyboard shortcuts not working? If your screen reader intercepts
MorE, click on the notification row first to give it focus, then press the shortcut. - Filters not showing results? Clear all filters first (click the X next to each active filter), then apply one filter at a time.
- Ask facilitator to model one inbox action live, then repeat the steps yourself.
- Finished but not sure you did it right? Compare your work against the Challenge 9 reference solution.
Learning Moment
Notification management protects focus. You can stay responsive to your team without drowning in updates. The habit you build here - checking filtered notifications once or twice a day - is how productive open source contributors stay on top of their work.
Learning Pattern Used in This Chapter
- Configure settings proactively (watch level) before work generates noise.
- Use filters to find signal in noise (review requests, assignments).
- Take decisive action on each notification (mute, done, or respond).
- Build a daily routine that keeps your inbox manageable.
What Generates a Notification?
GitHub sends you a notification when:
| Event | You are notified if... |
|---|---|
| Someone @mentions you | @your-username appears in any issue, PR, or discussion |
| A PR is assigned to you for review | You are added as a reviewer |
| An issue or PR is assigned to you | You are assigned |
| There is activity on a thread you are subscribed to | You commented, were mentioned, or chose to subscribe |
| A CI check fails on your PR | Actions sends a failure notification |
| A release is published | You are watching the repo for all activity |
Notification Subscription Levels
For each repository, you choose how many notifications to receive:
| Level | What You Receive |
|---|---|
| Participating and @mentions | Only notifications where you participated (commented, were assigned, @mentioned). Recommended for most repos. |
| All Activity | Every issue opened, every comment, every PR. Only use this for your own repos or very active contribution. |
| Ignore | No notifications from this repo at all. |
| Custom | Fine-grained control: issues only, PRs only, releases, etc. |
Changing your watch settings for a repo
Visual / mouse users
At the top of any repository page, find the Watch button (near Star and Fork). Click it to open a dropdown with levels: Participating and @mentions, All Activity, Custom, and Ignore. Click your preferred level - it takes effect immediately.
Screen reader users (NVDA / JAWS - Windows)
- Find the Watch button in the repo header (
Bto navigate buttons → find "Watch [N]" or "Unwatch" button) - Press
Enterto open the dropdown - Press
↑/↓to navigate the subscription options - Press
Enterto select your preferred level - The button label updates to confirm your choice
Screen reader users (VoiceOver - macOS)
- Quick Nav
Bto find the Watch button in the repo header (listen for "Watch" or "Unwatch") VO+Spaceto open the dropdownVO+Downor arrow keys to navigate subscription optionsVO+Spaceto select your preferred level- The button label updates to confirm your choice
Recommended setting for most repos: “Participating and @mentions only” - you stay in the loop on what involves you without noise.
The Notifications Inbox
Tool Cards: Manage Notifications
github.com (browser):
- Go to github.com/notifications (or press
GthenN). - Use
Eto mark done,Ito mark read/unread,Shift+Mto mute a thread.
VS Code Desktop (GitHub Pull Requests extension):
- The Notifications view in the GitHub sidebar shows items needing attention.
- Click a notification to open the related issue or PR directly in VS Code.
GitHub Desktop: GitHub Desktop does not manage notifications. Use the browser or CLI.
Git CLI / GitHub CLI:
# List PRs requesting your review (most common notification)
gh search prs --review-requested @me --state open
# Open the notifications page in your browser
gh browse notifications
Navigate to your inbox: https://github.com/notifications or press G then N (GitHub keyboard shortcut).
Screen reader note: The G N shortcut uses two sequential key presses (not simultaneous). Press G, release it, then press N. This works in Browse Mode.
GitHub CLI (gh) alternative - notifications
View and manage your GitHub notification status from the terminal:
# Check your notification status (opens the GitHub notification inbox)
gh api notifications --jq '.[].subject.title' | head -20
# View PRs that need your review (most common notification reason)
gh search prs --review-requested @me --state open
# View issues assigned to you
gh issue list --assignee @me --state open
# Check PR status for a specific notification
gh pr view 42 --repo owner/repo
Note: The GitHub CLI does not have a first-class gh notifications command. For full inbox management (mark as read, mute, archive), use the web interface at github.com/notifications. The gh CLI is most useful for quickly checking PR review requests and issue assignments that generate notifications.
Page structure
[Filters sidebar on left] ← Unread / Participating / @Mentions / Assigned / etc.
[Notification list in center] ← Each notification is a row
[Detail pane on right] ← Preview the notification (can be disabled)
Navigating the notification list
Visual / mouse users
The inbox shows notifications grouped by date (Today, Yesterday, This week, Older). Each row shows the repository, the issue or PR title, the event type, and the time. Click a row to open the notification and go to the issue or PR. Use the left sidebar filters to narrow the view. The Mark all as done button clears the entire inbox at once.
Screen reader users (NVDA / JAWS)
D→ main content landmarkHto navigate group headings (Today / Yesterday / This week / Older)Tabthrough individual notifications - each row announces: repo name, issue/PR title, event type, timeEnterto open the notification (goes to the issue/PR page)
Screen reader users (VoiceOver)
VO+U→ Main → navigate to notification listVO+Downto move through notificationsVO+Spaceto open a notification
What is announced per notification
"microsoft/vscode - Add keyboard shortcut for accessible view - @username mentioned you - 2 hours ago"
Components: repo/org | thread title | event type | timestamp
Learning Cards: The Notifications Inbox
Screen reader users
- Press
G N(two sequential keys, not simultaneous) from any GitHub page to jump directly to your notifications inbox - Press
Hto navigate date-group headings (Today, Yesterday, This Week, Older), thenTabthrough individual notification rows within each group - Each notification row announces: repository name, issue/PR title, event type (mentioned, review requested, assigned), and relative timestamp
Low vision users
- The inbox has a three-panel layout: filters on the left, notification list in the center, and an optional detail preview on the right; at high zoom the detail pane may collapse
- Unread notifications have a blue dot on the left edge of the row; read notifications do not, which is the primary visual distinction
- The left sidebar filter labels (Inbox, Unread, Saved, Done) are text links that remain readable at any zoom level
Sighted users
- The notifications inbox at github.com/notifications shows a list of notifications grouped by date, with a filter sidebar on the left
- Unread notifications have a blue dot indicator; click a notification row to open the issue or PR in context
- Quick actions appear on hover: a checkmark icon to mark as done, a bookmark icon to save for later, and a mute icon to unsubscribe from the thread
Inbox Actions - Keyboard Shortcuts
These shortcuts work when a notification is focused in the inbox:
| Shortcut | Action |
|---|---|
E |
Mark as done (archive from inbox) |
Shift+I |
Mark as read without opening |
Shift+U |
Mark as unread |
M |
Mute thread (no more notifications from this thread) |
S |
Save for later |
Enter |
Open the notification |
Screen reader note: These are GitHub's own keyboard shortcuts. In Browse Mode, some of these letters are also navigation keys. To use these shortcuts reliably, make sure focus is on the notification row (tab to it) rather than in browse/reading mode.
Filtering the Inbox
The left sidebar has quick filters. Use Tab or K to navigate to them:
| Filter | Shows |
|---|---|
| Inbox | All active notifications (default) |
| Unread | Only unread notifications |
| Saved | Notifications you saved with S |
| Done | Archived (marked done) notifications |
| @Mentioned | Only threads where you were directly @mentioned |
| Assigned | Issues and PRs assigned to you |
| Review requested | PRs where your review is requested |
| Participating | All threads you participated in |
Filtering by repository or organization
At the top of the notification list there is a filter/search field:
Visual / mouse users
Click the filter/search box at the top of the notification list and type a repository or organization name. The list narrows in real time. Press Escape or clear the box to reset.
Screen reader users (NVDA / JAWS - Windows)
- Press
ForEto reach the filter input - Focus Mode → type repo name or org name
- Results filter in real time
- Press
Escto clear the filter
Screen reader users (VoiceOver - macOS)
- Quick Nav
Fto reach the filter input VO+Shift+Downto interact → type repo or org name- Results filter in real time
- Press
Escto clear the filter andVO+Shift+Upto stop interacting
Managing Notifications at Scale
The "mark all as done" workflow
After a busy day or coming back from time away, clear your inbox methodically:
- Open Notifications inbox
- Tab to "Mark all as done" button → Enter (clears everything at once)
- Then use the "Done" filter to retrieve any you want to revisit
Muting a noisy thread
If a thread generates too many notifications:
Visual / mouse users
- Open the issue or PR page
- In the right sidebar, scroll to the Notifications section
- Click Unsubscribe - you will stop receiving notifications from this thread
- Alternatively, from the inbox: hover over the notification row and click the mute icon (or the … menu)
Screen reader users (NVDA / JAWS - Windows)
- Open the notification
- On the issue/PR page, navigate the sidebar to the Notifications section (
HorD) - Activate the Unsubscribe button
- Or from the inbox: focus the notification → press
Mto mute
Screen reader users (VoiceOver - macOS)
- Open the notification
- On the issue/PR page,
VO+U→ Landmarks or Quick NavHto find the Notifications section in the sidebar - Quick Nav
BorTabto find the Unsubscribe button →VO+Space - Or from the inbox: focus the notification and press
Mto mute
Dealing with @mentions you didn't expect
If you were @mentioned in an unfamiliar thread:
- Read the thread for context before responding
- If it seems like a mistake, a simple "I don't think this mention was meant for me - feel free to remove it!" is enough
- Unsubscribe after reading if you don't need to stay in the loop
Learning Cards: Managing Notifications at Scale
Screen reader users
- To mute a noisy thread from the inbox, focus the notification row with
Taband pressM; you will stop receiving updates from that thread - Press
Eto mark a focused notification as done (archived); focus automatically moves to the next notification for rapid triage - To bulk-clear, Tab to the "Mark all as done" button at the top of the inbox and press
Enter; then use the "Done" filter to retrieve anything you need later
Low vision users
- The "Mark all as done" button is at the top of the notification list, above the first notification group; it clears the entire inbox at once
- After marking notifications as done, switch to the "Done" filter in the left sidebar to review archived items; this filter persists until you switch back
- On an issue or PR page, the "Unsubscribe" button is in the right sidebar under a "Notifications" heading; it prevents future notifications from that thread
Sighted users
- Hover over any notification row to reveal quick-action icons: checkmark (done), bookmark (save), and mute (unsubscribe)
- Use the "Mark all as done" button to clear the entire inbox, then revisit important items via the "Done" filter in the left sidebar
- On an issue/PR page, the "Unsubscribe" link in the sidebar Notifications section stops notifications for that specific thread without unwatching the entire repository
Notification Settings - Per Your Account
Global notification preferences are at https://github.com/settings/notifications.
Key settings to review:
| Setting | Recommendation |
|---|---|
| Email delivery | Choose Participating and @mentions unless you prefer email for everything |
| GitHub Mobile | Enable only if you use GitHub Mobile - mobile notifications can duplicate desktop ones |
| Watching | "Participating and @mentions" unless you are an active maintainer |
| Organization alerts | Enable for orgs where you have responsibilities |
Navigate this settings page:
H → navigate to each settings section heading
F or E → navigate form fields within each section
Tab → move between options within a form group
Starring vs. Watching - What Is the Difference?
New contributors often confuse these two. They appear next to each other on every repository page and do completely different things.
Starring a Repository
| Feature | Description |
|---|---|
| What it does | Bookmarks the repository to your Stars list at github.com/stars |
| Notifications | None. Starring never sends you any notifications |
| Visibility | Public - anyone can see what you've starred on your profile |
| Use case | "I want to save this for later" or "I want to show appreciation" |
| Keyboard path | On any repo page: B to navigate buttons → find "Star" button → Enter |
Starring is GitHub's equivalent of a bookmark + public endorsement. The star count on a repository is a community signal of popularity. Many maintainers watch their star count as a rough measure of interest.
Watching a Repository
| Feature | Description |
|---|---|
| What it does | Subscribes you to notifications from that repository |
| Notifications | Sends notifications based on your chosen level (see below) |
| Visibility | Private - other users cannot see what you're watching |
| Use case | "I need to stay informed about activity in this repo" |
| Keyboard path | B → find "Watch" button → Enter → ↑/↓ to pick a level → Enter |
Common Mistake: Accidental Watching
When you comment on an issue or PR in a repository, GitHub automatically subscribes you to that thread - but not the whole repository. However, if you once click "Watch" on a busy repository (say, a popular open source project), you will receive a notification for every issue opened and every comment posted - potentially hundreds per day.
How to silence a repository you accidentally over-subscribed to
Step 1: Navigate to the repository
Step 2: B → Find "Unwatch" button → Enter
Step 3: Select "Participating and @mentions"
Step 4: Enter to confirm
This immediately reduces notifications from that repository to only threads you personally participated in.
Recommended Watching Strategy for This Workshop
| Repository | Recommended Watch Level |
|---|---|
community-access/accessibility-agents |
Participating and @mentions - you contribute there, you only need to hear back when someone replies to you |
| Your own fork | All Activity - this is your fork; know everything |
| Very busy popular repos | Ignore or Participating - do not watch for All Activity |
| Repos you're evaluating | Star only - save without subscribing |
Learning Cards: Starring vs. Watching
Screen reader users
- The Star and Watch buttons are adjacent in the repository header; press
Bto navigate buttons and listen for "Star" or "Watch" (or "Unstar" / "Unwatch" if already active) - Star: press
Enteron the Star button to bookmark; this generates zero notifications and is purely a bookmark to github.com/stars - Watch: press
Enteron the Watch button to open a dropdown; useUp/Down Arrowto choose a subscription level andEnterto confirm
Low vision users
- The Star button shows a star icon and a count (e.g., "Star 1.2k"); the Watch button shows an eye icon and a count; both are in the top-right area of the repository page
- After starring, the button changes to "Unstar" with a filled yellow star; after watching, it changes to "Unwatch" with a filled eye icon
- At 200%+ zoom, these buttons may wrap below the repository title; they remain functional at any zoom level
Sighted users
- Star (star icon) = bookmark only; Watch (eye icon) = subscribe to notifications; they are next to each other and next to the Fork button in the repo header
- Star counts are public and show on your profile; watch settings are private and affect only your notification inbox
- If you accidentally watched a busy repo and are flooded with notifications, click Unwatch and switch to "Participating and @mentions" to reduce noise immediately
Screen Reader Tips for the Notification Inbox
NVDA
- The notification list is complex - use
Tabto navigate individual rows rather than Browse Mode arrow keys - After marking notifications done (press
E), the next notification automatically receives focus - Use
NVDA+F7→ Links to get a filtered list of notification titles to scan quickly
JAWS
- Like NVDA, use
Tabfor row navigation in the inbox Insert+F6(Headings list) to jump between date group headings (Today, This Week, etc.)- The inbox updates in real time - JAWS will announce new notifications as they arrive
VoiceOver
- Use
VO+U→ Landmarks → Main to reach the notification list quickly VO+Spaceto activate a row,VO+Escapeto return to the list- With Quick Nav on,
Hnavigates the date group headings
The GitHub Mobile App - A Reference Note
GitHub has an iOS and Android app that supports push notifications. While the app itself is not covered as a primary tool in this workshop, it is worth knowing:
- Push notifications can alert you to review requests even when you're away from your computer
- The mobile app does work with iOS VoiceOver and Android TalkBack
- For primary contribution work, the desktop browser experience remains more fully featured
Try It: Tame Your Inbox
Time: 2 minutes | What you need: Browser, signed in to GitHub
Go to github.com/notifications and practice:
- Scan your inbox - Press
HandTabto navigate through notifications. Each one shows the repo name, type (issue/PR), and title. - Mark one as done - Find a notification you've already read. Press
Eto mark it as done. It disappears from the list. - Configure watching - Go to the Learning Room repository. Press
Dto landmarks, find the repo nav area, then look for the "Watch" or "Unwatch" button (Bto scan buttons). Choose your preferred watch level.
You're done. You now control what GitHub tells you about and what it doesn't.
What success feels like: Your inbox has fewer items, and you chose what to watch. Notifications work for you now, not against you.
Day 2 Amplifier - Accessibility Agents:
@daily-briefingManage your notification inbox manually before using any agent. The signal-versus-noise judgment you develop - what to act on, what to watch, what to mute - is the same judgment the agent applies when prioritizing its output. Without that judgment, you cannot evaluate whether the agent's prioritization is correct or whether it surfaced the things that actually matter to you.
Once you have mastered manual notification management:
- In VS Code -
@daily-briefing morning briefingdelivers the same information as your notification inbox, organized by priority and actionability, with the ability to reply, close, and merge from inside Copilot Chat- In your repo - Fork accessibility-agents and every collaborator on your project can run
@daily-briefingagainst your shared repository; the whole team stays aligned from a single command with no inbox required- In the cloud - GitHub Agentic Workflows can run on a schedule and post a team digest to a designated issue each morning, surfacing what needs attention before anyone opens their notifications
Your notification discipline today becomes the standard the agent enforces at scale tomorrow.
What You Accomplished Today
Take a breath. Day 1 is complete -- and you did a lot.
Here is every skill you practiced, mapped to the chapter where you learned it and the evidence you created along the way:
| Chapter | Skill | Evidence |
|---|---|---|
| Chapter 00 | Created a GitHub account and configured accessibility settings | Account exists, profile is visible |
| Chapter 01 | Chose your editing environment and tested it | Tool preference noted in your challenge issue |
| Chapter 02 | Understood what GitHub is, how repositories work, and what collaboration looks like | Completion comment on challenge issue |
| Chapter 03 | Navigated a real repository using keyboard and screen reader | Found specific files and folders in the Learning Room |
| Chapter 04 | Opened the Learning Room, found your challenge issues, and understood the workflow | First structured comment posted |
| Chapter 05 | Created, labeled, and commented on issues | Issue created with a descriptive title and body |
| Chapter 06 | Created a branch, edited a file, and opened a pull request | Merged PR visible in the repository |
| Chapter 07 | Recognized a merge conflict and resolved it | Conflict-free merge committed |
| Chapter 08 | Read contributing guidelines, understood community norms, and practiced respectful communication | Thoughtful comment on a peer's issue or PR |
| Chapter 09 | Used labels, milestones, and project boards to organize work | Labels applied, milestone progress visible |
| Chapter 10 | Configured notification preferences and managed your inbox | Watch level set, at least one notification acted on |
That is eleven chapters, eleven skills, and a trail of real evidence in a real repository.
If This Was Your First Time
If today was your first time using GitHub -- or your first time using it with a screen reader -- you have already done something most developers take weeks to piece together on their own. You navigated a complex platform, created real contributions, and collaborated with other people in a shared codebase. That is not a small thing.
If parts felt confusing or slow, that is completely normal. Every skill you practiced today gets faster with repetition. The point was never speed -- it was understanding.
Confidence Check
Before you close your laptop, take two minutes to answer these questions in your Chapter 10 challenge issue. There are no wrong answers -- this is for you.
- Which chapter felt the most natural to you? Which one do you want to revisit?
- Can you explain what a pull request does to someone who has never used GitHub?
- If you saw a merge conflict right now, would you know where to start?
- What is one thing you want to try on GitHub this week that you did not get to today?
Screen reader tip: You can copy these questions into your challenge issue comment and type your answers directly below each one. Use a blank line between each question-answer pair so the structure is clear when read back.
Your Challenge Progress
Look at how many challenge issues you completed today. Each one represents a skill you did not just read about -- you practiced it, posted evidence, and moved on. Some workshops hand you a certificate for sitting in a chair. This one asked you to prove your skills in a live repository, and you did.
If you completed all eleven challenges, you are ready for Day 2 with a strong foundation. If you missed a few, that is fine -- you can finish them at your own pace before Day 2 begins. The Learning Room stays open.
Learning Cards: What You Accomplished Today
Screen reader users
- You navigated GitHub entirely by keyboard: headings (
H), landmarks (D), buttons (B), links (K), and form fields (ForE) became your primary navigation tools - You created issues, opened PRs, resolved conflicts, and managed notifications -- all skills that transfer to any repository on GitHub
- Revisit any chapter by pressing
Ctrl+Lin your browser and typing the URL, or by navigating to the docs folder in the Learning Room repository
Low vision users
- Everything you did today at your current zoom level and contrast settings will work the same way tomorrow; GitHub's layout adapts consistently to browser zoom up to 400%
- If you found certain pages hard to read, revisit Settings, Accessibility on GitHub to try a different theme or motion preference before Day 2
- Your profile page at github.com/your-username now shows contribution activity from today; zoom in on the contribution graph to see your green squares
Sighted users
- Your GitHub profile now shows contribution activity from today: issues created, PRs opened, and commits made appear as green squares on your contribution graph
- Every skill from today (issues, PRs, reviews, labels, notifications) is used daily by professional developers; you practiced the real workflow, not a simplified version
- Bookmark your Learning Room repository and the notifications page (github.com/notifications) for quick access on Day 2
What Day 2 Adds
See also: Chapter 11: VS Code Interface is where Day 2 begins -- have VS Code installed and ready.
On Day 1, you worked entirely on GitHub.com. Everything happened in your browser -- creating issues, editing files, opening pull requests, resolving conflicts. On Day 2, you bring that same workflow to your own computer and add powerful new tools on top of it.
Here is what Day 2 covers:
| Chapters | Topic | What You Will Do |
|---|---|---|
| Ch 11 -- Ch 12 | VS Code deep dive | Install and configure VS Code with full screen reader and accessibility support |
| Ch 13 -- Ch 14 | Local Git | Clone repositories, commit locally, push and pull changes between your computer and GitHub |
| Ch 15 | Code review | Review pull requests with inline comments, suggestions, and approval workflows |
| Ch 16 | GitHub Copilot | Use AI-assisted coding with accessibility-first prompting techniques |
| Ch 17 | Issue templates | Create structured templates so every issue in your project starts with the right information |
| Ch 18 | Fork workflow | Fork a repository, make changes, and submit a pull request back to the original project |
| Ch 19 | Accessibility agents | Build and use custom agents that automate accessibility checks and team workflows |
| Ch 20 | Capstone | Design, build, test, and ship your own accessibility agent from scratch |
The mental model shift is straightforward: Day 1 taught you what GitHub does. Day 2 teaches you how to use it from your own development environment, with real tools that professional developers use every day.
Between Days
If your workshop has a gap between Day 1 and Day 2, here are three optional things you can do to stay sharp:
- Explore your notification settings. Now that you understand how notifications work, visit github.com/settings/notifications and customize your email and web preferences. There is no wrong configuration -- just find what feels manageable.
- Read issues in a project you care about. Pick any open source project on GitHub and browse its issue tracker. You now know enough to understand labels, milestones, and comment threads. Notice how maintainers communicate -- you will recognize the patterns from Chapter 08.
- Try a GitHub Skills course. GitHub Skills offers free, self-paced courses that run inside real repositories. "Introduction to GitHub" is a good one if you want to reinforce what you learned today. See Appendix Z for the full list of recommended courses.
Screen reader tip: GitHub Skills courses use bot-driven feedback inside pull requests. The interaction model is similar to the Learning Room -- you push a change, a bot reviews it, and you get instructions for the next step. If you completed today's challenges, you already know the workflow.
You Already Know More Than You Think
Think about where you started this morning. You may not have known what a repository was, or how to navigate one with a keyboard, or what happens when two people edit the same file. Now you do. You have created real issues, opened real pull requests, resolved real conflicts, and configured your own notification workflow -- all in a live, shared codebase.
Day 2 builds on every one of those skills. Nothing gets thrown away. Everything you did today is the foundation for everything that comes next.
End of Day 1: Congratulations. You have completed Challenge 9: Merge Day and finished the browser-based foundation. Return to the Course Guide to prepare for Day 2.
Next: Chapter 11: VS Code Interface
Back: Chapter 09: Labels, Milestones, and Projects
Related appendices: Appendix T: Community and Social | Appendix U: Discussions and Gists
Authoritative Sources
Use these official references when you need the current source of truth for facts in this chapter.
- GitHub Docs, home
- GitHub Changelog
- About Git
- GitHub flow
- About pull requests
- About issues
- Contributing to a project
Section-Level Source Map
Use this map to verify facts for each major section in this file.
- Managing Your GitHub Notification Inbox: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- Workshop Recommendation (Chapter 10): GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- What Generates a Notification?: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- Notification Subscription Levels: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- The Notifications Inbox: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- Inbox Actions - Keyboard Shortcuts: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- Filtering the Inbox: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- Managing Notifications at Scale: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- Notification Settings - Per Your Account: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- Starring vs. Watching - What Is the Difference?: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- Screen Reader Tips for the Notification Inbox: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- The GitHub Mobile App - A Reference Note: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- Try It: Tame Your Inbox: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- What You Accomplished Today: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- What Day 2 Adds: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests