User talk:Jimbo Wales

Welcome to my talk page. Please sign and date your entries by inserting ~~~~ at the end.
Start a new talk topic.

This is Jimbo Wales's talk page, where you can send them messages and comments.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Archives: Index, Index, A, B, C, D, E, F, G, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252: 10 days

This user talk page might be watched by friendly talk page stalkers, which means that someone other than me might reply to your query. Their input is welcome and their help with messages that I cannot reply to quickly is appreciated.

This talkpage has been mentioned by a media organization:

Matthew Gault (8 December 2021). "Wikipedia Editors Very Mad About Jimmy Wales' NFT of a Wikipedia Edit". Vice Media. The trouble began when Wales posted an announcement about the auction on his user talk page—a kind of message board where users communicate directly with each other.

Technical debt

Hi Jimbo! People say they don't even bother reporting problems to the WMF anymore because they believe the bugreports will be ignored anyway. What percentage of the money of the WMF is used to squash bugs? Can we please significantly increase that number, whatever it is?

Can you tell the WMF to spend a bunch of money to hire a bunch of nerds to work on Phabricator tickets? Wikipedians appear to be unable to contact the WMF.

Can we pause shiny new projects, and prioritize working on existing problems and technical debt instead? Thanks, Polygnotus (talk) 21:46, 14 March 2025 (UTC)[reply]

Can you point me to specific examples? Basically it's like super duper easy to contact the WMF, so I'm not sure what you mean. But if you're experiencing that, and especially if lots of people are, then yeah, let's roll up our sleeves and solve that.--Jimbo Wales (talk) 23:47, 14 March 2025 (UTC)[reply]

Communication: It is not easy for someone like myself to figure out which WMF-er to contact (but maybe there is some trick I have not discovered yet?). What do they use to communicate internally? Maybe I can contact them there? Or maybe that can alert them of pings on Wikipedia? For example if they use Slack to communicate internally we could build a Slack bot that notifies them if they get pinged.

Technical debt: I haven't made a list, and my memory is far from perfect, but I have heard that sentiment expressed several times, which is rather discouraging. Focusing on specific examples may detract from the truism that any website that exists for literal decades(!) builds up technical debt over time, and that it is good to focus on that once in a while. For example the Action API is missing a bunch of features (e.g. those in XTools).

I have some ideas that I believe may improve Wikipedia, but I am not sure how to reach the right person in the WMF who is willing and able to build something like that.

One idea was making it easy to add extra buttons to DiscussionTools.

Another idea was an alternative to the conventional talkpage notification Polygnotus (talk) 00:43, 15 March 2025 (UTC)[reply]

A dozen years in and countless dollars spent, the mobile site is still not fully functional and is an impediment to collaborative editing. I am a highly active editor and administrator who does 99% of my editing on smartphones, and I use the misnamed "desktop" site on my phone. It works just fine, which is ironic since the mobile site doesn't. It would be funny if it wasn't so tragic that we are losing out on potential editors because of the "I can't hear you" problem. Cullen328 (talk) 17:44, 15 March 2025 (UTC)[reply]

@Cullen328 I am trying to get Jimbo to agree with me that it would be a good idea to hire some more nerds. If there is too much negativity in this section Jimbo is less likely to agree with me. So there is a fine balance, enough negativity to show there is a problem, but not so much the message gets lost.

If Jimbo agrees that hiring more nerds is a good idea then we can ask them to work on the mobile interface.

@Jimbo Wales The mobile interface is much much better than it was, and a lot of improvements have been made, but there are still some things that could be improved, as Cullen328 points out. It would be awesome if there would be some more nerds to work on stuff like that. Polygnotus (talk) 18:18, 15 March 2025 (UTC)[reply]

Here is a good example. Ten years ago it was announced (with no prior community discussion) on mediawiki.org (which is the Wikipedia equivalent of In a cellar, behind a locked door marked "beware of the tiger.") that "More than 2,000 Notifications, will start to be removed". The reason given was "This change is mainly intended to reduce a performance bottleneck." There is no explanation what this bottleneck is, or what discovery has been done to see what the improvement will be, or what alternative have been considered. The Gerrit task to implement it merely says "Add job to keep user notifications in reasonable volume." A priori it's likely that a SQL or database fix could have resolved the bottleneck.

As far as I know this is the first time that WMF has deliberately deleted data people want to keep. I and a few others, however, came across this page and objected. I noticed, after a few years, that I was loosing notifications. Trizek kindly raised T227853 in 2019. MMiller reponded with "We'll need to wait to see if this becomes a widespread issue for many users before spending any time with it" to which I responded (as I do now) with "Meanwhile data is being irretrievably lost."

A few years later, an editor undoes thousands of my edits, which means all my notifications are gone - note failing to preserve Wikimedian's data is probably contrary to GDPR, as well as best practice and movement ideals.

I raised 2 tickets

