Page MenuHomePhabricator

Nuance: As an External Bridge, to GitHub and other similar systems
Open, WishlistPublic

Description

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.

Event Timeline

epriestley renamed this task from Nuance: As an External Bridge to Nuance: As an External Bridge, to GitHub and other similar systems.May 21 2017, 4:12 PM
epriestley triaged this task as Wishlist priority.
epriestley updated the task description. (Show Details)
avivey added a subscriber: avivey.May 22 2017, 4:12 AM

Why is this Nuance and not Doorkeeper?

chad added a subscriber: chad.EditedMay 22 2017, 4:27 AM

GH Issues flow into Nuance and a human can decide whether to open it up as a Maniphest Task, similar to email. The end user can fully communicate an issue back to Phabricator without ever leaving their preferred source (email, Github, Twitter). Developers can stay in Phabricator and manage priorities, projects, workboards.

In T12739#224607, @chad wrote:

GH Issues flow into Nuance and a human can decide whether to open it up as a Maniphest Task, similar to email. The end user can fully communicate an issue back to Phabricator without ever leaving their preferred source (email, Github, Twitter). Developers can stay in Phabricator and manage priorities, projects, workboards.

That sounds great! User doesn't need to see Phabricator (which is awesome) and instead can use (lame) favoured communications chanel... That would REALLY help with my current workflow, especially e-mail one 😉

Why is this Nuance and not Doorkeeper?

To expand on the above, the actual sync stuff mostly is Doorkeeper. When a human (or robot) says "yeah, let's bring this into Phabricator", Nuance hands the external object to Doorkeeper to do the actual data wrangling.

If you configure Nuance as an auto-approve inbound queue things end up being like 95% Doorkeeper. Nuance is largely just providing a UI for making decisions about what Doorkeeper should do.

Ahh, makes sense now :)