In 2016, we pursued a bi-directional bridge between GitHub and Phabricator. After GitHub, we could pursue bridging to JIRA, etc.
It works, somewhat, and is something we're likely to complete eventually. It was preempted by shifting priorities. (I think we had some internally mismatched expectations about the size of the project, too.) This was also in the era of "Dear GitHub" when a number of projects signed a letter raising concerns about GitHub's featureset. However, GitHub shipped some features (including `ISSUE_TEMPLATE.md` and `PULL_REQUEST_TEMPLATE.md`) which appeared to address these concerns.
Overall, this is currently a very low priority for us.
In these use cases, an object in a remote system which is substantially equivalent to an object in Phabricator is bridged into Phabricator. For example: GitHub Issues / Maniphest Tasks; GitHub Pull Requests / Differential Revisions; JIRA Tickets / Maniphest Tasks. The bridge is bi-directional.
Remote objects are initially pulled into Nuance, where either a human or a ruleset triages them. You can configure things so that, e.g., all GitHub issues immediately turn into bridged tasks, or so that issues are individually approved by a human gatekeeper.
This almost exclusively serves open source projects which want to use Phabricator an an "extension" for GitHub -- basically, get Phabricator's more powerful tools for project management, but not lower the barrier to entry for random contributors.
Currently I believe such projects are //largely// theoretical -- Babel was originally an exemplar, but they moved back to GitHub.