Jump to content

Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Berchanhimez (talk | contribs) at 18:57, 25 June 2024 (→Resources on severe mental illness pages: Reply). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, note:

Before commenting, note:

  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62

Wikipedia Hall of Fame?

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

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

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)[reply]
    "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)[reply]
    I agree with Chetsford on this. Wolverine XI (talk to me) 04:11, 9 April 2024 (UTC)[reply]
    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)[reply]
    Never say never. Wolverine XI (talk to me) 13:16, 9 April 2024 (UTC)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    @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)[reply]
  • 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)[reply]

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)[reply]
  • It might be a good idea. 3.14 (talk) 19:07, 8 April 2024 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    "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)[reply]
    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)[reply]
    "would be difficult if they are dead" I imagine it would. Chetsford (talk) 08:48, 10 April 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

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)[reply]

  • 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)[reply]
    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)[reply]
    Good point, but Wikipedia is not baseball. Wolverine XI (talk to me) 06:57, 14 April 2024 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

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)[reply]
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)[reply]
  • 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)[reply]

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)[reply]

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)[reply]
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)[reply]
The stocks aren't a hall of shame, it's a humourous list of mistakes. -- LCU ActivelyDisinterested «@» °∆t° 21:04, 9 May 2024 (UTC)[reply]
Awesome Aasim, isn't WP:Long term abuse already kind of that? — 🌙Eclipse (talk) (contribs) 14:49, 18 May 2024 (UTC)[reply]
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)[reply]

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

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)[reply]

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)[reply]
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)[reply]
Simpsons did it. Just Step Sideways from this world ..... today 20:07, 10 June 2024 (UTC)[reply]
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)[reply]
Guy brings Vitamin C effervescent tablets Aaron Liu (talk) 11:56, 11 June 2024 (UTC)[reply]
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)[reply]

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

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)[reply]

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)[reply]
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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
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)[reply]
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)[reply]
@Folly Mox yes! This is something meta:WikiCite/Shared Citations could address ~ 🦝 Shushugah (he/him • talk) 22:32, 18 June 2024 (UTC)[reply]
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)[reply]
User:SuperHamster/CiteUnseen adds icons according to RSP. Aaron Liu (talk) 02:16, 19 June 2024 (UTC)[reply]
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)[reply]

Ready for the mainspace

I'm here to solicit opinions about what it means for an article to be "ready for the mainspace". This phrase has turned up in hundreds of AFDs during recent years. Here's the story:

You are looking at an article. You have determined that the subject is notable, and that none of the Wikipedia:Criteria for speedy deletion apply to the article. Another editor says to you: "I don't think that article is ready for the mainspace".

What would you guess that the editor means? Is that consistent with our rules, such as the WP:NEXIST guideline or the WP:IMPERFECT policy? WhatamIdoing (talk) 19:32, 28 May 2024 (UTC)[reply]

