You’ve built a documentation site. Customers read it, learn how your product works, and inevitably think: “This is good, but it would be better if…”

Where do they send that feedback? Email? Slack? Twitter DM? A GitHub Issue if they know where your repo is? More likely, they don’t send it at all. The friction of figuring out where to submit an idea means most feedback evaporates before it reaches you.

Here’s a better pattern: put a suggestion board directly on your docs site. Let visitors submit ideas, vote on what matters most, and see which requests you’re working on—all without leaving the documentation.

The problem with scattered feedback

When feature requests come through multiple channels, you lose two things:

Prioritization signal. An email from one customer saying “We need SSO” looks the same as an email from another customer saying the same thing. You can’t tell if 2 customers want it or 50. There’s no aggregate view of demand.

Transparency. Customers submit feedback and hear nothing back. They don’t know if you’re considering it, building it, or decided against it. You probably triaged the request internally, but the customer who suggested it has no visibility into that decision.

The result is wasted effort: your team manually de-duplicates requests across email threads, Slack messages, and support tickets. Customers re-submit ideas they already sent because they assume nothing happened with the first one.

Why docs sites are the right place

Your documentation is where customers go when they’re actively thinking about your product. They’re reading about authentication, webhooks, or API limits, and that’s when they notice what’s missing.

If there’s a /suggestions link right there in the sidebar, submitting feedback takes 30 seconds. No context switch, no hunting for the right email address, no “should I file a GitHub Issue or…” uncertainty.

And once they submit it, they can see what everyone else wants too. Feature requests sorted by vote count naturally surface the most-wanted ideas. Your team doesn’t need to manually tally demand—the votes do it automatically.

How it works in practice

Scitor’s suggestion board feature connects your docs site to a GitHub Project board. Here’s the flow:

A visitor opens /suggestions on your docs site
They browse existing ideas (sorted by votes) and vote on ones they like
If their idea isn’t there, they submit a new suggestion
Scitor creates a GitHub Issue with a suggestion label and adds it to a dedicated Project board
Your team manages suggestions in GitHub Projects—drag them to “Planned”, “In Progress”, or “Shipped”
Status updates appear on the docs page automatically

The entire loop happens without customers needing a GitHub account or knowing your repo exists. They submit ideas through a web form, vote with one click, and see status updates reflected on the public page.

Setup takes 3 lines of config

Add this to .github/scitor.yaml in your repository:

suggestions:
  enabled: true

That’s it. On the next docs build, Scitor creates:

A GitHub Project board called “Suggestion Board”
Custom fields for Votes, Status, and Category
A /suggestions page on your docs site with a navigation link

Want to customize it? Add categories:

suggestions:
  enabled: true
  categories:
    - "Bug fix"
    - "New feature"
    - "Improvement"
    - "Documentation"

Now the submit form has a category dropdown, and suggestions display category badges.

The GitHub Projects integration

When suggestions are enabled, Scitor sets up a GitHub ProjectV2 board with everything pre-configured:

Custom fields:

Votes (number) — total vote count from docs site visitors
Status (single select) — Under Review | Planned | In Progress | Shipped | Declined
Category (single select) — matches your config

Pre-built views:

By Votes (table) — sorted by vote count, highest first
By Status (board) — kanban columns for dragging suggestions through states
Recent (table) — sorted by submission date

Managing suggestions is just normal GitHub Projects work:

Open the “By Votes” view to see what users want most
Drag suggestions in the board view to update status
Add comments on the linked Issue to discuss internally
Close the Issue when shipped or declined

Status changes sync back to the docs page. When you move a suggestion to “Planned”, visitors see a blue “Planned” badge on the public page. Move it to “Shipped” and it gets a green checkmark. This transparency builds trust—customers see that feedback doesn’t disappear into a black hole.

Voting is anonymous and frictionless

