How to sort GitHub issues by something better than thumbs-up count
Yes, but not the way most teams look for it. GitHub's own search supports sort:reactions-desc, which ranks issues by total reaction count across every emoji, and sort:reactions-+1-desc for thumbs up specifically, documented in GitHub's search qualifiers. Type either into the filter bar on your Issues tab and the list re-sorts. You don't need a script for that part, though it still won't tell you which reactor is worth caring about.
What GitHub can't tell you is who did the reacting. A thumbs up from a solo hobbyist counts exactly the same as a thumbs up from the account paying you six figures a year, because the reaction API returns a username and an emoji, nothing about which company that username works for or what they pay. Sorting by reaction count gets you "how many people clicked," which isn't the same question as "how much does this matter."
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionStep 1: use the sort GitHub already has
Before building anything, rule out the free option. The Issues tab's own Sort dropdown already has an entry for "The most added reaction on issues or pull requests," which is the same combined-reaction ranking you get from typing is:open sort:reactions-desc into the search bar. If you want one specific emoji instead of the combined count, that part is search-box only: sort:reactions-+1-desc for thumbs up, or sort:reactions-heart-desc for hearts, per the same qualifiers page. If your backlog is small enough that "most reacted" is a fine proxy for "most wanted," stop here.
Step 2: pull the actual reactor list
Reaction counts hide the names behind them. GitHub's API exposes them directly:
gh api repos/OWNER/REPO/issues/NUMBER/reactions --jq '.[].user.login'That returns every GitHub username who reacted, which is the raw material for the question a count can't answer: are these forty reactions forty different companies, or four companies whose engineers all reacted from personal and work accounts?
Step 3: match reactors to the accounts you actually care about
This is the part with no native GitHub feature, because GitHub has no concept of your customer list. Export the reactor usernames from step 2 and cross-reference them against whatever already maps people to companies on your side: a CRM, a support tool's contact list, or a plain spreadsheet if that's what you've got. GitHub usernames rarely match email addresses cleanly, so this usually means checking each reactor's public profile for a company or matching them against known engineers at accounts you track.
For a backlog with a handful of open issues a week, this is tedious but doable by hand once a week.
A weighted backlog for a five-person infra startup
At Bellcrest, a startup whose managed job queue runs in production at a few hundred companies, Nadia Voss handles triage on the open-source side of the issue tracker. Reaction counts had started driving her prioritization by accident.
Nadia, in the team's planning doc: #412 (retry-policy overrides) has 3 reactions. #398 (dark mode for the dashboard) has 22. We should probably do dark mode first?
Before committing to that, she pulled the reactor list on both issues with the gh api command from step 2. The 22 reactions on #398 came from 19 distinct GitHub accounts, all personal-looking usernames with no company signal she could find. The 3 reactions on #412 came from engineers at two of Bellcrest's five largest accounts by contract size, one of whom had also filed a support ticket the same week saying the missing override was blocking a migration.
Nadia, updated planning note: #412 stays first. Low reaction count, but it's two of our top-five accounts and one of them is blocked on it right now. #398 is real demand too, just not urgent enough to jump the queue.
Nothing here required new tooling, just the fifteen minutes it took to pull two reactor lists and check them against Bellcrest's own account list. It held up because the tracker was small enough that fifteen minutes a week was proportionate to the payoff.
What breaks first as the backlog grows
The approach above breaks down on ordinary schedules, not edge cases:
- Reactor-to-account matching doesn't scale past a handful of issues a week. Pulling usernames and checking each one against a customer list is a real task, and it's the first thing that gets skipped when the backlog gets busy, which is exactly when it matters most.
- GitHub usernames aren't stable identifiers for a person. The same engineer might react from a work GitHub account on one issue and a personal one on another, and nothing links the two unless you already know to look.
- The context lives in one place and the reaction lives in another. Knowing "this account is on our top-tier plan and had a support escalation last month" requires checking a different tool for every reactor, every time.
That's the point where a system that already knows who your customers are earns its keep, with one limit worth stating up front: Modem connects to your GitHub repos alongside Slack, support, and email, and reads issue and PR content, not the reaction API, so it can't re-score the emoji counts from steps 1 and 2 for you. What it does instead is turn a GitHub issue into a tracked topic the same way a Slack thread or a support ticket becomes one, weighted by the people who filed the issue and left comments rather than the people who clicked a reaction. Because Modem already holds the people and companies behind every channel it watches, that topic shows how many distinct customers and companies are actually behind a request, and a request that also showed up in a support ticket or a sales call gets counted as the same topic instead of a separate one. On a backlog where most real signal shows up as a comment or a linked ticket rather than a lone reaction, that covers more ground than reaction weighting alone would. On a backlog where reactions are genuinely the dominant signal, the manual reactor check from steps 2 and 3 stays the way to read it; Modem doesn't replace that specific check today. We build Modem, which makes us a biased source on this recommendation; the general shape of this problem, sorting the customer-facing slice of a tracker instead of the whole engineering backlog, is covered in more depth in how to triage GitHub issues at scale, and the wider set of tools that weight feedback by revenue instead of headcount is compared in best tools to prioritize customer feedback by revenue.
Start with your five most-reacted issues
Pick your five most-reacted open issues, pull the reactor list on each with the gh api command above, and check those usernames against your customer list by hand. This is the piece that stays manual even after you bring in a tool like Modem, since none of that tooling reads the reaction API either; what a tool changes is how much of the rest of your backlog needs the same treatment. You'll know within the hour whether your current top-of-backlog is actually your top priority, or just your most-clicked.
