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.

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

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.