GitHub issues filter out casual users by design
An issue template is a contribution workflow, not a feedback channel. Users without an account, without reproduction steps, or without the confidence to post publicly stay silent. A feedback button on your docs site accepts a two-sentence note — no login, no template, no public record.
Docs feedback needs a home that is not the repo
“This page confused me” is gold for documentation and noise in an issue tracker. TellTide submissions arrive with the page URL attached, so you know exactly which doc page generated the confusion — triage it privately and fix the page without ceremony.
Roadmap voting beats issue-thumb archaeology
Counting 👍 reactions across duplicate issues is nobody’s idea of prioritization. Publish the real candidates to a TellTide roadmap and let users vote in one place — then link the winning items back to tracking issues when work starts.
The workflow, end to end
Add the widget to your docs site and demo/playground (the repo README can link the roadmap). Casual users report confusion and wishes in seconds, anonymously if they choose.
Triage weekly: docs fixes go straight to a PR, feature themes go to the public roadmap for votes, and genuine bugs graduate to properly-filed issues by you — with context the user would never have written.
What open-source maintainers lean on most
- No-login feedback for non-contributor users
- Page URL context on every docs submission
- Public roadmap voting without GitHub accounts
- Free plan fits unfunded projects
- API intake if you want CLI or in-app hooks
Questions open-source maintainers ask before starting
Should this replace our issue tracker?
No — it feeds it. TellTide is the low-friction front door for casual users; you promote validated bugs and features into your tracker deliberately, with far better signal-to-noise than drive-by issues.
Does it work on static docs sites?
Yes — Docusaurus, Astro, VitePress, mdBook, plain HTML: anything that serves a page takes the one-line script. The Astro guide covers the is:inline detail for Astro-based docs.
Why is private-first feedback better for open-source maintainers?
Because raw feedback is messy: bug reports carry sensitive detail, reviews deserve personal replies, and half-formed ideas need clarification. A private inbox lets you handle each properly, then publish only credible feature requests to a roadmap where votes mean something.
