Comments

The following is an automatically-generated compilation of all talk pages for the Signpost issue dated 2024-05-16. For general Signpost discussion, see Wikipedia talk:Signpost.

Arbitration report: Ruined temples for posterity to ponder over – arbitration from '22 to '24 (8,989 bytes · 💬)

The AllisonW Affair is very much "the mystery of the withheld theme", to quote Otto Rank (by way of Anaïs Nin). More generally this Arbitration Report is a scroll of high-end flame-outs as fascinating as it is appalling. kencf0618 (talk) 11:58, 16 May 2024 (UTC)
I wasn't here for the last time a report like this happened, so it's fascinating reading through these cases and seeing the similarities between some of them. Suntooooth, it/he (talk/contribs) 12:56, 16 May 2024 (UTC)
Actually, Jonathunder hasn't posted again after discussing having a long and serious illness. I met him in 2019 at the Boston Wikimedia conference and was impressed by his enthusiasm, energy level, and overall love of editing and photographing for Commons. I don't think that he is (hopefully not 'was') a Wikipedian who would have left because of an arb case. Does anyone know if he is okay? Thanks. Randy Kryn (talk) 14:01, 16 May 2024 (UTC)
Thank you for a very interesting (and often entertaining) report. Toughpigs (talk) 15:00, 16 May 2024 (UTC)
Thank you for recognising the (to my mind, very sad) departure of the ultra-prolific BHG. I had been disappointed not to see her case mentioned in The Signpost at the time. PamD 16:03, 16 May 2024 (UTC)
Thanks for this. When I opened the page, I thought, Gee, I'll never read all the way to the bottom of this, only to find myself riveted, entertained and informed for the next half hour. --Andreas JN 466 18:58, 16 May 2024 (UTC)
I'll pile on by adding my thanks. -- John Broughton (♫♫) 19:31, 16 May 2024 (UTC)
I commented over on WPO that I assumed the lack of coverage was due to lack of resources, and not malice, unfounded speculation is sadly all too common over there, but I would also question why you would repeatedly call it a "badsite" when WP:BADSITES is a failed proposal from over a decade ago. I get that you feel personally attacked by those threads, because they do personally attack you, that's simply a fact. What I don't expect is that your hurt feelings over it be reflected in what is supposed to be neutral reporting about Wikipedia, not a place for you to try and fight back against those who are demonizing you on WPO. Regardless, I would say this is otherwise a fairly decent summation of a whole lot of arb business and I'm glad to see arbitration reporting return to the Signpost. Just Step Sideways ^{from this world ..... today} 21:34, 16 May 2024 (UTC)
in fairness, he only called it a "badsite" twice in one sentence of the final paragraph of a very long article ... sawyer * he/they * talk 22:03, 16 May 2024 (UTC)
In further fairness, saying a website that stokes stalking and harassment isn't so good of a site (perhaps, even, a 'bad site') doesn't seem all that partisan a take. Hydrangeans (she/her | talk | edits) 21:27, 17 May 2024 (UTC)

Forsooth -- one begins to suspect that perhaps my linking to the WP:BADSITES proposal may not have been intended as a direct endorsement of the essay and all it contains, or yet perhapser indeed that it's a tongue-in-cheek reference to the ubiqitous Wikipedia obsession with Voldemort-like circumlocution on the name of a website notable enough that we have a mainspace article about it. Perhaps this is even a more-likely explanation than me being so impotently blown away by the towering intellect of the website that I've been reduced to inchoate paraoxysms of befuddled rage. At any rate, since when does some guy posting your real name on a website mean you're bound by a permanent nondisparagement clause? I don't remember that on the user signup form... jp×g 🗯️ 08:39, 18 May 2024 (UTC)
"Jacob Gotts aka JPxG: liar or braindead?" #WhyNotBoth? FeRDNYC (talk) 08:54, 18 May 2024 (UTC)
Aaaaand another thanks from me. Crunchydillpickle🥒 (talk) 22:05, 16 May 2024 (UTC)
I guess one could apply to Wikipedia an old saying about academe: the fights are so vicious because the stakes are so low. At least the same reasons exist in both worlds. -- llywrch (talk) 23:15, 16 May 2024 (UTC)
Thanks for the report, the soap opera Cliff-notes approach was entertaining and your prose were excellent. See ya in the pit! —tim /// Carrite (talk) 23:18, 16 May 2024 (UTC)
Delightful and informative. At times I felt like a ghoul chortling over slasher movies and airliner crash investigation reports. Jim.henderson (talk) 01:33, 17 May 2024 (UTC)
Apparently the half-dozen desysops for cause covered by this story aren't enough to satisfy the community – the biggest thing to come out of requests-for-sysop reform will be a new requests-for-desysop process, which will only accelerate the rate of decline of administrators. – wbm1058 (talk) 03:25, 17 May 2024 (UTC)
Re: the SmallCats case - is this diff link correct? The link is presented as something inexplicable, but on clicking it all I see is some standard copy editing. — Mr. Stradivarius ^{♪ talk ♪} 15:39, 17 May 2024 (UTC)
i was wondering about that too! ... sawyer * he/they * talk 17:29, 17 May 2024 (UTC)
The year 2007 in the original diff link is telling – by simply adding a 1 at the start (that is, by adding one billion to the ID) we get what was meant: Special:Diff/1167933153. —⁠andrybak (talk) 19:13, 23 May 2024 (UTC)

Indeed and forsooth. I was quite confused by this error myself. I think I do need to write a script to autoconvert diff links... jp×g 🗯️ 05:35, 27 May 2024 (UTC)

JPxG, there are User:Enterprisey/diff-permalink and User:Enterprisey/diff-permalink-2 for doing the conversion during browsing. —⁠andrybak (talk) 05:57, 27 May 2024 (UTC)

I'll join the chorus here and say this was well done. ~~ Jessintime (talk) 20:58, 17 May 2024 (UTC)
I'm suddenly reminded of the Parks & Recreation atrocities map. (Leslie Knope, standing in front of a map of Pawnee in blue, with 10 or so white dots scattered throughout the town:)
This is a map of all the atrocities the Pawnee settlers inflicted upon the Wamapoke Indians. ... ... ...The atrocities are in blue.
FeRDNYC (talk) 06:03, 18 May 2024 (UTC)
Can I just say, I love the idea that there's such a thing as the Wikimedia Foundation's disinformation team, and I firmly choose to believe that said team does exactly what it says on the tin: Seeds out disinformation regarding the Wikimedia Foundation among the larger community. I mean, it tracks! FeRDNYC (talk) 08:39, 18 May 2024 (UTC)

Comix: Generations (19,897 bytes · 💬)

Here's what syscourse means in case balding cane-using Wikipedians with low-riding pants are wondering. Randy Kryn (talk) 12:42, 16 May 2024 (UTC)

this isn't funny, and if it's trying to make a point, i don't know what it is. ltb d l (talk) 13:26, 16 May 2024 (UTC)

The point is obvious, silly: Ancient Wikipedians with abnormally short legs are stupid. Randy Kryn (talk) 13:38, 16 May 2024 (UTC)
It's slightly funny, until you read the comments. Then it's funny. I can identify with either icon or both or neither, or either neither or both or neither either nor both. All the best: Rich Farmbrough 20:52, 21 May 2024 (UTC).

