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 Wikimedia Phabricator 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 RobLa-WMF, we recommend to simplify the RfC before removing the "Draft" template and calling widely for feedback.

1. Propose only three likely options, consider other alternatives only if the discussion leads to consider them:
   • Proposal A0: Status Quo and Reevaluate in a Year
   • Proposal A2: Status Quo + Scrumbugz
   • Proposal B0: Phabricator for All The Things
2. 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).
3. 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).

--Qgil (talk) 21:18, 2 April 2014 (UTC)

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 Support / Neutral / Oppose + 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)

guillom, 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)

I have added a banner at the top of the page mentioning the April 27 deadline.--Qgil (talk) 14:33, 21 April 2014 (UTC)

Note I removed it per Talk:Requests_for_comment/Phabricator#Shouldn.27t_we_close_this.3F - people need a bit more time and some of them do respect the deadlines :P Petrb (talk) 20:48, 28 April 2014 (UTC)

IRC discussions

Here the proposed times and dates for the IRC discussions in #wikimedia-office:

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

guillom 14:33, 14 April 2014 (UTC)

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

Hashar, 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. RobLa-WMF 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)

Commented in Phabricator (T41) - in short, we'll figure something out. Let's figure out the direction before getting too wound up in the implementation details. -- RobLa-WMF (talk) 20:41, 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

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

--Nemo 06:15, 15 April 2014 (UTC)

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)

I've added a banner to Bugzilla. --AKlapper (WMF) (talk) 07:12, 20 April 2014 (UTC)

It seems to be working! Is there a way to add a banner in Gerrit as well? Or can we assume that Gerrit users are also Bugzilla users?--Qgil (talk) 02:25, 21 April 2014 (UTC)

Uhm, Chad might know? :-/ --AKlapper (WMF) (talk) 06:36, 21 April 2014 (UTC)

I'm a bit concerned about the lack of participation in this RFC from key stakeholders so far. The Wikimedia development ecosystem is sizable and this is potentially a large change to its workflow. I'd expect a higher turnout than what I've been seeing, so I'm wondering about the Bugzilla notice or other means of advertising this discussion (it's not even listed at Requests for comment?). --MZMcBride (talk) 06:53, 20 April 2014 (UTC)

Urgh, thanks for noticing. I had naively expected some automated process to get things into that list. Added to "Seeking feedback" now. --AKlapper (WMF) (talk) 07:02, 20 April 2014 (UTC)

It was mentioned in meta:Tech/News/2014/17, which will reach a lot of the volunteer devs. Whatamidoing (WMF) (talk) 18:47, 21 April 2014 (UTC)

Participation has definitely improved in the past few days. --MZMcBride (talk) 03:57, 24 April 2014 (UTC)

Nemo, Seb35 and MZMcBride: I've prepared a site notice for mediawiki.org at MediaWiki talk:Sitenotice. I can put it up unless there are objections. guillom 16:12, 22 April 2014 (UTC)

I'd prefer that we only run one banner at a time. If we deploy a local sitenotice, we should hide the global CentralNotice(s). --MZMcBride (talk) 03:57, 24 April 2014 (UTC)

I considered putting up a watchlist notice instead for Phabricator (to avoid having two banners) but it seems watchlist notices aren't a thing here (MediaWiki:Watchlist-details has never been used). I'm not sure how much leeway we have with FDC banners, so I haven't removed it myself. guillom 07:59, 25 April 2014 (UTC)

Tools recommended and required

About the comments from Tfinc and Jeroen De Dauw 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)

Just saw this, I will edit my comment accordingly. Nevertheless, while committing to migrate everything, you could first migrate RT, Mingle and Trello; then finalize the Bugzilla migration plan, before freezing it; then finalize the Gerrit migration plan, before freezing Gerrit. This way, if any major problems show up while finalizing the harder migrations, you haven't precommitted to making everyone endure all problems at once. Migration can still happen as quickly as you're able to work out and implement each plan. (Also: you might consider shifting usage from old tools to new ones per project, at natural breaks at the end of current milestones, rather than all on the same day.) Sj (talk) 02:13, 2 May 2014 (UTC)

