GitHub user aicam closed a discussion: Proposal: Add a user feedback option to
Texera
### 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!
GitHub link: https://github.com/apache/texera/discussions/5759
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
