happy to - but it looks to me that the account is already successfully added. Should i delete it?

@Nikerabbit OK, I think it should be ready now. Please let me know if anything seems to be amiss!

I think the first question is whether the data is available. That's not an experiment, that's a simple data request. If you want me to create a different task for that, I'm happy to do that. Some guidance here is appreciated to make that as smooth as possible.

I'm not sure what is best practice here. If there is a way to verify the data? If the data is very much in line with what I'm requesting, I could imagine that a WMF-wide request is fair. If more data is needed, we could do see if there's an experiment possible.

Thanks a lot, this was very helpful and saves a lot of time.
The 275k seems to have been an accidental underestimate based on extrapolation, and i was able to verify that the number you found gets much closer to the truth indeed.

In T431953#12112772, @Aklapper wrote:

@Effeietsanders Who is "you" / who is this ticket addressing? Please add a corresponding project tag if possible - thanks!

Integrating it would be interesting. I would need to see more about the details of the implementation to know if there's anything I'm missing - but it sounds much lower friction than other approaches I've heard.

In T426959#11955556, @Robertsky wrote:

If you are referring to potential misuse of the verification mark, the minimum requirements that of IRC cloaks should suffice, including a team to revoke the verification mark if necessary. Of course, there could be a potential spill over into personal communications with uninvolved people, but it is the same as joining into unaffiliated chat rooms on IRC.

What would be the trust and safety implications? I'm thinking about withdrawing status, whether ucoc would then apply to their submissions, later privacy concerns, etc. not a hard blocker, but something to investigate.
A possibly problematic sure effect should be the extra time required for trust and safety.

Thanks a lot! And glad that there's one less thing to worry about re: back luck! And I agree, it would be great if it could be supported on Toolforge - easier for everyone.

In T381057#11934131, @nshahquinn-wmf wrote:

@Effeietsanders did you find that the 3 datasets mentioned in descriptions are the only ones missing, or are they just examples of what might be a larger problem?

Is the list of countries that we should expect to be filtered out, public? For example, I'm noticing that the data for CZ is very odd - while the country stats for cswiki suggest CZ to be a top country, it does not seem to show up here. Sometimes it does though... and Claude claims (grain of salt, but sofar it seems to hold up) that in all those cases it's labeled as "Czech Republic CZ" . Another explanation (which would be in line with NL) is that MaxMind uses "Czechia" and this means that the country is therefore somewhere in the pipeline rejected.

(initially posted on the wrong ticket)
It looks like NL has silently reappeared starting with the 2026-03-01 file, confirmed via a timeline scan.

In T381057#11932558, @nshahquinn-wmf wrote:

@Effeietsanders could you remove your two comments here and post them on T426559? It seems like that's where they belong, and it will make the tickets easier to follow.

I would expect that we would build the containers ourselves from the source. I am not aware of ready-made images of Particiapi and Polis. PostgreSQL may be available as a standard image.

(moved)

(moved)

Another use I'm trying to gather momentum for, would eventually be to better understand the concerns and possibilities around effective AI use in the Wikimedia universe. This is probably more a series of conversations - and my impression is that it's in part about making the conversation more accessible to people who are less-well versed in it, and at the same time enabling us to actually understand what those conversations are trying to say when they aren't just SNOW-closed.

I find it hard to discuss these concepts with community members without a working prototype. I would honestly love to discuss and understand your concerns on fragmentation more in a synchronous conversation. If you're up for it, let's schedule one.

Polis is an established opinion collection tool (https://pol.is ) that I have built on top of, and want to see if it would help establish more constructive conversations in certain community questions. Particiapi is a fork off that that allowed me to build a front-end flask app. It currently runs successfully with a nearly complete set of features locally.

The remaining actual request is based on https://wikitech.wikimedia.org/wiki/Portal:Toolforge/Admin/Kubernetes#Regenerate_.kube/config . Thanks!

Thanks for correcting it. It seems an over-assuming AI assistant added that message to my script output, and it was not part of another error. My bad!

@Legoktm Thanks again for this! Is there progress on the more high level task? I have another few lists where I was trying to add this, and just found this back :)

I was unable to verify the blocking and exempt status for the admin account creation.

Oh, not sure where I saw this pop up unexpectedly in results - nevermind!

It looks like the ACM is a current partner. Does that mean this ticket can be closed?

