Wikipedia

Wikipedia:Village pump (idea lab)/Archive 58

< Wikipedia:Village pump (idea lab)
Latest comment: 5 months ago by Just Step Sideways in topic Deprecate AFD subcategories?
Village pump (idea lab) archive  

This page contains discussions that have been archived from Village pump (idea lab). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62

Dealing with forum bloat

Latest comment: 6 months ago25 comments11 people in discussion

Some high-activity fora (in particular WP:ANI and WP:RSN) are so clogged with activity they become difficult to navigate and can even start to glitch and slow down web browsers. I think it’s a reasonable idea to break these down somehow, probably with case-based subpages. thoughts? Dronebogus (talk) 09:32, 4 June 2024 (UTC)

The main issue with RSN at the moment is that the very large at the top was restored from the archives. It needs to be closed, but that could have happened without it being restored. Anyone interested in closing it? -- LCU ActivelyDisinterested «@» °∆t° 15:41, 4 June 2024 (UTC)
I still think it’s emblematic of a larger issue— i.e. major fora working more akin to XfDs (lots of discussion and sometimes voting, more than enough for separate pages) but being treated like a simple noticeboard with minimal user interaction (i.e. Wikipedia:AIV) Dronebogus (talk) 16:48, 4 June 2024 (UTC)
There was a discussion about similar issues here on Village Pump, see WT:VPR#Looking for some unofficial clerks and Wikipedia:Village pump (technical)/Archive 209#SIZESPLIT but for Village pumps. I could see the same idea working, opportunistically creating subpages for large topics, but doing it in anyway automatically could cause issues. Especially on RSN the vast majority of posts get few is any replies, pushing them to subpages would only give them less visibility. -- LCU ActivelyDisinterested «@» °∆t° 17:00, 4 June 2024 (UTC)
I think the main solution for RSN is to insist that RSP proposals happen somewhere else. WhatamIdoing (talk) 17:01, 4 June 2024 (UTC)
We also need to do better at emphasizing what RSP is for (or perhaps stress what it ISN’T for). It has turned into a general RFC page for sourcing questions, and that was NOT the original intent. It is supposed to be a list of perennial sources (ie sources that are repeatedly discussed), not a comprehensive list of reliable/unreliable sources. Blueboar (talk) 12:59, 5 June 2024 (UTC)
Rename it to “perennial sources noticeboard”? Dronebogus (talk) 13:00, 5 June 2024 (UTC)
WP:RSP is the list of perennial sources, which doesn't seem to be particularly bloated or diluted. WP:RSN is the noticeboard that deals with questions about reliable sources - both determining the general reliability of frequently-used sources and whether a source is reliable in a specific context - that is very long. We need a place to discuss both types of question the RSN currently deals with and while that doesn't necessarily have to be the same place, there is sometimes overlap between them. I can think of two ways of reorganising that might help:
  1. Leaving all discussions as they are currently until they get to beyond a certain size, at which point they are moved to a subpage that is linked/transcluded from the main page (similar to how some VP and AN/I discussions are treated)
  2. Leaving RSN as is for small, specific discussion with new RFCs being their own subpage. There would be a (bot-maintained?) list of open (and recent?) RFCs at the top of the noticeboard, possibly similar to the recent ECP protections report at the top of WP:AN (but not collapsed) showing the title of the RFC, the source(s) being discussed, date and time initiated, number of comments and timestamp (and author?) of the latest comment and whether it is open or closed (and if the latter when it was closed and who by).
