It's not just about editors who are blocked who would have gotten a talk page message anyway per normal policy or practice of most (or all?) wikis. At the moment, you can be blocked and if the admin don't tell you wouldn't know anything about it if you don't happen to try and edit during the duration of the block. Such possibly being edge cases doesn't mean we shouldn't worry about it. Secondly, it's also I believe consistency. I believe you get a notification if your user rights are manually modified. Being blocked from editing is effectively if not technically a significant change in userright. The editor concerned should be notified of that by the software and not relied on the admin posting a talk page message telling them.

Hi @JeffreyWang, while I and I'm sure many others very much value your technical contributions to the MediaWiki community and ecosystesm, this is an election to the Wikimedia Foundation board of trustee and we have to draw the eligibility criteria based on some association with Wikimedia. I feel drawing the line on extension being used on Wikimedia wikis as a reasonable one.

In T243037#5812031, @Qgil wrote:

@soworu It would be useful to check with Legal how we can make any use of the existing data. Knowing who has applied for scholarship in previous Wikimanias and who was accepted / declined may be useful information for scholarship committees in the current Wikimania and future events.

And to expand on the above, reproduced bug on both 32 and 64 bits Firefox 70.0.

It's an issue with accessing the page on Firefox 70.0. Reproduced with FF 70 on Win 7. Expected behaviour with FF 69.0.1 (64-bit) on Win 10. Upgrade to v70.0 on the Win 10 and reproduced the bug.

For information, this is the code, and this is the command that ran the script.

I think someone need to update the package under \wikimania-scholarships\vendor\phpmailer\phpmailer and make sure nothing are broken by it?

And again for 2018.

Thanks a lot everyone that have helped get this sorted.

@thiemowmde You can accept the idea that "yyyy-mm-dd" may not make sense for some people in the world, but not when a native language reader telling you that "dd Mmm yyyy" makes even less sense? When doing localisation, if native readers are telling you that what you have make no sense in that language, stop and listen.

I personally don't really care about the list in question because I'm not an active contributor to the associated project. It only matters to me when emails get sent pretending to be from me (T160529) and there's no list admin to ask to set up a filter preventing those from getting through.

I'm not personally requesting anything. Just noting that the mailing list has no list admin.

And x2 again today. This is getting ridiculous.

And again.... https://lists.wikimedia.org/pipermail/wikimedia-l/2017-April/087294.html

In T160529#3161835, @grin wrote:

Dropping/autorejecting email with matching header
​X-Spam-Score: .+\+\+\+\+\+
(which is above spam scrote 5.00) probably helps a lot.

According to the message headers, fermium.wikimedia.org received a message from 154.73.18.196 at 09:53:16 UTC 15 March 2017 for delivery to a long list of Wikimedia mailing lists specifying "Wikimedia-l" <ktc AT ktchan.info> as the sender email address.

No. The edits, while made using the CentralNotice extension interface, are made by human.

It having been ignored for more than a year doesn't mean it's "probably not an issue anymore", especially if no unrelated changes have been made that might have fixed it indirectly. I have no recent experience of the problem because I have been using an external uploader (VicuñaUploader) for quite a while to specifically avoid the issues. Don't think "don't use our own uploader, use something else" is how we want to solve issues with the UploadWizard.

Even if you make the change here, it's not going to make any differences to those banners that are inserting the image manually through its own code.

Have set onlySampleRI, and basic javascript/cookie to display up to 2 times per project but that only affect what someone see and not whether the HTML/CSS/JS get loaded in the first place. @Glaisher had set traffic to 50% earlier.

Whose cache? The user's, the ISP's, Wikimedia server's? Multiple users have experienced this, so even if it's the users computers, should look at whether there's anything that can be done server side to reduce/eliminate this.

Personally, I'm not seeing any banners I shouldn't, but as @Glaisher mentioned, I'm not unique in having encourtered this.

Entirely possible, but I wasn't the only one at the Wikimedia UK's office that saw the banner after it supposed to have ended.

@atgo, can't tell because we have active banners scheduled displaying (until tomorrow) so I'm seeing those. I think I kept seeing the POTY banner until the steward vote / wikimania banner came online. Of course, I'm seeing the POTY banner again, but this time it's expected because it's currently R2 at the moment and it's been set to display for this last week.

That's all fine and dandy if it weren't for the fact that "m:" was broken on global user page until change 191812 (see above) provided a temporary fix!

See image for how banner edits are appearing as bot edits on watchlist.

Fixed the Wikimania banner in relation to this task.

Also see https://meta.wikimedia.org/wiki/Grants:TPS/Wikimania_scholars/Proposed_2015_Process