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)

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)
 * 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)

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)
 * 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)
 * 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)

Pros (improvements)

 * Everything would be on one place (how is that actually better? :P)
 * Single login for everything (can we integrate phabricator and SUL?)
 * 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 many-branch approach of gerrit
 * Support for code auditing, with automatic notification based on rules and conditions
 * Written in PHP
 * 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 Subversion).

Cons (potential issues)

 * Personal preferences and bookmarks will be lost
 * A list of features that do not exist in Phabricator, but do in Bugzilla, is currently not available
 * There will be a learning curve in switching to new software
 * SPOF - if phabricator breaks, everything breaks and bug trackers should be that kind of software that leaves the ship as last, now if it was just a part of something bigger, not isolated on separate server, the chances for breakage / being DDOS target etc are higher. (citation needed)