This feels like a mangling of interesting aspects of Wikipedia. I feel like there's two things here: queer youths (which I would count myself among) versus old professors is one of them. I think minimizing the spectrum between these different types of people and the amazing way they work together is a shame. The other is Wikipedia bureaucrats versus externally expert writers. Quoting Wikipedia policies at people in a smug way sucks! It's interesting that the sticking point here is a bad source that is relatively recent, it's hard to know what to really make of that, for me. Anyway, I'm sorry if Generalissima feels alienated by us youths with our neopronouns and syscourse :/ I hope we can figure out together how to replace Smith (2018) with a better source. ~Maplestrip/Mable (chat) 14:23, 16 May 2024 (UTC)

Is this the Wikipedia equivalent of a "phone bad i hate my wife" boomer comic?DogsRNice (talk) 14:49, 16 May 2024 (UTC)
IDK; it very likely isn't a "queer bad" comic, as the artist is a lesbian. Maplestrip's points on collaboration still stand though. Firestar464 (talk) 15:26, 16 May 2024 (UTC)

@Maplestrip: I wish my user signature made it on to this post; I am a nonbinary neo-pronoun using system. my message here is not that these things are bad, but rather that wikipedia is comprised of, primarily, very young people and very old people, who are coming from very different cultural contexts Generalissima (talk) (it/she) 16:35, 16 May 2024 (UTC)

Fair enough, weird that I got the exact opposite vibe from this cartoon. Keep drawing and making cartoons :) ~Maplestrip/Mable (chat) 18:24, 16 May 2024 (UTC)

@Maplestrip: Did you mean Wikipedia:bureaucrats when you said "Wikipedia bureaucrats" because my mental image of myself is closer to the old guy with a cane and I'm still one of our newest Bureaucrats; as a group we skew strongly to people who've been on this site for over 15 years....... Ϣere SpielChequers 16:33, 21 May 2024 (UTC)

@WereSpielChequers I read it to mean the "people who enforce/encourage/promote/like the bureaucracy" as in WP:NOTBURO/WP:BURO. An "expert writer" might be an expert in their own field, but be clueless with regard to hundreds and hundreds of Wikipedia:Policies and guidelines. —⁠andrybak (talk) 17:12, 21 May 2024 (UTC)

@WereSpielChequers: Andrybak's interpretation indeed aligns with my intention; it was a reference to WP:BURO. The connection isn't very strong here tho (only the Manual of Style is mentioned), the cartoon just brought this to mind. ~Maplestrip/Mable (chat) 06:33, 22 May 2024 (UTC)

Speaking as a balding middle-aged nonbinary queer who didn't know what syscourse meant until reading the above comment, I didn't find comic this particularly funny. But seeing the author's bio I figure it's not intentionally harsh, just maybe misguided and probably too obscure for a general Wikipedia audience. Funcrunch (talk) 16:31, 16 May 2024 (UTC)

Personally speaking –I am on The Signpost editorial team, but didn't see the comic prior to publication – it's curious to me that we as a community pick and choose sensitivities so finely. There's a discussion in the current issue about transphobia, which is great (the discussion, I mean), but also a comic that depicts a doofus as someone using a cane. Not a great look, as far as I'm concerned, no matter what identities the author portrays. ☆ Bri (talk) 16:39, 16 May 2024 (UTC)

How are they are a doofus? Generalissima (talk) (it/she) 16:42, 16 May 2024 (UTC)

Isn't the point of the comic that they're being lectured at by a younger person who's "hip" to the WP TLAs, and literally pointing a finger at them? ☆ Bri (talk) 16:45, 16 May 2024 (UTC)

It's supposed to portray both sides seem out of touch with the other. Generalissima (talk) (it/she) 16:49, 16 May 2024 (UTC)

The conversation here is certainly bearing that out, given what people have revealed about themselves. However a) I'm not sure it's funny and b) I still hold that our sensitivities are oddly selective. Nobody's being taken to Arbcom for ageism, and that's good, but still, inconsistent with past reactions to The Signpost humor. ☆ Bri (talk) 17:36, 16 May 2024 (UTC)

Maybe we need a Wikipedia:No ageism essay. Some1 (talk) 23:46, 16 May 2024 (UTC)

I think they're both doofuses because they both hang out on this doofus website 🤔 jp×g 🗯️ 22:45, 16 May 2024 (UTC)

If someone had told me that this was AI-generated, the result of a request to 'make a cartoon about Wikipedia', I'd probably have believed them. It entirely fails to exhibit actual humour. AndyTheGrump (talk) 16:47, 16 May 2024 (UTC)

