Phabricator/Plan

This plan to migrate our developer infrastructure to Phabricator consolidates the feedback received at Requests for comment/Phabricator, http://fab.wmflabs.org/project/view/14/, and other sources.

Summary
The result of the Phabricator RfC is favorable to move to this platform and replace gitblit, Gerrit, Jenkins, Bugzilla, RT, Trello, and Mingle. A first phase will focus on migrating all the Bugzilla data to Phabricator, and merge the project management work being done in Trello and Mingle. A second phase —that could be worked in parallel— will focus on substituting Gerrit for code review. There is also a possibility to deprecate Jenkins as a continuous integration tool, but this option is out of scope for now. A few blockers have been identified in these areas, and we will collaborate with the Phabricator community to fix them.

The calendar of the migration is conditioned by the resolution of these blockers. The current assumption is that Phabricator will deprecate Bugzilla, Trello, and Mingle first. Gerrit will follow after a period of transition.

The Engineering Platform team at the Wikimedia Foundation will lead this project allocating the resources necessary to define a detailed plan, proceed with the migration, and maintain the new infrastructure.

General

 * Users log in to Phabricator with their Wikimedia credentials.
 * Unified search powered by ElasticSearch.
 * IRC bots ported to Phabricator.

Task / bug management

 * Possibility to remove and delete comments.
 * All tasks under a private project (e.g. Security) must be private.
 * Interacting with external (non-Phabricator) users via email.
 * Migration of all Bugzilla and RT  data, leaving automatic redirects.
 * Gerrit plugin to notify back to Phabricator during the transition of code review tools.
 * Flexibility for teams to move from Trello, Mingle, and Gerrit within a window of deprecation.

For an analysis between Bugzilla and Phabricator, see Requests for comment/Phabricator/versus Bugzilla.

Code review

 * Pre-commit linting checks tailored to MediaWiki QA criteria.
 * The code review process in Differential/Audit needs to be adapted to our needs.
 * Build a binding between Phabricator and Zuul (if Phabricator's replacement for Jenkins is not ready).

Ending up with one more tool
Having less 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.

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. Most of them come with GitHub-like expectations anyway. Offering them one integrated platform is better.