Hollahoop

HollaHoop

Sign in
Feedback

Feature requests

Ideas the community would love to see.

New post
All typesFeatureBugTweak

Email ingestion for support tickets (IMAP/POP3 via Supabase Edge Function)

Scheduled Supabase Edge Function (Deno) that polls a configured IMAP mailbox per project on a cron interval, parses MIME, and either creates a new support_ticket or appends a support_message to an existing thread. Threading via In-Reply-To / References / Message-ID headers; idempotency via support_messages.external_message_id unique index. Per-project mailbox config (host, port, user, app password, ssl) stored encrypted (pgsodium) in a support_mailboxes table; only owners can read. Bounces and auto-replies filtered out. Outbound replies go via the same SMTP creds (or via SendGrid if Stripe-tier allows). Out of scope: full SMTP fanout to many recipients, OAuth (Gmail/Microsoft) - paste-an-app-password flow only in v1.

PlannedFeature requests·2 days ago·0

AI provider settings: Bring Your Own API Key

Org-level AI configuration (separate card from per-project knobs). Provider choice (Anthropic, OpenAI, OpenRouter), encrypted key storage (pgsodium), monthly spend cap (USD), per-user rate limit (default 30/hour), redaction toggles ("never send private board content", "never send PII"). Stored in a new ai_settings table keyed by org_id. Powers every AI feature in Hollahoop: existing duplicate detection + changelog drafting + the new AI Suggest card. When unset, AI features fall back to template/heuristic mode (we never silently 0-key-call). Visible spend meter on the org settings page so admins can see the bill in real time.

ShippedFeature requests·2 days ago·0

Estimated release date on Planned/Reviewing posts

Add an optional estimated_release_at timestamptz column on posts. Editable only when status is Planned or Reviewing (or any non-terminal state - settable via project config). Supports both exact dates ("2026-08-12") and quarter-fuzz ("2026-Q3") via a small parser, stored as a date plus a precision enum (day, week, month, quarter). Surfaces as a "Coming ~Aug" pill on cards, drives the Timeline view (separate post), and quietly clears itself when the post moves to Shipped (replaced by the actual ship date from status_history). Visible on the public roadmap when project is_public.

ShippedFeature requests·2 days ago·0

Saved filters and saved views

Let admins turn complex filters into named views: Untriaged this week, High votes low effort, Onboarding bugs, Pro customer requests, Stale planned, Mine, Needs changelog. Views can be private to a user or shared with the project. Schema: saved_views(id, project_id, owner_id, name, visibility, route_scope, filters jsonb, sort jsonb, created_at). UI: save current filter, pin views in sidebar, share link, set default view. Works across feedback list, roadmap, support inbox, analytics, and timeline.

ShippedFeature requests·2 days ago·0

Support inbox: foundation (tickets, messages, statuses)

New /app/{org}/{project}/support surface, separate from feedback. Two tables: support_tickets (id, project_id, subject, status, priority, requester_email, requester_name, assignee_id, source enum, external_message_id, created_at, last_activity_at) and support_messages (id, ticket_id, body_md, direction enum inbound|outbound, channel enum email|web|api, author_id, created_at). Status workflow: new -> open -> pending -> resolved -> closed. Inbox UI mirrors common helpdesk layout (list left, conversation right). Out of scope: email ingestion (separate card), AI suggest-reply and ticket-to-post conversion (separate card), SLA timers, multi-mailbox routing. This card lands the data model + a usable manual inbox where admins can create tickets via web and reply.

PlannedFeature requests·2 days ago·0

Live view: realtime presence and live counts (Supabase Realtime)

Show who else is on a post right now via small overlapping avatars; show typing indicator on the comment composer; live-update vote_count and comment_count without a refresh. Powered by Supabase Realtime broadcast + presence channels (one channel per post id). Lightweight - no new tables required, presence state is ephemeral. UI surfaces: post detail header (presence row), feedback list (live vote count ticking), team chat composer (typing dots). Tight scope - no edit conflict resolution, no "user X is editing" locks; just visibility primitives. Pairs nicely with team chat to make collaborative triage feel alive.

PlannedFeature requests·2 days ago·0

Team chat: internal-only comments and a team feed

Adds a parallel comment lane on every post that is visible only to org/project members - separate from the public discussion thread end-users see. Each post gets a "Team" tab next to "Public" comments. Plus a project-wide /team feed that aggregates the latest internal threads across all posts so admins can scan recent internal activity without clicking into each card. Schema: extend comments with visibility enum (public, internal). RLS: internal comments only readable/writable by project members. UI: tabbed thread on post detail, plus a new project-level Team page. Out of scope: real-time presence (separate card), DMs, slash-commands, file uploads beyond what posts already allow.

PlannedFeature requests·2 days ago·0

AI Suggest: opt-in suggestions with strict guardrails

A unified "Suggest improvement" affordance on posts, comments and changelog drafts. User-triggered only - never autonomous. Three modes: (1) Tighten wording, (2) Add structure (bullets, headings), (3) Summarise from linked GitHub PR/issue context. Output appears as a side-by-side diff the user must explicitly accept; AI never writes directly to a row. Guardrails: every prompt is constrained to the source content + an explicit task instruction (no open-ended queries), no chain-of-tool-use, no external retrieval. Accepts only suggestions of size <= 1.5x the original. Surfaces the source model + token count on each suggestion so users can audit. Skipped entirely when AI provider settings are unset.

