Talk:Requests for comment/Phabricator

Users/Personas to Consider
Numerous personas use and interact in the tool. It is helpful to keep in mind their different needs:
 * Users/reporters
 * Developers
 * Maintainers/Managers
 * Triagers/Bugwrangler
 * Tool's tech admin

A Phabricator project to plan the potential migration to Phabricator
The scenario of a potential migration to Phabricator raises many questions and also many proposals of steps that should be done. These questions are now spread in wiki pages, mailing lists, IRC discussions and even Phabricator tests at http://fab.wmflabs.org. In addition to this, many people involved in the discussion haven't used Phabricator beyond simple fictional tests. Proposal: create a  project at http://fab.wmflabs.org and document there the tasks, QA, and interesting resources relevant to this topic.

Benefits:


 * all the Phabricator-specific information in one place, testing the Phabricator paradigm
 * testing Phabricator in a real project (probably without code repository, but still)
 * helping to fine tune our Labs instance to our preferences, surely generating more feedback upstream
 * if we decide to migrate, we will have a better starting point for the plan than wiki pages, etc
 * if we need attention or help from the Phabricator community, we will be able to direct them to their natural environment, where they can easily register, watch, post... Now compare this with sending them to MediaWiki discussion pages like this one.

The Phabricator project would be a complement of this RfC. Here we can discuss the different options, the trade-offs, the master plan... while the bulk of questions about PH and the discussions about implementation details that we are starting to discuss could evolve there.--Qgil (talk) 01:08, 29 March 2014 (UTC)
 * I'm undecided about the overall idea. If we decide it's okay to use that Labs instance temporarily for real work, and if we adopt Phabricator, there are certainly tasks for the migration that could be managed there.  The migration also will involve code (the migration scripts at least).


 * However, it's important to note that when we report stuff to Phabricator (which we certainly will), we're reporting it their issue tracker. They might sometimes glance at our Phabricator to check out the bug in action.  However, they don't care about our 2-page wiki discussion about it.  Nor would they care much about our Q&A on our own Phabricator.  I think they're going to expect discussion/reports about issues with Phabricator's software itself to be focused, and to be at http://secure.phabricator.com/ Superm401 - Talk 08:03, 29 March 2014 (UTC)


 * Sure, what I mean is that we can start planning the hypothetical migration to Phabricator there, create the tasks required there, and if one of those tasks generates questions or requirements from upstream, we would document them there, linking to the appropriate URLs upstream. All I want to do is to concentrate all our knowledge about the potential migration in one place, as opposed to the many wikipages and mailing lists we have already now. I volunteercopying there whatever useful information or discussion we generate elsewhere. I want to learn to use Phabricator beyond the trivial tests.--Qgil (talk) 21:25, 2 April 2014 (UTC)


 * No objections; project created (short announcement sent to the team-practices list).--Qgil (talk) 00:16, 4 April 2014 (UTC)

Simplifying this RfC
After a chat with, we recommend to simplify the RfC before removing the "Draft" template and calling widely for feedback. --Qgil (talk) 21:18, 2 April 2014 (UTC)
 * 1) Propose only three likely options, consider other alternatives only if the discussion leads to consider them:
 * 2) * Proposal A0: Status Quo and Reevaluate in a Year
 * 3) * Proposal A2: Status Quo + Scrumbugz
 * 4) * Proposal B0: Phabricator for All The Things
 * 5) Don't pre-define blockers, don't make them part of the RfC. It is clear that a migration to Phabricator will require a plan with some conditions, but let's not get stuck here in discussions about details (e.g. is RT migration a blocker, full Bugzilla vs selective Bugzilla, etc).
 * 6) Organize a Meta-style RfC (Support, Neutral, Oppose... with one line of comment) as opposed to a MediaWiki Architecture RfC. Let's get concise feedback about the three options from a wide sample of the community, let's see whether that first wave of feedback reflects a consensus, or whether more discussion between two or three options is needed. Once we get consensus around one option, we can start planing for it (or just move along, if we choose to keep the status quo).