For what it's worth, before realizing that Generalissima had created this comic and that self-attacking is unlikely, my impression was that this was supposed to be an unkind jab at folks in the plural community. While I'm not someone who got a PhD when Jimmy Carter was president, deeply reading history means I'm familiar with the work of and respect a lot of people who do (numerous of my favorite books were written by people who look a bit like the gentleman in the comic). Perhaps this comic is something of an unintentional Rorschach test: what rib one sees (is it teasing both characters? teasing just one?) reveals less about the comic than the reader.
As for the seeming/possibly implied comparison/contrast appearing in the comments of the current reader response to the negative reader reaction to a past Signpost attempt at humor that was transphobic, I think the difference is that even if someone thinks being an older man with a PhD makes one a 'doofus' (which I think Generalissima has in these comments made clear she doesn't believe, and which as my comment explains is not the initial read I got from the comic, though my read was still not in alignment with Generalissima's intent), being an older man with a PhD is generally a position of relative socioeconomic power (this often means having a stable job, for example, since back in the twentieth century [when the Carter presidency was] the PhD-to-academic-job path was a lot more dependable than today's more-PhDs-than-job-openings situation; perhaps also being published and therefore having a legacy that will outlive the self). Punching down at trans people is punching down at a population systematically rendered by widespread discrimination more likely to suffer and even die, in some places/circumstances without memorial or recognition. Being thought of as stuffy is likely annoying for an older professor but isn't nearly as existentially threatening. Perhaps that accounts for the differential reactions. Hydrangeans (she/her | talk | edits) 19:04, 16 May 2024 (UTC)
since back in the twentieth century [when the Carter presidency was] the PhD-to-academic-job path was a lot more dependable than today's more-PhDs-than-job-openings situation

Not sure that's true! I remember reading a lot about this, and how many people fled academia in the mid to late 1970s because they couldn't find jobs with their PhD in the US. See also this. Viriditas (talk) 09:03, 17 May 2024 (UTC)
It's almost reassuring(?) in a somewhat macabre way that It's Always Been Bad, Actually... (or, rather, that the academic jobs crisis has been happening for over fifty years and not just since the Great Recession—interesting.) Hydrangeans (she/her | talk | edits) 09:31, 17 May 2024 (UTC)

Yeah, I never worked in my PhD field. In a year-and-a-half (starting in 1973) looking for a job in academia (in the US and in Puerto Rico), I got just one interview. That was a time when departments in my field were not hiring, or were actually shrinking, and some smaller schools were closing. That was one of the by-products of what the Vietnam War did to the economy. Donald Albury 14:11, 17 May 2024 (UTC)
Maybe another factor was that there were a lot of Vietnam veterans like me in school on the GI bill. That and all of the guys deferring the draft by staying in school. The schools were quite happy to have us paying tuition for degrees in fields that were getting over-crowded. Donald Albury 14:18, 17 May 2024 (UTC)
Don't forget what happened when the Moon program wound down! Far too many people with hard science PhDs to find jobs. IIRC, some of these people ended up working in the defense industry in the 1980s, while others went on to become founders in Silicon Valley tech companies. NYT covered this in 1970.[1] Viriditas (talk) 19:36, 17 May 2024 (UTC)
Well, all I can say is that I completed my PhD while Ford was president, so I guess I am really old. I hadn't heard of syscourse before, but I'm always happy to learn something new. But then, editing WP means I have to learn six new things every day before breakfast. Donald Albury 19:31, 16 May 2024 (UTC)
Odd. I am almost always the biggest grump in the room, and ... almost always need comics explained to me, and ... MUCH closer to the dude on the right, and ... it seems harmless, even mildly amusing, and my first interpretation was what Generalissima said they were going for. In a way, I think drawing something that a boomer understands should probably worry Generalissima a little bit. --Floquenbeam (talk) 19:36, 16 May 2024 (UTC)

The "Previous Comix" button leads me to the Comix before the Comix before previous Comix and then, when I get to the actual previous Comix, the "Next Comix" button seems to be absent there. Strange, isn't it? _WADroughtOfVowels^P 18:49, 16 May 2024 (UTC)

@ADroughtOfVowels, the previous comix link was fixed in Special:Diff/1224224289. Some of the previous/next links are missing, because the Comix was published in three different columns over the years: Comix (as this edition's), CommonsComix, and Humour. —⁠andrybak (talk) 20:58, 19 May 2024 (UTC)

looking at some of these comments without looking at the actual comic (or the context of the author, who i diclose is my friend), you'd think this was some kind of egregiously offensive jab at both plural queer zoomers and at old white men... i think that says more about the jumpiness of the community than it does about the comic ... sawyer * he/they * talk 20:33, 16 May 2024 (UTC)

I think maybe its because its hard to identify what the "joke" is, and people assume that if they don't get the joke they are probably the but of it. Bawolff (talk) 21:07, 16 May 2024 (UTC)

TIL we don’t have an encyclopedia article on Boomer humor. Also, I learned that only 16% of seniors use canes, which seems unusually low. For me, comedy that focuses on generational warfare is very low-hanging fruit, and should probably be avoided if it isn’t done with exceptional care. "Kids these days" comics are rarely funny across the board, but some people like Gary Larson managed to reinvent the idea by using young and old animals, often extinct species, to further heighten the absurdity. I think that kind of extreme take is what is missing here. Recently, some younger people have dismissed Larson as an example of Boomer humor, and I think that might be true for some of his panels, but Larson did manage to reinvent the genre in a unique way that appealed to many different generations. Perhaps if the Carter-era professor was also promoting an idea unique to his older generation in the 1970s it would have some comedic parity, and for me, that would be funny. Part of the problem is that you are giving the appearance of punching down at the younger generation who have not had as many opportunities as the older generation and have had to struggle and come into their own in an altogether unique way. This aspect is covered in some detail in our article on theories of humor. It can be difficult for some people of certain political affiliations to understand how this works. Viriditas (talk) 03:14, 17 May 2024 (UTC)

Good points all. My initial defense-of-older-Wikipedians above may be too harsh, and from reading this discussion it seems that the cartoon has served the principled purpose of creating dialogue. The youngster with the book pointing at the frowning geezer with a cane does create a wellsource test, we get what we get out of the cartoon. But by bringing whatever it brings to each reader it sets up a better understanding of the full community. I've read elsewhere that the photograph from the Toronto Wikiconference shows lots of people that look like your grandparents (that was written off-site, and not in a complimentary way). But looking at it from just a touch outside the box, what a great thing we have built! Members of all generations of many nations collabing! Has this ever occurred before in human history? Probably not, and that seems the important takeaway. And at least the cartoonist made him a professor, as one of the greatest groups of untapped potential editors are retired professors, active residents of nursing homes, and why we need a Wikipedian-in-residence in that huge Florida retirement community whose name slips my mind. Randy Kryn (talk) 03:17, 17 May 2024 (UTC)

The bottom line is that ageism is and has been a huge problem, and it’s often swept under the rug. It’s such a huge problem in the modern job market right now that there’s a burgeoning industry based on hiding your age from recruiters in internet searches. There’s also the loss of institutional memory that goes missing each year with older workers leaving or being pushed out of the job market. On the other side of the equation, there’s a high barrier to entry for younger people in some fields that’s almost impossible for them to break into, and this has come at the expense of higher education in countries where the younger generation cannot afford it anymore. My personal experience is that each brings something to the table that the other can use; the younger people bring fresh ideas and a willingness to experiment, while the older people bring experience and accumulated knowledge from many years that they can draw from so the younger people don’t have to reinvent the wheel. Within all of this, there is a great opportunity for humor, we just have to be able to see it. Viriditas (talk) 03:26, 17 May 2024 (UTC)

Ageism doesn't seem to be a problem on Wikipedia, unless I'm missing it. The cartoon is about Wikipedia, not society in general. Randy Kryn (talk) 03:35, 17 May 2024 (UTC)

We might be using the terms differently. The trope of "Kids these days" depends on negative stereotypes of younger people. Also, ageism is one of the most common discriminatory attitudes in social discourse, with almost all of our interactions depending on some elements of it. You have a point that ageism is far less prevalent in faceless, virtual collaborative workspaces, but it still shows up if you look for it. This particular comic depends on it in various ways. Perhaps I am overly sensitive to it as I’m always on the lookout for it. Viriditas (talk) 03:49, 17 May 2024 (UTC)

I literally did not know what syscourse meant until I came across this, no joke. Coming from someone who edits NETPOP-related articles, BTW. 🌙Eclipse ^(talk) ^(contribs) 00:34, 25 May 2024 (UTC)

In the media: Deadnames on the French Wikipedia, and a duel between Russian wikis (13,249 bytes · 💬)

Russia

Seems Russia can't decide what to do about its Wikipedia problem. Block the real one, as Turkey blocked the Turkish one for years? Fork it so the obedient domestic Russians can de-Nazify it without any nasty overseas Russian speakers interfering? Make a user-edited (domestic users only) branch of Great Russian Encyclopedia? I don't see that they have thought the Chinese method might be workable: Encourage loyal corporate entrepreneurs to prosper in the encyclopedia business, protected from foreign competition by blocking all Wikipedias and their mirrors. Jim.henderson (talk) 06:21, 17 May 2024 (UTC)
It's sad to see the Signpost perpetuating the hoax that "[Russian Wikipedia] articles on the Russian invasion of Ukraine... [were]... originally written by Ukrainians". After a balanced description of the diverse editors of the Russian Wikipedia, which come from all over the world, why is there a sudden support of Russian propaganda?

I think while writing on sensitive topics like this the authors should fact check first, write later.--Victoria (talk) 14:14, 17 May 2024 (UTC)

You made an error inserting [were]: that passage is a hypothetical future concerning their domestic government-approved Ruwiki, not a factual statement about the way our own Russian Wikipedia evolved. ☆ Bri (talk) 14:19, 17 May 2024 (UTC)

@Victoria: Thanks for the feedback, I honestly did not know. I apologize for the errors even as I am still learning what to say that would be correct. If you or anyone else would like to propose a precise correction, then The Signpost can include it. I was not one of the authors here, but I am an editor, and I wanted to respond to you.

About the reporting on Russian Wikipedia - This is challenging for us to report, and I am glad that we reported enough to get comments to advance the conversation. Here is some feedback that I heard: There is a Russian Wikipedia editing community, they do good editing and include many diverse perspectives, and they are proud of Russian language Wikipedia's quality and scope of content. This is commendable. Russian Wikipedia editors have good control over Russian Wikipedia, and saying otherwise without evidence and stating ways to improve things is defeatist and misguided. I apologize for my own part in failing to communicate this.
About the Signpost - Publishing stories which need correction is better than not having a newsletter at all, and I hope the day comes when the Wikimedia Movement incorporates development of community reporting about issues like this into its strategic planning. This is a volunteer publication with no budget. Anyone who reads the Signpost is a user who is able to contribute to its reporting, including for fact-checking. All the people in the world who wished to discuss this topic in The Signpost showed up to share their views, and all of them are also welcome to submit corrective and improved reporting in the next issue. I asked some people for submissions and will see what happens. Thanks. Bluerasberry (talk) 15:31, 17 May 2024 (UTC)

@Bluerasberry: Thank you for the reply.
The original passage: "Ruviki doesn't have enough of its own editors to keep up with 1.9 million articles, so its articles on the Russian invasion of Ukraine will likely be originally written by Ukrainians, and then heavily censored by...". Replace with "Ruviki doesn't have enough of its own editors to keep up with 1.9 million articles, so its articles on the Russian invasion of Ukraine will likely be originally written by the editors outside Russia, and then heavily censored by...". As you see, a small but significant distinction.--Victoria (talk) 09:38, 21 May 2024 (UTC)
Not even that. There are articles (on the Ukrainian war as well as other subjects over which current Russian authorities try to exercise exclusive control) that were created or heavily edited by editors from Russia with views significantly differing from the party line. There are enough people in Russia who don't like the direction in which their authorities steer the country, and I wouldn't be surprised if they are actually overrepresented in the Russian Wikipedia community compared to the overall demographic. So I understand what Smallbones wanted to say and what you want to say but I think the "undesirable" pool of editors is even wider. Deinocheirus (talk) 19:24, 24 May 2024 (UTC)

There is a Meta link on the topic: m:Requests for comment/Hiding the number of Russian/Belorussian/Kazakh contributors on the statistics map (also see the Dark theme that is now implemented on Meta). --ssr (talk) 13:03, 28 May 2024 (UTC)

(←) Hello @Victoria:. I'm sorry, I had no intention of contributing in any way to the Russian government's propaganda against the real Russian Wikipedia. I think you did misread the one sentence you partially quoted. I'll add some parenthetical comments here to clarify what I was trying to say: "(Ruviki's) articles on the Russian invasion of Ukraine will likely be originally written by Ukrainians (after VPNs are shutoff by the Russian government), and then heavily censored by bots (at the Ruviki fork)..." This doesn't mean that the WMF or the CIA or whoever are stopping Russian residents from contributing to the real Russian Wikipedia, rather it just states the obvious - that the Russian government will be stopping Rusian residents from doing so if they block both Wikipedia and VPNs. The Russian government can only blame themselves. If Ruviki takes the further step of censoring the real Wikipedia article, the Ruviki article will likely be unacceptable to everybody.

I also need to say that having such a distinguished Wikipedian comment on something I wrote as a special experience. In the last 5 years, starting with a short piece on the Great Russian Encyclopedia (preparing to take over the real Russian Wikipedia's place on the Russian internet), The Signpost has published over 2 dozen articles or shorter pieces on the Russian Wikipedia, most of which I've written or edited. My favorite is The oligarchs' socks. So you are an expert on Wikipedia and on Russia. Taken as a whole, how has our coverage of this topic been? We might want to continue this conversation via e-mail. Sincerely,

Smallbones_(smalltalk) 03:55, 18 May 2024 (UTC)

Hello @Smallbones:,

I don't think I misunderstood you, as in this reply you reiterate the problem: you think that the articles about Russian-Ukrainian war are written by the Russians and Ukrainians and removing the Russian residents by VPN blocking will mean that "the Ukrainians" will write the articles.

People who edit Russian Wikipedia - including the articles about the war - are much more diverse than Russian/Ukrainians as they include the editors from the former 14 USSR republics, which are now independent countries, plus former Eastern Block countries and very large diasporas in the US, Germany and Israel (10% of Israelis are Russian-speaking), recently swelled by the exodus of hundreds of thousands of supporting democracy Russians. Take me as a case in point - I'm originally from Belarus (one of the former USSR parts), I live in the UK - in no way I'm either Russian or Ukraininan, while my ho0me wiki is Russian Wikipedia.

The other point you are missing is that recently the number of Ukrainian readers of Ukraininan Wikipedia overtaken the number of Ukrainian readers of Russian Wikipedia. Concurrently, I saw a number of prominent Ukraininan-speaking Russian Wikipedia editors who switched from editing Russian to editing the Ukrainian Wikipedia after the start of the war. All this makes your statement that "articles on the Russian invasion of Ukraine will likely be originally written by Ukrainians" very unlikely.

I'm flattered to be called a "distinguished editor" - it's a first, thank you. Thank you for making the wider community aware about what is happening in the Russian-speaking wikimedia movement I'd be happy to continue our discussion in the e-mail. Victoria (talk) 09:54, 21 May 2024 (UTC)

"retooted"

Re Jim.henderson in Special:Diff/1224253099: On Twitter people "tweet" and "retweet". On Mastodon people "toot" and "retoot". Anomie ⚔ 10:51, 17 May 2024 (UTC)

Forsooth. jp×g 🗯️ 07:31, 19 May 2024 (UTC)

frwiki and no queerphobes

I'd like to note broader thematic connections between the frwiki poll and the WP:NOQUEERPHOBES discussion.

As mentioned in the article, there were sanctions levied against editors for canvassing. In the case of Srinka, she posted a notification on Mastodon asking those eligible to vote to do so. Editors noted that the Mastodon instance the notification was posted to was explicitly queer-friendly, which some believed made it inherently partisan - so it was unjustifiable to notify it and ask eligible editors to participate. This all regards a public statement, that a poll was going on in frwiki, outside of frwiki.

What is not mentioned in the article is the charges of canvassing at the MFD and DRV for WP:NOQUEERPHOBES, the latter being opened explicitly on the charge that canvassing had distorted the discussion, In particular the notification of the LGBT noticeboard by Your Friendly Neighborhood Sociologist. The DRV nomination stating While arguably within a strict reading of guidelines [ WP:APPNOTE ], it still had the effect of prejudicing the discussion. ... my position is that you cannot have a fair discussion and an accurate reading of community consensus when there have been notifications made to editors and forums that as a matter of commonsense are going to disproportionately generate support for one side of a discussion/debate.

French Wikipedia discussed whether a public explicitly LGBT friendly (as opposed to LGBT antagonistic or just explicitly indifferent I guess?) Mastodon instance was an appropriate place to notify; Here, a vocal minority tried to discuss whether the noticeboard of our own LGBT Studies WikiProject was (with the obvious answer being "yes"). @Trystan:, you commented in the discussion that Suggestions that notifying WP:LGBT on LGBT issues inherently constitutes canvassing? Almost makes me feel nostalgic for the early 2010s when that issue was settled. - I'd love if you could provide a bit more historical context! Your Friendly Neighborhood Sociologist ⚧ Ⓐ (talk) 16:36, 17 May 2024 (UTC)

I had in mind two related issues. The first was establishing consensus that WP:LGBT (starting out as the WP:LGBT notice board) could exist as a subject-based forum for editors interested in LGBT topics. The second was a series of debates circa 2010-2012 (eg, eg) establishing that WP:LGBT can tag articles of interest, in order to be notified of discussions on those articles.--Trystan (talk) 18:11, 17 May 2024 (UTC)

“For people who met the pre-transition notoriety criteria, the results of this poll were largely in favor of including pre-transition names at the top, and a larger majority agreed that they should be mentioned in the body". This is a fact: the results were such and such. And now, some people are using some French media to publish their disappointment at not having won the vote... and are trying to enforce a reversal of the result. It is not certain that such a way of proceeding will convince the dissenting majority! Pldx1 (talk) 16:52, 29 May 2024 (UTC)

News and notes: Democracy in action: multiple elections (10,778 bytes · 💬)

Wikimedia Foundation 2022–2023 reports

The WMF Annual Report has now been added to the Financial reports page. See notification in the Signpost Newsroom. The new Form 990 is now up as well and can be viewed here. --Andreas JN 466 11:52, 16 May 2024 (UTC)

I guess the article is correct in calling out that the report is not super detailed about what the work in the various expense categories consisted of. But in that, it is not all that different from previous WMF annual reports and indeed from the annual reports of many other US nonprofits. They generally are more focused on storytelling and on selectively highlighting some work areas where attractive progress can be presented - rather than on comprehensive, detailed accountability about the work done by every major department, whether goals were reached or not etc. This is to be expected, as a main audience of these reports is donors and there is also an impetus to keep this kind of document reasonably legible and engaging. (Although one could ask whether the Wikimedia Foundations has followed the National Council of Nonprofit's recommendation to "Be honest and acknowledge both the highs and the lows" in this report - I haven't read it fully myself yet, but perhaps Andreas has an opinion.)

What is different about the Foundation's 2022-23 annual report is that this was the first fiscal year since 2007 where this glossy donor-focused report was not complemented by regular quarterly or monthly activity reports. The Foundation had been publishing such regular updates since 2008, first as monthly and quarterly reports, then in form of slide decks from department-wise quarterly check-ins or "Tuning sessions". This was the place you could go to if you wanted to know what a particular WMF department's main work focus areas were in a particular timespan and what progress they made on their goals from the WMF annual plan (say, the Advancement team in January-March 2022). These updates have also been a source of reporting for the Signpost, and informed various community discussion. In short, they were an important accountability tool.

These regular public department-wise activity reports that WMF had been maintaining since 2008 were discontinued in 2022 (as Andreas himself pointed out at the time), a few months after Maryana Iskander became CEO in January 2022. (There was a "End of year report 2022" which still had some of this kind of per-department information, although in form of less detailed "highlights" and for the entire 2021-22 fiscal year. In 2023, even this kind of annual activity report appears to have been no longer published, at least it is not listed here - CCing NGunasena (WMF) and RAdimer-WMF to confirm, as they published the 2022 version.)

In short, under its current CEO the Wikimedia Foundation has become notably less transparent about how it actually spends its budget, compared to the tenures of the preceding three CEOs/executive directors in the one and a half decades prior.

Regards, HaeB (talk) 13:40, 16 May 2024 (UTC)

Hi HaeB. The Foundation really is trying to share details about how our work is progressing and about how funds are being allotted and used (more info below). We appreciate your feedback in making this more visible to those who are looking for it.

In FY 2022-23, we published several updates by region - Africa (also available in fr and sw), North America, LAC (also available in es and pt), ESEAP (also available in id and ja), South Asia (also available in hi and bn), North and Western Europe, MENA (also available in ar, de, and fr), CEE and Central Asia and a discussion of the regional focus.

So far this FY, we've published our Q1 progress report on Diff (Q2 coming soon) and a snapshot of highlights in our draft 2024-2025 annual plan. We submitted the progress report to the Signpost to share this with more Wikimedians. You can follow updates, and quarterly metrics reports, on the 2023-2024 annual plan reports page.

At present, four Foundation-submitted posts are awaiting a response on the Signpost submissions page. The oldest, which was submitted in January, directly discusses work we've done on our Annual Plan goals. Other waiting posts discuss PageTriage updates, Wishlist updates, and the recently-published Form 990.

Maryana has regularly shared updates to Wikimedia communities. Through the Talking:2024 project earlier this year, Foundation leadership hosted 130 conversations with community members to learn about their needs and share Foundation progress and plans. You can read about one such meeting in the Signpost. And in March, we launched a new Wikimedia Foundation page on Meta-Wiki, with updated links to resources, reports, and contact information. NGunasena (WMF) (talk) 22:02, 17 May 2024 (UTC)

We want hard numbers. We'd like it all presented in one place with accurately-titled breakdowns all the way to the bottom, not couched in the usual vague nonprofit-speak. That's all we're asking for. We don't want to have to attend a ton of Google Meets and Zoom calls and piece together the information bit by bit. I don't attend WMF calls because I have very little free time that coincides with them, and I (and many others like me, I'm sure) would prefer to have everything written down in a single document which can be referred to at any time. Wilhelm Tell DCCXLVI (^{talk to me!}/_{my edits}) 13:38, 18 May 2024 (UTC)

I just want to say, that acknowledging my RfA was kinda okay. I haven't witnessed how my RfA was closed with a "not now" by an experienced fellow (The recent archive may explain). Going off topic here, I wanted to explain my story. The day I started the RfA, I was expecting positive comments to be made, but in the end, things got a lot worse, with much criticism from many, I then felt that the community does not want me to be a sysop, and the community "hates" me. I was stressed, frustrated, feeling that the community were flogging me to death. I had expressed pain, it was so painful that I wanted to share a rather sad story. The purpose of the story was to raise awareness of the pain I received, and that I would expect them to forgive me. I was so stressed, watching my talk page's history, entry after entry, after which I gave up on seeing the Wikipedia. It caused me a trauma, it was a nightmare for me, and so I never opened Wikipedia the next day, and on that day I refocused on the criticism; I was calming down, forgetting the pain, drank a lot of water, moved a lot, and layed in bed. My soul was telling me to withdraw, but I couldn't, fearing the many messages that would come up to my talk page. My soul was like "Go withdraw now", but I was like "I couldn't". The next day, I was prompted to return to Wikipedia after reading an article while in incognito mode. I've returned back and was greeted by 39 pending notifications, the majority were on my talk page alone, and saw people chatting there. However, I've ran straight to the talk page and immediately made a comment for withdrawal, without reading the content. But soon after, I read the content and was shocked by two DRVs and a critical question from an admin. I was also impressed by the not now closure, and didn't realized so. I was feeling in danger, but after reading the positive comments, I've cooled down. I will agree with a The Signpost interview, and I will accept any comments below or elsewhere. Toadette^Edit! 23:52, 16 May 2024 (UTC)

Op-Ed: Wikidata to split as sheer volume of information overloads infrastructure (28,196 bytes · 💬)

I am amazed that a major Wikimedia porject is about to fail, and this is the first we have heard of it. Scaling databases is not a new science, the principles have been known for decades, I am certain there is a technical solution for this, and I haven't even looked at the "Limits" page yet. All the best: Rich Farmbrough 11:11, 16 May 2024 (UTC).

P.S. the link https://www.wikidata.org/wiki/WikiProject:Limits_of_Wikidata doesn't work.

I'll check back later. All the best: Rich Farmbrough 11:14, 16 May 2024 (UTC).

@Rich Farmbrough: Good catch -- fixed. Thanks! jp×g 🗯️ 11:28, 16 May 2024 (UTC)

well its not something that most people have a good grasp on, so only once you really start hitting the limits, it becomes more interesting for people who don’r really care about the details. Its also not uncommon, it’s just that usually people are able to find better solutions in the nick of time and most outsiders don't even realized something changed. Reminder that all of wmf was once one database server, and one rack in one datacenter, and that we ran without multimedia backups for over 15 years. In reality, most wmf projects have existential (technical) crises on a almost continual basis and hardly anyone notices (see also the major pagelinks db table normalizations, going on right now). —TheDJ (talk • contribs) 14:34, 16 May 2024 (UTC)

One problem is that Blazegraph in terms of development is somewhat in dead in the water as Amazon silently hired Blazegraph developers to develop the closed source Amazon Neptune service. However, Qlever could be a valid alternative for Blazegraph if it will scale high enough. --Zache (talk) 16:50, 16 May 2024 (UTC)

WMF does have money. They could hire a team to revive blazegraph development. We can't always rely on the open source world to provide us with software, sometimes we have to make it ourselves. To be clear, this is an expensive option. DB developers are much more expensive than php web dev. Trade offs would probably have to be made. Like all things in life it comes down to deciding what is important.Bawolff (talk) 17:35, 16 May 2024 (UTC)

Scaling RDF databases is a pretty different ballgame then scaling relational databases. I would consider scaling SPARQL based databases to very much be an open research problem. That doesn't mean there are no solutions, but they are full of trade-offs, and often look like doing the exact same thing (partitioning the graph) with some front end to keep the queries the same. Bawolff (talk) 17:33, 16 May 2024 (UTC)

I operate my own copy of the Wikidata Query Service that continues to provide a unified graph. If you do not have time to rewrite your queries to use the split graph, you should be able to run queries on my query service. I will continue operating this unified graph until it is literally no longer possible. Please reach out by email if you are interested in using this. Harej (talk) 21:41, 16 May 2024 (UTC)

@Harej: Technical question. How do you keep it in sync with wikidata changes? (ie. is it near realtime, is there periodical updates etc) I think that keeping it sync is biggest unsolved issue if one has its own replica. --Zache (talk) 23:52, 16 May 2024 (UTC)

Zache, syncing is not an unsolved issue if you use Blazegraph. The Wikimedia Foundation has developed tools to synchronize Wikibase instances, including Wikidata, via Recent Changes. So my query service keeps up more or less with real time. Harej (talk) 05:03, 20 May 2024 (UTC)

Didn't realize Wikipedia has now (or will soon have) had Wikidata for longer than it didn't. Nardog (talk) 23:44, 16 May 2024 (UTC)

Bad idea when I first heard about this option at Wikimania Capetown, still a bad idea now. I support this as a WikiCite editor - well, I'm a WikiCite editor, and I don't support this. The truths about Wikidata's quite genuine "big data" issues need to be addressed, for sure. Scholia, as a front end, surely also is a different matter from these back end questions. (That is not to discuss funding, which obviously is a point.) I was struck at WikidataCon 2019, where much was said about federation, how little of it made sense from a technical point of view. As someone who puts time into "main subject" and "author disambiguation" questions for article items, I see the direct link into Wikipedias and other sites from the subject and author items as fundamental. The Capetown advocacy was solely in terms of convenience to bot operators, which I would say was a blinkered outlook. Charles Matthews (talk) 04:21, 17 May 2024 (UTC)

Oh, and I note that the feedback period for comment ended the day before the publication of this article. Charles Matthews (talk) 07:17, 19 May 2024 (UTC)

Scholia usage volume

Scholia, a scholarly profiling service serving this content 100,000 times a day - what is the source for this number, and does it distinguish between human users and automated traffic? (It matched the 2018 stats here, but that publication explicitly warned that it "cannot be used to draw any conclusions other than that usage grows [as of 2018]. Multiple contributing factors seem likely, including web crawlers, generic growth of Wikidata and WikiCite content, increased interlinking both within Wikidata and between Wikidata and other websites, especially Wikimedia projects, as well as WikiCite or Wikidata outreach activities, which often feature Scholia prominently"). Regards, HaeB (talk) 06:30, 17 May 2024 (UTC)

@HaeB: The source is https://toolviews.toolforge.org/ which is a Wikimedia platform service. Like so many of our fundamentals, documentation is lacking, but based on rumor that service has same specifications for reporting a view as wikitech:Tool:Pageviews, which is how we report Wikipedia traffic to the world and which we consider reliable. The narrative for both pageviews and toolviews is that the Wikimedia platform reports web traffic in the way standard to the field, so regardless of bot/human ratio, our reporting should be comparable to anyone else reporting any other web platform traffic. Bluerasberry (talk) 18:09, 17 May 2024 (UTC)

Thanks, that's helpful. Some quick observations:

based on rumor that service has same specifications for reporting a view as wikitech:Tool:Pageviews - from a quick look at the code (good point about documentation btw), that does not appear to be the case, as Toolviews does not use the same pageview definition. In particular, regarding my question above, it does not seem to attempt to detect automated traffic. (Which does not mean it is unreliable per se - it does what it does - just that the conclusions we can draw from this data are limited, as warned about by the authors of that 2018 paper, which included yourself.)
so regardless of bot/human ratio, our reporting should be comparable to anyone else reporting any other web platform traffic - that doesn't seem to be true. Bot pageviews are usually excluded from web traffic reporting. That's also the default setting in the Pageviews tool (in views like [2] you have to change the setting under "Agent" to include "Spider" and "Automated" views alongside human/"User" views; their FAQ has more on the distinction.)
One way to get closer to an answer to the question of how much human usage Scholia actually sees might be the unique daily visitor counts whose existence the Toolviews API documentation advertises. Unfortunately though they seem to be broken (the API claims 0 visitors for Scholia and all other tools for recent dates; and tt turns out that MusikAnimal filed a bug about this last year already).
We can get a clue though by looking at the series of daily hits/pageviews for Scholia over time. Spot-checking January-April 2024, it's very interesting that while the numbers are indeed above 100k most days, there are several days where they are much smaller (e.g 2024-01-02: 34, 2024-01-12: 12, 2024-02-08: 28, 2024-03-04: 26. Similar a year earlier, e.g. 2023-02-15: 31, 2023-03-30: 8, 2023-04-17: 34). Such extremely large, isolated drops basically never occur for web traffic that is substantially human-generated. Now there might be some different explanations (e.g. further bugs in the Toolviews tool), but the most likely one is that Scholia sees very little direct human usage.

Regards, HaeB (talk) 07:49, 18 May 2024 (UTC)

PS, re the last bullet point: I noticed since that these weird drops are also showing for other tools (example), so the further bugs in the Toolviews tool possibility I mentioned is in fact the more likely one. And you already pointed that out elsewhere in the article (Many outages since 2022 are of the wikitech:Tool:Pageviews tool - sorry for overlooking that in my last comment; as I said, it consisted just of some quick observations). That's a bit in contrast though with which we consider reliable, no?

Either way, the question remains how much human usage the Scholia tool actually sees. I'm a bit surprised that this Op-ed describes it as a successful product citing nothing more than a metric that the 2018 paper warned should not be used for such conclusions.

Regards, HaeB (talk) 12:26, 20 May 2024 (UTC)

I don't quite follow everything being said here, but to whom it may concern, there will be a Toolviews visualization akin to Pageviews relatively soon. It's a volunteer project I've slowly been picking away at since 2019. It's maybe 90% of the way there, so stay tuned :) — MusikAnimal ^talk 22:51, 20 May 2024 (UTC)

