Thanks For The Feedback

What Thanks For The Feedback Actually Is

Thanks For The Feedback is a browser extension and automation tool that lets you auto-reply to open-source issue reports, pull request comments, and customer support tickets with a templated closing message. Most people use it to stop manually typing the same three sentences every time someone opens a bug report that has already been addressed. The extension lives in your browser and works primarily with GitHub, but it has integrations for GitLab and a few other platforms. The core feature is simple: you create a set of canned responses, assign triggers to them, and the tool posts the response for you or queues it for review before it goes out. That sounds straightforward until you try to use it at scale.

Getting Started With Thanks For The Feedback

Download the extension from the Chrome Web Store or Firefox Add-ons page. Search for "Thanks For The Feedback" by the developer team that published it. Install it, then open the dashboard and connect your GitHub account. The connection flow uses OAuth, so you grant it read and write permissions to your repositories. This is where most people hesitate, and honestly it is fair hesitation. Read the scope carefully before authorizing. Once connected, go to Settings and add a new template. A template is just text with optional variables. The most common variables are {{author}}, {{repo}}, and {{issue_number}}. You can build multiple templates for different scenarios like invalid reports, duplicate issues, or feature requests that do not align with the project roadmap. Here is a realistic example I actually use:

Template name: Duplicate Issue Closed Trigger: Issue labeled "duplicate" Message: Hi {{author}}, thanks for the report. This looks like a duplicate of #142, which already covers the same behavior. Closing this one in favor of the original. Please follow up there if you have additional details.

When a new issue arrives with that label, the tool can either post the message automatically or mark it for manual review first. I recommend the review step unless you are extremely confident in your labels.

How I Set It Up In Practice

I run this across about twelve repositories, ranging from small utility libraries to a mid-size web application. My first attempt was too aggressive. I enabled auto-close with auto-reply on everything, and within a week I had closed forty-two issues that turned out to be edge cases with legitimate user confusion. The users were unhappy. The messages felt dismissive. I learned quickly that automation works best when it handles the obvious cases and flags the ambiguous ones. My current setup uses three layers. The first layer runs a local script that checks incoming issues against a known issues list before Thanks For The Feedback ever sees them. If the issue matches something already documented, it gets tagged automatically. The second layer is the extension itself, handling the templated replies. The third layer is me, reviewing flagged items twice a day. This cut my daily issue management time from roughly two hours down to about twenty minutes.

Common Pitfalls People Run Into

One problem I hit early on and that many newcomers miss is that the extension cannot reliably distinguish between a duplicate issue and a similar but distinct issue. The algorithm looks at titles and keywords, not intent. If two issues share the same error message but stem from different root causes, the tool will close them as duplicates and send the same canned response. This creates exactly the kind of frustration you want to avoid. The workaround is to use custom labels instead of relying solely on automatic detection. Manually add a "verified-duplicate" label only after you have confirmed the duplication. Then set the extension to trigger only on that specific label, not on any label containing the word "duplicate." It adds a small manual step but it prevents the wrong replies from going out. Another pitfall is template drift. After a few weeks of updates, your templates stop matching your actual policy. I found this out when a contributor opened an issue about a breaking change I had introduced in a minor release. The auto-reply told them to check the changelog, but the changelog entry was vague and the real problem was undocumented. The reply made me look careless. I went back through every template and updated the ones that referenced outdated documentation.

What It Does Not Handle Well

Thanks For The Feedback is not a conversation tool. It does not parse follow-up responses intelligently. If a user replies to your auto-closed issue with new information, the extension does not adjust the thread or reopen anything unless you manually intervene. This is not a flaw in the traditional sense, but it is a hard limitation. Projects that expect the tool to manage full issue lifecycles will be disappointed. The extension also struggles with multilingual repositories. The templates are plain text substitutions. If your project receives issues in Spanish, Korean, or any language other than English, the auto-reply will still go out in whatever language you wrote the template in. Some users add multilingual template variants, but you have to create and maintain each one yourself. There is no automatic translation layer built in.

Alternative Approaches Worth Considering

If your project receives a high volume of issues and you need something more sophisticated, you might look at GitHub Actions with custom workflows. Tools like action-close-invalid-issue or stale combined with a custom reply script give you more control over conditions and logic. They require more setup, but they do not depend on a browser extension, which means they work even when you are not actively using your computer. For smaller projects, the extension is fine. It is fast to configure and gets the job done without writing code. Just be honest about what it can and cannot do, and set expectations accordingly with your team.

Final Notes On Usage

Make sure your templates sound like a person wrote them, not a policy document. Users can tell the difference, and responses that read like legal boilerplate tend to escalate frustration rather than reduce it. Keep messages under four sentences. Include the issue number. End with a clear next step, even if the next step is just "feel free to reply here if you disagree." It is a small thing but it changes how people interpret the closure. I have been using this setup for about eight months now. It handles roughly sixty percent of my incoming issues without human input. The remaining forty percent still requires judgment, and I am not convinced any tool will fully replace that part. That is fine. It means I spend less time on routine replies and more time on the issues that actually need attention.