Thryduulf (talk) 13:34, 5 June 2024 (UTC)
It's a common problem that editors open discussions/threads about getting sources added to RSP that have been regularly discussed, they all get closed down quite quickly. Very few source have recently been added to RSP.
RSN isn't usually very long, it only gets so when specific discussions are ongoing. Dealing with those discussions as they happen seems a lot less bureaucratic then setting up a mess of transcoded bot maintained pages.
Also transcluding all pages to one page is worse than having all discussions on one page, all the translcuded text has to be displayed but now with the overhead of transclusion. If the issue on any page is difficulties in display due to size then transclusion is the opposite of the solution. -- LCU ActivelyDisinterested «@» °∆t° 14:17, 5 June 2024 (UTC)
I've thought about splitting ANI. My current favorite idea is to imagine that we split it according to the day of the week (Wikipedia:Administrators' noticeboard/Incidents/Monday, Wikipedia:Administrators' noticeboard/Incidents/Tuesday, etc.). Everything can get archived together, but you could watch just the one page that "your" discussion is on. Because most are resolved and archived in about two days, the page should be nearly empty by the time it rolls around again. Admins could sign up to deal with a defined fraction of the week's load and not feel like the firehose never stops. We might have less feeling that it's just overwhelming because there are "too many" sections on the same page. And maybe we'd see less emotional spillover, in which I'm so mad about this discussion that I'm too harsh about everything else on the page. WhatamIdoing (talk) 17:00, 4 June 2024 (UTC)
I know this is a minor thing and a bit of a tangent, but ANI is not only frequently large (50+ sections some days, despite aggressive archiving) but it has an unusually high number of revisions, which means that various tools like https://xtools.wmcloud.org/ don't work on it. Sometimes I think it would be a good idea to do an archiving-esque Move procedure on that page at the start of each year (or at least for each decade). WhatamIdoing (talk) 17:07, 4 June 2024 (UTC)
I really like this idea. And the built-in reminder it provides when a discussion has been open for a week (and two weeks) could have a salutary effect. Newimpartial (talk) 17:08, 4 June 2024 (UTC)
What about going the whole way and turning it into dated subpages like TfD or MfD? Each subpage would be transcluded at WP:ANI until all the discussions on it have been closed. This could have the side benefit of making ANI more outcome-oriented, which seems to be a common characteristic of our more functional noticeboards. – Joe (talk) 09:09, 5 June 2024 (UTC)
Subpages make it much more difficult for people to watchlist the page and become aware of new discussions. Currently you can subscribe to and/or watchlist the page and be alerted to new discussions. With daily subpages you have to explicitly visit the main page and look for changes, watchlist/subscribe to 365 individual pages per year and/or use a workaround equivalent to user:Thryduulf/RfD watchlist. A forum like ANI needs visibility to work. Thryduulf (talk) 10:12, 5 June 2024 (UTC)
It needs visibility from admins, and I don't think that will stop. Maybe the peanut gallery watchlisting ANI and showing up for every discussion is actually a bad thing. Wilhelm Tell DCCXLVI (talk to me!/my edits) 11:19, 5 June 2024 (UTC)
Agreed. The problem with ANI is that it's too visible. A person with ANI on their watchlist is a person we don't want participating in ANI (I'm joking... kind of.) – Joe (talk) 12:04, 5 June 2024 (UTC)
As a non-admin, I occasionally watchlist ANI when there's a discussion of particular interest to me, such as unconstructive editing that I've recently helped to deal with. I try not to do so regularly, because it would flood my watchlist with edits which are important to someone but largely irrelevant to me. I would love to have my watchlist show only updates to a particular section. (I'm aware of subscriptions.) Certes (talk) 13:54, 5 June 2024 (UTC)
The issue with that is we need consensus from uninvolved editors for a lot of proposed actions at ANI. Making it more difficult to keep an eye out for something you may be able to contribute to isn't going to make it better. Also, this is another chance for me to bang the Administration noticeboard, not Administrators' noticeboard drum. AN and ANI are not for administrators, they're for site administration. ScottishFinnishRadish (talk) 13:59, 5 June 2024 (UTC)
We don't seem to struggle to get a consensus of uninvolved editors at other high-volume venues that use subpages, like AfD, TfD/MfD, or DRV. Conversely, it is rare for discussions at those venues to turn into lengthy pile-ons, boomerangs, or unclosable trainwrecks. When was the last time you heard somebody complain that ANI is awful because there are too few opinion-havers there? – Joe (talk) 14:31, 5 June 2024 (UTC)
I've also seen many threads there which start with a small group of editors pushing for something, that later uninvolved editors push back on. With less visibility comes less oversight. As a new editor the other high volumes venues you mention certainly felt more cliquey with the same editors turning up in discussion on a very regular basis, something the other noticeboards didn't seem to have. -- LCU ActivelyDisinterested «@» °∆t° 14:45, 5 June 2024 (UTC)
You think that the average AfD, MfD, or DRV would meet a reasonable quorum of uninvolved editors to indefinitely block, topic ban, ban, or otherwise sanction an editor? AfD is chronically underattended, for example, and articles are often deleted or kept on the word of two or three editors. ScottishFinnishRadish (talk) 14:51, 5 June 2024 (UTC)
Yes. When the outcome is obvious at XfD, a few editors will participate and others will not see the point in piling on: this is a feature, not a bug, and something that we could well try to emulate in our user conduct processes. When they're controversial (as an ANI sanctioning an established editor would be), 10-20 participants is not uncommon. – Joe (talk) 15:06, 5 June 2024 (UTC)
It's difficult to measure people not posting a comment, but I can confirm what @Joe Roe says: I avoid "piling on" at AFD, especially when the outcome is to delete, because it's unnecessary and might feel hurtful to the article's creator. WhatamIdoing (talk) 03:55, 6 June 2024 (UTC)
Subpages make it much more difficult for people to watchlist the page
That's why I thought that /Monday, /Tuesday would be better than each day. People can manually click on seven buttons more easily than 365 (times however many years you wanted to pre-load). However, I believe there is a script-y kind of way to watchlist all the pages for (say) a calendar year, if someone really wanted to do that. WhatamIdoing (talk) 03:54, 6 June 2024 (UTC)
I'm not sure formally closing all discussions at ANI is a good idea. Currently most of the uncontentious stuff is "closed" by bot archiving; explicit human closes of everything could easily lead to increased bickering about discussion closures for "no one cares"/"no longer interesting"/"nobody wants to act on this"/"no action needed" discussions (usually it is not worth determining which of these is the case). —Kusma (talk) 15:19, 5 June 2024 (UTC)

possible idea; entry compiling overviews of multiple novels, in a single series

Latest comment: 6 months ago5 comments5 people in discussion

hi all. i made the article below in my own userspace, to compile plot summaries for all novels in a series, namely the Aubrey-Maturin series, by Patrick O'Brian. what do folks here think of this, as a possible model for a type of article?

as far as I know, there is no rule currently against this type of article, but I wanted to get a little feedback here, just to see what reactions or comments on this type of article people might wish to express.

appreciate any feedback. thanks! Sm8900 (talk) 14:05, 7 June 2024 (UTC)

I like the idea, but I don't really think Wikipedia would be the best project for it, as this is mostly based on summarizing primary sources. However, it would be great to envision this as a separate Wikimedia project, if that can be possible! Chaotic Enby (talk · contribs) 14:17, 7 June 2024 (UTC)
WP:NOTPLOT seems like the relevant guideline here. While an encyclopedia article on a series of books can be appropriate (and indeed we do have Aubrey-Maturin series) an article which does nothing but summarise the series, as this seems to be, would not be. Caeciliusinhorto-public (talk) 14:20, 7 June 2024 (UTC)
TV Tropes has recap pages for series {example} Mach61 16:52, 8 June 2024 (UTC)
That is very long. Maybe incorporating condensed synopses of each entry just like List of Black Mirror episodes vs longer summaries on each individual article into Aubrey–Maturin series#Series would be more appropriate. Aaron Liu (talk) 14:20, 7 June 2024 (UTC)

Proposed revision of the COI guideline

Latest comment: 6 months ago12 comments8 people in discussion

Our current Conflict of Interest guideline is 6000 words - or 0.2 tomats - long, and often ambiguous and confusing. To address this we have recently been discussing at WP:COI a replacement, and I'm opening a discussion here to get further input on it now that it has gone through a few rounds of revisions.

It is considerably shorter than the current guideline, at just 1000 words, and is intended to be clearer about what restrictions apply to which editors. The intention is that it would replace the current COI guideline; the current text would be moved to an explanatory supplement where it could be edited and pruned as appropriate. BilledMammal (talk) 18:06, 23 May 2024 (UTC)

Draft of the proposed guideline

To preserve the integrity, neutrality, and public trust in Wikipedia, it is crucial to effectively manage conflicts of interest among editors. A conflict of interest arises when an editor's personal, professional, or financial connections might compromise the objectivity of their contributions. This guideline outlines the types of conflicts and specifies the conduct required for editors who may be affected by them.

Financial Conflict of Interest

An editor has a financial conflict of interest when they stand to gain, or can reasonably be expected to gain, financial benefits from the coverage of a topic on Wikipedia. This conflict arises in various forms:

  • Direct Financial Benefits: These include receiving direct payment for editing Wikipedia articles.
  • Indirect Financial Benefits: Such benefits are not as overt as direct payments but are significant. Examples include:
    • Business Exposure: Gaining from increased visibility when a product, service, or company is featured in an article. For example, an editor who is a major shareholder or partner in a business could materially benefit from increased sales due to enhanced visibility of their product on Wikipedia. Conversely, an individual who holds a inconsequential stake, such as a small fraction of a percent of shares in a publicly traded company, would not be positioned to experience noticeable financial gains from such coverage.
    • Reputation Enhancement: Benefiting indirectly from an enhanced reputation due to having a personal article on Wikipedia or being prominently featured as an expert. This can lead to increased professional opportunities, such as book sales, speaking engagements, or consultancy work.

Non-financial Conflict of Interest

An editor has a non-financial conflict of interest when their personal or professional connections may compromise their ability to present a subject objectively. This type of conflict arises in various forms:

  • Personal Relationships: Editing articles about friends, colleagues, family members, romantic partners, or personal adversaries can lead to biased content, whether overly favorable or unduly negative.
  • Professional Connections: Editing articles related to one's employer or competitors in the industry can introduce biases that may either unfairly promote one’s own organization or undermine others. Similarly, citing oneself or ones close acquaintances as sources can introduce bias, influencing the content to unduly favor personal or professional interests.
  • Significant Roles: Editing articles related to organizations in which an individual holds a significant role, or recently held a significant role, may introduce biases and a lack of objectivity in content related to the organization's interests. This is a spectrum, with whether an editor has a conflict of interest depending both on the level of authority or influence their role granted them, and the recency of the role. For example:
    • A general volunteer for the Democratic Party would have no conflict of interest.
    • A precinct captain for the Democratic Party would have a conflict of interest for a few years after they hold the role.
    • A presidential elector for the Democratic Party would permanently have a conflict of interest.

Managing Conflicts

  • Editors with a Financial Conflict: Must not directly edit affected articles. Instead, they should propose changes using the Edit COI template, disclosing the nature of their conflict on their user page and in any location they discuss the topic.
  • Editors with Non-financial Conflicts: While not strictly forbidden from directly editing affected articles, transparency is required; they must disclose their conflict in the edit summary and in any location they discuss the topic.

Exceptions

Aside from those explicitly listed here, no exceptions exist to this guideline; edits must abide by it regardless of their perceived harmlessness or quality. Editors who wish to avoid disclosing their conflict of interest may do so only be avoiding topics affected by it.

General exceptions

  1. Reverting obvious vandalism—edits that any well-intentioned user would agree constitute vandalism, such as page blanking and adding offensive language.
  2. Removal of clear copyright violations or content that unquestionably violates the non-free content policy (NFCC). What counts as exempt under NFCC can be controversial, and should be established as a violation first. Consider opening a deletion discussion at Wikipedia:Files for discussion instead of relying on this exemption.
  3. Removal of content that is clearly illegal under U.S. law, such as child pornography and links to pirated software.
  4. Removing contentious material that is libelous, biased, unsourced, or poorly sourced according to Wikipedia's biographies of living persons (BLP) policy. What counts as exempt under BLP can be controversial. Consider reporting to the BLP noticeboard instead of relying on this exemption.
  5. Reverting unambiguous spam, where the content would be eligible for page deletion under criterion G11 if it were a standalone page.

Wikipedians in residence

A Wikimedian in Residence (WIR) is a professional role in communications for an organization to share its knowledge within the Wikimedia platform, measure the impact of the same, and promote Wikipedia through training, education, and edit-a-thons. While WIRs can greatly benefit Wikipedia, there is a risk of edits that could unduly benefit their employers. To manage this risk, the following guidelines apply:

  • Scope of Editing: WIRs may edit articles related to but not directly involving their institution. They must not edit articles where their institution is the primary subject or could reasonably be seen as directly benefiting from the article's content; if they wish to make changes to such articles they must follow the instructions at #Managing Conflicts for Editors with a Financial Conflict.
  • Disclosure Requirements: WIRs must clearly disclose their role and association with their institution on their user page, as well as in any discussions or edits related to their role as a WIR

Reporting suspected violations

When violations of this policy are suspected or identified it is crucial to address them with transparency and caution, balancing protecting the encyclopedia with respect for the editors involved. Always adhere strictly to our no-outing policy; only post personal information if the editor has disclosed it on Wikipedia.

  • User talk page: Non-urgent issues can be raised on the editor's talk page, using the COI warning template as appropriate.
  • COI noticeboard: If issues remain unresolved after user talk page discussions, or if the user talk page is an unsuitable venue, escalate the matter to the Conflict of Interest Noticeboard. This noticeboard also provides guidance for editors dealing with their own conflicts.
  • Private communication: For issues requiring confidentiality, including where posting the information on Wikipedia would violate our policies on the posting of personal information, email evidence to the appropriate channels: for general COI issues, contact functionaries-en@lists.wikimedia.org, and for paid editing concerns, reach out to paid-en-wp@wikipedia.org. Always consult these channels for advice before sending private information.

Discussion

Any way to internationalise the bit under Significant roles? A "precinct captain for the Democratic Party" doesn't really map intuitively onto anything in my experience, and others may feel similarly. Folly Mox (talk) 20:41, 23 May 2024 (UTC)
I tried to think of a few as I didn't consider it ideal either, but I couldn't think of anything more recognizable. If you have any ideas I would be glad to change them. BilledMammal (talk) 00:08, 24 May 2024 (UTC)
  • I am really not liking the direction this proposal is taking us. This focuses on the editor and not the edits.
Having a conflict of interest should NOT bar anyone from editing as long as their edits are in accordance with our content policies and guidelines. Even a paid editor is not problematic UNLESS they are editing in a way that is contrary to our p&g.
I agree that it IS all too easy to (even unintentionally) edit in a way that is contrary to p&g when you have a tie to the topic… and so I agree with requiring disclosure. After all, when you disclose, others can better guide you when you unintentionally edit in a problematic way. BUT… those with a conflict CAN edit properly with such guidance.
The flaw isn’t in having a conflict of interest… the flaw is in allowing that conflict to impact one’s editing. And THAT is resolved by addressing the edits, not the editor. Blueboar (talk) 22:36, 23 May 2024 (UTC)
I agree that the flaw is in allowing the conflict to impact one's editing. However, I don't believe it's useful to focus on the edits within the conflict of interest guideline. All edits are held to the same standard: they are proper if they align with our content policies and guidelines, and improper if they don't.
Instead, we should recognize that editors with a conflict of interest can make significant positive contributions but also face an increased risk of making problematic edits - especially ones that are difficult to detect and address. Our goal should be to minimize this risk without hindering those positive contributions, and we can achieve this through two complementary processes: providing additional guidance to editors with a conflict of interest and subjecting their edits to greater scrutiny.
A conflict of interest guideline that focuses on the editor, promoting transparency and disclosure, supports these processes, and allows us to better manage the risk. BilledMammal (talk) 00:08, 24 May 2024 (UTC)
I agree with Blueboar, the only thing that matters is the edits. Everything that isn't directly supporting the inclusion of good edits and the exclusion of bad edits, regardless of source, is irrelevant. The significant majority of this proposal is focusing on completely the wrong thing. Thryduulf (talk) 21:34, 24 May 2024 (UTC)
@Blueboar and @Thryduulf, can't the same thing be said about the existing COI guideline? Is this really "taking us" somewhere new, or is it "keeping us exactly where we have been since 2012"?
Related to the comment from @Curbon7, I think the most recent major change was when Gigs and SlimVirgin largely re-wrote COI in 2012. If memory serves, the goal was to make COI focus on the editor instead of the edit, because real-world definitions (e.g., for corporate board malfeasance) focus on the individual actors instead of the actions. For example, if a non-profit board member owns an office building, and offers to rent badly needed office space to the non-profit at a massive discount, he can theoretically get in COI trouble for voting to accept his offer, even if that's clearly the best possible thing for the organization. WhatamIdoing (talk) 06:17, 25 May 2024 (UTC)
Wikipedia's COI policies don't ban those with a COI from editing. However, they do require you to:
  1. Disclose that COI
  2. Keep any bias in check
  3. Involve other editors to verify all edits are unbiased
  4. Avoid letting your voice "dominate" any articles on the topic.
The editor matters because we don't have perfect information. If a rando gives a citation for "Bob the scientist says X", it's reasonable to include this in an article, and I won't give it much thought. However, it's possible Bob's view falls outside the mainstream; to determine that, I'd need to learn all about X. I can't do this for every possible X, so I take a shortcut: if a COI editor who would benefit from X writes this edit, I make sure to be extra-careful when reviewing the edit. –Sincerely, A Lime 20:17, 9 June 2024 (UTC)
  • I think rather than re-writing the guidelines entirely it may be more wise to trim the guideline section-by-section. I'm not sure many editors have an appetite for a ground-up re-structuring which to some may seem to be the addition of new guidelines and removal of existing one; the issue with huge proposals like this is the risk of a controversial change in one spot derailing the entire thing. Curbon7 (talk) 22:59, 23 May 2024 (UTC)
    As a matter of practical politics, you're probably right. I don't remember a wholesale re-write ever being adopted in one go, though we have (10+ years ago) made really substantial changes to some policies through a series of edits. But it's also helpful to look at the potential goal. If it's going entirely the wrong way, then we might not want to propose any of the changes. WhatamIdoing (talk) 06:05, 25 May 2024 (UTC)
    I think an attempt at a ground-up restructuring is worth attempting; a lot of the changes only make sense in context, and I feel trying to run a dozen RfC's will quickly fatigue the community. BilledMammal (talk) 07:18, 2 June 2024 (UTC)

Worth the effort; there are many problems caused by the current guideline. North8000 (talk) 13:43, 4 June 2024 (UTC)

Make the edit request facility optional

Latest comment: 6 months ago33 comments9 people in discussion

An uncontroversial, "change X to Y" request can be done just as easily using a normal discussion thread. The edit request facility exists for low-activity protected articles where there is a need to summon an editor to handle the request; otherwise the request could sit unseen or ignored for years. In my experience, edit request is used far more often for changes that are not uncontroversial, and/or are not in the required "change X to Y" format. This is because users don't take the time to read the instructions presented to them in the request path.

It should be possible to turn off the edit request facility at articles where it isn't needed; i.e., articles that always have editors around. In such cases the edit request path could be replaced by instructions directing the user to the talk page (or saving them a step and presenting the same thing they would get by clicking "New section" at the talk page). ―Mandruss ☎ 22:31, 21 May 2024 (UTC)

Well it is already optional and editors do make requests in text only. The template makes it formal and encourages identifying the exact change, although often not used correctly. Graeme Bartlett (talk) 22:52, 21 May 2024 (UTC)
The use is optional; the facility is not. Again in my experience, editors are spending too much time rejecting "invalid" edit requests (which also wastes the requester's time).
The facility summons an outside editor by placing the article in a maintenance category for that purpose. In my 10+ years at normal-activity articles, I've yet to see a request handled by such an outside editor. Rather, the request is invariably changed to answered=y by a "local" editor, removing the article from the category, before an outside editor arrives to handle it. So, for a normal-activity article, what's the point of the category or the facility? ―Mandruss ☎ 23:26, 21 May 2024 (UTC)
Not every request-reviewer is that lazy. Quite a bit will engage in discussion. Aaron Liu (talk) 23:29, 21 May 2024 (UTC)
And they will do so improperly, all the more reason to turn off edit requests. The edit request instructions are quite clear: "What an edit request IS NOT for: [...] making a comment or starting a discussion: go to the talk page [...]". Again, if discussion is the goal, there is already a way to do that. ―Mandruss ☎ 23:55, 21 May 2024 (UTC)
Hmm. But should people new to a topic carry the burden of assessing whether a talk page is active? Aaron Liu (talk) 01:24, 22 May 2024 (UTC)
I don't understand the question. If you're referring to the requesters, they wouldn't have to make that assessment. It would have already been made by the article's editors (or not). For example, the editors at Donald Trump would turn off the edit request facility and any user clicking "View source" on the article page would be directed to the talk page (or, as I said, the box would be presented to start a discussion thread). More precisely, they would be presented the option to start a discussion thread, just as they're presented the option to submit an edit request today (big blue button).
And, again, if they don't seek discussion—if they have something clearly uncontroversial—a normal thread works equally well for that purpose. Heading: "Typo correction". Comment: "Please correct the spelling of 'envirmental' in the 'Climate change, environment, and energy' section. ~~~~". Done. The only material differences are (1) a more meaningful section heading, hopefully, (2) no need to change to answered=y, and (3) no maintenance category pointlessly involved. ―Mandruss ☎ 02:15, 22 May 2024 (UTC)
Then just add the edit notice for articles where all edits will be controversial. I don't see why we should remove the ER facility, which is still perfectly good for uncontroversial edits. I don't see why editors already being available is a problem. Aaron Liu (talk) 11:31, 22 May 2024 (UTC)
@Mandruss: The facility summons an outside editor by placing the article in a maintenance category for that purpose. In my 10+ years at normal-activity articles, I've yet to see a request handled by such an outside editor. Can you please clarify what you mean by this. Many volunteers watch CAT:ESP and related pages and handle requests. RudolfRed (talk) 02:45, 22 May 2024 (UTC)
@RudolfRed: I'm sure they do, but I've never seen them handle one at an article that always has editors around to handle it. Not once in 10+ years. They simply can't get there fast enough, presumably because they are processing a FIFO queue containing a number of older requests. Even if they could, why bother them when they aren't needed? They have many requests to handle where they are needed. ―Mandruss ☎ 02:56, 22 May 2024 (UTC)
There's a lot of high traffic articles here. In my experience handling well over 10,000 edit requests and patrolling all of the edit request queues, edit requests are often ignored by the regulars on well attended talk pages, and edit request patrollers handle requests on those articles very often. ScottishFinnishRadish (talk) 02:36, 25 May 2024 (UTC)
Great. Then those articles would not turn off the edit request facility. Hence "optional". ―Mandruss ☎ 04:30, 25 May 2024 (UTC)
Pages that are protected are normally of interest to many editors. So hopefully they are on watchlists. Also I expect that admins the protect, add the page to their watchlist so they can see any requests or edits. Graeme Bartlett (talk) 22:39, 23 May 2024 (UTC)
That reads like an argument for eliminating the edit request facility entirely, which would be a step too far in my opinion. It's certainly not an argument against making the facility optional at article level. ―Mandruss ☎ 01:10, 24 May 2024 (UTC)
And the argument is very wrong too. There are plenty of obscure protected pages. High-risk templates. MediaWiki-namespace pages. Gadgets like MediaWiki talk:Gadget-watchlist-notice-core.js, where even the edit request template itself has failed for two months. * Pppery * it has begun... 04:04, 24 May 2024 (UTC)
I implemented this a while ago per Wikipedia:Administrators' noticeboard/Archive334#Possible new tool/technique/procedure as {{Manual edit requests}}. It never got used then because the person who was advocating for it retired due to unrelated drama shortly after that discussion. * Pppery * it has begun... 04:04, 24 May 2024 (UTC)
I still don't see why editors being already available is a problem. Aaron Liu (talk) 11:29, 24 May 2024 (UTC)
You're choosing to frame this in a greatly oversimplified way that ignores points already made. I hate circular/repetitive discussion, and I suggest a re-read with more effort to see a different perspective. ―Mandruss ☎ 02:27, 25 May 2024 (UTC)
Bump. It's been said, not by me, that Idea Lab is where good ideas go to die. ―Mandruss ☎ 21:48, 5 June 2024 (UTC)
Even if that's true, I don't think the precondition is met for this one.
Suppressing the normal edit request mechanism IMO should only be done for pages where it makes it too easy for confused users to make completely misplaced edit requests (e.g. all the people who used to wind up at Template talk:Reflist trying to add references to some particular article, or Help talk:Edit summary trying to add a summary to their edit). If people are using it to make appropriate requests, even if malformed and even if the article always has editors around, then it's not a problem. Especially in the "always has editors around" case, those editors can handle it.
Above you complain about Rather, the request is invariably changed to answered=y by a "local" editor, removing the article from the category, before an outside editor arrives to handle it, which IMO is the mechanism working as intended: an editor answers the request and sets answered=y. Just because that happens to be an editor who'd have seen it anyway because they watch the page is not a "problem" that needs fixing. Anomie⚔ 11:22, 6 June 2024 (UTC)
The point is that, where there is no need to summon someone via the category, there is no need for the facility. That's it. In my nine years at the perpetually-protected Trump article, perhaps one in twenty edit requests have resulted in an edit to the article—and it could have been done using a normal thread. The other nineteen have been malformed, controversial, attempts to start discussion, or requests for permission to edit the article directly. That is a distracting waste of resources too easily avoided. ―Mandruss ☎ 12:12, 6 June 2024 (UTC)
It's not that I don't understand your point. It's that I disagree that removing the edit request pre-fill would make things better, outside of your own personal annoyance at seeing the edit request template. You or other editors on the page are free to retitle sections and mark the "bad" request as answered when you answer them. Anomie⚔ 12:46, 6 June 2024 (UTC)
Well, I think you do misunderstand my point, unless you're saying that the distracting waste of resources is acceptable. If that's the case, I invite you to come spend a few weeks at the Trump article; might change your perspective. We have more important things to do, and not enough time to do them. ―Mandruss ☎ 12:52, 6 June 2024 (UTC)
On second thought, it's not a good time for your visit. The article talk page has been temporarily semi-protected due to vandalism related to the conviction, and I think that's preventing edit requests. ―Mandruss ☎ 13:13, 6 June 2024 (UTC)
Sorry, I can't stand Trump. Anomie⚔ 00:49, 7 June 2024 (UTC)
I might be misunderstanding the proposal; currently I'm interpreting it as "disable the ability to create edit requests on controversial pages/pages with lots of watchers". If that's the case: last year, I made an edit request to the List of Conspiracy Theories article, which is unsurprisingly a controversial article and has over a thousand talk page watchers. By your criteria, I'm pretty sure edit requests would have been disabled. As it was, it took 23 days for anyone to bother to respond, during which time (if my memory's correct) it became the 12th-most-stale edit request on the entire site. ...had your proposal been in place, and had my request been forced to have been opened as a normal thread, it would have vanished into the void and would still be unanswered today. Because surprise surprise, the ultimate responder found it through the Edit Request Tool, not from watching the talk page. 2603:8001:4542:28FB:BC84:B937:5E69:2838 (talk) 14:42, 7 June 2024 (UTC) (Send talk messages here)
That's the general gist I saw when I was I patrolled edit requests. ScottishFinnishRadish (talk) 14:45, 7 June 2024 (UTC)
The proposal is to give an article's editors the power to turn off the edit request facility if they judge that it's doing more harm than good at that article. The test is not an arbitrary one based on # of watchers or anything else. Are you suggesting that decision would be made at List of conspiracy theories? Made on what basis?
Regardless, it's not like the decision is irreversible. If your normal thread sat unanswered for a long time, would that not be a clear reason to turn the facility back on? If your edit request went unanswered for 23 days, how is that an argument against this proposal? ―Mandruss ☎ 18:27, 7 June 2024 (UTC)
I'm just not seeing what it really does. The template attracts the patrollers. If they close an edit request it doesn't mean that the watchers of that particular article can't action or respond to the request in any way they see fit. ScottishFinnishRadish (talk) 18:30, 7 June 2024 (UTC)
If I've failed to make the point about "distracting waste of resources", I guess there's nothing else I can say. ―Mandruss ☎ 18:40, 7 June 2024 (UTC)
What you call waste, we call extremely effective redundancy. Aaron Liu (talk) 18:48, 7 June 2024 (UTC)
Perhaps I'm misreading, but it is unclear what resources are being wasted (server kittens?) or that anyone is distracted. One of two things is true. Either the request is answered by someone who is patrolling the categories for edit requests, in which case the system functioned as expected. Or the request is answered by a talk page watcher, in which case the proposed change would make no difference except perhaps cosmetically due to a different template. I suppose there is the tiniest chance that a patroller inspects a request at the precise instant a talk page watcher answers it and edit conflicts, but the benefit of eliminating an extremely rare occurrence is more than outweighed by the extra complications entailed by the proposed change. 184.152.68.190 (talk) 04:49, 10 June 2024 (UTC)
I doubt that new users would be able to know how to request turning the facility back on, nor if there were a facility because it was turned off. Aaron Liu (talk) 18:49, 7 June 2024 (UTC)

Reliable source engine

Latest comment: 6 months ago9 comments6 people in discussion

Created a prototype 'reliable source engine' (you can try it here) to simplify finding reliable sources. Is this something that already exists? That others might use? (if so, maybe Wikimedia can partner with Google to make the search engine ad-free?) Superb Owl (talk) 20:11, 4 June 2024 (UTC)

I just tried it and liked the results. Thanks! Schazjmd (talk) 20:23, 4 June 2024 (UTC)
See WP:WRS. --Talky Muser (talk) 20:37, 4 June 2024 (UTC)
Love it! Maybe that's something to implement to the Find sources link present in most citation needed templates? But, it already seems to exist as above. Cocobb8 (💬 talk • ✏️ contribs) 21:53, 4 June 2024 (UTC)
Thanks all! I pinged User_talk:Syced/Wikipedia_Reference_Search#Relationship_with_WP:RSP? for feedback and to see if they think it'd be helpful to have more versions and added a second version narrowed down to reliable sources without paywalls. Superb Owl (talk) 09:14, 5 June 2024 (UTC)
WP:RSSE is another. Levivich (talk) 02:29, 6 June 2024 (UTC)
Oh awesome! I added all of these to the esssay Wikipedia:Advanced source searching#Niche search engines so they are all in one place Superb Owl (talk) 22:20, 8 June 2024 (UTC)
Awesome! I'm definitely bookmarking it for later use. ‍Relativity ⚡️ 18:57, 8 June 2024 (UTC)
Would love your thoughts when you've tried it!
I also just filtered-out opinion pieces when possible.
And also confirmed that all of the other existing search engines include at least some sources where there is no consensus on reliability. Superb Owl (talk) 22:19, 10 June 2024 (UTC)

Whales

Latest comment: 6 months ago10 comments8 people in discussion

We don’t have enough content about whales. The whale content is lacking. Are kids going to be successful if they’re not skilled in whales? The answer is no. Hence, we need more whale content. First, how do they breed? Second, what do they like to eat? Third, 2603:7000:4EF0:9ED0:F9B8:A706:2018:DF70 (talk) 03:32, 10 June 2024 (UTC)

Moot We already have sweet Jimbo Wales. Aaron Liu (talk) 11:35, 10 June 2024 (UTC)
And {{whale}}! Chaotic Enby (talk · contribs) 12:44, 10 June 2024 (UTC)
[cetacean needed] —Jéské Couriano v^_^v threads critiques 23:16, 10 June 2024 (UTC)
fixœd Aaron Liu (talk) 02:58, 11 June 2024 (UTC)
Third, how often do they explode. —Cryptic 15:39, 10 June 2024 (UTC)
We can talk about whales during lunch. --jpgordon𝄢𝄆𝄐𝄇 21:20, 10 June 2024 (UTC)
We have a lot of content on this subject, but (per WP:ENGVAR) we use the UK spelling … without the “h”… see: Wales. Blueboar (talk) 21:31, 10 June 2024 (UTC)
I've created a task force homepage. Aaron Liu (talk) 22:20, 10 June 2024 (UTC)
I think you mean how often does he explode. The WordsmithTalk to me 00:37, 11 June 2024 (UTC)

Dark Mode as a Premium Feature

Latest comment: 6 months ago5 comments4 people in discussion

If dark mode was offered as a premium feature I'd be pretty likely to pay $0.99 per month for a premium "membership".

Offering this feature would help my eyes and could be a great way to get users to support the site more consistently. 2601:644:9282:65E0:6844:BE91:592E:183F (talk) 01:22, 13 June 2024 (UTC)

See Wikipedia:Dark mode. You can sort-of get it for free. And it would be grossly improper to charge for it. The WMF don't really need the money anyway. They are rolling in it, and a great number of contributors here consider both the way they raise funds and some of the things they spend it on to be less than optimal. AndyTheGrump (talk) 01:34, 13 June 2024 (UTC)
Appreciate your response. Good to know they aren't hurting for funds.
I've used Wikipedia extensively and have donated/contributed multiple times, and thought since I could be convinced to pay for this feature it was worth mentioning as a possible fundraising tactic.
Perhaps it would be grossly improper. Admittedly, I would trust an official Wikipedia feature more than installing a browser extension. 2601:644:9282:65E0:6844:BE91:592E:183F (talk) 01:40, 13 June 2024 (UTC)
I have been using the Dark Mode Gadget for I think a couple years. Some pictures came out wrong, but not enough to persuade me to give up the lovely darkness. Several minutes ago the notice came up that the Gadget was interfering with the new Dark Mode Feature, so I clicked the deactivate and found the correct option in Preferences. Very nice. Well, I don't notice if there's any difference. Alas, I have forgotten which pictures came out wrong with the old Dark Gadget, so don't know whether that was fixed. Anyway go, go, dark! Jim.henderson (talk) 01:44, 13 June 2024 (UTC)
The Wikimedia Foundation is working on a night mode; see mw:Reading/Web/Accessibility for reading. You can feel free to take that amount and donate it to a charitable organization whose goals align with Wikipedia, or some other Wikimedia Foundation project. isaacl (talk) 01:57, 13 June 2024 (UTC)

Wikipedia Hall of Fame?

Latest comment: 6 months ago75 comments26 people in discussion

What are your thoughts? Is it going to work? Comment down below. Wolverine XI (talk to me) 17:28, 8 April 2024 (UTC)

i think it would be pretty cool, maybe for significant editors. Cyb3rstarzzz (talk) 10:09, 14 June 2024 (UTC)

Hall of fame topic; section break 1

  • I'll bite. What do I get? Like, a room with a comfy chair? The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons. BD2412 T 17:37, 8 April 2024 (UTC)
    "The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons." That's a good point. Though, IMO, I don't think HOF should be behavior-exclusionary and should be open to anyone who has made an enduring impact on WP, regardless of how they made the impact. For instance, I say induct Jordan French (maybe not in the inaugural cohort, but eventually). Chetsford (talk) 18:47, 8 April 2024 (UTC)
    I agree with Chetsford on this. Wolverine XI (talk to me) 04:11, 9 April 2024 (UTC)
    French certainly made an impact but then so did many LTA vandals. If this idea is adopted, it seems appropriate to limit membership to those who have shown altruism rather than encouraging those who make Wikipedia worse for personal gain. Certes (talk) 08:24, 9 April 2024 (UTC)
    Never say never. Wolverine XI (talk to me) 13:16, 9 April 2024 (UTC)
    Yeah, that's a good point, Certes. I think this was intended more as an exaggeration for emphasis that we not be rules-bound for a HOF, but probably not a good example to underscore that! Anyway, I agree with your suggestion. Chetsford (talk) 15:26, 9 April 2024 (UTC)
  • We already have a lot of perks for experienced editors (Special holidays, Wikimedian of the Year, Editor of the Week, Service awards, ...), and I honestly don't think we need yet another way to separate "elite" Wikipedians from the rest of us. Chaotıċ Enby (talk · contribs) 18:02, 8 April 2024 (UTC)
  • Similar to Internet Hall of Fame, to be serious, there would need to be a reliable advisory board. They can help surface little known but important people from the early founder days. It could be a popular vote nomination process, like the Nobel, but picking the winners would need a small august body, known for deep institutional knowledge and experience. After a few rounds/years of winners, those winners then become members of the advisory board. Overall this is probably something that should be organized by WMF. Or you can just do it, but it will be another "This one is special. This one is also special" award. -- GreenC 18:32, 8 April 2024 (UTC)
    @GreenC, i like the discussion here of this idea, but how about an opposite approach? such as, anyone who wants to be in the hall of fame, can be?? and maybe split it up by topic, so that it would have some actual useful format to make it readable to others? Sm8900 (talk) 20:10, 17 April 2024 (UTC)
  • I like it. While we may have a superfluidity of awards, these cost essentially nothing to produce so I'm not sure I ever understand the resistance. All recognition systems are voluntary and those who don't approve can opt-out. Moreover, a HoF -- if managed through some approximation of the way GreenC describes -- would be different from existing accolades which are either interpersonal recognition (editor to editor) or metric-based recognition (e.g. Four Award, etc.). Chetsford (talk) 18:41, 8 April 2024 (UTC)

Hall of fame topic; section break 2

  • Of course they "cost nothing to produce", that's not the problem, the problem is that they give one more excuse to divide Wikipedians between "the ones who have power" (i.e. the unblockables) and the plebs like us. Chaotıċ Enby (talk · contribs) 13:36, 10 April 2024 (UTC)
  • It might be a good idea. 3.14 (talk) 19:07, 8 April 2024 (UTC)
  • The key questions for any initiative is what is the objective, and how helpful is the initiative in achieving this objective? For recognition programs, it's important to also consider how the selection process will work, and whether or not it will create more difficulties than benefits gained. Recognition programs are tricky because the flip side of selecting some is that many others are not selected, and that can result in conflict. isaacl (talk) 02:36, 9 April 2024 (UTC)
    That's how recognition programs work, but I don't think they'll necessarily cause any conflict. Wolverine XI (talk to me) 04:09, 9 April 2024 (UTC)
    "it's important to also consider how the selection process will work" After the inaugural cohort is selected, maybe it should become self-perpetuating with all prior inductees selecting each subsequent cohort. (Though you'd still need some system to choose the inaugural cohort.) This would mitigate politicization and degradation as inducted members would have a vested interest in maintaining its reputational coherence. Chetsford (talk) 05:37, 9 April 2024 (UTC)
    That would be difficult if they are dead or so long retired from WP they don't give a toss about the place anymore/are out of touch about who is still active and "deserves" a shout. - SchroCat (talk) 07:44, 10 April 2024 (UTC)
    "would be difficult if they are dead" I imagine it would. Chetsford (talk) 08:48, 10 April 2024 (UTC)
    I would object to exclusion of the deceased. There are some amazing editors who left us too soon, but with great work done first. BD2412 T 02:37, 11 April 2024 (UTC)
    We don't mean a blanket exclusion, just that we will ensure that batches of cohorts keep on coming; this line of discussion was about a proposal to have each cohort select the next. Aaron Liu (talk) 02:59, 11 April 2024 (UTC)
    I don't think we'll select a cohort that are all dead or inactive, for the reasons you've mentioned. Aaron Liu (talk) 11:34, 10 April 2024 (UTC)
    I think it best if you don't have any intake at all: voting for one's friends make this an inbred and insular process. As I've said before (as has Chaotic Enby), this is a bad idea - divisive and with the potential for conflict when the "wrong" people are elected and the "right" people over looked. - SchroCat (talk) 12:02, 10 April 2024 (UTC)
  • The English Wikipedia Hall of Fame idea sounds peachy keen, as Babe Ruth would say before tying his hands behind his back and hitting a home run with his neck (Ruth is, all kidding aside, the most underrated ballplayer in baseball history). The initial "class" obviously would include J and L, the pioneering heroes of our story, and I can think of several others who would be obvious. That first class probably shouldn't be large, maybe 7 or 8 inductees. Then the rules get tricky, but doable. In a perfect world we'd lock J and L in a room until they get to a place where they can come up with a plan of how to handle this that everyone says "Of course that's how it should be done". But, bottom line, I think an EWHoF is a good idea all around (without WMF involvement). Randy Kryn (talk) 03:22, 10 April 2024 (UTC)
  • A second rate popularity contest with ill-defined criteria? What could possibly go wrong. Terrible and divisive idea. You think someone's great - give 'em a barnstar, or, even better, leave them a thank you note, but to 'promote' people who will undoubtedly be divisive to others? That way grief and conflict lies. And this ignores the fact that "hall of fame" is not a worldwide concept that people everywhere readily grasp or buy into.- SchroCat (talk) 07:44, 10 April 2024 (UTC)
    Schro, the procedure is akin to the Wikimedian of the Year, except that it exclusively concentrates on the English Wikipedia. There's a purpose for these initiatives, and I firmly disagree that this is a "bad idea." Wolverine XI (talk to me) 13:25, 10 April 2024 (UTC)
    You are, of course, entitled to disagree. For what it's worth, I think the Wikimedian of the Year is a fairly crap award too, being a process with no criteria and something else that divides, rather than unites. Most people are happy to do the work for the sake of the work, not to seek vacuously external praise or validation just because they've caught the eye of someone powerful or happen to be pushing a zeitgeist line of thinking. - SchroCat (talk) 14:44, 10 April 2024 (UTC)
    As you haven't yet stated the purpose behind your suggestion, nor proposed a process, there isn't enough info to understand the potential benefits and costs. There's an understandable view that costs quickly outweigh benefits as any process involves more people, adding up to more total effort expended. isaacl (talk) 16:53, 10 April 2024 (UTC)

Hall of fame topic; section break 3

I don't much like anything on Wikipedia which encourages elitism, political campaigns, cliques, inequality, etc. I can imagine that many wiki-politicians would waste a lot of time campaigning to be elected to a HOF and that the results would be divisive. "How come so-and-so got elected, and I didn't?" Smallchief (talk) 21:44, 12 April 2024 (UTC)

  • I think this sort of thing is better left to other sites. Maybe the people who hang out at Wikipediocracy would create a Wikipedia Hall of Fame? Or would it become a Wikipedia Hall of Infamy? Phil Bridger (talk) 08:09, 13 April 2024 (UTC)
    I especially don't like the idea of putting infamous characters in a HOF. Follow baseball standards. Pete Rose and Shoeless Joe Jackson are not in the baseball HOF because of scandal, despite being qualified. No bad actors, no matter how famous, in a HOF. Smallchief (talk) 09:04, 13 April 2024 (UTC)
    Good point, but Wikipedia is not baseball. Wolverine XI (talk to me) 06:57, 14 April 2024 (UTC)
    Indeed. Baseball is a sport where defeating others on the field is encouraged. Wikipedia is a cooperative endeavour where it's frowned on. Certes (talk) 09:48, 14 April 2024 (UTC)
    Yes, this program is designed for honoring purposes rather than competition. I hope that's clear to all. Wolverine XI (talk to me) 04:41, 16 April 2024 (UTC)
    In that case, it seems the honor should not be of the Wikipedian itself, but of the work that they accomplished in a given area. That's why the Barnstars exist, of course. Just as WP:NPA encourages us to comment on the content and not on the creator, so too should we be aware to not place individual people on a pedestal.
    Frankly I find it disappointing that, in bringing forth the idea, the OP has not brought forth any comprehensive or detailed arguments in support of this idea and in response to the above critique. We are simply discussing a nebulous concept of recognition, which I think Wikipedia already addresses, and which if people really needed to see more of, they could use other websites or mediums for this purpose. Duly signed, ⛵ WaltClipper -(talk) 12:29, 16 April 2024 (UTC)
    And we do celebrate content, quite satisfactorily, with DYK and TFA. So there is no need for a "hall of fame", it's just more self-congratulation. Cremastra (talk) 20:45, 16 April 2024 (UTC)

section break 4; [wikilounge idea]

Section break 5

  • Editor of the Week was set up with a specific goal in mind: to demonstrate appreciation of specific positive behaviours and collaborative spirit by its recipients, with an explicit disclaimer that it's not intended to be a judgement about their overall characteristics. It was deliberately set up as a no-big-deal award with a very lightweight process, to avoid making it something that people would argue a lot about. The original pool of candidates was lesser-known editors, in order to give them a bit more encouragement to continue contributing, but has since been broadened to anyone. It's basically a slightly fancier barnstar, with some people slapping recipients on the back with a "good job". As a result of this carefully planned design, it hasn't fostered division. isaacl (talk) 02:05, 21 April 2024 (UTC)
Many such award schemes have been previously proposed. Only two, to my knowledge, still function: WP:QAI, because of the dedication of one editor, and WP:EOTW. If you want another one, set it up and run it yourself—if people like it, you can then apply to formalize it as a Wikipedia-wide process. ~~ AirshipJungleman29 (talk) 12:13, 26 April 2024 (UTC)
  • Oppose. I'm not sure what I'm opposing here, but whatever it is, I'm against it.
Anyway, the Service Awards are good because they are purely mechanical and entirely removed from politics. Entirely: If you're banned, you qualify. If everyone hates you, you qualify. If you drove your car up the steps and into the door of the Wikimedia Foundation offices on purpose, you qualify. Also, you continue to accrue service time -- which is measured from the date of your first edit, and does not take into account gaps -- after you're dead. So, if service time is the limiting factor for you, you will progress up the levels even after your demise, and I know of one editor who is. So... Maybe our Hall of Fame could be only for deceased editors. After all, you have to be dead five years before you're eligible for the baseball Hall of Fame. Then I think most people would be "Oh its nice to remember Smith" and not upset about the politics. My 2c. Herostratus (talk) 02:53, 28 May 2024 (UTC)

How about a Hall of Shame?

I know generally we are a bit negative especially when it comes to disruption, which is why we generally note previous hurdles as a cautionary tale of what not to repeat. A reminder everyone is human. A hall of fame will make editors more concerned with scoring brownie points than actually improving the project. Awesome Aasim 20:29, 7 May 2024 (UTC)

We already have Wikipedia:STOCKS, more than this would actually be more harmful than it might help. Chaotıċ Enby (talk · contribs) 20:33, 7 May 2024 (UTC)
Yeah I know. I was just thinking about why we have a hall of shame but not a hall of fame. Awesome Aasim 00:05, 8 May 2024 (UTC)
The stocks aren't a hall of shame, it's a humourous list of mistakes. -- LCU ActivelyDisinterested «@» °∆t° 21:04, 9 May 2024 (UTC)
Awesome Aasim, isn't WP:Long term abuse already kind of that? — 🌙Eclipse (talk) (contribs) 14:49, 18 May 2024 (UTC)
That page should not really be intended to be a 'hall of shame' due to WP:DENY and WP:BEANS (none of which apply to the village stocks in comparison). Xeroctic (talk) 19:33, 20 May 2024 (UTC)

We already have a hall of shame. Just Step Sideways from this world ..... today 17:40, 26 May 2024 (UTC)

An idea that might work: A Wikipedia statue

In place of the Hall of Fame, which doesn't seem to be going anywhere, how about this: Wikipedians can request that the Foundation agree to raise funds for and construct a Wikipedia statue featuring Jimbo Wales, Larry Sanger, and a stylized rendition of Wikipedia and Wikipedians enlarged and forever enlarging behind them (with, of course, the incomplete-globe logo somewhere in the mix). This should be a major statue, not a small standing one, and incorporate the full quality and historical significance of the encyclopedia.

Wales and Sanger should have no veto in the idea of their inclusion in the statue but both probably should have input on the final design of their figures portrayed at the time of Wikipedia's founding. Many of the world's major sculptors should either compete for the final design or submit ideas for it. If done well, with a full mix of realism and modern art, it would be beautiful, educational, and honor the two initiators, the tens of thousands of volunteers, and the concept of knowledge itself. Randy Kryn (talk) 00:25, 10 June 2024 (UTC)

Would sound good to me, though I fear that some may think it's spending they should focus on technical debt, which may or may not be valid. Aaron Liu (talk) 01:24, 10 June 2024 (UTC)
Thanks Aaron. It feels like a reasonable idea, the community asking the Foundation to do something like this. As for expense, focused fundraising works. Major funders, both former and potential, often like to focus their money on specific goals. Some may delight in funding the expansion of tech, others would appreciate the chance to fund an artwok, some might be glad to fund a full evening Wikibanquet as well as add more scholarships to the regional conferences. A large well-done statue (and please also appreciate the Wikipedia Monument) dedicated to the free sharing of knowledge would catch the eye of some art loving major funders, so that shouldn't be an issue. If I was a tech giant it'd be funded already. Imagine the design proposals that would come in. Randy Kryn (talk) 03:25, 10 June 2024 (UTC)
Simpsons did it. Just Step Sideways from this world ..... today 20:07, 10 June 2024 (UTC)
A true Wikipedia statue should be a big framework sphere like this but with the design of the Wikipedia globe logo, and made of little shelves. The public to be encouraged to climb all over it and place (and remove) items of their choosing on the shelves. A webcam to make it a live-streaming sensation. Activate the fountains below to hose it down regularly. Barnards.tar.gz (talk) 21:10, 10 June 2024 (UTC)
Guy brings Vitamin C effervescent tablets Aaron Liu (talk) 11:56, 11 June 2024 (UTC)
An interesting idea, if one drops the silliness of including Sanger. The man had as much input into the founding of this as Ronald Wayne did for Apple. That is, hardly a thing. Zaathras (talk) 00:13, 11 June 2024 (UTC)

Lack of Filipino folk arts

Latest comment: 6 months ago8 comments5 people in discussion

It has come to my attention that Wikipedia lacks info about Filipino folk arts. So far I've only seen three pages of Filipino folk songs, and in the folk section of Dance in the Phillipines a plethora of some dance's pages haven't been created. Obviously I'm not trying to say that we should add EVERY SINGLE BIT. But it would be nice to add others. Cyb3rstarzzz (talk) 14:10, 14 June 2024 (UTC)

Try being bold and editing pages yourself to see what you can improve. – Teratix ₵ 14:36, 14 June 2024 (UTC)
To underline what Teratix said, every page on Wikpedia was created by someone. You can be that someone. Phil Bridger (talk) 18:42, 14 June 2024 (UTC)
I (kind of) take my word back for Filipino folk songs, I've done some more research. I don't know the exact amount but it's more than three pages. But Wikipedia is still missing some more, the absence of Filipino folk dances is still present. I'll be sure to make their Wikipedia pages as soon as I can. Cyb3rstarzzz (talk) 09:17, 15 June 2024 (UTC)
As good old dear Liza would say, then fix it dear Henry then fix it. Davidstewartharvey (talk) 09:33, 15 June 2024 (UTC)
Yeah, I'll make sure to make their Wikipedia pages as soon as I can. Cyb3rstarzzz (talk) 14:09, 15 June 2024 (UTC)
Please do remember I am a new user, it'll take some time. Cyb3rstarzzz (talk) 16:58, 15 June 2024 (UTC)
Hi Cyb3rstarzzz, if you haven't already, you should take a look at Wikipedia:Tambayan Philippines and its discussion page. It looks like it's active, so you might be able to find another editor there who has some familiarity with the topic or who would be interested in coordinating efforts. hinnk (talk) 21:18, 15 June 2024 (UTC)

Proposed edits feature

Latest comment: 6 months ago35 comments11 people in discussion

I was thinking that there could be a new feature where someone makes an edit but instead of applying it, ticks a box so that it has to gain approval from one other editor to be applied (and can’t outright be refused). This is a much less time consuming method that would replace talk page spam and be more of a proposal. It would also be ideal for contentious topics, to stop incorrect or uncertain content from being applied. Alexanderkowal (talk) 12:03, 9 June 2024 (UTC)

Something like Wikipedia:Pending changes? Anomie⚔ 12:59, 9 June 2024 (UTC)
Yes but as an option per edit for an editor, or give the edit a timer of a few hours until it’s automatically applied, during which someone can revert it preemptively Alexanderkowal (talk) 13:07, 9 June 2024 (UTC)
Is it worth the effort to distrust an editor so much that we need a giant conservatorship scheme? Aaron Liu (talk) 13:12, 9 June 2024 (UTC)
It is not to distrust the editor, it’s for edits where the editor is unsure Alexanderkowal (talk) 13:21, 9 June 2024 (UTC)
@Aaron Liu My reading of the OP is that it's partly intended for editors to apply a "please check this" flag to their edits. This would only be used by editors who are editing in good faith but are unsure of Wikipedia's norms, etc (the vast majority of whom will be newcomers) so this might be a good way reducing entry barriers for some but I don't think it would be at all effective at reducing spam, deliberate misinformation, other bad-faith editing or those who are confidently wrong in good faith. Thryduulf (talk) 13:24, 9 June 2024 (UTC)
Yes correct, and it could be a less inflammatory way of doing WP:BRD on contentious topics or controversial edits Alexanderkowal (talk) 13:27, 9 June 2024 (UTC)
Only when the editor is not confident they are right. To catch the bad faith and confidently wrong it would have to apply to all editors (or all (extended-)confirmed editors), which is what pending changes is. Thryduulf (talk) 13:40, 9 June 2024 (UTC)
Yes Alexanderkowal (talk) 13:42, 9 June 2024 (UTC)
Editing already effectively works this way, especially if a "proposed edit" has a timer after which the edit is automatically accepted. Any edit can be reverted, so in effect every edit already is what a "proposed edit" would be under this scheme. I wonder if there's some value in making this into a technical restriction we could apply to problematic editors? Right now, if we identify that an editor's work is problematic, all we can really do is talk to them or else ban or block them. A sanction where we could impose pending changes on just their edits might be a decent lower-level enforcement mechanism. Then again our technical options for less-than-total blocks are already getting kind of complicated. Ivanvector (Talk/Edits) 13:54, 9 June 2024 (UTC)
You're right that a "proposed edit" with a timer is sort of like the status quo, but the status quo means that edit is published and likely to be read by some readers, the binary between published and unpublished edits facilitates conflict Alexanderkowal (talk) 13:57, 9 June 2024 (UTC)
(edit conflict) You still seem to be conflating things. This feature would either apply to all editors or be opt-in.
  • If opt-in it might have merit as a feature for good-faith new editors, but it would be useless at best against bad faith and confidently wrong editors so it would be a waste of time to discuss it in relation to the latter.
  • If applied to everyone it might be effective against good and bad faith errors, but it would duplicate the existing pending changes, so it would be a waste of time to discuss it.
So forget bad faith editors, controversial topics, BRD, etc and develop this as a proposal solely to reduce barriers to entry for not-yet-confident, good faith new editors. We need more of those people so reducing barriers to entry for them is a Good Thing. Thryduulf (talk) 13:55, 9 June 2024 (UTC)
Yes completely agree, I'm not tech literate so I would struggle to progress this but I'll try and lay out what I have in mind Alexanderkowal (talk) 13:59, 9 June 2024 (UTC)

The idea is a checkbox next to where the editor types the edit summary, to make this edit a "proposed edit", which appears in the edit history at the time it is 'published' and the edit is automatically applied after a chosen period of time, I suggest the options being 10 mins, 30 mins, 1 hr, 2hr, 6 hr, 12hr, 24 hr. Other editors, when reading the edit history, can either 'support' or 'oppose', support applies it immediately, oppose reverts it (reasons are given for both). If the edit is reverted, you accept it or move to the talk page.

The policy around this would have to be clear to counter spam or wasting editors' time. It would also have to counter page ownership, guardianship, and unnecessary reverting. Alexanderkowal (talk) 14:07, 9 June 2024 (UTC)

Also anyone can revert an edit that has been supported, it is not necessarily consensus 2 v 1 Alexanderkowal (talk) 14:09, 9 June 2024 (UTC)
It doesn't feel like you've taken Thryduulf's comments into account. A spammer doesn't have any incentive to opt into a mechanism intended to counter their work. And by design, your proposal is to ask other editors to consider proposed edits, so it's not countering additional effort from other editors. As written, it's encouraging editors to make proposed edits with the cost of additional work by others. Depending on the relative amount of good-faith edits that end up getting reverted today, versus ones that don't, in theory this could be a net gain. My instinctive feeling, though, is that the target audience isn't large enough for it to significantly reduce net effort. Thus I agree with Thryduulf that it would better to focus on encouragement as a goal. I suggest reading about Wikipedia:Article Feedback Tool, which has some similarities to your proposal. It was discontinued as the amount of useful suggestions was completely swamped by the numbers of poor suggestions, and there wasn't enough volunteer effort to handle them. isaacl (talk) 16:11, 9 June 2024 (UTC)
This isn't anything to do with spammers or bad faith editing. It is a feature for newer editors who're generally unsure and unfamiliar with policy. To be clear it is an option, most editors will not check the box. The second paragraph there was just about writing policy around it and foreseen problems. Alexanderkowal (talk) 16:28, 9 June 2024 (UTC)
I apologize; your second paragraph is a bit unclear to me. I suggest avoiding the word "policy" in that context, as it seems you're saying that the procedure should strive to avoid unhelpful suggestions, rather than suggesting relationships to policy. You could try discussing your proposal with WMF Growth team to see if they've considered anything along those lines. isaacl (talk) 16:50, 9 June 2024 (UTC)
Okay, thank you, yeah I could've worded it clearer Alexanderkowal (talk) 17:04, 9 June 2024 (UTC)
Could you clarify what 'and can’t outright be refused' means, and what problem it solves? If an editor checks the edit and see it's in error they can still just revert it, if they check the edit and don't think it's appropriate why then waste another editors time doing the check again. -- LCU ActivelyDisinterested «@» °∆t° 17:31, 9 June 2024 (UTC)
Please ignore my first two comments, I later combined them Alexanderkowal (talk) 17:35, 9 June 2024 (UTC)
Sorry I didn't reply properly. It encourages new people to edit wikipedia who're put off by their unfamiliarity with procedure and can facilitate master, student relationships between editors. It also means editors who're unsure about their particular edit can seek approval so that false information/edits contradicting policy are not published, even if for a short time. It can also be a less inflammatory method of doing BRD on controversial edits on contentious topics/pages. Alexanderkowal (talk) 12:58, 10 June 2024 (UTC)
It can also be a less inflammatory method of doing BRD on controversial edits on contentious topics/pages Don't understand this, what does "doing BRD" mean? Or why is doing BRD inflammatory? Selfstudier (talk) 13:18, 10 June 2024 (UTC)
Acting boldly on controversial topics can produce genuine conflict between editors and make it harder to work collaboratively, especially if editors are emotionally involved. This feature could provide a more measured way of going about it. Alexanderkowal (talk) 13:30, 10 June 2024 (UTC)
To be clear, a proposed edit can be outright refused/reverted by one other editor Alexanderkowal (talk) 13:02, 10 June 2024 (UTC)
If the edit has been made, it is not really "proposed" is it? And isn't it the case that any editor can already revert it? Selfstudier (talk) 13:20, 10 June 2024 (UTC)
I think you’re misunderstanding, which is fair because I haven’t been clear, the proposed edit is not immediately applied or published. It appears in the edit history like a published edit but isn’t yet one. After a chosen amount of time, during which it can be prematurely reverted, it can become a published edit. Another editor can immediately apply it if they agree with it and bypass the timer. Alexanderkowal (talk) 13:28, 10 June 2024 (UTC)
The German-language Wikipedia does this (with their version of Pending Changes), but it's applied involuntarily and per-user (e.g., all inexperienced users), rather than edit-by-edit.
There have been times when I've wished to have someone else check an edit for me. Here's one that I would have flagged for review. Ten years later, it's still in the article (and I still think it's correct). WhatamIdoing (talk) 17:53, 10 June 2024 (UTC)
Could do with a source though lol Alexanderkowal (talk) 18:11, 10 June 2024 (UTC)
Its bad enough that my typos may not be corrected for years, but I only noticed this error 8 years later. Donald Albury 23:57, 10 June 2024 (UTC)
This is an interesting idea: essentially, allowing editors to apply pending changes to their own edits on a per-edit basis. I like it. I think you'd need someone to add to MediaWiki the ability to do per-edit pending changes (not sure if that's possible with current software). It could help reduce edit wars and BLPvios and the like. Levivich (talk) 05:46, 11 June 2024 (UTC)
Another use case would be an intuitive replacement for edit requests. Aaron Liu (talk) 11:54, 11 June 2024 (UTC)
Yes, maybe the timer could have an option of unlimited, which would be the only option for non EC users on certain topics? Alexanderkowal (talk) 11:56, 11 June 2024 (UTC)

A confusion disclaimer should be added to the top of the page for cisgender

Latest comment: 6 months ago3 comments3 people in discussion

[section originally titled: "A confusion disclaimer should be added to the top of the page for cisgender to avoid confusion with the Russian military pact Commonwealth of Independent States often abbreviated as (CIS)"]

i tried searching for CIS Commonwealth of Independent States and i received the page for Cisgender. if somebody who maybe was unaware of the full name of the commonwealth of independent states attempted to search for the frequently used acronym CIS the full page maybe be hard to reach.

full disclaimer I don't intend to degrade gender science and thus the page for cisgender I love trans people 2601:584:4400:4110:CC8A:47DD:7DBD:EA0D (talk) 14:13, 19 June 2024 (UTC)

Indeed. I did a quick test by searching for CIS with 3 search engines:
  • Wikipedia's internal search engine:takes me directly to the disambiguation page
  • Google: First hit was the Center for Internet Security
  • DuckDuckGo: First hit was the Wikipedia page for Cisgender
So based on that HIGHLY SCIENTIFIC test,;) the search results aren't consistent and likely vary based on the search engine's profile of the user. It also appears Google's algorithm differentiates between CIS and Cis while DuckDuckGo's does not. However, the only one we directly control lands on the disambiguation page. So I'm not convinced there's much we can or should do. Dave (talk) 15:27, 19 June 2024 (UTC)

