-
Notifications
You must be signed in to change notification settings - Fork 6
solution bonus d
This shows a configured notification setup with before/after.
This bonus focuses on GitHub's web notification inbox as the primary way to manage notifications. Email notifications are optional and not required for this workshop. The configuration shown here demonstrates how to set up your GitHub account to manage notifications effectively whether you choose to use email or not.
The key principle: Use GitHub's web inbox at github.com/notifications as your main workflow. Enable email only if you choose to, and even then, only for high-priority items.
With default settings, GitHub sends email notifications for:
- Every issue and PR in every repository you watch
- Every comment on any thread you have participated in
- Every CI status update
This quickly becomes overwhelming. Most people start ignoring all GitHub emails. Instead, most professional developers use the web notification inbox.
- Participating: Email ON, Web ON -- you want to know when someone replies to your conversations
- Watching: Email OFF, Web ON -- browse these when you have time, not in your inbox
- GitHub Actions: Email OFF for successful runs, Email ON for failed runs only
- Repositories you actively contribute to: Watch (all activity)
- Repositories you read occasionally: Custom (issues and PRs only)
- Repositories you finished with: Unwatch
- Route
Community-Accessorganization notifications to your workshop email - Route personal project notifications to your personal email
- Why email off for watching: You can check the notification bell on github.com when you choose. Email notifications for watched repos create constant interruption for low-priority updates.
- Why Actions failures only: A green checkmark in the PR is enough. You only need an email when something breaks.
- Why unwatch finished repos: Your notification feed stays relevant to current work.
The learning objective is intentional notification management. If you changed at least one setting from the default and can explain why that change reduces noise while keeping you informed about what matters, you completed this bonus.
Use these official references when you need the current source of truth for facts in this chapter.
Use this map to verify facts for each major section in this file.
- Before: Default settings: GitHub Docs, home, GitHub Changelog
- After: Configured settings: GitHub Docs, home, GitHub Changelog
- Key decisions explained: GitHub Docs, home, GitHub Changelog
- What matters: GitHub Docs, home, GitHub Changelog
- 00 Setup
- 01 Tools
- 02 GitHub
- 03 Repositories
- 04 Learning Room
- 05 Issues
- 06 Pull Requests
- 07 Merge Conflicts
- 08 Culture
- 09 Labels Milestones Projects
- 10 Day 1 Close
- 11 VS Code Interface
- 12 VS Code Accessibility
- 13 How Git Works
- 14 Git in Practice
- 15 Code Review
- 16 Copilot
- 17 Issue Templates
- 18 Fork and Contribute
- 19 Accessibility Agents
- 20 Build Your Agent
- 21 GitHub Accessibility and Open Source
- 22 What Comes Next
Use these official references when you need the current source of truth for the wiki navigation structure and the GitHub workflow concepts represented by these links.
- Start: GitHub Docs, home, GitHub Changelog
- Day 1: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- Day 2: GitHub Docs, home, GitHub Changelog, About Git, GitHub flow, About pull requests
- Reference: GitHub Docs, home, GitHub Changelog
- Contributors: GitHub Docs, home, GitHub Changelog