GitHub +1s Are a Weak Priority 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 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

Cross-referencing a thread by hand is one issue, one renewal call someone happened to remember, and about twenty minutes of scrolling. It holds up on a small repo, 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 a GitHub handle to a paying account requires 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 an account'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 your support inbox never learn they're the same request.

That's where a system that already knows your customers starts doing work you can't do by hand, 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 lets a request from a large account sit in a thread for months until someone scrolls far enough to notice. Modem is our own product: on a small repo, 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.