Belated apologies for pinging you here without indicating more clearly why. It was because I saw you had filed that bug about that unique visitor data in toolviews. It made me think that you might be able to provide more insight in general on how reliable the toolviews numbers are, in particular when it comes to distinguishing tool usage by humans and spiders/automata (as WMF does for content pageviews). I realize though that you are not responsible at WMF for addressing that kind of problem.

All that being said, I would be curious whether/how it is planned to alert users of that forthcoming visualization of the Toolviews data about such issues (will it include a FAQ like the Pageviews Analysis tool?).

Regards, HaeB (talk) 06:38, 10 September 2024 (UTC)

PS: While closing tabs I noticed the comments at phab:T87001#8899655 ff. (e.g. The question of bot traffic vs. human was the first thing that came up when I showed toolviews to people at the hackathon and The very streamlined data collection that toolviews is doing based on the front proxy nginx logs does not contain any user-agent based processing. The idea was to be able to show traffic patterns more than to provide any sort of detailed traffic analysis. I agree that we should probably put a FAQ section on the https://wikitech.wikimedia.org/wiki/Tool:Toolviews page that I've not yet bothered to create for this tool). So it definitely looks like this issue is unsolved and that this Signpost article should not have used these numbers in this way to imply conclusions about the popularity of Scholia among human users. Regards, HaeB (talk) 16:30, 10 September 2024 (UTC)

