Talk:Phabricator/Plan

Linting

Re "Pre-commit linting checks tailored to MediaWiki QA criteria", linting before uploading is a useful and important feature of Arcanist. However, this is not a blocker for migration, since I think we will need to migrate Jenkins in the interim anyway (and we'll have some kind of server-side linting regardless). Superm401 - Talk 23:36, 5 May 2014 (UTC)

Agreed; useful but not blocking feature. Jdforrester (WMF) (talk) 01:45, 6 May 2014 (UTC)

fab.wmflabs.org

I don't see anything about the future of fab.wmflabs.org. There are some important discussions happening there, which should ideally be preserved in the eventual production instance. Legoktm (talk) 22:34, 6 May 2014 (UTC)

@Legoktm: Well, that's a problem, because when we started using fab.wmflabs.org it was on the understanding that it would be scrubbed out after a short while, and was only for testing functionality… Jdforrester (WMF) (talk) 23:00, 6 May 2014 (UTC)

I would say that it is a problem worth having. Thanks to the migration-related projects we are practicing with real tasks. An alternative would have been to create all thhat content in wiki pages, but it would have been more difficult to handle. If we can migrate Bugzilla reports to Phabricator, I'm sure we will be able to migrate Phabricator tasks to another Phabricator instance if we need it, when the right times comes after Day 1. Or maybe we will just want to keep this Labs instance for testing latest builds and what not.--Qgil (talk) 20:47, 7 May 2014 (UTC)

I'm not saying there's anything wrong with planning the migration in Phabricator, but it *has* to be migrated. There are important discussions happening with community members, staff, and upstream developers that need to be preserved and imported. IMO it should be a Day 1 thing, but at the very least it should be mentioned in the "Migration Plan" now that the draft template has been removed. Legoktm (talk) 00:40, 15 May 2014 (UTC)

Yes, you are right. Task created and /Plan edited.--Qgil (talk) 05:43, 16 May 2014 (UTC)

Thanks :) Legoktm (talk) 00:57, 17 May 2014 (UTC)

Surprisingly, a notice now appeared on main page:

This is a test install, be prepared to lose data or manually migrate to the future real instance at a later date. This instance is not meant for long term use.

--Nemo 08:54, 19 July 2014 (UTC)

Bugzilla must be last

It doesn't make any sense to move the largest, longest-serving and most newbie-facing tool first, using innocent users as guinea pigs. It also doesn't make sense to let WMF teams opt out of immediate migration, as this is a WMF operation and the learning cost for ~a handful people is negligible compared to the total cost for thousands. After all, the only thing we really must do without are Mingle and Trello; gerrit has only been used for two years; and RT is a very internal thing with super-technical users who can surely adapt to new software. --Nemo 10:27, 7 May 2014 (UTC)

@Nemo bis: Nonsense. Bugzilla is the least-user-friendly tool we currently have, even worse than gerrit. It is the most desperate for change. Jdforrester (WMF) (talk) 16:04, 7 May 2014 (UTC)

@Jdforrester (WMF): I believe that user-friendliness is a matter of taste, but nevertheless, it was not brought up as an argument by Nemo above, so let's leave it aside. The fact is that Bugzilla is the most user–facing tool we have; the number of tech-unsavvy users who visit Gerrit (not to mention Mingle or Trello) is negligible to non-existent. I agree that it makes little sense to move Bugzilla bugs to Phabricator first; we should test the thing on ourselves (so to say, more tech-savvy users) first, and only then make non–technical users use it when most annoying bugs are already reported and, hopefully, fixed. It makes more sense to me to start with porting Trello, Mingle, RT and Gerrit, and only then move to Bugzilla. odder (talk) 17:03, 7 May 2014 (UTC)

"Using innocent users as guinea pigs" is a dramatic sentence, but which specific problems or risks are you referring to? If we are talking about newbies and tech-unsavvy users, then changing Bugzilla for Phabricator is the best thing we can do for them. Fill a form consisting of title, project, and description. If you are unsure about the project, leave it empty or add various choices. Edit your task or your comments as many times as you need. Remove a comment you posted by mistake. Mention other users by adding their @nick. Insert a screenshot wherever you want. Like/unlike, love/unlove, subscribe with a single click. Do all this from your mobile device.

I expect the majority of WMF teams moving some Trello/Mingle projects to Phabricator by Day 1, moving the rest pretty quickly. If we start with Trello/Mingle alone then we will keep the divide with Bugzilla, which is the first problem we want to solve.--Qgil (talk) 21:22, 7 May 2014 (UTC)

Deploy schedule in Fab

It would probably be nice if we can also track the deploy schedule of the changes with Fab. Currently an oft heard complaint is that we close issues as "FIXED" and that people REOPEN and say: "I still see this bug on en.wp". Having automatic comments that describe when the estimated deploy time is for a merged change might help here. TheDJ (talk) 13:21, 20 May 2014 (UTC)

By "Fab" do you mean literally the test instance at fab.wmflabs.org or the future Wikimedia Phabricator in production? Currently, tasks fixed in fab.wmflabs.org actually mean "This task is fixed upstream, or we have found a local solution for it, and it will not be a problem in the official Wikimedia Phabricator." The fact that such fix is available in fab.wmflabs.org depends on someone updating Phabricator in the Labs instance, which is run basically on volunteering basis. This situation not optimal, but it reflects the current reality. We are putting all our focus in Wikimedia Phabricator Day 1.--Qgil (talk) 14:50, 20 May 2014 (UTC)

As we're discussing this on IRC too, this refers to the future production instance. It refers to the general confusion in Bugzilla "but if you RESOLVED FIXED this problem why is it still broken on that site? Because fixing isn't deploying." This is a topic to discuss after Day 1. --AKlapper (WMF) (talk) 14:56, 20 May 2014 (UTC)