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)


 * Perfect! I think this reflects the current status and makes the RfC very operational.--Qgil (talk) 04:33, 10 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)


 * Yes, at least in a first round we can start with /  /  + short comment. Let's see what kind of feedback comes out of that, and whether there is a quick consensus in some direction, pockets of disagreement that require deeper discussion, or what. 1 week + reassess is a good approach.
 * We didn't make it to April 11, but can we start on April 13 and then finish perhaps on April 30?
 * Can you confirm the IRC discussion time and date, please?
 * The work pre-defining the Phabricator migration tasks has estabilized. Everything seems to be ready to start the last phase of discussion.--Qgil (talk) 00:58, 14 April 2014 (UTC)


 * Yes, preparing the RFC and the FAQ took a bit longer than expected. April 13 will be difficult though :) If there is agreement on the format, we can start today. Let's do a final sanity check on the mailing lists, and if all's good, let's start today. Here's the proposed amended schedule:
 * April 14−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.
 * guillom 13:31, 14 April 2014 (UTC)


 * , I like this agile calendar. It needs more promotion, though. If only being posted in the RfC page itself. I wonder whether people is really aware of the deadlines.--Qgil (talk) 13:25, 17 April 2014 (UTC)
 * I re-read the announcement and no dates were mentioned there either. Considering the slow path of most of our RfC, maybe we should put more stress in the dates?--Qgil (talk) 14:26, 17 April 2014 (UTC)

IRC discussions
Here the proposed times and dates for the IRC discussions in #wikimedia-office: guillom 14:33, 14 April 2014 (UTC)
 * Thursday April 17, 2014 at 17:00 (UTC) (10:00 am PDT) (hosted by Guillaume)
 * Tuesday April 22, 2014 at 03:30 (UTC) (Monday 20:30 PDT) (hosted by Andre)

Suggestions
There isn't a clear list of what Phabricator is/does as well as the pros/cons compared to the various options we talked about so far. When I compare this draft to other RFCs, like Requests for comment/LESS, that's what I'd strongly suggest we add. Otherwise, people are probably going to not understand why it's being proposed we switch to Phabricator in particular. Steven Walling (WMF) &bull; talk   21:32, 14 April 2014 (UTC)
 * I second this. --Dan Garry, Wikimedia Foundation (talk) 01:59, 15 April 2014 (UTC)
 * Agreed. Especially needed: what bugzilla users gain from it. --Nemo 06:15, 15 April 2014 (UTC)
 * I don't know which format is expected here, but requirements, consolidated requirements, the options (plus for all pages the "History" tab) are available which led to this RfC. Initially comparing the pros/cons on a fine-grained level to all other tools brought up was not done because it did not feel like the best use of our time. Users were encouraged several times to try out the  tools proposed and provide their feedback on them, especially as  different users have different needs that I might not be aware of to a  sufficient extent. I welcome and encourage anybody to start such a  detailed comparison if you think that it could be helpful. --AKlapper (WMF) (talk) 12:59, 17 April 2014 (UTC)


 * The difference with an RFC like the one on LESS is that we're not just comparing 2 tools and their respective features here. We're discussing the replacement of many components of a toolchain (used by many users with differents goals, needs and activities) by an integrated toolchain.
 * I think the "Problem" and "Proposal" sections give a good overview of the pros and cons: We can replace our constellation of tools by one that does everything in one place, but the migration might not be entirely painless.
 * There was a high-level comparison done at Project management tools/Review/Options. Listing the pros and cons of Phabricator's components compared to the existing tools is a massive undertaking that can't be done by just 2 people; that's why we're tracking the missing features, and asking participants of the RFC to get involved. The goal of the RFC is not to vote on one solution vs. the other, it's to get many eyeballs with different goals and needs, put Phabricator to the test, and collaboratively assess if Phabricator is a better solution to the current status quo. guillom 13:01, 17 April 2014 (UTC)

Phabricator "supported by the WMF"
"...but Phabricator will be the one supported by the WMF."