Personally, and this is just my own opinion here, I find this "ready for the mainspace" thing a little ambiguous. As you said, as long as WP:GNG is met, an article that is properly sourced (or at least whose topic does) deserves to be in the mainspace. Not all articles are perfect, and by having an article in the mainspace, more people will see it and improve it, which is exactly the purpose of Wikipedia. It's a work in progress! Cocobb8 (💬 talk • ✏️ contribs) 19:45, 28 May 2024 (UTC)[reply]
I think it's a little ambiguous, too, which is why I'm asking. ;-) WhatamIdoing (talk) 20:14, 28 May 2024 (UTC)[reply]
However, WP:DRAFTIFY clearly states that the aim of moving an article to draft is to allow time and space for the draft's improvement until it is ready for mainspace, so maybe a change to that guideline could be required to make it clearer? Cocobb8 (💬 talk • ✏️ contribs) 20:17, 28 May 2024 (UTC)[reply]
If we can figure out what it means, that might be helpful. WhatamIdoing (talk) 20:32, 28 May 2024 (UTC)[reply]
I would generally interpret it as "WP:N has not been shown." Gråbergs Gråa Sång (talk) 19:53, 28 May 2024 (UTC)[reply]
Then what about you have determined that the subject is notable per @WhatamIdoing's original comment? Cocobb8 (💬 talk • ✏️ contribs) 20:02, 28 May 2024 (UTC)[reply]
If I couldn't see for myself why the other editor would say that, I'd ask. For myself, I could see saying "not ready for mainspace" for something so poorly or inappropriately written that it does a disservice to the topic and the reader (although I'd probably say specifically what my concern was). Schazjmd (talk) 20:12, 28 May 2024 (UTC)[reply]
Wikipedia:Drafts#During new page review says that it's enough that the topic is plausibly notable to draftify. An unsourced article with a claim of significance (or notability) could fit this description, not being eligible for WP:A7 but still not meeting the referencing standards for mainspace. Chaotic Enby (talk · contribs) 20:34, 28 May 2024 (UTC)[reply]
In my opinion, if the article draft meets all of the following it's ready for mainspace:
  • Is not being discussed at XfD
  • Would not meet a speedy deletion criterion in article space
  • Has no identified copyright, BLP, etc issues
  • Has sufficient sources to demonstrate notability
  • Has been at least minimally proof-read (perfection is not required, basic readability is).
  • Has no in-line editing notes ("need to reword this", "add more info here", etc) (excluding templates and hidden comments).
  • Has no obviously broken templates (if you don't know how to fix it, ask for help before moving). Thryduulf (talk) 21:22, 28 May 2024 (UTC) ("article" changed to "draft" for clarity Thryduulf (talk) 23:20, 28 May 2024 (UTC))[reply]
I'm not sure why you're asking in this venue. The only way to know is to ask the editor making the statement what they meant. Even if it could be done, I don't think it will be helpful to try to establish a common interpretation. Editors should be specific about their concerns. isaacl (talk) 22:15, 28 May 2024 (UTC)[reply]
It's difficult to ask hundreds of editors. Also, if everyone has their own ideas, then the phrase becomes useless. We might as well just say WP:IDONTLIKEIT in that case. WhatamIdoing (talk) 22:29, 28 May 2024 (UTC)[reply]
The phrase is useless on its own, as it's not specific. It sounds more like you want to revisit the criteria for deleting an article, to examine what should be considered showstopping shortcomings. Commenters in deletion discussions should be encouraged to list those shortcomings. They can optionally add that as a result, the article isn't ready for the mainspace. isaacl (talk) 22:48, 28 May 2024 (UTC)[reply]
I do not want to revisit the criteria for deleting an article. Also, if you take a look, this phrase frequently is given as a reason for not deleting the articles (but instead moving them to Draft: or User: space).
Consider Wikipedia:Deletion policy#Deletion of drafts: "If an article isn't ready for the main namespace, it can be moved to the draft namespace". Commenters in deletion discussions can listed specific shortcomings, but the deletion policy itself can't. Is this a matter of pure consensus, in which case it's nearly indistinguishable from IDONTLIKEIT (which sounds worse than it probably would be in practice)? Does it mean, e.g., what @Thryduulf said about "Has sufficient sources to demonstrate notability", in which case WP:NEXIST is no longer valid? Would a visibly broken template count as the sort of IMPERFECT thing that the deletion policy won't countenance? WhatamIdoing (talk) 23:09, 28 May 2024 (UTC)[reply]
To be clear, my criteria are for moving a page from draft space to article space, not for moving a page in the other direction (where such issues as broken templates should simply be fixed). Thryduulf (talk) 23:18, 28 May 2024 (UTC)[reply]
Articles don't avoid deletion to be moved to draftspace simply because they're not ready for mainspace by someone's measure, but because someone thinks there's promise to demonstrate that the topic meets English Wikipedia's standard for having an article. There's no point in trying to retroactively figure out what others have meant by a non-specific phrase they used in the past. Moving forward, users should be asked to provide specific details, assuming that it's not already clear from context what shortcomings are being considered.
Regarding the quote from the deletion policy, I agree that ideally it wouldn't use a vague phrase. I appreciate, though, that the sentence is trying to be a placeholder to cover any scenario where the participants in a deletion discussion agreed that the best course of action was to move the article to the draft namespace. It's essentially tautological. isaacl (talk) 00:05, 29 May 2024 (UTC)[reply]
If it means "by consensus at AFD", then it should say that. We could change the deletion policy to say that.
In re no point in trying to retroactively figure out what others have meant by a non-specific phrase they used in the past, I don't agree. This phrase seems to mean something to people. You are the only editor who thinks that understanding what we want to communicate (in about a thousand AFDs, in the deletion policy, twice in Wikipedia:Drafts, in more than forty thousand pages all told). When a bit of wiki-jargon has been used tens of thousands(!) of times, I don't think that figuring out what we mean, and whether we all mean the same thing, is pointless. If it doesn't interest you, then that's fine, but please don't tell other editors that what they've been saying is meaningless.
Also, I suspect that in a substantial fraction of cases, "not ready for mainspace by someone's personal standards" is exactly what is meant. WhatamIdoing (talk) 02:10, 29 May 2024 (UTC)[reply]
To clarify, I mean from my view, there's no point in trying to guess at the meaning in a village pump thread. If we're serious about trying to figure it out, we should be systematic: take a sampling and ask the editors in question if they're still around. We can also analyze the discussion threads to see if there is enough context to understand. isaacl (talk) 05:05, 29 May 2024 (UTC)[reply]
This phrase is used in WP:DELPOL and WP:DRAFTIFY. The village pump is the normal place to discuss confusion that affects multiple policy/guideline/help/etc. pages.
But I'm no longer hopeful that we can have that discussion. If you look at this thread, five editors thought they had something useful to contribute. Then you started posting that you thought it was not helpful to figure out what editors mean, that it's useless, that there's no point – and nobody else has shared their thoughts since. I think you have effectively discouraged editors from sharing their their views. WhatamIdoing (talk) 18:54, 31 May 2024 (UTC)[reply]
The main thing that it means to me is that most claims in the article are sourced, and that they're sourced to enough separate reliable sources to establish notability by just reading the references. Many topics are notable in the sense that sources exist out there somewhere, but implicit in the notability guideline is that the reason we're looking to establish there exist such-and-such many reliable sources about a topic is to use those sources to write the article. Any article that does not actually do this is half-baked. Loki (talk) 04:30, 1 June 2024 (UTC)[reply]
@LokiTheLiar, how many existing articles do you think meet the standard of "most claims in the article are sourced"? WhatamIdoing (talk) 21:56, 1 June 2024 (UTC)[reply]
I'm aware that there's lots of bad articles out there, if that's what you're asking. I'd still say that the majority of articles meet that standard, and that the overwhelming majority of traffic to Wikipedia is to articles that meet that standard.
Like, compare naked butler, which doesn't meet the standard I've set here, to complaint tablet to Ea-nasir, which does. They're both small articles on obscure subjects but the complaint tablet one is totally fine. Loki (talk) 22:12, 1 June 2024 (UTC)[reply]
I believe that the complaint tablet has about five times as many sentences as the median article and about ten times as many sources. So if that's the standard, we'd probably be deleting about 90% of current articles. WhatamIdoing (talk) 22:19, 1 June 2024 (UTC)[reply]
To put it another way: The median article is a stub. You have given a C-class article as an example that should be considered a "small article". A quick look at Wikipedia:Version 1.0 Editorial Team#Statistics suggests that my off-the-cuff 90% estimate is correct. Only about 10% of articles (excluding lists, dab pages, etc.) rate as C-class or higher. WhatamIdoing (talk) 22:25, 1 June 2024 (UTC)[reply]
Stub class articles don't necessarily violate this standard. So for instance, I just found a list of stubs and clicked randomly and found Ty Barnett, which clearly meets my standard. Or have Fred Baxter or William Beavers, literally the next two articles I clicked on. All stubs of obscure people, all definitely meet the standard I laid out. Loki (talk) 04:31, 2 June 2024 (UTC)[reply]
  • ORES says the first is Start-class. I think editors might have different opinions about whether it's a long stub vs a short Start, but at 200 words/10 sentences long, it is at minimum on the long side for a stub.
  • The second is a four-sentence, four-source stub, which might put it around the median article for length, but I think it is above average for sourcing.
  • The third is also Start-class. It has 2750 bytes of readable prose and 450 words. This is about twice the length of the maximum described in Wikipedia:Stub#How big is too big? The stub tag was removed from the article during an expansion in 2006. I have corrected the WP:1.0 rating on its talk page.
Looking at Fred Baxter (the second one), would you feel the same way if it had only three sentences and three sources? WhatamIdoing (talk) 06:16, 2 June 2024 (UTC)[reply]
Yes. I don't care about length at all. Loki (talk) 13:44, 2 June 2024 (UTC)[reply]
Are you interested in the number of sources, or the percentage of sentences with inline citations? WhatamIdoing (talk) 18:05, 2 June 2024 (UTC)[reply]
Number of sources only has to be enough to meet the notability guideline. Otherwise it's fraction of claims that need to be sourced that aren't. Loki (talk) 23:39, 2 June 2024 (UTC)[reply]
WP:NEXIST says that the number of citations required to meet the notability guideline is zero. (Per that long-standing guideline, the sources have to exist in the real world, but they don't have to be cited in the article.) There are no claims in User:WhatamIdoing/Christmas candy that need to be sourced (nothing about BLPs, nothing WP:LIKELY, etc.). Is that "ready for the mainspace" in your opinion? WhatamIdoing (talk) 23:51, 2 June 2024 (UTC)[reply]
In my opinion, that article isn't 'ready for mainspace' because it is unreferenced. Cremastra (talk) 00:51, 3 June 2024 (UTC)[reply]
I realize that the notability guideline itself says that the sources just have to exist somewhere, and not be actually present in the article. However, it's pretty clear that the reason the notability guideline says the sources have to exist somewhere is so they can be used to write the article.
My big problem with the example article you linked is that it's not clear that "Christmas candy" is a notable subject separate from specific types of Christmas candy. I also think some of the list of examples is more WP:LIKELY to be challenged than you think. I think that for instance someone who did not know what a szaloncukor was is very likely to start out doubtful that it is Christmas candy. Loki (talk) 02:33, 3 June 2024 (UTC)[reply]
Do you really think I needed to consult sources to write that "Christmas candy is candy associated with the Christmas holiday season. Candy canes are one type of Christmas candy"? WhatamIdoing (talk) 05:25, 3 June 2024 (UTC)[reply]
No, but someone who doesn't celebrate Christmas and has lived in a Hindu/Buddhist/Muslim-majority country all their life might need to. WP:V still stands, whether you like or not. Cremastra (talk) 12:05, 3 June 2024 (UTC)[reply]
WP:V says that it must be possible to find sources (e.g., at a library). It does not say that sources must be cited in the article, except four types of material, none of which are in this article. WP:V is not violated by having those two sentences uncited. WhatamIdoing (talk) 19:31, 3 June 2024 (UTC)[reply]
I would guess the editor means:
  • The article is completely unreferenced, and/or many of the claims are factually dubious
  • The article is written in English, but is barely coherent. It can be understood, so isn't gibberish, but is an embarrassment and not very helpful.
  • The article is blatantly and overtly promotional
Cremastra (talk) 20:30, 1 June 2024 (UTC)[reply]
I could also interpret "not ready for mainspace" to include glaring MOS or technical issues, like:
  • templates outputting nothing but error messages
  • external links peppering article prose
  • infobox with default values for parameters
  • entirely empty sections
  • no subheadings whatsoever, just a giant chunk of text
  • unintentional blockquotes from starting a paragraph with whitespace
  • other Wikipedia pages incorrectly formatted as references instead of internal links
  • etc
Folly Mox (talk) 14:22, 2 June 2024 (UTC)[reply]

First, to emphasize the obvious, "ready for mainspace" is a vague subjective term. Probably the only more objective term that could fall under that is "allowed to exist in mainspace" and the most universal standard for that is "likely to survive a reasonably well run AFD". And for an article (NOT article content) NPP and AFC passage ostensibly follow that. Which in turn (presuming no eggregious speedy or wp:not violations) the main criteria ends up being passing wp:notability. Many people (e.g. at AFC, during mentoring, and in this thread) set a higher standard for "ready for mainspace" which is that the content of the article and the article does not have any significant problems or shortcomings. Yes, this is a double standard, and can make AFC a somewhat rough and arbitrary path. But we need to recognize that it is only human by the person reviewing it. If somebody took an article to you that was allowed to exist in mainspace (usually a wp:notability decision on the topic) but which was in really bad or undeveloped shape, would you be willing to bless putting it into mainspace? Most people would want it to meet a higher quality standard before they would personally say "ready for mainspace". North8000 (talk) 19:21, 31 May 2024 (UTC)[reply]

  • If I'm not mistaken the "not ready for mainspace" phrase originated in WP:DRAFTIFY and has since leaked into deletion discussions. As everyone here seems to agree, it is very poorly defined phrase and, far from the low bars proposed above, I've seen new page and AfC reviewers invoke it for things like a draft not being long enough or using plain text references instead of {{cite}} templates. Rather than trying to define it, I think we should purge it from guidelines and templates in favour of listing specific problems in an understandable way. – Joe (talk) 12:35, 4 June 2024 (UTC)[reply]
    Rather than trying to define it, I think we should purge it from guidelines and templates in favour of listing specific problems in an understandable way. I agree with this. U ideally we would not move something out of mainspace or disallow moving it into mainspace unless there are problems that are all of specifically identified, actionable, adversely detrimental* and not trivially fixable (anything that is trivially fixable should just be fixed). *"adversely detrimental" means things like failed verification or no evidence of notability, not merely lacking inline sources, cite templates or being "too short". Thryduulf (talk) 12:44, 4 June 2024 (UTC)[reply]
    I suppose we could try to re-define it as "does not qualify for deletion" (either CSD or AFD), but (a) it'd take a couple years for the usage to shift and (b) there is a strong demand from a minority of the community to have ways to get rid of "ugly" (i.e., short) articles. WhatamIdoing (talk) 16:42, 4 June 2024 (UTC)[reply]
    Following up on what @Joe Roe said about DRAFTIFY, I find this in that page:
    2a. The page is obviously unready for mainspace, for example:
    2a-i. is not a reasonable WP:STUB (e.g. has very little verifiable information, or is interchangeable with a short dictionary entry, but the definition is not good);
    2a-ii. or it would have very little chance of survival at AfD;
    2a-iii. or it meets any speedy deletion criterion.
    This was introduced by SmokeyJoe as a result of his proposal at Wikipedia talk:New pages patrol/Archive 5#Clarification and guidance for draftification. (The original proposal was that "unready for mainspace" mean "It does not meet WP:STUB.")
    This suggests that the definition of "not ready for the mainspace" is:
    • a very short stub, containing either a bad dictionary definition or very little information in general;
    • the article is not ready because the subject is non-notable; or
    • the article qualifies for speedy deletion.
    Based on this, I suspect that the definition could be reduced to "contains less than about 20 words of encyclopedic content", because a look at Wiktionary suggests that the mode for dictionary definition length is a mere four words, and 20 words would give you one long sentence or several shorter ones. WhatamIdoing (talk) 01:45, 9 June 2024 (UTC)[reply]
    A stub should be defined at WP:STUB, not at WP:Drafts.
    A stub is a very short article that is accepted in mainspace, despite not meeting other inclusion guildelines. They seem to be inherently acceptable topics, like natural species, capable of expansion. SmokeyJoe (talk) 02:05, 9 June 2024 (UTC)[reply]
    Per WP:STUB, a stub is any short article. Generally, it is taken to be less than about 250 words/10 sentences. There are no minimum requirements in WP:STUB. Cancer is a disease – a mere four words with no sources and no other content – would be a valid stub per WP:STUB.
    WP:IDEALSTUB (perhaps that's what you had in mind?) recommends adding "enough information for other editors to expand upon it" and to avoid a {{db-nocontext}} deletion. Cancer is a disease is realistically enough to fulfill that recommendation.
    IDEALSTUB also recommends that you "try to expand upon this basic definition", so we could add something like Sometimes people die from it or It is mostly treated with surgery or drugs.
    Finally, IDEALSTUB recommends citing a source (though our policies only require this for BLPs, not for articles about diseases), so we could add a link to https://www.cdc.gov/cancer/ or some similar website.
    I don't know what you mean by "despite not meeting other inclusion guildelines". The inclusion guidelines are at Wikipedia:Notability and its friends, and none of them require any length or particular content in the articles. Cancer is a disease, unsourced, with nothing else, meets the inclusion guidelines. WhatamIdoing (talk) 04:24, 9 June 2024 (UTC)[reply]
    You’re referring to the sourcing requirement speaking to sources that exist, not sources currently listed. Ok, yes you are right. SmokeyJoe (talk) 09:56, 9 June 2024 (UTC)[reply]
    @SmokeyJoe, I wonder whether this list of "three" items could be shortened to two:
    • The subject is non-notable (in which case, you should usually send it to AFD instead of Draft:)
    • The article qualifies for speedy deletion (on any grounds, but particularly for {{db-nocontext}}).
    The example of "has very little verifiable information, or is interchangeable with a short dictionary entry, but the definition is not good)" is redundant with {{db-nocontext}}. But perhaps there is a different example of "not a reasonable WP:STUB" that should be retained? WhatamIdoing (talk) 15:30, 9 June 2024 (UTC)[reply]
    Three is a pleasing number.
    Lists of two encourage binary thinking. SmokeyJoe (talk) 00:17, 10 June 2024 (UTC)[reply]
    Sure, a great many things could be.
    I wonder whether it’s actually not a good thing to attempt to tidy up definitions of edge cases. Edge cases are messy, subjective, and cause emotional disputes. Mistakenly precise language can make this worse, setting up a conflict between rules oriented wikilawyers and new content creatives.
    Where are the actual problems that you are trying to solve? SmokeyJoe (talk) 00:08, 10 June 2024 (UTC)[reply]
    The problem I need to solve is: People use the same words to mean different things, which results in (preventable) confusion.
    The problem I want to solve is: People have significantly different ideas of what the minimum acceptable amount/type of content for an article is, which results in some preventable disputes (and some non-preventable disputes).
    For example, one editor looks at an article and says "Wow, ten sentences, nicely written, I understand what the subject is, and it's even kind of a cool subject. It's WP:NOTFINISHED, but readers will be happy if they run across it, especially if they only need basic information (which is usually the case)."
    Another editor looks at the same article and says "It's soooo embarrassing! WP:ITSUNREFERENCED so the whole thing might be made-up nonsense, and readers hate uncited articles. There's been WP:NOEFFORT to improve it. WP:WEDONTNEEDIT, and we do need to hide that WP:Garbage to protect our reputation. There's no chance of it getting deleted at AFD, but it's obviously not ready for the mainspace!"
    Some divergence is a desirable thing, but there's very little overlap between those two positions. If we're going to function well, we need to have most of us mostly agree on what the minimum requirements are for something being "ready for the mainspace".
    If "ready for the mainspace" is even a soft requirement, then we need to have a shared understanding of what that means, and it needs to be the same for both going into and getting back out of the Draft: space. WhatamIdoing (talk) 05:16, 10 June 2024 (UTC)[reply]

I agree with WAID that there is a real problem here. If you read the subpoints of WP:DRAFTIFY#During new page review, then it's clear that obviously unready for mainspace is intended to refer to a fairly narrow set of seriously problematic articles: something less than a stub, deletion almost certain, etc. But divorced from that context, "not ready for mainspace" admits a much wider range of understandings, as we've seen above. For example, the draftify script leaves the canned edit summary Not ready for mainspace, incubate in draftspace followed by a selection of prespecified reasons why the article is not ready, which include things like it needs more sources to establish notability and it has too many problems of language or grammar – a far cry from very little chance of survival at AfD. A similar message is given to the creator the explain what happened to the article. If you look at the logs, the vast majority of moves to draft use one of these canned reasons: people take their cues on what they should and shouldn't do from the UI in front of them, not the guideline. Taken out of the guideline and into scripts and other pages, the phrase "not ready for mainspace" itself has taken on a life of its own and is used to systematically circumvent the deletion policy on a daily basis. – Joe (talk) 08:12, 10 June 2024 (UTC)[reply]

Who are these draftifiers? Are they sufficiently qualified/experienced? My biggest concern about NPR approvals was insufficient expectation of experience at AfD, draftifiers are t performing AfD-like decisions, but unilaterally.
The wording of the script, was there any discussion or consensus behind it.
“Not ready for mainspace”. They are very simple word. I think it might be worth an essay, WP:Not ready for mainspace.
While trying not to embarrass individuals, is it possible to show me a list of bad draftifications? SmokeyJoe (talk) 12:37, 10 June 2024 (UTC)[reply]
I wouldn't know where to start. I've been reviewing draftifications through WP:PERM/NPP requests, CSD R2 nominations and from the logs for years now and I'd say I come across an egregious example just about every time I look. To be clear, by 'bad', I mean something that clearly exceeds the boundaries set by WP:DRAFTIFY and/or what I understand community expectations to be, not my own. I don't want to unfairly single anyone out, but you could check my contributions to the draft namespace for a representative sample. – Joe (talk) 13:44, 10 June 2024 (UTC)[reply]
Egregious?
Some brainstorming questions, not having looked at your contribution history yet:
Are reviewers systematically applying a higher standard to new articles than would be applied at AfD? I’ve seen that AfC reviewers do this. Could this be explained by an increased expectation of article standard, and AfD voting lagging this change? I know that some people complain about how hard it is to get article deleted at AfD.
Are bad draftifications being done by editors who are not NPRs? And are they doing bad things randomly?
Is there any sense that draftifications are being done to endorse a reviewers POV bias on what content should be in Wikipedia?
Is the problem with this page’s asserted boundaries, or with poor training of NPReviewers? Or with bias from the draftification script(s) due to them proving an easily option for difficult cases? I don’t think that anything in the fairly heavy NPR and AfC training pages instructions to read WP:Drafts. SmokeyJoe (talk) 13:59, 10 June 2024 (UTC)[reply]
Egregious meaning systematic enough that I feel I have to discuss it with the user and, if they don't stop, pull their NPR right. I think the rest of your questions are good ones and, although I give my anecdotal conclusion on them, I don't have any data to hand (and unfortunately I don't think anyone does, which is why this issue has been festering for years now). I do think the lack of clarity in the phrase "not ready for mainspace"—taken out of context, as discussed above—has contributed to the problem and that's why I think WAID's original question (what is ready for mainspace?) is a good one.
To suggest a concrete next step, there is a list of specific, consensus-backed things that make a page "not ready for mainspace" at WP:DRAFTYES. We could brainstorm what could be added to those, and/or consider making a separate list of things that don't disqualify a page from mainspace. – Joe (talk) 14:13, 10 June 2024 (UTC)[reply]
My impression:
  • Are reviewers systematically applying a higher standard to new articles than would be applied at AfD? – Yes. And it's not just one "rogue" editor; it's anyone who doesn't want to be seen "endorsing" or "accepting" an WP:UGLY article. You have to be willing to expend a lot of social capital to follow the written rules. This is one reason I recently suggested a "three strikes and you're out" approach to AFC: On the third time AFC rejects a submission, a bot should do a procedural nomination at AFD. There is no more reliable method of figuring out whether it will be kept at AFD than to send it to AFD.
  • Could this be explained by an increased expectation of article standard, and AfD voting lagging this change? – Yes, but I don't think that "increased" is the right word. AFD still operates on the written rules (e.g., sources must WP:NEXIST in the real world, but don't have to be cited in the article). NPP and AFC functionally reject this rule and want notability "demonstrated".
  • Are bad draftifications being done by editors who are not NPRs? And are they doing bad things randomly? – Yes, overly aggressive draftifications sometimes are done by anyone who believes they are defending Wikipedia against ugly articles, but it's not really random. It is an effort to "raise Wikipedia's quality" by forcing other editors to choose between improving the article or having it hidden from readers.
  • Is there any sense that draftifications are being done to endorse a reviewers POV bias on what content should be in Wikipedia? – I have not seen evidence of, e.g., editors draftifying articles related to geopolitical disputes. There have been times in which we see editors draftifying articles about, e.g., Bollywood actors or African politicians. This could be due to cultural differences (the normal, everyday ways of describing powerful people in some cultures looks like "pure promotional garbage!" in others) and is probably often due to WP:NEVERHEARDOFIT (with that bias applying both the subject and to the newspapers/standard sources in that country).
  • Is the problem with this page’s asserted boundaries, or with poor training of NPReviewers? Or with bias from the draftification script(s) due to them proving an easily option for difficult cases? – I don't think that training is the problem, because part of Wikipedia's notion of "training" is to watch what others are doing and follow their lead. The problem that I want to deal with is the problem of nobody knowing/agreeing on what those words mean. If we agree that ugly articles should be accepted, then the script should reinforce that. If we agree that ugly articles should be hidden, then the script should reinforce that (and WP:UGLY should be updated to say that ugly articles can be hidden in draftspace).
Joe, I like your idea of having "a separate list of things that don't disqualify a page from mainspace". WhatamIdoing (talk) 17:44, 10 June 2024 (UTC)[reply]
Me too. SmokeyJoe (talk) 11:44, 11 June 2024 (UTC)[reply]
  • User:WhatamIdoing, User:Joe Roe, how about “isn’t acceptable in mainspace”? Eg1. Eg2. SmokeyJoe (talk) 13:23, 12 June 2024 (UTC)[reply]
    If two people argue about whether something is ready, it does seem to be a horribly subjective argument over an undefined and unimportant threshold.
    If two people argue about whether something is acceptable, one can say “it is acceptable because I accept it” and the other can say “it is not acceptable because I am not accepting it”. It goes to AfD where the decision will be made, deleted or pseudodeleted, or kept in mainspace, proving one of the two to be right. SmokeyJoe (talk) 13:34, 12 June 2024 (UTC)[reply]
    If two uninvolved editors disagree in good faith about whether something is or isn't ready for mainspace, I think it should be declared ready and moved to mainspace but explicitly without prejudice to AfD (obviously nothing is immune from AfD, but it should be made explicit so the psychological bar to nomination is lower). Thryduulf (talk) 13:46, 12 June 2024 (UTC)[reply]
    If two uninvolved editors disagree in good faith about whether something is or isn't acceptable for mainspace, I think it should be declared acceptable and moved to mainspace but explicitly without prejudice to AfD (obviously nothing is immune from AfD, but it should be made explicit so the psychological bar to nomination is lower). SmokeyJoe (talk) 13:52, 12 June 2024 (UTC)[reply]
    I think any new wording is worth a try but I'm not sure that it is sufficiently different from "ready for mainspace" to make a difference. We don't generally encounter problems when editors disagree about drafts, because the obvious course of action then is to discuss it at AfD. The problem is that the vast majority of articles moved to draftspace are only seen by two people: the creator, and the reviewer who draftifies it. Reviewers shouldn't, but unfortunately often do (not least through the wording of the automated script), imply that their 'decision' on an article is uncontestable. Even if they don't, creators, especially inexperienced ones, are often ignorant of the fact that they don't have to go along with what the reviewer says. So unless a third party happens to come across the draft, we don't get disagreement, just a creator trying to meet whatever arbitrary standard a particular reviewer has decided is required for mainspace, or just concluding that their contribution has been rejected and giving up. This is incidentally the precise opposite of what WP:DRAFTIFY and most frequent draftifiers say they want to achieve: to "allow time and space for the draft's improvement". – Joe (talk) 14:01, 12 June 2024 (UTC)[reply]
    I think that “acceptable” is better defined, via tautology with hindsight, than “not ready”. On reflection, I think “not ready” is suggestive that it is ok to Draftify a topic that is undoubtedly suitable, cf meta:Conflicting Wikipedia philosophies and extreme Immediatism.
    I think that draftification should include a mandatory link to WP:DRAFTOBJECT, both in the edit summary / move log entry, and in the message posted to the author. I agree with you concern about content creators not knowing all of the rules. SmokeyJoe (talk) 14:41, 12 June 2024 (UTC)[reply]
    I don't think that wording helps much. For one thing, it implies that there is a consensus that some articles are "unacceptable", but gives nobody any idea what is "acceptable" and what is "unacceptable". WhatamIdoing (talk) 14:40, 12 June 2024 (UTC)[reply]
    Acceptable means it survives AfD. Unacceptable means it doesn’t survive AfD. SmokeyJoe (talk) 14:42, 12 June 2024 (UTC)[reply]
    So in the deletion policy, you wrote "If an article isn't acceptable in mainspace, it can be moved to the draft namespace" but what you mean is "If a subject isn't notable, it can be moved to the draft namespace"? WhatamIdoing (talk) 14:50, 12 June 2024 (UTC)[reply]
    I’ve been trying to remember what I meant seven years ago with “ready for mainspace”. One thing that comes up was that reviewers were expecting citations in a BLP to be “inline”. I think I was attempting to not engage with dubious reasons reviewers were using. This was then quite a new backwater page. I am disturbed to discover my verbiage to have been copied into deletion policy and to have become common phraseology at AfD.
    WP:Drafts is not supposed to rewrite WP:N. Pages that pass WP:N are sometimes deleted. Pages that fail WP:N are sometimes kept.
    When a reviewer moves a page to draftspace, the reviewer should be justifying their action, not quoting generic statements. SmokeyJoe (talk) 21:33, 12 June 2024 (UTC)[reply]
    I think the wording should be more direct regarding expectations. Taking some text from Wikipedia:Deletion policy § Incubation, it could be something like "If a recently created article shows potential but needs additional development to establish that the subject meets Wikipedia's standards for having an article, it can be moved to the draft namespace." isaacl (talk) 15:59, 12 June 2024 (UTC)[reply]
    Is the rule you have in mind that the subject must not only be notable (e.g., NEXIST) but also demonstrate notability (e.g., cite multiple sources)? WhatamIdoing (talk) 16:26, 12 June 2024 (UTC)[reply]
    Whatever is necessary to convince a consensus of editors that the subject meets English Wikipedia's standards for having an article. This doesn't necessarily require citing multiple sources appropriate for demonstrating that the standards have been met, though that would be an easier route. isaacl (talk) 18:14, 12 June 2024 (UTC)[reply]
    Does the English Wikipedia have any standards other than WP:N for having an article? WhatamIdoing (talk) 19:08, 12 June 2024 (UTC)[reply]
    Having an article, no. Having this article, yes - e.g. WP:V, WP:COPYVIO, WP:NOTENGLISH, WP:BLP, WP:G10, etc. Thryduulf (talk) 19:36, 12 June 2024 (UTC)[reply]
    WP:V is not in the business of deciding whether we should have an article, in any mainspace. It's about which discrete bits of material require inline citations. Uncited material (WP:ITSUNREFERENCED) is not grounds for deletion under WP:V.
    If the article violates BLP, then it can't be moved to the Draft: space, either, because BLP applies to all namespaces. Ditto for COPYVIO and G10, which are reasons for immediate deletion and apply to all namespaces.
    NOTENGLISH has a two-week timer for deletion. It also says "Please keep in mind that drafts are out of scope for this page." WhatamIdoing (talk) 19:55, 12 June 2024 (UTC)[reply]
    You are missing the distinction between whether there should be an article about a topic, and whether any given individual content written about that topic is appropriate. For example, Australia is a notable topic about which we should have an article, but an article reading "Australia is land of criminals and man-eating spiders that is permanently on fire. Citation: My ex-girlfriend" should not be in mainspace. Thryduulf (talk) 20:11, 12 June 2024 (UTC)[reply]
    I'm pretty sure that the hypothetical Australia example would qualify for Wikipedia:Criteria for speedy deletion#G3. Pure vandalism and blatant hoaxes. WhatamIdoing (talk) 00:44, 13 June 2024 (UTC)[reply]
    Possibly (it's definitely not a hoax, vandalism is debatable. Unarguably it would fail WP:V) however these are all matters that have absolutely nothing to do with notability and are relevant to whether a page should or should not be in the mainspace. Thryduulf (talk) 01:08, 13 June 2024 (UTC)[reply]
    Prcicely right. There are a lot of topics that pass GNG or ann SNG, and thus deserve to have AN article. But, that does not mean any specific attempt at creating that article is acceptable. That attempt may have serious issues with other policies and guidelines, and need a complete rewrite. Draftspace is a temporary holding pen where that rewrite can take place. Blueboar (talk) 20:05, 12 June 2024 (UTC)[reply]
    Yes, as you are aware, there are other considerations than those explicitly listed at Wikipedia:Notability. That page does link in its introduction to one of the other key guidance pages to consider, Wikipedia:What Wikipedia is not. I didn't get into it as I find it hard to discuss the entirety of Wikipedia guidance related to having an article at once, and so I linked to the most commonly referenced guidance page in this area. (It wasn't a final proposal for a different wording, just a starting point.) I appreciate you like to use Socratic questioning, but it feels like you're trying to elicit a response that you can counter with your knowledge of current guidance, rather than bringing up additional guidance to consider.. isaacl (talk) 22:58, 12 June 2024 (UTC)[reply]
  • Perhaps some of the confusion here stems from the fact that deletion is based purely on notability, while draftification can be based on other criteria. Yet, “not ready for Mainspace” gets invoked in edit summaries as an “explanation” for both actions. Blueboar (talk) 00:39, 13 June 2024 (UTC)[reply]
    Yes, plus there seems to be no agreement about what the "other criteria" are. WhatamIdoing (talk) 00:46, 13 June 2024 (UTC)[reply]
    User:WhatamIdoing, I’ve noticed that “unsourced” is a reason. SmokeyJoe (talk) 11:18, 15 June 2024 (UTC)[reply]
    The "unsourced" claims are probably in WP:PGCONFLICT with WP:NEXIST.
    I wonder whether the typical claim is actually "unsourced" (e.g., if it were a BLP, it'd qualify for WP:BLPPROD) or if the claim is closer to "does not contain a sufficient volume of sources that, in my opinion, clearly demonstrate notability". WhatamIdoing (talk) 14:04, 15 June 2024 (UTC)[reply]
    My opinion is that in new page review, if the page is unsourced, the reviewer should make some attempt to find sources, and if they fail to find sources, they should PROD the article (or BLPPROD) noting that they cannot find evidence of sources, and they should not Draftify, becuase unsourced content is dubious content that should be considered junk.
    At AfC, submitted drafts are routinely declined as unsourced. SmokeyJoe (talk) 00:18, 16 June 2024 (UTC)[reply]
    Do you really believe that "unsourced content is dubious content that should be considered junk"? If someone starts an article on French Renaissance gardens, and it says "French Renaissance gardens were the style of gardens in France during the Renaissance", do you actually think that's worth a {{dubious}} tag? Is it WP:JUNK?
    I can imagine it being irritating for those few people who want a Wikipedia:Four Award, but that article wouldn't violate a single policy. WhatamIdoing (talk) 16:57, 16 June 2024 (UTC)[reply]
    User:WhatamIdoing, I wrote with a few unstated assumptions. I’m assuming a new article, it is completely unsourced, no external links, a single author who is no longer active, and a new page patrollers has tried to find sources, at least by google search. The content is unverified and possibly unverifiable.
    French Renaissance gardens is the sort of article I’m imagining. Doubtless it exists, there were gardens in France during the renaissance, and it seems likely that they had a unique style. The information in the page may be true, but may just as likely be made up, embellished, oversimplified, etc. I consider this dangerous, through the process of citogenesis. Is the risk managed by draftififcation? SmokeyJoe (talk) 11:22, 18 June 2024 (UTC)[reply]
    If I found a new article or draft “French Renaissance gardens” containing unverifiable content, I would redirect it to Gardens of the French Renaissance. SmokeyJoe (talk) 11:40, 18 June 2024 (UTC)[reply]
    Template:Dubious would be not applicable. That template refers to “a specific statement or alleged fact that is sourced but that nevertheless seems dubious or unlikely. The unsourced article more likely contains BLUESKY plausible stuff.
    The WP:JUNK essay is about notability. I am talking about pages that are unverifiable. I don’t agree with that essay defining junk as stuff that fails Wikipedia-Notability. SmokeyJoe (talk) 11:28, 18 June 2024 (UTC)[reply]
    If it's actually unverifiable (which, as you can see from the books cited in Gardens of the French Renaissance, this is definitely not unverifiable), then the material would have to be removed. All material must be verifiable – that means that it must be possible for someone to check whether a reliable source says the same thing, with "possible" defined as including actions such as "getting help from a reference librarian at your own library" or "finding sources through Wikipedia:The Wikipedia Library" – though a sentence such as the one I gave does not require an inline citation according to WP:V. For WP:V purposes, it does not require a source even if it is the only sentence in the entire article.
    It is not my experience that uncited content is "just as likely be made up, embellished, oversimplified". About half of all sentences in the English Wikipedia are uncited; in my experience, it is not true that half of them (representing a quarter of our content) is made up, embellished, oversimplified, etc. I generally find that only a small proportion of our uncited content is wrong. My impression is that the proportion of wrong-and-uncited content is not as different from the proportion of wrong-and-cited content as one might wish.
    I have given you an example of a definitely verifiable (though presently uncited) sentence about a definitely notable subject. Do we agree that "unsourced content" is not necessarily "dubious content that should be considered junk"? WhatamIdoing (talk) 15:38, 18 June 2024 (UTC)[reply]
    We agree, "unsourced content" is not necessarily "dubious content that should be considered junk". SmokeyJoe (talk) 09:54, 19 June 2024 (UTC)[reply]
    Another reason if seen for non notability reasons to Draftify is “COI”. Including “suspected COI”. SmokeyJoe (talk) 00:37, 16 June 2024 (UTC)[reply]
    COI has no effect on non-notability. If it's non-notable, it should go to AFD, regardless of whether COI is suspected. WhatamIdoing (talk) 15:39, 18 June 2024 (UTC)[reply]

Contemplation of a Proposal: Mandate edit summary linking to WP:DRAFTOBJECT in every unilateral draftification

Proposal: Mandate edit summary linking to WP:DRAFTOBJECT in every unilateral draftification.

The more I think on this years old idea the more I think it should be done. In practical terms, it is a simple thing to write into draftification scripts. For manual draftifications, these draftifiers are probably not experience and the rule is even more important. For consensus based draftifications, via AfD or informal discussion, they should link the discussion.

I suspect the rule should also strongly encourage including WP:DRAFTOBJECT in the usertalk explanation (automatic by the scripts), but not mandated due to occasional complications such as the first page author being an IP or banned user. SmokeyJoe (talk) 00:33, 16 June 2024 (UTC)[reply]

I think we could realistically make this happen in the scripts, but not in manual edit summaries. WhatamIdoing (talk) 16:52, 16 June 2024 (UTC)[reply]
I agree, but but would it be a good idea, to make it happen in the scripts, and to encourage it in manual edit summaries? It seems to me to be an easy fix to some of the problems you’ve noted (eg newcomers being intimidated). Would it have downsides? It would not fix everything. Would you support this proposal? SmokeyJoe (talk) 11:37, 18 June 2024 (UTC)[reply]

This is the wrong place for proposals, and I would oppose it anyway, as mandating a link to an essay is a bad idea, as it gives the impression that DRAFTOBJECT is a policy without going through the policy validation process. E.g. the "you can't draftify again" part is being misused by some people to object to redraftification a priori, pretending that it isn't allowed. Often the same people who then object to an AfD because AfD is not cleanup, leaving not much room for other options to deal with very poor articles which, yes, aren't ready for the mainspace. Yes, the drafter could in theory do a complete cleanup of the article, providing coherent prose, sources, ... for a subject they know nothing about, where the sources are in a language they don't speak. Realistically speaking though, the best solution is to move the page to draft again and again until the creator or someone else with the time and knowledge to deal with it turns it into an acceptable article. Fram (talk) 10:03, 19 June 2024 (UTC)[reply]

Hi Fram.
Wrong place? Yes, I know, actually I meant it as contemplation for formally proposing this. I have learned to not propose something without at least one person agreeing with me. If supported, I would start a new page tagged {{Proposal}}. SmokeyJoe (talk) 11:26, 19 June 2024 (UTC)[reply]
DRAFTOBJECT *is*, already, pseudopolicy, and the proposal would be defacto ratification.
Redraftification, excepting for WP:COI, is not allowed. It is move warring. Two people disagreeing should not move war, but should discuss, and the perfect forum is AfD.
AfD is not cleanup? No, it is not. Neither is draftification. Draftification is not for cleanup.
What do you mean by a very poor article that is not “ready for mainspace”, to ask the central question of this thread?
If there is any disagreement, it should go to AfD. I firmly disagree with you if you if you think it is ok for one editor to have the authority over another to send their work to draftspace until it meets the first editors undefined standard. —SmokeyJoe (talk) 11:37, 19 June 2024 (UTC)[reply]
"Pseudopolicy" doesn't exist. Draftofject isn't only about "one editor to have the authority over another to send their work to draftspace until it meets the first editors undefined standard.", it also means that a second editor may not send a page back to draftspace. And the essay gives the right to "one editor to have the authority over other editors to send their own work to main space", no matter how poor. I see no problem with this nor a reason to burden AfD with it. I moved Draft:2025 Rugby Europe Championship to draft twice because it had no sources about the topic but about different topics, but if it could be sourced to good sources it would be a notable subject. An article with such poor sourcing is "not ready for the mainspace". Jesus Calls was draftified, recreated, speedy deleted, and then recreated as Jesus calls. I draftified that one, is that a redractification? And if so, is it for some reason problematic? I redraftified Air 1 (airline) (another editor did the original draftification), why not? Same for Mangkunegara III.
As for "not ready for mainspace", things like Draft:Sahajanya (unsourced microstub), Draft:Azad Samaj Party (Kanshi Ram), Uttar Pradesh and Draft:Azad Samaj Party (Kanshi Ram), Madhya Pradesh (barely above speedy deletion), Draft:2025 in Belgium (explanation for the "not ready" statement: "So far, this contains 1 sure event only, plus speculative claims about who will be PM, links to unrelated articles, and the holidays for 2024."), Draft:San Sanana (not ready as in "No evidence of notability at the moment, chart performance section is not for this song" but being an Indian song not easy for me or many others to check for actual notability), ... Fram (talk) 13:09, 19 June 2024 (UTC)[reply]
Taking Draft:2025 in Belgium as the example: Why did you decide that we shouldn't have that page in the mainspace?
There is no question about the notability. It would easily pass AFD, and AFC's mandate is to accept pages that will pass AFD. If Thief-River-Faller submits it to AFC, they ought to accept it immediately (assuming they follow their own rules, about which there has been some doubt).
It would also be more likely to get corrected if it were in the mainspace. So why hide it in Draft: space? WhatamIdoing (talk) 17:05, 19 June 2024 (UTC)[reply]
Whoever would accept that page as is would need their reviewer rights removed. "AFC's mandate is to accept pages that will pass AFD." Among many other things. Accepting pages with almost exclusively blatantly incorrect information just because the topic is notable is making Wikipedia worse, not better. The page at the moment has one correct entry, "7 – 17 August: Belgium at the 2025 World Games"; everything else is either speculation or just factually wrong for the topic. I would urge you to reread Wikipedia:WikiProject Articles for creation/Reviewing instructions, which contains a lot more than "notable = accept". Fram (talk) 21:28, 19 June 2024 (UTC)[reply]
Sure, I've read that page. I even helped write it. In particular, see Wikipedia:WikiProject Articles for creation/Reviewing instructions#Core purpose, which says (second sentence): "Articles that will probably survive a listing at Wikipedia:Articles for deletion should be accepted."
See also the second sentence of the next section: "Article submissions that are likely to survive an AfD nomination should be accepted and moved to mainspace" (bold in the original). WhatamIdoing (talk) 21:57, 19 June 2024 (UTC)[reply]
All the while ignoring the detailed checklist and workflow, which give further, more detailed instructions than the (by definition) simplified summary. I see no good arguments why this page should be in the mainspace as it is now, and putting it in the mainspace while knowing about the issues (which is what you claim a reviewer should do now, if asked by the creator) is basically vandalism, deliberately and knowingly putting incorrect information in the mainspace. Fram (talk) 07:43, 20 June 2024 (UTC)[reply]
I believe it would be best to blank the obviously wrong information. WhatamIdoing (talk) 20:24, 20 June 2024 (UTC)[reply]
Taking Draft:San Sanana as an example, why did you choose to hide it in Draft: space instead of blanking the apparently incorrect information (KjjjKjjj, that song isn't "Falling Behind", like it says in Draft:San Sanana#Charts, right?) and tagging it with {{notability}}? WhatamIdoing (talk) 18:14, 19 June 2024 (UTC)[reply]
So, if it is notable, I should keep it in mainspace. If it is not notable, I should nominate it for deletion. And if notability is unclear I should tag it with "notability", even if there are (like here) clearly other problems as well. Is there any scenario where you believe draftifications is an acceptable course? Fram (talk) 21:30, 19 June 2024 (UTC)[reply]
Yes, there are a couple of scenarios for which I would accept and even recommend draftification. The first and most obvious is when the editor(s) working on it want to take that route. The second obvious case IMO is when the subject is not currently notable but is reasonably likely to become notable within the next couple of months. For example, we know that certain events, such as the US State of the Union speech or the United States census, will continue to happen on a predictable schedule, but future events frequently fail Wikipedia:Notability (events) until shortly before they happen. If an article is created a bit too early, when we don't have enough sources/attention from the world at large, but when we also believe such sources will be forthcoming in short order (e.g., a press conference has been scheduled for an announcement), then I think draftification is better than either deletion or keeping it. WhatamIdoing (talk) 22:15, 19 June 2024 (UTC)[reply]
I don't think that extremely minimal approach to draftification is shared by many, and would leave many very poor new articles in the mainspace. Something like Draft:Science Centre, Patan has now been draftified twice, which is a good thing. Would the subject survive an AfD? No idea, and as discussed elsewhere, it isn't the job of reviewers to do a WP:BEFORE check. Fram (talk) 07:43, 20 June 2024 (UTC)[reply]
I think your extremely maximal approach to draftification, openly ignoring the only written guidance on the subject because it's "just an essay", is shared by even fewer. – Joe (talk) 11:16, 20 June 2024 (UTC)[reply]
See below, we actually have policy about this, which is what I follow. Fram (talk) 11:43, 20 June 2024 (UTC)[reply]
the proposal would be defacto ratification if in effect the idea is to make DRAFTOBJECT policy then that should be the proposal, rather than discussing edit summaries. -- LCU ActivelyDisinterested «@» °∆t° 19:13, 19 June 2024 (UTC)[reply]
Something doesn't have to be a policy (or even a guideline) to be linked in a tool-generated edit summary. WhatamIdoing (talk) 21:51, 19 June 2024 (UTC)[reply]
...which should be obvious given that the current edit summary used by scripts is a paraphrase of the very same essay (Not ready for mainspace, incubate in draftspace). Apparently it's okay to use a non-policy to justify moving tens or hundreds of thousands of articles out of mainspace, but not to remind the creators that they're entitled to move it back? – Joe (talk) 11:21, 20 June 2024 (UTC)[reply]
My point had nothing to do with adding anything to the summary of automated edits. It was that if editors wanted to make suggestions for new policy they should do so. The comment I was replying to was suggesting that policy should be made via discussion on another topic. -- LCU ActivelyDisinterested «@» °∆t° 14:35, 20 June 2024 (UTC)[reply]
I don't use that edit summary either, and if you both want a policy about draftification; WP:ATD-I: Recently created articles that have potential, but do not yet meet Wikipedia's quality standards, may be moved to the draft namespace ("draftified") for improvement. Fram (talk) 11:43, 20 June 2024 (UTC)[reply]
Where are those quality standards defined? Thryduulf (talk) 11:45, 20 June 2024 (UTC)[reply]
Nowhere probably, just like many things around here. Having reliable sources and intelligible prose, being factually correct, and actually being about the topic as suggested by the title, is what I (and in my experience most others who do new page checking) apply. I don't think any of these can be considered really controversial. Fram (talk) 12:01, 20 June 2024 (UTC)[reply]
This discussion demonstrates that every one of those is controversial:
  • The only requirement for sources is that they exist - if they don't exist the article should be prodded or sent to AfD, if they do exist add them to the article, if you don't know then look.
  • If there is no intelligible prose then the article should be deleted (speedy deletion criteria G1, G2, A1, A2 and/or A3 almost certainly apply)
  • If the article is factually incorrect then it should be corrected or nominated at prod or AfD (unless it's a blatant hoax, in which case it should be speedily deleted under criterion G3).
  • If it isn't about the topic as suggested by the title, then either rename the article or nominate it for prod/AfD. Thryduulf (talk) 12:14, 20 June 2024 (UTC)[reply]
Nobody would disagree that those are desirable qualities in an article, but whether they constitute a required standard for mainspace is indeed controversial. As just one data point, the existence of {{unreliable sources}}, {{incomprehensible}}, {{disputed}}, and {{off topic}} would suggest that all of the problems you list have been tolerated in mainspace in the past. The lack of a definition of "Wikipedia's quality standards"—AKA being "ready for mainspace"—is the problem that motivated this discussion and, as the discussion shows, it leaves room for a wide range of understandings. – Joe (talk) 12:17, 20 June 2024 (UTC)[reply]
Feel free to ping me when a policy proposal is put up for a vote. Until then, I don't think anything useful will come from continuing this discussion with you three. The requirements put up here, basically requesting the reviewers needing to do all the work the creator should have done and can do much easier, are mainly based on misreadings of policy ("The only requirement for sources is that they exist", well, no: "Any material lacking an inline citation to a reliable source that directly supports[b] the material may be removed and should not be restored without an inline citation to a reliable source. " and "The burden to demonstrate verifiability lies with the editor who adds or restores material" (bold in original). A completely unsourced article may thus be blanked (which would make it eligible for speedy deletion, not really preferable), or by draftifying it "removed" from the mainspace; and the burden to add sources lies with whoever wants it back in the mainspace, the one who "restores material". Putting that burden on new page reviewers is not acceptable (of course they may do so if they wish, but it should never be a requirement). Similarly, "If the article is factually incorrect then it should be corrected or nominated at prod or AfD (unless it's a blatant hoax, in which case it should be speedily deleted under criterion G3)" yes, it should be corrected by the creator or whoever wants the material in the mainspace. Otherwise it will be deleted. It shouldn't be brought to Prod or AfD as these are not for cleanup. "If it isn't about the topic as suggested by the title, then either rename the article or nominate it for prod/AfD." No, if you actually do new page patrol then you will encounter many cases where someone has created an article for topic X by copying their own previous creation about topic Y, and forgot to change all or most of the text. Topic X is notable, the creator is probably knowledgeable and interested in correcting this, but until then we have a completely wrong article in the mainspace (not incomplete, poorly sourced, just wrong). Speedy deleting this as a hoax is very WP:BITEy and draftifying the much more friendly, gentle solution, the middle ground between keeping the mainspace factual and the editor encouraged to continue working on it.
The approach taken by you three seems to be "we need a policy or you can not do this" (even though we have a policy encouraging draftification in such cases), and "you are not allowed to do things which go against this essay here". Oh, and "all the work should be done by the reviewers, not the creators" or (judging from their contributions) people who never patrol new pages, edit draft space, or nominate pages for deletion (like Whatamidoing and Thryduulf) I'll continue to ignore this until you get a policy that actually supports your positions, or until you get a consensus at ANI or so that I should change my approach. Fram (talk) 12:49, 20 June 2024 (UTC)[reply]
Most of that is not opposing DRAFTOBJECT, which is about empowering the newcomer to get their week at AfD if they want it. Opposing part of DRAFTOBJECT are a few example of something draftified twice, where WP:ATD-I rolled with DRAFTOBJECT would mean that Fram is supposed to send the bad article to AfD with a nomination to Draftify. Maybe “do not Draftify twice” is a soft rule, maybe newcomers mainspacing a draftified article do not actually mean that they want to debate it at AfD. SmokeyJoe (talk) 13:15, 20 June 2024 (UTC)[reply]
I find your (Fram's) response interesting, because underneath it, it feels like there is a question about whether Wikipedia is a collegial, collaborative project. Several of the examples you give sound like a Wikipedia-as-a-game model: Any sentence could be required to have an inline citation, so if "you" don't have "enough" (or any) inline citations, then "my" move is to capture your article. If you make the right moves, you can get your article promoted back to the mainspace, but I see my role as fundamentally adversarial: I will prevent you from sharing information until you do so in a way that I believe is appropriate, and I will not help you fix any problems you encounter. WhatamIdoing (talk) 21:06, 20 June 2024 (UTC)[reply]
And here I thought the singular purpose of Wikipedia is to be a factual, verifiable encyclopedia that anyone can edit. But all this time it has actually been a social platform where the real goal is to get more precious users by zealously protecting their right to publish whatever they want to the first page of Google. Editor retention above all else. JoelleJay (talk) 09:11, 21 June 2024 (UTC)[reply]
How the fuck are we going to maintain a "factual, verifiable encyclopedia" if we don't retain editors? – Joe (talk) 09:27, 21 June 2024 (UTC)[reply]
Editor retention can still be achieved without militantly assuming every article creation is inherently encyclopedic as a standalone regardless of sourcing and content. JoelleJay (talk) 10:15, 21 June 2024 (UTC)[reply]
Assuming bad faith, hiding their work in place that nobody will ever find it, and refusing to put any effort into even checking whether what they wrote is correct, let alone making trivial improvements to things new editors cannot reasonably be expected to master is not the way to retain editors. Thryduulf (talk) 10:31, 21 June 2024 (UTC)[reply]
Perhaps not, but frankly speaking, if new editors are not either of the mindset to proactively learn those "things new editors cannot reasonably be expected to master" beforehand or of the mindset to look for help afterwards on figuring out the issues with their creation(s), how to fix them, and then try again? Chances are, you won't retain them long-term with your suggested course of action either.
Instead, you'll likely as not lose them shortly after that newness has worn off just enough that people will start expecting them to have picked up on the basics of "articles need to be factual, non-promotional, in readable English-language prose, with sources", the major policies and guidelines, and some slightly-beyond-basic skills like how to create a reference without scattering CS1 errors all over the page, edit a table or infobox without breaking it, and so on. At that point, people will stop fixing their issues for them and expect them to do it themselves—with skills and knowledge they cannot reasonably be expected to have mastered if other people have silently fixed all issues for them so far.
The solution is not "let them figure it out entirely by themselves" nor "fix it for them without even making them try". It is guidance on where they went wrong and how to do it right. And yes, depending on the severity of the issues and how long fixing it is likely to take (and how likely an editor is to even give it a try), sometimes that guidance is better done outside mainspace. AddWittyNameHere 12:39, 21 June 2024 (UTC)[reply]
But what happens is not "move to draftspace, teach them what they need to know, including where to get help, assist them to improve their article and welcome them as a productive editor" but "move to draftsapce where someone can delete in six months". Thryduulf (talk) 13:01, 21 June 2024 (UTC)[reply]
Yes, hence my won't retain them [...] either (emphasis added) and [t]he solution is not "let them figure it out entirely by themselves" nor "fix it for them without even making them try" (emphasis), i.e. if the aim is predominantly "retaining editors", then absolutely, the current method does indeed not work well for that purpose. I just do not believe the course of action suggested by you would work any better, for the reasons outlined above (and would come with an additional hidden cost: still no long-term retaining of productive editors, but an increase in workload as a result of these editors leaving a little later)
That said, I don't think the primary intended objective of draftification-as-concept is or has ever been "retaining new editors", it is "guarding mainspace from incorrect, dubiously notable and/or unverifiable, but potentially improvable, new articles while retaining the contents somewhere so that (at least in theory, as we all know that this only rarely happens in practice) someone could work on improving it without the hassle of having to get it undeleted first". It is a slightly less BITEy alternative to deletion, but also only slightly so.
That in practice it ends up being less of an alternative to and more of a delayed form of deletion is exactly where the guidance I mentioned comes in: such guidance is lacking, it should not be, and if it were not, it would work towards both objectives (editor retention/mainspace not getting flooded by New Editor's Clueless First Article) and make it a significantly less BITEy alternative to deletion that produces some actually-mainspaceable articles instead of an almost-as-BITEy-delayed-deletion that produces a heap of stale drafts to be cleared like clockwork. AddWittyNameHere 14:09, 21 June 2024 (UTC)[reply]
And where was it decided that mainspace needed to be 'guarded' from such things? Not to state the obvious, but this is a wiki; we don't need a special place where people can work on things. Our editing policy even explicitly states that poor articles, if they can be improved, are welcome. – Joe (talk) 14:19, 21 June 2024 (UTC)[reply]
And where was it decided that mainspace needed to be 'guarded' from such things? Among various places, in the WP:ATD-I section of the WP:Deletion policy, which states Recently created articles that have potential, but do not yet meet Wikipedia's quality standards, may be moved to the draft namespace ("draftified") for improvement, with the aim of eventually moving them back to the main namespace, optionally via the articles for creation (AfC) process.; the WP:DRAFTIFY of the WP:Drafts explanatory essay, which states The aim of moving an article to draft is to allow time and space for the draft's improvement until it is acceptable for mainspace; during the RfC which proposed the creation of a Draft namespace and which explicitly described one of its potential uses as a successor of the now-historical WP:Article Incubator; during the various discussions and decisions which led to the existence of said now-historical Article Incubator. AddWittyNameHere 20:54, 21 June 2024 (UTC)[reply]
I've heard (but not read myself) that if you want to retain new editors who add content, then one of the best things you can do is add an inline tag like {{fact}}, which they will often fix the next day.
So if you want stuff WP:Glossary#cited, hiding the whole page in Draft: space probably isn't the right way to go about it. WhatamIdoing (talk) 21:10, 21 June 2024 (UTC)[reply]
Yes, exactly this. Frankly I don't expect the editors who aren't bothered to do even the bare minimum in making their first article PAG-compliant (citing sources in any format) to have any interest in sticking around long-term. If they don't understand they need citations in 2024, despite all the hand-holding alerts and training modules available for new editors nowadays and the ubiquitousness of "citation needed" in English online discourse, then best case scenario is they're a child or geriatric person who doesn't know any better. More likely they're careless, incompetent, a vandal or amateur self-promoter, and/or don't speak English at all, and would be both highly unlikely to continue editing anyway and not the type of editor we'd want to retain regardless. A person who actually cares about contributing would put in some effort and not be discouraged by the mildest difficulty, and a person we'd want to keep around would be familiar enough with "citations" and "what is an encyclopedia" that we wouldn't need to explain very basic concepts that have been universal in secondary education for 30+ years. JoelleJay (talk) 23:45, 21 June 2024 (UTC)[reply]
@AddWittyNameHere, I'm struck by your comment about skills and knowledge they cannot reasonably be expected to have mastered if other people have silently fixed all issues for them so far. I have said for years that one of the reasons that I stuck around in the early days was precisely because an editor silently fixed wikitext errors for me. I mastered wikitext despite this (welcome) help. I probably would have quit if everything had been reverted or someone had yelled at me for making mistakes. WhatamIdoing (talk) 03:57, 22 June 2024 (UTC)[reply]
(@WhatamIdoing: Apologies up-front for the somewhat lengthy response, but this is about as far as I managed to condense it after four rounds of removing extra verbiage.)
Yes, I think that's a common thing for a decent portion of the editors we actually retain: autodidacts and adjacent, to whom seeing someone else do it (or reading the documentation) is enough to pick up on what to do. But that's not the way everyone learns best, or finds comfortable, or has the time and energy to spare for to engage in what is a voluntary internet hobby. "cannot reasonably be expected" was meant to be read as "not a reasonable ask of all or most new editors", not as "impossible for any and every new editor".
"Revert everything/yell at" are certainly not better, but I am not advocating for that, and I am a little puzzled that every response I have gotten in this conversation so far seems to assume I must be in agreement with the status quo simply because I see issues with a specific alternative presented. Rather, I am saying "hey, instead of assuming these are the only options, let's look at what other options might exist. How about, say, Z: neither silent fixing nor silent draftifying, but actual personalized guidance."
(The hows of that are a separate matter. On account of this message already being lengthy, all I'll say about it here is that imo, it's probably best done through a different process than (but if possible, working closely with) NPP/AfC, both because of pre-existing chronic AfC/NPP backlogs and because of different personal inclinations and skill sets between "check large volume of articles for compliance with core content policies" and "guide individual newbies through creating a single core content policy compliant article, tailoring approach to said newbie".) AddWittyNameHere 09:24, 22 June 2024 (UTC)[reply]
I also think that it's supposed to be a verifiable, factual encyclopedia. However, that's not a full and complete description. Consider:
  • A verifiable, factual encyclopedia produced by people working together collaboratively (e.g., if you created an article by copying/pasting a previous one, and you forget to remove something from the old article, I could blank that off-topic content for you), versus
  • A verifiable, factual encyclopedia produced by people working adversarially (e.g., instead of fixing an obvious problem, I'll hide the whole thing in the Draft: namespace).
WhatamIdoing (talk) 21:06, 21 June 2024 (UTC)[reply]
What is this "pseudopolicy" and why is it exempt from actual policies, like Policy and guideline pages are seldom established without precedent[3] and require strong community support. Policies and guidelines may be established through new proposals, promotion of essays or guidelines, and reorganization of existing policies and guidelines through splitting and merging. [...] Proposals for new guidelines and policies require discussion and a high level of consensus from the entire community for promotion to guideline or policy status. Adding the {{policy}} template to a page without the required consensus does not mean the page is policy, even if the page summarizes or copies policy. and Wikipedia has a standard of participation and consensus for changes to policies and guidelines. and The burden to demonstrate verifiability lies with the editor who adds or restores material and Because a lack of content is better than misleading or false content, unsourced content may be challenged and removed.? JoelleJay (talk) 08:39, 21 June 2024 (UTC)[reply]
I’m not sure what the point in the green stuff is, but pseudo policy is something that is in practice as policy but without being documented. The most obvious pseudo policy is the guideline WP:N, which is not policy, but is enforced as policy through WP:DEL#REASON#8 (used to be #6). SmokeyJoe (talk) 13:56, 21 June 2024 (UTC)[reply]
The thing that bothers me about quoting "The burden to demonstrate verifiability lies with the editor who adds or restores material" in this context is that it seems to mean "Editors are supposed to magically know that I wanted an inline citation for that, even before I saw the page, so they should have provided one in advance of me actually WP:CHALLENGING the content, but since they didn't read my mind, the content should be hidden until they (a) find where I've hidden it and (b) fix it up well beyond the level of adding a source, but so that an AFC reviewer will feel comfortable publicly endorsing it".
That's not really what the policy says, but it appears to be what's meant in the specific context of draftification. WhatamIdoing (talk) 21:03, 21 June 2024 (UTC)[reply]
"Not ready for mainspace" is pure "I don't like it"-ism
if an article is:
  • in some form of English
  • has at least one citation
  • meets notability guidelines
  • is not an attack page
  • is not vandalism
  • is written in good faith
it *is* ready for mainspace. it does not need to be draftified.
It can be tagged to the skies. It can be ignored in NPP for months or years. It does not need to be put into a box labeled "go away you suck". New articles and new users are awkward teenagers that need a little patience and encouragement and many of them *will* grow into beautiful competent adults. Sending them away to reform school in the mountains is just avoiding dealing with our own discomfort with our own flaws and imperfections.
NPP should ideally be a "gates wide open come on in" group of greeters who are there to welcome new articles and new users to the party. "Hi here's a cocktail. It's crazy up in here. Here's the syllabus and another cocktail and a cookie and also a kitten. Don't mind them, that's a WikiProject, they're kindly fanatics."
Shitty articles are good actually. Shit is fertilizer. Shit is rich in nutrients and promotes growth. Scrubbing the world of shit reduces cholera transmission but also increases the prevalence of autoimmune disorders. There's got to be a balance.
Anyway, IMHO, "not ready for mainspace" is mean and vague and more harmful than helpful. Even the worst article that meets the standard above should be greeted with a compliment sandwich: "Thank you so much for contributing to Wikipedia! Your passion for this topic is so evident. I wanted to let you know that that according to our current guidelines, this article may be [list top 3 problems here]. Let me know if you need any help resolving these issues. We really appreciate you contributing to the sum of all human knowledge. There's so many topic domains that still need attention and we so appreciate your participation in growing the project."
Anyway, please enjoy the snacks and thanks for coming to the party. jengod (talk) 16:46, 21 June 2024 (UTC)[reply]
WP:FERTILIZER should be blue! – Joe (talk) 17:47, 21 June 2024 (UTC)[reply]
done. Let's groooooooowwwwww! jengod (talk) 18:29, 21 June 2024 (UTC)[reply]
Meh… I’m now considering writing a contrary essay, and calling it WP:Prune the weeds. Weeds need to be pruned in order for a healthy garden to grow. Blueboar (talk) 18:41, 21 June 2024 (UTC)[reply]
I would very much like all Wikipolicies to be presented as a series of (increasingly unhinged?) rambunctious garden metaphors, and would like to be pinged at the creation of each entry in the series please and thank you. :) jengod (talk) 18:57, 21 June 2024 (UTC)[reply]
Keukenof, said to be the most beautiful garden in the world, requires an awful lot of maintenance. The best Wikipedia articles, in terms of maintaining volunteer sustainability, are spontaneously maintained and updated by passing readers. SmokeyJoe (talk) 01:30, 22 June 2024 (UTC)[reply]
This is operating under the assumption that a primary purpose of Wikipedia is cultivating a social community that effusively courts all potential new users, even when it comes at the expense of encyclopedia quality and requires established editors to take time away from editing to mentor newbies. That's fine for the people who want to do that, but a huge proportion of editors are mainspace-only and so would not know about or care to participate in any kind of newcomer-welcoming behavior regardless of whether "building a community" was an actual WP goal, and would interact with newcomers the same way they always would with any other editor they encounter. Meanwhile I would guess a large percentage of those who do get involved in Wikipedia-space are only there for reasons directly related to improving the specific pages or topics they're working in rather than a desire to be part of a broader "Wikipedia movement" or to socialize or do outreach. These are the editors who have their individual motivations for expanding articlespace, enforcing content rules, molding the PAGs, etc. towards what they think the encyclopedia should be; why should they be forced into additional social roles, beyond what is needed for civil discourse between colleagues, in furtherance of the WMF's or other people's agendas for "Wikipedia the Institution", that are not actually backed up by empirical evidence showing they'd have the intended effect, and for which it isn't even clear how the intended result would improve the encyclopedia? JoelleJay (talk) 01:52, 22 June 2024 (UTC)[reply]
For User:WhatamIdoing especially, I was coincidentally listening to a radio program interviewing an academic horticulturist, who was asked for the definition of a weed: “A weed is a plant that you don’t like”. SmokeyJoe (talk) 07:08, 22 June 2024 (UTC)[reply]

Reliable source engine

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)[reply]

I just tried it and liked the results. Thanks! Schazjmd (talk) 20:23, 4 June 2024 (UTC)[reply]
See WP:WRS. --Talky Muser (talk) 20:37, 4 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
WP:RSSE is another. Levivich (talk) 02:29, 6 June 2024 (UTC)[reply]
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)[reply]
Awesome! I'm definitely bookmarking it for later use. ‍Relativity ⚡️ 18:57, 8 June 2024 (UTC)[reply]
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)[reply]

Proposed edits feature

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)[reply]

Something like Wikipedia:Pending changes? Anomie⚔ 12:59, 9 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
It is not to distrust the editor, it’s for edits where the editor is unsure Alexanderkowal (talk) 13:21, 9 June 2024 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
Yes Alexanderkowal (talk) 13:42, 9 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
(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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
Okay, thank you, yeah I could've worded it clearer Alexanderkowal (talk) 17:04, 9 June 2024 (UTC)[reply]
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)[reply]
Please ignore my first two comments, I later combined them Alexanderkowal (talk) 17:35, 9 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
To be clear, a proposed edit can be outright refused/reverted by one other editor Alexanderkowal (talk) 13:02, 10 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Could do with a source though lol Alexanderkowal (talk) 18:11, 10 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
Another use case would be an intuitive replacement for edit requests. Aaron Liu (talk) 11:54, 11 June 2024 (UTC)[reply]
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)[reply]

Whales

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)[reply]

Moot We already have sweet Jimbo Wales. Aaron Liu (talk) 11:35, 10 June 2024 (UTC)[reply]
And {{whale}}! Chaotic Enby (talk · contribs) 12:44, 10 June 2024 (UTC)[reply]
[cetacean needed] —Jéské Couriano v^_^v threads critiques 23:16, 10 June 2024 (UTC)[reply]
fixœd Aaron Liu (talk) 02:58, 11 June 2024 (UTC)[reply]
Third, how often do they explode. —Cryptic 15:39, 10 June 2024 (UTC)[reply]
We can talk about whales during lunch. --jpgordon𝄢𝄆𝄐𝄇 21:20, 10 June 2024 (UTC)[reply]
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)[reply]
I've created a task force homepage. Aaron Liu (talk) 22:20, 10 June 2024 (UTC)[reply]
I think you mean how often does he explode. The WordsmithTalk to me 00:37, 11 June 2024 (UTC)[reply]

Add a timeline to Wikipedia pages

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)[reply]

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)[reply]
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)[reply]
What I see in https://en.wikipedia.org/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)[reply]
Here you can find a good sample of view using TimelineJS : https://timeline.knightlab.com/ Htordj62 (talk) 10:00, 14 June 2024 (UTC)[reply]
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)[reply]
on wiki page https://en.wikipedia.org/wiki/Christophe_Colomb ChatGPT request : "would you extract the important dates from this Wikipedia page into a json file for timelinejs: https://en.wikipedia.org/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)[reply]
↓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)[reply]