Re-use and edit citation

Latest comment: 6 months ago12 comments4 people in discussion

I find the re-use citation tab to be of limited use, because it only allows using the exact same citation, pages and all. If then I try to edit just the page numbers in the new instance, it will change the page numbers in all instances of that citation, which I do not want. Instead what I'd like to see is the ability to just edit the page numbers in the new instance. I've encountered this use case hundreds of times, when I want to cite the same source but different pages in various places, thus it would greatly ease the burdensome tasks of adding citations. I have yet to encounter a case where i wanted to edit page numbers simultaneously in all instances of a citation. If the latter use case exists, then an option could be provided to change just this instance, or all instances of same citation.

I'd like to hear what other people think Thhhommmasss (talk) 02:44, 19 June 2024 (UTC)

I'd recommend using {{rp}} instead of the page parameter. Using the same source with a ton of different pages multiple times clogs up the reference list IMO. Or you could also use {{sfn}} if you're going to reuse the same page from a source that has multiple pages cited as well. Aaron Liu (talk) 03:09, 19 June 2024 (UTC)
I prefer using rich-text edit to source edit, since former is more convenient and faster for me. Instead I now have to use sfn which is a pain, and to get around that very often I use multiple automatically generated citations, via link, of the same source. But that too requires me to go to Google books or a similar source to get the same link again, so again more effort, plus it generates duplicate entire citations of same source. 95%+ of my citations from the same source are for different pages, and I do not need each one of these in the reference list, instead just the last referenced page could be kept in the list Thhhommmasss (talk) 06:22, 19 June 2024 (UTC)
Well, VE is indeed slower if you're working with templates. I find the 2010 Wikitext editor to be the best. It loads fast, has syntax-highlighting, and works with templates fast. You can use WP:ProveIt to autogen cites in source mode. Aaron Liu (talk) 19:40, 19 June 2024 (UTC)
The issue isn't the extra second or two that it takes VE to load vs. wikitext, instead t the considerably greater time it takes to to manually type out the wikitext citation template, vs. just clicking to select a source in VE from the reference list, and as noted below, input the new page number into a dialog. Plus, new editors are much less likely to be familiar with wikitext, so this could be another hurdle to participating Thhhommmasss (talk) 22:13, 19 June 2024 (UTC)
I do not doubt that the current workflow in VE has things to be desired. However, what I'm saying is that in the meantime, you can use the 2010 Wikitext to edit the pages faster than what you probably currently do. You can use a clipboard manager (including Windows's default, ⊞ Win+V) to copy the parts of the sfn templates right before the page number, and all you'll have to type is e.g. 41}}.
While WMDE works on the wish, someone might be able to make a userscript. Aaron Liu (talk) 22:38, 19 June 2024 (UTC)
When using Word or gmail, I also prefer their VE, instead of having to use Word markup or html, no matter the templates or other features they may have. I suspect the vast majority of users do too. I know some prefer different, and the proposal has no impact on current wikitext edit, it's only intended to help those who prefer VE. Believe change outlined below should be relatively easy Thhhommmasss (talk) 00:51, 20 June 2024 (UTC)
You can file a Phabricator task if you want. Aaron Liu (talk) 02:32, 20 June 2024 (UTC)
Thank you, I will look into thatThhhommmasss (talk) 22:25, 20 June 2024 (UTC)
Personally I despise {{rp}}: it's ugly, confusing to anyone who doesn't already know that [1]:23 is supposed to mean "page 23 in reference 1", and separates the page number from the reference. I wish m:WMDE Technical Wishes/Reusing references / m:WMDE Technical Wishes/extending references would happen; unfortunately it seems to keep stalling because of having to support VE. Anomie⚔ 11:42, 19 June 2024 (UTC)
I would also like to see WMDE's work become an option here (subject to all the usual WP:CITEVAR standards, of course). WhatamIdoing (talk) 18:18, 19 June 2024 (UTC)
Another approach would be not to save the pages to the reference list, since it is much more common that one wants to reference different pages in the same source, instead of wanting to repeatedly reference the same page. Then when user selects the source from the re-use list, a dialog could pop-up to let the user input the page numbers and save. As noted, I generally use the GUI edit since it is much faster, and I find having to switch to source edit for wikitext templates, just to reference a different page, to be one of the greatest pain points in WP usage. Citing in general is the biggest, most time-consuming chore, probably one of the main reasons people are less likely to edit and why many articles lack sufficient in-line citations, The issues with re-use make this worse Thhhommmasss (talk) 18:38, 19 June 2024 (UTC)

