GitHub discussion thread to issue with label carryover
Promote the discussion that found a real product gap into an issue so the maintainer keeps the context and labels instead of retyping the case from zero.
Why this can grow a startup
Some community threads should stay conversational, but the ones that reveal a real bug, request, or workflow break need a cleaner path into delivery. GitHub lets triage-level maintainers create an issue directly from a discussion, and the discussion content plus labels travel into the new issue body. That keeps the public question intact while giving the team a work object with less copy-paste loss. It also teaches contributors that useful discussions do not disappear into a side room. Good threads can graduate into tracked work.
Company example
GitHub Docs says people with triage permission can create an issue from a discussion, the discussion post is automatically included in the issue body, and existing labels are retained.
Source and metric
Source: GitHub Docs: Creating an issue
GitHub carries the discussion body and labels into the new issue when a maintainer uses Create issue from discussion.
When to use it
Use this when GitHub, Community, Product feedback is relevant to feedback routing, community archive, work intake and you can run a bounded test with a free budget.
When not to use it
Do not use it as a substitute for customer evidence, a clear owner, or a measurable stop condition. Local platform rules and market behavior still need checking.
Founder checklist
- Read GitHub Docs: Creating an issue and identify what is directly supported.
- Choose one channel context: GitHub, Community, Product feedback.
- Define the test around GitHub carries the discussion body and labels into the new issue when a maintainer uses Create issue from discussion..
- Set an owner, evidence window, and stop condition before launch.
Explore the context
Apply this with an operator
Build creator and community systems around real incentives, trust, and repeat participation.