[00:01:02] ejegg: thanks! [00:02:47] finally it looks like our deploy stuck :) [00:03:36] § Fundraising Sprint Devo, Fundraising-Backlog: BUG: Internal fraud "reject" data does not match GC's numbers; seems too high - https://phabricator.wikimedia.org/T89190#1029551 (atgo) [00:04:17] § Fundraising Sprint Devo, Fundraising-Backlog: BUG: Internal fraud "reject" data does not match GC's numbers; seems too high - https://phabricator.wikimedia.org/T89190#1029518 (atgo) [00:04:25] § Fundraising Sprint Devo, Fundraising-Backlog: BUG: Internal fraud "reject" data does not match GC's numbers; seems too high - https://phabricator.wikimedia.org/T89190#1029518 (atgo) [00:04:55] yay [00:17:43] Labs, Wikimedia-Fundraising-CiviCRM, Wikimedia-Fundraising: Create new labs project: fundraising-integration - https://phabricator.wikimedia.org/T88599#1029599 (Andrew) ok... if this is going to make use of the 'integration' project can I close this bug? [00:27:33] (CR) Ejegg: [C: -1] "Working! couple of suggestions inline, and reiterating comments from PS4" (4 comments) [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/188674 (owner: Ssmith) [00:44:27] (PS2) Ssmith: Save configuration for fraud gauge. [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/189840 (https://bugzilla.wikimedia.org/86836) [00:44:57] (CR) jenkins-bot: [V: -1] Save configuration for fraud gauge. [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/189840 (https://bugzilla.wikimedia.org/86836) (owner: Ssmith) [16:35:51] the-wub: hi! how's it going? Do remember if and if so where there were any notes from last week's language variants meeting? [16:36:39] the-wub: also, would you maybe have a second to point out to me bits of the donation pipeline that I'm not yet too familiar with? thanks in advance :) np if you're busy with something else [16:37:27] AndyRussG: I didn't take notes, and I don't recall any being sent round [16:37:40] the-wub: Ah hmm thanks [16:38:06] what bits of the pipeline are you curious about? my knowledge drops off quite early [16:39:49] Mmm thansk! well, I guess first would be maybe if you have some examples of how banners set up the first stages? I gather it's forms embedded in banners... that go to payment processors? [16:40:09] (I really should know more about this already!) [16:42:05] Oh now I remember, there's a Phabricator task... Silly me... [16:43:04] AndyRussG: the banners and donate wiki have forms in them, which pass the necessary info to https://payments.wikimedia.org/index.php/Special:GatewayFormChooser [16:43:42] that includes country, language, payment method, amount chosen, if it should be recurring, and the utm tracking info [16:44:21] oh, also the payment gateway to use [16:44:51] the-wub: got a concrete example of the code that does that? Also... is that the one that runs DonationInterface? [16:46:30] it is quite a mess due to lots of cruft built up over time, but the main part is in the redirectPayment() function in https://meta.wikimedia.org/wiki/MediaWiki:FR2013/Resources/BannerFormCore.js [16:47:03] yeah, I think GatewayFormChooser is part of DI [16:52:14] the-wub: doesn't look crufty! So I guess redirectPayment() is where the URL is built up to send us to the payment processor? That's where we'd have to add information about the language variant, no? [16:52:29] AndyRussG: correct [16:55:01] the-wub: cool, thanks! any thoughts on how to pass the variant info further down along the pipeline? through to thank-you e-mails? I see here's some doc I should really be familiar with: https://wikitech.wikimedia.org/wiki/Fundraising [16:55:58] that stuff is out of my area I'm afraid [16:56:45] can we not stuff it into the existing language field? or is that not able to cope with variants? [16:56:55] the-wub: OK, np :) heh, out of mine, mine too, until now [16:58:01] the-wub: good question. I guess we probably can! I expect how we do that would depend on how we work DonationInterface to pick it up [17:51:06] * AndyRussG waves [17:51:14] Hi AndyRussG [17:51:22] Hey! :) [17:52:06] Any idea how up-to-date this is: https://wikitech.wikimedia.org/wiki/Fundraising ? [17:52:54] mostly at least a year and a half old [17:53:01] any section in particular? [17:53:03] Ah hmmmmmmmmmmm [17:53:18] trying to grok how to send language variant info down the donation pipeline, all the way to thank-you e-mails, following a donation click on a banner? [17:53:32] ah, yes [17:53:36] s/?/./ [17:54:00] I wonder, would just sticking the language and variant in the language param sent to DonationInterface be enuf? [17:54:43] I think CiviCRM will need some work beyond that to get the ty mails out correctly [17:55:02] I don't know much beyond that [17:55:09] (CR) Awight: [C: 1] "I was close to merging, but I have enough little questions that it adds up to a yellow light :)" (11 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/189584 (owner: Ejegg) [17:55:23] thanks for the comments! [17:55:29] AndyRussG: have you peeked at my LanguageTag library? [17:55:43] awight: no! can haz links? [17:55:49] I'd really like to start handling locale data using IETF standards [17:55:56] I think it's in the card... lemme see [17:56:12] awight|meetingthing too. [17:56:13] I now I think I did see it wuns [17:56:15] once [17:56:16] AndyRussG: this is the main thing, https://github.com/adamwight/LanguageTag [17:57:07] It's got a "plugin" for converting MediaWiki language codes... [17:57:16] awight: right! Hmm... are we using that anywhere? [17:57:18] also for converting unix locale nonsense that we use in CiviCRM [17:57:20] not yet [17:57:33] Ah hmmmmmmmmmmm ;) [17:57:51] the thing is, language/variant is not quite the reality of what's happening [17:57:52] So in CiviCRM we use non-standard language codes? [17:58:01] there is also language x country x variant x script, etc [17:58:09] so we should encapsulate the complexity, IMO [17:58:21] AndyRussG: Civi uses something like unix locale, it's heinous [17:58:30] I have a patch to make it use my lib... [17:58:33] awight: Hmmm right... Indeed, well right now there's a variant selector on zhwiki [17:58:34] * K4|meetingthing frowns [17:58:46] :) [17:58:59] AndyRussG: but for now, I settled for having Civi support "null" language prefs [17:59:19] BCP-47 has a lot of nice things... multiple languages in order of preference... empty set... [17:59:59] See also http://laxstrom.name/blag/2012/08/28/language-validation-in-mediawiki/ [18:00:01] feel free not to use my lib, also, but do put me on your CC list for this project :) [18:00:06] K4|meetingthing: hope you feel better re: whatever needs chiropracty :) [18:00:16] Nemo_bis: awesome, thanks! [18:00:17] Spine needs adjustment. [18:00:35] Not my favorite malfunction ever. [18:00:41] But... [18:00:52] * K4|meetingthing shrugs, actually goes to meeting [18:00:54] K4|meetingthing: ow.... :( [18:01:29] Nemo_bis: thanks! [18:02:31] awight|disappear: it's mainly urgent for the upcoming zh campaign in a few months, I think a small but not necessarily standards-promoting patch in CN and banner JS can send the variant that the anon user has selected to DonationINterface [18:07:32] awight|disappear: also thanks! :) [18:07:43] ejegg: do you know if Special:GatewayFormChooser ever handles language variants? [18:12:56] AndyRussG: I don't think so [18:13:15] § Fundraising Sprint Devo, MediaWiki-extensions-CentralNotice: Spike: how to support language variants through entire donation process - https://phabricator.wikimedia.org/T88615#1031911 (AndyRussG) A place for rough notes: https://www.mediawiki.org/w/index.php?title=Fundraising_tech/Language_variants [18:13:31] ejegg: Hmm.... interesting [18:14:17] yeah, it's just country, currency, and method [18:14:19] I understand the user can select a variant in his or her prefs, but for CentralNotice and anons I guess you'll probably never get 'em [18:14:30] ejegg: quick pointer 2 the code that handles it? thanks! [18:14:38] the form chooser doesn't care about language at all, i think [18:15:51] getAllValidForms( $country, $currency, $paymentMethod, $paymentSubMethod, $recurring, $gateway ) [18:16:30] in DI/special/GatewayFormChooser.php [18:16:39] How does it currently get thru to civi etc? [18:17:09] DI drops a message in an activeMQ queue [18:17:28] and civi processes these to insert a contribution. [18:17:42] then another job runs to pick up recent contributions with no thank you date marked [18:17:47] and sends out letters [18:20:50] ejegg: but how does it get the language then? [18:21:05] Or rather how does it know what language to use? [18:21:17] ejegg: also https://www.mediawiki.org/w/index.php?title=Fundraising_tech/Language_variants [18:22:19] there was documentation of the message queue format someplace [18:22:57] anyway, there's a language field in the queue message [18:26:29] hmm, wmf_civicrm.module certainly has some groundwork for including variants in CRM [18:26:30] ejegg: but... how does GatewayFormChooser know which language to use? [18:27:04] GatewayFormChooser just picks out a gateway and an ffname, then redirects to that gateway page [18:27:39] the page picks up the form html based on the ffname, and calls a localization function on it to pull strings out of the i18n json files [18:28:25] right, but _which_ strings? I see uselang sent as a param from the banner... [18:28:50] Does the same param get sent along on the redirect? [18:28:54] sorry, I gotta do scrum of scrums in a minute... [18:28:59] ejegg: np, thanks! [18:29:05] yeah, the param should get passed along [18:29:20] ah hmm OK! :) [18:59:57] AndyRussG: I agree with a small patch, but it's going to be a lot better in the long run if we can send a single language tag whenever possible, rather than kludging a "variant"-- for example, pt-BR vs zh-big5 are actually different axes of variance. I don't want to proliferate "variant" fields in our message format and db schemas, if these are going to be deprecated. [19:03:35] AndyRussG: there's a thing called the IETF language tag (BCP 47) that tracks both locale stuff and script tags [19:03:57] ejegg: that is covered by my LanguageTag lib, fwiw... [19:05:37] i forget, does zh wiki's variant switcher deal with scripts or just locales? [19:07:04] nvm, found the slides from https://phabricator.wikimedia.org/T87652 [19:14:47] Nemo_bis: thanks for the link! Do you know if MediaWiki produces actual IETF language tags at this point? [19:16:54] AndyRussG: wfBCP47() ! looks like MediaWiki might already support the thing I was describing... [19:19:17] awight: ejegg: thanks! tl;dr from the meeting is, low priority or maybe don't even do anything, depending [19:19:36] I'll add the above to the notes page tho! [19:21:59] yurp [19:22:00] argh [19:22:09] soooooooooooooorrrrrrrrrrrrrry [19:22:11] we somehow steer around that iceberg every time [19:26:28] awight: MediaWiki doesn't produce language tags by itself, but tries to emit ISO 630 codes [19:26:36] 639 [19:27:05] Usually the minimum validation is against BCP 47 but we're getting stricter over time [19:27:57] Nemo_bis: which ISO 639? [19:28:08] For example, I thought we did "pt-BR" [19:28:21] 639-3 except when 639-1 is available [19:28:33] Well, we call it "pt-br" [19:28:58] right. that would be 'por' in 639-3 [19:29:27] "por" is just "pt" [19:29:35] oh... [19:30:02] so that loses the variant info [19:30:33] Anyway, it sounds like MediaWiki already has the thing which really matters for us--that the user's script (??) and variant are encoded into the language tag. [19:30:46] and that the tag satisfies BCP-47 [19:31:29] Yes [19:31:53] But we don't cover all sublocales, so we can only say whether a code is syntactically valid, not whether it makes sense [19:32:21] Hence Nikerabbit's example "stuff like fi-Cyrl-JA-x-foo that semantically makes no sense but is valid according to the rules" [19:32:33] Is Serbian Cyrillic/Latin transliteration preference encoded in the language tag? [19:33:04] Serbian is a sad example [19:33:08] hehe [19:33:15] fair enough [19:34:02] we call it sr-Cyrl vs. sr-Latn https://translatewiki.net/wiki/Portal:Sr [19:34:25] ah, that's actually legit BCP-47 though [19:34:39] but in this case we also have an actual "language code" for each, i.e. sr-ec vs. sr-el [19:34:44] blargh. [19:35:20] I don't think a general IETF language tag parser would recognize those as the same. [19:35:29] A simpler example is https://translatewiki.net/wiki/Portal:Uz [19:35:38] Nemo_bis: the set of variants that we've been talking about tentativley for FR and CentralNotice are the Chinese ones [19:35:52] There's the language selector in use on zh wiki [19:36:40] Ah. [19:36:59] zh-Hans is a real IETF thing, happily [19:40:49] § Fundraising Sprint Devo: Add contribution tracking ID to credit card statement on Worldpay - https://phabricator.wikimedia.org/T88060#1032199 (atgo) @ccogdill_wmf have you heard anything about this working yet? I'd love to close this [19:41:43] § Fundraising Sprint Devo: Add contribution tracking ID to credit card statement on Worldpay - https://phabricator.wikimedia.org/T88060#1032200 (CCogdill_WMF) I haven't @atgo, and it's supposed to work inconsistently so I'm not sure it's worth trying to track more people down to test. I'm fine to close it. [19:42:06] § Fundraising Sprint Devo: Add contribution tracking ID to credit card statement on Worldpay - https://phabricator.wikimedia.org/T88060#1032201 (atgo) Open>Resolved a:atgo [19:42:45] § Fundraising Sprint Devo: Add contribution tracking ID to credit card statement on Worldpay - https://phabricator.wikimedia.org/T88060#1032204 (atgo) Done. Thank you! [19:48:30] (CR) Ejegg: "Thanks for the comments! I think a stack of sparse arrays would work to avoid duplicate settings lookups and copies of values. Just tryi" (7 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/189584 (owner: Ejegg) [19:55:32] (CR) Awight: Move some logging functions into DonationLogger (3 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/189584 (owner: Ejegg) [19:56:18] § Fundraising Sprint Devo, Wikimedia-Fundraising, MediaWiki-extensions-DonationInterface: Tech Review of LATAM processor - https://phabricator.wikimedia.org/T87046#1032306 (atgo) a:atgo>awight [19:56:21] § Fundraising Sprint Devo, Fundraising-Backlog: BUG: Internal fraud "reject" data does not match GC's numbers; seems too high - https://phabricator.wikimedia.org/T89190#1032308 (atgo) a:atgo>None [20:15:01] pizzzacat: Are you fooding today? [20:15:18] K4-713: I have given up food for lent [20:15:27] You are better than me. :p [20:15:29] no actually yes I am fooding [20:15:33] one sec [20:15:38] cool [20:16:03] § Fundraising Sprint Devo, MediaWiki-extensions-CentralNotice: Spike: how to support language variants through entire donation process - https://phabricator.wikimedia.org/T88615#1032373 (atgo) @andyrussg do you think we can close this? [20:19:35] (CR) Ejegg: Move some logging functions into DonationLogger (2 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/189584 (owner: Ejegg) [20:28:28] (CR) Awight: Move some logging functions into DonationLogger (2 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/189584 (owner: Ejegg) [20:33:40] § Fundraising Sprint Devo, Wikimedia-Fundraising-CiviCRM: BUG: Gateway Reconciliation Report not pulling all donations - https://phabricator.wikimedia.org/T89288#1032458 (atgo) p:Triage>Unbreak! [20:33:48] § Fundraising Sprint Devo, Wikimedia-Fundraising-CiviCRM: BUG: Gateway Reconciliation Report not pulling all donations - https://phabricator.wikimedia.org/T89288#1032444 (atgo) a:atgo>None [20:34:29] § Fundraising Sprint Devo, § Fundraising Tech Backlog: Logging should be handled outside of core gateway class - https://phabricator.wikimedia.org/T86266#1032466 (atgo) a:Ejegg [20:34:42] § Fundraising Sprint Devo, Wikimedia-Fundraising-CiviCRM: BUG: Gateway Reconciliation Report not pulling all donations - https://phabricator.wikimedia.org/T89288#1032444 (atgo) [20:35:37] § Fundraising Sprint Devo, § Fundraising Dash: BUG: Fraud widget numbers don't seem right - https://phabricator.wikimedia.org/T87810#1032469 (atgo) [20:53:24] § Fundraising Sprint Devo, MediaWiki-extensions-CentralNotice: Spike: how to support language variants through entire donation process - https://phabricator.wikimedia.org/T88615#1032529 (AndyRussG) @atgo: Sounds good! (I'll link to the notes in the [[ https://phabricator.wikimedia.org/T55641 | general task ]]... [20:54:37] § Fundraising Sprint Devo, MediaWiki-extensions-CentralNotice: Spike: how to support language variants through entire donation process - https://phabricator.wikimedia.org/T88615#1032531 (atgo) Open>Resolved [21:05:35] MediaWiki-extensions-CentralNotice, Wikimedia-Fundraising: Special:RecordImpression should die in a fire - https://phabricator.wikimedia.org/T45250#1032545 (AndyRussG) Some thoughts on organizing code for the above approach: - Add a global impression-logging facility to CN, which could be turned off or set to... [21:09:37] ejegg: awight: should we start making version tags or branches in CentralNotice, as in "1.25wmf16"? I noticed this morning that it's hard to tell exactly the history of a branch head in its forking and sporking patch history... Or maybe I'm missing something... [21:10:03] I guess one could always refer to core submodule versions for that... [21:10:15] But it might be nicer to see it directly in the CN repo history [21:12:48] AndyRussG: interesting! I think by managing the release branch ourselves, we've opted out of the automated system that does just what you're describing (see EducationProgram for example) [21:13:05] Maybe... we should consider using the ordinary release management tools? [21:13:09] Is it an automated system? [21:13:11] yah [21:13:17] well, semi-automated :) [21:13:28] Coin-operated? [21:13:48] https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/tools/release [21:13:49] * AndyRussG shames self [21:14:30] awight: ah hmmm [21:14:55] Maybe I should ask one ops what the recommended best practice these days would be [21:15:21] I'd love to hear the official story! [21:15:40] K I'll ping when I inquire :) [21:16:01] On second thought, I think it's some sketchy, like they branch master at each release [21:16:31] We sort of want to keep our deployment branch, but maybe we want to enable the branching thing off of that? [21:21:07] Yeah, or at least having a visible record in the history of which commits were used for the last deploy [21:21:19] or rather previous deploys in general [21:25:37] So when we do a deploy across multiple wmf branches, we just point all of those tags to the same thing? [21:25:52] Or would we commit to writing all future patches for staged deploy? [21:27:06] ejegg: ah hahah good point [21:27:24] Though we could easily just put two tags on the same commit [21:27:46] uuuh which is what you just said [21:27:57] I guess the release branching tool actually doesn't do what we want--it determines which extension version is deployed for each release, but it doesn't update the branches for lightning deploys. [21:28:56] I'd just like to have a better history of what was out there, when. Lookin at the history below wmf_deploy I couldn't see which easily which tracks _had_ been master and which had been deploy [21:29:42] True that! Sadly, https://wikitech.wikimedia.org/wiki/Server_Admin_Log doesn't include SHA-1s [21:31:17] It actually seems like a defect of git! I mean, it records previous states of the repo WRT files, but not WRT where heads have travelled [21:31:57] BTW the good news is the CN update is out to all Wikipedias and no catastrophe [21:32:01] yet [21:32:10] .. [21:32:11] .... [21:32:11] ... [21:32:15] O_o [21:32:19] * awight knocks on plywood [21:32:33] Still none! https://en.wikipedia.org/wiki/Main_Page?country=IL [21:34:11] AndyRussG: I think you're right about just looking at mediawiki-core history and examining submodule bumps... [21:34:27] plywood, the processed cheese of lumber! http://en.wikipedia.org/wiki/Engineered_wood [21:34:39] maybe there's a tool to autoextract that [21:34:43] We can assume that the wmf release branches are very close to sync'ed with what's actually deployed. [21:34:53] that would be a nice side project, if it doesn't exist [21:35:02] hehe, so particle board is the margarine of lumber? [21:35:28] >_> [21:36:04] * awight grabs popcorn and watches wikimedia-operations [21:36:24] if there is a tool, we should improve it to spit out submodule versions... [21:36:44] yeah [21:37:51] AndyRussG: btw, mediawiki-tools-release/git-logs [21:42:56] awight: thx! [21:43:38] hopefully there's something better than that, though! [21:50:46] (CR) Ssmith: Library and Profile styles and flow (4 comments) [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/188674 (owner: Ssmith) [21:51:20] (PS8) Ssmith: Library and Profile styles and flow [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/188674 [22:20:05] § Fundraising Sprint Devo, § Fundraising Dash: Finish refactoring of each already existing widget - https://phabricator.wikimedia.org/T89298#1032813 (pizzzacat) NEW a:pizzzacat [22:20:23] § Fundraising Sprint Devo, § Fundraising Dash: Finish refactoring of each already existing widget - https://phabricator.wikimedia.org/T89298#1032820 (pizzzacat) [22:20:36] Damn. [22:20:47] The JD failed to write itself while I was in meetings. [22:21:43] I hate it when that happens [22:21:53] It seems to happen pretty much constantly. [22:22:43] I should probably stop hoping. [22:32:28] (PS6) Ejegg: Move some logging functions into DonationLogger [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/189584 [22:34:14] (PS5) Awight: WIP doPayment() [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/189153 [22:34:25] (PS7) Awight: Move some logging functions into DonationLogger [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/189584 (owner: Ejegg) [22:40:02] ~ * ~ @ ~ D o r i t o s ~ @ ~ * ~ [22:40:08] <_< [22:40:27] this is how I enjoy things [22:40:29] glutamate receptors ftfw! [22:40:32] I hope you got some cash for that. [22:40:40] Or more doritos. [22:40:45] whaat? [22:40:54] Celebrity endorsement. :p [22:41:12] ohhh I was like "wait are they charging for snacks now!?!" [22:41:21] I'd be hella in the hole [22:41:23] btw, this is real: http://mentalfloss.com/sites/default/files/styles/article_640x430/public/cool-american-doritos_5.jpg [22:41:47] damn [22:42:23] I... have no experience with that flavor. [22:42:39] you can't taste a flavor that you are [22:42:46] Huh. [22:42:48] according to Sideways Stories from Wayside School [22:42:56] It's BBQ, isn't it? [22:42:59] >_> [22:43:01] <_< [22:43:07] oh nooooes [22:43:25] mine is nacho disappointment [22:43:45] awww [22:44:28] (CR) Awight: [C: 2] "Elegant!" (2 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/189584 (owner: Ejegg) [22:44:58] (Merged) jenkins-bot: Move some logging functions into DonationLogger [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/189584 (owner: Ejegg) [22:45:02] (CR) Awight: Move some logging functions into DonationLogger (1 comment) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/189584 (owner: Ejegg) [22:46:47] Is "grape flavored nerds" an option? [22:47:12] I stopped eating those. Was tired of being accused of cannibalism. [22:47:34] um... what's purple and commutes? [22:47:40] a grape abelian. [22:48:11] http://ep.yimg.com/ay/candy-crate/nerds-strawberry-grape-1.gif [22:49:27] aww geez. an Abelian grape. it's only hilarious in that order. [22:50:31] I may have just googled for "Grimace on a bus". [22:52:42] I hate to say it, but the internet doesn't have one. [22:53:14] whaaat [22:53:21] we need to fix that [22:53:36] That's why I hesitated to mention it. [22:53:59] I just googled "kid smiling weirdly on a bus" [22:54:08] I bet there are a ton of those. [22:54:14] very disappointing actually [22:55:32] I guess its like shrimp chicken time [22:56:03] Oh right. Which also means it's time for me to leave. [23:01:05] (PS7) AndyRussG: WIP: Test fixtures: expand to cover more scenarios [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/188687 [23:01:49] (CR) jenkins-bot: [V: -1] WIP: Test fixtures: expand to cover more scenarios [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/188687 (owner: AndyRussG) [23:03:08] awight meeting? [23:03:15] we miss u awight [23:03:40] Wut u don't miss me :( [23:03:43] ? [23:04:04] ummm yes [23:04:09] yess I miss you [23:04:09] I miss you [23:04:29] I miss u kaldari where are you? [23:04:35] I miss Matt [23:04:45] aww [23:05:34] I’m in the office. Any bad movies this week? [23:05:47] not this week - last Thurs. of the month! [23:05:55] It's gonna be Samurai Cop [23:06:01] be there or be lame [23:06:30] nice. One day we need to show Hackers and force K4 to attend [23:06:57] ;) [23:07:43] she's coming to Samurai Cop [23:08:29] I’ll come to Samurai Cop if you’ll come sailing [23:10:51] I need your pirate flag! [23:17:05] Wikimedia-Fundraising, § Fundraising Sprint E, Wikimedia-Fundraising-CiviCRM: Ressurect phpunit tests for the CRM modules - https://phabricator.wikimedia.org/T86686#1032963 (atgo) [23:17:27] Release-Engineering, § Fundraising Tech Backlog, § Fundraising Sprint E, Continuous-Integration, Wikimedia-Fundraising-CiviCRM: Deploy CiviCRM integration job to WMF integration server - https://phabricator.wikimedia.org/T86374#1032964 (atgo) [23:23:01] MediaWiki-extensions-CentralNotice, § Fundraising Tech Backlog: Do banner hiding with mixins - https://phabricator.wikimedia.org/T86100#1032969 (atgo) [23:26:42] § Fundraising Sprint Devo, MediaWiki-extensions-CentralNotice: Remove banner variance params: take 2 - https://phabricator.wikimedia.org/T88626#1032991 (atgo) Open>Resolved a:atgo [23:51:29] § Fundraising Sprint Devo, Fundraising-Backlog: BUG: Internal fraud "reject" data does not match GC's numbers; seems too high - https://phabricator.wikimedia.org/T89190#1033006 (Ejegg) a:Ejegg [23:52:15] § Fundraising Sprint Devo, § Fundraising Dash: BUG: Fraud widget numbers don't seem right - https://phabricator.wikimedia.org/T87810#1033007 (Ejegg) a:Ejegg