Search engine for policy

Latest comment: 6 months ago8 comments3 people in discussion

I think there should be a search engine for Wikipedia policy where you can put in key words and the relevant pages come up Alexanderkowal (talk) 22:50, 20 June 2024 (UTC)

We have discussed putting policies in a separate hyphenated namespace as we do with the manual of style..... but to no avail yet. Pls see WP:GOVP for a whole bunch of different search boxes as seen down below..... that can be found on the namespace pages. You can also select this by the magnifying glass see Help:Searching.


Moxy🍁 00:11, 21 June 2024 (UTC)

But the MOS is in the project namespace? The MOS: redirects are in mainspace. Aaron Liu (talk) 00:20, 21 June 2024 (UTC)
Because the MOS are subpages organized like Wikipedia:Manual of Style/search term you can narrow down a search to just the manual of style (as seen in the box below). If policy pages or guidelines were set up in the same manner it would be an easy search. ....like Wikipedia:Policy/search term. But one of the problems is the MOS is a guideline.... so the search parameter Wikipedia:Guideline/search term maybe confusing and give a multitude of results that aren't actually part of the MOS. It's a conundrum that has never really been solved. It is odd that it's easier to search for Wiki projects then our policy pages because of the hyphenated name setup Wikipedia:WikiProject/search for a project you're interested in Moxy🍁 02:19, 21 June 2024 (UTC)
Don't we have searching in categories now? Aaron Liu (talk) 02:53, 21 June 2024 (UTC)
Deepcat for policies seem to always fail for some reason. Normal incategory doesn't. Aaron Liu (talk) 02:59, 21 June 2024 (UTC)
Those search boxes you’ve linked are really good, maybe have them on the page for beginners? Like the introduction to policy one Alexanderkowal (talk) 04:49, 21 June 2024 (UTC)
The writing could be “Feel free to search some key words to start reading policy. Editors intimate with Wikipedia policy will usually link relevant policies in discussions.” Alexanderkowal (talk) 05:30, 21 June 2024 (UTC)

