Requests for comment/Phabricator

Participate in the first round of feedback by April 27

Problem
The Wikimedia technical community is currently using plenty of different tools for tracking bugs / product management / project management / todo lists. Some are open-source and others are proprietary, some are self-hosted and others are hosted by third parties, and all in all the multitude of tools and channels makes it difficult for both staff and volunteers to keep track of what's happening. They also all have their own limitations, and the multitude of scattered tools involved in the development chain is cumbersome both for current and prospective contributors. Members of the development and user communities have expressed frustration due to the current state and wish to consolidate the development toolchain.

See the full email thread for more background.

Background
This is what has been done so far: The goal of this RfC is to come to an agreement as a community on a smaller set of tools that teams would agree upon, which would make collaboration and maintenance easier. Ideally, this would also be an opportunity to use tools that are better aligned with the values of our movement, and better integrated with each other.
 * People have shared their needs and workflows.
 * Andre and Guillaume have summarized all of that into consolidated requirements.
 * Andre and Guillaume have set up a list of options to solve our problem, based on what was mentioned during preliminary discussions.
 * People have discussed the options and eliminated some of them in preparation for the RfC.
 * Besides the wiki, communication has happened mainly on the teampractices list, with updates also sent to wikitech-l.
 * We're now drafting this RfC and welcoming edits on both the form and the content.

Proposal: Move to Phabricator
This proposal consists of replacing several of our tools by one consolidated tool. Phabricator will replace gitblit, Gerrit, Jenkins, Bugzilla, RT, Trello and Mingle. This means you'll only need one account for everything, and all tasks / bugs / commits / screenshots will be cross-referenced automatically. Development teams will be free to use other tools (like Trello, Mingle, etc.) but Phabricator will be the one supported by the WMF.

You can test Phabricator in Labs. This is an actual test instance so don't be afraid to break things.

If this proposal fails to gather agreement, we will keep the status quo. The status quo is somewhat working at the moment, so if there isn't a better alternative we can decide to keep what we have now and reevaluate every year. We may want to consider consolidating our project management tools later into Scrumbugz (a tool that works on top of Bugzilla) but that will be a separate discussion.

You're welcome to contribute to the developing FAQ and browse the Wikimedia Phabricator project in our test instance, which we're using to identify missing features and plan the possible migration.