What does this mean, exactly? Is this essentially a promise from the collective of people that maintain our current tools (e.g. Andre for Bugzilla, Chad for Gerrit, etc.) that they'd support Phabricator in the same manner that they support their current tool? Some clarification would be helpful. --Dan Garry, Wikimedia Foundation (talk) 02:02, 15 April 2014 (UTC)
 * I'd rather not become the sole person responsible for our CR infrastructure again. It was a mistake to put it on one person's shoulders before and it'd be shortsighted to do it again. ^demon[omg plz] 04:22, 15 April 2014 (UTC)
 * That sounds perfectly sensible to me. In light of your comments, I am even more curious what was meant by the sentence I highlighted above. --Dan Garry, Wikimedia Foundation (talk) 04:24, 15 April 2014 (UTC)
 * Well I assume it means we'll be supporting it as a team which is what I've suggested in a couple of places by now. I really think Phabricator needs at least two people who care about it and maintain it for us (whether that's staff, volunteers, or some pleasant mixture of the two). ^demon[omg plz] 04:31, 15 April 2014 (UTC)
 * Having the migration and the maintenance properly planned and resourced is a requirement for any migration to Phabricator, see http://fab.wmflabs.org/T41 . The Platform team needs to solve this. RobLa is the ultimate responsible, as budget owner.--Qgil (talk) 15:55, 16 April 2014 (UTC)
 * , ref your comment at the RfC, not having today a proper plan and allocated resources is caused by the fact that this RfC needs to come first. If the community decides to go for Phabricator then we will need to elaborate a good plan and guarantee the resources for maintenance. might have more details. By now we do have a broad plan and a requirement to have a plan and resources in place before starting any migration.--Qgil (talk) 05:10, 18 April 2014 (UTC)

Notices
When this RfC + FAQ is ready for extended view, it will need to be known by everyone affected in the MediaWiki ecosystem. I suggest --Nemo 06:15, 15 April 2014 (UTC)
 * an email to every bugzilla user with at least one action in bugzilla,
 * an email to mediawiki-announce,
 * a sitenotice on mediawiki.org,
 * perhaps an email to all gerrit users.
 * First and last item sound like overkill to me. Why would anybody who commented in Bugzilla or put a patch into Gerrit ages ago be interested enough in receiving an email about discussing about Wikimedia's infrastructure? I could imagine an information banner though in Bugzilla on top of every page though which would be less disruptive? --AKlapper (WMF) (talk) 20:03, 15 April 2014 (UTC)
 * For what is worth, last year I sent much more limited announcements to Bugzilla users, and I got a couple of complaints for "spamming". I would say, if you are in the loop, you are in the loop. If you don't, then your weight in the decision process will not be very heavy anyway. mediawiki-announce and sitenotice sounds good.--Qgil (talk) 15:58, 16 April 2014 (UTC)
 * This is just a way to exclude all those with differing opinions who are not among the initiators of the proposal: "if you are in the loop, you are in the loop". At the very least all email addresses which are default cc/assignee somewhere should be notified that their issue tracker may be replaced. If not all bugzilla users, it can be all bugzilla users with X actions in last 6 months. At least a few hundreds people need to be involved. --Nemo 09:50, 17 April 2014 (UTC)
 * A few days ago I explicitly contacted about 10 maintainers of a few 3rd party tools (but not extensions) using Wikimedia Bugzilla and/or Gerrit and got 2 replies "Why did you send me this email?". I'd still favor a banner on the Bugzilla website instead of disrupting people via email. --AKlapper (WMF) (talk) 10:28, 17 April 2014 (UTC)
 * In this case, probably add soon the sitenotices to let people know about this RfC, even if they go on bugzilla/mediawiki.org once per month or less.
 * I suggest also adding a note in the Tech News (I do it now, probably to rephrase). ~ Seb35 [^_^]  07:31, 18 April 2014 (UTC)
 * I also think that banners / notices are better than emails. Andre, Guillaume, do you need any help on this? About sending emails, for what is worth this report gives email addresses of 973 reporters active in the last 6 months. If you want to send a notification to these users you can do it from your email address, all the information is public. I won't use mine, and I don't think we should use any @wikimedia.org address for this.--Qgil (talk) 16:03, 18 April 2014 (UTC)

Tools recommended and required
About the comments from and  in the RfC, while the idea is to recommend (not to enforce) the migration from Trello / Mingle to Phabricator, if we move to Phabricator then Bugzilla and Gerrit would be frozen, the content migrated, and new reports and reviews would go through Phabricator. This will affect everybody in a way or another. We are discarding the possibility of starting a set with a subset of projects, because the most likely scenario is that we will keep all the current tools + one more. Check Migrate everything to Phabricator and dependent tasks -- feedback welcome.--Qgil (talk) 05:21, 18 April 2014 (UTC)

Reporting tasks to improve Phabricator
and others missing this or that in Phabricator (like ourselves), please report what you are missing at the Wikimedia Phabricator project -- or here, in detail. I have just created a project to list the tasks that would require upstreaming to Phabricator.org. Some of the ones you mention in your comment look like pretty trivial to solve. Integration with Gerrit and GitHub, what do you mean? (but in any case, see e.g. the MediaWiki repo in GitHub cloned). Voting, what do you mean (fwiw Phabricator has a module for voting, we haven't installed because nobody has brought a use case). In other words, let us know what you miss in Phabricator and we will do our best to fit your wishes into the general plan.--Qgil (talk) 05:37, 18 April 2014 (UTC)