User Details
- User Since
- Oct 14 2014, 5:52 AM (521 w, 1 d)
- Availability
- Available
- IRC Nick
- effeietsanders
- LDAP User
- Unknown
- MediaWiki User
- Effeietsanders [ Global Accounts ]
Fri, Sep 20
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.
Wed, Sep 18
Aug 10 2024
Jan 20 2024
Dec 26 2023
Dec 21 2023
Nov 17 2023
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.
Nov 4 2023
Aug 24 2023
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?
Aug 17 2023
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).
Aug 5 2023
Aug 2 2023
Aug 1 2023
@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")
Jul 31 2023
Jul 30 2023
@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.
Jul 28 2023
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.
Jun 29 2023
(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
Jun 22 2023
@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 :)
Jun 20 2023
@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.
Jun 5 2023
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
May 4 2023
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.
May 3 2023
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?
Feb 17 2023
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.
Jan 18 2023
I see, thanks. I implemented the urlencode, hopefully that does the trick.
Jan 6 2023
Dec 1 2022
@RLazarus could you verify this patch doesn't have a typo? This task seems unrelated.
Oct 19 2022
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.
Oct 2 2022
You're right, thanks for correcting me @Xelgen . Reopening for now.
Sep 30 2022
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
Aug 12 2022
Jul 14 2022
if the timing works, happy to join.
Jul 13 2022
@Whatamidoing-WMF (un)fortunately, I'm not one of the people affected by this bug. I'll ask though!
Jul 11 2022
For the record: I asked the users involved to try the suggestion by aklapper and report back.
Jul 10 2022
Jul 4 2022
@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.
Jun 24 2022
Jun 7 2022
I think so, yes!
May 5 2022
@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?
Apr 8 2022
@rook thanks, very helpful to be more aware of and silly that I didn't think of it!
Apr 5 2022
I suspect this ticket can now be resolved. Haven't seen recent activity.
Error can no longer be reproduced in this page. Resolving.
Mar 21 2022
Thanks!
Mar 7 2022
Feb 2 2022
Jan 15 2022
Jan 14 2022
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.
Jan 13 2022
@Geertivp could you attach the txt file?
Nov 17 2021
Oct 26 2021
Thanks @Dzahn it looks like making the user explicit for bast did the trick, I'm in.
Oct 25 2021
@Dzahn thanks! Unfortunately ssh keeps asking for a password when I try to ssh into bast: ssh -v bast1003.eqiad.wmnet and also tried stat: ssh stat1005.eqiad.wmnet
Oct 21 2021
Thanks @MGerlach . I added the information.
Sep 25 2021
Thanks @leila for this helpful response. We will discuss internally and follow up with you over email following that.
Sep 5 2021
Yeah, one of the main reasons why people think this might be different, is that people may have to take a photo before they can actually upload them. So they may see the banner, go take a picture, and then come back to the banner to upload.
Not sure if that actually happens in practice, but that may be one of the plausible reasons I heard why things may be different. There is some intuition that there is a diminishing return though - where the optimum lies, is not obvious to me :) .
@AndyRussG it would be great if you could help lay the connection with the right people :)
Sep 4 2021
Aug 30 2021
Thanks @Legoktm for digging into this! It is surprising that I'm not on wlm-announce as a member, because once i was, and i dont recall unsubscribing. But that is fixable!
Aug 28 2021
Aug 9 2021
Aug 7 2021
Someone just reported a problem on Telegram with the text "Unknown unrecoverable error has occurred. Error details: 'Your IP address has been [[m:Special:MyLanguage/Global Blocks|Blocked on all wiki's]] (...)" (the message is much longer). The message appears without markup and in flat wikitext. It seems to refer to a global block. The message appeared in the same location.
Jun 7 2021
May 7 2021
May 5 2021
The email was in English. Happy to forward if that is of help.
Apr 8 2021
@Dzahn many thanks for the speedy turnaround. I've set it up.
Apr 7 2021
Mar 1 2021
@Aklapper I'm sure this will be equally relevant in a month or so (this is the kind of thing that lingers too long), but technically speaking, we're still in the aftermath of WLM2020 :). We usually transition in March/April.
Jan 4 2021
Oct 16 2020
Agreed. I also want to add the perspective that it's not just English Wikipedia with plenty of interface admins that we're dealing with here. We're also looking at a vast majority of wiki's where the group of interface admins will be tiny, if even existent.
Oct 14 2020
Given the explanation by @PerfektesChaos , I can understand why admins are not permitted to create/re-create a js/css page. However, viewing a deleted version seems reasonably harmless. I imagine that people who have the ability and intention to hijack an admin account, have better sources for malicious code than deleted js/css pages on Wikipedia.