IRC office hours/Office hours 2015-02-18

Log for Language Engineering

Time: 13:00-14:00 UTC
Channel: #wikimedia-office
Timestamps are in UTC.

13:00:26 <arrbee> #startmeeting Language Engineering monthly office hour - February 2015
13:00:26 <wm-labs-meetbot> Meeting started Wed Feb 18 13:00:26 2015 UTC and is due to finish in 60 minutes. The chair is arrbee. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:26 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:26 <wm-labs-meetbot> The meeting name has been set to 'language_engineering_monthly_office_hour___february_2015'
13:00:52 <arrbee> Hello, Welcome to the monthly office hour of the Wikimedia Language Engineering team.
13:01:15 <arrbee> We are late by a week this time, but early on the hour
13:01:36 * arrbee is wondering who all are around
13:02:13 <arrbee> I am Runa, the Outreach coordinator for our team
13:02:19 <kart_> arrbee: hello!
13:03:06 <arrbee> and along with me are my team mates: kart_ Nikerabbit
13:04:00 <arrbee> First, the really important message: The chat today will be logged and publicly posted.
13:04:43 <arrbee> Our team's last office hour was on January 14
13:04:55 <arrbee> The logs are at:
13:04:57 <arrbee> #link https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2015-01-14
13:05:17 <arrbee> Hi aharoni
13:05:57 <arrbee> And our general team page is:
13:06:04 <arrbee> #link https://www.mediawiki.org/wiki/Wikimedia_Language_engineering
13:06:27 <aharoni> Salom!
13:06:29 <arrbee> We opted for an earlier time this month
13:07:12 <arrbee> If it works well then we would consider sticking with it. So we would love to hear opinions
13:07:53 * arrbee suspects this is prime commute time for India and some parts in the east.
13:08:45 <arrbee> During our last month's office hour we were in the middle of the first deployments of Content Translation
13:09:12 <arrbee> And by the end of that week, we had Content Translation running in 8 Wikipedias
13:09:31 <arrbee> In case you missed the announcement, its right here:
13:09:39 <arrbee> #link http://blog.wikimedia.org/2015/01/20/try-content-translation/
13:10:18 <arrbee> Its been just over a month and we are still tracking the stats to get a better understanding on how the tool is being used
13:10:32 <arrbee> A quick view of the usage numbers can be seen here:
13:10:43 <arrbee> #link http://language-reportcard.wmflabs.org/
13:12:22 <arrbee> For numbers related to individual wikis, you can use the Special:CXStats pages
13:13:32 <arrbee> Earlier this month, Content Translaltion was enabled on the Norwegian Nynorsk Wikipedia after we received a request from the community
13:14:08 <arrbee> We also enabled publishing directly into the main namespace for Catalan, Indonesian and Portuguese Wikipedia
13:14:40 <arrbee> Currently we are working on several things that make it easier to get Content Translation in more languages
13:15:24 <arrbee> kart_ and Santhosh (not here right now) are making these changes that will simplify how we choose the source and target languages
13:15:44 <arrbee> We will be making this change available in the beta server sometime later this week
13:16:06 <Nikerabbit> specifically, simplifying it on configuration side, on UI we already have adapted ULS for language selection
13:16:31 <arrbee> Thats right. Its a configuration change
13:16:34 <kart_> Largely users won't notice it :)
13:16:50 <kart_> But developers will love it!
13:17:05 <aharoni> Yes, it's an internal change, but the main idea behind it is that it's supposed to make adding new languages simpler for us developers, so the time from the request until the deployment should become shorter.
13:18:23 <arrbee> Presently the cycle extends anything between 15-20 days or more
13:18:34 <arrbee> including testing cycles
13:19:09 <arrbee> kart_: one of the things that we are often asked is about the testing environments we maintain
13:19:35 <arrbee> We also mention it in the graduation plan
13:19:38 <arrbee> #link https://www.mediawiki.org/wiki/Content_translation/Languages
13:19:58 <arrbee> labs, beta-labs and production
13:20:29 <arrbee> kart_: can you perhaps give us an overview about this
13:20:33 <arrbee> ?
13:20:47 <arrbee> Whats the flexibility, restrictions etc.
13:21:06 * arrbee waves to santhosh_
13:23:36 <kart_> hello
13:24:01 <arrbee> kart_: hi again, i thought you had dropped off :)
13:24:10 <kart_> Beta Labs are closer to Production.
13:24:35 <kart_> So, it makes testing easier for us
13:25:20 <kart_> arrbee: slow machine, excuse me for typos and lagging (may be network too)
13:25:37 <arrbee> no worries, we have ~35 more mins
13:26:23 <kart_> Good thing about Beta Labs (not to confuse with with Labs :)) always runs on master code for CX/cxserver
13:26:48 <kart_> so, we usually detects nice bugs from there.
13:27:29 <kart_> That's all for Beta.
13:28:17 <kart_> Labs are experimental setup by different team members from team. We really don't suggest to use for testing unless really needed.
13:29:12 <kart_> We maintain cx.wmflabs.org instance.
13:29:21 <kart_> No warranty :)
13:29:24 <arrbee> :)
13:30:05 <arrbee> So cx.wmflabs.org is essentially the most unreliable yet quite possibly be running more interesting stuff at the same time? ;)
13:30:41 <Nikerabbit> yep
13:31:03 <kart_> arrbee: yes. Specially, since we control it fully, we can do whatever with it (config specially)
13:31:28 <arrbee> Thats right
13:31:58 <Krenair> more unreliable than beta?
13:33:00 <kart_> Krenair: really. It has mw instance, that we forget to update sometime.
13:33:15 <Nikerabbit> beta at least strives to be stable, cx.wmflabs.org has no kind of guarantees
13:33:46 <kart_> there are cron setup, which now updates mw, cx, cxserver - but we don't give any assurance that all will work all the time.
13:34:02 <Nikerabbit> though, beta (aka deployment-prep) is much more complicated ecosystem so it is more likely to break for various reasons possibly unrelated to us
13:35:24 <kart_> So far, complicated setup like cxserver/apertium services has been useful by deploying in Beta first.
13:35:45 <kart_> oh. and Labs runs on nighty version of Apertium.
13:36:07 <kart_> May break your favourite language pair anytime!
13:38:23 <kart_> That doens't mean we don't love Labs ;)
13:38:41 <kart_> Both has been very useful for us.
13:38:49 <kart_> arrbee: over to you.
13:38:49 <arrbee> kart_: +1
13:39:06 <arrbee> kart_: one more for you :)
13:39:34 <arrbee> The other problem that often gets in the way is the 'publishing error'
13:39:45 <arrbee> We know that sometimes its related to Parsoid
13:40:05 <arrbee> kart_: Could you please tell us a bit more about why that happens?
13:42:40 <arrbee> ok.. looks like the network lag is really bad for kart_
13:42:48 <arrbee> umm.. Nikerabbit santhosh_ ?
13:43:01 <Nikerabbit> well there are various reasons for that
13:43:49 <Nikerabbit> it could be parsoid is having problems with that article, or the parsoid service could be temporarily down, or that the target wiki does not like the page, for example abuse filter may prevent edits
13:45:01 <kart_> Thanks Nikerabbit
13:45:06 <Nikerabbit> with improved logging we should be better able to monitor this in the future
13:46:23 <arrbee> I think aharoni had noticed something about abuse filter in the Spanish Wikipedia
13:47:46 <aharoni> Yes - the Spanish Wikipedia has a (sensible) abuse filter setting,
13:48:12 <aharoni> which warns people when they try to publish a page in the user space with categories that should be in the article space.
13:48:46 <aharoni> ContentTransation adds categories automatically, so articles with auto-adapted categories couldn't be published.
13:48:52 <aharoni> To fix this we did two things:
13:49:24 <aharoni> 1. Fixed ContentTranslation so that aut-adapted categories would be put inside <nowiki> unless published to the main space.
13:50:19 <aharoni> 2. Contacted the Spanish Wikipedia community and asked to tweak the abuse filter after this fix.
13:50:28 <aharoni> (Thanks to abian for doing this!)
13:51:03 <aharoni> Now there's another issue that affects publishing:
13:51:54 <aharoni> If a CAPTCHA is supposed to appear during publishing, it may be hidden if the page is scrolled all the way to the top, so that publishing appears to be stuck.
13:52:02 <aharoni> This is already fixed in the code, and will be deployed soon.
13:52:17 <aharoni> (Till then, if publishing appears to be stuck, try scrolling down.)
13:53:10 <arrbee> aharoni: This was noticed in the Portuguese Wikipedia, isn't it?
13:53:23 <aharoni> I noticed it in Spanish, but it can happen anywhere.
13:53:29 <arrbee> oh ok
13:54:06 <kart_> aharoni: should be deploy tomorrow if everything goes smooth :)
13:54:34 <aharoni> kart_: excellent.
13:55:11 <arrbee> We are nearing the end of the hour
13:55:28 <aharoni> And another little comment:
13:55:31 * arrbee looks around for any questions
13:56:01 <aharoni> After enabling direct publishing to the article space in Catalan, Indonesian and Portuguese Wikipedias, we are looking to more languages.
13:56:32 <aharoni> The update in Norwegian Nynorsk seems to be quick and successful - 20 out of 23 articles were published,
13:56:39 <aharoni> and Esperanto is going well, too,
13:56:59 <aharoni> so these two seem like likely candidates for direct main namespace publishing.
13:57:05 <aharoni> There will definitely be more :)
13:58:05 <aharoni> Finally, a happy announcement:
13:58:13 <arrbee> We generally announce this well ahead of time in each Wikipedia
13:58:17 <aharoni> After a break of a few months for technical reasons,
13:58:46 <aharoni> we finally restored the "most commonly used MediaWiki messages" group in translatewiki.net.
13:59:38 <arrbee> Alright! We are down to the last minute now
13:59:41 <purodha> thanks for that
14:00:12 <arrbee> Thanks everyone for joining in. Especially kart_ aharoni Nikerabbit for the explanations :)
14:00:15 <aharoni> you're welcome, purodha  :)
14:00:31 <arrbee> Our next office hour is scheduled to be on March 11. But do please check our announcements
14:00:38 * purodha is happily smiling
14:00:45 <arrbee> Most of our office hours were at 1700 UTC, but if this hour works well we would like to continue with it
14:00:53 <arrbee> #endmeeting