Reporting tasks to improve Phabricator

Thiemo Mättig (WMDE) 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)

As I said, to me the current Phabricator installation feels very much "out of the box" (I guess because it is) and not adjusted to our use cases. I honestly can't decide if it's better than what we have and worth my time.

In general, I totally agree that it would be awesome to have something that removes the huge gap between Bugzilla and Gerrit. In my opinion this is the biggest issue with our current setup: that a user who found out how to report bugs and now wants to help fixing them must switch to a completely different system. The gap between the two is just frightening.

I really don't have the time to report every problem I see as actual issues in Phabricator. I see so many little design flaws (which doesn't make them less important just because they are small, there are so many of them) as well as some bigger ones. I will try to list a few.

1. All fonts are to small. What's worst: the main text of an issue looks like it uses the smallest font on the page. Isn't the actual text the most important thing and should stick out? Yes, I can zoom in. But I don't want every user to zoom in first.[1]
2. There are so many icons with no description at all. For example: there is a flame icon on top of the page (looks like a logo but seems to have a meaning in terms of notifications), a plus (probably to add something to something, but what to what?) and an unlabeled arrow (could mean "hide toolbar" but seems to be an exit). Why don't they have hover tooltips (title attributes)? I consider this a major usability issue.[2]
3. The worst icon is this one. What is this? The border of a country? A decoding error?[3]
4. The tools in the toolbar on the right of an issue (the one with "Edit Task", "Merge Duplicates In" and so on) turn blue when you hover them, which is very nice. But for some strange reason you can not click the icons. This was literally one of my first clicks and my impression was "what, don't they support Firefox?".
5. At the bottom of each issue it says that I "added a comment". Which I obviously did not. Yes, I'm aware this is a placeholder for the preview. But why is it there if I did not typed anything?[4]
6. It seems there is no way to close an issue with a reason (e.g. "works for me").[5]
7. Are flags public? If they are private then the "Flag for Later" tool is simply misplaced between tools that actually modify the issue in a way thats visible to the public.
8. Same for "tokens". Are they public? I can't tell. It seems they are but they don't show up in the event stream at the bottom of the issue.
9. When I add "thumb up" tokens, are they counted? Can I see a list of issues with the most tokens somewhere? Basically a voting to quickly decide if an issue is worth developers time?
10. Voting? [6]
11. Remarkup? Really? Users are supposed to use an other markup language in addition to Wikitext, Markdown (Github) and the very limited one we have in Bugzilla? At least it's not WYSIWYG, phew.[7]
12. The board view seems to miss basically all information you need. All you see are the first few characters of each report. Maybe this board view is just not for me and my use cases.[8][9]
13. The diff views always shows a useless second scrollbar that only scrolls a few pixels (Firefox, Ubuntu). This consumes mouse wheel turns when the mouse is accidentally hovered above this bogus scroll pane.
14. In a diff I can't click the file names to quickly show the whole file. I have to scroll up to the top, search the file name in the list on top and click "browse".
15. For some reason the link to show a file is labeled "browse". I can "browse" a repository, but not a file.
16. To put something positive in: The repo browser is actually pretty cool. I like it.
17. The "Find Owners" tool in the repo browser seems to be broken. Or it does not have access to the information it needs.
18. [Blocker] When reviewing a commit I miss the number of lines that changed (e.g. "+231, -105"). Gerrit shows this for each file and for the whole change. For me this became a very, very important information and is a must-have.
19. [Blocker] How can I invite users to a code review?
20. Where is the list of my personal code reviews I'm watching?
21. Why can't I edit the title of a commit? When I click "Edit Commit" all I can do is add or remove a project.
22. It seems there is no reply button even if reply is possible by indenting with >. Bugzilla had way less features but it had a reply feature.[10]
23. It seems there is no way of going back to the list of audits when you are in an audit (other than using the browser history).
24. Wow, this was trippy! I clicked the "i" icon on top of the page and after that Phabricator started to act extremely weird. I only realized I'm in a completely different Phabricator when I tried to login again and couldn't. Simple solution: change the design in ours.

