For collecting feedback on web apps, especially when dealing with frontend changes, and organizing it effectively, I recommend considering some open-source alternatives that offer React integration and the ability to self-host data (on your own servers or S3). Here are a few tools that have worked well for me over the years:

1. *OpenReplay* (open-source): A fantastic session replay tool with React integration, allowing you to capture visual feedback, user sessions, and bug reports. It’s fully self-hostable, and you can store data in S3 or your own infrastructure. Highly recommend it for teams wanting full control over their data.

2. *Sentry (Self-hosted)*: While Sentry is primarily known for error tracking, it also allows capturing user feedback (with screenshots) and integrates well with React. The self-hosted version lets you manage everything internally, with support for custom storage like S3.

3. *GlitchTip* (open-source): A lightweight alternative to Sentry with error tracking and feedback options, designed for simplicity. Fully self-hostable and works great with React apps.

4. *Marker.io*: A fantastic tool for visual bug reporting that integrates seamlessly with React. It allows users to report bugs directly from the app, including screenshots and annotations. While not open-source, it supports private cloud hosting, letting you store data on your own infrastructure or in S3. The UI is great for non-technical users, making feedback collection simple and effective.

5. *SessionStack* (self-hosted option): A solid choice if you need session replays for debugging frontend issues. They offer a self-hosted version, so you can store all session data in S3 or your own servers.

For teams like yours, where managing feedback and QA efficiently is key, these tools provide the flexibility you need, especially if you require private hosting. They all integrate seamlessly with React, and they keep your data within your control.

I don't know of an internal feedback tool, that's not more general purpose. I think a lot of what you're describing is the-practice-of-software-development. There are Lots of possible solutions, what works best for _your_ team will be somewhat unique to them.

The company I work for [0] provides application hosting which includes automatic preview URLs, that can also be associated with a Github PR. The PR will have a link to the environment, with discussion below. Subsequent releases to the environment also get registered with the PR so it's easy to catalogue and annotate developments/fixes.

0. https://noop.dev

If you deploy on Vercel, the preview builds are automatic, and there is on-page commenting and discussions: https://vercel.com/docs/workflow-collaboration/comments

There are similar tools if you're not on Vercel, like https://usersnap.com/l/visual-feedback-tool

But beyond that, I don't think you should be having all the long discussions in the same place that you keep your tickets (let's say a kanban board). Have your discussions wherever you want, but keep them between the 2-3 people really involved. Then once they have an idea of what needs to change, THEN they can make a ticket for it with just some simple bullet points (linking back to the full discussion if they want).

Having everyone comment in the QA ticket directly mixes up discussion about the ticket itself and discussion about what to ticketize (which should've been done previously, outside the ticket). It's too much detail for the rest of the team to keep up with. They don't need the whole sordid history of how you got there, just what needs to be done.

In the teams I've been on, that previous discussion would happen all over the place... sometimes over Slack, sometimes over coffee at the coffee shop next door, sometimes in Figma/GDocs/Vercel comments, whatever. But once we come to an agreement, one of us writes the actual ticket without all the baggage, keeping it simple and clear.

----------

Edit: I think it really helps to have someone on the team who cares a lot about organization (and maybe even enjoys it). That could be anyone... a manager, project/product owner, one of the devs with a lighter workload, etc., just somebody who's OK going through the tickets once a week or so and making sure they have sufficient information for working on, and pinging the individual ticket creators for clarification if needed. The rest of the team doesn't need to get involved, but it helps make sure that the tickets are ready for work once you get to them. THAT's the sort of stuff that the comments in the actual ticket are good for (clarifications, not brainstorming).

Having someone do it manually is the simplest thing that might work. Yes, it sounds tedious and time consuming. So let that person automate the task away. That means putting someone with the skill to automate the task away at the manual task. Custom underware is a sewing problem not a shopping problem. Good luck.