T367755 Restore lost notifications. 8 months later closes with "There is no way we keep copies of deleted data for that long. I'm afraid that your old notifications are gone forever, and there's nothing anyone can do to restore them." Which is quite likely wrong if a WAL is maintained (and if it isn't it probably should be), but thanks for at least responding.
T367754 Attack deletes user's notifications. This is a security issue, as well as deleting data it makes it possible to hide relatively new notifications. A commentator suggested that this was not an easily achievable attack, and the ticket was closed. I have reopened it, with a more comprehensive (but I hope not too WP:BEANS]y) explanation of how this is not hard to achieve.

Summary, WMF fails to respond to community objections. Fails to explain the underlying issue. Fails to restore lost data. Fails to stop deleting data. Fails to close security hole (although they succeed in closing the ticket). This may never have happened if they had discussed the original issue. 10 years later this is still having an impact.

I have other examples which are less complex, but much older than ten years.

I'd emphasise that this [things not getting done] is a subtle issue, and certainly not a personal criticism of those involved. All the best: Rich Farmbrough 23:41, 16 March 2025 (UTC).[reply]

\volunteer developer hat. This just sounds like "decisions I don't like". There is no amount of developers that will result in "everyone gets everything they want whenever and however they want it". There were performance issues, people took action. It's cool people want to think along, but that doesn't mean most people have a proper understanding of the scale of performance issues that Wikimedia experiences. Those who do can already find the people in question. It took 7 years before wmf was even able to do any sort of substantial database migration again, they had bigger issues to take care of.

I'm all for hiring more developers to fix bugs (which I agree is heavily underfunded), but notifications by nature are ephemeral (they didn't even exist originally and are still optional). Everything can be build / fixed, but that doesn't mean it makes economic sense (time/money/effort, whichever economy you pick) to do so. This is a nice to have at most. And you just repeating and demanding that Wikimedia developers take action, doesn't change that, and will indeed cause people to ignore the repetitive requests. —TheDJ (talk • contribs) 12:54, 18 March 2025 (UTC)[reply]

Bit of an ad hominem there, I think. I'm not demanding that anyone do anything. I raised some tickets.

I would appreciate knowing what the "performance issue" was. It is very unlikely that a significant number of accounts had over 2,000 notifications at the time, so a that raises questions, if the issue was the total number of notifications on the system this wouldn't help much. If something was falling over on a per-account basis then there would likely be a way of limiting a query, without actually deleting notifications. If it was syncing, then there would probably be a chunking solution. It's also possible that what was a performance issue 10 years ago would no longer be a performance issue today. Of course it could be that this was a wicked problem that could only be solved by limiting the number of notifications a user can have, but without sharing the issue, I don't think it's a very convincing case.
I don't know what you mean by "find the people in question" - unless it's that getting things fixed is better done by talking directly to devs than raising tickets. In which case it's not what you know but who you know.
You say "notifications by nature are ephemeral," I don't agree. Nothing on-wiki is supposed to be ephemeral, every byte is supposed to be preserved for all time. It's true that we hide a lot of stuff by faux-deleting it, also true that much is probably more hidden than it should be, but we very rarely actually delete anything, pretty much only for legal reasons.

All the best: Rich Farmbrough 11:27, 19 March 2025 (UTC).[reply]

I'll just add a coda, without clarity on the "performance issue" it makes no sense to "demand" a reversion of the initial change. I have however, offered a solution which would allow the maximum number of items to be set on a per-wiki basis. This might be useful for non WMF users of the software regardless.

All the best: Rich Farmbrough 11:52, 19 March 2025 (UTC).[reply]

This looks very much like you holding a grudge to me and not a real problem with too much technical debt (which definitely exists). And the WMF can't maintain a four-year-long record of all database changes, both because that would no doubt be terabytes (or maybe even petabytes) of content, and because it would contain private data which they have promised to not keep for more than 90 days. * Pppery * _{it has begun...} 18:19, 19 March 2025 (UTC)[reply]

Good that everyone agrees there is a problem with technical debt; even if we disagree about other things. Polygnotus (talk) 23:46, 20 March 2025 (UTC)[reply]

Perhaps more concerning than MediaWiki design flaws is the Foundation's inability to handle reports to legal-reports@. I've been waiting on one report for over two months now and the other report I sent only got actioned when I emailed the volunteer Commons Oversight queue. Jay Cubby 21:19, 16 March 2025 (UTC)[reply]

Ok, but I am asking Jimbo to hire more nerds. So if you want the WMF to hire more people who respond to emails to that email address it may be a good idea to start a new section so that we don't go offtopic here. Polygnotus (talk) 21:26, 16 March 2025 (UTC)[reply]

I figured it was in the same vein of the Foundation prioritizing more the shiny things and less the more urgent things, like CSAM or MediaWiki maintenance. Feel free to move my comment to a new section if you find it irrelevant. Jay Cubby 00:51, 17 March 2025 (UTC)[reply]

@JayCubby Thing is, I find it very relevant. And it saddens me to hear that you had to wait so long. But the more we ask the smaller the chance is that Jimbo agrees. Polygnotus (talk) 00:53, 17 March 2025 (UTC)[reply]

Polygnotus is correct—please start another section to discuss anything that does not involve reducing technical debt. Johnuniq (talk) 03:02, 17 March 2025 (UTC)[reply]