Dark Mode as a Premium Feature

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

Lack of Filipino folk arts

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)[reply]

Try being bold and editing pages yourself to see what you can improve. – Teratix ₵ 14:36, 14 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
As good old dear Liza would say, then fix it dear Henry then fix it. Davidstewartharvey (talk) 09:33, 15 June 2024 (UTC)[reply]
Yeah, I'll make sure to make their Wikipedia pages as soon as I can. Cyb3rstarzzz (talk) 14:09, 15 June 2024 (UTC)[reply]
Please do remember I am a new user, it'll take some time. Cyb3rstarzzz (talk) 16:58, 15 June 2024 (UTC)[reply]
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)[reply]

Some kind of reminder at AN/I

This is not a joke proposal.

I'd like to propose some kind of reminder/checker that automatically runs at AN/I, in the style of [1]. Actually reading it back to the user is good, but a given user's computer probably doesn't have the sound turned on all the time, so a pop-up dialogue box, with a five-second delay before the user can click "continue" would probably work too. Something like this:

Here's what you just posted to AN/I:


Yes, post this comment.Wait, go back.


Thoughts? Cremastra (talk) 20:05, 16 June 2024 (UTC)[reply]

Having a delay for every single reply can really make things really annoying. You also have all the different userscripts for replying (CD, Factotum, etc.) that to make that warning appear to every one of them would be really hard. Aaron Liu (talk) 22:41, 16 June 2024 (UTC)[reply]
Forced preview was a feature(?) in the early days of the visual editor. However, it previewed the entire page, which would be a terrible experience at ANI.
There's another Wikipedia (Korean, maybe? I can't remember) that does something like this for all posts to their village pump. I don't think it shows your comment. It's more like a message that says "This is the village pump, which is not for random chatting". I don't know for certain how they set it up, but it might be implemented with the 'warn' setting in Special:AbuseFilter. That method would probably work on (almost) all tools. WhatamIdoing (talk) 18:24, 19 June 2024 (UTC)[reply]
I avoid ANI as much as possible but I like this idea, and I'm very impressed by this design. That's some legendary Wikitext work. Toadspike [Talk] 07:49, 25 June 2024 (UTC)[reply]