I hope that helps. --Thiemo Mättig (WMDE) 12:37, 29 April 2014 (UTC)

Thanks Thiemo! I have no idea how to answer directly after each item without destroying the numbering of your numbered list, so let me start here below the list by replying to the first items:

1. Not an issue here, but CSS could be adjusted, or your browser might remember custom zoom levels per domain.

3. Avatars: They are intentionally ugly so you replace them by a nice photo of you. ;) Also see http://fab.wmflabs.org/T124

6. That is covered by the "status" instead, plus you could explain more complicated decisions in a comment.

7. By default I'd assume that everything is public (I might be wrong though, haven't played with that flag yet).

8. Yes, tokens are public. I don't see much reason to tell for every item that it's public. :)

10. Voting via tokens; see http://fab.wmflabs.org/T150

11. See http://fab.wmflabs.org/T165

For 2,4,9 and the rest I need to find out later (got meetings now) and potentially upstream. --AKlapper (WMF) (talk) 14:51, 29 April 2014 (UTC)

3. The problem is that I did not even realized that this country border is supposed to be an avatar. Simple solution: do it like GitHub and use the default Gravatar icons.

--Thiemo Mättig (WMDE) 16:45, 29 April 2014 (UTC)

@Thiemo Mättig (WMDE): Gravatar? Are you joking, or do you seriously care so little about user privacy? Jdforrester (WMF) (talk) 19:11, 29 April 2014 (UTC)

It's good to know that we both agree on that, even if I couldn't make my point clear. I guess it's impossible to make everybody happy by pointing at weak spots in something that's otherwise a good idea. I tend to skip "i like it, but …" disclaimers when I write such posts. Blame me. --Thiemo Mättig (WMDE) 21:23, 29 April 2014 (UTC)

SUL

It would be great if there will be some way to connect Phabricator and SUL identities (possibly just use Wikimedia SUL username for everything). πr² (t • c) 22:02, 19 April 2014 (UTC)

Could you please report what you are missing at the Wikimedia Phabricator project if possible? Thanks! --AKlapper (WMF) (talk) 06:58, 20 April 2014 (UTC)

Wikimedia MediaWiki Core Team/Quarterly review, April 2014#OpenID connect says "Doing work in this area would make Phabricator integration with our Wikimedia project logins very simple" ("Considered but tabled for now"). That's something everyone would welcome as an improvement compared to bugzilla; it would be easier to convince people to abandon bugzilla after making available such feature. --Nemo 10:41, 20 April 2014 (UTC)

Yes, good idea. Tracked at T178: Implement Wikimedia SUL in this Labs instance.--Qgil (talk) 16:55, 21 April 2014 (UTC)

Training

Is there some sort of easily available training (e.g., free videos from a training class?) for Phabricator? A couple of comments talk about the learning curve. It's hard to evaluate a product when you don't understand it. Whatamidoing (WMF) (talk) 18:43, 21 April 2014 (UTC)

We are considering organizing a Tech Talk with a casual crash course run by some WMF employees that have worked with Phabricator in their previous job. If others think this is a good idea we will schedule the session.--Qgil (talk) 21:20, 21 April 2014 (UTC)

That sounds good. Will it be open to volunteer devs? Whatamidoing (WMF) (talk) 22:22, 22 April 2014 (UTC)

Of course! Public hangout-on-air ending up with a video available to watch.--Qgil (talk) 06:38, 23 April 2014 (UTC)

I think a Tech Talk would be a great idea, for those of us who don't have a lot of time to figure out how the tool works in detail. You often learn faster when a more experienced user shows you how they use the software in the context of real life tasks. And this would also let us ask any questions not already covered by the documentation. Fabrice Florin (WMF) (talk) 20:36, 28 April 2014 (UTC)

