I think the Github issue tracker would be a very useful addition to the workflow. However I don't think there should be more than one venue for any one class of issue, and some types are probably better handled here on meta.
Here's my idea:
1. Enable the issue tracker, but disable blank issues and require picking from an issue template.
1. [Configure the new issue](https://help.github.com/en/github/building-a-strong-community/configuring-issue-templates-for-your-repository#configuring-the-template-chooser) wizard with prominent links back here to meta for types of issues that should be redirected here.
- Anything site policy or community related (e.g. "Add downvotes" or "Add a site for Fuzzy Bears").
- All user experience feature requests. ("Add tag descriptions")
1. Include explicit types and matching templates for the types of bugs that should be tracked there.
- Security bugs ("XSS in ...")
- Code style issues ("Change PHP code style to ...")
- Deployment / workflow issues ("Remove NPM module source from repo")
- Technical feature requests ("Add API method for...")
- Other feature requests _only having been vetted on meta_, as cross link to a met post ("Implement feature discussed in meta post X")
A major thing that the issue tracker will do that meta posts here will not is collate commits with the issues they are related to. This makes it easier to collaborate as developers, track progress, discuss technical details, do code reviews, etc. It will also provide a home for things that would otherwise be noise on this Q&A site as they are simply not relevant or interesting to 95% of the intended audience of the actual site.
Note I'm happy to actually set this up but I'd like to see consensus or approval here first...
> **Update 16 Jan, 2020** - The [TA GitHub issue tracker](https://github.com/topanswers/topanswers/issues) is now open.
Yes to this.
I came looking for this question as I noticed the Issues tab wasn't available on GitHub and would have asked for it to be enabled if I didn't find this question.
One of the benefits of using github issues is that potential contributors could just pick an issue if it's not in progress yet and create a pull request with a potential fix. (Although with the speed issues get fixed on this site it could be hard finding an issue to work on)
I know next to nothing about how GitHub issue trackers work, but based on what you have said here, it sounds like the way forward unless someone else has a sensible objection.
Initially at least we can continue to work on issues raised directly in comments here, but it would seem to make sense for the devs to raise the issue on GitHub ourselves with a link to the comment here when that happens.
> Note I'm happy to actually set this up…
Wonderful, it's great to have the extra expertise in areas we are weak, thank you.
> …but I'd like to see consensus or approval here first...
There is no particular rush so please wait until you feel any discussion here has run its course.
I'll add a third voice of agreement. Github issue tracking is a key part of workflow on Github. You're likely to get plenty of developers happy to create tickets for bugs/features and you can use that to track future development and request/accept help for the site.