[00:05:41] AndyRussG|souper: When you get back, can you open that google doc for commenting? [00:06:10] I'm still frowning over the "one campaign at a time" thing. [00:07:46] If we do that, I think we have to rename the extension to CentralFundraisingToyWithOccasionalNoticesMaybe. [00:08:11] ...and that's long. [00:14:49] K4-713: what "one campaign at a time" thing? [00:15:23] "When a user is part of a test, they are not part of “any”/”any other” campaigns" [00:15:54] K4-713: Ah OK, yeah just lemme give you a bit of context on the doc [00:16:12] So, the way this reads (and what we were talking about yesterday with analytics) was that they intended to keep individuals from seeing any other notices until the test was over. [00:16:13] That's Ellery's initial scoping out of _his_ requirements for A/B testing [00:16:25] Yeah, I got some of this in person, too. [00:16:30] Yeah that's not necessarily an indication of anything that's actually happening [00:16:38] Hmm. [00:16:52] Okay, so what is this, then? [00:17:26] The needs of not having experiments interfere with each other are OK, but not able to trump anything, and there are short and medium and longer term stuff [00:18:10] I don't understand how we can enforce that in code without that being totally contradictory. [00:18:11] K4-713: the document is a mishmash of notes that follow up on various meetings [00:18:16] Aha. [00:18:17] Okay. [00:18:23] So... you don't want comments? [00:18:24] You can safely ignore that part :) [00:18:32] Ah yes, just lemme tell you where :) [00:19:08] So the main problem we're addressing is that buckets have been found to be not reliable and cycling endlessly [00:19:16] mhm [00:19:40] So the last meeting we got this prioritized list of requirements/wishlist for a quick fix [00:19:59] Ah, I see. [00:20:10] Those are under the heading "Immediate Solutions: Requirements" on page 3 [00:20:45] Got it. [00:20:56] Underneath that is a bunch of notes from brainstorming from several more meetings w/ Adam and ejegg|away [00:22:05] In addition to the "Immediate Solutions: Requirements" on page 3, the other part that would be great to get input on is "Immediate Solutions: Option 3, Detail", at the very end [00:22:24] That's what I just added, basically a proposal for a relatively quick fix that hits the requirements [00:24:16] based on Adam's idea (shorter versionis option 3 in the brainstorming section above), just really a more detailed scoping out [00:24:59] phase = treatment in that last bullet point in Client action? [00:25:23] Or is that something else? [00:25:32] K4-713: basically... [00:26:03] It's for the thing they've been wanting to with fullscreen first then upper banner after [00:26:26] So it's like instead of using buckets, which are really a different concept, it would use a new parameter called "phase" or "treatment phase" [00:26:26] Right, totally. I just didn't know if there was something else we were calling "phase". [00:26:28] If this goes awry, how painful is it going to be to roll back? [00:26:30] or something like that [00:26:43] Hmm [00:26:48] Well no DB schema change are involved [00:26:50] After the cache... implodes, as you say. :) [00:27:21] implodes as in becomes smaller and in reality stronger [00:27:41] (sorru trying to type with maple sugar on my fimgers) [00:28:02] hahaha [00:28:40] That's how we get ants! [00:28:56] hmm no wonder my laptop overheats... [00:29:02] So, cache getting smaller is great. [00:29:07] Yeah [00:29:17] The only issue with rollback I can see is that current buckets would be reset [00:29:19] So, it gets smaller, and then we notice something is wrong and have to roll back... [00:29:37] I guess it's probably just the standard 15 minute wait time anyway. [00:29:39] Well it just refreshes stuff when it gets the new old hits again [00:29:49] Okay, neat. [00:30:12] This seems reasonable. [00:30:30] I think, though, that we're going to want to schedule a deploy carefully here. [00:30:38] ...they're starting France for real tomorrow, I think. [00:30:59] We should leave that alone. [00:32:28] Yeah I think so too [00:32:53] There was some talk of as an even more temporary solution increasing the bucket duration [00:33:06] I don't know if that would have to be consulted with anyone [00:33:12] Are they interested in having any of these things for France? [00:33:29] I didn't hear that come up in the same thread anywhere. [00:33:35] I thiiink they may but I really don't know [00:33:43] This is all just Big-EN, right? [00:33:51] I think it's the main target [00:33:54] Yeah, we should ask atgo at some point. [00:34:07] Yeah... She was there at the last meating [00:34:22] Yeah, and she should be in charge of the priorities. [00:34:27] Yep [00:34:33] I'm sure this is all going to come up in prawning tomorrow, too. [00:34:44] Yep [00:35:09] In any case I was going to try and start on a tentative implementation [00:35:43] Also regarding the potential for awrygoingness, it might be fun to do a few unit tests... (?) [00:37:35] I'm 100% completely and whole-heartedly in favor of more tests. [00:37:56] And so is everybody else, even if they tell you differently. :p [00:43:10] cool! [02:10:55] I was walking in the countryside [02:11:02] split ends on eyebrows [07:08:00] (CR) Springle: [C: -1] WIP Schema for persistent global allocation tracking (2 comments) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/159403 (owner: AndyRussG) [15:25:20] (PS1) AndyRussG: WIP Temporary fix for bucket stickiness and expiry [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/169721 [15:33:57] (CR) AndyRussG: "Smoke tested..." [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/169721 (owner: AndyRussG) [16:10:25] Hi ejegg :) [16:10:33] Dija see https://gerrit.wikimedia.org/r/169721 ? [16:25:39] Hey awight :) [16:27:29] Hi AndyRussG [16:27:42] ejegg: :) [16:28:18] looking at the patch now [16:28:21] AndyRussG: morning! [16:28:46] I've only read the summary so far, but I don't think it gives us what we need... [16:28:54] awight: hi :) [16:29:05] awight: no it doesn't, it'd be just for France right now [16:29:09] ah [16:29:27] but it will mess with everyone else's bucketing... [16:29:48] probably, both making buckets last too long (across tests), and also resetting in the middle of tests. [16:29:53] true but really it's sort of in the spirit of what they currently expect bucketing to do, no? [16:30:13] no it'd only reset if you haven't gotten a banner in 7 days or more [16:30:36] so I think no one would be expecting a bucket to last more than that currently, anyway [16:31:11] ah, I read the last bullet point as, a single blank impression will reset the bucket cookie [16:31:35] Ah well yes that is correct [16:32:04] but that's not a hide, only a "no banner sent from the server", i.e., you're not in a campaign or a test anyway [16:32:27] hmm... [16:32:40] * awight looks at FR configuration [16:32:42] on any site currently in a campaign, the buckets will last, unless the campaign is disabled and then re-enabled [16:33:06] and in that case, only for the users visiting the site during the window if disenablement [16:33:11] This also won't reset existing 1-week cookies, will it? [16:34:22] not for sites currently experiencing campaigns, no [16:34:56] any site currently running a campaign, the cookies stick around for a week as supposed [16:35:25] also more notes at the end of the Google Doc [16:36:20] I have to run for a few minutes... will think about this workaround, thanks! [16:36:52] I'll put it out there to get more comments, K? [16:43:02] ejegg: If u wanna let me know any preliminary comments you have about whether this is worth puting out there as a tentative proposal... that'd be fantastic... thanks in advance! :) [16:44:39] AndyRussG: It seems ok - are we sure you never get a blank banner back while a campaign's on, even if it's throttled? [16:44:54] ejegg: aaaaaaaaaaaaaaah very good point [16:45:13] Humf! [16:46:59] K maybe that bit has to change then 8/ [16:48:16] why does it need to reset if the cookie expires in 7 days? [16:48:39] well it doesn't _need_ to [16:48:52] There is just some unreliability in browsers' eliminating cookies when they're supposed to [16:49:03] and they did want some randomization [16:49:18] hey AndyRussG! [16:49:21] but without the clearing of cookies it still would give them a quick fix of sticky [16:49:25] Hi atgo :) [16:49:39] wow, hanging on to cookies too long sounds like a bad browser bug [16:50:16] it looks like you're in the middle of something (and I logged into IRC halfway through)... but i'm reading through the bucket doc and wanted to check in before i talk to megan [16:50:53] atgo: sure! very very temporary fix that awight|biab and ejegg have been helping me with :) [16:51:00] ejegg: https://support.mozilla.org/en-US/questions/983361 [16:51:47] so... i see that there's a potential longer term solution you guys have agreed to, yeah? [16:51:54] you and awight|biab [16:51:57] ejegg: https://bugzilla.mozilla.org/show_bug.cgi?id=576347 [16:52:36] atgo: I think it's closer to being agreed upon but I feel like at least a bit more input is needed still [16:52:41] ok, fair enough [16:52:46] Man, Firefox fail [16:52:55] AndyRussG is the idea that this would be feasible before december? [16:53:00] atgo: yes [16:53:03] sweet [16:53:12] but not before france, which is more or less right now :) [16:53:46] and then i saw that megan had a question about buckets being sticky. If I'm understanding the issue correctly, we can't make buckets sticky, but we could theoretically extend the length of the buckets [16:53:53] which would make them less unsticky [16:54:02] So potential very very temp solution is the small patch that ejegg and awight|biab have been looking at (https://gerrit.wikimedia.org/r/#/c/169721/, just about to make a change there following ejegg's comment) [16:54:03] for this short term purpose [16:54:13] atgo: no, the above fix would make them sticky [16:54:20] for a week [16:54:27] as was always assumed they were [16:54:32] ah! sweet! [16:54:40] so that's awesome [16:54:52] and you guys are working on that now, and will send an update when it goes out, yeah? [16:55:17] and the other fix would give the other requirements, hopefully before Grand Anglo [16:55:53] rad [16:55:57] yeah, I have an e-mail almost all fired up and ready to go, still a small tweak needed now [16:56:04] awesome. thanks AndyRussG [16:56:08] and ejegg and awight|biab :) [16:56:13] i've got to run to a meeting [16:56:27] atgo: np, thanks also, have fun [16:58:07] ejegg: yeah it's a silly bug, actually glad I learned about it by chance a little while ago [16:59:07] surprising nobody's fixed it yet [17:01:10] you could be the first! :) [17:05:38] (PS2) AndyRussG: WIP Temporary fix for bucket stickiness and expiry [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/169721 [17:06:57] (CR) AndyRussG: "This patch set: no longer remove/invalidate cookies if no banner is received, since that's not compatible with campaigns that are not runn" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/169721 (owner: AndyRussG) [17:11:26] ejegg: ^ [17:15:17] cool, looking [17:15:37] thx [17:21:22] AndyRussG: So with this change, we don't store a bucket cookie unless they're seeing a banner [17:21:39] exactly [17:22:01] And every time they go to a site and do get a banner, the cookie expiry gets reset [17:24:37] there's no case where someone would WANT the user to stay in a bucket that didn't get a banner, is there? [17:25:34] ejegg: There should be no case when they want them to stay in a bucket longer than a week since the last time they got a banner, since bucket expiry is configured to be 1 week [17:25:57] Oops, Scrum of scrums is creeping up quickly. Anybody got anything I should share with them / ask from them? [17:26:19] not on my part, thanks :) [17:27:01] If at the start of a campaign they get a banner, then for several visits they get no banner, and just before the week is up they do get a banner, then their cookie would be extended one week more [17:27:19] If they never get a banner during the whole campaign then their bucket is irrelevant anyway [17:28:25] ok, buckets are always used for banner 1 vs banner 2, never for banner vs no banner [17:31:03] ejegg: hum, that is an interesting question too [17:31:30] I think you made a safe assumption though [17:31:54] heh I think you found a brilliant and relevant edge case [17:31:55] AndyRussG: so, I think the stickiness part is good, but the resetting is too arbitrary. [17:32:13] ejegg|ScrumOScru: your nickname should be "edge-egg" [17:32:14] However, if we take that part of the patch out, we have overly sticky buckets which never reset. [17:32:20] awight: I just did! check out PS2 [17:32:58] See above ejegg|ScrumOScru's edge case, but it's unusual enough to not matter for now, good to consider for any upcoming stuff tho! [17:33:09] k. we need to talk to ewulczyn about whether the extra stickiness is acceptable. I think it's a slight improvement over extending the cookie to a longer, fixed duration [17:33:25] but not resetting between tests is... unfortunate [17:33:26] yeah exactly that's the idea [17:33:50] He's the one who could evaluate this tradeoff from a statistical perspective... [17:34:25] now, where is he... [17:35:08] pinging in gchat... [17:35:57] AndyRussG: also... I had a thought about this: rather than me making assumptions about what WMDE would say, how about u get in touch with them? [17:36:27] They seem to be a CN admin group trying to use the tools in a more statistically rigorous way. [17:37:08] LPintscher is in SF today, I could ask her who is best to contact if you want. [17:37:23] ewulczyn: hi, Ellery! [17:37:43] awight: hey! [17:37:58] ewulczyn: AndyRussG is proposing what looks like a good fix for the bucket stickiness, but I'd like you to evaluate whether it's going to be *too* sticky [17:38:34] ewulczyn: hi! [17:38:38] ewulczyn: https://gerrit.wikimedia.org/r/#/c/169721/ and the very last new seciton of the Google Doc [17:38:39] The idea is that, the cookie expiration is refreshed at every banner impression. [17:38:54] AndyRussG: mind if I strikethrough options we've eliminated? [17:39:05] such as immediates 1 and 2 [17:39:09] please do! :) [17:39:13] k [17:39:26] awight: is it described in the doc? I'll give it a read now [17:41:11] ewulczyn: yes, Very Temporary Immediate Fix to only Stickiness (Very Tentative) [17:41:15] :) [17:41:49] is it option 3? [17:41:58] no, that's a longer-term thing we've been working on [17:42:19] the workaround we're discussing now is at the very bottom, "Very Temporary Immediate Fix to only Stickiness (Very Tentative) [17:42:23] " [17:43:05] page 6 [17:43:15] i see [17:44:03] ewulczyn: I'm afraid, for any quick workaround, the question comes down to how you would like to balance the errors: too much or too little stickiness? [17:44:34] basically this is better than just extending the cookie expiry because it's predictable and eliminates the cycling [17:44:52] With the current situation, we have a 0.5% chance of rebucketing during a 1hr test, and a 100% chance of rebucketing during a week-long test. [17:45:20] also, a 99.5% chance of making two consecutive hour-long tests dependent on one another... [17:45:54] For the proposed fix, it's a 100% chance of two tests within a week being dependent on one another... and a 0% chance of rebucketing for any test < 1 week long... [17:45:57] yeah it doesn't solve the need for re-shuffling but at least you know what you're getting [17:45:57] urgh [17:57:20] awight, AndyRussG: I'd say its not worth putting time into implementing this change. [17:59:05] ewulczyn: it's already implemented [17:59:30] ewulczyn: we could roll it out right away and have sticky buckets for the French [18:01:10] AndyRussG standup? [18:01:36] atgo: coming [18:03:42] AndyRussG, awight: Megan was concerned with sticky buckets because of the workaround they have for two stage treatments. If buckets are sticky then users see a banner on every page view. Her concern is that whenever we change a camapaign, people get rebucketed and people who already saw a full screen banner don't see anything (an artifact of their method). But since people [18:03:43] don't actually get rebucketed at every "test" its not an issue. [18:06:57] ewulczyn: on sec, in standup [18:15:13] ewulczyn: I think there's a bit of confusion on this... I'm going to send out an e-mail in any case since Anna and Megan are going to talk in a sec, but the main issue we're trying to address is https://www.mediawiki.org/wiki/Extension:CentralNotice/Buckets#Cycling_bucket_cookie_expiries.3F [18:17:40] ewulczyn: so I think the confusion is on the word "stickiness" [18:18:02] The problem is that buckets were not even sticky at all, they were cycling kinda randomly [18:18:26] So even the simplest A/B tests using buckets were not giving the expected results, unless they were very very short [18:19:10] As time goes on random rebucketing was increasing, so the longer a bucket-based A/B test, the less reliable the results [18:20:20] With this change A/B separation remains clean over the duration of any test up to a week long [18:20:49] And on the other topic you mention, the workaround for the two-stage treatment, I think it also makes that workaround feasable [18:23:40] Follwoing that, the next thing to work on would be the "Immediate Solutions: Option 3, Detail" which aims to solve more things, including the other "stickiness" issue, i.e., that buckets should be not stick and re-randomized in certain circumstances [18:24:15] and also the multiple treatment needs, so that that could be done properly, without hacky workarounds [18:24:25] ewulczyn: ^ does all that make sense? [18:24:46] AndyRussG: Yes, Agreed! This patch fixes one of our current problems. We still have the problem that tests interact with each other over time, because people don't get assigned to a treatment randomly at the start of each test. In principle, we will be able to run 1 correct test with the patch. To get correct data for more than 1 test, we need a rebucking feature. [18:25:12] ewulczyn: exactly [18:25:50] Once we have rebucking, the bucket might as well never expire. [18:26:01] yeah so the idea was to get this out first so one test can get going, and right away work on the more complete option that will re-randomize [18:26:03] edit: the bucket cookie might as well never expire [18:26:30] ewulczyn: yes... well I didn't want to change things too much because there are other users of CentralNotice [18:26:47] so we can't stray too far from what people expect to happen [18:26:56] AndyRussG: Ok, sounds like a plan! [18:26:58] rather here the idea was to make it work as expected [18:27:14] ewulczyn: fantastic :) [18:30:16] ewulczyn: thanks so much for taking a look at this, hugely appreciated... please do reach out anytime you have any comments or questions :) [18:31:04] AndyRussG: No problem, thanks for involving me in the discussion. I'm always up for thinking these things through [18:31:12] :) [18:39:33] ewulczyn: ok, so just to confirm here, you're okay with not rebucketing, for now? [18:41:11] I don't think we're going to have a rebucketing feature until the medium-term fix is rolled out. [18:42:01] When that happens, we can make buckets apply to exactly one campaign, and we will encourage CentralNotice admins to use campaigns for a single experiment. [18:44:06] awight: I would deploy this patch since its a step in the right direction. [18:44:10] AndyRussG: fyi, I'm gonna invite potential backdoor CN admins to the mailing list, so we have a way to communicate with them [18:44:23] ewulczyn: yeah for sure! [18:44:35] awight: Ohh sounds great! [18:45:09] AndyRussG: yah someone pointed out to me that Metawiki admins are able to (and do) use the CN admin interface. [18:45:15] I don't like it... but it's a fact for now. [18:45:31] yeah I think it's on the backend CN RfC [18:45:36] oh good! [18:45:46] it's OK they can ride the bandwagon [20:47:35] (PS1) Anomie: Add i18n for API module help [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/169805 [20:47:47] (PS1) Anomie: Add i18n for API module help [extensions/ContributionTracking] - https://gerrit.wikimedia.org/r/169811 [20:47:49] (PS1) Anomie: Add i18n for API module help [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/169812 [20:56:17] (CR) Anomie: "Note: If any reviewer sees any errors that need fixing, please feel free to fix it and upload a new patchset." [extensions/ContributionTracking] - https://gerrit.wikimedia.org/r/169811 (owner: Anomie) [20:58:55] (CR) Anomie: "Note: If any reviewer sees any errors that need fixing, please feel free to fix it and upload a new patchset." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/169812 (owner: Anomie) [20:59:46] (CR) Anomie: "Note: If any reviewer sees any errors that need fixing, please feel free to fix it and upload a new patchset." [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/169805 (owner: Anomie) [21:03:04] (PS1) AndyRussG: Fix links in campaign pager on banner pages [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/169867 [21:04:42] K4-713: should I make a Mingle card for wee little niggly changes? [21:05:07] * K4-713 just got beamed on to the planet [21:05:11] Er. [21:05:12] What? [21:05:19] "make button blue" [21:05:20] Wait. Yes. [21:05:26] What are we talking about? [21:07:31] (CR) Awight: [C: 2] "Thanks!" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/169805 (owner: Anomie) [21:07:42] (Merged) jenkins-bot: Add i18n for API module help [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/169805 (owner: Anomie) [21:07:42] heheh welcome K4-713 [21:07:59] * K4-713 blinks exactly seven times [21:08:04] I was talking about this one-liner https://gerrit.wikimedia.org/r/169867 [21:08:25] Don't know about any blue buttons [21:08:27] Really [21:08:34] No blue buttons on this planet [21:08:53] Ah! [21:08:55] Yesplease. [21:09:03] okay [21:09:16] It's *so much* easier to know things about what got deployed and when, if there are cards. [21:09:40] Er. brb. [21:09:59] (CR) Awight: [C: 2] "/me cheers for wicked vim macros" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/169812 (owner: Anomie) [21:10:27] (Merged) jenkins-bot: Add i18n for API module help [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/169812 (owner: Anomie) [21:21:00] (CR) Raimond Spekking: Add i18n for API module help (1 comment) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/169812 (owner: Anomie) [21:21:57] hey AndyRussG could you throw an estimate on #2108? [21:22:16] atgo: it took me 10 minutes [21:22:22] So I set it to "0" [21:22:25] perfect [21:22:29] that... makes tons of sense [21:22:35] :) [21:22:54] :) hehe 20 extra points for making sense? [21:23:06] jk [21:23:52] yeah the Mingle dilemma I do have is what if a lot of people are working on a card [21:29:01] yeah... that is true [21:29:19] but the points should just recognize the complexity of the task, so it's not really so much about # of man-hours or anything [21:29:42] Ah hmmm OK [21:29:54] * AndyRussG goes about adjusting points [21:35:00] hehe [21:36:14] AndyRussG ejegg i'm grabbing a celebratory 6 pack for the team here for shrimping. if you'd like to join :) [21:36:14] heh, sounds good [21:41:27] atgo: nice, thank you [21:42:09] thought i'd give you a heads up so that, you know, at least you might be able to partake...? [21:42:27] I may just stick with caffeen for now tho 8p I still have a few domestic duties to perform post-shrimp :) [21:43:49] haha alrighty [21:43:58] ejegg... mind helping be troubelshoot why i can't see anything in dash? [21:44:02] really appreciate the thought and the message though ;) [21:44:35] any time i can not buy you beer, AndyRussG, i'm there ;) [21:44:42] no sweat [21:45:04] atgo: are you logged in? [21:45:14] :) [21:45:30] ahh... apparently not [21:46:07] sigh. is my username probably my email? [21:46:36] dash.frdev.wikimedia.org K4-713 [21:48:36] K4-713: why do you lose minor version numbers when you wanter? [21:48:44] *wander [21:49:44] when she's un"tie"d there is no 713 [21:50:20] heeee. [21:50:45] Now I should just be K4|unversioned [21:50:56] I would expect a metamorphosis into "K8" personally, but that's sketchy territory [21:51:04] I could have been K80. [21:52:24] Sometimes alpha K4 has less bugs than the stable release, it's not always as you'd expect [21:52:55] Maybe that's the reason for atgo's sixpack--to bring out the alpha (unstable) in everyone [21:55:13] Though if when you're wandering you're released, right? [21:55:53] :) [21:56:14] I certainly hope so. Otherwise there's an unversioned K4 in the wild. [21:56:54] heheh that's why I never plan to leave beta [22:02:52] trying to get onto hangout... [22:05:03] (CR) Anomie: Add i18n for API module help (1 comment) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/169812 (owner: Anomie) [23:10:17] I think we need to update the silverpop exporter for the emails marked bad via civicrm bounce processing [23:11:02] it marks the email itself 'on hold', while the export just looks at the contact's is_opt_out or do_not_email [23:16:17] (PS1) Ejegg: Export 'On Hold' email addresses as 'opted out' [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/169954 [23:18:26] One last step for the bounce processing - gotta update the silverpop export to treat 'On Hold' emails (status given by Civi's bounce routine for hard bounced addresses) as opted out. [23:18:33] K4-713: https://gerrit.wikimedia.org/r/169954 [23:18:35] Huh. Did I just say anything in here, or did that get swallowed? [23:18:53] K4-713: your words of wisdom didn't come through [23:19:01] Well... that's normal. [23:19:02] * awight sits upright [23:19:03] :) [23:19:05] j/k [23:19:35] zacs: Hey! Hello. I heard a rumor that you have worked out a roadmap. That accurate? [23:20:05] I have a rough one. Yep [23:20:07] ejegg: That's a very small patch. [23:20:09] ejegg: I think you have to add the on_hold field to all the... dedupe logic in that file. [23:20:36] ejegg: oh nope, I see--you do this before dedupe. excellent! [23:20:41] zacs: Cool. Can I see it? I'd like to turn it into rough milestones if that makes sense. [23:20:42] oh, cool [23:21:07] sure thing [23:21:17] (CR) Awight: [C: 2] Export 'On Hold' email addresses as 'opted out' [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/169954 (owner: Ejegg) [23:21:27] woot! [23:22:18] AndyRussG|kids: no rush, but is that bucketing fix no longer a WIP? [23:22:28] awight: correct! [23:22:34] great [23:22:51] ejegg: awight: what time are you around until? I'm still semi-here, trying to think ahead about deploy slots... are either of you up for a CN deploy? what's the plan? :) [23:23:08] AndyRussG|kids: I'll be signing off pretty soon [23:23:18] I can help deploy in the morning, but would rather not babysit a deployment tonight [23:23:30] Yeah I think tomorrow is it [23:23:52] I can do the deploy, maybe 9 PDT? [23:24:00] Shall I encalendar? [23:24:42] (PS3) AndyRussG: Temporary fix for bucket stickiness and expiry [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/169721 [23:24:58] awight: that would be fantastic! yeah I can do that :) [23:25:36] thx much [23:28:55] AndyRussG|kids: okay, we have a window 1600-1700 UTC (1200-1300 EDT) [23:29:12] I can do the dirty work, if you want to be around for testing [23:29:48] awight: sounds great, thanks a ton :) [23:29:53] hehe ok [23:29:55] I can do patch preparation [23:36:03] (PS1) Ejegg: Merge remote-tracking branch 'origin/master' into deploy [wikimedia/fundraising/tools] (deploy) - https://gerrit.wikimedia.org/r/169963 [23:36:36] (CR) Ejegg: [C: 2] "+2 for deploy" [wikimedia/fundraising/tools] (deploy) - https://gerrit.wikimedia.org/r/169963 (owner: Ejegg) [23:38:11] awight: any special considerations for tools deploy? [23:38:34] that one script update is the only thing since last deployment [23:40:05] nope! [23:40:26] rockin! [23:40:41] Guess we'll get failmail overnight if that broke the export [23:42:25] !log updated tool from 19928683a8112e9aadd71ba47f199885ba517a02 to 419fb7aa32c6d0776056968378e358ee01985565 [23:42:31] Logged the message, Master [23:44:23] ejegg: u can always kick the process off manually, if you wish [23:45:17] oh yeah, will push the button in Jenkins. Thanks! [23:45:52] ejegg: btw, rlewis already noticed and appreciates the TY activity records [23:46:15] somehow, she said she noticed that yesterday. /me doubletakes [23:47:39] oh, I turned it on to send a test yesterday [23:47:54] but it was just as a real batch sent [23:48:23] No errors logged, though! [23:49:13] (CR) Awight: [C: 2] "Nice one, subtle!" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/169721 (owner: AndyRussG) [23:50:47] errr, or maybe turning it off didn't do anything? [23:50:57] (Merged) jenkins-bot: Temporary fix for bucket stickiness and expiry [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/169721 (owner: AndyRussG) [23:51:21] Let me see what the 'false' checkbox evaluates to [23:51:54] ejegg: wat [23:52:15] I mean, I may be evaluating the setting wrong [23:52:21] ejegg: that would be quite a bug. But the good news is that people are happy if it's still on :) [23:52:42] ejegg: tri-state... stinking html checkboxes [23:52:46] heh [23:52:49] they should call them... hexboxes [23:59:54] (PS1) Ejegg: Fix on/off switch for TY adding CiviMail records [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/169967