Having a presentation would be lovely and a big help. I've asked again on the (non-public) engineering mailing list if there are volunteers and asking for setting a preliminary date. --AKlapper (WMF) (talk) 19:25, 3 May 2014 (UTC)

Comparison with Gerrit?

While we have a pretty good idea of the mapping between Phabricator and Bugzilla, and while we ar getting a better idea of the comparison with Mingle/Trello, personally I would welcome more feedback from Git/Gerrit users about Differential/Diffusion/Audit.

• How does the experience of task commenting and code review compare with Bugzilla+Gerrit?
• How is the jump from GitHub to these tools?
• Many Windows users felt/feel that git-review / Gerrit is a pain, does Phabricator cause trouble for users of a specific platform?

--Qgil (talk) 21:24, 21 April 2014 (UTC)

Do we need to leave gerrit behind when moving to phabricator? Couldn't we use phabricator just to keep track of tasks and gerrit for vcode reviews?NRuiz (WMF) (talk) 10:27, 29 April 2014 (UTC)

We don't need to, but the reasons to keep Gerrit should outweigh the cost of keeping an extra tool. Longer reply here.--Qgil (talk) 22:08, 29 April 2014 (UTC)

Shouldn't we close this?

It's already 28. April and people are still voting, everywhere is that deadline is 27. April so I think we should close this "vote" now Petrb (talk) 12:20, 28 April 2014 (UTC)

I don't mind closing the RFC now, but I'm also thinking another week of input couldn't hurt. The proposed timeline mentioned the possibility to extend the RFC by one week. I'll reach out to the list to get more opinions about whether to leave open for a week or close now. guillom 16:32, 28 April 2014 (UTC)

I don't see much point in "closing" it until someone is prepared to take action. It's sort of like whether the deadline for your school work is "at <this exact time>" or "any time before the professor sits down to grade this assignment, which could be as early as <this exact time>": the first is an arbitrary deadline, but the second has practical consequences for someone's workflow. Whatamidoing (WMF) (talk) 18:40, 28 April 2014 (UTC)

Let's leave it open for a week. Steven Walling (WMF) • talk 18:53, 28 April 2014 (UTC)

We are still getting useful feedback every day. Next week, the Wikimedia hackathon will provide a natural place and time to evaluate the current status of the RfC and propose next steps.--Qgil (talk) 19:33, 28 April 2014 (UTC)

Sounds good to me. From what I can tell, Phabricator looks like a good solution for integrating all our different tools into a single environment. But I haven't had time to really dig in and check that it covers the basic tasks we use every day on Mingle. I suspect that it will, but can't make an informed vote until I know more. So giving it an extra week will help with that, particularly if combined with a Tech Talk. Thanks for hosting this RfC! :) Fabrice Florin (WMF) (talk) 20:40, 28 April 2014 (UTC)

Ok I have nothing against it as well, but I am strongly againsted having there huge label "vote by April 27". If I was to vote, I wouldn't just because it clearly say that voting is over. So we should at least change the deadline time so that it's not so confusing. Petrb (talk) 20:41, 28 April 2014 (UTC)

I removed the deadline from text. If you find it somewhere else, remove it there as well, so that people know they still can share their opinions. Petrb (talk) 20:46, 28 April 2014 (UTC)

Proposing to put Gerrit migration aside

I want to propose that we put aside the migration from Gerrit to Phabricator, still within the current RfC, in order to have a quicker resolution favorable to Phabricator for project management and bug reporting. We now have a good idea of the features missing for users of Bugzilla, Trello, Mingle, RT, and Scrumbugz, but the situation with Gerrit is still unclear (see the Code review in Phabricator project).

The resolution of the current RfC could have a section mentioning the willingness to have our code review process also integrated in Phabricator, but highlighting the fact that further evaluation is needed before considering a migration from Gerrit. This would give us freedom to proceed with the core Phabricator plan as a PM tool while developers look deeper to Differential, Arc, Audit, and Diffusion.

