[00:02:53] jdlrobson: Should we move the config for $wmgRelatedArticlesShowInFooter to be a sub block of the $wmgUseRelatedArticles config? It really can't be used without RelatedArticles right? [00:03:24] bd808: probably yeh [00:03:31] k. I'll amend [00:03:34] the latter does have to be true [00:03:35] thanks bd808 [00:04:04] Should $wgRelatedArticlesShowInSidebar always be false in that case too? [00:04:19] (when showing in footer I mean) [00:06:39] correct bd808 [00:06:56] since UseRelatedArticles is required to install the extension [00:07:24] and lives outside the extension [00:08:41] jdlrobson: https://gerrit.wikimedia.org/r/#/c/257434/4/wmf-config/CommonSettings.php,unified [00:22:22] bd808: +1 looks good :) [00:28:28] jdlrobson: I found out that thcipriani is running the train tomorrow rather than Mukunda [00:28:39] yup i got a reply from him :) [00:28:44] cool [01:00:28] o/ [01:04:48] Hi niedzilski-afk , any chance that you're around? [01:04:53] Whoops [01:05:10] niedzielski-afk [01:05:13] bmansurov: heya [01:05:23] hey! [01:09:58] bmansurov: i did most of the work for the deplyoment tomorrow [01:10:16] are we SWATting? [01:10:22] it will ride the train tomorrow [01:10:32] cool [01:10:33] have sent all necessary emails and prepared all necessary patches - all documented in ticket [01:10:48] we need to be around at 9am PST tomorrow in wikimedia-operations to ping twentyafterfour [01:10:54] in case we need a follow up [01:10:58] will you be around? [01:11:11] yes [01:11:19] i'll ping him too [01:23:02] Can someone run me through the process of testing the iOS beta? [01:23:42] JoshM mhurd bgerstle_afk coreyfloyd ^ [01:30:47] Never mind, I figured it out. I've still got iTunes Connect credentials, so I just added myself to the internal alpha. :) [01:31:45] the beta of the os? [01:31:58] Reedy: No, the Wikipedia app. [01:32:46] Is 5.0.0.535 the latest one? [01:33:56] Deskana: just heading out - josh or brian can prob answer any questions about the testing build bits in the morn [01:34:28] Deskana: brian's been wrangling testing build stuffs [01:35:30] mhurd_afk: Thanks. :-) [01:39:33] It'd be good to know if this is the right version to test before I do lots of testing, so if someone could let me know at some point, I'd appreciate it. :) [01:41:18] Deskana it's probably best to wait until we send another email, which will describe what's new [01:41:22] As wells [01:41:53] As well as* designate the version you should test (sorry on mobile) [01:44:07] bgerstle_afk: Okay, sounds good. I found a number of bugs already, so I'll wait to see if those are fixed. :-) [01:48:00] josephine_l: hey! sorry, i was out early today at a car appointment but i'm back now :) [01:48:40] niedzielski: It's all good, don't worry :) Could I chat with you for a moment about the MediaWiki API? [01:48:56] josephine_l: sure. on here or hangout? [01:49:01] (either is fine) [01:49:15] Haven't set my mic up, so here is faster I guess [01:49:36] ok cool. what's up? [01:50:04] Um, you linked to it in my task with the comment "For reference, I think I mentioned that the Wikipedia app uses geosearch[0][1] but I don't think it will work well for your needs since it gives pages. [01:50:04] [0] https://commons.wikimedia.org/wiki/Commons:API/MediaWiki#Retrieve_files_given_a_pair_of_coordinates_.28latitude.2C_longitude.29 [01:50:33] For the second API that I'm testing, we were talking loosely about it being "Commons API" [01:50:49] But the actual Commons:Commons API doesn't seem to be suitable at all [01:51:09] I think it was meant for obtaining information on pictures that already exist on Commons and whose filename is already known, not for searching for categories. [01:51:28] So I'm now looking at the Commons:API/MediaWiki, which is what you linked [01:52:05] josephine_l: ok that all makes sense [01:52:17] But the geosearch on this one doesn't seem to return Commons categories, only pages [01:52:29] Do you know if there's a way to make it return Commons categories instead? [01:52:41] josephine_l: can you see what categories a set of pages belongs to? [01:53:25] Sorry, not sure what you mean by a 'set' of pages? [01:54:28] josephine_l: so the problem with the api the wikipedia app uses is that it returns pages, not categories. it's not ideal, but could make a request for pages and then look at the categories common to them? [01:55:17] josephine_l: (i'm digging in now) [01:56:27] niedzielski: Thanks. I honestly don't know how that would work, as I am not very familiar with it. Based on the documentation that I have read so far I can't see a way to do that, but I might just be missing something. [01:58:57] I also posted a StackOverflow thread asking about it yesterday, but no bites so far :/ [02:00:50] josephine_l: ok great! i'm going through the documentation and trying some things in the api sandbox. it looks like spagewmf wrote a nice article about the app's nearby functionality which is the request i mentioned earlier. i wanted to explore that a little bit more and see how it could be used with commons. https://www.mediawiki.org/wiki/API:Show [02:00:50] ing_nearby_wiki_information [02:02:13] niedzielski: Thanks! Reading that now [02:11:25] niedzielski: I tried, using the sandbox, searching within the "Category" gsnamespace, but that doesn't return anything so I guess it doesn't mean what I thought it would [02:13:39] josephine_l: hm, i was just trying to make a similar request as we do in the app on commons but it's empty too: /w/api.php?action=query&list=geosearch&format=json&gscoord=40%7C-105&gsradius=10000&gslimit=10 [02:15:40] josephine_l: i think it's because everything is organized by categories [02:16:02] K, thanks Deskana! [02:16:59] niedzielski: Ah, okay. So there wasn't a need for the 'search for Commons categories' functionality in the MediaWiki API GeoData extension before this I guess [02:18:05] josephine_l: the functionality could well be there and i just don't know it yet. i'm still looking :) [02:19:45] niedzielski: Haha, okay. Me too. :) [02:20:08] josephine_l: for example, the commons page for mt rainier doesn't appear to have a geolocation: https://commons.wikimedia.org/wiki/Mount_Rainier [02:20:18] josephine_l: the wikipedia page does https://en.wikipedia.org/wiki/Mount_Rainier [02:24:12] niedzielski: Yeah, many Commons categories don't have a geolocation, I think Nicolas said that that might turn out to be an issue. But many of them also do, the WikiData API that I tested finds Commons categories quite well for many of the samples [02:29:23] josephine_l: so if i use wiki data (continuing looking around mt rainier), i get something like https://tools.wmflabs.org/wikidata-todo/tabernacle.html?wdq=claim%5B373%5D%20AND%20around%5B625%2C38.11386944444445%2C13.356263888888888%2C0.1%5D&pagepile=885&props=373%2C625&items=&show=1 [02:31:03] niedzielski: The permalink you sent me goes to the results with Cathedral (Palermo). I don't think you can reuse permalinks in tabernacle, I think you have to go to a fresh page and then select permalink from there. :) [02:32:12] josephine_l: https://tools.wmflabs.org/wikidata-todo/tabernacle.html?wdq=claim%5B373%5D%20AND%20around%5B625%2C46%2C-121%2C40%5D&pagepile=885&props=373%2C625&items=&show=1 [02:32:41] niedzielski: Is there a reason we are using 40km as the radius? [02:33:11] josephine_l: but i see this picture on the mt rainier page does have some geolocation data associated with it https://commons.wikimedia.org/wiki/File:Mount_Rainier_Hazard_Map-en.svg [02:33:34] josephine_l: so i kind of wonder if a lot of the categories don't have geodata we should use file pages instead? [02:33:46] josephine_l: oh, the 40km was arbitrary [02:35:54] niedzielski: I think the 3rd strategy we test is supposed to be looking for pics with similar coordinates and then pulling out their Commons categories. Similar to what you described with the Mt Rainier Hazard Map pic [02:36:13] josephine_l: ok so maybe something like what they use here https://tools.wmflabs.org/wiwosm/osm-on-ol/commons-on-osm.php?zoom=16&lat=46.8531&lon=-121.76 [02:36:37] But yeah, I'm actually not certain why we can't use pages instead of categories. Nicolas was adamant on it being categories and not pages, so we have to chat with him about it first I guess [02:36:56] josephine_l: if we have a list of pages, surely we can get the categories for those pages [02:38:36] niedzielski: Sorry, I'm not familiar with Commons on OSM, is that a photo visually shown at its geolocation? [02:39:51] Ah, okay. So I might try accepting pages when testing the APIs, then later programmatically extract the categories for those pages? [02:40:02] josephine_l: oh, i'm not either :) it looked like a list of file pages that have coordinates listed [02:40:30] josephine_l: that was one approach i was thinking. it might take multiple requests if there's not a built in api for it [02:41:13] so if you found 25 images near a given location, you could list the categories in kind of a word cloud ui with the repeated categories more prominent [02:41:53] niedzielski: Oh, sounds cool. :) [02:42:50] Sorry if this is a newbie question, but when we query MediaWiki for pages, is there a way to specify that the page is an image page and not an article page? [02:43:17] Or does it not matter much whether we get an image or article, if we're extracting the categories anyway? [02:45:35] josephine_l: i'm not sure offhandedly. that seems to be what's going on the osm map i linked to (all those are special pages). in the app, when we do a search we request an article title and thumbnails but they're not in the File namespace. [02:47:11] niedzielski: Ah, okay. Where do you think I should go from here? I am a bit lost at how to proceed. :) [02:47:31] josephine_l: maybe gsnamespace=6? i'm not sure how you would limit it to image files only though [02:51:11] niedzielski: Is that the 'file' namespace? [02:54:56] josephine_l: yeah, i was trying to use it with the geo query from earlier but that doesn't seem to work :| [02:55:26] niedzielski: Haha yeah, was going to say I didn't get any results :/ [02:55:27] josephine_l: seems to work with user pages though :) [02:55:37] gsnamespace=2 [02:57:49] niedzielski: Is this for Mt Rainier (46|-121) > [02:57:51] ? [02:58:09] josephine_l: those aren't the exact coordinates but the general area [02:59:09] niedzielski: Odd, searching for namespace "user" on those coords gives me nothing. Maybe I'm doing it wrong. Let me link my search [02:59:56] josephine_l: oops, looks like i was using 37.786952|-122.399523 for users [03:00:13] https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&list=geosearch&prop=categories&format=json&gscoord=37.786952%7C-122.399523&gsradius=10000&gslimit=10&gsnamespace=2 [03:01:51] niedzielski: Oh, okay, that does pull up users, thanks. :) How do we use those though? [03:02:25] josephine_l: oh i was just trying it with a different namespace to see how it worked. i don't think we'll use it [03:03:01] niedzielski: Ah, okay. [03:07:15] niedzielski: Is it okay if I copy this chat and send it to Nicolas before our next meeting? I think we covered quite a lot of ground here so it might help bring us all on the same page next time we talk [03:07:42] josephine_l: sure. it's all logged publicly anyway :) [03:07:53] niedzielski: Oh! Didn't know that :) [03:08:00] http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-mobile/ [03:08:25] Hahahah [03:09:10] niedzielski: Speaking of which, I haven't heard back from Nicolas about the potential Tuesday meeting, I guess it's too close to arrange that now, and we've talked here anyway? [03:09:24] josephine_l: there used to be a really nice botbot install up here but it's been down a while: http://botbot.wmflabs.org/freenode/wikimedia-mobile/ made browsing the logs fun [03:09:48] What's a botbot? [03:11:44] josephine_l: here's an example that's up https://botbot.me/freenode/racket/ it's just for browsing logs. no communication functionality so far afaik [03:12:10] josephine_l: isn't the meeting in 3 hours? [03:12:56] niedzielski: I would hope so but I haven't received confirmation from Nicolas I think? Did you? [03:13:17] josephine_l: oh, no. i was thinking i'd just see if he showed up or not [03:13:33] josephine_l: but it's fine to reschedule too [03:13:52] niedzielski: Sounds good to me if you don't mind hanging around to see, I can do that too :) [03:14:21] Today would definitely be best since I'm a bit unclear about the direction we should go in and it would be best if all 3 of us could agree on it [03:14:32] josephine_l: yeah, np. i was just going to play around in the sandbox and docs to see what's available [03:15:46] niedzielski: Thanks so much! It's been very helpful. :) I should really read more of the docs as well, I was wanting to talk to you first to see if the API had potential for our requirements or if I should go in a totally different direction [03:16:22] I can do that now and we'll meet here in about 2hrs 45min to see if Nicolas is around? [03:18:24] josephine_l: oh, i'm not an mw api expert yet :) if we can nail down a little bit more specific questions, then we can email the list or go to the mediawiki channel. i personally wanted to spend a bit more time in the related apis before engaging a larger audience but yeah, definitely want to get you unblocked [03:18:32] josephine_l: sounds good [03:20:47] niedzielski: Actually Week 2's task is not dependent on this week's one I think. I can try to do both concurrently, which gives more time for exploration, if you and Nicolas approve that. [03:23:48] josephine_l: i've no objections. i just say update the board so the card is in doing. we'll hit up nicolas when he gets on [03:25:16] niedzielski: Okay, see you then! :) [03:25:51] see ya! [04:55:00] https://etherpad.wikimedia.org/p/commons-app-android-nearby-categories [05:42:53] Sorry I missed your message, niedzielski. Is that like a Google Doc? [05:53:01] josephine_l: yeah, kind of an open source, flaky google doc :) [05:57:29] niedzielski: Oh, magnus manske! He was the guy who answered Nicolas' question on StackOverflow suggesting WikiData I think - http://opendata.stackexchange.com/questions/6133/api-to-get-wikimedia-commons-categories-that-are-near-a-particular-latitude-long [05:57:50] err, I mean he answered Nicolas' Q about which API to use, and suggested WikiData [05:59:33] nice! [06:00:51] Also I think the WikiData API literally returns Commons categories via use of the property id 373, it doesn't just return WikiData categories [06:02:40] josephine_l: that might be the way to go. so far i'm kind of partial to at least including the file namespace search since that includes all image categories in the area [06:03:03] josephine_l: for example, the category has no geodata but an image does [06:03:13] josephine_l: but maybe that will hurt as much as it helps? [06:03:51] josephine_l: btw, feel free to edit the etherpad with whatever findings you uncover. i've just put a few notes in there [06:05:09] niedzielski: I think that is what the Strategy#3 - "Existing pics at that location" is supposed to do. [06:06:59] If I'm not mistaken at least [06:08:21] Ah, why are my edits a bright magenta lol [06:08:58] Found it, much better now :) [06:10:24] ha :) [06:12:43] niedzielski is that etherpad doc stored at that URL long-term? [06:13:59] josephine_l: the url remains constant. i'm not sure if pads are ever deleted intentionally by the system. i have some that are about 6 months old so i think they're meant to be preserved [06:14:24] josephine_l: i've heard they're vandalized from time to time [06:14:33] oh, lol :/ [06:16:20] niedzielski: What's the difference btwn Wikipedia categories and Commons categories btw? I never fully understood it. But it seems that your example at (A) is retrieving Wikipedia categories [06:17:17] josephine_l: they should be commons categories i thought [06:18:09] josephine_l: for example, File:ATCbuilding.JPG is a member of the commons category Category:American Tract Society Building 150 Nassau Street [06:18:22] josephine_l: https://commons.wikimedia.org/wiki/Category:American_Tract_Society_Building_150_Nassau_Street [06:18:50] niedzielski: Oh okay! So if we're searching for image files then their category is automatically a Commons category? [06:19:49] josephine_l: i think so. we're searching the Commons MediaWiki. the prop=categories parameter provides categories on that MediaWiki installation which happens to be Commons AFAIK [06:20:33] niedzielski: Oh the sandbox works for the Commons MediaWiki endpoint in the same way! [06:20:41] Hello! :-) [06:20:42] josephine_l: for example, if i set up my own wiki, then i'd expect the categories returned to point to it [06:20:48] Nicolas_Raoul: hey! [06:20:53] Hi Nicolas_Raoul! Glad you could make it :) [06:21:01] Sorry for the delay! [06:21:12] no worries :) [06:21:23] * Nicolas_Raoul checks the log [06:21:27] No probs at all [06:21:58] niedzielski: I just realized I have been using the wrong endpoint for API sandbox this whole time... [06:22:42] josephine_l: :) that'll do it. each wiki is neat in that they all have their own special pages that operate on that wiki [06:23:04] Very interesting, thanks [06:24:36] Are you using video, or all IRC? [06:24:55] Nicolas_Raoul: we're just on irc right now [06:25:01] OK! [06:25:36] Nicolas_Raoul: i've forced an etherpad on josephine_l here: https://etherpad.wikimedia.org/p/commons-app-android-nearby-categories [06:26:05] (i was having some difficulty summarizing all the phab and irc back and forth :) [06:26:56] The etherpad isn't too bad :) [06:27:00] I've put my own edits into it [06:27:17] What does "Doesn't consider Image files." mean? [06:27:49] Nicolas_Raoul: for example, a File page might refer to an audio file or a video file, not necessarily an image file [06:30:01] But don't we want categories anyway? Does the query response return files as well? [06:31:26] Nicolas_Raoul: Yes but unfortunately the Commons MediaWiki API does not seem to be able to directly return categories [06:31:28] Nicolas_Raoul: it happens to returns page titles, File pages in this case, in addition to their categories. Their might be a way to suppress the title output that we can look into later. [06:33:45] josephine_l Nicolas_Raoul: yeah, i tried the category namespace but it always comes back empty for the geosearch generator [06:34:54] josephine_l Nicolas_Raoul: i could just be doing it wrong though. do Commons categories have geolocation? [06:35:33] They do, but my search for the category + geosearch on the sandbox always turns up empty too [06:35:35] some of them, but not many, as you know [06:36:07] niedzielski All of the categories I found via WikiData at https://github.com/nicolas-raoul/apps-android-commons/wiki/Location-based-category-search for instance have geolocation I think [06:36:11] josephine_l Nicolas_Raoul: maybe i'm just not looking near the right lat / lng [06:36:47] niedzielski I tried with the exact same lag/lng I used in the WikiData tests and they came up empty [06:36:58] But I might have some of the other parameters wrong [06:37:33] What method are you trying to build the request for right now? [06:37:47] A, B, C, Cbis? [06:37:51] https://commons.wikimedia.org/wiki/Special:ApiSandbox for MediaWiki Commons API [06:38:14] https://tools.wmflabs.org/wikidata-todo/tabernacle.html?wdq=&pagepile=885&props=373%2C625&items=&show=1 for WikiData [06:41:01] Have you tried method C? It sounds like the most promising, the drawback being that it takes more requests. [06:41:23] Nicolas_Raoul Not yet. Should I skip MediaWiki API for now and go straight to that then? [06:41:41] Is it doable non-programmatically? [06:42:17] Or will I be doing that using the MediaWiki API on the Commons endpoint, just a different query? [06:43:01] yes, just a different query [06:43:14] isn't method c just https://commons.wikimedia.org/wiki/Special:ApiSandbox#action=query&prop=categories&format=json&generator=geosearch&ggscoord=40.7127%7C-74.0059&ggsradius=10&ggslimit=5&ggsnamespace=6&ggsprimary=all [06:44:37] Ah yes that's it! So only 1 request, great :-) [06:44:48] Oh, okay! I can do that then :) [06:45:18] Lol, sorry niedzielski, copy pasted at the same time [06:46:08] "Not that many pages in some areas." <- Anyway if there are no geolocalized files in an area, chances are there are probably no categories either [06:46:36] Another question: What radius should we use? [06:46:44] if there are so few categories, it might not be worth doing both a category request and method C. if there are many categories, it might be worth doing both [06:47:00] Decreasing radius decreases chances of finding right category, but increasing radius increases false positives [06:47:01] I NYC a small radius is OK, but in Canada we would need a larger one :-) [06:47:26] results != good results :) [06:47:27] How about starting with a small one, and increasing if needed? [06:49:06] Start with 0.1km and go to 1, 10, etc? [06:49:29] Is there a way to know the number of results? [06:49:48] Besides manual counting? [06:52:20] hm, you mean just return the total number of results without any other data? [06:54:22] My 2yo cousin is playing with my keyboard [06:54:36] lol [06:55:18] hahah [06:55:40] yes if the API told us "there are 7398 results for this query" we would know that we can afford a smaller radius [06:56:57] I only see a "continue" JSON paragraph which tells us there are more results, but apparently we don't know how many more [06:58:32] btw, not sure what __HIDDENCAT__ is but it sounds like something we can safely hide. [07:01:08] Not as far as I know of for the WikiData one [07:01:49] Oh wait, there is [07:02:10] The only problem is that WikiData, or at least the tool I use to build the query, doesn't ever return 0 [07:02:19] So if your search is too narrow, it's stuck at 'Loading' forever [07:02:41] But if your search is too wide it's stuck at 'Loading' for like 2 minutes before it brings up "15421 items" [07:03:26] the search api has a totalhits option. i don't think geosearch does [07:03:47] ^ method c [07:07:16] josephine_l Nicolas_Raoul: i gotta go to sleepy times soon. josephine_l do you have what you need to keep going? [07:07:43] niedzielski I think so, I can definitely try to run method C tomorrow [07:07:59] We can continue to discuss the radius issue via email later on maybe? [07:09:38] I'll populate the GitHub wiki with links of my Method C searches and then we see how it goes? [07:09:46] josephine_l: sounds good. i think a worst case scenario for the radius would be to just add a slider bar. it'd be pretty neat if we could search for more popular categories first but i don't think we have that option. maybe we can do some things with reverse geocoding a city name to add a title parameter when the result set is large [07:11:11] niedzielski The Commons app already limits the no. of categories that show up in a search I think, for performance reasons. But maybe I'm misinterpreting what you mean. :) [07:12:09] It must be awfully late there. Go to bed, I'll email you guys when I hit the next snag :) [07:13:15] Good night niedzielski! [07:13:45] Bye niedzielski! [07:14:02] Nicolas_Raoul I should head off soon too. It's 8.13pm and haven't had dinner. [07:14:09] josephine_l: hm, i'll have to take another look. sounds good [07:14:20] josephine_l Nicolas_Raoul: have a good one! :) [07:14:27] for the method C part of the wiki, let's first try with manual optimal radius finding maybe? [07:14:53] Nicolas_Raoul I'll just try a few radius and compare the results? [07:18:09] yes why not! [07:19:35] Is 0.1km, 1km and 10km ok to try? [07:20:14] And should I go back and record the results of those radius for WikiData or we'll just try that with Method C first? [07:29:04] Nicolas_Raoul, you still there? :) [07:29:11] Yeah, these radiuses, plus maybe manually find the optimal radius [07:30:33] Okay, will do. I'll try that with Method C tomorrow and I'll link my results on the GitHub wiki [07:30:47] or better: specify a large ggsradius and a large ggslimit, then sort the results by their distance to the point, and only then take the 5 closest [07:31:16] (even then, several radiuses will probably be needed depending on the area) [07:31:40] Hrmmm. Okay, I'll try and see if I can do that. [07:32:53] If there's nothing else, I'll head off for now? Dinnertime. :) [07:40:47] Nicolas_Raoul: hi! o/ [07:40:58] Hi! :-) [07:41:03] How are you doing? [07:41:37] great, just hanging around here, and continuing to learn stuff :) [10:00:59] o/ [11:13:21] will be back online later [16:08:10] * dbrant waves to niedzielski [16:09:40] niedzielski: I don't think the IndexOutOfBounds issue is a blocker for release. It's not a regression; I just pulled it from HA because it's a relatively high-occurence crash. But we can leave it for now. [16:09:47] i know it's a pain in the ass. [16:10:24] dbrant: ok cool. then i think i really want to nail down is why ha reports aren't coming for v135 [16:10:44] o/ [16:12:04] niedzielski: what do you mean? [16:13:16] dbrant: i should be seeing those tsg nearby crashes and the test crashes under the production wikipedia app (they test against -r-) [16:13:43] niedzielski: oh! right... [16:13:48] dbrant: but i'm not. even with dev builds on version code 135, nothing is being recorded but the "transmission is sent" according to the logs [16:16:32] dbrant: er, i take that back. dev crashes from yesterday are now there but i swear they weren't yesterday... [16:59:24] kristenlans: I don't have rights to view the doc :( [17:04:05] niedzielski: when checking those Crash tickets yesterday - I got two "An unknown error..." : 1) in Nearby when Location services are disabled (filed) 2) when flipping too quickly through large Image Gallery (not filed) [17:04:16] niedzielski: and I have two questions :)) [17:04:48] etonkovidova: the unknown error in images is probably OOM (would need to check logcat) [17:04:56] niedzielski: 1) is there any additional info on those Unknown errors in logs? 2) should we be concerned? [17:05:33] etonkovidova: what version of the app were you testing? [17:05:50] niedzielski: yesterday's alpha build [17:06:25] etonkovidova: generally speaking, we only track _crashes_ but i'll take a peek [17:07:16] etonkovidova: our last crash on alpha was december 2nd but we've been having trouble with reporting in the latest build. i'll let you if we see anything new [17:07:43] niedzielski: thx! I was not too sure about those unknown errors... [17:11:25] * bd808 is being forced to listen to clubbing music in a hangout and cries out for help [18:07:03] bd808: now you feel my pain [18:08:03] jdlrobson, bmansurov: still not feeling 100%, so I'm gonna be offline for a couple hours and work again later tonight to break things up [18:08:15] ok, get well soon, jhobs [18:09:57] thanks bmansurov, I just know there's been a lot of strep (https://en.wikipedia.org/wiki/Streptococcal_pharyngitis) going around in my area so I'm just hoping it's not that [18:13:16] ohh, that's too bad. [18:15:14] later, dudes [18:47:36] dbrant: niedzielski bearND mdholloway for that wikipedia zero exit interstitial piece for q3, a small change to mw w0 api.php will be required. would any of you guys specifically be interested in trying to tackle this php? [18:47:52] [not it] [18:49:13] dr0ptp4kt_: i'm up for it, unless someone else has a hankering to write some php [18:49:22] i like the wording "probably doable by an android 'engineer'" [18:50:00] niedzielski: :) [18:52:05] dbrant: hey! i'm looking at your tofragment patch and i think i'm missing something. what's a good test to see it in action? i was thinking if i searched for "Uses of the proper distance" and tapped on the hubble's law article it'd take me to that section but it doesn't [18:52:10] ok, it sounds like mdholloway is the victor of this responsibility. mdholloway lmk when you're ready to get some grounding in the material. [18:53:58] dr0ptp4kt_: cool, how about if i put something on your calendar for after your 1:1 with toby? i should have the finishing touches on this wiktionary popup about wrapped up by then [18:54:20] mdholloway: that's cool. also cool is in january. seriously, either way is good. [18:55:27] niedzielski: there's an example in the task description. This handles the case when Prefixsearch results give you a redirect target with a fragment. In the case you mentioned, it's a full-text search result, and those don't contain the specific fragment (although they really should). [18:55:55] dr0ptp4kt_: hmm, yeah, if it's a q3 task maybe makes more sense to wait until then [18:56:33] mdholloway: sounds good. schedule away... [18:56:35] dbrant: i had tried searching for "jingle bells batman smells" but it didn't seem to work. i'll try again with proper casing this time [18:56:37] ...to january [18:56:52] niedzielski: need a comma, too ;) [18:57:24] dbrant: ok that works :) [18:58:57] dr0ptp4kt_: should we talk about it when i'm onsite for all hands or is that week going to be busy with other things? [19:01:45] * dr0ptp4kt_ mdholloway: you can schedule for wednesday of that week. invite jhobs and yurik, too, as Optional (where Optional = pleeease, pretty please) [19:03:44] mdholloway: did that last message go through? [19:03:51] dr0ptp4kt_: yep, got it [19:03:51] apparently cmd+enter makes things italic [19:03:57] * dr0ptp4kt_ test [19:04:11] mdholloway: hmm, i didn't expect that. so used to cmd+enter from emailing [19:04:15] * mdholloway 10-4 [19:04:16] the italicizing [19:04:37] mdholloway: dbrant niedzielski bearND i'll follow up on reading-wmf [19:05:37] ok cool :) [19:06:17] cool. still trying to fix the reference to "probably doable by an android 'engineer'" [19:06:59] but thanks to mdholloway for volunteering [19:32:53] FlorianSW: How do I replicate this issue? I'm on desktop Minerva and clicking watchstar before your patch and seeing no issues... https://gerrit.wikimedia.org/r/256966 [19:36:36] worked it out [20:27:15] dbrant: ok the ha stuff is sorted and i think all the bugs and patches scoped are resolved. 1) is there anything else we wanted to get in the beta? 2) do we want to cut today or tomorrow? [20:29:17] i guess we're still waiting on some follow ups from tsg [20:29:22] niedzielski: i'd like to give the IndexOutOfBounds one more try myself. How about first thing tomorrow? [20:30:01] dbrant: sure. sounds good. i recommend trying from the appropriate git tag so the ha reports line up [20:30:25] yep, good point [20:35:29] jdlrobson: thx for review [20:35:47] I imagine yesterday was fun time after four weeks of code freeze [21:07:10] bearND|afk mdholloway: hey! have you guys noticed any signs of the rollout? [21:08:27] niedzielski: bearND|afk has tested it from prod and my understanding was that it was working; haven't specifically looked into it myself yet, though, since i've been focused on the wiktionary popup. [21:09:20] mdholloway bearND|afk: ok cool. i haven't seen any spike in ha and was curious if any event logging or pageview analysis had been done [21:09:50] niedzielski: not yet on my end. [21:13:29] niedzielski: mdholloway: bearND|afk: i was just browsing through eventlogging, and we're definitely getting incoming events (session data with RB latency numbers). [21:14:00] nice! [21:32:26] sorry guys, had to bring the kids to the dentist [21:32:51] :) [21:33:29] dbrant: thanks for checking EL. Is there a way to see how much latency improves (average)? [21:33:52] like for the same clients before and after the switch to RB [21:34:41] mdholloway: i did not test with the prod app (if that's what you mean) since the roll out is just for beta. [21:35:52] bearND: yep, i meant prod content service [21:35:55] bearND: So far, the average latency (to get the lead section) for MW is 926ms, and for restbase it's 1160ms. [21:36:43] mdholloway: ah, ok [21:37:27] dbrant mdholloway bearND: is that expected to drop as the cache gets populated? [21:37:45] dbrant: hmm, that's a bit surprising. [21:38:21] niedzielski: yes, good point [21:39:25] afaik storage isn't prepopulated yet [21:40:07] gwicke: that's correct. Once a page gets requested a second time (and it hasn't changed since) it should be much faster [21:40:47] gwicke: do you have any metrics to share on the server side we should be watching for the service? [21:41:45] the top 10 entry points are available at https://grafana-admin.wikimedia.org/dashboard/db/restbase?panelId=15&fullscreen [21:41:51] also client side there should be an improvement by doing fewer client side DOM transformations [21:42:13] mobile doesn't make it in there yet [21:42:34] we are already pre-populating the summary end point [21:43:53] I'll check with Marko on why we aren't doing the same for lead sections yet [21:44:32] public version of the same graph: https://grafana.wikimedia.org/dashboard/db/restbase?panelId=15&fullscreen [21:46:22] so, summary is the second highest. That's strange. I thought we were the only ones using it so far [21:47:06] gwicke: ^ [21:47:29] that's mostly updates [21:47:55] we need to separate those out to more clearly see client requests to those end points [21:48:32] gwicke: where to you see what is a GET vs POST/PUT? [21:49:05] mdholloway dbrant /cc bearND: just to confirm, the wiktionary changes aren't intended for our last build (tomorrow), right? [21:49:07] gwicke: actually the string does have GET in the name [21:50:04] restbase.v1_page_summary_-title-.GET.ALL.sample_rate [21:50:16] niedzielski: i was assuming not. /cc dbrant [21:50:18] niedzielski: nope [21:50:20] yeah, but the updates are also GETs [21:50:34] we are just discussing enabling pre-generation / updates in -services [22:14:36] jdlrobson, sorry, forgot to mark me as away :( I see, the change is merged? Did you managed to replicate the issue? :) [22:17:47] FlorianSW: yup no problemo [22:40:21] kaity_: hey! quick question on https://phabricator.wikimedia.org/T120400 . what is bookmark-outline.svg used for? [22:45:10] jdlrobson, do you really think, that https://phabricator.wikimedia.org/T120443 is a GCI task? [22:46:04] where do you think adding the related article part into would be a good idea? :) James_F|Away posted, that he would choose contentSub, which seems a bit misplaced, because this is directly after the title, iirc :/ [22:47:15] niedzielski: bookmark outline is used for save [22:47:39] niedzielski: in the mock from left to right its Save, Share, Navigate [22:47:42] kaity_: oh, of course! :) nice! [22:48:09] niedzielski: then "bookmark" not outline is if the article has been saved [22:48:37] niedzielski: I was thinking i might make a separate ticket for that, since save will be an action and a state? [22:50:09] kaity_: since the functionality already exists in the menu and T120400 is to move it, i think that card should cover it [22:50:24] niedzielski: ok great [23:02:51] bd808: doing the meeting room shuffle [23:22:55] mdholloway: first screenshots of wikitionary look awesome! [23:23:09] kaity_: thanks! [23:23:28] mdholloway: impressed that you guys could parse through all the unstructured stuff on wiktionary pages [23:24:09] mdholloway: trying to find the book icon that you mentioned we already use for fair use.. [23:24:32] mdholloway: its this one right? https://materialdesignicons.com/icon/book [23:26:05] kaity_: yep, that's the one i was thinking of