Phabricator/FAQ/da

Why migrating to Phabricator?
Se.

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#Scope. 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: T30 T23 T22 T21 T20. A comparison between Phabricator and Bugzilla is available.

Is Phabricator easy to use?
Phabricator is explicitly not designed for newbies. «Phabricator is primarily targeted at software professionals and other professionals with adjacent responsibilities (like project management and operations). Particularly, we assume users are proficient computer users and familiar with software development concepts.» 

How can I help?
See Phabricator#Get involved.

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/Migration Timeline.

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 (please see Bugzilla URLs and their redirects) and RT tickets to Phabricator. It is still to be evaluated whether we can also easily redirect Gerrit changesets. Obviously, documentation about Bug management/Bugzilla (see T206), 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?
By default, Phabricator offers Reports by User and by Project and Burnup Rate (logging in might be required). Burndown charts for projects are available via the custom Sprint extension (see T153 and T1322), to be superseded by Phragile in the future. Charts are currently not enabled.

See also the related task about metrics in general.

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?
No, this is a way that nobody has walked before. Focusing on like-minded projects: maybe Blender did, in late 2013 (but from SVN, Trac and Trello); however no detailed report available yet and it's at least one order of magnitude smaller than MediaWiki. They're now sharing some code.

Why can't I login using my GitHub or Google account?
Although Phabricator has authentication plugins for GitHub, Google, and other identity providers, we have decided not to use them. With two Wikimedia alternatives that cover virtually all Wikimedia contributors, more options are not really necessary. Besides, these services depend on proprietary third party sites, and they might raise concerns about privacy and commercial interests. For more details, see T16 - Support only WMF SUL and LDAP as authentication mechanisms.

How can I merge my account from Wikipedia or other Wikimedia wikis with my Phabricator account?
Use Phabricator's Linked Accounts and Authentication tool for that.

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

Why not improving our current tools
Phabricator is already an integrated suite, which means the different components are intended to be used together. It is written in PHP, and their maintainers are very proactive.


 * This encourages features like explicitly attaching tasks to code changes, mocks, etc.
 * Although we can write or improve integrations like Gerrit Notification Bot, Bugzilla (Perl), Gerrit (Java), or Scrumbugz (Python) will probably never be a seamlessly integrated 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
True, most users of FLOSS software have experience with Bugzilla if anything, because it's used by all the major players (Linux itself, Mozilla, RedHat, GNOME etc. etc.). However this is not necessarily true for all MediaWiki newcomers. Offering them one integrated platform is better than looking for a platform they already know.

phabricator.wikimedia.org
Phabricator.wikimedia.org (aka bugs.wikimedia.org) is Wikimedia's bug tracking and project management tool.

Bugzilla
See Phabricator/versus Bugzilla.

RT
See Phabricator/versus RT.

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