Wikipedia:MOS on Music / Song Track Listing Credits

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)[reply]

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)[reply]
[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)[reply]
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)[reply]
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)[reply]

Re-use and edit citation

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
You can file a Phabricator task if you want. Aaron Liu (talk) 02:32, 20 June 2024 (UTC)[reply]
Thank you, I will look into thatThhhommmasss (talk) 22:25, 20 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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

[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)[reply]

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)[reply]

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

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)[reply]

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)[reply]
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)[reply]
Disagree. --Dustfreeworld (talk) 19:01, 21 June 2024 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Search engine for policy

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)[reply]

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)[reply]
But the MOS is in the project namespace? The MOS: redirects are in mainspace. Aaron Liu (talk) 00:20, 21 June 2024 (UTC)[reply]
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)[reply]
Don't we have searching in categories now? Aaron Liu (talk) 02:53, 21 June 2024 (UTC)[reply]
Deepcat for policies seem to always fail for some reason. Normal incategory doesn't. Aaron Liu (talk) 02:59, 21 June 2024 (UTC)[reply]
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)[reply]
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)[reply]

Ingest of SEC EDGAR data into Wikidata for Companies?

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)[reply]

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)[reply]

Formatting for mobile phones

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 [3], 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)[reply]

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)[reply]
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)[reply]
Do our readers know how to switch to desktop mode? I can't find a setting. Aymatth2 (talk) 15:11, 23 June 2024 (UTC)[reply]
It's at the bottom of the page. Aaron Liu (talk) 15:12, 23 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
(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)[reply]
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)[reply]

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)[reply]

