[00:00:41] milimetric: btw, https://phabricator.wikimedia.org/T101447 - of the 18 remaining ldap variables, 5 are from wikimetrics :) [00:00:53] we want to kill the LDAP variable functionality too soon (hiera replaces it) [00:43:15] milimetric: YuviPanda I haz working fab setup - lots of room to change - but first iteration. Serves http://edit-analysis-test.wmflabs.org/compare/ and http://language-reportcard-test.wmflabs.org/ [00:43:27] \o/ nice [00:49:01] (PS1) Madhuvishy: [WIP] Setup fabric to deploy dashboards powered by dashiki [analytics/dashiki] - https://gerrit.wikimedia.org/r/259437 (https://phabricator.wikimedia.org/T110351) [01:41:27] (PS2) Madhuvishy: [WIP] Setup fabric to deploy dashboards powered by dashiki [analytics/dashiki] - https://gerrit.wikimedia.org/r/259437 (https://phabricator.wikimedia.org/T110351) [01:43:42] (PS3) Madhuvishy: [WIP] Setup fabric to deploy dashboards powered by dashiki [analytics/dashiki] - https://gerrit.wikimedia.org/r/259437 (https://phabricator.wikimedia.org/T110351) [01:49:46] (PS4) Madhuvishy: [WIP] Setup fabric to deploy dashboards powered by dashiki [analytics/dashiki] - https://gerrit.wikimedia.org/r/259437 (https://phabricator.wikimedia.org/T110351) [02:21:21] (PS20) Madhuvishy: Setup celery task workflow to handle running reports for the ProgramMetrics API [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/253750 (https://phabricator.wikimedia.org/T118308) [03:33:26] Analytics-Backlog, Wikimedia-Developer-Summit-2016: Developer summit session: Pageview API overview - https://phabricator.wikimedia.org/T112956#1883728 (RobLa-WMF) I'm going to copy in a comment from {T119593} and then reply here, since I think this is a better context for a discussion: >>! In T119593#... [08:38:31] o/ [09:11:06] hi elukey [09:11:08] welcome :D [09:22:59] thanks! o/ [10:42:56] Analytics-EventLogging, EventBus, Wikimedia-Logstash, Patch-For-Review: eventlogging syslog message not properly recognized by logstash - https://phabricator.wikimedia.org/T120874#1884120 (hashar) @Ottomata congratulations and figuring out rsyslog was trimming the program name when emitting the me... [10:47:57] Analytics-EventLogging, EventBus, Wikimedia-Logstash, Patch-For-Review: eventlogging syslog message not properly recognized by logstash - https://phabricator.wikimedia.org/T120874#1884138 (hashar) a:Ottomata [10:48:15] Analytics-EventLogging, EventBus, Wikimedia-Logstash, Patch-For-Review: eventlogging syslog message not properly recognized by logstash - https://phabricator.wikimedia.org/T120874#1884139 (hashar) Open>Resolved Looking at the rsyslog conf with `salt -v '*' cmd.run 'grep syslogtag /etc/rsyslo... [10:48:24] Analytics-EventLogging, EventBus, Wikimedia-Logstash, Patch-For-Review, Wikimedia-log-errors: eventlogging syslog message not properly recognized by logstash - https://phabricator.wikimedia.org/T120874#1884141 (hashar) [11:05:24] Analytics-Tech-community-metrics, DevRel-December-2015, Patch-For-Review: Review/update mailing list repositories in korma - https://phabricator.wikimedia.org/T116285#1884173 (Aklapper) @Lcanasdiaz: Sorry, we had NFS hardware issues. [[ https://lists.wikimedia.org/pipermail/labs-l/2015-December/004178.... [14:56:38] ottomata, o/ is there any action needed in the raw_webrequest missing data? It's my ops-duty week [14:57:15] mforns: hm, we should probably add an entry here [14:57:16] https://wikitech.wikimedia.org/wiki/Analytics/Data/Webrequest#Changes_and_known_problems_since_2015-03-04 [14:57:22] aside from that, no [14:57:30] ok ottomata I'll do that [14:57:32] it will impact pageviews for that hour, so i'm not sure if that needs to be communicated [14:57:33] thx [14:57:36] thanks mforns, much appreciated [14:57:41] new kafka brokers in as of last night [14:57:58] datacenter ops folks pushed those through asap, so I feel obliged to do my part and get them up and running [15:00:40] ottomata, you mean it's better not to communicate it via email list? [15:01:04] nono [15:01:08] i just mean i'm busy! :) [15:01:17] and i appreciate you updating the thing, thank yoUuUu :) [15:01:30] ah! np I'll do that, thx, I'll also will send an email to analytics [15:43:44] Analytics-Kanban, EventBus, Patch-For-Review: Change analytics kafka cluster JMX metrics to be prefixed with cluster name and change alerts and dashboards [5 pts] - https://phabricator.wikimedia.org/T121643#1884556 (Ottomata) NEW a:Ottomata [15:45:19] joal, yt? [16:54:00] Analytics-Backlog: Implement purging of EL data in Hadoop - https://phabricator.wikimedia.org/T121657#1884797 (Nuria) NEW [16:55:40] mforns: joal is on vacation today [16:57:22] nuria, oh right! [16:57:25] thx [17:00:36] Analytics-Backlog: Visualization of Browser data to substitute current reports on wikistats - https://phabricator.wikimedia.org/T118329#1884834 (Krinkle) [17:01:30] Analytics-Backlog: Visualization of Browser data to substitute current reports on wikistats - https://phabricator.wikimedia.org/T118329#1797533 (Krinkle) [17:01:31] Analytics-Cluster: Story: Community has periodic browser stats report generated from Hadoop data - https://phabricator.wikimedia.org/T69053#734731 (Krinkle) [17:01:46] Analytics-Cluster: Story: Community has periodic browser stats report generated from Hadoop data - https://phabricator.wikimedia.org/T69053#734731 (Krinkle) See also: * {T118330} * { T118329} [17:03:47] Analytics-Kanban, EventBus, Patch-For-Review: Refactor kafka puppet roles with hiera for more generic use than analytics [8 pts] - https://phabricator.wikimedia.org/T120957#1884857 (Ottomata) [17:12:38] Analytics-Backlog: Implement purging of EL data in Hadoop {oryx} - https://phabricator.wikimedia.org/T121657#1884893 (kevinator) [17:13:03] nuria: The weekly browser statistics, are those publicly downloadable? I think they are but I forgot where (I can access them from hdfs, but I mean for others). [17:13:17] Looking at https://dumps.wikimedia.org/other/ [17:13:26] Krinkle: no, they are not yet, that is one of our goals for next quarter [17:14:20] Okay [17:14:29] Analytics-Kanban, EventBus, Patch-For-Review: Make analytics kafka puppet uses use new role::kafka::analytics::* classes [5 pts] - https://phabricator.wikimedia.org/T121659#1884903 (Ottomata) NEW a:Ottomata [17:30:26] madhuvishy, do you recall having this problem when executing spark in the cluster "ERROR YarnScheduler: Lost executor 5 on analytics1034.eqiad.wmnet: remote Akka client disassociated"? [17:31:14] hm, no [17:31:20] is that from a long running spark job? [17:31:37] ottomata, it was running for like 15 minutes [17:31:40] Analytics-Backlog, Wikimedia-Developer-Summit-2016: Developer summit session: Pageview API overview - https://phabricator.wikimedia.org/T112956#1884935 (Milimetric) [17:32:07] it's the anonymization code [17:33:07] hm [17:36:11] ottomata, google says it is a memory problem, the worker uses too much memory and it's killed by yarn [17:36:14] mforns: when did that fail? i just looked through a bunch of yarn server, don't see anything [17:36:16] ah ok [17:36:24] mforns: more workers and/or more memory? [17:36:32] aha [17:36:39] not sure though [17:36:47] I was using 2G per worker [17:36:55] 8 workers [17:37:00] because there are 8 files [17:37:35] mforns: how big are the files? if bigger than hdfs block size, you should be able to use more workers anyway [17:37:44] default hdfs block size is 256M [17:38:05] unless you are manually loading the files individual in your spark code [17:43:37] ottomata, the files are 57M each (seems to small) [17:43:51] and I'm loading them using sqlContext.parquetFile(inputFilePath) [17:43:59] *too small [17:45:31] Krinkle: the "select" on this document to calculate browsers is not the best: https://docs.google.com/spreadsheets/d/12VAUAWBH0a7CVEBJqPZCVr3YDkiDbM54mexoJUmg3MI/edit?ts=5671a04e#gid=0 [17:45:48] Krinkle: why not use reports already available weekly on hdfs? [17:48:08] mforns: are you running on yarn mode? [17:48:13] madhuvishy, yes [17:48:16] hmmm [17:48:39] madhuvishy, you mean --master yarn? yes [17:48:45] is the job failing with that error [17:48:51] yeah --master yarn [17:48:59] no, it just keeps retrying endlessly [17:49:12] ah [17:49:44] I'll try using a little bit more memory on the workers, I was using 2GB [17:49:47] each [17:50:02] is it still running? do you have applicationID? [17:50:21] no, but I can run it again if you want [17:51:06] will execute it again [17:51:08] sure! I can watch it and see if i find something. also is the code on gerrit? [17:51:47] madhuvishy, no the code is not on gerrit, this task is just having a working code, next task is jobifying it [17:52:17] mforns: okay :) if you can paste it in pastebin or a gist i can look :) [17:52:30] sure I was doing that :] [17:53:01] Analytics-Backlog, Wikimedia-Developer-Summit-2016: Developer summit session: Pageview API overview - https://phabricator.wikimedia.org/T112956#1884982 (Milimetric) >>! In T112956#1883728, @RobLa-WMF wrote: > @Milimetric, I don't mind the "screaming", but I do mind lack of clarity on goals. What we hav... [17:53:02] madhuvishy, http://pastebin.com/HgPzAFLs [17:53:22] I wasn't on IRC, arg! [17:53:41] milimetric: yes i missed you :) [17:53:50] I posted this https://phabricator.wikimedia.org/T112956#1884982, a-team, let me know if anyone thinks it's a crazy departure from what you were expecting [17:55:14] mforns: i dont think the job launched yet [17:55:26] but one thing i see is the driver memory is 256mb [17:55:28] madhuvishy, I forgot to call main() :P [17:55:35] it should be now [17:55:39] aah [17:57:01] madhuvishy, https://yarn.wikimedia.org/proxy/application_1441303822549_281949/ [17:57:09] mforns: ya got it :) [17:57:58] (PS6) Milimetric: Oozie-fy Country Breakdown Pageview Report [analytics/refinery] - https://gerrit.wikimedia.org/r/256355 (https://phabricator.wikimedia.org/T118323) [18:03:54] heading out to cafe for lunch, back later [18:04:05] madhuvishy, I don't understand: https://yarn.wikimedia.org/proxy/application_1441303822549_281949/executors/ how the input of each worker is 6.5GB, because the files read are 57MB each [18:04:16] there are 8 files [18:05:39] madhuvishy, maybe this was just a memory issue, this time I run in yarn mode with 3GB for each worker [18:07:06] oh, 57MB compressed of course [18:07:16] ok, now this makes sense [18:07:40] mforns: yeah it decompresses it [18:07:49] it seems to be good now right? [18:07:56] for now yes [18:08:12] it took a while though to fail the other time, like 15 mins [18:09:30] ya let's see [18:09:57] mm I think I know what the problem may be [18:10:25] we are using cache() to avoid recomputation but as the algorithm is recursive, we're caching every stage [18:10:45] we should unpersist() previous stages when they aren't used any more [18:11:02] I guess [18:11:24] i see only one thing cached so far [18:15:00] mforns: i think it's starting to fail [18:15:54] madhuvishy, yes [18:16:31] madhuvishy, now it's more clear: java.lang.OutOfMemoryError: GC overhead limit exceeded [18:16:47] yeah, at keyBy [18:17:25] this is the 3rd keyBy [18:18:18] OK it seems the hypothesis makes sense, I'll try to unpersist previous stages of the algorithm [18:18:37] killed the job [18:19:46] okay [18:19:58] nuria: Because I need by browser family without OS breakdown and because of continuity with the past reports I've made so far (different method of aggregation, more indirection). It only takes like 10 minutes to run. Until there is an analytics proper report I can use I prefer to remain consistent with what I have. [18:20:14] It's also useful sometimes to keep in touch with the absolute numbers [18:20:20] (roughly) [18:20:29] Krinkle: what is on the weekly report that is not proper? [18:20:48] (CR) Milimetric: [C: 2 V: 2] "Tested again, results at /mnt/hdfs/user/milimetric/archive/projectview/geo/hourly/2015/2015-10/projectviews-geo-20151001-000000.gz" [analytics/refinery] - https://gerrit.wikimedia.org/r/256355 (https://phabricator.wikimedia.org/T118323) (owner: Milimetric) [18:20:57] Too short of a time period, break down by OS fragmented which means I can't use it in any meaningful way directly. [18:21:08] And I don't have it on a url, which means I need to query stats1002 to get it [18:21:13] at which point I might as well query hive [18:21:17] takes me the same amount of time to figure out [18:21:29] milimetric: take a look at the fabric code when you get a chance. if you'd like something major changed I can do it [18:21:39] Krinkle: mmm. only that you are counting traffic tagged as automated right? [18:22:04] agent_type=user? [18:22:10] What do you mean [18:22:37] Either way, for the sake of continuity and abilty to compare against my past reports I'm not changing it until I migrate to the visualisation report. [18:22:44] Changing it now means I have to start over. [18:23:19] Krinkle: ah sorry, you have agent type yes. but still lumping together mobile & desktop [18:23:27] That's fine. [18:23:45] There are no user agent's afaik that are in both. And we are interested in numbers for both. [18:24:04] There are similar user agents, but ua-parser gives them different names [18:25:28] Krinkle: depends for what is this report used, if you want to see the true usage of IE8 makes no sense to look at mobile traffic on my opinion. [18:26:17] nuria: Mobile domain can be used by anyone. I often use desktop site on mobile, and other people sometimes use the mobile site on desktop (e.g. when linked from social media content that was produced on a mobile device). [18:26:20] It's the user agent that matters [18:28:03] Analytics-Backlog, Wikimedia-Developer-Summit-2016: Developer summit session: Pageview API overview - https://phabricator.wikimedia.org/T112956#1885093 (Dave_Braunschweig) I'll just add my own quick perspective on this. The previous method for accessing log files by having to download all data for all... [18:28:36] Krinkle: Right, i know. That is why ua comes reported with the tag either mobile or desktop, but -even if you can use either- the browser stats on those two domains are so different that i question that lumping them together delivers better info than having separated stats [18:29:16] the mobile and desktop site share 90%+ of the infrastructure. [18:29:28] Krinkle: and features? [18:29:31] I am not intersted in any breakdown between the two. Most code we write runs as-is on both. [18:30:35] Krinkle: if that is the case then you might be right but makes no sense to do bug triage for feature X looking at that browser list if that feature is used in desktop but not in mobile [18:30:48] Krinkle: that code is present doesn't mean that is used (but you know this best) [18:31:06] Krinkle: i certainly rememeber VE code on mobile not working, but still present. [18:31:19] Krinkle: picture might have chnaged since then [18:31:21] *changed [18:33:42] I don't see a strong relation between bug triage and browser usage. This data is used first and foremost to make informed decisions about dropping support older browsers, and for adopting new technologies. These kinds of technologies (JavaScript, CSS, HTML) are implemented by rendering engines regardless of platform. Blink, Gecko and WebKit run on desktop [18:33:42] and mobile alike. Our decision to drop IE8 from Grade A to Grade C support should be based on all page views, regardless of whether they were viewing en.wikipedia or en.m.wikipedia. Our decision to require JavaScript ES5 or adopt SVGs likewise is based on all browser usage as well. [18:34:03] The mobile site will use different SVGs than desktop, but the technology to package and deliver those icons is agnostic [18:41:37] Krinkle: mmm,ya. Pageviews and users/different devices are a different thing. We have wayyyy more different users in mobile than desktop. But pageview numbers per user per session are likely to be higher in desktop (mobile is more prone to quick short term usage) and i think this is a good enough reason to look at mobile browsers in isolation. Mobile browser [18:41:37] X might have less pageviews than Desktop browser Y and yet it might represent 10 times as many users. [18:42:33] Krinkle: but point made, I do not think your reasoning is incorrect, my argument is just a refinement. [18:51:18] milimetric, i wonder how we could tie external controls to the graphs - would allow us to have an interactive pageview stats browser [18:51:20] nuria: Yeah [18:51:37] nuria: btw, how are mobile app views classified. Are they agent_type=user? If so what would their browser be reported as? [18:52:02] krinkle: no browser [18:52:12] Krinkle: app version is reported on x-analytics header [18:52:31] Krinkle: apps use webviews as an internal container [18:52:43] Krinkle: thus http payload does not need to contain user-agent [18:52:51] Krinkle: when making requests [18:53:17] nuria: So are they part of browser_family="other" ? [18:53:26] Krinkle: the app user agent is defined as the app version, not the container that will show content [18:54:02] Krinkle: i think so, "not identified" [18:54:13] Analytics-Backlog: Visualization of Browser data to substitute current reports on wikistats - https://phabricator.wikimedia.org/T118329#1885190 (Krinkle) The following are my asks to make this task a success so I can stop running my own queries every month. These reports currently fulfil the needs of designer... [18:54:22] nuria: OK. I've summarised some points here ^ [18:54:23] yurik: either from the visual editor graph editor or some other gadget or extension [18:56:16] Krinkle: I see, nice. This is NOT possible though: >Percentage breakdown of unique visitors by browser family and browser version. Unique visitors rather than page views, if that is possible? [18:56:56] I assumed as much but I'm just communicating the ask for it. It's quite a common question. [18:57:08] as I understand it analytics is interested in it, but it's not finished yet. [18:57:21] once it is, I imagine it would become possible to tap into that information? [18:57:30] Krinkle: Not possible as in " not possible right now on the near term" not undoable [18:57:36] those are two different things [18:58:08] Yeah, It's not in the requirements. I'm just summarising that based on the decisions we make and the questions I get most often, those would have helped a lot. [18:58:33] also like you said, uniquees are different on mobile with regards to user behaviour and sessions [19:00:57] milimetric, http://vega.github.io/vega-editor/?mode=vega&spec=jobs-params [19:02:08] vega embed!! [19:18:27] Analytics-Backlog: Visualization of Browser data to substitute current reports on wikistats - https://phabricator.wikimedia.org/T118329#1885357 (Volker_E) From designers, but also developers perspective there's another subset of //important// data points in my opinion: - viewport properties like viewport siz... [19:56:30] Analytics-Backlog, Wikimedia-Developer-Summit-2016: Developer summit session: Pageview API overview - https://phabricator.wikimedia.org/T112956#1885489 (Milimetric) > For us, year over year comparisons by month are more meaningful for long term analysis than month to month comparisons. My biggest reque... [19:57:32] yurik: this is amazing, I love it. It just needs some CSS to be loaded with the Graph extension so the input area doesn't look awful and we're gold [19:57:55] I'll totally work on this next month or the first available hackathon [19:58:08] milimetric, we don't have variable support yet - its an extension on top of vega [19:58:37] but it shouldn't be too hard - once we figure out the security implications there [19:59:22] Analytics-Kanban, Analytics-Wikistats: {lama} Wikistats 2.0 - https://phabricator.wikimedia.org/T107175#1885507 (Nuria) @Jdforrester-WMF: sorry, i did not see your comment earlier. The item we closed was getting data from cluster in teh form of sensible reports. While there is no viz yet the data is avail... [19:59:54] yurik: seems pretty harmless since it's parsing that section into a pretty strict html form. But I got burnt before underestimating security problems :) [20:02:30] Analytics-Wikistats: stats.wikimedia.org needs an API - https://phabricator.wikimedia.org/T28352#1885521 (Nuria) Please see pageview API: https://wikitech.wikimedia.org/wiki/Analytics/AQS/Pageview_API it will hold pageview data as far back as May 2015, we are in the process of backfiling it. While it doesn... [20:02:37] Analytics-Wikistats: stats.wikimedia.org needs an API - https://phabricator.wikimedia.org/T28352#1885523 (Nuria) Open>declined [20:02:39] Analytics-Kanban, Analytics-Wikistats: {lama} Wikistats 2.0 - https://phabricator.wikimedia.org/T107175#1885525 (Nuria) [20:03:09] Analytics-Backlog, Wikipedia-iOS-App-Product-Backlog, hardware-requests, operations, and 2 others: Request one server to suport piwik analytics - https://phabricator.wikimedia.org/T116312#1885526 (Milimetric) >>! In T116312#1883286, @yuvipanda wrote: > This should probably be isolated in its own vl... [20:03:42] Analytics-Backlog: Visualization of Browser data to substitute current reports on wikistats - https://phabricator.wikimedia.org/T118329#1885532 (Nuria) [20:03:44] Analytics-Kanban, Analytics-Wikistats: {lama} Wikistats 2.0 - https://phabricator.wikimedia.org/T107175#1488807 (Nuria) [20:05:26] Analytics-Wikistats: Page view stats: monthly most popular articles not updated - https://phabricator.wikimedia.org/T48204#1885546 (Nuria) You can also get this data from PageviewAPI: https://wikitech.wikimedia.org/wiki/Analytics/AQS/Pageview_API#Most_viewed_articles [20:05:34] Analytics-Wikistats: Page view stats: monthly most popular articles not updated - https://phabricator.wikimedia.org/T48204#1885548 (Nuria) Open>declined [20:05:36] Analytics-Kanban, Analytics-Wikistats: {lama} Wikistats 2.0 - https://phabricator.wikimedia.org/T107175#1885550 (Nuria) [20:09:44] Analytics-Kanban, Patch-For-Review: Pageviews per country wikistats report. Feed data from hive {lama} [13 pts] - https://phabricator.wikimedia.org/T118323#1885575 (Nuria) [20:09:46] Analytics-Kanban, Analytics-Wikistats: {lama} Wikistats 2.0 - https://phabricator.wikimedia.org/T107175#1885574 (Nuria) [20:15:34] Analytics-Backlog, Wikimedia-Developer-Summit-2016: Developer summit session: Pageview API overview - https://phabricator.wikimedia.org/T112956#1885615 (Dave_Braunschweig) Would adding the old data with a different tag work? The historical / "bad" data could be loaded with a "historical" or "deprecated... [20:34:18] Analytics-Backlog, Wikipedia-iOS-App-Product-Backlog: Stand up piwik in a permanent and privacy-sensitive way - https://phabricator.wikimedia.org/T98058#1885659 (Nuria) Duplicate of https://phabricator.wikimedia.org/T116312? [20:48:25] Analytics, MobileFrontend, Reading-Web-Sprint-63-E____________: Make MobileWebUIClickTracking schema usable (too big) - https://phabricator.wikimedia.org/T108723#1528729 (Jdlrobson) [20:57:38] Analytics-Tech-community-metrics: Maniphest backend for Metrics Grimoire - https://phabricator.wikimedia.org/T96238#1885789 (Aklapper) Note that upstream now allows ascending order for Conduit's maniphest.query's "order" parameter (order-created, order-modified). See https://secure.phabricator.com/T7909 [21:10:12] Analytics-Backlog, Wikipedia-iOS-App-Product-Backlog, hardware-requests, operations, and 2 others: Request one server to suport piwik analytics - https://phabricator.wikimedia.org/T116312#1885844 (ori) >>! In T116312#1885526, @Milimetric wrote: >>>! In T116312#1883286, @yuvipanda wrote: >> This sho... [21:12:40] Analytics-Backlog, Wikipedia-iOS-App-Product-Backlog, hardware-requests, operations, and 2 others: Request one server to suport piwik analytics - https://phabricator.wikimedia.org/T116312#1885866 (ori) >>! In T116312#1881789, @Joe wrote: > I think piwik will need to have its own database hosted on... [21:29:30] Analytics-Kanban, Discovery, EventBus, MediaWiki-General-or-Unknown, and 7 others: EventBus MVP - https://phabricator.wikimedia.org/T114443#1885924 (RobH) [21:32:42] Analytics-Backlog, Wikipedia-iOS-App-Product-Backlog, hardware-requests, operations, and 2 others: Request one server to suport piwik analytics - https://phabricator.wikimedia.org/T116312#1885930 (Nuria) Sounds like a VM is the way to go. [22:17:33] milimetric: remind me again how far the backfill pageview data will eventually go. Beginning of May? [22:30:56] ragesoss: yes [23:30:26] Analytics-Backlog, Wikipedia-iOS-App-Product-Backlog, hardware-requests, operations, and 2 others: Request one server to suport piwik analytics - https://phabricator.wikimedia.org/T116312#1886362 (dr0ptp4kt) @ori, is that referring to the following? ``` dns/templates $ grep -ir 'LVS Misc' * ./0.6.... [23:30:42] Analytics-Backlog, Wikipedia-iOS-App-Product-Backlog, Zero, hardware-requests, and 3 others: Request one server to suport piwik analytics - https://phabricator.wikimedia.org/T116312#1886364 (dr0ptp4kt) [23:57:31] Analytics-Backlog, Wikimedia-Developer-Summit-2016: Developer summit session: Pageview API overview - https://phabricator.wikimedia.org/T112956#1886408 (RobLa-WMF) First, my apologies for being so grumpy in my last response. I think there is likely some very good conversation that can come from this....