[06:54:58] <wikibugs>	 fundraising-tech-ops: encrypt fundraising mariadb replication - https://phabricator.wikimedia.org/T170320 (jcrespo) We create our own mariadb and mysql packages for production- several of they can be installed at the same time, and they don't try to be "smart" about the data on boot. On the contrary, they ta...
[06:58:01] <wikibugs>	 fundraising-tech-ops: encrypt fundraising mariadb replication - https://phabricator.wikimedia.org/T170320 (jcrespo) On topic, we have been using TLS based replication for mariadb for almost over 2 years: https://phabricator.wikimedia.org/T111654#3010354
[15:09:48] <wikibugs>	 Fundraising-Backlog, MediaWiki-extensions-DonationInterface: Donation with no currency and zero amount sent payments_fraud message - https://phabricator.wikimedia.org/T200205 (Ejegg)
[15:57:47] <AndyRussG>	 Hi all! Back in a sec, fixing some IRC stuff...
[16:02:12] <wikibugs>	 (PS1) Ejegg: Revert "Localisation updates from https://translatewiki.net." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/447461
[16:32:29] <wikibugs>	 Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: restore Merge option to Actions dropdown for Search results - https://phabricator.wikimedia.org/T199929 (MBeat33) Open>Resolved a:MBeat33 This option is available now in the dropdown from the previous screenshot, and I used it on CID 4698213...
[16:44:29] <wikibugs>	 Fundraising Sprint Naming Sprints Is Not Important, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi: contribs export failing for DS agent - https://phabricator.wikimedia.org/T196569 (MBeat33) a:MBeat33>None
[16:46:57] <wikibugs>	 (CR) Ejegg: [C: 2] Revert "Localisation updates from https://translatewiki.net." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/447461 (owner: Ejegg)
[16:54:31] <wikibugs>	 (Merged) jenkins-bot: Revert "Localisation updates from https://translatewiki.net." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/447461 (owner: Ejegg)
[17:08:21] <wikibugs>	 Fundraising Sprint Matt Damon to head up Space Force, Fundraising Sprint Naming Sprints Is Not Important, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: BitPay import error - https://phabricator.wikimedia.org/T198669 (Ejegg) Open>Resolved
[17:09:05] <wikibugs>	 Fundraising Sprint Naming Sprints Is Not Important, Fundraising-Backlog, MediaWiki-extensions-ContributionTracking, MW-1.32-release-notes (WMF-deploy-2018-07-17 (1.32.0-wmf.13)), Patch-For-Review: [ContributionTracking] default DB settings differs when ... - https://phabricator.wikimedia.org/T195814
[17:09:19] <wikibugs>	 Fundraising Sprint Karma chameleons hide amongst us, Fundraising Sprint Lactose is unusually tolerant, Fundraising Sprint Matt Damon to head up Space Force, Fundraising Sprint Naming Sprints Is Not Important, and 3 others: Ingenico recurring messages missin... - https://phabricator.wikimedia.org/T195488
[17:09:46] <wikibugs>	 Fundraising Sprint Matt Damon to head up Space Force, Fundraising Sprint Naming Sprints Is Not Important, Fundraising-Backlog, Core-Platform-Team, and 4 others: [Bug] CentralNotice: "Failed to load data blob" error when editing translatable messages - https://phabricator.wikimedia.org/T198869 (Eje...
[17:09:48] <wikibugs>	 Fundraising Sprint Naming Sprints Is Not Important, Fundraising-Backlog, FR-Smashpig, Patch-For-Review, Unplanned-Sprint-Work: payments-antifraud messages with wrong date format - https://phabricator.wikimedia.org/T199468 (Ejegg) Open>Resolved
[17:10:01] <wikibugs>	 Fundraising Sprint Naming Sprints Is Not Important, Fundraising-Backlog, Patch-For-Review: Investigate why Ingenico donation did not recur on 6/14 - https://phabricator.wikimedia.org/T199331 (Ejegg) Open>Resolved
[17:29:21] <XenoRyet>	 !log updated payments-wiki from 63372154d0 to d8d8293b87
[17:29:23] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log
[17:35:31] <wikibugs>	 (PS1) Ejegg: Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/447477
[17:35:50] <wikibugs>	 (CR) Ejegg: [C: 2] Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/447477 (owner: Ejegg)
[17:38:07] <wikibugs>	 (PS1) Ejegg: Update DonationInterface submodule [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/447478
[17:38:13] <wikibugs>	 (CR) Ejegg: [C: 2] Update DonationInterface submodule [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/447478 (owner: Ejegg)
[17:45:25] <wikibugs>	 (Merged) jenkins-bot: Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/447477 (owner: Ejegg)
[17:45:30] <wikibugs>	 (Merged) jenkins-bot: Update DonationInterface submodule [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/447478 (owner: Ejegg)
[17:45:49] <wikibugs>	 Fundraising-Backlog: Add explainer text to CC payment form (for banner checkbox experience) - https://phabricator.wikimedia.org/T200218 (CCogdill_WMF)
[17:49:28] <wikibugs>	 Fundraising-Backlog: Add explainer text to CC payment form (for banner checkbox experience) - https://phabricator.wikimedia.org/T200218 (CCogdill_WMF) p:Triage>High
[17:53:26] <ejegg>	 !log updated payments-wiki from d8d8293b87 to 6390e50abd
[17:53:29] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log
[18:09:34] <saurabhbatra>	 anybody know what contribution_status_id=1 stands for?
[18:10:26] <ejegg>	 saurabhbatra: that's a successful contribution
[18:10:35] <ejegg>	 that hasn't been refunded or charged back
[18:11:17] <saurabhbatra>	 cool, thanks! :-)
[18:54:19] <wikibugs>	 (CR) Ejegg: [C: -1] "Needs rework - UI now needs to be a yes / no radio button pair instead of a checkbox" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/445327 (https://phabricator.wikimedia.org/T199278) (owner: Ejegg)
[18:58:02] <awight>	 saurabhbatra: You can get a list of contribution status code mappings through the option_group and option_value tables
[18:58:47] <awight>	 I don’t have an exact query on hand, but basically you say option_group.name=“contribution_status”, and join on option_value.group_id = option_group.id
[19:01:28] <jgleeson|away>	 ejegg, with you on the radio buttons
[19:03:39] <jgleeson>	 ejegg, not sure what's going on with the paypal test failures in your patch
[19:04:42] <jgleeson>	 ah, ignore me. I got mixed up
[19:04:53] <jgleeson>	 I confused your -1
[19:05:04] <awight>	 cwd: Are there any payments logs available on frdev?
[19:08:14] <saurabhbatra>	 awight: did you get the chance to go through the documents MBeat sent over?
[19:08:24] <awight>	 no!  looking now
[19:08:37] <awight>	 “transaction metrics"?
[19:08:59] <saurabhbatra>	 yup
[19:09:29] <awight>	 Seems we should target both refunds and chargebacks?
[19:09:46] <awight>	 They’re mostly the same class of stuff, the only difference is how quickly our agents can refund
[19:10:17] <saurabhbatra>	 yes!
[19:10:28] <awight>	 It would be nice if we had more information like donor-initiated vs. gateway-initiated
[19:11:30] <awight>	 MBeat: I’m looking at “chargebacks and metrics”, and wondering how you’re made aware of the need for a refund
[19:14:00] <MBeat>	 hi awight chargebacks reach us as: 1. transactions from periodic d/ls from Ingenico (like every week an agent exports everything at status 1500) 2. alerts from third party Ethoca 3. alerts (requests for information) from Igenico
[19:15:00] <awight>	 So when you get (2) & (3) alerts, your team just refunds right away?
[19:15:29] <awight>	 My interest FWIW is in finding whether there are distinct classes of issue that we should look for separately
[19:15:46] <awight>	 e.g. stolen CCs vs. spurious midnight donations
[19:16:45] <saurabhbatra>	 adam: in chargebacks and metrics, have a look at the "GC Monthly Transactions" worksheet
[19:18:14] <awight>	 MBeat: My very naive understanding so far is, when we receive a status 1500 or something, our system should just immediately refund.  Or is there a human step?
[19:19:13] <awight>	 What’s the group of potential chargebacks which is most difficult to deal with, such that having AI assistance to identify the most likely problematic ones might save your team time or money?
[19:20:20] <saurabhbatra>	 awight I'm guessing it involves a human step
[19:20:52] <MBeat>	 awight, for cases 2 & 3, we very often have already proactively refunded them as obvious fraud (I can send you & Saurabh the Master Refunds doc if that would be helpful). If we haven’t yet, then we immediately issue refunds. AI assistance would be most helpful in picking out the fraudsters who take the time to submit plausible name/email adresses
[19:21:11] <MBeat>	 the edge cases are the ones we spend time digging into, looking at IP activity etc
[19:21:30] <awight>	 We need to identify a group of these for training, then :)
[19:22:13] <awight>	 It’ll make a huge difference to the project to know whether these have the “donor” contact info available in Civi, BTW
[19:23:15] <awight>	 & it will be invaluable to boil down some of your experience around exactly what you look at when investigating
[19:24:07] <awight>	 e.g., what is “IP activity”?  Is this a history you look up in Civi, or in a PSP portal?
[19:25:41] <saurabhbatra>	 looking at "600s proactively settled" - i think it's majorly checking up previous contributions by the same person
[19:26:06] <awight>	 awesome, that happens to be easy to pull from Civi :-)
[19:26:10] <saurabhbatra>	 "plausible details" also makes an appearance
[19:26:28] <saurabhbatra>	 i think it might/might not be
[19:26:48] <saurabhbatra>	 for example there are mentions of "previous contrib (initials only)
[19:26:53] <awight>	 Is there a draft list of possible features somewhere?
[19:30:07] <awight>	 Sorry I’m just delinquent on email and it’s probably all there
[19:30:50] <MBeat>	 >  "previous contrib (initials only) is a prior donor who used just their initials for their name, and got snagged by one of our filters. IP activity we look up in vivafredge, to find the donation source, but also whether there’s other activity from that IP. And if there is, we look at whether it’s varied & legit, OR a cluster of exactly the same amount/currency/donation source
[19:32:00] <MBeat>	 https://collab.wikimedia.org/w/index.php?title=Fundraising/Donor_Services_Documentation/Fraud_Procedures
[19:32:32] <MBeat>	 > Factors Indicating Fraud
[19:37:19] <saurabhbatra>	 MBeat: looking at master refunds now, quick question - do these transactions make their way into civi as well?
[19:37:29] <MBeat>	 yes
[19:37:55] <saurabhbatra>	 and how are they marked>
[19:37:57] <saurabhbatra>	 *?
[19:38:26] <saurabhbatra>	 i see some fields are marked with cancel_reason='fraudulent donation' in civicrm_contribution
[19:38:32] <MBeat>	 usu. in a day or two, sometimes slower for other processors. They should read Contibution Status: canceled or :refunded, saurabhbatra
[19:38:48] <MBeat>	 yes, those are the ones that we catch quickly, at status 800
[19:39:17] <MBeat>	 we have to manually cancel then in Civi. Anything refunded at a higher status at Ingenico will come to Civi in the audit file
[19:39:37] <saurabhbatra>	 and these are the transactions we wish to catch using AI if I'm correct?
[19:39:47] <saurabhbatra>	 wrt the project
[19:41:05] <saurabhbatra>	 awight: did you catch my pms or did you timeout before?
[19:41:27] <MBeat>	 anything marked as a proactive refund in Master Refunds would be great to catch, as well as most charged-back ones that profile as fraud. There are some chargbacks that are referred to as “first party” fraud, where it’s more like a miscouunication between spouses (or some human error) that causes the chargeback request
[19:41:35] * awight backscrolls
[19:42:47] <saurabhbatra>	 i think that answers a lot of questions
[19:43:14] <saurabhbatra>	 i'll try running a few more queries, we might just be able to get the data we need :-)
[19:43:38] <MBeat>	 cool! let me know if you want to do a hangout to see the process or anything
[19:44:23] <saurabhbatra>	 that does sound tempting, i'll ping/mail you if it's needed!
[19:44:29] <saurabhbatra>	 thanks a bunch! :-)
[19:49:18] <MBeat>	 np!
[19:49:53] <awight>	 That’s wonderful news, that Civi records exist for our target class.
[19:50:28] <awight>	 I’d say we should drop miscommunications as a source of unavoidable noise.  Is there a way to review our training set for these?
[19:51:04] <awight>	 by unavoidable, I mean that our algorithm won’t be able to improve existing relationships between family members
[19:53:57] <saurabhbatra>	 i think we don't need to worry about that
[19:54:34] <awight>	 The data would be higher quality without it, though
[19:55:43] <saurabhbatra>	 that does make sense
[19:56:44] <awight>	 I think MBeat is right that our initial target class should be, “subset of fraud that results in chargebacks.”  I’d like to catch fraud regardless of stage, but the ones captured only in the payments logs or upstream PSP logs will probably have very different features available, seems like they should be distinct classes, and can be added incrementally as we go forward.
[19:57:19] <awight>	 Not that anyone was arguing differently, but just to try to define the scope of the sampling queries
[19:57:58] <saurabhbatra>	 +1 to that ^^
[20:03:45] <awight>	 MBeat: jfyi, my collabwiki access is not working at the moment.
[20:03:53] <awight>	 Asking for a 2FA on a long-burned fone
[20:04:16] <MBeat>	 ah, I’ll send you screenshot awight
[20:06:25] <awight>	 :-)
[20:08:24] <awight>	 MBeat: sprung myself into collabwiki, just in time!
[20:09:24] <awight>	 MBeat: What do you think about status “Cancelled”?  Are these more like spousal disagreement donations, or should we include as more like fraud?
[20:10:05] <MBeat>	 most by far of the Canceled’s in Civi are going to be real fraud we got to quickly, awight
[20:10:16] <awight>	 ooh excellent, thanks
[20:10:20] <awight>	 saurabhbatra: ^
[20:10:35] <saurabhbatra>	 yup, i'm stalking
[20:10:39] <saurabhbatra>	 i had an idea though
[20:10:39] <MBeat>	 something like 98%
[20:11:03] <awight>	 saurabhbatra: chargebacks, cancelled, and refunds then?
[20:11:37] <awight>	 oh + pending refunds
[20:12:15] <saurabhbatra>	 looks like most borderline cases are handled by a human going through previous transactions associated with the credit card/contact
[20:12:31] <saurabhbatra>	 performing look-ups by name/id
[20:12:53] <awight>	 diff(amount_now, amounts_then)?
[20:13:23] <awight>	 maybe the feature is a vector of diffs over all other_amounts
[20:13:57] <saurabhbatra>	 not sure
[20:14:10] <awight>	 MBeat question perhaps
[20:14:30] <saurabhbatra>	 also not sure whether we understood each other :-)
[20:14:32] <awight>	 Whether this donation matches last_donation_amount is probably most important, then come any patterns picked up by eye
[20:14:53] <saurabhbatra>	 oh i think i get you now :-)
[20:15:06] <awight>	 what other feature, I wonder
[20:15:10] <awight>	 *feature
[20:15:12] <awight>	 argh
[20:15:15] <awight>	 “s”
[20:16:35] <awight>	 Maybe this is a neural net problem, to find correlations between past donations?  This is not actually my forte :-)
[20:17:01] <saurabhbatra>	 i was just thinking about simple stuff like does this credit card/contact have a successful previous donation
[20:17:19] <saurabhbatra>	 simple rule-based stuff
[20:18:06] <saurabhbatra>	 probably this might help us root out border-line cases
[20:18:14] <saurabhbatra>	 increase precision + recall
[20:18:56] <saurabhbatra>	 and have this as a module post the random forest
[20:19:22] <saurabhbatra>	 anything at the edge of the threshold goes through this grinder
[20:21:13] <saurabhbatra>	 but I feel like we're getting side-tracked, chargebacks, cancelled, refunds and pending refunds it is!
[20:21:16] * awight facepalms.  Sorry everyone, I finally got into collabwiki and it’s a much more detailed explanation of where I’m slowly catching up to.  Thanks!
[20:25:59] <wikibugs>	 Fundraising-Backlog: publish Oanda exchange rates to internal, private google doc - https://phabricator.wikimedia.org/T200227 (DStrine)
[20:34:50] <wikibugs>	 (PS1) Raimond Spekking: Revert "Localisation updates from https://translatewiki.net." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/447550
[20:46:58] <K4-713>	 awight: "our algorithm won’t be able to improve existing relationships between family members". I have missed working with you. :p
[20:47:23] <awight>	 I feel so seen <3
[20:47:31] <K4-713>	 hahaha
[20:48:10] <awight>	 Luckily, domestic antics don’t usually cost us at the gateway (AFAIK), so we don’t have build them into the model
[20:48:21] <awight>	 Although at the same time, it would be hilarious to do so
[20:48:54] <K4-713>	 I probably shouldn't be thinking of ways we could check for that...
[20:49:13] <K4-713>	 ...you know: Before the refund email.
[20:49:26] <awight>	 Flicker some implicit bias images…
[20:49:57] <awight>	 Please rate your domestic situation on the scale below
[20:50:28] <awight>	 IS your ignorant spouse a jerk when you talk about books?  Try editing WP!
[20:51:58] <AndyRussG>	 awight: lol :)
[20:53:57] <K4-713>	 Using Banner History, we subtly sort people into user segments that have 1) spouces 2) that control the finances, and 3) hate free knowledge.
[20:54:57] <K4-713>	 I have no idea what kind of messaging would do that. Presumably messaging that would cause single people with financial independence and a love of free knowledge to donate?
[20:54:59] <awight>	 It would be funny to train on the coinbase contact fields which somehow are still not optional, so that we can show a dialog “It seems you have chosen to berate a donation to us, please know that we respect your privacy read here”
[20:55:48] <K4-713>	 haha
[20:55:49] <awight>	 lol, has banner history really crystallized into the philosopher’s stone of non-profit sales?
[20:56:22] <saurabhbatra>	 awight: another good news, not only are the google sheet transactions present in the database, the refunds with reasons like "donor request (wrong charity)" are marked as status id 1
[20:56:22] <K4-713>	 Nope! But who knows what we'll discover if we're clever.
[20:58:28] <awight>	 saurabhbatra: oh that is rad.  MBeat, awesome work!
[21:00:06] <saurabhbatra>	 i am seeing some fraudulent donations marked as status 1
[21:01:08] <saurabhbatra>	 but most of them are marked as 3 or 9
[21:02:40] <saurabhbatra>	 alright, so the newer donations might not have had their statuses corrected yet
[21:03:02] <saurabhbatra>	 won't be a problem for us
[21:03:18] <awight>	 Good catch
[21:03:28] <awight>	 Maybe bracket at now-1 month?
[21:04:19] <saurabhbatra>	 everyything before the 17-18th of this month is correct i think
[21:04:36] <saurabhbatra>	 but we have ~16k rows so we can be a bit generous with our filters
[21:04:50] <awight>	 nice
[21:05:39] <saurabhbatra>	 alright great, i feel like we've tackled a huge roadblock today :-)
[21:06:16] <saurabhbatra>	 next up - extracting information from IP addresses
[21:06:23] <awight>	 Yeah awesome work!
[21:06:31] <awight>	 Is IP address available in Civi?
[21:06:35] <saurabhbatra>	 yup
[21:06:39] <awight>	 kk
[21:06:49] <saurabhbatra>	 so i had a talk with ejegg
[21:07:28] <saurabhbatra>	 what happens in an actual transaction is - IP address info is polled from a GeoIP Varnish instance
[21:07:37] <saurabhbatra>	 stored in session and passed on to minFraud
[21:07:45] <awight>	 Sounds famiiar
[21:07:52] <awight>	 familiar*
[21:08:55] <saurabhbatra>	 shifted to pm for some reason
[21:09:04] <saurabhbatra>	 *curses irc and irc clients*
[21:09:42] <saurabhbatra>	 luckily there is a Debian implementation for GeoIP
[21:10:18] <saurabhbatra>	 so I can probably write a python script which polls it and updates our csv records
[21:12:06] <saurabhbatra>	 only problem being, I don't have sudo on frdev
[21:13:16] <awight>	 What is the GeoIP for, again?
[21:13:26] <awight>	 To compare with their billing address?
[21:14:09] <saurabhbatra>	 good question
[21:14:35] <saurabhbatra>	 atm it's just about extracting more information out of the IP address field
[21:14:54] <saurabhbatra>	 and let the random forest figure out patterns
[21:15:49] <awight>	 How relevant are the expanded IP infos, though?
[21:15:57] <saurabhbatra>	 i think, very
[21:16:37] <awight>	 I wouldn’t want to make a classifier which is biased against donations from any specific countries, if we can avoid that
[21:16:59] <saurabhbatra>	 it's not just countries though
[21:17:13] <saurabhbatra>	 particular zip codes within a country for ex
[21:17:35] <saurabhbatra>	 lat-long info
[21:17:36] <awight>	 I thought the IP work was more for finding a history of donations from that individual rather than finding out the location...
[21:17:57] <saurabhbatra>	 pseudo-blacklisting ISPs
[21:18:00] <awight>	 It’s pretty sketchy terrain when we start using direct zip codes etc
[21:18:22] <saurabhbatra>	 it's really easy to change IPs though
[21:18:41] <saurabhbatra>	 harder to change the information associated with your UP
[21:18:43] <saurabhbatra>	 *UP
[21:18:47] <saurabhbatra>	 *IP argh
[21:19:06] <saurabhbatra>	 what you're saying makes sense
[21:19:15] <awight>	 For ISPs we would want the raw IP probably but I don’t like the zip code approach because we don’t want to make it harder to donate from across town
[21:20:25] <saurabhbatra>	 IPs are tough for ML models to understand IMO
[21:20:38] <saurabhbatra>	 GeoIP gives ISP info too I think
[21:20:43] <saurabhbatra>	 not too sure
[21:21:17] <saurabhbatra>	 agree that we don't want to impede honest donations just based on location
[21:21:57] <saurabhbatra>	 but i feel like this data could make or break our classifier
[21:23:29] <saurabhbatra>	 then if we feel like it may be "unfair" based on location, we just skew our thresholds so that it precision goes up, recall goes down
[21:24:29] <saurabhbatra>	 from the chat i had with Elliott, minFraud also primarily uses this information to tune its filters
[21:25:26] <saurabhbatra>	 http://maxmind.github.io/minfraud-api-php/doc/v1.7.0/
[21:25:38] <awight>	 I’m sure they do, but they might not share our feeling of responsibility for a fair outcome
[21:26:40] <saurabhbatra>	 i think it sounds worse than it actually is
[21:27:35] <saurabhbatra>	 tbh without it we have little to no information about the transactions
[21:27:40] <awight>	 well… it’s possible to measure when we’re done, we vary country code and compare the model’s outputs
[21:28:15] <saurabhbatra>	 i think we're looking at it wrong
[21:28:41] <saurabhbatra>	 as long as precision is high, we're not impeding anyone from donating irrespective of their location
[21:29:23] <awight>	 I don’t see anything about location in https://collab.wikimedia.org/wiki/Fundraising/Donor_Services_Documentation/Fraud_Procedures, FWIW
[21:29:45] <awight>	 just factors #8, what else happened from this exact IP
[21:30:32] <saurabhbatra>	 i think the solution to this is that we try out both the models
[21:30:44] <saurabhbatra>	 see what kind of p-r curves we get
[21:30:49] <awight>	 It’s not just about precision if recall is different depending on some no-fault feature
[21:30:53] <saurabhbatra>	 and postpone the decision to that point
[21:31:11] <saurabhbatra>	 good point
[21:31:35] <awight>	 +1 It’s a great idea to try and see what happens, but IMO it’s a heavy decision to include such a feature and we should track that there are open questions...
[21:32:23] <saurabhbatra>	 agreed
[21:32:38] <awight>	 For example, with Wikipedia edit “damaging” we found that checking whether a user is logged-in or anonymous becomes an unfair question to consider, when the model selects a heavy weight on that feature
[21:33:01] <awight>	 An individual anonymous editor shouldn’t be punished for vandals hiding behind anonymity…
[21:33:30] <saurabhbatra>	 agreed, that makes sense
[21:34:35] <saurabhbatra>	 lets try the less-intrusive way first (raw IPs). if the model does not perform satisfactorily, then we can look this approach up too
[21:37:37] <eileen_>	 quack
[21:37:49] <saurabhbatra>	 morning eileen_ !
[21:37:49] <eileen_>	 (not up with the play here - just making comforting duck noises)
[21:37:55] <eileen_>	 morning
[21:38:52] <saurabhbatra>	 so adam and i were discussing the consequences of passing IP extracted data to train our model
[21:39:06] <saurabhbatra>	 (IP extracted geo-location data)
[21:39:30] <saurabhbatra>	 would a bias against a certain country/region be fair or not fair
[21:39:43] <saurabhbatra>	 based on our previous data
[21:41:16] <eileen_>	 Hmm - so I guess that fairness is a thing in ML as it can re-inforce priors
[21:41:19] <awight>	 saurabhbatra: I don’t think even IP is an input to the model MBeat outlined, fwiw..
[21:41:51] <awight>	 The feature would actually be the history of other donate wiki requests and transactions from that IP
[21:41:53] <eileen_>	 But, don’t we need to use an external provider to do a lookup for country- I’m not sure how that fits in with our privacy etc
[21:42:05] <awight>	 We’re allowed to if we want…
[21:42:53] <eileen_>	 I guess I like the idea of not locking any doors in the code we might want to re-open
[21:43:09] <saurabhbatra>	 the problem is not with exposing pii
[21:43:43] <eileen_>	 but this makes sense to me “: lets try the less-intrusive way first (raw IPs). if the model does not perform satisfactorily, then we can look this approach up too"
[21:43:50] <saurabhbatra>	 awight: that process is how transactions getting a high minFraud score are evaluated by humans
[21:44:30] <saurabhbatra>	 minFraud uses the geo-location data afaik
[21:44:35] <awight>	 But I don’t think we’re targeting that type of fraud for this phase of the project
[21:44:59] <awight>	 If we’re only doing chargebacks and refunds, those already made it through minfraud and the gateway’s native fraud
[21:45:44] <saurabhbatra>	 makes sense, but minFraud only uses rule-based filtering
[21:45:49] <saurabhbatra>	 we could improve on that
[21:48:58] <saurabhbatra>	 so the process is something like this - transaction made -> sent to minFraud -> rejected/processed -> if processed and suspicious, checked by humans and then resolved manually
[21:50:09] <saurabhbatra>	 so payments_fraud.validation_action='reject' are actually transactions rejected based on transaction data (including IP addresses) by minFraud
[21:50:21] <saurabhbatra>	 (i think)
[21:51:01] <awight>	 Yah I think that’s right
[21:51:34] <awight>	 But still, not quite seeing a good reason to expand our scope to catching or training on these...
[21:52:03] <saurabhbatra>	 i guess my argument hinges on the fact "they thought it was important so we should too"
[21:52:09] <saurabhbatra>	 but i see the flaw in that
[21:53:16] <saurabhbatra>	 and i see the logic in your argument
[21:53:33] <awight>	 I’ve probably added quite a bit to the static, by not following that we were focusing on chargebacks, sorry!
[21:53:47] <awight>	 At least I finally got it today
[21:54:07] <saurabhbatra>	 the only thing that irks me - suppose statistics show that 10% of frauds originate from country A
[21:54:27] <saurabhbatra>	 should we willfully ignore those?
[21:55:02] <saurabhbatra>	 that feels like something which is at cross-purposes with our original goals
[21:55:26] <awight>	 We should consider it for sure
[21:55:53] <saurabhbatra>	 it's complicated, the more i think about it the more i think you're right
[21:55:57] <awight>	 But IMO that would probably jump out from our results
[21:56:16] <saurabhbatra>	 but right morally not statistically
[21:56:24] <awight>	 lol <3
[21:56:32] <awight>	 What bothers me is that I don’t know the formal names or process for choosing features
[21:56:53] <awight>	 Just sparse, anecdotal reasons for not doing particular things.
[21:57:21] <saurabhbatra>	 i think that's better than the former :-)
[21:57:48] <saurabhbatra>	 i'll also have to do some reading up tbh, not my forte
[21:58:33] <saurabhbatra>	 i'm just basing my arguments on the assumption more data = better lol
[22:01:44] <saurabhbatra>	 another question which we should be asking is - are we looking to supplement minFraud or replace it?
[22:02:55] <saurabhbatra>	 something which can wait till tomorrow i think. off to bed now
[22:03:14] <saurabhbatra>	 cya awight eilenn_ !
[22:03:44] <saurabhbatra>	 i'll do a mail thread summarising everything tomorrow (mine)
[23:34:50] <wikibugs>	 (PS12) Ejegg: Add opt_in field for selected countries [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/445327 (https://phabricator.wikimedia.org/T199278)
[23:34:52] <wikibugs>	 (PS3) Ejegg: Get rid of traces of old 'optout' field. [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/446207 (https://phabricator.wikimedia.org/T199278)
[23:36:47] <wikibugs>	 (CR) jerkins-bot: [V: -1] Add opt_in field for selected countries [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/445327 (https://phabricator.wikimedia.org/T199278) (owner: Ejegg)
[23:37:13] <wikibugs>	 (CR) jerkins-bot: [V: -1] Get rid of traces of old 'optout' field. [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/446207 (https://phabricator.wikimedia.org/T199278) (owner: Ejegg)
[23:37:28] <wikibugs>	 (PS13) Ejegg: Add opt_in field for selected countries [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/445327 (https://phabricator.wikimedia.org/T199278)
[23:37:30] <wikibugs>	 (PS4) Ejegg: Get rid of traces of old 'optout' field. [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/446207 (https://phabricator.wikimedia.org/T199278)
[23:38:25] <wikibugs>	 (PS14) Ejegg: Add opt_in field for selected countries [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/445327 (https://phabricator.wikimedia.org/T199278)
[23:38:27] <wikibugs>	 (PS5) Ejegg: Get rid of traces of old 'optout' field. [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/446207 (https://phabricator.wikimedia.org/T199278)
[23:40:04] <wikibugs>	 (CR) jerkins-bot: [V: -1] Add opt_in field for selected countries [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/445327 (https://phabricator.wikimedia.org/T199278) (owner: Ejegg)
[23:40:10] <wikibugs>	 (CR) jerkins-bot: [V: -1] Get rid of traces of old 'optout' field. [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/446207 (https://phabricator.wikimedia.org/T199278) (owner: Ejegg)
[23:42:26] <wikibugs>	 (PS4) Eileen: Components for new contact editor [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/443202
[23:42:52] <wikibugs>	 (PS15) Ejegg: Add opt_in field for selected countries [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/445327 (https://phabricator.wikimedia.org/T199278)
[23:42:54] <wikibugs>	 (PS6) Ejegg: Get rid of traces of old 'optout' field. [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/446207 (https://phabricator.wikimedia.org/T199278)
[23:44:29] <eileen_>	 ejegg: code for contact summary editor is here https://gerrit.wikimedia.org/r/#/c/wikimedia/fundraising/crm/+/443202/
[23:44:40] <ejegg>	 thanks eileen_ !
[23:44:45] <wikibugs>	 (PS1) Eileen: Enable new contact editor extensions [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/447563
[23:45:32] <ejegg>	 wow, installing a whole new API version as an extension kinda boggles my mind
[23:46:31] <awight>	 :) eileen_  is reeeally good at that!
[23:46:43] <eileen_>	 :-)
[23:47:02] <eileen_>	 well the api v4 has been underway for a while - Coleman’s baby really
[23:47:21] <eileen_>	 this is kind of it’s graduation to the big time
[23:47:36] <eileen_>	 & yeah - at some point it has to ship with core by default