Wikimedia Release Engineering Team/Gerrit migration why

Background
In early 2014 the WMF undertook an analysis of tools to use for code-review, bug management, project management, and code hosting. The impetus of this analysis was the disconnected/disjointed environment for basic development/management process across multiple platforms (at the time: Bugzilla, Gerrit, Gitblit, Trello, and Mingle). The resulting analysis can be seen in this comparison of various options including Phabricator, Github, Scrumbugz, or "status quo" (iow: the disconnected multiple platforms).

A Request for Comments (RFC) was initiated in March of 2014 to propose the migration of all those tools to Phabricator. This RFC had a lively discussion in multiple forums (see threads on wikitech-l, teampractices list, and, of course, the RFC talk page). The RFC passed with support to begin with a migration to Bugzilla, and if that was successful, migrating code-review (Gerrit) as well.

See, for instance, the blog post announcing Phabricator used this sentence: "Initially, we’ll focus on bug tracking and project management, but we’re planning to also use it for code review once the features we need have been added." In fact, the title of the blog post is also "On our way to Phabricator" implying the journey has just begun.

Where we are now
The task/project management migration happened in November 2014, with migrations from Trello and Mingle completed for all teams since then (at their own pace).

The near future
The Wikimedia Foundation's Release Engineering Team (which maintains our project management and code review platforms) is preparing to continue along the plan of migrating code-review to Phabricator during the FY1516 Q2 and Q3 quarters (iow: from October '15 to March '16).

The general outline of steps along the way is:
 * 1) Deprecate Gitblit (ie: git.wikimedia.org) and host all repositories in Phabricator ("Diffusion")
 * 2) * This is in-progress already
 * 3) Migrate repositories that both 1) want to and 2) don't have CI requirements to code-review in Phabricator ("Differential")
 * 4) * This is in-progress already with pywikibot, and soon some WMF RelEng owned repositories
 * 5) * Doing this will give us real-world examples of code-review in Phabricator
 * 6) Setup our Continuous Integration/testing infrastructure to work with Phabricator code-review
 * 7) Share (via RFC?) our end-goal of how development and code-review will happen with Phabricator
 * 8) * informed by 2.
 * 9) If no surprises, migrate code-review from Gerrit to Phabricator and make Gerrit read-only (exact details tbd)

Pros and Cons of migrating to Phabricator
(partly taken from the RFC, partly new)

Pros

 * Everything would be in one place
 * This benefit can not be understated
 * Single login for everything (it uses your Wikimedia SUL account)
 * Built in integration of subsystems like bug tracker, code-review, etc
 * Single interface across subsystems (reduced cognitive load/confusion)
 * Integrates design and designers (via Pholio)
 * Conversations allowed to stay in one place (instead of spread across multiple platforms)
 * Reduce technical-debt maintained by our community by no longer maintaining a family of home-grown integration bots (see: grrrit-wm and potentially wikibugs2) and instead use/extend the Phabricator Bot.
 * Reducing the technical debt maintained by the WMF by:
 * Decommissioning Gerrit
 * Decommissioning Gitblit
 * Mobile-friendly
 * Login from any mobile device and see what you can read and do. Now, open Bugzilla or Gerrit...
 * Support for code auditing, with automatic notification based on rules and conditions
 * Faster reviewing of code (especially large diffs), and improved commit/review procedures
 * Multi-commit single-branch review support instead of the approach in Gerrit where each change is a single commit that is amended for each new patch set
 * Possibility to let users create their own repositories

Cons

 * Transition learning curve (inherent to any migration)
 * Can be partly addressed via trainings and documentation (which mostly already exists)
 * Single Point of Failure
 * Can be mitigated
 * No dedicated mobile app (unlike Trello)
 * It does have a mobile interface (better than Gerrit or Bugzilla)