Even with Gerrit out of the picture, the migration to Phabricator day 1 will take months. And even with a community decision favorable to move from Gerrit to Phabricator, the migration would probably happen some time after that Day 1 (a discussion for Plan to migrate code review from Gerrit to Phabricator). I see no need to block the PM side of Phabricator because of problems with the code review side. Do you agree?--Qgil (talk) 19:04, 1 May 2014 (UTC)

I think the benefits are less compelling if we don't do the code review too. However, reducing the number of issue tracking systems could still be a benefit. If we're considering dropping code review for now, I think we should commit (this means team buy-in) that after the migration, there will be one less writeable issue tracker (e.g. only Phabricator, or only Phabricator, Mingle, and RT, which is still a reduction). If after the migration, we simply have Phabricator, Trello, Mingle, and RT instead of Bugzilla, Trello, Mingle, and RT (same fragmentation, just one swapped), I don't consider that worth the transition costs. If we have Gerrit, Phabricator, Bugzilla, Trello, Mingle, and RT, that would be a failure.

I'm not quite ready to drop the code review idea. It does need further investigation, but I'd like us to do some of that (e.g. will we have to "land" patches manually, or would Jenkins do that, is using arcanist's linting tools for our coding conventions doable, etc.) Superm401 - Talk 20:30, 1 May 2014 (UTC)

[ec] @Qgil: I think this would be a mistake. Most of the value is in the tied task/bug <-> code step. If we decide that we couldn't use Phabricator for code review, we'd be stuck in a place which is "good enough" that we wouldn't want to address properly. Jdforrester (WMF) (talk) 20:31, 1 May 2014 (UTC)

Changing the RfC's proposal now after many have voted comes does not sound too thrilling to me. Especially, since many votes in favor of the switch voiced a strong desire to harmonize the set of tools to exactly one tool. I am not a fan of letting people vote, and then remove the incentive for their vote. Mhm :-/ And a Phabricator RfC that does not cover Gerrit isn't a “consolidation of tools” for me. I currently mostly use two tools: Bugzilla, and Gerrit. After the PhabricatorButKeepingGerrit switch I am still left with two tools: Phabricator, and Gerrit. I would have gained nothing, but only lost time learning Phabricator. --QChris (talk) 20:40, 1 May 2014 (UTC)

I was initially skeptical of this idea, but Quim convinced me when we spoke. We would still very, very, very seriously consider moving from Gerrit to Phabricator if we move everything else to Phabricator (like, with 99% certainty), but removing Gerrit from this particular RFC would make the ordering a little clearer. FWIW, I'm also ok still with keeping Gerrit->Phabricator on this list, but support whatever Quim thinks is best. -- RobLa-WMF (talk) 21:01, 1 May 2014 (UTC)

I guess my wording could have been clearer. I said "put aside", not "drop". The goal keeps being to go for one single tool that includes code review. The difference is that I'm proposing to resolve the RfC in the next couple of weeks knowing that the Gerrit vs Phabricator details are still unclear. The alternative is to wait until the Phabricator code review scenario is clear, and only then seek to approve the RfC. Both paths lead to the same goal, but in the second one Andre, Guillaume, myself, and other non-developers basically have to sit and wait, because we don't have the expertise to drive the discussion and report tasks upstream as we have done with the Bugzilla/PM tools discussion. I'd rather use that time to ramp up the official Wikimedia Phabricator instance and work on the migration of data to the new environment, a serious investment that we cannot commit to without an RfC resolution. The Gerrit-Phabricator work would continue while this happens. Whenever we have a plan for the Gerrit migration, we will implement it as well. In other words, I believe my proposal will get us to the final goal sooner, not later, with less friction and with a better knowledge of every step we make.--Qgil (talk) 21:22, 1 May 2014 (UTC)

Ugh. No thanks. Moving to Phabricator does not my support unless we commit to it the full way. Otherwise we're just doing a bunch of work to migrate Bugzilla and giving up nice functionality in Trello for nothing. Phabricator's only real advantage as a task management system is that tasks/bugs and code review are the same thing. You can tell from the comments in support that people are behind this because it consolidates our toolkit. If we don't do that consolidation, we're doing a lot of work for nothing. Steven Walling (WMF) • talk 21:52, 1 May 2014 (UTC)

Thank you all for your participation in this social experiment. ;) If this sample of people (who are following closely the RfC and know well my agenda) was confused by my proposal, we can only expect that the rest will be also confused by default. The promoters of this RfC still would like to have a resolution short after the Hackathon next week. Your help is needed untangling this problem, which is the main bottleneck we have currently: T274: The code review process in Differential/Audit needs to be adapted to our needs.--Qgil (talk) 05:58, 2 May 2014 (UTC)

