Wikipedia:Village pump (WMF)

Source: Wikipedia, the free encyclopedia.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
The WMF section of the village pump is a community-managed page. Editors or Wikimedia Foundation staff may post and discuss information, proposals, feedback requests, or other matters of significance to both the community and the Foundation. It is intended to aid communication, understanding, and coordination between the community and the foundation, though Wikimedia Foundation currently does not consider this page to be a communication venue.
  • Discussions of proposals which do not require significant foundation attention or involvement belong at Village pump (proposals)
  • Discussions of bugs and routine technical issues belong at Village pump (technical).
  • Consider developing new ideas at the Village pump (idea lab).
  • This page is not a place to appeal decisions about article content, which the WMF does not control (except in very rare cases); see Dispute resolution for that.
  • Issues that do not require project-wide attention should often be handled through Wikipedia:Contact us instead of here.
  • This board is not the place to report emergencies; go to
    Wikipedia:Emergency
    for that.

Threads may be automatically archived after 14 days of inactivity.

Behaviour on this page: This page is for engaging with and discussing the Wikimedia Foundation. Editors commenting here are required to act with appropriate decorum. While grievances, complaints, or criticism of the foundation are frequently posted here, you are expected to present them without being rude or hostile. Comments that are

Personal attacks
against other users, including employees of the Wikimedia Foundation, will be met with sanctions.

« Archives, 1, 2, 3, 4, 5, 6, 7

Stewards Election and Confirmation

The Stewards Election and Confirmation is currently taking place until 27 February. Interested editors can participate in the election here and the confirmation here.

Currently, 11 editors are running to become stewards, and 27 stewards are running to be reconfirmed. I have attempted to provide a neutral[a] summary of the current status of each of these candidacies, including a summary of concerns that have been raised. BilledMammal (talk) 15:49, 10 February 2024 (UTC)[reply]

Jump to: Summary Confirmation Candidates Election Candidates Internal discussion

Summary of Stewards, Steward Elections, and Steward Confirmations

Stewards

Stewards are a global group of users with complete access to the wiki interface on all public Wikimedia wikis. They have the technical ability to modify all local and global user rights, change the status and name of global accounts, and access any of the permissions available to administrators and bureaucrats. The use of steward rights is restricted by policy; stewards will not use their technical access when there are local users who can use that access, except in emergencies.

On the English Wikipedia, this means their primary functions are to make editors a bureaucrat and to globally ban editors; this last aspect can be controversial when an English Wikipedia editor is globally banned for activity that we would not consider to warrant such an action. They are also able to access personal data and suppressed information.

Steward Elections

Between January and February every year Steward Elections are held, during which editors with at least 600 edits who have been an admin on at least one Wikimedia Project for at least 6 months can run. To be elected an editor needs to receive at least 30 votes in support and at least 80% support.

Steward Confirmations

Between January and February every year Steward Confirmations are held, during which current stewards must have their status reconfirmed. During a public comment period editors may comment for or against a current steward; after the public comment period is closed all existing and newly elected stewards consider the comments and issue their own votes; a steward is removed if a majority of stewards vote to remove them.

Confirmation Candidates