"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)[reply]
I disagree. It's lightweight and optimized. Aaron Liu (talk) 17:18, 24 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Many gadgets are on by default. The reference hover-preview is a gadget. Aaron Liu (talk) 17:44, 24 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Sure; that functionality could be implemented now in the gadget, even without a separate window. isaacl (talk) 21:10, 24 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Jinx! Aaron Liu (talk) 17:50, 24 June 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Resources on severe mental illness pages

For example, on the pages for “Eating Disorders” and “Anorexia Nervosa” include a section about what hotlines and organizations are available for eating disorder treatment in predominantly English-speaking countries. It’s very likely that struggling individuals may come to wikipedia to learn more about what they’re dealing with, and how someone can access information about treatment is objectively relevant to the topic. Ju1c3machine (talk) 09:34, 24 June 2024 (UTC)[reply]

I'm often one to call out "that's not what Wikipedia is for", but I actually agree. Considering it purely from the perspective of building an encyclopedia, treatment and how people seek it is a legitimate aspect of its coverage, and an article is incomplete without it. I'd also say that these sort of resources are relevant external links that would be appropriate to include at the bottom of their article—maybe even in their own subsection under external links if applicable. Thebiguglyalien (talk) 22:52, 24 June 2024 (UTC)[reply]
Might be worth perusing a recent (2022) discussion on adding suicide hotline numbers to related articles, as it seems pertinent. Link to discussion Schazjmd (talk) 22:59, 24 June 2024 (UTC)[reply]
One question is, who would be responsible/liable if a reader suffers harm from following a no-longer valid or malicious link from such a page? That is why we have disclaimers on pages about medical topics. Donald Albury 23:09, 24 June 2024 (UTC)[reply]
If a link becomes invalid, how is that any different from other links being caught and updated by editors? Wiki isn't providing services so there's no liability issues- same as if the Yellow Pages contained a hotline that went out of order. Ju1c3machine (talk) 13:49, 25 June 2024 (UTC)[reply]
Personally, when seeing this, I was curious what other encyclopedias that exist in part/whole online do regarding this, so I went to a few to check. Let me preface this by saying I don't think it's a valid comparison to compare Wikipedia to a print encyclopedia for something like this, because we aren't ever complete and that's okay in part because we are online and perpetually being improved and updated. My opinion and analysis of policies/guidelines is after the list:
  • Encyclopedia Brittanica - suicide suicide resource box on the side of the page, depression (psychology) crisis information within the first paragraph, no information on article "bipolar disorder", no information on article "schizophrenia".
  • Encyclopedia.com - suicide basics discusses suicide hotlines existing but no specific links/numbers, depression again discusses their existence, and recommends checking "telephone books' [...] Community Service sections [... or] calling emergency services (911 in most places) but this is at the bottom of this long page. Has an article on "crisis intervention" that doesn't list specifics or how to find. Nothing on article "substance abuse". Of note, however, is that some of these articles have "resources" sections that do list specific phone numbers and/or websites for organizations providing hotlines.
  • The Canadian Encyclopedia - suicide info at top of article, mental health nothing in article, but links to a couple hotlines in the external links section at bottom of page, Suicide among Indigenous Peoples in Canada info at top of article.
