[09:44:01] enyone here? [10:48:37] gwicke: I really like your ascii art on https://www.mediawiki.org/wiki/Future/Parser_development :D [10:49:00] thanks ;) [10:50:09] gwicke: here is the rendered version: http://tinyurl.com/7pe7bwo :D [10:50:47] wow- I did not realize that was already renderable [10:50:59] did not use any tool for it [15:51:45] RoanKattouw - Fabrice mentioned yesterday that some aft5 clicktracking events aren't showing up as they should -- do you know which ones? I'd like to get that fixed before the meeting today. [15:52:17] I don't know what he's talking about [15:52:34] I do know we managed to lose all the data prior to midnight Eastern Time today [15:52:38] (Screw you, logrotate) [15:53:05] I can see how that would make it difficult to know which ones are missing :-P [15:53:20] The logrotate issue should be fixed as of this morning [15:53:36] But that doesn't get the old data back, so we've still got a small data set [15:53:54] When we mess with bucketing stats later today, we'll get some more data in that file, I guess :) [15:54:28] ok [15:55:12] I guess Dario would know what kind of events are missing, but it's early for hm [16:18:17] Anyone know when Erik is likely to run updated browser stats? [16:18:27] stats.wm.o is still october [18:03:56] DarTar: So, I just applied a live hack that will track just 1% of tracked bucketing events instead of all of them [18:04:16] So when I enable tracked bucketing in a minute, we won't get an avalanche of events [18:04:32] awesome [18:05:14] I would also like to increment the number that's in the clicktracking keys (you know, the experiment number after the @, currently zero) so everyone gets rebucketed [18:05:58] as in, after this test? [18:06:06] hello [18:06:10] hey bsitu [18:06:31] Hi DarTar [18:06:44] ok [18:06:49] hey rsterbin [18:06:56] ok all on board [18:07:02] shall i add the impressions tracking, then? [18:07:14] it's triggered when the form loads [18:07:18] DarTar: No, at the start of this test, to trigger the right conditions [18:07:21] (so after bucketing) [18:07:25] Oh, you wanted impression tracking? [18:07:31] I thought we were doing bucketing tracking [18:07:38] so two things, [18:07:39] i thought the opposite [18:07:40] Dario, maybe you could explain what kind of data you want from this? [18:07:44] heh [18:08:54] the first test is to check whether bucketing is performed randomly, we see major discrepancies in the AFT data by bucket (which would be good news) but we need to make sure users are randomly assigned to each bucket with a .33 probability [18:09:04] so that's the first test [18:10:08] RoanKattouw already deployed a hack to see whether the data we're collecting on 1% of users bucketed honors the random assignment [18:10:39] ok [18:11:05] I didn't fully deploy it yet [18:11:13] But go on [18:11:52] the second test, which I assumed would be part of Roan's hack, is to measure impressions of AFT5 on a small sample of users [18:12:13] Ah, OK [18:12:16] That's not actually part of it [18:12:17] I was expecting to test for correct random bucketing via this test [18:12:28] Reha, could you put that code in SVN then? [18:12:52] it's already there, just commented out -- but it's for everybody, not a small percentage [18:13:02] my question is: is it possible to sample impressions at a level you're confident with (in terms of scalability) while leaving all other events at 100%? [18:13:20] Yes [18:13:24] sweet [18:13:29] I'm already doing that for bucketing [18:13:50] It's not the most elegant code ever, but I just used if ( Math.random() * 100 < 1 ) { track event } [18:13:55] heh [18:14:00] ok, i can add that [18:14:23] if we can do that, than we can integrate sampled impressions into the clicktracking analysis which would be awesome [18:14:45] do you want overlay impressions at a percentage as well? [18:14:50] rsterbin, just to confirm, next week we'll be activating clicktracking events for the feedback button [18:14:58] no, I'd like to have all the other events at 100% [18:15:06] as they will be a tiny fraction of impressions [18:15:15] once we add the top link, they'll be a lot more [18:16:51] a lot more but still way below the level of impression tracking that would melt the servers [18:17:29] unfortunately I have no estimate of how many events we will be tracking as we never had a prominent link at the top of the page clicktracked at 100% [18:17:40] at least since I've been around at WMF [18:18:33] so unless Roan objects, I'd like to keep the same rate for events other than impressions [18:19:57] What is an "overlay impression"? [18:20:17] next week we'll be deploying a new version of AFT with an intermediate step [18:20:29] you will first have to click on a fixed position feedback button [18:20:38] and that opens an overlay with the AFT form [18:21:04] OK [18:21:17] So it's something that requires user interaction, then it's fine [18:21:18] so impressions of the widgets should be equal to the number of clicks on the feedback button [18:21:21] yep [18:21:41] the bottom-of-the-page impression doesn't happen until you scroll down enough to see it [18:22:09] (for articles where that's true, anyway) [18:22:27] ha good point [18:22:53] that's because the loader is called only when people scroll to the bottom, right? [18:22:57] right [18:23:00] hmm [18:23:11] bucketing happens as soon as the js loads [18:23:25] is there any other event that can be tracked on page load to measure a sample of impressions? [18:23:28] so they wouldn't be equal for long articles [18:23:38] if not, we'll just stick to that [18:23:58] wouldn't an impression be "saw the form"? [18:24:32] well, ideally you would like to make a distinction between: (a) visited the page but didn;t see the form and (2) visited the page and saw the form [18:24:33] that can happen either when they scroll to the bottom of the page or when they click the header/tab/toolbox link [18:24:56] if we track bucketing and impressions, that would do it [18:25:03] but we can still use (less accurate) pageview data for that [18:25:08] right [18:25:14] OK, enabling bucketing tracking now, I should start seeing data in ~5 mins [18:25:33] the trouble is that bucketing only happens once [18:25:42] not on every page view [18:25:43] Note that I'm not tracking bucketing the way you think you are [18:25:44] Exactly [18:25:55] I'm only tracking the "oh the user wasn't in a bucket yet, but they are now" event [18:26:00] yeah... pageview data wouldn't tell you about people who were using ie7 [18:26:01] Oh, and let me bump the version number too [18:26:21] (or, more correctly, it would tell you they saw it when they didn't) [18:26:29] rsterbin: yeah we have to live with that limitation unfortunately, and hope that it spreads uniformly across buckets [18:26:36] what if i add a tracking event at 1% on init? [18:27:02] init = loading? [18:27:05] yeah [18:27:22] so after category checks and such [18:27:29] Roan, would that work for you? [18:27:48] That's fine [18:27:54] let me check on where the ie stuff is happening... [18:27:57] great [18:28:57] so to recap, we will have bucketing events at 1%, impressions (via init) at 1%, all other events (including overlay impressions) at 100%, right? [18:28:58] that happens on startup, before any other js [18:29:39] init won't tell you if they scrolled to the bottom of the page [18:29:47] yes [18:30:24] it will ping for people who got to a page with aft enabled, using an acceptable browser [18:31:00] Hmm, right [18:31:07] We've only got v5 on a very low number of articles [18:31:10] which is, afik, technically not an impression at all [18:31:14] I'll just remove that live hack that does the 1% thing [18:31:15] rsterbin: I don't understand, so init and loading would be different? [18:31:24] yes [18:31:45] loading is the one i talked about before, where they scrolled to the bottom of the page [18:32:05] ok, so the plan is: [18:33:29] (A) bucketing events at 1% (B) init (every user on page load) at 1% (C) bottom-of-page impressions (AFT actually loaded) at 1%, (D) all other events (including overlay impressions) at 100%, right? [18:34:21] my only concern is treating bottom-of-page and overlay impressions differently [18:34:50] I'm gonna do (C) at 100% for now actually [18:35:06] rsterbin isn't that as in the specs for clicktracking? [18:35:14] let me bring them up [18:35:27] if there's a central location for clicktracking specs, i never saw it [18:35:43] oh I mean: https://bugzilla.wikimedia.org/show_bug.cgi?id=32992 [18:36:50] RoanKattouw: i think that's better; my totally informal survey of clicking around tells me the number of pages that would get a hit is relatively small anyway -- on the long pages, you have to scroll past references [18:36:51] the only reason why we didn't include optionN-impression-bottom is that we didn't know if it was feasible based on previous experience with AFT4 [18:37:10] what happened with aft4? [18:37:16] rsterbin: And there are very few pages anyway [18:37:28] servers melted precisely because we were tracking init events at 100% [18:37:29] right [18:37:36] Bucketing events, actually [18:37:41] oh right [18:37:43] But with the UDP stuff things shouldn't melt as badly [18:37:52] also, not the same as load [18:38:16] i think the below-the-fold factor is probably going to make a difference [18:38:21] yeah, so is there any technical difficulty in implementing different events for impressions for the overlay vs bottom placement? [18:38:26] rsterbin: totally [18:38:32] we already do [18:38:56] oh ok, so what's your concern? rsterbin: my only concern is treating bottom-of-page and overlay impressions differently [18:39:01] it's just that the "impression-bottom" is commented out [18:39:10] gotcha [18:39:16] OK, clicktracking events, hit me [18:39:22] you suggested tracking bottom impressions at 1% and overlay impressions at 100% [18:39:38] i agree with roan that bottom impressions should be at 100% [18:39:43] I'm now doing bottom @ 100% [18:39:49] waiting for things to kick in [18:39:51] if that's feasible, let's go for it [18:40:37] RoanKattouw: you've made the change in trunk, or just in prod? [18:40:38] rsterbin: can we update bug 32992 with the new events names that we are now tracking? [18:40:43] sure thing [18:40:47] great [18:40:48] I'm just refreshing cat /etc/logrotate.d/aft-udp2log | grep bucket now, nothing [18:40:53] rsterbin: prod, local hack [18:40:54] i think we should put this stuff on the wiki [18:40:59] and config [18:41:02] ok, cool [18:41:03] rsterbin: agreed [18:41:17] I should actually start a dedicated page for clicktracking [18:41:23] let me do it straightaway [18:41:23] RoanKattouw: i'll make those changes in svn [18:42:00] OK [18:42:25] but there's some new stuff in previous revs that hasn't been tested [18:42:40] I'll cherry-pick it [18:42:47] ok [18:43:33] D'OH [18:43:39] Why am I grepping the damn LOGROTATE CONFIG [18:43:41] BAD ROAN. BAD [18:44:01] There we go, it's been working fine all along [18:44:19] OK, Dario, I've got 10k lines of clicktracking data for you to have fun with [18:44:36] yay [18:44:53] Actually [18:44:58] Let me just post the numbers this way [18:45:00] DarTar: for the init impressions, option1-init okay? (with prefix as the others) [18:45:01] catrope@emery:/var/log/aft$ grep bucket clicktracking.log | grep one | wc -l [18:45:03] 3804 [18:45:04] catrope@emery:/var/log/aft$ grep bucket clicktracking.log | grep two | wc -l [18:45:06] 3694 [18:45:07] catrope@emery:/var/log/aft$ grep bucket clicktracking.log | grep three | wc -l [18:45:09] 3738 [18:45:21] ah that's reassuring :) [18:45:34] Given that one is 34% rather than 33% , that looks good enough for me [18:45:44] Turning tracking back off now [18:46:35] can you push the data you collect to internproxy? [18:47:00] I don't have access to that box [18:47:03] Not even root access (!!) [18:47:07] :-o [18:47:38] Do you have shell access on fenari? [18:47:41] nope [18:47:48] :-| [18:47:52] Hmph, and nightshade/willow isn't private enough [18:47:59] emery? [18:48:02] yeah we shouldn't be using the TS [18:48:03] locke? [18:48:13] I only have access to internproxy [18:48:22] Bah [18:48:28] *shrug* [18:48:32] Well, then get whoever runs that place to give me access [18:48:42] yeah, looking around for Asher [18:48:47] but I don't see him [18:48:56] rsterbin: How's the impression tracking stuff coming along? [18:49:12] done, just need confirmation from DarTar on the name [18:49:20] then i can check in [18:50:19] http://meta.wikimedia.org/wiki/Research:Article_feedback/Clicktracking [18:50:41] rsterbin: what name do you suggest? [18:50:50] optionX-init [18:50:57] fine with me [18:51:01] or just init, if you want to track before bucketing [18:51:18] we want to track by bucket [18:51:22] ok, cool [18:52:03] so we're adding optionX-init and uncommenting optionX-impression-bottom, right? [18:52:15] Krinkle: ping? [18:52:23] Roan: r108063 [18:52:36] hexmode: yes ? [18:52:46] whoops, RoanKattouw: r108063 [18:53:07] DarTar: added info to bug; adding to wiki now [18:53:14] great [18:53:19] Krinkle: http://pastebin.com/iBS8gaQz for https://www.mediawiki.org/wiki/Special:Code/MediaWiki/102301 [18:53:36] Krinkle: just wanted to see if that looked ok to you [18:53:44] before I commit [18:53:58] Still no robla [18:54:41] hexmode: the children>find is ok, I tested that. I don't know what the return is doing there though, checking out context in full file [18:54:55] Reedy: how's the AFT bot doing? [18:55:06] 8549 to go [18:55:09] Krinkle: return is b/c my linter was complaining [18:55:12] so 2970 added so far [18:55:20] 125 skipped (disambiguation pages) [18:55:23] great [18:55:26] hrm... spacing [18:55:31] hexmode: meaning, it's not to be committed ? [18:56:16] Krinkle: since I'm only concerned with the find bit, I'll only commit that [18:56:22] ok [18:56:25] rsterbin: thanks [18:56:33] DarTar: np [18:56:57] hexmode: what kind of linter is that by the way, sounds interesting [18:57:54] Krinkle: js2-mode.el by Steve Yegge [18:58:07] k, will check later [18:58:15] rsterbin: we still don't have in that list events for clicks on the fixed-positioned feedback button [18:58:25] do we? [18:58:27] *hexmode looks forward to another Emacs convert ;) [18:59:16] ah, no, we don't, although they are tracked [18:59:42] var linkInfo = { [18:59:42] 'A': { trackId: 'sitesub-link' }, [18:59:43] 'B': { trackId: 'titlebar-link' }, [18:59:43] 'C': { trackId: 'vertical-link' }, [18:59:43] 'D': { trackId: 'bottomright-link' }, [18:59:43] 'H': { trackId: 'section-link' }, [18:59:43] 'tbx': { trackId: 'toolbox-link' } [18:59:43] }; [19:00:04] so that's going to be D, right? [19:00:19] those do not distinguish between form options right now, though [19:01:02] oh right, that's because the initial plan was to activate bucketing by placement after the first phase [19:01:15] OK, init + bottom tracking deployed [19:01:21] Now waiting for events to come in [19:01:29] RoanKattouw: sweet [19:01:31] RoanKattouw: thanks [19:01:35] *fingers crossed* [19:02:01] Reedy: 8 PHP Catchable fatal error: Object of class RequestContext could not be converted to string in /usr/local/apache/common-local/php-1.18/includes/Title.php on line 524 [19:02:02] rsterbin, as of next week we'll use the current 3 design buckets but with the bottom-right link enabled [19:02:03] DarTar: i can make those "optionX-{whatever}-click" [19:02:10] yeah that's be useful [19:02:29] right [19:02:39] actually, [19:02:49] that adds another type of identifier [19:03:04] we currently have: [option id]-[event]-[placement id] [19:03:14] Reedy: 7 PHP Warning: explode() expects parameter 2 to be string, object given in /usr/local/apache/common-local/php-1.18/includes/specials/SpecialListusers.php on line 39 [19:03:21] if we want to track different links we would need something like: [19:03:25] Yay, I've got events: [19:03:26] catrope@emery:/var/log/aft$ grep init clicktracking.log | wc -l [19:03:28] 15 [19:03:44] [option id]-[trigger id]-[event]-[placement id] [19:03:49] or something, right? [19:04:14] RoanKattouw: great [19:04:25] ugh [19:04:30] wtf it's not taking the version number [19:04:35] Not that that's bad, but it's strange. Oh well [19:04:40] oh? [19:04:50] *Reedy barfs [19:05:00] $parms = explode( '/', ($par = ( $par !== null ) ? $par : '' ) ); [19:05:01] RoanKattouw: oh I thought you meant bucket number [19:05:05] Do I dare ask who the hell commited that? [19:05:25] Holy crap [19:05:27] Sigh, it's in trunk also [19:06:03] *hexmode is feels safe that it wasn't him [19:06:16] I'd hate the be the one making Reedy sick [19:06:26] RoanKattouw, for the Title one I need a caller line ideally.. [19:06:34] rsterbin, here's what I think we need for the naming scheme [19:06:59] You mean the RequestContext-to-string error? [19:07:01] Ok, that line of code dates back to r39296 [19:07:14] *r39269 [19:07:22] 1.7G fatal.log [19:07:24] Sight [19:07:26] *Sigh [19:07:27] 1 - trigger events: [option id]-[trigger id]-[event]-[placement id] [19:07:27] 2 - widget events: [option id]-[event]-[placement id] [19:07:27] 3 - CTA events: [option id]-[cta id]-[event]-[placement id] [19:07:28] Log rotation, anyone? [19:07:31] Yeah, it's the caller that's at issue [19:07:44] unless it's also in trunk [19:07:52] DarTar: isn't there only one trigger event, a click? [19:08:00] well, yeah :) [19:08:04] and one placement, the overlay? [19:08:13] correct [19:08:30] so you're just saying, we consider this an event [19:08:33] Reedy: http://pastebin.com/VmTrUqzu [19:08:38] so... optionX-triggerX-click-overlay? [19:08:51] sounds good [19:09:16] can we document on the wiki the keys for triggers? [19:09:23] sure [19:09:30] i can rename them to A-H [19:09:42] CA [19:09:44] as long as they match Fabrice's mockup [19:09:45] but we'll need one for toolbox (even if nobody every uses it) [19:09:49] right [19:09:59] that means he can't change the lettering again [19:10:07] this time it's got to stay the same [19:10:11] *DarTar nods [19:10:55] toolbox works by a different set of rules than the others -- you can't bucket into it; it's always there [19:11:04] maybe we call it TBX? [19:11:44] OK, we're capturing data successfully now [19:11:49] Dario, I'll send it to you later [19:11:53] woot :) [19:11:53] I have to do the MoodBar deployment now [19:12:19] RoanKattouw: thanks! [19:12:41] rsterbin: hang on, what was toolbox? [19:12:52] bsitu: What's scaptrappy about https://www.mediawiki.org/wiki/Special:Code/MediaWiki/107960 ? [19:13:03] *DarTar updating the wiki with a section on identifier types [19:13:03] that's the link nobody uses in the left sidebar, under "toolbox" [19:13:09] oh I see [19:13:14] so that's a trigger option [19:13:17] yep [19:13:28] but it's not a *bucketable* trigger option [19:13:30] ok, let's just add it with a dedicated key for the record [19:13:38] why is that so? [19:14:12] rmoen, bsitu: I'm ready to do the MoodBar/MarkAsHelpful update deployment when you guys are [19:14:22] is it ready? [19:14:26] i have a request if it isn't. [19:14:39] DarTar: because it's not prominent enough to be worth testing, but nobody wants to get rid of it [19:14:39] What's your request? [19:14:53] (If it doesn't make it in, they'll have a head start on it for next week, I guess) [19:15:15] I still have one item to check in [19:15:18] DarTar: so it's just on all the time [19:15:22] is it scheduled to deploy today? [19:15:34] Yes, Wednesday 11am [19:15:35] rsterbin: right, I thought it was special in terms of bucketing, let's just add it to the list of dead triggers [19:15:36] That's the weekly window [19:15:42] creating a section right now, bear with me [19:16:01] what's a dead trigger? [19:16:03] RoanKattouw, should be fixed now. Crappy context parameter insertion [19:16:31] sent the email. it won't make it into this build, i think. [19:16:35] just an alignment thing. [19:18:38] RoanKattouw: I just finished the last change we discussed yesterday and testing it now, I will commit the code in a minute [19:18:48] OK, cool [19:25:16] DarTar: going with triggerTBX, but need to get on a call now -- will check back later [19:25:31] re [19:25:38] rsterbin: np, ttyl [19:34:45] bsitu: Don't mean to be nagging too much, but how close are you to committing that last change? [19:35:57] RoanKattouw: I am committing it now, we are confirming with Alolita/howie if we are deploying today, since they have not reviewed all the changes yet [19:36:05] Oh, OK [19:36:08] Let me know what you decide [19:36:16] bsitu [19:36:23] howie is available to test now [19:36:32] so ask him and dario to test [19:36:44] okay, I will push them to prototype [19:37:36] bsitu: I can help with testing in a moment [19:37:55] and then Roan can deploy once they clear [19:38:27] sounds good [19:40:24] rsterbin: I created a placeholder section for feedback link identifiers: http://meta.wikimedia.org/wiki/Research:Article_feedback/Clicktracking#Trigger_IDs [19:41:04] I'll share this link with the rest of the team once you have filled out the trigger IDs [19:50:08] robla, about? [19:50:16] Hi...what's up? [19:50:41] Just wondering if you had an idea when Erik Zachte (or someone else) is likely to update stats.wm.o? [19:50:48] Specifically, the browser stats [19:50:58] Seen a new post with MS suggesting IE6 usage is under 1% now [19:51:04] so was interested from our end [19:51:28] As I know both platform and features are spending time on IE6 stuff [19:52:00] Reedy: I suspect he'll be updating it for the report card meeting tomorrow [19:52:10] Aha [19:52:11] That works [19:56:20] Would be nice if we can more formally stop actively supporting IE6 [20:10:18] bsitu: What are you tagging these revs scaptrap for? [20:14:20] who knows JS well enough to comment on decodeURIComponent here: https://bugzilla.wikimedia.org/33098 [20:19:28] https://www.mediawiki.org/wiki/ResourceLoader/V2_Task_management [20:19:31] So [20:19:34] "Mock-ups of Shared gadgets in preferences" [20:19:43] That one's on your plate [20:19:46] Yep [20:19:55] I guess we also need to look at what our availability looks like for the next while [20:20:18] I will be traveling 12-14, in Australia 16-20 and in SF 20-28 [20:20:42] I have ambitious plans for that, but not sure we to what extend it is necessary (it shouldn't be worse than before) [20:20:44] *14-20 [20:21:05] **not sure to what extend it is necessary (it shouldn't be worse than before) [20:21:29] Right [20:21:41] Well, what we have now isn't really all that nice [20:21:46] *Krinkle checks [20:22:54] eh, it's pretty broken right now [20:22:57] descriptions aren't shown [20:23:01] should they ? [20:23:37] Hmm, yeah, I guess they should be [20:23:42] *RoanKattouw puts on TODO list [20:24:08] Also, we've got the thing where there's a section for every wiki, with a subsection for every category [20:24:19] I'll shortly define "ambitious plans": make Gadget prefsection more like SpecialGadgets, so a proper row with small bolded title and description below and a button (like an actual button - could be checkbox behind the scenes) that indicates On or Off. [20:24:24]