Blog

GitHub Feedback Integration: Connect User Ideas to Issues

GitHub Feedback Integration: Connect User Ideas to Issues

Hand-drawn feedback cards and issue ticket

A GitHub feedback integration links the place where users ask for things to the place where your engineers build them. The goal is simple: a request on a public board becomes a GitHub issue when you decide it is worth building, and the requester hears back when that issue ships. You can build this with GitHub's own tools, with a few lines of automation, or with a feedback board that ships a GitHub integration. This guide covers all three, and the mistakes that make most setups noisy.

TL;DR

  • Keep two systems with two jobs: a feedback board for demand (ideas, votes, comments) and GitHub for work (issues, pull requests, releases).
  • Create a GitHub issue only after a request is reviewed, not for every idea. Link the issue back to the request.
  • Sync status in both directions, but start by syncing almost nothing else. Comments are the first thing to leave out.
  • GitHub alone can capture structure (issue forms, issue fields) and show a timeline (Projects roadmap layout), but it has no voting for outside users.
  • Petĩra is a hosted public feedback board with GitHub, Slack and Discord integrations, a public roadmap and a flat price with unlimited users, ideas and votes.

Table of Contents

Why feedback and issues should stay separate

GitHub Issues is built to plan and track your work. That is a different job from collecting demand. An issue tells an engineer what to do. A feedback item tells a product manager how many people want something and why.

When teams try to use one tool for both, two things tend to go wrong:

  1. Demand is invisible. Ten customers asking for the same export option end up as ten scattered comments, or ten duplicate issues, or an email thread nobody counts.
  2. Outsiders need accounts and context. Customers who are not developers rarely have a GitHub account, and they should not need one to say "I wish this did X."

A public board solves the first problem with votes and merged duplicates. It solves the second by letting anyone post without touching your repository. GitHub then receives only the requests that have earned engineering time.

The three ways to connect feedback to GitHub

ApproachEffortBest forWeak spot
GitHub-native (issue forms, issue fields, Projects)LowOpen source projects and technical users who already have accountsNo voting for outside users, no public status for non-developers
Custom automation (REST API, webhooks, Actions)Medium to highTeams with engineering time and unusual workflowsYou maintain it forever
Feedback board with a built-in GitHub integrationLowProduct teams serving customers who are not developersYou depend on what the integration supports

Most product teams end up in the third row. But the first two are worth understanding, because they show you what a good integration has to do.

Option 1: Use GitHub's own structure

If your users are developers, you may not need anything else to start. GitHub gives you two tools that turn free-text feedback into something you can sort.

Issue forms. You define a YAML form in your repository so reporters fill in specific fields instead of one blank text box. This works well for bug reports and feature requests where you always need the same facts: version, environment, what the user was trying to do.

Issue fields. At the organization level, GitHub lets you create custom issue fields to collect structured metadata such as priority, effort and impact across all repositories. GitHub's documentation says an organization can have up to 25 of them. That is enough to capture a rough impact score without leaving GitHub.

The limitation is plain. Neither tool counts demand from people outside your organization. A thumbs-up reaction on an issue is the closest thing to a vote, and it requires a GitHub login.

Option 2: Build your own automation

GitHub is open enough that you can wire anything to anything. The pieces you need:

  • Create issues from outside. The REST API for issues lets you create and manage issues, comments, labels, assignees and milestones from your own code.
  • Run logic inside GitHub. In GitHub Actions you can use the GITHUB_TOKEN to make API requests. GitHub's guidance is to use the permissions key to grant that token only the access the workflow needs.
  • React to changes. Webhook events fire when issues are opened, closed or edited, so your feedback system can learn that a fix shipped.

A typical build looks like this: a form on your site posts to a small service, the service calls the issues endpoint, and a webhook listener marks the original request as done when the issue closes. It works. It is also a small product you now own: authentication, retries, duplicate handling, spam and a UI for your support team.

If your team has strong opinions about the flow and a spare engineer, this is a fine choice. If not, you are spending engineering time on plumbing instead of on the feature people asked for.

Option 3: A feedback board with a GitHub integration

This is the pattern most product managers want: a public board where customers post and vote, a way to push the winning requests into GitHub, and status that flows back so the customer sees progress.

When you evaluate any board in this category, check these things before you commit:

  1. Which direction does status flow? One-way (board to GitHub) saves typing. Two-way means a closed issue can move the request to shipped without anyone remembering to update it.
  2. Can you link an existing issue, or only create new ones? Teams with an established backlog need to attach requests to issues that already exist.
  3. What crosses the boundary? Titles and descriptions are obvious. Comments, votes and requester names are decisions you should make deliberately.
  4. Do requesters need a GitHub account? For non-technical customers, the answer should be no.
  5. How is it priced as participation grows? Some tools charge more as end users or tracked contributors increase. That punishes you for the engagement you wanted.
  6. Can you leave? Look for export in open formats and a documented way to delete everything.

What to sync, and what to leave out

The most useful lesson from teams that have done this at scale is restraint. A write-up on closing the loop between support and engineering describes how over-syncing clutters issue threads with chatter that has no technical value, and recommends treating the integration as an engineering project with explicitly chosen data flows. That example involves a help desk rather than a feedback board, but the same logic applies to any tool you connect to GitHub.

Here is a sensible default.

DataBoard to GitHubGitHub to board
Title and summaryYes, written by the PMNo
Link to the requestYes, in the issue bodyYes, issue link on the request
Vote countOptional, as a one-time snapshotNo
Customer commentsNo, summarize insteadNo
Engineering discussionNoNo
Status (open, closed)NoYes
LabelsOptionalNo

