This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
Utterly badly sourced business articles
I observed somewhere over a decade ago how Articles for deletion was often approaching People, bands, and businesses for deletion.
This is still true today.
I wonder whether we can relieve some of the pressure on the AFD process, and on volunteers, with a modification of policy.
Consider the likes of Industrial Fasteners Institute (AfD discussion)
It has stood for 12 years (and a few hours!) with its only source ever being the business's own WWW site.
Or there's Imagine Sports (AfD discussion) which has stood for 16 years with two "official web site"s and an "official blog".
Should we encourage a presumption of deletion, or perhaps greater use of the proposed deletion process, for articles on business where they cite no other sources than the business's own direct publications?
We have the proposed deletion of biographies of living people process for biographies with no independent reliable sources, perhaps we need a similar mechanism for utterly badly sourced business articles, where we demand at least something other than company self-published histories and "about" pages.
(I'd agree with the deletion of business articles sourced to nothing other that the business's own publications, and press releases in other publications; but I think that that's another discussion. And similarly, I notice that people are addressing the undisclosed paid editing through other means. That's another discussion, too. It's the plethora of business articles that are basically vehicles for company website links that I think that we could address.)
I'd agree. But it should apply to all articles about anything. Which is better, a badly-sourced article that might or might not be accurate but nobody cares enough to source it, or no article? Does WP:BURDEN not apply to article creation as much as to its content? Maybe we need a WP:NOEXCEPTIONS policy. — Cheers, Steelpillow (Talk) 18:49, 13 November 2023 (UTC)Reply[reply]
Many of the older ones are actually fine, they originated in the days when sourcing was optional but derived from respectable sources such as other encyclopedias. Espresso Addict (talk) 02:33, 14 November 2023 (UTC)Reply[reply]
That claim is currently not verifiable, and the longer the cites stagnate the less tenable it becomes. Again, I draw your attention to WP:BURDEN. — Cheers, Steelpillow (Talk) 07:29, 14 November 2023 (UTC)Reply[reply]
As I've said in various fora of late, if we all just referenced articles instead of wasting breath discussing how to delete them the encyclopedia would be a great deal better served. Espresso Addict (talk) 10:03, 14 November 2023 (UTC)Reply[reply]
Undersourced businesses are already prod staples, I don't think any more encouragement is needed, and there's a big difference between non-profit societies/organisations and for-profit companies. Espresso Addict (talk) 02:33, 14 November 2023 (UTC)Reply[reply]
After the recent changes to WP:NCORP, the standards for for-profit companies are higher than for non-profit bodies such as academic societies – which just have to be national/international in scope & meet GNG – rather than having to meet the new elevated standards for companies. Espresso Addict (talk) 23:36, 14 November 2023 (UTC)Reply[reply]
"nobody cares enough to source it" includes those trying to delete it, in many cases. The "BURDEN" is WP:BEFORE. A lack of sources in an article does not mean there are a lack of sources. Wikipedia itself is not a reliable source for determining if a topic is notable. Many editors don't look beyond Wikipedia. This is a common problem at AfD. -- GreenC 15:07, 14 November 2023 (UTC)Reply[reply]
That sword cuts both ways. Many editors have not gone beyond corporate promotional blurbs when creating articles, and not only is this a problem at AFC this is a worse problem in the encyclopaedia. Vehicles for corporate WWW site links like International Labmate Ltd (AfD discussion), which had even more external links to the company's various WWW sites in its older versions than it has now, are littered throughout the encyclopaedia. Uncle G (talk) 17:29, 14 November 2023 (UTC)Reply[reply]
The most slam-dunk case is articles on businesses. If the above example one went to AFD, it would be an easy fail or if there is advocate for the article they will need to quickly find and add GNG sources. But for those years nobody even questioned it. Sports articles are a lot tougher. Since in sports, coverage itself a form of entertainment (rather than the typical criteria to receive coverage) and has lots of fan clubs in Wikipedia, and whoever takes it to AFD will get beat up for not first searching for the missing sources. Edge case bands always end up as edge cases because there is a lot of edge case coverage situations. (interviews etc.) Finally, the typical mechanics of the Wikipedia system are that WP:Ver is a way to remove content and not directly a criteria for existence of an article. Theoretically, if GNG sources exist that aren't in the article it can be kept. So if it's a sports article with no substantive sources from a place when the media is non-english in a different character set, it's arguable that you need to have someone fluent in the language/character set to search to show no suitable coverage in order to delete it. Bottom line, I don't think that anything that speeds up the simplest cases is going to do much. Sincerely, North8000 (talk) 15:35, 14 November 2023 (UTC)Reply[reply]
This is why I asked specfically about businesses, and about a specifically identifiable set of business articles, at that. This isn't setting out to solve the world's problems, just to address one thing to see whether there's a way to make things incrementally better. And I think that there's a good case to be made that if we already apply the just one reliable independent source criterion to biographies, we can apply it to businesses. Indeed, we already do that and more to business articles at AFC.
So maybe we should close this hole in our standards and require that as a simple uniform minimum across the article namespace too: at least one reliable independent source in the article for a business. We decide that we don't host external linkfarms for corporate WWW sites for 15 years like, say, Forsythe Technology or Nisco Invest.
Nowadays, these wouldn't make it through our excellent if overloaded NPP process. The community might be minded to enact WP:CSD#X4: article about a business, enterprise, or product that was started before 2020 and has never had an independent source?—S MarshallT/C 17:51, 14 November 2023 (UTC)Reply[reply]
If we can't get consensus to speedy new articles like this, then we're unlikely to find it for deleting old ones. —Cryptic 18:05, 14 November 2023 (UTC)Reply[reply]
CSD is really not appropriate, because Wikipedia:Deletion is not cleanup, and therefore there is the potential for it to be legitimately contested. PROD should be sufficient.
That said, I took a look at Industrial Fasteners Institute, mentioned at the top of the thread, and I have two overall thoughts:
Wow, that industry is way more complex and interesting than I'd ever have imagined, and
I can find sources for European Industrial Fasteners Institute (EIFI), which started a trade dispute a little while ago, but not as much about the (US) IFI. But I suspect them of being a case of WP:ITSIMPORTANT in the real world (like: they're actually important, if you care about things like whether a plane is likely to spontaneously disassemble itself while you're inside), and I'd suggest a "merge" (of this one stub plus a half-dozen similar organizations for whom a stub hasn't been created) to a List of fastener industry organizations or Fastener industry, rather than deletion.
I was reminded recently that it's our official policy that more information (NB: information, not separate articles) is better than less. If we make a recommendation, I would like to see us recommend something that results in more knowledge. WhatamIdoing (talk) 18:09, 14 November 2023 (UTC)Reply[reply]
I too looked at the fasteners article and was intrigued. Agree merging would be more useful than deletion.
Unless we want to purge almost all content on companies, a new speedy tag is not the way to go. I don't see why standard prod is not effective for old articles where the creator has retired? Are people mass-removing the prods? (I try to check the prod list from time to time but mostly tend to leave the businesses alone, as it is not an area in which I edit.) Espresso Addict (talk) 23:45, 14 November 2023 (UTC)Reply[reply]
In 1976, the IFI instituted a proceeding over import relief for U.S. fastener manufacturers with the International Trade Comission.[1][2]. It's also necessary to search under its pre-1949 name "The American Institute of Bolt, Nut and Rivet Manufacturers"[3]. There's more out there than people seem to have found so far. Jahaza (talk) 04:44, 28 November 2023 (UTC)Reply[reply]
Can we get a list generated of company articles for which the only external link on the page is the company website? BD2412T 04:02, 10 December 2023 (UTC)Reply[reply]
I imagine that would be tricky as it's not always going to be easy for a bot to identify that given only the article title. A list of articles about companies (presumably identified by presence in a category) that include external links to only a single domain would I guess be easier. There will be false positives in that list (e.g. when the only citations are to the same newspaper), but I suspect it will also be worth examining those articles for issues. There will also be false negatives (e.g. if an article cites megacorp.com and megacorpinternational.co.uk), and no such query will be able to identify when the article cites only regurgitated press releases and similar, however as long as these limitations are understood and presence or absence from the list is not treated as evidence of anything in itself I think the list would still have value. Thryduulf (talk) 12:32, 10 December 2023 (UTC)Reply[reply]
If any article is longstanding but as poorly sourced as you state, I'd at least give them the benefit of a cursory search for RS, then prod it. Wikipedia won't be specially harmed if an ultimately notable business gets removed, as if it's truly notable, it will come back as a new article (or restored deleted article) with proper cites. But as someone who has seen plenty of this kind of junk, my emotional center says to "Prod away!". Stefen Towers among the rest!Gab • Gruntwerk 19:06, 15 December 2023 (UTC)Reply[reply]
I'm doubtful that it's an entirely harmless action (what if someone's looking for that information during the interregnum?), and I'm even more doubtful that it will somehow come back as a new article with more sources.
As a side note, one of the distinctions drawn in the academic literature into whether users trust websites is between "trusting" and "finding useful". A Wikipedia article can be very useful to a reader ("Oh, I thought the account I was just assigned was an agribusiness customer, but it looks like they have a lot more business interests than I thought...") even when they don't really trust it ("...so I should probably check in with the previous account rep before I call them"). WhatamIdoing (talk) 03:12, 17 December 2023 (UTC)Reply[reply]
Since Wikipedia is not a business directory, the lack of an article for a likely non-notable (or barely notable at best) enterprise will be harmless within reason. There's Google and the yellow pages and what-not to cover the rest. We don't have to host it. There's myriad notable subjects we're still missing so I won't lose sleep over prodded business articles. :) Stefen Towers among the rest!Gab • Gruntwerk 04:00, 17 December 2023 (UTC)Reply[reply]
Who says that a poorly sourced article is "likely non-notable (or barely notable at best)"?
I believe that sending readers off to other sites (e.g., with worse privacy policies, or which might be secretly paid advertisements) is not harmless. WhatamIdoing (talk) 04:08, 17 December 2023 (UTC)Reply[reply]
If something has been prodded, the prodder is supposed to have done a cursory search to see if there's hope for a subject being notable. Per AGF, I assume this happens most of the time. Also, the Wikipedia does not exist for being a web searcher's soft landing. I'm not buying into the scope creep. We're just an encyclopedia. Stefen Towers among the rest!Gab • Gruntwerk 04:14, 17 December 2023 (UTC)Reply[reply]
I totally side with encourage a presumption of deletion, not only when the only sources are directly related to the topic but also with articles that are loaded with obscure sources that seem purposely dredged-up to prevent deletion on what would otherwise be a totally non-notable topic. This seems to be a common hallmark of paid-editing. Just, in general, I wish we would be more strict with notability, especially for business-related topics, including questioning if sources are actually notable (eg, WP:CONTEXTMATTERS). Also despite WP:SOURCEACCESS some things like trade publications available only to a limited audience, etc., simply shouldn't count as reliable sources as they weren't generally available to the public as per WP:PUBLISHED. Ultimately, despite all the policy stuff, it needs to boil down to asking ourselves, "Hey, has somebody purposely scraped the bottom of the barrel to get this article to pass our notability standards?" If so, I think we should err on the side of deleting it; otherwise, we just accumulate promotional cruft. Historically, I think we've tended to side with keeping anything that is referenced with too little weight put on the quality of the references. We need a cultural shift that tighten the hatches. Jason Quinn (talk) 15:33, 26 December 2023 (UTC)Reply[reply]
Do the whole bold Oppose. Nobody seems to have explained why Prod isn't enough for me to get behind this. I'd also argue it's a strawman argument, there isn't actually a problem beyond I don't like it that these article are in wikipedia. If they exist and have existed a long time it indicates they are doing something right and that consensus is to keep, as that's how consensus forms and works. If we need to change the rules to exclude them, what does that say about us? And how does it come to define Wikipedia? Don't we have enough articles that require copyediting to be worried about this, the top of my watchlist indicates a drive there? Wouldn't our efforts be better directed there than here? A look at Wikipedia:Backlog tells me over 400,000 articles need more refences. Could we better pressed finding them? I do wonder why I give my valuable time to this project, creating and salvaging, when so many people want to destroy that work. Sometimes I decide I no longer want to because of the negativity. Does that make Wikipedia better? Or should we strive towards consensus. Should we say we're at an even keel as things stand, the guidelines are balanced, in harmony, we know how to use them to achieve the goal, let's kill the backlogs then regroup on discussions such as these if merited? HidingT 19:57, 5 January 2024 (UTC)Reply[reply]
I agree to some extent however business articles should be backed up solid independent evidence not just statements from the business website. My biggest gripe is editors creating forks when there is no need. Take House of Fraser. The company havestarted to create Fraser stores, and have announced that all stores will eventually go over to the new branding. An editor has created a news page Frasers (department store) which was excepted by a reviewer. But as per the owners, this is just a rebrand! We don't need to fork out something unless it's way to big or there is a genuine split off of the business. Davidstewartharvey (talk) 11:13, 9 January 2024 (UTC)Reply[reply]
Yeah, I get where you are coming from, but I think it's easier to deal with that happening with what we've got in terms of a ruleset/guidance now, rather than reinvent the wheel and add more potential issues into the pack. HidingT 11:36, 12 January 2024 (UTC)Reply[reply]
Oppose. A presumption of deletion is not compatible with WP:NEXIST or WP:ATD or WP:BEFORE. It would be positively damaging to apply such a presumption to history articles about nineteenth century businesses; or to articles about businesses in industries that actually have some kind of fanbase (eg railway enthusiasts). The fact that independent sources are not cited in article does not mean they do not exist. James500 (talk) 14:14, 9 January 2024 (UTC)Reply[reply]
RfC to limit the inclusion of the deadname of deceased transgender or non-binary persons
For deceased transgender or non-binary persons, their former name (birth name, professional name, stage name, or pseudonym) should be included in their main biographical article only if the name is documented in multiple secondary and reliable sources containing non-trivial coverage of the person.
This text was added boldly by different editors, originally in July and again in October, but was removed in December. 18:38, 10 December 2023 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I have split this long discussion to its own page, because (a) it's only been open a few days, and we've already got 85 comments from 46 people here and (b) due to the number of large discussions, this Village Pump page is currently almost half a million bytes long, which is much longer than some people can effectively read and participate in. The new location for this RFC is Wikipedia:Requests for comment/Names of deceased trans people. Please join the discussion over there. Thanks for your understanding, WhatamIdoing (talk) 06:24, 14 December 2023 (UTC)Reply[reply]
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
Currently, WP:PGCHANGE says this: After some time, if there are no objections to the change and/or if a widespread consensus for your change or implementation is reached through discussion, you can then edit policy and guideline pages describing the practice to reflect the new situation.
Should WP:PGCHANGE include an explanation, or else clarify the meaning of "widespread consensus" to mean the following:
For the purpose of this policy, "widespread consensus for the change" means that the discussion about substantive changes to a policy or guideline must be advertised sitewide to the entire community (such as through a request for comment and/or by posting at centralized discussion) and, after being so advertised, would reach consensus for the change.
It need not be the exact wording, but this would be the intended meaning. The possibility to edit policies and guidelines if there are no objections to these changes will stay. Szmenderowiecki (talk) 13:27, 22 December 2023 (UTC)Reply[reply]
Background
A recent discussion about WP:ARTICLESIZE (a guideline) was closed as "consensus to change". But there were a few editors over there who opined that in WP:PGCHANGE (the policy about changing policies and guidelines), "widespread consensus" means that the discussion must be sufficiently advertised (preferably sitewide, as in with an RfC) and there be consensus. VQuakr went on to say that in a discussion about changing policy or a guideline, even a unanimous discussion with ~15 editors would mean little if it only remained known to those who cared about the guideline and did not appear as an RfC or similar.
I then asked DfD to help me out, and the one editor (Isaacl) who answered didn't say whether this was what the policy said but suggested that personally they would prefer to read it as asking for sitewide advertisement. Other editors (the majority of those people) wanted to avoid an RfC as it would be a drain on the community.
To be clear, I do not mean this discussion to overturn that closure (I don't have a horse in that race), but I do want to hear opinions on whether changing policies and guidelines is appropriate without an RfC, given the doubts that have appeared in interpreting that policy. I do not wish to comment about that discussion so as not to appear favouring either side of that discussion. Szmenderowiecki (talk) 13:27, 22 December 2023 (UTC)Reply[reply]
Survey
Oppose - I don't think the additional text works in the broader context of the section. A change can be made if no one objects. A single objection shouldn't neccessarily trigger the need for a site-wide RFC. Often the consensus can become clear through ordinary, widespread discussion, without the bureaucratic overhead of an RFC. There are some changes that should be put to such an RFC, but they shouldn't be mandatory in all cases that aren’t strictly unanimous.--Trystan (talk) 15:25, 22 December 2023 (UTC)Reply[reply]
Oppose as needless bureaucracy. A WikiProject talk page isn’t a valid place go get consensus, but a policy talk page obviously is Mach61 (talk) 18:28, 22 December 2023 (UTC)Reply[reply]
Reword. I think something is needed, but perhaps not this precise wording. What's really necessary is some sort of link to WP:CONLEVEL and an indication that you need a consensus commiserate to the level of the change you are making - minor tweaks don't require widely-advertised consensus, and sometimes may not require affirmative consensus at all if they're slight wording tweaks and nobody objects, whereas if your change would fundimentially alter the functioning of core policy then it needs consensus on a level appropriate for that massive impact. Currently, at least at a glance, the page doesn't mention that at all; there needs to be at least one link to CONLEVEL somewhere on the page, since understanding that policy is essential for any major policy change. (Especially see the second paragraph of CONLEVEL, which is central here.) --Aquillion (talk) 10:49, 24 December 2023 (UTC)Reply[reply]
A few months ago, Aquillion said that "an RFC on an article talk page is by default local, and any conclusions it reaches are local; that is the heart and soul of WP:CONLEVEL".
This is neither consistent with what CONLEVEL says (it gives an example of an unadvertised, non-RFC discussion between a self-selected group of editors on a WikiProject's talk page that they claim overrides the views of editors on hundreds or thousands of articles) nor with how RFCs (the primary mechanism for advertising a discussion to the wider community, with the goal of getting comments from uninvolved editors) are understood by the community. WhatamIdoing (talk) 18:01, 5 January 2024 (UTC)Reply[reply]
Indeedy. And those of who do more than a single trivial cleanup bit, like a top-to-bottom clarity and cross-referencing overhaul, tend to announce this on the talk page and lay out what we're doing and invite discussion (or even reversion). I do this all the time. We do occasionally get someone trying to make unconstructive substantive changes (add a new rule we don't need, flip a rule backwards from it original intent, subtly shift wording to help them win some petty dispute at an article, etc.), but this stuff usually gets reverted quickly if it's not discussed on the talk page and met with approval. — SMcCandlish☏¢ 😼 16:15, 15 January 2024 (UTC)Reply[reply]
Oppose at least in something like that form, per WP:NOT#BUREAUCRACY and WP:CREEP and WP:EDITING and the intent of WP:P&G (particularly WP:PGCHANGE) in the first place. That said, I agree with Aquillion that the section should include a cross-reference to WP:CONLEVEL. If some suggestion to do an RfC or something is included, it should not refer to WP:CENT which is for high-profile things needing massive amounts of editorial attention and which are likely to affect a bazillion articles (or editors thereof). CENT is absolutely not for minor clarification or loophole-closure tweaks to P&G material. The more appropriate venue for "advertising" a discussion about something like that is WP:VPPOL itself. Editors who care to be involved in the formation of our P&G pages already watch this page, but the entire editorial pool do not need CENT browbeating about what is usually maintenance trivia. — SMcCandlish☏¢ 😼 22:01, 27 December 2023 (UTC)Reply[reply]
About a year ago, on the talk page of one of the core policies (NPOV?), an editor stated that (in their opinion) every single edit to a policy page needed prior discussion, if not an RFC. We pointed the editor to the history page to review the edits made during the last month or so, and asked them how many of those they would revert. The answer was "none". I don't think most editors understand how many changes produce no real change in meaning – a link here, a grammar tweak there, but no substantive changes. Few of us make substantive changes without prior discussion, and even fewer of us make those edits without the change being reverted. WhatamIdoing (talk) 18:06, 5 January 2024 (UTC)Reply[reply]
Oppose I guess, I tend to agree and want to support but consensus works by being a consensus, not declaring it to exist. If enough people don't like the change when it is made, you enter into Bold revert discuss, don't you, because the consensus wasn't as strong as first thought or has changed since you thought you had it defined. So, hmmm, sitting on the fence getting splinters maybe? HidingT 20:02, 5 January 2024 (UTC)Reply[reply]
Discussion
@Szmenderowiecki: thanks for the well-thought out content above and the ping. I would say that the meaning of "widespread" varies depending on the scope of the impact of the proposed change. In the specific case of the article size discussion that prompted this, the group was discussing subsequent changes to other policies and believed that those changes would be subject to the consensus they had there. For the impact of the change they were proposing, their consensus was not widespread. I think we agree, though, that most changes to PAG do not need sitewide advertisement. The proposed change above effectively just kicks the can of when to advertise from the definition of "widespread" to the definition of "substantive". Ultimately, a judgement call will need to be made, and given that groupthink is more or less inherent in a collaborative environment, the reminder that a small team of editors (however internally aligned) shouldn't be making sitewide decisions in a vacuum will be met with occasional resistance. I'm not sure that's a problem that can be mitigated with a tweak to policy. VQuakr (talk) 16:53, 22 December 2023 (UTC)Reply[reply]
The "substantive change" thing is already in the policy. Before making substantive changes to policy and guideline pages, it is sometimes useful to try to establish a reasonable exception to the existing practice. Maybe this will be an issue sometime later but we can assume that typos, grammar, markup and general changes to wording that do not change the meaning of policy or guideline are non-substantive changes. Szmenderowiecki (talk) 17:20, 22 December 2023 (UTC)Reply[reply]
I'm not sure if the proposed change to the text is the best approach. Often changes face objections by someone who raises no specific concerns other than suggesting that a request for comments discussion be held, which can lead to the degree of impact being exaggerated and thus deadlocking minor changes from proceeding. In the referenced discussion, I said that in my view, the affected community of editors should be given the chance to discuss and influence the proposed change. This may not require a site-wide advertising of the proposal. It will depend on the scope of the guidance and the proposed change in question. isaacl (talk) 18:24, 22 December 2023 (UTC)Reply[reply]
Yep. Going through this right now with a bit of policy cleanup, which is being stonewalled by someone resistant to change (even basic grammar correction) simply for the sake of being resistant to change, as far as I can tell. — SMcCandlish☏¢ 😼 06:21, 30 December 2023 (UTC)Reply[reply]
I guess WP:NOTAVOTE would apply in that case. If the best they can argue is that their gut feeling is wrong or that I just want to resist all change, then I think we can safely disregard this. Szmenderowiecki (talk) 09:19, 4 January 2024 (UTC)Reply[reply]
Since I closed the discussion referenced above, I guess I'll just note that of course I think matching a proposed change to an appropriate quorum will always be a balancing act. Those affected by a change should have the opportunity to share their thoughts about it. In this case, a table listed "rules of thumb" in two (intended-to-be) equivalent measures – word count and kb of prose. A discussion at the guideline's talk page concluded the second measure (kb of prose size) should be removed as potentially confusing and unneeded. How broad a discussion is needed for such a change? The guideline's meaning is unchanged, it's just now expressed in one way rather than two. Even if WP:PGCHANGE read as proposed above, I likely would have closed the discussion the same way, considering this to not be a "substantive change", and expecting no particular controversy. Ajpolino (talk) 03:05, 3 January 2024 (UTC)Reply[reply]
Been a part of that discussion, and it does seem to be stonewalled also by a single party. I think their argument amounts to a (rather impassioned and stubborn) disagreement that the change is non-substantive. They seem to feel that the change, while perhaps not altering the actual end-result size/length limits, will in some way strongly affect at least some subset of users' understanding of how to arrive at it, their sense of what it means in reality, or something to this effect. I don't agree with the position, for reasons given over at that discussion, but it doesn't seem entirely out of left-field. — SMcCandlish☏¢ 😼 15:01, 5 January 2024 (UTC)Reply[reply]
Over-capitalization of NFL Draft
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
RfC on the matter opened below, the moved to its own page due to length. Closing this original loose discussion, since someone in the RfC was confused about there being two threads open. (WP:TALKFORK). — SMcCandlish☏¢ 😼 20:47, 12 January 2024 (UTC); updated: 17:36, 15 January 2024 (UTC)Reply[reply]
In you look at sources, "draft" is overwhelmingly lowercase in most relevant sports contexts, including NFL (see [4], [5]). Yet it's hard to get away from the capitaized "Draft" on wikipedia due to the large number of football-fan editors compared to the editors who want to respect our style guidelines (at least, the was my impression in past discussions). Is there anything to be done about that? I recently moved a bunch of "List of ** in the NFL Draft" articles to lowercase draft, as that context is one of the most overwhelmingly clear in stats, but before I got most of them done they all got reverted. Is another RFC the way to go? Other ideas? Dicklyon (talk) 04:38, 2 January 2024 (UTC)Reply[reply]
Thanks for finding that clear lack of consensus. Dicklyon (talk) 05:17, 2 January 2024 (UTC)Reply[reply]
@BeanieFan11:, in reverting my moves to the "in the NFL Draft" articles, you wrote the current consensus is that the main draft article is spelled with an uppercase "D" - that should be reflected here. Can you share where you find that consensus? Dicklyon (talk) 05:53, 2 January 2024 (UTC)Reply[reply]
A gaggle of editors from the American football wikiproject will stonewall any attempt to move any of these articles; RM process has too few uninvolved participants to overrule their false-consensus. The article title "National Football League Draft" is demonstrably inappropriate per WP:COMMONNAME (and WP:CONCISE) policy, and also fails WP:NCCAPS and MOS:SPORTCAPS and etc. [6] It should be at NFL draft, which is actually the common name by a wide margin – with d not D. Of the four renditions "National Football League Draft", "National Football League draft", "NFL Draft", and "NFL draft", the "National Football League Draft" one is the least frequent and "NFL draft" by far the most. (And that's without even doing anything to filter out title-case appearance in names of works and chapters/sections; i.e., the capitalized forms are being significantly over-represented in these search results.) The long version is barely attested in published material. But this means nothing if no one one but football fans who love capitalizing everything to do with football weighs in on the question. (Which shouldn't be a question in the first place. Dicklyon's moves should not have been reverted, because they comply with the policies and guidelines and the over-capitalization has no leg to stand on (it's unadulterated WP:ILIKEIT). — SMcCandlish☏¢ 😼 11:20, 2 January 2024 (UTC)Reply[reply]
I suspect you'd get the same resistance in an RM at the NHL Entry Draft page, fwiw. Editors can't force other editors to agree to what they want. Thus they can't force such changes, if enough editor oppose. GoodDay (talk) 12:13, 2 January 2024 (UTC)Reply[reply]
No. They are specific events, or processes, but not proper names unless maybe in the context of the TV show or something (e.g. "I got tickets for 2024 NFL Draft", or "ESPN got rights to broadcast 2024 NFL Draft", perhaps). Stats show lowercase dominant draft, same as in other sports. Dicklyon (talk) 18:40, 2 January 2024 (UTC)Reply[reply]
Regardless of where one stands on the issue, we should be consistent with the capitalization used at the primary article that these other articles are based off, which is currently at National Football League Draft. Until that article is moved, which there is not consensus to do based off past discussions, we are essentially in limbo and should be consistent, otherwise it'll devolve into edit warring. Hey man im josh (talk) 01:51, 3 January 2024 (UTC)Reply[reply]
We definitely have a WP:CONLEVEL failure happening here, where a WP:FALSECONSENSUS of people devoted to a topic area are defying site-wide guidelines that apply to all topics, to get an over-capitalization result in their pet subject (against both MOS:SPORTCAPS and MOS:SIGCAPS, as well as WP:NCCAPS, and WP:COMMONNAME policy), all on the basis of a specialized-style fallacy, namely that various American-football-specific sources like to capitalize just about everything to do with football, while general-audience sources provably do not do this. Statistics this stark [7] do not lie. We have a problem that WP:RM, a process nearly no one pays any attention to, is regularly overrun by topic-specific editors after one of them alerts the related wikiproject, and the results end up being a predictable pile-on that ignores the large stack of guidelines and at least one policy, to just suit the preferences of the topical wikiproject participants; meanwhile few RM closers have the gumption to just discount their anti-WP:P&G and anti-source arguments and close in favor of the lower-cases moves, because the headcount majority crying for upper-case is apt to make WP:MRV noise about it and otherwise cause a bunch of drama. The RM process is palpably failing for cases like this; it is being outright WP:GAMED.
I'm skeptical that this can be settled any other way than with a broadly advertised RfC, tedious as style RfCs may be. If football fans are convinced they have on their hands some kind of demonstrable exception that just must be made to site-wide capitalization rules, then they are welcome to try to prove that to the community's satisfaction. This sort of thing has come up before many times (common names of species, capitalization of breeds and cultivars, etc.) that have festered sometimes for years, with a lot of editorial strife and disruption in sporadic, uncentralized debates, and were not resolved until broadly RfCed (here or at WT:MOS). — SMcCandlish☏¢ 😼 11:20, 2 January 2024 (UTC)Reply[reply]
I suspect there'd be resistance as well from WP:HOCKEY, concerning pages related to the NHL Entry Draft, too. BTW the Major League Baseball draft page, was moved to its current form without an RM & with little input. GoodDay (talk) 12:07, 2 January 2024 (UTC)Reply[reply]
The NHL Entry Draft stats are a good example of what happens when over-capitalization in Wikipedia influences the real world. It's not too late to fix it, as it's still not nearly consistently capped in sources, esp. independent sources. Dicklyon (talk) 18:35, 2 January 2024 (UTC)Reply[reply]
@Dicklyon: You should either officially propose a move of National Football League Draft or accept that editors will (and should) try to be consistent with the capitalization used at that article. Otherwise this is, frankly, a waste of everyone's time. We'd just end up rehashing the exact same discussion happening here. Hey man im josh (talk) 01:54, 3 January 2024 (UTC)Reply[reply]
The problem with RM, mentioned above, makes it hard to get to a consensus in such cases. Maybe an RFC? Dicklyon (talk) 03:12, 3 January 2024 (UTC)Reply[reply]
You could go the route of an RFC, but I don't really think there will be consensus on this issue either way. I suppose I'm asking what the goal of starting this discussion is. Are you planning to craft an RfC based on this discussion? Hey man im josh (talk) 03:27, 3 January 2024 (UTC)Reply[reply]
I'm seeking ideas; I had asked: "Is another RFC the way to go? Other ideas?". RFC was one idea supported. Dicklyon (talk) 03:50, 3 January 2024 (UTC)Reply[reply]
Personally I'm not convinced there is an issue of overcapitalization, given that many editors are trying to be consistent with the main draft article. Hey man im josh (talk) 16:07, 4 January 2024 (UTC)Reply[reply]
This is turning entrely circular. We've been over this already: the main article is capitalized, against WP:COMMONNAME and MOS:CAPS and WP:NCCAPS and other considerations, because a handful of "give us capitals or else" football fans want it that way, and will en masse blockade any RM that tries to change it, producing a FALSECONSENSUS against guidelines applying to a "magically special" wikiproject. The problem is not that the main article says what it does, the problem is that RM is easily and badly gamable by a wikiproject who want a "pet" variance from guidelines that apply to every other subject, which is prevent that or any other related article from changing names, without wider community input that cannot be gamed by half-a-dozen people from a particular wikiproject. — SMcCandlish☏¢ 😼 14:54, 5 January 2024 (UTC)Reply[reply]
Your best bet is to neutrally summarize all the pro and con arguments and counter arguments, and place them right after the brief opening RFC statement. Too often people are !voting without knowing all the factors, which is difficult when bits and pieces are scattered in other people's !votes. At least give those people who want to be informed a clear overview. MOS, esp. capitalization, can be quite nuanced. Some !voters that only see "NFL Draft" in their everyday sources, honestly don't know there are other options or why. —Bagumba (talk) 04:43, 5 January 2024 (UTC)Reply[reply]
If someone can point out a pro-capitalization argument, I'd like to see it so I can include it. About the only thing we heard before was a multiply-repeated claim to trademark status, but that was pretty thoroughly debunked, I felt, with the only found "NFL Draft" trademark being for clothing items, like caps and tee shirts, not for the player selection meeting. Dicklyon (talk) 00:42, 6 January 2024 (UTC)Reply[reply]
My understanding is that the NFL uses a capitalization for the term, but I'm not able to dig into it at the moment. For what it's worth, I personally don't really care either way, but I do advocate for consistency with the main article. Hey man im josh (talk) 01:04, 6 January 2024 (UTC)Reply[reply]
I imagine some !voters only see "NFL Draft" on ESPN, NFL.com—and even many (most?) newspapers—and just write off that non-NFL fans aren't following the NFL expert sources. —Bagumba (talk) 02:09, 6 January 2024 (UTC)Reply[reply]
If people are only watching ESPN, they'll see it pretty much always lowercase, and we wouldn't have this problem. On NFL.com, usually uppercase (but they sometimes forget to tell their headline writers, like here and here. Dicklyon (talk) 02:22, 6 January 2024 (UTC)Reply[reply]
You're right about ESPN. Try CBSSport.com, which seems to regularly cap. (And I might be wrong re: the extent of newspapers)—Bagumba (talk) 03:11, 6 January 2024 (UTC)Reply[reply]
If you can't get consensus for a move, then there's no consensus for a move. It's a tautological statement, but it's also the core fact of it all. Not enough people agree with you. So what, move on and don't dwell on it. Also, can we not have presumptive and biased discussion headers like calling it "over-capitalization" when the point is to discuss if it is properly capitalized. oknazevad (talk) 02:16, 6 January 2024 (UTC)Reply[reply]
Sure, we disagree there. It's clearly over-capitalized, with respect to our guidance and sources. The question is just what to do. Probably a central RFC makes more sense than an RM at the article(s), to get a more balanced participation. Dicklyon (talk) 02:22, 6 January 2024 (UTC)Reply[reply]
I think in order for you to get a 'green light' on the changes you're proposing? you'd first have to have an RM at National Football League Draft, with the result being - change to National Football League draft. GoodDay (talk) 02:46, 6 January 2024 (UTC)Reply[reply]
The meta-question on P&G RfC vs RM
In the RfC below, there's a whole bunch of discussion on the meta question of what's an appropriate venue for finding a consensus, when page moves are involved. The venue would be expected to bias the participation, with RM discussions attracting more editors that are watching the affected pages, and a discussion here or other central P&G place attracting more editors who care about policies and guidelines. Ideally, the relative numbers shouldn't much matter, as long as there are enough participants to get a good representation of the community's interpretation of the issues, and how best to resolve the question. That is, it's not a vote. However, the RM mechanism typically doesn't attract very many people who care about policies and guidelines, so it becomes hard to see a consensus when there are only a few such voices.
The last RM on this question found 10 in support of lowercase, based on policies and guidelines, and 10 opposed, mostly citing and repeating alternate factoids about the relative usage or trademark status. The closer was unable to see that the opposition was not at all based on policies or guidelines or real data, so called it no consensus. In the current RfC discussion below, we have lower numbers on both sides, but maybe over time we'll see more participation. So far not. I've listed the RfC at WP:CENTRAL, and another editor informed a large number of the affected articles' talk pages; and another informed a bunch of other sport WikiProjects. So maybe we'll get more participation from one side or both. Whether we do or not, I doubt we'll learn anything not already in evidence about the community's views. I guess it becomes a problem for a good closer.
I'm still open to other good ideas about how to resolve such things. The football editors who are afraid of losing their precious capital D are not happy about the RfC approach. Dicklyon (talk) 20:22, 12 January 2024 (UTC)Reply[reply]
I've an idea. Close the RFC & open an RM at National Football League Draft. Trying to bring about changes from the ground up, rather then from the peak down, merely causes (IMHO) chaos. GoodDay (talk) 20:27, 12 January 2024 (UTC)Reply[reply]
Weird metaphor, since doing things "from the ground up" is usually regarded as constructive and is a common idiom. I'm 54, and I've never once in my life heard the advice to do something "from the peak down". — SMcCandlish☏¢ 😼 20:47, 12 January 2024 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Asking Advice About Giving Advice About Contentious Topic Protection
If another editor asks me for advice about their disagreement with the extended-confirmed protection of an article, where should I tell them to go to discuss the protection? I will explain the origin of this inquiry, but I am not asking specific advice about the case in point, but about all similar cases. A case request was made at DRN by a relatively new editor. The filing party had added some information to a biography of a living person. Their edits were then reverted by another editor, and the article was then placed under Palestine-Israel restrictions, including extended=confirmed protection. As a result, the new editor couldn't edit the article, and wanted the protection reviewed or appealed. I am not asking for advice about the specific article or its content dispute, because I think that the protecting admin was right. But what advice should I give in the future if another editor wants to ask about partial protection of an article because of a contentious topic? I could tell them to request unprotection at requests for protection, but that would just shift the question off to the admins at RFPP. I could say to discuss with the protecting administrator.
Also, even if the protection was removed, the new editor still can't make edits relating to Palestine-Israel. Galobtter (talk) 02:12, 5 January 2024 (UTC)Reply[reply]
User:Galobtter - Thank you for providing the information on appeals. I did explain that the protection was right.
I assume that you mean that the user still is not allowed to make Palestine-Israel edits. Protecting the page also protects the user from making the edits that they are forbidden from making. Robert McClenon (talk) 04:52, 5 January 2024 (UTC)Reply[reply]
Adding a policy bias against articles without sources
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Currently, there are over 114,000 articles on Wikipedia that contain no citations or sources, making it one of the largest clean up categories on the site. WP:WikiProject Unreferenced articles has been one of the main WikiProjects attempting to dig through this giant haystack in order to give as many articles proper sources. Unfortunately, a main obstacle to cleanup has been how stringent deletion policy is. If you WP:PROD an article, it takes a week to delete, which is fine, and can be reversed by anyone. The issue is that many of these articles are unsourced stubs with no indicated notability, an article that me and others would agree to be a uncontroversial deletion via WP:PROD. Many of these PROD's are contested and then must go through the possibly month long review process VIA WP:AFD. The conclusion to this process usually is delete, but I believe that a criterion should be proposed that biases an article in favor of deletion, which is not having any sources. If this is written into the WP:DELETE policy, then I believe that editors like me will have a much easier time combing through the massive garbage dump that are unsourced articles. Tooncool64 (talk) 06:39, 5 January 2024 (UTC)Reply[reply]
Doesn't our current policy effectively do that? Editors arguing for notability are already required to provide or attest to the existence of sources which support notability. Horse Eye's Back (talk) 07:09, 5 January 2024 (UTC)Reply[reply]
True, but this is more directed at solidifying a valid reason for deletion, or a secondary reason, an article lacking sources, such that a PROD could say "Article fails WP:NGEO and WP:NOSOURCE", and be viewed as uncontroversial. Tooncool64 (talk) 07:12, 5 January 2024 (UTC)Reply[reply]
I think to some extent PROD will always be controversial. Horse Eye's Back (talk) 08:15, 5 January 2024 (UTC)Reply[reply]
Interesting. I wasn’t aware of that. I proposed deletion for this article [8] but the tag was reverted. The reason was supposedly that other elections later on are notable, but regardless, the problem is many of the earlier articles are unsourced and redundant, and many just redirect to the nominated Emperors' pages. Yr Enw (talk) 07:46, 5 January 2024 (UTC)Reply[reply]
Its not a great reason, but its nice that they gave a reason at all (none is actually required to remove a PROD). The next step would be opening a talk page discussion on notability, hopefully the editor who removed the PROD is willing to work with you to find sources and if not will be willing to support a move towards AFD. Horse Eye's Back (talk) 08:15, 5 January 2024 (UTC)Reply[reply]
I did talk page them, but they never responded. I get the need for collab, but often it can just become unintentional filibustering Yr Enw (talk) 09:19, 5 January 2024 (UTC)Reply[reply]
What if the concepts of WP:BLPPROD were expanded to non-BLPs without any sources? At a minimum, a deprod could be required add one reliable source.—Bagumba (talk) 08:35, 5 January 2024 (UTC)Reply[reply]
This might be the best option. I wasn't even aware of the WP:BLPROD policy myself, but having a similar policy apply to unsourced articles would allow for both one, editors to more quickly sift through unsourced articles, and two, editors who want to do specialized research to find obscure sources for articles that are proposed via this hypothetical process. If no sources can truly be found, reliable or otherwise, then it would be an uncontroversial deletion that would be able to avoid the lengthy WP:AFD process. Tooncool64 (talk) 08:43, 5 January 2024 (UTC)Reply[reply]
Support this idea myself as well. Let'srun (talk) 15:06, 6 January 2024 (UTC)Reply[reply]
Well, I don't. AfD exists for a reason: inclusion criteria are based on whether sources exist, and whether it's possible to write an article on a subject. They aren't based on whether Bill has time tomorrow afternoon to go get an interlibrary loan and then drive out to pick up eighteen books and spend the entire evening going through to frantically reference 53 articles before the guillotine falls. AfD lasts seven days. If an AfD is relisted because of lack of participation, it means that there isn't enough volunteer effort available to properly assess the article. If there isn't enough volunteer effort available to properly assess an article...there isn't enough volunteer effort available to come to a firm conclusion that the topic is non-notable. jp×g🗯️ 09:39, 6 January 2024 (UTC)Reply[reply]
If someone wants to re-create the article in the future with sources, then more power to them. It would be a soft-delete, allowing an editor to re-create the page. Tens of thousands of these articles have no reason to exist, no content, no usability for information. Like I said previously, Wikipedia is not meant for collecting items that exist. Tooncool64 (talk) 10:02, 6 January 2024 (UTC)Reply[reply]
Well, it's not meant to be a shoot-em-up game either -- the fact that deleting articles causes an enjoyable sensation on the back of the neck isn't a reason to do it. There are plenty of reasons why stubs exist. They're written by someone who had access to some information, or maybe to a lot of information, but who for whatever reason wrote a very short article; for the vast majority of them, it's completely possible to write something longer. If it's not, and the article is such a turd it needs to be wholly extirpated from the project, we have AfD, which sees approximately fifty nominations per day, with a turnover of somewhere around a week. In fact, we also have draftification, PRODs and speedy deletion -- that makes four separate processes by which stuff can be taken out of mainspace if it's bad. Why do we need another? jp×g🗯️ 10:33, 6 January 2024 (UTC)Reply[reply]
I can completely understand why many people where against this in the way it was worded. If an unsourced PROD were to exist, it would need to have at the very least a 7 day time limit, like current WP:PROD. The major reason I am in favor of something like this is because I believe, at the very least in 2024, articles on Wikipedia need to have sources, even if it is just one. No article would pass WP:AFC without sources attached. Tooncool64 (talk) 08:59, 5 January 2024 (UTC)Reply[reply]
Thanks for pointing that one out. After a quick glance, it seems it involved a new tagging process that people objected to, as opposed to just expanding a known process, PROD. The proposal just waved at a link, and some likely thought TLDR or made some wrong assumptions, and rejected for that reason. Not saying this would necessarily pass, but an improved presentation and concise pitch could go a long way. —Bagumba (talk) 09:18, 5 January 2024 (UTC)Reply[reply]
Yep. I tried an RfC on that. Snow-opposed. (Although the wording was really badly done, as I recall, so everyone was at least moderately confused.) 🌺 Cremastra (talk) 00:42, 7 January 2024 (UTC)Reply[reply]
This is close to becoming a perennial proposal. Policy is the way it is a foundational principle of this project is that imperfect content is an opportunity for collaboration, not something that needs to be expunged. If you instead choose to look at articles that fellow volunteers have taken the time to write as a "garbage dump" and deletion as the preferred way of dealing with them, then of course you're going to meet friction. – Joe (talk) 09:05, 5 January 2024 (UTC)Reply[reply]
My rhetoric might be harsh, but unfortunately, many of these unsourced articles are tens of thousands of one sentenced geography stubs, that may or may not even meet WP:NGEO, or tens of thousands of unsourced "Topic in Year" articles. If you are looking at these articles as part of a maintenance category, which they are, then you are forced to realize that many of these are not worth keeping, if for the very fact that they are unusable for information. Tooncool64 (talk) 09:13, 5 January 2024 (UTC)Reply[reply]
Clearly at least one person disagreed with you about that, or the articles wouldn't exist. – Joe (talk) 10:01, 5 January 2024 (UTC)Reply[reply]
Unfortunately, the standards for creating articles was much lower back in the day. Tooncool64 (talk) 10:04, 5 January 2024 (UTC)Reply[reply]
That's amazing how much hard work and care went into those articles! If an editor in the future wants to re-create an article that was deleted via this hypothetical process, it wouldn't be difficult. We do not need to hoard unsourced articles currently for the possibility in the future that they may be found to be notable. Tooncool64 (talk) 10:03, 6 January 2024 (UTC)Reply[reply]
Yes it will: our hypothetical editor will have to notice that something's a redlink (from where?), look through the deletion log, ask the deleting admin for a WP:REFUND, wait on a response, and then get it restored to their userspace or draftspace. This is a rather long and complicated process that, generally, only power users are able to do. What concrete benefit is brought by forcing them to go through this? jp×g🗯️ 10:33, 6 January 2024 (UTC)Reply[reply]
Or they can just...create the article themselves without going through REFUND... The difference between expanding and de novo creating a 1-sentence stub is like, the one minute it takes to create a 1-sentence stub... An admin could literally paste the entire REFUND of the text in an edit summary, it's not like we're talking about valuable starting material here. JoelleJay (talk) 18:24, 6 January 2024 (UTC)Reply[reply]
Creating a new article on a title that has been deleted before requires one to know that one is encouraged to recreate some, but far from all, deleted articles. The box that comes up for all deleted content is far from encouraging. Espresso Addict (talk) 11:13, 7 January 2024 (UTC)Reply[reply]
The problem in that regard is that the way PROD is set up collaboration is "encouraged, but not required." Why not require collaboration as a requirement of challenging a PROD? Horse Eye's Back (talk) 09:17, 5 January 2024 (UTC)Reply[reply]
The fallback collaboration option is a formal AfD. PROD offers some rare opportunites for lightweight deletions if nobody is looking or people agree and don't contest, but a WP:REFUND is typically possible. —Bagumba (talk) 09:24, 5 January 2024 (UTC)Reply[reply]
TBH I think the ideal collaboration option is actually in between the two... A talk page discussion should be able to settle the issue the vast majority of the time... If the challenger was required to open a talk page section with their rationale (preferably in the form of sources) I think that would go a long way towards facilitating collaboration without the wounded feelings that jumping to AfD can cause. Horse Eye's Back (talk) 09:35, 5 January 2024 (UTC)Reply[reply]
Honestly I consider PROD a failed experiment at this point. The grey zone between CSD and AfD is just too narrow to support an extra process, and the awkward process (add a template, wait a week, keep checking back in case it's removed and you need to turn it into an AfD) makes it useless for anybody who's patrolling articles en masse. – Joe (talk) 10:03, 5 January 2024 (UTC)Reply[reply]
I would love to see some statistics on PROD... What percentage get challenged... What percentage of those go to AfD... What percentage of those survive AfD... Horse Eye's Back (talk) 10:12, 5 January 2024 (UTC)Reply[reply]
The problem is that nominating an article for prod takes a few seconds, and editors often nominate many in a short space of time. Finding a source will often take hours or more, and needs to be specific to the article in question. They are not symmetrical operations. Espresso Addict (talk) 00:55, 6 January 2024 (UTC)Reply[reply]
The creator of the article can take as long as they need to find sources, years even. There is no need to create the article in mains space to work on it, it can be done in draft or namespace . Horse Eye's Back (talk) 10:15, 6 January 2024 (UTC)Reply[reply]
No problem with requiring sources for new articles, but we're talking about the backlog of old ones here. Espresso Addict (talk) 11:07, 7 January 2024 (UTC)Reply[reply]
There has never been a time when that wasn't true, its as true of the old ones as the new ones... If the creator didn't want them judged by mainspace standards they wouldn't have created the article in mainspace. Horse Eye's Back (talk) 15:52, 7 January 2024 (UTC)Reply[reply]
Requiring a source be added to dePROD an unsourced article would be ideal. JoelleJay (talk) 20:14, 5 January 2024 (UTC)Reply[reply]
oppose incredibly strongly. Merge and redirect them if you can't source them rather than run them through afd. Deletion isn't clean up. If the merger is undone, build consensus for the merge. Job done. There's no deadline. We don't need to constantly revise the rules to do the work, we just need to use the rules we've got to make Wikipedia better and coach the editors around us on the way to use the tools. Merge. Redirect. Build consensus that that's the right approach.HidingT 22:05, 5 January 2024 (UTC)Reply[reply]
Oppose. Haven't we discussed this recently? The existing procedures (prod, then AfD if challenged) are adequate for removing nonnotable unsourced material. Espresso Addict (talk) 00:32, 6 January 2024 (UTC)Reply[reply]
I think this is a bad idea for the reasons I've explained above. jp×g🗯️ 09:44, 6 January 2024 (UTC)Reply[reply]
Oppose. This proposal is not compatible with WP:NEXIST or WP:ATD. The topic of an unsourced article is often notable. The content of unsourced articles is often accurate and verifiable. In fact, the content of unsourced articles is often WP:BLUE. James500 (talk) 11:40, 6 January 2024 (UTC)Reply[reply]
“The content is often WP:Blue”… really? prove it! 😉 Blueboar (talk) 15:13, 6 January 2024 (UTC)Reply[reply]
So your suggestion is to merge unsourced material elsewhere...? JoelleJay (talk) 22:07, 6 January 2024 (UTC)Reply[reply]
If the info is unsourced, then we shouldn't be merging it anywhere. Lee Vilenski(talk • contribs) 00:47, 7 January 2024 (UTC)Reply[reply]
Nah, part of the merge process is either sourcing what is unsourced or discarding it and improper for merging. This discussion is about entire erstwhile articles with no sources, not about snippets of text without sources in articles that otherwise are sourced. — SMcCandlish☏¢ 😼 03:14, 7 January 2024 (UTC)Reply[reply]
Merge and redirect them if you can't source them is directing us to merge the unsourced content of an unsourced article into another article. JoelleJay (talk) 18:44, 7 January 2024 (UTC)Reply[reply]
Oppose. I agree with Hiding, above. We aleady have the policies we need; what we lack is editorial focus to get the job done. — SMcCandlish☏¢ 😼 03:14, 7 January 2024 (UTC)Reply[reply]
My idea would be to increase the “unsourced article deletion” time to 60 days. Then I would probably accept it. 71.239.86.150 (talk) 20:08, 7 January 2024 (UTC)Reply[reply]
RfC: Should a special PROD category, similar to WP:BLPROD, be created for unreferenced tagged articles?
Should a special PROD category, similar to WP:BLPROD, be created for unreferenced tagged articles? Tooncool64 (talk) 06:33, 8 January 2024 (UTC)Reply[reply]
This category for deletion would have four caveats.
1. Articles could be removed from this process by having at least one sourced attached to it, removing the unreferenced tag.
2. Articles held within this category would not be deleted until 30 days have passed, hopefully allowing editors ample time to go through these articles and potentially find sources.
3. This would not be an automatic process. Unsourced articles would optimally be only tagged for this special PROD after editors have looked for a source and have failed to find one.
4. This proposed PROD policy would not supersede WP:AFD or WP:CSD.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
RfC on capitalization in "NFL Draft"/"National Football League draft" etc.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Regarding the capitalization in "NFL Draft"/"National Football League draft" etc., should it be capitalized "Draft", or lowercase "draft", in article text and titles? With what exceptions, if any? 03:46, 6 January 2024 (UTC) Dicklyon (talk) 03:46, 6 January 2024 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Getting the name of an article right can sometimes make a big difference in readership. My example is the article Society of Jesus which from July 1, 2015 until August 22, 2022 was viewed 181 times per day. The name of the article was changed (with substantial opposition to the change) to Jesuits on August 23, 2022 and the article was viewed 1,685 times per day from then until January 7, 2024. I can't think of any explanation except the name change for the sudden increase in readership. Smallchief (talk) 14:34, 8 January 2024 (UTC)Reply[reply]
I'm fairly certain of two things Smallchief: 1) that this is not the right place for this discussion and 2) that you have misunderstood how the pageviewer tool interprets redirects (this link may help). ~~ AirshipJungleman29 (talk) 14:57, 8 January 2024 (UTC)Reply[reply]
I'm fairly certain (1) I don't understand what you're trying to say and (2) if naming articles isn't part of policy what is? Smallchief (talk) 16:07, 8 January 2024 (UTC)Reply[reply]
(1) What AirshipJungleman29 is saying is that the reason not many people were visiting Jesuits prior to 22 August 2022 is that the article was at Society of Jesus; if you look at the pageviews for that article from 2015 until the page was moved ([9]), you will find that it averaged 2,340 views/day. (2) There is indeed a policy regarding article names, but there are policies regarding everything on Wikipedia; WP:VPP is for proposing new policies or changes to existing policies and it is not clear what, if anything, you are proposing should change about our article naming policies. Caeciliusinhorto (talk) 20:38, 8 January 2024 (UTC)Reply[reply]
You can see the effect of the move quite neatly if you combine the two graphs - basically they just switched places overnight. The new page gets a higher proportion of its traffic through the redirect than the old one did, presumably because of links left at the old name, but the total is approximately steady for the two combined.
You can also see the effect of the pageviews including redirects - ie Jesuits plus all pages that currently redirect to it. This graph confirms no particular change in the traffic totals for that group of pages. Andrew Gray (talk) 12:50, 11 January 2024 (UTC)Reply[reply]
I think the question is "Since most of our traffic comes from web search engines, should we consider SEO factors and Google ranking when we choose article titles?" WhatamIdoing (talk) 00:17, 10 January 2024 (UTC)Reply[reply]
My answer would be: no, Wikipedia:Article titles is fine for helping readers find what they are looking for. Also, I think Wikipedia will outlast Google Search - we're already seeing how LLMs might make the "search results ranking" paradigm obsolete. No need to compromise our policies and guidelines at all, especially since we're already ranked #1 for a great many searches anyway. Barnards.tar.gz (talk) 13:58, 11 January 2024 (UTC)Reply[reply]
@Barnards.tar.gz, given that most of our traffic comes from external web search engines, are we actually "helping readers find what they are looking for" if we are not using article titles that are more likely to appear in external web search engine results? WhatamIdoing (talk) 18:42, 16 January 2024 (UTC)Reply[reply]
Transfer of user's sysop status
This is going in circles and is quite off topic from the the purpose of this noticeboard, also noting that policies on other editions of Wikipedia are not in scope here. Quick summary: There is no technical mechanism to "transfer" access from one account to another. Users with the ability to manage permissions may technically add and remove permissions groups from accounts individually. The policy regarding gaining administrator access on this project is available here. Extreme edge cases could arise, such as during complicated account renames or other situations and would be examined on a case-by-case basis at WP:BN. — xaosfluxTalk 15:58, 11 January 2024 (UTC)Reply[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Is it possible to transfer sysop status from one user account to another. For example if we have a case where someone originally have 3 different accounts on different wikis, say enwiki, jawiki, and jvwiki. Over time, this user gains a sysop status on two of three wikis not at the same time. At some point, this user wants to unify its sysop status from one wiki to the other, so it turns that he has two accounts where one of which has sysop status on two wikis.
After all, is it possible? Sorry for my bad English, thanks. Natsuikomin (talk) 00:26, 10 January 2024 (UTC)Reply[reply]
It's "possible" in that 'crats or stewards could remove the sysop group from one account and add it to another. The hard part would be in convincing them to do so. The person would need to have discussions on each different wiki, convincing each community that the transfer makes sense for them. Anomie⚔ 02:03, 10 January 2024 (UTC)Reply[reply]
What do you mean by "make sense for them"? Natsuikomin (talk) 02:16, 10 January 2024 (UTC)Reply[reply]
You would have to convince someone with the ability to create an administrator to do so. The tricky bit might be proving that the person who originally controlled an account when it became a sysop was the same person who currently controls the account wanting sysop. At any rate, that would be an issue for the particular project and the way they do things. Johnuniq (talk) 03:14, 10 January 2024 (UTC)Reply[reply]
Besides that, should he coordinate with local sysops, or can he simply make a single global request, say through Wikimedia to enable the transfer to be done on any wikis which its separate acccounts would be affected on? Natsuikomin (talk) 03:38, 10 January 2024 (UTC)Reply[reply]
And regarding whether or not the two accounts are controlled by the same person, wouldn't the administrator simply delete the old account to prevent it from being used by other individual?
And if the administrator worries that the transfer could enable other unqualified person to have the sysop right, isn't it still possible to happen, for example a naughty current sysop gives its username and password to unknown person without having to make a request for transfer? Natsuikomin (talk) 03:43, 10 January 2024 (UTC)Reply[reply]
Sorry, I don't know and I think only a very small number of people would have experience with that. The rest of us would be guessing. Here, at enwiki, WP:RFA should be satisfied and I suspect there would be an uproar if a person were elevated to sysop without prior community scrutiny. You might try asking at WP:AN or perhaps one of the WP:ARBCOM pages. If trying that, post in one place only. Accounts are never deleted. Instead, an unwanted account might be indefinitely blocked or perhaps globally locked. An admin who was found to have handed out their password would never hold advanced rights again. I suspect indefinite blocks would be in order. Johnuniq (talk) 03:49, 10 January 2024 (UTC)Reply[reply]
So, it's possible. I haven't found out how, but I will search for it later. Thanks for the help. Natsuikomin (talk) 12:08, 10 January 2024 (UTC)Reply[reply]
These are examples from EN-Wiki, though. OP, am I correct in assuming that you would like to have sysop rights in all different language accounts you mentioned, but only passed the process for becoming one in 2 of them? Lectonar (talk) 12:24, 10 January 2024 (UTC)Reply[reply]
No, I meant to say that I already have sysop status on 2 of 3 accounts (meaning sysop status on 2 of 3 wikis).
Note: I don't have sysop status on any wikipedia sites at the moment. It's just my curiosity about the possibility of such a transfer process. Natsuikomin (talk) 12:44, 10 January 2024 (UTC)Reply[reply]
Yes, that's what I understood. And you want it on the 3rd too? Lectonar (talk) 12:46, 10 January 2024 (UTC)Reply[reply]
We can only answer questions about the English Wikipedia here. To become an admin on this Wikipedia you need to go through WP:RFA, as explained at WP:Administrators#Becoming an administrator. It does not matter how many other Wikipedias may have given you admin status. Anything else should be asked at the Wikipedia concerned or at meta:. Phil Bridger (talk) 13:00, 10 January 2024 (UTC)Reply[reply]
I don't know guys why some of you think that I was asking about how to become an admin on certain wiki site. All I was wondering about was the possibility of sysop status transfer. And all of your responses have explained it so well. Thanks a lot! Natsuikomin (talk) 13:23, 10 January 2024 (UTC)Reply[reply]
If I understand right you're asking about having an account with sysop rights on a different wiki, while you use a legitimate alternate account to edit this wiki which is later promoted to sysop here. So then you have two accounts with sysop rights on different wikis, and you want to transfer your enwiki sysop rights from the alternate account to your main one. Sure you can, a bureaucrat would just remove the userright from the alternate account and add it to the main one. As long as we can verify that you control both accounts (probably we would run checkuser to check) I don't see why the request would be declined. Ivanvector (Talk/Edits) 13:48, 10 January 2024 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This "guideline in all but name" has been remarkably stable for a long period of time, and is actually followed. I.e., it already is used by consensus as a guideline.
It is written in guideline-appropriate language already and does not need substantive revision, aside from removing a handful of self-references to WP:WikiProject Computer science (or user essays therefrom).
It has various "MOS:SOMETHING" shortcuts to it which are accepted in use and treated like any other; a 2022 WP:RfD to delete them closed with a consensus to keep.
Most of our topic-specific MoS pages originated this way, as wikiproject style advice pages and were moved to be integrated into MoS later.
A competing essay, now at Wikipedia:Manual of Style/Computing (failed proposal), was firmly rejected by consensus (even proposals to keep a few elements of it were rejected), while the page under discussion here was kept and praised.
If promoted, it definitely should be part of MoS as a site-wide guideline, not something held within a particular wikiproject (per WP:CONLEVEL and WP:POLICYFORK); same as with all the other topic-specific MoS pages and naming-conventions guidelines already.
This should not be interpreted as a proposal to elevate any other wikiproject style essays. Those that were viable have already been merged into MoS, and the rest seem to be disused and even problematic (though some might be reparable). This is the lone straggler, and I meant to nominate it years ago but forgot or pushed it off.
Having wikiproject style essays laying around as neither incorporated into MoS nor deprecated as {{Historical}} or {{Rejected}} is a hazard; cf. this RM in which a non-admin closer incorrectly came to a "no consensus" decision when people cited a wikiproject essay that contradicts both MOS:& and WP:COMMONNAME policy, as if the essay was coequal with side-wide article title requirements. Policy-forking often happens at pages like that essay (since corrected) when they are not part of MoS and thus don't get watchlisted by the guideline-shepherding editorial pool.
PS: MOS:COMPUTING, MOS:COMP, WP:MOSCOMP, and perhaps a few other shortcuts that currently point to the failed proposal should be usurped to redirect to the "new" guideline after the change. PPS: I have had almost no input into the page myself other than minor cleanup.
— SMcCandlish☏¢ 😼 13:54, 12 January 2024 (UTC); rev'd. 18:55, 12 January 2024 (UTC)Reply[reply]
Survey (MOS:CS)
Support as nominator, of course, and willing to do whatever cleanup is needed. — SMcCandlish☏¢ 😼 18:55, 12 January 2024 (UTC)Reply[reply]
Support seems fine, generally in favor of making it clear what pages are actually guidelines (with consensus support) and what pages aren't. Galobtter (talk) 21:57, 12 January 2024 (UTC)Reply[reply]
Support. A good summary of what we currently expect for computer science related pages. 0xDeadbeef→∞ (talk to me) 05:25, 13 January 2024 (UTC)Reply[reply]
Discussion (MOS:CS)
I find the statement The article should start with an introductory paragraph (or two) to be in a bit of tension with MOS:LEADLENGTH, which explicitly recommends larger leads for larger articles. If promoted, would this advice be removed, or modified to be in line with the general lead length guidance? — Red-tailed hawk(nest) 15:49, 12 January 2024 (UTC)Reply[reply]
Sure, any glitches like that would have to be normalized to agree with central guidance that governs it, like LEADLENGTH in this case. I figured I would probably miss something or other in going back over it before nominating. We don't tolerate WP:POLICYFORKs, so any such issues would have to be ironed out. — SMcCandlish☏¢ 😼 16:44, 12 January 2024 (UTC)Reply[reply]
Fixed. Also updated the lead paragraph example to agree with the current version of the selected article.[10] — SMcCandlish☏¢ 😼 16:56, 12 January 2024 (UTC)Reply[reply]
Some of the example articles seem to be outdated or aren't actually best examples we have in those subareas. For algorithms, binary search is a featured article on this topic, compared to Quicksort which is B-class. For programming languages, Python is C-class, and IIRC the best we get on programming languages is Rust, which is a GA. 0xDeadbeef→∞ (talk to me) 16:45, 12 January 2024 (UTC)Reply[reply]
Which other examples did you want to replace with which? Happy to do it, or you could just have at it. I don't think replacing the examples with better ones (or updated versions of the same ones, when quoting examples) would be substantive (i.e. no WP:PGCHANGE concerns). — SMcCandlish☏¢ 😼 16:58, 12 January 2024 (UTC)Reply[reply]
Many computing articles date from the early years of Wikipedia when sources weren't required; in particular if material was in textbooks was not thought necessary to provide sources. The result is much unreferenced material in these articles, which is becoming problematic. The proposed guideline says
It is quite important for an article to have a well-chosen list of references and pointers to the literature.
Can this be made more in line with current policy? The math guideline says
Per the Wikipedia policy, WP:VERIFY, it is essential for article content to have inline citations, and thus to have a well-chosen list of references and pointers to the literature.
Done, though in more specific terms [11] that reflect the policy better (inline citations are only required for specific sorts of things). — SMcCandlish☏¢ 😼 23:26, 12 January 2024 (UTC)Reply[reply]
I like that better than my suggestion. I am a member of the decreasing number of editors who believes "likely to be challenged" means "likely to be challenged as incorrect" rather than "likely to be challenged, even if correct, because there is no inline reference". StarryGrandma (talk) 05:15, 13 January 2024 (UTC)Reply[reply]
One would certainly hope the former continues to prevail. — SMcCandlish☏¢ 😼 08:30, 13 January 2024 (UTC)Reply[reply]
If this is to become part of the MOS, can we drag ourselves into the 21C and get rid of the insane prohibition on using binary prefixes? Adding a short paragraph would be sufficient to explain the difference between and to note that the SI prohibits the use of decimal prefixes with a binary meaning. Martin of Sheffield (talk) 10:00, 13 January 2024 (UTC)Reply[reply]
Would be a substantive change and something to propose in a separate RfC (also advertised at WT:MOSNUM, where this has been argued to death for over a decade). It's been a while, so it's vaguely possible that consensus could have changed on this question, though I doubt it. — SMcCandlish☏¢ 😼 20:43, 14 January 2024 (UTC)Reply[reply]
I fear that you are right in the assumption that the usual suspects would pile in and the sheer number of !votes would guarantee that nothing is done. It's really quite odd how we have metric measures forced on us by the SI enthusiasts - until - something that the SI bans but they like is mentioned! Maybe try again in another decade. :-( Martin of Sheffield (talk) 21:21, 14 January 2024 (UTC)Reply[reply]
I don't think including a "overview" section is something that I have seen in a lot of CS articles. Most articles will call this section a "background" section and what is being described as a "motivation" section is normally included with the history section. (Also maybe we can give a example of such usages of background sections (I'd personally say Small_set_expansion_hypothesis or maybe Cross-site leaks ?)
I'd also like to see some discussion on the use of self-published wiki/book content/blog posts from primary sources in the references section. (for example, referencing a blog post/ from the Rust development team is fine when specifically describing the internal architecture of the Rust compiler, or the motivation behind a specific issue with language design of Rust, however, it is discouraged in most other cases for example when describing Rust benchmarks or the features that set it apart from x language etc). Sohom (talk) 15:16, 13 January 2024 (UTC)Reply[reply]
On the sectioning matter, probably need to look at what GAs/FAs in the topic are doing and see how to update that material a bit. On the primary/secondary point, can you suggest some specific wording to use? — SMcCandlish☏¢ 😼 20:43, 14 January 2024 (UTC)Reply[reply]
If I were to start writing a CS article, I'd be seriously confused by Wikipedia:WikiProject_Computer_science/Manual_of_style#Design_patterns. It's one sentence that links to an article about a book; is the article the example to follow (even though it's tagged for layout issues)? Or am I expected to get this book to learn how to format an article about design patterns? I think that subsection either needs to be expanded to be more descriptive or removed. Schazjmd(talk) 15:30, 13 January 2024 (UTC)Reply[reply]
This well known book follows a very specific pattern when describing each design pattern See the entry about "Abstract Factory" I think following the pattern used by the book is what the guideline is talking about here. Sohom (talk) 18:04, 13 January 2024 (UTC)Reply[reply]
Thanks for explaining, @Sohom Datta. I think this subsection would be more useful if it provided a descriptive summary of the pattern used by the book. Schazjmd(talk) 18:13, 13 January 2024 (UTC)Reply[reply]
The Gamma, Helm, Johnson & Vlissides ("Gang of Four") book (1994, O'Reilly; also 1995, Addison-Wesley) is findable online in full text easily, but it's unclear whether any of the copies are legit (I'm skeptical). There are "cheatsheet" summaries available on various websites, similar to citation-style cheatsheets findable at various universities, etc. There are a lot of such patterns, and our page would get long if it tried to address all of them, so referring people to the book, to our own article on it and the specific-pattern articles we already have, and to some good cheatsheets, are likely to be the best we can do. The patterns themselves might actually call for additional mainspace material, i.e. expand on what's covered at Design Patterns#Patterns by type and the articles linked therefrom, but that's an separate article-development matter. A similar book with a similar title by Pree (1995, Addison-Wesley) is available for free reading via IA [12]. Weirdly, IA does have the 1998 CD-ROM that goes with the Gang of Four book [13], but not the book itself. — SMcCandlish☏¢ 😼 20:43, 14 January 2024 (UTC)Reply[reply]
Then at least can we say explicitly to follow the examples in the book? Just linking to the article about the book, "The classic GoF format is a good guideline for the structure of an article describing a design pattern.", is decidedly unhelpful. Schazjmd(talk) 20:53, 14 January 2024 (UTC)Reply[reply]
Yes, that seems easily doable, and I might link in a "cheatsheet" as a ref. — SMcCandlish☏¢ 😼 01:23, 16 January 2024 (UTC)Reply[reply]
I have a two-part question about removing content from an article talk page. I have read the talk page guidelines, and I don't think that they clearly answer my questions. I am not asking about a specific case of removing content from a talk page, but two more general questions. I am trying to mediate a dispute at DRN where one editor has removed a large amount of material (26Kbytes) from an article talk page that had been posted by another editor. The author who is doing the removing cites WP:FORUM, WP:NOTHOWTO, and WP:OR. I read the talk page guidelines, and they are clear that removing material from a talk page should not normally be done, but occasionally should be done, but they provide poor guidance for gray area cases.
My first question is where can the editor whose material was removed discuss it? DRN is a noticeboard to discuss article content, not talk page content. If an editor had removed paragraphs from an article citing undue weight or balance or unreliable sources, we could have moderated discussion. However, removal of talk page content isn't what DRN is for. Where should the other editor or I go to discuss? I don't like to advise editors to go to WP:ANI; I'm a content mediator. My second question is whether the talk page guidelines talk page is the right place to discuss the lack of clarity of the guidelines about removal of content. I assume that it is the right place, but am asking. (I could say that I don't want my post removed, but that would be half-humorous and half-serious.)
Robert McClenon (talk) 20:57, 15 January 2024 (UTC)Reply[reply]
Given the non-specific title of DRN, can't the DRN mediator mediate any on-wiki dispute? If you don't feel comfortable mediating a certain issue, can't you pass it on to another editor? Mediators need not be particularly specialized, or knowledgeable beforehand, in the nature of the content being disputed itself.
As to the Talk page guidelines page, I'd say yes, or at least just start a thread there now while you're fresh, and if someone thinks of a better forum you can move it later. It's about time the issue gets dealt with. I revert a lot of Talk page removals, and it often comes down to a fundamental difference of philosophy that guidelines could probably trod into. SamuelRiv (talk) 00:16, 16 January 2024 (UTC)Reply[reply]
Looking at the specific dispute, they're both newbies, so we can't assume that they know what's appropriate (unless one or more is a sock). Getting the page semi-protected for a couple of weeks might solve that dispute by leaving it to editors more familiar with our usual practices (@I dream of horses being already on the spot). Semi'ing the page would also help the remover stop exposing their IP address. WhatamIdoing (talk) 18:33, 16 January 2024 (UTC)Reply[reply]
User:WhatamIdoing - You say that the editors in the specific dispute are both newbies. Either you are looking at a different dispute, or you are looking at different editors than I was, or you have a different definition of a newbie than I do. I avoided naming the dispute because I wanted the advice to be generic rather than about the specific dispute, but I should have known that some editors would think that I was looking for dispute-specific advice, and dispute-specific advice is helpful, just not what I thought was important. I was asking about the ZX Spectrum_graphic_modes dispute, where the editor who removed the talk page posts has 37,000 edits, which I don't consider a newbie. If you were looking at the IP editor and the editor who filed the DRN dispute, they are probably the same person, who registered an account after making some IP edits. It was the experienced editor who removed the talk page posts. If you are looking at the Kapersky dispute, then it is true that both editors are new editors who are editing this article for the first time, but that dispute doesn't involve talk page removal. So which dispute were you looking at? Robert McClenon (talk) 20:23, 16 January 2024 (UTC)Reply[reply]
It turns out that I was looking at a different dispute at DRN, which involved two edit-warring accounts that both have less than 20 edits.
For this removal, I think the experienced editor is correct, and the former IP should be redirected to a site like Stack Overflow, or to a magazine that might be willing to publish an actual article written by the former IP. The removed content is not really about improving the article. WhatamIdoing (talk) 20:40, 16 January 2024 (UTC)Reply[reply]
Okay. I thought it might be that. In the specific case, the Kaspersky article, which was the subject of the edit-warring, has been ECP-protected as a contentious topic. What I was asking was where or how to discuss disputes over talk page removal. You, User:WhatamIdoing, have offered your opinion in the specific case, that you agree with the removal. But how or where should talk page removals be discussed? One editor suggested that I treat the talk page dispute as a content dispute and offer to mediate it. Another editor offered the compromise of archiving the material. Are there any other answers? Sometimes I am not asking about a tree but about the forest. Robert McClenon (talk) 21:10, 16 January 2024 (UTC)Reply[reply]
Sorry WhatamIdoing, but how is the removal in any way correct? Half the time the IP editor is referring back to changes they are in the process of, or have made to, the article. They are using the Talk page for one of the purposes we say to use it for -- explaining potentially contentious edits (like, say, if an IP editor started changing numbers around in the article, which are exactly the edits these Talk comments are explaining!)
We shouldn't be getting into the specifics of this particular dispute if OP is going to be mediating it anyway (and OP is not asking about the particulars of this dispute), but there you did. SamuelRiv (talk) 22:18, 16 January 2024 (UTC)Reply[reply]
"I think I have found a way to faithfully simulate the output image of the ZX Spectrum on a PAL TV. Of course, different TV sets produce different images, so it can only be an approximation. Descibed below is a much better approximation than the images currently displayed in the article. That's why I'm writing this, for anyone who has sufficient spare time, to use this procedure to produce a more realistic output images."
Does that sound like explaining anything about editing the article, or does it sound like hacking your own device at home? WhatamIdoing (talk) 22:33, 16 January 2024 (UTC)Reply[reply]
It sounds like IP intends to describe a "procedure to produce a more realistic output images" which would be "a much better approximation than the images currently displayed in the article." In other words, how to make the images better, and in previous posts why the current images and descriptions are not accurate. I cannot comprehend how you get from this that it's about hacking one's home device -- "faithfully simulate the output image". SamuelRiv (talk) 22:46, 16 January 2024 (UTC)Reply[reply]
Sometimes these things can be "chilled out" a bit by moving the off-topic or otherwise inappropriate material to the most recent talk-page archive. It's "softer" than just a reversion. — SMcCandlish☏¢ 😼 20:57, 16 January 2024 (UTC)Reply[reply]
Thank you, User:SMcCandlish, for suggesting what sounds like a compromise about talk page removal, to archive the material rather than arguing over whether to keep it or delete it. That is a generic answer that is also applicable in this specific case. Robert McClenon (talk) 21:10, 16 January 2024 (UTC)Reply[reply]
I think that contents of a talk page are normally discussed on that same talk page. WhatamIdoing (talk) 22:01, 16 January 2024 (UTC)Reply[reply]
Do we really need over 600 articles on individual Samsung products?
See here; over 300 of these are Samsung Galaxy models. I'm sure they're fine products and all, but an awful lot of these articles are on the short side, and an awful lot seem to be doing little more than listing the qualities of the product. There are too many similar examples to consistently handle this piecemeal, and too many articles for an individual editor to handle. BD2412T 22:59, 15 January 2024 (UTC)Reply[reply]
My feeling is that this is an awfully good time for WP:NOPAGE to be invoked and for articles of products of the same series to be merged. ~~ AirshipJungleman29 (talk) 23:20, 15 January 2024 (UTC)Reply[reply]
My position is that whenever there are many similar short articles, they should be combined into a longer article or list that covers all of them (see WP:NOPAGE and WP:HASTE). Thebiguglyalien (talk) 23:21, 15 January 2024 (UTC)Reply[reply]
Looks like many of those could be combined into larger articles and soec comparison tables. Lack of any discussion of individual models also begs why the need for separate articles. — Masem (t) 23:22, 15 January 2024 (UTC)Reply[reply]
I agree with the various comments about combining these up, but it's a lot. Is there a WikiProject or task force that would take this on? BD2412T 23:53, 15 January 2024 (UTC)Reply[reply]
Let's take a look at that AfD. The first keep vote says he added two sigcov sources; looking at the diff, he added two links to listicles as bullet points in the references section and then coupled it with an WP:OTHERSTUFFEXISTS argument. (least surprisingly of all, this person is a legacy admin). The second keep vote is just a plain WP:OTHERSTUFFEXISTS argument. The third keep vote asserted that it meets GNG because of the listicles and because it has a "notable design". It was then closed as keep without relisting by another legacy admin. Thebiguglyalien (talk) 02:38, 16 January 2024 (UTC)Reply[reply]
Yep, that was my Surprised at the arguments made comment, although DRV would be fruitless as there was no other way to close that. I missed that OwenX was an Admin, however. StarMississippi 02:54, 16 January 2024 (UTC)Reply[reply]
In my opinion, the best option would have been to relist with a warning that WP:ATAs would not be given serious consideration when closing, and we really need to start clamping down on !votes that cite weak sourcing as GNG. Getting back to the issue at hand, there's really not much in terms of precedent for combining groups of articles, even though it's something we should be doing more often. I tried to do this with List of mass stabbing incidents (2020–present), but months later someone went back through my edits to undo all of the merges because "no consensus", so now in many cases the smaller pages duplicate the content on the larger page. That's in addition to the fact that most of these only have routine coverage and don't meet GNG in the first place. If such a combination were to take place with the Samsung Galaxy A7 articles, for example, what would the first step be? And what would the target article look like? Thebiguglyalien (talk) 03:34, 16 January 2024 (UTC)Reply[reply]
The first step to merging the A7s would be identifying the merge target, which would probably best be Samsung Galaxy A7 (2015), which is the oldest and was originally named Samsung Galaxy A7. The articles are short enough that they'd work simply as subsections of a model/edition section. There could even be a summary table as there is by year at Samsung Galaxy A series. CMD (talk) 03:58, 16 January 2024 (UTC)Reply[reply]
I'm puzzled by all this handwringing at the possibility of merges being opposed for not having consensus and what to do about it. The answer is simple: get consensus. Wikipedia:Proposed article mergers exists for exactly this purpose - make a proposal, advertise it here and at any relevant WikiProjects then after a couple of weeks (or sooner if it starts snowing) ask someone uninvolved to close it. If there is consensus for the proposal then go ahead and implement it, if there isn't then either just move on or listen to the feedback you got and make a revised proposal. Thryduulf (talk) 14:46, 16 January 2024 (UTC)Reply[reply]
I agree with this. The correct procedure in cases like this, I think, is to propose a merger at the relevant location and, if/when the merger attains consensus, perform the merges (and redirects - leaving categorized redirects, I would hope). The problems encountered previously, I suspect, result from using AfD as a venue - it is profoundly ill-suited to making the kinds of decisions required here. Newimpartial (talk) 17:50, 16 January 2024 (UTC)Reply[reply]
What handwringing? I proposed a merge structure. This can be taken to PAG or any other board. There can't be consensus for a nonexistent proposal. CMD (talk) 01:18, 17 January 2024 (UTC)Reply[reply]
The ToF listicle, in addition to being a "use with caution" source and thus likely ineligible for NCORP, has all of 25 words on it, 6 of them being just the name. On what planet would anyone consider that SIGCOV?? And the Business Insider listicle has just 3 sentences, nowhere near SIGCOV. Is this another walled garden maintained by a small number of AfD participants? JoelleJay (talk) 22:46, 16 January 2024 (UTC)Reply[reply]
Probably, but that's true for most of AfD. You could find people to !vote keep on just about anything if it was mentioned in a local newspaper once. Thebiguglyalien (talk) 22:52, 16 January 2024 (UTC)Reply[reply]
@Star Mississippi: The first objection raised in that AfD was that the nominated subject received far more news coverage than most Samsung models, which suggests that this will not be a baseline concern for most Samsung models. BD2412T 15:16, 16 January 2024 (UTC)Reply[reply]
Not to take issue with any individual editor, but this is a great example of why AfD isn't a good venue for making decisions like this. The question shouldn't be anything like "which Samsung (phone) models are famous?" but rather, "what treatment of Samsung (phone) models serves the purposes of our readers and offers encyclopaedic coverage?". There is a constant tendency at AfD to answer the former type of question rather than the latter. Newimpartial (talk) 17:53, 16 January 2024 (UTC)Reply[reply]
Agree with what Newimpartial said. And because of that I think that a general discussion is a useful place to discuss this. Having a different 3-4 participants at each AFD decide is not the best way to do this. Also due to the complexity of the considerations, with input/influence from both wp:notability and wp:not dictating the best course. North8000 (talk) 18:11, 16 January 2024 (UTC)Reply[reply]
I agree with Newimpartial and North8000 here. The implied question at AfD is always "should the article(s) about this topic be deleted?", even if the nominator is actually asking something different or more nuanced. Accordingly people who think there should be coverage of this topic on Wikipedia will usually only !vote delete if the article is bad enough to require TNT and frequently this means they recommend keeping even if they would be happy with a merge, or even think a merge would be better. If you want to ask a different question, AfD is the wrong venue. Thryduulf (talk) 19:20, 16 January 2024 (UTC)Reply[reply]
Who's suggesting using AfD to combine articles? The AfD example just demonstrates that the most vocal people who want to keep the status quo generally don't understand or don't care about how notability is evaluated. Thebiguglyalien (talk) 22:49, 16 January 2024 (UTC)Reply[reply]
Of course not. How many of these actually receive non-routine SUSTAINED coverage? JoelleJay (talk) 22:30, 16 January 2024 (UTC)Reply[reply]
More than 0 but less than 600. If you want a more precise answer than that you're going to have to look for sources. Thryduulf (talk) 22:32, 16 January 2024 (UTC)Reply[reply]
Too many phones for 1 article, too many phones for separate articles. With cars, they often separate into generations of models eg. Toyota Corolla third generation Toyota Corolla (E30). Do phones have generations yet? -- GreenC 01:53, 17 January 2024 (UTC)Reply[reply]
Amir Tsarfati
Recently Wikipedi took down the page of Amir Tsarfati. This proves that Wikipedia, like most big tech,is antisemitic at heart. Amir is a real, and legitimate, person and personality. To remove his page is showing this organization is not independent at all, it is a left wing purveyor of Propaganda 2600:4040:4029:7400:DD60:2E56:7133:282B (talk) 20:37, 16 January 2024 (UTC)Reply[reply]
Nah. Wikipedia:Articles for deletion/Amir Tsarfati is pretty clear: He does not pass the WP:Notability test (lacks in-depth coverage in independent reliable sources). There is no claim by anyone that he is not real, nor that he is "illegitimate" whatever that might mean. He's just some random person who has not attracted significant coverage in sources independent of his own religious and non-profit work. — SMcCandlish☏¢ 😼 20:54, 16 January 2024 (UTC)Reply[reply]
If 2600:4040 had any connection to this person (or any other person or organization they wanted to have an article), then I'd encourage them to take WP:BFAQ#WHY to heart, especially the practical and helpful advice "to add to your own website a comprehensive list of any independent reliable sources, such as newspaper articles, which have been published about your organization. Such a list can help Wikipedia understand why you think your organization is notable" (emphasis mine). If you want to have an article about a given subject, then making it very, very easy for Wikipedia's volunteers to find Wikipedia:Independent sources about that subject is helpful. WhatamIdoing (talk) 22:08, 16 January 2024 (UTC)Reply[reply]
is antisemitic at heart. Sigh. To prove that, you'd need to prove discriminatory intent. Otherwise we're being antisemitic when we delete any article about anyone who is Jewish, and Islamophobic when we do so about anyone who is Muslim, and homophobic when... 🌺 Cremastra (talk) 22:38, 16 January 2024 (UTC)Reply[reply]
Not to be pedantic, but in my usage at least wikt:at heart always takes the meaning of "at the core, essentially, foundationally", and not any moral/spiritual sense (for which I'd instead say "in one's heart"). The latter definition may have something to do with intent, but no clarification of what OP means is given, and OP used the term "proves" in the most colloquial sense. SamuelRiv (talk) 23:09, 16 January 2024 (UTC)Reply[reply]
Trademark Symbol
I am trying to mediate a dispute at DRN in which a declared paid editor is asking to add the trademark symbol (TM) (actually the form in a circle) after the name of his company's product whenever it appears in an article. I looked in the policies and guidelines and the MOS, and didn't find a statement that we do or do not use trademark symbols. However, it has been my understanding that we do not use the trademark symbol, because it has a promotional quality, and that alternatives would include using a non-trademarked term for the product. Did I fail to find something in the MOS, or is the MOS silent on the subject? Should the MOS say not to use trademark symbols in Wikipedia articles? Could a compromise be to include a note in the article that that form of the name is trademarked?
Robert McClenon (talk) 02:58, 17 January 2024 (UTC)Reply[reply]
Wikipedia:Manual of Style/Trademarks says Do not use the ™ and ® symbols, or similar, in either article text or citations, unless unavoidably necessary for context. Pretty clear. Cullen328 (talk) 03:04, 17 January 2024 (UTC)Reply[reply]
I have dealt with a similar situation before, where one name of the subject was claimed to be protected as a trademark. Where that is the case, one solution is to just eliminate generic use of the claimed term from the article completely, and refer to the subject by its clearly generic name. Compare adhesive bandage and Band-Aid. BD2412T 03:39, 17 January 2024 (UTC)Reply[reply]
Using a trademarked term is not a problem as we are not doing trade under it, not passing it off as applying to our product. Look at any newspaper, and you'll see trademarked terms referenced left, right, and center in the newspaper text, without the trademark symbols. It falls under trademark fair use. -- Nat Gertler (talk) 05:18, 17 January 2024 (UTC)Reply[reply]
Thank you. It was right there where I was looking, and I didn't see it. Thank you. Case closed and user blocked for legal threat. Robert McClenon (talk) 05:39, 17 January 2024 (UTC)Reply[reply]
@InfiniteNexus I encountered the same bug about 10 minutes ago. Bug now, it seems that the this DB bug is resolved. Hooman Mallahzadeh (talk) 08:13, 4 December 2023 (UTC)Reply[reply]
To avoid creating high replication lag, this transaction was aborted because the write duration (3.465854883194) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead.
[5b6f2722-25fb-4736-a8a1-061b5bc2d481] 2023-12-04 14:31:18: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"
JFTR that edit went through in the meantime. And Phabricator indicates the developers are figuring it out. --Joy (talk) 17:05, 4 December 2023 (UTC)Reply[reply]
I also had errors on two edits in the last couple of hours. I didn't record the first but the second was [29eec93d-299b-4bdf-89d1-88caca3466b5] 2023-12-04 14:13:41: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError" on this edit. Both worked after I used the browser's Back button and clicked Publish again. Certes (talk) 14:17, 4 December 2023 (UTC)Reply[reply]
Still getting an error on this. I was getting something about a transaction being too large and taking too long (>3 sec) for a couple attempts. This attempt I got
A database query error has occurred. This may indicate a bug in the software.
[4d773f04-424e-4f64-af0f-f259aa808ecd] 2023-12-04 14:44:28: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
Attempts to edit my user sandbox page were successful.
I've been getting this error this morning too: To avoid creating high replication lag, this transaction was aborted because the write duration (15.307519674301) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead. [1cd8ddfe-f560-4300-b162-1d4d0448423c] 2023-12-04 16:19:03: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError" These aren't large changes I'm attempting. I have gotten a few edits through, but it's hit or miss. – Muboshgu (talk) 16:23, 4 December 2023 (UTC)Reply[reply]
A database query error has occurred. This may indicate a bug in the software.
[38a2ed1b-239f-4448-841c-e65ec46331ef] 2023-12-04 08:28:23: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
I've tried a couple of different edit summaries, and I'm able to edit other articles. Could someone else please try reverting the edit? Thanks. DH85868993 (talk) 08:32, 4 December 2023 (UTC)Reply[reply]
Me as well at Vista, California ... [ab2894fb-78ff-4187-a212-713464e91635] 2023-12-04 12:22:58: Fatal exception of type "Wikimedia\Rdbms\DBQueryError". Magnolia677 (talk) 12:25, 4 December 2023 (UTC)Reply[reply]
Same here, at Deer Park, New York: [a4dc9654-fbed-48be-8eb3-a597446272e9] 2023-12-04 12:32:07: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"WikiDan61ChatMe!ReadMe!! 12:33, 4 December 2023 (UTC)Reply[reply]
And the same here (in the UK), from about 2 hours ago, editing Caligula, using MacBook. Sometimes it lets me edit but not save. Other times, it works fine but not for long. There's no pattern to it that I can discern. My Watchlist responds to changes in all other articles. Haploidavey (talk) 12:59, 4 December 2023 (UTC) Just tried a test edit, and was treated to the following:Reply[reply]
I am getting this with many different articles. Mellk (talk) 13:21, 4 December 2023 (UTC)Reply[reply]
Database error
To avoid creating high replication lag, this transaction was aborted because the write duration (5.7858679294586) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead.
[b08b554e-cf70-4cd8-8291-03dd2733d85a] 2023-12-04 13:01:46: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"
Getting the same issue with the article Martin Artyukh. [85a67d40-833b-409f-a662-ba0486de9b09] 2023-12-04 15:51:16: Fatal exception of type "Wikimedia\Rdbms\DBQueryError" --BlameRuiner (talk) 15:52, 4 December 2023 (UTC)Reply[reply]
Yup, I'm getting the same error across multiple articles - sometimes takes multiple attempts to get a change to save. Parsecboy (talk) 16:23, 4 December 2023 (UTC)Reply[reply]
Recovering from it?
When this error hits me, if I go "back" in the browser to get back to the text I was working on, all my changes are gone. This is actually weird behavior in Chrome. E.g., if I instead get an edit-conflict page, I can "Back" in the browser freely. But when this DB error happens, it's like it somehow messes up the page cache. Does anyone know of a way to recover the text that was being worked on? I have an article that did a whole lot of cleanup work in (probably a good half hour of it) and don't want to lose all that work if I can help it. I'm still sitting on the DB error page on that one. — SMcCandlish☏¢ 😼 14:08, 4 December 2023 (UTC)Reply[reply]
Update: I took a gamble, and it turns out that clicking the Reload button worked (caveats: in Chrome, and without triggering another DB error; I have no idea what another browser would do, or what would happen if the DB error had recurred, and it might, since in trying to make a typo fix at another page I had to try five times, though each time I did it as a manual edit, not a reload). — SMcCandlish☏¢ 😼 14:28, 4 December 2023 (UTC)Reply[reply]
FWIW in my Firefox, the back button got me back into the previous state, with the content and summary fields intact, so I can keep retrying trivially. --Joy (talk) 14:33, 4 December 2023 (UTC)Reply[reply]
I'm in Microsoft Edge, and the back button gets me to the state pre-submission, with edits and summary in place. Though I am now taking a copy of the text before clicking Publish. Tacyarg (talk) 14:55, 4 December 2023 (UTC)Reply[reply]
I'm using Chrome on a chromebook and if I hit the Back button, I get the original article state from when I hit edit (i.e., I lost my changes and edit summary). I'm just going to wait until it seems to be resolved before making any more edits. Kimen8 (talk) 14:58, 4 December 2023 (UTC)Reply[reply]
FYI I just got this error (Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError") a few minutes ago, when attempting to edit FKA Twigs. My edit worked the second time I tried it. Funcrunch (talk) 17:45, 11 January 2024 (UTC)Reply[reply]
The article specifies to non-conditionally add a mapbox (specifically {{maplink-road}}). This thus depends on the Q code being looked up and being available in OSM. If it is not, it will fail to draw the map. It seems that the relationship for Bowery in OSM has disappeared, I can only find the way parts. —TheDJ (talk • contribs) 09:47, 9 January 2024 (UTC)Reply[reply]
In the meantime, is there a way to specify some coordinates so we at least get something, even if the road isn't highlighted? Jake Wartenberg (talk) 04:24, 11 January 2024 (UTC)Reply[reply]
On way is to populate |coordinates = with the right values, and then use |map_type = to specify an existing map like Module:Location map/data/United States Lower Manhattan. In this case, that solution works but doesn't look great, so in the meantime I've disabled the map entirely rather than keep an obviously broken infobox in production. It can easily be re-enabled once a better solution is found. Orange Suede Sofa (talk) 22:44, 11 January 2024 (UTC)Reply[reply]
Is there a way to add a sticky header to a wikitable? If I use {{sticky header}} and add class="unsortable" to all the 17 columns it works, but looks ridiculous. I hope there is something simpler. IKhitron (talk) 01:14, 11 January 2024 (UTC)Reply[reply]
Looking at Special:MobileDiff/1194770191 on my desktop computer using Vector2022, the header-legend has this background for added and this background for deleted. But then in the actual diff, deleted lines are appear as this background instead. I don't know enough about site CSS to know where to look. But I get the same result when I am not logged in, so it's not a personal CSS, gadget, or other preference changing it. DMacks (talk) 06:12, 11 January 2024 (UTC)Reply[reply]
phab:T354840 has been opened on this, appears to be an upstream problem, not something for us to fix here on enwiki. — xaosfluxTalk 10:49, 11 January 2024 (UTC)Reply[reply]
Try again. Is it only happening when you try to make a specific kind of edit? If so, what? — xaosfluxTalk 00:38, 12 January 2024 (UTC)Reply[reply]
I've tried it several times and its still happening. I dont think I did anything unique, just a handful of minor text edits. Mercedes-Fletcher (talk) 01:26, 12 January 2024 (UTC)Reply[reply]
@Mercedes-Fletcher some editors have reported similar problems in phab:T353889. I just made a change to the source of that article, could you try again? If it works, please let us know? If it still fails please record the exact step-by-step process you are following that leads to the error. — xaosfluxTalk 14:28, 12 January 2024 (UTC)Reply[reply]
A news source I frequently use doesn't seem to get "converted" any more by Refill toolforge?
hi - not sure if this is the right place. A news publication in NJ USA called TapInto has a number of city-based news pages by different journalists. When I put a bare URL recently using the Refill Tool forge tool, it no longer seems to fill it? Wondering why and if there is a fix? I also opened a discussion awhile back on TapInto' talk page. Thanks in advance Bhdshoes2 (talk) 15:45, 12 January 2024 (UTC)Reply[reply]
Recently, the mobile web UI has started showing thank buttons in diffs for edits by bots, which it hadn't been doing before. Is it intentional? Janhrach (talk) 11:44, 13 January 2024 (UTC)Reply[reply]
Janhrach, it looks like I (on the desktop interface) can also thank bots, so I think this is intentional. I vaguely remember seeing a phab ticket about thanking bots a while back. — Qwerfjkltalk 12:03, 13 January 2024 (UTC)Reply[reply]
The style of those articles is to link to each occurrence of the source. Thank you. -SusanLesch (talk) 16:00, 13 January 2024 (UTC)Reply[reply]
@SusanLesch: Although the pipe trick doesn't work, ordinary piped links are fine. Just type the missing name in yourself: [1] -- John of Reading (talk) 16:11, 13 January 2024 (UTC)Reply[reply]
@SusanLesch:Help:Pipe trick#Where it doesn't work said: "Where the pipe trick doesn't work, the link must be written out in full manually." I think "written out in full" could be misinterpreted as not allowing pipes at all so I have added an example.[15]PrimeHunter (talk) 16:51, 13 January 2024 (UTC)Reply[reply]
Perfect! Thanks much, John of Reading and PrimeHunter. Happy camper here. -SusanLesch (talk) 17:27, 13 January 2024 (UTC)Reply[reply]
Article under construction
Hi everyone,
I have a question and I figured someone must have asked before but I could not find an answer with MANY different questions asked in this section.
So, my question is if I am working on one area of the article (expanding it) and I am translating from one language to another (Serbian > English), what template can I use to "advise" everyone that I am working on this and I will remove this template as soon as work is done ?
I found few templates but I wanted to know what is the correct procedure if, say, for example, I want to put the content out in one edit and then add references in another, proof read on third edit, etc.
{{In use}} is usually a good choice. Make sure to remove it when you are done, or when you plan to stop editing for a few hours. – Jonesey95 (talk) 20:28, 13 January 2024 (UTC)Reply[reply]
What about if I am not done anything what I wanted and I want to go to bed ? Should I go with what @Redrose64 mentioned where bot will automatically remove it after 7 days.
Of course, I am planning to finish what I started within 1-3 days but just in case if something happens.
That, or {{under construction}}. I think that there's a bot that will remove both of these if the page isn't edited for seven days. --Redrose64 🌹 (talk) 20:40, 13 January 2024 (UTC)Reply[reply]
Delayed reveal for images in notices
Some notices have images that are initially undisplayed, but which become visible when an editable input or textarea element receives the focus. The image remains even when focus moves elsewhere. I have seen this happen on two kinds of page, there may be others. The steps to reproduce for each are:
From any page history, watchlist etc. visit any non-current revision of a page, for example Special:PermaLink/1195410333. Observe that the yellow box at the top, beginning This is an old revision of this page, contains no image. Click on the "Edit" tab. Observe that the yellow box is still there, unchanged; also that there is a second yellow box, beginning You are editing an old revision of this page, which also lacks an image. Now click on any one of: the main edit window; the edit summary window; the "search" window in the left sidebar. Observe that both of the yellow boxes immediately gain a triangular yellow warning sign containing the "!" character.
Go to Special:MyPage/common.css. Click on the "Edit" tab. Observe that the pink box at the top, beginning Please note: CSS subpages should not contain confidential data, contains no image. Now click on any one of: the main edit window; the edit summary window; the "search" window in the left sidebar. Observe that the pink box immediately gains an octagonal red warning sign containing the "!" character.
I am using MonoBook skin, Firefox 121 and Windows 10. --Redrose64 🌹 (talk) 20:22, 13 January 2024 (UTC)Reply[reply]
I don't see any icons appearing when following these steps. The boxes remain iconless. Anomie⚔ 20:37, 13 January 2024 (UTC)Reply[reply]
For both cases, the element concerned is <span class="cdx-message__icon"></span> (it's empty} and initially there are no matching CSS rules. For the first case, when the edit box receives the focus, the following CSS rules suddenly appear in the DOM:
Presumably they're injected by JavaScript somewhere. --Redrose64 🌹 (talk) 20:56, 13 January 2024 (UTC)Reply[reply]
I see style rules like those in the codex-styles ResourceLoader module, which would also be loaded by the @wikimedia/codex module. I'd guess some script, gadget, or feature you have enabled is loading it, and I don't have whatever it is enabled. Anomie⚔ 23:59, 13 January 2024 (UTC)Reply[reply]
I don't know what this codex-styles or @wikimedia/codex modules might be. I have turned off everything in User:Redrose64/common.js and the behaviour described above does not change. I have also found that it is replicable in all skins (including Cologne Blue and Modern), except for MinervaNeue. --Redrose64 🌹 (talk) 10:36, 14 January 2024 (UTC)Reply[reply]
In short, the "contents" box overlaps the table listing episodes. I can't use a smaller level of zoom due to my vision. So the box hides a good part of the content. Here's a partial screenshot of what I see: https://imgur.com/a/EVQJ19D
Of course, I can click on the "hide" button, and the box will stop overlapping. But I don't think I should have to do that in the first place. This is really annoying if I want to come back to this "contents" box at various points when reading the list; it forces me to click "hide" and "show" multiple times, this is absolutely not user-friendly.
It would be great if someone could try and fix that. I can't fix my vision issues (so changing my zoom level is not possible) and my screen settings works well for other tasks on my laptop - changing anything on my end could create a cascade of new issues on other websites or software I use, so I'd prefer to avoid changing anything on my end.
That's what happens when editors combine a wide table with {{TOC right}}. Options include removing TOC right, switching to a different skin, putting {{clear}} after the TOC, moving {{TOC right}} higher in the page (maybe), or making the table narrower. Or, if you have extra money, getting a monitor with a higher resolution, or probably other options. – Jonesey95 (talk) 20:38, 13 January 2024 (UTC)Reply[reply]
The {{TOC right}} cannot easily be moved up the page, unless either the lead is split, or another section is inserted before the Series overview. This is because the TOC must be the last element of the lead - if placed earlier in the lead, any content between it and the first section heading becomes inaccessible to screen readers. --Redrose64 🌹 (talk) 21:13, 13 January 2024 (UTC)Reply[reply]
Searching lists
Not so much a question as an "is this a reasonable thing to do and a reasonable way to go about it," but the past couple days I've been thinking about article-specific search boxes in, for example, lists of lists. (If you want background, start here or ask, but that's not particularly important; for an example, see List of films based on actual events.) I was looking around a bit and {{search box}} doesn't really seem to be intended for mainspace use (as we don't have proper subpages, among other reasons); so I threw together {{search lists}} based on the (very) small number of mainspace uses, which appear to all be adapted from one addition to a list a dozen years ago or so. (Courtesy ping to Michael Bednarek.)
Is this a reasonable thing to do? (I'm inclined to think that most good ideas are thought up and implemented by someone else before me.)
Having not really started many templates from scratch before, have I made any horrible mistakes here? (Or, other general comments/suggestions.)
Minor technical question: I know regex is generally discouraged when searching with insource; does the same apply to intitle, or is that generally fine?
And barring any issues in the above, I guess... feel free to use this if you know of a list that could use it. Hopefully it's helpful.
And hopefully some of that makes sense, rather than being an incomprehensible mess of gibberish to everyone except me. Cheers. LittlePuppers (talk) 00:30, 14 January 2024 (UTC)Reply[reply]
From a user perspective, I tried it out here using an intentionally ambiguous term ("Waco", which is both an actual event and a settlement) and found that the list-specific results returned correct and relevant sub-lists, but not the articles themselves. This is a drawback, since I then had to go and open three new pages and conduct three more searches within those lists, which was no fun. Having said that, the mainspace search (for which I used "Waco film" and "Waco movie") was much less useful in general, returning too many irrelevant results and omitting relevant ones. Regards, Orange Suede Sofa (talk) 01:29, 14 January 2024 (UTC)Reply[reply]
Huh, I wasn't thinking of returning the articles in the lists. That's an idea, but I'm not seeing a great way to implement it - we have linksto: but no linksfrom:. The closest you could probably get is checking if it's in a category, but it appears that there is often not quite a one-to-one correspondence between categories and lists. (And then you run into a whole lot of other ambiguities, because there are things on a list that redirect to a section, so you couldn't find them by searching in titles, and searching texts would bring up a whole lot of irrelevant stuff, and so on.) Hopefully searching the lists themselves should cover most cases reasonably well, though. LittlePuppers (talk) 03:05, 14 January 2024 (UTC)Reply[reply]
extendedconfirmed edit count threshold
Currently (as of 2024-01-13), extendedconfirmed status is conferred upon an account of sufficient tenure upon its reaching 501 edits, rather than upon 500 edits, as suggested by the WP:30/500 documentation. Dotyoyo (talk) 00:59, 14 January 2024 (UTC)Reply[reply]
@Dotyoyo: Are you saying that there has been a detrimental change to the way that the MediaWiki software works? I don't see what the problem is here. One edit either way won't make any difference, except to those confirmed users who wish to involve themselves in editing ECP pages, and so are making lots of edits with a view to passing the 500 (or 501) threshold as soon as possible. --Redrose64 🌹 (talk) 10:49, 14 January 2024 (UTC)Reply[reply]
There are a bunch of minor edge cases related to this, but none that are going to be changed technically. The relevant configuration item is $wmgAutopromoteOnceonEdit and the settings are:
'enwiki'=>['extendedconfirmed'=>['&',[APCOND_EDITCOUNT,500],[APCOND_AGE,30*86400],// 30 days * seconds in a day['!',[APCOND_INGROUPS,'sysop']],['!',[APCOND_INGROUPS,'bot']],]
The local pages describe to concept in plain language for the majority of users. If you think there is a tech issue with the process please report it as a bug. I would not support trying to work around by doing something like changing it to "499" in the configuration, converting to an implicit group, etc. — xaosfluxTalk 17:11, 14 January 2024 (UTC)Reply[reply]
Feel free to adjust plain language from something like "and at least 500 edits." to "has exceeded 500 edits". — xaosfluxTalk 17:12, 14 January 2024 (UTC)Reply[reply]
Off-by-one errors are common. I have checked several users at [16] and you are right, they all became extended confirmed on edit number 501. I haven't examined the code but my guess would be a timing issue where the check for 500 edits is made before the updated edit count is available. 500 or 501 seems unimportant so I would just ignore it but Phabricator would be the right place for a bug report. PrimeHunter (talk) 17:38, 14 January 2024 (UTC)Reply[reply]
It's not a timing bug. auto promote is evaluated before an edit is made (as part of the permissions check). So AFTER 500 edits, on the next time your state is evaluated, you will be extendedconfirmed. That means that for your 501st edit you are extended confirmed. —TheDJ (talk • contribs) 11:02, 15 January 2024 (UTC)Reply[reply]
Thanks for the explanation. That sounds pretty much like my "timing issue" guess even if it's not considered a bug. I had not guessed you can apparently edit an extended confirmed page on your 501st edit, but neither will users with exactly 500 edits if they still see "View source" and no edit links. PrimeHunter (talk) 12:54, 15 January 2024 (UTC)Reply[reply]
Checking the times to the second of the events, it appears that edit no. 501 is saved one or two seconds before the log entry recording the user rights change. --Redrose64 🌹 (talk) 13:33, 15 January 2024 (UTC)Reply[reply]
As a slight aside, is there any way to get the edit screen for a page one cannot edit, even though (I hope) the Publish button wouldn't work? I would actually find that feature useful for previewing changes to nested protected templates that I'm considering requesting where creating a chain of sandboxes would be awkward. Certes (talk) 13:42, 15 January 2024 (UTC)Reply[reply]
I'm tired of reading "465 feet (142 m)". It's ugly and it breaks up the flow of reading. Why can't we have the user specify whether they want sane units or freedom units in some user setting and then everything automatically gets displayed for them how they want it? It probably doesn't even require any software changes, just a version of {{convert}} which wraps things in <span class="metric-units"> and <span class="freedom-units"> and a trivial amount of CSS to pick which you see. RoySmith(talk) 03:49, 14 January 2024 (UTC)Reply[reply]
Most readers aren’t logged in. With that said, it is possible to customise content based on the location the reader is in - we could give imperial units to readers in the US, Myanmar, and Liberia, and metric units to everyone else. BilledMammal (talk) 03:58, 14 January 2024 (UTC)Reply[reply]
I knew somebody was going to bring up IP users. They can make accounts. Or things can fall back to how they are now for IPs. Or WMF can figure out how to let IP users set preferences. Whatever. In the case of a logged-in user, setting which units you want should not be a function of location, it should be a function of what units you prefer to see. Maybe geolocation could be a first guess at a default, but the user should certainly be able to override that in their prefs. RoySmith(talk) 04:12, 14 January 2024 (UTC)Reply[reply]
So what about certain technical usages? For instance, certain projectile weights or diameters are always presented in the reliable sources under a certain unit. I've never seen 20-pounder Parrott rifle or the 8-inch Columbiad referred to as the 9.07-kilogram Parrott rifle or the 20.32-centimeter Columbiad. So do we either just not convert these things and leave metric readers unfamiliar with the size/weight of these projectiles or automatically convert them and create made-up nomenclature that's not going to be found anywhere else. Hog FarmTalk 04:25, 14 January 2024 (UTC)Reply[reply]
RoySmith, what is preventing you from editing the sandbox of {{convert}} to add the classes, creating appropriate test cases, and then documenting how editors can set up custom CSS to show one class or the other? Also, why not start this discussion at Template talk:Convert? – Jonesey95 (talk) 05:53, 14 January 2024 (UTC)Reply[reply]
None of this is a reasonable response to the concern. Sorry. Your suggestion to mark certain kinds of units up is fine, but "I want it my way" isn't. There is a reason we removed auto date formatting, and logged out users are it. Remember, they are the 99%, not you. Izno (talk) 20:40, 14 January 2024 (UTC)Reply[reply]
I concur that the autodate formatting and the issues surrounding it are a good precedent to take into account. —TheDJ (talk • contribs) 10:46, 15 January 2024 (UTC)Reply[reply]
Some regions, nations, and people use and (more importantly) understand a mix of imperial and metric units. A preference could be set for those people logged-in, but those logged out would be left with articles that don't suitibly explain themselves. — Fourthords | =Λ= | 21:27, 14 January 2024 (UTC)Reply[reply]
I can also see problems where the units are normally given in one set or the other (eg 500m dash) so there should be a non-user preferred version shown first with the converted unit later. Masem (t) 04:34, 14 January 2024 (UTC)Reply[reply]
Me personally, I like seeing both units of measurement, so it doesn't bother me at all. ♠JCW555(talk)♠ 04:31, 14 January 2024 (UTC)Reply[reply]
Australia has been metric for 50 years, but we still talk 8-pound babies, 12-foot tinnies and quarter-acre blocks. The present system is fine, but we too often see inappropriate degrees of precision. Doug butler (talk) 06:05, 14 January 2024 (UTC)Reply[reply]
It's a small boat used for fishing. On a more relevant issue, I agree that inappropriate precision is something more important. — Jts1882 | talk 11:24, 14 January 2024 (UTC)Reply[reply]
And there was me thinking it was a tube of amber nectar. No worries. --Redrose64 🌹 (talk) 11:27, 14 January 2024 (UTC)Reply[reply]
It is technical in implementation details, there might be difficulties this forum could raise. -- GreenC 21:04, 14 January 2024 (UTC)Reply[reply]
I'm surprised convert doesn't already have a way to configure a default system, for logged in users. I agree there is too much complexity reading 2 systems, by default. If a measurement is globally preferred in one system, convert can have an override switch that will force display of both systems ignoring the user config to limit to one system (unless that one is the same as the globally preferred system). -- GreenC 21:04, 14 January 2024 (UTC)Reply[reply]
That's easy, they default to status quo, showing both systems. -- GreenC 19:14, 15 January 2024 (UTC)Reply[reply]
Insulting a broad swath of editors like that isn't exactly collegial... IMO its neither ugly or breaks up the flow of reading. Horse Eye's Back (talk) 07:31, 15 January 2024 (UTC)Reply[reply]
IMO, adding some spans with classes as suggested in the original post would be an easy and uncontroversial technical solution. This would not affect IP editors nor most logged in editors, who would still get to see both. Editors that care about such things could add the appropriate code to their User:YourName/common.css, such as .metric-units { display: none; }, which would hide the undesired units only when logged into their account. Simple, uncontroversial. This could be done with a template protected edit request at Module talk:Convert. –Novem Linguae (talk) 07:36, 15 January 2024 (UTC)Reply[reply]
We should keep using {{convert}} to overcome the global tyranny of the metric system. – Muboshgu (talk) 19:46, 15 January 2024 (UTC)Reply[reply]
Conversions are often necessary, and allows us to keep track of the original, referenced measurement. Well-meaning editors often convert numbers back and forth until they have changed considerably; keeping the original unit in the template helps avoid this. I would hate to forced to see only inches and grains and furlongs just because my IP address happens to be located in a retrograde, anti-knowledge society. But by all means, give people the option to hide additional numbers if they find them annoying. On the other hand, I agree we ought to stop converting numbers which do not need converting - automobile wheels, for instance, are measured in inches everywhere on the globe, and people keep applying conversion templates which is utterly inappropriate. Similarly, I bet some zealot/inattentive editor wrote "Royal Mile (1,609.34 m)" about Edinburgh. Mr.choppers | ✎ 21:29, 15 January 2024 (UTC)Reply[reply]
Not always. The Dunlop Denovo run-flat tyre used an associated belt of pressurised cans which couldn't be fitted once the tyre was on the rim, and the tyre couldn't be worked over the cans without damaging them, so special bolt-together wheels were designed. These could be split in order to fit a tyre and the can belt. Since the wheel construction was very different from the traditional form, the manufacturers took the opportunity to start with a clean sheet in terms of dimensions, and used a metric rim - 310 mm on the Austin Mini 1275GT and 375 mm for the Rover 3500 (SD1), for example. --Redrose64 🌹 (talk) 01:03, 16 January 2024 (UTC)Reply[reply]
Clearly some zealot needs to add a template to clear up misinformation, as some would say it should be "Royal Mile (1,814ish m)", given the Mile in question is Scottish. CMD (talk) 02:10, 16 January 2024 (UTC)Reply[reply]
We have the wonderfully over precise a total length of approximately one Scottish mile, an obsolete unit equal to 1.8072576 km.Nthep (talk) 14:12, 16 January 2024 (UTC)Reply[reply]
Issue with the XTools gadget
Hey all,
I've been experiencing an issue with the XTools gadget across all article space, where the HTML container for the infomation section (id: xtools) is duplicated; the first instance of it works as intended, the second contains only "." within its "#xtools_result" span tag. I'm using Firefox 121. Frzzl talk; contribs 15:46, 14 January 2024 (UTC)Reply[reply]
@Frzzl it appears that issues related to xtool are asked to be reported here. — xaosfluxTalk 16:34, 14 January 2024 (UTC)Reply[reply]
A public-domain multi-page PDF is hosted on the site. Let's say it's File:1901 phone book.pdf. If I wanted to link to page 47 in that PDF, what would the wiki-markup look like? — Fourthords | =Λ= | 17:45, 14 January 2024 (UTC)Reply[reply]
But that link doesn't say anything about wiki-markup at all, though? — Fourthords | =Λ= | 18:53, 14 January 2024 (UTC)Reply[reply]
Wikipedia - Das Buch@Fourthords: I don't think it's possible with a wikilink, i.e. wiki-markup like [[...]]. You can display page 47 with |page=47 in the image syntax like I did here. Clicking on the image goes to page 47 with the url https://commons.wikimedia.org/w/index.php?title=File:WikiPress_1_Wikipedia.pdf&page=47. Wikilinks do not allow query strings like &page=47. I doubt there is a way to link it without using external link syntax with a url instead of a wikilink. PrimeHunter (talk) 18:31, 14 January 2024 (UTC)Reply[reply]
Yep, that's exactly what I was wondering. That's a bummer, but thanks for the info! — Fourthords | =Λ= | 18:53, 14 January 2024 (UTC)Reply[reply]
Adding #page=x to the URL will link to that page in most browsers, but I don't know of a way off hand to link to the PDF itself instead of just the info/preview page, short of something like {{plainlink}}. LittlePuppers (talk) 18:36, 14 January 2024 (UTC)Reply[reply]
"when visited" what counts as a visit ? The file page, a media link, a download link ? —TheDJ (talk • contribs) 10:44, 15 January 2024 (UTC)Reply[reply]
I was thinking the file page, but I just googled and apparently PHP can't read #theseTypesOfURLTags. So would need to be done in the LinkRenderer I guess (detecting File namespace and PDF type, then converting the #47 to &page=47). If it's worth the trouble. Just an idea at this point. –Novem Linguae (talk) 11:21, 15 January 2024 (UTC)Reply[reply]
Gadget Creation
When opening a non-existent gadget page, like Gadget:example, the message says "You need to log in or create an account to create this page", even though the namespace is deprecated and this is not possible. This may be an issue or oversight with Template:No article text or it may be intentional. -322UbnBr2 (Talk | Contributions | Actions) 06:14, 15 January 2024 (UTC)Reply[reply]
It looks like {{No article text}} doesn't have a special case to deal with the gadget namespace, so it tries to detect what permissions are needed to create the page and... well, I don't know how deprecating a namespace works in MediaWiki (or wherever it's deprecated, if it's a WMF thing), but somehow it comes to the conclusion that you just need to be in the user group to do so. LittlePuppers (talk) 06:25, 15 January 2024 (UTC)Reply[reply]
Since there isn't a specific protection level applied (it's just... not possible), Module:Effective protection level comes to the conclusion that it's not protected, a talk page, or in draftspace, so you just need to be a registered user to create it. (Fun fact I just discovered: an IP can't create an IP user page, even for their own IP.) To fix the error message, you'd have to modify that module to return 'impossible' (or something) for the gadget namespace, and then modify every template/module that depends on that (or, modify {{No article text}} and hope everything else can deal with it), and so on... LittlePuppers (talk) 06:33, 15 January 2024 (UTC)Reply[reply]
Reading through my comments from yesterday... yeah, you could definitely fix it in the template without having to touch the module. (The module is the root cause of the present behavior, but the template could easily check the namespace and override.) LittlePuppers (talk) 18:33, 15 January 2024 (UTC)Reply[reply]
On second thought I've just suppressed that sentence entirely for these two namespaces, to put an end to this ridiculous timesink. * Pppery *it has begun... 20:48, 15 January 2024 (UTC)Reply[reply]
View tab and failing visual editor tab
I now have a view tab ("view images related to this article") and while the source editor tab/link works, the visual editor seems no longer working. There is also a link to replay edits being shown on the submenu instead perhaps of inside the tools dropdown. Shyamal (talk) 08:39, 15 January 2024 (UTC)Reply[reply]
PS: the visual edit tab now works. Shyamal (talk) 08:59, 15 January 2024 (UTC)Reply[reply]
Still seems to occur sometimes Shyamal (talk) 15:53, 15 January 2024 (UTC)Reply[reply]
https://en.wikipedia.org/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector-2022 line 10 > eval at line 18: TypeError: $(...).textSelection is not a function
Does this still happen in WP:SAFEMODE? If not, does it still happen if you blank User:Shyamal/common.js? I noticed your tried to comment out some code in your common.js with <!-- and -->. Surprisingly, that parses without error, but it doesn't do what you expect. Use /* and */ instead. Suffusion of Yellow (talk) 23:28, 15 January 2024 (UTC)Reply[reply]
Surprisingly, that parses without error Not so surprising if you know "ancient" web history. 😉 Way back when Netscape first introduced JavaScript in the mid 1990s, if you were to have used a <script> tag then many browsers would have rendered the code as text in your page, since they didn't recognize the tag. So what they did is made <!-- and (as the first non-whitespace non-comment token in a line) --> in JavaScript be the start of a single-line comment, same as //. Then people could start their scripts with <script><!-- and end them with --></script> so browsers that didn't recognize the <script> tag would treat the script itself as being a big HTML comment and therefore still not display it as text. All this is still required by the ECMAScript spec when inside web browsers for legacy reasons. Anomie⚔ 03:40, 16 January 2024 (UTC)Reply[reply]
Oh that's why <script> often had <!-- -->! TIL. Nardog (talk) 03:50, 16 January 2024 (UTC)Reply[reply]
js pages are evaluated as wikitext when they are saved. The result is not displayed on the saved page but the evaluation can have side effects like additions to link tables. If a script has parts which would be valid wikilink syntax then it can generate entries in WhatLinksHere or add the script to categories. This is avoided by the above where /* ... */ is a JavaScript comment but not a wikitext comment, so the nowiki tags are active code when the page is evaluated as wikitext. This prevents the JavaScript code from being evaluated as wikitext. PrimeHunter (talk) 05:20, 16 January 2024 (UTC)Reply[reply]
I use this trick on all my user scripts. I think it's a good practice. It prevents subtle bugs such as 4 tildes turning into a signature. –Novem Linguae (talk) 09:41, 16 January 2024 (UTC)Reply[reply]
I have blanked my common.js and yes, it does seem to work fine now! Thank you. I am surprised though by the sudden appearance of the issue... Shyamal (talk) 09:36, 16 January 2024 (UTC)Reply[reply]
Errant spaces in URLs
This probably happens when cutting and pasting wikitext from an editor with automatic line wrap enabled. An example in two places: |url=http://stories99 .com and in |archive-url= after "wins-the". (this is on mswiki but it happens on every wiki). The example shows how it makes GIGO with bots. The question is, how to find and fix? Presumably the |url= field contains only URL information so one can stitch together pieces of text separated by spaces, but I don't think this would hold in practice, there could be many exceptions. It can also occur in other arguments like |page=[https://google. com/book/PA=5 5]. The space(s) can occur anywhere within the URL. I have come across some articles where most URLs have this problem. -- GreenC 19:11, 15 January 2024 (UTC)Reply[reply]
Tech News: 2024-03
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
Pages that use the JSON contentmodel will now use tabs instead of spaces for auto-indentation. This will significantly reduce the page size. [17]
Gadgets and personal user scripts may now use JavaScript syntax introduced in ES6 (also known as "ES2015") and ES7 ("ES2016"). MediaWiki validates the source code to protect other site functionality from syntax errors, and to ensure scripts are valid in all supported browsers. Previously, Gadgets could use the requiresES6 option. This option is no longer needed and will be removed in the future. [18]
An update on the status of the Community Wishlist Survey for 2024 has been published. Please read and give your feedback.
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 January. It will be on non-Wikipedia wikis and some Wikipedias from 17 January. It will be on all wikis from 18 January (calendar). [21][22]
Starting on January 17, it will not be possible to login to Wikimedia wikis from some specific old versions of the Chrome browser (versions 51–66, released between 2016 and 2018). Additionally, users of iOS 12, or Safari on Mac OS 10.14, may need to login to each wiki separately. [23]
The jquery.cookie module was deprecated and replaced with the mediawiki.cookie module last year. A script has now been run to replace any remaining uses, and this week the temporary alias will be removed. [24]
A script has now been run to replace any remaining uses Note the script was buggy, you may want to check recent edits to scripts you maintain. Anomie⚔ 03:42, 16 January 2024 (UTC)Reply[reply]
How to limit Category display to subcats with non-zero contents
Is there a way to look at a diffusing category and only see the cats in it that themselves have anything in them? Use-case is a large cat of maintenance categories that each should be empty, where I want to find those that do need attention efficiently. DMacks (talk) 05:06, 16 January 2024 (UTC)Reply[reply]
@DMacks: I've written (with some difficulty) a CSS rule that on a category page will hide all the entries where the category link is followed by the text "(empty)":
I wanted to write the selector as .mw-categoryli:has(span[title="Contains 0 subcategories, 0 pages, and 0 files"]) but for some reason my browser (Firefox 121) doesn't like the sequence comma-space-character in an attribute selector. Anyway, the CSS rule goes in Special:MyPage/common.css, because it works in all skins. --Redrose64 🌹 (talk) 13:13, 16 January 2024 (UTC)Reply[reply]
I suspect DMAcks wants an option but still be able to see empty subcategories without logging out. Assuming your normal skin is not MonoBook, if you only save the above CSS in Special:MyPage/monobook.css and install User:PrimeHunter/In MonoBook.js in your common JavaScript then you can click "In MonoBook" on a category page to view it in MonoBook where empty subcategories will be hidden. PrimeHunter (talk) 14:11, 16 January 2024 (UTC)Reply[reply]
The two notification icons at the top of every page are blurry.
The two notification icons at the top of every page are blurry. I don't know if this is a css or javascript issue or just something else. 😎😎PaulGamerBoy360😎😎 (talk) 15:08, 16 January 2024 (UTC)Reply[reply]
They are not blurry for me. Can you share a screenshot? Matma Rextalk 17:09, 16 January 2024 (UTC)Reply[reply]
They are no longer blurry, It must of been a css issue because I have a heavily modified css & not all of it works properly on every device, although I don't know what in it would have caused the issue. 😎😎PaulGamerBoy360😎😎 (talk) 17:59, 16 January 2024 (UTC)Reply[reply]
Can I get my searches to open "Edit date - current on top"
I carry out a lot of searches for typos. I use the Advanced search, which always opens "Sort by relevance", whereas I need "Edit date - current on top" as I know when I last searched that particular list. I know it is only a few clicks and then running a new search to change it, but when doing it a hundred times or so, it is laborious and reduces my productivity. Adding "&sort=last_edit_desc" to the URL is equally clumsy, and I can't find any other options. Is there a way I can get my searches to open "Edit date - current on top" - Arjayay (talk) 20:13, 16 January 2024 (UTC)Reply[reply]
How do you typically open the advanced search? If you want all searches you make through the search form on every page on the site to be sorted by edit date by default, you can add
to your Special:MyPage/common.js. But if you're making the same queries anyway it sounds like the simplest solution is to bookmark the URLs for the search results already with sort=last_edit_desc. Nardog (talk) 03:45, 17 January 2024 (UTC)Reply[reply]
Random article
Hi all, Is there any way to filter the output of Special:Random, perhaps with a script? I'm not particularly keen on e.g. any sort of sport, minute sea snails, DNA or proteins, villages in Iran or Poland or US gubernatorial elections. Cheers, MinorProphet (talk) 21:06, 16 January 2024 (UTC)Reply[reply]
I suppose you could write a script that fetches a random page, and then discards it and picks a new one if it matches certain strings. — Qwerfjkltalk 21:31, 16 January 2024 (UTC)Reply[reply]
I could write a script if I knew how to, but I don't. Is there any chance of someone having a go if it wouldn't take too much time or trouble? MinorProphet (talk) 23:09, 16 January 2024 (UTC)Reply[reply]
Vector 2022 overrides personal .css
Following a discussion at the Help Desk about Level 5 and 6 headers, I experimented with changing the format of those headers in my Common.css, and also in my Vector-2022.css, but nothing made any difference. Until, that is, I changed from the default Vector 2022 skin to Monobook, whereupon my chosen formatting immediately appeared. I am using the latest update of Chrome on Linux (Lubuntu).
I know that other parts of my Common.css are active. Using F12 to show the HTML and Computed attributes, it appears that the Common.css format is used, but is then overridden by the Vector 2022 default; however, I am not sufficiently knowledgeable about web rendering to understand why.
Is there a way to format these headers under Vector 2022? And is anything else, possibly of greater import (as those header levels are almost never used) that is also blocked by the default skin? -- Verbarson talkedits 21:27, 16 January 2024 (UTC)Reply[reply]
CSS is a programming language. It follows logic. When you don't know about this logic, then it is difficult to make it work correctly. It is not vector 2022 overriding your choices, it is you not having specified your overrides to a level that they apply correctly in multiple situations. —TheDJ (talk • contribs) 22:02, 16 January 2024 (UTC)Reply[reply]
Pages that use the JSON contentmodel will now use tabs instead of spaces for auto-indentation. This will significantly reduce the page size. [25]
This has apparently also been done for the contentmodel "MassMessageListContent" used by that page. The diff doesn't show the real changes in the underlying page for that contentmodel. It shows a simplified representation of the changes without the change in the format used by the contentmodel. The page source before and after shows the change if you examine the whitespace at the start of lines. I don't know a way to display the "real" diff. PrimeHunter (talk) 22:03, 16 January 2024 (UTC)Reply[reply]
also, currently the only 2 given news sources nyt and ap are both american organisations. by adding the 4 below, there will be 3 american vs 2 british and 1 global, which will be less usa-centric as a whole.--RZuo (talk) 15:19, 24 November 2023 (UTC)Reply[reply]
consensus seems to be against adding these sources. theleekycauldron (talk • she/her) 22:26, 25 December 2023 (UTC)Reply[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Add reuters
support because reuters is better than AP (in its scope), and NYT (in everything).--RZuo (talk) 15:19, 24 November 2023 (UTC)Reply[reply]
Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. {{search for}} is great! Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Neutral: Reuters is ok to add but I'm not sure we need many more links. Nemo 07:12, 29 November 2023 (UTC)Reply[reply]
Oppose per Sdkb, remove individual news outlets. Eddie891TalkWork 15:31, 29 November 2023 (UTC)Reply[reply]
Oppose per SdkB, remove all individual news outlets as source recommendations. GenQuest"scribble" 07:15, 4 December 2023 (UTC)Reply[reply]
Oppose in favor of removing all individual news outlets, per Sdkb. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
Support as stated by the first support they are superior to the NYT. --Emir of Wikipedia (talk) 15:18, 24 December 2023 (UTC)Reply[reply]
Add BBC
support because bbc news is probably the most reputable among the most visited news websites, and the most visited among reputable news websites. and it's free, no login and whatnot.--RZuo (talk) 15:19, 24 November 2023 (UTC)Reply[reply]
Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Oppose in favor of something more WP:WRS-like, as suggested just above. We don't have links to individual scientific journals; why should we have links to individual news outlets? XOR'easter (talk) 17:52, 28 November 2023 (UTC)Reply[reply]
Oppose: BBC is usually ok but it's even more prone to the political winds of one country; not suitable. Nemo 07:12, 29 November 2023 (UTC)Reply[reply]
Oppose per Sdkb, remove individual news outlets. Eddie891TalkWork 15:31, 29 November 2023 (UTC)Reply[reply]
Oppose per SdkB and echoing XOR'easter, remove all individual news outlets as source recommendations, we don't do journals or magazines, so there's no need for profit-driven newspapers either. GenQuest"scribble" 07:29, 4 December 2023 (UTC)Reply[reply]
Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. {{search for}} is great! Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Oppose — the WSJ hard paywall makes the site impractical to use for a large number of editors, and it goes against Wikipedia's free-content ideals. —pythoncoder (talk | contribs) 04:15, 27 November 2023 (UTC)Reply[reply]
Oppose in favor of a general custom search engine, as suggested above. We go through the trouble of identifying "generally reliable" sources; we might as well benefit from all that work. As to the point about controversies raised above, plenty of those at the NYT have been about its editorial positions rather than its reporting, and, well, the WSJ is no stranger to that, either. I don't see why circulation is relevant in this context. XOR'easter (talk) 17:44, 28 November 2023 (UTC)Reply[reply]
Oppose per Sdkb, remove individual news outlets. Eddie891TalkWork 15:32, 29 November 2023 (UTC)Reply[reply]
Oppose per SdkB, remove all individual news outlets as source recommendations (we don't do journals or magazines, so there's no need for profit-driven newspapers either). GenQuest"scribble" 07:31, 4 December 2023 (UTC)Reply[reply]
Oppose in favor of removing all individual news outlets, per Sdkb; because the WSJ has a hard paywall; and because its web archives only go back to the late 1990s. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
Add The Times
support because The Times is better than nyt. for example, a company has created an archive of it for scholars to study it. do you see people doing that for nyt? as the most important newspaper of a country that once ruled many countries around the world, it reported a lot more on news around the world for a much longer period, compared to the usa-centric nyt.--RZuo (talk) 15:19, 24 November 2023 (UTC)Reply[reply]
Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. {{search for}} is great! Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Oppose, it seems even more paywalled. Nemo 07:12, 29 November 2023 (UTC)Reply[reply]
Oppose per Sdkb, remove individual news outlets. Eddie891TalkWork 15:32, 29 November 2023 (UTC)Reply[reply]
Oppose per SdkB, remove all individual news outlets as source recommendations (we don't do journals or magazines, so there's no need for profit-driven newspapers either). GenQuest"scribble" 07:32, 4 December 2023 (UTC)Reply[reply]
Oppose in favor of removing all individual news outlets, per Sdkb. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Remove all individual news outlets
STRONG CONSENSUS
Participants strongly supported this proposal. They argued that including individual news outlets clutters the template, that search engines can provide links to many different publications at once, and that inclusion of individual outlets gave undue weight to them and the regions they represent. They also highlighted how inclusion could create various unwanted precedents in future discussions.
A small number of contributors in opposition asserted that including well-known examples of reliable sources in the template was important. Supporters refuted this position by noting that it would be difficult to provide a geographically-balanced list of individual publications.
The proposer of the change used JSTOR as an example of a search engine rather than an individual source. One participant commented that they see JSTOR the opposite way (as an individual source rather than a search engine) and suggested removing it. Overall, there was little discussion of the website, so any future changes in its regard would need additional discussion.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Yikes. Let's take a step back here. As background, the module we're talking about is what produces the links seen mainly at the bottom of the 700k instances of {{Talk header}}. The goal is to help make it easier to find sources on a topic. However, that needs to be balanced with the imperative to keep the links in Talk header as minimized as possible to combat the notorious banner bloat on talk pages. So when we're thinking about which links to include or exclude, the frame should not be "might a few people find this helpful?" but rather "is this essential?"
In light of that, let's consider how people use this template. When I'm searching for sources for a Wikipedia article, I'm not interested only in what The New York Times, or Reuters, or the WSJ, or any other individual news outlet has to say on it (since Wikipedia articles are supposed to summarize all the reliable sources on a topic, not just a single source). So the main link I want to find news coverage is the Google News search, which will turn up those outlets as well as any others. And lucky me, that link already exists in the list, along with other links to places that collect works from many different publications (like JSTOR). The NYT link long stood out as the sole link to an individual source, and frankly including it was a mistake from the beginning. The way to remedy it is to remove it, along with the recently added link to AP, not to add more and more links to try to achieve some sort of balance.
What we're seeing above is the start of a path we don't want to go down, where we establish a new "worthy of Find sources inclusion" tier of source reliability and spend countless hours debating which sources to include in it and end up listing every newspaper of record across the globe to avoid the (legitimate) fears of geographic bias. Let's turn back from that and establish a simple standard that avoids all that ugliness and comports with how people actually do search: Find sources is for collections of sources, not for individual news outlets.
Support as proposer. {{u|Sdkb}}talk 17:02, 24 November 2023 (UTC)Reply[reply]
Support: hell, same. jp×g🗯️ 20:39, 24 November 2023 (UTC)Reply[reply]
that's exactly my point when i raised my objection to nyt back on 13 July 2023 Wikipedia:Village_pump_(proposals)/Archive_203#Replace_nyt_with_reuters. there had never been any argument for why it's chosen over all other sources. yet it took 125 days(!) for enwp to come to a conclusion of adding AP and not removing nyt, and no one has over the 125 days come up with argument for why nyt was chosen over other organisations but only some (Personal attack removed) kept lecturing me.
so here they go, to balance out the 2 american sources, at least 2 non-american must be added. :) RZuo (talk) 07:12, 25 November 2023 (UTC)Reply[reply]
This is why I created {{search for}} to be a comprehensive suite of searches that one can pull out the type of searches that one wants from. And if there's something useful to add to it, we can certainly consider it.
But {{find sources}} isn't the same thing. In the event that the multiple searches of {{search for}} are needed, simply replace {{find sources}} with {{search for}}, which is definitely the workman's multitool here. Otherwise {{find sources}} really should be focussed upon a few broad search engines. It's a spork to the multitool.
It's somewhat questionable that it gives such prominence to Google, which is another reason that {{search for}} exists, but the very reason that I designed {{search for}} as a series of collapsing boxes is that if you add everything in a single line it becomes enormous. I tried that with {{search for}}.
Something that is a single line mid-dot-separated list needs to be minimal, and if you keep adding more and more useful specialist searches to it you'll end up reinventing {{search for}} but badly.
@Uncle G:somewhat questionable that it gives such prominence to Google - see Searx + Startpage.com, as per my comment below. Boud (talk) 13:19, 25 November 2023 (UTC)Reply[reply]
I can imagine Search for replacing Find sources. In fact, I think you could make the tool even better by integrating some tools like WP:WRS, by expanding the scholarly articles section, by integrating the subject-specific recommendations or by emphasising you may get help to find your source. But that one is very good and practically fulfills the same purpose. Szmenderowiecki (talk) 23:25, 25 November 2023 (UTC)Reply[reply]
Comment. I just spent at least three or four minutes at maximum zoom trying to figure out whether bits three and seven (from the left) in the "multitool" photo are star drive, and I can't tell and it's upsetting my professional sensibilities. Even if they are, with only two included you're bound to run into screws you can't undo, either T15 or T20. Folly Mox (talk) 09:41, 26 November 2023 (UTC)Reply[reply]
Support but replace the privacy-violating Google link by a link to either the Searx meta-search news link at Openxng.com, Searx.be and/or Priv.au (alternatively, it should be possible technically to set up a round-robin selection from the best-rated Searx instances listed at https://searx.space), or to Startpage.com (though I don't know of how to directly link to the News section there). Startpage also protects privacy, so would satisfy UCOC, but it does do some advertising, so that would count as advocacy conferring financial benefits, as in the case of Google, with a financial motive for search engine bias in its search results, affecting the neutrality of our finding sources. Boud (talk) 13:16, 25 November 2023 (UTC)Reply[reply]
Support and I see no issue in a longer but more informative template. I only see the use of replacing Google with other browsers if they offer a comparable quality of search or it's slightly inferior but otherwise usable and respects privacy better. Privacy isn't a goal in and of itself, so we must weigh tradeoffs. Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Yeah, and we already have (sorta defunct) WP:WRS, which was supposed to be a one-stop tool to search all news.
Keep the number of links at the minimum, maximise searching within one custom search engine.
It's not really possible with peer-reviewed articles, but we have Google Scholar and equivalents for that and anyway we should strive to use the best sources we have, right? Szmenderowiecki (talk) 21:10, 25 November 2023 (UTC)Reply[reply]
@Szmenderowiecki:Browsers are not search engines. Google's version of its web browser is getting worse and worse in terms of privacy violation, but that's an independent issue.Boud (talk) 16:31, 26 November 2023 (UTC)Reply[reply]
Support for reduction of clutter. — Bilorv (talk) 20:25, 25 November 2023 (UTC)Reply[reply]
Support per proposer, reduces clutter Sohom (talk) 20:55, 25 November 2023 (UTC)Reply[reply]
Support strongly, especially since there's no reason to emphasize news sources by including many of them - for the vast majority of uses of {{find sources}} news sources might not even be right (let alone US based ones). Galobtter (talk) 21:00, 25 November 2023 (UTC)Reply[reply]
Neutral: ok to remove individual outlets but it doesn't help much when there's a link to Google News which contains all sort of trash. Also support removing JSTOR as another individual outlet that has no business being here alone. Support replacing the links to NYT and AP with a search engine which contains them (preferably with a small manual selection of outlets rather than an automated crawling of news-like websites). Nemo 07:21, 29 November 2023 (UTC)Reply[reply]
Support. Less is more. This is used very widely via templates, and what gets included in it should be of exceptionally broad and global applicability. There should only be tools to actually "find sources" and not any individual source or publisher. Adumbrativus (talk) 04:19, 30 November 2023 (UTC)Reply[reply]
Support per Sdkb. This is a slippery slope. Retswerb (talk) 01:31, 1 December 2023 (UTC)Reply[reply]
Strongly support per nom, Galobtter and particularly the desire to reduce banner bloat. Remagoxer(talk) 15:30, 1 December 2023 (UTC)Reply[reply]
Very Very Strong Support per SdkB, remove all individual news outlets as source recommendations (we don't do journals or magazines, so there's no need for profit-driven newspapers either). GenQuest"scribble" 07:36, 4 December 2023 (UTC)Reply[reply]
Support - per nom and above. (I trust I don't have to individually oppose the other sections if I'm voting support here.) Levivich (talk) 16:52, 4 December 2023 (UTC)Reply[reply]
Support per nom's criticism of banner bloat. The overall proposal rightfully recognizes America-centrism in a widely used template, but the solution cannot be adding the top English publications of each country BluePenguin18 🐧 ( 💬 ) 18:50, 4 December 2023 (UTC)Reply[reply]
Support to avoid inappropriate product placement and because I doubt anyone actually needs these links to find sources. – Joe (talk) 13:28, 5 December 2023 (UTC)Reply[reply]
Support Only including certain RS and not others violates NPOV, and the generic links are good enough for this purpose. QuicoleJR (talk) 14:19, 6 December 2023 (UTC)Reply[reply]
Support - Honestly, I don't think we should be giving any outlets any undue attention, as it may violate NPOV as mentioned above. Also, as others have mentioned, this will reduce link clutter as well. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
Support. It's prejudicial toward certain corporate "voices" in the news sphere (and certain countries' news), plus it would just continue to grow into an increasingly long list of such news outlets, which ultimately are redundant with the Google News link (though I wouldn't mind seeing that replaced by something that isn't subject to Google's own skewing, and using Microsoft's or Yandex's equivalent wouldn't help but just shift the problem of whose skew we're buying into). Maybe replace all these Google search types with DuckDuckGo ones, if we trust DDG more. — SMcCandlish☏¢ 😼 21:41, 18 December 2023 (UTC)Reply[reply]
Oppose. I think picking representative examples is very important—it seems totally useless to force a less useful presentation solely to create an appearance that information need not come from anywhere in particular. We don't get to freely choose where information we can use comes from or how we can get it. Yes, you can characterize a mention of a particular entity as promoting it, sometimes obviously, sometimes only in an abstract sense—but no one can actually take the reasoning here to its logical conclusion. It is uncomfortable that we rely on certain outlets to create Wikipedia, but I'm sorry to say that there is no intellectually honest remedy for this discomfort, only ways to obscure it. This change is arbitrary; the generic links only push the problem people seem to have back a singular step. Remsense留 21:56, 18 December 2023 (UTC)Reply[reply]
Oppose and I am in full agreement with Remsense. The sources in the module are helpful as the results from those links are narrowly-focused to meet the reseach needs of editors of this project, namely to provide independent, reliable source. We are frequently advised that this project does not right great wrongs, whether in terms of political or societal issues, nor in this case about the dominance of corporate voices in our media landscape. --Enos733 (talk) 00:36, 19 December 2023 (UTC)Reply[reply]
I don't really understand how this came to be a right-great-wrongs issue. We don't dispute NYT or AP is good, but if you need coverage from, say, Serbia, Poland or Canada, then using NYT or AP is kinda suboptimal compared to using local reliable outlets, which obviously cover local stuff better. Also, the framing about "corporate voices" is simply misguided. This is not the problem. The problem is that we choose to advertise only one voice among hundreds that are valid, and which WP:RSP recognizes are valid. It is also about creating a more versatile search tool. If among all sources they decide to choose NYT, we can't help it, but we should first offer a choice we don't really give right now. Instead we are suggesting "use NYT and AP". Adding individual outlets will just make the template needlessly bloated. Szmenderowiecki (talk) 10:37, 23 December 2023 (UTC)Reply[reply]
If you look at the discussion, there are several people who support removal to remove corporate voices or that somehow listing any outlet is a POV issue. - Enos733 (talk) 12:40, 23 December 2023 (UTC)Reply[reply]
I acknowledge that. As I said, for me the "corporate voices" thing is misguided. I can potentially agree with POV concerns for listing individual outlets if we are speaking about WP:SYSTEMICBIAS, which this diversification could help combat if only a little (the ultimate choice of sources still rests with the editors, and the source of that bias is mostly editors). Szmenderowiecki (talk) 16:20, 23 December 2023 (UTC)Reply[reply]
What I could agree with, if this could be implemented easily, is a way to personalize the search links. - Enos733 (talk) 01:29, 24 December 2023 (UTC)Reply[reply]
What do you mean by "personalise"? Doing Google's work all over again is not feasible. If you mean something like a dropdown list where you could tick the relevant boxes, I'm not sure Google's custom search engines can do that but maybe there are other techniques.
Probably the best would be to sort these outlets by regions (North America, Latin America, W Europe, Central-Eastern Europe, Middle East, Indian subcontinent, E Asia, Australia and Oceania, Arab Africa, Central Africa, S Africa; and a general one). I think it would be beneficial for editors to see all news outlets and not simply let them cherry-pick the ones that align with their preconceived notions and POV, or for that matter only choose the most famous ones at the detriment of others thst also do good journalism. Szmenderowiecki (talk) 18:36, 24 December 2023 (UTC)Reply[reply]
Support news outlets are not good general sources, full stop. (t · c) buidhe 02:17, 27 December 2023 (UTC)Reply[reply]
Support removing all individual outlets, those present are too America-centric. Stifle (talk) 14:25, 3 January 2024 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Replace the generic link
CONSENSUS AGAINST
In this discussion, participants established a rough consensus against replacing the generic link for search. Participants who supported replacing it cited concerns about user privacy, potential systemic bias of Google's search engine, and some alternative websites were suggested. Those in opposition to the generic link being replaced argued that Google is the best overall search engine presently out there, that no suitable replacement to Google that is of comparable quality exists, and that the tradeoff here in terms of usability weighs in favor of maintaining google. Some participants noted that they would approve of adding links of general search engines in addition to the generic Google link (rather than in replacement of the generic Google link), though no affirmative consensus to do so was reached in this discussion. — Red-tailed hawk(nest) 05:54, 12 January 2024 (UTC)Reply[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The generic link to Google violates Wikipedians' privacy (storing detailed private data for the purpose of sales to advertisers), which is contrary to the spirit of UCOC; like any individual search engine, it is subject to search engine bias that biases our selection of sources, and it uses filter bubbles targeted to each individual, tending to amplify existing demographicbiasesin Wikipedia. We could either give a link to list of search engines or choose a meta-search engine that gives high-quality general search results while protecting user privacy, reducing the bias to any particular engine, and avoiding filter bubbles. Boud (talk) 13:48, 25 November 2023 (UTC) Clarify: this section is only for the generic link, not for the specific links for news, books or scholarly sources. Boud (talk) 16:10, 26 November 2023 (UTC)Reply[reply]
Support as proposer. Suggest either (1) list of search engines, or (2) the Searx generic link at Openxng.com, Searx.be and/or Priv.au, or if a pseudo-random generator can be linked up to the module (should not be difficult with e.g. /dev/urandom, which is fast), use a round-robin selection from a list of e.g. 10 of the best-rated Searx instances listed at https://searx.space), or (3) Startpage.com. The round-robin solution with Searx would keep the link compact (5 characters) and would statistically reduce the bias of any individual Searx instance implicit in the way it is configured and run. Boud (talk) 13:48, 25 November 2023 (UTC)Reply[reply]
Given that Searx is not longer maintained, security vulnerabilities would not be widely reported and addressed in a timely manner. Furthermore, with such low market share, the Searx links you have provided would undoubtedly scare editors into suspecting they have been redirected to malware. While the random assignment to Searx instances increases privacy, this approach is unfamiliar to the average editor that expects links to consistently route them to the same specific site BluePenguin18 🐧 ( 💬 ) 19:11, 4 December 2023 (UTC)Reply[reply]
@BluePenguin18: The main development of Searx shifted to Searxng, which is actively maintained; currently there are 882 closed bugs vs 183 open bugs and the master branch is updated every few days or so. Searx.space only lists Searxng instances. Education of editors is worth the price of protecting their privacy; those who actually check URLs are likely to know enough to be able to search further for an explanation and learn. There's also the option of Wikimedia techies running a searx instance: https://searx.wikimedia.org. Boud (talk) 02:28, 10 December 2023 (UTC)Reply[reply]
@Boud Thanks for the clarification on Searxng! I would support a Wikimedia instance of Searx being offered alongside Google Search to comply with WP:ASTONISH, providing curious editors an opportunity to learn about and choose meta-search engines while still offering the currently dominant option BluePenguin18 🐧 ( 💬 ) 05:10, 10 December 2023 (UTC)Reply[reply]
Oppose. Google Search has plenty of problems that make it non-ideal, but it has over 90% market share. At that level, it's what editors expect, so providing anything else would go against WP:ASTONISH. Google also leverages its market dominance to provide better results in some cases, and editors' familiarity with it makes it easier for them to use. The metasearch engine idea is intriguing, but I wasn't impressed when I tested it just now. Searching for "Wikipedia" and navigating to the news tab produced results like this. Linking to the list of search engines is a nonstarter. The entire point of these links is to make searching for sources easier (to encourage more people to do it or just to add convenience). The current setup goes instantly to the Google results for the topic, whereas linking to the article would then require people to navigate to the search engine they want, click through to its article, click the external link to its site, and then re-enter the search term. At that level of inconvenience, people are just going to type the search query into their browser instead, bypassing the template and making it useless as a convenience aid. {{u|Sdkb}}talk 17:34, 25 November 2023 (UTC)Reply[reply]
Just to check what the actual arguments presented here are against the Searx proposal. They seem to be: (1) Google is dominant and it's what people expect; (2) anecdotal evidence. Boud (talk) 16:26, 26 November 2023 (UTC)Reply[reply]
As of September, Searx's github repo is no longer maintained. I'm not real familiar with the project, but surely that's bound to be an issue moving forward if we were to use it as the sole replacement for Google search? Any replacement for the sole link should be something with staying power. Retswerb (talk) 01:29, 1 December 2023 (UTC)Reply[reply]
See above: Strictly speaking, Searx is closed, replaced by Searxng. When I said "Searx" above, formally speaking I was referring to Searxng software and instances. Boud (talk) 02:30, 10 December 2023 (UTC)Reply[reply]
Oppose. Privacy isn't a goal in and of itself. I want to see the balance we trade between utility and privacy. If otherwise equal, obviously switch from Google but prefer utility in the balancing equation. Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
If we balance between utility and privacy, then privacy is a goal (among others). Boud (talk) 16:33, 26 November 2023 (UTC)Reply[reply]
A goal that I believe is secondary to utility, which is the primary goal (find as many sources as you can). You can believe we should prioritise privacy even to the detriment of utility, which is fine but I think few people will share your view.
Also, {{search for}} already includes a couple of search engines outside Google. You can suggest a couple more there. Theoretically if there is independent confirmation that startpage.com is equivalent to Google but is more privacy-friendly, why not? We can change the link.
But my testing of relatively obscure topics I mentioned (e.g. reasons why few people live in Tasmania) showed that most alternatives simply performed worse. Now whether Google (or Microsoft, Apple or whatever) abused its market dominance is basically irrelevant for me, because the point is to find data and (hopefully) let users exercise best judgment in choosing.
I need to see that any of the SearX, Mojeek or other search engines are good enough to use. This also applies to searches in languages other than English, so if the engine is optimised for English but sucks in Russian, it's not good enough. Szmenderowiecki (talk) 18:41, 26 November 2023 (UTC)Reply[reply]
In principle, OK to let users exercise best judgment in choosing, but the search engine bias in the results that the users have to choose from only makes it easy for them to use judgment within that biased selection. A mix of biases (via a meta-search engine) should tend to reduce the overall bias.Searx is not a search engine, it is a metasearch engine. Mojeek is a search engine.As for other languages, given that in English a very sort of notorious example is when the Google search engine was categorizing black people as monkeysper a Princeton engineering interview, the case of Timnit Gebru's exit from Google, and the Santa Clara University advice Search engines and artificial intelligence are neither neutral nor free from human judgment, I see no reason to trust Google to be better in non-English languages than in English. Financial reasons suggest the opposite: paying fluent speakers of small-population languages of poor countries won't contribute much to Google/Alphabet advertising revenue. Boud (talk) 19:35, 26 November 2023 (UTC)Reply[reply]
Oppose This proposal feels a bit wikilawyery especially bringing up the UCOC which has nothing to do with this proposal. Given everything being equal, I would definitely support using alternative engines (or atleast giving users the options to do so). However, this is not the case, instead results from other engines tend to be inferior or outright non-existent for certain search terms. Additionally, a geographical bias can actually sometimes help editors who live in specific regions find better sources (Annecdotally, I have a easier time digging up sourcing about Indian topics if I switch to my Indian registered internet connection when I am in other countries.) -- Sohom (talk) 21:09, 25 November 2023 (UTC)Reply[reply]
If there's consensus to continue violating UCOC - and in fact I expect that there will be consensus to continue to at least partially violate UCOC by keeping at least one or two Google links - then we'll find that out. WMF will have to fight us if it wishes to fully implement UCOC. Recommending that other Wikipedians violate their privacy is disrespectful and risky, e.g. it's inconsistent with ensuring that the Wikimedia projects are productive, pleasant and safe spaces, and contribute to the Wikimedia mission. It's not safe to be encouraged to violate your personal privacy. To make an analogy: suppose you're invited to a Wikimedia community face-to-face workshop and on entry to the room, there's someone at the door who asks you to take off all your clothes. Whether Google's privacy invasion into your mind - your browser history and browser parameters - is worse or better than a violation of your bodily privacy is a matter of judgment, but both cases are privacy violations. Boud (talk) 19:57, 26 November 2023 (UTC)Reply[reply]
@Boud You've lost me at the analogy. Giving up ones privacy is not akin to sexual harrasment, linking to the UCOC's harrasment clause and giving examples of sexual harrasment as a analogy is not going to change that fact.
The {{find sources}} template links are just suggestions/convinience links for good places to find sourcing, you are welcomed to ignore it completely and use your own search engines (in fact I do so myself most of the times, even when using Google). I would liken it more to being offered a milk-coffee at a Wikimedia event, when I myself am lactose intolerant (I am not, but hypothetically speaking). Sohom (talk) 14:07, 30 November 2023 (UTC)Reply[reply]
Oppose Google search/news/scholar/books are very good for finding sources and any replacement has to have similar quality. Galobtter (talk) 21:11, 25 November 2023 (UTC)Reply[reply]
Oppose. A pretty normal WP:BEFORE would probably include Google news, Google books, and Google scholar. Removing links to Google would make this workflow inefficient. At a minimum, equivalent search engines that search news articles, books, and academic papers should be proposed. A general "let's get rid of Google" with no suggested replacement, in my opinion, is not the way to go. –Novem Linguae (talk) 02:00, 26 November 2023 (UTC)Reply[reply]
This proposal is only for the generic link. That is independent of the specific links for news, books and scholarly sources. The above section (so far) seems to be only about news links. Boud (talk) 16:10, 26 November 2023 (UTC)Reply[reply]
Support replacing Google search with (pretty much) anything else. Linking Google means we're letting advertisers decide what ends up used as source in Wikipedia, an obvious source of systemic bias. If people think a direct link to a web search is needed for people's workflows, DuckDuckGo would be an improvement on the current state. DuckDuckGo introduces less systemic bias because it generally doesn't personalise results based on user fingerprinting and doesn't serve automatically generated prose or other non-sources into the "search results" page. Nemo 07:12, 29 November 2023 (UTC)Reply[reply]
This is misguided. By not personalizing, all users would get the same search results for the same query, reducing the variety of sources used on Wikipedia. While Wikipedia faces systemic bias for its disproportionate share of cis, white, and male editors, the diversity that does exist generates alternative advertiser profiles to see unique sources BluePenguin18 🐧 ( 💬 ) 19:11, 4 December 2023 (UTC)Reply[reply]
So this argument is that by violating Wikipedians' privacy in tracking and recording their habits (in some cases) as being non-cis-white-male, these Wikipedians will select from sources that help create source diversity, but will to the same degree statistically out their gender/social-group profiles, whether they wish it or not. This makes the UCOC violation even worse: it's not just that Wikipedians are encouraged to give their browsing habits to an organisation known for tracking this to great detail, but those browsing habits risk being (statistically) revealed in their choice of sources. Machine learning applied to Wikipedians' selection of sources could suggest their likely Google gender/group profiles. For Wikipedians living in some countries and editing en.Wikipedia, this puts them at risk of prison or death. Boud (talk) 02:54, 10 December 2023 (UTC)Reply[reply]
I might be misunderstanding this argument, but are you suggesting that oppressive regimes will be targetting Wikipedians living under their rule by trawling through contributions and compiling a list of sources added per account name, and then reverse engineering those accounts' possible google profiles based on the sources they've added? Folly Mox (talk) 04:24, 10 December 2023 (UTC)Reply[reply]
Not will, but could; and not trawling by hand, but rather intelligently doing analysis using a mix of software and human thinking. Actions such as the Saudi infiltration of Twitter - or Google - will not always work and they risk embarrassment. To the extent that Google's filter bubbles characterise Wikipedians' profiles and improve diversity in the selection of sources (the point made by BluePenguin18), there would, in principle, be a signal, by definition.Suppose that Wikipedian X is LGBT, that the Downtown Post Daily Times strongly promotes LGBT content, as well as news content unrelated to LGBT issues, and is accepted as a WP:RS in Wikipedia, but X is unaware of the LGBT aspect of the DPDT (it's not obvious in the name). Then Google often gives X sources from DPDT (which buys lots of Google ads), and X often uses them in Wikipedia, unaware that other Wikipedians get DPDT links from Google much more rarely. Boud (talk) 13:47, 10 December 2023 (UTC)Reply[reply]
Even when machine learning models become capable of identifying editors' characteristics based on their choice of sources, it would simpler and more accurate to surveil their list of top edited pages. When the Saudi government infiltrated the Arabic Wikipedia's administrator community, they took the simplest approach to content control by looking at what specific editors were writing. BluePenguin18 🐧 ( 💬 ) 20:02, 10 December 2023 (UTC)Reply[reply]
Some editors may deliberately attempt to hide their interests by editing Wikipedia in a way that hides their (in this hypothetical case) LGBT profile, but some of their general non-Wikipedia searches will be for LGBT material. We get back to the case of our hypothetical editor unintentionally using DPDT as a source for a non-LGBT Wikipedia article, unaware that this is a statistical clue to being LGBT. Whether or not this is the best way to identify people to for arbitrary arrest and torture, it's available in the record. Boud (talk) 18:52, 13 December 2023 (UTC)Reply[reply]
@Boud: You gotta stop bringing up the UCOC thing. It's not helpful. I try not to inject myself in every conversation involving the UCoC, but I won't be able to sleep tonight if I don't correct the absolute absurdity that is your reply: If there's consensus to continue violating UCOC - and in fact I expect that there will be consensus to continue to at least partially violate UCOC by keeping at least one or two Google links - then we'll find that out. WMF will have to fight us if it wishes to fully implement UCOC. I've spent hours of my life having discussions with the WMF and the community about the UCOC. What you are suggesting is so far removed from anything a rational person would even consider when enforcing it. There is zero possibility of anyone of applying it to this case; most especially not the WMF. Your logic here is so twisted and nonsensical that I'm embarrassed to even feel the need to respond. –MJL‐Talk‐☖ 06:55, 13 December 2023 (UTC)Reply[reply]
I don't see any arguments here explaining why encouraging Wikipedians to violate their privacy and thus put themselves at increased risk of harm is consistent with the spirit of UCOC; absurdity ... twisted ... nonsensical are not arguments. Boud (talk) 18:52, 13 December 2023 (UTC)Reply[reply]
The amount of logical assumptions you have to make to get where you are at is indeed absurd, twisted, and nonsensical. Adding a link to a Google search is not encouraging Wikipedians to violate their privacy (as has already been explained to you). Even if it was, the spirit of the UCoC (if there can be such a thing) which you keep referring to would not be violated nor enforced. I know this because I co-wrote the enforcement guidelines. –MJL‐Talk‐☖ 18:55, 14 December 2023 (UTC)Reply[reply]
Support the idea of replacing the generic google link with some sort of list of search engines. We already do this when providing links to ISBNs and co-ords. Rather than picking what search engine people use, we can present them with a list of options. I'm not convinced any Google alternative is actually good enough to fully replace the link to google, especially recognizing its sheer market dominance (it will be what many people expect to find and use). Eddie891TalkWork 15:36, 29 November 2023 (UTC)Reply[reply]
Oppose replacing Google: The top searches on Bing, and likely most other search engines is "Google". Meet the reader where they're at. Mach61 (talk) 05:41, 30 November 2023 (UTC)Reply[reply]
Oppose As much as I dislike the corporation, it is the best overall source of sources. O3000, Ret. (talk) 19:38, 1 December 2023 (UTC)Reply[reply]
Whether or not a search template not used in article content contains a hyperlink to Google has nothing at all to do with verifiability. Even if this template didn't exist at all, stuff could still be verifiable. Uncle G (talk) 14:56, 11 December 2023 (UTC)Reply[reply]
Oppose - As much as Google may have plenty of privacy issues, that is a separate matter from whether it is useful, which it is. Thus, I don't see a reason to remove it at this time. I would support adding different search engines like Bing or Yahoo if there were consensus for it, though. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
Support adding links to other search engines; the current google search engine is deeply flawed. The list of search engines should continue to include google -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:13, 13 December 2023 (UTC)Reply[reply]
Oppose The generic search link can be valuable to editors. There is no replacement in this proposal, just removal. --Enos733 (talk) 12:44, 23 December 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Discussion (Module:Find sources)
There are two orthogonal issues here, reliability and coverage of sources (which is core encyclopedia stuff) and search engines' respect for privacy (which is a user preference). This is unlikely to lead to a productive conversation. Personally I think we should recommend source-finding techniques on a per-wikiproject basis. We need to look in different places for sources for a contemporary American biography, a 20C New Zealand law, a 19C Malay biography, an 18C German political scandal, a 17C book and an ancient Middle Eastern location. Seems likely to me that we can come up with a per-user preference for generic search engine privacy and then parameters to help find specific content (bot-assisted based on cats and wikiprojects). Stuartyeates (talk) 19:14, 25 November 2023 (UTC)Reply[reply]
It's true that there are two orthogonal motivations, and you are probably right that a tech solution may be able satisfy both. The idea of a per-user preference parameter for search engine privacy, that would be used by the module to switch between privacy-violating and privacy-respecting search engines and meta-search engines, is good. This would need techie willingness to implement it. There would also be the question of which setting should be the default: should selecting privacy be opt-in or opt-out? Boud (talk) 20:13, 26 November 2023 (UTC)Reply[reply]
If we think this is going to be a popular subject (~50 editors?), please copy/paste it to a subpage before adding an RFC tag. This page was recently nearly a million bytes long, and that makes it very difficult for people to read (especially on smart phones). The most popular title is Wikipedia:Requests_for_comment/YOUR-THING-HERE (see examples), but it's okay to do Wikipedia:Village_pump_(proposals)/YOUR-THING-HERE if you prefer. WhatamIdoing (talk) 18:59, 24 November 2023 (UTC)Reply[reply]
I think this first should have an RfC tag before we move it to a subpage of VPR. People won't know of this discussion if we hide it in a subpage. Szmenderowiecki (talk) 21:12, 25 November 2023 (UTC)Reply[reply]
If it's an RFC, people will know about it no matter where it happens. The Wikipedia:Feedback request service posts personalized messages to editors' talk pages about RFCs in subject areas that interest them. But I agree (and, more importantly, so does WP:RFC) that it would be good to keep a link here, especially if the discussion starts here and gets moved. WhatamIdoing (talk) 23:20, 26 November 2023 (UTC)Reply[reply]
Maybe this should be done reactively rather than proactively. That is, wait for sections to get big, then put them on a subpage. –Novem Linguae (talk) 02:05, 26 November 2023 (UTC)Reply[reply]
@Novem Linguae, do you have a preferred number for "big"? There are already more than 50 comments in this section. WhatamIdoing (talk) 23:22, 26 November 2023 (UTC)Reply[reply]
Exactly how many news sources are deemed reliable by Wikipedia & which ones are they? GoodDay (talk) 16:28, 23 December 2023 (UTC)Reply[reply]
RfC: disallowing new signatures obsolete tags
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
There is clearconsensus in favor of the proposal. Any remaining technical questions can be worked out during implementation. (non-admin closure) {{u|Sdkb}}talk 20:40, 24 December 2023 (UTC)Reply[reply]
Background/details (disallowing new signatures obsolete tags)
In 2020, as part of the DiscussionTools project, signature validation was added to MediaWiki. Since its implementation, users have been unable to save an invalid signature in Special:Preferences (invalid signatures saved beforehand are still allowed). Currently, the validator disallows every WP:LINT error except for obsolete-tags. (The most commonly used obsolete tag is <font>...</font>, but <tt>...</tt>, <center>...</center>, and <strike>...</strike> are also obsolete.) This proposal would eliminate that exception. Pre-existing signatures would not be affected by this proposal.
Survey (disallowing new signatures obsolete tags)
Support as proposer. Bots (and humans) are currently fixing obsolete-tags en masse, and this was backed by community consensus in February. I believe this change should appeal to people on both "sides" of that debate. If you support fixing obsolete tags, the benefits are obvious. If you oppose fixing obsolete tags, fixing them is already backed by community consensus. This change would help limit the amount of lint that bots need to fix.Additionally, WP:SIGFONT is already part of the signature guidelines. This would simply enforce that section techincally. HouseBlastertalk 01:10, 3 December 2023 (UTC)Reply[reply]
Support, if bots are already fixing them what's the point in allowing them? — Alexis Jazz (talk or ping me) 01:18, 3 December 2023 (UTC)Reply[reply]
Support, these are already deprecated in terms of browser support, and the day will come that support for them is dropped entirely. This is a good step to ensure those who may not know that are not negatively impacted by such a change, and eliminating the need for linter bots to make needless edits fixing them. SeraphimbladeTalk to me 04:35, 3 December 2023 (UTC)Reply[reply]
Support, use of obsolete tags cause too much drama. BilledMammal (talk) 05:03, 3 December 2023 (UTC)Reply[reply]
Support When saving edits, edits that contain lint errors should be blocked too Killarnee (talk) 14:23, 3 December 2023 (UTC)Reply[reply]
Support: Seems like a no-brainer to me. It's just real signature validation, plus this'll reduce needed resources by bots as there'd probably be less signatures that need fixing. Aaron Liu (talk) 16:03, 3 December 2023 (UTC)Reply[reply]
Support I'm kind of iffy on the whole fixing obsolete tags thing (I kind of doubt browsers will ever drop support for it), but we should what we can to prevent new additions of these. Galobtter (talk) 16:32, 3 December 2023 (UTC)Reply[reply]
Weak SupportEhhh - this should be dealt with WMF-projects wide or not at all. — xaosfluxTalk 18:56, 3 December 2023 (UTC)Reply[reply]
I assume the response to a global proposal would be "not without enwiki consensus", and there's nothing in this proposal preventing a later global one. ~ ToBeFree (talk) 22:56, 3 December 2023 (UTC)Reply[reply]
OK sure, don't think this is that big of a deal but if it's going to reduce bot edits then sure. — xaosfluxTalk 10:56, 4 December 2023 (UTC)Reply[reply]
Support as someone who spends a lot of time fixing Linter errors. It has been frustrating to watch new errors introduced into pages when we have such a huge backlog (3.6 million listed errors currently). Turning off the flowing tap of obsolete tags in signatures is a way to stem the flow when the bathtub of errors is overflowing. – Jonesey95 (talk) 23:28, 3 December 2023 (UTC)Reply[reply]
SupportWe should definitely prevent new additions, I'm surprised that this is not already the norm.Sohom (talk) 01:41, 4 December 2023 (UTC)Reply[reply]
Support Anything to reduce pointless addition of deprecated syntax, with subsequent time-wasting fixes, would be good. Johnuniq (talk) 04:07, 4 December 2023 (UTC)Reply[reply]
Support - regardless of how one feels about the urgency of fixing existing obsolete tags, it makes sense for Wikipedia to stop adding new obsolete tags to its pages. Long overdue, thanks for proposing this, HB. Levivich (talk) 05:23, 4 December 2023 (UTC)Reply[reply]
Support - My signature formerly used those tags to get under the maximum length. While as a web dev I knew they were outdated, I thought they were relatively harmless in this context (as browsers will continue to support them for compatibility) and didn't realise they were discouraged on enWP until another user gave me a heads up. If bots are already changing these tags the proverbial ship has already sailed regarding their usage. ― novov(tc) 02:38, 7 December 2023 (UTC)Reply[reply]
You could subst the font template to cut down on some chars to maybe make it fit. Aaron Liu (talk) 12:09, 7 December 2023 (UTC)Reply[reply]
Aaron Liu, surely that would be bypassing the signature limit (WP:SIGLENGTH: please be careful to verify that your signature does not violate the 255-character length limit when the templates are expanded, as the software will not do this automatically). — Qwerfjkltalk 18:35, 7 December 2023 (UTC)Reply[reply]
Support. We are already fixing these sigs (which was also approved in a recent RfC). Disallowing new ones to be introduced will reduce the amount of work needed and the "watchlist spam" issue some editors were complaining about. --Gonnym (talk) 12:30, 7 December 2023 (UTC)Reply[reply]
Support. I'm not convinced on the necessity of fixing lint errors on old talk pages, but stopping new ones seems more worthwile. -- LCU ActivelyDisinterested«@» °∆t° 19:05, 7 December 2023 (UTC)Reply[reply]
Support, as long as there is a crystal clear error message linking to mw:Help:Lint_errors/obsolete-tag or similar that can be understood even by someone who started editing yesterday and has tried to emulate the non-compliant signature of their favourite long-term editor. Certes (talk) 12:15, 8 December 2023 (UTC)Reply[reply]
Support Good idea Isla🏳️⚧ 13:20, 10 December 2023 (UTC)Reply[reply]
Support Since we should be designing Wikipedia for browsers that almost all people use (Chrome/Edge 120, Firefox 120, Safari, etc.). We should aim for modern web compliance including HTML5 and ES6 compliance. AwesomeAasim 15:40, 12 December 2023 (UTC)Reply[reply]
Discussion (disallowing new signatures obsolete tags)
@HouseBlaster: Please add a couple more words to the RFC question. It could be read as preventing me from changing my signature to one that has an obsolete-tag lint error, or it could be read as preventing a current user who has an obsolete-tag lint error from signing a new comment. I know the background explains that, but a word or two more might help. Johnuniq (talk) 01:16, 3 December 2023 (UTC)Reply[reply]
I just pinged you because you participated in the earlier discussion; this change would not impact you at all. HouseBlastertalk 21:56, 3 December 2023 (UTC)Reply[reply]
HouseBlaster, I thought Q1 was going to go first, did I miss it? — Alexis Jazz (talk or ping me) 01:21, 3 December 2023 (UTC)Reply[reply]
Oops. Mentally I had this one going first... my bad. I think this order is better because this one does not require mass messages (because it only impacts people in the future). That brings two benefits: one, we only have to generate a list/write a message/etc. once. Two, people whose signature are both invalid under the current criteria and contain <font>...</font> tags would not be double mass-messaged. HouseBlastertalk 21:56, 3 December 2023 (UTC)Reply[reply]
FRS recipient: My main question is how exactly would that work? If someone included <tt>...</tt> in their signature, would they just get an error message, or would it prompt them to replace the tag with {{mono|}}? Seeing as this could be one of the earliest things someone does after creating an account, we absolutely do not want to make them dive into the wikipedia help documentation to track down accomplishing their preferred signature, especially if they see existing accounts' signatures still using the deprecated functionality before they've been fixed by bot. VanIsaac, GHTVcontWpWS 03:10, 3 December 2023 (UTC)Reply[reply]
I see nothing wrong with shoving headlong into formatting syntax documentation any newcomers whose first orders of business on the website include fancy sig customisation. Folly Mox (talk) 04:19, 3 December 2023 (UTC)Reply[reply]
The issue is when syntax that a new editor sees working for someone else won't work for them. The deprecated html tags work just fine when they make a comment, but for some reason there is an exception when it comes to their signature, but not anyone else's. That's a distinctly WP:BITEY behavior for the interface. VanIsaac, GHTVcontWpWS 08:27, 3 December 2023 (UTC)Reply[reply]
Aren't bots already fixing such signatures with deprecated tags? Aaron Liu (talk) 16:03, 3 December 2023 (UTC)Reply[reply]
@Vanisaac, if you have a disallowed sig (and this RFC proposes to expand what's considered disallowed by software), and you leave a note on the talk page, it will just use the normal, default sig (e.g., like mine, like Folly Mox's, like Johnuniq's). It won't bother you about it; it'll just ignore your disallowed sig and quietly substitute the default.
If you notice it and try to update your prefs, it will not let you save an improper custom sig. It will give you an error message then. Consequently, one approach is that you just try to fix it until you hit upon something that the system will accept. If solving it by the trial-and-error method seems unappealing, then the editor can ask for help. Most people do this at Wikipedia talk:Signatures or Wikipedia:Village pump (technical) or a friend's page.
So that seems like the most unhelpful functionality imaginable. VanIsaac, GHTVcontWpWS 08:27, 3 December 2023 (UTC)Reply[reply]
Why? The options are:
Don't restrict anything in software, or
Restrict invalid sigs in software, and if you happen to have an invalid sig, then prevent you from using talk pages until you fix it (e.g., throw an error message after you have already typed a comment), or
Restrict invalid sigs in software, and if you happen to have an invalid sig, then keep letting you use talk pages with a known-valid sig.
Interfering with normal use of the wikis until you debug your sig would be my candidate for a "worst approach" prize.
As Alexis Jazz corrects below, the first step is to stop people from adding new invalid sigs to their prefs. We could stay in that state for years. WhatamIdoing (talk) 20:18, 3 December 2023 (UTC)Reply[reply]
No, the options actually are:
Do nothing.
Restrict new non-standard sigs, but provide instant feedback on what the problem is and a direct link to a tool tip or the section on the help page that shows you how to accomplish what you are trying to do using current standards and has updated content that would let that user know that some of the solutions won't be valid in signatures.
Restrict new non-standard sigs, providing the same feedback and help AND at some time implement a system to require old editors with non-standard formatting to also update those sigs, providing the same helpful guidance thereby lessening the workload on lint fixing bots.
Restrict new non-standard sigs but implicitly say by your omission of any help or suggestions "ha ha, you saw something somebody else did that you want to do, but we don't allow that any more, but only for new guys, and we're not going to tell you what you did wrong or how to fix it. So fuck you as you try to track down what it is that you did wrong and how to fix it, or you can just give up and become disillusioned with a site that is so massively hostile to new contributors."
If the choice is between fuck you and do nothing, doing nothing is vastly superior as a choice. VanIsaac, GHTVcontWpWS 18:55, 6 December 2023 (UTC)Reply[reply]
The linter already will provide you with a help page to the relevant error when it detects lint errors. In this case, it’ll probably direct you to mw:Help:Lint error/obsolete-tag. I don’t see why you think it’s a choice between whether or not to “fuck you”.I just tested, and it should say “Your signature contains invalid or deprecated HTML syntax” along with a list of problems with a “learn more” link button for each. Aaron Liu (talk) 19:54, 6 December 2023 (UTC)Reply[reply]
Well, the "fuck you" option is what Folly Mox gave me when I specifically asked about how this proposal would be implemented. So maybe you need to get your ducks in a row and give me a straight answer on how this proposal will be implemented. What exactly does the linter tell you? When does it tell you? How does it tell you? How can we make more useful information available? Should we have a validation wizard that would output code fixing linter errors that we could point these new signature editors to? If the intent is to not give a "fuck you", then we need to actually back that up with our actions. VanIsaac, GHTVcontWpWS 20:18, 6 December 2023 (UTC)Reply[reply]
Firstly, I think Folly Mox meant just giving them a link to the relevant doc page when they said shoving. Secondly, just look at this screenshot I found by simply searching "signature lint" on commons (though there has been a very minor difference: instead of bullet points, the extension uses a numbered list now.) Aaron Liu (talk) 23:06, 6 December 2023 (UTC)Reply[reply]
The behavior depends on what stage things are at. In the stage that prevents the creation of new bad sigs, you get instant feedback. That feedback may or may not be understood, but it is instant and provided in bold-faced red letters. In the stage in which old bad sigs are no longer accepted, it silently switches to the default, known-good sig. WhatamIdoing (talk) 07:21, 10 December 2023 (UTC)Reply[reply]
The latter stage seems like a separate RfC. The former's feedback seems pretty clear to me. Aaron Liu (talk) 16:48, 10 December 2023 (UTC)Reply[reply]
After the conclusion of this RfC (regardless of if it is successful or not), I plan to propose that we apply the signature validation rules retroactively (after affected users are mass messaged with pertinent info). Both of these proposals are a simple config change; the retroactive option would default invalid signatures to MediaWiki:Signature, e.g.
This is an example message with a default signature. Example (talk)
How would you know which users to mass message? Aaron Liu (talk) 12:19, 7 December 2023 (UTC)Reply[reply]
Quarry; you can see a partial report at toolforge (note that sig-too-long-post-subst and some of Line breaks would not be affected).HouseBlastertalk 00:15, 8 December 2023 (UTC)Reply[reply]
Wait, that signature length detection is possible and disabled‽ Aaron Liu (talk) 11:57, 8 December 2023 (UTC)Reply[reply]
No, they are not detected/disabled. That's why they would not be affected.HouseBlastertalk 16:55, 8 December 2023 (UTC)Reply[reply]
No, I mean that the substituted length detection is disabled. I really wonder why. Aaron Liu (talk) 17:49, 8 December 2023 (UTC)Reply[reply]
WhatamIdoing, looking at Note that the scope of this proposal has been narrowed to only impact newly saved signatures. it seems users who already have obsolete tags in their signature can continue to substitute that signature on talk pages, they just won't be able to adjust it in their preferences. But presumably if this passes we'll see another proposal down the line to end that grandfather clause. Unless the number of signatures that bots need to adjust ends up being really really low, in which case it could be a non-issue. — Alexis Jazz (talk or ping me) 10:05, 3 December 2023 (UTC)Reply[reply]
Out of curiosity, how would one set one's username's font in their signature without the font tag? — Red-tailed hawk(nest) 05:55, 4 December 2023 (UTC)Reply[reply]
To save people the click: <font face="foobar"> can be rewritten as <span style="font-family:foobar;">.HouseBlastertalk 13:34, 4 December 2023 (UTC)Reply[reply]
Another curiosity: whilst HTML 3.2 allowed the <font> tag to have either or both of the color= and size= attributes, it noted Some user agents also support a FACE attribute which accepts a comma separated list of font names in order of preference. This is used to search for an installed font with the corresponding name. FACE is not part of HTML 3.2.HTML 4 formally added the face= attribute to the syntax, but immediately deprecated it along with the element itself. --Redrose64 🌹 (talk) 11:27, 5 December 2023 (UTC)Reply[reply]
Query: Is <strike>depreciated in favour of <s> or is there another, more convoluted way? Adam Cuerden(talk)Has about 8.6% of all FPs. 23:39, 5 December 2023 (UTC)Reply[reply]
[26]: Use the <del> tag to define deleted text [...] Use the <s> tag to mark up text that is no longer correctAaron Liu (talk) 00:03, 6 December 2023 (UTC)Reply[reply]
And if you want a strikethrough without semantic connotations, you can use <span style="text-decoration:line-through;">.HouseBlastertalk 00:09, 6 December 2023 (UTC)Reply[reply]
Why stop there? We could make everything so much simpler by using <span class="mw-signature-struckthrough mw-signature-nonsemantic-strikethrough" title="nonsemantic-strikethrough" id="struckthrough-nonsemantic-qghlm11j" onclick="" style="font-size:100%; font-family: san-serif; filter: hue-rotate(0deg); text-decoration: line-through; display: inherit; text-align: inherit;" alt="Non-semantically struckthrough signature"></span>. jp×g🗯️ 13:13, 9 December 2023 (UTC)Reply[reply]
This outcome is looking pretty snowy, and discussion seems to have reached a natural conclusion. – Jonesey95 (talk) 20:44, 15 December 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Post RfC: disallowing new signatures obsolete tags close
@Gonnym open a site configuration request in phabricator. — xaosfluxTalk 10:18, 26 December 2023 (UTC)Reply[reply]
In T140606, matmarex wrote: I updated the patch to include a config variable $wgSignatureAllowedLintErrors. It defaults to [ 'obsolete-tag' ] (which allows <font> tags etc.), and you can file a task to change this config to an empty array [] whenever the community of English Wikipedia (or any other wiki) agrees to that. I have filed T354067 to make that request, based on the RFC consensus listed above. If I have made any technical errors, feel free to weigh in with comments or corrections. – Jonesey95 (talk) 00:36, 28 December 2023 (UTC)Reply[reply]
It seems the patch for this has stalled because nobody asked someone on Wikitech to add it to the deploy calendar (see the unresolved comment). Is there a process for asking? Could someone do that? Aaron Liu (talk) 16:50, 10 January 2024 (UTC)Reply[reply]
Hi. I was unexpectedly out of town for a while; I will try to get this done within the next day or two.HouseBlastertalk 19:43, 11 January 2024 (UTC)Reply[reply]
It seems like the patch is finished now. Thanks! Aaron Liu (talk) 22:00, 11 January 2024 (UTC)Reply[reply]
in my signature, and I got an error saying that I was using an obsolete tag. This is good progress. HouseBlaster, is it time for phase 2 of this RFC? As a Linter error fixer, it can't happen soon enough for me. – Jonesey95 (talk) 23:23, 11 January 2024 (UTC)Reply[reply]
Increase default thumbnail size from 220px to 250px
Example at 220pxExample at 250pxExample at 300px
Way back in 2009, English Wikipedia decided to change its default thumbnail size from 180px to 220px (which became the default for all wikis). It's been 15 years since then, and the most common screen resolution is now 1920x1080,[27][28] which makes 220px seem rather small. The Swedish, Norwegian, and Finnish Wikipedias have already switched to 250px and the Dutch Wikipedia switched to 260px(!). Since there are already other wikis using 250px, the impact on the thumbnailing services and thumbnail storage should be manageable (as the most commonly requested thumbnails will already be available in 250px). A 2014 proposal to increase the default size to 300px failed to reach consensus, which is why I'm trying the more modest proposal of 250px (which is the next size up in wgThumbLimits). Nosferattus (talk) 19:00, 5 January 2024 (UTC)Reply[reply]
Support as proposer - After wondering why thumbnails are so tiny on Wikipedia (especially compared to other websites), I finally figured out I could change the default in my preferences, which made me wonder why the default is so small, which led me to research the history of the issue. Seems like a bump in the size is overdue. Nosferattus (talk) 19:04, 5 January 2024 (UTC)Reply[reply]
Support - I've always thought that Wikipedia has frustratingly small thumbnails. 4.16.149.14 (talk) 20:01, 5 January 2024 (UTC)Reply[reply]
Oppose In many case images aren't just used on their own, but side by side with other images (the multiple images template for example). This already leads to cramped text on none desktop screens, and this propodal only makes that worse. Thete is also the issue of |upright= to think of, as this would effect the size from which images are scaled. If images appear to small a setting for larger base size is available in preferences. -- LCU ActivelyDisinterested«@» °∆t° 20:33, 5 January 2024 (UTC)Reply[reply]
The common screen size of phones have also increased. In most cases where the multiple images template is used, it's on its own line instead of sharing with text. IP editors and readers should also be accounted for, and I don't see what considerations upright adds to thumbnail sizes. Aaron Liu (talk) 21:45, 5 January 2024 (UTC)Reply[reply]
Sorry but In most cases where the multiple images template is used, it's on its own line instead of sharing with text is the opposite of my experience. -- LCU ActivelyDisinterested«@» °∆t° 22:01, 5 January 2024 (UTC)Reply[reply]
You're right - the one line ones are "mini-galleries", which are vastly preferable to multiple images, which are used far too often. Johnbod (talk) 04:12, 7 January 2024 (UTC)Reply[reply]
Yep with this increase all horizontal multiple images templates will immediately become to wide. Mini-galleries are definitely a better idea. -- LCU ActivelyDisinterested«@» °∆t° 12:49, 7 January 2024 (UTC)Reply[reply]
Template:Multiple image is used in less than one percent of articles. It has a hard-coded default of 200px and therefore should not be affected by this change at all. WhatamIdoing (talk) 18:30, 7 January 2024 (UTC)Reply[reply]
I still don't see what considerations upright adds to thumbnail sizes. Aren't the considerations of that exactly the same as those for changing the thumbnail sizes? Aaron Liu (talk) 21:36, 9 January 2024 (UTC)Reply[reply]
Upright is scaled from the base image size, so any images that have been set as a specific size using upright will increase in size based on this change. -- LCU ActivelyDisinterested«@» °∆t° 22:57, 9 January 2024 (UTC)Reply[reply]
The same goes for every other iamge. Aaron Liu (talk) 23:11, 9 January 2024 (UTC)Reply[reply]
No. If an image is set to 300px it won't change, but if it's set to 1.36 upright it will increase in size proportional to this change. -- LCU ActivelyDisinterested«@» °∆t° 23:17, 9 January 2024 (UTC)Reply[reply]
So will images not set to any px. Uprights are meant to be relative, I don’t see the problem here. Aaron Liu (talk) 00:45, 10 January 2024 (UTC)Reply[reply]
Then obviously I have failed to explain the point in a way you can understand. -- LCU ActivelyDisinterested«@» °∆t° 13:27, 10 January 2024 (UTC)Reply[reply]
Support - 220px is tiny, especially on a 4K monitor which are becoming more common. I think it would be useful to increase the size, especially since other Wikis already have. 30px isn't much in the grand scheme of things and hasn't caused any issues for me when putting images in infoboxes. --StreetcarEnjoyer (talk) 20:46, 5 January 2024 (UTC)Reply[reply]
Support 220px looks tiny on my screen. I can set my default up to 300px but prefer to see what the readers are seeing. Or not, given the small size on their 4K monitors. Hawkeye7(discuss) 23:02, 5 January 2024 (UTC)Reply[reply]
Meh Personally, despite my screen being 1920×1280, I seldom maximize my browser. Also keep in mind how Vector 2022 shrinks the content area. Anomie⚔ 00:29, 6 January 2024 (UTC)Reply[reply]
As a staunch supporter of V22, I don't think the larger Earth image looks wrong here. (Not sure if that means we should do it though, so I'm neutral.) Aaron Liu (talk) 12:51, 7 January 2024 (UTC)Reply[reply]
@Nosferattus: isn't 360×800 the most common screen resolution (a very quick check showed readership of TFA today at about 2:1 mobile web to desktop web). — xaosfluxTalk 00:41, 6 January 2024 (UTC)Reply[reply]
@Xaosflux: Yes, I think you're correct and 250px (or 300px for that matter) works great at 360×800, as the mobile layout puts images on their own line. Nosferattus (talk) 01:31, 6 January 2024 (UTC)Reply[reply]
Isn't mobile configured separately? I'm pretty sure that we can change the desktop size without changing the mobile size. WhatamIdoing (talk) 04:41, 7 January 2024 (UTC)Reply[reply]
Support. It's not 2009 anymore, and the images look way better bigger. Relativity 02:56, 7 January 2024 (UTC)Reply[reply]
Comment I don't fully understand the importance of screen size here, as I thought WP:VECTOR2022 specifically constrains article width by default. Could anyone with a super-wide monitor clarify? CMD (talk) 03:39, 7 January 2024 (UTC)Reply[reply]
It does by default. But the people !voting here probably either use a different skin or have clicked the button to un-constrain it. Anomie⚔ 04:29, 7 January 2024 (UTC)Reply[reply]
Given the resistance to the community wish of making unconstrained the default, it would be best to make decisions considering restricted width as the most likely one to be encountered by desktop readers. Having a look myself, I don't think 250px creates an issue within the constrained width (and I believe the latest zebradesign has been implemented), but worth keeping this default look in mind. CMD (talk) 14:31, 7 January 2024 (UTC)Reply[reply]
Support I feel like I have to squint to look at images pretty often. This should be an RfC advertised on WP:CENT tho. Galobtter (talk) 03:47, 7 January 2024 (UTC)Reply[reply]
Strong Support Hardly any images except photos of faces can be properly read at 220px. As per Relativity, except even in 2009 our images looked too small. Johnbod (talk) 04:10, 7 January 2024 (UTC)Reply[reply]
Support. I'd prefer jumping straight to 300px (and I think mw:Ops would, too), but 250px is fine and an improvement over what we have now. Somewhat bigger images are easier for people to see (e.g., if you're old enough to use reading glasses, which I'm sure I set down somewhere just a minute ago), but they also make the pages seem more interesting. I set mine to 300px last year, and I've never regretted it, and you can, too: go to Special:Preferences#mw-prefsection-rendering-files and change the thumbnail size. As noted above, several other communities have made this change already, and I'll add that AFAIK no community has ever switched to a bigger number, regretted it, and then asked to be switched back to a smaller size. BTW, because the English Wikipedia is the largest wiki in the history of the world, etc., the actual switch is something that requires a bit of planning. This is not difficult – in fact, on our end, it's really quite easy – but we should not be surprised, e.g., if we get an official request to manually set the images in the very most popular articles (probably on the order of the top 0.01% by page views) to the new size in advance of the official switchover. We can send a bot around to do this (and also to undo it after the switch is made), and that will take some of the strain off the servers on the magical day (plus give both editors and readers a way to see the change in action before it happens everywhere). Let's do this. WhatamIdoing (talk) 04:55, 7 January 2024 (UTC)Reply[reply]
Support per WhatamIdoing. I've had a default size of 300px for a couple of years now, and it's hugely improved the desktop reading experience. MichaelMaggs (talk) 11:09, 7 January 2024 (UTC)Reply[reply]
Oppose We still also must consider mobile screens, and going above 220 px will put a strain on those readers. If you are on desktop, you can set the default size through a registered account to handle this. Masem (t) 18:32, 7 January 2024 (UTC)Reply[reply]
Why would it? As mentioned above, since images are put on their own line in mobile, having bigger images is nice and causes no issues. I just increased my thumbnail size to 300px and it looks great - a lot of images are a lot easier to see that way (Special:Preferences#mw-prefsection-rendering-files also affects mobile, so you can test it for yourself). 250px is not going to cause any issues for mobile. Galobtter (talk) 18:53, 7 January 2024 (UTC)Reply[reply]
I disagree, I find larger thumbs on mobile to be too large for a reasonable reading experience. Masem (t) 20:13, 7 January 2024 (UTC)Reply[reply]
I'll also add that there is an issue with anything larger than 220px for a large chuck of non-free images, which we have constrained to 0.1MP. Many portrait non-free images like movie posters end up with image sizes around 400 x 225 px to stay within the 0.1MP. Thumbnail sizes over 220 px will implicitly and incorrectly imply that non-free images can be uploaded to larger sizes, which will not happen. Masem (t) 20:19, 7 January 2024 (UTC)Reply[reply]
Is there any actual legal basis for 10% of a megapixel? My impression is that this was more or less a random number pulled out of somebody's. jp×g🗯️ 15:42, 8 January 2024 (UTC)Reply[reply]
No, it’s just something we picked. The legal precedent is only that the usage has to be ‘minimal’. If u have a retina screen in many cases u already get noticeably pixelated thumbnails for non free images. Upping the thumbnail size would increase that problem. —TheDJ (talk • contribs) 21:35, 9 January 2024 (UTC)Reply[reply]
Also, 250x400 px = 0.1MP exactly, so we could have the same height on a vertical image. US theater posters have a ratio of 27:40, so we'd be expecting to see uploads at 250x370px. WhatamIdoing (talk) 02:16, 10 January 2024 (UTC)Reply[reply]
Support, especially for mobile. I've got a tiny screen for a mobile, and default thumbnail has a lot of ugly white around it. On desktop it's a no-brainer; I usually set upright=1.35 to ensure images/graphs are easy to see. By choosing a better default, fewer people will need to rescale. Many people rescale using the px parameter, which causes accessibility issues, so another plus if that is avoided. My guess is that a default of 300px or 260px would be even better. —Femke 🐦 (talk) 18:58, 7 January 2024 (UTC)Reply[reply]
Support - Sensible suggestion. I would even support 300px in the future. Schierbecker (talk) 19:07, 7 January 2024 (UTC)Reply[reply]
Support Looks good, more accessible, and none of the concerns raised bother me. ~ F4U (talk • they/it) 19:12, 7 January 2024 (UTC)Reply[reply]
Support as a longtime smartphone user. My phone can easily handle the larger images. Cullen328 (talk) 19:13, 7 January 2024 (UTC)Reply[reply]
Support Jeez, I remember it was pulling teeth to get the thumb size bumped up years ago, and now it's been more than a decade? I think we are hitting the useful limits of thumbnail size at 250px, given that a) lots more reader use is mobile, which is width-restrained, and b) the WMF's Vector redesign harms screen horizontal real estate for the vast majority of readers and it's likely even if they're browsing full-screen at 1920x1080, they don't necessarily have correspondingly more content area, but I think the small bump proposed here is sensible. Der Wohltemperierte Fuchstalk 19:24, 7 January 2024 (UTC)Reply[reply]
The mobile width of an average mobile screen is 360 to 440 ‘non-retina’ pixels. With margins removed that’s about 300 to 360 web pixels. Above that width, the skin will scale down the image. —TheDJ (talk • contribs) 21:39, 9 January 2024 (UTC)Reply[reply]
Support. This is less of an issue with Vector 2022, which makes the horizontal area much smaller, but I still recommend it be done. I myself have manually set the thumbnail size to 400px so I can see more in Vector 2017, which is the skin I use. SWinxy (talk) 19:45, 7 January 2024 (UTC)Reply[reply]
And, yes, I would also support 300px thumbnails too. SWinxy (talk) 18:03, 9 January 2024 (UTC)Reply[reply]
Support I set my personal default to 400px some time ago and that's fine so even 250px is small. And I'm not using anything special – mostly a 1920 x 1080 laptop or a smartphone. Andrew🐉(talk) 21:09, 7 January 2024 (UTC)Reply[reply]
Support: aesthetically, I like the current size better, but that's no reason to oppose, just my opinion. I am convinced by supporter's arguments above. 🌺 Cremastra (talk) 22:41, 7 January 2024 (UTC)Reply[reply]
Support. I do not see downsides to this proposal. Screens are significantly larger than they were a decade ago, so they should be able to handle slightly larger thumbnails just fine. For non-free media, that means the media will likely be smaller than the proposed new default, but that is only a minor issue. Conversely, I think 250px default thumbnails would be a significant benefit for both desktop and mobile users, especially seeing how many articles already use images that are 250px or larger in their infoboxes. – Epicgenius (talk) 23:28, 7 January 2024 (UTC)Reply[reply]
The "0.1 megapixels is an ironclad rule we bot-enforce" definition of "low resolution" is something else that probably needs revisiting in a separate discussion. Der Wohltemperierte Fuchstalk 01:00, 8 January 2024 (UTC)Reply[reply]
Yeah that seems like a very arbitrary rule we could relax without issues. Galobtter (talk) 14:56, 8 January 2024 (UTC)Reply[reply]
In that case, I don't think there are any other issues with upscaling the default thumbnail size to 250px. Although I definitely see why there is a size limit for non-free media, I agree the 0.1 megapixel limit seems arbitrary (for example, why can't it be 0.11 or 0.12 megapixels, which would allow non-free media to be slightly wider?). – Epicgenius (talk) 19:56, 8 January 2024 (UTC)Reply[reply]
Strong support - sane defaults make the world go round. There's always option for templates and or individuals to hard-code other sizes. ~ 🦝 Shushugah (he/him • talk) 23:59, 7 January 2024 (UTC)Reply[reply]
Support, a really good idea. Now hopefully somebody will get around to increasing the default text size, probably small enough that it was designed for 18-year-olds with the eyesight of eagles. Randy Kryn (talk) 00:32, 8 January 2024 (UTC)Reply[reply]
Support Reading and commenting from mobile to say that this looks better on the mobile version of the wiki and doesn't raise any issues there. CoconutOctopustalk 12:20, 8 January 2024 (UTC)Reply[reply]
Support going straight to 300px; I am almost kind of reticent to support going to 250px because we might end up stuck there for another fifteen years. 300px is, I'd say, close to an absolute minimum for things being legible. 220px is so mindbogglingly tiny I can't even explain it without using language from the old country:
>220px thumbnails
>2011
I seriously hope you guys don't do this
All else aside, this is a great idea and overdue. jp×g🗯️ 15:33, 8 January 2024 (UTC)Reply[reply]
For reference, here is a screenshot of this page on a 4K monitor at 100% zoom level lol.Please sir may I have some more pixelsjp×g🗯️ 15:38, 8 January 2024 (UTC)Reply[reply]
The default skin has limited width, not to mention most use 1080p monitors. You may make it 300 for yourself. Aaron Liu (talk) 15:42, 8 January 2024 (UTC)Reply[reply]
The default skin was not handed to us on tablets from heaven; it was made by designers in accordance with the constraints of the project, one of which was that thumbnails were 220 pixels wide. This seems like a rather circular problem: we can't increase the thumb resolution because the skin wasn't designed around them, and the skin won't be designed around larger thumbnails because we don't use them? jp×g🗯️ 20:45, 8 January 2024 (UTC)Reply[reply]
Hmm, I've searched a bunch of places and I can't seem to find a place that says V22 was designed on the basis of 220px thumbs. Aaron Liu (talk) 20:59, 8 January 2024 (UTC)Reply[reply]
Expecting the WMF to react to changing thumbnail sizes on a single project (even the main one) seems unlikely, and the default fixed-width page layout is how the vast majority of users will experience the site. (As an aside, one reason for the page width limits is that the longer lines go, the harder it is to read, hence one reason why you never ended up with extremely horizontal books. I dunno who is browsing Wikipedia at full-width and full 4K resolution, but that's objectively a worse way to experience it, and we shouldn't be considering those edge cases when making decisions for the majority.) Der Wohltemperierte Fuchstalk 16:14, 9 January 2024 (UTC)Reply[reply]
I use limited width and even then the width is wide enough to justify 250px thumbs. Aaron Liu (talk) 16:43, 9 January 2024 (UTC)Reply[reply]
Weak support. It's a marginal change, but apparently important enough to end up at CD. Oh well – I kinda like bigger images anyway. I can't support this beyond personal opinion on aesthetics, but I'd be willing to put a Weak Support on it. InvadingInvader (userpage, talk) 15:57, 8 January 2024 (UTC)Reply[reply]
Support per WhatamIdoing given that the screen resolutions of both computer and mobile screens has increased since 2009 designation. BluePenguin18 🐧 ( 💬 ) 16:35, 8 January 2024 (UTC)Reply[reply]
Support per WAID. Personally, I use 300px, which works fine also on my phone. —Kusma (talk) 18:21, 8 January 2024 (UTC)Reply[reply]
Strong support - Increasing to at least 250px (if not 300px) makes sense in relation to more advanced mobile phones and desktop screens. As a visual thinker and learner (as opposed to a "word person") this change would also increase literacy for those of use who are visually dominant. Therefore I see it as an accessibility issue as well. Netherzone (talk) 18:36, 8 January 2024 (UTC)Reply[reply]
Support Just like with money inflation, keeping as the relative same as 15 years ago would be about 500px and 250 is a tiny step in comparison. North8000 (talk) 19:04, 8 January 2024 (UTC)Reply[reply]
Support as web design best practice. I broached this idea back in 2020, and given the response here it seems I shouldn't have let myself be talked out of it. I've had my personal preference set to 250px ever since then — it's nice, and I'd like to give readers that same experience. I find the opposes generally unconvincing (Masem's fair use concerns seem at least a bit valid, but as TheDJ notes, a bit of pixelation is already happening on high-resolution devices, which are becoming more common over time, so it's water under the bridge; and I don't have any problem with people uploading larger fair use images that then get automatically reduced, nor with us exploring raising the 0.1MP standard). {{u|Sdkb}}talk 00:24, 10 January 2024 (UTC)Reply[reply]
Support without prejudice against further increases. – Teratix₵ 04:30, 10 January 2024 (UTC)Reply[reply]
Support And wouldn't be opposed to something larger than 250px too -Fastily 22:48, 10 January 2024 (UTC)Reply[reply]
Support: I've previously thought 220px was too small on desktop, and an increase to 250px seems reasonable even considered the limited width of Vector 2022 (which improves readability and skimming). — Bilorv (talk) 23:48, 13 January 2024 (UTC)Reply[reply]
Support Yes please, it would be a much more sensible default! Leijurv (talk) 21:40, 15 January 2024 (UTC)Reply[reply]
Support Good size and looks better on bigger screens Isla🏳️⚧ 00:36, 17 January 2024 (UTC)Reply[reply]
Increasing to 300px
Even though there is overwhelming consensus to increase resolution, 250px is a very small jump and in my opinion it should be increased to 300px. In the 2000s, the most common screen resolutions are 800x600 and 1024x768. Now, the most common resolution are 1080p, which is 1920x1080. 1920/1024 = 1.875, so in theory we should scale the image to 400px, but that's too large because New Vector has a fixed width for content. So, I made a test to determine whether 300px is truly the optimal image size. In one page, I opened Earth in default New Vector and preview it in 300px. In another page, I opened the same article in the Internet Archive as it looks like in 2008 and use a browser tool to set a 1024x768 resolution and then scale the page until both article's text looks at around the same width. Indeed, in both pages, the image looks almost exactly in the same proportion. I'm uploading screenshots of my test to Wikimedia Commons for others to see. CactiStaccingCrane (talk) 10:53, 9 January 2024 (UTC)Reply[reply]
Also, I would like to add that increasing picture resolution helps with printed and offline version of Wikipedia where there is no option to browse the full-res picture. That's why I consider 250px to be too small of a change. CactiStaccingCrane (talk) 02:52, 10 January 2024 (UTC)Reply[reply]
Oppose. The scaled version is definitely closer to 250px. The picture of Earth is a square image, while a lot more images are landscape. In my experience, for such images, 300px covers up way too much text. Aaron Liu (talk) 12:41, 9 January 2024 (UTC)Reply[reply]
It's not too helpful an image as the Earth image appears to be in an infobox that maintains its width, however as the pixel scaling is horizontal a landscape image would cover up less text than a square image. CMD (talk) 14:10, 9 January 2024 (UTC)Reply[reply]
Could we have an example with regular image thumbs instead? Aaron Liu (talk) 14:32, 9 January 2024 (UTC)Reply[reply]
I'm a bit tired today, so can someone else make the example pic? CactiStaccingCrane (talk) 16:47, 9 January 2024 (UTC)Reply[reply]
300px covers up way too much text – Um, it doesn't cover up any text. Bigger images do take up more vertical space, but if it's actually overlapping with the text, then you should probably be at the Wikipedia:Help desk or Wikipedia:Village pump (technical) with a screenshot showing how the image prevents you from seeing all the words on the page. WhatamIdoing (talk) 02:23, 10 January 2024 (UTC)Reply[reply]
Bigger images will cause words to run away from the image, which is what I meant by "cover up", not literally overlap. Aaron Liu (talk) 03:16, 10 January 2024 (UTC)Reply[reply]
Support as the inevitable outcome. We will someday do this. Why not now? WhatamIdoing (talk) 02:23, 10 January 2024 (UTC)Reply[reply]
Because current popular screen sizes aren't fitted for such large image sizes. One day your local wages will inflate, but that doesn't mean we should inflate them now. Aaron Liu (talk) 03:16, 10 January 2024 (UTC)Reply[reply]
Support, that's what I use and it is great both on my laptop and on my smartphone. (I rarely use ultra-wide screens). —Kusma (talk) 13:32, 10 January 2024 (UTC)Reply[reply]
Oppose per my rationale above. Were default Vector not restricting width I would possibly feel differently, but it is what it is, and given image/template sandwiching issues a more conservative default is a bit less ungainly in edge cases. Der Wohltemperierte Fuchstalk 13:59, 10 January 2024 (UTC)Reply[reply]
Support Also fine with this. Johnbod (talk) 18:59, 10 January 2024 (UTC)Reply[reply]
Support Per above, this is also fine. -Fastily 22:50, 10 January 2024 (UTC)Reply[reply]
Support but note significant work --> a change from 220px to 250px will mean that some images with be a bit on the large size (with upright=1.35 for instance), but not too ugly. When we change it to 300px, a lot of images with upright=1.35 or upright=1.5 will have become too big. We may want to find consensus to change the upright parameter automatically under certain conditions (f.i. upright>1.35.. ). —Femke 🐦 (talk) 17:55, 12 January 2024 (UTC)Reply[reply]
This was part of my reasoning for opposing both changes, if the default is increased any images set with upright will become the wrong size. Some kind of automated correction would certainly help. -- LCU ActivelyDisinterested«@» °∆t° 21:00, 12 January 2024 (UTC)Reply[reply]
Oppose. 300px simply looks too big on my laptop screen (effective resolution 1280×800, using Vector Legacy). Even worse on my smartphone (also using Vector Legacy which I understand is an edge case), where the image takes up about 40% of the page width. —pythoncoder (talk | contribs) 21:18, 12 January 2024 (UTC)Reply[reply]
Support I set my personal default to 400px some time ago and that's fine so even 300px is small. And I'm not using anything special – mostly a 1920 x 1080 laptop or a smartphone. Andrew🐉(talk) 09:05, 16 January 2024 (UTC)Reply[reply]
On Vector 2022, with both toolbars floating? Aaron Liu (talk) 12:34, 16 January 2024 (UTC)Reply[reply]
Oppose seems to be too big on smaller devices like phones and has some issues with Vector 2022 right now I might support in the future if Vector 2022 is fixed Isla🏳️⚧ 00:32, 17 January 2024 (UTC)Reply[reply]
Erm, fixed? The design of max. width + toolbars is not gonna change and is a feature, not a bug. Aaron Liu (talk) 02:12, 17 January 2024 (UTC)Reply[reply]
Discussion (thumbnail size)
Can't we use something that depends on the actual current width of the page? Vector 2022 allows that to change with the click of a button; why shouldn't the images become larger if the screen is larger? Maximum and minimum values, and even the height of the screen, can be calculated freely and automatically. For example, we could define that an image's maximum width is the minimum of: 20% line width, 100% view height, 400px. ~ ToBeFree (talk) 19:04, 12 January 2024 (UTC)Reply[reply]
What about mobile, where images need to be on their own line? Aaron Liu (talk) 19:10, 12 January 2024 (UTC)Reply[reply]
This can all be specified in stylesheets. If "mobile" refers to a mobile design, at MediaWiki:Mobile.css. If "mobile" is Vector 2022 on a mobile screen, by using media queries or universal definitions (such as my "minimum of" example above). ~ ToBeFree (talk) 23:35, 12 January 2024 (UTC)Reply[reply]
Dynamic scaling of content, not just images, should be the way forward. This would ultimately allow for a single page style regardless of screen size or aspect. -- LCU ActivelyDisinterested«@» °∆t° 20:55, 12 January 2024 (UTC)Reply[reply]
As I understand it, somewhere in the server infrastructure, the thumbnail images have been generated and cached for fast delivery (thus WhatamIdoing's suggestion that the size be manually changed for high-traffic articles in advance of switching the default, to take the load off the servers from generating images on-demand until the cache has been re-generated). Thus having the thumbnails with different pixel sizes based on each user's window size would have a significant impact on performance. It is theoretically possible to specify a maximum limit for the space in which the thumbnail is rendered, though, so it won't take up more than a certain amount of the available content space regardless of the pixel size of the image. I've never looked closely at how it works under the hood, though, so am not sure how much rework might be needed. Cases where editors have used an {{{upright}}} scaling factor > 1 to deliberately exceed the usual horizontal space allocated would have to be accommodated, which might be tricky. isaacl (talk) 21:47, 12 January 2024 (UTC)Reply[reply]
Ah, thumbnail caching is a point I hadn't thought about. But if we use the "minimum of: 20% line width, 100% view height, 400px" example, we can serve 400px thumbnails and they'll never have to be upscaled. Or, taking "upright" into account, the limits could be "20%*upright width, 100% width, 100% height and 400px*upright", with 400px*upright thumbnails, I guess. ~ ToBeFree (talk) 13:06, 13 January 2024 (UTC)Reply[reply]
Yes, as I said, it would be possible to limit the space in which the image is rendered while serving it at a specific size, though I am uncertain about the amount of changes required for implementation (it could require work both in the MediaWiki code as well as the wikitext source). As any applied scaling factor isn't a fixed value (or one of a fixed set of values), however, accommodating it with a CSS rule would require custom CSS to be generated for each instance and targeted for the specific image. Given how the cascade works, I'm not sure if the template can cleanly manage this on its own (though I suppose as a kludge it could manually replicate a common rule while adding additional constraints). (Javascript code could apply an appropriate rule, but this would result in layout shifts, as well as requiring the user agent to support Javascript.) isaacl (talk) 17:51, 13 January 2024 (UTC)Reply[reply]
Improvement to how Wikipedia handles multiple citations of the same source.
Currently multiple citations to the same source are handled reasonably well, with a number appearing in superscript in the body multiple times, with the same number appearing just once in the references list, with letters (a, b, c, etc) after the number allowing you to return to the exact place in the article that you were up to, however, the reader won't necessarily know whether they were up to a, b, c, or whatever. Sure, it's usually not too hard to find your place, but it could be made easier if the in-text superscript said for example, 8a, 8b, 8c, etc rather than just using the same repeated numeral for multiple citations of the same source. MathewMunro (talk) 05:38, 7 January 2024 (UTC)Reply[reply]
When clicking the numbered link to get to the ref, the ref becomes highlighted. Maybe the specific 'a', 'b', etc. could be specially denoted there? That would be an extension with consistent behavior. Changing the way the footnote marker is written in the text seems more confusing to readers, since it suggests that either there are different refs ('8a' vs '8b') or that there are different subparts of ref 8 (some refs do bundle multiple entries). DMacks (talk) 05:50, 7 January 2024 (UTC)Reply[reply]
Sure, the reference becomes highlighted, but whether you have to click on 'a' or 'b' or whatever to get back to where you were is not clear, whereas if the superscript in the body of the article said '8a' or '8b', it would be pretty clear which one you were up to. An alternative would be to differentially highlight the 'a' or 'b' after the '8' or whatever number & letter it was in the references after you click on the superscript number in the body of the article, so you know which letter to click on to get back to where you were, or some similar means of making it stand out so that people know which one is the one to click to get back to where they were. MathewMunro (talk) 10:23, 7 January 2024 (UTC)Reply[reply]
It sounds like you are objecting to my proposal of do exactly what you later wrote as your alternative:) To wit, I wrote "clicking the numbered link to get to the ref...the specific 'a', 'b', etc. could be specially denoted [in the ref after clicking]". DMacks (talk) 14:11, 7 January 2024 (UTC)Reply[reply]
Sorry, I didn't understand what you meant by 'Maybe the specific 'a', 'b', etc. could be specially denoted there?', but I'm on the same page now :)
And yes, that would be a smaller and for some a less confusing change. Highlighting the specific 'a', 'b', etc in a different colour would be one effective way of specially denoting which hyperlink to click on to get back to where you were. MathewMunro (talk) 14:39, 7 January 2024 (UTC)Reply[reply]
This seems like it would be confusing in combination with T100645, which IMO would be far more useful than this. Particularly since it seems to me that the browser's back button is more convenient than trying to figure out whether 'a' or 'b' or whatever is the right tiny link to click to get back, assuming someone isn't just using the Reference Tooltips gadget in the first place. Anomie⚔ 14:05, 7 January 2024 (UTC)Reply[reply]
That phab task looks like it would be a software replacement for {{rp}}? That sounds helpful. I agree that the idea floated here, of adding letters to the citation numbers[2b] would be more confusing than anything else, and imply a seperate work or portion of work supporting the cited claim despite actually being the same.[2a] Seems like it might also interfere directly with the citation style of some articles, which use ref groups to generate citation numbers with a similar format.[C 2]I'm not necessarily against a software patch to use javascript to change the metrics of the hopback link followed to make it easier to guess, but: the tiny sliver of the userbase that actually interfaces with citations probably reads them through an on-hover or single tap, without clicking through to the reflist; whenever I guess wrong, I tap "back" in the browser and guess again; most multiply cited sources shouldn't have so many different loci of citation that it's a difficult or tedious process to find the correct hopback link; and those that are cited that many times will probably be recognisable based on their oft repeated citation numeral, negating the need to click through to it after the initial few appearances. Folly Mox (talk) 14:29, 7 January 2024 (UTC)Reply[reply]
Thanks for the tip. I didn't realise just using the browser's back button would take me back. Although I noticed that when using the back button, the reference will be somewhere on the page, depending on where it was (top, middle or bottom of the page) when you clicked on the reference, but clicking the correct 'a', 'b', 'c', etc hyperlink in the references will set the relevant line in the body of the article to the top of the page, making it easier to find. I realise that most people can find a reference that's somewhere on the page pretty easily, but it is easier to find it in my opinion if it's at the top of the page.
I accept that there are drawbacks of using a 1a, 1b, 1c, etc referencing style, and so forget about that. How about instead we do either one or preferably both of the following:
1. Make the back button take you to the place you were, but with the line containing the reference set to the top of the page; and
2. After you click a citation superscript numeral in the article's body, highlight & bold the relevant 'a', 'b', or 'c', etc in the references that you have to click on to get back to where you were?
Although, I just noticed that if you click the little '^' symbol in the references, it does exactly what I want it to do, and the hover works well too, so maybe it's just a matter of learning how to use it properly :) although, there's nothing wrong with having multiple ways of accomplishing the same thing. MathewMunro (talk) 14:49, 7 January 2024 (UTC)Reply[reply]
Neither of these is a good idea. We should not attempt to change how the browser's "back" button behaves. Some websites do this, by various means including server-side immediate redirection, client-side immediate redirection, and Javascript that actually modifies the botton's action. It can mean that you get trapped on that website with no way of getting back to where you came from - this might of course be intentional, but it's not what we want for our readers.
When you follow a link from a superscripted ref marker to the ref itself, or from the backlink on the ref to the superscripted ref marker, the place that you reach gains a pale blue background; this is due to a CSS rule:
The first selector (ol.references li:target) goes for a whole list item in the references section. To pick out an individual backlink within that list item could be possible, but would mean that the individual backlink would need to be the target of the link from the superscripted ref marker, and since this is not the whole ref, the pale blue background would be less visible. Such changes - even if agreed on here - would need to be requested through phab:. --Redrose64 🌹 (talk) 18:18, 7 January 2024 (UTC)Reply[reply]
Agreed modifying the back button behaviour would be bad if it had any kind of spill-over effect trapping you on a page. I certainly don't know enough about web-programming to know whether or not it could be done in a way that only does what it's supposed to do on all browsers & devices. And if you had to choose between highlighting the whole reference and highlighting just the relevant 'a' or 'b' or whatever, you would certainly be better off just leaving it the way it is, especially seeing as clicking the '^' symbol takes you back to where you were even if you don't know whether it was reference 'a' or 'b' or whatever. But if you could differentially highlight both the whole reference and the relevant 'a' or 'b' or whatever, (or change the text colour of the relevant 'a' or 'b' or whatever in addition to highlighting the whole refernece) that would be ideal, but again, this would only be a very very marginal improvement. I'm happy to let it go :) MathewMunro (talk) 21:07, 8 January 2024 (UTC)Reply[reply]
Please see this discussion for a proposal to enable archiving of discussions at pages like WP:Help desk that have level-one headings to group discussions by date in the Table of Contents. Afaict, Help desk archiving currently happens N days after the *first* message of the day was posted, regardless of how recent the last message was. Mathglot (talk) 00:25, 10 January 2024 (UTC)Reply[reply]
One idea I propose on how to shorten them is to rewrite the banner article template in three sentences, each in one line at normal text size, just like {{Afd}}:
Stated rationale for deletion
Link to contest speedy deletion
Encourage editors to improve the article and link to speedy deletion process in general
Ok, that's quite a lot of templates. I think it would be much better for individual editors to be bold and edit the templates directly, after this discussion resulted in a consensus of action. CactiStaccingCrane (talk) 15:51, 11 January 2024 (UTC)Reply[reply]
The problem is they're all template-protected, and highly used. I think it'd be better to try to hash out at least the rough wording for each beforehand – just to reduce lots of subsequent edit requests, there doesn't have to be a big discussion of each one or anything. – Joe (talk) 15:53, 11 January 2024 (UTC)Reply[reply]
This would mean that the unbolded message at {{db-meta}} template would needs to be drastically shortened, the user notification request and the "last edited at X" be removed. {{AfD}} has proved that we don't really need these in the banner. CactiStaccingCrane (talk) 16:04, 11 January 2024 (UTC)Reply[reply]
@CactiStaccingCrane, CENT-listed discussions tend to go better when there is a concrete, fully defined proposal for editors to !vote on. I'd suggest holding off on listing until you have finished crafting the proposed changes at the subpage. {{u|Sdkb}}talk 16:29, 11 January 2024 (UTC)Reply[reply]
This template may meet Wikipedia's criteria for speedy deletion{{{1}}}.See [[Wikipedia:Criteria for speedy deletion#{{{CRITERION}}}|CSD {{{CRITERION}}}]].
If this template does not meet the criteria for speedy deletion, or you intend to fix it, please remove this notice, but do not remove this notice from pages that you have created yourself. If you created this page and you disagree with the given reason for deletion, you can click the button below and leave a message explaining why you believe it should not be deleted. You can also visit the talk page to check if you have received a response to your message.
[button]
Note that this template may be deleted at any time if it unquestionably meets the speedy deletion criteria, or if an explanation posted to the talk page is found to be insufficient.
[timestamp]
And here's my proposal:
This template may meet Wikipedia's [criteria for speedy deletion{{{1}}}.] [link directly to the specific criterion for speedy deletion]
You are welcome to contest this speedy deletion by leaving a message at [link to contest speedy deletion].
Feel free to improve the article, but do not remove this notice if you have created this page. For more information, see the guide to speedy deletion.
I would contest that change. You're making significant change to the guidance to (non-creator) users which is contrary to the text of the actual policy. Anomie⚔ 13:28, 14 January 2024 (UTC)Reply[reply]
Could you mention specifically what policy is being violated? I'm just trying to make speedy deletion templates follow {{Article for deletion}} templates since the AfD banner is already well-accepted by the community. CactiStaccingCrane (talk) 13:31, 14 January 2024 (UTC)Reply[reply]
CSD tags are generally allowed to be removed by anyone except the creator. Your changed wording suggests that everyone has to go to the link to contest it. Anomie⚔ 13:43, 14 January 2024 (UTC)Reply[reply]
In 2020, as part of the DiscussionTools project, signature validation was added to MediaWiki. Since its implementation, users have been unable to save an "invalid" signature in Special:Preferences. A "valid" signature must:
link to the user's userpage, talk page, or contributions
not abuse template substitution in specific ways (namely, no forging signatures and no adding line break characters)
These changes have been in place since 2020, but they only prevent someone from saving a new signature. Invalid signatures from pre-2020 are still permitted by the software. If implemented, users with invalid signature preferences would have the standard signature (MediaWiki:Signature: [[User:Example|Example]] ([[User talk:Example|talk]])) applied when signing until such time as they update their signature preference. Affected users would be warned a month in advance of this change.
Technical implementation: this would be implemented by setting $wgSignatureValidation to disallow, after sending a MassMessage to all affected users at least a month in advance.
Support as proposer. There are many reasons this is a good thing. The most obvious is that invalid signatures are A Bad Thing, and getting rid of them is thus A Good Thing. All invalid signatures violate WP:SIG in some way, so this cuts down on problematic signatures. Additionally, I would argue it is unfair that this validation is only applied to new editors. HouseBlastertalk 03:47, 12 January 2024 (UTC)Reply[reply]
Support. I do not see the harm in this, as signatures are mostly an aesthetic thing, and the reasons given are practical. Practicality should usually outweigh aesthetics. ― novov(tc) 10:08, 12 January 2024 (UTC)Reply[reply]
Support Definitely a positive change, best to phase out invalid signatures that might be causing software issues. Sohom (talk) 15:47, 12 January 2024 (UTC)Reply[reply]
Support As with my comment in the last RFC as long as editors are running round fixing these errors we should avoid making new ones. -- LCU ActivelyDisinterested«@» °∆t° 15:48, 12 January 2024 (UTC)Reply[reply]
Support, this will reduce the need for linter bot edits, and a month's notice is more than sufficient for people to either correct the issues, or ask for help doing so if they need it. The proposed notice should point them to where they can ask for technical help if they're not sure what they need to fix or how to do it. SeraphimbladeTalk to me 15:48, 12 January 2024 (UTC)Reply[reply]
Support. In addition to disabling bad or broken syntax this will also reduce the need of editors and bots to fix these, this reducing watchlist spam and angering other editors. --Gonnym (talk) 16:23, 12 January 2024 (UTC)Reply[reply]
Support. It has been more than three years since the new rules went into effect. They should be applied to everyone at this point, with no grandfathering effects. – Jonesey95 (talk) 16:37, 12 January 2024 (UTC)Reply[reply]
Strong support all but obsolete tags and Plain fancy signature, which I’m neutral to as forbiddance of the former were only implemented yesterday and the latter doesn’t actually do harm. I’ll switch if somebody can demonstrate that there aren’t much people using the former and the latter won’t be reset. It’s also disappointing the subst thing isn’t checked. Aaron Liu (talk) 16:50, 12 January 2024 (UTC)Reply[reply]
Support - the HTML Wikipedia publishes today should comply with today's HTML standards. Levivich (talk) 16:53, 12 January 2024 (UTC)Reply[reply]
Support as a practical measure. Grandfathered users do not deserve any special exemption. I forecast white fluffiness and encourage someone to close this once it's been up for a few days. {{u|Sdkb}}talk 17:00, 12 January 2024 (UTC)Reply[reply]
Oppose I don't see the point of locking older users out of signing pages because they use the font tag --GuerilleroParlez Moi 09:57, 13 January 2024 (UTC)Reply[reply]
from the way I see the RfC , the users will not be locked out from signing pages. The RfC is basically about resetting the signature output to default if they don't fix/update their signatures by a set time. – robertsky (talk) 10:04, 13 January 2024 (UTC)Reply[reply]
Editors will be able to sign their posts. The RFC says "users with invalid signature preferences would have the standard signature ... applied when signing". – Jonesey95 (talk) 14:57, 13 January 2024 (UTC)Reply[reply]
Support. I recall a couple times where editors decided to edit war to retain <font> tags in their signatures. This will at least reduce or eliminate new signatures with linter errors. I hope the advance warning includes a link to instructions on how to update signatures with deprecated tags. Philbert2.71828 18:49, 13 January 2024 (UTC)Reply[reply]
Support per Levivich HTML standards. SWinxy (talk) 19:35, 13 January 2024 (UTC)Reply[reply]
Support: an uncontroversial rollout of existing technical decisions (which, in turn, enforce existing guideline/policy/good practice/common sense). — Bilorv (talk) 23:52, 13 January 2024 (UTC)Reply[reply]
Support. This will reduce invalid signatures and be a more consistent application of rules. Hanif Al Husaini (talk) 00:03, 16 January 2024 (UTC)Reply[reply]
I believe the report linked immediately above lists only people who have posted to any talk spaces in the last three months. That catches most of the people whose signatures would be causing errors in current discussions, but there are no doubt thousands of inactive editors with invalid signatures. There are also thousands of editors with font tags in their signatures; those editors are not listed on the above report. It is an open question as to whether they will really be "affected" if they are inactive, but I'll leave that one to the philosophers. Importantly, no existing pages will be edited or changed as a result of this RFC. It affects only editors' saved signature preferences. – Jonesey95 (talk) 16:39, 12 January 2024 (UTC)Reply[reply]
Note that 102 of these are simply signatures without wikitext that have the "treat as wikitext" box ticked. Aaron Liu (talk) 16:50, 12 January 2024 (UTC)Reply[reply]
@HouseBlaster: I was not notified by the above. Please edit this section to delete your comment, then save. Then edit again to add the same comment but with a new signature. Johnuniq (talk) 04:50, 12 January 2024 (UTC)Reply[reply]
We may want to notify the people who this would affect. Is there any objection if I were to drop a note on their talk pages? — Red-tailed hawk(nest) 15:45, 12 January 2024 (UTC)Reply[reply]
Once again, please note that the "sig-too-long-post-subst" editors should not be notified, because they will not be affected by this change. Also, editors whose only error is using obsolete (font or tt or strike) tags in their signatures should have their signatures reset, but they are not listed in the report linked above. We will need to scrape some database or other in order to find them. – Jonesey95 (talk) 16:43, 12 January 2024 (UTC)Reply[reply]
I don't remember participating in these discussions?—CYBERPOWER(Around) 14:30, 14 January 2024 (UTC)Reply[reply]
There was just a reference that you would have been personally impacted, as it was reported that at the time you were on this list. — xaosfluxTalk 14:44, 14 January 2024 (UTC)Reply[reply]
I was? I haven't changed my signature in years though. I wonder what changed? —CYBERPOWER(Around) 15:05, 14 January 2024 (UTC)Reply[reply]
Possibly whatever that report does was confused by the amount of substing in your signature, or possibly it saw some issue with whichever time-specific signature happened to be in use at the time. Anomie⚔ 16:23, 14 January 2024 (UTC)Reply[reply]
@Cyberpower678:User:InternetArchiveBotis on the list because the report does not recognize [[:en:User:InternetArchiveBot]] as a non-interwiki link. The validator itself is smart enough to realize it is, in fact, a local link.HouseBlaster (talk · he/him) 21:04, 14 January 2024 (UTC)Reply[reply]
Ah, well that's an easy fix, for when I get an opportunity to sign in as IABot at some point. —CYBERPOWER(Message) 03:37, 17 January 2024 (UTC)Reply[reply]
RFC on the mass-draftication on stub-class Olympian articles
Should the list of stub-class articles published at Quarry query 76969 (generated by @BilledMammal) be mass-moved to draft space, subject to auto-deletion after 36 months instead of the normal 6 months? InvadingInvader (userpage, talk) 18:28, 12 January 2024 (UTC)Reply[reply]
Support as proposer. We still haven't fully cleaned up the mess that are the Lugstubs. A vast majority of these articles, if not all of them, solely reference to Olympic databases, no indication alone of fulfilling GNG. While there are some articles which can notable, a vast majority of them fail WP:NOLYMPIC, though to give a chance for them to be reviewed and remaining on Wikipedia, instead of mass-PRODification, akin to the passed WP:LUGSTUBS and WP:LUGSTUBS2, I propose that these over 22,000 Lugstubs, as part of LUGSTUBS3, be moved to draft space with a 36-month expiration date to give enough time for the good ones to be submitted to AFC and reviewed. This I believe is an appropriate concession between those who wish these article stay, and those who wish these articles be delete. InvadingInvader (userpage, talk) 18:28, 12 January 2024 (UTC)Reply[reply]
Hold on now, @InvadingInvader: - would you be willing to delay this for a little longer? I had intended on doing at some point soon a contest to cleanup articles like these, but was waiting for BilledMammal to get me a few lists. I had hoped to see if it would give any success before doing something drastic like this. BeanieFan11 (talk) 18:34, 12 January 2024 (UTC)Reply[reply]
Also, I think this would deserve more workshopping as there is almost for sure to be false positives in a massive 20,000+ article list generated by bot; the previous lugstubs discussions that were workshopped and were 25 times smaller still had many errors. BeanieFan11 (talk) 18:38, 12 January 2024 (UTC)Reply[reply]
This is why I suggest mass drafting. That way, those who wish to work on these articles as well as potential false positives would be saved and returned, whilst the truly unnecessary Lugstubs would be purged. You can still hold your contest. InvadingInvader (userpage, talk) 18:48, 12 January 2024 (UTC)Reply[reply]
Hat ~30 posts of circular back-and-forth repeating the above. Ajpolino (talk) 21:17, 12 January 2024 (UTC)Reply[reply]
@InvadingInvader: But there is no way anyone can work through 25,000 articles in that timeframe. Would you be willing to just temporarily withdraw this, do some workshopping, maybe hold the contest and re-propose at a later date? This would be a major disaster as it stands. BeanieFan11 (talk) 18:51, 12 January 2024 (UTC)Reply[reply]
How would it be a disaster? The last two LUGSTUBS proposals were successful. InvadingInvader (userpage, talk) 18:51, 12 January 2024 (UTC)Reply[reply]
@InvadingInvader: I think we need more time to work everything out before diving straight into drastic measures. There are sure to be many false positives in this and this would result in the catastrophic removal of tens of thousands of articles. I suggest trying out the contest and seeing how that works first, and if it is unsuccessful, then we could resort to this. BeanieFan11 (talk) 18:53, 12 January 2024 (UTC)Reply[reply]
Think of it this way - as it stands, 95% of these articles would never be found in draftspace and would be soon deleted. If we run the contest and it is successful, we could continue to do every so often it and work our way through in a more beneficial way that does not remove tens of thousands of potentially notable articles / that actually improves them. BeanieFan11 (talk) 18:55, 12 January 2024 (UTC)Reply[reply]
They're not being removed. They're being sent to draftspace. Remember that there are about 110,000 active users on the English Wikipedia. That's (at a minimum) four users per one article. Even if it was only one user per draft, there would be time to save these articles if they meet the GNG. I'm proposing a 36-month deadline. That is more than enough time to find sources for these articles. And hey – if they end up being deleted, but more SIGCOV comes five years later, they can EASILY be re-created. InvadingInvader (userpage, talk) 18:55, 12 January 2024 (UTC)Reply[reply]
95%+ of users here do not work in the Olympic area. This deadline is not long enough (also, see WP:NODEADLINE) and would likely have 95%+ of the articles deleted. My suggestion is the contest, which, if successful, could be repeated every so-often and would result in them being improved rather than deleted. BeanieFan11 (talk) 18:59, 12 January 2024 (UTC)Reply[reply]
Move them to draftspace then to do it. Or userfy them. They don't belong in the mainspace until there is proof that they fulfill the GNG. InvadingInvader (userpage, talk) 19:00, 12 January 2024 (UTC)Reply[reply]
Until such sources are found, move them to draftspace. InvadingInvader (userpage, talk) 19:02, 12 January 2024 (UTC)Reply[reply]
That directly contradicts the notability policy I cited above. We are not required to draftifiy everything that does not at this very moment pass GNG with the current sourcing. BeanieFan11 (talk) 19:04, 12 January 2024 (UTC)Reply[reply]
Seems closer to comparing apples to oranges. We aren't required to draftify everything, but we should. If something can't fulfill GNG, don't include it in the mainspace. That's why draftspace exists: to work on articles and get them into compliance. InvadingInvader (userpage, talk) 19:07, 12 January 2024 (UTC)Reply[reply]
(edit conflict) You say that we should, but draftify policy is that "Older articles should not be draftified" (90-day cutoff). If something can't fulfill GNG, don't include it in the mainspace – the thing is, a large portion of these are notable... I agree with Folly Mox below. BeanieFan11 (talk) 19:09, 12 January 2024 (UTC)Reply[reply]
Why should these articles remain in the mainspace before we can find GNG-fulfilling coverage? InvadingInvader (userpage, talk) 19:08, 12 January 2024 (UTC)Reply[reply]
Past consensus disagrees. Per the discussions at LUGSTUBS and LUGSTUBS2, the community has agreed that these articles in most of their current state belongs in the draftspace, or at the very least not the mainspace. InvadingInvader (userpage, talk) 19:12, 12 January 2024 (UTC)Reply[reply]
Those both passed by the skin of their teeth and affected much smaller quantities of articles. This proposal is too rushed and needs workshopping. BeanieFan11 (talk) 19:13, 12 January 2024 (UTC)Reply[reply]
Quote the closure of LUGSTUBS2: a stronger consensus that they should not be left in mainspace. Skin of your teeth? InvadingInvader (userpage, talk) 19:15, 12 January 2024 (UTC)Reply[reply]
Also from the closure: However, I would urge the proposers not to charge headlong into the draftification process without further thought. A lot of people are uncomfortable with the large number of articles—a list of 1200 people from different eras and different nations is very difficult for humans to parse and I would urge the proponents to break it down. BeanieFan11 (talk) 19:16, 12 January 2024 (UTC)Reply[reply]
Would you rather have 22000 AfDs, or 22000 drafts? InvadingInvader (userpage, talk) 19:18, 12 January 2024 (UTC)Reply[reply]
I would rather us go through them in a sensible and non-rushed way (WP:NORUSH), such as holding contests to improve the notable ones while steadily nominating others for deletion. BeanieFan11 (talk) 19:19, 12 January 2024 (UTC)Reply[reply]
Why not do it in draftspace then for the time being? That's where articles are meant to be improved to be better than stub class InvadingInvader (userpage, talk) 19:22, 12 January 2024 (UTC)Reply[reply]
Because draftspace makes it a rush and imposes a deadline (WP:NODEADLINE). Articles can be improved in mainspace too, you know. BeanieFan11 (talk) 19:23, 12 January 2024 (UTC)Reply[reply]
That's why I proposed an extended deadline for drafts. Also that allows us to spare tens of thousands of AfD debates. InvadingInvader (userpage, talk) 19:25, 12 January 2024 (UTC)Reply[reply]
It is still a deadline that is way too short; we do not have enough editors to go through nearly 1,000 tough-to-research articles a month. BeanieFan11 (talk) 19:26, 12 January 2024 (UTC)Reply[reply]
You can always recruit more editors. Request a mass-messenger to send a mass message out. NPP does it all the time. InvadingInvader (userpage, talk) 19:27, 12 January 2024 (UTC)Reply[reply]
Three years should be enough time anyways. If you want five years I'll give you five years. InvadingInvader (userpage, talk) 19:28, 12 January 2024 (UTC)Reply[reply]
Or we could just improve them in mainspace, which means that editors can work at their own pace without a imposed deadline that will result in mass deletion... You've been systematically PRODing and AFDing Olympians - I support your efforts there - but not 25,000 all at once. BeanieFan11 (talk) 19:29, 12 January 2024 (UTC)Reply[reply]
@InvadingInvader: Would you be willing to withdraw this for now so it can be workshopped and the terms discussed further (maybe hold the competition(s) and see how it goes, etc.)? BeanieFan11 (talk) 19:46, 12 January 2024 (UTC)Reply[reply]
Probably not productive to relitigate LUGSTUBS2 with a 70% shorter G13 immunity window. Needs workshopping, preferably at a dedicated page. Folly Mox (talk) 18:56, 12 January 2024 (UTC)Reply[reply]
I've removed the RfC tag since this is clearly premature. Galobtter (talk) 22:17, 14 January 2024 (UTC)Reply[reply]
very strongly oppose. This has all the problems identified at the previous proposal (which only barely had consensus), only worse because of the vast number of articles that have not even been attempted to be pruned for false positives, etc. Thryduulf (talk) 11:05, 15 January 2024 (UTC)Reply[reply]
If a nomination has received few or no comments from any editor, and no one has opposed deletion, and the article hasn't been declined for proposed deletion in the past, the closing administrator should treat the XfD nomination as an expired PROD and follow the instructions listed at Wikipedia:Proposed deletion#Procedure for administrators.
This proposal would remove the requirement that an article be eligible for PROD to be "soft deleted". In effect, this would mean poorly-attended but unopposed deletion debates can be closed as WP:REFUND-eligible soft delete.
Survey (RfC: allow soft deletion of unopposed nominations)
Support as proposer. In December, there were 46 deletion nominations ultimately closed as delete after being relisted as "ineligible for soft deletion": 1, 2, 3, 4, 5, 6, 7, 9, 10, 11,[a]12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 31, 32,[b]33, 34, 35, 36, 37, 38,[c]39, 40, 41, 42, 43, 44, 45, and 46.In fairness, there were four (4) articles that are still bluelinks because they were ineligible for soft deletion: 1,[d]2, 3,[e] and 4. But I don't think that a redirect, a stub, a non-neutral REFBOMB mess, and No Pants Day justify the volunteer time rubber-stamping nominations. WP:OFD2023 shows that ~15% of AfD nominations are closed as keep, which is ~twice the 8% survival rate of the "ineligible-for-soft-deletion" December group. This suggests that editor time is better spent rescuing other articles.Finally, I will note that this change would still allow for WP:REFUNDs of the affected articles. HouseBlastertalk 01:15, 13 January 2024 (UTC)Reply[reply]
I want to add a little bit to my rationale: this proposal would result in PROD and soft deletion being treated differently, and that is the point. A well-advertised-but-unattended discussion is not the same thing as a banner staying atop a page for a week. Arguing against this proposal because it would treat soft deletion and PROD differently is textbook circular reasoning: treating them the same way is A Good Thing because they should be treated the same way. Respectfully, why should fundamentally different processes have the same outcome?I would also point out that the status quo is the 46 articles from December are "hard" deleted: you either need some showstopping sources to show the closer/an admin at WP:REFUND or else must make your case at WP:DRV to get them undeleted. This proposal would result in all of them being REFUND-eligible. HouseBlaster (talk · he/him) 03:29, 14 January 2024 (UTC)Reply[reply]
Strong support no irreversible harm. Potential abuse/misuse is mitigated by a single user and in worst case, a guaranteed WP:REFUND is always possible. ~ 🦝 Shushugah (he/him • talk) 01:36, 13 January 2024 (UTC)Reply[reply]
Support Makes it easier to restore deleted articles and discourages drive-by/rubber stamp !votes. Seems like a net-positive. -Fastily 01:54, 13 January 2024 (UTC)Reply[reply]
Support but caveats: The nominator must make a clear delete rational; the nominator must declare that they have followed WP:BEFORE, and say why the BEFORE options, especially WP:ATD are not suitable. I assume that this can override a previous PROD removal. —SmokeyJoe (talk) 05:29, 13 January 2024 (UTC)Reply[reply]
Oppose I have always held that soft deletion at AfD is simply a procedure where we pretend that the nominator, instead of nominating the article for AfD, tags it for PROD instead. So there should be no difference in the rules for soft deletion vs. PROD IMO. However, I am open to considering introducing an expiration for PROD declines, such that an article which has not been declined for PROD in, say, the last five years becomes eligible for both PROD and soft deletion. The reason why declined PRODs are ineligible for PROD is the same reason why we discourage edit warring - you shouldn't be able to get the last say just by being more obstinate at forcing your changes through. However, five years is long enough to presume that the original decliner may have forgotten about the article; they can always maintain their opposition by re-removing the PROD or !voting keep at AfD. -- King of ♥ ♦ ♣ ♠ 06:19, 13 January 2024 (UTC)Reply[reply]
Strong support as outlined by nominator. Makes perfect sense. Best Alexandermcnabb (talk) 09:02, 13 January 2024 (UTC)Reply[reply]
Support. It took me a bit to parse the proposal, which boils down to "can articles be soft deleted if they've had a contested PROD?". Q for nom: would this change mean that after a single week a decision would be made, or would the normal relisting cadence happen? I'm with King of Hearts in an alternate solution where a soft deletion would only be blocked if the PROD was less than some number of years ago. Eight years, perhaps? Ten seems too long (2014 was a decade ago) but 5 feels too soon (2019 was just a few days ago). SWinxy (talk) 19:22, 13 January 2024 (UTC)Reply[reply]
I envisioned it being a tool in the closer's toolbox: namely, if they feel relisting would be productive, relist. If not, it would be eligible for soft deletion. HouseBlaster (talk · he/him) 22:33, 13 January 2024 (UTC)Reply[reply]
Oppose per King of Hearts. If someone nominates an article for PROD, which is contested, and then immediately renominates it for AfD, just because the person who opposed that PROD didn't show up to the discussion, doesn't mean the article should be deleted. Also open to allowing PROD again after 10 years or something like that, but soft deletion is just applying PROD rules to AfD. Galobtter (talk) 19:31, 13 January 2024 (UTC)Reply[reply]
Oppose. This proposal would effectively allow an article to be PRODed twice. If a PROD has already been removed once, the nomination is controversial. If the person who removes the PROD states in his edit summary that the article should not be deleted, or that the grounds for deletion are erroneous, or that the article satisfies GNG, or the like, I can only infer that the AfD is not unopposed, and that making a comment like that amounts to opposition. James500 (talk) 02:53, 14 January 2024 (UTC)Reply[reply]
This proposal is also explicitly based on the assumption that changing the rules of AfD will not change the behaviour of AfD participants described by the statistics cited. It is not obvious that the assumption is true. This proposal might result in an increase in the number of nominations being made in the first place. Nominators might decide to send every declined PROD to AfD in the hope of getting a soft deletion while no one is watching. This proposal might also result in more keep !votes being made in the first place, if deprodders cannot just wait for an unattended AfD to be closed as no consensus. I also notice that the statistics cited are for December (the time of year when we have the fewest active editors), and do not take into account any seasonal variation that might exist. James500 (talk) 18:06, 14 January 2024 (UTC)Reply[reply]
Fair enough point about seasonal variation. I pulled the statistics for June 2023 (chosen as halfway through the year): 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 31, 32, 33, 34, 35,[f]36, 37,[g]38, 39, 40, 41, 42, 43, 44, and 45.Bluelinks: 1, 2, 3, 4, 5, 6. There is also Wikipedia:Articles for deletion/Log/2023 June 16#Explore Learning, which I am not sure which category to put in. It was closed as "delete", but is currently a redirect to ExploreLearning (without a space). That article appears to be on an entirely different company. At the very least, the two articles (Explore Learning and ExploreLearning) coexisted for a period of time—maybe there was a WP:CONTENTFORK? I'd appreciate it if someone with admin goggles could take a look.Finally, the behavior changes you cite seem to be positive changes. The point of any discussion is to find consensus, which logically means "no consensus" closes are not an ideal outcome. We allow speedy renomination of no consensus closes for a reason, after all. Thus, I would argue that discouraging dePRODers from seeking a "no consensus" close is a good thing. I also take issue with the assertion that Nominators might decide to send every declined PROD to AfD in the hope of getting a soft deletion while no one is watching. First, I would hope that people would not attempt to game the system. But holding a full-blown AfD is absolutely not while no one is watching. There is a banner atop the page (which was evidently enough to attract the dePROPer), it is listed on the daily AFD log, and there is literally an entire WikiProject dedicated to ensuring other interested participants see the discussion. HouseBlaster (talk · he/him) 22:13, 14 January 2024 (UTC)Reply[reply]
Oppose there is often low participation at AfD so waiting a second week for comments is reasonable. Also the deprodder would be rushed into responding when they may be offline for a period. This suggestion would unnecessarily speed up deletion without any consensus in my view, Atlantic306 (talk) 22:48, 14 January 2024 (UTC)Reply[reply]
Oppose. If an article is ineligible for PROD then it is, by definition, controversial and is thus completely unsuitable for deletion without an active consensus to do so. Thryduulf (talk) 11:01, 15 January 2024 (UTC)Reply[reply]
Oppose, although well-motivated, this proposal would open the door to deletion of articles that just don't happen to be interesting to the handful of editors who regularly visit AfD, even when the nomination is obviously spurious or misguided. Admins should be both allowed, and expected, to use their discretion to relist, or otherwise ensure that deletion is for policy-based reasons, not just because no one could be bothered that week. Elemimele (talk) 12:10, 15 January 2024 (UTC)Reply[reply]
Oppose may open door for misuse. I see these cases as no consensus to delete which if anything should default to keep. Well-meaning proposal but defies conventional wisdom. --PeaceNT (talk) 04:36, 16 January 2024 (UTC)Reply[reply]
Support. If nobody cares enough about an article to make a brief comment on an AFD, it does not have enough support to exist. Stifle (talk) 09:52, 16 January 2024 (UTC)Reply[reply]
Support. If nobody can rebut the argument for deletion then we shouldn't be keeping the article, per WP:CONSENSUS. BilledMammal (talk) 11:44, 16 January 2024 (UTC)Reply[reply]
Meh This RFC seems poorly written, as it fails to note that very section the nomination links to goes on to offer several options for when it was an opposed prod, one of which already is soft deletion. It's unclear to me whether "supports" will be interpreted as supporting the status quo or as calling for something more strict, and I could see some opposes actually supporting the status quo too. I see there was a better-worded RFC on this topic at Wikipedia talk:Deletion process#Clarifying NOQUORUM Soft Deletes that didn't get many responses.Personally I think we can afford a relist or two before soft-deleting, even if the de-PRODder didn't notice the AFD to oppose there too, per WP:NODEADLINE. But leaving it open to admin discretion (i.e. the status quo) is ok with me too on the assumption that admins will save immediate soft deletion for clearer cases. Anomie⚔ 12:12, 16 January 2024 (UTC)Reply[reply]
Oppose For similar reasoning as King of Hearts. I would not necessarily be opposed to this in cases with a multi-year gap between PROD and AfD, but I do not like the idea of essentially being able to PROD an article twice in a short period of time. As for a timeframe, leave it to admin discretion. Curbon7 (talk) 12:24, 16 January 2024 (UTC)Reply[reply]
Oppose - a week is nowhere near enough time, a lot of articles for deletion are likely to be on more obscure topics, that we possibly should have articles about, but that most editors will not be familiar with. A week is not enough time to be seen by someone who might be able to expand the article or explain it's importance. If there's an automatic deletion cut-off it should be closer to a year. Irtapil (talk) 15:11, 16 January 2024 (UTC)Reply[reply]
Procedural Oppose per Anomie. There is a lot of context missing from this RfC, such as how that sentence got added to the process and the conflict with another part of the same section, i.e. it may already be an option. I put forward a discussion at Wikipedia talk:Deletion process#Clarifying NOQUORUM Soft Deletes to try and discuss some different wordings and options that could be used in a proper RfC per WP:RFCBEFORE. It would be advisable to close this discussion, workshop the wordings on that talkpage, and come up with a more comprehensive one since the current wording is self-contradictory. The WordsmithTalk to me 20:52, 16 January 2024 (UTC)Reply[reply]
I take this proposal to be stating that we should strike and the article hasn't been declined for proposed deletion in the past, which I think would resolve the contradiction. voorts (talk/contributions) 04:01, 17 January 2024 (UTC)Reply[reply]
Discussion (RfC: allow soft deletion of unopposed nominations)
So to be clear and article like MIKTA would be deleted even though the rationale doesn't make sense?Moxy- 22:42, 13 January 2024 (UTC)Reply[reply]
No, because someone expressed opposition to deleting the article in the discussion. (If that comment had not been made, the article would be eligible for soft deletion under the current rules.) HouseBlaster (talk · he/him) 22:54, 13 January 2024 (UTC)Reply[reply]
So not comment then default deletion ..... do those involved in deletion at least look for sources...as in is there an common sense or effort involved if noone comments? Moxy- 04:48, 14 January 2024 (UTC)Reply[reply]
If people are not looking for sources before !voting, I would argue that is a problem beyond the scope of this proposal.HouseBlaster (talk · he/him) 02:42, 15 January 2024 (UTC)Reply[reply]
MIKTA is just a case of a really bad nomination by a user who clearly sent an article to AfD without Googling its title. Lazy nominations are a problem with or without soft deletion. Pichpich (talk) 04:35, 15 January 2024 (UTC)Reply[reply]
But soft deletions make the effects of lazy nominations very significantly worse. Thryduulf (talk) 11:02, 15 January 2024 (UTC)Reply[reply]
Perhaps, although I'd be counting on the closing admin to review the deletion rationale before actually soft-deleting the article, just as I'd expect admins to close PRODs as deletions only after performing the usual and basic WP:BEFORE checks. Am I just being naïve here? Pichpich (talk) 12:58, 15 January 2024 (UTC)Reply[reply]
Am I just being naïve here? unfortunately you are. While the worst offender that I know of was desysopped, there is no shortage of deletions being done without proper checks. Thryduulf (talk) 14:56, 15 January 2024 (UTC)Reply[reply]
I know for a fact at least some admins don't look at articles at all when closing deletion discussions, so no. (And TBF deletion closers have a lot of work to do without replicating the participants work) Mach61 (talk) 16:49, 15 January 2024 (UTC)Reply[reply]
Notes
^with the relist comment Not eligible for soft-deletion (due to contested prod back in 2006 (!) ...)
^a batch nomination of seven was relisted because one had been dePROD'd
Why not restore the lists of contents of pages under the lede and in bold as it was before?
Now, to see the lists you have to click on that symbol to the left of the page's title. It took me several months to discover that the lists still existed and how I could make them appear by clicking on that god**** symbol. I'm convinced that, like me, zillions of occasional readers will not realize that the lengthy article they're reading actually has a useful list of contents hidden somewhere. To fulfil their purpose lists of contents should be user-friendly, that is, instantly visible, not discreetly tucked somewhere. Lubiesque (talk) 20:49, 13 January 2024 (UTC)Reply[reply]
On most screens the table of contents is visible by default on the sidebar, but on narrow screens it is not. Are you viewing on a narrow screen (or did you accidentally hide it - you can unhide it by hitting the "move to sidebar" button). Galobtter (talk) 21:09, 13 January 2024 (UTC)Reply[reply]
Maybe this varies by skin. I am using the legacy vector 2010 skin and the TOC appears below the lede. RudolfRed (talk) 21:11, 13 January 2024 (UTC)Reply[reply]
I realize I should have looked around more.. After all, it was unlikely that the lists of contents would be gone for good.--Lubiesque (talk) 21:50, 13 January 2024 (UTC)Reply[reply]
Lubiesque this occurred when the WikiMedia Foundation changed the skin of Wikipedia against the wishes of the community. You can go into your settings and switch from Vector 2022 to Vector 2010 if you want to change it back. There's also an ongoing discussion about the change where you can leave your feedback. Thebiguglyalien (talk) 23:45, 13 January 2024 (UTC)Reply[reply]
Note that the closers of the RfC initiated before the rollout determined that participants expressed overall...positive reception to the changes. — Frostly (talk) 23:25, 14 January 2024 (UTC)Reply[reply]
Because the Wikimedia Foundation refused to do so, instead deciding to suddenly roll out a major UI redesign with little notice and significant issues. See WP:V22RFC2. InfiniteNexus (talk) 04:43, 15 January 2024 (UTC)Reply[reply]
Centralized discussion on Color Bars
Color Bars are used on nonpartisan election articles which are located on the bottom of the where the political party would be located if the election was not nonpartisan
Some Wikipedia editors have removed the Color bars and replaced the colors with political party as a good faith edit on the election articles, and concerns and objections have been put forward. Removed the Color bars and replaced the colors with political party as a good faith edit Assuming that the candidate is in a politicil party with out displaying the name which can cause issues add disruptions to nonpartisan election articles. I propose Color Bars should not be used at all on Infobox election of nonpartisan election main page articles in The United States DLCY89* (talk) 02:28, 16 January 2024 (UTC)Reply[reply]
After reviewing this thread, the linked diffs and talkpages, and the requested closure above, I'm supremely unimpressed with the conduct of a number of people in this topic area. It certainly isn't just one person, incivility is rampant throughout the area. In order to break the back of this problem, I'd propose General Sanctions be authorized for the Darts topic area, text below copied from WP:GS/PW. The WordsmithTalk to me 02:04, 17 January 2024 (UTC)Reply[reply]
Any uninvolved administrator may, at his or her own discretion, impose sanctions on any editor working in the area of conflict if, despite being warned, that editor repeatedly or seriously fails to adhere to the purpose of Wikipedia, any expected standards of behavior, or any normal editorial process.
The sanctions imposed may include blocks of up to one year in length, bans from editing any page or set of pages within the area of conflict, bans on any editing related to the topic or its closely related topics, restrictions on reverts or other specified behaviors; or any other measures which the imposing administrator believes are reasonably necessary to ensure the smooth functioning of the project.
Prior to any sanctions being imposed, the editor shall be given a warning with a link to this decision and, where appropriate, should be counseled on specific steps that he or she can take to improve his or her editing in accordance with relevant policies and guidelines.
Sanctions imposed may be appealed to the imposing administrator or at the appropriate administrators' noticeboard.
Support. The AN thread is quite revealing of how editors interact in that topic area. voorts (talk/contributions) 04:11, 17 January 2024 (UTC)Reply[reply]
You might consider proposing that the community designate the topic area in question to be a Contentious topic. isaacl (talk) 05:53, 17 January 2024 (UTC)Reply[reply]
I considered it, but chose not to on purpose. WP:CTOP is specifically tied to Arbcom and subject to their oversight; we still have template issues leftover from when Contentious Topics replaced WP:ACDS. By using the older Discretionary Sanctions language, it makes things much more clear that it was placed by the community and not Arbcom, that it doesn't happen at WP:AE or get appealed to WP:ARCA, etc. Separating community-based sanctions from arbcom-based sanctions reduces confusion in the long run. The WordsmithTalk to me 06:10, 17 January 2024 (UTC)Reply[reply]
Over the long run, personally I think it would be simpler to have one procedure for authorizing additional actions by administrators, with either the community or the arbitration committee designating topic areas where the procedure can apply. I appreciate, though, that this would be breaking new ground for the community and so at present has more uncertainty. isaacl (talk) 06:21, 17 January 2024 (UTC)Reply[reply]
Idea lab
Interest in testing a tool for Breaking News? Seeking feedback.
My team at the foundation, WME, has developed a dashboard that tries to identify new articles related to global "newsworthy" events as they are being written about across Wikipedia language editions at any given moment. You can read more about it here. I'm seeking help to improve the feature.
I'd appreciate if anyone that tries it out can surface any potentially missing templates from across language projects that would help us capture more results. Using the thumbs up and down buttons in the demo to confirm or deny if entries are accurately identified as breaking news, would help me in the long and medium-term in building a better, more accurate tool.
Although Enterprises' focus is not on creating editing tools or gadgets, we hope this can be of use to the community, too.
Are the thumbs up/down supposed to be if the article as a whole is about a current news event, or has been created in wake of a current news event? Because e.g. you have on the tracker Mama Diabaté who died two days ago, so that would be news and result in increased traffic and editing, but her notability would have been established over decades. On the other hand 2023 Guyana Defence Force helicopter crash was created for the purpose of covering a specific important recent news event. Are both to be considered "hits" for the tracker?
Also, "indications count" isn't documented, and I don't know what it means, and it seems odd (being a count) that you can only filter numbers equal to the count as opposed to higher or lower than. I also don't think the raw number of edits is too useful of a metric for the user to filter potential news articles, since news is rather localized by interest and region. Page-views-to-editor-ratio would seem more useful -- a niche new article or split may have a lot of edits from a dedicated editor and reviewers at first, but very few outside viewers will care to see it in the first hours. Any news event will blow it out of the water in viewer-to-editor ratio, even if news stories will have more anonymous editors. SamuelRiv (talk) 16:58, 8 December 2023 (UTC)Reply[reply]
Thanks for this feedback @SamuelRiv -- thumbs are to say, is this news or or not. there are a lot of false positives so were trying to filter what is not news. I'd consider both those examples as news. What is news and what isn't is so subjective, so really just up to the individual.
We don't use any pageviews right now, so all this is based on editing behavior/presence. Good call on the "viewer-to-editor" ratio idea ... My only issue that we could only calculate that 24/h too late (given how PV work right now). FNavas-WMF (talk) 21:10, 8 December 2023 (UTC)Reply[reply]
A 24h delay in the ratio is fine as long as you have some smoothing average on both views and edits -- it will be better than the metrics you currently have available. (I'm sure you can figure out better metrics once you get some data.)
News isn't really subjective in these clear cases -- your first verification would just be a Google n-gram call to see if there was a major spike in searches in the past week. If the API for that is free, that'd be the best metric I can think of. There's tons of simple algorithms to verify a spike or step discontinuity in rough data. SamuelRiv (talk) 21:20, 8 December 2023 (UTC)Reply[reply]
@FNavas-WMF many breaking news items are related to articles that already exist - so being able to see articles that have high "within last hour" activity instead of only new articles may be useful. — xaosfluxTalk 18:08, 8 December 2023 (UTC)Reply[reply]
yep 100% agree @Xaosflux -- i'm working on getting us to within the last hour method you describe as we speak! FNavas-WMF (talk) 21:11, 8 December 2023 (UTC)Reply[reply]
I would go further and say that anyone who feels compelled to write about a news event on Wikipedia should look for existing articles to update rather than create a new one. This is an encyclopedia, not a newspaper. Phil Bridger (talk) 21:27, 8 December 2023 (UTC)Reply[reply]
@Phil Bridger totally agree. It seems to me that folks, at least on enWiki, do try to add to an existing article, which is why this tools as it works now is only very good for NEW, totally unforeseen events. Do you pointing editors to existing articles that are part of news is more valuable than to new articles? FNavas-WMF (talk) 16:25, 11 December 2023 (UTC)Reply[reply]
Thanks for the ping. This is on my radar and I was even able to chat with Francisco a bit at WikiConference North America recently. I've subscribed to this discussion and I'm curious to see what folks say about the tool. ---Another Believer(Talk) 00:39, 12 December 2023 (UTC)Reply[reply]
Thanks! These comments have been very useful. I'm looking for more ways to cut down false positives to cut the noise! The "cite news" template is extremely useful to catching breaking news. It seems quite reliably used in new news events.
{{cite web}} gets used a lot as well, especially when being used by newer editors who are using one of the citation insertion tools. — xaosfluxTalk 20:46, 18 December 2023 (UTC)Reply[reply]
That template is probably less specific, though. WhatamIdoing (talk) 21:13, 18 December 2023 (UTC)Reply[reply]
Indeed. But especially if you are a user (new or old) that isn't aware of some of these templates and go through the basic VE workflow of (a) Type in something (b) Click the Cite button (c) Dump in your URL -- you will end up inserting a cite web. — xaosfluxTalk 21:46, 18 December 2023 (UTC)Reply[reply]
@FNavas-WMF, an article being tagged with {{Current}} would be a direct indicator that we consider it a current event. But it is automatically removed by bot as soon as editing activity fades, which is often still while a layperson might consider something to be breaking news. Wikipedia:Current event templates#Current events has related templates/categorization. I'm curious how your tool uses/relates to this. An article being linked from Portal:Current events would be another strong indicator. {{u|Sdkb}}talk 00:12, 3 January 2024 (UTC)Reply[reply]
Option to omit subordinate sections on edit
Case in point: [29] The editor meant to add the content at the end of the "Discussion (II)" section, but ended up adding it at the end of its subordinate section, "Split off into a new page". He didn't catch the error and it was fixed later by a different editor (me). He is an experienced editor, significantly above average in technical competence, and I see this happen too often.
(In this case, I ended up changing the level of "Split off into a new page" to that of "Discussion (II)" to prevent this from happening again, but that solution was sub-optimal. By all logic the "Split off into a new page" should be subordinate to the Discussion section.)
Even if one is aware of this pitfall, it can be really cumbersome to have to back up to find the section you want. Imagine if there are four or five subordinates, some of them really long.
There should be the option to edit a section without its subordinates. Equally beneficial on any page that has multi-level sections, including articles, not just talk pages. As for specifics, that's why I'm on this page.
One thing to consider is that an editor might not know the option exists, or it might not occur to them to use it. In such cases the option would do little good. I'm thinking a pop-up box if the edited section has any subordinates: "Do you want to include the subordinate section(s)?" ―Mandruss☎ 21:58, 10 December 2023 (UTC)Reply[reply]
+1 for this sort of feature. It's been requested in various places for over a decade IIRC. I don't get caught adding content in the wrong place, so much as it's annoying to have to scroll to the correct place and an excessively long preview of subsections I am not planning to change. DMacks (talk) 22:19, 10 December 2023 (UTC)Reply[reply]
So the last comment in that thread was PrimeHunter, one of our most credible editors on technical questions, saying this is not only technically possible but "straightforward". There was no reply, suggesting concession by the naysayers. That was at VPT, and it seems to me the next step would've been this page. Not sure why that didn't happen. ―Mandruss☎ 22:17, 12 December 2023 (UTC)Reply[reply]
I said "It seems straightforward". I'm not a MediaWiki developer and don't know how easy it would be in practice but it doesn't sound hard. I don't believe Izno's earlier comment there: I'm pretty sure "this is not technically feasible" is the answer due to the way that HTML sectioning works. That seems irrelevant. When you save a section edit, MediaWiki reparses the wikitext of the whole page in the same way as if you had edited the whole page. PrimeHunter (talk) 21:55, 18 December 2023 (UTC)Reply[reply]
-1 to the popup confirmation, but +1 to being able to edit just the "lead" of a section sans any subsections. I'm sure people will jump in with some good examples, but I'm struggling to imagine when "edit smallest applicable subsection" and "edit entire page" are both worse options than "edit intermediate size chunk". Folly Mox (talk) 02:19, 11 December 2023 (UTC)Reply[reply]
@Folly Mox: Your last sentence seems to suggest that it should never include subordinate sections, which would be another way of solving this problem; do I have that correct? If so, there are some cases where one would want to do that, such as re-ordering the subordinate sections or moving text between subordinate sections. Such things could be accomplished in other ways, including editing the entire page, but significantly less easily and more error-prone. ―Mandruss☎ 20:33, 11 December 2023 (UTC)Reply[reply]
Yeah, never including subsections except in the "edit full page" case was my idea for avoiding a popup confirmation, but those things you mention are fine arguments for retaining the ability to edit a section including all its subsections. Another one is when there is no "section lead", and the prose starts after the first subsection. Misclicking on the wrong pencil would send users to an empty editing interface, which we'd have to cancel out of annoyingly. So maybe my idea is bad? I definitely am not liking an additional modal thing to tap between the editing pencil and the editing interface, but I'm not sure of the way round it. Folly Mox (talk) 21:45, 11 December 2023 (UTC)Reply[reply]
"Editing pencil": You must be using a different editor. I click [ edit ] next to the section heading.Remember that the pop-up would only happen when there are subordinates, so the impact might be less than you imagine. The question would be asked only when needed. ―Mandruss☎ 21:56, 11 December 2023 (UTC)Reply[reply]
On mobile skin, you have to go all the way to the top toolbar on a page, click the three dots, and click "edit full page" to do that. On very large pages that may well be a bigger inconvenience than the issue described here. Mach61 (talk) 19:50, 11 December 2023 (UTC)Reply[reply]
(Actually, there's no technical reason why this feature would have to be implemented the same on m.wiki AFAIK, so carry on) Mach61 (talk) 19:52, 11 December 2023 (UTC)Reply[reply]
There are indeed two issues here. The major one is the back-end: we need MW API support for it. The other one is the interface to activate it, for which we could have all sorts UI/UX design ideas, gadgets, etc. But none of the latter matters without the former. DMacks (talk) 02:12, 12 December 2023 (UTC)Reply[reply]
That's above my pay grade. If this earned a consensus at VPR, what are the realistic odds it would happen? ―Mandruss☎ 06:47, 12 December 2023 (UTC)Reply[reply]
Any chance the gadget that allows the editing of lead sections might help? CMD (talk) 07:43, 12 December 2023 (UTC)Reply[reply]
No, that is quite different. Each section is numbered sequentially, so the lead is section 0 already and is not a header-delimited section at all (so the other sections are not subsections of it, in the way a === is a subsection of ==). DMacks (talk) 07:52, 12 December 2023 (UTC)Reply[reply]
Brainstorming a gadget that would be a clickable link in the section to call action=edit buth then intercept the actual spawning of the editor. It would snip off everything starting with the first line that begins with "==" into a hidden separate field, then reattached it when the user clicks 'publish'. DMacks (talk) 10:11, 2 January 2024 (UTC)Reply[reply]
Brainstorming a COPYVIO-hunter bot
I'd like to propose the idea of a a COPYVIO-hunter bot, but I'm not ready to make a specific Bot request yet, and so I'd like to expose this idea here first to brainstorm it. Sometimes, copyright violations are discovered that have been present on Wikipedia for years. (The copyright-violating content at Barnabas#Alleged writings was added on 4 August 2014 and discovered 18 December 2023.) But for an alert Tea house questioner two days ago, who knows when, if ever, this would have been discovered. That's worrisome.
We have some good tools out there, such as Earwig's detector, and my basic idea is to leverage that by building a bot around it, which would apply it to articles, and either generate a report, or apply the {{Copyvio}} template directly. A couple of additional bot tasks could streamline the human part of the investigation by finding the insertion point (Blame) and determining copy direction (IA search). There are input, performance, scaling questions, and human factors, and likely others I haven't thought of. As far as input, ideally I'd like to see a hybrid or dual-channel input of a hopper with manual feed by editors (possibly semi-automated feed by other tools), and an automated input where the bot picks urls based on some heuristic.
For performance, I launched Earwig with all three boxes checked, and it took 62 seconds to return results for Charles de Gaulle (174,627b) and 16 seconds for (randomly chosen) Junes Barny (5,563b). I'm pretty sure there are a lot more articles closer in size to the latter than the former, so let's say Earwig takes 30 seconds per search on average; multiplying that by {{NUMBEROFARTICLES}} gives us 6.43 years to search all of Wikipedia with a dumb, single-threaded bot with no ability to prune its input stack. (Of course, Wikipedia would be bigger six years later, but that gives us an idea.) Given that the Barnabas violation went undiscovered for nine years, six years is not so bad, as I see it. But not all articles are equal, and probably some pruning method could decrease the size of the input stack, or at least prioritize it towards articles more likely to have undiscovered violations.
As far as scaling, I have no idea of server availability at WMF, but presumably there are some bot instruction pages somewhere for bot writers which address how many threads are optimal, and other factors that could scale up the processing for better throughput; maybe someone knows something about that. If we had six threads going against one input stack, that would reduce it to one year; it would be great to run it annually against the entire encyclopedia.
For human factors, I'm thinking about the increased number of articles tagged with copy violations, and the additional load on admins that would inevitably result. There are currently 17 articles tagged with the {{Copyvio}} template right now. I wanted to provide some estimate of activity at Wikipedia:Copyright problems to gauge current throughput, but I'm not so familiar with the page, and was unable to do so. Inevitably, a bot would increase the load on admins (for WP:REVDEL) and other volunteers, and it would be helpful to gather some data about what would happen. Not sure if its possible to project that, but maybe a stripped down version of the bot just to wrap Earwig and spit out numbers on a test run of a week or two might give us some idea. I'm guessing in operation, it would generate a big, backlog balloon initially based on the first two decades of Wikipedia, but then its output would slow to some steady state; in any case, backlogs in other areas have been generated and attacked before with success.
Maybe a bot could somewhat reduce load per investigation, by means a handy output report that includes Earwig percent, maybe a brief excerpt of copied content, and so on. A couple of additional tasks could be defined which would work off the output report, one task running Blame on the suspect articles to add date of insertion to the report, and another to read IA snapshots and determine direction of copy (i.e., is it a mirror, or a copyvio), resulting in a report with information that ought to make the human part of the investigation considerably faster and more efficient per occurrence, which should at least somewhat offset the increased overall number of investigations.
Would love to hear any feedback on the technical aspects of this, as well as the human factors, and whether something like this should even be attempted. Thanks, Mathglot (talk) 02:00, 21 December 2023 (UTC)Reply[reply]
Maybe a fourth task could be a disposition-triage task, and would act on the report output of previous tasks based on configurable values; something like: "if copy-direction = copyvio then if Earwig-pct > 85 then remove content from article and mark/categorize as revdel-needed; else if Earwig-pct < 20 then remove Copyvio template and mark report as handled; else leave for human assessment; else mark as mirror and handled." Mathglot (talk) 02:29, 21 December 2023 (UTC)Reply[reply]
EranBot currently sends every new edit through CopyPatrol if I understand it correctly, which essentially runs the edits through Turnitin/iThenticate. One could reduce the bot load by making it only look at articles that were created prior to August 2016.
@MusikAnimal (WMF) and Mathglot: I understand that the WMF is currently working on a replacement/re-vamp of CopyPatrol (i.e. Plagiabot). Is there a way to integrate a sort of "historical article detection" into a similar interface while re-using some of the code from the new Plagiabot, or is this something that you think would be better kept separate? — Red-tailed hawk(nest) 02:42, 21 December 2023 (UTC)Reply[reply]
That's terrific news, which means, if I understand correctly, that whatever the scope of the problem is, at least it's not getting worse (assuming perfect precision from Plagiabot). So we only have to deal with the pre-whatever-year issue, and slowly chip away at it. (I am subscribed; no ping needed.) Mathglot (talk) 02:56, 21 December 2023 (UTC)Reply[reply]
@MusikAnimal (WMF) I remember putting this up on phabricator somewhere (I think?), but would it be possible to provide a stable API to integrate CopyPatrol with various other editing/CVUA tools (specifically it would be great to be able to answer the question "What is the iThenticate score/URLs for a specific edit") Sohom (talk) 06:29, 21 December 2023 (UTC)Reply[reply]
I've left MusikAnimal a comment on their WMF account talk page. It would be nice to hear from them on this. — Red-tailed hawk(nest) 17:45, 25 December 2023 (UTC)Reply[reply]
I acknowledge it's Christmas, and many WMF staff are taking vacation/holiday, so it's fairly possible that we might not hear back for a week or so. — Red-tailed hawk(nest) 17:53, 25 December 2023 (UTC)Reply[reply]
Thanks. I've added DNAU for 1 month, imagining that he may be on a nice, long winter vacation. Mathglot (talk) 21:24, 25 December 2023 (UTC)Reply[reply]
An API for reviewing/unreviewing does exist, but it's undocumented right now. It also doesn't provide Access Control headers. I was working on an external-use API for CopyPatrol, but decided to hold off until the new version that uses Symfony was finished and deployed, since it won't be usable anyway until deployment has finished. Chlod (say hi!) 02:22, 26 December 2023 (UTC)Reply[reply]
Thanks for your patience! I was "around" on my volunteer account, but haven't been checking this one until today (my first day back at work after the break).
It sounds like you all are asking for phab:T165951, which was declined last November. It can be re-opened if there's interest in it. However, it's worth noting CopyPatrol doesn't go through every edit, only those that meet certain criteria. I let @JJMC89 speak to that before I say something wrong ;)
As for an API, we can certainly add an endpoint to get the score for a given revision, if it exists in our database. That's simple to implement and won't require authentication. If you could file a bug, I can have that ready for when the new CopyPatrol goes live.
API endpoints that make changes to our db, such as reviewing/unreviewing, is another matter. Right now we authenticate with OAuth, so we'd need to somehow have clients go through that before they could use the endpoint. If @Chlod is interested in building this, I'll happily review it! :) Off the top of my head, I'm not sure how to go about implementing it. Alternatively, maybe we could provide all logged in users an API key? That would avoid clients having to login to CopyPatrol.
I don't think we want to permit requesting new scores for any arbitrary revision, at least not until our partnership with Turnitin is finalized. That should happen very soon, and then we'll know for sure if we can send out that many API requests. Some changes to JJMC89's bot would likely also need to be made. All in all, I'd say this feature request is not much more than a "maybe".
Also, in case no ones mentioned it yet, attempting to identify old copyvios is tricky because of the all-too-common WP:BACKWARDSCOPY issue. In some cases it may not be possible to ascertain which came first -- Wikipedia or the source -- so I'd weary of attempting to automate this. MusikAnimal (WMF) (talk) 00:57, 3 January 2024 (UTC)Reply[reply]
The new bot looks at edits made in the article and draft namespaces (0 and 118) to submit to turnitin and skips the following types of edits:
made by a bots or users on the allow list
(revision) deleted before processing (rare unless catching up from a service outage)
rollbacks (MediaWiki native or Twinkle)
additions of < 500 characters after cleaning the wikitext.
Those that come back with more than a 50% match to a (non-allow listed) source are shown in CopyPatrol for human assessment.
As a quick test, I added an endpoint to dump the data from the database for a specified revision.[30]
{"diff_id":7275308,"lang":"en","page_namespace":0,"page_title":"Mahāyāna_Mahāparinirvāṇa_Sūtra","project":"wikipedia","rev_id":1178398456,"rev_parent_id":1178304407,"rev_timestamp":"Tue, 03 Oct 2023 12:16:34 GMT","rev_user_text":"Javierfv1212","sources":[{"description":"C. V. Jones. \"The Buddhist Self\", Walter de Gruyter GmbH, 2021","percent":50.3817,"source_id":820817,"submission_id":"3084bde6-3b8b-488c-bf33-c8c27a73ae06","url":"https://doi.org/10.1515/9780824886493"}],"status":0,"status_timestamp":"Tue, 03 Oct 2023 12:38:16 GMT","status_user_text":null,"submission_id":"3084bde6-3b8b-488c-bf33-c8c27a73ae06"}
Please file a task so we can workshop the best way to design the API.
Filed as phab:T354324. This could be done on either the frontend or the backend; but it doesn't look like the backend source is publicly-available (and API endpoints are a frontend task anyway, so it should probably live on the frontend). Chlod (say hi!) 10:03, 4 January 2024 (UTC)Reply[reply]
I'd encourage making the repos public unless there is a reason for keeping them private. It will make things easier if someone goes inactive or if someone wants to submit a patch. –Novem Linguae (talk) 11:36, 4 January 2024 (UTC)Reply[reply]
Hi, Mathglot! Great to hear more initiative on copyright cleanup tasks; they're always a big help. Someone brought up a related idea at WT:CCI a while back, and I responded with a few points that probably apply here too. I've got a cannula lodged in my hand right now, so I'll copy over what I said in that thread to avoid straining it. There wasn't a lot of back-and-forth on that thread anyway so it's probably easier if I just repost it here.
There was an idea previously floated around about having Turnitin or Earwig run on all revisions of past cases; I'd say this is probably the general idea when talking about automation for CCI cases. When it actually comes down to making it happen, though, it's a spider web of caveats and limitations that make it hard to get off the ground. Here's a more-organized explanation of my thoughts that I randomly collected in the past few months:
First is the issue of cost. There's around 508 thousand revisions left to check (as of May this year), but we only ever have a finite amount of Earwig search engine searches or Turnitin credits. Processing all of these automatically means we have to work with the WMF to get more credits for a one-time run-through, and we're not sure if we'll get decent results for a majority of those checks.
We could work around this by completely disabling search engine checks, as the thread you linked discussed, but this can either work for or against us based on the case. We could also work around this by only selecting a few cases which rely mostly on web sources or (for Turnitin) sources that we know would probably be indexed. This significantly cuts down on the amount of revisions to check. But then there's the next issue:
A lot of the older cases, especially the ones over three years old, start getting a lot of false positives. As article text remains on the wiki for long periods of time, SEO spam sites, academic documents, slideshows, and others start copying from Wikipedia. We filter out a lot of these already (like those in this list and a bunch of others), but we still hit them every once in a while and enough that it clogs up what reports we would otherwise get from Earwig/Turnitin.
A possible solution to this would be human intervention (which is more or less a given with something like this), where editors will double-check to see if a flagged revision actually is copied from somewhere, or if it's just a false positive. Human intervention will weed out false positives, but then it won't weed out the false negatives.
At the end of the day, copyvio checking is a really hard computer science problem that humanity is still in the middle of solving. False negatives; like when a revision flies under the radar because a source it copied from has died, or when the text has been paraphrased enough to make checkers think it's completely original text; will always be one of the biggest brick walls we face. False positives waste editor time, yes, but false negatives arguably take up more time, because we then need to re-check the case. It also wouldn't be a good look for us or the WMF if it turns out that we get a lot of false positives and negatives, since that could be perceived by the community as a waste of funds. Perhaps this is still something that could benefit from research and testing. — User:Chlod 13:02, 24 November 2023 (UTC)
This was for checking revisions on CCI pages, but the same applies for scanning every latest revision for all articles. It seems we've also been stretching Earwig to its limits recently, Earwig has been going down for almost every day in the past two weeks (CommTech's UptimeRobot). Unfortunately, the Earwig logs are project members-only, so I can't snoop in to figure out the cause by myself. But usually, we chalk this up to Earwig running out of Google API tokens. Would appreciate comments or ideas for the problems above; anything to ensure copyvios don't fly under the radar. Chlod (say hi!) 02:15, 26 December 2023 (UTC)Reply[reply]
Chlod thanks much for this. A few questions or comments:
Whats the 508,000 revisions? Is that just from CCI investigations?
In that same bullet, what cost are you talking about, processing time? And what did you mean by decent results, are you alluding to false +/- that you raised lower down?
As far as the workarounds, this sounds like roughly what I referred to as various pruning methods to shorten or reorder the input list.
Re false + due to websites copying from Wikipedia, I don't see this as a major problem and I addressed it in the 'direction of copy' comment involving IA checks. Maybe we'd have to negotiate with IA for a certain amount of search traffic per unit time, but as a fellow non-profit and given the reasons for it, I can't imagine there wouldn't be some positive arrangement to come out of that. That would eliminate the need for human intervention in a proportion of cases; see the "if-then" psuedo-code at the end of my comment. The triage attempts to automate a lot of it, and steer only the grey-area cases toward human intervention. And it should also weed out most false negatives for the same reason, and I don't see the failure to have 0% false negatives as a problem. There is always a problem identifying edge cases, even when humans are involved; if an automated solution improves our accuracy and throughput over what it was before, then it's worthwhile. One hundred percent accuracy and coverage are a goal but they will never be attained and that shouldnt stop us from incremental progress; even if automated processes fail to identify some sites for human intervention, we'll catch 'em, hopefully, next iteration of the processing.
"Really hard computer science problem": again, imho, we don't need to "solve" it, we just need to do a bit better than we were doing heretofore. Paraphrase will fall, imho, to better shingling turbocharged with some AI to recognize synonyms and linguistic transformations at some point in the not-nearly so distant future as I would've guessed a year ago. We needn't let the perfect be the enemy of the good, and I think we can do a lot of good now.
Yep, the 508k revisions is those we have to check at CCI. That's from a dashboard by Firefly to see how much is left. It has its inaccuracies, but it's correct for most cases.
For the cost, it's actual monetary cost. From what I've heard (and what I assume from what I've heard), the WMF pays for the Google API and Turnitin credits, and that cost is pinned to how much we use Earwig and how many edits are checked by CopyPatrol, respectively. Attempting to request more credits for either needs discussion with the WMF, who then needs to discuss with Google/Turnitin. And yeah, the decent results is whether or not Earwig comes up with a false positive/negative.
Definitely; there's a lot of one-or-two-sentence stubs that don't really need checking. This could, of course, be filtered out, possibly with a lot more criteria for skipping than just that.
I'm wary about using Internet Archive as a "source of truth" for dates. Though we do exactly that in CCI, it's probably not reliable enough to make broad judgements on whether a page is a copy or was copied from. If the pipeline goes Earwig → URL of likely match → Internet Archive, the data it would provide in a report could be a false positive if either the page changed URLs at any point in time (as I've seen happen with Sparknotes) as Internet Archive may not recognize the switch or if it was never archived before (though this practically never happens for recently-added citations). Of course, it's best if this is tested empirically first.
This is a step in the right direction though. The downside of not using a system like this at all is that the direction checking will be manual, which then just pushes the investigation work back to the addressing user/administrator, and that could result in anywhere from zero (by luck) to a lot of false positives. But what has to be checked first is whether this will end up increasing processing time/workload for checking users.
Earwig's Copyvio Tool is actively maintained by The Earwig. The recent downtimes were shortly discussed in User talk:The Earwig § Copyvio tool is down; I only saw this now. Seems to have been from increased usage.
I agree; something is better than nothing. I'm mostly just worried about stretching the few editors working on copyvio even thinner by adding more work to do. We could balance this by encouraging more editors to help out at WP:CCP, but copyright cleanup really just has historically low participation rates. Chlod (say hi!) 05:14, 27 December 2023 (UTC)Reply[reply]
Hey Chlod, thanks for pinging me here.
With Google's API, there's a hard daily limit of 10,000 queries per day, which costs US$50. The copyvio detector will make up to 8 queries per page (each query corresponds to a sentence or so of text, so that is chosen to strike a balance between performance and detection accuracy – longer articles would really benefit from more than 8 queries in many cases). So that works out to somewhere between 1,250 and 10,000 articles per day; let's say 2,000 on average. To be very clear, that's a limit built into Google's API terms. We can't get around it without a special agreement with Google, and everything I've heard from the WMF indicates we have no special agreement: we're paying the regular rate. Over ten years of running the copyvio detector, and despite multiple people asking, I've never managed to make the right connections with the right people at Google to get a special agreement (or the WMF hasn't, and IMO it's really them who should be doing that instead of me).
Just bashing the numbers out, checking 500,000 pages without a special agreement with Google would cost $12,500 and take at least 8 months (again assuming 5 queries/page).
The search engine is really the limiting factor here, hence my emphasizing it. Compute cost is much cheaper and we could use WMCloud to parallelize this more effectively if the daily limits weren't so severe.
Recent issues aren't related to using up all of our Google API credits but mostly due to my own poor software engineering decisions ten years ago. Sometimes it's due to unauthorized bot traffic that needs to be identified and blocked, but in this case I haven't noticed any. There's an ongoing project to improve performance, but no timeline for when it will be ready, unfortunately.
Thanks for these detailed explanations. Just noting that I've started User:Novem Linguae/Essays/Copyvio detectors to try to document all these copyright tools and their nuances. Seems like every couple months this comes up and I've forgotten all the details since the last discussion, so maybe an essay will help me remember it :) –Novem Linguae (talk) 12:13, 31 December 2023 (UTC)Reply[reply]
@The Earwig: Anywhere I could possibly help with the copyvio detector's uptime? It's also affecting the NPP workflow at times, as the copyvio detector is part of checks to be done when patrolling. Chlod (say hi!) 13:56, 4 January 2024 (UTC)Reply[reply]
@Chlod: Thanks for offering to help! I've given you maintainer access to the tool, and you have permission to restart it when needed. This is the case if the request backlog gets full (a log message "uWSGI listen queue of socket" is printed to uwsgi.log over several minutes) but occasional slowness doesn't necessarily mean the queue is full and needs to be cleared. It's good for us to have maintainers across different timezones. But beyond the occasional restarts, addressing the underlying issue is complicated and not something I expect help with. As hinted above, a backend rewrite is in progress to improve performance. — The Earwig (talk) 16:41, 4 January 2024 (UTC)Reply[reply]
As I understand it, the issues with applying Earwig's copyvio thing to more pages (and the reason it always takes a million years to run) has nothing to do with computational power or programming skill on our part, but rather because Google search, which is a quite critical part of this software working, has deliberately decided to fuck us sideways on search queries.
Well, it's not clear: it could be that or it could be that nobody from Wikipedia or from the WMF has succeeded in figuring out how to ask them from a special dispensation.
At any rate, we have a rather low quota, and it would cost tens of thousands of dollars to make it higher, and we do not get any special dispensation although I guess they are perfectly fine to make millions of dollars from reusing our content in their own knowledge panels lol. jp×g🗯️ 11:25, 28 December 2023 (UTC)Reply[reply]
Maybe @NPerry (WMF): might give more insight as to why the Wikimedia Foundation has not been able to get resources for copyright detection with Google search ? AFAIR, last year, they were involved with managing Wikimedia's partnership with Google. Sohom (talk) 11:54, 28 December 2023 (UTC)Reply[reply]
I'm not active in copyvio detection work, so take what I say as an outsider's perspective. Overall, copyvio detection on Wikipedia seems like an area that's struggling despite the heroic efforts of those working on it — multi-year backlogs at places like CCI are indicative of a system that's just not working. Bot assistance is our best hope of changing that dynamic on a systemic level, so I think it's a fruitful avenue to pursue. It'd be complex on a level greater even than ClueBotNG, but if successful it'd be similarly impactful.One thing to perhaps think about is the difference between old copyvios and newly added ones. My vague understanding is that a lot of the difficulty/pain comes from years-old insertions, which have since been built upon, necessitating removal of large chunks of an article. If it'd be simpler to build a bot that only checks/fixes new contributions, then perhaps that'd be a good place to start. If it could sufficiently stem the tide, perhaps it'd lead to a situation similar to what we have with non-notable articles/deficient FAs today, where there's a bunch of stuff in the past to clean up, but ultimately it's a finite backlog with few new entries being added, creating hope we'll someday get through it (cf. WP:SWEEP).Hope that's helpful, and good luck with this work! {{u|Sdkb}}talk 00:03, 3 January 2024 (UTC)Reply[reply]
(Possible overlap with part of above) - we have a copyright flagging system already (see log) - and allowing more bots to flag is fairly easy to do. Like many have said, building a reliable algorithm for doing the actual checking is a "hard" problem. One problem that came up during prior third party solutions like TURNITIN is that these companies wanted to reuse Wikipedia content without honoring the licensing requirements (e.g. We send them some text, they store it, then they reserve that to other people without attribution). — xaosfluxTalk 17:00, 4 January 2024 (UTC)Reply[reply]
Deletion of account is needed
There should be an account deletion system. Edits made by deleted account should be left with name of the account without a link. 160.238.0.118 (talk) 19:34, 26 December 2023 (UTC)Reply[reply]
For legal reasons related to attribution of material, it is not possible to delete accounts. They can however be renamed in some circumstances: see Wikipedia:Courtesy vanishing. AndyTheGrump (talk) 19:45, 26 December 2023 (UTC)Reply[reply]
Given I can just search for all other edits made by that "name of the account", there is no difference whether or not they have a "link". Sounds like a distinction without a difference. What is it your understanding of what an 'account' actually is? DMacks (talk) 10:03, 2 January 2024 (UTC)Reply[reply]
In the site's terms of service, you agree that the link is sufficient attribution. Remove the link, and the attribution is no longer within what you agreed to, and technically, you can sue the WMF. Snowmanonahoe (talk·contribs·typos) 14:27, 14 January 2024 (UTC)Reply[reply]
Allow soft deletion of unopposed nominations
Hi. I am wondering what people would think about repealing the "a page is only eligible for soft deletion if it has been PROD'd/deleted in the past" rule. I am not the most active person at AfD, but I invite anyone to go to a random page in the (recent-ish) AfD archives and ctrl+f for the word "ineligible". Uncontroversial nominations (or nominations in which the nominator leaves nothing for further participants to add) get relisted all the time because someone objected to a PROD, or it was previously deleted.
I went through the closed discussions in December, and I found 36 discussions which were relisted as ineligible for soft deletion but were subsequently deleted (usually after a few delete per nom or delete NN !votes, and perhaps some additional relists): 1, 2, 3, 4, 5, 6, 7, 9, 10, 11[a], 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 31, 32[b], 33, 34, 35, and 36.
To be fair, I found four bluelinks that were saved because they were "ineligible for soft deletion": 1[c], 2, 3[d], 4. But I don't think that a redirect, a stub, a non-neutral REFBOMB mess, and No Pants Day[e] justify the volunteer hours spent rubber-stamping uncontroversial nominations. Therefore, my idea: let these things be soft-deleted. Even if they were controversial[f] at one point in time, they are not anymore. They would be eligible for WP:REFUNDs, and a single objection in the current AfD debate would still prevent soft deletion. I think it is time to get rid of this WP:CREEPy rule. HouseBlastertalk 05:51, 2 January 2024 (UTC)Reply[reply]
It generally takes a lot more effort to create content than to delete it, so I'd apply strict scrutiny to any proposal to relax the criteria for PRODding. {{u|Sdkb}}talk 22:35, 2 January 2024 (UTC)Reply[reply]
To be clear, this would not change eligibility for PROD. It would only change eligibility for WP:SOFTDELETEing articles listed at AfD for a week (with all the associated notifications).On a different note, I would also consider that the status quo is those 36+ articles (accounting for batch nominations) are "hard"-deleted. If someone subsequently finds sources, you either have to make a very convincing case to the deleting admin or spend a week's worth of editor-time at DRV. This proposal would make them all eligible for a REFUND.HouseBlastertalk 23:28, 2 January 2024 (UTC)Reply[reply]
Ah, thank you for clarifying, and best of luck formulating the proposal! {{u|Sdkb}}talk 23:31, 2 January 2024 (UTC)Reply[reply]
Notes
^with the relist comment Not eligible for soft-deletion (due to contested prod back in 2006 (!) ...
^a batch nomination of seven was relisted because one had been dePROD'd
I respect the ambition, but realistically any massive change to WP:N would have to have been prompted by some unprecedented event or shift in community sentiment. I don't think people are actually dissatisfied with how notability as a whole works, even if some individual SNGs remain contreversial. Mach61 (talk) 10:12, 2 January 2024 (UTC)Reply[reply]
My feedback is that it looks like you are throwing out all of WP:N and trying to start again from first principles. But why? Barnards.tar.gz (talk) 11:10, 2 January 2024 (UTC)Reply[reply]
My first problem is with length: all the notability guidelines(SNG and GNG) make up for a reading experience nearing typical novellas — WP:N alone contributes 4000 words of reading material. However, all those tens of thousands words of guidance are thrown into a wrench by WP:PAGEDECIDE. How our numerous SNGs interacts with GNGs are defined is lacking, and newcomers are just meant to figure it out themselves. Any attempt to formally define it will inevitably be met with series of no-consensuses. I believe that hints that the way we are defining notability right now is fundamentally flawed. My goal with the proposal is instead of trying to use importance as criterion for inclusion(an insurmountably subjective and unfeasible task), but just to use the pre-existing policies as guidance. Catalk to me! 11:19, 2 January 2024 (UTC)Reply[reply]
Is "trying to use importance as criteria for inclusion" actually the current standard? WP:N goes to pains to distinguish notability from simple importance (except as reliable sources decide to cover it, which is the current N standard). DMacks (talk) 11:27, 2 January 2024 (UTC)Reply[reply]
That's what it says on the tin, but reading SNGs like WP:BIO and WP:NPROF clearly shows it's more of a importance criteria than anything. Even GNG proves to be an publicity indicator since it does not actually deal with article content. I don't know why we have all these guidelines when it could be replaced with "What is the best possible article that can be made?" Catalk to me! 11:40, 2 January 2024 (UTC)Reply[reply]
If you feel that the criteria are not being properly applied, have you tried fixing that first before deciding that everything should be thrown out? 331dot (talk) 11:49, 2 January 2024 (UTC)Reply[reply]
I recognize I am in a minority position with this belief but I believe notability as a system is fundamentally flawed for reasons described as above.
So I'm just wondering what makes you think a broader proposal covering more ground will gain consensus when a narrower proposal didn't. 331dot (talk) 15:04, 3 January 2024 (UTC)Reply[reply]
I would be a fool to think such a radical change like this would gain consensus. I'm poking around with different proposals to gauge community sentiment with notability. Catalk to me! 15:43, 3 January 2024 (UTC)Reply[reply]
The rationale behind notability is positively defined at WP:WHYNMach61 (talk) 16:31, 2 January 2024 (UTC)Reply[reply]
I am not sure what point is being made here. WHYN only explains the reasoning behind GNG. Catalk to me! 16:36, 2 January 2024 (UTC)Reply[reply]
@Ca, what do you make of the sentence at the end of WHYN that says "Because these requirements are based on major content policies, they apply to all articles, not solely articles justified under the general notability criteria"? It's been there since WHYN was created. WhatamIdoing (talk) 01:16, 10 January 2024 (UTC)Reply[reply]
So, practicality concerns aside, I want to engage with the philosophy of this, since that's really what's interesting and it's what you're looking for.
If I'm reading correctly. you see "notability", the term of art we have built up onsite, as fallacious: we claim "notability" to be something robust and objective, independent from "importance"—which is ultimately a subjective notion—but ultimately, "notability" just boils down to just being "importance" in many cases anyway. I agree with this.
However, I'm not really convinced it's a problem that can be solved, and I think your attempt goes a ways to explain why: you've just moved the problem back a step, offloading the subjectivity at the heart of an encyclopedia onto other terms of art: how do we know when we can establish WP:NPOV and WP:V—when we feel like the framing is neutral enough; when we feel like the claim is verifiable enough? Surely these can't be solved by statistical analysis, or whatever—at least I don't think so.
Since we're also axiomizing "what Wikipedia is not"—when does an article stop being an indiscriminate collection of information, or a dictionary? Those are informed by our present policy, and now they have no practical criteria whatsoever.
The consensus mechanism we have to fill in the gaps left by the flexibility of WP:N is ultimately powered by subjectivity, but I think someone here may need to win a Berggruen Prize before we can really tackle that problem. Remsense留 09:01, 3 January 2024 (UTC)Reply[reply]
I've always been first in line to say that SNGs are a mess and should generally be ignored in favor of GNG, just like discretionary sanctions should be ignored in favor of simply not being a jerk. But the community is attached to their pet SNGs and there's almost zero chance of doing away with them. We got NPORN removed, and even on such an immensely niche topic, it was like pulling teeth. GMGtalk 12:47, 2 January 2024 (UTC)Reply[reply]
If I'm understanding correctly, the problem you're trying to address is that there are some articles that meet the notability threshold but nevertheless should not have an article because of one of the reasons at WP:PAGEDECIDE. I agree that that's a problem. My explanation for it would be that, because 95% of AfDs deal with notability rather than PAGEDECIDE, many inexperienced editors use the heuristic "notable → keep" and ignore PAGEDECIDE.That said, I don't think a new policy or guideline is the solution. We already have too many of those, and the impulse to replace them with a simplified version isn't going to succeed. PAGEDECIDE already has guideline status as part of the WP:Notability guideline page, so I'd instead encourage you to suggest changes to make it clearer, more easily invoked, and the notability guideline page as a whole simplified.Something our policy/guideline pages badly need overall is for someone good at plain English writing to go through them with no agenda except shortening/simplifying/clarifying them. It won't be an enviable task, as everything on every PAG page was added for some reason or another, so there will be a lot of discussion/pushback about how to simplify without losing meaning. But it'd really be a valuable service. {{u|Sdkb}}talk 23:46, 2 January 2024 (UTC)Reply[reply]
The main thing is, I do not understand why we have the whole vaguely defined concept of notability when PAGEDECIDE supposedly trumps everything. Catalk to me! 02:15, 3 January 2024 (UTC)Reply[reply]
PAGEDECIDE doesn't trump WP:N. It says that there are times that while a topic may merit a stand-alone article that it can be shown to meet the GNG or an SNG, there are reasons not to have a stand-alone article (such as when the topic is better covered in concern with a larger topic or similar topics).
Notability is a guideline and purposely vague because it is meant to encourage articles to start from a point that shows potential for growth so that the wiki-way can be used to expand. But as others have pointed out, this is not a one-size-fits-all approach, due to systematic bias from sources. Masem (t) 05:09, 3 January 2024 (UTC)Reply[reply]
If you were seriously proposing to dump GNG and its emphasis on hype and publicity and one-size-fits-all rules over importance, and try to push more subject-specific importance-based guidelines, I might be on board. This goes in exactly the wrong direction. We cannot possibly include articles on all topics about which reliable but local or routine sources have provided enough information to write start-class articles, which is what GNG pretends to do (but in practice doesn't). Instead, we need to use notability to filter out the truly unimportant topics. But because GNG does that based on publicity, it is inaccurate and easy to game. Cutting out all the nuance and making it be one size fits all can only worsen those problems, without solving any actual problem with current practice. —David Eppstein (talk) 04:43, 3 January 2024 (UTC)Reply[reply]
I'll echo the above comment: this seems to be a step in the opposite direction from what I could conceivably report. Moreover, it doesn't actually reduce the "subjective" aspect, just pushes it off to a different place. Who decides whether a biography is "negative", or whether all the sources are "marginally reliable", or what counts as "undue weight", or when an article is "unwieldy", or when related topics are "better appreciated" as separate pages, or when a topic is "controversial" instead of "mundane"? If the goal is to reduce the number of different policy/guideline pages, I say we go all out and synthesize WP:V, WP:NPOV, WP:NOR, WP:NOT, and WP:BLP into a single Wikipedia Rulebook. They're only separate pages due to historical accidents; if one were starting a wiki-based encyclopedia project now, with the benefit of Wikipedia's accumulated experience, one could cover the whole ethos in a single document instead of multiple pages that all talk about each other. XOR'easter (talk) 05:35, 3 January 2024 (UTC)Reply[reply]
Tangential note: A few people have mentioned that it's hard understand notability guidelines due to their length and detail. A couple weeks ago, I began drafting User:Wracking/Notability with the goal of creating bullet-point summaries of each SNG, mainly for my own reference. If this is something anyone wants to collaborate on, please reach out. Wrackingtalk! 05:47, 3 January 2024 (UTC)Reply[reply]
I tend to agree with David and XOR'easter. If I got to rewrite Wikipedia's inclusion guidelines from scratch, I'd go for specific guidelines on specific subjects, based on the consensus of editors knowledgeable about those subjects, and drop the futile quest for a Grand Unified Theory of Notability. The idea that we can use a single standard to classify literally all of human knowledge into the boxes "notable" or "not notable" would sound like complete madness to the average non-Wikipedian. And then try telling them that we think we can do so with just five bulletpoints... – Joe (talk) 09:29, 3 January 2024 (UTC)Reply[reply]
Yeah, what he said, and also what they said. jp×g🗯️ 11:06, 3 January 2024 (UTC)Reply[reply]
@Joe, in fairness, the idea that we're going to have an encyclopedia that anyone can write without even needing so much as a user account or email, that also sounds like complete madness. So not sure that "sounds like complete madness" is a strong argument against anything on Wikipedia :-) Levivich (talk) 20:57, 7 January 2024 (UTC)Reply[reply]
I actually think that WP:GNG is a good Grand Unified Theory of Notability, since it ties back into core policies with the theory "So, can this topic ever make a core policy-compliant Wikipedia article?". Most alternatives tend to lean into "Someone finds this important" which is a lot more subjective and tends to invite both mass stubs and snobbery. Jo-Jo Eumerus (talk) 13:37, 3 January 2024 (UTC)Reply[reply]
I know this comment was made last week, but it seems as good a place as any for me to add my piece of the elephant, which is that in my view the GNG works terribly as a Grand Unified Theory because it applies a pseudo-objective threshold to sets of sources and topics that are in themselves quite heterogenous. But an inflexibly-applied, source-based standard will always lead to the overrepresentation of privileged groups in biographies (like white Europeans) because they are overrepresented in reliable sources. And topics like sub-national geographies of human settlement, or national elections, will be treated inconsistently not only because of actual differences in the "reality" of each geographical or social context but even in cases that are objectively similar, simply because sources are easier to find in some instances than in others. Some periodic elections in a specified polity will meet GNG and others in the same polity will not. Some sub-national territories of a Westphalian state will meet GNG and others at the same level of the same state will not. This does not serve an encyclopaedia.
In my view, one goal of an encyclopaedia is to treat equivalent topics in equivalent ways, and while reliable sourcing is always required, the myth that there is a specifiable level of sourcing that would work for all topics is actively detrimental to the project of building an encyclopaedia of knowledge by and for human beings. Newimpartial (talk) 02:50, 10 January 2024 (UTC)Reply[reply]
Problem is, "white Europeans are overrepresented" in practice means "not-'white Europeans' are underrepresented". It's a subtle distinction but it does matter: If a topic is underrepresented, you can run into serious difficulties in accurately depicting it. I don't write biographies but I've seen the same problem of a non-Western topic having much fewer sources to use in my area of editing (volcanoes, natural phenomena). Sometimes you get lucky as I did with African humid period and there is enough coverage, but other times you have Nuevo Mundo volcano with much fewer sources than the comparable Crater Flat. Jo-Jo Eumerus (talk) 08:28, 10 January 2024 (UTC)Reply[reply]
Obviously Wikipedia cannot publish ahead of the reliable sources. But Wikipedia can publish closer to the extent of RS coverage in areas of underrepresentation while being more restrained in publishing in areas of overrepresentation. Grand Unified Theory approaches to GNG operate in the direction opposite to encyclopaedic coverage in this respect, IMO. And this is a great example also of what an encyclopaedia for humans, by humans, can do better than neural networks can. I think the project should do that. Newimpartial (talk) 11:57, 10 January 2024 (UTC)Reply[reply]
Counterproposal: rename "Notability". If we're really going to rework the inclusion criteria for an encyclopaedia article here, let's do away with the confusing term "notability" and call it what it is. Right now it's something close to alreadypublishedaboutness (catchy, I know), but if we're going to redo the inclusion criteria, we could either rename the larger body of policy after what consensus agrees on the fundamental criterion is, or just call it inclusion criteria. Folly Mox (talk) 14:16, 3 January 2024 (UTC)Reply[reply]
Support this idea much more than dismantling GNG. 🌺 Cremastra (talk) 00:59, 7 January 2024 (UTC)Reply[reply]
While I'm not convinced this is necessary per se, I'm just going to vomit a few potential terms: the crime of "notability" is arguably the "-ability". However, the term should have as little lexical overlap with "verifiability" as possible.
How about substantiation, attestation, recognition, corroboration, representation, precedence?
No, I don't think any of these work: I think "notability" might be the closest, best English word to use for this concept, so that the greatest number of people understand its usage as easily as possible.
I still think it's likely we just have to live with the subjectivity at the heart of "encyclopedias" as a concept. It's not like anyone else has figured this out! Remsense留 01:33, 7 January 2024 (UTC)Reply[reply]
"Inclusion criteria" is the way to go. One fundamental flaw in "notability" is it suggests a property of the subject that we as editors are discovering (something is notable or not notable and it's up to us to figure out which). In fact, "notability" isn't a property inherent in any subject, it's a decision editors make (we don't discover or learn if a subject is notable, we decide whether subjects are notable or not). "Inclusion criteria" has the advantage of being clear that it's a set of rules made up by editors for the purpose of deciding what topics should be covered--and not some inherent property, or something having to do with the inherent value of topics. Levivich (talk) 21:01, 7 January 2024 (UTC)Reply[reply]
Oh and the inclusion criteria should be "enough reliable independent secondary sourcing to write an accurate and complete tertiary encyclopedia article" which is what GNG already tries to get at. Levivich (talk) 21:04, 7 January 2024 (UTC)Reply[reply]
Agree with this. This is why some SNGs, and de facto notability, are bad, because sometimes there isn't enough information out there to write an encyclopedic article. 🌺 Cremastra (talk) 21:14, 7 January 2024 (UTC)Reply[reply]
"Standards of inclusion" is the term I suggested once upon a time, in one of the longest discussions on renaming the notability page. One of the reasons was indeed that it emphasizes that it's a Wikipedia standard, not an inherent characteristic or externally defined property. These days I usually use the more clunkier "standards for having an article", due to Wikipedia:What Wikipedia is not, as it is another standard of inclusion based on scope that is typically evaluated independently of the guidance on the notability page. isaacl (talk) 22:34, 7 January 2024 (UTC)Reply[reply]
I've long said that we should rename it to something that refers to our criteria or requirements for having a Wikipedia:Separate, stand-alone article. Creating redirects for your favorite titles could be a way to identify possible future titles. WhatamIdoing (talk) 01:33, 10 January 2024 (UTC)Reply[reply]
I have to agree with Remsense on most points. While some kind of notability reform is needed, this is not the best way to go about it. Currently, apart from some less stringent SNGs, all articles have to meet GNG. This keeps out of one-reference sub-stubs that are better suited to wiktionary or wikidata. If we remove GNG, then our only rationale for deleting unhelpful articles that wouldn't be notable under GNG is likely a combination of WP:NOTDIC, WP:NOTDB, WP:INDISCRIMINATE, and WP:5P1.
The problem is that all of those are mostly or entirely subjective. Who decides what qualifies as an "indiscriminate collection of information", or what "encyclopedic" really means, when you get right down to it? We already have these disputes (case in point: the Barbenheimer RfC), but if they became commonplace at Articles for Deletion, matters would get worse.
We shouldn't rely on subjective measures. We already do, to a degree (how much coverage is "significant" coverage? How reliable is this source, really?) but implementing such a proposal, and accordingly dismantling the GNG, would intensify existing disputes.
The GNG is not great. But it works, and it's quantifiable, at least more so than allusions to WP:NOT. You need multiple sources, three is recommended, and they have to be reliable and secondary.
I think we should have more, specific, SNGs, that are objective and easily quantifiable. Notability isn't a yes-no question, but if we have more subject-specific notability guidelines, then we can be more accurate. Vaguer standards aren't helpful, because vagueness invariably leads to disputes. 🌺 Cremastra (talk) 18:26, 7 January 2024 (UTC)Reply[reply]
I asked (again) about defining SIGCOV last year. The answers can be divided this way:
[the minority view] We have found and cited at least one source that uses words like 'significant' or 'important' to describe the subject. For these few editors, two short sentences are good enough, so long as one of the sentences says something like "He's the most significant Ruritanian player during the last decade". They're wrong, of course, but it suggests that @Ca is on the right track with the idea of editors wanting to screen out subjects they believe are unimportant.
[the common view among experienced editors] We have found sources that contain enough facts to write an article, as measured, e.g., by word counts or by information contained. However, editors are afraid of saying how much is enough, because as soon as they say "a subject is notable if it gets a total of 2,908 words spread across four news articles in a newspaper on the top-20 list in the List of newspapers by circulation, counting only one article from each year and at least one of the articles has to contain two photos, plus evidence that the subject was mentioned in a still-extant source on social media by a person who won an Olympic medal", then some horrible spammer is going to destroy Wikipedia by getting their stupid little unworthy subject covered in depth by all of these sources, and then where will we be? Plus, if I say that we require 2,500 words in sources, then that might keep out the stuff that I want to write about. If we leave it vague, I can say that my subject only needs Wikipedia:One hundred words in sources, but your subject needs thousands, and unless you're watching my every word, you'll never notice what a hypocrite I am.
We did not come to an overally conclusion, but I think that
we basically agreed that sources containing information that is useless in practice ("I heard a funny joke this morning...") plus content that is potentially useful in an article ("Paul Politician's birthday is on the 32nd of Octember") should only have the potentially useful parts counted towards any sort of word/fact count, and
we inched towards the idea that a couple hundred words of potentially useful content is SIGCOV (i.e., not just a couple of sentences, but also not requiring whole books, or even whole chapters).
then some horrible spammer is going to destroy Wikipedia by getting their stupid little unworthy subject covered in depth by all of these sources, and then where will we be? Plus, if I say that we require 2,500 words in sources, then that might keep out the stuff that I want to write about. If we leave it vague, I can say that my subject only needs Wikipedia:One hundred words in sources, but your subject needs thousands, and unless you're watching my every word, you'll never notice what a hypocrite I am. Incredible. This describes me exactly. 🌺 Cremastra (talk) 02:15, 10 January 2024 (UTC)Reply[reply]
This is what I'm getting at when I gesture to the subjectivity at the heart of an encyclopedia. The encyclopedia genre is synthetic, no one has ever figured out what "should" be in one. It would be very difficult to stomach an overturning of consensus that has existed the entire length of the site, that the presence of some classes of article is a serious net negative to the site, even if it means being arbitrary and potentially keeping some good articles from being created. I believe this very strongly.
I don't want to edit on a site that looks like Urban Dictionary, Reddit, or the oldest editions of the Brittanica in spots: it feels bad, incurious, lacking united understanding in what we're doing here. It's cultural and subjective, but I'm okay with that. Remsense留 02:33, 10 January 2024 (UTC)Reply[reply]
@Cremastra, I think it describes all of us, when we feel like the stakes are high enough. WhatamIdoing (talk) 02:36, 10 January 2024 (UTC)Reply[reply]
WP:Notability is a big vague confusing mess but it mostly works. IMO the way that it really works is that it combines 3 attributes:
Sourcing criteria which ostensibly is the only criteria. This is also used as a measuring stick for #2
Real world importance/notability
Degree of enclyclopedicness .....degree of compliance with Wp:not, above the floor of outright rejection under Wp:not
If we ever want to tidy up wp:notability, we're going to need to acknowledge this as a starting point. North8000 (talk) 14:29, 3 January 2024 (UTC)Reply[reply]
I agree with this. There is a balance between coverage (how often and how in-depth a subject is featured in independent sources) and the importance of the subject. There ought to be or there is more flexibility of sourcing needed for individuals who are at the top of their profession (whether in academics, sport, politics, business) compared with individuals who are active locally, in minor or secondary leagues, or non-executive positions. This is why the SNGs are useful - to help make determinations of real world importance. - Enos733 (talk) 18:23, 3 January 2024 (UTC)Reply[reply]
For example, if two published high school newspapers did lengthy in depth coverage of guitar player John Smith, that fully satisfies GNG but the system might not let that one pass. If the same two writeups were in Rolling Stone magazine, the system would certainly pass him. So the prominence of the sources (combined with the space they dedicated) matters for assessing #2, and #2 matters.
Another example: A town of 1,000 people with no sources other than a couple which (merely) reliably establish it's existence. The system is going to let that one be an article. Some will say it's because "GNG sources are likely to exist" but in reality it's because it's an ultra-enclyclopedic topic. Because it passes wp:not by a mile, and is also mentioned in 5P. North8000 (talk) 21:53, 3 January 2024 (UTC)Reply[reply]
Agreed. When we let the sports SNGs die, we inadvertently opened the door to a lot of minor league baseball players, because minor league baseball necessarily receives a bunch of local/routine coverage which looks like or could be GNG even if the player never comes close to making the major leagues, which was functionally necessary to enter a print baseball encyclopaedia. I'm not generally a fan of SNGs, but the ones that exclude rather than include can be very helpful. SportingFlyerT·C 07:01, 4 January 2024 (UTC)Reply[reply]
I knew at the time that that fix was only going to be 1/2 of a fix. In the "grand wp:notability unification" that I have in my head, it
Acknowledges that real world notability/importance is a factor and the coverage is a measuring stick for that as well
Calibrates for the ratio of coverage to real world notability in that field. Since in sports coverage is an end/product of itself and so less of / a weaker indicator, coverage in this area is less meaningful and it adjusts for that
Calibrate for degree of enclyclopedicness. A typical sports artticl is a bit lower here than a typical enclyclopedia article and it adjusts for that
The net result would be that the standard would be a bit tougher for sports than it currently is. North8000 (talk) 18:14, 4 January 2024 (UTC)Reply[reply]
Adding searching to the nearby page
Hello,
Not sure is this is the correct place to put this, but is it possible to add coordinate or location searching to the nearby page, to allow for location permissions to not have to be granted?
Thanks, Geardona (talk) 12:49, 4 January 2024 (UTC)Reply[reply]
Ok, did not realise that was a feature, maybe add a search bar to the page itself for more user-friendliness? Geardona (talk) 13:03, 4 January 2024 (UTC)Reply[reply]
Auto-confirmed
Hi. I’ve realized that it’s insanely easy to get auto-confirmed status… and I thought I had to use articles for creation forever. Would it be a good idea to make it more difficult? Say 50 edits, like on es.wp, or more time editing; one month, maybe? Encyclopédisme (talk) 14:32, 4 January 2024 (UTC)Reply[reply]
I mean being able, to say, move pages, create pages etc. You need 10 edits and a 4 day old account. That is auto-confirmed. Encyclopédisme (talk) 14:39, 4 January 2024 (UTC)Reply[reply]
@Encyclopédisme Sorry, I mixed it up with auto-patrolled :) My bad !
Despite the name, the autopatrolled flag is only handed out manually. Some accounts are marked as autopatrolled fairly quickly; others can be active for many years and create thousands of pages without it. Certes (talk) 20:30, 4 January 2024 (UTC)Reply[reply]
@Certes I am one of those in the second group :) The funniest part is that I am interface administrator of Serbian Wikipedia, wrote over 800 articles there yet somehow English Wikipedia needs me to show more values.
Please don't take it personally. I've created thousands of pages over the last 16 years and am not autopatrolled. The flag is simply a convenience for patrollers, and doesn't allow the account to do anything it couldn't do anyway. Certes (talk) 22:44, 4 January 2024 (UTC)Reply[reply]
@Боки: You have been autoconfirmed since 03:20, 14 July 2020 (UTC). --Redrose64 🦌 (talk) 22:17, 4 January 2024 (UTC)Reply[reply]
@Redrose64 Yeah, I just realized that I have misread the auto confirmed vs auto patrolled :)
The section refers to autoconfirmed status, which is handed out automatically on the account's tenth edit or four days after registering (whichever is later). That link should show a box top left saying "Your account is autoconfirmed" if you are logged in to an account that is not very new. Certes (talk) 14:46, 4 January 2024 (UTC)Reply[reply]
I personally would keep the WP:AFC route, until an AFC reviewer recommends the article author directly publishes articles. Having multiple eyes is an asset, not a detriment. I wish sometimes as a niche publisher that more people would review my articles. I say that as someone who is WP:AUTOPATROLLED. But making space for newer article contributors is in the interest of the wider encyclopedia. ~ 🦝 Shushugah (he/him • talk) 17:50, 4 January 2024 (UTC)Reply[reply]
I started creating 2 articles already. One of them was reviewed, the other already edited by other editors. The problem is indeed that niche subjects are widely overlooked, and due to the small audience, often state outright false info (Specifically I created articles about the Inca, also widely touched by this), based on old sources, or works of vulgarisation which don’t correspond exactly with the academic consensus. Encyclopédisme (talk) 17:56, 4 January 2024 (UTC)Reply[reply]
I was just curious if there was any discussion earlier, as I was not able to find it in the archives. If not, is it possible to have mass patrolling done? This could be helpful when dealing with multiple edits, where a user has made minor changes such as adding a specific number or other minor details. Instead of going into each and every single one of the edits, is there any way that mass patrol can be implemented, allowing us to check and approve certain unpatrolled edits more efficiently?
@Боки: We don't have edit patrolling enabled on English Wikipedia. Only new pages are patrolled, not individual edits. 🌺 Cremastra (talk) 01:01, 7 January 2024 (UTC)Reply[reply]
@Cremastra If I may ask, why not ? How do you manage the information that gets posted on the Wikipedia pages then ? People can just post anything and everything. There has to be a way that this gets managed. БокиWrite to me! 15:02, 8 January 2024 (UTC)Reply[reply]
@Боки: That's a good question, but I don't really know the answer. Many users informally patrol RecentChanges to watch for vandalism, myself included. We check our watchlists, and keep an eye on worrisome editors. Things seem to generally tick along fine. 🌺 Cremastra (talk) 20:46, 8 January 2024 (UTC)Reply[reply]
@Cremastra What about the fact if someone makes a mistake or puts some incorrect information ? How do users here correct it ? They redo it or do they just revert the edit ? БокиWrite to me! 20:59, 8 January 2024 (UTC)Reply[reply]
Yeah, someone would generally fix the problem or just revert the edit. There has been discussion of enabling edit reviewing lately, but I believe the idea was shot down. I think, in practice, edits are generally reviewed at some time or another, there's just not a special person clicking a "review" button. The process is unofficial and informal. It seems to (mostly) work. 🌺 Cremastra (talk) 21:01, 8 January 2024 (UTC)Reply[reply]
@Cremastra The reason why I am asking is because at Serbian Wikipedia (with a lot less edits, mind you) we have bunch of reviewers (including myself) who review edits of non-auto-patrolled users which brings me to the next point, how does person here on English Wikipedia become auto-patrolled ? БокиWrite to me! 21:04, 8 January 2024 (UTC)Reply[reply]
The auto-patrolled right (where your articles are patrolled automatically) is granted by an admin through a formal request process. See WP:PERM/AP. Cheers, 🌺 Cremastra (talk) 22:12, 8 January 2024 (UTC)Reply[reply]
@Cremastra I will definitely work towards that considering I am an interface admin of Serbian Wiki. My only concern is with this amount of edits, does it not "ruin" the reputation of article if someone can easily add something to the article without anyone noticing it for a while ? БокиWrite to me! 00:26, 9 January 2024 (UTC)Reply[reply]
does it not "ruin" the reputation of article if someone can easily add something to the article without anyone noticing it for a while Someone easily adding something to an article is how Wikipedia works. 🌺 Cremastra (talk) 00:31, 9 January 2024 (UTC)Reply[reply]
@Cremastra I know but in this occassion, I am referring to person adding, for example, "... and this woman has been involved with my dad" (literally) as part of the article. If this does not get patrolled or checked, then this goes on the article that someone will read and say what is going on. БокиWrite to me! 08:45, 9 January 2024 (UTC)Reply[reply]
Well, to a degree that would get checked. I patrol recentchanges fairly regularly, and if I saw that edit, I would revert it. 🌺 Cremastra (talk) 13:11, 9 January 2024 (UTC)Reply[reply]
@Боки, I think you might be unclear on the purpose of auto-patrolled. Most new articles are reviewed by a team of editors, the new pages patrol. When an editor has created a lot of acceptable articles, they can be assigned "auto-patrolled" so the reviewing editors have more time to concentrate on other articles. It makes no difference in editing abilities or rights for the editor who has auto-patrolled. Schazjmd(talk) 00:32, 9 January 2024 (UTC)Reply[reply]
@Schazjmd on Serbian Wikipedia, auto-patrolled means we, as patrollers, do not have to check your edits (whether it's new page or just a simple edit on something) any more and you have gained trust that you will not make meaningless edits and that you know what you are doing on Wikipedia. That's what my definition of auto-patrolled is and that's what I am referring to. БокиWrite to me! 08:47, 9 January 2024 (UTC)Reply[reply]
The scale of editors on enwp, as well as automated anti vandalism tool leaves good faith but non-constructive edits. And it generally works on enwp. Incorrect Source verification is probably hardest challenge we have ~ 🦝 Shushugah (he/him • talk) 09:02, 9 January 2024 (UTC)Reply[reply]
@Боки: With a description like that, I think that you are referring to pending changes review. That is not the same as autopatrolled, which concerns only the creation of new articles. --Redrose64 🌹 (talk) 15:22, 9 January 2024 (UTC)Reply[reply]
A Wikipedia journal
There's a lot of research about Wikipedia, but it tends to be from an 'outsider' perspective: computer scientists and computational social scientists that are interested in Wikipedia because it's a huge, open dataset; critiques of our content, or lack thereof, in specific fields; or, increasingly, experiments in replacing some or all of our work with algorithms. All very interesting and valuable, but what I'd really like to read is more studies of Wikipedia in its own terms. Things like the histories of specific policies, analyses of how processes work, biographies of prominent editors. Research like that does exist (e.g. the WMF's Wikipedia @ 20 edited volume springs to mind), but it's scattered around and hard to find.
If the Wikipedia community was a conventional collective organisation, a scholarly society or a trade union or something, it'd probably already have its own little periodical for that kind of thing. Something like The Signpost, but with bibliographic references, peer review, etc. Written and read primarily be people who are involved in, or at least have a deep knowledge of, the community. It could be hosted on-wiki like the Signpost or, perhaps better for discoverability, somewhere else, as long as it has that rooting in the community. Would anybody else be interested in something like that? – Joe (talk) 08:56, 5 January 2024 (UTC)Reply[reply]
Well as you know I don't really agree with what you wrote there. But certainly that could be one role of a journal like this: counter-critiques to academic critiques of Wikipedia are unfortunately not going to be taken as seriously when they're published on Wikipedia itself. – Joe (talk) 13:59, 8 January 2024 (UTC)Reply[reply]
A nice idea! A major issue is the unpaid aspect of it. On other hand, if an academic is being paid, they can push for open-access, open-data etc.. which is what a lot of meta:Wikiresearch is. I also think about wikinews:Main and the success/challenges it faces ~ 🦝 Shushugah (he/him • talk) 01:11, 7 January 2024 (UTC)Reply[reply]
@Shushugah: Thanks. I'm not sure I follow though, who is(n't) being paid? – Joe (talk) 13:53, 8 January 2024 (UTC)Reply[reply]
Not quite what you're describing, but there are the WikiJournals. The idea there is more about getting wiki contributions to "count for something" by sending them through peer review and formatting them as journal pieces. There was the Wiki Studies Journal which involved several Wikipedians, but it doesn't appear to still be going. Heather Ford kicked off Wikihistories fairly recently -- not sure where that's headed.
Back to your thought, though, it would certainly be interesting. I'd be curious how much enthusiasm there is. I've seen a lot of valuable research projects undertaken by volunteers that would benefit from being cleaned up and formally "published". It may also be useful to provide a forum to publish literature reviews or to critique existing research. — Rhododendritestalk \\ 14:26, 7 January 2024 (UTC)Reply[reply]
My thinking exactly. This is the kind of thing people do already, and especially for users that are also in academia, or plan to be, it would be nice to be able to collect formal citations and credit for it.
Level of interest is the key. If the Wiki Studies Journal was a similar and failed, then it'd be good to know what went wrong. Otherwise, I was thinking of trying to put together an initial issue of invited contributions. If we couldn't find enough contributors, then we have our answer. – Joe (talk) 13:57, 8 January 2024 (UTC)Reply[reply]
HaeB knows a lot about research on Wikipedia. I'm not sure that it's true that a lot of it is done by outsiders. WhatamIdoing (talk) 02:07, 10 January 2024 (UTC)Reply[reply]
Bibliography articles
We have a number of articles titled 'Bibliography of X'/'X bibliography'. Sometimes these are lists of works by a subject, eg Virginia Woolf bibliography. Sometimes they are lists of works about a subject, eg Bibliography of Andrew Jackson. Sometimes they're both, eg Harold Pinter bibliography. Is "both" a desired approach? For example, if I wanted to split out some of the massive bibliography at Virginia Woolf, would I add it to the existing Virginia Woolf bibliography or would I create a new article? And if the latter, what would that be called to distinguish it from the existing article? Nikkimaria (talk) 21:06, 7 January 2024 (UTC)Reply[reply]
That massive bibliography at the Virginia Wolfe article isn't just a bibliography, it is part of the references. The article uses shortened footnotes, so each of those sources is the target of a hyperlink from the short footnotes in the references section. So they can't be moved to another article. Since the term "Bibliography" is ambiguous I would rather articles used the terms Citations / References for the two sections rather than References / Bibliography.
Yep, wouldn't be looking at removing any of the sources actually cited, just some of the ones that aren't. Thanks for the example, that's helpful - anyone have thoughts on what the best titling approach would be for these different types of bibliographies? Nikkimaria (talk) 00:04, 9 January 2024 (UTC)Reply[reply]
Post on an article's Talk page when you remove/move anything from an article's improperly-intermingled Bibliography + Works Cited + References section -- that is, so that anything removed was not from the article's history from a state prior to material being cited in-line, such that any residual material failing in-line verification may be more easily cross-referenced to the article's history. (To those to whom this paragraph seems like nonsensical word salad: you know it when you see it -- see major history articles.) SamuelRiv (talk) 00:30, 16 January 2024 (UTC)Reply[reply]
I think spoken versions of articles have some of the most potential for improvement of any area of the site. Of course, the existing paradigm has an obvious central issue: recordings become out of date almost immediately, which dissuades both potential narrators and listeners. I've thought a bit about this, and I have a preliminary idea for a format that could at least exist alongside the existing spoken articles: abridged spoken sections. Especially on good or featured articles, it seems like sections could be excerpted, possibly adapted to be better read aloud (adapted to a "podcast" form, if you like), and then those could be recorded. Because they are their own text—which would also exist as a readable transcript, of course—they wouldn't immediately go out of date, while reflecting both the work put into the accompanying article and the needs of listeners.Remsense留 04:47, 8 January 2024 (UTC)Reply[reply]
Why wouldn't these excerpts also be prone to going out of date?
I'd be interested to know how many people prefer listening to an out of date version of an article, versus having a screen reader read the up-to-date version.
I also wonder if effort could be focused on marking up difficult passages to assist screen readers in some way. Barnards.tar.gz (talk) 08:58, 8 January 2024 (UTC)Reply[reply]
Because they would have their own transcript that may be edited to have particular suitedness to being read aloud—they would only meaningfully become out of date if the substance of the part of the article that was abridged changes, not just minor changes in wording or sentence reshuffling.
I think screen readers are the other major reason articles aren't read anymore, but I think—albeit as someone who uses screen readers but does not require them to read—that they're just not as nice a lot of the time? Sure, people can set screen readers to a blistering pace they're still comfortable with, but they still produce errors and best-fit algorithmic awkwardness. There's plenty to explore in a "podcast" presentation to achieve what screen readers cannot. Perhaps the format can diverge even further—during a discussion I was having a few days ago, the possibility of writing for/recording a dialogue format came up, and I think that has potential. Remsense留 20:57, 8 January 2024 (UTC)Reply[reply]
I think the best way to solve the outdating issue would be to create a clickable tool or function that would use something like AI or computer speech that would be in-built in Wikipedia that can read the text in all articles exactly as they currently stand. Helper201 (talk) 21:50, 8 January 2024 (UTC)Reply[reply]
As already mentioned, many people already use screen readers that are highly customizable by each individual user: we are discussing a potential form of spoken article that would also be less redundant in the age of screen readers. Remsense留 21:53, 8 January 2024 (UTC)Reply[reply]
Screen readers have existed longer than Wikipedia has. They've probably become a bit more mainstream though, with VoiceOver and Google TalkBack being pre-installed on smartphones. As a screen reader user, I'm very text-oriented so I almost never use Spoken Wikipedia and would almost never use spoken excerpts either. I don't think many proficient screen reader users would. Graham87 (talk) 06:08, 9 January 2024 (UTC)Reply[reply]
Thank you very much for your insight. This may seem like an off-topic question, but what about podcasts? Are they perceived as too slow or inferior to (hypothetically) equivalent passages from books using a screen reader as well? If not, what advantages do they have? Are there any advantages for you personally to have something narrated by a person as opposed to a screen reader, or are the disadvantages simply too great? Remsense留 06:15, 9 January 2024 (UTC)Reply[reply]
@Remsense: Sorry, just got this. Lots of blind people like them; several use audio players to speed them up. I don't listen to them often though but I'm probably an outlier that way. If both a podcast and a transcript were available, I personally would only listen to the podcast if I wanted to find out what a person's voice was like ... or if the production had sound effects, etc. that couldn't be conveyed through a transcript. As I said I'm a bit more extreme than most blind people this way though. Graham87 (talk) 12:21, 11 January 2024 (UTC)Reply[reply]
Pinging @Isaidnoway:, who also uses a screen reader and expressed the polar opposite view from mine in that discussion. Graham87 (talk) 12:30, 11 January 2024 (UTC)Reply[reply]
It's a survey with actual voting. A place to dump all your complaints and wants. Maybe something with more focus will come out of it but I wouldn't want to be the one who had to summarise it. Doug Wellertalk 16:59, 10 January 2024 (UTC)Reply[reply]
Workshop: draftifying
Firstly, Jimbo Wales agrees with me. Well, not with me directly. But with the gist of this argument, and the argument behind unreferenced-PROD. He wrote in 2006:
I really want to encourage a much stronger culture which says: it is better to have no information, than to have information like this, with no sources. Any editor who removes such things, and refuses to allow it back without an actual and appropriate source, should be the recipient of a barnstar.
As a New Page Patroller, I frequently draftify unsourced articles.
Not unfrequently, the creator of the article moves the draft back to mainspace, or re-creates it with the same content. The topic is frequently fringe, difficult to verify, but not necessarily PRODable or AfD'able.
It isn't 2005 anymore. We shouldn't have new unsourced articles being created. They do get created, but are usually PRODed or draftified by NPPers.
Per WP:DRAFTIFY, we aren't allowed to re-draftify an article. Because of this clause, draftifying is essentially useless. All the creator has to do is move it back.
Someone dumps a pile of garbage on the sidewalk. There might be some re-usable or recyclable items in there, but it's hard to tell. Per municipal policy, a street cleaner takes it to the waste-dumper's house. It's their garbage.
Instead of throwing it out normally, or sorting out re-usable or recyclable stuff, the waste-dumper takes their garbage out of the facility and puts it right back onto the street. The street cleaner finds it again. Municipal policy states that the cleaner should either sort through it themself or ignore it. Once they have finished sorting, they should keep the recyclable items and take the rest to a waste-management facility, where they will have to write a report detailing why they think the garbage should by destroyed. The waste management facility is called AFD.
This is clearly nonsense. Why should the street cleaner have to sort through someone else's garbage?
I would like to propose disallowing draftified articles being moved back to mainspace if the problem for which the "article" was draftified has not been fixed. Let the street cleaner take the garbage back the waste-dumper's house. 🌺 Cremastra (talk) 15:34, 13 January 2024 (UTC)Reply[reply]
^Wales, Jimmy (2006-07-19). "insist on sources". WikiEN-l. Retrieved 2007-01-31.
A reminder for those who don't notice the brightly-coloured editnotice: this is the idea lab, so no !votes. 🌺 Cremastra (talk) 15:35, 13 January 2024 (UTC)Reply[reply]
I think we discussed this before on Discord, and the main highlighted point was: 'Users have the right to object to draftification and can move it back to the article space.' But it's good to see you here, searching for some additional ideas. – DreamRimmer (talk) 16:17, 13 January 2024 (UTC)Reply[reply]
When I check my Draftify log, most articles have been improved & returned to Mainspace. The major challange is the PROD/AfD process. In May, 2023 I setup my PROD/AfD subpage to track articles. I am totally Ok with reverts along with a reasonable explanation. It's a problem for un-explained reverts, and "junk/incomplete" articles remaining in mainspace. And I understand the goal is article improvements. Thanks for this discussion. Regards, JoeNMLC (talk) 16:44, 13 January 2024 (UTC)Reply[reply]
Looking at one's draftify log is a good idea. Looking at my own, from August 2023, when I only draftified 8 articles:
One was redirected, after some confusing duplicated drafts/AfC-dodging and this related AfD.
Five remain in draftspace. Two of those drafts have been deleted because they were created by a sockpuppet.
One has been moved back to mainspace after being improved in draftspace, and looks pretty good.
One was re-created, unreferenced, in mainspace. It was unsuccessfully PRODed by a different user in October 2023; it has no references but is a list of sorts.
I hate that linked essay, and have found that in most cases, unreferenced prose is relatively easily verifiable in published sources that the original editor neglected to include.Having said that, I do think the current wording of WP:DRAFTOBJECT is overly strict. I don't think the same reviewer / patroller should draftify the same page more than once, even in the absence of improvements, but if multiple reviewers / patrollers think an article should be returned to draftspace for improvement, that no longer strikes me as "unilateral", and it is in fact the draft creator's moves to mainspace that are "unilateral", and the required next process should be AfC rather than AfD.The AfD problem is real, but the garbage analogy is inapt. Unreferenced articles are less "this is garbage" and more "someone didn't fill out the paperwork". (Also, unless you're very nosy, it's usually pretty difficult to determine whose garbage you've happened across littered in the public space, and no municipality I'm aware of requires street cleaners to sort waste streams on pickup, even if it is best practice. Typically, this duty falls on the people who work the recycle and hazmat streams at the transfer station or other facilities, with the acknowledgement that the landfill stream will often contain material that properly ought to be processed differently.)Folly Mox (talk) 18:01, 13 January 2024 (UTC)Reply[reply]
To 99% of people having their article moved to draftspace is going to discourage them from ever improving it.★Trekker (talk) 22:16, 13 January 2024 (UTC)Reply[reply]
Why so? Having it moved to draftspace is a chance for them to fix it without other editors swarming over it with cleanup tags and PROD templates and brightly-coloured banners. 🌺 Cremastra (talk) 22:42, 13 January 2024 (UTC)Reply[reply]
I believe @WhatamIdoing has the specific numbers, but draftified articles have a dismal return-to-mainspace rate. Mach61 (talk) 01:26, 14 January 2024 (UTC)Reply[reply]
Draftspace is where articles go to die, and we've known that for years. Steven Walling knows the original research on this best, and if you wanted to get more recent numbers, @Cryptic or someone else at Wikipedia:Request a query could probably tell you what percentage of pages in the Draft: namespace got deleted last year (e.g., created in January 2023 and deleted from the Draft: namespace since then).
You can also estimate it from the logs. You can find the number of page moves into vs out of the Draft: space in Special:Log/move and the number of articles created and deleted in Special:RecentChanges. The numbers for the last couple of days look like roughly 120 articles created each day, 150 articles moved into the draftspace each day, 150 articles moved out of the draftspace each day, and 150 articles deleted each day. We put 270 articles in, and we deleted 150 of them. That's a 55% deletion rate. Ideally, you'd look at these numbers over the space of at least 7 full days, as there are definitely weekly trends in activity, and things like a holiday weekend, an important football game, a change in the activity level for even one key editor, etc., can throw the numbers off quite a bit. WhatamIdoing (talk) 22:48, 14 January 2024 (UTC)Reply[reply]
But is all this necessarily bad? I believe in quality over quantity. 🌺 Cremastra (talk) 22:51, 14 January 2024 (UTC)Reply[reply]
Issues I believe this proposal would have to first resolve in order to have any chance of gaining consensus: (1) There will probably be a dispute about whether the alleged problem with the article/draft actually existed in the first place. (2) There will probably be a dispute about whether the alleged problem with the article/draft was sufficiently serious to justify draftification. (3) There will probably be a dispute about whether the alleged problem with the article/draft has actually been fixed. In all three cases, the draftifier is not particularly unlikely to be completely on the wrong side of consensus. The fact that the draftifier believes or claims that a page is "garbage" does not mean that the page actually is garbage. To take the example given by the proposer, I have, over the course of many years, seen many articles tagged as "unreferenced", despite that fact that those articles very obviously did have references (presumably because the tagger just did not like the references in the article). I cannot imagine the community supporting the unilateral draftification, with no right of appeal, of articles, where there is a real dispute about the 'appropriateness' of the draftification. James500 (talk) 02:18, 14 January 2024 (UTC)Reply[reply]
I don't think this can pass. Judging from previous village pump discussions, about half of Wikipedians don't like draftspace, seeing it as a backdoor to deletion. The de facto options in situations where a very poor article (such as one with no sources) is WP:DRAFTOBJECTed are WP:AFD, or WP:TNT. Hope this helps. –Novem Linguae (talk) 03:58, 14 January 2024 (UTC)Reply[reply]
Unsourced articles are an easy target but fundamentally WP:DRAFTOBJECT is not about article content, it's about WP:CONSENSUS. If you think an article doesn't meet WP:V and therefore shouldn't be in main space, but another editor disagrees in good faith (i.e. by reverting your bold move to draft space), then you have to stop and talk about it. There's really no way around that. You can't just insist that you're right and the other editor has to satisfy you, because you're the New Page Reviewer. That's not "the encyclopedia that anyone can edit". Besides, I've seen NPPers wrongly identify articles as unsourced plenty of times, whether because they missed references that looked like something else, a new editor struggling to format their sources, or just didn't read it properly. Folly Mox makes a good point about multiple reviewers being involved above, but still, if multiple editors are involved in a dispute about where a page should be, we'd expect them to discuss it (e.g. at AfD), not get into a move war. – Joe (talk) 07:14, 14 January 2024 (UTC)Reply[reply]
Wasn't the "information like this" from the Jimbo quote something about two tech founders throwing pies at each other to settle a dispute? That probably doesn't apply to most of the articles we're talking about, which don't tend to involve unlikely stories about BLPs (the quote is from years before the creation of WP:BLP). A few thoughts:
The underlying assumption is that the article creator WP:OWNs the article. This is supposed to be a collaborative project, so why should we treat an unsourced article as "your garbage"? I disagree that unsourced content is always "garbage" or "graffiti", but why don't we think of it as "our" problem? New content is a gift to us and to the world. Some gifts are bigger or smaller, and some are better or worse, but the absence of a little blue clicky number doesn't make it garbage. (My own idea of garbage is misinformation and disinformation.)
The belief that an unsourced article is "unfit for mainspace" is not supported by any policy or guideline. It is the personal preference of a fraction of editors, but it's not one of our rules. If we want to build a system based on this preference, then that preference needs to be turned into an actual rule first.
I wonder how big this problem actually is. I checked the pages created during the last three days in the mainspace and draftspace, using the visual editor (because there's a tag that makes it easy to check for the addition of a new ref, but it's not available for the 2010 wikitext editor [yet?]). 40% of them were redirects, at least 45% had at least one ref tag added in the first version of the page, and the remaining small fraction either had a ref added later (example, example, example), or not at all (example article, example dab page), or it actually had refs but they weren't autodetected (example, example, example, and pinging User:ESanders (WMF) to see whether that's a bug in mw:EditCheck). This is overall not feeling like a serious problem. Most pages that are supposed to have refs (e.g., they're not dab pages) are already getting refs. In fact, having looked at this, I don't think I would draftify a new article if this were the only serious problem.
Unsourced articles are definitely unfit for mainspace in this day and age especially if they don't fall into the evergreen WP:NSPECIES, WP:NPOL and WP:NGEO spectrum. I personally prefer the AFD route than the draftification route, however, it still stands that unless improved, a complete unsourced article is no better than misinformation and disinformation. Sohom (talk) 15:42, 15 January 2024 (UTC)Reply[reply]
@Sohom Datta, there is no policy or guideline that says all articles must cite at least one reliable source. Wikipedia:Notability explicitly says the opposite: what makes a subject notable is whether sources exist in the real world, not whether sources have been typed into the Wikipedia article. It is true that some individuals personally believe that an article without a source is unfit for mainspace, but that's a personal belief and is not supported by policy.
BTW, the research on the draftspace indicates that if you want unsourced articles to get sources, you need to leave them in the mainspace. If your goal is to get them deleted with a minimum of fuss and bother, then you should put them in the draftspace. WhatamIdoing (talk) 17:27, 15 January 2024 (UTC)Reply[reply]
I do agree that articles need to have at least one reliable source cited though. I think what you meant here is that this should not be acted retroactively. CactiStaccingCrane (talk) 17:29, 15 January 2024 (UTC)Reply[reply]
My point is even smaller than that: Editors should not misrepresent the state of the actual rules by claiming that unsourced articles can't be, or shouldn't be, in the mainspace solely because they are unsourced. The correct (i.e., accurate and honest) process is:
Rules explicitly do not require a source to be cited in a mainspace article.
Get rules changed to require at least one source to be cited.
Tell editors (especially newbies) that their new article is unacceptable because it does not comply with the new rule.
The process that some editors are currently using is:
Rules explicitly do not require a source to be cited in a mainspace article.
Tell editors (especially newbies) that their new article is unacceptable because it does not meet my personal criteria, while pretending that my personal criteria are the actual rules.
Whether the new rule is retroactive or not is not really a concern of mine. I am confident that it would eventually become retroactive even if it doesn't start that way. (That's exactly what happened with the rules for WP:BLPPROD: it started off as solely forward-looking, and became retroactive later.) What concerns me is editors claiming that the rules are X when the rules are actually not-X. Either change your claims or change the rules, but don't misrepresent the rules. WhatamIdoing (talk) 17:41, 15 January 2024 (UTC)Reply[reply]
@WhatamIdoing I think you missed my point about a AFD. The fastest way to get sources to a article in my experience (counterintuitively and unfortunately) is an articles for deletion/discussion, not letting it languish in mainspace (and definitely not draftspace). A AFD puts it on the radar on multiple wikiprojects, which are much more likely to provide reliable sourcing than I will ever be able to provide.
If even after 2/3 weeks of advertising, nobody (including the article creator) thinks the article is worth saving, that could/should indicate that the article is probably not notable at that current moment.
Also, I agree that there currently exists no policy that prevents a editor from not including any sources in a article (theoretically). But at a much more practical level, it is not really fair to expect a editor with limited prior understanding of the subject matter to accurately evaluate a articles notability if they have absolutely zero starting points for their search for sources. Sohom (talk) 17:57, 15 January 2024 (UTC)Reply[reply]
And yet we say that Wikipedia:Deletion is not cleanup, because it's uncollegial and anti-collaborative for an editor to demand that others drop everything they're doing because an article must be sourced this week, or it will be deleted. As you say, editors with limited prior understanding of the subject matter have difficulty accurately evaluating notability for those subjects – so they shouldn't be sending them to AFD in the first place. AFD is for articles that you genuinely believe to be non-notable, not articles you'd like someone else to improve right away.
Permitting editors to use AFD to demand clean up of subjects they're unfamiliar with is also a source of systemic bias. We've had altogether too many cases of editors sending Asia- and Africa-related subjects off to AFD out of ignorance, thinking that WP:NEVERHEARDOFIT is a good enough excuse and that if other editors want to keep it, then they will cheerfully drop everything they're doing to provide sources. If nobody intervenes, we lose the articles. This is not okay. WhatamIdoing (talk) 18:07, 15 January 2024 (UTC)Reply[reply]
I personally don't think it is uncollaborative to go "Hey, this article has no sources, and I could not find any based on a few Google searches, what should we do about this ?" (which tends to be most AFDs these days). For all you know, it could be a radioactive peice of hallucinating ChatGPT junk (or other promotional garbage) which needs to nuked out of orbit ASAP, or it could be a documenting an important niche topic that few people have heard about which needs to be preserved. AFD is lot more collaborative than, "well, that's somebody else's problem I guess" and walking away. Sohom (talk) 18:28, 15 January 2024 (UTC)Reply[reply]
Do you mean that the creating-edit isn't tagged with "adds reference"? That does look suspicious. Am I still allowed to ask you to file a Phab task 🙂 ESanders (WMF) (talk) 18:31, 15 January 2024 (UTC)Reply[reply]
If y'all end up creating a phab, could you subscribe @soda (me) as well :) Sohom (talk) 18:34, 15 January 2024 (UTC)Reply[reply]
Oppose - The remedy here is AFD, not permanent banishment to AFC (followed by eventual deletion without discussion through G13). If you can't see a consensus to delete, please don't harass article creators. ~Kvng (talk) 13:15, 16 January 2024 (UTC)Reply[reply]
Sigh. You didn't read the banner, or the edit notice, or my reminder, did you. 🌺 Cremastra (talk) 13:24, 16 January 2024 (UTC)Reply[reply]
@Cremastra, No I clearly did not. Sorry. I'm not sure how to be constructive about this proposal. Does that mean I should say nothing? ~Kvng (talk) 02:14, 17 January 2024 (UTC)Reply[reply]
"The topic is frequently fringe, difficult to verify, but not necessarily PRODable or AfD'able." If it would be appropriate to boldly draftify an article, then it would appropriate (when contested without fixing the issue) to nominate it at AfD for draftification. As with a contested blank-to-redirect, for which the appropriate discussion venue is AfD per this request for comment, you don't need to request deletion in order to nominate an article at AfD. And if it is not nominated for the purpose of deletion, then a full WP:BEFORE inquiry about whether the subject is notable and so forth isn't applicable.
I'd like to see the standard draftification messages more explicitly say that if an editor disagrees with the reasons for draftification, they can respond to the reasons for the move and ask (insist) that the article be restored to mainspace until there is a discussion to either delete it or make it a draft. SilverLocust💬 19:56, 16 January 2024 (UTC)Reply[reply]
Excise the "crime" topic from the "law" topic; make "law, government and administration" an established grouping of topics
As an editor largely focused on law and legal philosophy articles, I find it hard to locate articles on subjects relevant to me and my expertise on Wikipedia-space pages that are sorted by topic (like WP:FAC, WP:GAC, or WP:RfC).
The undifferentiated inclusion of the very popular "crime" and "law enforcement" categories (here I don't mean categories in the technical sense) in the overall fairly unpopular "law" category means that most articles sorted under "law" turn out to be "Murder of so-and-so" or "Jimminy Bob Killman (murderer)"-type articles which require no particular expertise in any country's law or any field of legal scholarship. In terms of the skills required to contribute, they are perhaps closer to biography or history articles, or they might be in a category of their own.
Since law is a fairly underappreciated topic on Wikipedia (I find), it may be appropriate in some contexts to group it together with related topics. I would suggest that "government" be split off from "politics and government" where it exists, and merged with "law" and a newly minted category, "administration", forming the "law, government and administration" category. ("Government" would thenceforth focus more on formal/institutional political science and social philosophy, whereas "politics" would be retain people, parties, ideologies, and what have you.)
I'd be interested in alternative solutions, though, since two objections to the idea do spring readily to my mind: For one, public law is arguably the only government-/administration-adjacent field of law, and private law should be appended to the "economics" topic or something. For another, grouping law with government might create the impression that the law is definitely an institution of the state (the government), or even synonymous with it. This is not undisputed; especially some jurists in the common law tradition (found e.g in England and the U.S.) maintain that it is fundamentally a set of societal traditions, influenced by, but not derived from, the state.
What I'll be looking for when I put the finished proposal out is a consensus that the new categorization/grouping practices be recommended for internal and public-facing categorization purposes.
Again, I'd love to hear perspectives and suggestions. If you could tell me which user communities I should notify about this post or the finished proposal so that consensus is representative and the relevant people are aware of this re-systematization, I'd also be much obliged.
I was going to recommend -deepcat:"Crime", but there are too many subcategories and the search fails. Folly Mox (talk) 02:44, 14 January 2024 (UTC)Reply[reply]
Have you tried searching incategory:"WikiProject Law articles" -incategory:"WikiProject Crime and Criminal Biography articles" ? Make sure you are searching in the Talk: namespace or maybe just go through Category:WikiProject Law articles115.188.140.167 (talk) 10:16, 14 January 2024 (UTC)Reply[reply]
Are you looking for articles to edit, or specifically for FAs and GAs? SuggestBot can look at your contributions and suggest a list of articles that you might be interested in. WhatamIdoing (talk) 23:44, 14 January 2024 (UTC)Reply[reply]
Thanks for those recommendations! SuggestBot and the specific phrasing of the search terms provided, in particular, sound useful for my purposes. I was hoping to help bring already high-quality law articles into the spotlight by reviewing/supporting them in the FA/GA processes, which is why I was looking there specifically. I also want to get a general idea of the structure and weak points of jurisprudential Wikipedia.
That said, I'm not sure if looking for articles listed by WikiProject Law will help in every case. Wherever articles of all topics are listed for specific encyclopedic purposes, the poor categorization of law will make things hard; which is why I wanted to achieve a general consensus before I charge ahead with shifting around categories. Additionally, I'm not too well-versed in Wikipedia's more technical side, so any list-producing bots that automatically compile articles into categories would need to be adjusted by more adept minds.
Incidentally, it occurs to me that perhaps I ought to get WikiProject Law on board first . . .
Hello,
Would it be possible to add the tags "previously undone edit", "possible edit war" and "likely repeated vandalism". All would be activated in slightly different ways, the first would be activated when the same user undos the reversion of their original edit; the second would be activated when 2 separate versions of a revision are rapidly changed between; the third would be an escalation for the first, a high ORES score edit being consistently reverted and re-added.
Definitely maybe. The first might be possible in Special:AbuseFilter (about which you can inquire at Wikipedia:Village pump (technical)). I think that detecting the others might (a) have to be done in MediaWiki code, like the Reverted tag, and (b) not be available instantly, especially if you want it to work if there have been unrelated intervening tags. WhatamIdoing (talk) 23:47, 14 January 2024 (UTC)Reply[reply]
Probably useful to file a phab for this, and maybe something that the ModTools team would be interested in looking into :) Sohom (talk) 15:17, 15 January 2024 (UTC)Reply[reply]
The integration of a neutral and curated AI platform with search engines has the potential to revolutionize information access and combat misinformation. By providing context, flagging biases, and promoting critical thinking, these platforms can empower users to navigate the complex information landscape of the internet Perfedge (talk) 06:06, 15 January 2024 (UTC)Reply[reply]
Wikipedia is an online encyclopaedia, not a search engine, so that would be out of scope for the project. And while the Wikimedia Foundation might possibly have the funding to finance such a project, if it were feasible, they don't have much of a reputation for creating complex software with any degree of rapidity. And frankly, the evidence that current AI is even capable of fulfilling the objectives you describe would appear to be lacking. 'Critical thinking' will, for now, have to be facilitated by actually doing the thinking ourselves. AndyTheGrump (talk) 06:17, 15 January 2024 (UTC)Reply[reply]
Oddly enough, that statement sounds like something a chatbot would spit out. Or a "corporate mission statement." But I have to object to using "curated" "revolutionize" "combat" "promoting" "empower" and "landscape" in just two sentences.
Also, no. Per AndyTheGrump, we will have to continue to use brains. 🌺 Cremastra (talk) 22:40, 16 January 2024 (UTC)Reply[reply]
Ignoring the lead comment (which no offense to user, sounds like machine-generated businessbabble, hold the synergy), I'm intrigued by the header question. I don't think ChatGPT in any nearcoming commercial iteration will be particularly useful as a dynamic tool for evaluating sources, not least because it doesn't get updated fast enough. However at its most basic, I'd like to see if it can give some intelligent analysis (at either the individual article level or of an outlet given a sample of articles) that's better than some of the crud at Media Bias/Fact Check. (Have MBFC's writeups gotten better in the last couple years? Their methodology for comparing outlets actually in theory seems not bad.)
To start I tried asking ChatGPT (3.5) in a couple prompts to evaluate bias and reliability on article from an inner-metro local paper, the Dorchester Reporter, figuring that the author is unknown and the paper would not be much evaluated in any secondary media GPT may have seen. I'm currently having trouble getting the output to say anything of substance (it almost seems to be telling me to do my own homework!) (and yes I'm including the full article plaintext in the prompt). If anyone else is interested, see if they can get anything substantial -- I have then prepared a regional cross-section of local outlet stories on the same topic, and a also spread of sample stories from a new outlet, to see what kind of reports it will give. SamuelRiv (talk) 01:54, 17 January 2024 (UTC)Reply[reply]
Export to PDF, Epub, Odt and LaTeX
Hi,
I would like to include mediawiki2latex in Wikipedia. It exports wiki articles to PDF, Epub, Odt and LaTeX.
Yours 11:43, 15 January 2024 (UTC) Dirk Hünniger (talk) 11:43, 15 January 2024 (UTC)Reply[reply]
Improving Wikipedia's Editing Process
I'm an expert in an emerging technology called "General Collective Intelligence" or GCI platforms, which aim to significantly increase the collective intelligence of groups, and hence to significantly increase impact on any collective outcome in general that a group might target, per dollar of resources spent. This has the potential for radically disruptive positive impact in a vast range of areas from addressing poverty, to sustainable economic development, to addressing the environmental degradation that has been associated with climate change, but I'd like to begin with improving Wikipedia's editing process. In summary, a general collective intelligence identifies different problem solving strategies and the domains in which each strategy is optimal in order to switch to the optimal strategy for each problem. Some typical issues that plague Wikipedia (like edit warring) are just symptoms of a clash between problem-solving strategies rather than the collective intelligence to cooperate in using the optimal strategy. A short summary is linked below. I look forward to your guidance.
Please provide citations to appropriate third-party sources supporting your claims concerning the abilities of 'General Collective Intelligence'. AndyTheGrump (talk) 14:44, 15 January 2024 (UTC)Reply[reply]
To achieve Collective Intelligence one needs a lot of permutations and most Wikipedia articles tend to reach a "good enough" state, then don't deviate much beyond that due to the work involved in rewriting existing text. It's actually harder to rewrite an existing article than create a new one. In rewriting, you have to consider and incorporate what is already there, plus add new content around it. Very time consuming. Most users don't undertake that unless they are really dedicated, or the existing requires WP:TNT. Most articles reach a point then don't evolve much. (Ignoring all the maintenance and trivial edits). A better example of GCI is generative AI because it speeds up the evolution process to (literally) light speed, one can quickly see collective intelligence generating new things of value. -- GreenC 16:24, 15 January 2024 (UTC)Reply[reply]
Sounds like doi:10.1007/978-981-19-2840-6_18. It's probably not a notable subject, and I doubt that it would work. That is, it would only work if nearly all the participants were truly open to any outcome, which is basically never the case when there's a dispute. It would have us be hyper-rational when people are being emotional. It could probably turn into a decent consulting career specializing in things like creating corporate mission statements and such, though. WhatamIdoing (talk) 17:52, 15 January 2024 (UTC)Reply[reply]
Indeed, uh what? Or to put it another way, 'citation needed'. I know it's fashionable these days to claim that AI can solve all of the world's problems before tea-time, but we actually need concrete verifiable evidence to justify using it on Wikipedia. AndyTheGrump (talk) 17:56, 15 January 2024 (UTC)Reply[reply]
Understandablifying advanced math articles -- GPT and the Holy Grail
Forever ago (2007) I created a few theoretical comp sci and neurosci articles -- stressing the content is mostly math. One of which I (mis?)remember, but cannot seem to find now, attracted some comment on the Talk page like it was completely incomprehensible and the worst article they had ever read on WP. (I had thought it was Flashsort, which I wrote on WP:REQuest and attracted some mockery, but I might be confusing stuff.) I had a good laugh at this stuff -- if you check the Talk pages on WP math articles, such comments aren't exactly unusual -- I always wondered in my time educating and writing if there wasn't some way to just break through this seeming dense incomprehensibility barrier that's almost universal in rigorous technical text.
Fastforward to today and people figuring out use cases for ChatGPT (3.5). I type in the following: Rewrite the wikipedia article on Flashsort into simplified English
ChatGPT 3.5: Flashsort into simplified English
Flashsort is a way to arrange numbers or data in order, from the smallest to the biggest. It's a special method that does this really quickly.
When we want to sort things, like a list of numbers, there are different methods to do it. Some are faster than others. Flashsort is one of the faster ones.
Here's how it works:
Dividing the Range: First, we look at the numbers we want to sort and find the smallest and biggest numbers. This helps us figure out how big our sorting range is.
Creating Buckets: Imagine we have a bunch of boxes, and each box can hold a certain range of numbers. We create these boxes, also called "buckets," to fit the range of numbers in the list.
Distributing Numbers: Now, we go through our list of numbers and quickly put them into the right buckets. We do this by calculating where each number should go based on its value.
Sorting Inside Buckets: After we've put all the numbers in their respective buckets, we sort the numbers inside each bucket. We can use any sorting method we like, but inside each bucket, the numbers are already close to each other, so we don't have to do a lot of work.
Joining Buckets: Finally, we take the sorted numbers from each bucket and put them together. When we do this, the numbers are all sorted from smallest to biggest.
Advantages of Flashsort:
It's fast, especially when dealing with a large number of items.
It's efficient because it doesn't waste time comparing every number to every other number.
It works well when the numbers are distributed unevenly, meaning some numbers are way bigger or smaller than others.
Limitations of Flashsort:
It might not be the best choice for sorting very small lists.
It needs some extra memory space to create the buckets.
In simple terms, Flashsort is a clever way to quickly sort numbers by dividing them into buckets, sorting those buckets, and then putting everything together. It's like sorting toys into different boxes based on their size and then arranging the toys inside each box neatly. This helps us find what we need faster.
The output is mostly accurate. More to the point, while it doesn't sound completely precise in a mathy sorta way, when I went over it a few times I couldn't think of anything wrong with it, or even necessarily disqualifyingly imprecise about the text. It reminded me of a really really well-written teen/lay science book, except such a really esoteric topic that nobody would ever put it in a teen or pop book.
All I can think is that this is a game changer, especially with GPT-4. The lede of almost every major, but densely written, technical article can be run through this and then curated, since the lede does not have to be 100% precise on any topic -- history, agriculture, sports, whatever -- that's for the body. Even more significantly, this could be an engine to draft minor articles for review for Simple English WP, which is still anemic by comparison.
Again, to emphasize, (as if anyone anywhere serious disagrees or hasn't considered this:) all generated material is a draft that must be reviewed in its entirety for content; and (lesser consensus on this:) any lengthy prose retained verbatim for WP or other publication should include attribution to content generation tools used. SamuelRiv (talk) 01:59, 16 January 2024 (UTC)Reply[reply]
I think the "mostly" in "mostly accurate" is a problem. ChatGPT and these things have a known reputation for saying untrue things. In practice, I think this suggestion will fail because it's a lot of effort to check each claim, and people will often forget to do so. Jo-Jo Eumerus (talk) 08:48, 16 January 2024 (UTC)Reply[reply]
And let's not forget that the sheer existence of English Wikipedia and Simple English wikipedia, is one of the reasons this model even knows how to do this. —TheDJ (talk • contribs) 09:34, 16 January 2024 (UTC)Reply[reply]
You really don't see "anything wrong" with "It works well when the numbers are distributed unevenly"? I'm also going to take issue with why it says "Sorting Inside Buckets" is fast, the very existence of the "Joining Buckets" step, and (relatedly) that it doesn't say anything besides "quickly" about how this differs from a histogram sort, the explanation of which forms the bulk of the article. —Cryptic 10:09, 16 January 2024 (UTC)Reply[reply]
I know the idea lab is for positive feedback, but this example is not great. There are basic errors: not only does flashsort not work well when the numbers are distributed unevenly (because some buckets remain big), but "uneven" doesn't mean some numbers are way bigger or smaller than others (1, 2, 10 is uneven; 1, 1001, 2001 isn't). Worse, it sounds credible: having sucked the reader in with a few truisms, it hallucinates plausibly. Even some true facts are misleading: it doesn't waste time comparing every number to every other number, but even bubble sort isn't that dim. Less importantly, the tone is unencyclopedic, but that covers up the fact that even the correct statements are vague and imprecise (fast rather than O(n), etc.). One day we may be able to curate good AI-written articles, but we seem to be a long way from that yet. Certes (talk) 14:16, 16 January 2024 (UTC)Reply[reply]
Some things to clarify:
First, I did all this several months ago and only have notes of the prompt and output. I should have reread instead of going just from memory. Yes, the "Advantages" and "Limitations" are awful, so I shouldn't have flatly said there wasn't "anything wrong".
Second, we can show it with a better article example (one I actually cared to remember anything about), and also on GPT-4, but what I'm impressed by is the ability to put technical text into a readable format while still accurately describing steps of the algorithm. I'd still say on a quick re-read there's nothing disqualifyingly wrong in what is affirmatively stated (except in the two sections noted), except there is significant omission (it's a very short output for a long technical article) -- my point is that it can help write good ledes where you will always have imprecision and omission. I'm not sure where specifically you see hallucinations per se -- it doesn't go off into outer space in the sections noted.
Third, you can fine-tune tone with prompts, and you can fine-tune how much mathematical language you want to have in there too (or just add it yourself in the curation process. For the prompt I used, copied literally, I'd say it output something expected.
Fourth, who said anything about "AI-written articles"? I'm talking about a tool to aid in writing -- the kinds of things the whole rest of the ChatGPT-using population is using it for. SamuelRiv (talk) SamuelRiv (talk) 18:06, 16 January 2024 (UTC)Reply[reply]
I agree that a simple prompt like the one you have provided can easily be improved to get better results. Pinging @JPxG who has a lot of experience in this area. — Qwerfjkltalk 19:37, 16 January 2024 (UTC)Reply[reply]
WMF
RfC to issue a non-binding resolution to the Wikimedia Foundation
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
Consensus for Wikipedia: Village pump to issue non-binding resolution for all three sections, especially #3: Increased support for internal needs. Onetwothreeip (talk) 04:00, 24 December 2023 (UTC)Reply[reply]
Should the English Wikipedia issue the following non-binding resolutions to the Wikimedia Foundation?
Each of the resolutions has its own section for !votes and discussion:
Grants to organizations intending to be active on the English Wikipedia
The English Wikipedia community is concerned about the distribution of grants related to activity on the English Wikipedia that will either not contribute to our goals of building an encyclopedia or will actively hinder those goals. We request that the Wikimedia Foundation informs the English Wikipedia of all non-trivial grants that will result in activity on the English Wikipedia through the opening of a discussion at the Village Pump (WMF) prior to the grant being issued.
Grants to organizations unrelated to supporting Wikimedia Projects
The English Wikipedia community is concerned that the Wikimedia Foundation has found itself engaged in mission creep, and that this has resulted in funds that donors provided in the belief that they would support Wikimedia Projects being allocated to unrelated external organizations, despite urgent need for those funds to address internal deficiencies. We request that the Wikimedia Foundation reappropriates all money remaining in the Knowledge Equity Fund, and we request that prior to making non-trivial grants that a reasonable individual could consider unrelated to supporting Wikimedia Projects that the Foundation seeks approval from the community.
Increased support for internal needs
The English Wikipedia community is concerned that the Wikimedia Foundation has neglected critical areas of the project, and that continued neglect of these areas may endanger the project. To improve the resilience of the project, we request that money be reallocated to hiring more technical staff, whose role will be to fulfill requests from the community such as those expressed on the Community Wishlist, as well as restoring access to tools such as grapher extension. To improve knowledge equity we also request that that the Foundation provides funding to assist established editors in accessing the resources they need
to improve the encyclopedia, such as by increasing the number of libraries accessible through the Wikipedia Library and by giving micro-grants for the purchase of backlogged items at Resource Request.
Related discussions
There are three related discussions that editors involved in this may be interested in; they are listed here.
Community Response
Grants to organizations intending to be active on the English Wikipedia (Community Response)
The English Wikipedia community is concerned about the distribution of grants related to activity on the English Wikipedia that will either not contribute to our goals of building an encyclopedia or will actively hinder those goals. We request that the Wikimedia Foundation informs the English Wikipedia of all non-trivial grants that will result in activity on the English Wikipedia through the opening of a discussion at the Village Pump (WMF) prior to the grant being issued.
Grants to organizations intending to be active on the English Wikipedia (Survey)
Support (Grants to organizations intending to be active on the English Wikipedia)
There have been many issues over the years where groups have been funded by the WMF to engage in activities on the English Wikipedia, only for the activity to be actively harmful to our project by providing no benefit and resulting in our volunteers having to spend time cleaning up the resulting mess. Often, this result can be reasonably predicted, as it could have been with the Deforestation in Nigeria project, if only the WMF had actively sought our input; hopefully this resolution will convince them to do so. BilledMammal (talk) 01:01, 3 October 2023 (UTC)Reply[reply]
As someone unfamiliar, what happened with the Deforestation in Nigeria project?—Ineffablebookkeeper (talk) ({{ping}} me!) 12:09, 3 October 2023 (UTC)Reply[reply]
The Wikimedia Community, and not the Wikimedia Foundation, governs the Wikimedia Movement. When donors give money to Wikipedia, they give it to the Wikimedia Community and not the Wikimedia Foundation. It is essential that money go to support the Wikimedia Community, its culture, and its values. With increasing regularity and forcefulness, the values and ethics of the Wikimedia Foundation are contrary to those of the Wikimedia Community. Bluerasberry (talk) 14:25, 3 October 2023 (UTC)Reply[reply]
Support as amended. Some initiatives seem to be about experimenting with editing privileges as a classroom tool rather than improving Wikipedia, and that's not where these grants should go. Certes (talk) 14:32, 3 October 2023 (UTC)Reply[reply]
Support as amended. Notifying us ahead of time when a grant recipient's activities are expected to affect this project will allow people to help them course correct in the early stages if lack of competence appears to be an issue, rather than waiting for it to be discovered organically once it has already become a problem. The tighter feedback loop should result in better articles, less discouragement from the grant recipients, more competent new editors, and decreased frustration from en.wp editors. The increased transparency may reduce ill will between this project and the Foundation. Folly Mox (talk) 14:58, 3 October 2023 (UTC)Reply[reply]
Support with the amendment made. The community should be emphasizing *what* the community wants to happen. Exactly how to make that happen is a separate issue and I think statements like this should be distilled to the key element(s). CoffeeCrumbs (talk) 15:08, 3 October 2023 (UTC)Reply[reply]
Support. The language requires the WMF to inform the community, it doesn't say the community has to approve the grant. "Non-trivial" should be defined later as some dollar threshold, so there will be large grants and small grants, and the WMF should be required to inform enwiki whenever it is considering a large grant that will affect enwiki. I for one would like to know about large grants being considered without having to read through every grant application on meta. I've been surprised at how many grants are in the tens of thousands, hundreds of thousands, or millions of dollars. This would be very easy for the WMF to comply with, and I don't see any downside. Levivich (talk) 16:59, 3 October 2023 (UTC)Reply[reply]
Support. The fairly recent case of Nigerian deforestation articles springs to mind and asks serious questions about the ability of the WMF to allocate grants. More attention is needed here. Willbb234 20:34, 3 October 2023 (UTC)Reply[reply]
Support as amended. Would be good to define "non-trivial" for clarity. Espresso Addict (talk) 21:03, 3 October 2023 (UTC)Reply[reply]
Support, but I don't think that the notification necessarily has to be a discussion (alternatively it could simply be a post), and I'd be fine with any discussion ocurring on metawiki. It'd create less work for the folks that review grants and less places to monitor. As for the merits of notification, enwiki might often know more about the state of the wiki than grant approvers when a grant largely concerns enwiki (in my opinion should be determined at reviewer discretion), so I think that it makes sense to notify enwiki as a courtesy. —Danre98(talk^contribs) 02:59, 4 October 2023 (UTC)Reply[reply]
Support. This isn't even asking for veto power, just "Hey, if a grant you're giving is likely to have a substantial impact on the English Wikipedia, please give us a heads up beforehand." I do not think that is an unreasonable request. SeraphimbladeTalk to me 03:06, 4 October 2023 (UTC)Reply[reply]
This seems like a good step toward transparency and harm reduction. —siroχo 03:45, 4 October 2023 (UTC)Reply[reply]
Reviewing grant applications and judging a project's likely impact on content are two tasks that require different skill sets. Perhaps it would help if grant applicants without an established track record as Wikipedians submit some samples of work to the editor community before being awarded tens of thousands of dollars. AndreasJN466 11:43, 5 October 2023 (UTC)Reply[reply]
Support, now that the problematic lines in the statement have been removed. – SD0001 (talk) 16:30, 5 October 2023 (UTC)Reply[reply]
Support: there are far too many situations where unpaid volunteers are cleaning up the mess left by paid agents. It is one thing for this to be for-profit COI editing but entirely another for it to be grant money coming from reader donations. We are the best placed to judge whether an idea fits en.wiki. Creating new articles will rarely be an appropriate task for newcomers. Some absolutely shocking grant approvals show the process has no oversight by anyone with a clue. — Bilorv (talk) 20:59, 6 October 2023 (UTC)Reply[reply]
Support I think it is actually totally reasonable to say "please let us know if you are going to give money to an organization that is going to edit on Wikipedia so that we can have oversight and guidance". Introducing grant money has the power to overwhelm the abilities of even a project as large English Wikipedia to clean up errors and problems. We should at least be able to know when a project is going to start. Steven Walling • talk 02:16, 7 October 2023 (UTC)Reply[reply]
Support. I don't even mainly edit in enwp but I am looking forward of this kind of initiatives from the community and whether we can apply it outside of enwp. RXerself (talk) 16:15, 11 October 2023 (UTC)Reply[reply]
Support as a way to increase transparency and community involvement. DFlhb (talk) 12:25, 12 October 2023 (UTC)Reply[reply]
Support many of these grants are poorly designed and allocated, resulting in waste of money and damage to the project --Ita140188 (talk) 18:58, 13 October 2023 (UTC)Reply[reply]
Support No-brainer. A mild version to just inform. North8000 (talk) 19:26, 13 October 2023 (UTC)Reply[reply]
Support. The WMF is not a generic "make things better-er" charity. Mebigrouxboy (talk) 23:45, 22 October 2023 (UTC)Reply[reply]
Support I'm amazed this isn't being done already; giving money to something that creates un-helpful articles here that we have to deal with seems counter-intuitive. Oaktree b (talk) 15:42, 23 October 2023 (UTC)Reply[reply]
Support. If money is given in the promise of activity in English Wikipedia a notification should be a common sense approach. The community would gladly assist the organizations receiving the grant, but the community also should have the right to scrutinize "paid" activities going on in their wiki. ✠ SunDawn ✠(contact) 03:05, 25 October 2023 (UTC)Reply[reply]
Support Grants should go to organizations aiming to actually help the project, or at least not add more work for volunteers to repair it behind them. In any case, transparency over the goals and intended actions of such organizations receiving grants is more than welcome. ChaotıċEnby(t · c) 02:41, 27 November 2023 (UTC)Reply[reply]
Oppose (Grants to organizations intending to be active on the English Wikipedia)
Too vague to be useful and doesn't respect the autonomy of other projects. What does "non-trivial" mean? What does "active on the English Wikipedia" mean? While I can imagine what they might reasonably mean, if we're going to support a resolution that we hope will be implemented, we need to provide actual metrics against which we can evaluate compliance. Presumably the resolution intends that non-rapid fund grants made for activities that will result in edits directly on EnWiki seek feedback from the EnWiki community. It could also mean something else (allocations over a particular dollar amount, for example, or organizations doing specific kinds of activities). The risk is we pass this because we all imagine some shared understanding when no shared meaning exists, and then when the WMF does what it thinks we mean the false consensus is laid bare as more backlash ensues. Further, the proposal could amount to an EnWiki veto over what occurs on other projects should a grant cover multiple projects (like Commons or Wiktionary). We could say that the WMF should do the same for those projects too, but if every project impacted by a grant gets its own on-project discussion and potential veto, we now have potentially hundreds of consultations to be managed being tracked across multiple projects and threads. That's why these kinds of discussions on grants already take place on Meta, the wiki for cross-project coordination. Of course, communication as to what's happening on meta could be improved such as when I and others added a dedicated "Meta" section to CENT to raise awareness of important discussion on that wiki, but the "here to build an encyclopedia" argument cuts both ways: EnWiki is for building an encyclopedia, not grant administration. I agree with (what I imagine to be) the sentiment, but as a resolution I think it is too loose. — Wug·a·po·des 02:23, 3 October 2023 (UTC)Reply[reply]
I appreciate the amendment as it addressed a main concern. I'll take some time to consider how I feel about the remaining vagueness but for the moment consider me somewhere between neutral and weak opposition. — Wug·a·po·des 23:49, 3 October 2023 (UTC)Reply[reply]
Editor attention is already spread thin among so many (too many) Foundation initatives. Spreading thinner the attention of foundation minded editors further concerns me. The foundation needs to be competent in making grants and to the exten that it's not, that high level problem at the macro level is what needs solving, not micro level feedback. Best, Barkeep49 (talk) 03:42, 3 October 2023 (UTC)Reply[reply]
Regarding Editor attention is already spread thin among so many (too many) Foundation initatives. Spreading thinner the attention of foundation minded editors further concerns me.: My hope, by having them inform us rather than expecting us to watch metawiki and inform ourselves, is that we will make it easier for editors to engage with these sorts of issues and thus increase the number of editors willing to do so. BilledMammal (talk) 07:38, 3 October 2023 (UTC)Reply[reply]
I understand. My preference would be that volunteers help the Foundation setup productive systems that do not require constant wide spread volunteer oversight. Grantmaking is a time consuming activity and I'd be happy to let paid people spend the lions share of the time on it. Best, Barkeep49 (talk) 12:52, 3 October 2023 (UTC)Reply[reply]
Oh dear. Please take a good look at all the formal groups that exist in the movement today - roughly 180 of them, at least half of which will directly or indirectly contribute to English Wikipedia. (Don't forget, almost all of these groups do or can participate formally in discussing global policies and processes that will affect our project; and those supporting international events, as well as MediaWiki, Commons and Wikidata, certainly have a trickle-down effect.) And that doesn't count informal groups, "recognized" groups that aren't affiliates, and individual volunteers. Oh, and hubs - which are deliberately intended to involve multiple groups focused on particular topics. If people want to get stuck into reviewing grant applications, they should go over to Meta, volunteer their time and energy, and do it. They're always looking for volunteers. Oh, and incidentally, deforestation in Nigeria is a real thing.[31]Risker (talk) 04:09, 3 October 2023 (UTC) (Adding parenthetically that there are multiple Wikipedias edited by Nigerian Wikipedians; just because there's an article in English - one that has lots of tags on it - doesn't mean there is a parallel article in other local languages. This isn't just an English Wikipedia issue. Risker (talk) 04:44, 3 October 2023 (UTC) )Reply[reply]
@Risker: Regarding your parenthetical comment about Nigerian Wikipedians working in many languages, note that the Task List for the $20,000 Deforestation in Nigeria project only mentions English Wikipedia articles. The first draft of the grant application did mention Igbo articles in addition to English, but the references to Igbo article work were first reduced in scale and then deleted altogether: [32], [33]. AndreasJN466 11:28, 5 October 2023 (UTC)Reply[reply]
Also, I think reviewing grant applications and judging a project's likely impact (positive or negative) on Wikipedia content quality require different skill sets. (Of course, the latter is always difficult without a work sample supplied beforehand, or an established track record of article work.) AndreasJN466 11:36, 5 October 2023 (UTC)Reply[reply]
Per Wugapodes and Risker, with more comments to follow. KevinL (aka L235·t·c) 04:15, 3 October 2023 (UTC)Reply[reply]
We can and should tell the Foundation that they need to rethink the broad direction they're taking on grants. But in no way should EnWiki, or for that matter any community, become the grant overlords. We are hardly qualified to give individual level feedback on grants. There is a reason we have the board and a foundation. Wikipedia's community governance works great at creating an encyclopedia, but it does not do great at managing money. We can effect grant reform without having to become grant reviewers. CaptainEekEdits Ho Cap'n!⚓ 05:07, 3 October 2023 (UTC)Reply[reply]
Per Wugapodes, Risker and CaptainEek. Thryduulf (talk) 08:07, 3 October 2023 (UTC)Reply[reply]
The amended version is considerably less bad than the previous version, but I'm still not convinced this is a direction we should be going in. Thryduulf (talk) 16:52, 3 October 2023 (UTC)Reply[reply]
This sounds vague and appears to ask for an enwiki veto of what happens on other projects. I'm not convinced there isn't a problem here, as the deforestation issue highlights, and the WMF should have some introspection of that happened. But I don't believe the current suggest is the right way to go. -- LCU ActivelyDisinterested∆transmissions∆ °co-ords° 21:18, 3 October 2023 (UTC)Reply[reply]
I won't repeat the points made so well by others but I want to note that if we deleted the second paragraph and the last sentence of the first paragraph, then I'd certainly "support", and I think others might too. This having been done, I'll move to support.—S MarshallT/C 08:34, 3 October 2023 (UTC)Reply[reply]
Oppose per Risker. You want to review grants, nobody is stopping you. Also the non-neutral wording declares matters of opinion as matters of fact, enough to oppose on this basis alone. Gamaliel (talk) 23:08, 3 October 2023 (UTC)Reply[reply]
Per the very good comments above, with special mention to Barkeep49 and CaptainEek regarding the competencies (and lack of) of our community-governance system here. There have been many expressed concerns with the grant system, but I am unsure how this proposal would move assist much with them. CMD (talk) 03:21, 4 October 2023 (UTC)Reply[reply]
Oppose. Review of grants should be done through meta. However, it may be good to compile a rolling list of grants that may generate content for enwiki for editors here for ease of tracking related updates. Through this list, we can potentially see if there is an overall benefit or negative outcomes from the grants and then see how such grants can be processed or advised in the future. How it is to be done can be explored further if there's support for this consideration instead. – robertsky (talk) 08:34, 4 October 2023 (UTC)Reply[reply]
Per most of the above. Badly worded and likely impossible to implement. Not a solution to the issues given as examples. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:39, 4 October 2023 (UTC)Reply[reply]
The revised proposal moved me from a clear oppose to being on the fence. This is one where other opinions have influenced my perspective, so I weakly oppose mainly per Risker, but also Barkeep, Eek, and Wugapodes. — Rhododendritestalk \\ 18:59, 4 October 2023 (UTC)Reply[reply]
Grants can already be reviewed. Meta is the place for it, not here. Hawkeye7(discuss) 20:27, 4 October 2023 (UTC)Reply[reply]
Mine is a weak support, given the "non-binding resolution" nature of the proposal and the fact that I don't think it hurts to remind the WMF that grants which could impact the on-project conduct of parties, be they regular editors or not, are worth special consideration and have a special level of interest to this community. That said, I'm pushed to a formal oppose based on 1) the fact that the specific proposal here still strays a little into miscasting the community's position to oversight the foundation's financial and administrative decisions in such areas and, 2) the fact that despite this relationships, the Foundation already has more than abundant transparency on such matters through Meta. A better outcome here would be a push to make more editors conversant in broader Wikimedia movement processes and procedures. SnowRise let's rap 21:32, 4 October 2023 (UTC)Reply[reply]
Weakly mostly on two items: 1) Wugapodes' objection over imprecision, and 2) that I think any discussion should continue where it has been, which is Meta, rather than here (i.e. that it should be a notification only here). I think this is otherwise supportable and to be fair is something that could/should be done for every wiki which might be affected by grants work. Izno (talk) 22:45, 4 October 2023 (UTC)Reply[reply]
While it may not literally be written to enable that, the "opening of a discussion" over a new grant would become an avenue to propose revoking that grant, and I don't think it's our place to do that, both in principle and from an official standpoint. RunningTiger123 (talk) 02:54, 8 October 2023 (UTC)Reply[reply]
There is already a process for this. Curbon7 (talk) 02:26, 25 November 2023 (UTC)Reply[reply]
Grants to organizations intending to be active on the English Wikipedia (Discussion)
Comment. Not opposed to this, but it feels like a bit of a sledgehammer–nut response targeted at the single (awful) grant. Would prefer a longer list of grants falling under the education programme, and elsewhere, that have resulted in clear harm to the encyclopedia. Espresso Addict (talk) 01:56, 3 October 2023 (UTC)Reply[reply]
I don't have a list on hand, but the most common time for it to occur is when the WMF gives a group funds that they use as monetary prizes for editing; for example, Wikipedia Pages Wanting Photos in past years, although it is no longer an issue as it no longer offers monetary prizes. BilledMammal (talk) 02:19, 3 October 2023 (UTC)Reply[reply]
While I would love it if the WMF did apply this to other projects I didn't feel it would be appropriate for us to ask the WMF to do so without the consent of those Wiki's. BilledMammal (talk) 02:16, 3 October 2023 (UTC)Reply[reply]
Question what does it mean by non-trivial sum? Fresh from organising Wikimania 2023, of which I had a direct hand in operationalising Wiki Loves Living Heritage Singapore 2023, would the sponsored prizes there (offhandedly, not more than 10,000 USD) be counted if it was funded by the Foundation? Of it, it generated 1,180 new images, many are of certain quality that can be used on the articles here. How low do we consider as trivia? This also raises the question of grants that are given that on surface seemingly does not affect enwiki directly, but in reality is. Do we want to or should we be policing those as well? – robertsky (talk) 03:21, 3 October 2023 (UTC)Reply[reply]
@Robertsky Side note. As far as I can tell, WMF does not even support any community requests for funding under 500 USD (rapid grant minimum). If I am wrong, I'd appreciate a link. IMHO 500 USD plus is non-trivial, considering global scale of our project (it is more tham mimimum monthly income in some poor places). Piotr Konieczny aka Prokonsul Piotrus| reply here 05:52, 3 October 2023 (UTC)Reply[reply]
Defining "non-trivial" seems in the cards. I do not know how many grants would usefully be reviewed though if that number is any higher than the floor, since I suspect it is the smaller grants that have an outsized influence on the volunteers here. Pizza for a badly-planned editathon seems more likely to disrupt than most other kinds of grants. Izno (talk) 19:56, 3 October 2023 (UTC)Reply[reply]
Comment. I'd support something closer to For any WMF-funded activity that is determined to have had a net negative effect on the English Wikipedia, the WMF will pay an equivalent amount for contract labour to slay backlogs of the community's choosing. I know, I know: who defines and decides "net negative"? It's just a dream. Folly Mox (talk) 03:31, 3 October 2023 (UTC)Reply[reply]
Comment I think there's a resolution to be made here, but needs to be more specific in light of the oppose comments. I would leave out the part which says "and does not proceed with the grant if the English Wikipedia is not convinced of its utility." The foundation should certainly evaluate our comments, but the final decisions should be up to it. Also, this needs to be more narrowly focused on projects which seek to directly affect the content on English Wikipedia. – SD0001 (talk) 08:15, 3 October 2023 (UTC)Reply[reply]
Because the original wording didn't appear to have the broad community backing we need for the WMF to take these resolutions onboard; I'm hoping this wording will be more palatable. BilledMammal (talk) 10:38, 3 October 2023 (UTC)Reply[reply]
You haven't changed anything that would change my opinion. If people want to get involved in grants, they need to get directly involved. It is incredibly disrespectful to the volunteers who work so hard to analyse grant requests to suggest that *one* community gets veto rights on their carefully considered and nuanced decisions, many of which affect multiple projects. I would suggest that authors of these proposals (I know it wasn't just you, BilledMammal, you're just taking the brunt of the responses) actually spend the time to talk to people involved in grant review and analysis, and perhaps actually try to assist in grant review and analysis, before saying that (a dozen or so people from) a project should be able to essentially veto a grant. Please walk a mile in those shoes. This is WP:IDONTLIKEIT on a global scale. Risker (talk) 19:12, 3 October 2023 (UTC)Reply[reply]
I don't see a veto here now post-change, I see a required notification so that users who might be interested in specific proposals can indeed actually try to assist in grant review and analysis. If the grants at that point are vetoed by review of interested users from here, that would seem to say more about the utility of the grant than not. The clearly detrimental Deforestation project (and others before it!) should not have been approved and review by en.wp users would likely have identified issues with that grant immediately.
I have a remaining concern that this could be used to detrimental effect for grants which do not per se target en.wp. For example, the "Deforestation" project was clearly (or perhaps not clearly) intended to be done as work targeting en.wp, and it is this kind of grant I think a notification would be good for. It feels like a miss to notify about a general grant to improve software affecting multiple wikis or multi-wiki coverage of material but not intending to focus on en.wp or even substantially contribute here. Can this framing be tightened? Izno (talk) 19:54, 3 October 2023 (UTC)Reply[reply]
Sorry Izno, I missed this. That was a fair request, but I think it is a little too late now - however, my personal perspective is that a software project wouldn't result in activity on enwiki, even if it would affect enwiki, and thus notification wouldn't be required. BilledMammal (talk) 01:12, 16 October 2023 (UTC)Reply[reply]
Where does this proposal "suggest that *one* community gets veto rights"? Please, let's not spread misinformation. Levivich (talk) 19:54, 3 October 2023 (UTC)Reply[reply]
Comment. Hi everyone, Yael here, VP of Community Growth at WMF, which is a sub-team within Advancement that includes the Community Resources team, responsible for grants distribution. I’m seeing two (and-a-half) interconnected issues in this RfC, and I’m happy to speak to each of them: 1) Funding activity on EnWP that is not intended to contribute to our goals of building an encyclopedia; 1a) A specific comment about a grant on deforestation in Nigeria, which is used as an example of either non-encyclopedic content or an active hindering of that goal. And 2) How WMF communicates with EnWP about grants that will result in activity on EnWP. Regarding #1: The grants we make through our Community Resources team are intended to support the Wikimedia community to contribute to our collective goal of increasing encyclopedic content. I am in complete alignment with the spirit of this RfC - that grants should contribute to this goal, and that they should be of a high enough quality that they don’t make work of en-Wiki editors more difficult. Sometimes people disagree with what is encyclopedic content, but we trust that the Wiki projects make those decisions themselves; thankfully, it’s rare that content directly supported by grants is added to any of the Wikis that is counter to this objective. Sometimes, we make funding mistakes or the grants don’t go as we had hoped. That’s what happened with the specific grant referenced re: deforestation in Nigeria. As others have mentioned, this is a topic that many believe should be on Wikipedia. Unfortunately, the quality of the article didn’t live up to en-Wiki standards and as a result caused EnWP admins more work. I genuinely apologize for that. There’s a lot we’ve learned from this grant portfolio (you can see the full proposals, both those funded and not, on Meta here). I won’t go into detail here, as I’m trying to respond to the main point of the RfC. In short, this grant came from a pool of funding that did not go through our Regional Funds Committee community review process, and we’ve since sunsetted that pool of funding. We are now sending all applicants from The Organizer Lab to the Rapid Grants program, which has both a lower cap in funding and is reviewed by the Regional Funds Committees. Regarding #2: Current practice is that all proposals are publicly available on Meta for community input. We rarely see much engagement there, but community members are welcome to engage and their comments will be considered and reviewed by the Regional Fund Committees, which are made up of community volunteers. We also ask all grantees to describe to what extent they’ve engaged with their relevant Wiki communities in drafting the proposal; I acknowledge that some do this more than others and we’re reliant on their self-attestation to this. Given that Meta can be hard to navigate, and that many EnWP members are more active on the Village Pump, the request to share information there is a fair one. Community Resources can commit to sending out an announcement on all Village Pumps (not just EnWP), when the funding round is open and proposals are open for Community input. This announcement will link to Meta, where the proposals are posted for comment. Ultimately, Regional Fund Committees make the final recommendations on funding, but they take community input, which can be done directly on the Meta pages associated with the proposals. Finally, I’m open to learning what other communication channels would be helpful (e.g., a Wikimedia-l announcement?) when each funding round is open. On a personal note, I welcome requests and feedback particularly on relatively solvable asks like this. I respect that RfCs are important to EnWP for community alignment, but you are welcome to also just send concerns like this directly to the Community Resources team or to me. We genuinely love solving solvable problems. RWeissburg (WMF) (talk) 17:40, 13 October 2023 (UTC)Reply[reply]
RWeissburg (WMF), that doesn't solve the core problem. Have a look at WP:THEYCANTHEARYOU. That should have been treated as an emergency blocker-level bug. Yet, years after reporting, it still is not addressed. We need editors to be notified consistently if we leave a message on their talk page, and for that to be dead obvious in the interface. If the "mobile app" does not or cannot support that, get rid of it, and ask people to use a browser to access the website, which they should be doing anyway (no website should have an "app" to access it; the "app" to access a website is a browser). But if you must have an "app", make sure it functions completely correctly, including letting the user know, in no uncertain terms, when someone has left them a talk page message. SeraphimbladeTalk to me 04:48, 22 October 2023 (UTC)Reply[reply]
Hi @Seraphimblade - I think maybe your comment is intended for the third topic: "Increased Support for Internal Needs"? @JTanner (WMF) has responded on that topic below. 75.104.108.53 (talk) 16:04, 23 November 2023 (UTC)Reply[reply]
My apologies - that comment above is from me; I had accidentally been logged out. - Yael RWeissburg (WMF) (talk) 16:05, 23 November 2023 (UTC)Reply[reply]
I don't understand what this proposal actually entails. m:Grants shows there are many different processes. Occasionally there can be dozens of grant requests for projects which may produce edits on the English Wikipedia. Does this proposal ask for more granular links pointing out each individual proposal in its own section on the village pump, or what? Nemo 14:01, 28 October 2023 (UTC)Reply[reply]
Grants to organizations unrelated to supporting Wikimedia Projects (Community Response)
The English Wikipedia community is concerned that the Wikimedia Foundation has found itself engaged in mission creep, and that this has resulted in funds that donors provided in the belief that they would support Wikimedia Projects being allocated to unrelated external organizations, despite urgent need for those funds to address internal deficiencies. We request that the Wikimedia Foundation reappropriates all money remaining in the Knowledge Equity Fund, and we request that prior to making non-trivial grants that a reasonable individual could consider unrelated to supporting Wikimedia Projects that the Foundation seeks approval from the community.
Grants to organizations unrelated to supporting Wikimedia Projects (Survey)
Support (Grants to organizations unrelated to supporting Wikimedia Projects)
In most cases it will not be appropriate for the WMF to provide funds to organizations unrelated to supporting Wikimedia Projects; our donors gave money to support the projects and we should respect that. Rare exceptions may occur, but in such circumstances broad oversight from the community should be sought, to ensure that the grant is appropriate and that it will not damage our image by causing the public to believe that we are becoming a partisan entity. BilledMammal (talk) 01:01, 3 October 2023 (UTC)Reply[reply]
As I've said in the past, soliciting donations for one cause and then handing them off to a different cause is in effect the same thing as a scam. 100% of funding collected by the WMF should go into supporting the various editions of Wikipedia and its sister projects or to keeping the WMF operating as an organization that facilitates these projects. Thebiguglyalien (talk) 03:07, 3 October 2023 (UTC)Reply[reply]
Frankly, I'd find it astonishing that this needed to be said, if it wasn't for the evidence that it clearly does. AndyTheGrump (talk) 03:11, 3 October 2023 (UTC)Reply[reply]
WMF solicited donations using disingenuous messaging like "Wikipedia is not for sale" and is transferring not-insignificant amounts of such funds to goals that have nothing to do with Wikipedia or with any of its sister projects. That is morally dubious at best and fraud at worst. It needs to stop. Ciridae (talk) 05:57, 3 October 2023 (UTC)Reply[reply]
The money needs to be used for the purposes the donors expected it to be used for. If donors were told they were paying to keep the lights on and the servers running, and they were, then it's unethical and duplicitous to spend it on advocacy think-tanks. Also, Wikipedia has a reputation for neutrality that was very hard-won and will be very easily-lost. Don't squander it please. Spending donors' money on advocacy groups is reckless and risks our core mission. I can envisage headlines about "Wikipedia applies political pressure" on a slow news day and I think that would be a catastrophic outcome.—S MarshallT/C 08:42, 3 October 2023 (UTC)Reply[reply]
Money raised for Wikipedia should stay for Wikipedia. As I said elsewhere, $200K USD for a non-profit organization based in Indonesia that works on human rights and advocacy issues for indigenous people is a nice plan, but not related to the project in any way. Edward-Woodrow • talk 12:21, 3 October 2023 (UTC)Reply[reply]
If I may, While I understand the concerns regarding the allocation of funds by the Wikimedia Foundation, it's important to remember the wisdom in the quote, 'It's not right to take the children's food and throw it to the dogs.' In this context, the children represent Wikimedia Projects, and the dogs represent unrelated external organizations. It's crucial that funds donated for supporting Wikimedia Projects are prioritized for their intended purpose. Therefore, I wholeheartedly support the request for the Wikimedia Foundation to reappropriate any remaining money in the Knowledge Equity Fund and seek community approval before making grants that may appear unrelated to supporting Wikimedia Projects. This approach aligns with the principle of responsible fund allocation. Icem4k (talk) 14:25, 3 October 2023 (UTC)Reply[reply]
Support, in the interests of honesty and transparency. Certes (talk) 14:26, 3 October 2023 (UTC)Reply[reply]
The Wikimedia Community, and not the Wikimedia Foundation, governs the Wikimedia Movement. When donors give money to Wikipedia, they give it to the Wikimedia Community and not the Wikimedia Foundation. It is essential that money go to support the Wikimedia Community, its culture, and its values. With increasing regularity and forcefulness, the values and ethics of the Wikimedia Foundation are contrary to those of the Wikimedia Community. Bluerasberry (talk) 14:25, 3 October 2023 (UTC)Reply[reply]
Support, per S Marshall's points. The bait-and-switch of WMF fundraising has gone on far enough. Even if used for other good things, it's important to be honest about what money donated will be used for. People who provide financial support deserve that honesty, yet we have this yearly débâcle in which we have banners that suggest that donated money will be used for something that's only a small portion of the budget. CoffeeCrumbs (talk) 15:06, 3 October 2023 (UTC)Reply[reply]
For many years, the WMF has been spending way too much money on non-editing improvements (like trying to solve the root causes of systemic bias or knowledge inequity) and too little money on editing improvements (like upgrading Visual Editor, or the graphs extension). This needs to stop. They need to spend the donations primarily on hardware and software development and maintenance; only when those needs are met should they even consider spending the donations on anything else, and those needs are not met and never have been. Levivich (talk) 17:03, 3 October 2023 (UTC)Reply[reply]
Strong support. I believe donors are misguided on where their money will end up. Giving money to other organisations is a big no and I can't believe this has been going on for so long. Willbb234 20:41, 3 October 2023 (UTC)Reply[reply]
Donors expect the WMF to spend money on WMF projects and goals, not to be a general-purpose grant making group --In actu (Guerillero)Parlez Moi 11:11, 4 October 2023 (UTC)Reply[reply]
Support. Our donation money should be spent at home, not on third party causes that have minimal or no inter-relation with Wikimedia. Reminding the WMF of this is appropriate. I am a bit surprised at the quantity of opposes. Perhaps this RFC should have been simplified to "The English Wikipedia opposes spending donor money on causes not closely related to Wikimedia, and is deeply concerned about the Knowledge Equity Fund." –Novem Linguae (talk) 07:54, 5 October 2023 (UTC)Reply[reply]
Support. I think the idea of rephrasing this per User:Novem Linguae's suggestion (or by simply cutting the second sentence) has merit. We do not really want to micromanage these grants, nor are we properly equipped for it. We want the WMF to get the message – a message that a good number of opposers appear to agree with. --AndreasJN466 18:17, 5 October 2023 (UTC)Reply[reply]
Support Novem Linguae's suggestion, with tentative support for the other wording. It's rather dishonest to advertise for donations on Wikipedia and then have that money go to something that's at best very remotely related to Wikipedia. 173.244.10.85 (talk) 15:03, 6 October 2023 (UTC)Reply[reply]
Support: readers who donate are largely unaware of what their donations are used for and external organisations is a big part of it. WMF mission creep exceeded ludicrous levels several years ago. Of course good things come from working with other organisations like Internet Archive, but the statement is that the WMF need to consult the community over such collaborations. — Bilorv (talk) 21:05, 6 October 2023 (UTC)Reply[reply]
I would prefer if "and we request that prior to making non-trivial grants that a reasonable individual could consider unrelated to supporting Wikimedia Projects that the Foundation seeks approval from the community." was removed but support the general principal. Jenks24 (talk) 17:24, 7 October 2023 (UTC)Reply[reply]
Support - funds raised by Wikimedia are understood (and advertised as such) to be used (and necessary) to run Wikipedia and associated projects, not third party organizations. --Ita140188 (talk) 13:56, 9 October 2023 (UTC)Reply[reply]
Support. While doing projects on knowledge equity itself is not inherently opposed to what we are doing in Wikipedia, the fund that was gathered by benefiting from the work of the community must be used to help the people inequity inside the community first. I would rather see a legal fund for editors in oppressive countries, or expand the coverage of The Wikipedia Library. RXerself (talk) 20:52, 11 October 2023 (UTC)Reply[reply]
Support. WMF funds should be for WMF projects, of which many are needed. Crossroads-talk- 21:55, 11 October 2023 (UTC)Reply[reply]
Support. The WMF has gone from the stewards of Wikipedia to a 'movement' in it's own right, and it is impeding Wikipedia's ability to be a reliable, high-quality encyclopedia. INeedOGVector (talk) 22:12, 12 October 2023 (UTC)Reply[reply]
Support A much needed reform. And ending deception of donors who largely are asked to donate to support Wikipedia and then transferring money to people and organizations unrelated to that. North8000 (talk) 19:30, 13 October 2023 (UTC)Reply[reply]
Support. The second part of the sentence could be just removed, since it is too prescriptive on implementation details. For example, simply removing the KEF would also be a good course of action. Anyway, I agree with the overall idea. MarioGom (talk) 07:51, 15 October 2023 (UTC)Reply[reply]
Strong Support - Money given to WMF is given out of an understanding that it is to uphold WP - Any deviation from this merits a discussion prior. Captain Jack Sparrow (talk) 20:57, 15 October 2023 (UTC)Reply[reply]
I think the specific wording could use a bit more workshopping, potentially after the RfC, but agree with the overall sentiment. (I prefer Novem Linguae's version.) Tol (talk | contribs) @ 15:38, 19 October 2023 (UTC)Reply[reply]
Strong Support Money given to WMF should be used for WMF. My time to edit Wikipedia (that strongly benefited WMF) should be used for WMF/Wikipedia, not for projects that are too far unrelated from the goals of Wikipedia. There are many good causes in this world - people should donate directly to those causes instead. WMF should be totally unbiased, and allowing money to flow out for "causes" can cause biases. ✠ SunDawn ✠(contact) 03:07, 25 October 2023 (UTC)Reply[reply]
Support - The mission creep has been harmful and means ever more requests for funding not actually required for the sites people think they are donating to tompagenet (talk) 13:17, 29 October 2023 (UTC)Reply[reply]
Support Fund the community's work, not things that aren't our mission. It's also not being straight with the donors.--Wehwalt (talk) 01:33, 1 November 2023 (UTC)Reply[reply]
Support The grants made should be related to Wikimedia projects. Strobilomyces (talk) 21:16, 5 November 2023 (UTC)Reply[reply]
Support. Knowledge equity can mean a lot of things, and the inequity continues in many non-English Wikipedias and most sister projects. These funds should be directed to WMF projects first as that was the donor's expectation. Yet when I see Knowledge Equity fund recipients don't contribute towards WMF projects at all despite having strong synergies (e.g. "Arab Reporters for Investigative Journalism" wrote 0 Wikinews article despite being an investigative journalism organization in their name and "Borealis Racial Equity in Journalism Fund" admitted in their report to WMF that they improved/wrote 0 articles and added 0 images.) Even a Wiki Edu classroom project has a bigger and meaningful impact towards an WMF project and at a far cheaper cost. As the Knowledge Equity fund currently stands, it needs to be reined in when projects are funded with so few strings attached. OhanaUnitedTalk page 06:10, 23 November 2023 (UTC)Reply[reply]
Support Grants made with the expectation of reaching Wikimedia projects should go to Wikimedia projects. ChaotıċEnby(t · c) 02:39, 27 November 2023 (UTC)Reply[reply]
Oppose (Grants to organizations unrelated to supporting Wikimedia Projects)
Knowledge equity and related issues, while not directly related to the projects, are crucial issues that are within the WMF's scope. Frostly (talk) 02:01, 3 October 2023 (UTC)Reply[reply]
This seems like an over-reaction to a poorly-communicated initiative; the WMF has conceded that it should have provided more information and explanation as to how funding these groups had the potential to expand available free knowledge that can be used in Wikimedia projects. Noting also that this is English Wikipedia, and should only include proposals that are specific to English Wikipedia. Those grants are at the global/meta level. Risker (talk) 04:19, 3 October 2023 (UTC)Reply[reply]
The first sentence is fine. The second sentence is way outside outside the English Wikipedia's area of competence. Thryduulf (talk) 08:09, 3 October 2023 (UTC)Reply[reply]
I'm especially opposed to demanding the money already allocated for the fund be returned, it seems unnecessary to me and risks stuff being killed off prematurely every time there's a change in leadership in ways we may not like. There seems to be agreement that the KEF is not going to be repeated, so while there are still going to be changes a gradual winding down based on existing decisions is far better than a sudden change. Do we really want when we finally get something we want funded only a year or two later it will be killed immediately just because new leadership no longer agrees? To be clear, I understand the money hasn't been allocated to any particular purpose yet, but it's still been allocated for the fund. I'm also deeply concerned that there is already a serious imbalance between the English Wikipedia and pretty much every other project (some a lot more than others) and while I don't think many or maybe even any other projects agree with the KEF, effectively we're demanding that the English wikipedia alone is able to dictate where money is not spent which is a major WTF. I'd also note that while the general idea may be laudable, it's actually a lot more complicated than that. I've looked at some of the projects and while they may not directly ensure project improvements, they may in the long term do so. It's well known that there is extensive systemic bias in the English Wikipedia and all projects are affected by this in varying ways. Improving access to education etc in places where it is limited increases the chances we will one day have editors from these areas able to contribute. It's clearly a very long term goal and the actual effect from some minor project is likely to be miniscule, so I don't actually think it's an effective way for the WMF to spend their money and would not encourage it but it also illustrates why a vague statement cannot really limit the WMF. I also consider the issue of insufficient funding for important projects separate issue. The WMF is not short on funds and it's clear that the reason why some important areas aren't getting sufficient attention isn't because they're spending all their money on stuff like KEF. This doesn't mean they should be spending the money on such things but it does mean it is unlikely doing this will achieve anything other than prematurely killing the KEF. Nil Einne (talk) 11:05, 3 October 2023 (UTC)Reply[reply]
meta:Knowledge Equity Fund clearly explains its relevance to the WMF's core mission: the fund is used to (emphasis added) support knowledge equity by addressing the racial inequities preventing access and participation in free knowledge. The English Wikipedia has struggled to address systemic bias from the beginning. It's a major problem and I'm glad the WMF is using some of its considerable financial resources to try tackling the root causes. You can't fix everything with editathons. – Joe (talk) 14:16, 3 October 2023 (UTC)Reply[reply]
It is very interesting and unfortunate that the wording of this part of the rfc equates "knowledge equity" with "non-trivial" activities. The self righteousness is not lost on me. I can only reiterate the sentiments on this oppose section. The zero-sum mindset herein is simply unhelpful. I am yet to hear real facts leveled against "the knowledge equity fund" that are worth talking about, other than "we need money to do stuff and we dont like this projetc, therefore stop it and give us the money". --Thuvack | talk 17:52, 3 October 2023 (UTC)Reply[reply]
I agree with Thryduulf here, although the first sentence is fine the second oversteps. Editors dissatisfaction with current spending shouldn't control specific details.-- LCU ActivelyDisinterested∆transmissions∆ °co-ords° 21:25, 3 October 2023 (UTC)Reply[reply]
I don't think having the English Wikipedia community approve all such grants individually is an effective use of either the WMF's or the community's time. The community should help set the objectives of these grants, so they can be filtered appropriately as part of the grant process. isaacl (talk) 23:32, 3 October 2023 (UTC)Reply[reply]
@Isaacl: Here "community" doesn't refer to enwiki, but the broader community - I was thinking through a securepoll vote (not, in my opinion, an unreasonable overhead when we are talking hundreds of thousands or millions of dollars), but other methods as determined by the WMF would also be appropriate. BilledMammal (talk) 03:41, 4 October 2023 (UTC)Reply[reply]
I have the same view regarding the effective use of the Wikimedia community's time. isaacl (talk) 04:00, 4 October 2023 (UTC)Reply[reply]
Ideally we shouldn't need to spend time on things like this, but unfortunately the WMF has demonstrated that they can't be trusted to act without oversight, through things like KEF and through other grants like POSTCARD which I discuss below (supporting Youtube and Instagram influencers). Personally I think the overhead can be kept to a minimal, such as by broad requests for approval (for example, rather than having voted on every grant proposed under the KEF, the community votes on the KEF itself), but reasonable minds may differ. BilledMammal (talk) 04:09, 4 October 2023 (UTC)Reply[reply]
It would be more effective to influence the setting of objectives and engage with the review process as necessary. isaacl (talk) 04:15, 4 October 2023 (UTC)Reply[reply]
While I suspect this will find some support, after some thought I find myself in the oppose column -- and for reasons not directly connected to the KEF. First, some background: This proposal began as a proposal to hold fundraising hostage unless the English Wikipedia got line-item veto power over all of the WMF's finances. That's been toned down quite a lot, but I can't get over the pervasive sense of English Wikipedia supremacy/exceptionalism running through all of the discussions up to this point. We are already the largest and most powerful of the projects. We already numerically dwarf everyone else. We already have most of our users in the richest countries on the planet. The idea that we deserve total financial power over the entire rest of the Wikimedia universe is shocking, and while that's not being proposed here, knowing that was the goal means I can't help but carry forward some skepticism here. I can fully appreciate that the idea of funding projects "unrelated" to Wikimedia projects is going to unite many people with a range of valid criticisms about how the WMF spends its money (i.e. "X feature or Y bug has been missing/broken for ages, but you're funding this?"). But the target of criticism here is something where the feedback has already led to a decision not to fund it again. What we're doing is deciding whether to adopt a general principle about "unrelated" projects using the KEF as an example, but never actually defining "unrelated". Others above have tried to explain the extent to which calling this "unrelated" is misleading. Wugapodes gives some good examples of other "unrelated" (but not actually unrelated) potential grantees. I'd add research into wikis in general, work on OpenStreetMap, research into linked data practices, funding for archives to digitize sources, and other kinds of projects that help us indirectly. And it's in that context that the KEF is indeed related. It's just not an edit-a-thon or Wikipedian-in-Residence. TL;DR - This might look like a referendum on the KEF, but it's actually a broadly worded principle with unclear implications. Given the background of these proposals, I have no reason not to think "unrelated" won't be treated as broadly as possible. — Rhododendritestalk \\ 00:49, 4 October 2023 (UTC)Reply[reply]
Per Thryduulf; that bit ought to originate from meta (if it's a good idea in the first place) and seems entitled coming from one wiki. In addition, Wugapodes brings up good concerns about wording. —Danre98(talk^contribs) 03:08, 4 October 2023 (UTC)Reply[reply]
Agree with the concerns raised above. Furthermore, even if the proposed method wasn't worded as vaguely as it is, handling individual grants through community vote seems an inherently poor idea, an inherent mismatch with our slow and fuzzy consensus system. CMD (talk) 03:17, 4 October 2023 (UTC)Reply[reply]
Per others. While I agree with the first sentence, the second feels like we're overstepping a bit. ARandomName123 (talk)Ping me! 06:32, 4 October 2023 (UTC)Reply[reply]
Per Rhododendrites above, and per Folly Mox and Wugapodes in the discussion section below. While the proposal's goals are understandable, the vague wording makes it impractical to actually enforce, the proposal would give enwp a disproportionate amount of power over other wikis, and I'm not convinced that a single-wiki RfC has the scope to enforce this change regardless. ModernDayTrilobite (talk • contribs) 15:59, 4 October 2023 (UTC)Reply[reply]
Not a good idea at all. And if this was a good idea, a "non-binding resolution" is not the way to go about it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:44, 4 October 2023 (UTC)Reply[reply]
This is far beyond our purview. I can envisage a speculative (if highly unlikely) scenario in which this project were so underfunded with regard to basic needs, relative to the amount of funds raised in relation to en.Wikipedia and donor intent that the en.Wikipedia community might need to make some noise to see more commitment to en.Wikipedia in the WMFs budget. But bluntly, we don't live in that reality or anything remotely like it. This project's needs are more than substantially enough met to justify our attempting to beackseat drive for the fiduciaries and professionals at the WMF on decisions that are well withing their legal and institutional discretion. A more generally worded appeal for a higher level of consultation/seeking feedback from the community might be something I can get behind, but this proposal (especially considering how it arose) is just presumptuous and way beyond the division of labour and authority as relates to WMF and movement finances. SnowRise let's rap 21:45, 4 October 2023 (UTC)Reply[reply]
we request that prior to making non-trivial grants that a reasonable individual could consider unrelated to supporting Wikimedia Projects that the Foundation seeks approval from the community. This is too vague to support. What is non-trivial? What counts as "approval" and how would it be solicited? Which community do you mean, as there are many of them beyond English Wikipedia? The WMF already tries to get community approval, but globally from all Wikimedians via Meta. The disconnect is that most editors don't show up to Meta and participate in grant reviews, but that work does in fact happen. I agree the WMF should work on encouraging more on-wiki connection between the grant review (which is actually conducted by volunteer committees in many cases, btw) and the editing communities, but this is not a clear enough proposed solution to take action on. Steven Walling • talk 15:31, 6 October 2023 (UTC)Reply[reply]
@Steven Walling: You said "too vague to support." What specific definitions of the terms "non-trivial," "approval," and "community" would cause you to support the proposal? Levivich (talk) 16:02, 6 October 2023 (UTC)Reply[reply]
This isn't my proposal so not really incumbent on me to fix it. It seems implied that the proposal actually means "The WMF should run a straw poll !vote on the Village Pump every time before they want to make a grant over [insert whatever arbitrary $ amount qualifies as non-trivial]". Really unclear if that's specifically what is meant though. In definition this vague, technically speaking the WMF already fulfills the requirements, because the entire grantmaking process on Meta is done transparently and mostly via volunteer committees. Steven Walling • talk 02:06, 7 October 2023 (UTC)Reply[reply]
If this proposal was only the first sentence – a reminder to spend money more wisely and prioritize the Wikimedia Community, in tandem with proposal 3 which I supported – I would certainly get behind that, but a targeted shot across the bow against the Knowledge Equity Fund, which I broadly agree with and would argue is quite valuable and important, is not something I can get behind. Curbon7 (talk) 19:20, 7 October 2023 (UTC)Reply[reply]
Rhododendrites brings up good points about how this seems to value too much authority over all Wikimedia projects with the English Wikipedia. As noted elsewhere, if there is a place for that authority, it's at meta with the global community. I also think WMF's support for groups outside the project is important – we need places to get our information from in the first place – and I can't shake the feeling this is a step towards stopping that. RunningTiger123 (talk) 03:03, 8 October 2023 (UTC)Reply[reply]
Rhododendrites and RT put it well. The proposal is poorly worded, misrepresents a particular community-overseen grant pool, asks to cancel that grant pool and for an impossibly vague en:wp veto over future grants, and misuses the trope of donor intent. It also implausibly suggests that grants earmarked during a year of surplus and amounting to under 1% of the WMF's program budget, are somehow preventing it from addressing unspecified "internal deficiencies". There are valid + uncontroversial points to be made for the Foundation to better align its prioritize with community needs... but this does not make any of those points, instead proposing to make a dubious statement on behalf of the whole community. No, thank you. – SJ + 04:21, 8 October 2023 (UTC)Reply[reply]
The original proposal is waaay to broad for me to support in any sensible fashion. The community has absolutely no remit in deciding to veto funding based on what is relevant to the movement (with enough wikilawyering, we would probably have consider recent funding for projects like Wikidata and WikiLamda (or allocation of money for Wikimania 2023) to have not directly support the movement and could have labelled them as mission creep). That being said, I would Support @Novem Linguae's rewording since it is short and succint and gets the point across without resorting to insinuations/effectively codifying a veto power for the en.wikipedia community and assumption of bad faith on the part of the Foundation. -- Sohom (talk) 12:51, 6 October 2023 (UTC)Reply[reply]
@Sohom Datta Judging by the content of your comment and your reference to Novem Linguae's rewording, I suspect you meant to oppose the proposal below this one, i.e. "Grants to organizations unrelated to supporting Wikimedia Projects (Community Response)". (Feel free to delete this comment either way.) Regards, AndreasJN466 16:24, 6 October 2023 (UTC)Reply[reply]
The purpose of WMF, as mandated by the founding documents, is the support of free knowledge. Maintaining Wikipedia is just one method to do so. Giving to other organizations working in the field of free knowledge is supported by this purpose. --h-stt!? 15:18, 23 October 2023 (UTC)Reply[reply]
As others have said, the second sentence goes too far. I also agree with others that the Knowledge Equity Fund is not obviously unrelated to Wikipedia's mission; we should instead push for greater transparency around the KEF. Suriname0 (talk) 22:24, 23 October 2023 (UTC)Reply[reply]
Grants to organizations unrelated to supporting Wikimedia Projects (Discussion)
So I guess my issue with this text is that the WMF does consult with the community about disbursement of Knowledge Equity Grants. See meta:Knowledge Equity Fund#The Knowledge Equity Fund Committee, which lists five volunteers alongside the six staffers.It's widely known that the Knowledge Equity Fund is pretty unpopular, and no one seems to have indicated it will recur after the third year of disbursements, which I guess we'll hear about on Friday. Someone on wikimedia-l or some other email thread compared these grants to basic research, like laying the groundwork for a more successful "free knowledge movement", which was a minority view but makes sense.The thing I suppose rubs me wrongest is that the goal here seems to be to stop giving these planned grants to marginalised groups, and spend it instead on English Wikipedia, the rich white dude of the Wikimedia Party Palace. Yes, that's not stated explicitly, but Resolution 3: Here's How to Spend Money on Us immediately follows. We don't not need Foundation money for staff to maintain technical debt, fix bugs, talk to us, etc., but it just feels... kinda gross? Please note this is a comment, not an oppose. Folly Mox (talk) 03:22, 3 October 2023 (UTC)Reply[reply]
Folly Mox, I think you hit the nail on the head with this comment. This proposal feels....entitled. Risker (talk) 07:29, 3 October 2023 (UTC)Reply[reply]
It is reasonable that many in the community feel entitled to see WMF budget used to support Wikimedia projects (not us, which sounds like anyone here is expecting to see a penny). Especially since that is what all fundraising messaging strongly implies. On seeing Wikimedia projects as the rich white dude... I couldn't disagree more. Some of us still see Wikimedia projects as a humanist mission that deserves full focus from the Foundation that was established to guarantee its continuity. MarioGom (talk) 17:48, 5 November 2023 (UTC)Reply[reply]
The WMF should be spending its money on improving WMF projects for readers, and on helping editors to make such improvements. No one suggests limiting the spending to wikipedias, or to English-language projects. (Spending on Chinese Wiktionary is fine, and probably doesn't benefit many rich white dudes.) Giving money to some external body to spend should require evidence that it will benefit WMF projects more than spending that money directly. Certes (talk) 18:47, 5 November 2023 (UTC)Reply[reply]
I think that's an important distinction. The WMF is certainly not "The English Wikipedia Foundation", and we of course must remember that. If WMF spends funds on, for example, helping a project in a less common language recruit editors and get off the ground, that is a totally valid use of those funds, because it is spent in direct support of the Wikimedia mission. But WMF is the Wikimedia Foundation, not the Fix-Everything-Everywhere Foundation. So it is reasonable to expect that when WMF spends its funds, it will be able to directly answer the question "What direct benefit is this expenditure expected to have toward the Wikimedia projects?". That doesn't have to be spent directly on the projects—if, for example, the WMF were to help start up a journal willing to do peer review and publication for articles in areas that are traditionally underrepresented in academic publications, that is of direct value to the Wikimedia projects by expanding the range of things we have enough high quality source material to write about, where before that we wouldn't. But it is then possible to say "Well, here's how this benefits Wikimedia." On the other hand, it seems that many of the things WMF is currently doing are in the realm of "That's a nice thing to do—but it seems out of scope for us to be doing it." SeraphimbladeTalk to me 19:50, 5 November 2023 (UTC)Reply[reply]
There seems to be a dichotomy between Wikimedia Projects and external orgs that I think misunderstands the relationship between our projects and the wider free knowledge movement. Creative Commons and the Internet Archive are external organizations which are mission aligned, and their success is directly relevant to the success of our projects. If they asked us for a grant would we tell them to kick bricks because it doesn't benefit our projects? A more specific example, I spent some time last year working with Cornell's copyright information center on a grant proposal to increase their staffing so that they could resume and increase their outreach work which our CCI group had found valuable but which had been cut due to university budgetary restrictions (it fell through in the planning stage, unfortunately). Would this resolution have prevented that kind of support for mission-aligned organizations? It wouldn't have been spent "on the projects", but the benefit of being a "good neighbor" and supporting groups who share our values and support our goals has knock-on effects that shouldn't be summarily dismissed. — Wug·a·po·des 00:19, 4 October 2023 (UTC)Reply[reply]
@Wugapodes: This purpose of this proposal isn't to stop grants going to entities that a reasonable individual could consider unrelated to supporting Wikimedia Projects; it's to give the broader community oversight of the process, because things like the KEF and other grants like POSTCARD, which are intended to support (I am not making this up) Instragram and Youtube influencers have shown that we cannot trust the judgement of the WMF in this matter.
If the WMF wanted to give $500,000 to Internet Archive or a similar project then I have no doubt that the community would approve it, because there is no possible reputational damage from such a grant and because IA is critical to our mission - it is essential to allow us to comply with WP:V. Indeed, I would argue that it is related to supporting Wikimedia projects, but perhaps a reasonable argument can be made as to why it is not. BilledMammal (talk) 03:54, 4 October 2023 (UTC)Reply[reply]
After your response I'm less clear on what's being proposed. You keep using really vague words like "broader community" and "oversight" which on the surface sound agreeable but are being used to mask what seem to be more controversial positions. The "broader community" is Meta, it's the global community comprising participants of all projects. Do you mean everyone or do you mean EnWiki? This community (i.e., the global community) already has broad oversight of these processes including multiple volunteer led, region specific committees and an open comment period on Meta (one of which you linked to). Wanting more participation is reasonable, but I don't think that framing this as if there's no community involvement or participation is fair; not liking a process and a process not existing are different things.The premise of the resolution isn't even well motivated: the resolution hinges on what individual donors think they're supporting, but neglects the other $30 million dollars in major gifts,enterprise funds, endowment returns, and investment returns which don't come from the small individual donors relied on by the rhetoric. It uses vague language games of "non-trivial" and "reasonable individual" to hide that fact that even among supporters there's no clear understanding of what those mean---some supporters suggest that "non-trivial" would cover every single rapid grant over the $500 minimum. Even your comment here can't firmly reject that this proposal would implicate partnerships with major mission aligned organizations like the Internet Archive I would argue that it is related to supporting Wikimedia projects, but perhaps a reasonable argument can be made as to why it is not. I'm not going to sign my name to something so vague that it can be twisted in whatever way someone wants. — Wug·a·po·des 06:22, 4 October 2023 (UTC)Reply[reply]
Do you mean everyone or do you mean EnWiki? Everyone, and I would argue that they don't have broader oversight of the processes; if they did, KEF would not have happened.
vague language games of "non-trivial" and "reasonable individual" For broad statements like this specificity is difficult, and results in situations where the WMF could use technicalities to get around seeking community approval. However, I don't see that as an issue; the very worst that can happen here is the WMF unnecessarily asks for community approval for some grants.
Even your comment here can't firmly reject that this proposal would implicate partnerships with major mission aligned organizations like the Internet Archive I don't discount the possibility that a reasonable argument could be made, but I can't envisage one. BilledMammal (talk) 06:34, 4 October 2023 (UTC)Reply[reply]
Everyone so then why is this on EnWiki? Why are the first words of the proposal "The English Wikipedia community"? Has this been translated in to any other languages? Have opinions of any other community been considered? The KEF was half volunteers hailing from English, French, Spanish, Indonesian, and Arabic projects; the current grants structure was was redesigned over nearly a year on the basis of multiple consultations with stakeholders including various project volunteers from across the globe. Why should anyone believe that an RfC held on EnWiki and talking solely about EnWiki accurately reflects global consensus on how communities would like to oversee grants? On what basis are you speaking for the global community?For broad statements like this specificity is difficult You want greater control and oversight of a $20 million grants budget, but defining the scope of what you want greater control over is too hard of a problem? Indeed, revolution is easy; governing is hard. Are you prepared to accept the increased staff overhead (read: the administrative costs being criticized elsewhere) that comes with managing all those "unnecessar[y]" postings? Too many posting will make it harder to find the important proposals (compare banner blindness); how will you ensure that this glut of "funding for edit-a-thon pizza" requests won't paradoxically lead to less oversight as people tune out? We could say these (and other questions) are for the WMF to figure out, but if you don't trust them to even implement specific requests, why would you trust them to implement vague requests? Plus, that would mean yet more admin overhead spent on interpreting our vague resolutions. I don't see vagueness as a problem in its own right; I see it as a problem because it belies a lack of strategic direction. The allocation of a $20 million annual grants budget, let alone the $170 million annual budget, shouldn't be decided on the basis of vague value statements. I find it ironic that misappropriation of funds is seen as a problem when the WMF does it, but we're allowed to hand-wave away the specifics of allocating millions of dollars because it's too difficult to figure out. — Wug·a·po·des 22:50, 4 October 2023 (UTC)Reply[reply]
Regarding "everyone", I suspect you would find it more objectionable, not less, if the proposal was that grants to organizations unrelated to supporting Wikimedia Projects needed approval from the enwiki community, rather than from the broader community.
defining the scope of what you want greater control over is too hard of a problem It's a difficult problem, but it is one that we could work around, if it was beneficial to do so. It is not; with this being a non-binding resolution we are better served by defining a principle that we can then work with the WMF to implement - and as I said, the worst that can happen is the WMF unnecessarily asks for community approval for some grants.
how will you ensure that this glut of "funding for edit-a-thon pizza" requests won't paradoxically lead to less oversight as people tune out edit-a-thon's are indisputably related to supporting Wikimedia Projects; this proposal isn't asking for the WMF to get our approval on such grants.
I find it ironic that misappropriation of funds is seen as a problem when the WMF does it, but we're allowed to hand-wave away the specifics of allocating millions of dollars because it's too difficult to figure out. We're not going to be allocating them; this resolution doesn't ask for us to decide where they will go. All it asks is that the WMF ensures that the community is onboard with their decisions. BilledMammal (talk) 08:45, 5 October 2023 (UTC)Reply[reply]
You didn't answer my question: on what basis are you speaking for the global community? You claim to be speaking for everyone, but when asked for justification on how you represent global opinions you deflect. When the EnWiki centrism of your position is pointed out, you start speaking about the global community again. You see how we keep playing this language game, right? Do you understand why this inability to speak plainly gives me no confidence in the resolution?And again, you didn't answer my question: are you prepared to accept the increased administrative costs necessary to handle the superfluous postings and consultation work required to manage your vague resolution? If you balk at doing threshold levels of strategic planning, I do not trust that you are prepared for the far more difficult work ahead.You're right, I got this confused with the other resolution where edit-a-thons would potentially be covered as a "non-trivial grant[] that will result in activity on the English Wikipedia".We're not going to be allocating them [funds] This is outright false. The resolution explicitly says "We request that the Wikimedia Foundation reappropriates all money remaining in the Knowledge Equity Fund". You're seeking to direct millions right here and right now, and later on ask that they "seek[] approval" for ill-defined categories of future grants. — Wug·a·po·des 18:18, 5 October 2023 (UTC)Reply[reply]
I think there has been a miscommunication here. This resolution speaks for the English Wikipedia; if passed the English Wikipedia would be asking that the broader community is consulted on grants to organizations unrelated to supporting Wikimedia Projects. I don't believe there is any enwiki centrism here; we are saying that we are concerned about these grants but we recognize that it isn't our place to decide alone whether they go forward or not; instead, we are asking that the WMF seeks approval for them from the broader community.
This is outright false. Perhaps we are using a different definition of the word allocate; the definition I am using is the act of deciding officially which person, company, area of business, etc. something should be given to. This resolution doesn't ask that we are allowed to decide who will receive funding; instead, it asks that we are allowed to reject funding within a narrow area, to act as gatekeepers. If that isn't the definition you are using can you clarify?
are you prepared to accept the increased administrative costs necessary to handle the superfluous postings and consultation work required to manage your vague resolution I'm not convinced there will be an increased administrative overhead. Some of the grants issued in the past are ones that should be obvious to the WMF would be rejected by the community; even absent this requirement those grants consume administrative capacity. Ideally, the WMF will recognize this and rather than wasting their time, and the communities time, on the grants will instead redirect the administrative capacity to handle the community consultation work. However, even if they don't and administrative costs are increased I believe the net result will be less money spent on the program as a whole due to grants being rejected. So yes, I am prepared to accept it.
If you balk at doing threshold levels of strategic planning, I do not trust that you are prepared for the far more difficult work ahead. I feel I have already replied to your statements about the lack of specificity in the proposal; It's a difficult problem, but it is one that we could work around, if it was beneficial to do so. It is not; with this being a non-binding resolution we are better served by defining a principle that we can then work with the WMF to implement - and as I said, the worst that can happen is the WMF unnecessarily asks for community approval for some grants.BilledMammal (talk) 18:48, 5 October 2023 (UTC)Reply[reply]
I can't really support this as currently worded (I do not think that the English Wikipedia in and of itself has the authority to demand that the WMF do a particular thing with already allocated funds), but I will give a "moral support" here. The WMF certainly has been spending too much money on things which do not have a clear connection to the core mission of Wikimedia, and has not generally been willing to give further detailed explanations for "How does this further Wikimedia's goals, and how is this expenditure the best way to achieve that?" beyond platitudes. So, I agree in the spirit of the thing, but this proposal is not the right way to ask for that. SeraphimbladeTalk to me 03:19, 4 October 2023 (UTC)Reply[reply]
@Seraphimblade: It's not a demand, but a request - and personally, I would have no issue if the WMF did proceed with the third round, so long as they first secured the broader communities approval through a securepoll vote. BilledMammal (talk) 03:54, 4 October 2023 (UTC)Reply[reply]
@Seraphimblade: seconding your point, a proposal to focus on the core mission, with specific examples of what needs clearer focus, would feel constructive. That does not feel like the spirit of this proposal to me, which second-guesses and mischaracterizes a specific effort to counter systemic bias that already involves community input, and at least tried to explain its origins and how it furthers Wikimedia's goals. – SJ + 04:50, 8 October 2023 (UTC)Reply[reply]
Small note that the Oppose/Support section titles are potentially a tad confusing. When read at face value, they might suggest you support/oppose the opposite of what you intend. Support for instance, when read as a sentence means: support, giving grants to external organisations, while in reality it means I support the proposal that that we are against giving external organisations grants. This is also a common issue with Survey polls in politics. —TheDJ (talk • contribs) 09:38, 4 October 2023 (UTC)Reply[reply]
Many of the topics and concerns raised here were discussed at the open community call hosted by the Knowledge Equity Fund Committee last Friday, October 6. You can find the notes from that call on Meta. These topics include how we can more clearly communicate opportunities for communities to participate in nominating grantees and getting involved, how the Knowledge Equity Fund grantees are connected to the movement and how we can better connect the dots, and how we are measuring the impact of knowledge equity. The Committee will be meeting this week to discuss the suggestions and feedback from the call and will post an update about next steps in the next two weeks.NGunasena (WMF) (talk) 19:42, 11 October 2023 (UTC)Reply[reply]
I just posted some next steps and changes that the Knowledge Equity Fund Committee will be taking based on the feedback we heard in the community call, in three distinct areas: Improving communication, Clarifying impact, and Connecting the dots with the movement. This is not a comprehensive list as we're still in discussion, but we wanted to share the changes as we go. NGunasena (WMF) (talk) 20:56, 20 October 2023 (UTC)Reply[reply]
The most important way to address Knowledge Equity also involves "sticking to our knitting": improving our mobile editing interface and mobile apps. Many potential editors only have access to smart phones, not computers. If we really want to boost editing from areas like the Global South, we need to make it easier.
I think the first thing to address there is WP:THEYCANTHEARYOU. That should have been treated as an emergency level bug from the beginning, and it's well past time to get that fixed. SeraphimbladeTalk to me 04:41, 22 October 2023 (UTC)Reply[reply]
Hi @Seraphimblade, my name is Jazmin (Jaz) and I am the Product Manager for the Mobile Apps team. I very much agree that maintaining on-wiki communication functionality is important and necessary. This is why, over the last two years, we’ve prioritized improvements to make the WP:THEYCANTHEARYOU table more and more green. (e.g., 1, 2, 3), though for some added context, depending on the platform (Android app, iOS app, or Mobile Web) the implementation, or lack thereof, of alerts differs, but steps are being taken to change that.
Specifically on the issue of IP editors not seeing notifications, we are currently working on it. I can understand that specific mobile communications issues feel a bit slow or quirky (depending on the platform) as compared to others; this is due to several teams working systematically to address anonymous edits through temporary accounts.
In the future, the shift to “temporary accounts” (formerly known as IP Masking) will hide IP addresses from the general public while also allowing people to continue editing without creating actual accounts. Particularly in the apps, users that do not login to a permanent account when attempting to make an edit, will automatically be assigned a temporary account that is based on cookies, not location. On the apps, users with temporary accounts will have the same editing and notifications experience as people that create permanent accounts. This will eliminate the quirks and inconsistencies across platforms, addressing many of the outstanding gaps in mobile notifications. @NKohli (WMF) and @SGrabarczuk (WMF) can share more about this project overall should you have any questions.
Additionally, next week we will make some updates to the cross team on-wiki communication MediaWiki page, which was created to be more inclusive of other language wikis; the refresh will include incorporating updates currently represented on team specific project pages. The app's Community Relations Specialist, @ARamadan-WMF will ping you there once the updates are live so that we can continue the conversation and get your input on whether or not we are going in the right direction.
Hi @A. B., I am happy to see your passion for improving editing on mobile. My name is Jazmin (Jaz), and I am the Product Manager for the Mobile Apps team. While I collaborate with the team responsible for Mobile Web, I do want to make that distinction, so you can understand the context of my response.
My manager, @MMiller (WMF), shared just a few improvements we are working on for the mobile app experience. What isn’t mentioned there is that we are completely rewriting the editor on iOS to improve the performance.
We have an open meeting coming up Friday if you’d like to have a closer look at our roadmap and share additional ideas to improve the editing experience on the app. If you can’t make the time, no worries, we will record it and provide notes. We also make updates for the Android and iOS app on a monthly basis, which includes sharing early designs and ideas and we welcome your partnership. If ever you have feature ideas or bugs you notice feel free to reach out to @ARamadan-WMF so that we can triage it in our weekly team meeting.
For any Mobile Web ideas that are editing specific feel free to reach out to @PPelberg (WMF) and for more reading features @OVasileva (WMF) is a good person to talk to. JTanner (WMF) (talk) 20:55, 26 October 2023 (UTC)Reply[reply]
Increased support for internal needs (Community Response)
The English Wikipedia community is concerned that the Wikimedia Foundation has neglected critical areas of the project, and that continued neglect of these areas may endanger the project. To improve the resilience of the project, we request that money be reallocated to hiring more technical staff, whose role will be to fulfill requests from the community such as those expressed on the Community Wishlist, as well as restoring access to tools such as grapher extension. To improve knowledge equity we also request that that the Foundation provides funding to assist established editors in accessing the resources they need
to improve the encyclopedia, such as by increasing the number of libraries accessible through the Wikipedia Library and by giving micro-grants for the purchase of backlogged items at Resource Request.
Increased support for internal needs (Survey)
Support (Increased support for internal needs)
What we need from the WMF most of all is tech support; for them to maintain the website and develop the tools that we need to build the encyclopedia. Unfortunately, this support is often lacking; despite the criticality of New Page Patrol it took a massive lobbying effort to get the WMF to dedicate any resources to it, and it has been six months since we were notified that the graph extension had to be disabled due to security risks, but there has been little progress on restoring it despite its utility. Hopefully the WMF will be willing to take this resolution on board and in its next budget direct a greater proportion of resources towards providing this support. BilledMammal (talk) 01:01, 3 October 2023 (UTC)Reply[reply]
Easy support, though I'd encourage removing "established" from "established editors". While accepting this non-binding resolution is several steps removed from actually seeing a change in TWL resources, what would help knowledge equity is actually to lower the requirements to access TWL. Help people get off on the right foot when they're editing rather than assume they'll slog through 500 edits without access to good sourcing. Certainly not enough to cause me to oppose, but I'd like to see that word removed (apologies for not catching it before the proposal went live -- perhaps it's not too late, BilledMammal?). — Rhododendritestalk \\ 01:36, 3 October 2023 (UTC)Reply[reply]
While I understand your concern, I'd prefer to leave "established" in there. Realistically publishers offering resources are going to want to have some idea of the hit rate they are signing up for. I can't see Elsevier, for example, wanting to open ScienceDirect much more widely than they already have. Espresso Addict (talk) 01:47, 3 October 2023 (UTC)Reply[reply]
Then what is the funding going towards? Last I checked, everything in TWL isn't because the WMF paid for it but because someone simply asked the publisher for it. WMF could help close the gap. I cannot imagine the WMF paying to add these resources, as that would lead to all the other publishers saying "wait, we don't have to give it away?" — Rhododendritestalk \\ 02:01, 3 October 2023 (UTC)Reply[reply]
@Rhododendrites and Espresso Addict: Just jumping in with a quick note that Rhododendrites is correct - we don't pay subscriptions for any of The Wikipedia Library's resources. It would be obscenely expensive given that we serve tens of thousands of users (approaching the entire WMF budget), and as you suggest, paying one publisher would risk resulting in a chain of events where other publishers also demand payment. I'm sympathetic to the idea of lowering access requirements, I'd love for more editors to be able to use the library. Unfortunately this would require renegotiating all our agreements, which is a lot of work. Input is welcome on this topic at T314357. Samwalton9 (WMF) (talk) 10:06, 6 October 2023 (UTC)Reply[reply]
Thanks for the response, Samwalton9 (WMF). I read the interesting Phab link but it won't let me comment. I think it would be more realistic for the Foundation to pay for access for a small group of highly active named editors, perhaps for a specific type of task, which would make it fall more under the Wikipedian-in-Residence type of relationship. On the access requirements, fwiw, I have chatted to several non-editors about the library resources as a recruitment ploy and non-editors are generally interested until I mention the access requirements, which seem unapproachably steep to them. Espresso Addict (talk) 21:44, 6 October 2023 (UTC)Reply[reply]
If they say they're raising money to support and improve the encyclopedia, they should do so. Intothatdarkness 01:52, 3 October 2023 (UTC)Reply[reply]
I've said as much before and I think leveraging existing resources like the legal fees assistance program and Rapid Grants would be an efficient way to make progress on this in parallel with increasing Wikipedia Library holdings. — Wug·a·po·des 02:30, 3 October 2023 (UTC)Reply[reply]
Community Wishlist items that consistently receive high support are continually being overlooked due to currently insufficient funding for technical staff. Reallocating funds from such editing grants would arguably enable editors to more efficiently pursue these grants' aim of increased article coverage BluePenguin18 🐧 ( 💬 ) 02:48, 3 October 2023 (UTC)Reply[reply]
"Hire more devs" is a no-brainer. The microgrants sound like an interesting idea as well, and the Wikipedia Library is already amazing. But yeah, hire more devs. Help us align with our shared goals. Folly Mox (talk) 03:02, 3 October 2023 (UTC)Reply[reply]
The WMF has more than enough money to do these things, but it has inexplicably decided to spend a large sum of this money on things that do not help Wikipedia and its sister projects. Thebiguglyalien (talk) 03:14, 3 October 2023 (UTC)Reply[reply]
Mainly due to the graph extension being disabled and the lack of work going towards fixing it. It's like a ghost haunting the talk pages of most Wikipedia articles. I've noticed a concerning amount of decay when it comes to tech support, and if additional funding will help then I'm all for it. Deauthorized. (talk) 03:23, 3 October 2023 (UTC)Reply[reply]
While I'm a little worried about monkey paw effects here, that doesn't diminish my support per BilledMammal. Barkeep49 (talk) 03:39, 3 October 2023 (UTC)Reply[reply]
In agreement with Barkeep49, with more comments to follow. Best, KevinL (aka L235·t·c) 04:16, 3 October 2023 (UTC)Reply[reply]
Common sense. There have been several technical issues at NPP that we have had to beg and grovel for the WMF to fix. More resources towards technical development is self-evident. Curbon7 (talk) 04:17, 3 October 2023 (UTC)Reply[reply]
While I understand that the Foundation has had some growing pains in the tech department, that is no excuse to not continue to put effort into our software. If that requires some radical changes, so be it, but we need more effort going into our backend. That means more money. There are far too many tech issues that have lingered for years. CaptainEekEdits Ho Cap'n!⚓ 05:03, 3 October 2023 (UTC)Reply[reply]
100%. Don't know if this is going to move the needle but it couldn't hurt. Nardog (talk) 05:08, 3 October 2023 (UTC)Reply[reply]
Tech support and maintenance, and development of features requested by editors is the minimum that is expected from the WMF. Ciridae (talk) 06:00, 3 October 2023 (UTC)Reply[reply]
I'm not generally as critical of the WMF as many but this is the one areas I agree with the critics. The WMF has been slack in supporting the communities needs. I appreciate that it doesn't always go well since some features have been implemented on request then disliked and abandoned, and that there are a lot of communities with differing needs to support, but they can and should do better. Nil Einne (talk) 11:23, 3 October 2023 (UTC)Reply[reply]
Micro-grants for old Resource Requests seems like a pretty good idea. ARandomName123 (talk)Ping me! 13:07, 3 October 2023 (UTC)Reply[reply]
This is what the WMF was created for. Certes (talk) 14:27, 3 October 2023 (UTC)Reply[reply]
The Wikimedia Community, and not the Wikimedia Foundation, governs the Wikimedia Movement. When donors give money to Wikipedia, they give it to the Wikimedia Community and not the Wikimedia Foundation. It is essential that money go to support the Wikimedia Community, its culture, and its values. With increasing regularity and forcefulness, the values and ethics of the Wikimedia Foundation are contrary to those of the Wikimedia Community. Bluerasberry (talk) 14:25, 3 October 2023 (UTC)Reply[reply]
It's the primary mission of the movement, after all. The execution should match the sales pitch. Many of the other things they do are, I feel, for laudable goals, but fundraising shouldn't be pretextual in this way. There are many projects related to the core mission that receive anemic funding. The core mission is the reason the WMF exists. CoffeeCrumbs (talk) 15:14, 3 October 2023 (UTC)Reply[reply]
WMF has consistently shown that it is willing to spend any amount of money needed for fundraising, and the fun parties that are involved with that, and very little on actual needed functions. The leadership has been a disgrace for years, and is part of the reason I don't spend more time here. Dennis Brown - 2¢ 16:46, 3 October 2023 (UTC)Reply[reply]
WMF has been neglecting its core function for too long. Levivich (talk) 17:05, 3 October 2023 (UTC)Reply[reply]
Support. I particularly like the idea of widening the scope of the Wikipedia Library. I think this is a resource which so many editors use and could do with additional investment. Willbb234 20:43, 3 October 2023 (UTC)Reply[reply]
Yes, the foundation should always have its primary mission in mind. However, I support with the nuance that the foundation has hired support staff, of which some are necessary, and that whilst micro grants for resource requests are a good idea, the linked page (at least) is only on enwiki which is a negative. —Danre98(talk^contribs) 03:23, 4 October 2023 (UTC)Reply[reply]
One of the WMF's primary founding purposes was to provide technical services and software development for the Wikimedia projects. If not its top priority, that should be very close to it. We have far too often seen highly desired community requests go either entirely unanswered or get a "We don't have the resources right now" for years on end, while we see tons of resources flowing out in dozens of other directions. SeraphimbladeTalk to me 04:43, 4 October 2023 (UTC)Reply[reply]
Support, if for no other reason than this is what donors expect their money to be spent on. Barnards.tar.gz (talk) 07:50, 4 October 2023 (UTC)Reply[reply]
I think this is where we're on firmest ground, because we're asking for something that we need rather than trying to dictate to the WMF. It really is astonishing how little of the WMF's enormous budget goes to software. We haven't been able to use mw:Extension:Graph for six months, apparently because it was unmaintained for years before that. NPP had to beg for fixes to Page Curation, also unmaintained for years, and after three months of work all the team assigned to it could manage to do is switch to a more modern backend with no significant changes to the functionality (to be clear I'm not criticising the team; they're clearly under-resourced). We can't reliably talk to editors on mobile. And that's with volunteer developers doing a great deal of the heavy lifting. – Joe (talk) 08:24, 4 October 2023 (UTC)Reply[reply]
Technical maintenance is important and is outside the ability of the community to perform. I think conveying to the WMF that we'd like to see more investment in that area could be productive. ModernDayTrilobite (talk • contribs) 16:05, 4 October 2023 (UTC)Reply[reply]
We have some of the most-obsessive volunteers and they give the world their labor for free. Least we could do is ensure truth in advertising by supporting those editors. Chris Troutman (talk) 20:11, 4 October 2023 (UTC)Reply[reply]
Now this one I can get behind. My support is a little on the weaker side, because I recognize the complexities involved in the financing of the Wikimedia movement and institutional ecosystem, with it's many stakeholders and I broadly respect the discretion of the WMF as pertains to addressing and balancing the competing needs. That said, the specific areas highlighted by this proposal are known current weaknesses in our technical infrastructure (even if vaguely defined here). And while I have often felt the scrutiny the WMF faces from some of it's more consistent critics as regards it's management of movement resources has strayed into the presumptuous (to say nothing of those that are sometimes histrionic, speculative, unrealistic, or simply wildly outside the purview of those without the relevant fiduciary or professional duties), I do think that these would-be muckrakers have succeeded in at least one respect: highlighting just how sizeable a largess the WMF has managed to accrue for the movement through effective fundraising. While I do not believe it is this community's role to set terms on how those funds are distributed (outside of a speculative existential crises from underfunding), I do not see the harm in pointing out to the WMF that we have a few areas where funding of technical solutions would be especially helpful at this moment in time, and that there is an argument to be made, based on donor intent, that the large role that en.Wikipedia plays in generating funds for the movement as a whole arguably militates for plugging these needs sooner, rather than later, at least when the reserve financing is as flush as apparently they currently are. SnowRise let's rap 22:01, 4 October 2023 (UTC)Reply[reply]
Support. I am not so concerned with the Wikipedia Library and WP:RX part as this is the first I'm hearing of problems in those areas. I am very supportive of the Community Wishlist and community software part of this RFC though. Community software seems like an area that has historically been neglected, with some small progress made recently, but still with much work to do. –Novem Linguae (talk) 08:00, 5 October 2023 (UTC)Reply[reply]
Support: with the amount of money the WMF have, the technology we have should be cutting edge. The graph extension is a prime example of something that should have been fixed overnight. The Wishlist simply doesn't work. The problem is not just the broken things and the missing functionality. I don't think many experienced volunteers understand just how unusable this website is to newcomers. For one thing, website design has advanced since 2001 when writing in lightweight markup language was expected. For another, experienced volunteers accrue all sorts of gadgets and js code to make simple tasks that are otherwise very complicated or make readable what is completely unreadable on the base site. — Bilorv (talk) 21:16, 6 October 2023 (UTC)Reply[reply]
Support This year the Foundation did the annual planning in public with community input for the first time in years. That was a step in the right direction, and many of the things they committed to are explicitly with the editing community in mind. There is still more that could be done to put sufficient staff attention on community needs however, and be responsive/agile when it comes to planning and resourcing. Steven Walling • talk 02:10, 7 October 2023 (UTC)Reply[reply]
Support it's ridiculous that the foundation has apparently enough money to donate to other organizations, while not enough to perform basic software maintenance to support its core mission --Ita140188 (talk) 14:00, 9 October 2023 (UTC)Reply[reply]
Support – Most people who donate I've talked to IRL have the impression that "it's to keep the servers running". I think using a larger portion of funds towards tech support is necessary or should at least be an option to allocate your donation to. Clovermoss🍀(talk) 20:33, 10 October 2023 (UTC)Reply[reply]
Support This will also stop deceiving donors who do so to support Wikipedia. It would have been better to include / implicitly includes "shift funds from other less related areas, not increase total expenditures." North8000 (talk) 19:34, 13 October 2023 (UTC)Reply[reply]
Support The WMFs number one job - really the only reason it needs to exist - is technical and it seems to always forget that in favor of "flashier" initiatives. The impact of more technical work dwarfs any other uses of donor money. Galobtter (talk) 22:51, 13 October 2023 (UTC)Reply[reply]
Support We could do so much more. (comment from involved editor) — TheresNoTime (talk • they/them) 11:48, 14 October 2023 (UTC)Reply[reply]
Support The WMF needs to provide far more support to the community, and there are almost zero blockers preventing it, or at least a request for it from us. Justarandomamerican (talk) Have a good day! 21:11, 14 October 2023 (UTC)Reply[reply]
Support. This should be the top priority of the WMF. I would suggest finding ways to align C-level executives with this core mission, rather than aligning Wikimedia projects with whatever makes good high profile resumes in the US NGO scene. MarioGom (talk) 08:00, 15 October 2023 (UTC)Reply[reply]
Support. In particular, improve the mobile interface and apps so less affluent editors can more easily add content. Many have mobile devices but no desktop computer. Also see my 23 October TWL suggestion in the discussion section below. --A. B.(talk • contribs • global count) 02:37, 22 October 2023 (UTC)Reply[reply]
Support. Obviously. Stop wasting $$$ on "flashy" projects in lieu of increased support for the community, that's what people give their money for. --Randykitty (talk) 13:26, 24 October 2023 (UTC)Reply[reply]
Support Organization failure when everything is for the "flash" and "bangs" instead of taking care of the core values. We didn't need too much work. WMF is already bloated with millions of dollars they have received - we didn't need to bloat it even more. Any IT startup tech having money/resources WMF got today can easily fix any tech issues around here - but WMF can't. ✠ SunDawn ✠(contact) 03:10, 25 October 2023 (UTC)Reply[reply]
Support I know of at least one privacy-impacting security flaw which is still not fixed because we have to balance what we are physically able to contribute our time to, and what is within the scope of the project we commit to. What else needs to be said? Suffusion of Yellow (talk) 23:55, 27 October 2023 (UTC)Reply[reply]
Conditional Support. I agree with Rhododendrites that the word "established" should be removed from "established editors". I also think mention of the Graph extension should be removed, as there were good reasons it was disabled and it distracts from our overall point to bring it up here. Nosferattus (talk) 01:52, 28 October 2023 (UTC)Reply[reply]
WP:TCHY creates a tremendous workload for volunteer editors and has frustrated me for a long time. — SamX [talk·contribs] 08:15, 28 October 2023 (UTC)Reply[reply]
Support - we need the resources of the Wikimedia foundation to go directly into wikimedia websites. The ever growing funding requirement that is essentially unconnected from the actual task of running the websites is unacceptable tompagenet (talk) 13:19, 29 October 2023 (UTC)Reply[reply]
Oppose Should the WMF devote more effort to community requests? Sure! But I've been here nearly two decades and I've never used grapher extension. And tools I use every day you've probably never used. We're not all going to agree on what is a critical request, so this is pretty pointless. Gamaliel (talk) 23:15, 3 October 2023 (UTC)Reply[reply]
Oppose including Graph extension Solely on the grounds of including/dragging the the Graph extension into this topic. The Graph extension was disabled due to issues wrt to vulnerabilities with upstream libraries. This is not something that the WMF can do something about. While the WMF could theoretically somehow commit to maintaining our entire upstream software stack, this is prohibitively expensive to the point that even Google and Microsoft do not tend to do this. The approach that the Wikimedia Foundation is currently taking is that of sandboxing libraries is notoriously hard to do correctly, as evidenced by the gazillions of bugs in Microsoft and Google products that use client-side sandboxing (such as research.google.com and Visual Studio Code) which are still being found and exploited. I think the tardiness in this case, is warranted. Support otherwise. -- Sohom (talk) 14:05, 6 October 2023 (UTC)Reply[reply]
This is because the extension was not updated for several years. All we need is to transition to the newest software versions as all established organizations do regularly Ita140188 (talk) 14:01, 9 October 2023 (UTC)Reply[reply]
@Ita140188All we need is to transition to the newest software versions it is significantly harder to do that than you think, especially in the context of the aging technical debt surrounding the usage of MediaWiki. Porting the Graph extension over to Vega 3,4 or 5 (which I agree would also solve the problem) is a non-trivial task that includes more than just updating version numbers but also making sure that wikitext written for the graph tag using the previous version of the library still works on the newer version even though the abstractions used by the libraries might have radically changed, not to mention that in-case this compatibility is not possible, editors will have to manually check and update each and every instance of the usage of graph tags. Sohom (talk) 05:49, 10 October 2023 (UTC)Reply[reply]
I agree, and that's the point. The lack of investment over many years created this technical debt, which reinforces the case for having more resources allocated to this. We cannot and we should not assume that old versions of software will work forever and no bugs will be ever found. The only way to have functioning software today is to constantly update it, and that takes resources. Ita140188 (talk) 07:38, 10 October 2023 (UTC)Reply[reply]
Mild oppose as worded. While I agree with the overall sentiment, "To improve knowledge equity [...] assist established editors" sounds like a contradiction in terms. Reinforcing the existing community might just consolidate the status quo.
I tend to agree with the three premises I see in this statement, namely that:
the most direct way for Wikimedia to improve knowledge equity is to grow and improve our freely licensed projects (more diverse works for a more diverse audience);
our contributor base, while insufficiently diverse, is more diverse than the average media landscape, therefore making the existing contributor base more effective will be a net positive for the world;
the most direct way to make contributors more effective is to look at the existing community and provide them more of the tools they need.
However, those premises are not universally accepted or verifiable. Sure, if you try to improve a specific article like Deforestation in Nigeria you're going to conclude that it's far more effective to message its contributors and give them a few hundred dollars in resources to make further work easier, compared to giving 20 k$ to someone seemingly unaware of the existence of the article. Once you try to do the same across a broader topic like Nigeria or deforestation globally, if you just help the existing contributors it's likely they'll keep doing more of the same. So we need to at least keep an eye on some of our broader goals, such as verifiability, which involve all of our users, including unregistered users.
Which brings me to the specific suggestion included in the proposal. The Wikipedia Library might as well increase inequality, in that it reinforces a relatively narrow base of contributors and contributions based on established/exclusive sources (such as USA-centric publishers or prestige-based research), further amplifying structural bias. The alternative is to invest in more inclusive sources and source providers, which would help all our users get in touch with more diverse sources. An unregistered user who wants to verify a claim from a reference has a much easier job when a link to open access version is provided, or when a preview or digital loan from the Internet Archive is linked. Moreover, such open or semi-open resources help the production of secondary sources by helping library users, translators, researchers, authors, educators. It's relatively easy and low-risk for us to help, as it takes relatively low effort new initiatives or existing initiatives like Invest in Open Infrastructure.
No it's not. Nemo 17:45, 7 November 2023 (UTC)Reply[reply]
Increased support for internal needs (Discussion)
I'm not going to read any of these long-worded points, I started to but am guessing that they (Edit: now have read many of them) ...all comes down to WMF has control of the money gained from touting Wikipedia so of course they owe us anything we want and they should also include the community in almost everything they do. Why not? And more power to WMF in everything. I hope some wonderful billionaires will be giving them (and, in turn, some trickle down to Wikipedia please) $100 million at a pop. Bill Gates, donate a 100 million, or 200, give them a lot, and kindly stipulate that 1/3 of that should go to the projects conceived of and organized by Wikipedia editors. Every year someone else should step up and do this. Taylor Swift, a million would go a long way, and Elon, how about funding Commons to the hilt, create the creation. By the way, VivaWikiVegas could use a few million in cash/and or MGM housing donations to throw the bash of the century for Wikipedia's 25th birthday. As for Editor Expeditions...
For just one of a thousand examples, this is something I literally thought of yesterday. WMF Wikipedia coffers (which should be overflowing with kindness) can send teams of Editor Expeditions out in the field. An individual or a group, say an art editor, a technology editor, a city-specific subject-expert, a few fill-in-the-blank editors, sent or a week or two as individuals or as a team to a city, a nation, to the citadels of a scientific field, to work on article sources, photographs for Commons, meeting with local officials to promote Wikipedia etc. Participation of the local community with the Wikipedia community to give options for growth. A team would have a back-up crew working with them daily, maybe the people who will be leading the next on-site expedition.
Randy, I admire your unselfconsciousness. In your first sentence you call others' contributions "long-worded points" and decline to read them, and then you've written all this.—S MarshallT/C 08:49, 3 October 2023 (UTC)Reply[reply]
Thanks, I learned at my father's knee. In my above comment I was referring to the many varied questions and proposals on this page and the others put up yesterday. Brevity might do all of us a favor, but in this case I've added my comments concerning all of them in one place. Randy Kryn (talk) 14:05, 3 October 2023 (UTC)Reply[reply]
@Deauthorized: On graph extension. The extension is disabled, but there is no lack of attention from the developers. From phab:T334940, the amount of work to be done to fix the extension is... non-trivial, with no direct path to upgrade the underlying engine to the latest version. Just that the conversation isn't happening here, it doesn't mean there is a lack of work. – robertsky (talk) 03:36, 3 October 2023 (UTC)Reply[reply]
Does anyone understand what the plan actually is? If so, what can editors do to help fix broken graphs which presumably need to be edited somehow, e.g., to make them compatible with Vega 5? This is a good example of something that fell apart when a vulnerability was discovered, because there were no staff resources devoted to fixing emergent faults. That does indeed seem like a money allocation deficiency to me. Sandizer (talk) 09:53, 3 October 2023 (UTC)Reply[reply]
I guess so, but it's hard to confirm. After this and that, I still really don't have a handle on what needs to be done at all. Sandizer (talk) 16:22, 5 October 2023 (UTC)Reply[reply]
Does anyone understand what the plan actually is? If so, what can editors do to help fix broken graphs which presumably need to be edited somehow, e.g., to make them compatible with Vega 5?
Hi @Sandizer, great question. The plan is to re-enable the Graph Extension in a sandboxediFrame with a restrictive content security policy. Additionally, we will make the Graph Extension compatible with Vega 5 so that, going forward, all new graphs will benefit from Vega 5's security, accessibility, and syntax improvements. We will also equip volunteers with code and processes that will ease the transition from Vega 2 to Vega 5 when the time for this transition comes.
This is a plan we've converged on through months of conversations with a network of volunteers. Within the next week, you can expect to see a roadmap that details the specific steps we – volunteers and staff – will need to take to make the above happen.
In the meantime, we appreciate how proactive you are, and have been, about asking what you [and other volunteers] can do to help fix the broken graphs.
I recognize that it is likely frustrating to be willing and ready to lend help and for it to not be clear how to do so. I’m naming this potential frustration because it’s important to me that you know it’s something we’re thinking about as we try to strike a balance between re-enabling the extension as quickly as possible while doing so in a way that keeps Wikipedias as a whole safe and secure.
And hi, I'm Peter Pelberg 👋🏼 I work as the product manager on the Editing Team. I'm also responsible for safely and securely restoring access to the information and capabilities disabling the Graph Extension has left people without.
@Sohom. You bet. If any new questions/ideas/concerns emerge as you're thinking about the Graph Extension, please ping me! PPelberg (WMF) (talk) 18:43, 16 October 2023 (UTC)Reply[reply]
It is beyond ridiculous that this problem was allowed to occur and with each passing day it damages Wikipedia's reputation to editors and readers. This is not to criticise the employees working on the issue, but the misallocation of WMF funds that led functionality like the Graph Extension to be neglected for years. The WMF is rolling in money but not spending enough of it on maintaining tech, modernising interfaces, community wishes and so forth. — Bilorv (talk) 19:30, 16 October 2023 (UTC)Reply[reply]
Thank you for the response. I hope that this issue is corrected soon. Deauthorized. (talk) 00:39, 17 October 2023 (UTC)Reply[reply]
@PPelberg (WMF): the roadmap seems ok. 2 points in mind, 1. I think it is also best to involve those who hold the templateeditor user rights and/or actively working on WP:TFD/H queue here on enwiki, if you have not done so, to accelerate the transition over to Vega 5. 2. is there an end date to Vega 2 backport? Will Vega 2 be eventually be decommissioned totally and when? Asking because it will give the community a sense of urgency to move to Vega 5 for the supported graphs in Vega 5, while solutions or workarounds for the unsupported graphs/features either in form of somehow grafting the unsupported graphs or decoupling them to another template, etc. can be worked on. – robertsky (talk) 13:42, 21 October 2023 (UTC)Reply[reply]
@PPelberg (WMF): the roadmap seems ok. 2 points in mind, 1. I think it is also best to involve those who hold the templateeditor user rights and/or actively working on WP:TFD/H queue here on enwiki, if you have not done so, to accelerate the transition over to Vega 5.
Great call, @robertsky. We have not yet contacted the two groups you named above. Although, I've filed T346291 to hold us accountable to doing so.
A clarifying question: were you thinking the communication you described above would happen once the technical components for porting existing graphs to Vega 5 are in place? Were you thinking that communication would happen now? Both? Something else?
…I want to be sure I'm accurately understanding you.
is there an end date to Vega 2 backport? Will Vega 2 be eventually be decommissioned totally and when?
Great questions. I'm going to respond to the second question first…
Regarding the first question you asked – "Is there an end date to Vega 2 backport?" – can you please say a bit more about what you mean by this question? E.g. might you be asking:
1) "When the Graphs Extension is re-enabled, will it support Vega 2-based graphs?"
2) "If the answer to "1)" is "yes," how long after the Graph Extension is re-enabled with support for Vega 2 will Vega 2 support be removed?"
Asking because it will give the community a sense of urgency to move to Vega 5 for the supported graphs in Vega 5, while solutions or workarounds for the unsupported graphs/features either in form of somehow grafting the unsupported graphs or decoupling them to another template, etc. can be worked on.
Understood! I appreciate you sharing the thinking that prompted you to ask the above. PPelberg (WMF) (talk) 23:52, 26 October 2023 (UTC)Reply[reply]
were you thinking the communication you described above would happen once the technical components for porting existing graphs to Vega 5 are in place? Were you thinking that communication would happen now? Both? Something else?
For a wider participation, the communication can happen when the components are in place for the migration, hopefully with clear instructions on how to use the tools, which I assume to be at the end of Phase 2? My thoughts are that with clear instructions, at least of the simple charts, any editors can change the charts without much assistance, and for the more complex ones, the experienced template editors, with respect to Charts extension, can quickly work on doing up a suitable replacement based on these instructions, other prior experiences, and/or creativity.
With respect to the end date question, it is was asked under the assumption that Vega 2 will be enabled in a safe manner in the meantime. So yes, your clarifying 2-part questions is correct. – robertsky (talk) 03:21, 27 October 2023 (UTC)Reply[reply]
And presumably if the WMF allocated more resources to it, that work would get done faster? That's how work usually works, anyway. More importantly, with more resources, we can hope that there won't be more extensions in the future that just get forgotten about for six years, causing blow-ups like this. – Joe (talk) 13:21, 4 October 2023 (UTC)Reply[reply]
Exactly. This is the result of underinvestment and neglect for many years, and something that was entirely predictable Ita140188 (talk) 19:11, 11 October 2023 (UTC)Reply[reply]
Hard to say if throwing more developers at this stage for the Graph extension is going to make the work get done faster. But definitely will be helpful to have more developers/eyes to look into other extensions, being used on all projected hosted on the Foundation's servers, neglected or not. At the very least sort out a priority list based on criteria such as security or feature gap, etc. for future development. – robertsky (talk) 10:29, 16 October 2023 (UTC)Reply[reply]
What Robertsky said. There are thousands of us who remember the early WMF having the total staffing of what is today the staffing of the smallest team in the Product & Technology sphere. There are thousands of us who remember hours-long and even occasionally days-long downtime. I can still remember the time there was nobody officially "on call" for keeping the site up, and one of the few capable individuals actually had to deplane just before take-off in order to get Wikipedia back up. (And never did get reimbursed for their missed vacation.) We cannot be complaining about the WMF spending too much money on staffing and benefits while at the same time complaining that there aren't enough staff to do everything. The technological debt is significant (although being worked down). Part of that debt comes from extensions built by volunteers years ago that managed to get into MediaWiki core, only to have the maintainers leave. We may have to give up some extensions that are difficult or impractical to maintain, or consider other ways of doing certain things. But that would mean change, and we all know how Wikimedia communities respond to changes.... Risker (talk) 04:32, 3 October 2023 (UTC)Reply[reply]
"We cannot be complaining about the WMF spending too much money on staffing and benefits while at the same time complaining that there aren't enough staff to do everything." True, but it's almost inevitable that growing organizations will eventually lose focus on some if not most of their core needs, resulting in too many people and not enough vital work being accomplished. Sandizer (talk) 10:06, 3 October 2023 (UTC)Reply[reply]
I object to Wikimedia Foundation staff hired to do things best done by the non-technical community, including convening conversations on ethics and values, doing outreach, and community organizing. I support Wikimedia Foundation hiring technical staff for code development. The coders are not the ones who find themselves in conflict with the community. The staff who speak on behalf of the Wikimedia community and for the Wikimedia community frequently do. Bluerasberry (talk) 14:36, 3 October 2023 (UTC)Reply[reply]
Perhaps you should ask the technology staff this. When I sit with developers, they point to the differing expectations between communities, and the disproportionate entitlement of English Wikipedia, as major issues. They aren't here to build English Wikipedia, they're here to support 800 projects, all with different needs and demands. Those staff you're worried about were brought in to act as buffers between the very demanding individuals in many communities, and the developers who (as a group) are quite conflict-averse. When it used to be the developers talking to communities, they were pilloried, too. Risker (talk) 18:10, 3 October 2023 (UTC)Reply[reply]
That's a really insightful point, which is in some ways at the crux of this: what amount of entitlement is appropriately proportionate for the English Wikipedia? About half of the 820 Wikimedia projects appear to have fewer than 20 active editors. I'll not touch on revenue or mindshare / reputation. That acrimony is best handled elsewhere. I will say that Community Wishlist items are often unfulfilled, which affects all projects, and the priority of the survey results is already determined by devs, so they're free to rebalance to help serve smaller communities disproportionately to their sizes.Do the dev teams not want more crew? I understand there's a point in software engineering where throwing more people at a problem loses effectiveness, but we're hardly close to that point. Folly Mox (talk) 21:11, 3 October 2023 (UTC)Reply[reply]
I guess I'm not seeing anywhere in the proposed resolution where it recommends cutting staff positions that are ancillary to development and maintenance in order to pay for the proposed new technical positions.In any case though, I think I misunderstood Risker's Perhaps you should ask the technology staff this as something more general than a reply to the sentence directly above it. Folly Mox (talk) 01:16, 4 October 2023 (UTC)Reply[reply]
[Developers] aren't here to build English Wikipedia, they're here to support 800 projects, all with different needs and demands. Then it'd be great if the WMF would hire some devs to work specifically on the English (and other large) Wikipedias, given that we're its flagship project and bring in the lion's share of the money used to support the rest of those 800 projects. – Joe (talk) 13:18, 4 October 2023 (UTC)Reply[reply]
Hi all - I’m Sam Walton, the Product Manager for The Wikipedia Library (and now Moderator Tools). I saw increased support for The Wikipedia Library was mentioned in this RfC so I wanted to jump in to share some information about how we grow the library and what we’ve been doing recently. First, some good news - The Wikipedia Library continues to grow, with 12 new partnerships in the last year and numerous collections renewed or moved to more seamless methods of access. We also recently hired Vipin SJ as a dedicated partnerships manager, so for the first time we have someone solely focusing on growing the amount of content available through the library. This has really helped us be more comprehensive and committed in our approach - I’ve worked on the library for something like 8 years now and I think the program is currently in the best place it’s ever been.
Acquiring new partnerships to expand the available content in the library can be a slow and frustrating process, but usually not because of a lack of capacity on our side. We’re building the library through no-cost partnerships, and this isn’t a proposal publishers are accustomed to evaluating. Unlike with sales, they don’t have teams ready to field these requests and simply action them. Getting a new partnership is a process that starts with getting through to someone at the organisation who is in the right position to understand what we’re asking, usually involves multiple meetings to explain the partnership model, answer their questions, and assuage their concerns. We then need to agree on how access will be provided, and often need to get legal teams involved to review and sign agreements. Although this is all fairly rote to us at this point, and we have dozens of conversations on the go simultaneously, during this process it’s very common for the publisher to lose interest or to spend a lot of time in long discussions around the details (we signed with Wiley about 1.5 years after our first contact with them!). Once we’ve got a partnership signed and content is available to editors, we then need to keep the partner up to date and engaged with the program, so that if we need something from them, we won’t be disappointed to discover, for example, that our contact no longer works there. The reason I’m laying all this out is to explain that although this requires effort from our side, the bottleneck in this process is usually the organisations we’re dealing with.
I also wanted to be candid and note that we shouldn’t lose sight of how much content is already available! We regularly hear from librarians from around the world who are jealous at the range and volume of content we have available in The Wikipedia Library today, because it would simply be unaffordable for them to subscribe to it all. We did a back-of-the-envelope calculation and if the WMF was directly paying for all the subscriptions for the library, for the tens of thousands of users who qualify to use it, the total cost would come out to something like the entire current Wikimedia Foundation yearly budget! All this to say, although - obviously - I appreciate the message you’re sending here about how valued the library is, I personally think we’re already dedicated to growing it and making it as broad in its coverage as possible.
If you want to help us prioritise our partnerships, we have a suggestions page where you can add or upvote content suggestions. It’s not been obvious where these suggestions go historically, so we’re actively trying to do a better job of linking these to corresponding Phabricator tickets, where we’ll post updates on our progress, so you can subscribe to tickets to learn more about how things are going with any particular organisation. If you want to stay up to date with new content available through the library you can also sign up to our newsletter. I also just want to take the opportunity to quickly note that in my capacity on Moderator Tools I created Wikipedia:Moderator Tools/Automoderator to provide opportunities for en.wiki input into our team’s current project.
This message turned out a lot longer than I anticipated, but I hope it's a helpful overview. Happy to answer any questions you have about the library or anything I wrote above. Samwalton9 (WMF) (talk) 09:03, 13 October 2023 (UTC)Reply[reply]
@Levivich Instead of directly paying for content subscriptions like a typical library, we have agreements through which they provide us access for free. They see benefits from the partnership (more editors citing their content on one of the most popular websites in the world), and so we're usually able to convince them that it's in their interest to go down this route rather than charging us money. Samwalton9 (WMF) (talk) 15:30, 13 October 2023 (UTC)Reply[reply]
Sam, I just want leave a drive-by kudos for the entire TWL team. I'm not privy to the internal details, but having worked on partnership projects like this before, I can only imagine how chaotic this is. Every partner has its own rules, its own API, its own licensing quirks, its own level of commitment, its own level of technical (in)competence, its own collection of demonstrably stupid and broken things that it insists must happen. Am I close? While I often rant about how clunky some parts of the system are, I recognize the heroic job you folks are doing and the incalculably huge benefit TWL provides to wikipedia editors. Thank you. RoySmith(talk) 15:56, 13 October 2023 (UTC)Reply[reply]
Extremely well-put, Roy. ♠PMC♠ (talk) 17:35, 13 October 2023 (UTC)Reply[reply]
The library is the best development, by far, in my 17+ years of editing Wikipedia. Thanks to everyone who works on it. Espresso Addict (talk) 01:04, 15 October 2023 (UTC)Reply[reply]
Suggestion for TWL: Libraries buy licenses for digital versions of books they can lend to patrons. Consider a trial program to do the same for the TWL. Considerations:
Start with a small number of the most requested items and buy them.
Require a brief explanation from the borrower why they want to check out the resource. It could be a simple one sentence note such as: "I am writing articles on Albanian military battles in the 15th century".
To prevent hoarding, if a book is not returned by the return date, cancel the loan (if that's technically possible)
Use volunteers (editors) as gatekeepers, at least on this Wikipedia to save aggravation and distraction for WMF staff. Maybe someday WMF would fund a full time librarian but let's crawl before we walk.
Before checking out more books in the future, ask borrowers to point to work they did with their first loan. Again, a simple sentence or a few diffs would suffice.
Hi everyone – I’m Marshall Miller; I’m a Director of Product at WMF. I work with many of the WMF teams that build and maintain editing and reading experiences, including the Editing team, which is taking point on the Graphs extension, the Moderator Tools team, which operates The Wikipedia Library (please do check out the responses from Peter and Sam on those topics above), and other teams like Web, Mobile Apps, and Growth, each of which maintains parts of the software that I’m sure many of you use.
I’d like to address some of the overarching concerns raised in this RfC discussion about the foundation’s level of investment in technical infrastructure and software. I’ll explain below how we’ve made a deliberate shift this year to focus on the needs and ideas of experienced editors, but I know that even with that shift, it can continue to feel like key tools and features are neglected. I understand that feels demoralizing, and can lead to editor burnout. I can say that we’re striving to address that directly through how we spend our resources, and I’m hoping you all will notice the results in the coming months.
So to explain a bit how we’ve prioritized and budgeted this year – the product and technology area is the largest area of focus (both in terms of staff and budget allocation) at WMF. Much of that allocation is toward what we call “essential work” – which refers to the sort of maintenance, monitoring, upgrading, and fixing that keeps our sites running at a fundamental level and across hundreds of languages, including data centers, security, databases, etc. I know most everyone here knows that that kind of work is essential, even though much of it takes place behind the scenes.
Then there are the strategic parts of our work, which is about making substantial changes to how the software works. That work is laid out in this year’s annual plan. You can see that it says that this year, the Foundation’s plan is recentered around Product & Technology, and that we are prioritizing established editors over newcomers. We’re doing this because we know that the wikis depend on the most active volunteers, and that those volunteers have an outsized positive impact on the content. How we’re doing this is expanded upon on this page about the “Infrastructure” parts of the plan, and you can find further detail by following links on that page to the specific objectives and key results, and further detail on the budget here and here. It’s worth noting that the foundation committed to these priorities even while slowing overall budget growth for the foundation as a whole. And we’ve shared that these priorities are intended to be multi-year - meaning that this strengthened focus on our technical needs is meant to be the driving priority for the Foundation’s budget and plans in coming years.
I’d like to lay out some examples of outputs and upcoming priorities from the teams I work with, which I think show the current focus on experienced editors. These projects are all based on ideas and requests coming from experienced users, and are geared toward helping them have more efficient workflows, helping them be able to spend their time on the most important wiki work, and have control over how features are used on their wikis. If those don’t sound like the right priorities for experienced editors, we definitely want to hear how you see it. I think it’s also important to note that for each initiative in this list, knowledgeable and interested community members have been involved in the planning and design throughout – this helps us make sure that the plans to invest in experienced editors’ workflows will actually make a difference to them.
New Pages Patrol / PageTriage: after the open letter from new page patrollers about the PageTriage software, the Moderator Tools team worked with patrollers to modernize the software so that future improvements and bugs can be much more easily addressed. The new version of PageTriage entered production this past week.
Discussion Tools: over the past year and a half, the Editing team has rolled out the many parts of the “Discussion Tools” project, which added the “reply” button on talk pages and the ability to subscribe to specific threads on a long talk page, among other features to make it efficient to engage in conversation on the wikis. About 2.6 million edits have been published with the reply button, with 79% of those being made by users with over 100 edits. And for newcomers, data analysis has shown us that these tools have increased the quantity and quality of the comments they make on talk pages.
Dark mode: having a “dark mode” for Wikipedia has persistently been a top wish in the Community Wishlist, and it is prioritized in this year’s annual plan and currently under development, along with the ability for readers and editors to choose their preferred font size. We’ve heard from many community members that these changes will make both reading and editing Wikipedia a more comfortable and accessible visual experience.
Patrolling on Android: the Mobile Apps team is building a way for patrollers to easily patrol edits from the Android app, meant to give patrollers more options and opportunities to do their wiki work on their mobile device.
Watchlist on iOS: the Mobile Apps team introduced the watchlist on the iOS app this past week, which gives experienced editors a new way to monitor important pages from their phones.
Edit Check: we’ve heard from many experienced users and wishlist proposals that software could help prevent or improve low-quality edits from newcomers, which experienced users then have to correct or revert. To address this, the Editing team is building “Edit Check”, which is going to start out by automatically warning newer editors when they have added information without a reference, encourage them to add a reference, and then check whether their reference comes from a dubious source. This is meant to decrease the burden on patrollers while also teaching newcomers how to add reliable information. As of this past week, Edit Check is now being tested on several small pilot Wikipedias.
Automoderator: English Wikipedia and some other large wikis have benefited tremendously from bots that automatically revert clear vandalism, like ClueBot NG. This takes a major burden off of patrollers and frees up their time. The Moderator Tools team is working to bring that capability to other language wikis that don’t currently have any of those sorts of bots, so that their patrollers can also focus on more challenging problems.
Community Configuration: when WMF builds features, it is common that different wikis want the feature to work in different ways. We want experienced volunteers who know their wikis well to have control over how a feature works on their wiki – instead of WMF being the sole keepers of that control. The Growth team is building Community Configuration, which is a way for administrators to specify aspects of how a feature will behave for all the users on that wiki. This is currently implemented for the Growth features, allowing English Wikipedia administrators to specify, for instance, which sorts of edit suggestions newcomers receive. With the work being done here, administrators will be able to similarly configure many of the other features listed above, like Edit Check and Automoderator.
Commons Upload Wizard: among multiple community concerns being addressed around Commons are upgrades to the upload wizard. These upgrades will help newcomers load content appropriately to Commons, guiding them toward making the right designations about licensing so that Commons patrollers can more accurately make deletion decisions.
That list touches on some of the projects specifically geared toward experienced editors, and does not include items addressed through the Wishlist process (more updates to come on how that process is evolving to better meet community needs). I hope that many of you follow along with the above projects in which you’re interested so that you can weigh in and help guide them.
How does this all sound? Does this approach make sense? What thoughts or concerns do you have about the work or the prioritization? -- MMiller (WMF) (talk) 04:55, 23 October 2023 (UTC)Reply[reply]
Hello, I’m Runa Bhattacharjee, Senior Director of Product for Languages and Content Growth. I oversee the Community Tech team, which runs the annual Community Wishlist Survey. I am based in India.
The wishlist is an important avenue for the Foundation to understand and address the technical needs of volunteers. While the Community Tech team is tasked with a prioritized list of wishes during the year, they are not the only team who supports this work. More than 20 teams across our Product and Technology department support the wishlist process right from evaluating the incoming wishes, providing technical input, responding to dependent technical debt, infrastructure support, and various kinds of reviews. These teams also work on wishes and provide maintenance work for completed wishes as a core function of their roles. Periodically, the teams also gather (virtually) multiple times a year for dedicated wish completion sprints. Going forward we would like to do a better job of highlighting how editors' priorities expressed through the wishlist make it to teams across the Wikimedia Foundation.
To give you a few examples of recent work done through this setup:
Auto-save feature now known as Edit-Recovery Feature that saves wikitext and other edit form information while typing, and allows for restoring it after the browser has been accidentally closed, or a power or network outage or browser crash.
Realtime preview that allows users using the 2010 wikitext editor to preview the page in real time when editing.
Rewrite XTools - a project to update and maintain XTools, the wiki curation and moderation tools originally developed by User:X! and rewritten by User:Hedonil.
Watchlist Expiry that allows users to watch pages for a limited period of time.
Recently at Wikimania I heard from volunteers their appreciation and support for the community wishlist survey process. At the same time some voiced their frustration and concerns about the process the way it is now.
Advanced editorial role responsibilities are growing across languages, regions, and affiliate needs. Besides a growth in volume of technical issues, there is also an increase in the technical complexity in the issues that the editors are bringing to our notice. It is important that we help connect the dots and make the necessary improvement within the Wikimedia Foundation so that editors' priorities expressed through the wishlist make it to formal priorities listed in our annual plan to make sure they are resourced and tracked more impactfully.
We have begun a process to improve and redesign the wishlist survey, with the objective to have an effective response system in place for the technical requests we know are of high importance like critical editor workflows. In the coming weeks, I’ll be sharing more information about how the wishlist will evolve.Runa Bhattacharjee (WMF) (talk) 18:35, 2 November 2023 (UTC)Reply[reply]
Procedural query If proposals 1 and 2 pass, would they pass with the wording The English Wikipedia community is [...], because frankly ~40 in favor with ~20+ opposed is not representative of the English Wikipedia community (at least of those who are participating here) especially when compared to the overwhelming support in favor of proposal 3. Curbon7 (talk) 02:30, 25 November 2023 (UTC)Reply[reply]
My understanding is yes; while the support isn't as extensive as for #3, approximately twice as many editors support #1 and #2 as oppose it and so in my opinion it is still appropriate to say that the English Wikipedia collectively - though not unanimously - supports this position.
For a different example, we still say that the Arbitrators are elected by the English Wikipedia Community, even though some receive less than 2/3rds support. BilledMammal (talk) 03:39, 25 November 2023 (UTC)Reply[reply]
Correct. Although this does also highlight the fact that we may need to make this page more accessible to editors in general - My first year at wikipedia, I dont think I even knew this page existed. If you look at the discussion above, the experience amongst editors is much higher than what would be typical of wikipedians - Which can be a benefit and a hinderance both. Captain Jack Sparrow (talk) 13:06, 25 November 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Post-close
A small note of elaboration. I have determined that the Wikipedia Village Pump has issued the three non-binding resolutions, due to the support of discussion participants outweighing opposition. I have not stated whether this is supported by English Wikipedia, and the absence of reference to the Wikipedia community in the closure statement should not be seen as summarising the discussion. There is clear support that this discussion page supports these resolutions, with the third resolution being supported especially strongly.
The English Wikipedia community is concerned about the distribution of grants related to activity on the English Wikipedia that will either not contribute to our goals of building an encyclopedia or will actively hinder those goals. We request that the Wikimedia Foundation informs the English Wikipedia of all non-trivial grants that will result in activity on the English Wikipedia through the opening of a discussion at the Village Pump (WMF) prior to the grant being issued.
The English Wikipedia community is concerned that the Wikimedia Foundation has found itself engaged in mission creep, and that this has resulted in funds that donors provided in the belief that they would support Wikimedia Projects being allocated to unrelated external organizations, despite urgent need for those funds to address internal deficiencies. We request that the Wikimedia Foundation reappropriates all money remaining in the Knowledge Equity Fund, and we request that prior to making non-trivial grants that a reasonable individual could consider unrelated to supporting Wikimedia Projects that the Foundation seeks approval from the community.
The English Wikipedia community is concerned that the Wikimedia Foundation has neglected critical areas of the project, and that continued neglect of these areas may endanger the project. To improve the resilience of the project, we request that money be reallocated to hiring more technical staff, whose role will be to fulfill requests from the community such as those expressed on the Community Wishlist, as well as restoring access to tools such as grapher extension. To improve knowledge equity we also request that that the Foundation provides funding to assist established editors in accessing the resources they needto improve the encyclopedia, such as by increasing the number of libraries accessible through the Wikipedia Library and by giving micro-grants for the purchase of backlogged items at Resource Request.
I'm still quite peeved that statement 2 directly targets the KEF for liquidation. It just seems unproductive to phrase it that way, which is a shame because the first portion of statement 2 raises a solid point regarding the apportionment of WMF funds. All I'm saying is it would have been far more productive to request that the WMF focus on WMF projects first for funding rather than just saying "Nuke it!!!!". Curbon7 (talk) 18:02, 24 December 2023 (UTC)Reply[reply]
The resolutions can be amended by consensus as well. Onetwothreeip (talk) 21:50, 24 December 2023 (UTC)Reply[reply]
For clarification, I'm not just whining because my position did not achieve consensus. I am well-aware that my support of the KEF is a minority position here on en.wp. I'm just trying to say that there is a more tactful way to word that statement. Curbon7 (talk) 05:37, 25 December 2023 (UTC)Reply[reply]
@Onetwothreeip, I'm concerned regarding the lack of coverage regarding opposition for the resolutions in your close. Please consider amending it to be more detailed in summarizing the discussion rather than only providing a broad result. Additionally, I see in the discussion that while there is a numerical consensus for the resolutions, there are also quite reasonable arguments opposing it. I encourage you to weigh the content of the discussions rather than merely the quantitative !votes. (involved) — Frostly (talk) 04:39, 25 December 2023 (UTC)Reply[reply]
I believe I have implied that there was more opposition to the first and second resolutions than there was to the third resolutions, without giving undue weight to that opposition. I have been purposefully concise to avoid amplifying any particular arguments.
Regarding the opposition to the first two resolutions, I could not find any objective reason to weigh the minority view disproportionately in its favour. There is much less scope to weigh the minority view greater than the majority view in a non-editorial discussion such as this, where editing policies don't apply. As a neutral closer, I cannot find (or should disregard) that one argument is subjectively or arbitrarily better than another, though I do not mean to suggest that I think you are saying I should. I can add the underlined to the closure comment. Onetwothreeip (talk) 06:04, 25 December 2023 (UTC)Reply[reply]
Wait what? (involved): 1. I thought this closed like two months ago? 2. I have determined that the Wikipedia Village Pump has issued the three non-binding resolutions, due to the support of discussion participants outweighing opposition is the least best closing rationale I've seen outside AfD. Folly Mox (talk) 04:48, 25 December 2023 (UTC)Reply[reply]
It did close a while back, was reopened, and then archived without close if I remember correctly. And now reclosed. Captain Jack Sparrow (talk) 05:07, 25 December 2023 (UTC)Reply[reply]
I closed it and the close was overturned. Honestly this RfC is so stale I doubt the WMF will draft a response to it. Mach61 (talk) 05:25, 25 December 2023 (UTC)Reply[reply]
There is simply not much more to say. There is greater support for the three resolutions than opposition, not only in number but in relative weight as well. I have elaborated above that there is a lack of any compelling reason to give disproportionate weight to the minority view, rather than a reason to not do so. Onetwothreeip (talk) 06:11, 25 December 2023 (UTC)Reply[reply]
I could have been a lot kinder in my characterisation of your closing rationale, but what about identifying common themes, subtopics, and rationales? I thought a close was supposed to summarise the discussion. See example. Folly Mox (talk) 07:09, 25 December 2023 (UTC)Reply[reply]
I appreciate that discussion closures can be longer, but I did not feel it was appropriate in this case to summarise the points of the discussion. Unlike closing a discussion for an editorial dispute, determining the reasons for the consensus wouldn't provide further editing guidance. The unusually lengthy closure comment in your example helps editors contribute to the article further than the direct question being discussed. There is not much more to summarise this discussion than editors choosing to support these resolutions, and I aim to avoid expressing an opinion on which reasons are good or bad. I would encourage anybody to summarise the arguments of the discussion. Onetwothreeip (talk) 07:53, 25 December 2023 (UTC)Reply[reply]
I think for long RFCs, long closes are better. Part of a good close is summarizing the discussion. The participants need to feel like you read everything and understood it, and enough of the closer's thought process needs to be disclosed to make the participants feel like the close is within closer discretion. –Novem Linguae (talk) 11:40, 25 December 2023 (UTC)Reply[reply]
Summary: Resolutions supported due to discussion participants' concerns over Wikimedia Foundation funds being provided for non-encyclopaedia initiatives, funding of activities which cause article quality issues requiring editors to resolve, lack of notice to the community regarding grants being awarded, and desire for technical upgrades to Wikipedia. Onetwothreeip (talk) 01:37, 26 December 2023 (UTC)Reply[reply]
I have determined that the Wikipedia Village Pump has issued the three non-binding resolutions, due to the support of discussion participants outweighing opposition. I have not stated whether this is supported by English Wikipedia, and the absence of reference to the Wikipedia community in the closure statement should not be seen as summarising the discussion.
I find this a little confusing - it makes it unclear to me how the support of the Wikipedia community could ever be determined, if a CENT-listed RfC in the Village Pump is insufficient to do so. I think it would be helpful to close this as we would any other global discussion; simply stating whether this or isn't a consensus, without making the consensus limited to a specific area that doesn't reflect the true scope of the discussion.
Would you be willing to update the close to do so? BilledMammal (talk) 03:54, 30 December 2023 (UTC)Reply[reply]
It is certainly unclear how the support of the Wikipedia community can be determined, without far greater participation. There have been discussions and votes on Wikipedia with hundreds of supporters (38, 45 and 78 supporters for these three resolutions). I found consensus for these resolutions, but there is not enough to say that the Wikipedia community supports the resolutions directly. Instead, it can be said that the Wikipedia Village Pump believes that English Wikipedia should issue these resolutions. I am willing to update the close to describe that this is not limited to a specific area, but neither should it be implied that it is unlimited. Onetwothreeip (talk) 05:04, 30 December 2023 (UTC)Reply[reply]
I am willing to update the close to describe that this is not limited to a specific area, but neither should it be implied that it is unlimited.
Can you specify how you would update it?
It is certainly unclear how the support of the Wikipedia community can be determined, without far greater participation
In the past, a CENT-listed RfC at the village pump that comes to a consensus on the question asked. Can you clarify on what basis, and what policy or guideline supports that basis, that lead you to decide that it was insufficient in this case? BilledMammal (talk) 05:41, 30 December 2023 (UTC)Reply[reply]
It can be described that the consensus is not necessarily limited to this talk page, but the closer can't determine the extent of the consensus beyond what they can see in front of them. I did not decide that anything was insufficient in this case and I made no decisions about how the Wikipedia community feels. The close was purely regarding how this talk page feels. Onetwothreeip (talk) 23:26, 30 December 2023 (UTC)Reply[reply]
It was listed on T:CENT and had at least 78 participants. I do not think that saying It is certainly unclear how the support of the Wikipedia community can be determined, without far greater participation is accurate. To request any higher sets the bar way too high, to a number that is unachievable, imo. This was, by all measures, a well-attended RFC that was advertised in all the places necessary to make it a community-wide consensus rather than a local consensus. –Novem Linguae (talk) 00:42, 1 January 2024 (UTC)Reply[reply]
@Onetwothreeip: I agree with Novem Linguae here; I think your close was broadly appropriate, except where you try to say that there was only a local consensus; I don't believe that such a statement is supported by policy. Would you be willing to adjust your close, or failing that revert it and allow another to close? BilledMammal (talk) 15:17, 4 January 2024 (UTC)Reply[reply]
Well I don't say that it's only a local consensus, it just can't be determined how broad the consensus is. If the resolutions had a thousand supporters for example (rather than thirty-eight), it would be much easier to determine a project-wide consensus. I could add this detail to the closure comments. Onetwothreeip (talk) 21:17, 4 January 2024 (UTC)Reply[reply]
I feel like if you believe this, you should close the entire RfC as no consensus. That's generally what closers have done when they feel a higher quorum is necessary to justify changes. Mach61 (talk) 05:44, 30 December 2023 (UTC)Reply[reply]
I don't believe that a higher quorum is necessary. There is enough consensus here to determine that the Village Pump supports these resolutions. Onetwothreeip (talk) 23:28, 30 December 2023 (UTC)Reply[reply]
The difference between this and other RfCs is they don't explicitly claim to speak on behalf of the entire website/community. There have been very few other RfCs along those lines before, and they've more often been styled more like an open letter, or have gotten more support than these got (e.g. the SOPA/PIPA blackout). I'm involved, of course, but it does seem like a good point that if the RfC is framed as speaking for the entire Wikipedia community, it's setting itself up for failure because it would need a high degree of participation to be justified. Even if it's listed at CENT, if only a small number of people support something it's hard to close as consensus on behalf of the entire site. IMO the discussion didn't need unarchiving and closing. The WMF has certainly already seen it, has seen that there was more support than opposition, and has seen the arguments on both sides. — Rhododendritestalk \\ 15:37, 30 December 2023 (UTC)Reply[reply]
Wikimedia's financial health
Wikipedia:Wikipedia Signpost/2023-11-20/News and notes has a update on Wikimedia's financial health, including an audit report for FY2022–2023. Income is up $25m at $180m. Expenses are up $23m at $169m, including salaries up $13m to $101m and hosting up $0.4m to $3.1m. Certes (talk) 11:35, 21 November 2023 (UTC)Reply[reply]
Proposal: add user-defined Common edit summaries to Preferences
I'd like to propose an enhancement to Preferences to add a feature enabling a user to enter a list of their own commonly used edit summary phrases, and then present them in the "Common edit summaries" dropdown that appears in Preview mode below the Edit summary input field.
In my case, I rarely use any of the potted ones, but I do have ones I use all the time, and this would be a real productivity enhancement. Probably one set per namespace to match current dropdown functionality, but just implementing mainspace would be a good start. (If I had my choice, I'd have the offerings be additive, i.e., organized as checkboxes, or permit multiple choices in the dropdown via Ctrl+select so I could assemble my edit summary by picking several, but this is probably a separate proposal.) Extra credit: in Preferences, if my custom edit summary list is empty, then prepopulate it grayed out with my top ten summaries in my last 500 edits (or top seven, as mainspace common summaries dropdown length is now). In the Preview mode dropdown, place user-defined list at the top, and if not fully filled out, then fill in remaining slots below from the potted summaries. When the cheers die down, extend to other namespaces. Mathglot (talk) 23:28, 21 November 2023 (UTC)Reply[reply]
Does your browser not save them for you? Firefox does for me, so all I need to do is start typing and then select from the options FF gives me. Nthep (talk) 14:22, 22 November 2023 (UTC)Reply[reply]
Editting the desktop site via mobile and the keyboard does all this for you, including narrowing selection based on what has already been typed. Most of my summaries take no more than two or three taps. -- LCU ActivelyDisinterested«@» °∆t° 20:45, 22 November 2023 (UTC)Reply[reply]
I use section edits almost exclusively (for many reasons, including ease of use, faster, fewer ec's, etc.) and the browser suggestions have to match from the very first character. For this section, it has to match /* Proposal: add user-defined Common edit summaries to Preferences */ which means there aren't any, except for my OP and further edits here. Same thing in, say, Mainspace or User talk space, where this feature would be really handy, and where browser suggestions help barely at all. Mathglot (talk) 00:32, 23 November 2023 (UTC)Reply[reply]
Copy and pasting are also easier on mobile. I cut the section details get the summary I need, and paste the section details back at the front. -- LCU ActivelyDisinterested«@» °∆t° 20:35, 23 November 2023 (UTC)Reply[reply]
Wikimedia Foundation banner fundraising campaign on English Wikipedia starts next week
Dear all,
The WMF is running its annual banner fundraising campaign for non logged in users in Australia, Canada, Ireland, New Zealand, the UK, and the US from 28th of November to the 31st of December 2023.
Thank you to everyone who has worked together to prepare the campaign this year! We’ve built up the collaboration process this year on the community collaboration page, at in person events (e.g. Wikimania and WikiCon North America), and in other individual discussions. More information around the campaign, like example banners and messaging, can be found on the community collaboration page. We continue to welcome ideas on the page.
Some more resources around the fundraising campaign:
It's starting now? Then why have we had banners up for a month or so? There have been complaints here and at the Teahouse. Edward-Woodrow (talk) 19:04, 26 November 2023 (UTC)Reply[reply]
Many thanks for all your hard work this year, for both you personally Julia and the entire team. Best, KevinL (aka L235·t·c) 07:35, 29 November 2023 (UTC)Reply[reply]
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
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)Reply[reply]
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)Reply[reply]
"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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
I don't think it's clear from the comment whether the IP user understands that Wikipedia is written by volunteers and feels that the consequent cost saving makes requesting donations unnecessary, or if they think we ask for money and are refused. Certes (talk) 22:36, 25 December 2023 (UTC)Reply[reply]
#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)
Is it productive to post these here? This feedback doesn't seem very actionable. –Novem Linguae (talk) 13:32, 20 December 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
VTRS gets loads of emails on similar lines to the posts quoted above. Nthep (talk) 13:21, 21 December 2023 (UTC)Reply[reply]
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)Reply[reply]
"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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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.
My usual device is not working, so I tried editing off of Safari (I did sign up for the NPP backlog drive, after all). Genuinely unusable. Probably going to take a break until it's fixed. DrowssapSMM 22:41, 2 January 2024 (UTC)Reply[reply]
Calling @Folly Mox, who knows about editing on the mobile site. Unfortunately, there's no central noticeboard or other page where mobile-based editors congregate. WhatamIdoing (talk) 03:00, 3 January 2024 (UTC)Reply[reply]
Perhaps there could be - is this suitable for a project, or do they have to be about articles? Newystats (talk) 22:04, 15 January 2024 (UTC)Reply[reply]
My experience (as a frequent iPhone user) is that m.wiki is very good for reading pages (better than Vector is on desktop, actually), serviceable for copyediting and projectspace discussions, and very bad for expanding articles (no tools like ProveIt for citations, and switching between the article and the sources is harder with mobile browser tabs). Vector 2010 holds up surprisingly well for editing, seeing as it wasn't mobile-optimized at all, but is a much worse reading experience. Mach61 (talk) 03:06, 3 January 2024 (UTC)Reply[reply]
(responding to ping) I do like the mobile web experience for the most part, and don't really find any part of it particularly burdensome or uncomfortable. I've been a fully mobile editor since the death of my last computer in summer 2022, but I must confess almost complete unfamiliarity with most advanced editing tools. I've never applied for the NPP perm, but having a look at Special:NewPagesFeed just now, it seems essentially identical between Minerva and Vector 2022.There are, of course, some tasks that are more difficult: I can't run two browser windows sidey-side with a source in one and an open editing interface in another, but it is a bit more convenient that I can hold my phone flat against the opposing page of a physical book if I'm using one of those. Most scripts don't support Minerva, so I'll have to hop into desktop view if I want to use Rater or Prosesize or many functions of Twinkle, and the limited RAM of a mobile device has led me to uninstall scripts that have some utility because the additional javascript load times weren't worth it. And of course the input is typically a bit slower on a cell phone keyboard than the usual kind, but the predictive text helps to an extent (I never have managed to figure out swipe typing).Essentially though, genuinely unusable is so nonspecific and unactionable that I don't know what to say or how I could help. This reminds me of another recent complaint at VPI, which suggested the mobile frontend was "uncomfortable" without specifics or further elaboration. That's not a way to get functional help or to suggest software improvements. User:DrowssapSMM, I hope your computer gets fixed soon, but do you have any examples of specific tasks you were unable to complete using your mobile device, and what it was in particular that made them impossible for you? Folly Mox (talk) 12:33, 3 January 2024 (UTC)Reply[reply]
@Folly Mox I edit a lot on an Android phone and find that I keep changing between different interfaces, voluntarily or involuntarily, to get different functionality: If I want to look at an editor's contributions I have to get their user page, opt for "Desktop view" and then look at the contributions list. If they haven't created a user page ... I have to find something they've edited, find a version which gives a "contribs" link alongside their username as part of the diff, etc. There is one ghastly state I sometimes fall into where the font size increases with every keystroke so it's very soon impossible to do anything at all and I have to abandon the edit.
It seems impossible to contribute to some talk page discussions, I think Wikipedia Project talk pages mostly, though I can contribute to article and user talk pages. If I want to add to the end of the automatic edit summary after doing an "undo", I often struggle to scroll along to its end, if it's longer than the input box: sometimes it will move, sometimes not, possibly dependent on what scale Ive zoomed it to.
It's altogether a somewhat unpredictable and stressful experience, but I keep on doing it because I can use the phone in places where I don't have my computer, such as sitting on the sofa, semi-sociably half-watching something on the television. PamD 17:08, 3 January 2024 (UTC)Reply[reply]
PamD huh, I have encountered zero of those problems using Firefox on Android with "advanced" mode in my mobile preferences. Contribs are available at the page header of User: and User talk: pages, I can tap "read as a wiki page" to view and edit Wikipedia talk: conversations, and my typeface size has never increased outside a pinch zoom. I could see an Undo diff preview being uncomfortably long, but have never had a problem getting the screen to scroll. Folly Mox (talk) 17:18, 3 January 2024 (UTC)Reply[reply]
Hmm, I use Firefox on desktop but Chrome on phone. Perhaps I should try Firefox on the phone. PamD 18:08, 3 January 2024 (UTC)Reply[reply]
You might find this page useful: User:Cullen328/Smartphone editing. I do a lot of editing while mobile (such as now!) and I find the desktop version of Vector 2010 to be the best interface for it. Barnards.tar.gz (talk) 17:26, 3 January 2024 (UTC)Reply[reply]
I mean, maybe, and I'm not sure of any other high profile mobile editing user essays, but the takeaway from the linked essay (briefly: desktop view, landscape orientation) is the exact opposite to how I edit, and I get on fine. It's really up to personal preference (and Special:Preferences) except in some edge cases, like viewing navboxes or the source of a fully protected template. Folly Mox (talk) 03:22, 4 January 2024 (UTC)Reply[reply]
Mobile editing is terrible, but for me even mobile reading (Samsung Galaxy A50, Chrome) is nearly impossible since a few weeks. And then there are the strange things on Mobile view even when seen on a desktop. E.g. the right side of the translate box at the top of this is a clear "show", while the same in mobile view has a "show" which for some reason fades out to the right. The watchlist in mobile uses way, way too many lines (4 or 5 per entry for no good reason), where "thank" is a too big button and "rollback" is a lot smaller and without a border (on desktop view they are nicely aligned and formatted).
This is simply brilliant. Above the diff, it shows the legend: "Content added" in a blue box, "Content deleted" in a yellow box. Below, the actual diff, shows content added against a green background, and content removed against a red background. Phew, good thing I had the legend... Oh, but perhaps because I look at it in Wikitext and not in Visual? Er, no, when I make that switch, the added text is shown against some green-bluish hue, not the same as the "content added" box at all, and the removed line is no longer visible.
Editing? I can't edit a complete page in mobile, if I use the "edit" pencil at the top I only get the lead. E.g. swapping two sections is not possible (or at the very least not intuitive) this way. Doing this in desktop mode is straightforward. Doing all this also reminded me of one of the reasons why Visual Editing is such a pain in the ass. Changing a short description in wikitext is "click edit, change shortdesc, save". Doing this in VE is "click edit, scroll up (!), click short desc icon, click edit again but now at the bottom, change shortdesc, save, save again because you only "saved" the template change". Fram (talk) 19:19, 3 January 2024 (UTC)Reply[reply]
I use to edit using the mobile version on my phone a lot. ... no longer do so...instead I switch to desktop mode on my phone. There is a link at the very bottom of every page to change to desktop view and back. Moxy- 20:06, 3 January 2024 (UTC)Reply[reply]
There's a script that will force the desktop version as well, useful if you're googling something and end up following a link back to Wikipedia. -- LCU ActivelyDisinterested«@» °∆t° 01:11, 4 January 2024 (UTC)Reply[reply]
An "edit full page" option for mobile was added a few months ago, in the vertical ellipsis menu in the upper right, with the rest of the page tools. Swapping sections seems pretty identical (cut-paste). I don't see the same blue / yellow legend boxes in inline diff mode, which might be the result of a user preference. Folly Mox (talk) 03:18, 4 January 2024 (UTC)Reply[reply]
I get the exact same look when I log out, so not the result of a user preference. Fram (talk) 09:39, 4 January 2024 (UTC)Reply[reply]
After checking the linked diff logged out in three separate browsers, I haven't been able to view the "content added" / "content removed" legend in either source or visual mode, so it doesn't seem like it's one of my user preferences either. Folly Mox (talk) 12:11, 4 January 2024 (UTC)Reply[reply]
Looks like the legend hides if your device is 1000px wide or smaller. Which may explain why it hasn't been noticed that MobileFrontend overrides MediaWiki core's diff colors but not the colors in the legend. Compare this desktop diff (again, in a browser with a width >1000px) where the legend and colors do match. Anomie⚔ 12:38, 4 January 2024 (UTC)Reply[reply]
Seconding the concern that editing pages on mobile in Firefox gives a bizarre situation where editing the entire article only gives you the lead section. I figure this might be some weird user preference but it always annoys me a lot. In general, the mobile editing experience leaves a lot to be desired, although I'll confess I do not have a lot of concrete suggestions. It does seem like the mobile website downplays the editor-created nature of the site a lot (i.e. history and the like are often hidden). jp×g🗯️ 08:46, 6 January 2024 (UTC)Reply[reply]
JPxG, the edit pencil at the top of an article opens only the lead. "Edit full page" is collapsed inside the vertical ellipsis menu in the upper right, along with Special:WhatLinksHere, Special:PageInfo, et al. This is a recent change (feels like second two thirds of 2023; I'll see if I can find the date). Folly Mox (talk) 12:40, 6 January 2024 (UTC)Reply[reply]
1 August, as part of MediaWiki 1.41/wmf.20, pursuant to phab:T203151, but apparently this option is only available if you enable "Advanced" mode in Special:MobileOptions. I think not having this mode enabled probably severely cripples the editing experience (link anchored to "1 August" above has the deets). Folly Mox (talk) 12:54, 6 January 2024 (UTC)Reply[reply]
Computer is fixed, so it doesn't really matter all that much anymore. I just couldn't deal with mobile diffs. DrowssapSMM 12:10, 4 January 2024 (UTC)Reply[reply]
Screenshot added. Also note the ridiculously large footer (which extends further to the right than the actual page, poor layouting once again) Fram (talk) 12:23, 4 January 2024 (UTC)Reply[reply]
Illustrate a mobile view anomaly on Wikipedia
Another screenshot, showing the weird "show" (bottom right) fade out. Very artistic. Fram (talk) 12:28, 4 January 2024 (UTC)Reply[reply]
Separately from any issues with it, the mobile view has the appearance of something that is a decade or more out of date. I would hope the WMF are working to consolidate around one appearance that scales across devices and different screen sizes. Working on each separately at this point would be a waste of resources. -- LCU ActivelyDisinterested«@» °∆t° 19:45, 4 January 2024 (UTC)Reply[reply]
I don't think I share that hope. Having one or more giant screen, with a keyboard + mouse input setup, and the ability to have multiple apps open in a single view, is a fundamentally different experience to a vertically oriented, cramped, "one app at a time", "long-press contextual menu instead of shortcut keys", "keyboard input necessarily occludes a non trivial portion of the screen" kinda situation.Also there are pretty big differences in system resources. I really should replace my phone soon, but my device memory is such that even if most gadgets and userscripts were supported in Minerva I'd still disable them due to the overhead of loading all the javascript. I only enable Twinkle if I have to restore an old revision or AfD an article.I'm sure that Minerva probably looks old and busted viewed full screen on a desktop monitor, but on a mobile device it does a good job giving the page contents most of the screen real estate and keeping the other elements out of the way until needed. Folly Mox (talk) 18:00, 6 January 2024 (UTC)Reply[reply]
Minerva probably looks old and busted viewed full screen on a desktop monitor – before Vector 2022, before even Wikiwand, I understand that how to switch to Wikipedia's "secret" mobile view periodically made the rounds on social media. Reportedly, people thought it was easier to read. It's not my own personal favorite, but that doesn't mean those people are wrong. WhatamIdoing (talk) 23:02, 6 January 2024 (UTC)Reply[reply]
It's altogether possible that what looks "fine and normal" to me actually looks a decade or more out of date to younger eyes. That probably applies to most of the things I own and uh me. Folly Mox (talk) 23:21, 6 January 2024 (UTC)Reply[reply]
Central banner for a Commons contest to photograph the culinary diversity of Bengal
A photographic contest is going to happen from 15th January, 2024 to 14th February 2024 on Wikimedia Commons to enrich the photographic content Bengali culinary diversity and a central notice request has been placed to target English Wikipedia users including non-registered ones from Bangladesh and the Indian states of West Bengal, Tripura, Assam, Sikkim and Jharkhand. Thanks. -- Bodhisattwa (talk) 06:33, 9 January 2024 (UTC)Reply[reply]
Edit summary spam
I'm sure this must be a perennial chestnut but what's the best way to handle edit summary spam? I see an increasing number of edits like this which commit trivial vandalism, a dummy edit or even a minor improvement but their main effect and likely purpose is to pollute the page history permanently with a commercial break. They generally do not qualify for revdel. Do we simply ignore them per WP:DENY? Certes (talk) 12:55, 9 January 2024 (UTC)Reply[reply]
@Certes revert, block as needed. If there is some excessive amount, no one is going to care if an admin revdel's them via RD5 embracing DELREASON 4. I wouldn't bother chasing after single ones for such revdel, same as we wouldn't bother chasing after revdeling spam in the page text. — xaosfluxTalk 15:01, 9 January 2024 (UTC)Reply[reply]
Also, if there become some recurring pattern - we can try to prevent them with abusefilters. — xaosfluxTalk 15:01, 9 January 2024 (UTC)Reply[reply]
I think it's worth remembering how few people actually look at the edit summaries, especially if it's not the edit at the top of the list.
Mass revdel does make that a lot easier for those up for the task. I'd definitely take the time if the edit summaries include links, I do that for user creation logs when I block promotional usernames. The Blade of the Northern Lights (話して下さい) 05:07, 11 January 2024 (UTC)Reply[reply]
change the description of an article
I entered the word "Triptych" and one of the possibilities that popped up was "Triptychs by Francis Bacon" with a note that they were painted between 1994 and 1986. I looked; that should be "between 1944 and 1986." How can this be fixed? J S Ayer (talk) 04:43, 10 January 2024 (UTC)Reply[reply]
@J S Ayer, it looks like that's the result of a simple accidental typo. You can see the edit that caused it here. You can fix it yourself, or you can ask Ffffrr to fix it. We all make mistakes occasionally, and it really helps if other people are willing to look out for the accidents and help fix them. WhatamIdoing (talk) 05:36, 10 January 2024 (UTC)Reply[reply]
Thank you! Never ran into that one before! J S Ayer (talk) 06:01, 10 January 2024 (UTC)Reply[reply]
Thanks for correcting the error. Ffffrr (talk) 11:52, 10 January 2024 (UTC)Reply[reply]
Fixed. Also updated the lead paragraph example to agree with the current version of the selected article.[10] — SMcCandlish ☏ ¢ 😼 16:56, 12 January 2024 (UTC)
Done with regard to those two. — SMcCandlish ☏ ¢ 😼 17:02, 12 January 2024 (UTC)
You are invited to join the discussion at Wikipedia:Village Pump (Idea lab) § Workshop: draftifying. 🌺 Cremastra (talk) 17:47, 13 January 2024 (UTC)
Write to me! 20:11, 13 January 2024 (UTC)
Write to me! 21:38, 13 January 2024 (UTC)
Pages that use the JSON contentmodel will now use tabs instead of spaces for auto-indentation. This will significantly reduce the page size. [17]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 January. It will be on non-Wikipedia wikis and some Wikipedias from 17 January. It will be on all wikis from 18 January (calendar). [21][22]
.jpg)
Courtesy link: User talk:Σ#Archiving in the context of a page that uses level-one headings as dividers
22:42, 13 January 2024 (UTC)
04:48, 14 January 2024 (UTC)
Thanks Geardona (talk to me?) 02:37, 14 January 2024 (UTC)
Thanks Geardona (talk to me?) 19:34, 16 January 2024 (UTC)
Mathglot (talk) 23:28, 21 November 2023 (UTC)