I have seen lots of issues but finding them now is tricky. A simple case is phab:T281921 where (nearly four years ago), it was reported that visiting bn:Template:Arguments generates an error. It's a minor matter but there should be a WMF technical person who notices stuff like that and spends a few hours finding the cause (is it indicative of a fundamental problem?) and solution. Johnuniq (talk) 03:02, 17 March 2025 (UTC)[reply]

Yes it is unfortunate that many such operational tickets remain open. Additional and dedicated staffing to take care of operational bugs and problems that the community encounters would be highly appreciated. This goes even more so for the sister sites, which are in FAR deeper holes than wikipedia is. —TheDJ (talk • contribs) 13:11, 18 March 2025 (UTC)[reply]

This has been investigated. It's some old corrupt DB in the database that doesn't indicate any sort of fundamental problem. And that was already pointed out years ago. * Pppery * _{it has begun...} 18:19, 19 March 2025 (UTC)[reply]

Here's another, that just bit me today - I see from Phabricator that it has bitten me in the past. T4700 (soon to celebrate it's 20th birthday) the pipe trick doesn't work inside refs (or other extension tags). All the best: Rich Farmbrough 11:06, 19 March 2025 (UTC).[reply]

It would be interesting to see a list of oldest Phabricator tickets. Polygnotus (talk) 06:53, 25 March 2025 (UTC)[reply]

Open tasks >20 years old (though for very old ones, there was the conversion from bugtracker that may be hiding the age). — xaosflux ^Talk 10:16, 25 March 2025 (UTC)[reply]

Almost old enough to drink in the USA! Polygnotus (talk) 10:30, 1 April 2025 (UTC)[reply]

Some of the discussion above confuses the term technical debt (which Wikipedia defines as the implied cost of additional work in the future resulting from choosing an expedient solution over a more robust one) with what would be more commonly called product backlog (features that need to be implemented and user-facing bugs that should be fixed).

But in any case, something quite similar to the original question was asked in this recent interview (which we also covered in the last Signpost issue) with Selena Deckelmann, who heads the Foundation's 300-strong product and technology department:

Interviewer (Yaron Koren): [A question] around the issue of priorities - there's always bugs to fix. Do you feel like you have to push in one way or the other like [...] to focus more on big picture, new feature type of stuff versus bug fixes, or the other way around.[...and also] refactoring, which arguably is a third category, of code for performance and that sort of thing. How do you balance out all those different goals?

Selena Deckelmann: Yeah, that's a great question. The annual plan system, that I helped put into place, has a category of work which is objectives and key results driven, and so that's like traditional product management, [...] where we're trying to say for, you know, this period of time, usually like a year, what we're trying to accomplish with. That is, an increase in page views of this [much] percent or, you know, improvements in editor workflows measured by surveys or usage of a tool, things like that. And that's probably about half of the work of the Foundation at this point. The other half is dedicated to what we've called essential work, and all of that is bottoms-up driven. So it's all of the teams and the individuals in those teams looking at their backlogs. Some of that's coming from Phabricator, some of it might be them like looking at the infrastructure, looking at logs and things that are breaking and, you know, figuring out stuff from there. And so that's the other half. So that's kind of where we've ended up in the last couple years and me just taking a look at everything that was there and trying to like assess where we are. You know, I think there's some folks in some teams that would like to do less of that maintenance work, you know, they'd like it to be a lower percentage and there are some teams that wish it was more. [And so,] rather than thinking about it as like one team has 50/50, the percentage across the different teams is different and it reflects [...] the local circumstances of that team and the things that it's supporting. So, at a high level, it's kind of coming out to about 50% and I imagine that that'll fluctuate over time depending on what it is that we're working on. And then for individual teams, we try to give them quite a bit of autonomy, because [...] there's a lot of work streams happening, like a lot of code that's being cranked out, a lot of challenges like in supporting the size of infrastructure, you know, for the billions of users. There's just like lots of things happening all the time that no one person or even like a group of 10 people could stay on top of and make decisions about all the time. So we have to figure out a way of delegating that effectively. And this so far, it's working pretty well. There are challenges, you know, like sometimes a team gets overwhelmed by incidents, [...] and then some important piece of work, you know, falls off the table and we have to figure out what to do about that. And so to deal with that, we have regular reporting and having people review those reports and like circling back and trying to figure out solutions to challenges like that. But yeah, that's about how it works today.

For the kind of problems alleged above (high-impact bug fixes being neglected, whether or not that matches every case mentioned), I think one key statement here is that what we've called essential work [...] is bottoms-up driven. So it's all of the teams and the individuals in those teams looking at their backlogs. Meaning that the causes for such failures could include:

an individual or team being under-resourced in relation to the backlog of bugs they are on the hook for (as mentioned in the interview)
an individual or team making wrong decisions (indeed it seems that while WMF has generally worked on prioritizing work more by impact in recent years, there is also still a lot of room for employees' personal whims, tastes and incentives to influence product decisions and bug prioritization)
a bug or task "falling through the cracks", i.e. being in no particular individual's or team's area of responsibility.

Regards, HaeB (talk) 07:31, 2 April 2025 (UTC)[reply]