Phabricator/FAQ

Why migrating to Phabricator?
See Phabricator.

Which parts of the infrastructure will get migrated?
The main focus is on Bugzilla, Gerrit, Trello, Mingle, RT (but not necessarily limited to them). Also see Project management tools/Review. Except for Phabricator's wiki functionality which would be disabled, we would like to migrate fully to Phabricator instead of piecemeal.

Is there a list of known deficiencies of / known issues with Phabricator?
Testers have reported some of the regressions and missing functionalities that users will experience after the migration. Some of them are listed on top of the following tickets:.

How can I help?
See Phabricator.

What is the current amount of work maintaining Bugzilla/Gerrit/Mingle/Trello sync tools?
Bingle and Bugello synchronize some aspects of tickets between Bugzilla and Mingle/Trello, but functionality is limited and ticket statuses between tools can easily get out of sync (also see list of open Bingle issues). Arthur should be able to elaborate on the amount of maintenance work required. Gerrit's hooks-bugzilla plugin does not require maintenance but has limitations (1,2) which are not easy to solve.

How would the migration happen?
Bugzilla/RT/Gerrit tickets, projects, user accounts, patchsets, access settings, etc. would have to be moved into Phabricator. (related upstream ticket). The switching costs are not clear yet; Your help is welcome to evaluate them. A clear cut for at least one tool (Bugzilla) seems preferable in order to not continue running all to-be-replaced systems plus yet another one (Phabricator).

When would the migration happen?
See Phabricator.

What would that mean for me?
At some point current infrastructure tools (see above) would be replaced by Phabricator. Phabricator has a different user interface and some changes in workflow, compared to the current setup. In the long run, things will get less complicated because everything is in one tool; there will be more transparency and efficiency because discussions are more centralized and in one tool instead of several tools.

As different development teams use different tools with different needs (reporters, developers, product managers, scrum masters, ...), you want to play with the Labs instance of Phabricator to see if it fits your needs. See section "How can I help?".

Will external links/URLs break?
We will try to minimize broken links by redirecting Bugzilla and RT tickets to Phabricator. It is still to be evaluated whether we can also easily redirect Gerrit changesets. Obviously, documentation about Bugzilla, Gerrit or RT will need updating.

How flexible is Phabricator when restricting access to certain tickets, or tickets in certain products (e.g. "Security")?

 * related task

Does Phabricator provide statistics, metrics, charts?
Phabricator offers Reports by User and by Project, Burnup Rate and Charts (logging in required).

See also the related task.

Does any other FLOSS project use Phabricator?
FLOSS projects using Phabricator include LLVM, Blender, and Phabricator itself.

There is also a list of projects on English Wikipedia but most are proprietary and/or small. Facebook's install is very large.

Did anyone else migrate to Phabricator as we would?
Focusing on like-minded projects: maybe Blender, in late 2013 (but from SVN). No detailed report available yet and it's at least one order of magnitude smaller than MediaWiki.

Ending up with one more tool
Having fewer tools is the whole point of this exercise. The replacement of Bugzilla and Gerrit with Phabricator is an essential requirement of this project. The teams using Trello and Mingle understand that relying in these commercial services is not a long-term solution.

Lack of a detailed plan
The current working plan is good enough to provide a realistic vision supported by the community. The WMF needs an RfC resolution in order to allocate the resources needed to elaborate a detailed plan.

Why not improving our current tools
Phabricator offers a very good basis today, it is written in PHP, and their maintainers are very proactive. Bringing Bugzilla (Perl), Gerrit (Java), or Scrumbugz (Python) to Phabricator's level would require a lot more work, even if their maintainers would agree with such plan. Also, Phabricator is an integrated suite, which means the different components are intended to be used together. This encourages features like explicitly attaching tasks to code changes, mocks, etc. Although we can write or improve integrations like Gerrit Notification Bot, they will probably never be as seamless as a suite.

Some projects should test first
Yes, this is also our recommendation for the migration from Gerrit to Phabricator. About the migration from Bugzilla to Phabricator, it needs to be done at once because we cannot do a full migration of data with two moving targets.

Various UI issues
We can customize the CSS of our instance for more appropriate font sizes, colors, etc. Upstream has already fixed some of the problems reported.

Requiring arc
Arc checks new patches for basic mistakes before uploading them for review. This is useful for the majority of contributors and for the project. The occasional contributor can upload a patch directly via the Phabricator Web UI.

Phabricator is unfamiliar for most newcomers
New contributors are not necessarily familiar with Bugzilla and Gerrit either. Offering them one integrated platform is better.

Bugzilla
See Phabricator/versus_Bugzilla.

Is Phabricator flexible enough to allow different teams to define their own workflows and ways of organizing sprints/tasks/stories/etc?

 * related task - this welcomes answering by individuals who have already worked and maintained a Phabricator instance.

Yes, at least to some degree. For example, different projects can define their own columns/swim lanes on workboards with "Add Column".

Does Phabricator provide boards per project and/or iteration?
See e.g. the Wikimedia Phabricator board. Related tasks: Identify features Trello users would miss and Identify features Mingle users would miss

Gerrit
=== Gerrit - Phabricator is not at all opinionated about how to structure one's history. Gerrit forces us to rebase and very cleanly package these neat little changes together. Has this been considered? ===