(oops, I clicked a button I wasn't sure what it did :) )

In T379318#11693429, @ssingh wrote:

@greg: Traffic was notified about this an it seems like wiki.gives is a 404. Is that expected?

No rush. We can totally park it for later. The use-case has been long standing and intermittent so no immediate driving force, just Something We Should Do(TM).

+1 to both, thanks!

hmmm, thinking about this from the lens of the use case I put in the description, I'm not sure!

Thanks Elliott!

👍

Both are fine. And I assume the separate view on https://sal.toolforge.org/ is just going to be via having a fundraising entry on the /projects list?

Looks like the form that the template uses is restricted to reduce spam (presumably). I just added you to WMF-NDA so you can now use it. Just, usual statement: now you can see things in Phabricator that aren't always public :)

@CHudson-WMF if you use the template link from https://wikitech.wikimedia.org/wiki/Fundraising/techops/docs/fundraising_access_request it'll automatically add the correct project tag. I just added it now :)

Thanks for the ping @FCeratto-WMF .

Thank you! We'll reach out later (it's a bit busy over here right now, as you can imagine).

Thanks @jcrespo ! I didn't see your message until now and well, your warning was founded:
https://github.com/minio/minio/commit/27742d469462e1561c776f88ca7a1f26816d69e2 (minio in official maintenance mode now)

As @AStein-WMF 's manager, I approve.

Updates so far from Wenjun and Dami: https://office.wikimedia.org/w/index.php?title=Fundraising%2FEngineering%2FOn_call&diff=372087&oldid=352995

Moving to our current sprint (which will change in a couple hours from now) to keep track as we ensure there's no follow-up needed on our side.

For the record, the list of emails in my screenshot above have been marked as opt-out so no emails should go to them anymore.

(I'm deeming none of that as PII, even though I wouldn't normally paste the emails of any other contacts in Civi.)

Results of searching %@lists.wikimedia.org in Civi:

added that parent task (T87667) which has other Accessibility concerns (but is old, so might need re-review).

Moving back to Triage from Later.

Moving to done on chaos crew board, as the AWS outage is over (*knocks on wood*).

Changing from UBN! to High, since the acoustic-hosted links seem to be working again.

Noting that I'm prioritizing this investigation task due to the usage rate being very out of the ordinary and will required some significant budget re-arrangement to compensate. cc @AKanji-WMF @XenoRyet

Approved!

Thanks Peter and thanks for the config change. Do you want to manage the deploy of this through a backport window or have someone of fr-tech? https://wikitech.wikimedia.org/wiki/Backport_windows

done: https://donate.wikimedia.org/w/index.php?title=Template:2012FR/Form-countryspecific-control/US&action=history

Folks are reporting it works again, we'll uncomment that commented out line above ^.

Thread with Gravy & Trustly: https://wikimedia.slack.com/archives/C07JA677QDQ/p1759518709277799

https://donate.wikimedia.org/w/index.php?title=Template:2012FR/Form-countryspecific-control/US&diff=prev&oldid=41743

At 10:09am pacific from Gravy:

Hey @Cstone, our team has released a fix for this issue. We'll be monitoring closely at UTC midnight to ensure everything is working as expected.

T402062: Fundraising access request for Lars Sander-Green

Oops: T402061: Fundraising access request for Stacy Burnett

After more investigation the next steps are to turn it back on and see if the deadlocks reoccur.

Greg Grossmeier <greg@wikimedia.org> Mon, Aug 18, 2025 at 8:00 AM
To: Lisa Gruwell <lgruwell@wikimedia.org>
Cc: Jeff Green <jgreen@wikimedia.org>, Avishua Stein <astein@wikimedia.org>
Hello Lisa,

Greg Grossmeier <greg@wikimedia.org> Mon, Aug 18, 2025 at 8:00 AM
To: Lisa Gruwell <lgruwell@wikimedia.org>
Cc: Jeff Green <jgreen@wikimedia.org>, Avishua Stein <astein@wikimedia.org>
Hello Lisa,

We discussed this internally briefly and I agree that we should turn off the frdata update job until we can determine the root cause and mitigations.

(changing from UBN to High as this should be resolved, we just wait to actually close tasks until our sprint review)

Relevant slack thread with dlocal that @AnnWF re-poked to get info from them: https://wikimedia.slack.com/archives/C072S0VFH42/p1749739060959609

summary of discussion during fr-tech backlog triage call: We're pretty certain if the only thing changing in the cookie is setting the expiry date, CentralNotice should consume/use correctly.

Kindly asking for help diagnosing this Release-Engineering-Team.

Moving this out of unscheduled into Triage for us (FR Tech) to re-review/prioritize our side on it as it's a thing that needs cross-team (Traffic and FR-Tech) coordination.