GitHub issues for feature requests: enough, or add a board?

If the people who ask for features are developers with a GitHub account, and your repository is public, GitHub issues are enough: an enhancement label, an issue form that asks the right questions, and 👍 reactions to rank them. Once requests come from customers who don't live on GitHub, issues start losing them, and a feedback board should take them in while issues stay the engineering record. The part that breaks is the link between the two, so here is when to add a board, and what keeping both in step should do for you.

When issues are enough#

Open-source projects and developer tools often never need anything else. Their users already have accounts, read the code, and write good reports. A few habits make issues work as a request tracker:

• A label for requests, kept apart from bugs, so that label:enhancement lists them.
• An issue form that asks for the problem before the solution: see our feature request template, a form you can copy.
• Reactions as votes. GitHub's search sorts by them: is:open label:enhancement sort:reactions-+1-desc lists the most wanted first.
• Discussions for the vague ideas, so that issues stay things someone could start on.

Where issues stop working#

Issues were made for the people who build the software. When the people who ask are your customers, six things go wrong:

1. Asking takes an account. Most customers of a business app have none on GitHub, and won't create one to ask for an export. The request goes to support, to a sales call or nowhere.
2. A public repository shows everything. A customer describing their workflow writes it for anyone to read, with their name beside it. A private repository fixes that by shutting customers out entirely.
3. A reaction counts accounts, not customers. It says nothing of who asked: a team on your biggest plan and a visitor from last week weigh the same.
4. Duplicates split the votes. The same request arrives in five wordings. Closing four as duplicates of the fifth leaves their reactions on the closed issues.
5. Nobody hears when it ships. The issue closes when the code merges. The customer who asked through support learns about it by chance, if at all.
6. Requests drown among the work. Bugs, tasks and refactors share the list, and triage becomes a job of its own.

Two places, one request#

The usual answer is a board for intake and issues for the work. Customers post, vote and comment on a board, signed in with the account they already have in your app; the board shows similar requests while they type, and the team merges what is still a duplicate, votes included. When a request is ready to build, it becomes an issue.

That hand-off is where things get lost. Someone copies the request into an issue, the engineers discuss it there, the issue closes, and the request on the board still says "Planned" a month later. A sync replaces the copying.

What a sync should do#

Whichever tools you use, these are the parts that save the most work:

• Create the issue from the request, with a title and a text written for engineers, a link back, and the number of votes. Nothing about who asked: no name, no email, no company leaves for the tracker.
• Statuses both ways. An issue closed as completed completes its request, and the people who voted hear about it. A request moved to "Planned" or "In progress" moves its issue, with a label.
• More than one issue per request. Offline mode needs the web app, the mobile app and the backend. The request completes once every issue is done.
• Comments both ways, without names. What customers add reaches the issue as "A customer commented"; what engineers write comes back as internal notes the team reads and the customers don't, unless the team publishes an answer.
• Care with public repositories. A request not everyone may see shouldn't reach a public issue without someone saying so.

With Swingback#

Swingback's portal and widget take requests from customers signed in with your app's account, and each request links to issues on GitHub and in Linear, up to 20 of them. Statuses and comments travel both ways as above, and routing rules can send a request to the right repository by its board and tags.

GitHub and Linear in the docs has the setup, what each state of an issue gives a request, and what leaves for the tracker.