To be superfluous, I also tried creating an account via the 'add editor' button (not sure if this is the expected workflow, the interface is a bit confusing here):

In fact, this is using the account creation link that the user is presented with on the dashboard registration page. Maybe I'm misunderstanding your assumptions/question? I added a screenshot below of what the attendee would see.

OK, I did a test with the help of an enwiki admin. Reproduction steps:

• Go to https://en.wikipedia.org/wiki/Wikipedia:Get_my_IP_address and copy your IP
• Open incognito browser and go to nl.wikipedia.org and create an account . Confirm this is possible. Close browser.
• Open incognito browser and go to en.wikipedia.org and create account. Confirm this is possible, close browser.
• Open the event registration link in an incognito browser and click on "sign up with Wikipedia". Observe that this is possible. Keep this window open.
• Block your IP on en.wikipedia.org for 30 minutes
• Open the event registration link in an incognito browser and click on "sign up with Wikipedia" --> observe that this link is now greyed out with a subtle 'information' icon that tells you that the IP is blocked.
• Now we return to the already opened window. Note that the url has something like /enwiki/ in it. Try creating an account. Observe that you get a message with: "Auto-creation of a local account failed: This IP address has been blocked from editing Wikipedia."
• Go back to the same url and change /enwiki/ to /nlwiki/ and try again. Observe this still gives the same message.
• Open incognito browser and go to nl.wikipedia.org and create an account . Confirm this is possible. Close browser.
• Open incognito browser and go to en.wikipedia.org and create account. Confirm this is NOT possible, close browser.

As a sidenote:
Just to be clear, the biggest blocking issue is really that the /enwiki/ in the url should become /<homewiki>/ . That may require a bigger change that also involves the API somehow, but that is a 'true solution'. However, I can indeed imagine that there might be workarounds available to deal with some of the symptoms - which is also appreciated!

In T307878#11612828, @Xaosflux wrote:

I know the dashboard-created accounts are already bypassing ratelimits and has enwiki ipblock exemption. Is it actually failing to create accounts still? I agree this isn't ideal; just trying to what the biggest blocking issues are. One I can see is if there is a global block, the local project may need to exempt the users locally so they can contribute, but that would happen even if they were created locally.

Thanks for asking!

I can support this request. See also https://meta.wikimedia.org/wiki/Talk:Programs_%26_Events_Dashboard/Archives/2024#Request:_Automatic_account_creation_on_home_wiki? as another sample case from a while ago.

In fact... for me, the thanks link appears right next to the revert button. The revert button does not have a confirmation step (although its effect is more intrusive - I guess it's at least theoretically revertable itself), which might give some estimate as well (if we expect people to misclick - I don't see a reason why that wouldn't be roughly symmetric). So perhaps we could look at reverts of reverts caused by the revert button?

In T416564#11593308, @Izno wrote:

The thank action can take place from parts of the interface that have many other links (deliberately so), such as on the watchlist or recent changes, or indeed the page history. Avoiding misclicks is probably the primary reason thank has a confirmation.

@isarantopoulos I see you moved this task to a board that seems to be inactive (presumably because ORES is being deprecated).

While I'm less worried about rate limiting for security reasons, I would be very curious whether a limit would make 'thanks' more valuable! This becomes more a research question - but it would be fascinating to see what the (longer term) effect would be to switch some communities to a budget of 'thanks'. This could be related to the number of edits they make (a budget of 10, where every 10 edits refills 1 thanks).
My hypothesis would be that with a budget, if sufficiently communicated, the 'value' of a thanks would go up and it might have a larger positive effect on both the recipient and the sender on retention and activity levels.

I ran into this again as admin, who received a reminder of pending moderation requests. That currently has no link to Posterius and it's actually quite a few clicks to find (try googling it if you don't remember 'posterius' as the name).
On the list I ran into this, where I'm admin, we have [list:member:digest:footer] and [list:member:regular:footer] as templates (via this page. I am guessing that the footer/text for the reminder emails is set in [list:admin:notice:pending]?

dq_by_uploader is no longer available. Not sure if this is by design, but that seems to make this issue moot.

Could this be related to https://commons.wikimedia.org/wiki/User_talk:AcroniusZ#Monument_numbers ? That also seems to be related to batches of uploads that have incorrect information propagated - although it may also be entirely unrelated.