Ingest of SEC EDGAR data into Wikidata for Companies?

Latest comment: 6 months ago2 comments2 people in discussion

I have recently noticed that many company infoboxes are frequently out of date, even though they draw from Wikidata for information like yearly results because it is only updated manually. All of this data is available online through the SEC's EDGAR system, at least for publicly traded companies in the US, so I was wondering whether it would be worthwhile to write a bot that would read SEC data and update Wikidata with it.

Botlord (talk) 17:40, 22 June 2024 (UTC)

You should probably talk about this at d:Wikidata:Project chat. (They will probably think it's an extremely good idea, if it is done correctly.) WhatamIdoing (talk) 18:38, 22 June 2024 (UTC)

Add a timeline to Wikipedia pages

Latest comment: 6 months ago9 comments4 people in discussion

Hi, More than 10 years ago I thought about improving Wikipedia pages, but I was convinced that Wikipedia would logically end up integrating it over time. However, I note that this was not the case even though it would certainly add value to the presentation of the information.

In fact it involves adding a horizontally scrolling timeline in each Wikipedia page in which the topics of the page are located, accompanied by a bunch of events of all types from the period, where each event listed in the timeline would be clickable to go to the relevant Wikipedia page.

This timeline could be enhanced with a zoom to go into more or less detail, as well as filters such as: Characters, History, Politics, Science, Sports... so that its presentation is not too busy.

Clicking on a date or event could also refocus this timeline on the period concerned.

For students, journalists and anyone doing research, this would provide a temporal view of information.

And for all other WEB users another way to navigate your encyclopedia.

In my opinion, this is interesting work which would enhance the encyclopedia by making it evolve qualitatively in terms of ergonomics.

For any clarification if you have not understood the concept, I will be happy to clarify my suggestion with the hope that it will eventually succeed. Htordj62 (talk) 14:54, 12 June 2024 (UTC)

This is a good idea, but I am afraid that it might not necessarily work when different timelines are considered. For instance, taking something like Dinosaur, would we show the timeline of dinosaur evolution from the Triassic onwards with events such as the Cretaceous–Paleogene extinction event, or the timeline (at a completely different scale) of dinosaur research, with the discovery and classification of fossil species and events like the dinosaur renaissance? Chaotic Enby (talk · contribs) 14:58, 12 June 2024 (UTC)
That's right but the scale could be not linear and if you can zoom in/out you can select what you want to see, the idea is not to see complete timeline at first view but to see on page an interesting period.
There is many things to do around this graphically for instance on mouse hover it could break the timeline in several popup timelines depending on different subjects.
Regards Htordj62 (talk) 15:08, 12 June 2024 (UTC)
What I see in https://en.wiki.x.io/wiki/Template:Horizontal_timeline this is a text textline not a graphic so it is limited, and the idea is not to force the page creator to manage it. I see that like a task of server which extracts dates of the page to build the graphic time line and add it on page.
I will try to provide you a graphic view I mean. Htordj62 (talk) 09:43, 13 June 2024 (UTC)
Here you can find a good sample of view using TimelineJS : https://timeline.knightlab.com/ Htordj62 (talk) 10:00, 14 June 2024 (UTC)
I see it's easy to make a robot using ChatGpt API to extract from a wikipedia page interresting dates in a JSON file for TimeLineJS. So this kind of robot could parse all Wikipedia page to extract it JSON files then the timeline could be construct for TimelineJS. Htordj62 (talk) 14:58, 24 June 2024 (UTC)
on wiki page https://en.wiki.x.io/wiki/Christophe_Colomb ChatGPT request : "would you extract the important dates from this Wikipedia page into a json file for timelinejs: https://en.wiki.x.io/wiki/Christophe_Colomb" . The response is : "{
"events": [
{
"start_date": {"year": 1451, "month": 10, "day": 31},
"text": {"headline": "Birth of Christopher Columbus", "text": "Christopher Columbus was born in Genoa, Republic of Genoa (now part of modern Italy)."}
},
{
"start_date": {"year": 1476},
"text": {"headline": "Columbus Shipwrecked", "text": "Columbus was shipwrecked off the coast of Portugal and swam to Lisbon, where he settled for a while."}
},
{
"start_date": {"year": 1484},
"text": {"headline": "First Proposal to King John II", "text": "Columbus presented his plan to sail west to reach Asia to King John II of Portugal, but it was rejected."}
},
{
"start_date": {"year": 1486},
"text": {"headline": "Proposal to the Spanish Court", "text": "Columbus proposed his plan to the Spanish monarchs, Ferdinand and Isabella, who also initially rejected it."}
},
{
"start_date": {"year": 1492, "month": 4},
"text": {"headline": "Capitulations of Santa Fe", "text": "Columbus was granted titles and funding by Ferdinand and Isabella for his westward voyage."}
},
{
"start_date": {"year": 1492, "month": 8, "day": 3},
"text": {"headline": "First Voyage Begins", "text": "Columbus set sail from Palos de la Frontera with three ships: the Santa María, the Pinta, and the Niña."}
},
{
"start_date": {"year": 1492, "month": 10, "day": 12},
"text": {"headline": "Landfall in the Americas", "text": "Columbus and his crew landed on an island in the Bahamas, which he named San Salvador."}
},
{
"start_date": {"year": 1493, "month": 3, "day": 15},
"text": {"headline": "Return from First Voyage", "text": "Columbus returned to Spain and was received with honors by the Spanish court."}
},
{
"start_date": {"year": 1493, "month": 9, "day": 24},
"text": {"headline": "Second Voyage Begins", "text": "Columbus departed on his second voyage with a fleet of 17 ships to explore more of the Caribbean."}
},
{
"start_date": {"year": 1496, "month": 6, "day": 11},
"text": {"headline": "Return from Second Voyage", "text": "Columbus returned to Spain after exploring several islands in the Caribbean, including Hispaniola and Cuba."}
},
{
"start_date": {"year": 1498, "month": 5, "day": 30},
"text": {"headline": "Third Voyage Begins", "text": "Columbus set sail on his third voyage, during which he reached the mainland of South America."}
},
{
"start_date": {"year": 1500, "month": 8, "day": 23},
"text": {"headline": "Arrest and Return to Spain", "text": "Columbus was arrested by Spanish authorities in Hispaniola and returned to Spain in chains."}
},
{
"start_date": {"year": 1502, "month": 5, "day": 11},
"text": {"headline": "Fourth Voyage Begins", "text": "Columbus embarked on his fourth and final voyage to find a passage to Asia."}
},
{
"start_date": {"year": 1504, "month": 11, "day": 7},
"text": {"headline": "Return from Fourth Voyage", "text": "Columbus returned to Spain, ending his last voyage of exploration."}
},
{
"start_date": {"year": 1506, "month": 5, "day": 20},
"text": {"headline": "Death of Christopher Columbus", "text": "Columbus died in Valladolid, Spain, at the age of 54."}
}
]
}
" Htordj62 (talk) 15:03, 24 June 2024 (UTC)
↓You
↓might
↓want
↓to
↓take
↓a
↓look
↓at
│
0
│
1080
│
2160
│
3240
│
4320
│
5400
For any of yall reading this thread in desktop mode, here's what the above template renders like on mobile:
 
Folly Mox (talk) 23:15, 16 June 2024 (UTC)

Allowing Master's theses when not used to dispute more reliable sources

Latest comment: 6 months ago30 comments21 people in discussion

WP:SCHOLARSHIP generally allows PhD dissertations and generally disallows Master's theses, unless they have had "significant scholarly influence." I feel that this is really locking us out from a lot of very reliable sourcing. I understand that these are often not quite as polished as something like a monograph or PhD dissertation, but often times they are the highest quality sources available about very niche subject matters. They are subject to professional review, they cite their sources, and they are published by reliable institutions. Can we really say that these are less reliable than an entry in a historical society newsletter or an online news report from an assuredly hurried local journalist?

Just today I encountered a 2022 masters thesis, East Meets West in Cheeloo University (doi:10.7916/scmr-6237). As far as I can tell, this is the most comprehensive source available on the architecture of Cheeloo University. But I can't use it, since it's a masters thesis, and as far as Google Scholar can tell, it has yet to be cited elsewhere.

I feel that people should be allowed to use masters theses in certain fields (I can only speak for the humanities, I'd be interested to know this from a STEM perspective) so long as A) They are not used to dispute something said in reliable sources and B) They are not used to confer notability. I feel this would strike a good balance of allowing us to use these often very useful sources, while still recognizing that a book, journal article, or PhD thesis is probably preferable if you have the choice between them. I'd love to hear other folks thoughts! Generalissima (talk) (it/she) 00:43, 7 May 2024 (UTC)

In the stem area I would expect that important research would also be published in journals. I would discourage use of Masters theses rather than disallow. One issue is lack of accessability. Even when referenced, may not be accessible. The lack of "peer" review can also mean there are more errors included. Graeme Bartlett (talk) 02:03, 7 May 2024 (UTC)
Is there any public information generally available about the process of publishing masters' theses for a given university? What level of scrutiny or review is generally applied, etc. I think considering whatever information is available there could lend a lot of clarity to deciding whether a given thesis is reliable. Remsense诉 02:09, 7 May 2024 (UTC)
  • The rule in question is a counsel of perfection but perfect is the enemy of good and so WP:IAR applies. By coincidence, notice that today's featured article is about a work which started as a dissertation. The main thing I notice about this is that the readership for this topic is tiny. If you're working on a topic like the architecture of an obscure university that no longer exists, then you're mainly writing to please yourself and so should do what you think best. Andrew🐉(talk) 06:49, 7 May 2024 (UTC)
    I both agree and don't, to the extent that I don't think less popular topics should be viewed as less important as regards our content policies. Of course, I certainly understand the distinction between there being less available coupled with internal motivation, and that. Remsense诉 06:54, 7 May 2024 (UTC)
  • I'd question whether Master's theses are really subject to professional review or published by reliable institutions. By professional review, I assume you mean that somebody examines them. But unlike a PhD examination or journal peer review, which both act as barriers to publication, getting a low grade on a Master's thesis doesn't stop the thesis existing. The author can still put it online – presumably without the grade. Also, and speaking as a university teacher myself, the person who examined it examined it as a Master's thesis, not as a piece of publishable research. A middling or good grade means "I think the student did a good job with this material" not "I think this is a reliable source on this subject". As for publication, in my experience most Master's theses are not published (though those that are, e.g. in a journal, certainly become reliable sources). Some university libraries make archived copies available online, but this isn't really the same thing because again, any Master's theses that meets the formal requirements for submission will be there, regardless of quality. – Joe (talk) 07:59, 7 May 2024 (UTC)
    Fair enough, I didn't think about the barrier to publication angle. I guess if we think about them more along the lines of a newspaper article (which can be of wildly different quality) then we could just evaluate them on their own merits. Just like how there is great journalistic coverage of some areas of history and archaeology, there is horrible, misleading coverage; and if it's not used as a major source in the article, it's pretty easy to spot when it's the latter. Generalissima (talk) (it/she) 15:42, 7 May 2024 (UTC)
  • Purely anecdotal, but with respect to professional review, the only person on my master's thesis committee (my director) who understood what I was doing left on sabbatical half-way through. His replacement as chair kept me on the straight and narrow in my use of statistics, but knew no more about what I was doing than the rest of the committee. In retrospect, I can say that my thesis did not add anything useful to the sum total of human knowledge. On the other hand, I have dug into the bibliography section in a thesis to find sources I had otherwise missed, but that is a long shot. - Donald Albury 16:20, 7 May 2024 (UTC)
  • If we would accept a blog post from the university itself (which would be self-published, primary, and non-independent) for the same kind of contents, then we should probably accept a master's thesis for it. A source only needs to be strong enough to support the weight of the claims it's cited for. If they're non-controversial (e.g., everyone agrees that there are some buildings on the campus), then the source doesn't have to be ideal. WhatamIdoing (talk) 21:53, 7 May 2024 (UTC)
    I believe that you are referring to WP:ABOUTSELF. My understanding of that is that we could cite the thesis for statements about the thesis and the author of the thesis, but not for statements about topics covered by the thesis. Donald Albury 22:33, 7 May 2024 (UTC)
    Not really. With the possible exception of contentious BLP matter, I think we should accept it for pretty much all non-controversial content. WhatamIdoing (talk) 22:50, 17 May 2024 (UTC)
  • I agree that rigid exclusion of master's theses does not serve the project well. The language in WP:SCHOLARSHIP regarding Ph.D. dissertations would seem also to address many of the concerns above: Some of them will have gone through a process of academic peer reviewing, of varying levels of rigor, but some will not. If possible, use theses that have been cited in the literature; supervised by recognized specialists in the field; or reviewed by independent parties. (Of course, this issue would also be solved more efficiently by treating this guideline like a guideline to be applied flexibly in service of the mission rather than as a pseudo-policy that must be followed rigidly except in the most exceptional circumstances -- but that seems to be a bit too much to ask these days.) -- Visviva (talk) 04:12, 8 May 2024 (UTC)
  • I have come across some very high quality master's theses and agree that rigid exclusion of master's theses does not serve the project well. I had to work around this on Revolt of the Admirals and it was painful. In the case of my own master's thesis, it was thoroughly reviewed by two external examiners (as well as, of course, by my supervisor). It is available online and widely cited in the literature. The PhD was reviewed by three external reviewers, but is not as widely cited, and while also available online, I never got around to publishing it. Hawkeye7 (discuss) 04:47, 8 May 2024 (UTC)
    I think there's some regional differences here. In Europe, a Master's thesis isn't examined by a committee and their are no external examiners, just the supervisor. – Joe (talk) 06:34, 8 May 2024 (UTC)
  • I agree that theses provide weak arguments for controversial points, as do other sources often accepted as reliable such as news articles or unreplicated one-off studies (I also think that there are many PhD dissertations that are questionable.) But, in writing research on historical topics, I these can be very useful and informative. They often provide a well-cited overview of a particularly esoteric topic that may not be the focus of a book or major study, which interested readers can read an analyze themselves. I like using them when they can be linked so readers can view them. As others have pointed out, At bare minimum, I'd like to be able to cite them even if they aren't standalone. (e.g., sometimes I can get the point cited by a book by a mainstream press, but it covers the topic in a sentence, whereas the dissertation gives the in-depth detail.) Wtfiv (talk) 20:47, 9 May 2024 (UTC)
Theses are a mixed bag. Master's thesis even more so. I can say that mine went through a rigorous review process (I had a former president of the Canadian Association of Physicists as an external examiner on mine) as well as one other physics PhD, and had two physics PhD as my supervisors. The comments/feedback were substantive and relevant, and had to be addressed before acceptance.
But go to a different department, in the same university, and the reviewing standards and requirements for a master's thesis are quite different. Headbomb {t · c · p · b} 21:34, 9 May 2024 (UTC)
As Visviva said above, if people treat the guideline like a policy that "no masters theses can be cited for anything (or they can only be cited if lots of other people cite and repeat what they say, making it unnecessary to cite them), because we assume no masters thesis has ever been reviewed and made reliable; meanwhile, PhD theses are reliable because we're assuming every one has been reviewed by reviewers who know what they were doing", that's a problem (in fact, it's two problems separated by a semicolon). I think it would make more sense, as Visviva seems to be suggesting, to apply the same kinds of evaluative criteria as are supposed to be applied to PhD theses to both PhD and Masters theses, plus OP's suggestion that we don't use them to contradict a more reliable source; together with the fact that tighter sourcing requirements are already in effect for BLPs, medical topics, and various contentious topics, we'd in practice only cite masters theses when there was reason to think they were reliable for the uncontentious thing we were citing them for, e.g. the architecture of a particular university, which seems reasonable. (As WhatamIdoing said, if we'd accept a passing aside in blog post by the university as reliable for saying the buildings were neoclassical, it seems weird to reject a masters thesis all about the buildings being neoclassical.) Notability seems like a separate issue and it seems reasonable to say masters theses also don't impart much notability. -sche (talk) 00:48, 19 May 2024 (UTC)
  • As per Graeme Bartlett's comment, if the underlying research in a master's thesis is of sufficient quality to source, the author should have or would have submitted it for publication to a journal. If sources used in the literature review are beneficial, then just directly cite those, don't cite the thesis (I've used many master's theses to discover references for WP articles, but I've never directly cited the thesis). My thesis was looked at by external examiners but it was certainly not done with the same critical eye as they would have applied to a Ph.D. dissertation. Opening this door seems like a recipe for disaster. Chetsford (talk) 01:04, 2 June 2024 (UTC)
  • I think I agree most with WhatamIdoing here. Master's theses face nowhere near the oversight of that PhD theses do, but it's still generally going to be much more thorough work than the newspaper articles that make up the bulk of Wikipedia citations. signed, Rosguill talk 01:35, 2 June 2024 (UTC)
  • I used to teach a Master's course at the University of Birmingham (UK)aimed at non-college grads. The thesis was just part of the course. There's no way these could have been used as sources for Wikipedia. I've seen a US thesis which was also part of a taught course and not reliably published — Preceding unsigned comment added by Doug Weller (talk • contribs) 14:23, 13 June 2024 (UTC)
  • What Doug said. The only use I'd ever consider appropriate for a Masters thesis not already cited in a published reliable source would be as a research tool for references. The level of scrutiny such material gets varies wildly, and none of it is being examined as material intended for publication. AndyTheGrump (talk) 15:06, 13 June 2024 (UTC)
  • I would sooner accept an undergraduate research paper/thesis than say, a newspaper story from 1900 (which often seem embellished). There's no such thing as a medium that is universally perfect by nature of how it is created. Even the Voyager Record reflects the biases of its creation and the time it was made, despite the immense cost and effort put into it. Wikipedians who place newspaper articles above master's theses are cherry-picking which forms of subpar scholarship they care about. There are many, many examples or allegations of subpar reporting from A-grade or B-grade news organizations. You could browse through criticism sections on The New York Times or Reuters, or reference the criticism levied by people like Alec Karakatsanis. Master's theses should be allowed like most other "reliable" sources - on a case by case basis, subject to comparison to other reliable sources. Such theses are often the best or only source on obscure topics, and average arrive closer to verifiability than their exclusion would. Anonymous-232 (talk) 20:07, 16 June 2024 (UTC)
    This is not really addressing the issues being discussed, which are more about a lack of peer review allowing basic errors in rhetoric and research to be transmitted, rather than the more abstract cultural concerns you're gesturing to. We can't "use them on a case by case basis" if there's no other sources to check them for errors against. They're not reliable.Remsense诉 20:18, 16 June 2024 (UTC)
    The problem is that we have a simple, easy to understand rule against citing Bachelor's and Master's theses, and by overturning it, the doors would be opened wide for abuse. tgeorgescu (talk) 11:13, 27 June 2024 (UTC)