Steward[b] Home wiki Concerns[c] Current status[d]
S O N %
AmandaNP English Wikipedia 82 0 0 100%
AntiCompositeNumber Wikimedia Commons 67 0 0 100%
Base Ukrainian Wikipedia 52 2 0 96%
Bsadowski1 English Wikipedia 51 1 0 98%
DerHexer Wikimedia Commons 72 0 0 100%
Elton Portuguese Wikipedia 34 0 0 100%
HakanIST Wikidata Some concerns about their activity levels 46 3 0 93%
Hasley Spanish Wikipedia 47 0 0 100%
Hoo man German Wikipedia Some concerns about their activity levels 31 7 0 81%
Jon Kolbert Wikimedia Commons 41 0 0 100%
MarcGarver English Wikibooks 23 1 1 96%
Martin Urbanec Czech Wikipedia 66 2 0 97%
masti Polish Wikipedia Concerns about their failure to respond to queries; effectively, concerns that they are failing to meet the steward equivalent of
WP:ADMINACCT
40 16 9 71%
Mykola7 Ukrainian Wikipedia 61 2 0 97%
RadiX Portuguese Wikipedia 36 0 0 100%
Sakretsu Italian Wikipedia Concerns about their involvement in the Gitz affair, specifically use of steward rights while under a potential conflict of interest. For context see Wikipedia:Wikipedia Signpost/2023-06-19/In the media and Wikipedia talk:Wikipedia Signpost/2023-06-19/In the media. 62 13 3 83%
Schniggendiller German Wikipedia 39 0 1 100%
Sotiale Korean Wikipedia 50 0 0 100%
Stryn Finnish Wikipedia 41 0 0 100%
Superpes15 Italian Wikipedia 78 0 1 100%
Tegel Swedish Wikipedia 43 0 2 100%
Teles Portuguese Wikipedia 41 0 1 100%
Vermont Simple Wikipedia 66 1 0 98%
Vituzzu Italian Wikipedia Concerns about their involvement in the Gitz affair, specifically use of steward rights while under a potential conflict of interest,
WP:OUTING, and behavior during the confirmation process. For context see Wikipedia:Wikipedia Signpost/2023-06-19/In the media and Wikipedia talk:Wikipedia Signpost/2023-06-19/In the media
.
57 34 2 62%
Wim b Italian Wiktionary 51 0 0 100%
Xaosflux English Wikipedia 51 0 0 100%
علاء Arabic Wikipedia Concerns about their involvement in the Arabic Wikipedia black out and auto-logout. 62 4 1 94%

Election Candidates

Candidate[b] Home wiki Concerns[c] Current status[d]
S O N %
Ajraddatz English Wikipedia 190 1 2 99%
Albertoleoncio Portuguese Wikipedia Concerns about level of cross-wiki activity 113 14 8 89%
EPIC Swedish Wikipedia Concerns about experience, cross-wiki activity, and hat collecting 104 14 17 88%
JJMC89 English Wikipedia Concerns about level of cross-wiki activity 98 12 12 89%
Johannnes89 German Wikipedia 187 2 4 99%
K6ka English Wikipedia Concerns about level of cross-wiki activity 39 46 17 46%
Lee Vilenski English Wikipedia Concerns about level of cross-wiki activity 18 71 14 20%
Melos Italian Wikipedia Concerns about activity levels 147 10 11 94%
Turkmen Azerbaijani Wikipedia Concerns about re-using statement from a previous attempt 65 41 24 61%
Yahya Wikidata 147 2 4 99%
~aanzx Kannada Wikipedia Broad range of concerns, including cross-wiki activity, experience, and views on spam. 14 67 22 17%

English Wikipedia Discussion

Nice summary. Thanks for taking the time. –Novem Linguae (talk) 17:09, 10 February 2024 (UTC)[reply]

Agree with Novem, thank you! As you mention, it'd be awesome to have this automated in the future (maybe as a Toolforge tool instead of a bot, to avoid the update edits needed). — Frostly (talk) 23:41, 12 February 2024 (UTC)[reply]
There already is a toolforge tool for the election candidates (though not the confirmation candidates) - https://stewardbots-legacy.toolforge.org/Elections/elections.php stwalkerster (talk) 13:09, 14 February 2024 (UTC)[reply]

Notes

  1. ^ For full disclosure; I have currently participated in two of the discussions, with a vote for Xaosflux and a vote against Vituzzu
  2. ^ a b Link takes you directly to the voting page; candidate statements may be found there.
  3. ^ a b Column is left empty when there is little or no opposition. Concerns are summarized from the votes in the linked discussion.
  4. ^ a b Manually updated; last updated at 23:24, 12 February 2024 (UTC). It would be useful to automate this for future elections.

No relicensing template

