Those projects have a lot of history and often very specific needs and workflows. Github's bug tracker is really simplistic TBH, and lacks a lot of crucial yet

Those projects have a lot of history and often very specific needs and workflows. Github's bug tracker is really simplistic TBH, and lacks a lot of crucial yet basic functionality, such as custom fields, issue dependencies, etc that are really, really useful if you're working on a large project, and they're very useful to the maintainers in particular. You can sort of get around a small part of it with issue templates but it doesn't really fix the root problems (e.g. it can't offer this metadata as part of the API if you script against it), especially if you ever need to extend or integrate your issue tracker elsewhere. Also, maybe I'm reading part of your suggestion incorrectly, but you really only want one canonical issue tracker. I've seen some people use GH repositories as issues-only repos for off-site code, which is OK for public accessibility, if it's the only one. But multiple places where bugs can be reported and multiple trackers, etc generally take a substantial amount of time and effort to maintain for the developers. It's already hard enough for most teams to keep on top of whatever issue tracker they have already, having to wedge two tools together just makes it worse... And also... Personally, Github is nice and all, but saying "Everyone should always go out of their way to use it so my life of reporting bugs can be that much easier, think about it" seems a bit self centered and short sighted, to be honest. Having a code mirror on GH is always pretty good practice though, IMO, and quite easy to configure at least.