Phabricator/FAQ

Why?
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?
- this welcomes answering by individuals who have already worked and maintained a Phabricator instance.

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

 * related upstream ticket

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

Does Phabricator provide boards per project and/or iteration?
See e.g. http://fab.wmflabs.org/project/board/3/ which is still being under development. Related upstream tickets: https://secure.phabricator.com/project/board/773/ and https://secure.phabricator.com/T1344 and https://secure.phabricator.com/T2575

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