Wikipedia:Village pump (WMF)/Archive 7
This page contains discussions that have been archived from Village pump (WMF). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Let's configure: Suggested Edits
Background
Growth Team have developed a tool for newcomer engagement / reader conversion: Suggested Edits. This tool is highly configurable per community, but the English Wikipedia have yet to take advantage of that configurability to any real degree. This has led to some problems.
- The basics
Suggested Edits are very prominent to newly signed up accounts. Immediately after successful completion of Special:CreateAccount, newcomers are presented with two screens of information about Suggested Edits, before reaching Special:Homepage, where the feature is prominent and centre screen, with the term additionally bolded in the modal "Welcome to your homepage" they must click through to access the homepage. See c:File:2023 signup flow - prior to homepage 1 of 2.png, c:File:2023 signup flow - prior to homepage 2 of 2.png, c:File:2023 signup flow - initial landing at homepage.png. Basically, the new account experience does everything it can to funnel newcomers into the Suggested Edits feature. We shouldn't ignore it.
- The workings
Suggested Edits are subdivided into three difficulty tiers (see related discussions here and here). The default tier – "easy" – comprises the copyedit task and the links task. links is not yet deployed to this project, ETA early 2024. So the focus is copyedit.
Articles are added to the pool of Suggested Edits by templates. These are configurable by local admins at Special:EditGrowthConfig. Articles can be removed from the pool by use of templates (currently just the recently created {{no newcomer task}}) and by use of categories (none active). Articles cannot be included by use of categories.
Suggested Edits makes use of the ORES articletopic taxonomy (transitioning to LiftWing on the backend). This allows users to filter for Suggested Edits (i.e. cleanup templates) within certain topics, as guessed by machine learning models.
- Guidance through newcomer features
Clicking through to a Suggested Edit will bring up a "learn more" banner, which features six bespoke "quick tips" about the copyedit task. The text for these tips is in the MediaWiki: namespace, editable only by interface admins. From the Homepage, a Help Panel is available with links configurable by all admins at Special:EditGrowthConfig. I'd also like to address the links available earlier in the signup process.
- Outcomes
I invite anyone from Growth to share statistics about what percentage of editors whose first edits were through the Suggested Edits feature have gone on to publish, say, their 100th or 500th edit, and any other statistics about the feature that seem applicable. I ask participants to focus on configuring the feature rather than disabling it, which is not in scope.
On the community side, the feature has been associated with disruptive incidents leading to ANI filings (1, 2, 3, maybe more), sock-sniffing (a functionary timewaster), requests for page protection (which costs admin time), etc. Recent change patrollers are invited to share their experience patrolling edits tagged "Newcomer task - copyedit".
Problem factors
- 1. Limited options presented
The recent disruptions seem to stem from the topic filters. Only a few cleanup templates will make an article eligible for the copyedit task: {{peacock}}, {{inappropriate person}}, {{in-universe}}, {{advert}}, {{awkward}}, and {{tone}}. When combined with the articletopic filter, this creates certain intersections containing very few articles.
For example, leaving the default "easy" difficulty selector in Suggested Edits and filtering for the topic "history" gives one result, seen in File:2023 suggested edits - copyedit honeypot.png, equivalent to this search. The influx of newcomer edits to these copyedit honeypots overwhelms the community's capacity for review at those articles, as seen in several of the linked discussions. Topics with few available "easy" Suggested Edits can be seen at Special:NewcomerTasksInfo.
- 2. Expectations mismatches
The copyedit task purports to take "5 – 10 minutes" to improve the encyclopaedia, and gives very basic copyediting guidance:
- Copy editing is about making a small fix to the way an article is written, and it is a valuable and easy way to get used to editing Wikipedia. Copy edits help articles be more professional and trustworthy.
Reaching Mercury from Earthh poses significant technical challenges. - To make a difference, you only need to make one or two small corrections. You do not need to work on the entire article. You also don't need to have any special knowledge about the topic.
- You can fix spelling and grammar errors. This might include sentences that are too long, repeated words, or incorrect punctuation.
Mars has has two small moons. - You can also rewrite sentences so that they do not contain opinions. Wikipedia content should be neutral, clear, and encyclopedic. However, be careful not to change the facts in the sentence.
Jupiter is the largest, and most interesting, planet in the Solar System.
This sentence contains an opinion that should be removed. - Once you see a correction you want to make, tap the edit pencil on that section to get started. Then go ahead and fix issues by deleting and typing as needed.
- Either find more changes to make, or go ahead and tap the blue arrow button to publish your edit!
Formatting removed. The final two pieces of guidance take useragent parameters to customise display for mobile or desktop editors. The final piece of guidance contains a link to "learn more about the copyedit task", which up until a few days ago pointed to Wikipedia:Basic copyediting, and now points to Wikipedia:Writing better articles.
None of this guidance is incorrect, but it doesn't mention anything about core content policies, doesn't mention the Manual of Style, doesn't mention WP:ENGVAR (a very common stumbling block for newer editors), and doesn't invite the user to learn more about the reported problem with the article by clicking the displayed maintenance template, most of which cannot be addressed by basic copyediting.
We're pushing zero-edit accounts towards articles with maintenance templates like {{tone}}: ambiguous, requiring a high degree of familiarity with MOS considerations and what we expect an encyclopaedia article to read like, often difficult to resolve even for experienced contributors, sometimes needing a major rewrite, and not necessarily improvable by basic copyediting. While doing this, we tell them that they can improve the article in "5 – 10 minutes" of things like fixing typos.
- 3. Low visibility of community vetted guidance
When signing up my test account in researching this, I filled out a brief survey stating that I registered an account in order to create an article. During the signup flow, I was presented with a box recommending smaller edits first, with no caution about WP:COI, WP:PROMO, or WP:GNG, although it did come with a link to Help:Creating pages, which appropriately redirects to Help:Your first article. Earlier I was presented with links to Help:Introduction and Wikipedia:Help desk.
The copyedit task, as mentioned, contains a link to Wikipedia:Writing better articles at the end of its quick tip series. The help panel accessible from Special:Homepage contains links to Wikipedia:Writing better articles, Help:Introduction to editing with VisualEditor/1, Help:Introduction to images with VisualEditor/1, Help:Introduction to referencing with VisualEditor/1, Wikipedia:Article wizard, and Help:Contents.
Meanwhile, if we look at the Welcome templates, we see links to pages like Help:Getting started, Help:Editing, Wikipedia:Simplified ruleset, Wikipedia:Contributing to Wikipedia, Wikipedia:Simplified Manual of Style, WP:5P, Wikipedia:Teahouse, and Help:Your first article, amongst many others. Significantly, nothing in the guidance on the newcomer homepage nor within the Suggested Edits module mentions any of the following: edit summaries, talk pages (including that the user has one and how to sign them), user sandboxes for practicing syntax, or use of the {{helpme}} template.
Ideas for improvement
- A. Edit the "quick tips" for the copyedit task
Having two pages of guidance about basic spelling and grammar issues is probably too many. I appreciate the goal is to get people from zero edits to one, and so very basic information like "you don't have to fix the whole article" and "even small contributions matter" are important here. But since the stretch goal is to get people from one edit to a lot, we should try harder not to set newcomers up for reversion of nonconstructive / noncompliant edits, and not throw them into problem areas without explaining the problems or setting reasonable expectations about their experience.
I offer no suggestions for words to improve this guidance, or how to structure it, apart from a strong recommendation to mention ENGVAR. The current guidance is probably the product of research and professionals. Altering it will require intadmin admin access.
- B. Better / more help links
The links in the help panel could clearly be improved. I appreciate that the newcomer homepage is meant to help guide new editors through a variety of tasks, but three separate VisualEditor help pages alongside zero core content pages and zero MOS is not a good balance. Wikipedia:Article wizard should not be linked directly: Help:Your first article should be presented as required reading beforehand.
Help:Introduction is only linked during the account creation process, and not surfaced thereafter. Wikipedia:Teahouse should clearly be somewhere. I'm agnostic on which links specifically belong in the help panel, but it seems obvious (to me, who is weird and could be wrong) that the three VisualEditor pages could be collapsed to Help:Introduction, its parent. Anyone who can't find the links to the three specific VisualEditor tutorial pages from there is probably not our target demographic.
We have the ability to link more pages from prose in the Suggested Edits quick tips mentioned above. We don't want to overwhelm newcomers with so many links they know not which to read, but it seems self-defeating not to give them pointers that they will overwhelmingly likely find useful. I'm hoping some Foundation people might be able to comment on what might be an appropriate number of links to display to very new editors.
I'm uncertain if we can just add more links in the help panel from Special:EditGrowthConfig, because it is throwing an exception at time of writing.
- C. Configure which articles go in the copyedit task
This step alone should solve the most acute issue: newcomer disruption at copyedit honeypots. As I see it, we have two options for how to change this for the better:
I. Attempt to rescope the task fittingly
{{in-universe}} (1282 transclusions), {{inappropriate person}} (53 transclusions), and {{awkward}} (140 transclusions) are genuinely fixable by new editors with no prior experience. Looking at WP:TC, others that seemed possible are:
- {{abbreviations}} (82 transclusions)
- {{like resume}} (3780 transclusions)
- {{prose}} (3350 transclusions)
- {{cleanup tense}} (27 transclusions)
- {{verify spelling}} (485 transclusions)
- {{copy edit section}} (97 transclusions)
- {{copy edit}} (2619 transclusions)
Under this theory of change, we could also create our own special {{newcomer copyedit}} or similar, and manually tag articles where their contributions would be more helpful.
The problems with this are that with the removal of {{tone}} (7977 transclusions), {{peacock}} (3349 transclusions), and {{advert}} (18338 transclusions), we'd be reducing the options of "easy edits" presented, and likely making the honeypot disruption worse instead of better. This approach may improve the new editor experience, since they'll be presented with articles where the basic copyediting guidance makes sense, and where new editors can genuinely fix reported issues.
II. Accept that "easy edits" are not associated with cleanup templates
In a discussion a few years ago that I will not link as a courtesy, a suggestion was made for extremely specific cleanup templates geared towards very new editors, to the degree of "term is misspelt in this article". Of course, WP:SOFIXIT applies, and anyone who went around tagging articles identifying known typos instead of just correcting them would probably be blocked for disruption.
The reality on the ground is that a cleanup template is (typically, under best practice) applied only when an editor has run out of time, energy, patience, or competence to actually address the issue. These are usually things a fresh editor cannot know how to fix (and, appropriately, there is no guidance in Suggested Edits about how to remove a cleanup template).
This last bit, about not indicating how to mark a reported problem as resolved, shows that we're already putting newcomers in hopeless situations, so why limit ourselves to cleanup templates? {{unreferenced}} (160561 transclusions) applies to articles that are: unmaintained, C Class or below, often have few editors, no text–source integrity to break, and could frequently benefit from minor copyedits. This template is not for copyedits, but it seems a safe and broad choice for the copyedit task, where newcomers genuinely can make improvements and not be reverted or break much. The downside is that they are also unwatched. This feels like a more organic solution, and more in line with where our project currently stands.
An even crazier idea, included for completeness, is to use something like {{short description}} (5.6 million transclusions, probably representing almost all non-redirect articles). We could exclude based on templates or categories. An entirely organic solution which steers people nowhere, to let them make their minor copyedits that don't really help anything at whichever article they fancy.
- Non-starters
The following require dev involvement: creating additional newcomer tasks (like a second tier of copyediting), including articles based on categories (like Category:C-Class articles), rate-limiting Suggested Edits on individual articles, merging copyedit honeypots into different topics or suppressing their display if there are fewer than N valid options, significant alterations to the presentation of Special:Homepage.
- Tl;dr
I hope I'm more bored with this now than you are, dear reader. Please engage in discussion about this feature so we can make it work appropriately with our project instead of seeing it as a source of disruption. Main proposal is at "C", talk page is at WT:GTF.
Folly Mox (talk) 03:14, 19 November 2023 (UTC)
The text for these tips is in the MediaWiki: namespace, editable only by interface admins
isn't true - ordinary admins can edit most MediaWiki namespace pages. Not that it particularly matters since I'm the person most likely to be implementing any changes here, and I hold both rights. * Pppery * it has begun... 04:06, 19 November 2023 (UTC)- There was a recent discussion lamenting the size of the {{unreferenced}} backlog. It does seem like a possible task for new editors. I wonder if there is a short "3-step plan" instruction we can give for a reference for a claim in the article. We could explain, as RS says, that
Articles should be based on reliable, independent, published sources with a reputation for fact-checking and accuracy,
and ask them to seek one out to back up a claim in an unreferenced article. —siroχo 09:47, 19 November 2023 (UTC)- I probably should have mentioned that we already use {{unreferenced}} to sort articles into the
referencenewcomer task (tiered as "medium difficulty"). The idea here is not to get new editors to add references to these articles, just to give them a pool of articles where they can make their first, basic copyediting edits, and likely actually improve prose. Folly Mox (talk) 15:59, 19 November 2023 (UTC)- Ah I see the problem more clearly now. The "easy" task is not so easy (given that an editor had to tag it, as you explained in more depth). I agreed with that point, and effectively suggested that a "medium" task could be on par or perhaps even easier than that "easy" task, ironically reinforcing the issue you raised.
- I'm admittedly not very familiar with the broad new editor experience. Onboarding was simple in 2004, when a plausible claim was unlikely to be immediately removed if it had no citation.
- I realize this isn't at VPI, but ... I wonder if it's worth using some sort of automation to look at low-edit-frequency untagged articles to check grammar, style, formatting, etc, and instead of tagging them (which would be a risky use of automation), feed them into some new editor experience? The automation wouldn't alter the articles in any way, but it would bypass the problem that you raised that tagged articles are often not "easy" copyedit fixes. —siroχo 00:11, 20 November 2023 (UTC)
- We already have projects like Wikipedia:Typo Team/moss. These predate, and hence are not integrated with, suggested edits. * Pppery * it has begun... 01:10, 20 November 2023 (UTC)
- Siroxo, that's a great idea for a phab request. All the things I brought here are implementable now, by local admins, with no dev involvement. At present the
copyedittask can only include articles based onhastemplate, so some selection of templates is required for community configuration. Folly Mox (talk) 12:46, 20 November 2023 (UTC)
- I’d like to see Citation Hunt better advertised. Mach61 (talk) 19:27, 19 November 2023 (UTC)
- I probably should have mentioned that we already use {{unreferenced}} to sort articles into the
- Easy and Difficult is not a simple spectrum. At Template:Welcome training I avoided that sort of description and instead went for a task based description. Take two newbies, one an academic who wants a little practice in their written English, the other a precocious 10 year old who is a native speaker of English. One of them would likely find referencing unreferenced facts a much easier task than the other. There's also a typo finding tool in beta test. ϢereSpielChequers 21:48, 19 November 2023 (UTC)
- I agree. (Two relevant discussions here and here, linked in the OP).Apart from changing the internal variable names and
template-basedeligibility style of the "easy"copyedittask, I think we have community control over the displayed name of the task (Special:EditGrowthConfig is still throwing a MWException at time of writing, so I'm unable to check). Between configuring the guidance, the templates, and the "Learn more" link, we could turn this task into whatever we want. (MOS fixes can be very easy and quick, and if compliant tend not to be reverted.)I appreciate it's not clear, because my writing isn't clear, because my brain is organised as well as the "everything else" table midway through a garage sale, but the intent here is to use the tools already available to the community to configure these features to work better with our project: better experiences for newcomers with clearer footing, realistic expectations, and more appropriate guidance; and better experiences for seasoned contributors, who should ideally no longer have to deal with copyedit honeypots created by unfortunate intersections of topics and tags. Folly Mox (talk) 13:04, 20 November 2023 (UTC)
- I agree. (Two relevant discussions here and here, linked in the OP).Apart from changing the internal variable names and
- Broadly agree with all this. But there are an awful lot of articles where any native English-speaker of say 17-plus can improve ESL prose. I don't know if we tactfully convey this. Johnbod (talk) 13:25, 20 November 2023 (UTC)
- Thank you for opening this discussion, Folly Mox!
- The data will come soon, we have to gather what's relevant to that conversation with the most up-to-date numbers for English Wikipedia.
- Anyone can have a look at the number of tasks available per topic at Special:NewcomerTasksInfo.
Suggested links in Russian language - A quick clarification regarding one of the types of tasks in The workings section. There is an active task to add links but it is very limited (because it is too borad). Newcomers are asked to open the article and to add links, with text guidance. These newcomers sometimes drift from the initial task, which can lead to incomprehension from patrollers: "why that 'ad a link' tagged edit lead the users to fix spellings?" Plus, this task only has one article available as I write this message.
- We have a new task to replace it, Suggested links, already available at all Wikipedias, except German and English (you can test it at Simple English). It provides quite endless suggestions. A (group of) word is algorithm-suggested, highlighted in the text, with the target shown. Users just have to Yes/No/Unsure them. This task is the one Folly Mox mentions, and we plan to deploy it in January at English Wikipedia.
- I hope this helps; let me know if you have any question related to this topic. Trizek_(WMF) (talk) 14:40, 20 November 2023 (UTC)
- @Folly Mox thanks for starting this discussion and suggesting ideas to better configure Suggested Edits.
- You asked for Growth team members to share statistics about the Suggested Edits that seem applicable, and I can think of three experiments we've conducted with results relevant to Suggested Edits.
- We released "Newcomer task" experiment analysis when the Suggested Edits feature was initially released in November 2020. The key findings were that Newcomer tasks (AKA Suggested Edits) resulted in increases in:
- the probability that newcomers make their first article edit (+11.6%)
- the probability that they are retained as editors
- the number of edits they make during their first couple of weeks on the wiki (+22%)
- We also more recently conducted Newcomer task edit type analysis, to better understand if new editors were getting "stuck" doing easy tasks. This analysis finds that newcomers who start out with Add a Link and other Newcomer Tasks and who go on to have additional edit sessions most likely go on to make other types of article edits as well, we do not find evidence they restrict themselves to Add a Link tasks.
- A third experiment related to Suggested Edits that is worth mentioning is the "add a link" Experiment Analysis. Suggested Edits are most impactful when we release Structured Tasks like "add a link" and "add an image." Structured Tasks basically provide a Suggested Edit for a new editor that includes onboarding, and then breaks the task into a few easy-to-follow steps. The analysis finds that the Add a Link structured task leads to increases in newcomer participation, particularly by making constructive (non-reverted) article edits. These tasks aren't released on English Wikipedia yet, but we plan to make the tasks available to English Wikipedia in early 2024, and then admins can enable them in Special:EditGrowthConfig if there is community interest. These tasks are effective at funneling more new account holders into editing, but as you know, people make mistakes when learning new skills. :) In other words, as more new people try editing, there is an increase in the patroller/moderator burden. So these are features the Growth team has made configurable, so communities can decide to opt in or opt out.
- Hopefully this data helps, but I also understand that it doesn't perfectly answer all questions. I don’t have an answer to your exact question: what percentage of editors whose first edits were through the Suggested Edits feature have gone on to publish, say, their 100th or 500th edit? It sounds like the underlying question is about long-term retention, and the Growth team experiments generally utilize a more short-term definition of Constructive retention. I agree it would interesting to look at some longer-term metrics, and if this group is interested I can follow up with our data analyst about potential future analysis.
- Do you have additional questions or feedback regarding Suggested Edits? Is there anything I should do to increase awareness of the community customization options available via Special:EditGrowthConfig? We hope to make it easier for more features to be build for Community Configuration in the future, so that's something the Growth team is thinking a lot about right now. KStoller-WMF (talk) 20:11, 22 November 2023 (UTC)
Another complaint
Another IP user (1.157.92.55 has complained about the advertising banners, this time at AN:
If the donations were ACTUALLY going to the editors who make this website, I would pay. But no, that money goes towards the Wikimedia "Foundation" and their ludicrously overpaid executives. Why can't they just relinquish some of their salary? WHY do you act like Wikipedia will fail without these donations? You DON'T need that money for servers so stop acting like you do. It's absolutely pathetic, sleazy, and utterly dishonest. I don't CARE about Wikimedia's projects, I ONLY care about Wikipedia, and if I'm going to be paying money, that money should be going to the ACTUAL users who create this website, not a bunch of overpaid bourgeoisie "staff" who accomplish absolutely nothing. Absolutely disgusting. And the INSISTENCE is utterly obnoxious - EVERY time I load a Wikipedia page your misleading begging loads up top and forcibly scrolls upwards to the top. Enough is enough. STOP LYING
Thought you might be interested. Cremastra (talk) 01:09, 16 December 2023 (UTC)
- And honestly, I don't entirely disagree with them, although I wouldn't put in those terms. Cremastra (talk) 01:12, 16 December 2023 (UTC)
- I am sorry that readers are upset and I also wouldn't have used those words, but the comment does match my own reasons for not donating money. I am glad that at least one potential donor is clearer about how donations are spent, and thus able to make an informed decision about giving. Certes (talk) 19:51, 16 December 2023 (UTC)
- WMF executive pay went viral on Twitter, apparently. Saw this Business Insider story about it on Reddit. — Rhododendrites talk \\ 01:34, 16 December 2023 (UTC)
"The CEO of the most important website in history [Wikipedia] makes $790,000. The CEO of Docusign, a company that JUST signs documents for you, made $85,940,000 this year,"
I believe top positions should be compensated well. And 790k is only less than 1% of 85 million. It is a reasonable salary. Also, I suggested the fundraising ads, in line with the ads of The Guardian. After all, we don't want Wikipedia to be taken over by commercial ads in a bid to raise funds. Ads that come with demands of undue censorship and bias. Regards, Thinker78 (talk) 03:55, 16 December 2023 (UTC)- I have been quite critical of WMF fundraising practices in the past, but that rant is unhinged and amounts to trolling. I do not think that it should be taken seriously. Cullen328 (talk) 20:04, 16 December 2023 (UTC)
- What rant? Regards, Thinker78 (talk) 21:38, 16 December 2023 (UTC)
- I think he means the original post. The pay rates shown on twitter amounts to a storm in a teacup. They are quite low for the positions. Maybe other spending could be criticised, but not that. -- LCU ActivelyDisinterested «@» °∆t° 17:16, 19 December 2023 (UTC)
- One interpretation is that, although top WMF staff each have a reasonable salary, there are too many managers and too few lower-paid staff assigned to more visibly useful tasks such as fixing bugs. Certes (talk) 22:39, 25 December 2023 (UTC)
- The proliferation of middle management is the bane of all large organisations, I'm sure the WMF is no different. -- LCU ActivelyDisinterested «@» °∆t° 22:56, 29 December 2023 (UTC)
- One interpretation is that, although top WMF staff each have a reasonable salary, there are too many managers and too few lower-paid staff assigned to more visibly useful tasks such as fixing bugs. Certes (talk) 22:39, 25 December 2023 (UTC)
- I think he means the original post. The pay rates shown on twitter amounts to a storm in a teacup. They are quite low for the positions. Maybe other spending could be criticised, but not that. -- LCU ActivelyDisinterested «@» °∆t° 17:16, 19 December 2023 (UTC)
- What rant? Regards, Thinker78 (talk) 21:38, 16 December 2023 (UTC)
- There is no risk that Wikipedia will ever be forced to carry commercial advertising, even if literally all fundraising were completely stopped for multiple years. jp×g🗯️ 11:12, 28 December 2023 (UTC)
- I have been quite critical of WMF fundraising practices in the past, but that rant is unhinged and amounts to trolling. I do not think that it should be taken seriously. Cullen328 (talk) 20:04, 16 December 2023 (UTC)
- This rant demonstrates a lack of understanding regarding the volunteer nature of Wikipedia. As well, see grants. — Frostly (talk) 22:06, 25 December 2023 (UTC)
#2 (courtesy of the Teahouse)
Please STOP YOUR ONGOING BEGGING adverts asking for money. If you can’t manage the operation - CLOSE IT DOWN & go away - Stip ruining our experience 👎😡👎😡👎 2A00:23C4:D0F:1D01:9C29:17CA:2F74:C7EF (talk) 07:58, 20 December 2023 (UTC)
I'll be relaying any I see here. Cremastra (talk) 13:27, 20 December 2023 (UTC)
- Is it productive to post these here? This feedback doesn't seem very actionable. –Novem Linguae (talk) 13:32, 20 December 2023 (UTC)
- It's useful to know what some readers are thinking, even if those who feel strongly enough to comment are unlikely to form a representative sample. It's not actionable in that the WMF is unlikely either to stop begging or to close down, but the feedback may be helpful when wording future banners. Certes (talk) 15:53, 20 December 2023 (UTC)
- I agree that continuing to copy these here is not useful. I'm sure the WMF is aware that some people are upset about their fund raising practices, and the complaints embodied in these posts are all things that have been talked about before. These kinds of posts don't add anything new. RoySmith (talk) 16:08, 20 December 2023 (UTC)
- Agreed. KevinL (aka L235 · t · c) 23:38, 20 December 2023 (UTC)
- I don't think volunteers should be heat shields for people upset at the foundation's fundraising. So what would the correct way to make sure these complaints are seen by the people they're meant to be seen if not posting here? Barkeep49 (talk) 03:02, 21 December 2023 (UTC)
- I'm not sure that there is any benefit in making unconstructive rants more visible than they are at present. Volunteers are not acting as "heat shields" but more akin to spam filters. If you do think it's important that the foundation see it, then email it so as not to waste more volunteer time by posting it here. Thryduulf (talk) 11:10, 21 December 2023 (UTC)
- I don't think volunteers should be heat shields for people upset at the foundation's fundraising. So what would the correct way to make sure these complaints are seen by the people they're meant to be seen if not posting here? Barkeep49 (talk) 03:02, 21 December 2023 (UTC)
- Agreed. KevinL (aka L235 · t · c) 23:38, 20 December 2023 (UTC)
- I agree that continuing to copy these here is not useful. I'm sure the WMF is aware that some people are upset about their fund raising practices, and the complaints embodied in these posts are all things that have been talked about before. These kinds of posts don't add anything new. RoySmith (talk) 16:08, 20 December 2023 (UTC)
- It's useful to know what some readers are thinking, even if those who feel strongly enough to comment are unlikely to form a representative sample. It's not actionable in that the WMF is unlikely either to stop begging or to close down, but the feedback may be helpful when wording future banners. Certes (talk) 15:53, 20 December 2023 (UTC)
- They could post puppies and kittens are cute, and someone on the internet would have a rant against it. Unless someone posts something useful or interesting I don't see the point, I'm sure the WMF are well aware of their detractors. -- LCU ActivelyDisinterested «@» °∆t° 20:11, 20 December 2023 (UTC)
- "If you can’t manage the operation - CLOSE IT DOWN & go away". So basically they rather have Wikipedia close down rather than see fundraising requests. I think whoever wrote that should simply go away from Wikipedia. Anyways, I suggested the fundraising ads because I read they have been very successful in The Guardian. No idea if it was because of my suggestion they implemented it or not but I support the ads, even though I don't donate money because I have donated thousands worth of my time. Regards, Thinker78 (talk) 03:24, 21 December 2023 (UTC)
- I am not against posting these here, it's light tongue-clucking reading, but I think it serves no real purpose. My reasoning is as follows: For most feedback/reviews (think restauarant reviews on Yelp, product reviews on Amazon or your fave website), there's a human tendency to a bivariate distribution: people who loved loved loved it, and people who hated hated hated it; maybe a few just shy of that on either end. But the number of people who take the time to say a restaurant or product was decent, pretty much "met their expectations" is underrepresented, because where's the motivation to sign in, type that all out, and send it? You have to be a real data demon to do that. However, fund-raising is different: no matter how good the objective, nobody writes in to say how excited they were to receive the dunning request from Save the Manatees, or whatever there fave charity is; only some small fragment of the negative cohort bothers to write back, and their reaction is predictable. So, whether there are five posts thundering vitriol about our fund-raising or five thousand, I don' believe there's anything we can learn from it, other than perhaps the timing of when some social media platform posted a link to it, and how much influence they have, and there's nothing much we can do about that. I'm sure the WMF must do some A–B tests on the *wording* of such requests in order to measure the results (on the positive side) no doubt provides useful info, but I'd love to hear whether any A–B tests are done to measure negative reaction of the outraged-flame type, and whether anybody at WMF cares if there is. My guess is 'no' and 'no'. Mathglot (talk) 06:01, 25 December 2023 (UTC)
Hi all, I'm posting on behalf of WMF's online fundraising team. This is an interesting discussion around a topic we see as both important and challenging for the scale at which we operate: how to measure and ‘weight’ qualitative feedback. We work on it all the time, and we try to take both a human approach, e.g. building relationships through dialog, as well as running A/B tests to detect and improve points of friction.
On the more relational and dialog-based approach: we do rely on valuable feedback from various sources from readers, donors, and volunteers to inform the campaign, and we thank you for passing along more feedback. This year, we've been working with volunteers the past few months on the campaign and appreciate all the time and creativity everyone has brought to the collaboration process. We also recognize the increased volume in messages from readers at this time of year, and have staff dedicated to responding to inquiries who are monitoring our email address, donate[at]wikimedia[dot]org. Please feel free to forward any fundraising related messages to that email address and the team will follow up. We could also discuss having the team assist with responses at the teahouse, if that would be helpful. We welcome ideas for how we can better support volunteers during fundraising campaigns.
In our A/B testing, we often design tests that are aimed at improving user and reader experience, e.g. adding clarity around how to find the close button, improving the flow so that fewer donors get stuck or see error messages, etc.
I agree that online feedback can often swing to the extremes, but it is also true that any feedback contains a kernel of an idea that might lead to positive outcomes for all users. So we try to stay humble and receptive to input. Thank you and happy new year. - SPatton (WMF) (talk) 15:31, 29 December 2023 (UTC)
Wikimedia Foundation banner fundraising campaign on English Wikipedia ended yesterday
Dear all,
The WMF annual banner fundraising campaign for non logged in users in Australia, Canada, Ireland, New Zealand, the UK, and the US ended yesterday.
We would like to thank all of you whether you collaborated with us on the community collaboration page, or answered questions from readers on the Helpdesk, the Teahouse, or the VRT. Thank you all for your engagement during the Foundation’s biggest banner fundraising campaign of the year and for all your contributions to the projects. Thank you to all the donors who made the campaign a success and support free knowledge.
You can find the fundraising team across on meta if you have any questions or comments.
Best, JBrungs (WMF) (talk) 10:37, 1 January 2024 (UTC)
- And now you’ve started it up again. It’s not really “annual” if you do it year-round, is it? 98.97.153.210 (talk) 19:44, 25 January 2024 (UTC)
You are invited to join the discussion at meta:Community Wishlist Survey/Future Of The Wishlist/January 4, 2024 Update. –Novem Linguae (talk) 13:27, 18 January 2024 (UTC)
Knowledge Equity Fund round 3
I can't find the meta page for round 3, so leaving a mailing list link instead. Please post meta page link when available. https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/thread/B5PP2LUNDEAMPFZEKK6DXSXSN5YH7UQ6/ –Novem Linguae (talk) 13:30, 18 January 2024 (UTC)
Annual plan planning
... is coming up soon. meta:Wikimedia Foundation Community Affairs Committee/Talking: 2024, if this is still going on, may be one way to participate in that process. Might also be worth watchlisting the placeholder page meta:Wikimedia Foundation Annual Plan/2024-2025. Comments welcome from WMF folks with more details on the annual plan drafting schedule and how volunteers can best participate. –Novem Linguae (talk) 13:35, 18 January 2024 (UTC)
- Hi @Novem Linguae, thanks for the question. We'll share plans for participating in the annual planning process some time in February. That said, this year we're starting from a blank slate, so we're hoping to hear from people about what they want in next year's plan in the Talking:2024 process. These ideas will help shape our plan from the start. All this is to say, if you have ideas, go ahead and share them now! :) KStineRowe (WMF) (talk) 15:38, 23 January 2024 (UTC)
- Thanks. I went ahead and left an idea at meta:Talk:Wikimedia Foundation Community Affairs Committee/Talking: 2024. –Novem Linguae (talk) 19:56, 7 February 2024 (UTC)
- Hi @Novem Linguae, the objectives for our product and technology work are now live. There's an accompanying Diff post, and I've made a public announcement. Please let me know if you have any other questions! KStineRowe (WMF) (talk) 17:26, 20 February 2024 (UTC)
- Thanks. I went ahead and left an idea at meta:Talk:Wikimedia Foundation Community Affairs Committee/Talking: 2024. –Novem Linguae (talk) 19:56, 7 February 2024 (UTC)
You are invited to join the discussion at meta:Universal Code of Conduct/Coordinating Committee/Charter/Voter information. –Novem Linguae (talk) 13:21, 19 January 2024 (UTC)
Katherine Maher named to head NPR
Saw this about an hour ago on the Wikimedia General Chat Telegram channel, where a link to a paywalled article on the HY Times was posted. Her biography on Wikipedia has this free one to the announcement on NPR.
My own opinion, based on her clumsy & ill-informed response to the FRAM debacle -- as well as routinely ignoring her talk page over at Meta -- is that she was selected for this position more due to success at networking than for her job performance at the Foundation. She may prove to not be up to the job. That said, I will be quite happy if she proves me wrong & flourishes there. -- llywrch (talk) 20:51, 25 January 2024 (UTC)
- I think she'll do ok as long as she has a good CTO to deal with the "technological turbulence". The job there seems likely to play more to her strengths than her weaknesses, and to see some of the kinds of things she pushed for while at WMF as desirable rather than undesirable. Anomie⚔ 21:48, 25 January 2024 (UTC)
Wikimedia Community Fund (General Support Fund) Round 2 announcement
Hello everyone. The Community Resources team at Wikimedia Foundation announced the upcoming round 2 for the General Support Fund, which will run from February through May 2024. The Wikimedia Community Fund's General Support Fund provides flexible support for long-term projects contributing to Wikimedia projects. In the announcement, you can find information for new and returning applicants, as well as details about the round timeline and grant budgets. We will also reach out to you during the community review period. Read the full announcement on Meta-Wiki. On behalf of the Community Resources team. --I JethroBT (WMF) (talk) 21:49, 8 February 2024 (UTC)
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)
| 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)
- 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)
- 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)
Notes
- ^ For full disclosure; I have currently participated in two of the discussions, with a vote for Xaosflux and a vote against Vituzzu
- ^ a b Link takes you directly to the voting page; candidate statements may be found there.
- ^ a b Column is left empty when there is little or no opposition. Concerns are summarized from the votes in the linked discussion.
- ^ 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 {{WikimediaNoLicensing}} permissible under wmf:Term of Use? It's even fully protected. User Anthony (inactive) created the original in 2004, and the license only dates to 2011, so maybe the template is grandfathered in somehow? Beyond the legal, I've seen it on a user page (and elsewhere) and on user pages it seems to be a declaration that the user does not intend to comply with the Terms of use, and even if the statement above the Publish button negates that from a legal point of view (does it?) which maybe means the template's assertion is void, it hardly seems the right attitude for a User here to have. Should it be taken to 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)
- 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)
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)
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)
- @Slaporte (WMF): - FYI. TrangaBellam (talk) 15:17, 9 March 2024 (UTC)
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)
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- That's why the proposal is to hire a dev specifically to work on maintenance. Tercer (talk) 06:51, 25 March 2024 (UTC)
- 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)
- Been there, done that. Assigning all mainteinance work to a single engineer (or a small group of them) is a really bad idea in practice. It just obfuscates the need to have better mainteinance practices across the whole engineering organization. It isolates "mainteinance folk" from the new developments that they'll eventually move to mainteinance. It leads burns out, and then to a new "mainteinance guy" coming who starts from scratch and cannot tap into institutional knowledge about mainteinance. It is just unsustainable practice. MarioGom (talk) 10:19, 6 April 2024 (UTC)
- 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)
- 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)
- 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)
- That's why the proposal is to hire a dev specifically to work on maintenance. Tercer (talk) 06:51, 25 March 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- I suspect WMF SRE would be fine with a newer version of the package, provided that there was a compelling reason (more than just small bug fixes) and a different person/team took full responsibility for what that entailed. Like if WMF multimedia team (staffed in this hypothetical future differently) basically said that this is a critical issue, we need the new version, and we are willing to take responsibility for all that entailed, it would probably happen. But that is not the situation happening here. Bawolff (talk) 15:28, 30 March 2024 (UTC)
- This certainly does illustrate the odd relationship that the community has with WMF. In a commercial software shop, there would be meetings between engineering and product managements. The product folks would say, "If this bug isn't fixed, it's going to cost us $X next quarter in lost revenue as customers jump ship". The engineering folks would say, "The only way we can fix this is if we go off the LTS train and that's going to cost us $Y in additional engineering costs, plus some indeterminate $Z in technical risk exposure". The two sides would argue and come to some decision, but at least both points of view would be heard and weighed.
- But that relationship doesn't exist here. The customer base is the volunteer community. It's difficult to put a price tag on their labor, and even if you could, they don't have a seat at the table when it comes to making these decisions. Yeah, there's meta:Community Tech and meta:Community Wishlist Survey, but that's not quite the same thing as having the VP of sales in your face about fixing whatever bug is pissing off his biggest customer and threatening his bonus this quarter :-) RoySmith (talk) 17:48, 30 March 2024 (UTC)
- I think there is also a problem here in that the community lacks sufficient knowledge into how WMF does things to make effective criticism, and without effective criticism its impossible to hold WMF to account. Take this thread. The proposal is for WMF to hire a single developer to work on maintenance of MediaWiki despite the fact that there is already a lot more than one developer currently working on MediaWiki maintenance and none of the issues mentioned actually are MW maintenance issues. As a proposal it is pretty non-sensical - it is hard to even tell if these are issues the community cares a lot about or just an issue that a few people care about. The community might lack a seat at the table, which is a problem, but the community is also pretty bad at expressing what is important to it in a way you can actually do something with. Bawolff (talk) 18:17, 30 March 2024 (UTC)
- You're missing the forest for the trees. I could have phrased the proposal instead as "invest more resources in maintenance" without changing anything else, and your criticism wouldn't apply. Moreover, you're missing the point about "jumping off the LTS train". There is no need to update this package in isolation. If MW had been updated to Bookworm last year, or even Bullseye three years ago, they would have gotten for free the SVG bugfix. No matter which way you look at it, maintenance is lacking. Tercer (talk) 19:16, 30 March 2024 (UTC)
- Sure, but would it have been worth it? I also have a long list of things i would like to see fixed. The issue is everyone has a different list. I don't think there is any reason to think that hiring 10 more, or even 100 more devs would neccesarily fix the specific issues you are concerned about. Not all problems can be fixed by just hiring more people. (P.s. my criticism of, well technically this isn't a mediawiki issue, isn't neccesarily directed at you - there is no reason you should know where the boundries between different components lie. I think it is more emblematic of the meta problem where the community lacks the ability to really tell what WMF is doing and hence lacks the ability to really judge it which undermines the community's ability to be taken seriously when lobbying for changes) Bawolff (talk) 21:21, 30 March 2024 (UTC)
- Actually, we do have good visibility into what they're doing. The big picture of how they handle OS upgrades is on on Wikitech. And if you're willing to invest some effort looking around on phab, you can find all the details. For example, T355020 talks about upgrading the hosts that Thumbor runs on. RoySmith (talk) 22:06, 30 March 2024 (UTC)
- Yes, it would. Updating Debian is a no-brainer. Very likely it would take care of a large fraction of your list automatically. And it's something you have to do anyway, so there's no benefit from running archaeological versions. Keep in mind that we're talking about Debian stable here, so even the newest version is already old and battle-tested. Tercer (talk) 22:09, 30 March 2024 (UTC)
- Sure, but would it have been worth it? I also have a long list of things i would like to see fixed. The issue is everyone has a different list. I don't think there is any reason to think that hiring 10 more, or even 100 more devs would neccesarily fix the specific issues you are concerned about. Not all problems can be fixed by just hiring more people. (P.s. my criticism of, well technically this isn't a mediawiki issue, isn't neccesarily directed at you - there is no reason you should know where the boundries between different components lie. I think it is more emblematic of the meta problem where the community lacks the ability to really tell what WMF is doing and hence lacks the ability to really judge it which undermines the community's ability to be taken seriously when lobbying for changes) Bawolff (talk) 21:21, 30 March 2024 (UTC)
- You're missing the forest for the trees. I could have phrased the proposal instead as "invest more resources in maintenance" without changing anything else, and your criticism wouldn't apply. Moreover, you're missing the point about "jumping off the LTS train". There is no need to update this package in isolation. If MW had been updated to Bookworm last year, or even Bullseye three years ago, they would have gotten for free the SVG bugfix. No matter which way you look at it, maintenance is lacking. Tercer (talk) 19:16, 30 March 2024 (UTC)
- I think there is also a problem here in that the community lacks sufficient knowledge into how WMF does things to make effective criticism, and without effective criticism its impossible to hold WMF to account. Take this thread. The proposal is for WMF to hire a single developer to work on maintenance of MediaWiki despite the fact that there is already a lot more than one developer currently working on MediaWiki maintenance and none of the issues mentioned actually are MW maintenance issues. As a proposal it is pretty non-sensical - it is hard to even tell if these are issues the community cares a lot about or just an issue that a few people care about. The community might lack a seat at the table, which is a problem, but the community is also pretty bad at expressing what is important to it in a way you can actually do something with. Bawolff (talk) 18:17, 30 March 2024 (UTC)
- I suspect WMF SRE would be fine with a newer version of the package, provided that there was a compelling reason (more than just small bug fixes) and a different person/team took full responsibility for what that entailed. Like if WMF multimedia team (staffed in this hypothetical future differently) basically said that this is a critical issue, we need the new version, and we are willing to take responsibility for all that entailed, it would probably happen. But that is not the situation happening here. Bawolff (talk) 15:28, 30 March 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Regarding the broken Graph extension, I have written an overview in the new Signpost that hopefully sheds some light on the situation for those who haven't followed it closely over the past year: Wikipedia:Wikipedia Signpost/2024-03-29/Technology report.
- Speaking personally and generally (i.e. not necessarily about the Graph situation in particular), I think people should keep their minds open to the possibility that several things can be true at once: 1) WMF does a lot more maintenance (and other technical) work than some community members give it credit for, 2) many technical issues are trickier to solve that it might appear without detailed knowledge about the situation, but also 3) WMF often has serious problems with assigning resources proportional to impact and 4) there can also sometimes be situations where engineers overcomplicate a problem and let the perfect become the enemy of the good, or lack the expertise to find the most efficient solution. Regards, HaeB (talk) 02:49, 30 March 2024 (UTC)
- Thank you @HaeB for your even-handed review of the Graph extension situation, and articulating some real challenges that we all face, contributors and WMF staff. Something that I remind myself daily is that most people are trying very hard to get decisions they think will have a lasting impact right, and it's true that sometimes that can lead to letting 'perfect become the enemy of good.'
- I wanted to share a little of my perspective on the maintenance challenge: I've joked that this is my third 20+ year old codebase. Over those years, security, uptime and performance expectations have changed dramatically along with the Internet. We all expect software to be more safe, available and faster than ever before. Wikipedias have the privilege of serving a large user base of readers and editors, who are diverse in their geography, expectations and needs (to name just a few ways!). And often, those who work on the software are trying to keep as much functionality as possible as we modify things, so that as little as possible breaks even as the world changes around us. An imperfect analogy to what's happened might be retrofitting a series of buildings and changing their core purpose from some industry to housing. It's possible to change the purpose of a building without changing any of the internal structure, but over time, that becomes increasingly hard to live with. And now you have tenants, so you can't just send everyone away for a year to upgrade it all!
- We have multiple significant maintenance projects underway. One place to hear about a part of this work is in the monthly MediaWiki Insights reports, which describe MediaWiki project progress and plans. Each language wiki and sister project wiki is a separate deployment that also supports a distinct set of extensions, some of which were created and deployed many years ago, under pretty different circumstances than we face today. Following the insights reports may help those interested learn more about what it takes to untangle years of uncoordinated decision making for our most critical software, and what it will require for us to establish a platform that is supportable on a free and open internet by dedicated staff and volunteers, and still enable an open and distributed model for all contributions.
- Having volunteers who understand our challenges and then help us think through how to get things right together is super helpful. Thanks again and please keep sharing your thoughts. SDeckelmann-WMF (talk) 19:42, 1 April 2024 (UTC)