In favor of Phabricator

 * But migration of existing content (including closed bugs, etc.) is critical. Jdforrester (WMF) (talk) 00:24, 15 April 2014 (UTC)
 * --JEissfeldt (WMF) (talk) 01:06, 15 April 2014 (UTC) agree both with the proposal and the critical content point made by James
 * +1 to what James said. BZ data must be migrated. ^demon[omg plz] 16:40, 15 April 2014 (UTC)
 * Support as long as teams can still user third party tools like Trello as necessary Tfinc (talk) 00:20, 17 April 2014 (UTC)
 * The idea of having developers, designers, product managers, and just any volunteer using one tool with their Wikimedia credentials is worth fighting for. The migration will be complex, but we are planning for it. Phabricator is coded in PHP, a language that MediaWiki developers are familiar with, and the upstream project takes feedback and patches.--Qgil (talk) 15:50, 17 April 2014 (UTC)
 * I imagine there will be a lot of "ZOMG my favorite feature of X isn't here" but I think having issues and code review and planning all in one pile would be worth the pain of learning a new set of tools. BDavis (WMF) (talk) 17:12, 17 April 2014 (UTC)
 * I think it will be worth the effort. Grunny  ( talk ) 18:03, 17 April 2014 (UTC)
 * While I feel the current tools meet the needs (AFAIK), Phabricator's oneness seems to be much better with one account for every service as opposed to every account for every service. What James said it pretty much critical with this. John F. Lewis (talk) 17:33, 18 April 2014 (UTC)
 * I like the fast diff-view in Phabricator (diffs of huge files are almost impossible to view in gerrit for me and I do not want to view them in a custom diff viewer every time; with Opera, I struggle in gerrit anyway), the fact that it is all-in-one and most important to me that it is possible to create profiles so I can hopefully see to whom I am talking. I think it's worth migrating, although the terminology is fundamentally different. -- Rillke (talk) 11:25, 20 April 2014 (UTC)
 * per others. --Zhuyifei1999 (talk) 12:16, 20 April 2014 (UTC)
 * For volunteers like me, who spend only a few hours during their spare time on Mediawiki development, it takes a lot of time to get along with all the tools. Furthermore it's sometimes strange that some information like RT or ORTS is hidden. (How do I sign with VE?)--Physikerwelt (talk) 12:45, 20 April 2014 (UTC)
 * Strongly in favor. Phabricator is a pleasure to use. It strikes me as having been designed and architected with awareness of the pain-points of collaborative software development. The interface has a way of nudging you towards positive, constructive interactions. Its command-line tool, arc, is superb. The documentation is excellent. Upstream is very responsive. Features like Herald are innovative and useful. Let's do it. --Ori.livneh (talk) 19:51, 20 April 2014 (UTC)
 * In favour. This would be a nice change, and has much better functionality than the antiquated bugzilla. Ajraddatz (Talk) 21:56, 20 April 2014 (UTC)
 * Strongly in favour of this. Both Bugzilla and Gerrit aren't the best platform in my opinion, and Phabricator looks much better. I especially like Phabricator being based on PHP, since Bugzilla's Perl code was something I never liked. --GeorgeBarnick (talk) 21:59, 20 April 2014 (UTC)
 * I want one place, not three or four, to go document and discuss patches and the issues related to them. Steven Walling (WMF) &bull; talk   05:17, 21 April 2014 (UTC)
 * I will favor anything that lets me edit code online, instead of having to install specialized software, keeping a local copy of the code and hand-crafting patches. (I asume some form of local-repository development will remain possible.) — Edokter  ( talk ) — 11:26, 21 April 2014 (UTC)
 * I honestly do not care all that much for Phabricator's current UI, but I expect that it can be tweaked as we gain expertise with it (or that it can be made to be tweakable). The point for me is that the status quo is not tenable: having to use at least six disjoint tools that barely interface with each other just to do day-to-day work is a guaranteed recipe to have things fall between the cracks.  It also means that even if we do end up having to hammer our workflow into the code, there is just the one tool to fiddle with.  &mdash; MPelletier (WMF) (talk) 12:52, 21 April 2014 (UTC)
 * Strong support per Ori and Steven. Maryana (WMF) (talk) 17:01, 21 April 2014 (UTC)
 * Folks commenting in the "No" column should recognize that tools like Trello and Mingle haven't made it into the WMF workflow for whimsical reasons; Bugzilla simply lacks an adequate project management workflow. In the absence of better PM tools, we'll have a fragmentation of information flows which leads to its own inefficiencies. Tools like Scrumbugz seek to address this, but it's in the context of an aging, rigid codebase. Phabricator is built to support modern development practices and looks very promising from everything I've seen so far (proliferation of silly proper noun names for different functions notwithstanding). I think an incremental migration with checkpoints on real-world issues is the way to go.--Eloquence (talk) 17:10, 21 April 2014 (UTC)
 * Well I'm hugely biases since I was advocating Phabricator when it was a decision between that and Gerrit. (Having said that, the reasons others gave for not switching were very viable at the time only to be mitigated by Phabricator's continued upward trajectory.) I caution people during the migration for an expectation of a feature-for-feature parity improvement is not in the cards, but on balance the rewards outweigh the loses, and this has been the case for many PHP-based software endeavors both closed and open-source as evidenced at how low the churn has been away from using Phabricator. Tychay (talk) 20:31, 21 April 2014 (UTC)
 * (Wanted to put this below, but I couldn't figure a good place in the other options to put it). I have concerns about the logistics of this migration. I think it might be easiest to transfer via Gerrit, then PM tools (Trello, Mingle, etc), then Bugzilla. The first requires just alignment on developers and actually removes some unnecessary overhead. The second should be staggered on a project-by-project basis over a longer duration as the positives outweigh the negatives (as the teams would have to migrate their existing entries or had specific reasons/features that caused them to use a certain tool). The third probably last as it involves the largest institutional inertia and affected people, however the full benefit won't be seen until Bugzilla is integrated. Not sure if it can be staggered or what the transition looks like, but I do thing while it should be handled right, some compromise on the loss of a couple of data fields should be acceptable (a lot of metadata in Bugzilla is useless/archaeic). Tychay (talk) 20:32, 21 April 2014 (UTC)
 * Strong support for everything in one place. MGalloway (WMF) (talk) 21:38, 21 April 2014 (UTC)
 * Support for the unification of development in a single place, as someone who has primarily used these tools for looking at what's in development and for reporting bugs. Right now it's a huge pain to navigate Bugzilla and submit things, and the disconnect between Bugzilla and Gerrit is fairly annoying. --Nicereddy (talk) 21:43, 21 April 2014 (UTC)
 * Cannot. Agree. More. MGalloway (WMF) (talk) 23:30, 21 April 2014 (UTC)
 * Support - Phabricator has come a long way in the past couple of years. What looks awfully promising about it is that they seem to have a coherent vision for providing tools that make development teams productive, and a focus on important things that most tools in this space neglect (user interface, performance, and a sense of humor).  From all outward indications, the upstream will be a joy to work with, and the tool is in a programming langauge (PHP) that we have a lot of familiarity with. The migration promises to be a miserable experience (all migrations of this scale are...no matter how great the tool), but this is the first toolset I've seen that looks likely to be worth the pain. -- RobLa-WMF (talk) 00:25, 22 April 2014 (UTC)
 * This would be awesome. The current mess of tools (especially bugzilla vs trello vs mingle) is quite frustrating for finding whether something is already noted, and has made me not want to enter bugs for myself (especially in Bugzilla with its irritating login requirements). SUL integration would be great if possible. Jay8g (talk) 01:27, 22 April 2014 (UTC)
 * Strong support: per others, it's always a good idea to have one place for all tasks. Chmarkine (talk) 03:44, 22 April 2014 (UTC)
 * Support - I haven't used dev tools yet, it would be easier to have 1 place to go and start Aprillion (talk) 12:17, 22 April 2014 (UTC)
 * Support - having all tools in one place can only be a good thing. Jdlrobson (talk) 17:29, 22 April 2014 (UTC)
 * Support - Based on what I know so far, I support moving to Phabricator.  The top practical problem I face with the current solution is going back and forth between Trello and Bugzilla, but see below for secondary issues.  However, we do need to ensure we're not just adding another tool without replacing/removing anything.  This means at least turning off/redirecting/marking read-only Bugzilla and Gerrit.  The most realistic way to accomplish that is to do a complete migration of at least Bugzilla, ideally other issue tracking tools like Trello, Mingle, etc., and possibly others like Gerrit.  I've already seen some cool features in Phabricator (e.g. updateable mocks, drag-and-drop file uploading, simple embedding and linking and CCing (oddly, Trello does not allow you to CC other users).  It also should allow much tighter integration between Gerrit and Bugzilla (no more getting two Bugzilla emails after you upload a patch to Gerrit, and perhaps auto-fixing bugs based on a commit message tag).  Being written in PHP is definitely helpful.  It will not magically mean every MediaWiki PHP dev works on Phabricator, but it will hopefully encourage creating a critical mass of collaboration with upstream.  I also strongly support using open source infrastructure, so this is a step in the right direction on that front.  There will definitely be switching costs and issues, but so far it looks like it will be worth it. Superm401 - Talk 21:38, 22 April 2014 (UTC)
 * Strong Support - There are issues with Phabricator, like any single tool that would be an option (there is no unicorn that covers all use-cases efficiently), but I think it's biggest strength is Evan P and the Phabricator community. His responses to our suggestions/requests have been amazing. And it isn't just us. Other organizations that have migrated to Phabricator have had similar experiences; someone reports an issue that Phab has with their internal work flow, a week later Even P comes back with a fix, before the org (devianArt in this case) could even start working on it. Evan P and the rest of the Phab community is awesome and are an upstream that I want to work with more than pretty much any other. And in the long term, the relationship you have with your upstream is tantamount to pretty much anything else. Greg (WMF) (talk) 16:04, 23 April 2014 (UTC)
 * Support, even though I have not used other tools (yet) than Bugzilla, but it's always better to have everything at the same place (if possible). --Stryn (talk) 17:58, 23 April 2014 (UTC)
 * I have been playing with it for a while and I say Let's go get this thing deployed on our servers Petrb (talk) 07:36, 24 April 2014 (UTC)
 * Support - Yes please - F ASTILY  (TALK)  00:13, 25 April 2014 (UTC)

In favor of keeping our current tools

 * I would like to see a rough roadmap of the migration and what task force is going to be allocated to it. I looked a bit around and could not find how we are going to handle the transition. I dont mind changing tools, but I wish we handle it as a proper project or we risk spending a couple years doing the migration on a best effort basis. So until we have a migration plan, I will remain suspicious. Antoine &#34;hashar&#34; Musso (talk) 21:08, 17 April 2014 (UTC)
 * Everything is being tracked in our test instance itself: how to migrate everything, what features are currently missing, how to configure it for our needs, even the resource planning. Is this what you were looking for? It's still incomplete, but resources for a migration task force won't be allocated unless this RFC shows explicit support from the technical community. guillom 14:01, 18 April 2014 (UTC)
 * Meh, I hate changing systems which (apparently) work. Though, I don't feel strongly on this issue. Vogone    talk   17:37, 18 April 2014 (UTC)
 * "The Wikimedia technical community is currently using plenty of different tools for tracking bugs / product management / project management / todo lists" so you want to add one more? But if you show me the way how to force all people to move to the new system I may support. (And no it's not disabling old tools which would just mean loosing usefull stuff of users who would not give up (or wont know how to move) even under such conditions as it's with TS -> Labs move in some way happened) --Base (talk) 14:04, 19 April 2014 (UTC)
 * It's not "adding one more" as we are after replacing systems. Old systems become read-only or disabled, if that's how you interpret "forcing". --AKlapper (WMF) (talk) 07:07, 20 April 2014 (UTC)
 * There is some precedent for "replacing" over "adding" that might mitigate some of the pessism: In 2012, Subversion was replaced with Git/Gerrit. On a per-project level, many teams have migrated between multiple project management tools—bulletin board, Wiki, Bugzilla, Trello. Mingle, and Google Doc—never using more than one concurrently for more than 2 weeks during a transition. Also, the major pain point in PM tools cited is poor integration of those tools with Git and Bugzilla (or general crumminess of management capabilities in the case of Bugzilla), this is especially bad for those who have to navigate multiple tools in the course of their work (notably tech leads, scrum master, and product managers). The multiplicity/redundancy is also the source of much friction because of the lack of responsiveness due people not being on a tool (for instance the devs working from Gerrit, while the bug was in Bugzilla) Tychay (talk) 20:40, 21 April 2014 (UTC)
 * It's probably worth integrating MediaWiki with Bugzilla more. Bugzilla has an API. If WMF could also work on making Bugzilla more mobile-friendly and "user-friendly", I'm sure everyone would appreciate it. Gryllida 07:22, 20 April 2014 (UTC)
 * We don't use MediaWiki for a project management and issue-tracker, because that's not what it is for. For years, we did code review on-wiki (see examples) and it was a nightmare to work with. A wiki is a great tool for documenting things. It's not a code review tool or issue tracker. Steven Walling (WMF) &bull; talk   05:23, 21 April 2014 (UTC)
 * 1) I agree with Base, Gryllida. 2) I think Mingle, Trello should be migrated into Bugzilla, not creating new one. &mdash;   Revicomplaint?  07:28, 20 April 2014 (UTC)
 * I don't think any change is required at the moment. Bugzilla, Gerrit, etc. are quite adequate for our current needs. I have never had any problems or concerns with them. The integration between the tools may be a bit hackish at times, but to me, the fact that the current systems are in widespread use and perhaps already familiar to newly-arriving developers is more important. What's more, I don't like Phabricator. It's a rather intimidating web app which looks like it could have a steep learning curve, and could undo some of the good work of people like Quim in attracting new developers to the WMF's projects. This, that and the other (talk) 09:58, 20 April 2014 (UTC)
 * For what is worth, one of the reasons why I support Phabricator is to offer to new contributors a single tool with Wikimedia SUL that fits in the expectations of regular GitHub users. Currently it is painful to send newcomers to Bugzilla and Gerrit in addition to mediawiki.org, while having teams more and more invested in Trello/Mingle (because Bugzilla won't handle the PM work) is a pain for everybody, newcomers included.--Qgil (talk) 23:50, 21 April 2014 (UTC)
 * Personally, I find having to create accounts for multiple different services with different workflows and having to try to figure out how to use every single one separately is far more difficult than if we were to introduce them to a single service which contains all the development work and bug reports in a single location. That, plus the interface is far better looking and easier to use than Bugzilla (keep in mind that you're used to Bugzilla, so if you can navigate it easily that's probably why). --Nicereddy (talk) 01:50, 22 April 2014 (UTC)
 * I'm only commenting on Bugzilla (and slightly RT) here, As i've had limited to no use with the other tools, I don't think think moving will solve any of the "real" issues we currently have, The issue with multiple tools is more due to staffing and cultural issues allowing it to be come so spread out, Whilst some of these tools do have their uses, Some should also be dropped or restricted to very specific use cases, For example RT was introduced because of the security & permissions point of view when needing to deal with outside individuals and a few other small cases it has since basically evolved into a private ops bugtracker with a lot of information that could probably already be in BZ. Also another issue is the maturity and team backing Phab, For example when gerrit was chosen compared to custom writing something like we did with SVN (E:CodeReview) it was decided against because we would land with the same issues about having to maintain the code. Peachey88 (talk) 08:52, 21 April 2014 (UTC)
 * , can you explain your last comment? Phabricator is a young project, but they have a significant community and user base that keep gaining momentum, see an Ohloh comparison with Bugzilla and Gerrit, and Phabricator.--Qgil (talk) 23:40, 22 April 2014 (UTC)
 * I think the overhead of migrating and learning the new interface is not worth the effort. Bugzilla works fine for most of what we do. The interface also looks a bit scary to me, although Bugzilla's interface is not completely obvious either. Bugzilla is also used for more free software projects and thus has been proven to work in practice. Basically echoing Revi and TTO's concerns as well. As Multichill mentioned, we don't want to add another competing standard for teams to choose from (Trello, Mingle, ...) πr2 (t • c) 21:43, 22 April 2014 (UTC)
 * This isn't just about replacing Bugzilla. Phabricator lets us consolidate a host of disparate tools (Bugzilla, Gerrit, git.wikimedia.org, others) in to one view of work on MediaWiki. What's more: Bugzilla is clearly not working for Wikimedia Foundation developers, who are doing a large bulk of the work that is tracked in Bugzilla. This is obviously the case when you consider that nearly all teams are using a secondary project management tool on top of Bugzilla, and may even disregard Bugzilla as the canonical list of bugs/issues with a component, because it's such a mess. This doesn't even begin to touch how unfriendly Bugzilla is to non-developers who we want to report issues... Steven Walling (WMF) &bull; talk   21:09, 23 April 2014 (UTC)
 * As long as we do not force people to switch to only Phabricator (and forcing would be bad), we'll not reach the desired consolidation of tools, but just add another tool to the set of tools the different teams use. For me, bugzilla and gerrit both have their issues, but they get the job done sufficiently well. Of the many open bugs in our Phabricator, Phabricator's requirement to use "arc" instead of plain git to fetch/push commits bothers me the most. --QChris (talk) 22:52, 23 April 2014 (UTC)
 * , reply from maintainer epriestley at #phabricator: "everything works fine without arc | you get more features and stuff with it, people mostly seem pretty happy about them | but it's absolutely not required | If some of the documentation was misleading in that respect, let me know and I'll fix it."--Qgil (talk) 21:41, 24 April 2014 (UTC)
 * , I followed up with epriestly. Without arc, you're expected to 'git diff' and copy/paste that in the web UI. That's not a "works fine" for me :-) First, it's really, really inconvenient. And then you'll loose commit metadata that way. Like committer, author, and most important: parent of a commit. But Phabricator does not value this kind of metadata much anyways. For example "arc patch/land" does not honor them either (see upstream ticket T4333). Also, merging a patch is not possible nicely without arc. You have to merge in your repo locally, and then push directly to the branch to bypass review. --QChris (talk) 00:04, 25 April 2014 (UTC)

