If you’re moving customer support into GitHub, you face an immediate choice: Issues or Discussions?
Both can handle inbound emails, both support comments and labels, and both keep your support work in one place. But they’re designed for fundamentally different workflows. Choose wrong and you’ll fight the tooling instead of working with it.
Here’s how to decide.
The core difference
GitHub Issues are designed for trackable, actionable work. They assume a linear lifecycle: open → in progress → resolved → closed. They work best when there’s a clear “done” state.
GitHub Discussions are designed for open-ended conversation. They assume ongoing dialogue, multiple threads, and no clear resolution. They work best when the goal is knowledge sharing, not task completion.
For customer support, this distinction determines whether a ticket feels natural or awkward in each system.
When Issues work better
1. Bug reports and feature requests
If a customer emails about a bug, that’s a trackable task with a clear lifecycle: reported → investigated → fixed → deployed → closed. Issues are built for this.
The assignee field makes it clear who owns the fix. Labels track status (in-progress, deployed, waiting-on-customer). Milestones batch related bugs together. Closing the issue signals resolution.
Discussions have none of these primitives. You could jury-rig status tracking with categories or labels, but it would feel like fighting the platform.
2. Tickets that need SLA tracking
If you track response times and resolution deadlines, Issues are the only option. Labels like sla:at-risk and sla:breached make sense on an Issue because Issues have open/closed states and timestamps.
SLA tracking on Discussions would require custom tooling to interpret “answered” vs “resolved” since Discussions have no canonical lifecycle.
3. Workflows that integrate with GitHub Actions
Many teams use GitHub Actions to automate support: auto-assign tickets based on category, escalate stale issues, notify on-call engineers when urgent tickets arrive, or sync to external systems.
Actions integrate cleanly with Issues through events like issues.opened, issues.labeled, and issues.assigned. Discussion events exist but are less mature and less documented. If automation is central to your workflow, Issues are safer.
4. Support that becomes product work
If support tickets often turn into bugs or feature requests that engineering works on, Issues keep everything in one system. A customer reports a bug via email, it creates an Issue, engineering fixes it, and the same Issue tracks the work from report to resolution.
With Discussions, you would need to create a separate Issue for the engineering work, splitting the context.
When Discussions work better
1. Community support
If you run a public forum where customers help each other (common in open-source projects or API products with an active community), Discussions are the right tool. They support threaded replies, upvoting, and marking an answer as “accepted.”
The UI encourages browsing and discovery. Discussions show up in search more naturally than closed Issues because they are designed to be evergreen knowledge, not archived tasks.
2. Questions without a clear resolution
Some customer emails aren’t tickets in the traditional sense. “What’s the best way to structure our API calls for performance?” or “How do other teams handle authentication?” These are open-ended questions that might generate ongoing discussion, not a single resolution.
Discussions allow multiple people to chime in, vote on answers, and build context over time. Issues feel too rigid for this—closing an Issue implies the question is settled, which isn’t always true.
3. FAQ and knowledge base building
If your goal is to build a searchable archive of questions and answers that customers can browse before emailing you, Discussions are designed for that. Categories like “Billing,” “API,” and “Getting Started” organize the content naturally.
Issues can do this, but the UX fights you. Issues are optimized for scanning status (“what needs my attention?”), not for reading solved problems (“how do other people handle X?“).
4. Lower-stakes conversations
Some teams prefer Discussions for customer support because closing an Issue feels more final than marking a Discussion as answered. If a customer replies after a ticket is closed, reopening an Issue feels heavier than continuing a Discussion thread.
This is subjective, but teams that value a more relaxed, conversational tone often gravitate toward Discussions.
Feature comparison
| Feature | Issues | Discussions |
|---|---|---|
| Open/closed lifecycle | Yes | No (answered/unanswered instead) |
| Assignees | Yes | No |
| Labels | Yes | Yes (but less commonly used) |
| Milestones | Yes | No |
| Projects / boards | Native support | Limited support |
| Threaded replies | No (flat comments) | Yes (nested threads) |
| Upvoting | Reactions only | Native upvote on answers |
| Mark as answered | No | Yes |
| GitHub Actions integration | Mature | Less mature |
| Email notifications | Yes | Yes |
| Searchability | Good for open tickets | Better for evergreen content |
| Public visibility | Typical for OSS | Designed for public |
| SLA tracking (with tools) | Yes | Workarounds required |
Hybrid approaches
Some teams use both:
- Discussions for general questions and community interaction.
- Issues for bug reports and support tickets that require tracking and resolution.
Tools like Scitor let you configure this per repository with a single line in .github/scitor.yaml:
integration: issue # or "discussion"You can even route different email addresses to different integration types if your team has both a general help channel and a dedicated support queue.
The private vs. public question
One concern teams have: “Aren’t Issues and Discussions public by default?”
Yes, in public repositories. But most teams that run customer support through GitHub use a dedicated private repository (e.g., yourcompany/support). Customers interact entirely via email—they never see GitHub. The Issues or Discussions are only visible to your team.
This works the same whether you choose Issues or Discussions.
Decision framework
Choose Issues if:
- Customer support involves trackable tasks with clear resolution (bugs, feature requests, billing problems).
- You need SLA tracking, routing, or automated escalation.
- Most tickets result in engineering work (bug fixes, config changes).
- Your team wants a structured workflow with assignees and status labels.
Choose Discussions if:
- Customer support is more open-ended (questions, advice, troubleshooting).
- You want a community forum where customers can help each other.
- You are building a public knowledge base of common questions.
- Your workflow is conversational rather than task-driven.
Choose both if:
- You want Discussions for general help and community, plus Issues for tracked support tickets.
- You have the bandwidth to manage two channels and can route customers appropriately.
Our recommendation for most teams
For customer support where engineers handle tickets directly, Issues are the safer default. They map cleanly to the helpdesk model most teams are familiar with: tickets arrive, get triaged, assigned, worked on, and closed. The tooling around Issues is mature, automation is straightforward, and SLA tracking works naturally.
Discussions shine when you want community interaction or a public Q&A forum. If that’s not your primary goal, Issues will feel more familiar and structured.
Try both. With Scitor, switching between Issues and Discussions is a one-line config change. Install from the GitHub Marketplace and experiment with what fits your workflow.