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)


 * Superm401: Upstreaming issues to Phabricator that we cannot solve in our instance (not related to the settings of our instance etc.) will be on my plate once such issues are identified. --AKlapper (WMF) (talk) 15:01, 7 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).


 * First item of this list is done now. --AKlapper (WMF) (talk) 16:01, 7 April 2014 (UTC)


 * I was bold and went even further; basically, Phabricator is the main option, and not-Phabricator (i.e. the status quo) is the other option, so I don't feel there's a need to separate them: If we don't want Phabricator, it means we keep the status quo. If we keep the status quo, whether we use Scrumbugz or not is a separate discussion that we can have later. Therefore, I've modified the proposal to focus on Phabricator (with the understanding that the alternative choice is the status quo). Unless there are strong objections, I'll also rename the page for consistency. guillom 13:25, 9 April 2014 (UTC)


 * I've finished to move the planning content over to our test Phabricator instance (per the decision from the section above). guillom 15:38, 9 April 2014 (UTC)

Format and schedule of the RfC
Before we officially open this RfC, we need to:
 * agree on its format and schedule
 * put together an FAQ as agreed in the last IRC discussion.

The format is pretty straightforward now that we've simplified the RfC and its proposal. We're basically asking the question of whether we want to move to Phabricator to consolidate our development toolchain. As hinted above, it seems to make sense to break down the answers into regular Support / Oppose / Neutral sections.

Regarding the schedule, I'm proposing:
 * Until April 10: Prepare the RfC and supporting documents (e.g. FAQ), discuss format and schedule
 * April 11−27: Run the RfC, advertise it widely
 * April 17: Host another IRC discussion to discuss the state of the RfC, answer questions, etc.
 * April 28: Collectively assess the state of the RfC here on the talk page, and decide whether there is agreement or whether we extend the discussion period (by 1 week, then re-assess?). When the discussion period is over, close the RfC and see where we go from there.

Andre and I will work on the FAQ this week. guillom 15:53, 9 April 2014 (UTC)