I've used and seen used master's theses in articles, and agree with a lot of the people here. I'm not sure which if any academic departments fully fact check every claim in the master's theses they go on to approve, but the same is true for most publication media. My position can be summarised as Use cautiously and replace with better source where possible.
Also, honestly, have yall seen what's out there in the wild in mainspace? The people who frequent this board tend to be responsible editors, and take our sourcing pretty seriously, but the amount of truly garbage sources cited like they're totally unproblematic is deafening. A master's thesis, despite the potential flaws, is head and shoulders above a blog post, a self-published book, a blog post someone uploaded to academia.edu, a google books search result, ViralFinance.info's "Top 150 Most Disuptive Blockchainers of 2019", an Amazon product listing, a 1930s travellogue published by a popular printing house but cited like it's a legitimate historical source for a period centuries prior, literature that's long been superseded by newer research that's more difficult to access than one-click borrowing from Internet Archive, etc.
Sorry I kinda lost the trail there. In most cases, a master's thesis will not be the best source. But I don't think we need to (nor, indeed, do) straitjacket ourselves with a blanket ban if no one else has bothered to publish on some obscuratum that would improve an article to include. Folly Mox (talk) 20:52, 16 June 2024 (UTC)
Almost completely unrelated, but if we had something like a Reference: namespace, we could attach things like levels of confidence in a source, and represent that somehow to the reader, like changing the little blue clicky numbers from blue to orange for sources that are not too tier. Folly Mox (talk) 20:58, 16 June 2024 (UTC)
@Folly Mox yes! This is something meta:WikiCite/Shared Citations could address ~ 🦝 Shushugah (he/him • talk) 22:32, 18 June 2024 (UTC)
I see I somehow haven't registered my written support for that project, despite being aware of it for a year or so. I see the allure of wanting to make a big software architecture like that work all across the Wikimedia ecosystem, and have concerns about how it would translate technically into different spaces, ✂️ [three paragraphs of yelling at clouds trimmed and binned] Folly Mox (talk) 04:14, 19 June 2024 (UTC)
User:SuperHamster/CiteUnseen adds icons according to RSP. Aaron Liu (talk) 02:16, 19 June 2024 (UTC)
Oh right there is that, and WP:UPSD and User:Novem Linguae/Scripts/CiteHighlighter also provide borderline similar functionality. Folly Mox (talk) 04:04, 19 June 2024 (UTC)

Formatting for mobile phones

Latest comment: 6 months ago52 comments6 people in discussion

Most editors exclusively use a desktop device. They make their additions or changes, preview the result to check appearance, save and move on.

But 75% of Wikipedia traffic comes from mobile devices and only 25% from desktops [1], so the appearance of an article on a phone is much more important than its appearance on a larger screen. The techies have done an excellent job of making the mobile interface attractive, but there is nothing they can do about the content. Long paragraphs and tables with many columns are hard or impossible to read on the phone. Short sections with two or three lines on a desktop may look odd, but work well on a phone where the sections fill half the screen.There are probably many other ways in which content looks good on a desktop, but bad on a phone, or vice-versa.

This is to suggest that

  • A group of editors work out broad principles for the way articles should be structured so they look good on a phone, which is much the most important reader interface, and if possible also look good on a desktop
  • The group then systematically reviews the Wikipedia guidlines to make sure they encourage best practices.

Comments? Aymatth2 (talk) 12:18, 23 June 2024 (UTC)

I don't think paragraph length should be considered, and I don't see much else to do other than just splitting excessively-wide tables. (And even these have the easy fix option of using overflow:auto.) Aaron Liu (talk) 14:17, 23 June 2024 (UTC)
As someone who almost exclusively uses my phone to both read and edit WP… my reaction is: “meh”.
Paragraph length is not a problem. Very wide tables can be annoying, but I can deal with it. Plus, I can always switch over to “desktop” mode if need be. Blueboar (talk) 14:29, 23 June 2024 (UTC)
Do our readers know how to switch to desktop mode? I can't find a setting. Aymatth2 (talk) 15:11, 23 June 2024 (UTC)
It's at the bottom of the page. Aaron Liu (talk) 15:12, 23 June 2024 (UTC)
But If our readers have trouble viewing an article, would they scroll to the foot of the article and click that link? They might click on "settings" to see if there is another way to view it. Aymatth2 (talk) 00:20, 24 June 2024 (UTC)
I find very large paragraphs hard to read even on a laptop. I get lost in them. The news sites I read (BBC, Economist, Washington Post etc.) consistently keep paragraphs below half a screen long. I assume they have style guides that recommend that as easier on readers.
I have no idea what overflow:auto is. Is that something that should be mentioned in Help:Table, as simething editors should add to large tables? Aymatth2 (talk) 15:09, 23 June 2024 (UTC)
I've started a thread at VPT about adding scrollbars.
I don't think any policy change for shorter paragraphs will happen. There's a lot of hardliners that insist Wikipedia being an encyclopedia means we shouldn't have decoration and shouldn't be comparing ourselves to newspapers. Aaron Liu (talk) 15:17, 23 June 2024 (UTC)
Form factor is a consideration in improving readability with paragraph length. Newspapers, with their narrower column width, use shorter paragraphs than books, for example. Text aimed for phones would very much benefit from shorter paragraphs to break up the text column. Appropriate guidance is tricky for web pages due to the wide variety of viewing devices. I do think that editors ought to keep this in mind, though, and lean towards making paragraphs shorter than they might otherwise. isaacl (talk) 15:54, 23 June 2024 (UTC)
I suppose, maybe, we could add support for a new markup element like <mb> (mobile break) that would be ignored in desktop mode, but start a new paragraph on a mobile. I don't know if anyone would use it though. We will never get acceptance on any fixed limit to paragraph size, but should ask editors to at least check how their articles look on phones.
That is straying beyond the point of this idea, which is just to get a working group together to discuss ways editors could improve the appearance of their articles on phones, and to adjust our guidelines accordingly. There must be a number of things that would help. Aymatth2 (talk) 17:03, 23 June 2024 (UTC)
It's not just a matter of inserting paragraph breaks – paragraphs should be constructed to have smaller scopes. The key issue is as you've stated: there are practical limits to how many different devices editors are willing or able to check. The design problem is that a scalable responsive design needs to constrain the layout possibilities in specific ways, but this goes against decades of English Wikipedia tradition. For example, historically, editors position elements as they see fit based on their limited testing. To improve display on narrow width devices, there should be strict rules to follow on floating elements left or right, with size and spacing specifications. I might be mistaken, but my instinct is that there isn't sufficient support for this amongst those who like to discuss these matters. isaacl (talk) 22:19, 23 June 2024 (UTC)
(Tapping this out with one finger on my phone) If Wikipedia ignores advances in UI design it will slowly die. I know there is a lot of inertia, but am inclined to be optimistic. Maybe there are three separate threads.
1. Guidelines for editors to make their articles more readable on phones,
2. Technical fixes to make them more readable,
3. Ways to make editors more concerned about how the 75% of readers will view their work.
The last may be the most important. If the buttons at the foot of the desktop edit panel were "Save . Preview . Mobile view . Diffs", and Mobile View showed a window with the article in a typical-sized mobile phone frame, that could do a lot of good. I am sure others who are interested in the future of the mobile Wikipedia will have better ideas, maybe some radical ones. Aymatth2 (talk) 00:11, 24 June 2024 (UTC)
Wikitext at present doesn't provide a way to automatically constrain layout – say, with target slots for floated elements with specific sizes and spacing. Introducing this would be theoretically possible, but would be a very large effort in converting existing articles. So I suspect the existing approach of just relying on editors manually identifying problematic layout and making ad hoc corrections will continue. That has its limits, but probably has the best benefit-cost ratio for now.
The Vector 2022 skin follows responsive design principles, but they aren't enabled due to community resistance. If at some point the community is convinced to allow it to be switched on, there is the possibility of unifying the default mobile skin with the default desktop skin. This will make it easier for editors to simulate the narrow width display of any device, since they will have roughly (though not necessarily exactly) the same appearance as on a narrow desktop window. In the meantime, I agree that a "Preview with default mobile skin" could be helpful.
Regarding general writing guidelines: it's hard to give specific advice when the device display widths can vary so much. I think editors won't want to write for the narrowest width, which would lean towards many small paragraphs, and less dependence on images or other inset info. For better or worse, the reaction to the Vector 2022 skin revealed there are many vocal editors who will remain unconvinced without specific A-B testing performed with a wide sampling of the Wikipedia audience (and maybe not even then). Thus I can only think of broad guidance such as "keep in mind that narrower displays will have less room for floated elements", "paragraphs will take up more vertical space on narrow displays, so keep them a bit shorter", and "avoid really wide tables". I'm dubious, though, that a significant number of editors would find this advice and remember it. It could still be helpful for editors who go around fixing up articles, of course. isaacl (talk) 01:01, 24 June 2024 (UTC)

I think we will have to rely on editors doing the formatting, rater than trying to enforce it. Most editors will not read the advice, let alone follow it, but it can be useful as something to refer to during discussions, even if it has to be a bit vague. Editors doing clean-up may find it useful. I find that images generally work quite well on the mobile. I use thumbnails with default properties, not too many or they stray far from the text they illustrate. On a mobile, they appear in front of rhe text, which is fine. They should never be more than illustrations, obviously, because blind people cannot see them. That is another subject... But what it we proposed the following at the foot of the desktop edit window?

Publish changes
Mobile preview
Desktop preview
Show changes
Cancel
Editing help

That is, strongly encourage editors to look at the 75% view before saving. Of course, some will pay no attention to how the page looks on a phone, but more editors may start considering it. Would there be violent pushback from the editor community if this were done? Aymatth2 (talk) 12:55, 24 June 2024 (UTC)