@HaeB: I admit near total ignorance in interpreting the metrics which the Wikimedia platform makes available, including the limits of their reliability and what to notice when they conflict with each other.

I will be presenting some of the information in this report in about a month at wikiconference:Submissions:2024/WikiCite_-_proposed_as_Wikimedia_sibling_project with care to make the corrections you have indicated. My presentation will include published slides and a recording, so if you have specific suggestions for what I should correct, then say so, as everything you have said so far is valuable to me. I will follow up with an email to ask you for a voice/video chat, and if you can meet me, I will take notes because you understand this and are the only person giving me feedback on this in all the times I have presented this. Thanks so much. Bluerasberry (talk) 18:06, 10 September 2024 (UTC)

What's the limiting factor?

I was surprised that WD, having about as many items as Commons has pictures, should be subject to severe strain that Commons is spared. I guess it's because WD gets a lot more queries. I bring up WikiShootMe more days than not, and Commons App almost as often, and probably each instance means multiple searches among those hundred million items most of which have nothing to do with geocoordinates. So, it makes sense that my favorite views, the ones that are all about geocoordinates, should be limited to a separate database for places, and users who want to know something about people will use a separate biographical one, and scholarly articles? Every one that was published in the past century? Yipes; that must be a terribly heavy load, so that means separation again. And so forth. Kind of a shame that separate but affiliated websites must be set up to work around technical limitations, but I hope they can all be made to work together without too much confusion. Jim.henderson (talk) 02:02, 18 May 2024 (UTC)

