Skip to main content
RapidDev - Software Development Agency
github-for-non-tech

How to Track Feature Requests and Feedback on GitHub

Use GitHub Issues with "enhancement" and "feedback" labels to track feature requests and user feedback. Create a feature request template so feedback is consistent and actionable. For open-ended discussions, enable GitHub Discussions to give your community a place to share ideas without cluttering your Issues list.

What you'll learn

  • How to create feedback and enhancement labels for your repository
  • How to build a feature request template for consistent feedback
  • How to enable GitHub Discussions for open-ended community feedback
  • How to prioritize and manage feedback using filters and Projects
Book a free consultation
4.9Clutch rating
600+Happy partners
17+Countries served
190+Team members
Beginner7 min read12 minutesAny modern web browser (Chrome, Safari, Edge, Firefox)March 2026RapidDev Engineering Team
TL;DR

Use GitHub Issues with "enhancement" and "feedback" labels to track feature requests and user feedback. Create a feature request template so feedback is consistent and actionable. For open-ended discussions, enable GitHub Discussions to give your community a place to share ideas without cluttering your Issues list.

Why Tracking Feedback on GitHub Beats Spreadsheets and Email

User feedback and feature requests are essential for building the right product, but they are useless if they live in scattered emails, Slack messages, and spreadsheets. GitHub gives you a single, searchable home for all feedback. Each piece of feedback becomes an Issue with an "enhancement" or "feedback" label, making it easy to find, prioritize, and track. Feature request templates ensure every submission includes the same details: what the user wants, why it matters, and how important it is. For more open-ended conversations — like brainstorming or product direction — GitHub Discussions provides a forum-style space that keeps your Issues list clean. AI tools like Replit and Lovable can pick up feature requests directly from issues, so your feedback pipeline feeds straight into your build process.

Prerequisites

  • A free GitHub account
  • A repository where you have admin or write access
  • A modern web browser

Step-by-step guide

1

Create feedback-related labels in your repository

