Proposal: Add a user feedback option to Texera

[aicam]

Context

We received a request to add a feedback option to the application, so that users have a built-in way to report issues, request features, or share general comments about the system. Today there is no in-app channel for this — feedback only reaches us indirectly (e.g., word of mouth or GitHub issues, which most end users won't open).

This discussion is to align on what kind of feedback mechanism we want to build before committing to an implementation.

Options considered

Option 1 — Integrate an open-source feedback/ticketing service
Adopt an existing open-source tool to provide advanced ticketing and real-time notifications to maintainers (e.g., status tracking, assignment, threaded replies, notifications).

• Pros: Rich functionality out of the box; maintainers get real-time visibility and a proper triage workflow; little ticketing logic to build ourselves.
• Cons: Additional service to deploy, operate, and maintain; integration and authentication work; likely overkill for current needs.

Option 2 — Simple feedback message (a form)
Let users submit a plain feedback message about the system through a simple form. The submission is stored and/or routed to the maintainers, with no ticket lifecycle.

• Pros: Minimal effort to build and maintain; low friction for users; covers the core request ("let users tell us something").
• Cons: No status tracking or back-and-forth with the user; maintainers must manually triage submissions.

Option 3 — Develop a basic in-house ticketing system
Build a lightweight ticketing system ourselves (submit, track status, respond).

• Pros: Tailored to Texera; no external dependency; more capable than a plain message.
• Cons: Significant development and ongoing maintenance effort; reimplements functionality that mature tools already provide.

Current proposal

Our current inclination is to start with Option 2: a simple form that lets users submit feedback about the system. This directly satisfies the original request with the least overhead, and we can iterate toward richer ticketing/notification capabilities (Options 1 or 3) later if usage shows the need.

Open questions

• Where should the feedback entry point live in the UI (e.g., a button in the navigation/header, or a dedicated page)?
• How should submissions be stored and surfaced to maintainers (database table, email/notification, GitHub, etc.)?
• What fields should the form capture (free-text only, or category/severity, optional contact, current page/context)?
• Should we capture lightweight context automatically (e.g., page URL, browser info) to help with triage?

Please share any thoughts, concerns, or preferences on the direction. Thanks!

[aglinxinyuan]

Can we consider a fourth option: leveraging third-party services instead of building everything ourselves? We don’t need to reinvent the wheel for every component—just as we use GitHub rather than building our own Git system.

For example, we could add a feedback template to our issue tracker, or adopt an existing solution such as Zendesk for feedback collection and management.

[aicam]

I think option 1 is exactly that

[aglinxinyuan]

I think option 1 is exactly that

In Option 1, we need to manage and maintain the deployment ourselves. In contrast, Option 4 leverages third-party services such as GitHub, so we don’t need to handle the deployment or maintenance of the ticketing system.

[kunwp1]

Didn't we previously have a forum page to enable this feature? Is it possible to reuse that?

[Yicong-Huang]

Before we say yes to this, I think we should be very careful about the scope. Texera is an Apache open-source project, not a SaaS product with a dedicated support team. In general, an open-source project cannot provide a private ticketing/support service in the same way a commercial SaaS offering can.

I have three main concerns:

1. Privacy and sensitive information. This is my biggest concern. Through the in-app feedback channel, users may accidentally submit private workflow details, logs, internal URLs, dataset names, credentials, or other sensitive information. As an open-source project, we should avoid collecting and storing such information unless we have a very clear policy around where the data goes, who can access it, how long it is retained, and who is responsible for handling deletion or follow-up requests.
2. Maintainer bandwidth. Once we add an in-app feedback or ticketing channel, it is no longer just a UI feature — it effectively becomes a service that someone has to operate. Users may expect maintainers to monitor, triage, respond, and follow up on submitted tickets. That creates an ongoing operational burden for the community.
3. Open-source community process. Apache projects generally encourage users to share feedback, bug reports, and feature requests through public community channels, such as GitHub Issues, GitHub Discussions, public Jira, and mailing lists. This keeps the discussion searchable, transparent, and open to contributions from the broader community. A private ticketing channel would go in the opposite direction unless it is limited to clearly sensitive cases, such as security reports.

Because of these concerns, I would suggest that we do not frame this as a private ticketing or support system. For regular bugs, feature requests, and usability feedback, we should continue to use public GitHub Issues or Discussions. For security-sensitive reports, we should direct users to the appropriate private security reporting channel.

To make user's life easier, we could provide an in-app UI for submitting feedback and automatically create GitHub issues from those submissions. However, in that case, we MUST make it very clear to users before they submit that the information will be posted publicly. The UI should explicitly warn users not to include credentials, private data, internal URLs, sensitive logs, or other confidential information.

If this is for a future SaaS deployment of Texera, that is a different discussion. A SaaS offering could provide its own support channel, privacy policy, retention policy, and operational ownership. But I do not think the open-source project itself should implicitly take on that responsibility.

[zuozhiw]

As Xinyuan said, we should definitely leverage an existing service. Regardless of open source or a possibly future saas offering. There's little point in reinventing wheels for this one. Also at this stage, I would prefer to just use github for feedbacks.

If the use case is for one of our deployments, when the user base gets larger, then I would consider using an open source forum. Another alternative would just be a community slack channel, which is also quite popular.

[chenlica]

This "Feedback" feature could just allow users to provide suggestions to the system admins, without expecting any formal replies. So a ticket system is not needed for now. The "Forum" feature we implemented earlier (currently disabled) is for a different purpose, i.e., letting people have online discussions.

I suggest we use an existing service to make it easier. Each Texera deployment needs to configure this service properly.

[aicam]

Thanks for everyone suggestion, based on the discussion, we go with Option 2 (simple feedback with no formal response).