Basically neutral

 * Personally, with the current test installation (microscopic fonts, functions hidden behind unlabeled icons, other icons not clickable, tendency to feature bloat, some features like voting missing, other features like Gerrit and GitHub integration not testable at the moment) I can't decide if it's worth my time. It could be the greatest thing on earth or turn into a bottomless pit. A project that starts with "We can't manage 12 tools! We need to do something!" could also end with "Now we have 13 tools." --Thiemo Mättig (WMDE) 14:14, 17 April 2014 (UTC)
 * I am in favor of trying out Phabricator for a few select projects so we get a better idea of what moving over all projects would mean --Jeroen De Dauw (talk) 19:09, 17 April 2014 (UTC)
 * I gave it a try, very stressful so far (I hope not to touch it for a few weeks now, I'll need some discipline). Will need huge amounts of help to figure out, if we really want to kill bugzilla: I expect at least a couple hundreds more bugs need to be filed and triaged, please help with testing. My results so far are visible at (only partly and only after login, try the search). --Nemo 19:10, 19 April 2014 (UTC)
 * I'm not convinced that the time invested in changing our code review tool (again) is worth the expected benefits. Legoktm (talk) 07:40, 20 April 2014 (UTC)
 * IM kinda HO we gotta change default avatar on our demo, it's unacceptable for me to use an NFC image as it... --Liuxinyu970226 (talk) 10:15, 20 April 2014 (UTC)
 * I share Legoktm's and Thiemo's concerns, but I also see the problem with our current (overwhelmingly) large tool stack. The most important thing over here is to really make the cut on the n tools we have atm and to not have n+1 tools after. - Hoo man (talk) 11:45, 20 April 2014 (UTC)
 * I'm basically neutral but I couldn't agree more with Antoine: If we're going to change, it should be done with a proper project. When I talk about a project, I'm talking about a project as defined here. Clear goal, clear time path, clear budget etc. I'm a bit afraid this is going to happen. Multichill (talk) 15:23, 20 April 2014 (UTC)
 * I dont mind, I am not a developer. If you think you need it. Do it. But do it once. It take us some time, to get in touch with bugzilla. So we will need some time to get in touch with the new sw. (errr, where I have a singnature button in Visual Editor?) Juandev
 * A new system could be nice, I don't really care either way. But we want to make sure users will not be suddenly surprised by this.--Jasper Deng (talk) 00:18, 21 April 2014 (UTC)
 * I largely agree with Multichill, et al. Some specific team (whether that's a Wikimedia Foundation team or a Wikimedia chapter team or a coalition of volunteers) has to take charge of this and properly migrate the current suite of tools to Phabricator. This will be tedious and long and annoying. As long as whatever new tool is implemented has IRC feeds, I'm pretty neutral on the topic. I will say that in my limited interaction with Phabricator, it seems to go out of its way to be gimmicky and obnoxious. I'm wondering if that's a configurable mode. It might be nice to enable rotating cutesy submit buttons and "stickers" in a year or two, but for now, the transition will be difficult enough without Phabricator constantly dressed in a clown costume. --MZMcBride (talk) 00:31, 21 April 2014 (UTC)
 * The silly names have been turned off already - it's now in "serious business" mode (instead of "fun mode"). Discussion at http://fab.wmflabs.org/T119 –Quiddity (talk) 22:22, 21 April 2014 (UTC)
 * On the one hand, Phabricator is one unified system which will therefore likely reduce the work we need to keep so many separate systems going. On the other hand, it's unclear to me what cost the migration will have, and how much time it will take learning a new system. Without having more data to figure out whether the pluses overcome the minuses, I am basically neutral. --Dan Garry, Wikimedia Foundation (talk) 15:44, 21 April 2014 (UTC)
 * I now support this proposal, here is my former opinion: This discussion would be far more simple if we point out the biggest improvements and potential bigest issues that migration would do, so please fill up this list with that is in your mind. I am not really againsted Phabricator, but I really do like bugzilla, as that is one of best open source bug trackers and saying just "let's have 1 tool for everything" is not much of argument to me :) For this reason I created new section with pros cons. Petrb (talk) 16:48, 21 April 2014 (UTC)
 * Which tools are we actually talking about is it just bugzilla and gerrit that would be unified or is there more of them? Petrb (talk) 16:51, 21 April 2014 (UTC)
 * The other dimension is project management tools. This includes Mingle and Trello which are actively in use in the WMF, which would also be replaced by Phabricator. People at the WMF have written scripts to actively copy Bugzilla bugs into Mingle and Trello, but these scripts occasionally need maintenance. So, Bugzilla and Gerrit are the big ones most people know about, but there are others. --Dan Garry, Wikimedia Foundation (talk) 17:19, 21 April 2014 (UTC)
 * Most impressive part I found is that it allows regular users to create own repositories. This however needs to be enabled. Would this be enabled on production version of phabricator? I am not using our gerrit only because I have to wait weeks or months for repositories to be created and that suck. Primary reason I stick with github is this feature (being able to create new repo in 10 seconds) Petrb (talk) 09:20, 22 April 2014 (UTC)
 * I'm neutral to the debate of using Phabricator over Bugzilla and Gerrit. However for the management of Features (user stories) and their workflows using Agile Scrum methodology, I prefer Trello.  It is possible to adapt a Phabricator Workboard to suit product management, however I recommend creating a separate project for product Features so your Workboard does not get overrun with the sight of new bugs and subtasks.  One more reason I prefer Trello over Phabricator is this issue: http://fab.wmflabs.org/T195
 * Being Trello a proprietary service, and requiring users to register in a 3rd party server to participate, there is no way Trello (and Mingle) will fit in the Wikimedia context in the long term. They are ok-ish short term solutions because our teams didn't find better tools. T195 can be fixed customizing the CSS; community division and WMF teams planning elsewhere are much bigger problems.--Qgil (talk) 18:43, 22 April 2014 (UTC)
 * As an occasional tech, I am happy with Bugzilla, I don’t use Trello/Mingle/RT, and I "invested" time to learn Gerrit (and Git) more than one year after Gerrit was installed in production because I had no time before, so a bit sad if these leave. On the other side, I understand WMF developers want a more integrated tool for easier project management. Anyway, if Phabricator (or another tool) is used, please use it at least 5 years to let time to community members to learn it and become accustomed to. ~ Seb35 [^_^]  23:17, 22 April 2014 (UTC)

Pros (improvements)

 * Everything would be in one place
 * Single login for everything (Can we integrate Phabricator and SUL? That would be cool. See Pick an authentication provider.)
 * Better integration of subsystems like bug tracker, git etc
 * Single interface with no need to switch between differently looking, possibly confusing other interfaces of other instruments (like buzilla, gerrit etc).
 * Responsivity and communication will be improved (currently a lot of issues brought up in one tool are missed in the other. i.e. a bug in Bugzilla is not addressed because the PM is working on a management tool, even after addressed the bug is not closed after the patch is reviewed and committed in Gerrit, there is no evidence that work is being done in Bugzilla even though there may be a lot of activity in Git or the management tool regarding that specific bug).
 * Integrations between tools (e.g. Bugzilla to Mingle) is done ad-hoc and usually on a per-project basis because there is no return to scale to do this across others as they use different tools for certain key parts.
 * Prioritization in bugzilla has no roadmap burn-down to why it is or isn't being worked on by those involved in a project (ScrumBugz into Bugzilla would solve it, but only if projects move to it).
 * 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
 * Support for code auditing, with automatic notification based on rules and conditions
 * Written in PHP, so it's more easily extensible
 * Already a deep knowledge on PHP due to it being the language of MediaWiki expertise
 * Gerrit is in Java, Bugzilla is in Perl, most PM tools are closed-source and hosted on commercial sites with integration being their own unique APIs, neither has a large developer footprint in the community
 * Deep integration between Phabricator (issue tracking, project/task management, and commits) and Wiki becomes a real possibility again (something we lost when we moved away from CodeReview).
 * Mobile-friendly. Login from any mobile device and see what you can read and do. Now, open Bugzilla and Gerrit...
 * Tasks can be assigned to more than one project. Projects can be easily as if they were keywords. No more discussions about products / components taxonomy, no more fights to decide where a bug should be filed. See How to organize projects.
 * Respects privacy more. Bugzilla and Gerrit expose your email address. Phabricator does not.
 * Better developer tools, specifically Arc, the command line interface to Phabricator. This means we would no longer we dependent on git-review or hacking together our own tools.
 * Possibility to let users create their own repositories. See Enabling creation of repositories by regular users?

Cons (potential issues)

 * There will be a learning curve in switching to new software
 * See features Bugzilla users would miss in Phabricator
 * See features Trello users would miss in Phabricator
 * SPOF - if phabricator breaks, everything breaks and bug trackers should be highly available, how would you report a ticket that there is a problem with phabricator when it is a bug tracker on its own? There will be maintenances of phabricator and they will shut down everything. So impact of every maintenance / outage will be significantly higher than now.
 * Have all the issues with our previous evaluation with Git/Gerrit been addressed?