Wikidata has 125 million items. Does Commons have 125 million pictures? Ymblanter (talk) 07:08, 18 May 2024 (UTC)

Wikidata and Commons have a similar number of pages, around 100 million. Last time I checked, the issues with Wikidata were due to the frequency in updates. Wikidata has over 2 billion edits, while Commons has less than 1 billion (or about 20 million monthly edits vs. 10). Nemo 09:19, 18 May 2024 (UTC)

To amplify (first posting on this got lost) Commons has 105 million media files. There is no direct comparison. If the commons:SPARQL query service was as much used as the Wikidata SPARQL, and the metadata for files were fully expressed in commons:Structured data, there would be a basis for comparison. It would likely show up that few media files had really large metadata, that typically the metadata were not very much updated after initial upload, and certainly Commons had few projects for systematic metadata expansion (unless the role of categories changed). These differences can help to explain why from the point of view of "big data" issues you cannot really equate the two sister projects. For example query.wikidata.org needs to refresh its working dump of Wikidata on a timescale of seconds to function properly, which is not a relevant requirement for Commons at present. Charles Matthews (talk) 09:53, 18 May 2024 (UTC):

So I would say that the "sheer volume" headline is more than a trifle misleading on the technical side. The worst-case WikiCite items are things like the Higgs boson article item with several thousand authors. But it is probably the average-case ones, say with 30 "cites-work" statements, that fatten up the graph, and these get edited often enough, for example with tools, to link to author items rather just giving author strings. UniProt is twice the size of Wikidata in terms of items[3]. Charles Matthews (talk) 14:22, 18 May 2024 (UTC)