Generated by MeetBot 0.1.4 (http://wiki.debian.org/MeetBot)

Log for VisualEditor

[15:56:40] <whatami> The second weekly bug triage meeting for VisualEditor will start in about five minutes. Instructions for joining the WebEx portion of the meeting are at https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal I plan to post links to the bugs being discussed here if you want to follow along in IRC.
[16:02:11] <whatami> The list of tasks to be discussed today was posted at https://phabricator.wikimedia.org/project/board/1015/
[16:02:14] * andre__ waits for WebEx to do something in his browser
[16:02:31] <cndiv> I'm handling audio for this meeting, any comments (even positive!) direct to me, please.
[16:02:52] <cndiv> andre__: you're the Fedora user, right?
[16:02:57] <andre__> yeah
[16:03:51] <whatami> https://phabricator.wikimedia.org/project/profile/1015/ has the list of objectives.
[16:03:51] <awjr> can someone please share a link to the release criteria?
[16:03:54] <awjr> thanks :)
[16:04:03] <andre__> seems to work...
[16:04:15] <andre__> awjr, https://phabricator.wikimedia.org/project/profile/1015/
[16:04:20] <awjr> ty
[16:06:42] <qgil_> Hi, is there a meeting number or URL to join from Android app?
[16:07:01] <qgil_> Webex, I mean. VisualEditor meeting.
[16:07:11] <whatami> Let me see...
[16:07:19] <marcoil> qgil_: the meeting number is 803 811 433
[16:07:30] <whatami> Thanks, marcoil
[16:07:42] <marcoil> but maybe you'll need to get to the webpage to get a attendee ID
[16:07:57] <marcoil> np :)
[16:07:57] <rdaiccherlb> No attendee ID needed
[16:08:06] <marcoil> ah, great
[16:09:12] <rdaiccherlb> We're currently discussing previously discussed (now resolved) items
[16:09:21] <qgil_> hm, I see participants and "arthur speaking" but no audio. Lemme see...
[16:10:05] <whatami> https://phabricator.wikimedia.org/maniphest/query/K9TVM696Wulv/#R
[16:10:06] <marcoil> cndiv: audio gets here really well, fyi
[16:10:19] <awjr> cndiv marcoil same here - ty :)
[16:11:01] <qgil_> ah, now it works
[16:11:47] <gnubeard> Audio over a T1 via webex web/native client is nominal. Crystal clear and I can hear all speakers.
[16:12:12] <subbu> i am on the phone and audio is fine here.
[16:13:14] <qgil_> https://phabricator.wikimedia.org/project/sprint/
[16:13:23] <qgil_> The project "§ Fundraising Dash" is not set up for Sprint because it has not been assigned a start date
[16:13:23] <qgil_> To do this, go to the Project Edit Details Page
[16:13:33] <qgil_> This is due to the Phabricator upgrade an hour ago
[16:13:33] <subbu> whatami, i joined late .. and what is the list of bugs that james is going over right now?
[16:13:42] <whatami> https://phabricator.wikimedia.org/maniphest/query/K9TVM696Wulv/#R
[16:13:49] <rdaiccherlb> https://phabricator.wikimedia.org/maniphest/query/K9TVM696Wulv/#R - they are the resolved issues from last week
[16:13:55] <whatami> It's bugs that were resolved a while ago.
[16:14:12] <whatami> Or yesterday, in other cases.
[16:14:23] <rdaiccherlb> We're taking comments on those bugs right now
[16:14:41] <qgil_> I mean, if you go to https://phabricator.wikimedia.org/tag/%C2%A7_visualeditor_q3_blockers/ and you click on the burndown link, this is the error message you get
[16:15:02] <subbu> thanks.
[16:15:34] <whatami> The task list is in https://phabricator.wikimedia.org/project/board/1015/ and James F is likely to take them in order from the first column.
[16:15:45] <qgil_> ah, https://phabricator.wikimedia.org/project/sprint/view/1015/ works. Sorry for the noise -- the burndown looks a lot better now!
[16:15:46] <rdaiccherlb> We're going to move onto Nominated Blockers Review
[16:16:00] <rdaiccherlb> Currently 16 nominated blockers here: https://phabricator.wikimedia.org/project/view/1015/
[16:16:33] <whatami> https://phabricator.wikimedia.org/T89072
[16:16:34] <rdaiccherlb> First item: https://phabricator.wikimedia.org/T89788
[16:16:45] <whatami> No, it's the 9072 item.
[16:16:54] <rdaiccherlb> sorry wrong link by me: follow whatami -s link
[16:17:27] <andre__> For the records, both https://phabricator.wikimedia.org/project/sprint/board/1015/ and https://phabricator.wikimedia.org/project/board/1015/ work, but the first link also shows points
[16:17:41] <andre__> (Sorry, we upgraded Phab an hour ago and some links changed and quite some UI)
[16:17:46] <gnubeard> I think katie has a delay.
[16:18:40] <whatami> https://phabricator.wikimedia.org/T88152
[16:19:10] <rdaiccherlb> THis has already been fixed in development, and so it's moving to accepted
[16:19:19] <whatami> https://phabricator.wikimedia.org/T89075
[16:20:05] <rdaiccherlb> This has been accepted as it bocks the objective of having properly tested code
[16:20:09] <whatami> https://phabricator.wikimedia.org/T89192
[16:20:42] <whatami> https://phabricator.wikimedia.org/T89309
[16:21:10] <whatami> https://phabricator.wikimedia.org/T89543
[16:21:12] <rdaiccherlb> Both of these have just been accepted
[16:21:23] <whatami> https://phabricator.wikimedia.org/T89423
[16:21:38] <whatami> 543 and 423 are being taken as a unit
[16:23:19] <whatami> https://phabricator.wikimedia.org/T89536 and https://phabricator.wikimedia.org/T89735
[16:23:53] <rdaiccherlb> Accepting both of these
[16:25:04] <whatami> https://phabricator.wikimedia.org/T89352
[16:27:00] <rdaiccherlb> Will be accepting
[16:27:04] <whatami> https://phabricator.wikimedia.org/T52036
[16:28:48] <rdaiccherlb> WIll be accepting but will be working on it a bit later
[16:28:51] <whatami> https://phabricator.wikimedia.org/T73085
[16:32:05] <rdaiccherlb> Provisionally accepted as a task to review but it may be complicated to implement
[16:34:28] <gnubeard> The feedback we are receiving on this call is that we should block. I think that it’s a good call to block.  :)
[16:34:31] <whatami> https://phabricator.wikimedia.org/T89788
[16:36:03] <Eloquence> qgil_, general process so far has been to accept things even if they're at the investigatory stage. we flag in the tasks that there are still open questions.
[16:36:38] <Eloquence> +1 gnubeard
[16:39:02] <qgil_> Maybe it was unclear what I was proposing: keep the task in "Nominated", but only move to "Accepted" tasks that we really believe are blockers and we will do our best to fix -- but OK, no stop energy here.  :)
[16:40:11] <whatami> qgil_, I understand your concern. It would be nice if nothing ever needed to leave the "Accepted" column. But I don't think that the devs look at the nomination column, and there isn't a special "maybe" column.
[16:40:14] <whatami> https://phabricator.wikimedia.org/T89072
[16:40:22] <whatami> https://phabricator.wikimedia.org/T89074
[16:40:30] <whatami> This is what Kaity's talking about.
[16:40:56] <qgil_> Creating a "maybe" or "needs investigation" column is trivial, if that is the problem...
[16:41:49] <gnubeard> qgil_: I understand. You were proposing to keep it as a nomination. In my experience, it’s better to empty the nomination queue every time you triage. Engineers will not be looking at the nomination queue. They will be looking at the blocker queue. If we want to find an answer that requires an engineer, it should live in the queue where engineers live.
[16:43:47] <qgil_> :D
[16:43:49] <gnubeard> heh
[16:44:14] <whatami> https://phabricator.wikimedia.org/T76398 will be next
[16:44:35] <rdaiccherlb> Please keep your church bells on mute, folks
[16:46:05] <gnubeard> I think this is really a question of whether or not we are at a point to accept relatively complex new features at this point.
[16:47:38] <Eloquence> -1 on a complex opening experience, +1 for simple tweaks to current dialog
[16:47:48] <gnubeard> I think that’s the right call, James.
[16:47:55] <awjr> +1
[16:47:59] <marcoil> 1
[16:48:02] <whatami> (Those were clock chimes, not church bells: https://en.wikipedia.org/wiki/Westminster_Quarters )
[16:48:11] <whatami> https://phabricator.wikimedia.org/T76398
[16:48:17] <whatami> https://phabricator.wikimedia.org/T76397
[16:48:22] <whatami> These are the last two.
[16:48:32] <awjr> kaity have you guys done user testing with prototypes or something on https://phabricator.wikimedia.org/T89074
[16:48:33] <awjr>  ?
[16:49:09] <kaity> awjr: yes initial testing with a prototype
[16:49:23] <kaity> looking to do more next week
[16:49:31] <whatami> I might be wrong, but I thought that one of the introductory tours was using (or planning to use?) VisualEditor at a Wikipedia where VisualEditor is already available to everyone by default.
[16:49:32] <awjr> kaity: nice - were you by chance able to get good data on the difference in the editing experiences?
[16:49:57] <rdaiccherlb> kaity I would love to talk with you about it further
[16:50:17] <kaity> rdaiccherlb: great!
[16:51:14] <awjr> kaity: im asking in part because one of the release criteria currently defined is 'Better task performance by users without editing experience compared with wikitext' - while 'better' is a bit ambiguous at the moment, i think that might be a good rubric by which to frame the feature with the data
[16:51:33] <whatami> That's the end of the list.
[16:51:46] <rdaiccherlb> We're taking any follow up feedback, questions etc
[16:51:53] <rdaiccherlb> in the last few minutes of the meeting
[16:51:58] <gnubeard> Dropping off the call, and I’m really happy with how these are going. I like that we’re listening to direct feedback.
[16:52:12] <kaity> its hard to get really scientific data on it but working with abbey to develop something
[16:52:15] <andre__> I don't manage to enable my audio, sigh.
[16:53:09] <andre__> My question is basically if folks went through the most popular complaints in past RfC's on en.wp and such for disabling VE and made sure that those complaints are on the blockers list.
[16:53:17] <andre__> (I think I basically stole this qustion from Quim)
[16:53:38] <kaity> awjr: initial testing was showing users who had never edited VE and asking them how confident they could do a few tasks
[16:53:45] <Eloquence> thank you James_F|Away  :)
[16:53:47] <rdaiccherlb> Thank you everyone
[16:53:49] <awjr> thanks James_F|Away :)
[16:53:52] <awjr> and everyone!
[16:53:57] <marcoil> thanks
[16:53:59] <kaity> then showed them the tour and asked them to rate their confidence on those same tasks
[16:54:02] <gnubeard> andre__: Will ask about your question.
[16:54:16] <qgil_> Thank you!
[16:54:32] <Eloquence> kaity, I think the tour is a good idea but I'm worried about the dev complexity at this time. and, we need to account for different user groups getting this dialog.
[16:54:32] <andre__> Hmm. Last time I could at least enable my microphone. This time even that didn't work...
[16:54:58] <Eloquence> the most obvious issue that I see with the first open experience right now is that the welcome dialog has way too much text and doesn't make it easy to switch back to wikitext if that's what you want to do
[16:55:00] <kaity> Eloquence: thats good feedback, thanks!
[16:55:25] <kaity> I think it should address the 2 edit buttons also
[16:55:43] <Eloquence> This is our new, easier way to edit. It's still in beta, which means you might find parts of the page you can't edit, or encounter issues that need to be fixed. We encourage you to review your changes, and we welcome reports about any issues you might encounter in using VisualEditor (click the "Help" button to submit feedback). You can switch to the wikitext editor at any time by clicking on the "Edit" tab, keeping any changes you have
[16:55:43] <Eloquence> made.
[16:55:55] <Eloquence> that's a lot of text :)
[16:56:34] <awjr> i bet especially when it's translated to something like german :p
[16:56:40] <kaity> yes we can improve that for sure
[16:56:41] <Eloquence> and the "switch to the wikitext editor" is textual instruction and not an actual part of the dialog