The rule behind the table: engineers see the problem and the evidence, customers see the outcome. Neither side sees the other's working conversation.

A note on duplicates

If you create an issue for every request, you will have the duplicate problem you were trying to escape. Merge duplicates on the board first, then create one issue for the merged request. The vote count is then your evidence, and the issue body can say "requested by 42 customers" with a link to the board.

Merged feedback request becomes one GitHub issue

A workflow that works

Here is a flow a small product team can set up in an afternoon.

  1. Collect in one place. Point every channel at the board: the widget in your app, links in support replies, a link in your release emails. Our guide to collecting user feedback through always-on channels covers how to do that without surveying people to death.
  2. Review weekly. Set a fixed slot. Merge duplicates, reject out-of-scope requests with a reason, and mark the keepers as under review.
  3. Decide with evidence. Look at votes, but also at who is asking. Ten votes from your best-fit customers can matter more than fifty from people who will never pay.
  4. Create the issue. Write the engineering framing yourself: the problem, who has it, what success looks like. Link back to the board item.
  5. Move the status. When the issue is accepted into a milestone, mark the request as planned. When work starts, in progress.
  6. Close the loop. When the issue closes, the request becomes shipped and the people who voted are told. If a request is declined, tell them that too.

Step 6 is where most teams drop the ball. The practical argument for automating it is that manual updates get forgotten. We break the loop down further in five steps teams can assign and verify.

Using GitHub for your roadmap

Readers searching this topic often want a roadmap in GitHub, not just issues. There are two quite different things people mean.

An internal timeline. GitHub Projects has a roadmap layout that places issues, pull requests and draft issues on a timeline using your date and iteration fields. It is a good planning view for the people building the product.

A public roadmap. GitHub itself publishes one at the github/roadmap repository, showing what is being worked on and at what stage. That model suits open source and developer tools, where customers read GitHub daily.

For a product whose customers are not developers, a public GitHub project is the wrong front door. They want to see "planned," "in progress" and "shipped" next to the idea they voted for, without a repository in sight. That is the case for a board-based public roadmap, with GitHub staying as the internal engine. If you are choosing a format, four public roadmap formats lays out the tradeoffs, and stopping roadmap and backlog drift explains how to keep the two honest with each other.

Using GitHub for your roadmap — overview diagram

Our perspective: keep the board simple and let GitHub stay technical

We built Petĩra around a belief that the feedback board should be the one place customers look, and that it should not get more expensive when more of them show up. Every plan includes unlimited users, ideas and votes at a flat rate. We think pricing per participant quietly discourages the behavior a feedback board exists to encourage.

On GitHub specifically, our view is that the integration should be boring. Statuses on the board follow the same path as your work: under review, planned, in progress, shipped. Your engineers keep working in issues. Your customers never see a stack trace or an internal debate. The board is the public face, and GitHub is the workshop.

We also think leaving should be easy. You can export everything as JSON or CSV, delete all your data, and if you are arriving from another tool you can import from Canny, Fider or a CSV. A feedback tool that holds your history hostage is a worse tool, however good its integrations are.

If you take one thing from this article, take the discipline: start by syncing very little, and add a data flow only when someone on the team can explain why it is needed.

— Aron

Where Petĩra fits

Petĩra is a hosted public feedback board. Customers post ideas, vote and comment. You track each idea through under review, planned, in progress and shipped, publish a public roadmap, embed a widget in your product, and connect Slack, Discord and GitHub. You can use a custom domain and custom CSS, run private boards, and moderate what comes in.

Pricing is published on the pricing page:

PlanMonthlyYearly
Free0 EUR per monthn/a
Pro19 EUR per month190 EUR per year
Team49 EUR per month490 EUR per year

All plans include unlimited users, ideas and votes. If you are comparing costs across tools, our pricing comparison of 12 feedback tools shows how per-user models add up. You can start on the free plan and see how the board fits your GitHub workflow before paying anything. Start at petira.io.

Common mistakes to avoid

  • Creating an issue for every idea. The backlog fills with unvetted work and the engineers stop trusting it. Only reviewed requests cross over.
  • Syncing comments both ways. "Any update?" does not belong in a pull request thread.
  • No owner for the loop. Someone has to be responsible for telling users what happened. Assign a name, not a team.
  • Public roadmap promises with dates. Statuses are safer than deadlines. Say "planned," not "next month," unless you are sure.
  • Ignoring declined requests. A clear "no, and here is why" earns more trust than silence. Our feature request email templates include replies for exactly this.
  • Weak request quality. If requests arrive vague, issues will be vague. A good feature request template fixes that upstream.

FAQ

Can I connect user feedback to GitHub Issues without writing code?

Yes. A feedback board with a GitHub integration lets you create or link issues from a request without touching the API. You only need custom code, using the REST API and webhooks, if you want behavior the integration does not offer.

Should every feature request become a GitHub issue?

No. Collect and vote on requests in the board, review them on a schedule, and create issues only for the ones you intend to build. This keeps the backlog credible and lets the vote count stay on the board where it belongs.

Can GitHub work as a public roadmap for customers?

It can, if your customers are developers. GitHub Projects offers a timeline layout and GitHub publishes its own public roadmap in a repository. For non-technical customers, a board with statuses and a roadmap view is easier to follow because it requires no GitHub account.

How do I keep customers updated when an issue is closed?

Use two-way status sync. When the issue closes, the linked request moves to shipped and the people who followed it are notified. If your tool cannot do this, a webhook on the issue closing event can trigger the update.

Sources

Recommended