The biggest issue people have with us including them is "scope" or similar. These arguments necessarily reference what Wikipedia is not - either directly or through essays/etc. Relevant policies, guidelines, and essays that have been referenced before or likely to be referenced now are below - along with my analysis of why they don't preclude mental health information from being provided on pages:
  • From WP:NOT: Advertising, marketing, publicity, or public relations... or issuing public service announcements - nobody's asking for "public service announcements" style of information. What people are asking for seems to be similar to what The Canadian Encyclopedia publishes on their articles directly about suicide. Also from WP:NOT: Simple listings without contextual information showing encyclopedic merit. Listings such as the white or yellow pages should not be replicated. - this is referencing actual lists that are not encyclopedically relevant, not what's being requested here.
  • From WP:ADVOCACY: Wikipedia is first and foremost an encyclopedia which aims to create a breadth of high-quality, neutral, verifiable articles and to become a serious, respected reference work. - as shown above, many encyclopedias do publish resources as part of their encyclopedic mission. Also from Wikipedia:Advocacy § Identifying advocacy: Some editors come to Wikipedia with the goal of raising the visibility or credibility of a specific viewpoint. It may be a hypothesis which they feel has been unduly dismissed or rejected by the scientific community; it may be alternate or revisionist interpretation of a historical event or personage; it may be additions to an article about an organization to portray it in a positive or negative light. The essential problem is that these goals conflict with Wikipedia's mission. Wikipedia is not a venue to right great wrongs, to promote ideas or beliefs which have been ignored or marginalized in the Real World, or to be an adjunct web presence for an organization. Wikipedia cannot give greater prominence to an agenda than experts or reliable sources in the Real World have given it; the failure to understand this fundamental precept is at the root of most problems with advocacy on Wikipedia. - resource information is not advocacy by any definition. The only applicable part of this could be "an adjunct web presence for an organization", but even that doesn't really apply, since nobody is advocating for any specific organization to be represented, but general information. The potential for the resources to be used to advocate for specific organizations can be handled through guidelines on how the specific information displayed is to be selected, where it is to be displayed on the page, and carefully selecting which pages they do display on.
  • No Righting Great Wrongs is also commonly referenced - but it doesn't apply here. You might think that Wikipedia is a great place to set the record straight and right great wrongs, but that is absolutely not the case. While we can record the righting of great wrongs, we can't actually "ride the crest of the wave" ourselves. - there is no "record" attempting to be "set... straight", and in fact, we wouldn't be "rid[ing] the crest of the wave ourselves". Many encyclopedias that are online include these resources already, and in fact many non-encyclopedia websites do too. We would be following, not leading, in that sense.
  • The 5 pillars - Wikipedia is an encyclopedia - Wikipedia combines many features of general and specialized encyclopedias, almanacs, and gazetteers. - again, as showed above, encyclopedias do contain this sort of information sometimes.
  • Wikipedia:No disclaimers - A disclaimer in a Wikipedia article is a statement or warning that the article is not appropriate, suitable, or guaranteed for some specified purpose. - again, not what's being requested here. While some may desire for these notices to include a statement about what is included in the article, that is not what the basis of this is about. Again, see The Canadian Encyclopedia - a simple statement To reach the Canada Suicide Prevention Service, contact 1-833-456-4566. would suffice, even without the first sentence they include about the content of the article.
  • Wikipedia:External links - External links normally should not be placed in the body of an article. Nobody is proposing they be placed in the body of the article, but instead in a header or infobox style. And to note, infoboxes already allow external links in them, so there's a huge precedent for external links not being relegated to the bottom of the page when placing them at the top is more useful to our readers. Some acceptable external links include those that contain further research that is accurate and on-topic, information that could not be added to the article for reasons such as copyright or amount of detail, or other meaningful, relevant content that is not suitable for inclusion in an article for reasons unrelated to its accuracy. Pretty clear that this is "further research..." and is "other meaningful, relevant content that is not suitable for inclusion in the article".
  • Arguments are also made that the information may become outdated, become malicious, not work when a reader clicks them... but these sorts of arguments don't affect our ability to put other external links in articles, even in the infobox. As always, Wikipedia is never finished, and these notices could be crafted in a way that allows (trusted) editors to update them when necessary. And that's actually the benefit of an online, everyone-can-edit encyclopedia over a print one - a print encyclopedia would not be able to be updated on the spot if/when resources change. Hence why I do not think comparing us to print encyclopedias here is reasonable - because they do have this as a valid reason to not put information into their print versions.
  • Last thing I'll address in these bullet points is the question of liability that Donald Albury brings up above. To make a slight correction, we do not have disclaimers on medical articles - but the reason we don't is the general disclaimer at the bottom of every page on the wiki. We also have the medical specific disclaimer, but that isn't actually linked directly from the bottom bar, and per our guidelines on disclaimers, shouldn't be linked in specific articles either. If those disclaimers suffice to protect us from liability from pages that explicitly detail current medical practice, and even more so, pages like crisis hotline, rape, suicide, and more to have external links to, phone numbers for, information about, and images that reference them now... then those same disclaimers will protect us if the same information is presented in a different manner/place on the page. If this sort of proposal is further developed, it would be prudent to confirm with legal the wording/etc to ensure they're aware - but they've really never prior regulated the wording of content in that sort of way.