PlannedFeature requests·2 days ago·0

Create a GitHub issue from a Hollahoop post (optional outbound)

When an admin moves a post to Planned, offer (do NOT auto-fire) a "Create GitHub issue" action. Generates an issue in the linked repo with body=post body + voter count + Hollahoop permalink, labels=Hollahoop tags + a "from-hollahoop" label so they are filterable, default assignee from project settings. Creates the github_post_links row on success. Two-button UI on status change: "Plan only" or "Plan + Create Issue". Avoids surprise issues - every outbound mutation requires explicit click. Per-project toggle to disable the prompt entirely if the team prefers paste-URL-only workflow.

PlannedFeature requests·2 days ago·0

Reflect GitHub Milestones on the Hollahoop roadmap

Read-only reflection of GitHub Milestones onto the Hollahoop roadmap surface - explicitly NOT a new Hollahoop primitive. For each linked repo, fetch open milestones; render them as soft headings on the roadmap with their due_on date and progress (open/closed issue count from GitHub). Posts whose linked issue belongs to a milestone get a small "Milestone: v1.4" badge. This is the use-GitHub-as-the-planning-layer play. Keeps Hollahoop free of epic/story/sprint vocabulary while looking like a planning tool to anyone who wants one. Refresh on milestone webhook events plus a 5-minute cache fallback.

PlannedFeature requests·2 days ago·0

Release published: AI changelog draft from PR + issue context

When a GitHub Release is published (release.published webhook, ignoring drafts and prereleases by default), bundle every Hollahoop post that hit Shipped since the previous release for that repo and create a draft changelog_entries row. Source material for the AI draft: release.body + release tag + linked PR titles/bodies + linked issue titles + the Hollahoop posts own titles. Output is a versioned draft titled e.g. "v1.4.0 - what shipped" sitting in the Drafts queue, not auto-published. Pairs with the AI provider settings card (BYOK key, guardrails). When no key is configured, fall back to the existing template-based draft.

PlannedFeature requests·2 days ago·0

Auto-ship: GitHub issue closed flips Hollahoop post to Shipped

When a GitHub issue with a github_post_links row is closed with state_reason=completed, flip the linked Hollahoop post to the project Shipped status. Append a "Closed by [PR title](url)" footer to post body when the closing PR is detected. Per-project toggle for "Reopen post if issue is reopened" (default off — engineering teams reopen issues for QA, not for regression). Implements the issues.closed and pull_request.closed webhook handlers. Idempotent via webhook_events.delivery_id. Does NOT mirror comments, does NOT sync issue body — strictly status signal only.

PlannedFeature requests·2 days ago·0

Link a Hollahoop post to a GitHub issue or PR

Keystone of the GitHub integration: lets admins paste any GitHub issue or PR URL onto a Hollahoop post. Parses owner/repo/number, validates the org has the GitHub App installed on that repo, stores the link in a new github_post_links table (post_id PK, repo_id, issue_number, etag, last_synced). Renders an "acme/api#123" pill on the post detail page and on roadmap cards. Optional: parse cross-repo refs ("acme/api#123") in post bodies and offer "Convert to link?" suggestion. This is the cheapest single feature to ship and seeds the data every other GitHub event handler depends on. Build before auto-ship and release-driven changelog drafts.

PlannedFeature requests·2 days ago·0

Linear sync integration

For teams that plan in Linear instead of GitHub. Similar shape to GitHub sync but using Linear OAuth/API: link Hollahoop posts to Linear issues, optional create Linear issue from Planned, Linear issue completed -> Hollahoop Shipped, comments/labels optional, Linear project/cycle reflection as read-only badges. Keep scope narrower than GitHub v1: link, create, complete, reflect project/cycle. No full bidirectional comment sync. Use the same integration abstractions as GitHub where possible so connectors share event, link, and status plumbing.

PlannedFeature requests·2 days ago·0

GitHub App: install flow and org-level credentials

Foundation for every other GitHub feature. Register one Hollahoop GitHub App globally; let org owners install it on their GH org with selected repos. Persist installation_id, account_login and installed_by in a new github_installations table keyed by org_id. Mint installation tokens on demand via @octokit/auth-app (1h TTL, in-memory cached). New webhook route /api/integrations/github/webhook with HMAC signature verification and a webhook_events idempotency log. Org settings gets a GitHub card with Install / Reinstall / Uninstall. Out of scope: per-project repo linking (separate post), per-post issue linking (separate post), inbound event handlers (separate post). This card only delivers a working install + token mint + signed webhook receiver that logs events to a table.

PlannedFeature requests·2 days ago·0

Public shipped-requests stats widget

Embeddable marketing badge for customer sites: "We shipped 23 user requests in the last 90 days" with link to public changelog/roadmap. Pulls from status history and changelog publish data. Customizable colors, size, and time window. This is distribution: every customer embedding the badge advertises Hollahoop-powered customer feedback. Needs anti-gaming rules and public-safe aggregation only. Pairs with the public hub and in-app announcement widget.

ShippedFeature requests·2 days ago·0
HollahoopGet yours