@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.

I don't believe that this app is currently being advertised, made available or maintained. @yuvipanda would be the most recent maintainer, and that has been a while.

Ah, I looked not carefully enough. Thanks for pointing this out. Should there be a 'deprecated' statement in the description as is the case with other deprecated columns?

We worked on this at the hackathon a bit and I think we figured it out on our usecase (the first uploader is sometimes in the image table and sometimes in the oldimage table, so you have to use both. From what I understand, the image table always contains the uploader of the current version, and then the oldimage table only contains uploaders of previous versions).

@rook I've been unable to reproduce even on the main server, but the hub-paws-dev actually doesn't even start up the server for me (it gets stuck at 2023-08-01T23:22:42Z [Normal] Pulling image "quay.io/wikimedia-paws-prod/singleuser:pr-317")

I have been running different versions of two notebooks (iterating to squeeze out bugs and data issues) this and this. I suspect the latter has been the most challenging - but it's hard to pin down as it only happened twice so far.

@rook just fyi, I was having problems again today (between 9 and 10pm PT, if that helps) as a gradual slowdown and restarting kernel didn't help, but this was resolved after restarting the server.

Found a workaround: stopping the server via the hub control panel, and then starting a server from the same resulted in a workable situation again. Not sure if this should be closed, or if there's an underlying issue that needs addressing.

(moving from in-progress to open for now -- will need a bit of discussion to see whether it is likely that it every gets resolved in a more satisfactory way)

As for the status:

• As far as the research project is concerned, this is probably how far it'll go.
• It did not answer the questions we set out to answer to the level of detail we hoped for, but gave some insights.

After much back and forth (sorry for the delays!) I finally published the write-up here: https://meta.wikimedia.org/wiki/Research:Effectiveness_of_the_new_participant_pipeline_for_Wiki_Loves_campaigns#Outcomes

@ssastry @Whatamidoing-WMF we now have a volunteer who's able to reproduce the error. Please let them know any additional questions you may have to drill down to the cause :)

@Sietske Thanks a lot. I believe the ability to edit the entire page is by design (although it is a bit confusing, i agree). I was unable to reproduce it myself so far this way, but trying to turn on some features to see if I can find it too.

More people have been reporting this recently again in https://nl.wikipedia.org/wiki/Wikipedia:De_kroeg#Bonje_met_de_visuele_editor:_artikeltekst_verschijnt_twee_keer_tijdens_bewerken

OK let me rephrase this: What do you want to do with the summary and what do we want to learn? You can spend a lot of time digging out details from it (and I would appreciate access to the raw data regardless for some evaluation attempts myself) but that may be beyond the scope of what you're looking for.

If I should do a more in depth analysis, I need the raw responses. But given that Manfred already shared a summary, what exactly is the deliverable here?

Do I have access to the data?

No, this is unrelated.

I think this is a good one to track. Should be easy to fix, once someone takes over maintenance of Monumental.

I see, thanks. I implemented the urlencode, hopefully that does the trick.

@RLazarus could you verify this patch doesn't have a typo? This task seems unrelated.

I'm not sure if I fully understand your request (how the rounds would tie together in your view, and what settings would apply when). What is clear, is that this is a feature request, rather than a bug report (still helpful, just making the distinction).

I believe that the disqualifications only happen when the images are loaded for the first round. So it would be expected behavior to me that if you change the juror after creating the round, that the images from this new judge are not disqualified.
This is maybe not ideal, but I can't think of a practical way that would consistently deal with new jurors midway the process - because it could possibly involve re-assigning all images to judges if you want to disqualify some midway through a round while balancing the number of images per judge.

You're right, thanks for correcting me @Xelgen . Reopening for now.

This is expected behavior: I believe that countries only show up after their first valid upload. Armenia seems to be correctly denoted here: https://commons.wikimedia.org/wiki/Module:WL_data

This is expected behavior: I believe that countries only show up after their first valid upload. Armenia seems to be correctly denoted here: https://commons.wikimedia.org/wiki/Module:WL_data

if the timing works, happy to join.

@Whatamidoing-WMF (un)fortunately, I'm not one of the people affected by this bug. I'll ask though!

For the record: I asked the users involved to try the suggestion by aklapper and report back.

@Ciell We need to rename the list (or archive it), and possibly move it from wmnl to the @lists.wikimedia.org mail server. It would be nice if we can carry over the archives to the new list, but not sure if that's feasible.

I think so, yes!

@Mayakp.wiki I don't have access to the full report, but the public slides mention 2-4% (globally) / 5-9% (USA) before Oct 3, and 5-8% (globally) / 15-21% (USA) after Nov 4. Am I correct to assume that the Nov was a typo and should be Oct 4?

@rook thanks, very helpful to be more aware of and silly that I didn't think of it!

I suspect this ticket can now be resolved. Haven't seen recent activity.

Error can no longer be reproduced in this page. Resolving.

Thanks!

With copypaste i mean the option to use 'file list' which allows you to copypaste the content of the file (Without header) directly. In my experience, less error prone. When I import it that way, I get 1951 correct imports out of 2076. This means there must be 125 errors.

@Geertivp could you attach the txt file?