Can GitHub Projects' Custom Fields Replace a Real Feedback Triage Process?
Custom fields in GitHub Projects are enough to run triage on the issues already sitting in your tracker. Give every issue a status, a priority, and an area, and a project view sorted by those fields tells you what to work on next. What fields can't do is anything upstream of that. They attach to issues, not conversations, so a bug report that never became an issue doesn't exist as far as your fields are concerned, and two issues describing the same problem in different words each get their own row, tracked separately, forever, unless someone notices and merges them by hand.
So the honest answer is a scoped yes. Fields replace the sorting half of triage, not the noticing half, and noticing is the harder half once a team is receiving more feedback than one person reads in full.
What the fields actually do
GitHub's documentation on Projects fields lists five types you define yourself: text, number, date, single-select, and iteration. A typical triage setup uses single-select for Priority (P0 through P3) and Status (Needs triage, Confirmed, In progress, Done), plus a date field for a target milestone. GitHub has also been extending this to organization-level issue fields, the same shape of thing (priority, effort, dates) but defined once and attached to the issue itself rather than to one project, so it shows up automatically wherever that issue gets added. As of a June 2026 changelog, those issue fields are also readable and writable by AI tools connected to the GitHub MCP server, which means an agent can file an issue with priority and area already set instead of a human filling them in later.
That's a genuinely useful building block. It's also the part of triage that was never the bottleneck. Deciding a priority for an issue that's already in front of you takes seconds. The work that eats a triager's morning is reading forty new issues and figuring out which three are the same complaint from three different customers, which is exactly the step fields don't touch.
The one piece of native dedupe that does exist, and its limit
GitHub isn't blind to this. The same June 2026 changelog announces duplicate detection in public preview. When someone is filling out a new issue, GitHub searches the repo's existing issues and surfaces up to three possible matches right in the creation form, before the issue is even submitted.
That's the right idea, and worth turning on. But it's scoped narrowly on purpose. It runs at the moment of creation, against one repository, and it's a suggestion a human still has to accept or dismiss. It doesn't retroactively group the duplicates already sitting in your backlog, it doesn't span repos if your product is split across several, and it has nothing to say about a complaint that arrived in a support ticket or a Slack DM and never got typed into a GitHub issue form at all. Fields and this new duplicate check both operate on issues that already exist. Everything before that line, the actual conversation with the customer, is invisible to both.
“export is broken for us”
“any update on SSO?”
“we hit the rate limit again”
Read + clusteredWhat this looked like at Fenmark Dispatch
Fenmark Dispatch builds scheduling software for HVAC and plumbing contractors, and support runs through a shared GitHub repo where customers and the two on-call engineers both file issues. Pallavi Thackeray manages engineering there, and she'd set the team up with a clean three-field board using Priority, Area, and Status, single-select all the way down.
It worked for about six weeks. Then she pulled up the board one Monday and found this waiting in the team channel from one of the on-call engineers:
"I closed three issues this morning that were all 'the route re-optimizes and drops a stop when a tech marks a job complete mid-route.' Same bug, three different customers, three different write-ups over two weeks. Priority and area were set correctly on all three the whole time, that part of the board was fine. Nobody had read all three closely enough to notice they were the same thing until I sat down and actually compared them side by side."
The fields hadn't failed. Priority: P1 and Area: routing were sitting on all three issues, correctly, the entire time. What the board never surfaced was that three rows were one bug, because nothing about a single-select field compares the text of one issue to another. Pallavi's fix, for now, is a weekly fifteen-minute pass where someone reads every open issue's title out loud in standup. It catches most of it, at her current volume, at the cost of fifteen minutes nobody gets back.
Three gaps a fields-only board can't close
Three limits show up in roughly this order as a repo's issue volume grows:
- Nothing tracks a request before it's an issue. A field can't hold information about a conversation that never got promoted into GitHub. If a customer mentions a problem in a support thread and nobody opens an issue for it, your fields are 100% accurate about the issues that exist and silent about the one that doesn't.
- Duplicates still require a human to notice the wording matches. The creation-time suggestion helps the next issue filed; it does nothing for the backlog you already have, and nothing across repos if your issues are split by service.
- Nobody's requester list survives a merge. When you do close a duplicate, the person who filed it is gone from the canonical issue unless someone manually adds a comment naming them. Ship the fix, and there's no field that tells you who to tell.
None of that is a knock on the fields themselves. It's a scope mismatch. Fields are a sorting mechanism for issues, and a growing share of the actual triage problem happens before an issue exists or across issues nobody has compared side by side.
Where Modem picks up
Modem is what we build, so the next few paragraphs describe our own product rather than a neutral pick, and that's worth knowing going in. Modem connects to your GitHub repos alongside Slack, Discord, and your support tool, and it reads the conversation before anyone decides it's worth an issue. Three customers describing the same routing bug in different words, across a Slack thread, a support ticket, and a GitHub issue, get clustered into one counted topic with all three people attached. The comparison Pallavi's team was doing by hand in standup happens automatically, and it isn't limited to one repo or to issues that already got filed. Fields and duplicate detection still do their job downstream of that; Modem is what makes sure the issue that reaches the board is the one issue that needed to exist, with the full requester list riding along instead of getting dropped at merge time.
Below a few dozen issues a week in a single repo, the field setup above plus a habit of skimming titles for repeats is genuinely enough. Buying a clustering tool for that volume is solving a problem you don't have yet. The math changes once feedback is arriving through more than one channel or the read-through starts eating real time each week, which is usually well before a repo feels large by issue count alone.
If most of your issues are internal engineering work rather than customer reports, the sweep-and-label rotation in how to triage GitHub issues at scale is the better fit than anything above. And if the feedback you're triaging starts somewhere other than GitHub, our roundup of tools that turn customer feedback into GitHub issues covers getting it there in the first place.
Three fields, one setting, one habit
Set up the three fields (Priority, Area, Status), turn on duplicate detection in your repo settings, and add one line to your issue template asking reporters to search first. That's a real triage system for a single repo at moderate volume. The signal to watch for isn't issue count; it's the first time someone closes a duplicate that had already been sitting there, correctly labeled, for two weeks.