"The techies have done an excellent job of making the mobile interface attractive," Sorry, but this statement makes me distrust anything you say. The mobile interface is a hideous, godforsaken monstrosity. --User:Khajidha (talk) (contributions) 11:43, 24 June 2024 (UTC)
I disagree. It's lightweight and optimized. Aaron Liu (talk) 17:18, 24 June 2024 (UTC)
An imperfect approach would be to have a preview link with &useskin=Minerva at the end. Update: &useformat=mobile is used by the mobile preview gadget. Editors would have to adjust their browser window width to test different sizes. This could be implemented in a user script or gadget to test it out. isaacl (talk) 13:44, 24 June 2024 (UTC)
I am not sure that many different sizes are important. If it looks ok on a 40-character wide phone/window and on the editor's full screen desktop, it probably looks ok on other sizes too. But the Mobile preview should open in a window that can be resized. That is detail though. The big question is whether a change like this, affecting all editors, has a hope of being accepted. Aymatth2 (talk) 14:22, 24 June 2024 (UTC)
The imperfect approach I am thinking of would just be a link similar to the existing preview link, so it would appear in the same window in the same way. You can resize the window to check any width you want. (I don't really agree that a page can just be checked with one smaller size, but that's a finer level of procedure.) I suggested implementing it as a user script or gadget first, so people can try it out and then its usefulness can be gauged. isaacl (talk) 16:50, 24 June 2024 (UTC)
There's a gadget "Mobile sidebar preview: show page in mobile view while browsing the desktop site" which shows the mobile view at the side when on the desktop site. I feel like there used to be a gadget/script to do something similar only when editing/previewing, but can't find it now. the wub "?!" 17:06, 24 June 2024 (UTC)
I think "Mobile preview" needs to open a separate window about 2.5" text width plus horizontal and vertical scroll bars . It should not be a gadget that editors have to install, and should not fill the edit window. When I use mobile preview on a page after saving, it shows just a bit narrower than the desktop view, otherwise not much different. Images and infoboxes float as usual. I do not get the effect of viewing on the phone. I can resize the window, although I cannot get it quite as narrow as my phone, but I don't think editors will bother to resize. They will glance at the mobile view, looks fine, move on. When they click on "Mobile preview" they should see it the way it will look on a typical phone. They can then resize to see, e.g., a larger mobile screen.
That said, if we bring this to a formal proposal, we can encourage editors to try the gadget and try mobile preview and resizing. Aymatth2 (talk) 17:35, 24 June 2024 (UTC)
Many gadgets are on by default. The reference hover-preview is a gadget. Aaron Liu (talk) 17:44, 24 June 2024 (UTC)
I would caution against treating your typical experience as being typical for everyone; there are a lot of different devices out there and conditions vary in different countries. That being said, I enabled the mobile sidebar preview (thanks, User:The wub!) and I think it does a reasonable job. If it could be enhanced to support preview during editing, that would be great. isaacl (talk) 17:56, 24 June 2024 (UTC)
Assuming a separate window opens, default the size of a typical phone, we could give it a menu (maybe drop-down or icons) to let the user select other common formats. Aymatth2 (talk) 18:49, 24 June 2024 (UTC)
Personally, I think just something ~400px wide is enough; the height doesn't really matter much, and the iPhone SE is 375px wide. Aaron Liu (talk) 20:02, 24 June 2024 (UTC)
Sure; that functionality could be implemented now in the gadget, even without a separate window. isaacl (talk) 21:10, 24 June 2024 (UTC)
I can.t find the gadget. Maybe it has been disabled. I used to have the script that did it while editing, but got rid of it recently. I had not used it for years, and it was acting up.
Aymatth2 (talk) 17:59, 24 June 2024 (UTC)
I don't think this is triggerable from site JS and I'm not saying that a "Mobile preview" button should be abandoned, but most desktop browsers have a responsive-viewport mode. You open DevTools (usually with F12 or Ctrl/Cmd+Shift+i), and click on the button with a phone and a tablet. Aaron Liu (talk) 17:20, 24 June 2024 (UTC)
I am sure there is a way. If we got agreement, which may be very tough, we should be able to get the MediaWiki software changed to support it if need be. Aymatth2 (talk) 17:46, 24 June 2024 (UTC)
It's a browser thing, so as a matter of security I'd expect it to be isolated from webpages. Aaron Liu (talk) 17:49, 24 June 2024 (UTC)
No, I think it would be a security vulnerability if a web site could trigger your dev tools to launch. I'm aware of this functionality, but I think something like the existing mobile preview gadget is much more likely to be used by a broader segment of editors. isaacl (talk) 17:50, 24 June 2024 (UTC)
Jinx! Aaron Liu (talk) 17:50, 24 June 2024 (UTC)
I see websites opening sub-windows all the time. No idea how they do it, but I don't think there is a security issue. Aymatth2 (talk) 18:23, 24 June 2024 (UTC)
Sub-windows are just other websites while opening devtools is sort of like opening your command prompt. Aaron Liu (talk) 18:26, 24 June 2024 (UTC)
Also note that opening up lots of windows is a common ad spam and malware technique, so browsers started to block that behaviour. isaacl (talk) 18:30, 24 June 2024 (UTC)
I can't see the browsers blocking Wikipedia when it opens a second window within the first. But maybe it could be done with some sort of <div> floating on top of the edit window, and displaying the visible part of the mobile rendering of the edit box content. I have great faith in the ability of the techies to find a way. Assuming it can be done, what would the more conservative editors object about? They still have the "Desktop preview" button, but now they can see the mobile 75% view. Aymatth2 (talk) 22:54, 24 June 2024 (UTC)
Browsers usually block new windows that aren't directly from the click of a button or link. Aaron Liu (talk) 23:04, 24 June 2024 (UTC)
In this case the new window would, I presume, be from a click on a link. The target url would return a window the right size and position. But the real question is whether the editors who think mobile phones are just a passing fad will reject the idea out of hand. Aymatth2 (talk) 00:20, 25 June 2024 (UTC)
I believe we should reject editors who believe phones are a passing fad instead.
Anyway, I feel like the approach of the gadget—adding a button that makes the mobile version show up at the side—would be better than necessitating the editor to switch to another window or unfullscreen the previous one. Aaron Liu (talk) 00:54, 25 June 2024 (UTC)
I wasn't commenting on a specific implementation for either the existing gadget or a new gadget/script. I was just responding to your reply to my comment on the security concern with opening new windows. Changing the page layout to add a sidebar, which is done by the current mobile preview gadget, sounds more like what you mean by a "sub-window" (there is no sub-window concept per se in HTML, leaving frames aside). isaacl (talk) 01:08, 25 June 2024 (UTC)
Publish changes
Mobile preview
Desktop preview
Show changes
Cancel
Editing help
The important thing, I think, is
  • The editor sees a line of buttons at the foot of the edit window something like the crude mock-up above
  • "Mobile preview" is placed before "Desktop preview", since it shows what 75% of readers will see
  • When they click "Mobile preview", the editor sees the edited page in mobile format, the same size as on a typical phone, with horizontal and vertical scroll bars if needed.
  • It would be nice, but inessential, to be able to resize the preview to see the appearance on smaller or larger phones or tablets.
If the cleanest way to achieve that is to open a sidebar, no problem. We should stay receptive to other techniques. As I type this reply, I see a preview that shows how it will look on the desktop below. I don't know how that is done. Maybe a sidebar is just a variant.
My main concern is resistance to adding yet another button to the editing interface. I wish we could anticipate the objections. Aymatth2 (talk) 13:05, 25 June 2024 (UTC)
Yes, you've already mentioned your concern, and I stated how implementing the feature in a gadget or script would allow feedback to be collected.
Have you tried the current mobile preview gadget? It adds a preview off to the side of the main text flow. You can close it and then there will be a button in the horizontal menu bar below the article title that lets you re-enable the preview. I think using the same interface would be a good way to go. isaacl (talk) 14:28, 25 June 2024 (UTC)
I can't find the gadget. I go to Preferences - Gadgets and it is not in the list. Aymatth2 (talk) 14:46, 25 June 2024 (UTC)
I found the problem. Not using the default skin. Yes, that looks good, although it needs sideways scrolling.
I agree. A good first step would be to get a version built for the edit window, and get feedback. Once any problems were cleared, it could be launched from the new "Mobile preview" button. Aymatth2 (talk) 14:55, 25 June 2024 (UTC)
I think it would be better to just reuse the existing mobile preview button that appears in the horizontal menu bar when the preview sidebar has been collapsed. isaacl (talk) 15:19, 25 June 2024 (UTC)
Do you mean the menu bar right at the foot of the page?
Privacy policy  About  Wikipedia  Disclaimers  Contact Wikipedia  Code of Conduct  Developers  Statistics  Cookie statement  Mobile view
I think very few editors know it exists. We need something conspicuous when the editor goes to save their changes. Aymatth2 (talk) 16:04, 25 June 2024 (UTC)
No. With the mobile preview gadget enabled, there is a sidebar with the mobile preview, which has an "X" button that lets you close it. As I mentioned, this causes a button to appear in the horizontal menu bar below the article title that lets you re-enable the preview (next to the watchlist star). If the gadget were extended so it supported previewing the page during editing, then editors could just turn on the preview using the same button. This re-uses their experience with the mobile preview gadget. isaacl (talk) 16:17, 25 June 2024 (UTC)
The little   button at the top right. I see it now. That is good when editors are testing out mobile preview, but as long as the gadget is optional, few will see it. Once it is enabled by default, some may click on it. But until a "Mobile Preview" button is enabled beside the "Save Changes" button, editors are much more likely to preview the desktop version and not the mobile version. Aymatth2 (talk) 17:04, 25 June 2024 (UTC)
Getting people to try out an optional gadget is how we can gain feedback before changing defaults (such as enabling the gadget) for everyone. isaacl (talk) 22:15, 25 June 2024 (UTC)
Fully agree. The first step is to get the gadget written. I assume it will be an adaptation of the current gadget, adapted to use the edit window text. Then it is optional for a while until fully proven, then default for a while, then the last step is the "Mobile Preview" button. It could take quite a long time. What would be the right forum to ask for development of the gadget? Aymatth2 (talk) 22:34, 25 June 2024 (UTC)
WP:US/R Aaron Liu (talk) 15:26, 27 June 2024 (UTC)
Thanks. I will wait a few days to see if anyone wants to add to this discussion, then go there. Aymatth2 (talk) 17:05, 27 June 2024 (UTC)

why I am voting no on the Movement Charter

Latest comment: 6 months ago13 comments3 people in discussion

suggest you vote "no" on the current vote to ratify the Movement Charter. for more discussion, feel free to read this section: meta:Talk:Movement_Charter#Why I voted "No"

here is a quote from that page, by someone else there, not myself:

I cannot support a charter that provides for representation of/selected by affiliates (as opposed to community-elected members who happen to also be involved with affiliates) on the Global Council, for substantially the reasons I stated at m:Talk:Movement Charter/Archive 5#Mdaniels5757's thoughts. Ultimately, I am concerned that affiliates, as a group (1) are distinct from the community at-large, and therefore (2) have different interests than the community at large. This causes the potential for a fox-guarding-the-henhouse situation; affiliates should not have a vote in movement-wide funding distribution matters. Although I think the small changes to voting thresholds were a step in the right direction, we are still a far way away from a Charter that I can support: one that centers the entire Wikimedia Community.

thanks. Sm8900 (talk) 09:25, 27 June 2024 (UTC)

I would like to encourage open-minded discussion of this idea. in that spirit, here is a link to enable you to read one relevant section of the proposed charter, yourself. i sincerely hope this will be beneficial to provide helpful discussion amongst different opinions on this issue.

link: meta:Movement_Charter#Global Council#Initial creation and future expansion

--Sm8900 (talk) 11:26, 27 June 2024 (UTC)
The main point of involving affiliates in high-level decisions is that if it were a direct democratic vote, the English Wikipedia would decide everything for everyone every time. Having affiliates all around the world and engaging them for decisionmaking purposes ensures they get a say. There are also the other arguments in representative democracies vs. direct democracies. For example, following what goes on at the Wikimedia Foundation -- governance, strategy, grants, concerns from individual projects, etc. -- and evaluating the consequences of those decisions/opportunities requires a huge amount of time. I'm not part of leadership in any affiliate now, but when I was and it came time to make a decision on behalf of the chapter, we really put in time to ensure we understood the situation. Like for the affiliate-selected board seats, we actually read up on and researched all of the candidates, took notes, met to discuss, and in some cases even invited them to meet with us. How many individual community members have the capacity to take that time, or to read/follow the whole movement strategy process, or to understand the ins and outs of grant proposals, etc., let alone want to take that time?
There are some, of course, and I would never want to rely on a system that's completely based on representation. Indeed the initial global council is mostly community-elected, and that group can change its composition as it sees fit. But no, it's not some secret club of power-hungry weirdos. Well, maybe weirdos, but it's usually really easy for other weirdos with an affiliate nearby to get involved in that process and have a say -- it's not particularly exclusive.
Also, do we need new sections to present our individual for/against positions and canvass for votes? — Rhododendrites talk \\ 14:12, 27 June 2024 (UTC)
@Rhododendrites, good to have your reply. everything you just said is totally valid. and in my own personal mundane opinion, this is why we do not need a movement charter.
as you note, leaders of affiliates are already highy active , diligent and well-informed. it is unnecessary to enact a whole legalistic new structure which unnecessarily elevates them to some newly-defined level of statutory authority. they already have some solid influence, mainly due to their own hard-earned efforts and diligent knowledge in the processes that already exist now.
the current processes originated from natural community processes over time. i would much rather keep what we have, and not proceed with any adoption for the movemment charter.
the above is just my own personal opinion. and by the way, I want to publicly thank my fellow editor above and also publicly say that i have spoken to them a few times and they happen to be a genuinely helpful person in real [non-virtual] life. a cup of tea for you. thanks!  Y   Sm8900 (talk) 14:20, 27 June 2024 (UTC)
just to reply further and to comment further, if i may. you said: it's not some secret club of power-hungry weirdos. Well, maybe weirdos, but it's usually really easy for other weirdos with an affiliate nearby to get involved in that process and have a say -- it's not particularly exclusive.
I would differ with that somewhat. it is a new council, correct? it has 28 members, correct? and even if it had 128 members, there would still be the same problem. any official hierarchical body, by its very nature, is not something that "anyone" can get involved in. I don't see a need to create a whole new official body, give it some set of vague powers, label it the "global council," and then hope it is helpful.
currently the influence and power resides mostly with the hardest-working editors, including the outstanding folks who help to run various affiliates. i am fine with the existing structure and the existing hierarchy, and i would like to keep it, and i would like to not adopt this particular proposal. thanks. Sm8900 (talk) 14:47, 27 June 2024 (UTC)
it is a new council, correct? - FWIW the "not particularly exclusive" was still part of my response about affiliates, not the global council. — Rhododendrites talk \\ 15:08, 27 June 2024 (UTC)
ok, noted, thanks. Sm8900 (talk) 15:31, 27 June 2024 (UTC)
@Rhododendrites, ok let's discuss if that's ok. can someone please tell me, what exactly is this "Global Council"? does it have intrinsic top-level authority? who is supposed to run it, and what is it supposed to do? does it outrank all admins? all stewards? what specifically is being proposed here?!! Sm8900 (talk) 18:43, 27 June 2024 (UTC)
I do not have access to any additional information beyond what's in the current charter. — Rhododendrites talk \\ 19:17, 27 June 2024 (UTC)
@Sm8900, I haven't read the proposed charter, and I haven't followed this project, but I believe that the overall idea (whether this particular version gets adopted or not) is to shift some power away from the WMF and towards the larger, more established affiliate organizations.
From the POV of the online-only English Wikipedia editor, think of something like "Every year, some organization has to decide how much money has to be raised each December with banners at the English Wikipedia. Do I want the WMF to make that decision, or do I want a committee dominated by [for example] WMDE and WMUK to make that decision?"
In both cases (the WMF's board vs the Global Council), the group making the decision will be mostly made up of people who were primarily voted in by the English Wikipedia. WhatamIdoing (talk) 01:18, 28 June 2024 (UTC)
@WhatamIdoing ok, yes, I agree that your comments are accurate, and I agree that that was the underlying idea. however one main question that I have might be, how did we delegate a committee to devise and fomulate a charter document, and instead what we got was a newly-constructed governing body, with overall authority? wouldn't it have made more sense to simply set up some new task forces with a specific scope, and limited roles, for specific goals and purposes? Sm8900 (talk) 03:39, 28 June 2024 (UTC)
Creating a "Global Council" was one of the major recommendations from the 2030 strategy discussions. See m:Movement Strategy/Recommendations/Ensure Equity in Decision-making. The task was to Create a Movement Charter to: Lay the values, principles and policy basis for Movement structures, including the roles and responsibilities of the Global Council. This is not a case of saying that we want A and accidentally ending up with B; this is a case of saying that we (or "they", if you prefer) want a newly-constructed governing body with overall authority and doing their best to create a newly-constructed governing body with overall authority.
If you think it would have made more sense to do something different, then unfortunately the time to say that was about five years ago. However, to the extent that the real goal is "take power [or funding, which is its own kind of power] away from them and give it to me", then I doubt that some new task forces with limited scope or roles would be able to achieve that goal. WhatamIdoing (talk) 04:22, 28 June 2024 (UTC)
Ok your reply is very informative and helpful. This is why I posted this here. Thanks for those great helpful details. I will look over those items. Sm8900 (talk) 05:46, 28 June 2024 (UTC)

WikiProject banners unrelated to the article subjects

Latest comment: 6 months ago3 comments3 people in discussion

Each talk page has banners about the specific WikiProjects it falls under. For example, Talk:Henry VIII includes WikiProject banners for Biography, Military history, and England, among others. These all make sense as the article is intrinsically relevant to these subjects. But then occasionally you also see banners like Template:WikiProject Guild of Copy Editors, Template:WikiProject Spoken Wikipedia, Template:WikiProject Women in Green, and Template:WikiProject Women in Red. These aren't actually relevant to the subject, and they don't really tell us anything meaningful about the article. It doesn't change the article's status because of where someone got the idea to create it or why someone copyedited it. What they do is contribute to banner blindness. Is there any value in keeping these banners in article-talk namespace when they primarily serve as an "our group was here" notice? Thebiguglyalien (talk) 23:07, 28 June 2024 (UTC)

Regarding banner blindness: these aren't banners that have to be read. They can optionally be read by any interested editors. WikiProject banners enable article alerts to be delivered to interested WikiProjects. isaacl (talk) 01:51, 29 June 2024 (UTC)
Talk page contents, including WikiProject banners, are not meant to tell us anything meaningful about the article or to change the article's status. They are meant to tell you where you can get help ("Hey, it says you already copyedited it, but it's still really bad!") and to tell other people (e.g., the Wikipedia:Version 1.0 Editorial Team) some things (e.g., which lower-quality pages to prioritize). WhatamIdoing (talk) 02:06, 29 June 2024 (UTC)

Wikipedia:MOS on Music / Song Track Listing Credits

Latest comment: 6 months ago6 comments6 people in discussion

I was reading Let_It_Be_(album) #Track_listing and perplexed to find the tracks credited to Lennon–McCartney. While this was the mythos at the time, later scholarship has done a great job distinguishing many of the Beatles tracks as predominantly or entirely written by Lennon or McCartney. I can't seem to find the style guideline on this, but I assume it's something like "song credits should be as written on the original release."

This is unencyclopedic and ahistorical. While most song credits will line up neatly with later scholarship, some rare cases exist where listed credits were chosen for political or business reasons.

The style guide should default to credits as printed (except in cases where artists changed their name later), but allow for those to be de-emphasized in favor of newer research. For example, Let_It_Be_(album) #Track_listing's writer credits should be almost the same as the lead vocalist credits. Anonymous-232 (talk) 20:16, 16 June 2024 (UTC)

The MOS is a style guide that really doesn't deal with what sources are best to use in a given situation, which is why you couldn't find such guidance in it; it's possible that WikiProject Music has some sort of established norm for this, but Wikipedia policy (see WP:V) already greatly favors information in reliable, secondary sources. If such consensus in scholarship exists, and it's cited, I doubt anyone will have an issue with changing the credits of songs to fit that consensus. ~Adam (talk · contribs) 02:55, 17 June 2024 (UTC)
[2] Rolling Stone interview with Paul about it the credits. Should we be changing what was agreed? Davidstewartharvey (talk) 08:41, 17 June 2024 (UTC)
My gut feeling is that the track listing should match the credit listed on the actual release. Later discussion (whether scholarly research, notable speculation or something in between) is something that should be discussed in prose (maybe accompanied by a list in some cases) that explains the background, why this is a thing that has been researched/speculated about and what the basis for assigning different authorship to each track is. Thryduulf (talk) 09:07, 17 June 2024 (UTC)
Track listing should be as published at time of release. The text of the article can cover anything else: pseudonyms, legal challenges, scholarly analysis, etc. --User:Khajidha (talk) (contributions) 12:33, 17 June 2024 (UTC)
I would argue that since the article is about the album, the track listing ought to be documenting what is credited. CoffeeCrumbs (talk) 08:01, 29 June 2024 (UTC)

Category:Wikipedia cleanup by subject

Latest comment: 5 months ago5 comments2 people in discussion

Hi, I was wondering whether there was a way to improve Category:Wikipedia cleanup by subject, at the moment it looks like people have to group articles manually. It doesn't seem like articles are assigned part of a wider topic/s on creation, if I'm not mistaken, which would make it problematic to group based off of subjects and tags. I was just thinking it'd be useful to have subjects like Science, History, Geography, Culture and society, Miscellaneous etc.Kowal2701 (talk) 15:37, 30 June 2024 (UTC)

Could this not be done by grouping by first wide-ranging WP banners and then cleanup tags? Kowal2701 (talk) 15:42, 30 June 2024 (UTC)
It seems like WP:Cleanup seeks not to discriminate by subject Kowal2701 (talk) 15:48, 30 June 2024 (UTC)
There is a bot that creates lists based on wikiproject – the "by topic" link at the top of the category EdwardUK (talk) 17:45, 30 June 2024 (UTC)
You're right, sorry I didn't notice that Kowal2701 (talk) 17:59, 30 June 2024 (UTC)

See wikidata topics with many articles, but no enwiki article

Latest comment: 5 months ago8 comments6 people in discussion

I think some tool through which we can see Wikidata items that have lots of articles and no enwiki article would be a great way to improve the encyclopedia and get important articles written. If something has an article in 25 languages, and none in English yet, that's a good sign that we need to get moving. What do you all think? ꧁Zanahary꧂ 00:04, 2 July 2024 (UTC)

I thought we had this, but I've not been able to find it. Wikipedia:WikiProject Missing encyclopedic articles exists but has been inactive since circa 2014. The bottom of that page contains links to many other semi-relevant pages (mostly related to redlinks on enwp), including a bot that did what you are asking (but possibly with the pre-Wikidata system of interlanguage links) but which now 404s. Thryduulf (talk) 01:18, 2 July 2024 (UTC)
Are you looking for Wikipedia:Featured articles in other languages (with language-specific sub-pages)? There's also Category:Featured articles needing translation from foreign-language Wikipedias for manually tagged pages. WhatamIdoing (talk) 05:19, 2 July 2024 (UTC)
I ran a couple of Quarry queries that answers this:
Wikidata items with no English Wikipedia article but articles in at least 25 other languages
Wikidata items with Simple Wikipedia articles but not English Wikipedia
Because I don't know how to exclude items that relate to non-article space pages without querying the individual Wikipedia's, I have excluded all items that have ":" in the page name; this will cause some articles to be incorrectly excluded, but it will get most of them. (Cryptic, any thoughts on a better way to do this?) BilledMammal (talk) 09:15, 2 July 2024 (UTC)
The top one is interesting. Radio Studio 54 Network exists in 132 languages... seemingly all created by the same remarkably-polyglot Italian editor. It was deleted on enwiki in 2020 so maybe what this is really measuring is which projects aren't so good at detecting cross-wiki spam. – Joe (talk) 09:43, 2 July 2024 (UTC)
And all of the top ones I've looked at so far do exist, there are just errors on Wikidata. – Joe (talk) 09:50, 2 July 2024 (UTC)
I'm not that familiar with the wikidata (sql) schema, but I don't immediately see a better way to do it. (The way wb_items_per_site stores the external wiki page names with localized namespace names is particularly frustrating, given that the local wikis don't have that data anywhere and the hoops we have to jump through to get them to display nicely in queries.) I'd suggest asking at d:WD:RAQ. —Cryptic 10:17, 2 July 2024 (UTC)
You can do this with a combination of SPARQL queries and ListeriaBot. That's how the Women in Red redlink lists based on Wikidata are created, for example. – Joe (talk) 09:37, 2 July 2024 (UTC)

Why is there no "Proposed Edits" feature?

Latest comment: 5 months ago12 comments7 people in discussion

Self explanatory, I think it would really help in preventing vandalism. Cyb3rstarzzz (talk) 14:25, 2 July 2024 (UTC)

Wikipedia:Pending changes Aaron Liu (talk) 15:29, 2 July 2024 (UTC)
When I read "proposed edits", I had suggested edits in mind more than pending changes. :) Trizek_(WMF) (talk) 17:34, 2 July 2024 (UTC)
Well, that wouldn't prevent vandalism, eh? Aaron Liu (talk) 17:48, 2 July 2024 (UTC)
Actually, as suggested edits guide users, they are less likely to make mistakes. Which means their edits are less likely to be considered as vandalism (let's not forget that this term is often a catch-all for anything that isn't good enough). Trizek_(WMF) (talk) 13:21, 3 July 2024 (UTC)
The German-language Wikipedia has a type of Pending changes enabled for all articles. It prevents vandalism from being shown to readers. You know what else they have? Only 60% as many editors as they did 10 years ago. When people can't see their first efforts (mistakes and all) show up in the mainspace, they give up.
To replace an editor who makes my volume of edits, we need 30,000 (thirty thousand!) newbies to make – and usually screw up – their first edit. Thirty thousand first edits turns into only 5,000 autoconfirmed editors. Five thousand autoconfirmed editors turns into a mere 100 editors who will make 1,000 edits. And that's just to replace me. We have 10,000 experienced editors active in any given month, and 100% of us will someday stop editing. This community overall is just barely balanced. We cannot afford to discourage even more of those newcomers by making their first efforts feel ineffective. WhatamIdoing (talk) 18:25, 2 July 2024 (UTC)
You put that really nicely.
I think we've touched on a subtler aspect of this conversation: the point generally is to balance boldness with article quality, broadly construed. If Wikipedia was hooked directly to my neurons with no filter, I'd be in big trouble, but I'd be the boldest editor you've ever seen. I agree with the assessment that on the whole, we have it about right. (Or rather, that we are barely hanging on.) Donald brought up below that low-traffic articles would suffer the most from being locked up. Equivalently, they seem also to suffer the most from editorial growing pains, as it were. I'm not sure whether there's anything to consider there beyond making more personal trips to review underserved articles, but I think I can admit that when I get WP:BITEY, it's often informed by something like "if I didn't catch this, it would have stayed here for a decade". That's not the new editor's fault, but the angst is something to ponder? Remsense诉 09:17, 3 July 2024 (UTC)
No matter the type of barrier to set up, vandals will always manage to vandalize. But he more barriers you put in the way, the more likely you are to scare off bona fide users who are unsure of their actions. It adds to the regeneration issues any community faces, as WhatamIgoing describes.
There is another path, currently explored by the Wikimedia Foundation's Editing team with Edit check: instead of leaving newcomers alone when they click "edit", we can detect what they are doing and provide direct advice. The first check created and tested detects if a paragraph is added, and, if so, it encourages users to add a citation. Some people give up (as they don't have one) but many more add a citation.
We are designing the next possible check around copy-pasting. If you are curious about it, we host a community conversation on 3 July 2024 at 17:30 UTC. Everyone is welcomed. Trizek_(WMF) (talk) 13:27, 3 July 2024 (UTC)
To be clear, I wasn't even thinking about vandalism, just good faith edits that nonetheless make the encyclopedia worse. I wish there were more tools to leverage existing work more efficiently: I feel we can basically do everything we want to do to "finish" Wikipedia by more efficiently synthesizing work that's already been done over the past 22 years. This is off-topic but it's been on my mind a lot. Remsense诉 13:46, 3 July 2024 (UTC)
I truly believe that Growth features and Editing's Edit check are promising features to help newcomers making better quality edits from good faith users. :) Trizek_(WMF) (talk) 15:59, 3 July 2024 (UTC)
We encourage new editors to boldly edit articles. — xaosflux Talk 18:46, 2 July 2024 (UTC)
I once supported applying pending edits everywhere. I've changed my mind. The thing is that until a pending edit is dealt with (either approved or reverted), no subsequent edits will show. On low traffic articles a pending edit might wait a long time until someone who can review pending edits comes along and decides to deal with it. On high traffic articles, pending edits may be cleared fairly quickly, but there may be several subsequent edits caught in the queue before the pending edit is cleared. I no longer see any advantage to using pending edits. Donald Albury 19:42, 2 July 2024 (UTC)