So, it's not the number of items as the headline might suggest, nor the size of items, nor even the traffic of queries as I suspected. Rather, the major problem is the heavy traffic of changes, and most of those changes are by bots. It's pleasant to know that we Commons users are not much the problem; mostly we are among the many who are at risk of suffering. Even though my uploads via WikiShootMe and Commons App are automatically linked in WD, that's a small part of the WD load. Yippee; it's not my fault; I'm just a victim! Jim.henderson (talk) 16:08, 18 May 2024 (UTC)

I'm not familar with the exact issues involved, but i strongly suspect it is not simply data churn rate, but that size of the underlying graph is a very significant issue here. Bawolff (talk) 08:58, 19 May 2024 (UTC)

I mentioned Uniprot, and https://sparql.uniprot.org/ is not having the same problems, I believe, despite having 150 billion triples. I'm no expert. It does seem to get by with an update every eight weeks. Charles Matthews (talk) 10:12, 19 May 2024 (UTC)

[I should preface this with im just guessing here]. I'm more just saying that the factors are inter-related and we probably shouldn't assume its just one single cause but a bunch of factors in combination. I suspect (albeit this is a total guess with nothing backing it up) things would be a lot easier if the graph size would be much smaller or the churn rate was significantly lower. As far as churn rate goes - it should be noted that there is a significant difference between a db with a low churn rate vs one with zero churn (a static db you have to rebuild if you want to change something). The static case opens up certain possibilities that just aren't possible if the data changes at all. Bawolff (talk) 18:58, 19 May 2024 (UTC)

I read a little more some of the on wiki pages. wikitech:Wikidata Query Service/ScalingStrategy seems to imply that there are two problems - capacity (Overall graph size) & update lag (data churn rate). It sounds like some improvements were made on the update lag front so it is less pressing at least in the near term, and that the larger concern at the moment is around capacity. The uniprot endpoint is using Virtuoso, which from what I understand makes some trade-offs to allow for really high capacity. In particular it has bad support for incremental updates (So no live updates), and it also has a feature where if the query is hard, it may return its best guess instead of the correct answer. Having the query engine be a static snapshot is a trade-off that might be acceptable to some users, but it is a pretty big trade-off and probably not to be taken lightly. Bawolff (talk) 08:04, 20 May 2024 (UTC)

Capacity is indeed the most important issue here. As of now, true horizontal scaling (sharding) of graph databases is an unsolved technological problem – but this would be the solution that is needed for Wikidata.

Currently, the entire graph representation of Wikidata needs to fit into the memory of a single computer for the Wikidata query service (WDQS), which is the most important interface to consume data. Adding more memory to this computer (vertical scaling) becomes increasingly expensive and does not scale indefinitely anyways. Due to the lack of horizontal scaling for graph databases, it is currently not an option to distribute the graph to several computers which behave as if they were one database—as it can easily be done for many other database types.

There are a few graph database engines that claim to have solved horizontal scaling, but usually this comes at the expense of plenty of query performance (i.e. consuming data is usually significantly slower and less predictable when horizontal scaling is used), and those engines which have gotten this feature only got it rather recently. At this point it is not obvious which engine will emerge as the clear go-to option in the future for a graph of the size of Wikidata.

