Why "+1" Comments on a GitHub Issue Are a Bad Prioritization Signal

No. A pile of "+1" comments on a GitHub issue tells you how many people bothered to type two characters into a text box. It does not tell you who they are, what they pay, or whether losing them would cost you anything. GitHub's own reaction and comment data has no field for company, plan, or contract value, so forty identical "+1" comments and four comments from your four biggest accounts look exactly the same in the thread, and exactly the same in any count you run on top of it.

That gap is old. GitHub added emoji reactions in 2016 specifically because typing them into comments was making threads unreadable. The announcement is blunt about it, noting that using emoji as comments "resulted in a lot of noise" and that popular threads turned into "a long thread full of emoji and not much content." Reactions were supposed to replace the habit. Years later, people still type "+1" instead, which is exactly the workaround GitHub's own community keeps re-litigating: a long-running discussion on adding a real voting feature includes a contributor observing that "many users add their reaction emojis as comments instead of reactions to the top-comment," and it's one of dozens of open threads asking GitHub for something reactions still don't deliver.

Where the habit comes from, and why it stuck

"+1" predates GitHub. It's a convention borrowed from code review culture, where typing it in a review or a mailing list thread meant "I agree, and I want that on record," back when there was no reaction button to click instead. On an issue tracker, the same habit became a stand-in for a vote: no upvote button exists, so a comment does the job.

The trouble is that a comment isn't a lightweight signal the way a reaction is. Every "+1" comment on a subscribed issue generates a real notification for everyone still watching it, which is precisely why GitHub's community keeps asking for a way to opt out. A separate open discussion about locking issues points out that maintainers lock threads specifically to stop the "+1" pile-on once a decision is made, and locking also disables reactions, so the fix for one kind of noise removes the lighter-weight alternative too. The workaround people reach for when reactions feel too buried, typing a comment instead, is the same workaround that made GitHub add reactions in the first place.

What Femi found under forty identical comments at Vaultmark

Vaultmark builds a secrets-management CLI that developers install for free, plus a hosted control plane that mid-size engineering teams pay for. Femi Adeyeye is the founding engineer who still reads every issue on the open-source repo personally.

Issue #218, "Support importing secrets from AWS Secrets Manager," had been open for eleven months and had accumulated forty-three comments, the overwhelming majority of them one line:

@devtoolfan_92: +1, would really help my workflow

@k-nakamura: +1 same here

@buildbot-curious: any update on this? +1

Femi had it filed under "someday" for most of that time, reasoning that a feature nobody on the paying side had escalated could wait behind work with clearer ROI. What changed his mind wasn't the comment count. It was noticing, while scrolling for the tenth time, that two of the usernames belonged to engineers at Northfield Analytics, a $60,000-a-year hosted customer he recognized from a renewal call the week before, where their infra lead had mentioned "still copying secrets by hand from AWS" almost in passing.

Femi, in the team's planning channel: #218 has 43 comments and I almost let it keep sitting. Two of those "+1"s are Northfield's engineers, and they brought the same thing up on the renewal call without connecting it to the issue. The other forty-one, I genuinely don't know if they're free-tier users or duplicate accounts from the same three people.

He didn't get a count of distinct paying accounts behind the issue, because nothing in GitHub's comment or reaction data groups usernames by company. What he got was one confirmed account worth acting on, found by cross-referencing a call note against a username by hand, and a strong suspicion the other forty comments were mostly noise from the free tier. He shipped the AWS import path the next sprint. It's still an open question how many other issues in that repo have the same shape and haven't had someone happen to notice.

What GitHub's own tools can tell you, and what they can't

Before reaching for anything else, it's worth knowing exactly what's already built in, because most of it stops short of the actual question.

• comments:>N in issue search filters by comment count, and sort:comments in the sort menu ranks by it. Both are documented in GitHub's search qualifiers. Neither distinguishes a "+1" from a maintainer's three-paragraph reply; comment count measures words typed, not votes cast.
• in:comments "+1" searches comment bodies directly, per GitHub's issue search docs, so you can at least isolate which comments are literal votes rather than discussion. It still returns usernames, not accounts.
• The Reactions API returns a login, an avatar, and an emoji per reaction. The documented fields include identity data like login and email if public, but nothing about which company that person works for or what they pay you. A thumbs-up from a solo hobbyist and a thumbs-up from your largest account return an identical object.

Put together, GitHub gives you volume: how many comments, how many reactions, how many words, with no native way to weight any of it by who's actually asking. That's true whether the vote arrived as an emoji or as typed text, but "+1" comments carry an extra cost reactions don't. Each one is a fresh item in every subscriber's notifications, on an issue that may already be settled.

When this stops being one founder's job

Femi's cross-reference was one issue, one renewal call he happened to remember, and about twenty minutes of scrolling. That holds up at Vaultmark's current scale, and it stops holding up for reasons that show up on a predictable schedule, not as edge cases:

• GitHub usernames don't map to companies. Matching @k-nakamura to Northfield required Femi already knowing the person, from a call, by name. At any real volume, most commenters are strangers.
• The context that makes a vote worth weighting lives somewhere else. The renewal call, the contract value, the fact that this is the third time the account has mentioned it, none of that is in GitHub. It's in a call recording, a CRM field, and someone's memory.
• Nothing dedupes across channels. If Northfield's infra lead also emails support about the same gap, or a different engineer raises it on a call next quarter, GitHub's comment thread and Vaultmark's support inbox never learn they're the same request.

That's the point where a system that already knows who your customers are earns its keep, with a real limit stated up front: Modem doesn't read the reaction API or score comment counts for you. What it does is read the GitHub repos you connect alongside your support tool and call transcripts, and tie each issue to the people and companies already in your context graph. A request that shows up as an issue, a support ticket, and something said on a renewal call becomes one topic instead of three unconnected data points a founding engineer has to happen to remember, which is exactly the gap that let issue #218 sit for eleven months until someone happened to scroll far enough to notice. Modem is our own product, which is worth saying plainly here: at Vaultmark's size, one founder reading every issue by hand is enough, and nothing about that changes until the volume does. Past a few dozen issues a month, or past the point where one person can't personally remember every call, that manual cross-reference is the first thing that stops happening reliably. The general shape of ranking a backlog by more than reaction count, including what GitHub's search and API can do without any external tool, is covered in how to sort GitHub issues by something better than thumbs-up count, and the wider triage process this fits into is in how to triage GitHub issues at scale.

Short of adopting anything, there's a version of this worth running today: pick your most-commented open issue, run in:comments "+1" against it to see how many of those comments are actual votes versus discussion, then check the five most recent commenters' usernames against any customer list you already have. If none of them match, the count is probably real demand, undifferentiated. If even one does, that's your answer on which issue actually needs to move this week, regardless of what the comment count says about anything else.