No login, no email required. Visitors click ▲ to vote on a suggestion. Each person gets one vote per idea, tracked by an anonymous hash of their IP and browser fingerprint.

Vote counts update in real-time on the docs page and sync to the “Votes” field on your Project board. The most-wanted ideas naturally rise to the top.

This is critical. When you check the “By Votes” view in GitHub Projects, you’re looking at aggregate demand—not just the loudest voice or the most recent request, but actual signal from your user base.

When to use moderation

By default, suggestions appear on the docs page immediately. For most teams, this works fine. But if you expect high volumes or want to filter duplicates before they go public, enable moderation:

suggestions:
  enabled: true
  moderation: true

With moderation:

New suggestions still create a GitHub Issue
But they’re hidden from the docs page until you change their status
Once you set status to “Planned”, “In Progress”, or even “Declined”, the suggestion becomes public

This keeps your board clean without blocking submissions.

Real example: what customers actually want

Here’s what the “By Votes” view might look like after a few weeks:

Suggestion	Votes	Status
Add Slack integration for notifications	47	Planned
Support for multi-language docs	38	Under Review
Dark mode for documentation site	29	In Progress
Webhook signature verification	23	Planned
Export reports to CSV	19	Under Review
Custom domain for forms	12	Shipped ✅

You now have clear prioritization data. The Slack integration has 47 votes—way more demand than CSV exports with 19. You can make informed decisions about what to build next.

And customers can see you’re working on dark mode (In Progress) and already shipped custom domains. That visibility matters.

Why this beats a feedback form

Most feedback forms are black holes. The user fills it out, hits submit, and never hears back. They have no idea if anyone read it, if others want the same thing, or if you’re even considering it.

A suggestion board flips this:

Submissions are public (unless you enable moderation)
Users can vote on each other’s ideas
Status updates show progress
The entire board becomes a prioritization tool for your team

It’s not just collecting feedback—it’s creating a shared understanding of what matters between you and your users.

When not to use this

This pattern works best for products with:

Developer or technical audiences who understand feature requests
A documentation site where users spend time learning the product
A team that’s willing to manage a GitHub Project board

It’s less suited for:

High-volume consumer products (you’ll drown in submissions)
Teams that don’t use GitHub for planning
Products without technical documentation

If your product doesn’t have a docs site, a standalone feedback widget or a dedicated feedback tool like Canny might be better.

Privacy and spam protection

Voting is anonymous. Scitor stores a SHA-256 hash of the visitor’s IP and User-Agent, nothing more. No personal data is retained for voting.

Submission includes optional contact info. The submit form has name and email fields, but they’re optional. If provided, they appear in the GitHub Issue body (visible to your team) but not on the public docs page.

Spam prevention includes:

Honeypot field (catches simple bots)
Turnstile CAPTCHA (Cloudflare’s privacy-preserving challenge)
Rate limiting (5 submissions per IP per hour)

The transparency advantage

The biggest win isn’t the data—it’s the trust. When customers see:

Their suggestion got 15 votes from other users
You moved it to “Planned” status
A comment from your team explaining the timeline

They know you’re listening. They stop re-submitting the same request through different channels because they can see the status themselves.

And when you mark something “Declined” with a comment explaining why, that’s valuable too. Users appreciate transparency even when the answer is “no, and here’s why.”

Getting started

If you’re already using Scitor for GitHub-based docs, enabling suggestions takes one config change:

docs:
  path: docs
  title: "Your Product Docs"

suggestions:
  enabled: true

Push to your main branch. On the next build, you’ll have a /suggestions page and a GitHub Project board ready to go.

No separate feedback tool to integrate. No third-party service to pay for. Just GitHub Projects (which you probably already use) plus a public-facing interface for your users.

Set up a suggestion board. Scitor’s suggestion board feature is included in the Pro plan ($9/month). Install from the GitHub Marketplace and add it to your docs site in minutes.

Collecting Feature Requests Directly from Your Documentation