I'm afraid there is really not much that can be done differently than the proposed split at this point; it is not a question of resources, or lack of will. We have to accept that multiple graphs and query federation are the way to go. —MisterSynergy (talk) 19:33, 21 May 2024 (UTC)

Does blazegraph really need everything in memory? Its not advertised as an in-memory database. Of course, regardless of that, memory pressure still has a significant affect on query performance as the data set gets larger. While i agree that vertical scaling can't go on forever, it does seem like we are very far away from the limit if money was no option. For example, AWS offers servers with 24 terabytes of ram (e.g. u-24tb1.112xlarge). Such things are very expensive, but they do exist. Bawolff (talk) 22:50, 21 May 2024 (UTC)

As much as I am aware, the memory spec of the current setup is indeed relatively moderate, compared to what is technically possible. However, please also consider that there are already north of 20 servers behind WDQS, distributed to two different data centers and partially reserved for internal and external usage. Each of those servers is capable of running queries on the entire graph, and the load from different requests is somehow evenly distributed among them.

If you want to scale vertically, you need to do this for all of these machines. Doing so might help for possibly a couple of years, but the fundamental problem—the absence of a viable technical solution—would very likely not be solved by then either. —MisterSynergy (talk) 21:29, 23 May 2024 (UTC)

Its important to distinguish the wikidata query service from the wikidata wiki. The database powering the wikidata wiki is scaling fine. Wikimedia commons is a bad comparison because the wiki itself is not having scaling issues, it is the query service that is having issues. Bawolff (talk) 08:51, 19 May 2024 (UTC)

Indeed the analysis of the alternatives has the number of triples and the frequency of their update as major criteria. I'd say it's debatable where the boundaries of "the wiki itself" end though: what about native search, for example? At one point ElasticSearch was struggling to handle the updates on Wikidata, as well, for pretty much the same reason (IIRC). Nemo 09:41, 19 May 2024 (UTC)

Well, what Lane has written is indeed an opinion piece, leaving room for other opinions and discussions. My own takeaways are more complex. Leaving aside implications for my own future WikiCite involvement, and the whole tech funding debate, here are some:

Continuing significance of the pre-COVID timelines of Wikidata and WikiCite.
Poor state of community control of automated editing on Wikidata, coupled with attachment to "quick results".
Assessment of how the WMF's wooing of librarians is doing needed, in concrete terms.

Enough for now, really. Charles Matthews (talk) 05:28, 19 May 2024 (UTC)

Missing aspects

The other day, I recommended this Signpost article as background reading in a Facebook discussion (about this recent announcement on the WDQS backend update). I received this feedback:

I think it should be stressed that this is an opinion piece and rather incomplete. The author writes it himself [...]
the author does not seem to be aware of https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update/WDQS_backend_alternatives , which shows throughout the article. It's perfectly fine because of the disclaimer he adds himself. I just wanted to point that out.

Just wanted to post this here as context for other Signpost readers, and also a bit in the context of general discussions we have been having in the Signpost team on how much to vet or review opinion articles. (Again, obviously the author of this one put a lot of work into it and also, as the above quoted critic acknowledges, diligently included a disclaimer.)

Regards, HaeB (talk) 06:46, 10 September 2024 (UTC)

In fairness, I don't know how much that changes this article. Like yes, the plan seems to be: sharding graph for short term, move to QLever in the longer (or at least medium) term. It is not like we're just sharding the graph and then totally out of ideas. The question still remains - will it work and how much scaling does that buy us? The initial benchmarks do look extremely promising, but we're talking about a small number of benchmarks done in a non-production context not under load on a system that is quite frankly relatively immature (e.g. UPDATE support was just written recently). There is still a ton of uncertainty here. At a high level, I think this op-ed is essentially asking the question of what is the viability of WDQS at the different levels of scale we might optimistically see wikidata reach in the next 10 years assuming no artificial limitations are placed on it. Community members want to know this because they need to make plans based on the answer of this question. Not knowing creates fear, uncertainty and doubt in the Wikidata community. The WDQS backend alternative document doesn't answer that question. Bawolff (talk) 08:43, 3 October 2024 (UTC)

Special report: Will the new RfA reform come to the rescue of administrators? (4,181 bytes · 💬)

you can change the process. you can't change culture. ltb d l (talk) 13:15, 16 May 2024 (UTC)
Um, yes, even major cultures can be changed. I recall when drink-driving was the norm in the UK, for instance; I heard car crashes every Friday or Saturday night as drunken drivers lost control and hit a wall or a lamp-post, on an empty road. Now, people arrange to get home by other means if they intend to go out and drink. So a culture embedded for decades among millions of people can be shifted, with patience and persuasion. We'll get it done here too, slowly. Chiswick Chap (talk) 09:13, 20 May 2024 (UTC)
Has there been any comparisons of this issue with other large Wikipedias? I notice on a brief look that German and French Wikipedia admin numbers are similarly falling over time. While RfA process changes are certainly worthwhile, I'm not 100% sure that even a great process alone will halt the issue completely. SFB 22:19, 16 May 2024 (UTC)
- @Sillyfolkboy: Nothing I'm aware of, but I'd be happy to be proven wrong! And yes, obviously the RfA process is only one of the many reasons why the admin pool has kept shrinking, as the overall number of editors has done (except during the pandemic years, maybe), but hey, at least this reform might be useful to stabilize and solidify a core of dedicated users. Oltrepier (talk) 08:25, 18 May 2024 (UTC)
- Wikipedia:Wikipedia Signpost/2012-10-22/Special report, a report from 2012 by @Jan eissfeldt:. It discussed admin reforms (specifically recall) from the German Wikipedia from 2009, and how they affected adminship in the next 3 years. Soni (talk) 09:57, 18 May 2024 (UTC)
  - @Soni: Nice, thank you for sharing this, and for your work on the current reform process! Oltrepier (talk) 13:16, 18 May 2024 (UTC)
The short answer to the question posed by this special report is No. The proposal to make the first two days discussion-only has not proved to be successful. Actually, it's just taken a single RfA to prove it to be a disaster. – wbm1058 (talk) 10:06, 17 May 2024 (UTC)
- With due respect, ToadetteEdit knew they weren't going to pass RFA before they self-nominated. I'd say we didn't learn very much, except that when an unqualified candidate shows up, they'll likely be dealt with roughly. IMHO, this wasn't a reasonable test of the change because this candidate wouldn't have passed under any RFA regime, and even knew it beforehand. Technically, an outcome which 1) taught the community a valuable and unexpected lesson, and 2) didn't advance a poor candidate, is a win for those of us willing to try something different. No harm and it will never happen again. Those are wins. BusterD (talk) 00:27, 18 May 2024 (UTC)
Editor's note: I just wanted to thank theleekycauldron once again for agreeing to a "mini-interview" and for the work she's doing, together with other people! Oltrepier (talk) 07:32, 18 May 2024 (UTC)
Likewise, thanks :) appreciated your reaching out! theleekycauldron (talk • she/her) 07:38, 18 May 2024 (UTC)
Nothing changes. It’s a nice effort, and nice coverage, all leading to zero sum. The community is beholden to the broken process, it can’t be change, altered, reorganized, or otherwise fixed. 2600:1011:B188:718D:5C7:E042:B7D6:2426 (talk) 22:26, 31 May 2024 (UTC)

Traffic report: Crawl out through the fallout, baby (0 bytes · 💬)

Wikipedia talk:Wikipedia Signpost/2024-05-16/Traffic report