Email

http://fab.wmflabs.org/settings/panel/emailpreferences/ versus https://bugzilla.wikimedia.org/userprefs.cgi?tab=email

Are the email options enough? Can they be improved? We need the powerusers to not get over-whelmed, or under-informed, about things they need to know.

There's also Herald http://fab.wmflabs.org/herald/ (docs), but I haven't understood how that works, yet.

[Tangent: I've been pondering ways to highlight the Bugzilla & Echo prefs, to signify "this option is high-volume". Experiments include: a color-highlight, eg. https://i.imgur.com/IcEWCzF.png Or a size-variation, eg. https://i.imgur.com/tOJOsXG.png -- Just a thought, and not sure where else to put it.] –Quiddity (talk) 17:05, 2 May 2014 (UTC)

I actually think Phabricator's approach to notifications is more flexible and simpler to handle. Are you missing anything specific? Unlike Bugzilla, Phabricator offers web notifications (think Bugzilla with Echo) ;) . Unlike Bugzilla, with Herald you can receive notifications for types of events (e.g. every time someone mentions "Quiddity" in source code, whenever some regexp is produced, etc).--Qgil (talk) 17:56, 2 May 2014 (UTC)

@Quiddity: Do you miss something specific? Herold might miss some functionality, but it also provides functionality that Bugzilla missed so far (e.g. setting yourself as default CC on a project instead of having to ask a Bugzilla admin, cf. bugzilla:37105, hence I'm curious. --AKlapper (WMF) (talk) 19:28, 3 May 2014 (UTC)

Nope, I was just looking at the menus and noticed the vast difference in number of options. (Relatedly, Trello only has 3 email-notification options: None (web-only), Bundled, Individual). I started this thread in case it was helpful to consider, and an issue that hadn't been specifically poked at yet. (Plus I wanted to share my UX experiments :) –Quiddity (talk) 19:43, 3 May 2014 (UTC)

Images in review

Can I have animated gifs in Phabricator review? Much like as done here.

-- Jeroen De Dauw (talk) 16:17, 3 May 2014 (UTC)

Yes.  :) --Qgil (talk) 05:18, 4 May 2014 (UTC)

Phabricator having no Jenkins replacement ready

Although RfC's section 4 claims to also replace Jenkins, it seems Phabricator does not yet have a Jenkins replacement ready. epriestley said on T207#53:

[...], but Phabricator can't replace Jenkins today. It can interact with it (like Gerrit does), [...]

It seems Phabricator people are trying to implement a “Harbormaster/Drydock” CI tool since 2012, but as it's still not there yet, I guess this mean that Jenkins is yet one more tool to stay around even after the Phabricator migration? --QChris (talk) 09:26, 4 May 2014 (UTC)

Indeed, a Jenkins replacement is not ready yet. Handling continuous integration via Phabricator may be possible in the future, but such option should be probably be taken out from the scope of the current plans. I have edited Requests_for_comment/Phabricator/Plan#Summary accordingly.--Qgil (talk) 13:44, 5 May 2014 (UTC)

Draft plan

I have started drafting a plan for the next steps at Requests for comment/Phabricator/Plan. It aims to be a starting point for the next round of discussion to be held here and at the Wikimedia hackathon in Zürich this weekend. Edits, questions, and feedback welcome.--Qgil (talk) 06:38, 5 May 2014 (UTC)