Jump to content

Requests for comment/Phabricator

From mediawiki.org
Request for comment (RFC)
Phabricator
Component General
Creation date
Author(s) Andre Klapper, Guillaume Paumier
Document status accepted
Bugzilla was migrated to Phabricator 2014-11.

Problem

[edit]

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 for both current and prospective contributors. Members of the development and user communities have expressed frustration due to the current state of affairs and wish to consolidate the development toolchain.

See the full email thread for more background.

Background

[edit]

This is what has been done so far:

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

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.

Is Phabricator easy to use?

[edit]

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.» [1]

How can I help?

[edit]

See Phabricator#Get involved.

Proposal: Move to Phabricator

[edit]

This proposal consists of replacing several of our tools with 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

[edit]
  • But migration of existing content (including closed bugs, etc.) is critical. Jdforrester (WMF) (talk) 00:24, 15 April 2014 (UTC)[reply]
  • --JEissfeldt (WMF) (talk) 01:06, 15 April 2014 (UTC) agree both with the proposal and the critical content point made by James[reply]
  • +1 to what James said. BZ data must be migrated. ^demon[omg plz] 16:40, 15 April 2014 (UTC)[reply]
  • Support as long as teams can still user third party tools like Trello as necessary Tfinc (talk) 00:20, 17 April 2014 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • I think it will be worth the effort. Grunny (talk) 18:03, 17 April 2014 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • per others. --Zhuyifei1999 (talk) 12:16, 20 April 2014 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • I want one place, not three or four, to go document and discuss patches and the issues related to them. Steven Walling (WMF) • talk 05:17, 21 April 2014 (UTC)[reply]
  • 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)[reply]
  • 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. — MPelletier (WMF) (talk) 12:52, 21 April 2014 (UTC)[reply]
  • Strong support per Ori and Steven. Maryana (WMF) (talk) 17:01, 21 April 2014 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    (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)[reply]
  • Strong support for everything in one place. MGalloway (WMF) (talk) 21:38, 21 April 2014 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    • Speaking of the 'sense of humor,' maybe we could somehow import those funny quotes that users can optionally make Bugzilla put at the top of every page of that tool's search results while we're importing it whether we do this importing manually or automatically? — RandomDSdevel (talk) 21:45, 27 April 2014 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • Support: Me neither, really; I've filed bugs in Bugzilla, but it's a 'bit' of a pain to use since it's interface is so archaic. Phabricator sounds like a great tool to move all of our development stuff to, and I might just start helping out some once all of the dust settles (or maybe even before then; it all depends on whether I'm available or not due to the facts that I plan to start learning C++ pretty soon and that this might take up a lot of my time.) — RandomDSdevel (talk) 21:49, 27 April 2014 (UTC)[reply]
  • Support - having all tools in one place can only be a good thing. Jdlrobson (talk) 17:29, 22 April 2014 (UTC)[reply]
  • 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)[reply]
    Simple unified search is another benefit of having it all in one place. Superm401 - Talk 23:43, 28 April 2014 (UTC)`[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support - Yes please -FASTILY (TALK) 00:13, 25 April 2014 (UTC)[reply]
  • Support the pain is real! Copying issues between bugzilla and {team's Project Management tool}, the disjointed concurrent discussion in bugzilla|gerrit|{team's Project Management tool}, the mindless busywork of keeping the state of an issue up-to-date in all three tools, the redundant notifications that this busywork generates, ... A fourth area that Phabricator integrates is design mockups, an area where the MediaWiki community has never had a good tool. You can upload an image into Phabricator's pholio system and people can comment on it, see http://fab.wmflabs.org/M1/1/ . -- S Page (WMF) (talk) 19:36, 25 April 2014 (UTC)[reply]
  • Support - As someone considering getting into extension development/generally helping out in the next few months, learning to use one tool is much less intimidating than trying to figure out a workflow across five different sites. Phabricator, from my exploration of it, looks nice and intuitve for all the basics.-etesp (talk) 19:41, 25 April 2014 (UTC)[reply]
  • Yes. However, It should be possible to use Wikimedia/Wikitech account to log in to Phabricator, rather than having an independence system (currently you need to create a new account to Bugzilla). (In the future, I hope Wikitech can be added to all.dblist, so that users can use SUL account to log in WMFlabs, rather then create a new account: current account in Wikitech would be merged to SUL ones.)--GZWDer (talk) 12:21, 26 April 2014 (UTC)[reply]
  • Support - Moving to one integrated toolset seems like a dream come true. --Lydia Pintscher (WMDE) (talk) 17:41, 27 April 2014 (UTC)[reply]
  • I believe that a single integrated system is absolutely a good idea. The sheer number of tools being used simultaneously at present is bewildering (RT is involved somewhere as well?!). However the comments on display here lead me to feel that Phabricator appears to require a little more work before it's quite ready. I have two other concerns: firstly, there needs to be an assurance that after the change Bugzilla will be maintained in read-only mode forever; it has a decade's worth of incoming links that shouldn't be broken. Secondly, when Bugzilla bugs are imported, will their entire comment history be imported as well? I think that it should. The discussions associated with bugs are by far the most important aspect of the whole thing. If dealing with a bug in the new system requires having to scoot back to Bugzilla to pick up on all the context and/or previous decisions, that messes up the point of only having a single bugtracker. — Scott • talk 13:14, 27 April 2014 (UTC)[reply]
  • Support per above - it's better to have everything centralized in just one place. LlamaAl (talk) 19:08, 27 April 2014 (UTC)[reply]
  • Surely centralizing the tools will be a major improvement of the situation for new contributors and Wikimedia communities, getting rid of external project management tools will bring everyone back in the loop of WMF development, and the code review system can't possibly be worse than Gerrit. Shedding a single tear for Bugzilla, Matma Rex (talk) 20:25, 28 April 2014 (UTC)[reply]
  • I don't contribute code or reviews, but I do use Bugzilla, and if the transition can be smooth and almost lossless (I guess missing features might be available at some point?), I'm for it. --Elitre (WMF) (talk) 15:05, 29 April 2014 (UTC)[reply]
  • From the point of view of a non-technical user of Bugzilla, I would like to be able to track something from bug reporting to successful implementation without necessarily having to ask a question in a comment and await a reply. Presumably the integrated approach will make it possible for me to monitor progress on implementation without wasting my or other peoples' time on such requests for information. If such tracking will not be part of the new integrated system, then I suppose the tech folks will have more time to respond to my requests for information on progress. DCDuring (talk) 15:25, 30 April 2014 (UTC)[reply]
    • As a reporter (or as someone subscribing to an existing task) you only have to sit and wait. In addition to the notifications you would receive in Bugzilla (i.e. change of priority, new comments...) you can also receive notifications for related changes in the project management board (i.e. task selected for the current sprint), new design mockups, and new patches landing. You can fine tune these notification via email preferences.--Qgil (talk) 20:51, 30 April 2014 (UTC)[reply]
  • Strong support - we have been using Phabricator for almost three years at my work, and every time I have to use Gerrit because of MediaWiki I want to cry. --Svemir Brkic (talk) 12:02, 1 May 2014 (UTC)[reply]
  • Strongly in favour, provided we go through the pain of a bugzilla->phabricator migration up-front. --Pixelpapst (talk) 12:32, 1 May 2014 (UTC)[reply]
  • Strong support. Phabricator's not perfect, but its team is solid and actively making integration better every month. Even if it doesn't replace all current tools, it would make a fine replacement for most. Echoing Jeroen: it is worth starting out with small use cases, to finalize the list of issues to address, before freezing major existing tools. (Even if you're committing to using it for everything.) To limit disruption, you could migrate one existing tool at a time, each time paying the migration cost up front before a freeze. Sj (talk) 01:02, 2 May 2014 (UTC)[reply]
  • Moderate support. As long as this tool is in fact a unified user interface that is connected to existing tools which will remain usable separately (even if their design is simplified and modestly adapted to support the Phabricator UI on top of them). This way, if something breaks in Phabricator, we still have a fallback. What this means is that Phabricator should connect to all these tools via a REST web API (without using the UI of these tools). If needed all these tools may be adjusted to offer the necessary web API. Often these tools will support additional new features still not integrated in Phabricator (because these features are still not exposed in their REST API, or because the necessary internal plugins for Phabricator have still not been developed). This way the developments may remain separate, Phabricator will be used more and more, but gradually, with graceful fallback to the individual existing tools, which may also be suspended separately (as often these tools use their own databases requiring their own maintenance). Phabricator should still work if one of the tool is suspended (i.e. the REST API of the individual tool says that it is not responsive, or working in read-only mode, or only by a redirection to a read-only static cache providing very minimal information such as current status). Verdy p (talk) 01:58, 6 May 2014 (UTC)[reply]
  • Support. Ralgis (talk) 07:50, 9 May 2014 (UTC)[reply]

In favor of keeping our current tools

[edit]
  • 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 "hashar" Musso (talk) 21:08, 17 April 2014 (UTC)[reply]
    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)[reply]
  • 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)[reply]
  • "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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    • 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) • talk 05:23, 21 April 2014 (UTC)[reply]
  • 1) I agree with Base, Gryllida. 2) I think Mingle, Trello should be migrated into Bugzilla, not creating new one. — Revicomplaint? 07:28, 20 April 2014 (UTC)[reply]
  • 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)[reply]
    • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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) • talk 21:09, 23 April 2014 (UTC)[reply]
  • 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]
    • QChris, 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)[reply]
      • Qgil, 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)[reply]
  • Not needed. Please fix cricital bugs first, they need more attention. Southparkfan (talk) 22:02, 27 April 2014 (UTC)[reply]
  • Phabricator has a slick (and uniform) UI, but the discussion has shown that it has many shortcomings in various places, so I don't think it is useful to replace one toolset with deficiencies with another one. The dependency on arc will create another stumbling block for users who just want to commit patches and not themselves :-). Overall, the absence of -1s & Co., amending changes after approval, etc. suggest that it aims more for a corporate market where rogues are dealt with by HR than an open source community. This is also another disadvantage as IIRC Phabricator serves only two open source projects so far. So we'd be #3 to hit for every (security) issue that comes up. These deficiencies could of course be worked on and resolved, but this very RfC shows the most likely scenario that we would see in a few years: "Phabricator is bad at this and that, so let's just use xyz as a replacement!" I think the underlying issue is not technical, but cultural: If people are able to use other tools concurrently to Bugzilla and Gerrit and then complain about having to keep them in sync, they'll do so with Phabricator as well. --Tim Landscheidt 03:47, 28 April 2014 (UTC)[reply]
  • If it's true that I need a command line tool just to invite people to a code review then my name needs to be here until we found a UI solution that's equivalent to the one in Gerrit. Phabricator should make things more integrated, not more isolated. --Thiemo Mättig (WMDE) 16:59, 29 April 2014 (UTC)[reply]
  • Phabricator needs a much cleaner GUI. No additional command-line tool shall be needed for developers. All bugzilla/gerrit urls shall still be working. Some real repositories should switch to Phabricator first, then we can evaluate how it works in a production environment. --Ricordisamoa 01:52, 2 May 2014 (UTC)[reply]
  • Integration with Eclipse. Currently Mylyn's integration with Bugzilla and Gerrit are both really good, and I don't see an alternative for Phabricator. DMaggot (talk) 21:40, 30 May 2014 (UTC)[reply]

Basically neutral

[edit]
  • 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)[reply]
  • 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)[reply]
  • 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 [3] (only partly and only after login, try the search). --Nemo 19:10, 19 April 2014 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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 — Preceding unsigned comment added by KLeduc (WMF) (talk • contribs) 15:52, 22 April 2014‎ (UTC)[reply]
    • 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)[reply]
  • 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)[reply]
  • As someone that has dealt numerous times with Mingle SoS cards linked to a Bugzilla forwarded to an RT ticket, I'm excited about the prospect of a unified bugtracker, even in the case where I'd have to sacrifice useful functionality that each of these tools provides to me. I'd be hugely in favor of this, but: I'm a lot more worried about Phabricator's code review system and git integration, especially in regards with traditional git workflows (Gerrit is pretty bad in this aspect, but the arc workflow seems even worse, see e.g. the commits messages in Phabricator's own repository). It seems to me that the evaluation so far has been mostly on the issue tracker functionality; it might make sense as a first step, but now we're being asked for our opinion on a proposal to replace our code review system as well, and I don't feel sufficiently informed about that. Faidon Liambotis (WMF) (talk) 00:37, 25 April 2014 (UTC)[reply]
  • Jeroen De Dauw could be my spokeperson.
    — Danny B. 15:40, 27 April 2014 (UTC)[reply]
  • I have taken a look at Phabricator and admit it's a bit confusing (especially the git / code review part) to me. I think it's going to need quite a bit of customization to really to get it to work the way we need, plus quite a bit of pain to transition and get used to a new system. Perhaps it's worth it though. Once I get more comfortable with it and confident it does what we need, then I am happy about having a centralized tool. I suppose if we take it slow (e.g. start with phabricator instead of gitblit), then that's a good way to go. Aude (talk) 21:16, 28 April 2014 (UTC)[reply]
  • As a bugzilla user and occasional gerrit visitor, I don't mind much the change. It will take some time to re-learn, but maybe it is worth to have everything in one place. However I think the migration should be planned thoroughly and see which modifications need to be done before. In T46 there are many missing features that seem critical.--Micru (talk) 22:11, 28 April 2014 (UTC)[reply]
    • Micru, which features seem critical? These ones? Please reply in the wiki page or in the related Phabricator tasks.--Qgil (talk) 04:21, 29 April 2014 (UTC)[reply]
      • @Qgil: Yep, for bugzilla I would say that bug priority and dependency tree are quite important. Of Bugzilla I also like the ability to create sorted queries like this one. I don't know if Phabricator is able to do something similar because I haven't spent enough time playing with it. Above all I would say that the most critical "missing feature" is the configuration option to remove all eye-candy bloat from Phabricator and leave it at least as bare bones as bz.--Micru (talk) 20:08, 29 April 2014 (UTC)[reply]
        • Micru, what does "eye-candy bloat" mean? Your definition of "critical" might be very different. And to turn this the other way round: I miss switching off the Bugzilla's dusty UI from the late 90es with its many confusing fields which don't even try to hide any complexity to any new users. ;) --AKlapper (WMF) (talk) 15:16, 2 May 2014 (UTC)[reply]
  • The username issue will be an obstacle for getting infrequent users to report bugs (it needs a way to link to the wiki username or similar); we already have issues with people refusing to use bugzilla because their email address is exposed, and those same users are going to be even more reluctant if their "real name" is exposed. I have been frustrated by bugzillas that link to a bunch of other stuff, some of which is viewable by everyone and some of which is "private" or limited access: this should be addressed more easily. On the other hand, do we risk having an increasing number of user-reported issues swept into a private "ticket" they can no longer read? On the whole I agree with those who say that there has to be the commitment of the development team to make this a single tool and not use others in order for this not to become just one more tool that has to be dealt with; the existing tools need to be locked off in order for this change to work. Risker (talk) 16:24, 30 April 2014 (UTC)[reply]
    • The default assumption is that your Wikimedia credentials will just work [4]. Phabricator doesn't expose email addresses. If we go for Wikimedia SUL then I don't think that user will have to enter any name, unless they want to specify it in their user profile. In any case your name can be (space).[5]. About private tickets, the idea is not to change a bit the current behavior in Bugzilla (you can access to your reports even when they are marked as private.[6] Other than that, all services must be public, just like thhey are now.[7]. And yes, the plan is to migrate the entire Bugzilla and leave it as read-only, which should pull the teams using Trello, Mingle, Scrumbugz, and hopefully RT as well, at the time and speed that makes sense for each team within a deprecation window. [8]. We believe that Gerrit is also part of the mix, but more tests and opinions are welcome.[9].--Qgil (talk) 21:08, 30 April 2014 (UTC)[reply]
    • https://bugzilla.mozilla.org/show_bug.cgi?id=218917 has a new patch in so Bugzilla may not expose email addresses for much longer. Not to mention, https://bugzilla.mozilla.org/show_bug.cgi?id=120030 was fixed long ago. --Elvey (talk) 03:29, 7 May 2014 (UTC)[reply]
  • It is crucial that all links to Bugzilla on the various projects will still be working if it is decided to move over. Romaine (talk) 22:50, 30 April 2014 (UTC)[reply]
  • I like the idea of a unified system, but think that we need more information to make an informed final decision. Working out a migration tool in particular for issues & then testing with some projects for real sounds like a good strategy to get that information. -- Gabriel
  • I spent some time looking at this and I like the fact that it has a issue tracker, and I like some aspects of the code review interface (that I can see all files at once when reviewing a patch, I can look at the raw code if I want to without having download a zip), that I dont have to maintain multiple accounts across tools, but I haven't done a more serious or thorough test of this yet. My own concern is whether all the effort of the migration will be worth it -- primarily the need to migrate all bugzilla tickets over or gerrit patches over to phabricator. I see the bugzilla migration requirement pretty daunting. If existing bugzilla tickets can be left in bugzilla and Phabricator is used for new issues/bugs, then that seems like a more reasonable option to me. I am sure these discussions have all already happened -- I'll go look for them. --Subbu, 5th May 2014.

Pros / Cons

[edit]

For a specific comparison with Bugzilla, see Phabricator/versus Bugzilla

Pros (improvements)

[edit]
  • 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).
    • Integrates design and designers. Phabricator organizes design mockups and feedback in the same tool as code; you can upload an image into Phabricator's pholio system and people can comment on it.
    • 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)

[edit]
  • 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. 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 maintenance 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?
  • No dedicated mobile application, only accessible via web. Therefore no push notifications, etc. Mobile support is better than Gerrit and Bugzilla, but not Trello (which has its own app - but proprietary).
Retrieved from "https://www.mediawiki.org/w/index.php?title=Requests_for_comment/Phabricator&oldid=5092437"