To be quite honest, this is a stylistic decision, and only a stylistic decision. Not an issue of whether it's encyclopedic or not, because other online encyclopedias do include this information at least sometimes (and again, we follow, not lead). Not an issue of whether a link would violate our policy on external links, because such links would meet the three criteria listed there: Is the site content accessible to the reader? Is the site content proper in the context of the article (useful, tasteful, informative, factual, etc.)? Is the link functioning and likely to remain functional? (emphasis mine). It's not trying to right a great wrong, because there is no "great wrong" being righted, this would be purely informational in nature. It's not a disclaimer, because nobody's suggesting this be simply be a warning about what follows in the article (which would be a disclaimer), but to more prominently place relevant and helpful information towards the top of the article in some way. Not advocacy, because nobody is suggesting we advocate for anything - providing this information at the top of the article(s) in question would serve an informational purpose for our readers. While it's certainly within us editors' discretion as a community here to decide "we don't want to provide this information", there's really no policy reason that we can't. And even if there was, If a rule prevents you from improving or maintaining Wikipedia, ignore it. Wikipedia exists to be an encyclopedia - "A comprehensive reference work (often spanning several printed volumes) with articles" - and to provide useful articles for readers... in a way that the reader will understand and find interesting. Whether we want to admit it or not, some readers will be directed to Wikipedia when they are searching for information about suicide, mental health, rape, etc. and currently, the primary place they will see it is the very end of articles in External Links - which does not serve our readers who will in a time of distress see a long article and likely never make it to the EL section. For all of the above reasons, I support further discussion, and workshopping of an infobox or top-banner style notice to be placed on pages that would provide this information. I would be happy to workshop some examples of formatting if it would be beneficial to this discussion or an eventual RfC, but I would need others to input on the best way to provide geographically relevant information - is it that the banner links to a separate page (whether in article space, project space, or elsewhere) that contains resources by country/location? Or is it the use of geo-notices as proposed here? Or is there another way that wouldn't require the user to click through to a separate page? -bɜ:ʳkənhɪmez (User/say hi!) 01:00, 25 June 2024 (UTC)[reply]
"Whether we want to admit it or not, some readers will be directed to Wikipedia when they are searching for information about suicide, mental health, rape, etc. and currently, the primary place they will see it is the very end of articles in External Links" That's funny. I would have thought that the primary place they would find such information is the articles themeselves. If I were looking for help, therapy, treatment, etc for such things, I wouldn't go to the article about them. I would do a search for "suicide helpline" or "rape crisis center", etc. Sorry, but you still fail to show that WP:NOT doesn't apply. User:Khajidha (talk) (contributions) 13:26, 25 June 2024 (UTC)[reply]
It's completely reasonable that someone that suspects they may have a mental health problem may do research about it to see if it really does line up with what they're experiencing. Providing this information in no way detracts from the usefulness of Wikipedia- the only possible effect is positive. Ju1c3machine (talk) 13:47, 25 June 2024 (UTC)[reply]
That's not what the original poster is asking to add. That's what should already be in the article. --User:Khajidha (talk) (contributions) 14:07, 25 June 2024 (UTC)[reply]
I am the original poster- I'm saying that if someone is researching a condition, it might be because they're thinking they have it, so including resources would be helpful. Ju1c3machine (talk) 14:31, 25 June 2024 (UTC)[reply]
Which are you looking to add 1) details about the disorder to "see if it really does line up with what they're experiencing" or 2) places to go for an actual diagnosis, because these are different things. The first is encyclopedically relevant, the second isn't. --User:Khajidha (talk) (contributions) 14:46, 25 June 2024 (UTC)[reply]
I'm asking to add resources such as official government sponsored hotlines, because if someone is on the page for a mental illness they think they might have, where to find treatment is relevant and helpful information. Ju1c3machine (talk) 17:57, 25 June 2024 (UTC)[reply]
No, the most likely effect will be that more people will rely on Wikipedia to give them information about helplines, etc., rather than on more relevant and more complete websites. Chaotic Enby (talk · contribs) 17:32, 25 June 2024 (UTC)[reply]
As mentioned before, news sites commonly include hotlines at the end of articles about suicide- I don't think anyone has drawn the conclusion that they should head to the NYT for mental health information. Ju1c3machine (talk) 17:58, 25 June 2024 (UTC)[reply]
I don't see an issue with making a cat hall page to list "recognized" resources for mental health type issues, with "recognized" being either official govt resources (like 988 for the Suicide hotline) or from expert, well known medical organizations in that area. Since these can vary by country, a separate page makes sense, and which could be highlighted by a color keyed navbox. Masem (t) 14:21, 25 June 2024 (UTC)[reply]
I definitely agree that we might want to limit resources to those that are official/government funded instead of random organizations. Ju1c3machine (talk) 14:32, 25 June 2024 (UTC)[reply]
How many official/government contact points are we talking about? There are 193 members of the UN plus a few other generally recognized sovereignties, some breakaway states, a number of dependent territories, and many sub-territories (states, provinces, etc.), each of which may have their own resource contact points. So, do we concentrate on providing contact information only for political units with large populations? Sending people to on-line contacts which do not have a local presence will often not be enough. In some places, directing people with problems to official contacts may not be the best way to help them. Maintaining all of that information (protecting it from link-rot, vandals and well-meaning but ill-informed editors) is going to require work from volunteers (edit-protection or pending changes may help, but is not perfect). I am afraid that, based on the typical level of maintenance in Wikipeida projects, a page such as proposed here will end up giving unusable or even harmful information to people seeking help. Donald Albury 16:28, 25 June 2024 (UTC)[reply]
For article content, when the full list isn't feasible, we usually focus on large English-speaking countries plus anything with significance (the oldest, the biggest, etc.).
For external links, we would normally link to a web directory instead of maintaining anything ourselves (e.g., https://www.psychologytoday.com/us/basics/suicide/suicide-prevention-hotlines-resources-worldwide for suicide hotlines). WhatamIdoing (talk) 16:43, 25 June 2024 (UTC)[reply]
If this is on a separate list page, there is no reason not to include them all. One or multiple tables (organized by continent) can make for easy navigation. Subpages could be made for North America (US states and Canadian provinces) and any other country where there is such significant lower level govt involvement. — Masem (t) 16:44, 25 June 2024 (UTC)[reply]
I was thinking that keeping it to English-speaking countries would be enough, considering this is English Wikipedia. Ju1c3machine (talk) 18:02, 25 June 2024 (UTC)[reply]
I like the idea of a separate page or a template similar to a navbox, but I think that should only be a partial solution. Again, many articles already include resources (of varying quality and number) at the bottom of the page in the external links section. So adding more resources even further down on the page doesn’t really improve anything here. Maybe I misunderstood you? But I’d prefer it to be an info box style template (whether above, below, or incorporated into the info box if the article had one) with a sentence inviting people to click a link if all they want to see is the resources without having to scroll the article. -bɜ:ʳkənhɪmez (User/say hi!) 18:56, 25 June 2024 (UTC)[reply]
On the original idea, of having a section (or paragraph) in articles about various organizations/crisis lines, I think it's a good idea. If the article is organized along the suggested WP:MEDSECTIONS plan, then it would usually go under ==Society and culture==. For example, an article about suicide could mention 1-800-273-8255 (song).
In terms of ==External links==, Wikipedia:Manual of Style/Medicine-related articles#External links has recommended for years that local/city organizations be excluded (because even if we think it's great that one city has a support group meeting on Thursday mornings for that kind of cancer, that's really not useful information for the rest of the world), and that either a small number of national/international groups be considered for inclusion, or a link to a good Web directory (which does not have to be Curlie, and often shouldn't be). WhatamIdoing (talk) 16:37, 25 June 2024 (UTC)[reply]
  • This is becoming a WP:Perennial proposals issue, but I have several reservations about this practice, however well-intentioned. The evidence of the effectiveness of suicide hotlines is inconclusive.[1] Any endorsement of this health intervention is non-compliant with WP:MEDRS. The inclusion of such resources could a) be taken as condescending by people who have these conditions or b) could encourage faulty self-diagnosis, which would be very problematic. Encouraging the reader to think of their subjectivity as a potential victim of an illness can have deleterious psychological effects. Further, as Donald Albury notes, the work of actually verifying that any given hotline, even if government-sponsored, is actually sincere in its mission and serves to help those who call it represents a massive amount of volunteer effort on a global scale, with a very real risk of sending people to crisis lines that will cause them harm (due to insufficient patient privacy protections, due to inadequately trained personnel or ideologically rather than scientifically-driven therapy practices, etc.). The framing of this entire question feels like a response to a school-assembly PSA: why depression and anorexia? Why not schizophrenia, or BPD? What about illnesses that are not primarily mental, but which almost certainly see a significant amount of traffic from people who suspect that they've contracted them, such as gonorrhea or COVID? Crisis hotline disclaimers are a feel-good solution in search of a problem, and we will certainly find a can of worms' worth of problems if we implement it. signed, Rosguill talk 17:09, 25 June 2024 (UTC)[reply]
    OP here- you might note that the original post uses anorexia as an example- if there are help lines for BPD and schizophrenia then I think those should be added as well. I"m not weighing in on physical illnesses because that's very clearly a matter for doctors, and it's a bad-faith argument to compare the two. "Here's where people that have this can get help'" is in no way condescending or encouraging self-diagnosis, and I'm pretty confused on how you drew that conclusion from what I said at all. Ju1c3machine (talk) 18:06, 25 June 2024 (UTC)[reply]
    I agree that it needs more discussion on what article(s) or topics this would display on. But the mere fact that discussion and hashing out are needed shouldn’t preclude a proposal from moving forward. -bɜ:ʳkənhɪmez (User/say hi!) 18:57, 25 June 2024 (UTC)[reply]
