[00:01:46] <ejegg>	 pizzzacat: since it seems grrrit is still out: https://gerrit.wikimedia.org/r/195807
[00:04:28] <AndyRussG>	 ejegg: didja think of any other possible issues or possible different approaches?
[00:04:44] <ejegg>	 not yet
[00:04:50] <AndyRussG>	 K :)
[00:04:53] <ejegg>	 i'll certainly let you know if i do!
[00:04:58] <AndyRussG>	 thanks much!
[00:06:23] <AndyRussG>	 I'll add to the etherpad the general points we talked about ^ and if it's confirmed the RL cache works as expected, I'll close the spike about this design...
[00:06:34] <ejegg>	 cool!
[00:07:41] <K4-713>	 ejegg: Have you had a chance to look at any PCI things yet?
[00:07:53] <K4-713>	 If not, I was going to go digging for helpful things.
[00:07:59] <K4-713>	 ...unless you've already done that.
[00:09:31] <ejegg>	 K4-713: not yet, besides searching the fileshare for *PCI*
[00:09:40] <ejegg>	 ...and not finding anything
[00:09:44] <K4-713>	 I got it.
[00:09:52] <K4-713>	 I must have saved the thing last time or something.
[00:10:09] <K4-713>	 "If I was last year's SAQ, where would I... oh. There I am."
[00:10:26] <ejegg>	 anthropomorphizing can be so useful
[00:10:37] <K4-713>	 I basically never stop.
[00:11:13] <ejegg>	 i like your world
[00:12:08] <K4-713>	 There are a lot of googly eyes.
[00:24:00] <AndyRussG>	 Krinkle: hi! are you familiar with RL module caching? got a sec to help me check if I'm understanding how it works? thx in advance!
[00:25:28] <Krinkle>	 AndyRussG: Yup! Fire away
[00:25:45] <Krinkle>	 Im leaving soon ish though
[00:26:13] <AndyRussG>	 Krinkle: coool thanks! So... modules are cached locally indefinitely as long as they're not removed from Mediawiki and the version stays the same?
[00:26:48] <AndyRussG>	 It looks like the registry of modules is checked, not sure exactly how often, and if a module is in localStorage that's not registered, it's purged
[00:27:08] <AndyRussG>	 That would work for our purposes, just wanting to check that it's the case :)
[00:27:29] <Krinkle>	 AndyRussG: Depending on your definition of 'locally', yes. They might get purged by ops or deployers for other reasons from time to time. So don't depend on cache staying always.
[00:27:44] <Krinkle>	 Oh you meant client-side
[00:27:50] <ejegg>	 OK, K4-713, I'll look at that stuff more in the morning and figure out the subset of things that need awight's input
[00:27:58] <AndyRussG>	 Krinkle: yeah! sorry I didn't specify, client-side in localStorage
[00:28:27] <Krinkle>	 AndyRussG: What's your evil plan? :)
[00:28:28] <AndyRussG>	 Basically we're just trying to see which option will be most performant for what we want to do
[00:28:37] <AndyRussG>	 Buahahaha... heh... one sec
[00:28:49] <K4-713>	 ejegg: Sounds good.
[00:29:04] <K4-713>	 Thanks for volunteering for that one.
[00:29:10] <AndyRussG>	 Krinkle: overview of change: https://upload.wikimedia.org/wikipedia/mediawiki/e/e4/CentralNotice_mixing_and_logging_proposal_2015-03-01.svg
[00:29:25] <AndyRussG>	 Basically, we currently have JS coming in with banners
[00:30:00] <AndyRussG>	 and we want to move some of that to RL modules to be made available after a campaign is chosen, but before a specific banner for that campaign is chosen
[00:30:20] <AndyRussG>	 Also: http://etherpad.wikimedia.org/p/CampaignAssociatedMixins
[00:30:40] <AndyRussG>	 It looks like we're gonna take plan A for 100 dollars
[00:31:55] <Krinkle>	 AndyRussG: Define 'mixin' in the context of current/proposed implementation?
[00:32:24] <AndyRussG>	 Krinkle: yurp, it's a thing that's currently in CentralNotice but only can be banner-associated, not campaign-associated
[00:32:30] <AndyRussG>	 It's a blurb of JS
[00:32:36] <AndyRussG>	 That can have parameters
[00:33:53] <AndyRussG>	 So the idea will be, for example, select the banner-hiding mixin for a campaign, and our central notice users will be able to set parameters for how many banners to show in that campaign without auto-hiding
[00:34:04] <AndyRussG>	 They currently do this with on-wiki JS that is added to banners
[00:34:08] <Krinkle>	 AndyRussG: How would the request for RL modules know which to load? How does this improve the performance if it still needs to load the banner from the special page afterwards?
[00:34:27] <AndyRussG>	 Right!
[00:36:08] <Krinkle>	 (s/performance/http requests/)
[00:36:33] <AndyRussG>	 Answer 1: when the server sends to the client a list of posible campaigns, it'll tell the client which RL module-based "mixin"s are need (if any) for each. If a campaign is chosen (this happens on the client) that has a mixin, we'll use mw.loader.load to load it, and it'll either be fetched from the server or hopefully, more often than not, gotten from in-browser localStorage
[00:36:52] <AndyRussG>	 (that's why I want to be sure I get what's up w/ localstorage)
[00:36:55] <AndyRussG>	 Answer 2:
[00:37:56] <AndyRussG>	 The new scheme will allow us to count logs of Special:BannerLoader as actually indicating a banner was shown, so we won't always have to send a special, additional logging call (currently Special:RecordImpression) to know if a banner was really shown
[00:38:18] <AndyRussG>	 There will still be logging calls but they'll be much less frequent, hence the performance improvement
[00:39:18] <AndyRussG>	 Also Special:BannerLoader won't be called a the times when a banner is really going to be hidden (for example, campaigns that stop showing banners after you've seen like 5 or so), also leading to less requests
[00:39:44] <Krinkle>	 Don't worry about localStorage. LocalStorage is just an additional layer on top of HTTP 304.
[00:40:00] <Krinkle>	 It doesn't increase or decrease cache hits much for this purpose.
[00:40:29] <Krinkle>	 The module is only in localStorage if it was previously requested. It's essentially a mapping of load.php urls to responses (slightly more abstracted)
[00:40:51] <AndyRussG>	 Yeah
[00:41:04] <Krinkle>	 Assuming the banner choice can not be known server-side, the call to mw.loader.load would be made after the initial RL modules request comes back. So that's an extra request for that chosen module
[00:41:07] <AndyRussG>	 I mean, we are expecting these modules to be requested a lot, especially when a user is being targeted for a campaign
[00:41:29] <AndyRussG>	 So by relying on the RL infrastructure, it can be fetched just the first time it's needed
[00:41:36] <AndyRussG>	 The other option is to send it in on every request
[00:42:24] <AndyRussG>	 Yeah I see it's an extra request for the chosen module, since it's requested dynamically from JS
[00:42:29] <Krinkle>	 AndyRussG: Hm.. so this js payload you want to move from special:bannerloader to an rl module, that's specific to one banner, right?
[00:42:32] <AndyRussG>	 But only the first time, no?
[00:42:48] <Krinkle>	 And is authored by users?
[00:42:54] <AndyRussG>	 No...
[00:43:06] <AndyRussG>	 It's stuff that is used a lot by FR and goes in tons of banners
[00:43:32] <Krinkle>	 So Special:BannerLoader and centralnotice would still respond with html and include <script>
[00:43:39] <AndyRussG>	 It's currently on-wiki, is authored mainly by Peter (the_wub) though meta administrators and CN admins can change it
[00:43:59] <Krinkle>	 What's an example of something that would become a module?
[00:44:05] <AndyRussG>	 Special:BannerLoader would still have html, script, yeah I don't think we'd be ready to get rid of that
[00:44:11] <AndyRussG>	 Mmm one sec
[00:45:05] <AndyRussG>	 Krinkle: here's a banner with lots of JS: https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/edit/B15_danbDKNO_dsk_lg_dsn_nag_side
[00:45:32] <AndyRussG>	 So several of those snippets work together to control and log actual banner showings
[00:46:01] <AndyRussG>	 And also to make sure users dont' see more than one half-or-nearly-full-screen banner, even across different campaigns
[00:46:27] <AndyRussG>	 So for example it'd be some of the snippets that work together for that
[00:47:23] <AndyRussG>	 For example https://meta.wikimedia.org/wiki/MediaWiki:FR2014/Resources/SeenCountB.js
[00:47:26] <AndyRussG>	 Plus other related functions
[00:47:44] <Krinkle>	 Ah, the included <script> templates
[00:47:49] <Krinkle>	 Those are "mixins" ?
[00:47:50] <AndyRussG>	 yeah
[00:47:53] <AndyRussG>	 no
[00:48:08] <AndyRussG>	 Mixins were meant to replace those
[00:48:20] <Krinkle>	 Right, they'd become mixins
[00:48:24] <AndyRussG>	 Yes
[00:48:44] <AndyRussG>	 I mean, more precisely, we already have mixins that can be associated with banners thanks to awight's footwork
[00:48:48] <AndyRussG>	 However they're not really used yet
[00:48:53] <Krinkle>	 AndyRussG: Where are mixins registered?
[00:49:35] <AndyRussG>	 The currently implemented banner-not-campaign-associated mixines are registered..
[00:49:45] <Krinkle>	 In the extension or on-wiki? Can they still take placeholder values per-banner, or would they use actual JS variables instead? E.g. can a mixin be loaded as-is or does it need preprocessing
[00:50:17] <AndyRussG>	 Currently they are registered in the extension but they take parameters
[00:50:43] <AndyRussG>	 That general approach wouldn't change, they'd just now become real RL modules and would be associated with campaigns rather than banners
[00:52:42] <AndyRussG>	 Currently they actually have a decent UI component where banner authors set the parameters via a form
[00:54:47] <AndyRussG>	 I haven't looked into the exact mechanism we'd use for passing in the params, but the params would need to be flexible, like in the current mixin system
[00:56:46] <AndyRussG>	 If we can be relatively sure that, say, for a month-long campaign, a RL module will stay in users' localstorage and so when loaded dynamically it'll only cause an extra request the first time (assuming the module doesn't change) then I think this is a pretty reasonable design to persue...
[00:56:51] <Krinkle>	 AndyRussG: How do they take parameters? Loaded modules have no request context, so they can't substitute values or anything like that
[00:57:18] <Krinkle>	 server-side that is
[00:57:30] <AndyRussG>	 Currently they're not implemented as RL modules
[00:57:37] <AndyRussG>	 Ah server-side! Mmm no, that's not needed
[00:57:45] <AndyRussG>	 All the params will be available in the client
[00:58:08] <Krinkle>	 So there wouldn't be any placeholders or parameters replaced inside script
[00:58:17] <AndyRussG>	 It'll just be a matter of letting the JS in the module have the params it needs
[00:58:20] <Krinkle>	 only passed as function arguments
[00:58:21] <AndyRussG>	 client-side
[00:58:28] <Krinkle>	 Right
[00:58:42] <AndyRussG>	 Yeah something like that
[00:58:59] <AndyRussG>	 I can't imagine that's an unsolvable piece of the puzzle
[00:59:03] <Krinkle>	 AndyRussG: Hm..
[00:59:13] <Krinkle>	 AndyRussG: So one problem is registration of modules.
[00:59:36] <AndyRussG>	 Just register like normal RL modules?
[01:00:09] <Krinkle>	 Every module has to be registered. All modules, dependencies and timestamps are in the module manifest in the startup module. Which is sent to all users globally and only cached for 5 minutes. Adding bloat to that is bad. So all in all, CentralNotice as a whole, should not register more than 3 or 4 modules.
[01:00:34] <Krinkle>	 regardless of wiki, language or which campaings/banner relates to them.
[01:00:47] <Krinkle>	 wiki, language, logged in, skin etc.
[01:00:56] <AndyRussG>	 yeah that sounds OK
[01:01:11] <AndyRussG>	 For our nefarious plans I think we'll only be adding 1 or 2, at least to start
[01:02:59] <Krinkle>	 AndyRussG: Are there are any mixins in existence now?
[01:03:08] <Krinkle>	 I see the global var in centralnotice but it's not set anywhere
[01:03:29] <Krinkle>	 The few lines in https://meta.wikimedia.org/wiki/MediaWiki:FR2014/Resources/SeenCountB.js should probably not be its own RL module
[01:07:10] <AndyRussG>	 Krinkle: there were some, they were obsolete and removed, and there's a patch to add a new one: https://gerrit.wikimedia.org/r/#/c/181239/
[01:07:33] <AndyRussG>	 But we're holding off on that patch until we see where we go with this new scheme
[01:07:51] <AndyRussG>	 Yes, definitely such short blobs have no place in a separate module
[01:08:17] <Krinkle>	 AndyRussG: Hm.. sorry for all the Qs, I'm all new to the terms and definitions
[01:08:18] <AndyRussG>	 It'd only become worth it if we can consolidate a significant amount of such blobs that are used together
[01:08:31] <AndyRussG>	 Krinkle: np! really appreciated :)
[01:08:32] <Krinkle>	 AndyRussG: So in the proposed system, would modules only be used for campaign-level javascript payloads?
[01:08:49] <AndyRussG>	 the new modules we're talking about, yes
[01:09:13] <AndyRussG>	 basically as in http://etherpad.wikimedia.org/p/CampaignAssociatedMixins
[01:09:32] <AndyRussG>	 Approach A is: an extra request the first time a user gets targeted by a campaign
[01:09:58] <Krinkle>	 Hm.. that suggests each mixin is its own module. And then a campaign or banner specifies which mixin it wants, and the client will load those first before displaying the banner.
[01:10:00] <AndyRussG>	 Approch B, which we're not favoring now, involves blatantly serving out more JS to more users constantly, albeit without the additional request
[01:10:04] <Krinkle>	 Sort of like a list of dependencies.
[01:10:24] <AndyRussG>	 Correct
[01:12:28] <Krinkle>	 AndyRussG: Hm.. I'm missing some connection about difference between campaigns and banners for this purpose. I assume not having it be per-banner is easier, but why?
[01:12:46] <AndyRussG>	 No, this is pre-banner
[01:13:04] <AndyRussG>	 Sorry about the terminology! Campaigns are the more general thing
[01:13:04] <Krinkle>	 not per-campaign?
[01:13:09] <Krinkle>	 (which mixins are used)
[01:13:18] <AndyRussG>	 Ah heh, pre-banner and per-campaign
[01:13:27] <AndyRussG>	 (Sorry I read pre not per)
[01:13:48] <AndyRussG>	 There are two reasons for having it per-campaign and not per-banner
[01:14:39] <AndyRussG>	 The architectural differnce is that with per-campaign we are running a bit of special JS after the campaign is chosen, but before the banner is chosen
[01:14:40] <Krinkle>	 async question: How are banner choices given from server to client? Is that an RL module now? I remember us talking about that a while back.
[01:15:28] <AndyRussG>	 For example, a campaign can have 4 banners: two alternative full-screen banners, and two alternative top-banners, and users will get one of each, and after a while of seeing banners, then none at all
[01:16:12] <AndyRussG>	 re: banner choices, yes that is a change we brought in a few months ago :) currently the server is able to somewhat narrow down which campaigns a user is eligible for
[01:16:53] <AndyRussG>	 So right away we send in a bunch of choices, i.e., a list of possible campaigns and banner names and other details for those campaigns
[01:17:13] <AndyRussG>	 On the client, more info is added into the mix and the final choice of campaign and banner is made
[01:17:34] <Krinkle>	 Right BannerChoiceDataResourceLoaderModule gets all options for the current RL context and that's loaded in the initial RL modules request from the top of the page?
[01:17:49] <Krinkle>	 s/options/choices
[01:18:22] <AndyRussG>	 yes
[01:18:46] <AndyRussG>	 Once a banner is chosen, it is fetched from the server via Special:BannerLoader. But that doesn't in fact necessarily mean that it will be shown
[01:19:07] <AndyRussG>	 Because the logic for _really_ deciding to show it is contained in JS in the actual banner
[01:19:40] <AndyRussG>	 For example, that's where the check for a previous full-screen, click-on-hide-button, banner-view-count etc comes in
[01:19:58] <AndyRussG>	 And that is the logic that we want to push out of the banners and into something that gets to the client sooner
[01:20:06] <Krinkle>	 right, and if that logic returns false, no banner will be shown for that view
[01:20:11] <AndyRussG>	 exactly
[01:20:17] <Krinkle>	 it chooses one, tries it, and then either shows it or not.
[01:20:41] <AndyRussG>	 Currently yes... but in the new system, it won't even have to fetch it when it won't be shown
[01:20:48] <Krinkle>	 So the JS in the banner can only decide to no-show, it can't influence the likelihood of being choosen.
[01:21:31] <Krinkle>	 But it sounded like the campaign JS can participate in the choosing logic?
[01:22:15] <Krinkle>	 Ah, right. The logic for prev-fullcreen, cookie-hidden, banner-count-max is eligible for mixin?
[01:22:34] * Krinkle feels like he almost gets it
[01:23:57] <AndyRussG>	 yeah!
[01:24:13] <AndyRussG>	 currently banners don't influence the likelyhood of being chosen
[01:24:30] <AndyRussG>	 They're chosen, and they run their JS and show themselves, or don't
[01:25:17] <AndyRussG>	 And in the new scheme, they'll still run JS but will normally be expected to definitely show if they're loaded
[01:25:36] <Krinkle>	 Right. the JS would be for interactive purposes?
[01:25:50] <AndyRussG>	 Right!
[01:26:12] <AndyRussG>	 Yeah there's more JS that is in the banner and can, I think, stay there
[01:26:22] <Krinkle>	 AndyRussG: Hm.. don't need to know for this, but I'm curious how the mixin would talk to the banner controller
[01:27:09] <AndyRussG>	 right! well, it's not yet determined, there is currently a minimal banner controller API that the in-banner-JS has access to
[01:27:10] <Krinkle>	 Yeah, I remember from last time. It makes sense to bundle them together. Wherever they go, special page or otherewise, keep together.
[01:27:30] <AndyRussG>	 ?
[01:27:45] <Krinkle>	 to bundle the <script> related to a specific banner and its other HTML as one string.
[01:27:58] <AndyRussG>	 Ah right yeah
[01:28:21] <AndyRussG>	 I mean, I'm not opposed at all to looking into some refactoring for optimising and code quality, but that'll be for another rainy day
[01:29:02] <Krinkle>	 AndyRussG: So banner controller would first decide on a campaign, then choose a banner, then load the mixin modules for that campaign, and if a-OK, load the banner?
[01:30:14] <AndyRussG>	 Krinkle: almost...
[01:31:48] <AndyRussG>	 Rather, banner controller would first decide on a campaign, then load the mixin modules for that campaign, and give the mixin modules the opportunity to influence banner selection (for example, by specifying a user's bucket) as well as determining if the banner should be really shown, and then, if a-OK, load the banner
[01:32:54] <AndyRussG>	 ^ that detail is for another issue that I haven't mentioned yet, I think, which is the "lost impressions" to avoid repeated full-screen banners
[01:33:36] <AndyRussG>	 Basically, as things stand, since the logic to detect previous full-screen views is actually in the banners, a banner has to be loaded to run it
[01:35:01] <AndyRussG>	 So if a user has already seen a full-screen banner, at the start of a campaign, they'll still get the full-screen banner loaded but won't see it; instead the banner has JS to detect the previous full-screen view and put the user in a special "bucket" that will prevent them from seeing any more full-screens for the duration of that campaign
[01:35:13] <Krinkle>	 AndyRussG: Hm.. would the mixin code need to know about banners in a campaign (e.g. not re-usable from one campaign to another)
[01:35:13] <AndyRussG>	 I know, it's pretty convoluted
[01:36:45] <AndyRussG>	 Good quesiton... the answer is, no, we have "buckets" that banners in a campaign can be associated with, so the mixin can just choose a bucket, and the campaign creators can know which buckets different banners are associated with, and set the mixin's paramters appropriately
[01:37:06] <AndyRussG>	 Yeah these would definitely need to be reusable
[01:38:29] <Krinkle>	 AndyRussG: OK. This sounds great.
[01:38:36] <AndyRussG>	 Krinkle: woohoo! :)
[01:38:46] <Krinkle>	 Can't find any holes :)
[01:39:06] <Krinkle>	 AndyRussG: Looks like the mixin modules would be (static) resourceloader file modules?
[01:39:14] <Krinkle>	 registered in the CN extension?
[01:40:11] <AndyRussG>	 yup!
[01:40:19] <Krinkle>	 Perfect
[01:41:12] <AndyRussG>	 great!
[01:42:22] <AndyRussG>	 may I quote you in the Phabricator task? >_>
[01:42:30] <AndyRussG>	 <_<
[01:42:50] <AndyRussG>	 (don't worry, I'll still take all the blame if it blows up... :)
[01:43:17] <Krinkle>	 AndyRussG: Yeah. Anything in particular?
[01:43:34] <AndyRussG>	 Ah just the "can't find any holes" part :)
[01:44:38] <AndyRussG>	 https://phabricator.wikimedia.org/T90913 (I'll also move some stuff from the etherpad there...)
[01:44:45] <Krinkle>	 Sure
[01:46:03] <AndyRussG>	 K!
[01:46:24] <AndyRussG>	 Thanks so much for taking a close look, really appreciate it :)
[01:48:25] <Krinkle>	 You're welcome :)
[01:50:02] <AndyRussG>	 \o/
[14:23:45] <wikibugs>	 Wikimedia-Fundraising, MediaWiki-extensions-CentralNotice, Epic, HTTPS-by-default, and 3 others: Special:RecordImpression should die in a fire - https://phabricator.wikimedia.org/T45250#1109448 (AndyRussG)
[14:23:47] <wikibugs>	 § Fundraising Sprint Abba, § Fundraising Sprint Beastie Boys, § Fundraising Sprint the Cure, Fundraising Tech Backlog, and 3 others: Do banner hiding with mixins - https://phabricator.wikimedia.org/T86100#1109450 (AndyRussG)
[16:38:32] <grrrit-wm>	 (PS3) AndyRussG: QUnit: avoid PHP error by using fallback API URL for banner choices [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/195200 (https://phabricator.wikimedia.org/T91763)
[16:46:04] <K4-713>	 awight: I'm stuck in all the meetings today. Can you find a place for that XML to live, somewhere in public?
[16:46:12] <awight>	 K4-713: shore thing!
[16:46:28] <K4-713>	 thanks. I owe you one One.
[16:46:34] <awight>	 no way.
[16:47:53] <awight>	 K4-713: Can I say that we use it for the coding task?
[16:48:01] <K4-713>	 Yep.
[16:48:07] <awight>	 ok
[16:48:53] <K4-713>	 Just don't publish my list of automatic strikes. Har.
[16:49:30] <awight>	 :)
[17:01:21] <grrrit-wm>	 (CR) Ssmith: [C: 2] Fix time windowing and grouping [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/195807 (owner: Ejegg)
[17:03:39] <grrrit-wm>	 (CR) Ssmith: [C: 2] Don't immediately request data when not saved [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/195766 (owner: Ejegg)
[17:04:32] <grrrit-wm>	 (Merged) jenkins-bot: Don't immediately request data when not saved [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/195766 (owner: Ejegg)
[17:11:42] <grrrit-wm>	 (PS4) AndyRussG: QUnit: avoid PHP error by using fallback API URL for banner choices [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/195200 (https://phabricator.wikimedia.org/T91763)
[17:16:31] <grrrit-wm>	 (CR) AndyRussG: "I don't know why the jenkins QUnit job output for PS4 only shows warnings called from lines 91 and 106 of CNBannerChoiceDataResourceLoader" (2 comments) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/195200 (https://phabricator.wikimedia.org/T91763) (owner: AndyRussG)
[17:18:10] <grrrit-wm>	 (CR) Ssmith: [C: 2] Set dropdown initial values to saved values [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/195767 (owner: Ejegg)
[17:24:22] <grrrit-wm>	 (CR) Ejegg: [C: 2] Move remaining contrib modules into new home [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195347 (owner: Awight)
[17:25:45] <grrrit-wm>	 (CR) Ejegg: [C: 2] Add JSHint configuration [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/195355 (owner: Awight)
[17:30:09] <wikibugs>	 Wikimedia-Fundraising-CiviCRM, Continuous-Integration: CI for Civi: provision and run tests under Jenkins/Zuul - https://phabricator.wikimedia.org/T86103#1110110 (Ejegg)
[17:35:42] <wikibugs>	 Wikimedia-Fundraising-CiviCRM, Fundraising Tech Backlog, Release-Engineering, Scrum-of-Scrums, and 2 others: Continuous integration - CiviCRM - https://phabricator.wikimedia.org/T78100#1110140 (Cmcmahon)
[17:36:41] <grrrit-wm>	 (Abandoned) Ssmith: Fix some style things with nav [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/185102 (owner: Ssmith)
[18:27:05] <atgo>	 hey awight if you're lookign for a cookie to lick, K4-713 had mentioned she thought you could be on this? https://phabricator.wikimedia.org/T91446
[18:27:18] <atgo>	 gc is impatient for it :/
[18:27:40] <K4-713>	 did ejegg start on that?
[18:30:39] <ejegg>	 just looking at stuff, didn't fill anything in yet
[18:41:10] <AndyRussG>	 awight: Hi! does the plan in https://phabricator.wikimedia.org/T90913 now seem solid enough to go ahead an try to implement? (np if ur busy)
[18:45:58] <grrrit-wm>	 (PS1) Ejegg: Fix board nav links [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/195979
[18:46:39] <grrrit-wm>	 (CR) jenkins-bot: [V: -1] Fix board nav links [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/195979 (owner: Ejegg)
[18:49:42] <grrrit-wm>	 (PS2) Ejegg: Fix board nav links [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/195979
[19:19:24] <ejegg>	 pizzzacat: would it make sense for me to fix the labels and you to do the UI stuff with the library and the modals?
[19:19:35] <ejegg>	 I have an idea of how to do the label stuff
[19:20:52] <wikibugs>	 Wikimedia-Fundraising-CiviCRM, Fundraising-Backlog: Spike: do cancelled paypal subscriptions appear in civi? - https://phabricator.wikimedia.org/T92326#1110594 (CCogdill_WMF) This question is based on the bi-monthly recurring failure scan I run. The top results are consistently PP recurring failures and...
[19:25:57] <pizzzacat>	 ejegg um
[19:26:12] <pizzzacat>	 sure
[19:26:31] <pizzzacat>	 just let me know when you're done ejegg?
[19:26:52] <ejegg>	 OK, will do.  I'm just touching widgetBase.js so far
[19:27:11] <ejegg>	 Oh, I will need to touch x-by-y.js too
[19:27:13] <pizzzacat>	 oh it wouldn't need to touch x by y?
[19:27:20] <pizzzacat>	 yeah
[19:32:11] <pizzzacat>	 can I just push up this small change on x by y first?
[19:32:16] <pizzzacat>	 ejegg
[19:32:21] <ejegg>	 please do, I'll work around it
[19:32:26] <pizzzacat>	 ok cool
[19:56:31] <grrrit-wm>	 (PS1) Ssmith: Fix time display, remove refresh and profile btns [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/195996
[19:57:54] <pizzzacat>	 ejegg it's ready
[19:57:59] <ejegg>	 looking!
[19:58:09] <pizzzacat>	 no rush! gonna grab lunch now
[20:01:46] <grrrit-wm>	 (CR) Ejegg: "Looks good, but can you please keep the spaces / tabs consistent within a file?" [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/195996 (owner: Ssmith)
[20:23:58] <awight>	 AndyRussG: Sure does look solid!
[20:24:19] <AndyRussG>	 awight: fabtastique, thanks :)
[20:24:50] <awight>	 I'm curious enuf that I might peek at when getDependencies is called...
[20:25:20] <awight>	 Hrm--from the startup module.  This might work!
[20:25:23] <AndyRussG>	 It's only from ResourceLoaderStartUpModule
[20:25:41] <AndyRussG>	 Yeah, assuming caching and updating works appropriately :) which it should
[20:25:49] <AndyRussG>	 since it's working fine now
[20:26:51] <AndyRussG>	 Currently it bumps the version of CNBannerChoiceDataResourceLoaderModule when needed, and the times that the info will change are the same pre and post nefarious plan implementation
[20:27:10] <awight>	 pretty exciting...
[20:27:29] <AndyRussG>	 Again deforming the original intent of RL to new pretzel shapes!
[20:27:36] <awight>	 :)
[20:28:18] <AndyRussG>	 Next time we could make RL a finite state machine-based AI that could take over FR
[20:29:03] <awight>	 or we could have Civi make the final judgements
[20:29:53] <AndyRussG>	 ooh or a battle of the bits between RL and Civi!
[20:41:44] <atgo>	 hey AndyRussG you should add a picture to your phab acct
[20:41:45] <atgo>	 :Pp
[20:44:16] <AndyRussG>	 atgo: ahh hmm, the default icon has too much hair on its head?
[20:44:16] <AndyRussG>	 uhh ok, will do :)
[20:44:37] <atgo>	 hahaha :P
[20:44:46] <atgo>	 i mean... no big deal
[20:45:35] <grrrit-wm>	 (PS1) Ejegg: WIP: Fix x axis labels [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/196010
[20:51:28] <AndyRussG>	 atgo: ah OK... yeah, I mean thanks for reminding me about it :) I was planning to do it sometime sooooon 8p
[20:53:04] <wikibugs>	 § Fundraising Sprint Abba, § Fundraising Sprint Beastie Boys, § Fundraising Sprint the Cure, Fundraising Tech Backlog, and 3 others: Do banner hiding with mixins - https://phabricator.wikimedia.org/T86100#1110988 (AndyRussG)
[20:53:06] <wikibugs>	 Wikimedia-Fundraising, MediaWiki-extensions-CentralNotice, Epic, HTTPS-by-default, and 3 others: Special:RecordImpression should die in a fire - https://phabricator.wikimedia.org/T45250#1110989 (AndyRussG)
[20:54:43] <pizzzacat>	 ejegg sorry about the spacing issue… in my IDE it's not showing up that way
[20:54:56] <awight>	 AndyRussG: all we have to look at is this old snapshot of you, the incense and stuff is already causing the image to fade 8)
[20:55:09] <ejegg>	 pizzzacat: what IDE?
[20:55:28] <AndyRussG>	 awww... hmm which one is that I wonder?
[20:55:34] * AndyRussG is touched :)
[20:55:39] <pizzzacat>	 Sublime
[20:56:39] <pizzzacat>	 just emailed you a snapshot.. wonder what I can do to fix this issue
[20:56:45] <AndyRussG>	 (awight: silliness aside, thanks for the reminder...)
[20:56:56] <ejegg>	 pizzzacat: there's got to be a setting
[20:57:03] <awight>	 AndyRussG: https://catfc.files.wordpress.com/2009/07/img_0267.jpg
[20:57:14] <ejegg>	 ideally to keep the existing whitespace in each file
[20:57:23] <pizzzacat>	 ohh "convert spaces to tabs"
[20:57:33] <AndyRussG>	 pizzzacat: hmmm!
[20:57:40] <pizzzacat>	 I wonder why it isn't using tabs because *I'm* using tabs
[20:57:46] <pizzzacat>	 to lazy to space 4 times
[20:57:48] <pizzzacat>	 *too
[20:58:03] <ejegg>	 it must be converting tabs to spaces then
[20:58:05] <pizzzacat>	 two lazy too space for thymes
[20:58:11] <ejegg>	 heh
[20:58:13] <pizzzacat>	 yeah.. weird
[20:58:19] <pizzzacat>	 will take a look at my config
[20:58:26] <pizzzacat>	 sorry, I know that's annoying!
[20:58:33] <ejegg>	 oh hey, there's a thing called .editorconfig
[20:58:42] <ejegg>	 let me check in a file
[20:58:48] <ejegg>	 see if that helps
[20:59:25] <pizzzacat>	 weird, I have:
[20:59:28] <pizzzacat>	     // Set to true to insert spaces when tab is pressed
[20:59:28] <pizzzacat>	     "translate_tabs_to_spaces": false,
[21:00:18] <pizzzacat>	 everything seems set right. do you mean .editorconfig in gerrit or somewhere?
[21:02:04] <grrrit-wm>	 (PS1) Ejegg: Add .editorconfig [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/196020
[21:02:25] <ejegg>	 pizzzacat: try checking out that change^^^, then close and re-open the project in sublime
[21:02:32] <ejegg>	 then make some changes to a js file
[21:02:43] <ejegg>	 and do a git diff to see what the changes look like
[21:03:01] <grrrit-wm>	 (PS1) Awight: Check in our customizations prior to upgrade [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/196021 (https://phabricator.wikimedia.org/T77910)
[21:03:27] <pizzzacat>	 ok will do ejegg
[21:03:33] <ejegg>	 pizzzacat: oh, .editorconfig is a plugin you need to install
[21:03:42] <ejegg>	 is there a Package Control thing?
[21:03:53] <pizzzacat>	 in my Sublime, yes
[21:03:59] <ejegg>	 look for EditorConfig and snag that
[21:04:05] <pizzzacat>	 ok
[21:07:55] <pizzzacat>	 ejegg how would I be able to tell a difference in the diff?
[21:09:21] <ejegg>	 oh hey, you can just show hidden chars in preferences -> settings
[21:09:27] <ejegg>	 draw_white_space: all
[21:09:49] <ejegg>	 or draw_white_space: selection
[21:10:15] <pizzzacat>	 I already have that set
[21:10:18] <ejegg>	 and there's a plugin to make that easier: HighlightWhitespaces
[21:10:50] <pizzzacat>	 I have it set to selection which is how I could see that spaces were used instead of tabs after you commented
[21:10:59] <ejegg>	 ohh, i see
[21:11:00] <ejegg>	 cool
[21:11:00] <pizzzacat>	 but I don't have it on all the time because it's ugly and drives me bonkers
[21:11:11] <pizzzacat>	 and I only use tabs, never use spaces
[21:11:14] <ejegg>	 yeah, definitely ugle
[21:11:17] <ejegg>	 ugly
[21:11:21] <pizzzacat>	 and I have the "use tabs on indent" setting set
[21:11:31] <pizzzacat>	 so I dunno why this shizzle happenin
[21:11:33] <ejegg>	 ok, so with the EditorConfig plugin and that .editorconfig file
[21:11:51] <ejegg>	 does it still convert tabs to spaces if you add stuff to a js file?
[21:11:53] <pizzzacat>	 I have it now and looked at the diff but I'm not really sure what I'm looing for
[21:12:03] <ejegg>	 ah, forget about the diff
[21:12:09] <ejegg>	 if you can see it right in the editor
[21:12:24] <pizzzacat>	 ha no
[21:12:28] <pizzzacat>	 no it doesn't
[21:12:35] <pizzzacat>	 I mean the opposite
[21:12:39] <pizzzacat>	 it still gives spaces
[21:12:52] <pizzzacat>	 it doesn't change/update to tabs
[21:12:58] <pizzzacat>	 baahh
[21:13:49] <pizzzacat>	 so do you want to agree on a convention? tabs, equal to 4 spaces?
[21:14:02] <pizzzacat>	 I can fix files as I touch them
[21:14:05] <ejegg>	 yeah, i prefer tabs
[21:14:11] <pizzzacat>	 word
[21:14:16] <ejegg>	 as long as we can both make our IDEs use em
[21:14:39] <pizzzacat>	 yeah.. I mean I can keep digging to solve it but in the meantime try to check to make sure it's using tabs
[21:14:48] <pizzzacat>	 until I find the thing that actually fixes it
[21:15:20] <pizzzacat>	 ¯\_(ツ)_/¯
[21:25:05] <grrrit-wm>	 (CR) Ssmith: [C: 2] "doesn't really fix my issue but doesn't hurt, if it does for others!" [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/196020 (owner: Ejegg)
[21:25:36] <grrrit-wm>	 (Merged) jenkins-bot: Add .editorconfig [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/196020 (owner: Ejegg)
[21:31:46] <grrrit-wm>	 (CR) AndyRussG: "P.S. It's true error handling/warning stuff is suboptimal, including on the API path... hence the TODO..." [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/195200 (https://phabricator.wikimedia.org/T91763) (owner: AndyRussG)
[21:34:21] <grrrit-wm>	 (PS2) Ssmith: Fix time display, remove refresh and profile btns [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/195996
[21:42:06] <pizzzacat>	 ejegg do you mind +2ing? ^
[21:47:50] <pizzzacat>	 also, everyone, here is your cat of the day… https://38.media.tumblr.com/168cebc46275a04c61f66e3a8a28d55a/tumblr_nkwnasRqP21s7fwo7o1_400.gif
[21:49:16] <awight>	 Bad to the core
[21:50:29] <pizzzacat>	 bad???
[21:50:36] <pizzzacat>	 is this opposite day?
[21:54:02] <awight>	 :p baaad.
[21:55:54] <grrrit-wm>	 (CR) Ejegg: "Oops, just noticed it's the wrong time period. Want to just go back to 'by ' + timeChoice() ? That will work better if we want to save t" (1 comment) [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/195996 (owner: Ssmith)
[22:32:04] <atgo>	 https://phabricator.wikimedia.org/T91452
[23:17:25] <atgo>	 hey awight i assume i know the answer, but do we have any docs about how recurring works?
[23:19:07] <awight>	 <<_
[23:19:14] <awight>	 who's asking :p
[23:19:20] <atgo>	 ellery :)
[23:19:30] * awight jiggles the IRC.
[23:19:43] <awight>	 He must be scared of distractions :D
[23:20:26] <atgo>	 haha it's... secondary sources
[23:20:40] <atgo>	 if we have something we can just send that would be helpful. otherwise i'm making a phab task to make something
[23:22:16] <awight>	 Sorry, I can't find anything.  It's... pretty simple :x  it would help if he can tell us specifically what he wants to understand.
[23:27:21] <atgo>	 cool
[23:30:55] <atgo>	 ok one more question
[23:31:03] <atgo>	 UTC-8 != pacific, right?
[23:31:11] <atgo>	 awight ejegg andyrussg
[23:31:21] <atgo>	 like doesn't UTC not do DST?
[23:31:23] <awight>	 atgo: I think we're in -7 now
[23:31:26] <atgo>	 right
[23:31:28] <atgo>	 that's what i'm after
[23:31:28] <awight>	 no, it doesn't
[23:31:30] <atgo>	 thanks :)
[23:31:48] <awight>	 yeah, you have to second-guess ical and google this month, they have bugs every time.
[23:32:32] <atgo>	 and we would MUCH prefer something that doesn't use DST for any audit
[23:32:34] <AndyRussG>	 atgo: meatings have been ontime as indicated by my calendar so far :) we also went on DST at the same time as u
[23:32:59] <AndyRussG>	 We're not UTC-4 but used to be UTC-5
[23:33:01] <AndyRussG>	 now
[23:33:02] <AndyRussG>	 I meant
[23:33:06] <AndyRussG>	 s/not/now/
[23:33:06] <atgo>	 right
[23:33:10] <atgo>	 :)
[23:33:13] <atgo>	 snow?
[23:33:47] <atgo>	 awight for audit we always want something without daylight savings, right?
[23:33:50] <awight>	 atgo: yep.  but fwiw, some large vendors such as PayPal insist on local time reports, so they have... company.
[23:33:56] <atgo>	 ok cool
[23:33:57] <atgo>	 thanks :)
[23:33:58] <awight>	 we can't really insist
[23:34:11] <awight>	 However.  Can they just include the timezone?  that's good enuf.
[23:34:20] <atgo>	 thank you!
[23:34:59] <awight>	 atgo: If you care to troutslap them, http://en.wikipedia.org/wiki/ISO_8601
[23:35:17] <atgo>	 :)
[23:35:38] <wikibugs>	 Wikimedia-Fundraising, Wikimedia-Fundraising-CiviCRM, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips: Make Civi Reminders work in Staging - https://phabricator.wikimedia.org/T86345#1111601 (atgo) @ejegg @rlewis @caitvirtue I see a reminder went out - is this one...
[23:41:19] <wikibugs>	 Wikimedia-Fundraising-CiviCRM, Fundraising-Backlog, Fundraising Sprint G: Spike: What happened with this JP Morgan import? - https://phabricator.wikimedia.org/T92463#1111615 (atgo) NEW
[23:44:14] <wikibugs>	 § Fundraising Sprint Abba, Fundraising-Backlog: Spike: Let's take a look at recurring - https://phabricator.wikimedia.org/T86087#1111633 (atgo)
[23:47:15] <AndyRussG>	 Hey awight...! So I'm checking out https://phabricator.wikimedia.org/T86100...
[23:47:32] <AndyRussG>	 Really sorry again for having taken so many eons and decades with it
[23:47:45] <AndyRussG>	 Not to mention teraseconds
[23:48:44] <AndyRussG>	 Of the patches mentioned in that card, three are already merg'd an' deploy'd: https://gerrit.wikimedia.org/r/#/c/181240/ https://gerrit.wikimedia.org/r/#/c/182897/ https://gerrit.wikimedia.org/r/#/c/182107/
[23:49:02] <awight>	 AndyRussG: No worries, I'm happy with the way it worked out... u got to it exactly when there was a way to implement it in a meaningfully better way...
[23:49:26] <awight>	 yes, those are cleanup
[23:49:35] <AndyRussG>	 Yeah! So those are all great
[23:50:58] <AndyRussG>	 So here is what I think we'll end up with following the whole campaign-mixin-banner-history show:
[23:51:19] <AndyRussG>	 - show/hide logic and banner history as campaign-associated mixins
[23:51:41] <AndyRussG>	 - a few other commonly used features that work more closely with banners as banner-associated mixins
[23:51:57] <AndyRussG>	 - a refactored bannerController API
[23:53:11] <AndyRussG>	 So the question is, in view of that, where to with these patches? https://gerrit.wikimedia.org/r/#/c/181244/  https://gerrit.wikimedia.org/r/#/c/181239/
[23:55:12] <AndyRussG>	 The second one, namesake of the actual Phab task, I guess is not worth pursuing for now, if there'll be a campaign-associated mixin for that... Really sorry! IIRC it was more or less a copy-paste from the JS on meta, right? If so I guess I shouldn't feel too badly about it, then...
[23:55:55] <AndyRussG>	 It just seems that changing the FR workflow, albeit slightly, twice in a pretty short period isn't worth it
[23:59:07] <AndyRussG>	 Let's say all things considered, we may get the whole campaign-associated show/hide mixin deployed in a month? Maybe it's not worth the double change within that timeframe? I could very definitely be dead wrong, please LMK if so 8p