Ban the use of subpages on Portals

Latest comment: 5 months ago9 comments6 people in discussion

Contrary to what was suggested in Wikipedia:Arbitration/Requests/Case/Portals#Community discussion recommended, little progress has been made since then. I have updated some portals such as Portal:The arts and Portal:Science, but the result has been less than satisfactory. The concept of a portal based on transclusion seems to me to be far superior to the concept of a portal based on sub-pages. But even it has a lot of problems, such as script errors and unreliable transclusion of content. I have ideas for a simple portal concept, based on .css, WP:LINK and KISS principle like Main Page or WikiVoyage Main page[3].

But one step at a time, before proposing something new, I would like to discuss whether the subpage model is really obsolete and whether it is positive to ban the use of Subpages in portals. Per WP:SP 4. Portal subpages—for Portal-specific templates and content.Guilherme Burn (talk) 18:19, 5 July 2024 (UTC)

@Guilherme Burn, I doubt that most editors know enough about this to actually understand what you're talking about. Maybe provide a pair of matched examples, one using a subpage and the other not? WhatamIdoing (talk) 19:18, 5 July 2024 (UTC)
Agreed, and I'd add that maybe it is time we actually had the discussion suggested in the arbcom case, and this could be one of several proposals. Just Step Sideways from this world ..... today 19:24, 5 July 2024 (UTC)
Examples of the use of transclusion, Portal:Countries, Portal:Religion, examples of portals using subpages Portal:Mathematics, Portal:Literature, Portal:Society. Guilherme Burn (talk) 19:51, 5 July 2024 (UTC)
On Portal:Countries I just see a lot of big red error messages saying "The time allocated for running scripts has expired." That doesn't really speak for the transclusion approach. – Joe (talk) 06:42, 6 July 2024 (UTC)

It must be done right. These portal conversions are being done too hastily by people who don't know the subject matter. For example the bio of Jamie Lee Curtis was once transcluded on Portal:Sex work. Schierbecker (talk) 20:01, 5 July 2024 (UTC)

This is a good example of the problem of transclusion, as I mentioned. (I am even the author of this mistake :facepalm), the content was taken from List of prostitutes and courtesans where it is quoted.Guilherme Burn (talk) 21:23, 5 July 2024 (UTC)

"Curated subpages" and "transclusion directly from articles" can both be used and both make sense. Selected anniversaries like at Portal:Germany are an example where I think the subpage model is superior. On the other hand, direct transclusion is the only sensible choice for selected articles that can easily go out of date, like all BLPs. —Kusma (talk) 07:17, 6 July 2024 (UTC)

For more hybrid ideas: Portal:Germany/Selected article uses subpages, and many (not all) of them use transclusion from articles. —Kusma (talk) 07:27, 6 July 2024 (UTC)

What to do with near-empty lists of names of obscure asteroids?

Latest comment: 5 months ago17 comments12 people in discussion

At Wikipedia:Articles for deletion/Meanings of minor planet names: 500001–501000, it was suggested to start a broader discussion about what to do with these lists. We have now 568 (and counting) such lists (Category:Lists of meanings of minor planet names, and while the lower-numbered ones are about notable subjects where the lists are perfectly acceptable as is, the higher-numbered ones are a collection of explanations of the names of obscure asteroids, named after obscure people (e.g. the great-grandfather of the discoverer of the asteroid, Meanings of minor planet names: 623001–624000). Should these be deleted, merged, ...? Simply keeping something like Meanings of minor planet names: 618001–619000, a one-entry list sourced to a primary source, seems to go against all notability guidelines and what is accepted for other topics. And where is the cutoff between the notable ones and the non-notable ones? All ideas to help write an RfC or other proposal about this are welcome. Fram (talk) 07:51, 20 June 2024 (UTC)

One problem here seems to be that the structure of the lists that makes sense for the first 20k or so entries is extended to 700k entries. Aggressive merging into larger lists covering 10k-100k asteroids each would already substantially improve the usefulness of these. —Kusma (talk) 09:09, 20 June 2024 (UTC)
I looked at Meanings of minor planet names: 623001–624000. It ostensibly covers 1000 minor planets. It has ten ==Sections==, each of which is intended to cover 100 minor planets.
The number of minor planets actually covered is: two (2). On the whole page. There are nine empty sections with nine empty tables, and one section containing a table that has information about two of them.
I'm okay with the page only having a couple of entries; presumably some others will m:eventually get added. But I would like to consider a rule that says there should not be so many empty sections. IMO sections should be added when they're needed, not merely because the page exists. So that's one thing that could be discussed in an RFC: Should the structure be set up before there is content? WhatamIdoing (talk) 21:27, 20 June 2024 (UTC)
Disagree. --Dustfreeworld (talk) 19:01, 21 June 2024 (UTC)
@Dustfreeworld It's not clear to me what part of WhatamIdoing's comment (or maybe something else) you are disagreeing with, let alone why? Thryduulf (talk) 21:30, 22 June 2024 (UTC)
Maybe empty lists could be removed, and the pages consolidated into larger ranges (say, 500001–600000) with only named minor planets discussed in reliable sources? Chaotic Enby (talk · contribs) 20:19, 21 June 2024 (UTC)
Meanings of names in general would be notable, so I would support merging until there is about 100 names on a page. THat is so that the page is worth opening. All the empty sections and tables should be removed. Graeme Bartlett (talk) 08:15, 23 June 2024 (UTC)
Many of them seem to be non-notable though, sourced (and sourceable) only to the naming institution and not remarked upon elsewhere. There are of course exceptions, but among the higher-numbered ones, these seem to be rare. I don't think either of the two entries here is a notable one. Fram (talk) 09:47, 24 June 2024 (UTC)
Why do we have lists of non-notable objects sourced to primary databases in the first place? They serve no navigation purpose and so clearly fail NOTDIRECTORY, which would supersede any LISTPURP "informational" rationale. If these objects didn't have a predictable numbering system I doubt even the named ones would be in lists, much less the unnamed ones. JoelleJay (talk) 17:42, 23 June 2024 (UTC)
Because muh hard work putting it all together! I hate to say this, but I think the answer is "keep sending it back to AFD until we get it right". 35.139.154.158 (talk) 21:56, 4 July 2024 (UTC)
Can you give one way in which the existence of these pages affects you whatsoever? jp×g🗯️ 00:29, 7 July 2024 (UTC)
Currently, if I look at the page Meanings of minor-planet names, there are several tables in the article, with hundreds of cells in them, and the majority of them are redirects back to the parent page because they don't have anything in them. Whereas the ones that actually do have entries have specific articles. I think this is basically fine, even if it does give rise to the weird edge-case situation where we end up with some list-section article with onle one or two or three entries. "Fixing" this, I reckon, would involve going through and restructuring all of the articles to have different spans of objects in them, which I think would be insanely complicated. jp×g🗯️ 00:32, 7 July 2024 (UTC)

Deprecate AFD subcategories?

Latest comment: 5 months ago7 comments4 people in discussion

When nominating an article for deletion, Twinkle (and other tools, presumably?) asks you to categorize it into an AFD subcategory, for example: Category:AfD debates (Science and technology). Tools now also very helpfully include integrated deletion sorting, which essentially duplicates the subcat process while providing much more fine-grained sorting than something as broad as "science and technology". It therefore seems redundant to me, but I thought I'd ask here first as sometimes there are other issues invovled that may actually be helpful to some users. Just Step Sideways from this world ..... today 19:05, 5 July 2024 (UTC)

Yeah I agree that deletion sorting has made these obsolete. – Joe (talk) 19:14, 5 July 2024 (UTC)
The number of page views for that cat suggest that someone's looking at it. https://xkcd.com/1172/ WhatamIdoing (talk) 19:17, 5 July 2024 (UTC)
That's why I posted here first before proposing anything, if it is doing something other than adding an extra step to deletion nominations, that changes the math. Just Step Sideways from this world ..... today 19:29, 5 July 2024 (UTC)
This does amount to <10 a day though. Which, considering that AfD handles something like 50-60 discussions a day, isn't all that much. It could well just be ten newbies curiously clicking through to the category then thinking, "well, this isn't useful". And maintaining these categories isn't free: each discussion must be manually sorted. – Joe (talk) 08:39, 6 July 2024 (UTC)
I agree that these categories are probably no longer needed. Perhaps the users of the categories disagree, though, so in the spirit of WP:LEOPARD, it would be best to tag the categories for WP:CFD so the users are notified properly and can explain the advantages of the categories over the deletion sorting lists (if there are any). —Kusma (talk) 09:22, 6 July 2024 (UTC)
Aaaaand we're live at Wikipedia:Categories for discussion/Log/2024 July 12#AFD topic-sorting subcategories. Just Step Sideways from this world ..... today 22:59, 12 July 2024 (UTC)
Retrieved from "https://en.wiki.x.io/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_58&oldid=1236631767"