How is Template {{

Afd? Even if legally void, why encourage that with a template, even if it's just a pointless sign of an ornery user strutting some attitude on their user page, like a lot of userboxes are. Adding Slaporte (WMF). Mathglot (talk) 19:02, 4 March 2024 (UTC)[reply
]

It looks like there about eight users active in the past year who display that template on their user page. Most users displaying the template have not edited in 10 years or more. I don't see how displaying that template can override the terms of use. I don't see it as a major problem. If the template does not have any legal effect, then trying to delete it may create more drama than it is worth. Donald Albury 20:43, 4 March 2024 (UTC)[reply]
 You are invited to join the discussion at Wikipedia:Templates for discussion/Log/2024 March 4 § Template:WikimediaNoLicensing. — Frostly (talk) 21:12, 4 March 2024 (UTC)[reply]

Al-Quds University

Why is Al-Quds University not only mirroring the English Wikipedia—which I presume is permitted by law—but also using Wikimedia logos? TrangaBellam (talk) 15:13, 9 March 2024 (UTC)[reply]

@Slaporte (WMF): - FYI. TrangaBellam (talk) 15:17, 9 March 2024 (UTC)[reply]

Conversations with the Trustees - next call this Thursday 21st!

Hi all. I just wanted to give you a heads-up, in case you didn’t already know, that there are regular ‘Conversation with the Trustees’ events that you are welcome to attend and ask questions to the Wikimedia Foundation Board of Trustees (who oversee and guide the Foundation). I’m hosting the next one, taking place this Thursday 21st March at 19h UTC and, speaking as a long-time enwiki editor, it would be really nice to see people from here attending and engaging in the discussions. Please see m:Wikimedia Foundation Community Affairs Committee/2024-03-21 Conversation with Trustees for details! Thanks. Mike Peel (talk) 21:51, 18 March 2024 (UTC)[reply]

This is good to know about, Mike; thanks for sharing! Sdkbtalk 18:31, 19 March 2024 (UTC)[reply]

Proposal: WMF should hire a full-time developer to do basic maintenance on MediaWiki

I've been disappointed with the state of disrepair of MediaWiki for years, but yesterday I've become aware of an issue that finally drove me to complain: there was a basic SVG rendering bug that has been fixed upstream 4 years ago, but it still torments Wikipedia readers because WMF can't be bothered to install the fixed version T97233. WMF also refuses to switch to a less buggy SVG rendering library T40010 or to let the browsers do the rendering themselves T5593. Other users there expressed skepticism that SVGs would ever work here and we should revert to PNGs instead, as such issues have existed for more than a decade without being addressed.

This lack of basic maintenance is not limited to SVGs. There is also the well-known issue that graphs are "temporarily" disabled, which was triggered by MediaWiki using the Vega 2 library for 6 years after its end-of-life, until this time bomb exploded in their face. It looks like the current "solution" is just disable graphs forever T334940.

Another issue is that MediaWiki still runs on Debian Buster, the Debian stable from two releases ago. Fun fact, it will be end-of-lifed in three months, so we'll have one of the biggest websites in the world running on unsupported software. And these are only the problems I have personally encountered. Other editors tell of many more that I won't list here.

One might think that this situation is due to a lack of funds, but this is not the case. WMF has so much money that it doesn't know what to do with it: Signpost May 2023, Signpost August 2023. That's why I'm launching this proposal to tell it: hire a full-time developer to do at least basic maintenance. It's unconscionable to donate millions of dollars to other charities while your own website is falling apart.

It would be in fact perfectly natural natural for such a wealthy foundation administering such a large website to fix bugs themselves, or even take over development of the libraries it depends upon. I'm not demanding that much. Only to keep the software stack remotely up to date. Right now it's downright archaeological. Our billions of readers are suffering through issues that the rest of the world has long solved. Tercer (talk) 15:56, 23 March 2024 (UTC)[reply]

As I understand it, the WMF has hundreds of staff and these include developers. Github has 558 names of such. So, my impression is that there's no lack of staff or other resources. Presumably it's more matter of organisation and fit. I'm guessing that there's a lot of legacy code and technical debt and maybe this is too brittle and rotten to maintain easily. The graph debacle indicates that senior management ought to be getting a grip on this before a more catastrophic gap opens up. Andrew🐉(talk) 17:58, 23 March 2024 (UTC)[reply]
Obviously WMF has some developers. Certainly not hundreds, let alone 558. In any case none of them is dedicated to maintenance, otherwise Wikipedia's servers wouldn't be in a worse state than my grandmother's PC. I assume they are working on sexy new features such as the visual editor, the reply function, or the dark mode. Maintenance is boring, and doesn't look impressive in your CV. Nobody wants to do it. That's why I'm proposing a full-time maintainer.
Your alternative theory that they have enough resources but still can't do maintenance can be summarized as rank incompetence, and that's too cynical for my taste. It's also not actionable. What could one propose? "Proposal: WMF should get its shit together"? Tercer (talk) 19:09, 23 March 2024 (UTC)[reply]
The WMF does appear to have hundreds of developers and engineers. For example, see Developers/Maintainers which has a specific column documenting maintenance responsibilities. Some of these are the responsibility of entire teams such as Wikimedia Site Reliability Engineering which has a headcount of about 45. There are still clearly gaps in this structure, as shown by the year-long outage of graphs, for example. But the idea that there's nobody currently responsible for maintenance in a general sense seems too simplistic. The problem seems more that there's a complex structure in which it's easy for issues to fall down cracks or for people to pass the buck. Andrew🐉(talk) 21:21, 23 March 2024 (UTC)[reply]
I took a look at the gigantic list in Developers/Maintainers; the first two names there are volunteers, not staff, so we can easily discount that as indicating that WMF has hundreds of devs. All the ones I clicked in Wikimedia Site Reliability Engineering, however, are actually staff, so we can take 45 as a lower bound for the number of devs. Fair enough, some of them are responsible for maintenance, but it's clearly not enough. The WMF can easily afford to hire another, and it should urgently do so. Tercer (talk) 23:07, 23 March 2024 (UTC)[reply]
I find these threads tiresome. By background, I'm a real software engineer for real money in real life. I do some software development on enwiki-related projects as a volunteer. The pay sucks (but it's no worse than I get paid for editing) but at least I get to pick and choose what I work on, when I want to work on it, and how I want to architect it.
I've found my interactions with the WMF development staff similar to my interactions with any dev group I've ever worked with. Some are good, some not so good. There's a few who are absolute joys to work with. There's a few who are grumps. But then again, you could cross out "WMF developer" and write in (with crayon if you like) "enwiki editor" and you would still have a true statement.
The basic architecture is 25-ish years old. There's a lot of legacy crud. The fact that the core system is written in PHP just boggles my mind. Recruiting must be a challenge. How do you attract top-shelf talent when what you're offering is an opportunity to work on a legacy code base written in PHP and salaries which I can only assume are not competitive with what the Googles and Facebooks and Apples of the tech world are offering. And yes, you are right, doing maintenance work is not what people want to do. If you told somebody, "Your job is to ONLY work on maintaining the old stuff and you'll never get a chance to work on anything that's new and shiny and exciting", I can't imagine you'd get many applications. RoySmith (talk) 23:54, 23 March 2024 (UTC)[reply]
And the slow code review process discourages the volunteers who are affected by longstanding bugs from working on fixing them. And of course a company with a known-bad workplace culture.
I think there are people, myself included, who would be willing to work on only fixing bugs rather than building new things in principle, but probably a lot of those people (again including myself) have internally vilified the WMF for exactly this reason so would consider it to morally repugnant to work for them. * Pppery * it has begun... 00:32, 24 March 2024 (UTC)[reply]
I am one of those people. The experience described in that link is totally unacceptable and would lead to prosecution in many jurisdictions. I am ashamed to be associated with its perpetrators. Certes (talk) 01:41, 24 March 2024 (UTC)[reply]
That's why WMF has to pay them. You'll never get boring infrastructure work done by volunteers. And no, I don't believe you'd have any difficulty finding applicants if you offer a decent salary. Even for working with PHP (it's no COBOL, everybody knows PHP). WMF can afford to pay even a top salary from a tiny fraction of the money it has been setting on fire. Tercer (talk) 10:26, 24 March 2024 (UTC)[reply]
Yes, that sounds much more likely to succeed than giving the interesting work to the paid staff and hoping some mug will volunteer to do the grind for free. One option is make dedicated maintenance a role rather than a person, and to allocate it to a different member of staff each month. (Other time periods are available.) That way no one has to do it for long enough to drive them to resignation, and it's a chance to cycle the skill set with e.g. graph maintenance being done when a graph expert is on duty. Certes (talk) 11:44, 24 March 2024 (UTC)[reply]
Small bug fixes can be spread out amongst developers. But truly addressing significant technical debt means cleaning up the software framework to be more sustainable. That's not something that can be done effectively by rotating the work. isaacl (talk) 20:49, 25 March 2024 (UTC)[reply]
To add a bit to what Roy Smith described about software development: there are failures in managing it throughout the industry, particularly dealing with legacy code bases and a existing user population that generally wants all of their interactions to remain exactly the same. When the software has an associated revenue stream, there's a profit incentive to drive deadlines to be met, but when there isn't, the motivation is to get something that works implemented, as cheaply as possible. That tends to accumulate technical debt that has to be resolved later. One more developer isn't going to have much effect on these problems, which need significant resources working in concert to address. Better project management and setting of priorities is needed, to adequately plan how to transform the code base to a more sustainable state. Note there's a good possibility that would result in a decision to shed functionality currently in use that's too costly or insecure to keep in place, with a plan to re-implement some parts deemed necessary. isaacl (talk) 01:57, 24 March 2024 (UTC)[reply]
That's mitigated slightly by the lack of one negative force: MediaWiki has no need to make change for change's sake, just to make Product 2024 look sufficiently different from Product 2021 that users will feel obliged to upgrade. Certes (talk) 11:48, 24 March 2024 (UTC)[reply]
I'm a software engineer myself. More specifically I'm an SRE, so I'm typically responsible for the types of tasks you're talking about (server upgrades, etc). Let me give you my perspective:
For most software engineers, the work they do at their job is completely outside of their control. They do what makes their boss happy, and in turn, they do what makes their boss happy, and so on. Thankless work like regular maintenance is often dropped without the proper incentives. For some people, those incentives are the salary to work long hours, but since many American jobs in big tech pay 2x to 5x the salary WMF pays for the same role, That isn't it. Those incentives have to come from the top. An example of what that might look like is a "backlog drive" that employees are required to participate in. But that's pretty rare, because leadership is typically being evaluated on metrics like increasing revenue or visitors to the site, and technical debt doesn't push those metrics. So, asking WMF to hire more people doesn't address the problem. Those new employees, if hired, would just fall into the established system that caused the technical debt to exist in the first place. So the conversation you need to be having is: "How do we convince WMF to invest in technical debt?" I don't know the answer to that question. But focusing on hiring more people doesn't solve anything. Mokadoshi (talk) 03:31, 25 March 2024 (UTC)[reply]
That's why the proposal is to hire a dev specifically to work on maintenance. Tercer (talk) 06:51, 25 March 2024 (UTC)[reply]
The problem is bigger than just one person working on small bug fixes. The framework needs to be cleaned up to be more sustainable. The third-party software dependencies need to be reconciled across different extensions. This needs co-ordination across multiple development areas, and a lot of automated testing. It needs support from management to push through, rather than to just spend enough to keep the parts working. isaacl (talk) 20:49, 25 March 2024 (UTC)[reply]
Yes, investing in technical debt is exactly what's needed, but one reason (or excuse) for not doing that is lack of people. If I gag the cynic in me shouting that any new staff would just be diverted to exciting but unnecessary new chrome, an increase in resource should make it easier to get through the required drudgery. Certes (talk) 09:14, 25 March 2024 (UTC)[reply]
The key point is why hasn't the WMF already hired that one more developer, or ten, or fifty? Because it places a higher priority on spending those funds and management resources in other areas. For the development environment to truly improve, the WMF needs to change how it sets its priorities. Echoing what Mokadoshi said, that's the problem that needs to be worked on. isaacl (talk) 20:58, 25 March 2024 (UTC)[reply]
Do you have a source that the Wikipedia web servers run on Debian Buster? I thought they ran on Kubernetes? Mokadoshi (talk) 19:03, 25 March 2024 (UTC)[reply]
A message just came around on the cloud-announce mailing list saying that all the VPS hosts running Buster need to be upgraded in the next few months. I don't have any insight into what they're running on the production web servers, but I assume if they're migrating the VPS fleet, they're doing the same for production. RoySmith (talk) 19:14, 25 March 2024 (UTC)[reply]
Thanks for that link, I'm not in that mailing list so I didn't know. I don't know how WMF runs prod so it very well may be that they are running Buster. But it's important to note that the announcement is for Cloud-VPS which is VPS hosting for the community. It would be common practice to not upgrade Cloud-VPS until the last possible minute so as to minimize disruption for the community. AWS for example does not forcibly upgrade your OS until the last possible day. Mokadoshi (talk) 19:51, 25 March 2024 (UTC)[reply]
I wouldn't spend too much time and effort focusing on the Debian Buster thing. That doesn't affect end users in any way that I can see, and it is not end of life'd yet. Let's trust WMF software engineers and SREs to handle those details, and focus on things that directly affect end users. –Novem Linguae (talk) 21:05, 25 March 2024 (UTC)[reply]
Where it adds to the technical debt that has to be managed is the work to figure out the third-party software stack required by the extensions used for a given Wikimedia site. I agree that it's not a level of detail that editors should be worried about figuring out, but getting the code base improved so that it's easier to work out is important for long-term sustainability of the software. isaacl (talk) 21:24, 25 March 2024 (UTC)[reply]
It's in the discussion of the SVG bug I linked, where they say they will only install the bugfix when it comes with Bullseye, and link to the task for upgrading from Buster to Bullseye. Tercer (talk) 23:33, 25 March 2024 (UTC)[reply]
I really don't want to speak for the WMF, but I kind of understand their logic here. One way to manage a fleet of machines is to stick with LTS releases and survive on whatever gets packaged into that. It's certainly possible to built custom installs, but once you start doing that, you're off the LTS train and have to take on a lot more responsibility and overhead. I've lived in both worlds. If you haven't, it's difficult to fully understand just how attractive sticking to the LTS can be. RoySmith (talk) 00:10, 26 March 2024 (UTC)[reply]
  • From what I am aware of, there is a decent number of employed devs as well as volunteers, so if anything, this is a coordination problem (economical and social) more than anything else. I do have to agree on the point that despite the number of people, some important things don't seem to get done - some of it is primarily because dealing with legacy code is hard, and because hiring quality is hard (this is not to imply at all that current devs are bad) but more exactly that hiring the best devs to work on legacy code is particularly challenging (atleast without paying through the nose). The best way to resolve this is to use the donation war chest and work harder on technical evangelism + hiring on quality over quantity. --qedk (t c) 22:54, 25 March 2024 (UTC)[reply]
    Perhaps WMF can fund the volunteer developers to do basic maintenance, just like the Rapid Fund and the Wikimedia Technology Fund (which is unfortunately permanently on hold)? Thanks. SCP-2000 14:53, 27 March 2024 (UTC)[reply]
  • Hi all - I'm Mark Bergsma, VP of Site Reliability Engineering & Security at WMF. Thanks for this discussion and the points already raised. I'd like to help clarify a few things: at WMF we do indeed have a few hundred developers/engineers - spread over many teams in the Product & Technology department, which is roughly half of the organization. "Maintenance" is not exclusively done by a few dedicated staff, but is the shared responsibility of most of those teams and staff, for the components they're responsible for. They actually spend a large amount of their time on that, and for some teams it's the vast majority of their work. We do consider that a priority and explicitly make time & space for it (we call it "essential work"), and we aim to carefully balance it with strategic work (like bringing new functionality to users/contributors), as well as needed investments into our platform and infrastructure (e.g. our multi-year project to migrate all our services to modern Kubernetes platforms for easier development/testing/maintenance/developer workflows). Since last year, we've also made MediaWiki and related platform work an explicit priority (WE3), including the establishment of some much needed MediaWiki-focused teams again, and have an explicit annual goal to increase the number of staff and volunteer developers working on MediaWiki, WE3.2), and the new formation of our MediaWiki platform strategy. This will continue going forward (WE5 and WE6 of our draft next-year plan).
    Nonetheless, it's true that we have a big challenge sustaining the large and ever growing footprint of services, features and code we've developed and deployed over the now long history of our projects, at the large scale we're operating at. Compared to that footprint, and considering the very wide range of technologies involved, old and new, different code bases and needed knowledge and skill sets, a few hundred staff to sustain and develop that is not all that much. It involves difficult choices and tradeoffs everywhere - prioritizing between many tasks and projects, all of which seem important. It's something we care about, have done quite a bit of process improvement work on over the past 1.5 year, and have a lot more left to do on. We're planning several related initiatives (e.g. WE5.1, all KRs of PES*) as part of our next annual plan to further improve this. We're also going to communicate more about this sort of work, which has been less publicly visible before.
    But, for something more concrete right now: I've also looked into the situation of the specific issue with SVGs that you raised. That's indeed a problem with an old librsvg library version that is used by Thumbor, our thumbnailing service, which was extensively worked on last year to migrate it to our Kubernetes platform - also for easier/quicker maintenance like discussed here. Further work (including the Thumbor container OS image upgrade and some required Thumbor development for that) then unfortunately got delayed, as the development team then responsible for it needed to be disbanded and reorganized at the time - also to allow us to form the aforementioned MediaWiki focused teams. But, I'm now happy to report that the plan is for the work on the Thumbor upgrade to Debian Bullseye to start soon, in the next few weeks, which when finished should finally address this frustrating issue as well. (And yes, we do normally upgrade before OS releases go out-of-support :)
HTH! -- Mark Bergsma (WMF) (talk) 12:14, 27 March 2024 (UTC)[reply]
Thanks for taking the time for such a detailed answer (it seems that Andrew Davidson had a much better grasp of the situation, and I stand corrected). I'm glad to hear that you are aware of the issues, care about them, and there are plans for improvement. In particular, I'm glad that there is a MediaWiki team again and that WE5.1 is an explicit goal. If the state of MediaWiki in fact improves (at least in the issues I'm aware of) I'll resume donating.
It's clear that the answer to my specific proposal is (a quite diplomatic) "no", but I don't mind. I care about the results, and I'm not going to pretend to know better than you how to achieve them. Tercer (talk) 18:44, 27 March 2024 (UTC)[reply]

Preannouncement of upcoming Movement Charter conversations

I am Kaarel, support staff of the Movement Charter Drafting Committee, working with the Wikimedia Foundation.

I am writing here to let you know in advance that the full draft of the Movement Charter will be published on April 2nd, 2024. This will kick off the community engagement period from April 2nd to April 22nd. Perspectives from the English Wikipedia community would be very valuable for the conversations.

For context, the Movement Charter is a proposed document to define roles and responsibilities for all the members and entities of the Wikimedia Movement, including to lay out a new Global Council for movement governance.

Everyone in the Wikimedia Movement is invited to share feedback on the full version of the Charter draft – this is the last chance to propose improvements before the Charter draft is updated for the ratification vote in June 2024.

Since the last feedback round the drafts have gone through notable changes. I hope many of you will still find it worthwhile to review the drafts and share your perspectives to inform the final version of the text that will be ratified.

How to share your feedback?

Read the Committee's latest updates for more information. I am truly grateful for your kind attention!

On behalf of the Movement Charter Drafting Committee, --KVaidla (WMF) (talk) 07:38, 26 March 2024 (UTC)[reply]

Please remember, when attempting to tie-in and enforce any specific rulings or wording of the document, that this project is Wikipedia (specifically English Wikipedia) and not Wikimedia or an entity called "Wikimedia movement", and its editors are called Wikipedians and not Wikimedians (although some Wikipedians may also want to self-identify as Wikimedians). Thanks. Randy Kryn (talk) 12:27, 27 March 2024 (UTC)[reply]
Thank you for this feedback! I would like to understand better the point you are making. The Wikimedia Movement Charter is a high level document defining the future roles and responsibilities of those comprising it. As defined here, on English Wikipedia, "The Wikimedia movement is the global community of contributors to the Wikimedia projects, including Wikipedia." The article further elaborates that "the Wikimedia community includes a number of communities devoted to single wikis", followed by a list, including Wikipedia communities.
In my perspective, this means that following the definitions also in respective article on English Wikipedia, as curated by English Wikipedia community, Wikipedians are part of particular Wikipedia community, who in turn are part of the global Wikimedia community. It does not seem reasonable in a Charter-like high level document to mention all the projects separately, so the term Wikimedia is used. At the same time, I do hear your point about the choice of the term might feel "alienating" (my interpretation, please correct or specify, if not correct) for the contributors of particular projects. What is your positive proposal for terminology considering this?
Thank you for your very kind attention given to the matter! --KVaidla (WMF) (talk) 15:46, 28 March 2024 (UTC)[reply]