Go to your repository on github.com. Click the "Issues" tab, then click "Labels" next to the search bar. Click the green "New label" button. Create these labels: "feedback" (color: #C2E0C6, light green) for general user feedback, "enhancement" (color: #A2EEEF, light blue) for feature requests, "needs-discussion" (color: #D4C5F9, purple) for items that need team input, and "user-reported" (color: #FEF2C0, yellow) for items that came from actual users. For each label, enter the name, pick a color, add a short description, and click "Create label."

Expected result: Your Labels page shows feedback, enhancement, needs-discussion, and user-reported labels with distinct colors.

2

Create a feature request issue template

Go to the repository's Code tab. Click "Add file" and select "Create new file." In the filename field, type ".github/ISSUE_TEMPLATE/feature-request.md" — GitHub creates the folders automatically. Paste the feature request template from the complete code section below. Scroll down, type a commit message like "Add feature request template," and click "Commit changes." Now when anyone clicks New issue, they see this template as an option alongside any bug report template you already have.

Expected result: The template file appears in your repository, and the New issue page shows the feature request option.

3

Submit feedback as a structured Issue

Click the "Issues" tab and then "New issue." Select the feature request template. Fill in each section: describe the feature, explain the problem it solves, describe who would use it, and suggest how it might work. On the right sidebar, click "Labels" and add "enhancement" and optionally "user-reported" if the request came from a user. Assign it to the product owner or leave it unassigned for triage. Click "Submit new issue." The feedback is now trackable, searchable, and linked to your project.

Expected result: A new issue appears with enhancement and feedback labels, following the template structure.

4

Enable GitHub Discussions for open-ended feedback

For conversations that are not specific tasks — like brainstorming, product direction, or general questions — GitHub Discussions is a better fit than Issues. Go to your repository, click "Settings" in the top tab bar. Scroll down to the "Features" section. Check the box next to "Discussions" and click "Set up discussions." GitHub creates a Discussions tab in your repository with default categories like Ideas, Q&A, and General. You can customize these categories to match your needs, such as adding "Feature Ideas" and "User Feedback."

Expected result: A new "Discussions" tab appears in your repository's top menu bar, with default categories ready to use.

5

Convert a Discussion into an Issue when it becomes actionable

Sometimes a Discussion evolves into a concrete feature request. When this happens, open the Discussion, click the three-dot menu in the top-right corner of the post, and select "Create issue from discussion." GitHub pre-fills the issue with the Discussion content. Add the appropriate labels (enhancement, high-priority, etc.), assign someone, and submit. The original Discussion now shows a link to the issue, keeping the conversation history connected to the task.

Expected result: A new Issue is created from the Discussion, and the Discussion shows a reference link to the new issue.

6

Filter and prioritize feedback in your Issues list

Go to the Issues tab and use the filter bar to view feedback. Type "label:enhancement" in the search bar to see only feature requests. Combine filters: "label:enhancement label:user-reported" shows features requested by real users. Sort by newest, oldest, or most commented using the Sort dropdown. For a visual overview, add these issues to a GitHub Project board where you can drag them between columns like "Backlog," "Considering," and "Planned" to show your team the status of each request.

Expected result: The Issues list shows only enhancement and feedback items, filtered and sorted to your preference.

Complete working example

.github/ISSUE_TEMPLATE/feature-request.md
1---
2name: Feature Request
3about: Suggest a feature or improvement for the product
4title: "[Feature] "
5labels: enhancement
6assignees: ''
7---
8
9## Feature Description
10Describe the feature you would like in plain language.
11
12## Problem It Solves
13What problem or frustration does this feature address?
14
15## Who Benefits
16Who would use this feature? (all users, admins, new users, etc.)
17
18## Suggested Solution
19How do you imagine this feature working? (optional)
20
21## Alternatives Considered
22Have you tried any workarounds? (optional)
23
24## Priority
25- [ ] Must-have blocking a key use case
26- [ ] Nice-to-have would improve the experience
27- [ ] Future consideration good idea for later
28
29## Screenshots or References
30Drag and drop mockups, examples, or competitor screenshots here.

Common mistakes when tracking Feature Requests and Feedback on GitHub

Why it's a problem: Tracking feedback in email threads or Slack messages instead of GitHub

How to avoid: Create a habit: every piece of actionable feedback gets a GitHub Issue. You can quickly create one from your phone at github.com. This keeps everything searchable and trackable.

Why it's a problem: Mixing bugs and feature requests without labels

How to avoid: Always label issues as "bug" or "enhancement" so you can filter them separately. Bugs are broken things; enhancements are new things.

Why it's a problem: Creating feature request issues without enough context

How to avoid: Use a feature request template that asks for the problem being solved, who benefits, and suggested priority. Templates prevent incomplete submissions.

Why it's a problem: Ignoring community Discussions and letting them go stale

How to avoid: Review Discussions weekly. Respond to posts, convert actionable items to Issues, and close resolved conversations.

Why it's a problem: Not telling users what happened with their feedback

How to avoid: When you close a feedback issue, add a comment explaining the outcome: built it, planned for later, or decided not to pursue (and why).

Best practices

  • Use a feature request template so every piece of feedback has consistent structure
  • Label feedback issues with "enhancement" and add priority labels for triage
  • Enable GitHub Discussions for open-ended brainstorming and keep Issues for actionable tasks
  • Convert Discussions into Issues when they become specific enough to act on
  • Tag user-reported feedback with a "user-reported" label to distinguish it from internal ideas
  • Review feedback weekly — prioritize, respond, and close stale items
  • Add feedback issues to a GitHub Project board with columns like Backlog, Considering, and Planned
  • Close feedback issues with a comment explaining the decision, whether you built it or not

Still stuck?

Copy one of these prompts to get a personalized, step-by-step explanation.

ChatGPT Prompt

I'm a non-technical founder collecting feature requests from users. Help me create a system for organizing and prioritizing feedback using GitHub Issues and labels.

Frequently asked questions

What is the difference between GitHub Issues and GitHub Discussions?

Issues are for specific, actionable tasks (bugs, features, to-dos). Discussions are for open-ended conversations, brainstorming, and Q&A. You can convert a Discussion into an Issue when it becomes specific enough to act on.

Can users submit feedback without a GitHub account?

Not directly. GitHub requires an account to create Issues or Discussions. You can work around this by creating a simple feedback form (via Google Forms or a Lovable-built form) that emails you, and then you create the Issue on their behalf.

How do I prioritize feedback when there is too much of it?

Use priority labels (must-have, nice-to-have, future) and sort by the label. Focus on must-have items from real users first. A GitHub Project board with columns helps visualize what is being considered versus what is planned.

Should I close feedback issues I am not going to build?

Yes. Close them with a comment explaining why: "We considered this but decided it does not align with our current direction." This respects the submitter's time and keeps your Issues list clean.

Can I use AI tools to help respond to feedback?

Yes. You can paste a user's feedback into Lovable, Cursor, or ChatGPT to draft a response, evaluate feasibility, or even start building the requested feature immediately.

Can RapidDev help set up a feedback management system on GitHub?

Yes. RapidDev helps teams configure issue templates, label systems, Discussions categories, and Project boards so feedback is consistently captured and prioritized.

How do I prevent duplicate feature requests?

Before creating a new issue, search existing issues using keywords. GitHub's search bar on the Issues page searches titles and descriptions. You can also pin a popular request and ask users to upvote it with a thumbs-up reaction instead of filing duplicates.

RapidDev

Talk to an Expert

Our team has built 600+ apps. Get personalized help with your project.

Book a free consultation

Need help with your project?

Our experts have built 600+ apps and can accelerate your development. Book a free consultation — no strings attached.

Book a free consultation

We put the rapid in RapidDev

Need a dedicated strategic tech and growth partner? Discover what RapidDev can do for your business! Book a call with our team to schedule a free, no-obligation consultation. We'll discuss your project and provide a custom quote at no cost.