The idea needs some workshopping and refinement, but I support in principle. The page/template would need to be 30/500 protected at minimum, but full or templateeditor protection would be preferable because it would be a definite target for trolls. It might also be worth opening a dialogue with the Foundation to see if they or Trust & Safety might want to give some input. They might even have some resources or a grant for maintaining it. The WordsmithTalk to me 17:19, 25 June 2024 (UTC)[reply]
Pages aren't protected preemptively, and trolls are virtually never extended-confirmed so I don't see what full protection would bring in this case, except making it much harder to add new entries assuming the proposal goes through. Chaotic Enby (talk · contribs) 17:25, 25 June 2024 (UTC)[reply]
Articles are usually not pre-emptively protected, though there are some exceptions like Today's Featured Article when it's on the Main Page. Other high-risk pages like the Main Page itself are protected, and we have an entire guideline allowing high risk templates to be pre-emptively protected on a case-by-case basis. Regarding the WP:NOT argument, I think there's a valid WP:IAR exemption that can be justified on humanitarian grounds. The WordsmithTalk to me 17:42, 25 June 2024 (UTC)[reply]
Today's Featured Article is only preemptively protected because previous TFA were repeatedly targeted, and is still only semi-protected. The only preemptively full or template-protected pages, high-risk templates are protected because they are transcluded on tens of thousands of pages and can cause immediate widespread damage to the encyclopedia, while not needing regular updates. A list of information on many organizations will definitely need regular updates, while not being transcluded to the same scale as citation or infobox templates, so full protection is very much not needed. Chaotic Enby (talk · contribs) 18:20, 25 June 2024 (UTC)[reply]
Sorry, but this still falls under WP:NOT. You have still not demonstrated why Listings such as the white or yellow pages should not be replicated. does not apply here, especially with the proposal of making separate pages for this information. Chaotic Enby (talk · contribs) 17:29, 25 June 2024 (UTC)[reply]
Information on organizations that treat or provide assistance with a disease is objectively relevant to the Wiki pages aimed to provide information about that disease. Even if that were not the case, I also agree with The Wordsmith on there being a valid exemption to the rule for humanitarian reasons. Ju1c3machine (talk) 18:10, 25 June 2024 (UTC)[reply]

References

  1. ^ Hoffberg, Adam S.; Stearns-Yoder, Kelly A.; Brenner, Lisa A. (2020-01-17). "The Effectiveness of Crisis Line Services: A Systematic Review". Frontiers in Public Health. 7. doi:10.3389/fpubh.2019.00399. ISSN 2296-2565.{{cite journal}}: CS1 maint: unflagged free DOI (link)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)&oldid=1230973861"