Phabricator/FAQ

Why?

 * The volume and complexity of our software projects keeps increasing; MediaWiki and Bugzilla fall short for project management.
 * WMF teams are increasingly using Mingle and Trello, 3rd party commercial services that are alien to the Wikimedia community and principles. This is creating a divide. Wikimedia Germany is trying Scrumbugz, a one-man OSS project barely maintained.
 * Overlap, duplication, and actions falling between the cracks increase.
 * To mitigate this problem, we have created more tools that we need to maintain.
 * Contributing to Bugzilla (Perl) and Gerrit (Java) is complex for us (PHP).
 * The current setup brings overhead and annoyance to key developers:
 * Senior developers having to use heavily Gerrit, Bugzilla, and Mingle/Trello.
 * New contributors, most of them arriving with GitHub-like expectations.

See Project management tools/Review.

Which parts of the infrastructure would 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:. For Bugzilla users, personal tags and votes cannot be transfered as Phabricator offers no similar concepts, and URLs for saved searches in Bugzilla will not work anymore as Phabricator does not offer passing URL parameters in a similar way to Bugzilla.

How can I help?
Try out the Labs instance of Phabricator and help identify which of the features we need is missing. If you find one, create a task in the Phabricator test instance that we're using to prepare for the possible migration: If you are a developer you could also give Phabricator's code a try; Phabricator is written in PHP like MediaWiki.
 * Add a Bugzilla feature that's missing from Phabricator
 * Add a Gerrit feature that's missing
 * Add a Trello feature that's missing
 * Add a Mingle feature that's missing
 * Add a RT feature that's missing
 * Add a Scrumbugz feature that's missing
 * Add a feature that's generally missing

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?
There is no hard schedule yet but we're talking months rather than years. We are still defining missing functionality in Phabricator so the timeline can only be defined once we know which functionality is blocking us and how the missing functionality will be written. The same goes for migrating data.

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.

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".

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 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 - 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? ==

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.