There are questions about the issue

[jgchgjhbkj]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Issues

Body

Some forks are more active and of higher quality than the original project, and many new issues (feature requests, bug reports) are raised about those forks. I propose that GitHub provides an easy way to “fork issues” or to file issues specifically for a forked repository—perhaps even to selectively carry over (mirror or link) issues from the upstream repository to a popular fork.

This would help maintainers and users of active forks manage their own issue trackers clearly and make it easier for contributors to raise problems or suggestions directly with the fork, rather than only in the original repository.

Feature request summary:

• Allow issues to be opened specifically for forks, even if issues are closed/disabled on the parent repository.
• (Optional) Provide a mechanism to import, mirror, or link relevant issues between upstream and forked repositories.

This would greatly improve communication and collaboration around active forks.

Guidelines

• I have read the above statement and can confirm my post is relevant to the GitHub feature areas Issues and/or Projects.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[alive-xd]

This would actually solve a real problem for many active open-source forks.

There are quite a few cases where a fork becomes:

• more actively maintained
• more feature-rich
• more compatible with newer ecosystems
  than the original upstream repository, yet issue management still remains tightly centered around the parent project.

A dedicated fork-aware issue workflow could improve collaboration significantly.

A few ideas that could make this even more useful:

• Allow maintainers of forks to optionally inherit or sync selected upstream issues
• Add labels such as “Fork-specific” or “Upstream-related”
• Provide issue relationship mapping between upstream and fork repositories
• Allow contributors to choose whether an issue targets the upstream project or a specific fork
• Add visibility indicators showing which forks are most active or have independent issue ecosystems

This could especially help:

• abandoned but widely forked projects
• ecosystem-specific forks
• compatibility-focused forks
• security-maintained forks
• long-term community-maintained variants

Right now, discussions and bug reports for active forks often become fragmented across repositories, external discussions, or duplicated issues. A more structured fork issue model could make collaboration much cleaner for both maintainers and contributors.

Interesting proposal overall.

[FahimAhamed0602]

Basically, GitHub's system assumes that a "fork" is just a temporary workspace. The idea was always: you fork a project, fix a bug, submit a pull request back to the main project, and you're done. Because of that, GitHub tries to funnel all the issue reporting back to the original parent repository.

But as we all know, that’s not always how it plays out. Sometimes the original creator abandons a project, and the community rallies around a specific fork to keep it alive. Or, somebody makes a fork specifically to adapt a tool for a different operating system. When that happens, the fork basically becomes its own independent project. Forcing people to log bugs in the original, inactive repository is confusing for users and a huge headache for the new maintainers.

The proposed solution hits the nail on the head by asking for two main things:

• Let forks have their own independent issue trackers. Even if the original parent repo has issues disabled, the active fork needs a place for its community to report bugs and suggest features.
• Make it easy to move issues around. If someone accidentally posts a bug in the old parent repo, or if an old issue is suddenly relevant to the new fork, there should be a simple way to mirror, link, or transfer it over so the context isn't lost.

This would be a massive quality-of-life improvement. It acknowledges that forks aren't just stepping stones anymore—sometimes they are the permanent successors to a project. Giving them the proper tools to manage their own communities would stop discussions from getting fragmented and make collaborating way smoother.

[jgchgjhbkj]

Yes, adding Issue to Forks helps those active project developers have platforms to solve problems and come up with new ideas and new features, especially if the original project is stopped for maintenance or read-only, which helps developers to better maintain their own projects