Feedback tool for Open Source Maintainers
Your issue tracker is already the feedback board. The work that drowns you is triage and dedup, so Usero links the dups and opens one draft PR you review like any contributor.
Most of your project hours go to triage, not code. The issue queue is the feedback board, and re-typing "looks like a dup of #1234" is the treadmill.
For a maintainer the bottleneck was never collecting feedback. The issue tracker collects it relentlessly. The bottleneck is everything between a report landing and a fix going out. GitHub's own survey of maintainers puts numbers on it: 60 percent want help with triage (labeling, categorizing, routing) and 30 percent want automatic duplicate detection. Some maintainers describe spending 80 percent of their project time on support and community and only 20 percent writing code. As contribution friction drops, every minor inconvenience becomes a fresh issue, and you spend your evenings hand-typing "looks like a dup of #1234" and asking, again, for repro steps. The queue grows faster than you can read it, and reading it is the part that burns you out.
Where Usero fits
I make Usero, so weigh that. The honest worry for this audience comes first: maintainers from Godot to curl have said publicly they are drowning in low-effort AI-generated PRs, and a tool that opens AI PRs is the last thing a triage-weary maintainer wants near their repo. So the framing is the framing, not a footnote. Usero opens a DRAFT pull request against your own repo, with a scoped token, and it drafts the code, the merge is always your call. Nothing auto-lands. What it actually does for you is the triage you hate: it clusters fifteen reports of the same niche-config crash into one item with a count, links the dups, and opens a single draft with a first-pass guard. You read that diff exactly like you read any contributor's PR. The request ends as code, not as a row on a board, and the fifteen dup comments never get typed.
Fifteen separate issues reporting the same crash collapse into one clustered item with the duplicates linked. You stop writing the same "is this #1234?" comment by hand. The draft PR that comes out the other side is a first pass you review and rewrite, so the part only a maintainer knows stays a maintainer decision.
Every PR opens as a draft against your repo through a scoped GitHub token. It cannot merge itself and it touches nothing you do not approve. This is the opposite of the drive-by AI PR flood maintainers complain about: it is a starting diff that waits for you, framed as a contributor's first attempt, not a fait accompli.
A first-timer files "does not work on Windows" with no steps. Instead of you re-deriving context for the third time, Usero clusters it against older Windows issues that do carry repros and drafts a path-separator fix that references them. The context-rebuilding tax on low-quality reports drops.
For a library or CLI with no web UI, the widget has nowhere to live, and that is fine. The value here is the issue clustering and the draft PR off your existing GitHub queue, not a feedback button. If you do run a docs site or landing page, the vanilla embed adds a structured report path on top.
The honest objection
Because the thing maintainers hate is the drive-by: an unsolicited AI PR from a stranger, opened against your repo, that you did not ask for and now have to triage on top of everything else. Usero is the inverse. It runs on your repo, with your token, and only drafts a fix when reports actually cluster, and it opens as a draft that does nothing until you act. If your repo gets enough duplicate, low-repro issues that hand-deduping eats your week, it helps. If your queue is small and you enjoy triaging it, you do not need it, stay as you are.
FAQ
No. It opens drafts, only against your own connected repo, only when reports cluster, and never merges. A draft sits there until you review the diff and decide. The auto-merge behavior maintainers rightly fear is not something Usero does or can do.
A scoped GitHub token to read the repo and open draft pull requests. It does not get write-to-main or merge rights. You merge through your normal review flow, the same as any external contribution.
The widget is, mostly, yes, a CLI or library has no surface for it. But the issue clustering and draft-PR drafting run off your GitHub issue queue, which you already have. That is where the value sits for pure-library maintainers. The widget only matters if you also run a docs site or landing page.
Labeling bots stop at triage. Usero does the clustering and then drafts the actual fix as a reviewable diff, so a clustered request can leave your queue as merged code instead of a tidier backlog. You still review every line.
Free tier. No credit card. Two-minute install. The PR opens as a draft, you merge it.