Jump to content

Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)

Village pump sections
post, watch, search
Discuss existing and proposed policies
post, watch, search
Discuss technical issues about Wikipedia
post, watch, search
Discuss new proposals that are not policy-related
post, watch, search
Incubate new ideas before formally proposing them
post, watch, search
Discuss issues involving the Wikimedia Foundation
post, watch, search
Post messages that do not fit into any other category
View all village pump sections at once
Other help and discussion locations
I want... Then go to...
...help using or editing Wikipedia Teahouse (for newer users) or Help desk (for experienced users)
...to find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review
...help resolving a specific article edit dispute Requests for comment
...to comment on a specific article Article's talk page
...to view and discuss other Wikimedia projects Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography Citing Wikipedia
...to report sites that copy Wikipedia content Mirrors and forks
...to ask questions or make comments Questions


Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Fringe Theories Noticeboard, religious topics, and WP:CANVAS

For years the Fringe Theory Noticeboard has been a go-to for a lot of editors when it comes to soliciting help on religious topics. This has caused… problems. FTN seems bent towards a particular kind of skepticism which, while healthy for Wikipedia as a whole, leads to some serious issues with WP:NPOV, WP:CIVILITY, and on occasion WP:OUT on these topics. The most signifficant incident off the top of my head was admins coming down on FTN for insisting that members of Falun Gong declare themselves as COI editors on any Falun Gong topics. There’s also been some pretty big issues with FTN regulars editing religious articles not realizing when something is technical/academic terminology when it comes to religious topics, which is playing out right now in the discussion here and which got its start on FTN.

There seems to be this attitude that religions should be treated as any other fringe theory and there are regular calls to edit religious articles in a way that seems to be fairly openly hostile. This definitely comes across as trying to right a great wrong with religion not being treated with appropriate intellectual derision. This is especially the case with New Religious Movements such as Mormonism, Falun Gong, etc.

My concern is that exclusively bringing these topics to WP:FTN and not, say, the religion wikiproject (or the appropriate wikiproject for a given religion) ends up feeling like a deliberate decision to exclude people who may be less hostile to a specific religion and comes across as WP:CANVAS, especially in light of how willing FTN regulars are to throw WP:CIVILITY out the window on religious topics to the point of multiple admin warnings and thread closures. My willingness to assume good faith is pretty low here considering the history of open hostility to (mainstream) religious/spiritual topics when they come up on FTN.

My fundamental question here as it relates to policy is should religious topics which are specifically relating to religious history and theology, as opposed to a specific empirical claim, fall under the “fringe theory” umbrella? If so, should the appropriate wikiprojects be notified at the same time so as to not basically canvas people who have specific biases but not necessarily a useful working knowledge of a given topic? Warrenᚋᚐᚊᚔ 10:00, 11 September 2024 (UTC)[reply]

Falun Gong is notably the only religious movement to have a dedicated CTOP designation, ie. Wikipedia:Contentious topics/Falun Gong, beyond the broader Wikipedia:Contentious topics/Pseudoscience and fringe science. Canvassing specific wikiprojects or not doesn't really mean much in my opinion. There definitely are POV editors, but most editors in WikiProjects on religion are heterogeneous. I do think there are tensions in terms of whether Wikipedia exists to promote a religious movements viewpoint about its religion, especially theological summaries, but I don't agree a policy change is helpful or warranted here. If there's any policy to look at, it's about sourcing requirements and weighing. ~ 🦝 Shushugah (he/him • talk) 10:21, 11 September 2024 (UTC)[reply]
Falun Gong is notably the only religious movement to have a dedicated CTOP designation
Keep in mind the incident I was referring to was FTN demanding Falun Gong editors out their religious affiliation when editing pages, which the admins in the discussion came down like a meteorite on. It's not just a question of "Is this religion fringe/y" but this sort of r/atheism open hostility to religious topics, especially when it gets into the theological weeds and not just something which is clearly fringe. Warrenᚋᚐᚊᚔ 10:26, 11 September 2024 (UTC)[reply]
the admins in the discussion came down like a meteorite on ← sounds impressive. What sanctions were applied? Bon courage (talk) 11:14, 11 September 2024 (UTC)[reply]
I'd also like to hear more about this. It's news to me. :bloodofox: (talk) 06:43, 12 September 2024 (UTC)[reply]
On the other hand I do remember plenty of action in relation to the LDS/COI fracas, like an enormous amount of activity at ANI ending in sanctions.[1] and a WP:BUREAUCRAT losing their bits. But we're told here the multi-admin "meteor strike" was on FTN participants? Curious. Bon courage (talk) 08:00, 12 September 2024 (UTC)[reply]
There can be 'fringe theories' about everything, including religious history and theology. It is trivial for wikiproject pages to transclude FTN if desired so as to provide notifications to followers. Feoffer (talk) 10:22, 11 September 2024 (UTC)[reply]
But the issue isn't other people transcluding FTN, it's FTN editors only pinging FTN on religious topics when the editing gets contentious, as opposed to anyone else regardless of their experience in the exact topic in question, which is why it feels pretty strongly like WP:CANVAS. Warrenᚋᚐᚊᚔ 10:29, 11 September 2024 (UTC)[reply]
  • Not this again. This is like a stuck record from the OP, who keeps popping up at FTN to air this supposed grievance. The lack of the examples in their complaint speaks volumes and I suggest Hitchen's razor is applied. But, to repeat what has often been said there: religion does not fall under WP:FRINGE but when claims from a religion obtrude into the real world (like claiming that Christian Science can cure disease or that the E-meter has a useful function) then WP:FRINGE can certainly apply; the religious aspect doesn't give nonsense some sort of Holy Shield from Wikipedia's NPOV policy by which it must be accurately described within a rational, knowledge-based context. Bon courage (talk) 11:12, 11 September 2024 (UTC)[reply]
    This is like a stuck record from the OP, who keeps popping up at FTN to air this supposed grievance.
    What? I was told to bring this here during the last huge blowout about it and hadn't gotten around to it, the current spate of Mormon topics on FTN made me think it's finally time to get around to it. Beyond that I'm a regular at FTN? I'm not "popping up at FTN to air this supposed grievance", I'm a regular contributor there who is bothered by the handling of a specific topic at FTN and this is a recurring and ongoing problem, who only brings it up when that problem comes to the forefront, which it has in two separate and ongoing threads.
    The lack of the examples in their complaint speaks volumes
    I didn't provide specific examples because the main talk page of FTN is right there for all to see and I didn't want it to come across as airing grievances with specific individuals, or make the discussion about, say, Cunning folk traditions and the Latter Day Saint movement rather than the broader issue of FTN on religious topics.
    religion does not fall under WP:FRINGE but when claims from a religion obtrude into the real world (like claiming that Christian Science can cure disease or that the E-meter has a useful function) then WP:FRINGE can certainly apply
    I addressed this right away in the post you're replying to. The issue isn't the E-meter like content, which are absolutely fringe, but rather people treating core claims of theology as a fringe topic, when it may be a bit fuzzy in a Venn diagram between a fringe topic and a religious one, or even just blanket religious topics being treated as fringe despite them being wholly articles of faith. You've been around FTN long enough to know that there's a contingent that see religion as an inherent enemy and I'm very far from the only person to bring this up recently. Warrenᚋᚐᚊᚔ 11:33, 11 September 2024 (UTC)[reply]
    No, I think you're imagining things and keep banging on about reddit and atheism. If people want to believe a Douglas DC-8 piloted by Xenu put Thetans in a volcano (or whatever) as part of their 'core theology' that's fine. If they say it actually happened that's a problem. There is nothing here to fix. Or do you have a specific proposal? Bon courage (talk) 11:37, 11 September 2024 (UTC)[reply]
    No, I think you're imagining things and keep banging on about reddit and atheism.
    As I'm far from the only one to raise this specific concern, that sure seems like a mass hallucination then. I (and others) use "r/atheism" as a shorthand for a specific form of "angry at religion" type of persona that pops up basically all over in bursts. It's a shorthand, and it's one where I'm far from the only person using it.
    If people want to believe a Douglas DC-8 piloted by Xenu put Thetans in a volcano (or whatever) as part of their 'core theology' that's fine.
    What isn't fine is users not feeling that a topic is being treated with appropriate derision, as opposed to just WP:NPOV and addressing WP:PROFRINGE. This comes up a hell of a lot on religious topics on FTN, and while it's not exactly a majority stance it is a present one. A contingent of FTN basically likes viewing the Resurrection of Jesus and the Loch Ness monster as rhetorically equivalent and deserving of the same sort of treatment. Regardless of personal beliefs around either, Wikipedia is not the place to air personal grievances with religion.
    There is nothing here to fix. Or do you have a specific proposal?
    Well, seeing as FTN handles religious topics indelicately, inexpertly, and with a very gung-ho attitude I think that making sure the appropriate wikiproject is roped in on religious issues would probably do quite a lot. I think the current discussion on cunning folk is a pretty great example of FTN jumping the gun due to a lack of familiarity with the literature on a given topic. Warrenᚋᚐᚊᚔ 11:45, 11 September 2024 (UTC)[reply]
    WikiProjects do not or should not create Wikipedia:Local consensus. You are welcome to add any relevant WikiProject banners on any talk pages, and notify any WikiProjects you want for broader discussions. It would not be seen as canvassing, because a WikiProject in of itself does not represent any particular NPOV (hopefully true for the WP:TERRORISM related ones). Sure, {{WikiProject Mormon}} likely has more adherents of LDS faith, but also more importantly, people with scholarly knowledge, whether as adherents, critics and other. If a specific WikiProject is POV pushing or trying to create local consensus, that can be dealt with, but in of itself, notifying any WikiProject you want is fine. Admittedly some projects like WP:ISRAEL and WP:PALESTINE COULD be merged, but neither projects are in of themselves "canvassing" when being notified. ~ 🦝 Shushugah (he/him • talk) 11:59, 11 September 2024 (UTC)[reply]
    If a specific WikiProject is POV pushing or trying to create local consensus, that can be dealt with
    This is what I think is happening with FTN, though not necessarily very explicitly. "Anti-religion" isn't a neutral point of view, and it can come across as canvasing to go to a place where that's a prevailing attitude while simply ignoring the other wikiprojects that may actually have more ability to contribute directly to the topics at hand.
    Essentially I don't feel that
    a WikiProject in of itself does not represent any particular NPOV
    holds true for FTN when it comes to religion. Warrenᚋᚐᚊᚔ 12:03, 11 September 2024 (UTC)[reply]
    FTN is a noticeboard, not a WikiProject. Bon courage (talk) 12:07, 11 September 2024 (UTC)[reply]
    Whoops, sorry, you're right, that's what I get for reading along too quickly. Warrenᚋᚐᚊᚔ 12:07, 11 September 2024 (UTC)[reply]
    Last time I looked FTN had a large number of people with different takes on topics. Maybe you'd go to WP:SKEP for atheism? Bon courage (talk) 12:10, 11 September 2024 (UTC)[reply]
    Anyways, your point begs what's considered neutral/default state, and when it comes to religion, is not an easy one. I find this essay helpful Wikipedia:Criticisms of society may be consistent with NPOV and reliability. As someone who was raised extremely religious and now atheist, I am appreciative that Wikipedia has always been a decent source of summarizing the state of literature out there. In some cases, it was not as "comprehensive" as my specific religious theological education, because the sourcing requirements were not up-to par. There are better resources off-wiki if the goal is to provide a religious seminar. ~ 🦝 Shushugah (he/him • talk) 12:12, 11 September 2024 (UTC)[reply]
    I think the bigger issue is where it relates to New religious movements like Falun Gong, Mormonism, the Moonies, etc. which have a lot less established literature around theology and people tend to be a lot more open about treating with derision. Hell, I've been accused of being crypto-Falun Gong on FTN and I'm an FTN regular... Warrenᚋᚐᚊᚔ 12:16, 11 September 2024 (UTC)[reply]
    I suppose some notions are risible, and being labelled 'religion' doesn't mean a topic becomes deserving of respect (although maybe religious people believe this?) Thus yogic flying is as daft as perinium sunning: just because one has religious-y connections doesn't mean it isn't nonsense on toast. Bon courage (talk) 12:21, 11 September 2024 (UTC)[reply]
    I think you are imaging (or maybe projecting) this "anger". Complaining about the supposed mental state of fellow editors is not useful. Wikipedia editors are often inexpert; it is the basis of much discussion on every article ever. If anybody want to inform any WikiProject that a discussion at any noticeboard may be of interest they may do so. Indeed that is often useful. Bon courage (talk) 12:00, 11 September 2024 (UTC)[reply]
    I think you are imaging (or maybe projecting) this "anger". Complaining about the supposed mental state of fellow editors is not useful.
    Surely this was intentional?[Humor] Warrenᚋᚐᚊᚔ 12:11, 11 September 2024 (UTC)[reply]
    Core claims of theology can be fringe, for example miracles. Horse Eye's Back (talk) 14:33, 11 September 2024 (UTC)[reply]
    Not sure what the Cunning folk traditions thread has to do with anything. There were only 4 posts by 3 posters (including you and an IP). The initial post by @Feoffer: was clearly on the wrong board -- such a proposal if having too few people for consensus (or if too contentious) on an article Talk page is meant for an RfC on that Talk page, usually with notification of the relevant WikiProjects. The lack of replies on FTN suggests other watchers were generally aware this was misplaced. SamuelRiv (talk) 15:11, 11 September 2024 (UTC)[reply]
  • Since the stated purpose of this noticeboard (top of page) is "to discuss already-proposed policies and guidelines and to discuss changes to existing policies and guidelines" and nothing of the sort is in evidence, I suggest this thread is closed as off-topic. Bon courage (talk) 12:45, 11 September 2024 (UTC)[reply]
    I get that you don’t agree with the thesis in the slightest but I was literally told to bring this exact topic here. Warrenᚋᚐᚊᚔ 12:48, 11 September 2024 (UTC)[reply]
    Anybody telling you to post like this at WP:VPP needs a WP:TROUT. Perhaps WP:VPM or WP:VPI could have been appropriate. Bon courage (talk) 12:59, 11 September 2024 (UTC)[reply]
    I agree that this should probably be on one of the other Village Pump boards, since there's not really a P&G change or problem suggested here. It's not a huge deal either way, and the thread is already going, but the procedure to move a discussion thread is easy enough and can be done by anyone. Warrenmck, if you like, you can use the {{Moved discussion to}} template set and simply cut-and-paste this thread to a different pump. (But again, not a big deal either way.) SamuelRiv (talk) 14:49, 11 September 2024 (UTC)[reply]
    Be happy to, but I’m on my phone right now and it’d be a bit cumbersome. Warrenᚋᚐᚊᚔ 16:12, 11 September 2024 (UTC)[reply]
  • Putting aside the rest, the question is should religious topics which are specifically relating to religious history and theology, as opposed to a specific empirical claim, fall under the “fringe theory” umbrella. That's a fine policy question to ask here IMO as it's about WP:FRINGE. But the implied question here is actually "should religious topics be exempt from WP:FRINGE" and the answer is no. Not every aspect of religion has to do with WP:FRINGE, but some do. If someone is applying WP:FRINGE where it doesn't belong, that's the same as any user applying any other policy incorrectly and would have to be dealt with on the user level. If you think users are systematically misapplying policy at FTN, that's an issue for WP:AN and would need a lot of unambiguous diffs. — Rhododendrites talk \\ 13:06, 11 September 2024 (UTC)[reply]
    I don’t think this could be done at WP:AN, because it’s more of a general attitude thing than a problem with specific users. Unambiguous diffs of FFN misapplying FTN are either easy or impossible, depending on what the remit of FTN is. I definitely agree that religion shouldn’t be exempt from fringe, but there’s a contingent that treat religion itself as fringe.
    looking at the threads I’ve been involved in recently on religion:
    1. The LDS and Cunning Folk thread, which seems to heavilystem from a misunderstanding that “cunning folk” is the specific applicable academic term which exists well beyond Mormon topics.
    2. The Joseph Smith Golden Plates thread. It’s rife with calls that Wikipedia should be outright calling Joseph Smith an active fraud, sources not fully agreeing with that conclusion (though leaving the possibility open) be damned.
    3. The Tukdam thread, which did actually call out some issues with that page but also didn’t grasp the language used by researchers working with minority religious communities (and fair enough, that’s esoteric)
    Of twenty threads on FTN right now, nine are directly about religion (discounting the tenth which mentions religion but which is really just about racism). Most of these do actually belong at FTN, but the substance of the threads really highlights that “religion is not inherently fringe” seems to be openly ignored by a decent chunk of the involved parties. If half the content on FTN is going to be religious in nature, then it’s not really just about fringe theories anymore, is it? And the lack of civility or ability to handle sensitive topics becomes a prominent issue that could use guidelines for handling so we reduce the amount of inexpert sledgehammers wielded in the direction of religious topics. Warrenᚋᚐᚊᚔ 13:32, 11 September 2024 (UTC)[reply]
    So you're saying all the (what you term) 'religious' threads at FTN are there properly, but there is a problem with stuff being raised there improperly. Then there is the vague complaint that you think some people ignore the “religion is not inherently fringe” idea, but with not a diff in sight. This is bizarre. The supposed bombshell 'cunning folk' thread has only four mild-mannered posts (one of them yours) discussing a proposal.[2] Isn't that what noticeboards are for? Bon courage (talk) 13:42, 11 September 2024 (UTC)[reply]
    If you're so convinced there's nothing of merit here, why the WP:TEND? I think we're all fairly clear on your perspective that this is a nothing sandwich, but hell even in this thread:
    being labelled 'religion' doesn't mean a topic becomes deserving of respect (although maybe religious people believe this?)
    Feels sort of like the problem in a nutshell? Wikipedia's policies around civility and bigotry (not necessarily articles, just to pre-address that) absolutely does distinguish "religious belief" among other categories as deserving respect when it comes to civility. The point isn't respecting the beliefs, it's respecting that they are beliefs and mean a heck of a lot to some people, and while "some people" in this equation aren't entitled to ignore wikipedia policies around verifiability and neutrality in favour of their argument, that doesn't mean that they deserve to have their beliefs mocked and ridiculed in talk pages (but let's be real, the more fringe-y it gets the more that'll happen to a degree).
    That we seem to have exempted NRMs from a need to handle the same way we do world religions is a genuine systemic failing of WP:NPOV. I can't for a second imagine someone who is committed to WP:NPOV and was themselves a Mormon wouldn't take more than a passing glance at the current state of FTN and instantly nope out due to the behaviour of editors in talk pages and noticeboards, and we need those editors to better address fringe relating to those topics. Warrenᚋᚐᚊᚔ 14:02, 11 September 2024 (UTC)[reply]
    From a glance, FTN seems to have a large number of useful Mormon participants. If there are civility problems, raise them at ANI, AE or appropriate venues (but again, you have provided zero evidence). To make the same point again: beliefs are beliefs, but reality is reality. There is no "respect" according to any claim in that latter realm, religious or not. Instead, Wikipedia relies on sources and concentrates on conveying accepted knowledge and if that upsets religious sensibilities, well: tough. So no, the Shroud of Turin is not Jesus' funeral shroud, the Earth is not 6,000 years old, Jesus did not visit America, and prayer does not cure cancer. NRMs and 'mainstream' religions are treated the same in this respect. Bon courage (talk) 14:19, 11 September 2024 (UTC)[reply]
    Nothing in this discussion was a personal attack at you nor was it advocating for a diluting of Wikipedia’s stances around religion. I cannot begin to fathom the tone with which you’ve elected to engage here. Warrenᚋᚐᚊᚔ 14:25, 11 September 2024 (UTC)[reply]
    Basically, you're casting WP:ASPERSIONS on a whole noticeboard (effectively hundreds of editors) saying things which are largely un-evidenced (no diffs given) or simply wrong (such as Mormons shunning FTN). You have attacked me with a "why the WP:TEND?" jibe. Bon courage (talk) 14:37, 11 September 2024 (UTC)[reply]
    The part where you accuse Bon courage of disruptive editing (WP:TEND) without apparent grounds (or with really weak grounds that would equally apply to yourself) does appear to be a personal attack. Horse Eye's Back (talk) 14:41, 11 September 2024 (UTC)[reply]
    I’m trying to act in good faith here, it genuinely seemed Bon Courage was basically misrepresenting the initial argument while saying any discussion should be procedurally shut down. It was not intended as a personal attack. Warrenᚋᚐᚊᚔ 14:47, 11 September 2024 (UTC)[reply]
    From your opening post: "My willingness to assume good faith is pretty low". Bon courage (talk) 15:05, 12 September 2024 (UTC)[reply]
  • "was admins coming down on FTN for insisting that members of Falun Gong declare themselves as COI editors on any Falun Gong topics" did this actually happen? I remember we had a whole string of issues with Falun Gong members being disruptive but I don't remember admins sanctioning FTN or anything like that. Horse Eye's Back (talk) 14:26, 11 September 2024 (UTC)[reply]
    Indeed it is baked into the WP:PAGs that religious belief can be a source of a WP:COI. There's a reason the entirety of Scientology church IP addresses are blocked from the Project. Bon courage (talk) 14:39, 11 September 2024 (UTC)[reply]
    Wikipedia:Fringe theories/Noticeboard/Archive 96 Warrenᚋᚐᚊᚔ 14:44, 11 September 2024 (UTC)[reply]
    Not finding it, which admins and what did they say? A quick search says that the only editors on that page who mentioned COI are you, Bon Courage, and @ජපස:. Horse Eye's Back (talk) 14:53, 11 September 2024 (UTC)[reply]
    The closest thing I can find is this related AE request where the filer was TBanned, another editor who was seen as broadly pro-Falun Gong was indeffed, and "editors in the Falun Gong topic area" (not FTN regulars) were "warned to not speculate about other editors' religious views, nor to attempt to disqualify others' comments based on actual or perceived religious views" (not against "insisting that members of Falun Gong declare themselves as COI editors on any Falun Gong topics").
    In the FTN thread linked by Warren, there is a comment by ScottishFinnishRadish that WP:TPG is clear, Do not ask for another's personal details. It is inappropriate for a number of reasons, and adherents of a faith should in no way be expected to share that while editing. which isn't exactly "was admins coming down on FTN for insisting that members of Falun Gong declare themselves as COI editors on any Falun Gong topics". It's more "one admin saying that it isn't permitted to ask other editors whether they are Falun Gong adherents" which is... sort of close-ish? Caeciliusinhorto-public (talk) 08:46, 12 September 2024 (UTC)[reply]
    Thats just an admin saying that you're supposed to say "Do you have a COI with topic X" without any prompting as to what the COI is believed to be not "Are you a member of topic X? If so you have a COI" which is a pretty common note that admins give. Its certainly not giving COI editors a free pass on COI as long as their COI is personal info (it almost always is)... Which appears to be what the OP was suggesting. COI is not an excuse for outing, but outing can't be used as a shield against legitimate COI concerns. Horse Eye's Back (talk) 17:49, 13 September 2024 (UTC)[reply]
If we were to take this idea to the extreme, then FTN wouldn't be able to discuss topics like faith healing which seem to me to be clearly within scope. Hemiauchenia (talk) 15:19, 11 September 2024 (UTC)[reply]
It'd be a lot easier if you refer us to specific example threads here. It's hardly throwing anyone under the bus to link to discussion threads instead of just implying them for us to find ourselves -- and people seem to be getting offended regardless.
Meanwhile, I believe what you have been referring to many times here is the Cargo cult thread (which is where the suggestion of canvassing and referral to VPP is made). I have two notes: first is that I agree that a P&G noticeboard should not be used for canvassing people back to an article Talk page or an RfC (per existing norms, RfC notifications are done on subject-matter WikiProjects, by subscription, etc). Generally with noticeboards like WP:RSN the scope is limited to resolving issues of the P&G, unless/until discussion goes into article content, at which point it is referred back to the article Talk page. The P&G noticeboards I've followed have been pretty disciplined about this, so I'm not sure whether that's one issue with FTN. On a similar note of scope, noticeboards can refer to superceding policy, and FT is pretty much made up entirely of superceding policies (it feels like it could be better as an explanatory essay more than a guideline imo). So if a post there is actually about a RS or OR dispute, maybe it should instead be referred to RSN or NORN? SamuelRiv (talk) 15:28, 11 September 2024 (UTC)[reply]
RfC notifications are done on subject-matter WikiProjects ← don't think so. WP:BLPN, WP:NORN and WP:NPOVN are for example ideal places to publicise RfCs where those P&Gs apply. Bon courage (talk) 15:45, 11 September 2024 (UTC)[reply]
and people seem to be getting offended regardless.
To the extent I regret raising this thread. I think this thread is itself a microcosm of my core issue: FTN is unable to handle some religious topics in good faith. Not "FTN needs to treat religious claims as non-fringe" which is a honestly strange read multiple people here have had considering that my initial post specifically was narrowly focused on matters of theology and, as an example:
To make the same point again: beliefs are beliefs, but reality is reality. There is no "respect" according to any claim in that latter realm, religious or not. Instead, Wikipedia relies on sources and concentrates on conveying accepted knowledge and if that upsets religious sensibilities, well: tough. So no, the Shroud of Turin is not Jesus' funeral shroud, the Earth is not 6,000 years old, Jesus did not visit America, and prayer does not cure cancer. NRMs and 'mainstream' religions are treated the same in this respect.
How in any chosen diety's name does any of this have anything to do with a concern raised here? Not once did I call for Wikipedia to treat religious topics as hyper-credible per internal logic, nor did I express any concern about articles "offending religious sensibilities", nor did I make any sort of argument that'd exclude faith healing from the remit of FTN:
should religious topics which are specifically relating to religious history and theology, as opposed to a specific empirical claim, fall under the “fringe theory” umbrella?
Faith healing and every single example from Bon Voyage's reply above make specific empirical claims. All of them, without exception. So what I'm left with here is an FTN regular who came in extremely hot for some reason ignoring the fact that I'm also an FTN regular while pretending that my argument was an axe to grind, when my core argument is that FTN handling these topics alone without involving editors familiar with them has lead to some problematic editing, in addition to FTN basically openly vilifying NRMs on FTN. Not once in this entire thread have I said that FTN should leave all religious topics alone, nor, as some seem to imply, have I argued that religious claims should be treated with credulity and handled with kid gloves.
At this point to even engage with this thread I feel like I have to dedicate a fair amount of time to addressing arguments I never made. It feels like people are trying to read some kind of apologetics into my comments which I never intended, and if that's coming across to multiple people then that's a communication problem on my end, but I think that this thread right here has become a perfect example of how complex, loaded, nuanced topics which invoke strong emotions on all sides are not necessarily best handled in a vacuum by a noticeboard which, as much as we'd all love the policy-backed
Neutrally worded notices to noticeboards or projects are not canvassing
to be true, it doesn't necessarily hold water in practice.
@ජපස's suggestion:
Maybe a resolution could be adding a request in the FTN boilerplate that when people start a thread that they notify relevant WikiProjects?
Would solve literally every single issue I have except for the open intolerance, which is a secondary issue. Warrenᚋᚐᚊᚔ 13:50, 12 September 2024 (UTC)[reply]
 Done [3] jps (talk) 17:45, 12 September 2024 (UTC)[reply]
Meanwhile, I believe what you have been referring to many times here is the Cargo cult thread
Funny enough, I haven't even gotten around to reading that one. FTN is genuinely pushing majority-NRM focused some days. Warrenᚋᚐᚊᚔ 13:51, 12 September 2024 (UTC)[reply]
You made an erroneous distinction: "religious history and theology, as opposed to a specific empirical claim". These are not cleanly distinct things. Religious history and theology is rife with empirical claims (Lazarus e.g.), and these are not exempt from "fringe". Your argument is weirdly personifying a noticeboard of hundreds of people with statements as though it were an monolith, like "FTN is unable to handle some religious topics in good faith", with zero evidence. Perhaps the reason you get a "hot" response is because you write accusatory, wrong and confused statements about "problems" which, without any evidence, come across as borderline trolling.
This is all seems track back to when FTN addressed your own muddle over panspermia where,[4] instead of grappling with the problems at hand, you perceived some kind of problem with the noticeboard that was solving those content problems. There you wrongly asserted It’s absolutely erroneous to say “panspermia is a fringe theory” which, ironically, shows the very lack of understanding of specialist terminology you are now attacking here in imagined others. Instead of taking on the chin, you insinuated there was some kind of issue with FTN ("I do think that there's something very problematic here going on"). As another user observed in that linked thread "Instead of trying to find a solution, you are making accusations while claiming you are not". And so we have this pattern here again. It is a time sink. (It should be noted, if this[5] is to believed, that the OP's editing has been to FTN and ANI hugely more than to anything else in the Project, which tells its own story. I'm thinking WP:NOTHERE.) Bon courage (talk) 14:56, 12 September 2024 (UTC)[reply]
There you wrongly asserted It’s absolutely erroneous to say “panspermia is a fringe theory” which, ironically, shows the very lack of understanding of specialist terminology you are now attacking here in imagined others
Well, seeing as I’m a research meteoriticist (essjay aside) I’m pretty comfortable pointing to that specific example as “strong options, little expertise” on the point of FTN. In fact, I’m far more comfortable pointing to that one as an example of FTN inexpertly handling nuanced topics than I am around any of the religious ones. Theres a reason it was very easy for me to cite a pile of papers which make the case that researchers are using “panspermia” in a way that Wikipedia insists is only pseudo-panspermia. The distinction on Wikipedia cannot pass WP:VERIFY, WP:IDIDNTHEARTHAT at FTN aside, which is why I think the best proposal was bifurcating it to Panspermia (Astrobiology) and Panspermia (Fringe theory). FTN is extremely slow to acknowledge there may be a fundamental misunderstanding on the part of the noticeboard around a fringe topic. Of course, trying to bring in a bit of nuance with citations didn’t stop people from accusations of being WP:PROFRINGE and possessing a
lack of understanding of specialist terminology
I’m going to be very honest, since your first post here commenting you’ve been fully on the offensive insisting this is some kind of misguided personal crusade. Between assuming motivations/incompetence on my part and some shall we go with routinely characterful reimagining of the posts you’re responding to I think I’m at least going to bow out of engaging with your replies here, and suggest we consider that mutual to avoid gunking up discussions more. Warrenᚋᚐᚊᚔ 10:34, 16 September 2024 (UTC)[reply]
I would expect an article on a religion to describe, e.g., the foundational documents, the liturgy, the rituals, the tenets. Excluding believers would exclude the editors most likely to be familiar with the literature. As long as an editor is neither attacking nor proselytizing, I don't see a COI. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:23, 11 September 2024 (UTC)[reply]
This just seems to be an argument against the entire concept of regulating COI editing... COI in general applies to the editors most likely to be familiar with a topic, for example the editors most familiar with Edward P. Exemplar are likely Edward himself, his friends, and his family... But we absolutely do not want Edward himself, his friends, and his family writing that article. Horse Eye's Back (talk) 16:44, 17 September 2024 (UTC)[reply]
I personally thrill when people who are less hostile than I to religions post at WP:FTN and I thrill when people who are more hostile than I to religions post at WP:FTN. Generally, I thrill at anyone posting at WP:FTN. Though I may object (sometimes strenuously) to others' positions, I welcome their positions being aired as it helps clarify Wikipedia editorial praxis. I may be singular in this, I understand. Someone with sage observational skills pointed out that I may simply enjoy having arguments more than others. But I have learned things from such arguments and I do think that these discussions have helped clarify matters. Can't there be different strokes for different folks?
Maybe a resolution could be adding a request in the FTN boilerplate that when people start a thread that they notify relevant WikiProjects?
jps (talk) 17:03, 11 September 2024 (UTC)[reply]
I enjoy having arguments more than you do. Phil Bridger (talk) 19:14, 11 September 2024 (UTC)[reply]
If they're notifying the WikiProjects, then it's a content dispute, and so it should be handled by the WikiProjects, or else RfC. If the intent is that FTN is a general-purpose board for fringe content, then that's the domain of a WikiProject, not a P&G noticeboard. (And just because FT has a separate guideline page, does not mean it automatically needs its own noticeboard; and in a separate point, I'd be interested if there's anything in FT that is not entirely redundant with the extensive RS and OR guidelines.) SamuelRiv (talk) 07:19, 12 September 2024 (UTC)[reply]
Eh? All noticeboards except ANI/AN are for content disputes. The stated purpose of FTN is to "help determine whether [a] topic is fringe and if so, whether it is treated accurately and impartially". There is quite a bit in WP:FRINGE which is distinct, for example WP:FRIND, WP:NFRINGE and WP:PARITY. Bon courage (talk) 07:36, 12 September 2024 (UTC)[reply]
You are free to propose FTN for deletion if you don't like the way it is set-up. Others have done so in the past.
I think the consensus has generally been that it's okay to have a centralized discussion board that brings together people who have a general interest in topics that are relevant to WP:FRINGE. WikiProjects have remits which go well beyond that sort of thing.
jps (talk) 15:39, 12 September 2024 (UTC)[reply]
That would be both interesting and useful. It's no secret for example that Falun Gong-aligned accounts once maintained a chokehold on Falun Gong-related English Wikipedia articles like Shen Yun, Epoch times, and Li Hongzhi before a handful of editors finally broke it up. Today many of the responsible WP:SPA accounts have been zpped but new accounts constantly pop up trying at new angles to manipulate coverage. The matter has seen discussion in peer-reviewed material but it is poorly documented on Wikipedia itself. :bloodofox: (talk) 08:05, 12 September 2024 (UTC)[reply]
I think that Wikipedia:Arbitration/Requests/Case/GamerGate is also relevant, but in a very different way. That's the case in which being the target of something like Death by a thousand cuts results in the community blaming the victim for not being able to tolerate even more "minor" annoyances.
I feel like there is some of that going on above. People aren't reacting here, as if from a tabula rasa, to the exact statements being made. They're reacting to long histories and perhaps what sounds like coded meanings or Dog whistle (politics). So, e.g., maybe you didn't directly say "having a religious belief is automatically a COI" – or at least not in this discussion – but other editors have said this, and you said something that reminded them of the overall climate on wiki. And now you're mad at them for noticing the overall climate, or for assuming that you agree with it, and anyway, how dare they be upset about something that upsets them?
If you haven't personally seen editors claiming that being religious is a problem, then I point out that there are l-o-n-g discussions open at ANI and COIN right now about whether being a member of a particular Christian denomination is a formal COI. Note that I'm not linking them because I think that having anyone in this discussion join them would be a bad idea – too much risk of us providing more heat than light, and all that. WhatamIdoing (talk) 17:47, 12 September 2024 (UTC)[reply]
I've never seen anyone say that having a religious belief is automatically a COI, I've seen people say that religious belief or affiliation can be a COI and people say that it can't be. Nothing in policy or guideline seems to support the "can't" side while the "can" side is currently consensus. Horse Eye's Back (talk) 18:03, 13 September 2024 (UTC)[reply]
I don't remember seeing anyone claim that all religious beliefs are always a COI. I have seen editors say that having specific, uncommon religious beliefs (e.g., anyone who belongs to this or that 'cult') is a COI for any articles related to that subject area.
ArbCom disagreed in 2010: "For example, an editor who is a member of a particular organisation or holds a particular set of religious or other beliefs is not prohibited from editing articles about that organisation or those beliefs but should take care that his or her editing on that topic adheres to the neutrality policy and other key policies."
But editors are not required to agree with ArbCom. WhatamIdoing (talk) 18:34, 13 September 2024 (UTC)[reply]
Editors with a COI are not prohibited from editing pages regardless so not sure if there actually is any disagreement there. The catch-22 is that if it is possible to identify the editor's religious affiliation from their edits alone then their edits aren't NPOV. Horse Eye's Back (talk) 05:26, 14 September 2024 (UTC)[reply]
I don't think that's always true, but the case I worry about more is the incorrect "identification". WhatamIdoing (talk) 05:42, 14 September 2024 (UTC)[reply]
In what context is a COI editor actually prohibited from making edits? Incorrect identification is not an outing concern, so not sure why you would worry more about that than legit outing but OK. Horse Eye's Back (talk) 06:36, 14 September 2024 (UTC)[reply]
Incorrect identification is a Wikipedia:Harassment concern. Earlier this year, you made false COI accusations about an editor – based on off-wiki information that turned out to be incomplete in important ways – that resulted in that editor feeling strongly pressured to disclose the highly personal situation that led to them being kicked out of the religion they were raised in. This is bad for Wikipedia, and it is bad for the falsely accused editors. You shouldn't have done that. IMO editors should be strongly discouraged from following your example.
COI editors are officially not prohibited from making all edits, but COI editors are officially prohibited from making most types of contributions. However, in practice, WP:Nobody reads the directions, and many of them are told by well-meaning editors that they shouldn't make any edits at all, and some of them are also told that if they do, then they'll be dragged to ANI or COIN for a criticism and self-criticism session. See, e.g., fully disclosed paid editors being told that simple updates for outdated information should be handled through the edit request system because "it's best" if paid editors never touch the mainspace. It is best – if your personal values prioritize purity over up-to-date articles. WhatamIdoing (talk) 16:52, 14 September 2024 (UTC)[reply]
Well that suddenly took a person turn... These are serious aspersions and that is not my memory of what happened in what ways was the infomation incomplete? I would also note that those allegations turned out to be 100% valid, they were not in any way false. "COI editors are officially prohibited from making most types of contributions" doesn't appear to be true, as far as I can see they are not officially prohibited from making any type of contributions in particular. Horse Eye's Back (talk) 14:59, 15 September 2024 (UTC)[reply]
Casting wp:aspersions is "accus[ing an editor] of misbehavior without evidence". You were accused of misbehavior for a specific course of events. I was not a part of this, it was not linked, and I don't really care, but I found the narrative easy to enough to follow that it seems to me that if I asked you both to spell out in detail the factual series of events, you'd agree -- that's why it's not aspersions.
Since the topic of this sub-sub-thread is COI, and the editor brought up this sad tale because it directly relates to COI, I also see nothing personal or uncivil in it. You state there is a factual lie or inaccuracy in the narrative, so that probably should be hammered on your own respective talk pages. SamuelRiv (talk) 15:01, 16 September 2024 (UTC)[reply]
The catch-22 is that if it is possible to identify the editor's religious affiliation from their edits alone then their edits aren't NPOV.
okay, but I’ve been accused of being Falun Gong for my comments on FTN, so maybe nobody should be trying to divine the religion of editors on the basis of their edits?
like don’t get me wrong, if someone is editing a JW article with watchtower talking points that’s definitely an issue, but there’s little value I can imagine in trying to “gotcha” an editor’s faith and if their editing is a COI issue or otherwise problematic that can be addressed. Someone may simply have bad information and be editing on that basis. Warrenᚋᚐᚊᚔ 10:43, 16 September 2024 (UTC)[reply]
If people's affiliation can be inferred from NPOV edits, then I'd say that's working-as-intended. People can be TBanned for repeated or blatant NPOV on contentious/vulnerable articles without any reference to COI -- that's the whole premise for TBans on stuff like Israel-Palestine (nobody would say that being a national from one or the other is a COI to edit respective articles). Political fervor is quite the driver of disruptive editing -- if that is regulated without COI then why are some here calling for COI for religion?
(fwiw, I'd argue "religious affiliation" is not usually the same as affiliation/membership in a specific church bureaucracy/org that is affiliated with that religion -- so for example one could argue CoS is a church-organization that is affiliated with dianetics philosophy/religion; then an employee of CoS has COI by existing policy. I realize that definition would put a monolithic-monocephalous church in a grey zone, but I'd again say NPOV is sufficient.) SamuelRiv (talk) 15:21, 16 September 2024 (UTC)[reply]
To clarify, I am 100% not endorsing any sort of on-wiki assertion or accusation of another editor's religion or political beliefs based on their editing habits (agreeing Warren above). I am saying such blatant NPOV edits can be called out for what they are, as they have been in every contentious topic area. (It's common also to call out poor or undue sourcing, synth, cherrypicking, etc. -- blatant bad behavior be blatant.) SamuelRiv (talk) 18:14, 16 September 2024 (UTC)[reply]
The trouble with COI editing is it's often not "blatant", but like "dirt in the gauge" of the fine instrument in consensus forming. A !vote in a RfC here, a change of emphasis in an article there, and hey presto! POV achieved! The basic truth is that Wikipedia fails to deal with COIs because of its emphasis on the primacy of anonymity. The two are irreconcilable. Thus: the shit-show continues, and will continue for ever until Wikipedia gets a grip and turns into a serious Project. Bon courage (talk) 18:27, 16 September 2024 (UTC)[reply]
COI can be a subtle problem, but so can many other things. Someone attempting a subtle change in emphasis is not necessarily a bigger problem than editors who believe they're always right – and we have lots of those (including me, except that I really am always right!). If I have to choose between an editor who determines reliability on the basis of whether the source says the Right™ Thing and an editor with a secret COI who wants to slightly shift the emphasis of an article, I might not always think that the latter is the bigger problem. WhatamIdoing (talk) 18:54, 16 September 2024 (UTC)[reply]
That would be to misunderstand, fundamentally, the pernicious nature of COI. People may - on their own behalves - argue passionately in many directions. But when an external interest is exerting influence, the outcome of decision-making will depend of which interest has most sway. It is why serious consensus-making fora (i.e. not Wikipedia) tend to have stringent rules on COI transparency. Bon courage (talk) 19:03, 16 September 2024 (UTC)[reply]
I don't think I'm misunderstanding COI. I think I'm saying that I'd rather have a small problem in an article than a big one. WhatamIdoing (talk) 21:24, 16 September 2024 (UTC)[reply]
Well, you were choosing types of editors you'd maybe prefer. Bon courage (talk) 02:40, 17 September 2024 (UTC)[reply]
A subtle shift in article focus seems like a smaller problem than a big bias in source choice; ergo, I'd choose the editor who spends multiple years pushing for a small shift in focus over the editor who spends multiple years pushing to exclude good sources with the 'wrong' POV and include weak sources with the 'right' POV. WhatamIdoing (talk) 04:26, 17 September 2024 (UTC)[reply]
Hah! Editors are wrong all the time, and preferring weak sources to strong ones is of course a common fault particularly in newbies. But here's the thing: editors with a brain and good faith will generally change their mind, modify their position or gracefully concede a point if they are presented with cogent opposition but have no skin in the game. They learn and grow. The COI editor will forever press Wikipedia to follow the line that they've been assigned, without deviation. I'd rather have an editor corps of messy but correctable human beings than apparatchiks dedicated to shaping content in some particular way so as to advance an outside interest. Bon courage (talk) 04:46, 17 September 2024 (UTC)[reply]
But editors who do have skin in the game, but not of the sort that 'counts' as a COI, don't generally change their minds. They forever press Wikipedia to follow the line that they've personally adopted, without deviation, exactly like that irritating family member that you never want to hear talking about politics at any family gathering.
Also, paid editors are often temporary: eventually, either we come to a plausible compromise (and sometimes that 'subtle shift in article focus' is actually warranted, though not generally with the wording that the marketing department suggests), or the payer decides to quit throwing good money after bad.
People who feel aggrieved about something will argue for decades about their pet thing. I know one who is still upset that his mother had to pay inheritance taxes half a century ago. I don't know if he would agree that he's a "messy" human being, but I am convinced that if he were editing Wikipedia, he would not be a "correctable" one.
Perhaps putting it in WP:UPPERCASE will help: Given a choice between a WP:GREATWRONGS editor pushing bad sourcing and a WP:COI editor pushing a subtle shift in emphasis, I'm often going to prefer the COI editor. WhatamIdoing (talk) 05:26, 17 September 2024 (UTC)[reply]
Or we could just have neither editor... Thats clearly the best solution in terms of improving the encyclopedia. It doesn't have to be one or the other, both the tendentious editor and the COI editor who doesn't respect NPOV can be shown the door if they don't change. Horse Eye's Back (talk) 06:15, 17 September 2024 (UTC)[reply]
Don't spoil it HEB. WAID has chosen her beau and I have chosen mine. We shall both go to the dance and have a thoroughly miserable time. Bon courage (talk) 06:26, 17 September 2024 (UTC)[reply]
Neither would be lovely. However, for some unaccountable reason, the paperwork to declare me Queen of Everything seems to have gotten lost, and until that's resolved, I don't think it's feasible. WhatamIdoing (talk) 19:18, 17 September 2024 (UTC)[reply]
Not seeing why both would be any less feasible than one or the other... If both can be done individually then both can be done together. Horse Eye's Back (talk) 16:27, 18 September 2024 (UTC)[reply]
Neither can be done consistently or reliably. WhatamIdoing (talk) 17:39, 18 September 2024 (UTC)[reply]
If neither can be done then why is the choice either or? Horse Eye's Back (talk) 16:25, 19 September 2024 (UTC)[reply]
Because sometimes figuring out whether Bad Thing #1 is better or worse than Bad Thing #2 is helpful to people. It can help people develop perspective and prioritize their efforts. WhatamIdoing (talk) 21:04, 19 September 2024 (UTC)[reply]
The effect seems to be to excuse one of the bad things, why can't we just say that both are bad and should result in full or partial seperation from the project and which is badder is up to context and personal opinion? Horse Eye's Back (talk) 14:30, 20 September 2024 (UTC)[reply]
We did say that. WhatamIdoing (talk) 16:59, 20 September 2024 (UTC)[reply]
Then perhaps I do not understand the point you wished to make. Horse Eye's Back (talk) 17:17, 20 September 2024 (UTC)[reply]
While I also agree that neither is best if possible, I am also always going to prefer an editor editing in good faith to an editor editing in bad faith. Loki (talk) 19:53, 17 September 2024 (UTC)[reply]
Of course, but few people, except blatant vandals, think they are deliberately trying to make Wikipedia worse. A paid agent may think they're making Wikipedia more accurate or fairer. A personal POV pusher may believe they're making Wikipedia better by giving a little more respect for an idea they believe. Even the parents who show up at Talk:Santa Claus every December, to ask that we not "ruin" Christmas by telling their kids that Santa Claus isn't a living, breathing magical person think they're trying to make Wikipedia better.
That's why the rule is Wikipedia:Assume good faith: assume that the other person – no matter how stupid, misguided, or wrong they may actually be – is actually trying to do something that in their opinion will make Wikipedia better. To put it more bluntly, when the white supremacists show up with their racist garbage, we assume that they're trying to make Wikipedia better according to their own way of thinking, even though we don't agree that their garbage actually makes it any better. WhatamIdoing (talk) 00:44, 18 September 2024 (UTC)[reply]
Yes indeed, I think "bad faith" is one of the most misunderstood/misused phrases on Wikipedia. Bon courage (talk) 11:40, 18 September 2024 (UTC)[reply]
Maybe it would help if we re-wrote Wikipedia:Tendentious editing to say "Tendentious editing is a pattern of good-faith editing that is partisan, biased, skewed, and does not maintain an editorially neutral point of view." WhatamIdoing (talk) 17:41, 18 September 2024 (UTC)[reply]
I agree, which is why I think COI editing is so egregious, because it's one of the few kinds of editing that is actually in bad faith. Loki (talk) 18:41, 18 September 2024 (UTC)[reply]
@LokiTheLiar, imagine that someone works for a big company. In the actual marketing department, no less. This person notices that the number of employees in {{infobox company}} is several years out of date. Imagine that the employee corrects the error.
In your opinion, is that employee "trying to hurt Wikipedia" or "trying to help Wikipedia"? WhatamIdoing (talk) 19:43, 18 September 2024 (UTC)[reply]
You didn't provide the piece of information we would need to know in order to determine that... Their intention. It is most likely that their intention was to promote their company therefore their intention was to hurt wikipedia, but unless you provide that piece of the puzzle the question is (perhaps purposefully) unanswerable in a straight manner. Horse Eye's Back (talk) 14:26, 20 September 2024 (UTC)[reply]
This: their intention was to promote their company therefore their intention was to hurt wikipedia is a logical fallacy. WhatamIdoing (talk) 16:58, 20 September 2024 (UTC)[reply]
How so? The use of wikipedia for promotion unambigously hurts wikipedia, thats why we explicitly ban it (WP:PROMO). Anyone who intends to engage in promotion, advertising, or recruitment intends to hurt wikipedia. Horse Eye's Back (talk) 17:19, 20 September 2024 (UTC)[reply]
While I disagree with him on many COI things, I'm behind HEB here. Correcting an error in order to promote an organization that is paying you to promote them is a bad faith edit and harms Wikipedia.
To see why, imagine that article has three estimates in it for number of employees: one that is too low, one that is correct, and one that is too high. The COI editor only corrects the one that is too low despite being aware of all of them. Is that a good faith edit? Loki (talk) 19:22, 20 September 2024 (UTC)[reply]
@LokiTheLiar, see the comment where I've already addressed the biased assumption that more employees is better for a company. (Hint: Layoffs usually result in stock prices going up, not down.)
Also, what if there aren't three estimates? What if it's just one wrong number in an infobox, and the COI editor is merely correcting a simple factual error?
Just because a person with a COI could make an edit that is intended to harm Wikipedia – or, more likely, that is intended to help the company and doesn't care whether Wikipedia is helped or harmed – doesn't mean that every single edit made by that person is inherently harmful. WhatamIdoing (talk) 20:07, 20 September 2024 (UTC)[reply]
Thats true , but every promotional edit they made would be inherently harmful. They could also make other edits but thats not really the point. Horse Eye's Back (talk) 17:26, 25 September 2024 (UTC)[reply]

{outdent} Two things:

  • Simply replacing inaccurate or outdated information with accurate, up-to-date information unambiguously helps Wikipedia.
    • "As of 2012, the company had 190 employees" → "As of 2024, the company had 165 employees".
    • "As of 2012, Alice Expert was the CEO" → "As of 2024, Bob Business was the CEO".
  • Correcting a factual error is not inherently promotional.
    • Whether more or fewer employees is better (and therefore potentially promotional) depends on how you interpret that. For example, is having slightly fewer employees a sign of good management leading to greater efficiency and productivity, or is it a sign of a shrinking, struggling company that can barely make payroll?

Have you ever heard of a win–win scenario? On those occasions when what's best for Wikipedia happens to match what's best for the company, then Wikipedia is not actually harmed by the company getting what they want.

There are many circumstances in which what's good for the company is bad for Wikipedia, but there are also circumstances in which what's good for the company is also best for Wikipedia. WhatamIdoing (talk) 18:26, 20 September 2024 (UTC)[reply]

In re Thats true , but every promotional edit they made would be inherently harmful. They could also make other edits but thats not really the point.
No, that really is the point. Exclusively promotional edits are harmful, no matter who makes them. A good edit made by a Bad™ person is still a good edit. A bad edit made by a Good™ person is still a bad edit. WhatamIdoing (talk) 19:25, 25 September 2024 (UTC)[reply]
The win-win scenario is when the COI editor makes an edit request like they're supposed to... If they make the edit directly thats a loss for wikipedia. We don't scrub the edits of confirmed COI editors, your argument would only make sense if we did. Horse Eye's Back (talk) 16:00, 27 September 2024 (UTC)[reply]

Break

the editor who spends multiple years pushing to exclude good sources with the 'wrong' POV
I've definitely seen this habit at FTN, and it was one of the impulses for this thread. If FTN has decided their specific understanding of a topic, collectively, is the "correct" one then attempts to address that are often met with accusations of POV-pushing, attempts to introduce FUD for WP:PROFRINGE purposes, etc.
The example raised above is a pretty good one for this. Wikipedia has a hard deliniation between Panspermia and Pseudo-panspermia, but this hard deliniation doesn't exist in the literature and "panspermia" is regularly and routinely used to refer to what Wikipedia calls "Pseudo-panspermia". Note that this isn't "the scientific literature is actually down with the fringe theory" but rather "the specific terminalogical bifurcation that Wikipedia is using is an artifice of Wikipedia and risks confusing readers who come to Wikipedia on this topic from credible sources."
No amount of academic, primary, secondary, etc. sources that show that "Panspermia" can and is regularly used to refer to it landed with anything other than a wet thud and accusations from some of the FTN core. Even in the Tukdam thread that's on FTN right now there's a "Well we can't consider that credible source" (which is, to be fair, actually arguable on the sourcing, but not cut-and-dry per WP:RS). There seems to be this attitude of absolute certainty that arises from FTN which outpaces the ability of people whose personal expertise is more rooted around fringe theories to evaluate.
See: above with me being accused of not understanding specialist terminology in my own field. Warrenᚋᚐᚊᚔ 08:47, 17 September 2024 (UTC)[reply]
You asserted, with the "absolute certainty" you are projecting onto others It’s absolutely erroneous to say “panspermia is a fringe theory”. You were shown the sources to show why this was wrong and had to concede "The Science Direct link you provided is certainly evidence that both terms are used". In such cases Wikipedia need to manage the terminology and use hatnotes to guide the reader, and this is what happened. Consensus was achieved and things improved thanks to FTN. Yet here you are rewriting history and somehow it's the fault of "FTN" that you were in a muddle. It's all very odd. Have you considered the problem isn't with FTN at all, but somewhere else? Bon courage (talk) 14:16, 17 September 2024 (UTC)[reply]
If you have an issue with me personally take it to WP:ANI.
Here is the thread which is being very creatively represented above for anyone who'd like to evaluate it for themselves. FTN's "consensus" on this topic was exactly what @WhatamIdoing seemed to be worried about.
This thread just feels like a huge waste of time at this point, and it really didn't have to. Warrenᚋᚐᚊᚔ 14:51, 17 September 2024 (UTC)[reply]
In fact the thread sprawled to here where the issue was resolved. If I took every editor that was wrong about something to ANI I'd never be out of the place (and would have to take myself there regularly!). I think we can all agree this thread has been a waste of time. It was always going to be since there was no evidence and no proposal. Perhaps this can - for all our sakes - be the last time this particular FTN complaint pony is taken round the park. Bon courage (talk) 14:58, 17 September 2024 (UTC)[reply]
I genuinely can't even begin to think of how to respond to this. Warrenᚋᚐᚊᚔ 15:15, 17 September 2024 (UTC)[reply]
No. Religion is ubiquitous in most parts of the world. While many if not most of the various religions of the world hold beliefs that are not provable by science, they are just that beliefs. While all fringe theories could be categorized as beliefs, not all beliefs are fringe theories. Elmmapleoakpine (talk) 18:55, 25 September 2024 (UTC)[reply]
A religious belief that has no effect on the rest of scholarship is just that. For example, a claim that pure land exists is generally so far removed from physical reality as to be basically just worth documenting as a major belief in Buddhism. However, there are those Buddhists, some of which are more active than others, who claim that there exists a literal Mount Meru that one can actually discover here on Earth. That is a WP:FRINGE theory. jps (talk) 20:25, 26 September 2024 (UTC)[reply]
Not all beliefs are fringe... But all "beliefs that are not provable by science" are fringe. Horse Eye's Back (talk) 16:03, 27 September 2024 (UTC)[reply]
That's not true. Firstly, it's not true because the policy defines a fringe view as "an idea that departs significantly from the prevailing views or mainstream views in its particular field", not according to whether the view is provable by science.
Secondly, it's not true because it's goes against common sense. Views in non-scientific fields (e.g., art criticism, history) are never provable by science and can still be classified as mainstream or fringe. It's nonsense to say that since, e.g., fictional characters can't be scientifically proven to exist, then all views about them are fringe. WhatamIdoing (talk) 17:31, 27 September 2024 (UTC)[reply]
Religious views are never mainstream by definition, no single religion is that large and they don't generally agree on anything. The field of Religious Studies isn't some sort of free for all, even claims which are purely religious can be fringe. The belief that a fictional character was real would be fringe, the mainstream view is that fictional characters are not real. Horse Eye's Back (talk) 15:45, 28 September 2024 (UTC)[reply]
Religious views are certainly "prevailing views", since 85% of the world subscribes to some sort of religious views. Those religious views include ideas that are very widely held (e.g., that humans are different from other animals in some important way; that justice and peace are desirable values; that long-term happiness is something people should seek; that there are good ways and bad ways to relate to others). The belief that justice is better than injustice is absolutely "not provable by science", but it's definitely mainstream. Science might help us understand what actions could achieve specific forms of justice, but science (i.e., excluding the quasi-religion of scientism) can't tell is that justice is good.
When considering not just "the prevailing views" but specifically the "mainstream views in its particular field", we prioritize scholarly sources. For example, most of the world believes in ghosts. The scholars in the relevant fields, using the methods of that field don't. Therefore, "ghosts are real" is WP:FRINGE and "ghosts are not real" is mainstream. There is no limitation here about the relevant field needing to be a scientific one.
Also, let's go back to that fictional character. Othello (character) is a fictional character. What was this fictional character's racial/ethnic background intended to be? There are two mainstream views. Neither are provable by science. Neither of them are WP:FRINGE. A view that "departs significantly from the prevailing views or mainstream views in its particular field" might say that Othello was Irish, and this would be FRINGE. A view that aligns with the mainstream views in the field might say that Othello was a brown-skinned Muslim from the Mediterranean coast, and this would not be FRINGE. But the relevant fields are literary studies, theatre studies, and history, none of which are science. Each view on that question is declared FRINGE or not FRINGE without any reference whatsoever to whether the view is "provable by science". WhatamIdoing (talk) 23:47, 28 September 2024 (UTC)[reply]

There's been another exchange on FTN in the last few days that I think really highlights my issues here. A user (@ජපස:) removed the entire section on academic study from the Tukdam article. They removed a link to a UW-Madison research group publishing on this topic using brain scans and other methods. He dismissed their papers out of hand as not being justified in the article with

It's a bit misleading to claim it's been studied by "western academics". It's actually been studied by religious believers.

Which is obviously not how any of this works. We cannot just decide that the religion of an author is basis for us ignoring the fact that they're publishing in serious journals when research scientists with an American university (not just religious scholars playing with brain scans for fun without any idea what they're doing) and an even passing knowledge of the field of Buddhist Studies will make it very clear that scholar-practitioners are the norm in the field. And this is why FTN should tread cautiously with assuming they know the fields they're editing in. "Well the author is a Buddhist and can't be trusted to write about Buddhism" is not a reasonable take, especially in the context of an academic field that both routinely stands up to outside scrutiny of their scholarship and which is typically rife with people who both practice their faith and publish on it in critical, objective ways.

Why are FTN regulars deciding that the religion of authors is enough to justify the removal of entire sections when we're talking about accepted peer-review publications in Forensic Science International: Reports, Culture, Medicine, and Psychiatry, and Ethnos? Why are we tolerating the dismissal of credible, non-Bealles-list peer-reviewd sources on the grounds of the religion of the author when there's zero evidence whatseover of wrongdoing that could have implicated the study in question or its authors? Wikipedia is worse for this type of editing, incredulity and personal (ir-)religious philosophy shouldn't be dictating the content of articles.

Warrenᚋᚐᚊᚔ 08:48, 28 September 2024 (UTC)[reply]

I feel it's an important detail here that the results of the studies in question didn't particularly support wild, fantastical conclusions that warrant incredulity. The claim was "Meditating dead monks are still somewhat alive" and the paper's conclusion was "He's dead, Jim." It feels like the religion of the authors is the whole basis for the objection of inclusion here, which is not at all how WP:NPOV and WP:RS work, but on FTN it can. This is, to me, simply open bigotry, which is something I've been expressing some frustration at here.
This is why I disagree with @ActivelyDisinterested that
Neutrally worded notices to noticeboards or projects are not canvassing
When a noticeboard starts having its own interpretation of the sites rules and it operates on those, and does so on obscure parts of Wikipeida that may not have many eyes on it, then yes, the official canvassing policy aside if can very much feel like "I want to bring this issue only to people who have the same interpretation of policy that I do." Warrenᚋᚐᚊᚔ 09:02, 28 September 2024 (UTC)[reply]
"I want to bring this issue only to people who have the same interpretation of policy that I do.", so about (insert project name here)... -- LCU ActivelyDisinterested «@» °∆t° 10:07, 28 September 2024 (UTC)[reply]
At this point it would appear to be you who holds heterodox interpretations of policy... Not the guys you keep ranting about. Horse Eye's Back (talk) 15:49, 28 September 2024 (UTC)[reply]
Based on community action earlier this year, Warrenmck is not the one with the heterodox interpretation. A thread at ANI a few months ago ended in a topic ban for a user who was rejecting citations to academically published material about Islam merely on the grounds that the academics were Muslims. Excluding content cited to academically published material about Buddhism merely because the academics were also Buddhists is the behavior and interpretation that's out of step with the community. Hydrangeans (she/her | talk | edits) 16:35, 28 September 2024 (UTC)[reply]
Thank you. I genuinely feel a little crazy with these exchanges here. Between this and the discussion above about how all religions are totally fringe I feel like some of FTN isn't engaging with, well, WP:FRINGE in good faith when it comes to topics of religion, which can result in article quality being reduced, which isn't what any of us want from noticeboards.
It's pretty clear that, while maybe not a huge systemic thing, several editors are using FTN to grind a particular axe. The is probably where things like attacking a credible scholar on the basis of their faith without any evidence whatsoever of impropriety comes from as far as I can tell, because it's certainly not coming from WP:FRINGE or WP:RS. Warrenᚋᚐᚊᚔ 14:36, 30 September 2024 (UTC)[reply]
Over the years, I have rejected a variety of publications about Isra' and Mi'raj on the basis of the apologetics of the author. The fact that academics who are arguing in favor of the literal truth of that story are Islamic is absolutely relevant. It is also the case that the research program Warren is whining about did not result in any solid publications. Not any that would pass WP:REDFLAG certainly. The article text just linked to their research group and press releases! The fact that this guy from UWisc is a devotee of Tibetan Buddhist approaches to meditation while claiming that Buddhists who are good at meditating continue to meditate after they are dead is WP:BOLLOCKS influenced by a blinkered religious devotion. It's the equivalent of Young Earth Creationism or Hindu astrology. jps (talk) 15:52, 30 September 2024 (UTC)[reply]
claiming that Buddhists who are good at meditating continue to meditate after they are dead: Except that apparently isn't what the source claimed, or at least it isn't what was in the article text. The article text that you twice removed (wholesale, with no attempt at just trimming) stated that the study did not detect any brain activity in clinically dead tukdam (italics added). As Warrenmck said that the conclusion was "He's dead, Jim." What's so 'bollocks' about that? And what's so un-solid about the source, a research center at a secular state university (University of Wisconsin-Madison)? You pay no apparent notice to the secular university setting of the source nor to the utterly plausible results of the research (that no, there is no detectable brain activity from the dead monks); all you offer is your apparent revulsion that the researcher was a Buddhist. It's frankly bigotry, and the way you let it influence your editing is disruptive. Hydrangeans (she/her | talk | edits) 18:59, 30 September 2024 (UTC)[reply]
The suggestion that jps has any "apparent revulsion" is unwarranted here. Are we reading the same source? This one appears problematic to me, and the article content being sourced to it should not have relied on such a source. Firefangledfeathers (talk / contribs) 19:07, 30 September 2024 (UTC)[reply]
I think that section should definitely be trimmed but obviously not removed. It's a real and secular study that didn't find anything WP:EXTRAORDINARY, so saying that it existed and didn't find any brain activity ought to be utterly uncontroversial. Loki (talk) 19:52, 30 September 2024 (UTC)[reply]
The EEG on a corpse was hardly the only thing they claimed to "test". The entire enterprise is an ideological juggernaut that includes things like asking the asinine question as to whether the corpses decay at different rates depending on their status as meditators -- claims which are so ridiculous as to be nearly impossible to operationalize. The lack of serious peer-reviewed work in serious journals on this attests to that. The attempt to argue that there is any legitimate research interest whatsoever into whether there might be measurable signs of this religious belief is belied by the fact that WP:FRIND sources are totally absent discussing this. jps (talk) 00:58, 1 October 2024 (UTC)[reply]
The lack of serious peer-reviewed work in serious journals on this attests to that.
From the research group you removed from the article as a "shit" source:
it certainly looks like It is also the case that the research program Warren is whining about did not result in any solid publications. may have been a bit off the mark? Thanks for accusing me of "whining" though.
Warrenᚋᚐᚊᚔ 08:38, 1 October 2024 (UTC)[reply]
C'mon. I see a list that includes predatory and pocket journals, FrotiersIn, MDPI, and moribund backdoors to avoid peer review by competent scholars. And you were already warned at WP:FTN about promoting Frontiers as a potential WP:RS. These are terrible sources for claims about corpses decaying. This is basically WP:PROFRINGE. jps (talk) 15:18, 1 October 2024 (UTC)[reply]
Or not. Frontiers in Psychology is a highly rated journal.[6] Their WP:Impact factor is more than twice the average for the field. Beall's List said that "Some of their journals have a very poor peer-review; some are fine." WP:CITEWATCH says that these journals should be evaluated "case by case", which is significantly different from "anything and everything from MDPI is a terrible source" or "anything in MDPI is basically PROFRINGE". WhatamIdoing (talk) 17:06, 1 October 2024 (UTC)[reply]
Here's the whole list:
  • Forensic Science International is a mid-tier journal, ranked 46th percentile in Scopus.[7]
  • Culture, Medicine and Psychiatry is ranked 90th percentile by Scopus[8] and is indexed by MEDLINE.[9] Their impact factor is high for "culture" and low for "psychiatry".
  • Ethnos is rated 93rd percentile[10] and has an impact factor a bit above average for anthropology.
  • Religions is rated 90th percentile[11] with an impact factor that would be typical for sociology (I don't have numbers for religious studies specifically).
  • Frontiers in Psychology is ranked at the 78th percentile[12] and has an impact factor that's double the typical level for psychology.
I'm not seeing serious problems here. None of these journals are remove-on-sight predatory journals. Some of them are quite respectable. WhatamIdoing (talk) 17:29, 1 October 2024 (UTC)[reply]
Would you rate any of these journals highly for the evaluation of medical conditions or slowing decay? jps (talk) 18:30, 1 October 2024 (UTC)[reply]
A review article in Culture, Medicine and Psychiatry would tick all the boxes for the WP:MEDRS ideal: MEDLINE listed, reputable publisher, good metrics. Dhat syndrome would probably be improved by using their PMID 39136849. Wandering (dementia) would probably be improve by incorporating the POV presented in PMID 29368117. PMID 27142641 looks like it could be useful in Chronic condition or Terminal illness or even Spoon theory, as it presents the process of developing realistic expectations as being a form of healing/healthcare.
I would accept a recent review article, within the usual scope of their field, from any of these journals. I wonder if the problem here is less about the source and more about what the source is being used for. For example, the 1991(!) Cult Med Psy article might be more useful for "Some people have a different concept of death than modern medicine!" than for "It is a definite fact that even though his heart stopped beating last week and he hasn't moved or breathed since then, he's still alive". WhatamIdoing (talk) 19:12, 1 October 2024 (UTC)[reply]
I can definitely get behind an argument that we need to look at what sources are used for. My main interest is preventing some sort of WP:PROFRINGE of the empirical claims associated with Tukdam. There is obvious interest in these subjects from a cultural studies, anthropological, sociological, and comparative religious perspective. The issue I have always had with this particular research group is the attempt to claim there is legitimate research interest in Tukdam within the context of neuroscience, physiology, and even quantum physics(!). There is some shoehorning that I see by the group itself and even more that got laundered into previous versions of our own article text. jps (talk) 14:01, 2 October 2024 (UTC)[reply]
Before I listed Tukdam at WP:FTN, it had been discussed at WT:DYK[13] and transcluded onto the talk page from Template:Did you know nominations/Tukdam. Two editors other than myself had supported the removal of the "Scientific research" section. The primary author of the article restored it.[14] Above, it was mentioned that FTN discussions should be linked from relevant notice boards. Issues about Tukdam had already been raised Wikipedia talk:WikiProject Buddhism weeks before hand.[15] I've added links to both this discussion and the one at FTN just now.[16] If I noticed a problem (a faith-based belief being misrepresented as an evidence-based hypothesis), but I "didn't grasp the language" used by a specialized field, I think posting to a relevant notice board was the correct thing to do. Despite conflicts, do you think that the changes made since the issue was raised improve or worsen the article, Warrenmck? Rjjiii (talk) 16:35, 28 September 2024 (UTC)[reply]
I think most of the changes made so far have been good, and was quick myself to question Tricycle as a source being... not great in the context of that article. None of this has any bearing whatsoever on an editorial decision being presented as based on the faith of the author. An identical conclusion could have been arrived at in any other way, but it's not on me or other editors to discern if just open bigotry is actually masking an in-depth discussion which warrants consideration. If those points exist, then editors should cite them and not the religion of a given academic.
Even if I wholly agreed with every change made (which for the most part, minus the removal of the scientific studies section which I'm still unclear why you and others are calling for its removal, we do agree on) nothing would change in that lines like
It's a bit misleading to claim it's been studied by "western academics". It's actually been studied by religious believers.
shouldn't be happening here. Warrenᚋᚐᚊᚔ 14:29, 30 September 2024 (UTC)[reply]
You're not going to stop my evaluations of religious nonsense by posting to village pump. I'm allowed to make judgement calls in the cause of protecting the encyclopedia from hyperbolic and farcical religious claims. jps (talk) 15:53, 30 September 2024 (UTC)[reply]
I agree with @Warrenmck here. Wikipedia isn't pro- or anti-anything, except pro-verifiability and neutrality. Everyone is allowed to make judgement calls within Wiki rules and consensus (which terms as hyperbolic and farcical do not imply). It's also worth examining what is actually notable about these beliefs; that they exist among a community, or that it wouldn't pass peer-review? A majority of the time with any movement/philosophy (religious or other), it's the former. We could do this about almost anything, like Jesus' resurrection or optimism/pessimism. AnandaBliss (talk) 17:33, 30 September 2024 (UTC)[reply]
I agree that often you want to say something like "Some of these people believe ____". Sometimes an article needs to say "____ is not factually true" (e.g., List of common misconceptions). And I would add a third category: "____ was sensationally claimed in the news/has become a common stereotype in popular culture/was a widespread internet meme in YYYY". WhatamIdoing (talk) 18:05, 30 September 2024 (UTC)[reply]
In this case, the imprimatur of a "research group" was being laundered as a way to claim that there was "serious investigation" into whether or not meditating champions would be able to continue meditating after death and thereby prevent their corpses from decaying. This is pretty WP:BLUESKY nonsense. I do not see how it is at all defensible. jps (talk) 00:51, 1 October 2024 (UTC)[reply]
You again removed the section in question, with the edit comment of
Get better sources if you think there is anything here. These sources are shit.
There's a content dispute here, but also a fundamental behaviour and WP:OWN issue. At no level is how you're engaging with this appropriate. It feels like you have far more of an issue with the fact that the research group exists at all, rather than any substantive issue with their findings. UW Madison and their research group focused on this are credible, and they've published their results in journals like Forensic Science International: Reports, Culture, Medicine, and Psychiatry, and Ethnos. They are a perfectly acceptable secondary source. Ideologically driven editing has no place here. Warrenᚋᚐᚊᚔ 08:22, 1 October 2024 (UTC)[reply]
If we're turning this into a conduct discussion forum, I'd say the bigger problem is that you're supporting poor content based on a poor source. I don't think of this as being a common issue with your work, and my good-faith guess is that maybe your involvement in this conduct dispute is putting up some content blinkers. You've repeatedly restored, for example, a wiki-voice claim that a named individual "remained in tukdam for 13 days". That's obviously not appropriate. If there's a systemic problem at FTN, can we pick cleaner examples? Firefangledfeathers (talk / contribs) 12:50, 1 October 2024 (UTC)[reply]
I have no strong opinions on the exact verbiage of the section before you changed it a lot recently. I have strong objections to the removal of the entire section on absurd grounds that the source isn't good. Not once have you actually raised a specific concern with the source other than what amounts to "C'mon, look at it" which several of us have and have seen no particular issue with.
If there's a systemic problem at FTN, can we pick cleaner examples?
I frankly think the issues around the sources being rejected due to what appears to just be personal incredulity is pretty much is the cleanest possible example, here. Warrenᚋᚐᚊᚔ 13:32, 1 October 2024 (UTC)[reply]
This "personal incredulity" mind-reading gambit is tough to take in good faith. WP:REDFLAG is part of WP:V, one of our core policies. Firefangledfeathers (talk / contribs) 14:14, 1 October 2024 (UTC)[reply]
FWIW, while I also don't think that line is worth including:
a) I think the idea that a whole long section should be blanked because of one bad line is obviously absurd.
b) The source in question I also agree seems fine. Notably it does not endorse that line.
Like a lot of FTN content disputes I'm not entirely sure why it's even happening. It feels like the "skeptic" side, huge airquotes, has dug their heels into an aesthetic commitment so hard they haven't even actually bothered to look at the source. Loki (talk) 19:16, 1 October 2024 (UTC)[reply]
The source explicitly endorses that line, saying "Ling Rinpoche remained in the state for 13 days, exhibiting a fresh life-like appearance in the humid subtropical climate of Dharamsala until the thirteenth day when initial decompositional signs appeared." In context, "the state" unambiguously refers to the tukdam state. As for "whole long section should be blanked because of one bad line": what a weird and untrue guess at the motivation for the removal. Which edit summary hinted at anything of the sort? Firefangledfeathers (talk / contribs) 19:27, 1 October 2024 (UTC)[reply]
I think that sentence would benefit from a re-write. For example, consider "This study began in 1995 after a discussion between neuroscientist Richard Davidson and the Dalai Lama about the meditative death of Kyabje Yongzin Ling Rinpoche, who was said to have remained in tukdam for 13 days because his body did not show visible signs of decomposition until then." WhatamIdoing (talk) 20:01, 1 October 2024 (UTC)[reply]
I would go even further with who was said to have remained in tukdam for 13 days because his body was said by monks and other believers to have not shown did not show visible signs of decomposition until then. jps (talk) 14:04, 2 October 2024 (UTC)[reply]
Does the source make that claim, or is that your editorialization? Because when I glanced through it I didn’t see the bifurcation in claims you’re making. I can imagine a whole bunch of environmental variables factoring in but you seem very hung up on a form split between what the source says and what you personally deem credible, and I don’t think it’s reasonable to ask editors to filter papers through your personal incredulity as a standard before editing.
It’s not like the implication in any of these papers is “a specific theology is true!” and in your race to editorialize you’re possibly inventing caveats and conclusions not in the papers in question.
I have zero problem with your suggested edit if that’s actually backed up by the sources. Warrenᚋᚐᚊᚔ 18:06, 2 October 2024 (UTC)[reply]
The source begins the narrative with the phrase 'The Dalai Lama described' and follows that description for a while, so jps's paraphrase would seem to be a fair summary and not editorialization. MrOllie (talk) 18:14, 2 October 2024 (UTC)[reply]
About They are a perfectly acceptable secondary source: Journals aren't primary/secondary/tertiary sources per se; they're publications in which multiple individual primary/secondary/tertiary sources are published.
All first-time reports of scientific research are primary sources for the results of that research. Wikipedia:Secondary does not mean good. An article that provides comments on the research would be a secondary source, even if those comments say something like "Look at this huge waste of research money" or "All the experts we contacted thought this was a huge joke" or "Here's more proof that peer review doesn't indicate importance, and journal editors aren't immune to clickbait fodder", and even if that commentary is in a popular/non-academic publication. WhatamIdoing (talk) 17:48, 1 October 2024 (UTC)[reply]
I echo you in emphasizing that a single research paper is a primary source -- if there's no other research coming out, then I'd be very cautious about mentioning such a paper at all or its conclusions (and especially not summarize them more than they choose to summarize themselves in their own abstract and conclusions sections).
U:jps had an odd comment about the credibility of the UWisc group (with sentiment echoed by others) that included The attempt to argue that there is any legitimate research interest whatsoever into whether there might be measurable signs of this religious belief is belied by the fact that WP:FRIND sources are totally absent discussing this. This seems odd in that one of the issues of wp:Parity is the relative lack of typical RS that challenge fringe claims; so here a typical RS is critically assessing fringe Tukdam claims, yet therefore this becomes in itself a reason for prejudice against the RS's reliability?
I don't see that objective scientific inquiry needs to be defended (even if the investigator has personal biases, which we all do). Nonetheless, as the EEG paper outlines (as have a couple more I've seen investigating similar stuff), investigating this sort of thing raises all sorts of interesting methodological questions in several fields. Usually the conclusions of these sorts of papers is not the most important part. SamuelRiv (talk) 20:18, 2 October 2024 (UTC)[reply]
I think the evaluation of a claim should be contextual and methodological, absolutely, and that's also why the "he's dead, Jim" conclusion is unimpressive to me. To take another example, there are a number of null-result papers published in Journal of Scientific Exploration that would otherwise be used to prove certain wacky ideas "taken seriously" which, y'know, isn't true because even those WP:BLUESKY conclusions don't receive notice. To behave otherwise risks us becoming cherry-pickers. I take WP:REDFLAG to be my lodestar. The idea is that you want multiple serious, independent relevant researchers arguing there is a there there before Wikipedia should be going on and on about that kind of "they take us seriously argument".
Shroudies are another good example of this. The amount of ink spilled about what is obviously a medieval forgery is absurd, but the faithful will point to the ludicrous number of "investigations" that start from square one and apply yet another test to the thing as evidence that science takes them seriously. It doesn't.
jps (talk) 23:07, 2 October 2024 (UTC)[reply]
I feel that this reaction is a degree of defensiveness that is not compatible with building an encyclopedia. Wikipedia goes by the sources and not whether the existence of the sources will cause someone somewhere to believe that they are being taken seriously by the scientific establishment. Like, the thing you are describing is just not a thing that Wikipedia can or should consider at all. Loki (talk) 03:37, 3 October 2024 (UTC)[reply]
We are tasked with deciding whether a source is reliable for the claim it is making. If there are few to no citations that notice a WP:PRIMARY source, we typically do not lean heavily on it. jps (talk) 17:11, 3 October 2024 (UTC)[reply]

Kind of feeling like what you are describing is WP:RGW. PackMecEng (talk) 16:29, 3 October 2024 (UTC)[reply]

Not sure who this is directed towards, but I think this is something of an inversion of my point. The "righting of great wrongs" is typically what I see being pushed by those who are arguing, "hey, this WP:FRINGE idea deserves more consideration." jps (talk) 17:14, 3 October 2024 (UTC)[reply]
It was a reply to Loki, the outdents make it kind of tricky. Sorry about that. PackMecEng (talk) 21:51, 3 October 2024 (UTC)[reply]
Pack's comment sounds fair to me. We see editors in some areas trying to make sure that readers are "protected from" certain ideas. We're happy to invoke NOTCENSORED for (e.g.) sexual content, or whether Santa Claus exists, but we are less inclined to expose readers to POVs that we don't agree with and that we believe should be considered a "scientific fact/falsehood".
In such cases, saying "This idea exists" is interpreted by editors as "This idea deserves more consideration". In this case, you can look at the facts and come up with several responses: "Huh, those people think meditation happens in the heart, so it was stupid of them to test the brain". Or "Look at the stupid research ideas people spend money on". Or "I wonder why they tried to apply medical technology to their spiritual practice". But the worry from the RGW-ish editors is that somebody might read it and say "Wow, finding out whether dead bodies can still meditate must be a worthy scientific endeavor instead of a candidate for the BMJ's Christmas edition. I believe in science, so now I believe in meditation after death!" WhatamIdoing (talk) 17:23, 3 October 2024 (UTC)[reply]
I am not as concerned with reader reaction as I am with the possibility that Wikipedia functions a role in laundering claims that there is scientific endeavor found here. I am hoping to evaluate the worthiness of article text on the basis of WP:NFRINGE. I argue that the proper amount to include for many claims that strain credulity on the basis of a WP:Notability vs. prominence basis is zero. jps (talk) 19:14, 3 October 2024 (UTC)[reply]
I am with the possibility that Wikipedia functions a role in laundering claims that there is scientific endeavor found here
There very clearly is, though. This isn't the only neuroscience group doing work with Buddhist monks, and that doesn't mean that the researchers involved in those research groups are making, laundering, or even agreeing with any theological claims. This isn't a particularly unknown thing among neuroscientists as far as I know, and it speaks a lot more to "interesting brains" than validating any kind of theology. Warrenᚋᚐᚊᚔ 19:58, 3 October 2024 (UTC)[reply]
I think you might want to go down the hall and knock on the doors of a few neuroscientists and ask what if they have heard about performing EEGs on corpses on the basis of tukdam and whether there is a legitimate research question to answer by doing so. I'll do the same. Then we can report back. jps (talk) 20:30, 3 October 2024 (UTC)[reply]
My issue is following the logic. You want to have an article about a fringe topic. By its nature, fringe theories tend not to have quality independent RS that debunk them. (Various reasons for this -- but even those who consider fringe theories in themselves worth their time may decide ignoring them is a good strategy; others feel they should be positively debunked; afaik there is not an objectively "correct" position given basically identical goals.) That said, when such an independent RS comes about, you suggest the RS is unreliable for the sole fact that it investigates a fringe theory. Whether you feel that, ethically or whatever, any scientists should investigate fringe theories ever, is your own thing, but it has and will occasionally happen, and scientists will do it in a certain way, and I don't know how you would expect it to be done differently. And without those occasional RS, the only source of parity (or parody) on fringe topics is from snarky self-qualified skeptic bloggers. SamuelRiv (talk) 17:32, 3 October 2024 (UTC)[reply]
Yes, exactly this. We're obligated to use the WP:BESTSOURCES on a topic, and clearly a study saying "he's dead Jim" is a stronger source than a science blogger snarkily conjecturing "he's dead Jim", regardless of what you feel about the beliefs of the people who did the study or if it was worthwhile to do it in the first place. Loki (talk) 17:41, 3 October 2024 (UTC)[reply]
Just as an aside, remembering one particularly well-written informal review, Andrade and Radhakrishnan 2009 made a point that there are very good theological and philosophical reasons for rejecting or debunking claims of empirically-testable spiritual intervention on Earth. (Indeed, once the spiritual becomes scientifically empirical, it by definition is no longer spiritual.) A number of religious authorities have learned this lesson, as have religious scientists. A faithful Buddhist may (or may not) have every reason than any skeptic to want to see the empirical claims of Tukdam disproven. SamuelRiv (talk) 17:59, 3 October 2024 (UTC)[reply]
Do I want to have an article on a fringe topic? I'm not sure I do? jps (talk) 19:15, 3 October 2024 (UTC)[reply]
I do. I think that providing facts (including facts about opinions, spiritual beliefs, perspectives, and errors) is an important service to the world. I do not subscribe to the belief that all publicity is good publicity or that describing the wide diversity of people's beliefs is promoting fringe subjects. I also don't believe that it's Wikipedia's job decide which beliefs are worthy of being learned about. WhatamIdoing (talk) 20:24, 3 October 2024 (UTC)[reply]
I think we are at slight differences of opinions about where we draw the line for WP:NFRINGE. I am just less of an inclusionist and like to be dragged kicking and screaming over the line to articlespace presentation. jps (talk) 20:31, 3 October 2024 (UTC)[reply]
What's even more odd to me in this whole mess of a discussion is that a lot of the research motivations are clearly independent of the religious or fringe-adjascent claims; it's just a desire for more data on the state of the brain at the moments around death. Couple that with a population eager to probe that specific thing and you have a basis for a fairly ethical approach to a very sticky study subject. Warrenᚋᚐᚊᚔ 20:02, 3 October 2024 (UTC)[reply]
I am not at all convinced that these are the motivations, but I also don't think the motivations ultimately matter. What does matter is the lack of third-party notice. jps (talk) 20:33, 3 October 2024 (UTC)[reply]
It feels like the goalposts keep moving. We can't say this; there's no scientific research. Oh, there's scientific research, but we still can't say this, because we need someone to comment on the research. Oh, there was a television program commenting directly on the research? Well, we still can't say it, because the television program isn't truly independent. Oh, now you've got an article in a reputable daily newspaper analyzing the television program's analysis of the scientific research and that doesn't appear to be written by someone with any personal connections to this subject and which also didn't interview anyone even remotely involved in this? Well, that still won't do, because, um, I'll think of something, but a self-self-published website like Quackwatch would be infinitely preferable to whatever sources actually exist.
This is the sort of thing that makes people wonder whether the ultimate test is "Does the source agree with my personal POV?" WhatamIdoing (talk) 21:09, 3 October 2024 (UTC)[reply]
What is the TV program commenting on the research? jps (talk) 21:43, 3 October 2024 (UTC)[reply]
A documentary called Tukdam: Point of Death, apparently. The newspaper describes it as "The strangest programme of this week — or of any week for a long time" and provided some analytical commentary (e.g., comparisons to the popular Christian tradition of ascribing saintly values to physical Incorruptibility). WhatamIdoing (talk) 23:22, 3 October 2024 (UTC)[reply]
I have been trying to watch this documentary, but have failed. Maybe because it only appeared on Irish TV? Unclear. If you know how I can watch it, I would be grateful. jps (talk) 13:09, 4 October 2024 (UTC)[reply]
I haven't attempted to watch the documentary. I think the newspaper article provides enough information about it to give me an idea of its contents. WhatamIdoing (talk) 20:34, 4 October 2024 (UTC)[reply]
It is definitely true that one of the biggest complaints of WP:PROFRINGE is that Wikipedians dismiss their proposed sourcing as unreliable. To wit, I don't think I've seen much in the way of reliable sourcing that post-death brain activity is a hot topic except among those religious believers who, as part of their faith, believe that this is a possibility. jps (talk) 21:47, 3 October 2024 (UTC)[reply]
Reliability isn't about whether it's "a hot topic". Reliability is whether we trust (aka are willing to "rely on") a source for a given statement. Whether something's a hot topic is a matter for NPOV rather than reliability.
We see this all the time in medical topics. A loussy primary source actually is reliable for a statement like "In YYYY, one study found that pouring gasoline on cancer cells reliably killed them". The problem is that the space in an article should be focused on less stupid forms of cancer research (because even if Wikipedia has an infinite supply of pixels, reader attention does not have a correspondingly infinite number of minutes to spend on reading the article). In this case, if you put "tukdam" into your favorite news search engine, basically all the sources are trying to explain whether it can be proven to exist via modern technology. Ergo it is DUE for the article mention something about this subject. WhatamIdoing (talk) 23:27, 3 October 2024 (UTC)[reply]
I don't think the model of "putting tukdam in your favorite search engine" to test for whether a perspective on a topic deserves inclusion is valid. I think WP:FRIND asks us to consider broader impacts. jps (talk) 01:25, 4 October 2024 (UTC)[reply]
Sure: You should put "tukdam" in your favorite search engine and see which independent sources you can find. If your favorite search engine happens to be news.google.com, you should find a couple dozen sources that were not written by any of the authors of the EEG study. WhatamIdoing (talk) 02:43, 4 October 2024 (UTC)[reply]
Here is all that I find when I do that:
  • Big Think starts out with "It’s definitely happening, and it’s definitely weird. After the apparent death of some monks, their bodies remain in a meditating position without decaying for an extraordinary length of time, often as long as two or three weeks." [17]
  • The only other article is from mindmatters.ai which is a publication by the Discovery Institute(!) I beg your forgiveness that I stop right there.
So one article that starts out pretty miserably is all that I'm seeing, but maybe you're getting better results than I.
jps (talk) 13:08, 4 October 2024 (UTC)[reply]

Back to the core concern

So it feels like, unintentionally, the exact situation I’m griping about has played out at full volume here. A subset of FTN regulars has shown up first attempting to shut down any discussion (I can’t help but notice I’ve been told I’ve been “warned” for citing a source someone here didn’t like, and told I’m being WP:PROFRINGE for the same) and refusing to avoid strawmanning, expounded on personal extra-policy values of “not accidentally giving a topic credibility” when the entire argument around that is something failing a vibe check (rather than anything to do with WP:RS) and in general just engaging in WP:RGW behaviour.

The editorial standards several users here advocate for are patently absurd. We are not qualified to evaluate if peer-reviewed publications have subtle implicit biases that poison the data in a way that the referees, with their actual qualifications, at various journals weren’t able to spot. We are being told that any scientific investigation into religious claims must be treated as fringe, even when the results are exactly what would be expected and make no extraordinary claims. We are meant to take it on face value that this entire endeavour is an attempt to legitimize a religion using science, and we must ignore specific and reasonable claims as to why scientists might actually be interested in this and must instead condemn academics for even daring to look at this.

This isn’t policy, this isn’t how Wikipedia works, and this is actively worsening articles. Editors in here have made it abundantly clear that they’re explicitly and openly not engaging with these topics in good faith, which goes back to my entire point posting this here where active derision of topics relating to religions seems to be the only acceptable approach to much of FTN. Given that this has come up with multiple editors, it does seem like there’s possibly a culture problem at FTN that warrants addressing and possibly greater oversight.

I’ve seen this come up time and time again when the actual understanding of a topic differs from the popular understanding of FTN. We saw it at panspermia, where a segment of FTN decided that plain as day sources right in front of them were secondary to their personal understanding of a topic. We’ve seen it at the Cunning folk and Mormonism thread, where editors viewed “cunning folk” as an attempt to whitewash magic and no amount of “this is the term used in academia” seemed to counter those laundering concerns. We see it here again, where the personal incredulity of editors who cannot begin to believe that neuroscientists may have a secular, academic interest in a specific type of brain activity. I can’t help but notice how much of the arguments here hinge on “this research group is taking something seriously that they shouldn’t be” without a single actual substantive argument to back that up. We’re being expected to take those arguments as serious and meaningful when they’re merely an opinion of an editor. In all cases WP:RS instantly caves to WP:IDONTLIKEIT, which is made pretty explicitly with

Do I want to have an article on a fringe topic? I'm not sure I do?

This isn’t improving Wikipedia. It’s making certain topics a nightmare to edit on because as it stands FTN cannot be wrong and FTN users are never wrong in their understanding of fringe. Evidence of a misunderstand is always just another WP:PROFRINGE user trying to concern-troll away good articles with PROFRINGE content and anyone who disagrees is, well, see the first large reply this post elicited.

This is, frankly, exhausting. Warrenᚋᚐᚊᚔ 10:26, 4 October 2024 (UTC)[reply]

To me, it seems pretty arrogant to declare that a slightly contrary WikiPhilosophy of your fellow Wikipedians "isn't improving Wikipedia". This is the kind of rhetoric I see in radical inclusionist spaces often, and it strikes me as inflammatory at best and toxic at worst, which feels like a bit of WP:KETTLE irony considering your complaint is largely that you (or those who follow closer to your editing philosophy) are feeling put upon. I should hope that people advocate for approaches because they think they are right. Differences of opinion are likely to occur, and the solution doesn't have to be thesis/antithesis. If you think that you aren't being heard, then maybe consider the massive length of this discussion. jps (talk) 13:15, 4 October 2024 (UTC)[reply]
I think 90% of this is just common content dispute, with the added complication that Warren keeps describing the policy-based objections to his proposed content as IDONTLIKEIT or "merely an opinion" or lacking in substance. That's pretty typical as well, though it is exhausting. If our goal is to get back to the core concern, which I understand to be allegations of a systemic conduct problem at FTN, I'd suggest that identifying examples where Warren isn't personally part of the dispute might get us some distance from the common content disputes. Firefangledfeathers (talk / contribs) 13:24, 4 October 2024 (UTC)[reply]
the policy-based objections to his proposed content—When the purportedly policy-based objection in a particular case was 'the sources were created by Buddhists' and ignores all other context (that the research was conducted through a research center at a secular university, that the reported result was the rather normal 'the dead monk is dead'), and when the general concern is said to be with patterns of objections that on examination boil down to 'the source/author can be connected to religion', I am hard-pressed to see the substance or policy basis of the objection. Hydrangeans (she/her | talk | edits) 06:14, 6 October 2024 (UTC)[reply]
You read all the edit summaries and discussion here and at the talk page, and you found them all to say "created by Buddhists"? Firefangledfeathers (talk / contribs) 11:55, 6 October 2024 (UTC)[reply]
Edit summaries at Tukdam don't seem to haven't gotten much beyond claims like "get better sources" and "This is all WP:FRINGE nonsense claims. Unless non-believers find it worthy of notice, it is not worthy" (the nonsense claim that dead brains don't give off brain activity?). And in this discussion, comments like describing the author as "this guy from UWisc is a devotee of Tibetan Buddhist approaches to meditation" and must therefore be unsuitably "influenced by a blinkered religious devotion", or saying that he (JPS) is protecting the encyclopedia from hyperbolic and farcical religious claims (the unblinkered, religiously devoted act of saying that... dead brains gave off no brain activity?) For where JPS hasn't hammered at the religious connections of an author, I think Loki has described the situation well in saying JPS seems to say that the existence of the sources will cause someone somewhere to believe that they are being taken seriously and that this, somehow, makes the sources unusable for our purposes on Wikipedia. To quote another editor from a recent discussion, JPS continues to characterize situations as one click more severe than is necessary; the source's tone being more generous to Buddhism than an individual Wikipedia editor might feel becomes a reason to consider the whole enterprise, seculary university and all, as untrustworthy, and this despite our community having a guideline that reminds us that a reliable source can be biased; we just try not to reproduce the bias.
Add to that the expressions of pride in being uncooperative with other editors (preferring "to be dragged kicking and screaming", professing to "enjoy having arguments", and taking on a brusque, short tone that doesn't strike me as treating other editors as respected colleagues rather than as ideological enemies), an attitude of behavior that's explicitly contrary to Wikipedia's expectation that we be reasonably cooperative, and Warrenmck's exhaustion seems pretty understandable. All this time and energy gets put into trying to assuage JPS's concern (except JPS is not interested in being assuaged; JPS explicitly would apparently rather have arguments and be dragged kicking and screaming) instead of getting put into doing as Loki brought up: trimming the content to be its best and most relevant, neutral version. Instead, by repeatedly pushing total exclusion of even the notion that anyone checked for brain activity (and found none!), we instead remain in the Discuss portion of the suggested WP:BRD cycle. Hydrangeans (she/her | talk | edits) 15:40, 6 October 2024 (UTC)[reply]
the source's tone being more generous to Buddhism than an individual Wikipedia editor might feel
It’s worth pointing out this sort of conciliatory tone is pretty common when working with minority ethnic/faith groups. It’s a bad look for researchers to get permission to study a topic within a minority community and turn around and (from the perspective of the community you’re working in) insulting them. “Yeah, their religious belief is wrong” isn’t exactly a shining example of research ethics.
Also I can think of at least one good research paper in geosciences which studied the mythology of Native Hawaiians to fascinating effect. Warrenᚋᚐᚊᚔ 23:54, 6 October 2024 (UTC)[reply]
More like the conciliatory tone is pretty common for researchers in general. Researchers tend not only to take a neutral tone, but I've often seen that if they're in a paper that's going to objectively demonstrate not-X, they will take a tone that is generous and often deferent to the position of X (among other reasons to indicate that they investigated any alternative hypotheses). (My favorite example of this is from papers on dog and cat cognition, which the authors typically introduce with something along the lines of 'It is scientifically obvious that cats are reproduction machines motivated solely by food, with never any objective evidence of emotion', and the paper proceeds to prove that cats do love their owners. 'Further research is recommended.') SamuelRiv (talk) 03:01, 7 October 2024 (UTC)[reply]
More like the conciliatory tone is pretty common for researchers in general
oh, for sure. Just when it comes to minority groups, especially those who have faced substantial hardship, that tone goes into overdrive. When it comes to scientific investigations of spiritual practices, especially when done in cooperation with monastic/preistly/ordained communities it’s best not to make them feel that working with you is directly undermining their own faith/beliefs/identity (etc.) Warrenᚋᚐᚊᚔ 03:29, 7 October 2024 (UTC)[reply]
Calling for better sources and reverting because content violates FRINGE are both good moves. The sourcing was poor, and FRINGE was being violated. JPS clearly articulated at the FTN discussion and at the talk page at least one way in which the content violated FRINGE, and it had nothing to do with anyone being a believer. Warren reverted to restore the content saying that JPS's reason was just "not liking the research group". I raised REDFLAG concerns, which Warren dismissed as "personal incredulity". I'm not saying anyone's conduct here was perfect, but I have an extremely difficult time seeing W's action as clearing the "reasonably cooperative" bar you mention. Incidentally, "we instead remain in the Discuss portion of the suggested WP:BRD cycle" isn't true for the "checked for brain activity (and found none!)" part of the disputed content. It's been sitting in the article for a few days now with at least rough talk page consensus. Firefangledfeathers (talk / contribs) 01:37, 7 October 2024 (UTC)[reply]
My current opinion is that WP:Fringe itself may be better placed as an explanatory essay, with original P&G sections woven back into their core P&G: Parity under NPOV/DUE, NFringe under Notability, etc.. The role of FTN is overlapped by existing noticeboards, which handle fringe theories and editors regularly without much issue. As a cultural matter, it may be that the referral of editors to FTN, the labelling of their content as "fringe" as opposed to a violation of general policy, itself invites the long often-heated content debates that seem to most often characterize the board.
Closing a noticeboard is a big step, (as would be rearranging a P&G page, but that's the lesser one), and I'd like to spend more time watching there before making a definitive judgement on my own part, but I do see the problems identified, and this is a possible way to try to address them. SamuelRiv (talk) 13:39, 4 October 2024 (UTC)[reply]
I don't know if closing FTN would actually help. When a group of editors feels like their interests are served by working together, then it's pretty difficult to get them to stop. We could close FTN and discover that Wikipedia:WikiProject Skepticism becomes a lot busier, or that coordination is happening off wiki.
It might be nice to encourage the FTN regulars to put NPOVN on their watchlists, though. NPOVN can always benefit from a few extra eyes. WhatamIdoing (talk) 20:32, 4 October 2024 (UTC)[reply]
At that point it would be an ARBCOM case and possibly get them separated from fringe topics in general. PackMecEng (talk) 21:11, 4 October 2024 (UTC)[reply]
I don't think that would be a good outcome. WhatamIdoing (talk) 22:05, 4 October 2024 (UTC)[reply]
What I find strange is that this stems from the Tukdam article saying in wikivoice that individuals where still alive after they had died. No-one should be disrespecting religious beliefs, but the context for such things should be that they are beliefs.
If editors have been making uncivil or disrespectful remarks that should be rectified, editors shouldn't interject their own opinions on other people's beliefs it's not helpful or constructive. Equally editors shouldn't be stating beliefs as if they were factually true. -- LCU ActivelyDisinterested «@» °∆t° 19:54, 5 October 2024 (UTC)[reply]
To be clear, at no point have I objected to removing that line. The only thing I objected to was a total section blanking. Me undoing the blanking wasn't a tacit endorsement of the whole text that was there before and I agree that religious beliefs shouldn't be presented in wikivoice and that line was inappropriate there. Warrenᚋᚐᚊᚔ 20:32, 5 October 2024 (UTC)[reply]
Editors restoring content are endorsing it, by restoring it you are taking responsibility for it. Any section with that in was inappropriate, if it had been restored after improvements that would have been another matter. -- LCU ActivelyDisinterested «@» °∆t° 20:39, 5 October 2024 (UTC)[reply]
I reverted a section blanking and immediately took it to the talk page as clearly it was contentious. That's not out of line. Warrenᚋᚐᚊᚔ 20:50, 5 October 2024 (UTC)[reply]
True but by reverting it you were taking responsibility for it, removing text isn't something that necessary needs reverting while consensus is found. -- LCU ActivelyDisinterested «@» °∆t° 21:21, 5 October 2024 (UTC)[reply]
No. The section was blanked with "removing WP:FRINGE claims" as the sole edit comment. It is very clear that the entire section isn't just fringe claims and it's very clear that the user in question who blanked it has a significant ideological axe to grind they seem unable to leave out of their editing. Here's the diff. Considering how very blatant the bigotry motivating these edits has been, a revert and the comment on the talk page was appropriate. Re-reading this to pull the diff I actually think an ANI would have been appropriate a while ago for some of the open bigotry and how absurd the WP:OWN situation has gotten but by now I think it'd just be rehashing this argument and go nowhere. Warrenᚋᚐᚊᚔ 21:55, 5 October 2024 (UTC)[reply]
I agree that ANI would not be a desirable forum right now. WhatamIdoing (talk) 22:36, 5 October 2024 (UTC)[reply]
I still think it may be warranted, but I’m holding off. We have here two issues:
1) a possible systemic issue with FTN and religious topics
2) an editor who is openly editing with prejudice as a base, flinging around accusations, and inventing new site policies to get their way in a content dispute
at this point this whole thing feels… weird. One editor is blanking sections they ideologically disagree with, attacking a source for the source’s religion which has nothing to do with the results, going around “warning” editors for citing sources they don’t like, and just moving goalposts over and over to create a specific interpretation of policy that by all appearances is designed to arrive at a specific foregone conclusion.
But the discussion has become “Why didn’t you remove that one line when you restored the article? You restored bad faith page blanking so now you’re responsible for it.” and broader discussions around the article. The problem is so much time has been spent discussing the behaviour of one (or two, to include me in fairness) editors that the entire point has either been lost or poisoned, because whatever issue with FTN I was bringing up here never got to this extreme with “no they’ve got religion so we can’t trust them” as a basis for editing that people mostly just seem fine glossing over?
If I’m the wrong here I’ll own up to it, but “I don’t see a reliable source for the claim that there’s academic interest in this topic” in response to a research group and a half dozen peer reviewed papers is cut and dry not engaging in good faith. Warrenᚋᚐᚊᚔ 00:43, 6 October 2024 (UTC)[reply]
I am mystified how you think it is a problem to WP:REDFLAG claims that people meditate after they are dead. jps (talk) 18:53, 6 October 2024 (UTC)[reply]
I suspect that other editors are mystified how you think it is a problem to say that these REDFLAG claims have been debunked. Compare:
  • Homeopathy repeatedly says there's scientific evidence against it.
  • Hoxsey Therapy says there's scientific evidence against it.
  • Faith healing says there's scientific evidence against it.
  • But Tukdam – Whoa, we can't say there's scientific evidence against that. That might make people think this religious belief was a valid subject of scientific inquiry!
I know you support the first three. What's so wildly different about someone claiming that a special person can channel divine powers vs someone claiming that an equally special person can meditate after their physical death? WhatamIdoing (talk) 19:51, 6 October 2024 (UTC)[reply]
One very small part of what jps removed was about scientific evidence against tukdam, sort of. That brief bit was outweighed by caveats about the research barriers, wikivoice claims that tukdam is real, and promotional content about the research team. The article is better off now that we briefly summarize a published study, but removing the problematic content was an incremental improvement over the status quo ante. Any supporter of the good bits of the content could have partially restored the good bits, just as jps could have partially removed the bad bits. Firefangledfeathers (talk / contribs) 01:44, 7 October 2024 (UTC)[reply]
I don't know about that.  Comments from jps say all of this content is an attempt to argue that there is any legitimate research interest whatsoever and an attempt to claim there is legitimate research interest in Tukdam within the context of neuroscience.  He objects to providing information that someone could use as a "they take us seriously argument".  He does not want Wikipedia to say anything that supports any claims that there is scientific endeavor found here.  He does not believe that there is a legitimate research question to answer, so he does not want Wikipedia to report that people have done the research.  He opposes having Wikipedia acknowledge the verifiable fact that these studies were done, regardless of their outcomes. WhatamIdoing (talk) 03:20, 7 October 2024 (UTC)[reply]
The disputed content started with "Western scientific interest has grown", cited to the self-published website of the research group in question, so many of those concerns are well-founded. Firefangledfeathers (talk / contribs) 04:27, 7 October 2024 (UTC)[reply]
It was my impression that except in the case of violations of copyright or BLP, leaving a page in the status quo ante state is considered reasonable during content disputes. Hydrangeans (she/her | talk | edits) 06:09, 6 October 2024 (UTC)[reply]

+1 to merging WP:FTN with WP:NPOVN and WP:FRINGE with WP:NPOV. Levivich (talk) 15:41, 4 October 2024 (UTC)[reply]

At this point I think it's not a bad call, and I'm a regular at FTN. There's too much of a power user concern, and it either needs to not be a full on noticeboard or it needs to be diluted with people who share a goal of improving wikipedia and addressing WP:NPOV concerns but who can do so without a personal religious views very explicitly dictating their editing. Its function is better served as a noticeboard but the commitment to Wikipedia policies is not as strict as it should be for a noticeboard. Warrenᚋᚐᚊᚔ 18:33, 5 October 2024 (UTC)[reply]
FTN is primarily concerned with Pseudo-scholarship rather than religion. WhatamIdoing (talk) 19:26, 5 October 2024 (UTC)[reply]
But what's being done here is exclusively slandering scholarship as pseudo-scholarship, purely on the basis of the topic and the faith of the author, despite results which are 0% unexpected or WP:PROFRINGE. @SamuelRiv summarized how I see this whole situation best:
You want to have an article about a fringe topic. By its nature, fringe theories tend not to have quality independent RS that debunk them. [...] That said, when such an independent RS comes about, you suggest the RS is unreliable for the sole fact that it investigates a fringe theory.
I think they're meant to be concerned with Pseudo-scholarship, but what we're seeing here is a: at times a majority of FTN is about religious pages and b: FTN is inventing their own conception of pseudo-scholarship and declaring perfectly reasonable academics guilty of it.
See also: the whole panspermia thing
I think there's a lot of "FTN is ____" in here which is a nice ideal but doesn't actually pan out to the experience of FTN. Note I'm not calling for getting rid of it, I just think that FTN by its very nature attracts people who are more on the militant side of skeptic in a way that gets disruptive. I've left it pretty well alone but scroll up and look at the "warning" I received for citing Frontier, then go look at FTN at the context of the "warning" I received coupled with how many times here I've been accused of being WP:PROFRINGE for not damnatio memoriae-ing a peer-reviewed source and tell me if this behaviour is compatible with the norms of Wikipedia or building a better encyclopedia. Warrenᚋᚐᚊᚔ 19:50, 5 October 2024 (UTC)[reply]
Warrenmck, i can't help but recall this thread from more than a year ago. I could not care less whether otherkin are viewed as a religion or not, but am just hanging out to find sources for a hard-working group who make a positive impact on the project. If you are at such a hair trigger and on such a mission to get others to conform to your worldview then no wonder you are finding it "exhausting".
Looking at some of the threads you've pointed to i would probably agree that Stapley shouldn't be dismissed so readily and to take a closer look at the content. But i would probably say that content does not justify keeping the current title and it should probably move to 'folk magic' or similar. I disagree with "the regulars" at FTN sometimes, no big deal.
As far as getting Egon Spengler and his UW Madison group's research into the article, well, there is a think tank behind it and it is in partnership with the Dalai Lama. So even tho a bunch of neuroscientists probably think he's a nice guy and all reason to be cautious. A lot of your arguments seem to come down to inclusion simply because something has been published and insistence on that basis. Maybe try something different because that tactic is one seen probably 2-3 times a day by "the regulars". I shudder to think what some of the content would look like if there wasn't opposition to that view. The test here for such speculative (admittedly so in the papers) is whether or not other researchers take notice. That's pretty objective and from what i've seen mostly applied across the board on a wide variety of topics by "the regulars", but of course no one gets everything right all the time.fiveby(zero) 04:32, 6 October 2024 (UTC)[reply]
And I’ve also basically been working on rewriting the entire Otherkin article in that time, feel free to check its edit history. Like I said, I’m a regular at FTN and I try tackling a lot of the faith-centric stuff that comes up at FTN because I’ve got a bit of a formal background in religious studies. I may as well edit in a broad area I know, though I do mostly stay out of Mormonism threads since I don’t know it as well.
I’m not just complaining, I’m actively putting in the work to improve these articles. Let me be a little more clear about my frustration with this: I think FTN has one tool, a hammer, and has decided that they’re collective experts on identifying nails. It can simply result in worse quality articles, the reason I’ve brought up the Panspermia example here is it’s a very cut and dry non-fringe case of FTN just deciding that evidence cannot be allowed to counter their understanding.
well, there is a think tank behind it and it is in partnership with the Dalai Lama. So even tho a bunch of neuroscientists probably think he's a nice guy and all reason to be cautious.
I agree! But what’s happening here isn’t caution, it’s bigotry. It’s very clearly bigotry. I don’t see the benefit to sanitizing accusations of bigotry, because “these aren’t academics, they’re religious believers and we should ignore their output” is bigotry.
FTN is great with quack medicine, UFOs, etc. but the second the Venn diagram overlaps with spirituality or faith there’s this sort of gleeful attitude of taking the religious down a peg, and not just when it comes to editors but apparently authors of research papers. We have an editor in here accusing authors, baselessly, of academic impropriety, using that accusation to edit articles on the basis of open bigotry, and and I don’t know why we’re tolerating that. We’ve seen recent topic bans for that exact behaviour recently.
A lot of your arguments seem to come down to inclusion simply because something has been published and insistence on that basis.
You do realize the source being argued about here rejects Tukdam, yes? It’s at no level pro-fringe, an editor just doesn’t like the religion of the author and is just being disruptive on that basis. Warrenᚋᚐᚊᚔ 12:36, 6 October 2024 (UTC)[reply]
Very clearly bigotry? That is rather strong don't you think? Wikipedia's purpose concerns readers, information, and knowledge. I take these arguments expressed in opposition to your to be just that: views concerning readers, information, and knowledge; and how WP should work towards achieving that purpose. I have certain opinions concerning these matters which generate a negative reaction to, for instance, new-agers, postmodernists, evolutionary psychologists, and Canadians.
Why should i care if a source rejects Tukdam? Applying that standard i would feel would lack objectivity and be a little dishonest. I try to be objective and honest but am probably as full of shit as the next editor.
I'm sure "the regulars" would benefit from hearing about and adapting to my views on how they should edit, but somehow image that preaching to them about it would likely be an unproductive use of everyone's time. fiveby(zero) 16:08, 6 October 2024 (UTC)[reply]
That is rather strong don't you think?: What seems 'strong' is JPS saying things like this guy from UWisc is a devotee of Tibetan Buddhist approaches to meditation and is influenced by a blinkered religious devotion, or that academics are actually not academics because they are instead religious believers. I'm hard pressed to see how this doesn't amount to claiming a Buddhist, regardless of academic training or posting or employment, can't or shouldn't be considered an academic. Hydrangeans (she/her | talk | edits) 16:18, 6 October 2024 (UTC)[reply]
Buddhists make great academics up to the point they argue in favor of dogmatic religious positions in ways that WP:REDFLAG. Arguing that Tukdam is a physical or biological state is a common position of a very particular set of religious believers and, to my knowledge, exactly one American academic group housed at a secular institution is led by such a religious believer. To be clear, I find it admirable that he is open about his belief in contrast to the mess that we are in when trying to consider Ian Stevenson's undercover connections to theosophy. By the way, there is another research group in St. Petersburg, Russia -- but I haven't figured out what they are all about as the sourcing for their stuff is very obscure. jps (talk) 19:04, 6 October 2024 (UTC)[reply]
Why should i care if a source rejects Tukdam?
Because that’s the sourcing standard we actively want on potentially fringe topics? This is the only instance I can think of with FTN actively calling for the removal of evidence against a fringe stance. Warrenᚋᚐᚊᚔ 16:31, 6 October 2024 (UTC)[reply]
You haven't been around enough, then. We have removed loving debunkings (and accounts) of lots of extreme fringe positions on the basis of WP:NFRINGE. Just off the top of my head, editors gutted the article on modern geocentrism and replaced it with an economic redirect. jps (talk) 18:58, 6 October 2024 (UTC)[reply]
This wasn’t a debunking paper. There were perfectly valid secular motivations. That you don’t accept them as truthful is a personal thing and not relevant to Wikipedia. Warrenᚋᚐᚊᚔ 20:22, 6 October 2024 (UTC)[reply]
You said, This is the only instance I can think of with FTN actively calling for the removal of evidence against a fringe stance. I gave another instance. This is not at all personal for me. Please stop insisting otherwise. jps (talk) 19:52, 7 October 2024 (UTC)[reply]
Fair enough on the example, but WP:AGF would be gaslighting myself here, at this point. You’ve made it excruciating clear you’ve got a serious prejudice here and you’re using it to inform your editing and I’m afraid I’m tired of pretending otherwise. As other editors have pointed out, it seems like you’re engaging in WP:WGR and accusing academics of impropriety on the basis of their religion in they absence of any actual evidence and constant WP:IDIDNTHEARTHAT repeatedly in the face of secular interest in this topic.
If you can’t maintain WP:NPOV on these topics you can’t demand other editors treat your POV as neutral in the face of very direct and explicit claims from you to the contrary, and I’m far from the only person interpreting your statements as bigotry. I’m happy enough to just not engage with you at all if you’d prefer, but I’m done pretending there’s been a fruitful endeavour here (seriously, how many times have you directly accused me of being WP:PROFRINGE now? Or playing admin and “warning” me for citing a source you didn’t like?) or that this hasn’t just been you refusing to hear what people are saying about your behaviour here and pretending it’s just just me with an issue. Warrenᚋᚐᚊᚔ 21:07, 7 October 2024 (UTC)[reply]
From WP:AGF: "Assuming good faith (AGF) means assuming that people are not deliberately trying to hurt Wikipedia, even when their actions are harmful."
This is measured according to their own (probably wrong) idea of what would help Wikipedia. That means that if an editor believes (however wrongly) that applying a religious litmus test to sources would help Wikipedia, and so they apply such a test, then that editor is acting in good faith. (It does not matter whether the test is pro- or anti-religious.) You might call it "screwing up in good faith", but it's still good faith. Good-faith actions can be harmful.
The opposite of "acting in good faith" is "deliberately screwing up for the actual, direct purpose of hurting Wikipedia". The opposite is not "holds POVs that I find reprehensible" or "espouses views that, if expressed during a job interview, would constitute discrimination against a protected class in my country". That latter point is for Wikipedia:Civility, not for AGF. WhatamIdoing (talk) 21:32, 7 October 2024 (UTC)[reply]
One of FTN’s favourite pastimes is throwing AGF to the wind and openly explicitly running away editors who engage in ideologically driven fringe editing. Yeah, at some point it’s possible to just lose sight of being able to see how someone is viewing their own behaviour, sincerely, as helping build an encyclopedia. I’m only human.
The fact that an admin is cheerleading this bigotry to an extent is appalling, in my time here I’ve come to expect much better from Wikipedia. Maybe I’m just wrong here but I’ve firmly hit a brick wall here and should probably disengage and take a wikibreak. Warrenᚋᚐᚊᚔ 21:48, 7 October 2024 (UTC)[reply]
I don't think that's precisely correct. FTN probably does run some editors off. (I've run a couple off myself; discouraging would-be contributors who are net harmful to Wikipedia is not an inherently bad thing.) I don't think FTN is known for saying that these editors intend to be harmful; instead, they're known for saying that editors actually are harmful. AGF only requires us to acknowledge that most harm is a misguided attempt to help.
Compliance with AGF means "I reverted that because it's wrong" or "That's not appropriate content for Wikipedia" instead of starting it with "You intentionally vandalized Wikipedia on purpose!" WhatamIdoing (talk) 03:07, 8 October 2024 (UTC)[reply]
Indeed, bad faith is a very rare problem on Wikipedia. In the context of FRINGE, far more harmful would be (say) a true believer, desperate that the world should be exposed through Wikipedia to their discovery that energy can be derived from a perpetual motion machine. Bon courage (talk) 04:30, 8 October 2024 (UTC)[reply]
I wouldn't describe bad faith as very rare; if that were true, then Cluebot would be out of a job and Wikipedia:Administrator intervention against vandalism would be a very boring page. But I do think that it's very rare among established editors. WhatamIdoing (talk) 04:45, 8 October 2024 (UTC)[reply]

I see a lot of "FTN" being used as a collective noun, as in "one of FTN's favourite pastimes is throwing AGF to the wind". As someone who sometimes uses that noticeboard, I guess that's directed at me, too? Because otherwise why not specify who you're talking about? And if you're talking about one or more specific people, that's a matter for ANI, not VPP. Almost 2500 people have edited that page, with nearly 1200 watchers. There are some heavy users, but the top 10 editors have only made about a quarter of all edits.
At the end of the day, there's gray area where people may disagree whether something deals with purely theological beliefs or whether it touches on something empirical/falsifiable/scientific. If someone is repeatedly bringing topics to FTN that fall squarely on the theological side, beyond the gray area, then deal with that person. I could be wrong, but I just don't see a consensus to get rid of WP:FRINGE or WP:FTN happening any time soon. Nonetheless, a concrete proposal would be preferable to repeated accusations directed at a large group of contributors, especially when the closest thing to evidence has concerned just a couple of them. — Rhododendrites talk \\ 22:23, 7 October 2024 (UTC)[reply]

I agree this should have been an ANI. As I said above, what I came here to raise has never gotten to the extreme it has in this instance, and that’s derailed any fruitful discussion of wider systematic issues.
We both know well enough there’s a cadre of regulars, but the situation in the case that’s come up here has basically removed all ability to look at a wider issue with nuance, though the behaviour of some of the other regulars in here did help make that case a bit. After this situation I’m now of the opinion that FTN should be merged with WP:NPOVN. Warrenᚋᚐᚊᚔ 22:35, 7 October 2024 (UTC)[reply]
It's a recognizable tactic to attack a personified "FTN" as a proxy for this OP's perceived enemies. Textbook WP:ASPERSIONS. So yeah, this may be better at ANI but not for the reason the OP thinks. This quixotic campaign has been going on for too long across too many areas to be ignorable for much longer. Bon courage (talk) 04:06, 8 October 2024 (UTC)[reply]
Just ANI me if you sincerely believe that, since you’re just teasing threats of it anyways. If my behaviour is out of line here let’s evaluate it and if sanctions are warranted they’re warranted. That’s sincere, I know my utter exasperation with you and jps hasn’t lead to my finest edits. You’ve been nothing but openly hostile and dismissive from your first reply here and your insistence that I’m on some kind of quixotic crusade falls flat in the face of me not being the only one seeing the problem here. Warrenᚋᚐᚊᚔ 05:03, 8 October 2024 (UTC)[reply]
I have no intention to "ANI you", but might contribute if you end up there. Nobody else is seeing "the problem" here because there is no "the problem" stated, just a vague meta-complaint about "FTN" (initially framed as a question about religion and scope) that has valency for a small number of other users' various stances. What your basic complaint seems to boil down to is that one or two editors disagree with you on various points and have the temerity to argue their case, perhaps forcefully! There is a fairly broad spectrum of approaches to editing Wikipedia you know, and it is really not an issue if some editors fall outside the narrow band other editors prefer so long as they remain within the broad spectrum of the community as a whole. Bon courage (talk) 05:25, 8 October 2024 (UTC)[reply]
I guess I'm nobody. Hydrangeans (she/her | talk | edits) 05:26, 8 October 2024 (UTC)[reply]
No, you're one of the editors who's bound your own take onto the meta-complaint. Hence your statement of "the issue" is different to anything the OP has stated. Bon courage (talk) 05:35, 8 October 2024 (UTC)[reply]
Since Warrenmck said We cannot just decide that the religion of an author is basis for us ignoring the fact that they're publishing in serious journals when research scientists with an American university, I don't see how I'm as far off the mark of anything the OP has stated you claim. Hydrangeans (she/her | talk | edits) 05:48, 8 October 2024 (UTC)[reply]
A problematic campaign has gone on for too long across too many areas, but it's not Warrenmck's. The troubling campaign is the effort by a small number of editors to decide whether or not to cite sources by applying religious tests to the authors. Moving into the realm of the hypothetical, it could be right to not cite X source; it could be right to leave out Y content; but it isn't right to do so for the reason that Z credentialed scholar operating in an academic setting is [insert personal attribute, e. g. a certain race, religion, gender, nationality, etc.]. Hydrangeans (she/her | talk | edits) 05:26, 8 October 2024 (UTC)[reply]
Classic WP:ASPERSIONS ("a situation where an editor accuses another editor or a group of editors of misbehavior without evidence"). It's hard to comment without evidence but it's not at all unusual for sources to be disqualified or regarded with suspicion on Wikipedia because of their authors' record, context, and stated beliefs (e.g. certain researchers for Morgellons, Chinese research into TCM and Russian neuroscience in general). Is there some kind of religious exemption? Bon courage (talk) 05:32, 8 October 2024 (UTC)[reply]
They are not 'classic aspersions'. You have not included in consideration quotations provided elsewhere in this thread that constitute evidence and posts that explain the evidence.
An author's context includes things like academic training and university posting, and members of the community seemed to arrive at a relatively strong consensus in an ANI thread from this year that considering a relevantly-trained and university-posted author uncitable for [topics related to X religion] solely because of being an adherent of [X religion] was disruptive to the point of being a reason to topic-ban an editor who applied that train of thought to Islam, removing and objecting to citations of university-press-published content about Islam solely because the content was written by Muslims. I think it'd be safe to guess that Warrenmck would agree with me that we're not lining up to defend a proselytizing or devotional publisher like Chick Tracts; the goal isn't to say that no scrutiny should be applied to books printed by "Convert People to X Religion Press". Rather, the concern is with saying that academics don't count as academics if they have a religious background, as in the example It's a bit misleading to claim it's been studied by "western academics". It's actually been studied by religious believers, when the religious believers were also trained, credentialed, and posted at a research center of a secular state-run university. I wouldn't consider that a "religious exemption" to the necessary consideration of record and context so much as "it seems bigoted to say Muslims can't be qualified, trained, credentialed, and trusted authors on something to do with Islam even when they have academic postings at universities or that Buddhists can't be qualified, trained, credentialed, and trusted authors on something to do with Buddhism even when they have academic postings at universities". Hydrangeans (she/her | talk | edits) 06:07, 8 October 2024 (UTC)[reply]
jps makes an interesting point. Referring to religious researchers into a fringe/religious topic as just "academics" would be a kind of POV omission in many circumstances no? Devout Catholics on the Turin Shroud? Scientologists on e-meters? Mormons on Joseph Smith? Christian Scientists on animal magnetism? Fundamentalists on the age of the Earth? All seems fair play for concern especially where WP:FRINGE claims are in play. And I agree it's not simple, all kinds of contexts for a source apply too. The "problem" here seems rather the push to deny that Wikipedia editors can raise these concerns and argue their case. Bon courage (talk) 06:20, 8 October 2024 (UTC)[reply]
where WP:FRINGE claims are in play: And when fringe claims are not in play? The report at issue concluded that despite what some Buddhists believed, no, monks who try to meditate while dying don't display any post-mortem brain activity—dead monks, in fact, exhibit all signs of being dead. It is one thing to discount, say, a Catholic historian who says 'the Turin Shroud is definitely authentic'. It's quite another to discount a Catholic historian saying things like 'X traditional belief about the Shroud of Turin is false' Hydrangeans (she/her | talk | edits) 07:35, 8 October 2024 (UTC)[reply]
When FRINGE claims are not in play then FRINGE is not a consideration and FTN not an appropriate venue. But this is a thread about FRINGE things at FTN. In general claims of something require better sourcing than claims of nothing, if that 'nothing' is just the default null hypothesis. Bon courage (talk) 07:49, 8 October 2024 (UTC)[reply]
When FRINGE claims are not in play then FRINGE is not a consideration and FTN not an appropriate venue: That's good advice.
But this is a thread about FRINGE things at FTN.: Is it? This has been a thread that is, at least in the OP, about worries of there being an attitude that religions should be treated as any other fringe theory and there are regular calls to edit religious articles in a way that seems to be fairly openly hostile without necessarily having regard for whether content is actually 'fringe'. After all, the particular example source much discussed in this thread has been one in which the empirically fringe claim made by some adherents ('dead monks mediate, their brains still work') was not empirically endorsed by the researchers. The source instead concluded 'when he died his brain stopped doing anything'. And yet an editor explicitly considered that non-fringe-ness irrelevant to deciding to regard it as suspect and unciteable (the words used being the "he's dead, Jim" conclusion is unimpressive to me). Hydrangeans (she/her | talk | edits) 17:17, 8 October 2024 (UTC)[reply]
After all, the particular example source much discussed in this thread has been one in which the empirically fringe claim made by some adherents
I think it’s also fair to point out that in contrast to many articles like this FTN gets involved in, not one editor here is taking a WP:PROFRINGE stance (accusations aside) on the content of the articles, so I’m hard pressed to actually see any fringe editing here beyond what was there at the start with editors uninvolved in this entire process.
I think raising Tukdam as it was written at FTN was reasonable, the article had some sources and phrasing which were inappropriate and I was the first editor to remove some of that content and raise Tricycle as biased in FTN. What follows wasn’t just fixing the article, but the open hostility to the article topic we’ve seen time and time again.
For what it’s worth (for Bon), I don’t see where we’re disagreeing at all and think you’re actually managing to articulate my perspectives a bit better than I can filtered through exasperation Warrenᚋᚐᚊᚔ 18:53, 8 October 2024 (UTC)[reply]
It's hard to comment without evidence but it's not at all unusual for sources to be disqualified or regarded with suspicion on Wikipedia because of their authors' record, context, and stated beliefs (e.g. certain researchers for Morgellons, Chinese research into TCM and Russian neuroscience in general). Is there some kind of religious exemption?
If I may, "context" bears much weight here. Just like any other argument you can make in this vein, there is a fine line between analyzing the reliability of individual authors based on their work and what their peers have to say about it, following a complete chain of logical inferences—and skipping that work, going with the latent "vibe" based on the intersection of categories visible about the author (independently if in tandem with the reputation of the relevant institutions). The latter approach amounts to bigotry. Remsense ‥ 论 06:54, 8 October 2024 (UTC)[reply]
Completely agree; it's complicated. And at the other (wrong) extreme I can remember a push at one time to ban any research on COVID-19 if the authors had a Chinese-sounding name. Generally there are factors suggesting a source is reliable that can outweigh any reputation an author might have, but at the same time there are entire large fields of "medical" evidential research Wikipedia puts in the bin no matter how esteemed the publisher or how peer-reviewed the paper because of the field itself (e.g. homeopathy). WP:ECREE is also a factor in this; and the idea that dead people meditate is rather ... exceptional. Bon courage (talk) 07:04, 8 October 2024 (UTC)[reply]
A claim that dead people have been scientifically or technologically proven to meditate would indeed be exceptional. A claim that a religion says that a few dead people meditate, OTOH, is no more exceptional than when a religion says that people are mere manifestations of the universe, or that people are being reincarnated through the millennia on a path towards enlightenment, or that people have immortal souls.
AFAICT though, the the objection isn't to the religious claim, but to mentioning that science says that these people are just plain dead, according to every physical measurement they've tried so far. We've got a 526-word-long article that contains only a single sentence about modern scientific research, and even that was removed at one point. These are not difficult claims that require special skills. The religion says part of the body stays warm, so stick a thermometer on it and see if that claim matches reality. WhatamIdoing (talk) 17:56, 8 October 2024 (UTC)[reply]
Nonetheless, a concrete proposal would be preferable to repeated accusations directed at a large group of contributors, especially when the closest thing to evidence has concerned just a couple of them.
Look at how my interactions have gone so far in here with the user’s I’m concerned about the behaviour of and ask yourself for a half second why I’d open myself up to more of this. I’m already at the point of a wiki break and am just sticking around now in case Bon decides to ANI me so I don’t get accused of simply not responding to that.
It doesn’t appear to matter what I actually say, what a few people want me to have said gets hot replies and derails any possible discussion, and this entire thread gets derailed. And that’s not in my head. Scroll back up to the top and look at the fixation on faith healing and other things that make empirical claims when my entire thesis was very explicitly about pure theology and a secondary thing of religious intolerance. I don’t thinks it’s even possible to go back to the first point here and the second point I believe has become self evident. Warrenᚋᚐᚊᚔ 05:30, 8 October 2024 (UTC)[reply]
If the distinction was as clean as you thought there wouldn't be all this fuss about Tukdam, right? Your invocation of "religious history and theology, as opposed to a specific empirical claim" is a false dichotomy. You can't expect other editors to use it a basis for discussion. Bon courage (talk) 05:39, 8 October 2024 (UTC)[reply]
The Tukdam article wasn’t posted when this thread went live and I raised it as an example of the intolerance issue, not the pure-theology issue, though did mention it in the context of FTN being tactless and inexpert.
Your invocation of "religious history and theology, as opposed to a specific empirical claim" is a false dichotomy.
You added the word history there, as history is most certainly not theology. And in what possible way is a belief in something utterly unfalsifiable the same as a claim that can be measured and analyzed? It’s a perfectly reasonable distinction. Warrenᚋᚐᚊᚔ 05:43, 8 October 2024 (UTC)[reply]
I added nothing, but copy and pasted the bold bit of your first post to this thread, which I assume was intended to be the main thing you were raising. So all this time you've been complaining editors aren't engaging with your post when you aren't even aware what you wrote? Bon courage (talk) 05:52, 8 October 2024 (UTC)[reply]
Well, look at me with egg on my face. Warrenᚋᚐᚊᚔ 05:53, 8 October 2024 (UTC)[reply]
the user’s [sic] I’m concerned about the behaviour of ← and here we have it at last. You're concerned about particular user behaviour. So why is that being raised in an opaque way at VPP? Bon courage (talk) 05:50, 8 October 2024 (UTC)[reply]
I’m genuinely unsure what gotcha you think you just stumbled across. I think you’re so caught up with seeing me as some kind of enemy that you’re not taking the time to read what you’re replying to, a pattern that seems to go quite a ways back in this thread. Warrenᚋᚐᚊᚔ 05:57, 8 October 2024 (UTC)[reply]
I don't think of you as an "enemy" at all. But this long drawn-out campaign you're waging as proxy for an apparent spat with one or two editors (maybe me? I don't know) risks exhausting the community. I really really don't think you should accuse anybody of not reading what they're responding to with quite so much 'egg on your face' (above)! Bon courage (talk) 06:07, 8 October 2024 (UTC)[reply]
Since Warrenmck already said I agree this should have been an ANI (though I don't consider it a terrible thing to have wanted to find a solution that doesn't involve disciplinary action against a user), I wonder if that's why there's a sense of being unsure what gotcha you think you just stumbled across. Hydrangeans (she/her | talk | edits) 06:11, 8 October 2024 (UTC)[reply]
But this long drawn-out campaign you're waging as proxy for an apparent spat with one or two editors
What? Have you considered exactly how many of the things you’ve been at me for in this thread are utter products of your imagination? You pointed out where I made an embarrassing mistake and I immediately owned up to it, but you’ve constantly represented arguments I’ve made any way except by actually assuming I’m not hiding my real motivations. Have you considered the possibility that I’m sincere, acting in good faith, trying to stop disruptive editing, and dealing with a fair amount of direct and baseless accusations because of that? Warrenᚋᚐᚊᚔ 06:17, 8 October 2024 (UTC)[reply]
I don't think you're "hiding your motivations", rather that your just being very coy about what you mean (which might be that you think a "cadre" of users A, B and C are problematic and need to be sanctioned).
Have you considered the possibility that I’m sincere, acting in good faith ← of for sure you are. But I also think you're wrong. Wrong about how the WP:PAGs apply and wrong about how the community operates. Bon courage (talk) 06:29, 8 October 2024 (UTC)[reply]
I don't think you're "hiding your motivations", rather that your just being very coy about what you mean
I fail to see how the accusations are distinct. And no, I don’t have a list of users in my head. Warrenᚋᚐᚊᚔ 06:32, 8 October 2024 (UTC)[reply]
  • I think it's important to remember that, in the big picture, Wikipedia's handling of fringe theories is working appropriately; see [18] in particular, which goes into depth on how good our handling of fringe topics is. (See also [19][20] for coverage.) I can understand that it is sometimes frustrating or that WP:FRINGEN can sometimes be overbearing, but I'd be strenuously opposed to any significant changes to how it operates when it is, largely, working. Dealing with the flood of fringe material on the internet is difficult, and Wikipedia is one of the few places that has coverage saying we've managed it properly despite being open for everyone to contribute; WP:FRINGEN is an important part of that. (Also, just from a skim, huge swaths of the above seem to be about disputes between a few specific editors who believe each other guilty of misconduct; that's not an issue for WP:VPP at all, and shouldn't be turned into a discussion of FRINGEN as a whole. Conduct issues with individual editors should be taken to either WP:AE or WP:ANI as appropriate.) --Aquillion (talk) 15:18, 13 October 2024 (UTC)[reply]
    The point we're making is that we tackle fringe topics well enough, or even in the majority of the cases, without or in spite of FTN and/or WP:Fringe. And at least one of your citations cut to the point:
    • Steinsson 2023 makes zero mention of FTN (talks about "noticeboards that are frequented by large numbers of Wikipedians" and specifically AN, NPOVN, and BLPN), and only a cursory mention of WP:Fringe, but the bulk of the paper talks about core policies, with NPOV being central -- this may be a methodological choice.
    • Matsakis 2018 Wired is about Gerbic's Guerilla Skepticism, which has come under ANI scrutiny in recent years. I'm not sure if anyone should go down this rabbithole of stupid internet drama, but here is one dumb blog link. The article also makes no mention of FTN or WP:Fringe, or of any noticeboard or P&G (i.e. the role that noticeboards and policies play in general -- it's essentially praising the administrative supereffectiveness of an off-wiki cabal). My main point is that I'm not going to put much consideration into a puff piece about an off-wiki coordinating group compared to a more objective reading from the previous paper.
    • Cooke 2020 Wired talks neither about WP:Fringe nor FTN nor any noticeboards.
    I'll expand on this in a little bit. SamuelRiv (talk) 16:20, 13 October 2024 (UTC)[reply]
    To continue on FTN, a snapshot of the noticeboard front page: I make the following measurement of its behavior as a content-conflict resolution noticeboard, versus a WP:Canvassing board as OP suggests in the title. Currently, I count 6 threads in which editors on all sides of the dispute were notified of the FTN posting/discussion in a timely manner, versus 4 threads in which they were not, and 4 additional threads which could not be evaluated in this manner. You can check my work on my sandbox. Additionally, in my opinion, on threads in which all participants were not notified and were not present, there was insufficient (i.e. nonexistent) encouragement by other editors on FTN on threads to ping them.
    While this is a very small manual survey (slow as I have to check the discussion pages on the individual articles), I believe it reflects poorly on FTN compared to other noticeboards, and lends some support to OP's accusation that FTN is being used a great deal, but not exclusively, for canvassing. SamuelRiv (talk) 16:40, 14 October 2024 (UTC)[reply]
    Like many noticeboards (e.g. BLPN, NORN), FTN does not have a requirement for notification in all cases, though editors are required to notify others if they mention them specifically. If there's appetite for strengthening the requirement, we should probably discuss at WT:FTN. Firefangledfeathers (talk / contribs) 16:51, 14 October 2024 (UTC)[reply]
    The problem is, I think, that people are far less emotionally invested in BLPN, NORM, etc. A lot of skeptic editing comes from people who, understandably, view themselves as skeptics in their everyday life. That’s to say it can be a part of someone’s identity in a way that we see with other POV editing but don’t tend to see with more policy-centric noticeboards. This can especially bleed into religion articles as a lot of self-identified skeptics are a little militant in their dislike of religion. I think this is why there’s so much pushback to the notion that a: WP:FRINGE cannot be applied in an openly hostile way to religion (not just religious content being added to articles, which obviously axe) and b: this sort of head-in-the-sand WP:DIDNTHEARTHAT if it turns out some long-held anti-fringe stance is actually more nuanced than originally thought.
    Basically FTN isn’t acting like a noticeboard for policy issues, but a wikiproject for people with strong skeptic stances. Therefore I don’t see how strengthening the notification requirement solves the issue of what can beer into POV editing, because I suspect that notifying would just result in business as usual, plus notifications. People can seem to be unmoved by evidence and are quick to throw out accusations of WP:PROFRINGE (see above) for dissent. It’s better off merged into NPOVN, imo. Warrenᚋᚐᚊᚔ 17:49, 14 October 2024 (UTC)[reply]
    @SamuelRiv, when you looked down the page, did you get a sense for the proportion of topics that were:
    • Move the dispute to the noticeboard to be settled there (typical for, e.g., RSN),
    • Requests that page watchers go to the talk page (typical for most WikiProjects), or
    • Questions more in the "background information" range (typical for a village pump post)?
    WhatamIdoing (talk) 18:53, 14 October 2024 (UTC)[reply]
    As far as I can tell looking now, none are about relocating or centralizing discussion, except the UAPDA thread is interesting where the editor challenged with WP:fringe goes themselves to FTN for advice on how to address it; a lot of the comments there seemed counterproductive until people finally got to the point (it had zero to do with any fringe policies from what I can tell). There are a couple that seemed to try to want to fork a discussion onto FTN, rather than redirect it.
    It appears the majority of threats are requesting people comment on existing article discussions (in two cases, the condition of an entire article or AfD).
    In 2 other cases, some general background questions not directly related to an article dispute were being asked. SamuelRiv (talk) 20:03, 14 October 2024 (UTC)[reply]
    It sounds like it's working more like a WikiProject: a centralized page to seek help from people who are knowledgeable about the subject matter. That's not inherently bad; it's good for editors to bring their health-related article disputes to WT:MED and their stats/math questions to WT:MATH. I'm not sure that I'd recommend merging that to a more traditional noticeboard, though, as it's quite a different style of interaction. WhatamIdoing (talk) 20:44, 14 October 2024 (UTC)[reply]
    It sounds like it's working more like a WikiProject
    I agree, but I think a wikiproject behaving like FTN would likely be censured on WP:OWN and WP:CIVIL grounds. Warrenᚋᚐᚊᚔ 12:28, 15 October 2024 (UTC)[reply]
    Realistically, we usually object to such groups only when they're visibly successful. Wikipedia:Article Rescue Squadron has been the target of similar complaints in the past. WhatamIdoing (talk) 19:01, 15 October 2024 (UTC)[reply]
    I am less convinced than they are that Wikipedia's handling of fringe topics is working appropriately. I see at least two issues:
    1. On issues FTN (one could argue, the greater skeptic movement) doesn't see as its targets, it doesn't do anything, and as a result there's lots of articles on minor religious topics that have wild supernatural claims in them. For instance, see Oven of Akhnai, which repeats a story from the Talmud verbatim in Wikivoice that basically treats rabbis as wizards. Or the recently fixed poor state of Tukdam was also due to this.
    2. On issues FTN (again, one could argue the greater skeptic movement) does see as its targets, it is extremely aggressive about maintaining a "skeptical" POV, often way past what the actual sources can support. The recent arguments over Tukdam are also a clear case of this, as an example of what happens when FTN suddenly discovers something it believes to be woo-y. My other example is EMDR, which claims a therapy that has been recommended by a huge list of WP:MEDORGs remains controversial within the psychological community per an article from 25 years ago and an article that specifically claims there is no controversy that it does work, because it's on the list of skeptic targets, because when it was initially formulated many psychologists were very skeptical of it to the point of calling it pseudoscience.
    In a lot of ways FTN operates as Wikipedia's immune system, and in this capacity Wikipedia clearly has an autoimmune disorder. It doesn't react to most things it should, and when it does react it way overreacts. The mere fact that most of the things skeptics look out for are not present on Wikipedia is not by itself sufficient evidence that it's actually working as desired. Loki (talk) 21:45, 13 October 2024 (UTC)[reply]
    +1 PARAKANYAA (talk) 02:12, 14 October 2024 (UTC)[reply]
    On issues FTN (again, one could argue the greater skeptic movement) does see as its targets, it is extremely aggressive about maintaining a "skeptical" POV, often way past what the actual sources can support
    This is the biggest issue I can see. It feels like people view themselves as WP:SMEs in “fringe” when that’s not exactly a thing, and sometimes editors assume their own read on complex topics is arrived at from a place of perfect understanding. Panspermia (discussed above) is still the most galling example of this to me, where source after source after source after source was met with “nuh uh” and the way it’s set up on Wikipedia is still potentially actively misreading to readers.
    Merge it with NPOVN and coming down on hallucinated policy interpretations would remedy a lot of this. Warrenᚋᚐᚊᚔ 12:59, 14 October 2024 (UTC)[reply]
    +1 to Samuel, Loki, and Warren's analyses. "Skepticism" can become as much a crusade on Wikipedia as fringe POV pushing. Levivich (talk) 15:31, 14 October 2024 (UTC)[reply]

Administrator Recall

Is there consensus to have administrator recall based on the consensus reached during Wikipedia:Requests for adminship/2024 review? 03:11, 22 September 2024 (UTC)
The consensus reached there established recall with the following process:

Petition
  • Cannot be launched until 12 months have passed since the user has successfully requested adminship or bureaucratship, re-requested adminship, or become an arbitrator.
  • Open for up to 1 month.
  • Notification is posted to Wikipedia:Administrators' noticeboard.
  • 25 editors must support the petition to trigger the re-request for adminship process.
  • The format allows for discussion and reasoning to be explained.
  • To support a petition, you must meet the criteria to participate in a request for adminship. You must not support more than 5 open petitions. There is no limitation on how often someone can initiate a petition.
  • If a petition for a given admin fails to gain the required support, another petition for that admin cannot be launched for six months.
  • Support statements can be stricken based on the same criteria as for requests for adminship.
Re-request process
  • A bureaucrat will start a re-request for adminship by default. The admin can request a delay of up to 30 days. If the re-request does not start by then, the admin can have their privileges removed at the discretion of the bureaucrats.
  • The re-request can also take the form of participating in an admin election. (Not clear what the consensus is regarding the need for the election to fall within the 30-day window).
  • For either a re-request or an election, the following thresholds apply:
    • below 50%: fail
    • 50–60%: Bureaucrats evaluate consensus
    • 60% and above: pass

Background

During phase 1 of WP:RFA2024 Joe Roe closed two proposals for recall with the following close (in part with emphasis in the original):

Considering § Proposal 16: Allow the community to initiate recall RfAs, § Proposal 16c: Community recall process based on dewiki, § Proposal 16d: Community recall process initiated by consensus (withdrawn), in parallel, there is a rough consensus that the community should be able to compel an administrator to make a re-request for adminship (RRFA) in order to retain their administrator rights. However, there is also a consensus that the process(es) for initiating an RRFA needs to be worked out in more detail before this is implemented. Phase II of this review should therefore consider specific proposals for RRFA initiation procedures and further consensus should be sought on which, if any, is to be adopted. The dewiki-inspired process suggested in Proposal 16c was well-supported and should be a starting point for these discussions.

When the second phase began the process was, after 3 days, structured in a way that took Proposal 16c and offered alternative options for certain criteria. This was done in good faith by Soni who had originally proposed 16c. Some editors objected to this structuring at the time and/or suggested that a 3rd RfC would be needed to confirm consensus; Joe Roe would later clarify well after the process was underway that the Phase 2 structure did not, in his opinion as closer, reflect the consensus of Phase 1. Others, including Voorts who closed most of Admin recall phase 2, suggest that there was adequate consensus to implement the process described above. Post-close discussion among editors has failed to achieve any kind of consensus (including whether there needs to be an RfC like this). As an editor uninvolved in the current discussions about Admin recall until now, it seemed to me that the clearest way to figure out if this recall process has consensus or not is to ask the community here rather than have this discussion in parallel with an attempt to recall someone. Barkeep49 (talk) 03:11, 22 September 2024 (UTC)[reply]

Survey (administrator recall)

  • (involved) The question here is simple: did a two-phase discussion that reached consensus in both phases also achieve an overall consensus to implement? The answer is equally simple: yes, it did. The current strongest argument against this idea seems to be that Phase II's formatting didn't give enough leeway for someone to propose a recall system distinct from the dewiki process (while still using that as a starting point). But there was an open discussion, and I don't recall seeing a different idea gain any significant amount of traction. If we really need to go through an entirely new RfC to double-confirm a proposal we've already accepted in principle and fine-tuned, fine, let's do it, but it seems like a waste of community time to me. theleekycauldron (talk • she/her) 11:10, 22 September 2024 (UTC)[reply]
    The open discussion section was closed after three days though. – Joe (talk) 11:49, 24 September 2024 (UTC)[reply]
    Despite this, people added additional proposals, and additional options to existing proposals, and nobody complained about the open discussion section being closed, for months thereafter. Levivich (talk) 18:24, 24 September 2024 (UTC)[reply]
  • (uninvolved) Yes consensus was reached. Naturally new tweaks/discussions will come along. Let's have specific RfCs on those. ~ 🦝 Shushugah (he/him • talk) 11:38, 22 September 2024 (UTC)[reply]
  • Yes there is a consensus (uninvolved). A legitimate objection is that the process of managing the second RfC may have stymied other possible outcomes beyond a de wiki style process, and this may have been the case. However, RfCs with perceived flaws tend to generate lots of comments pointing this out (as we can already see below) and I'm just not seeing that that in the 2nd phase RfC. The 1st phase confirmed that the community wanted a recall process, the 2nd phase asked for proposals to be developed for implementation and there was a consensus found within that discussion for a specific variant. In the interest of not letting the perfect being the enemy of the good, I believe there is sufficient support for the admin policy to be updated based in this outcome, with further adjustments being made as required (or indeed removing it entirely should a subsequent consensus determine that it should). Scribolt (talk) 15:42, 22 September 2024 (UTC)[reply]
  • Strangely-worded question. No, there isn't currently a consensus for this proposal; but yes, I think we should reach consensus for it at this RfC.—S Marshall T/C 16:45, 22 September 2024 (UTC)[reply]
  • A key challenge in trying to reach agreement by consensus is that interest tends to wane as discussion moves from higher-level concepts to more fine details. One way to address this is to get consensus for a general initiative, obtain consensus for key aspects to incorporate, then work on implementation details. For this specific situation, I think the phase 2 discussion did a sufficient job at taking the support shown during phase 1 and working out agreement on the broad-stroke steps for a recall process. As always, because it's hard to get people to pay enough attention to reconcile specific wording, part of working out the implementation means finding a working procedure that is the central object illuminated from different directions by people's statements. I feel the phase 2 results reveals enough scaffolding to proceed with implementation. isaacl (talk) 17:00, 22 September 2024 (UTC)[reply]
  • (involved) Yes. There is consensus per my comments in the post-close discussion, as well as per leeky and Scribolt above. Those editors raising objections to the idea of admin recall or the proposals that gained consensus, but who did not participate in the earlier RfCs, should have participated; phases I and II were both widely advertised (I remember them being posted at T:CENT, VPP, AN, AN/I, etc.). I worry that a third RfC will fatigue the community and disproportionately draw the most vocal opponents to the process, resulting in a small group of people overriding a consensus already twice-determined by the community. voorts (talk/contributions) 20:51, 22 September 2024 (UTC)[reply]
  • (I closed some of the proposals) I don't know why we need an RfC to say "yes, this RfC was correct", but yes. Charlotte (Queen of Hearts • talk) 22:40, 22 September 2024 (UTC)[reply]
  • I participated in both Phase I and Phase II. I believe the results of Phase II achieved consensus and should be implemented. I do not see how this contradicts the results of Phase I. As others have pointed out, an actual policy page is still being drafted and might have to go through yet another RfC. Having an RfC on the validity of each step seems like a waste of time. Toadspike [Talk] 07:34, 23 September 2024 (UTC)[reply]
  • I think your question answers itself. "Was there consensus for the consensus"? The answer is obviously yes. Now, if you want to ask a different question, open a different RFC. --130.111.220.19 (talk) 18:14, 23 September 2024 (UTC)[reply]
  • No, there isn't consensus for the recall process proposed at Wikipedia:Administrator recall. I'll reiterate a comment I made on the Phase II talk page: taking the mini-consensuses from that phase, then using them to cobble together a process, doesn't translate into a solid policy with broad community consensus. The fact that various aspects of the proposal, even now, are up in the air disproves the notion that "the consensus already exists". Those who are advocating for Wikipedia:Administrator recall need to finalise that page, then present it for a simple yes/no RfC, so that the consensus (or lack thereof) on the policy as a whole is beyond question. SuperMarioMan (Talk) 20:55, 23 September 2024 (UTC)[reply]
  • No, there is no consensus for this, and I've explained why on the pages where the proposal is being developed. But I think it's unfair to ask this question now, because the editors who support the proposal are still working on it. I therefore think this RfC should be closed as premature. --Tryptofish (talk) 21:51, 23 September 2024 (UTC)[reply]
    • I had hoped that this RfC would be withdrawn, but it appears that it won't, so I feel the need to say why this RfC cannot establish consensus for the policy change.
      • First, Barkeep49 gets the facts wrong in the statement of this RfC. He says: Joe Roe would later clarify well after the process was underway that the Phase 2 structure did not, in his opinion as closer, reflect the consensus of Phase 1. In fact, he said more than that: I'm really sorry to say this, but reading it all through now, I think Wikipedia:Requests for adminship/2024 review/Phase II/Administrator recall has trainwrecked... I just cannot see how a genuine consensus can be said to come from a process like this... The only way I can see of salvaging this is to take whatever precise version of 16C got the most support and present it as a straight support/oppose RfC. [21]. Barkeep49 goes on to quote Voorts as having determined that phase 2 established consensus: Others, including Voorts who closed most of Admin recall phase 2, suggest that there was adequate consensus to implement the process described above. But in fact, Voorts drew a clear distinction between his close of individual sections, as an uninvolved closer, and his personal opinions about overall consensus, which were separate from the close: [22], [23].
      • And the bullet-list summary differs in some substantive ways from what appears to be the proposed policy. 25 editors must support the petition. Isn't it 25 extended confirmed editors? Who closes the petition? In fact, this is still being discussed: [24].
      • Since when are policy pages simply a bullet-list? Are we being asked to establish the bullet-list as a policy page, or are we being asked about Wikipedia:Administrator recall? The latter is beyond any question a work-in-progress. So if it needs to be changed as the editing process there continues, are we establishing consensus for the current version, or for some indeterminate version that will emerge in the future? And if the real purpose of this RfC is to establish consensus against, is that a fair process?
      • Phase 1 established consensus for some form of process. Phase 2 established consensus for some particular forms of the process, but did not establish whether those forms are actually to be implemented as policy, or whether those forms are the best version to be submitted as a policy proposal. This RfC muddles two different questions: whether the process so far has already established consensus, or whether the proposal summarized in bullet points should now be adopted as policy. And some editors here have been answering the first question, whereas others have been answering the second.
      • No one has answered the question of what is inadequate with the status quo, with ArbCom handling desysop requests.
      • The bullet-list proposal would be a disaster for Wikipedia if enacted here. It can't even be launched within the first year after the successful RfA? What happens if an admin does objectional things before then? More importantly, we are in a time when many members of the community are deeply concerned that we do not have enough new admins emerging from RfA, and that we are starting to see backlogs. Many members of the community regard RfA as being unattractive to well-qualified candidates, too stressful, not worth the aggravation. So if any random group of 25 users can force a recall, and just a few can start the petition process, how will that affect administrator morale? Will even more qualified RfA candidates decide against applying? Will current admins become too fearful of angering 25 disruptive editors, and hold back from dealing with contentious tasks, such as AE?
    • At least we should have a fully-developed proposal for the community to evaluate. Given that there are editors who are working on just that, it seems foolish to demand an up-or-down RfC now, before they have finished, on the theory that this would save them the trouble of working on something that will fail. Plenty of editors want the proposal to succeed, so they are not being imposed upon by giving them the time to finish. And the proposal here isn't ready for prime time. --Tryptofish (talk) 22:56, 25 September 2024 (UTC)[reply]
  • Yes (uninvolved) - There is a super clear consensus to have an administrator recall. Still work to be done om the actual policy page. But to the question of this RFC, Is there consensus to have administrator recall based on the consensus reached during the last review? Yes clearly, otherwise the right next step would be to challenge that close. This is not the place to relitigate the RFC or how the policy page is being created. PackMecEng (talk) 13:13, 24 September 2024 (UTC)[reply]
  • No IMO the question is unclear but I think interpreted as "was it decided that the deWiki version be adopted?". In shorthand, the main close was a general consensus that there should be a recall process, with the related verbiage in essence implicitly saying that it needed to be developed and then approved. The close on adopting the deWiki version was that there was insufficient participation (in this context) to consider it to be a decision either way. So the next step is to develop a proposal that can get wide support and get it approved. While keeping in mind that the first close says that it's already decided that "we want something like this" and so that question should not be revisited, and "There should not be any such recall process" is not a valid argument at this point. North8000 (talk) 13:54, 24 September 2024 (UTC)[reply]
    That next step is what Phase II was. Levivich (talk) 18:19, 24 September 2024 (UTC)[reply]
  • Yes. If this discussion is "Should Wikipedia:Administrator recall be implemented?", my answer is yes. That is effectively what the list of points above effectively are. If this question is "Is there consensus already to implement Wikipedia:Administrator recall?" then my answer is also Yes. I think there was consensus via Phase II to do this. If people believe there isn't, then I strongly prefer resolving the first question right now instead of bunting this entire thing to a second RFC further down the line.
    I also personally would have preferred a week while editors already discussing the matter at Wikipedia talk:Administrator recall could resolve this. But the cat's out of the bag, and nobody seems to actually close this as premature. So I would prefer going through with this RFC instead of alternatives that draw this out for everyone. Soni (talk) 05:06, 25 September 2024 (UTC)[reply]
  • Regarding Soni's first question, my answer is unreservedly Yes. Regarding Soni's second question, my answer is a Very Weak Yes. Also, this RfC is a premature mess. Tazerdadog (talk) 18:30, 25 September 2024 (UTC)[reply]
  • Yes. ~ ToBeFree (talk) 22:02, 25 September 2024 (UTC)[reply]
  • Yes. We do not need an RfC to answer the question "Did the previous discussion, with a consensus close, actually close with a consensus?" Just get it done. Details will, as usual, be refined as we go along. If the entire thing turns out, after post-implmentation experience, to be a bad idea, then it can be undone later. PS: If there is doubt whether a close of an RfC or other discussion actually reached the consensus claimed by the closer, the place to hash that out is WP:AN (unless it's subject to a more specific review process like WP:MRV for move disputes, and WP:DRV for deletion ones).  — SMcCandlish ☏ ¢ 😼  13:08, 27 September 2024 (UTC)[reply]
  • Involved yes there is consensus, yes this should be implemented, per those above and in particular leeky. HouseBlaster (talk • he/they) 18:12, 28 September 2024 (UTC)[reply]
  • No. The partial trainwreck of the discussion that happened at the Phase II RfC meant that consensus for several critical aspects of the recall proposal did not gain sufficient consensus to enact such a significant change to a core policy (WP:ADMIN). And for my own part I failed to see a consensus on some matters at all, though I suppose reasonable minds can disagree on the matter. JavaHurricane 10:31, 29 September 2024 (UTC)[reply]
  • Yes per S Marshall. The process should continue with the understanding that there is a consensus for recall on this basis though details remain to be finalized. Eluchil404 (talk) 21:45, 29 September 2024 (UTC)[reply]
    • I don't think the question here is whether there is consensus for some future version, in which the details will have been finalized. It's whether there is consensus for what it says at the top of this RfC. --Tryptofish (talk) 22:50, 29 September 2024 (UTC)[reply]
      • Right. And my position is that there is (or at least it should be established here) consensus for the form of recall described in the 14 bullet points listed above. Some people in this discussion have queried the precise interpretation of some of the points, so another round of workshopping precise language would not be amiss, but the proposal should continue to move forward on this basis without "going back to the drawing board" because of concerns about a previous RFC. Eluchil404 (talk) 23:43, 29 September 2024 (UTC)[reply]
  • Yes, there is consensus to adopt an administrator recall process that includes the characteristics that achieved consensus in RFA2024 Phase II. To my eye, the proposal here successfully reflects that consensus. ModernDayTrilobite (talk • contribs) 14:41, 30 September 2024 (UTC)[reply]
  • "25 editors" is much too vague. Could be 25 IPs? Only logged in editors with some experience should be allowed, and the simplest way is to require EC. Zerotalk 02:47, 3 October 2024 (UTC)[reply]
    Already done. The suffrage requirements for recall petitions are "same as RFA". That was one of the Phase 2 consensuses (consensi?). Phase 1 consensus set RFA suffrage to EC. Levivich (talk) 03:33, 3 October 2024 (UTC)[reply]
  • Yes, confirm consensus. The weight of community involvement and the clear consensus close are sufficient to grant this process the effect of policy immediately. I will say this: I am absolutely shocked that the second phase of the discussion was not better advertised; given the long-anticipated nature of this process and the importance to community functions moving forward, it should have been better attended. And yet, the dozens of editors that did participate came to reasonable and clear consensus conclusions on various facets of the process. Beyond that, we are years deep into repeated derailing of the creation of this function, despite clear community support for some sort of process. There is absolutely no reason why further discussion to clarify, alter, or amend any provision of the process cannot take place after the process is codified in its namespace. But the time has come for the process to exist, and there is nothing egregiously problematic in what was decided upon in the foregoing discussion. With the caveat that, no matter what the community decided upon for the initial procedure, there are bound to be things we can only think to address and adjust after the first community RRfA discussions take place. SnowRise let's rap 10:33, 3 October 2024 (UTC)[reply]
    Regarding notifications about the second phase of discussion: a watchlist message was posted, the centralized discussion notice box was updated, and a link was posted to the Administrators' noticeboard (there was also a link present in the announcement of the closure of phase 1). A mass message was sent to what I believe is a list of participants in phase 1. isaacl (talk) 16:47, 3 October 2024 (UTC)[reply]
    Well, fair enough, if it was posted on CD, which is arguably the single best thing you can do to promote an issue. But I do think spaces like VP are a vastly more reasonable place for posting a notice intended to draw in general community input about the recall of admins, compared to AN, with it's limited traffic mostly constrained to admin activity (or at least as much constrained as any open space on the project). In fact, some may argue (though I'm certain it was lack of forethought rather than intent) that the only noticeboard to receive a notice of the discussion being the one noticeboard with the highest admin-to-non-admin activity ratio is maybe the least optimal way to advertise a discussion that would seek to create the community's first direct means for recalling admins. The CD link seems to have been the only notice well-calculated to reach an average community member: the mass mailer, the discussion link in the closure of phase I, and the watchlist notice, all of those were only ever going to reach those who participated in Phase I. Which is good, but again, probably a lot less than this discussion warranted. SnowRise let's rap 17:35, 4 October 2024 (UTC)[reply]
    Watchlist notices get pushed to everyone with an account, no? Also, CD is posted at the top of VPP. voorts (talk/contributions) 19:55, 4 October 2024 (UTC)[reply]
  • Yes (involved), but I agree with everyone who is saying that this is pre-mature fanfanboy (block) 18:27, 3 October 2024 (UTC)[reply]
  • Yes there appears to be community consensus to implement an Administrator Recall process as described. I think some of the concerns raised are genuine, especially the potential for abuse... But I doubt the community would look kindly on editors who chose to WP:GAME this new system. Horse Eye's Back (talk) 20:06, 4 October 2024 (UTC)[reply]
  • Yes (involved). The existence of the pre-voting "open discussion" section, as well as the widespread "find a consensus" sentiment was enough for the consensus found to be valid. Mach61 14:10, 7 October 2024 (UTC)[reply]
  • Yes (involved). From the get-go, the purpose of WP:RFA2024 was to reach consensus -- not to workshop a proposal for later ratification, but to workshop proposals and approve/deny them in the same RFA2024 process. In Phase I, Proposals 16 and 16c, the overall proposal for a community-based recall system (#16) reached consensus. On the numbers, 65 editors voted, and it was 43-22. On the proposal for a specific dewiki-like system (#16c), 34 editors voted, it was a 25-9 majority, but this was determined to not be consensus because of the (relatively) lower participation.

    We went on to Phase II, where specific proposals for details of the recall system were made. The purpose of Phase II was, clearly, to iron the details from Phase I #16c, not to draft a proposal for submission to the community, but to decide the details, in Phase II. This is evidenced by the many "find a consensus" votes in Phase II (the phrase appears 27 times on the page, in addition to which there are various variations on the theme), which were editors expressly saying they'd rather have a recall system in place with any of the proposed details, than have the proposal for recall fail due to disagreement about some of its details. It was clear that the participants wanted Phase II to end with a consensus for an actual system, not a proposal for a third round of RFC. 93 editors participated in Phase II [25], which is even more than in Phase I.

    Both Phase I and II were widely advertised, tagged with the RFC template, advertised on watchlists, and posted on WP:CENT -- they more than complied with WP:PGCHANGE. They had broad participation, and the fact that Phase II ended with a system very similar to dewiki only confirms the budding consensus from Phase I. The fact that the "open discussion" section of Phase II was closed after a few days does not undermine the consensus-forming process in my view; discussion continued, new proposals continued to be made, and some voted against the entire idea of recall. Nevertheless, consensus was formed on various proposals, leading to the system that is now well-documented at WP:RECALL.

    So, yes, this months-long process confirmed what we all already knew was global consensus (to have a community-decided involuntary recall system, and to have it be modeled on dewiki's successful system); this RFC will be the third time in a single year that this global consensus will be confirmed. When this RFC is closed as "yes," as I believe it will be, we should put the policy template on WP:RECALL and that should dispel any and all doubts as to whether WP:RECALL has consensus. 100+ editors in 3 rounds of voting is more than enough to establish global consensus. Levivich (talk) 17:47, 7 October 2024 (UTC)[reply]

  • Yes and No. It appears that Wikipedia:Administrator recall is still being developed and that these dot points are the basis for that development. There is a consensus for a recall policy according to these dot points but as has been pointed out above these dot points are not a policy in and of themselves so cannot be adopted immediately. When there is consensus for a barebones policy (the dot points) it is then developed into an actual policy page before a final RfC to adopt it. That's the normal process and should be followed here. So, yes there is a consensus to have a recall process along the lines of the dot points and that is correctly being developed into a policy before final adoption so, no, there is not yet a consensus to turn the wordy version at Wikipedia:Administrator recall into policy. Callanecc (talk • contribs • logs) 01:49, 8 October 2024 (UTC)[reply]
    The current version is less than 500 words and it's been stable for one week. voorts (talk/contributions) 01:57, 8 October 2024 (UTC)[reply]
    Sounds like it's ready for an RfC for formal adoption as a policy then? I don't think it's appropriate to merge this RfC into that given that the proposal here is a series of dot points that is different to what's at Wikipedia:Administrator recall. For example, I wouldn't support 25 editors as listed in this proposal but would support 25 extended confirmed editors. Other questions have been raised above (for example what if there's a concurrent ArbCom case) and I would encourage editors who have raised those concerns here to take them to Wikipedia talk:Administrator recall for a further discussion and whether or not they should be incorporated into that proposal before it is put forward for adoption. Callanecc (talk • contribs • logs) 00:26, 9 October 2024 (UTC)[reply]
    25 extended-confirmed editors is already a requirement. A fourth RFC seems excessive. Levivich (talk) 01:45, 9 October 2024 (UTC)[reply]
    +1 Yet another reason why this should have been workshopped first: this proposal is missing a crucial part of the previous stage. Sincerely, Dilettante Sincerely, Dilettante 01:51, 9 October 2024 (UTC)[reply]
    While I have expressed agreement with this sentiment before, I am also a firm believer of not putting everyone through additional WP:BURO after this. So I'd rather User: Barkeep49 or someone else add a link to WP:Administrator recall to the topic above instead of trying to wrangle a 4th RFC. I'd phrased my !vote above to answer the question I think we should be asking anyway. Soni (talk) 06:30, 9 October 2024 (UTC)[reply]
    Agreed: Callanecc and Dilettante's points are accurate and well taken, but this really does come down to a more direct call on community will and BURO. I think the obvious emerging consensus here is that if a version of the policy language has already been rendered which includes all of the consensus elements agreed to for the process, without any glaring contraventions or other issues, then as soon as this discussion closes with a consensus in the affirmative, that version of the guideline becomes policy immediately. Repeating the process yet again for purely pro forma reasons is not necessary, appropriate, or a reasonable use of community time. Let's remember that any version validated can thereafter be reasonably expected to be subject to discussion and further tweaking, particularly in its first months.
    EDIT: Though I do think one reasonable thing that could be done thereafter would be to advertise every major disputed discussion on the guideline talk page at VPP for the next six months (and having a tendency to do so thereafter, really). It is, after all, a new process that has non-trivial consequence to our administrative operations, so continuing to have heavy community input in its initial evolution here can only be regarded as a good thing. SnowRise let's rap 03:18, 13 October 2024 (UTC)[reply]
    Adding on to the pile that says that we've already gone through so much bureaucracy at this point that any more after this would be really out of the norm. If there's consensus here, mark it as policy and work out fine details as they are brought up. If there's not consensus, let's find out right now, and not after more formal RFC cycles. Tazerdadog (talk) 18:12, 15 October 2024 (UTC)[reply]
  • Yes on principle, but some points still need to be workshopped. How does 50–60%: Bureaucrats evaluate consensus work for an election? Is it split in the middle? This kind of details should've been made clear before putting the proposal up to a vote. (Edit: looking at the comments below, this appears to have already been discussed) Chaotic Enby (talk · contribs) 06:15, 9 October 2024 (UTC)[reply]
    Yeah it's 55%, which was added to WP:RECALL a few weeks ago (following that discussion below). Levivich (talk) 06:22, 9 October 2024 (UTC)[reply]

General discussion (Administrator Recall)

  • Close as the proposal is still being developed. A draft of a full proposal is being discussed at WP:Administrator recall that refines and adds clarification to the closes at WP:RFA2024. All editors are welcome to participate in the discussion. I do anticipate that this proposal will come back for community discussion. --Enos733 (talk) 03:35, 22 September 2024 (UTC)[reply]
    As noted when this was raised on my talk page, the work there appears procedural. There is no agreement even there about whether or not this is already policy or not. Having editors spend time developing something in detail when the core policy doesn't have consensus is a poor use of time in my opinion. If it does have consensus the details can be worked out and will be made to happen. We have seen that happen with Admin elections coming out of the RFA2024 process. Best, Barkeep49 (talk) 03:49, 22 September 2024 (UTC)[reply]
    I understand where you are coming from, but the detailed efforts identified a couple challenges with how to implement the close, and I wouldn't suggest that the policy described above is the exact proposal coming from those efforts (although it is in harmony with the closes in WP:RFA2024). While every policy could be further refined, I am of the belief that our community is best served by bringing forward a more complete proposal for community discussion. - Enos733 (talk) 04:28, 22 September 2024 (UTC)[reply]
    This should be closed. For most people, whether they support admin recall depends very much on the details of the proposed mechanism. For a sensible RfC, the mechanism has to be spelled out (as above) but must not change for 30 days. That does not match reality at the moment. Johnuniq (talk) 04:48, 22 September 2024 (UTC)[reply]
    @Johnuniq genuine question: what details do people need beyond which there is already RfC consensus for? Best, Barkeep49 (talk) 15:46, 22 September 2024 (UTC)[reply]
    Barkeep49, I oppose the proposal, but I think you should withdraw this RfC for now. What people still need (or at least should be entitled to) is to see a full proposal, a proposed policy page, not the bullet list summary you posted here, and to see a rationale for adopting the proposal, prepared by its supporters. And editors are working on those things now. --Tryptofish (talk) 21:59, 23 September 2024 (UTC)[reply]
  • I long ago tuned this out as a TL;DR waste of my time. But curious, is there a consensus that the current Arbitration Committee-led "recall procedure" is not up to the task, and should be discontinued? Or, rather, is there a consensus that both procedures may be used. Can an admin be subject to both an Arbcom case *and* a "community recall procedure" at the same time? Is there a consensus for that? To be clear, I oppose the possibility of simultaneous, competing recall procedures. wbm1058 (talk) 09:53, 22 September 2024 (UTC)[reply]
    @Wbm1058 Nothing in this above would prevent someone from becoming a party to an arbcom case, or from arbcom issuing any remedy. How would you like a blocking condition to work? Perhaps a prohibition on community recall rrfa launching while the admin is a party to an arbcom case? — xaosflux Talk 10:42, 22 September 2024 (UTC)[reply]
    If stripping the Arbitration Committee of the power to desysop isn't part of the package, this whole "recall procedure" strikes me as highly problematic. Imagine an Admin suffering through a month-long Arbitration Commmittee proceeding, ending with an "admonishment" to the administrator, followed hours later by the opening of a "community recall procedure". – wbm1058 (talk) 10:52, 22 September 2024 (UTC)[reply]
  • Bureaucrats evaluate consensus for 50-60% is invalid for the election option, that is strictly a vote - so needs a specific value. — xaosflux Talk 10:38, 22 September 2024 (UTC)[reply]
    There has been consensus for 60% threshold for Admin elections. The same has been summarised in Wikipedia:Administrator recall as well (which was intended as a summary of Phase II) but I don't see a link to it in the main proposal here Soni (talk) 10:54, 22 September 2024 (UTC)[reply]
    So perhaps the description above just needs to be clarified. — xaosflux Talk 14:41, 22 September 2024 (UTC)[reply]
    Should be consensus for 55%. Option C stated the midpoint of whatever passed in the other discussion. Option C won there, which was 50-60%, so the midpoint is 55% which is explicitly called out in the first discussion. Pinging @Voorts: in case I'm completely misreading something here. Tazerdadog (talk) 18:51, 22 September 2024 (UTC)[reply]
    55% is correct. voorts (talk/contributions) 20:31, 22 September 2024 (UTC)[reply]
    @Xaosflux, @Soni, and @Tazerdadog: I've fixed the close to state that it's 55% without 'crat discretion; I think I added that bit by accident because that's nowhere in that discussion. voorts (talk/contributions) 20:45, 22 September 2024 (UTC)[reply]
  • Leaving aside everything else, this part is confusing: A bureaucrat will start a re-request for adminship by default. The admin can request a delay of up to 30 days. If the re-request does not start by then, the admin can have their privileges removed at the discretion of the bureaucrats. Is this implying that if the admin requests a delay then the admin is responsible for creating it? Why not have the 'crat create it after the delay, same as they would for no-delay? Anomie⚔ 14:39, 22 September 2024 (UTC)[reply]
    I don't like that part at all. I'd rather see the admin start their own RRFA within some short deadline (7 days - with possibly the option for asking for the 30 day extension) -- and if they don't start it anyone can ask at BN to process the desysop. Crats never have to edit, so requiring the crats to create a pageto move the process forward gives them a pocket veto. — xaosflux Talk 14:46, 22 September 2024 (UTC)[reply]
    I disagree with this RFC's summary of that part of the proposal. As I read it, an admin chooses whether to start an RFA (or stand for election), which must be done within 30 days, and if it's not done within 30 days, crats desysop with discretion ("discretion" such as taking into account whether the petition was entirely signed by obvious sock puppets or had the requisite number of qualified signatories, or to extend the period to 32 or 33 days instead of 30 due to the admin's RL schedule, things of that nature). Levivich (talk) 15:06, 22 September 2024 (UTC)[reply]
    Option E there is where it says the 'crat should open create the discussion. The other options had the admin being required to say "come attack me" within a certain period of time. The combination of E+A is where we got the confusion here, since E didn't explicitly say what should happen if a delay is requested. Anomie⚔ 15:11, 22 September 2024 (UTC)[reply]
    Yeah, I think the closer got it wrong by finding consensus for E. Only 6 people (out of 30+) voted for E. It's A, not E. Levivich (talk) 15:20, 22 September 2024 (UTC)[reply]
    OTOH, looks like only 9 of those 30+ voted after E was added. That part, at least, seems like it could use further discussion by people who care. Anomie⚔ 15:23, 22 September 2024 (UTC)[reply]
    I just asked the closer to reconsider it. Levivich (talk) 15:30, 22 September 2024 (UTC)[reply]
    This point is one of the pieces that has been ironed out at WP:Administrator recall. As I said above, and others have pointed out, this proposal is not completely ripe. - Enos733 (talk) 15:38, 22 September 2024 (UTC)[reply]
    Yeah I guess the current language at WP:RRFA handles it just fine. @Anomie and Xaosflux: take a look at WP:RRFA, I think that addresses your concerns on this point? Levivich (talk) 16:06, 22 September 2024 (UTC)[reply]
    🤷 Looks to me like they changed it from E+A to just A. That does resolve the confusion. Anomie⚔ 16:50, 22 September 2024 (UTC)[reply]
    I don't think it would ever happen, but in theory the crats could just wait 30 days and then decide to revoke privileges without any community input, which seems like a flaw, that part should be reworded to clarify who is responsible for starting the process in each situation. ASUKITE 17:08, 3 October 2024 (UTC)[reply]
  • Close as premature. The page is a mess right now, as several people have posted above. It isn't anywhere near finalized so of course there will be holes and parts where it doesn't judge consensus. When I said "What we need is an RFC to decide whether or not we need another RFC", I didn't expect anyone to actually do it. Sincerely, Dilettante 15:48, 22 September 2024 (UTC)[reply]
  • I'm a little confused as to what is being asked here: is this a request for approval of a process? Or are we judging whether consensus was previously formed for it? The latter does not seem to me a good question to ask, as it is sending us further into the weeds of a proposal that has already gotten out of hand with respect to creation and approval procedure. But that's how I read my colleagues' !votes above. Vanamonde93 (talk) 16:16, 22 September 2024 (UTC)[reply]
  • Do we really need another bureaucratic mess that is another RfC? I think the last one had enough consensus. Ping me if there's anything in particular we're trying to work out and I'm not getting the point of this. I'm trying to take a step back from the more complicated aspects of the project right now but this is important. Clovermoss🍀 (talk) 16:20, 22 September 2024 (UTC)[reply]
  • Close as a confusing, duplicative mess. The specific question in this RFC, as far as I can make out, is asking whether the previous discussion had consensus to implement something following discussion, or whether the outcome of that further discussion needs to be subject to an RFC. I don't think it's sensible to even ask that until that further discussion is complete and we can see the differences between it and the consensus outcome. However, above there appears to be discussion of things other than that question, and no clear agreement about what the consensus of the last RFC was (with the consensus as determined by the closer having changed at least once since the initial close) - other than more discussion of the details was needed (which seems to be happening in two places). I don't think it's possible for this discussion to be useful in any way so it should be closed before it creates even more confusion. Thryduulf (talk) 21:04, 22 September 2024 (UTC)[reply]
    @Thryduulf: I think there might be some confusion about what this discussion is for – it would definitely be silly if it was trying to ask people to assess the consensus of the post-close discussion on talk. This RfC asks the same question the post-close discussion has been focused on: did the Phase I and Phase II RfCs result in a consensus to implement? That, I think, is worth discussing. theleekycauldron (talk • she/her) 23:23, 22 September 2024 (UTC)[reply]
  • The "25 editors" figure in the initial proposal was qualified as being extended confirmed. Definitely not supporting a process whereby any 25 editors, over the course of a full month, can start this process. — Rhododendrites talk \\ 13:13, 24 September 2024 (UTC)[reply]
  • I don't think there's a consensus ... but whether there is or isn't, "There is no limitation on how often someone can initiate a petition." needs to be clarified. You can't support more than five open petitions, but then the next sentence says you can initiate a petition without limit. Those two statements need to be harmonized. --B (talk) 13:34, 24 September 2024 (UTC)[reply]
    I don't think "There is no limitation on how often someone can initiate a petition" is entirely accurate. There are limitations on how often someone can initiate a petition (there are cooling off periods, plus the 5-petitions-at-once limit), limitations that were decided in Phase II and are specified at WP:Administrator recall § Petition. Levivich (talk) 18:20, 24 September 2024 (UTC)[reply]
  • Re:Close as premature comments, I said my piece above and on my talk page about why I thought (and think) it appropriate. I also don't think I hold any particular status other than being UNINVOLVED in this process. So if some other UNINVOLVED editor wants to close this as premature, I'm certainly not going to push back. Best, Barkeep49 (talk) 20:18, 25 September 2024 (UTC)[reply]
  • For further background, see wp:Administrators_open_to_recall and the associated categories and pages. (including pages related to some actual recalls) When we came up with this back in the Jurassic Era, we intended it to be voluntary. It's interesting to see that there appears to be consensus that some kind of mandatory process be implemented. ++Lar: t/c 15:53, 9 October 2024 (UTC)[reply]

What is a revert?

There is a long-simmering issue when dealing with 1RR, namely there is no policy that covers what a revert is. WP:REVERT which defines a revert as reversing a prior edit or undoing the effects of one or more edits, which typically results in the article being restored to a version that existed sometime previously. is an essay, and Help:Revert, which is an information page, uses undoing or otherwise negating the effects of one or more edits, which results in the page (or a part of it) being restored to a previous version.

First issue is that these two definitions contradict each other. ...typically results in the article being restored to a version that existed sometime previously and ...which results in the page (or a part of it) being restored to a previous version are mutually exclusive. Something can typically result or result, and there is a large space between them. Secondly, undoing the effects of one or more edits and otherwise negating the effects is a hole wide enough to drive an article about an 80s cartoon character through. Normally, this type of ambiguity is par for the course, but we have multiple policies, bright-line rules, and arbitration sanctionsWP:3RR, WP:1RR, WP:CTOP#Standard_set that call out reverts, and can be grounds for immediate blocking and sanctioning.

So I ask, what is a revert? When does something become the WP:STATUSQUO so that changing or removing it is BOLD and not a revert? Where is the line on undoing the effects or negating the effects? If someone adds bananas are good to an article and someone changes that to bananas are not good has the previous edit been reverted, as the effect was negated, or should the banana-hater have the first mover advantage? Should we have an actual policy defining a revert if we're going to have arbitration sanctions and bright-line blocked if you break 'em rules about reverting? ScottishFinnishRadish (talk) 12:39, 26 September 2024 (UTC)[reply]

A related discussion on from talk page can be seen at User talk:ScottishFinnishRadish/Archive 33#Clarity on reverts. ScottishFinnishRadish (talk) 12:42, 26 September 2024 (UTC)[reply]
A revert is changing anything I don't want changed. Seriously tho, since changing anything is technically a revert, one is forced into examining the exact circumstances, how long since content was added, intent, etc. Selfstudier (talk) 13:36, 26 September 2024 (UTC)[reply]
I think rules should be interpretted according to their purpose, which isn't always clear from their literal wording. The purpose of classifying edits as reverts is to identify edit-warring in a semi-rigorous way. It isn't to catch editors out for cooperative editing. If Selfstudier writes "The population of XYZ is 10,000", and I remove it with the comment "I don't like that source", then that's a revert. However, if I remove it with the comment "That's a different place called XYZ, see page 23 for our XYZ", that's cooperative editing. The difference is that in the first instance I was opposing Selfstudier's intention, and in the second case I was assisting with it. Something likely to please the editor whose edit is being changed shouldn't be called edit-warring, ergo not a revert. Encoding this principle in a way that everyone can understand might be tall order, and in my current covid-ridden-and-sleep-deprived state I won't try. Zerotalk 15:15, 26 September 2024 (UTC)[reply]
SFR is correct to highlight the "restored to a previous version" aspect, which was always broken. Consider add A, add B, delete A, add C, delete B. Possibly two reverts in there but no two versions of the page are the same. Zerotalk 15:19, 26 September 2024 (UTC)[reply]
Should be able to point to an edit that was reversed. Removal is basically always a revert, restoring what was removed is almost always a revert, rewording? Depends, but in the case of "A is true" edited to "A is not true", one of those editors is doing something more important than reverting anyway. nableezy - 15:54, 26 September 2024 (UTC)[reply]
I don't think there can be a hard rule on when edit B negates the effects of edit A, because there are lots of ways to reword edits, all functionally equivalent to a revert. Unfortunately for the enforcement of the one-revert rule, I think it's also difficult to have blanket rules on when some content has achieved default consensus agreement status, as it's highly dependent on factors such as how many editors regularly review changes to an article. As per English Wikipedia's decision-making traditions, the way forward is to have a discussion about what is the current consensus, halting any changes on the contested content in the meantime. I appreciate, though, that has high overhead. The community has been unable to agree upon less costly ways to resolve disagreements. isaacl (talk) 15:59, 26 September 2024 (UTC)[reply]
An edit that deliberately reverses the changes of one or more previous edits, in whole or in part. Cremastra (talk) 19:39, 26 September 2024 (UTC)[reply]
I think it's a constructive and reasonable clarification. I would say that if you can no longer see the edit you're supposedly reverting in the first 50 or 100 page revisions, and there's good faith reason to believe that the editor was no longer aware that they were reverting, it's no longer a revert. Wikipedia:Reverting: Any edit to existing text could be said to reverse some of a previous edit. However, this is not the way the community defines reversion, because it is not consistent with either the principle of collaborative editing or with the editing policy. Wholesale reversions (complete reversal of one or more previous edits) are singled out for special treatment because a reversion cannot help an article converge on a consensus version. Andre🚐 22:44, 5 October 2024 (UTC)[reply]
  • I feel like some essays on this might be a good idea (then we can figure out which one is most accurate, refine it over time, and gradually push it towards policy, or at least towards being a highly-respected essay with nearly the weight of policy.) Having hard-and-fast rules risks people gaming them, and I'm not sure it's possible, but there's some definite guidelines that could be helpful. I threw together a quick-and-dirty User:Aquillion/What_is_a_revert with my thoughts - note the two questions at the end, which are the points I'm uncertain about (I definitely saw a dispute recently about the "removal -> restore -> add text downplaying the disputed material" sequence somewhere recently, so it ought to be nailed down.) My opinion is that it isn't a revert - this interprets negating the effects too broadly. As the second example on my essay shows, that logic could be used to argue that once I've made an edit to an article, almost any edit made by anyone in a dispute with me anywhere in the article at all is now a revert, because any addition of other information that potentially contradicts or even just waters down the WP:WEIGHT of my addition could reasonably be framed as undoing the intent of my edit. I add something saying "X is true"; someone in a dispute with me then makes a large addition to the article, of stuff that was never there before but which represents a position that broadly diverges from what I added. I accuse them of trying to water down my statement that "X is true" by making it less of the article by percentage and otherwise shifting the balance I established, effectively reverting me. This may even actually be their intent! It's a common situation! But it's not, I think, an actual revert. --Aquillion (talk) 16:51, 12 October 2024 (UTC)[reply]
    I think that your discussion of how things become a lot less clear with 1RR vs 3RR is worth noting. A lot of things become more clear with the repetition, but it's pretty blurry with 1RR. ScottishFinnishRadish (talk) 21:26, 12 October 2024 (UTC)[reply]
First, an observation: the community has imposed a 0RR sanction before, which is not intended to be a complete ban on editing. Nearly every edit involves undoing or otherwise negating the effects of one or more edits. Therefore, a revert is not simply undoing or otherwise negating the effects of one or more edits and so either that definition is wrong or the qualifier which results in the page (or a part of it) being restored to a previous version is important.
My general inclination, separate from that observation, is to construe "revert" narrowly. An edit is a revert if it returns the page to a prior state and it's not if not, even if it's intended to contradict or downplay other information in the article. I agree with Aquillion that the cyclic nature of an edit war is an important piece of the puzzle, and therefore am inclined to say that editing disputes that progress rather than cycle are not edit warring even if they don't usually feel great from the inside. Loki (talk) 23:38, 12 October 2024 (UTC)[reply]

New Page Reviewers

Hi. I thought I ask the question here regarding policy on New Page Reviewers. The current tutorial states "The purpose of new pages patrol is equally to identify pages which cannot meet this standard, and so should be deleted, and to support the improvement of those that can. Pages that pass new pages patrol don't have to be perfect, just not entirely unsuitable for inclusion." On several occasions I have noted that new page reviewers have marked pages as reviewed, but for other editors to then go in another as not meeting notability rules. If this is the case is there not a mechanism that the new page reviewers can be reported as not meeting the "just not entirely unsuitable for inclusion" criteria? Davidstewartharvey (talk) 12:22, 29 September 2024 (UTC)[reply]

The second part of your statement is unclear, could you rephrase? Remsense ‥ 论 12:31, 29 September 2024 (UTC)[reply]
I think they are saying that there are 2 editors A and B. A reviews the page, marks it as reviewed, then B marks it as not meeting notability rules. And the question is whether there is a way to report this inconsistency based on the premise that B is correct, and A made an error. Sean.hoyland (talk) 12:55, 29 September 2024 (UTC)[reply]
Or vice versa! Davidstewartharvey (talk) 13:23, 29 September 2024 (UTC)[reply]
It's common for editors to disagree on notability, as is clear in a number of AfD nominations, so a reviewer passing a new page that is subsequently nominated for deletion isn't necessarily a problem. If, however, you see it happening frequently with the same reviewer, you should discuss your concerns with that editor on their talk page. Schazjmd (talk) 14:07, 29 September 2024 (UTC)[reply]
Something doesn't have to be unquestionably notable to pass NPP patrol. It just needs to be "not entirely unsuitable". Some NPPers will only mark at patrolled when they're very, very sure a topic is notable; others will mark it as patrolled so long as it doesn't meet some of the WP:CSD criteria, most reviewers are somewhere in between the two. Also, many people use the notability tag not to mean "this isn't notable" (really, if you're sure, you should probably start a deletion discussion), but "I don't know if this is notable, can someone who knows more about this kind of thing come check?" So even if two different reviewers might both agree that a page should be marked as patrolled, that doesn't mean that one reviewer might want to leave a notability tag where the other wouldn't. -- asilvering (talk) 00:38, 30 September 2024 (UTC)[reply]
Wikipedia:New pages patrol § Notability explains that Opinions are divided on how important it is to consider notability during new page patrol. In my own opinion, notability issues don't always make an article entirely unsuitable for inclusion; as Joe Roe says in his excellent NPP tips essay, NPP is not the Notability Police. jlwoodwa (talk) 17:07, 30 September 2024 (UTC)[reply]
I'd take that essay with a grain of salt. The opinions there about notability and draftification are... controversial. Thebiguglyalien (talk) 15:15, 5 October 2024 (UTC)[reply]
I haven't heard anybody object to them? No doubt you've amassed a considerable knowledge of the spectrum of opinions on new page reviewing since I granted you the right six months ago, though. – Joe (talk) 18:13, 14 October 2024 (UTC)[reply]

Template protection for DYK queues?

For those not familiar with the DYK workflow, its basically anybody can review a submission, anybody can promote a reviewed submission to a prep area, but then we need an admin to move that into a queue, because the queues are fully (i.e. admin only) protected. Once in a queue, an admin bot moves things to {{Did you know}} which is transcluded onto the main page. DYK is chronically short of admins to perform the last step. That's probably the single biggest roadblock to the smooth operation of DYK, and has been for a long time.

There are a number of DYK regulars who are highly skilled and trustworthy, but for all the usual reasons don't want to subject themselves to RfA hell. I started a conversation at WT:DYK#Giving queues template instead of full protection? about the possibility of changing the full protection of the queues to template protection, and making a limited number of DYK regulars template editors. This was met with positive response, so I'm coming here to find out how the broader community would feel about this.

I know it's policy that the main page is fully protected (but I don't know where that's written down). It's unclear to me how much of the DYK queues being fully protected is baked into policy. The Template Editor capability only goes back to 2013, much newer than DYK, so I suspect it's mostly a case of "we've always done it this way". Assuming DYK could agree on the implementation details, would I be within my remit as an admin to change the protection level on the DYK queues and start handing out template editor bits? Or does that require some community-wide approval process? RoySmith (talk) 17:57, 30 September 2024 (UTC)[reply]

I support the proposal (and suggest that DYK regular admins just hand out the bit as needed). In case anyone is wondering, the DYK template on the Main Page and the next DYK update would continue to be fully protected via cascading protection, so the proposal would not allow template editors to vandalise the Main Page. —Kusma (talk) 18:37, 30 September 2024 (UTC)[reply]
Doesn't template editor usually have a host of pre-requirements? As anyone with template editor can change templates transcluded to millions of articles. -- LCU ActivelyDisinterested «@» °∆t° 23:11, 30 September 2024 (UTC)[reply]
Yup. They are described at WP:TPEGRANT. RoySmith (talk) 23:20, 30 September 2024 (UTC)[reply]
Personally, I don't favour expanding the role of template editors simply because the permission may be easier to grant. I would prefer creating a new permission tailored for the role, such as DYK-editor or main-page-editor, which can be assigned to a corresponding user group. isaacl (talk) 23:54, 30 September 2024 (UTC)[reply]
In theory, I agree that a finer-grained permission system would be a good thing. In practice, I suspect it would be near impossible to make that happen. In the meantime, we've got zero filled queues because no admins want to do the work, and the people who want to do the work aren't admins and don't want to be. RoySmith (talk) 00:37, 1 October 2024 (UTC)[reply]
I'm not sure that it would be impossible to gain consensus for a protection level for, say, main page maintenance. If I understand the documentation correctly, only configuration changes are needed. I just don't see template editor as a good fit: I think it requires a much higher degree of trust than editing main page components. isaacl (talk) 01:32, 1 October 2024 (UTC)[reply]
Well, I'm willing to explore other possibilities. Can you give me a link to where this is documented? RoySmith (talk) 01:37, 1 October 2024 (UTC)[reply]
mw:Help:Protected pages says additional protection levels can be defined by the $wgRestrictionLevels configuration setting. mw:Manual:$wgRestrictionLevels shows an example of defining a permission level, and then modifying $wgGroupPermissions to assign the permission level to a user group (also see mw:Manual:User rights § Creating a new group and assigning permissions to it). isaacl (talk) 04:16, 1 October 2024 (UTC)[reply]
Thanks for the link. As far as I can tell from that, what we'd need to do is not just create a new user group, but also create a new restriction level. That all seems excessively complicated. RoySmith (talk) 11:33, 1 October 2024 (UTC)[reply]
Yes, that's what I said. Creating the permission level is one line in the configuration, and is necessary to be able to designate which pages can be edited by the new role. Procedurally, it's the equivalent amount of work as designating a page that can only be edited by those with the template editor role, and then assigning users to the corresponding template editor group. isaacl (talk) 15:57, 1 October 2024 (UTC)[reply]
OK, I'm not seeing that. Perhaps you could write it all out in in detail a sandbox or something? RoySmith (talk) 16:10, 1 October 2024 (UTC)[reply]
As I understand it, the English Wikipedia configuration was modified to implement the template editor role. The change allowed admins to select the template editor permission level when protecting a page, created a template editor user group, and assigned the permission to the new template editor group and the sysop group. The same would have to be done to create a main page editor permission and a corresponding role. The new permission level is needed so specific pages can be designated as limited to main page editors. A corresponding group is needed so main page editors can be assigned to the group. The permission is also assigned to the sysop group so admins can also edit the pages in question. isaacl (talk) 16:55, 1 October 2024 (UTC)[reply]
I'm not opposed to going this route, but I'm not confident enough that I understand the details to tackle it myself. If you're willing to take on getting this created, I'll be happy to use it in lieu of my current plan. RoySmith (talk) 17:02, 1 October 2024 (UTC)[reply]
If it helps, Wikipedia talk:Requests for comment/Template editor user right/Archive 2 § Next steps is where the work to implement the template editor role was discussed. Roughly speaking, it seems to consist of configuration changes, MediaWiki message changes, English Wikipedia page protection process changes, and English Wikipedia icon changes. I'm only tangentially familiar with most of these, so I think a better bet would be to crowdsource volunteers to help out. Hopefully an RfC would find enough interested helpers (as seems to have been the case with the template editor role, but then again, by the nature of that role it was probably more likely to do so). I was mainly thinking of what it took to implement the role in the configuration, rather than how to update English Wikipedia's procedures, so I appreciate now that it's more upfront work than re-using an existing permission level. However I think it pays off by making it easier to replenish a pool of editors able to edit the main page, since they won't have to meet the higher requirements for the template editor role. isaacl (talk) 17:33, 1 October 2024 (UTC)[reply]
I don't think fine grained permissions are a good thing. Everybody who can be trusted to edit templates or to decide what should be on the Main Page should be made an admin. The only reason we need extra permissions at all is that we do not have a working method to make new admins. —Kusma (talk) 05:20, 1 October 2024 (UTC)[reply]
So in the interest of getting results, I would suggest to go ahead with changing the queue protection to "template protection" and assigning the template editor bit to a couple of people now. A separate permission could be a later second step that we should take if we need it. —Kusma (talk) 11:11, 1 October 2024 (UTC)[reply]
My read on this is that they may say they want to do the work, but they don't think they'd be trusted to. And in that case, why should we trust them to? RFA is still thataway, and we're not doing anybody - not the reluctant candidates, not the current admins, not the DYK process - any favors by bypassing it. —Cryptic 13:58, 1 October 2024 (UTC)[reply]
By bypassing RfA we do almost everyone a favour. The exception is future admins who will have higher workloads because we aren't promoting enough of them. But as long as RfA is so hurtful that failed RfAs have a high chance of putting off people from editing altogether (or at least from running ever again), we need to care for other processes like DYK by finding solutions for their problems without involving RfA. —Kusma (talk) 15:03, 1 October 2024 (UTC)[reply]
We have important work that isn't getting done. We have people with the skills and desire to do that work. The only reason we can't draw a line between point A and point B is because RFA is totally broken. RoySmith (talk) 15:22, 1 October 2024 (UTC)[reply]
We have the ability to draw a line between point A and point B without making it go through point C (whether that's the admin role or the template editor role). We bundle the lines together to try to avoid overhead in managing the lines. But in this case, where drawing the line would be easy given the existence of a pool of editors with the required skills and interest, I think it's less overhead to draw a direct line, rather than routing it through a different point that requires a larger set of skills. isaacl (talk) 16:09, 1 October 2024 (UTC)[reply]
Your read on this is wrong. I don't need everything about me to be vetted by voters who can be very rude for no reason, especially when the only thing I would do if I was an admin would be to update DYK. I don't want to ban editors, delete articles, or do any of that stuff. SL93 (talk) 23:33, 3 October 2024 (UTC)[reply]
The bizarre thing about all this is that one of the abilities I have as an admin is being able to edit template-protected pages. Which is stupid because my understanding of non-trivial template syntax is essentially zero. The only thing I know how to #invoke is sheer terror about anything that has more than one pair of curly braces. And of all the stupid things I've seen asked at RfA, never once have I seen anybody quizzed on their understanding of template syntax. RoySmith (talk) 00:01, 4 October 2024 (UTC)[reply]
Presumably trusted with the mop. We'd now be potentially extending that same level of trust to some DYK editors who probably won't have any template coding experience either. —Bagumba (talk) 13:31, 4 October 2024 (UTC)[reply]
Same. I can break any template the first time I use it, and I won't go near editing most except for things like adding an entry in a navigation template. I think what we need to consider is whether an editor can be trusted to know what they don't know. Valereee (talk) 16:21, 5 October 2024 (UTC)[reply]
DYK queue editors would likely not have the "real" template coding experience typically expected by WP:TPEGRANT. They basically are just editing text. But if given the right, they would then have access to other highly-sensitive templates and their actual code. —Bagumba (talk) 12:45, 1 October 2024 (UTC)[reply]
And if they abuse that, the right can be revoked. --Ahecht (TALK
PAGE) 01:24, 4 October 2024 (UTC)[reply]
If the abuse that right they could break every page or post anything they like to the main page. -- LCU ActivelyDisinterested «@» °∆t° 15:15, 7 October 2024 (UTC)[reply]
@ActivelyDisinterested As long as they meet the first 4 criteria of WP:TPEGRANT I don't seen how they'd be more likely to break every page than any other template editor (and in reality, I think the worst a template editor could do is break a little under 20% of pages), and anything they put on the main page would have to sit in the queue first where it could be reverted before hitting the main page. --Ahecht (TALK
PAGE) 21:44, 7 October 2024 (UTC)[reply]
What about the other 3 criteria aren't you meant to meet all four of them? Also doesn't the main page directly transclude templates? If so the TPE right could be abused to push anything to it. As to how many pages could be effect I'm not sure how many pages something like {{cite web}} or {{short description}} is transcluded to, but I'd bet it's more than 20%. -- LCU ActivelyDisinterested «@» °∆t° 23:06, 7 October 2024 (UTC)[reply]
@ActivelyDisinterested All templates transcluded on the main page are Wikipedia:Cascade-protected items and cannot be edited by template editors. --Ahecht (TALK
PAGE) 20:28, 14 October 2024 (UTC)[reply]
Thanks for clarifying. -- LCU ActivelyDisinterested «@» °∆t° 20:51, 14 October 2024 (UTC)[reply]
While these are technically templates, these aren't really templates. Granting template editor rights to editors who have no experience working with templates is completely the wrong way of doing things. Gonnym (talk) 11:46, 15 October 2024 (UTC)[reply]

Just to be clear, what I'm seeking here is clarification on why the queues are fully protected. Is there some specific established policy which requires that because they feed into the main page?— Preceding unsigned comment added by RoySmith (talk • contribs) 11:24, 1 October 2024 (UTC)[reply]

Judging by the protected areas listed at WP:ERRORS, it looks like any page content that will imminently be on the MP is fully protected. —Bagumba (talk) 12:49, 1 October 2024 (UTC)[reply]
Yes, via the WP:CASCADE protection of Main Page (which includes Wikipedia:Main Page/Tomorrow to protect the next DYK queue). —Kusma (talk) 13:32, 1 October 2024 (UTC)[reply]

The DYK queues might be a good use case for pending changes level 2 (disabled for the better part of a decade), or heck, even level 1. The admin bot could be changed to copy over only the most recent approved revision. IznoPublic (talk) 03:14, 6 October 2024 (UTC)[reply]

BTW, this change was made a few days ago. So far, the world has not come to an end, so let's see how things go. If there's problems, we can always revisit this to see if a different solution would work better. RoySmith (talk) 20:37, 14 October 2024 (UTC)[reply]

I find this quite surprising given this discussion. -- LCU ActivelyDisinterested «@» °∆t° 20:54, 14 October 2024 (UTC)[reply]
The question I was asking was "Is there a policy reason which prevents me from doing this". Nobody came up with such a reason. RoySmith (talk) 21:00, 14 October 2024 (UTC)[reply]
+1, let's see how it goes. Valereee (talk) 11:19, 15 October 2024 (UTC)[reply]

RfC: In the news criteria amendments

Should either of the following proposals to amend the criteria for In the news be adopted?

Proposal 1: Amend the ITN significance criteria (WP:ITNSIGNIF) to state: The significance criteria are met if an event is reported on the print front pages of major national newspapers in multiple countries (examples of websites hosting front pages: [26] and [27]).

Proposal 2: Abolish ITNSIGNIF and amend the ITN update requirement (WP:ITNUPDATE) to state that a sufficient update is one that adds substantial due coverage of an event (at least two paragraphs or five sentences) to an article about a notable subject.

Proposal 3: Mark WP:ITN as historical and remove the "In The News" template from the Main Page, effectively closing the process in lieu of an alternate means of featuring encyclopedic content on Wikipedia.

You may also propose your own amendments. voorts (talk/contributions) 22:53, 7 October 2024 (UTC)[reply]

To clarify: Proposal 1 would replace the current ITNSIGNIF. Please see the background and previous discussions for the rationale. voorts (talk/contributions) 13:44, 8 October 2024 (UTC)[reply]
Adding for the record Proposal 3: Mark WP:ITN as historical and remove the "In The News" template from the Main Page, effectively closing the process in lieu of an alternate means of featuring encyclopedic content on Wikipedia. Duly signed, ⛵ WaltClipper -(talk) 13:48, 8 October 2024 (UTC)[reply]
Updated to add Proposal 3 above the first signature as part of the RFC question that gets copied to RFC pages. Levivich (talk) 18:27, 8 October 2024 (UTC)[reply]

Notifications

Notified: Template:Centralized discussion, Wikipedia talk:In the news, Wikipedia:Village pump (proposals), Wikipedia:Administrators' noticeboard. voorts (talk/contributions) 23:03, 7 October 2024 (UTC)[reply]

Background (In the news criteria amendments)

During a closure review of a proposed ITN entry, several editors expressed a concern that discussions at ITN are closed for subjective reasons because WP:ITNSIGNIF does not provide sufficient guidance for determining consensus. There was then a discussion at WT:ITN where several editors proposed changes to ITN, including amending or abolishing the significance criteria, and amending the update criteria. Some editors proposed replacing ITN with something else on the Main Page. voorts (talk/contributions) 22:53, 7 October 2024 (UTC)[reply]

Survey (In the news criteria amendments)

  • Yes on 1. As of right now, any non-ITNR blurb proposal, especially RDs, is a dogfight where people insist "it is/is not important enough to blurb". No-one's convinced by an opponent because our process is essentially to decide it on a sui generis basis. Clear rules save editor time in such discussions. If something's not on the front page of multiple newspapers, it really shouldn't be blurbed (there's an obvious IAR exception for when the event is so significant we can post faster than newspapers have time to print, like with Elizabeth II's death, but I trust editor judgement in such instances). On the other hand, if something is, it probably should. This should prevent some of the staleness that we see. Sincerely, Dilettante 23:28, 7 October 2024 (UTC)[reply]
  • Support 2 as its drafter, but I also support 1 as a second choice. ITN should in theory be about featuring subjects that are in the news, instead of a simple list of news stories. If there is enough news about a person/place/thing that its article can be immediately updated with significant due content, then it should qualify. ITN's purpose is ultimately to display content that we've recently improved, just like DYK. Thebiguglyalien (talk) 23:37, 7 October 2024 (UTC)[reply]
    I'm also willing to support 3 and replace ITN with something else if reform isn't viable. Thebiguglyalien (talk) 18:42, 8 October 2024 (UTC)[reply]
  • 2 as first choice, but if that fails to get consensus, 1. ITN’s slow update schedule fails to incentivize content improvement like the other mainspace sections, and is vastly inferior to P:CE in either informing readers of new events or connecting them to articles they wish to go to (though external search engines make that specific goal mostly irrelevant). Prop. 1 is a decent reform to ITN as it exists since it would reduce repetitive arguments, but Prop. 2 brings ITN in line with the rest of the main page Mach61 23:39, 7 October 2024 (UTC)[reply]
    I will say, I think a standard closer to four paragraphs or 300 words might be better, but that can be amended later Mach61 00:58, 8 October 2024 (UTC)[reply]
    I initially suggested the two paragraph minimum, but I'd also support a higher barrier. On top of holding ourselves to a higher standard, it would make it easier to catch frivolous expansions and other undue content that people would try to push through. Thebiguglyalien (talk) 02:08, 8 October 2024 (UTC)[reply]
    Support 3 as well. Yes, all these options are mutually exclusive, but they are all better ways of dealing with ITN than the status quo. Mach61 16:36, 15 October 2024 (UTC)[reply]
  • Yes on 1 or 2, with a preference for 1. ITN has been broken for quite some time, as editors use their own personal criteria to judge what stories are important enough to be listed. (Just look at the discussion surrounding US President Joe Biden's departure from the 2024 presidential race.) Setting aside the tremendous amounts of personal acrimony this generates, any story that does manage to get posted is often significantly out of date by the time it is replaced. For example, as I write this, the oldest story on ITN is a sport final that happened nearly ten days ago. That's no longer "news" by any definition of the word. It certainly doesn't track with reliable sources, as all the news articles about it are at least a week old. The Wikipedia article's views have unsurprisingly cratered. And despite all that, we are still advertising it on our main page to millions of readers. This situation makes us look out of date and out of touch, and it reduces ITN's usefulness to readers (readers being the primary reason we're all editing Wikipedia). It's time to change. The status quo is untenable. Ed [talk] [OMT] 23:48, 7 October 2024 (UTC)[reply]
    • Updating after option 3 was added: I'm really close to being open to that option as well purely due to the acrimonious atmosphere at ITN. However, I'd need to see a proposal to replace it with P:CE or similar to actually support. It would be a real loss to Wikipedia if we completely dropped the part of the main page that reminds readers that we are a living and updateable resource. Ed [talk] [OMT] 19:48, 8 October 2024 (UTC)[reply]
  • Support 2 per my comments on WT:ITN, oppose 1, as being in front-page news isn't necessarily a good criterion of encyclopedic significance, and things like commercial announcements might end up getting too much weight. Chaotic Enby (talk · contribs) 23:58, 7 October 2024 (UTC)[reply]
  • Abolish ITN. The main page is Wikipedia's front cover and should invite readers into the encyclopedia. All content featured on the main page should deserve the spot only because it is a legitimate achievement of Wikipedia editors such that enhances the image and public reception of Wikipedia. A reader arriving on the main page is met with a list of promises: "Click here for something good". A promise needs to be made and needs to be delivered on. Featured articles are worthy of being featured because doing so highlights editors' ability to create very good content. DYK items are usually not very good content but are worthy of being featured because the hooks promote the perception that Wikipedia contains many interesting facts, that its articles also have some entertainment value, and they are backed up by at least adequate, presentable content that was recently created, drastically expanded, or improved. "On this day" is a traditional element that counterbalances the lightheartedness of DYK and highlights the vast work of editors who have developed comprehensive coverage of historic events. Each part of the main page communicates a promise along the lines of "there's something good here—click here for more", and has something to back that promise up with. Except for ITN. The weird old news panel. Old news and non-presentable articles on "significant events" are non-featurable. Instead of highlighting good work, Wikipedia is highlighting a curated list of world events selected through a non-encyclopedic process that manifests a systemic passive-aggressive contrarianism (not blaming anyone, it's a group dynamic and a systemic tendency arising from the incompatibility of the encyclopedia format with the news format) relative to the mainstream media discourse. Instead of promising good content and delivering on it, the message is, "we know what is really important in the world". That has turned out to be the whole point of ITN. It does not support the central purpose of Wikipedia—making a great encyclopedia. It does not help readers find and quickly access content they are likely to be searching for because an item is in the news—because the content is usually ridiculously stale for something put in proximity of the word "news". Readers can find and quickly access such content without it being added to the main page, and there is no reason why they should be directed to recent events content in an encyclopedia before being led to any other section of the encyclopedia. Yes, Wikipedia is different from traditional encyclopedias because it is a "dynamic resource", but that is obvious enough without it being advertised on the main page, and there is no particular reason to advertise this fact above the fact that it is an encyclopedia that everyone can edit (that is what makes it a truly dynamic resource). It does not showcase quality Wikipedia content on current events. Content on current events that is actually good exists, but it is relatively rare; ultimately, it is not even that content that gets featured because ITN items only have to pass a very low bar in terms of quality and are actually selected on the grounds of significance. ITN does not deliver good things to a reader and isn't backed up by good content. Pointing readers to subjects they might not have been looking for but nonetheless may interest them is served by DYK. ITN should be abolished entirely. If it isn't abolished, I support Proposal 2.—Alalch E. 23:59, 7 October 2024 (UTC)[reply]
    Hear, hear. InedibleHulk (talk) 01:50, 8 October 2024 (UTC)[reply]
    This is difficult to read without paragraph breaks. Duly signed, ⛵ WaltClipper -(talk) 13:43, 8 October 2024 (UTC)[reply]
    @WaltCip: I've user-essayified it: User:Alalch E./Everything on the Main Page is featured —Alalch E. 17:07, 8 October 2024 (UTC)[reply]
    Yes, Wikipedia is different from traditional encyclopedias because it is a "dynamic resource", but that is obvious enough without it being advertised on the main page. The fact that Wikipedia has interesting information is also obvious, yet we have DYK. The fact that Wikipedia has high-quality articles is obvious, yet we have TFA. The fact that Wikipedia has information on historic events is obvious, yet we have OTD. That's a non-argument, except in the context of wholly reforming the main page.Sincerely, Dilettante 17:17, 8 October 2024 (UTC)[reply]
    The non-argument comes from WP:ITNPURPOSE, and I'm identifying it as a non-argument for having ITN. A thing such as ITN is not needed on the main page to emphasize Wikipedia as a dynamic resource. —Alalch E. 23:11, 8 October 2024 (UTC)[reply]
    I agree with this sentiment as well. ITN was born due to 9/11 and it is dividing Wikipedia apart. 130.245.192.6 (talk) 13:48, 9 October 2024 (UTC)[reply]
  • Support 2 per @Thebiguglyalien. Oppose 1. I think it would significantly restrict the types of articles that get featured at ITN. As for abolishing ITN, while I appreciate @Alalch E.'s concerns, I think we ought to give ITN a chance before invoking the nuclear option. voorts (talk/contributions) 00:08, 8 October 2024 (UTC)[reply]
    I also largely agree with @Masem regarding option 1. voorts (talk/contributions) 01:11, 8 October 2024 (UTC)[reply]
    Also, even if this RfC ultimately results in no consensus as to any particular option, it would be helpful for the closer to identify broader areas of consensus that might help to focus future discussion. voorts (talk/contributions) 00:16, 9 October 2024 (UTC)[reply]
    At this point, weak support for option 3. Given the number of ITN regulars claiming that there's no problem with ITN in this discussion, I'm not sure that we can do anything to fix it. voorts (talk/contributions) 19:02, 10 October 2024 (UTC)[reply]
  • As an involved editor at ITN, I will not explicitly vote here. I still believe the level to which ITN is broken or "broken" is heavily overstated. That said, I would be in favor of some variety of change to INTSIGNIF, if something must be changed, and would like to propose a impacts-based assessment of news items for ITN inclusion, whereby editors discuss the impacts (particularly long-term and lasting ones) of the events comprising the blurb in question. My rationale being that readers likely wish to engage with impactful news rather than events that may be of lesser effect or are ephemeral. This would fit with ITN's purpose of guiding readers to articles they may be interested in reading, while still filtering out some of the garbage news (ie celebrity drama) that may generate interest, but is of fleeting concern. Granted, there is no objective criteria here, but my belief is that I do not believe any criteria that are both objective and reasonable for ITN are possible. I may be proven wrong here and am willing to see if I am, but I have doubts that this shall happen. And I really do believe proposal 2 is just not tenable at all for the project's purposes and could make ITN way too subject to media bias (particularly western media). DarkSide830 (talk) 00:22, 8 October 2024 (UTC)[reply]
    @DarkSide830 If you're concerned about western media bias, your proposal would make things much worse in that regard. The metapedians who comment on pages like ITN are more likely to be western and much more likely to be men than our readership. Of course their prospective on what the most "impactful" events are will skew towards what affects them Mach61 00:47, 8 October 2024 (UTC)[reply]
    I don't see that at all. If our concern is coverage, then the nominations that would be most successful are Anglosphere based events, because Anglosphere publications cover them the most and most extensively, and these are the publications that the English-speaking editors of this wiki would most frequently consult. Either way, I don't know how my proposal would negatively change anything from this perspective. DarkSide830 (talk) 01:37, 8 October 2024 (UTC)[reply]
    Okay, well, if the regulars are partaking, put me down as leaning support on proposal 1 and fairly solidly opposed to 2. DarkSide830 (talk) 02:30, 8 October 2024 (UTC)[reply]
  • Support 1 [EDIT: changed to oppose both in comment below] [EDIT 2: added oppose 3 in comment below] seems well enough if ITN regulars think it facilitates their process. The guideline should be worded well that a "sufficient" criterion does not mean "necessary". [A sufficient criterion of notability says nothing about being necessary for notability, and it definitely says nothing about being sufficient for inclusion.] It seems that #1 excludes #2. I don't think #2 is bad, and it'd streamline the guideline in some ways, but I doubt it fixes anything, and if the problem some in ITN raised is a lack of objective standards, then I don't see how #2 addresses that. SamuelRiv (talk) 00:33, 8 October 2024 (UTC)[reply]
    Option 2 eliminates any consideration of significance, leaving only the quality and amended update requirements. Under that option, any article that is of sufficient quality and has two new paragraphs or five sentences added about a recent event would qualify for ITN. voorts (talk/contributions) 00:56, 8 October 2024 (UTC)[reply]
    Doesn't that just punt the question of "is this notably internationally groundbreaky newsy enough for ITN" completely to the ITN editors, by omitting it entirely? They'll still have to discuss it. I know there's no fixed notability thresholds now, so it's not technically any worse, but it wouldn't be any better either. And as the problem still exists, wouldn't someone just say in three months, "why don't we have a minimum standard for notability?" I guess at least if you have no notability section, it's a blank slate so that next time ITN can hammer out a more robust solution? SamuelRiv (talk) 01:24, 8 October 2024 (UTC)[reply]
    @SamuelRiv It would work exactly the same as the recent deaths section does now; there would be no discussion of extra notability beyond what is necessary to avoid an WP:AfD nomination, and any arguments about significance would be discarded for consensus purposes. Mach61 01:29, 8 October 2024 (UTC)[reply]
    Old-era-style significance arguments that don't attach to the remaining and amended criteria wouldn't contribute to consensus and such activity wouldn't be able to prevent posting. Notability standard is over at WP:N. A five-sentence addition to a preexisting article about a notable topic would be judged using the actual encyclopedia criteria for content, primarily WP:RECENTISM. If the recent expansion has overburdened [the article] with documenting breaking news reports and controversy as it happens, it fails both update and quality criteria, because that newly added content should be editorially addressed through removal, so there's no ITN candidate to be had. There's no "well, recentism is bad, but it's really subjective" in RECENTISM, or "it's important to summarize, but it's highly subjective whether something has been summarized or not" in WP:SUMMARY, and there's no "the question of who is responsible for achieving consensus for inclusion is a highly subjective matter" in WP:ONUS, etc. Good judgement is required when editing and it's easy to see when it's absent. It's only in ITN discussions which operate on a parallel plane divorced from recognizable best practices that things can be subjective. It's time to put Wikipedia back into ITN. Failing that, ITN is a foreign body. —Alalch E. 01:54, 8 October 2024 (UTC)[reply]
    Changing vote to Oppose both in response to voort's comment that This proposal would completely replace the current [subjective] criteria (in response to question of how this amends the existing text). This proposal seems to want to address existing complaints by disregarding the reality of discussions around it, from my impression of the ITN talk samples given in this RfC. As I noted before, there may be some argument for tearing it all up and hoping that what is later written will work better for ITN, but if that's the plan then just say it. SamuelRiv (talk) 16:33, 8 October 2024 (UTC)[reply]
    I'm fine saying that that's the plan. For option 2, the goal is to eliminate the subjective significance criteria entirely. Content should not appear on the Main Page based on subjective impressions and local consensus. Option 2 would require ITN discussions to evaluate whether a new contribution about a current event meets NPOV. In my view, if an editor makes a due, well-written and sourced contribution about a current event to an article that meets ITNQUALITY, that should suffice for ITN. The added benefit of forcing ITN to focus on due weight is that it would become a built-in system to clean up event-cruft. voorts (talk/contributions) 00:12, 9 October 2024 (UTC)[reply]
    There is a big difference in what is DUE in the context of an individual article and what is DUE in the context of the main page of a general purpose encyclopaedia. Thryduulf (talk) 00:22, 9 October 2024 (UTC)[reply]
    I would think most contributions about recent events that meet this criterion, as well as WP:ITNQUALITY, would be as due for inclusion on the main page as most DYK hooks. voorts (talk/contributions) 00:37, 9 October 2024 (UTC)[reply]
    Add Oppose 3: ITN is not the cause or the propagator of wp:recentism and wp:notnews. I am confident that the creators of Mike Pence's fly were not motivated by the existence of ITN. To address recentism/notnews would require a concerted wp-wide awareness of how to pre-evaluate the historical context of current events articles (i.e. 10-year-test, and more), how news is a primary historical source, and how often news events may be better presented in context of existing articles rather than entirely new ones. SamuelRiv (talk) 17:05, 13 October 2024 (UTC)[reply]
  • Oppose both ITN's purpose has been to feature high quality WP articles that happen to be in the news, with 9/11 the catalyst for its formation. To that end, ITN has always been curated similar to the other main page sections (like DYK and TFA) to avoid systematic bias that would otherwise favor English-language or Western (US and UK primarily) news coverage. It has been operating fine until the last few years, which I believe is tied to the fact we have problems with trying to keep WP:NOTNEWS in check across WP, with far too much detailed coverage of news events happening on WP (indeed, this is what Wikinews is supposed to do, not Wikipedia). The impact on ITN is that some editors want to see more news coverage, rather than see quality articles that are in the news, which leads to editors creating articles on events that lack enduring coverage. Dealing with NOTNEWS is a separate issue beyond this, but it should be addressed before fundamentally changing the purpose of ITN. To the specific proposals, Option 1 would end up affirming the systematic bias that would imbalance coverage of US and UK news (particularly politics), as well as discriminate against less "popular" news items like medical and scientific discoveries. And Option 2 would effectively be the same, with now systematic bias affirmed by editor bias that would give far too much focus on US and UK topics. Both also discourage the quality aspect, which has always been the primary requirement for ITN and for having the section on the main page in the first place. It would be far better to make sure what the purpose of ITN, determine if there are issues with getting nominations in the first place (which hasn't been done), and then determine if changes to the significance criteria are needed. --Masem (t) 00:57, 8 October 2024 (UTC)[reply]
    @Masem
    • Option 1 would end up affirming the systematic bias that would imbalance coverage of US and UK news How? Prop. 1 doesn't even specify that the front pages be printed in English, much less in the anglosphere.
    • Both also discourage the quality aspect Prop. 2 literally makes quality the only relevant factor in posting.
    Mach61 01:25, 8 October 2024 (UTC)[reply]
    While that is true, the bulk of ITN candidates overall have been based on English-based sources, with maybe one or two stories every few months based on foreign langage ones. Until we also get over the editorial bias that comes with systematic bias (that most of the editors here are English-speaking and primarily read English sources, and thus have more interest in those topics) that would still be prefferentially favor the US and UK stories. And Prop 2 basically just eliminates the media bias for the systematic editorial bias of what interests editors the most rather than what best reflects an encyclopedia. ETA: We already have demonstrated problems with editor systematic bias via the issue with recent death blurbs, where famous and popular deaths get a huge wave of supports without concern for quality, while trying to get actually good quality BLPs of major figures is very difficult. I know this discussion is not covering recent deaths, but it is part of the same ongoing problems that ITN has had in the last several years. — Masem (t) 01:38, 8 October 2024 (UTC)[reply]
    On geography bias: How is the bias that would exist under Prop. 1 (not disputing its existence) be any worse than what currently exists? Certainly, in absolute terms more articles about the nonwestern subjects will be posted; that seems more important than the ratio of western/non-western posts. Seems like you're making the perfect than the enemy of the good.
    On Prop 2 basically just eliminates the media bias for the systematic editorial bias of what interests editors the most rather than what best reflects an encyclopedia. Again, the "perfect v. good" dynamic comes into play. All the subjects ITN already posts will be posted, its just that more events will be posted alongside them if Prop. 2 passes. Why is this so bad? I can give one very good reason why increasing the total number of articles posted would be good, namely incentivizing editors to improve them up to the quality standards without worrying if their efforts will prove fruitless. I really don't think any possible PR damage from fluff being posted will outweigh that. Mach61 17:03, 8 October 2024 (UTC)[reply]
    With the current approach, we can easily combat geography bias, making sure that we have reasonable means to include stories outside Western regions that fall below the fold, typically disasters that happen in third-world countries. Prop 1 would create too much weight on what stories get repeated the most in national headlines, and a fundamental issue is that, not every headline story in newspapers makes for a good WP topic or even appropriate for inclusion on WP. We are looking at topics with long-term, enduring coverage, and the bulk of what newspapers feature on front pages are day-to-day events that may deserve a line or two update in an existing article, but not the endless dissection of news topics that we are currently generating in many places.
    Discussions below explain why Prop 2 is a terrible idea, because that would allow anything that has an update from being in the news to be included, and that would mean tons of celebrity stories, pop culture elements, product unveilings, and so on.
    We would like to increase the number of posts but I am pretty confident this is more due to the problem of low number of nominations to start (which points to more a volunteer process to get more topics nominated), many nominations present poor quality articles (which includes article that rely too heavily on reaction sections to carry the weight) and the fact that many nominations are news events that fail NOTNEWS in the first place (such as the initiating blocking of X in Brazil story). Most of this comes from righting the entire ship when it comes to NOTNEWS and getting editors back to writing encyclopedic articles that happen to include current events. Once that is re-established, then it should be easier to tackle what we can do to encourage more nominations to ITN. — Masem (t) 12:27, 9 October 2024 (UTC)[reply]
    Echoing what Masem says here, I do believe the NOTNEWS issue is massively understated when it comes to ITN. Quite frankly, there is way too little consideration for NOTNEWS across the entire site. This basically puts any new article into play, no matter how trivial. I'll just provide an example from my area of expertise. Last year, 8 tropical systems in the Atlantic had individual articles written on them, four of them fairly insubstantial and with limited impacts. That said, these articles are each well-sourced, with at least 30 citations each, and are well-written. If your priority is well-written articles, hey, I can see how you'd like that. But these are relatively mundane weather events all things considered, and generally lack long-term impacts. Are these articles that the readers are generally looking for? Do we need to feature these articles beyond those which are generally features at ITN? I'd say no. DarkSide830 (talk) 01:44, 8 October 2024 (UTC)[reply]
  • IMO, this is one of the problems with ITN - this "gatekeeping" of excluding systemic bias. It actually makes ITN its own walled garden, and elevates things that may be of less interest or importance to many readers, but adds them to the main page, because ITN thinks it is important. Natg 19 (talk) 01:55, 8 October 2024 (UTC)[reply]
    • So you should be then asking TFA and DYK to be more focused on what we thing readers "want" rather than to demonstrate what the best work that WP can produce, to align with this. This is, of course, a very bad proposition for obvious reasons. — Masem (t) 02:18, 8 October 2024 (UTC)[reply]
I don't know about other main page projects. But where does it say that "Wikipedia must fight systemic bias"? To me this is a WP:RGW situation. ITN should show what is "in the news", whether that is a lot of US/UK news or not. If there is more of a certain type of news, so be it. Natg 19 (talk) 05:29, 8 October 2024 (UTC)[reply]
The essay WP:BIAS states that the systematic bias created by the media and editors is one that falls under NPOV, in that we should not have any preference or deference towards topics due to what area of the world they occur in. So the approach to the selection of topics featured at TFA and DYK are geared around avoiding excessive preference towards one specific region, and thus have coordinating admins that work by consensus to judge what topics should and when they appear. ITN is meant to feature quality work on WP on topics that happen to be in the news, not merely to be a news ticker, and thus requires more thoughtful selection and consideration for what topics should appear rather than "its in all the headlines" Masem (t) 12:11, 8 October 2024 (UTC)[reply]
And Oppose 3, because I think the issues at ITN are not around it's format nor are something that can't be fixed, but that to fix ITN starts with fixing the problem around NOTNEWS across all of WP. (this both deals with when it actually appropriate to create articles on new events, how much to write about new events to fit into WP's summary style, and the net quality of new event articles) I am not blind that there is discourse at ITN, but it is not ITN that is the source of it. With NOTNEWS as the problem, there is a fair amount of "crap in, crap out" aspects at ITN, fundamentally not a problem with ITN itself. So eliminating ITN makes little sense. Masem (t) 21:29, 10 October 2024 (UTC)[reply]
  • Support either 1 or 2, with a preference for 2. I am a current participant at ITN, and do agree with a lot of Alalch E.'s concerns. Natg 19 (talk) 01:55, 8 October 2024 (UTC)[reply]
  • Support #3, oppose the other two. The first would make many currently-ITNR items unpostable, and the second would be even sillier, viz Meta Platforms would be postable since there's a small update about its recently-demoed augmented reality glasses (such a nomination has no chance of passing ITN right now). Banedon (talk) 02:02, 8 October 2024 (UTC)[reply]
    The quality requirement can be increased, and even then, that update currently doesn't pass the bar. Aaron Liu (talk) 11:32, 8 October 2024 (UTC)[reply]
    I can easily add a couple more sentences, thereby hitting the threshold. Banedon (talk) 15:12, 8 October 2024 (UTC)[reply]
    At which point it falls back to regular editorial processes, and it would be weighed against WP:NPOV and WP:RECENCY. Thebiguglyalien (talk) 18:38, 8 October 2024 (UTC)[reply]
    Does that not indicate the proposed amendment is not working? Banedon (talk) 23:36, 8 October 2024 (UTC)[reply]
    It's the whole point! There are established practices for applying policy and following sources when working with content, but it seems that most ITN editors don't even know these practices exist, let alone have experience applying them. Just look at some of the horrified responses from editors who are more experienced with higher-end content writing and reviewing in the recent close review. The rest of the community is trying to tell ITN that its "this feels like it's an important subject" is not welcome on Wikipedia. Thebiguglyalien (talk) 00:07, 9 October 2024 (UTC)[reply]
    I don't see your point. Implement this change, and I can add a couple of sentences to Meta Platforms and get it featured, which you seem to think is a bad idea. But it's this change that allows for the nomination. You can't oppose the nomination either on policy grounds (since it explicitly passes). Assuming you still think it's a bad idea to feature this, then you must argue that "this policy doesn't work", ergo, one should oppose the policy now. I don't see how what you wrote is relevant to this train of logic. Banedon (talk) 02:26, 9 October 2024 (UTC)[reply]
    We decide whether the update conforms with WP:NPOV, the same way we do with any other article. If you're adding content to an article when sources about the article's subject don't indicate that it's significant to that subject, then you're doing it wrong and another editor would be justified in removing it. This is the same thing I tried to explain to you at Talk:Benevolent dictatorship not too long ago. Thebiguglyalien (talk) 02:43, 9 October 2024 (UTC)[reply]
    Are you suggesting that adding information about Meta's upcoming AR glasses would violate NPOV? Banedon (talk) 02:49, 9 October 2024 (UTC)[reply]
    WP:PROPORTION, specifically. Thebiguglyalien (talk) 02:52, 9 October 2024 (UTC)[reply]
    I'd say it's a tall order arguing it's undue, but even assuming it isn't, how does this policy stop one from nominating iPhone 16? Banedon (talk) 03:03, 9 October 2024 (UTC)[reply]
    iPhone 16 is a really weak article, and I'd want to see a lot of work done on it before approving it for the main page. But if that's done, and you can find multiple reliable independent sources that provide significant coverage for the release? Then the subject is notable, and it's in the news. I see no grounds to oppose it at that point except gut feeling. And gut feeling is not a reliable source. Thebiguglyalien (talk) 03:15, 9 October 2024 (UTC)[reply]
    If you genuinely believe that featuring iPhone 16 on the main page is conceivably a good idea, then we disagree on a fundamental level and there's nothing more to discuss. Banedon (talk) 03:39, 9 October 2024 (UTC)[reply]
    The condition is that there's enough information for a great article. We merged a ton of articles about Samsung phones a while ago. Aaron Liu (talk) 12:34, 9 October 2024 (UTC)[reply]
    Nothing in either of these proposals requires there to be enough information for a "great article", it just requires there to be a few sentences of information that is DUE for inclusion on an article about a notable topic. Nobody can argue in good faith that the release of a new iPhone model is UNDUE for inclusion on the iPhone and List of iPhone models articles. Thryduulf (talk) 12:44, 9 October 2024 (UTC)[reply]
    Ah, I get it now. I don't think the iPhone 16 has enough stuff for two paragraphs, though I agree that the quality barrier should be increased, as it is currently satisfied with mere sentences. Aaron Liu (talk) 16:55, 9 October 2024 (UTC)[reply]
    iPhone 16 currently has 150% the median number of words as the median Wikipedia article, and 325% as many refs as the median article. WhatamIdoing (talk) 18:00, 9 October 2024 (UTC)[reply]
    That's not a good measure for absolute quality, plus Alien also clarified that only parts added into an existing page count, which I believe is good since anything of encyclopedic value is placed in context. Aaron Liu (talk) 21:29, 9 October 2024 (UTC)[reply]
    Sure, you could define 90% of Wikipedia articles as being substandard, if you wanted to, and sometimes people write five thousand words with 50 citations of pure garbage (just ask any English teacher).
    But it's also possible that "mere sentences" is exactly what most Wikipedia articles are, and that expecting ITN, or the Main Page generally, to only link to articles that are statistical outliers in terms of how many "mere sentences" they contain would be unreasonable.
    BTW, the numbers for the middle 50% of Wikipedia articles are:
    • 123–782 words
    • 5–29 sentences
    • 2–9 refs
    • 12–46 links
    Think about that the next time you see a new article rejected because it "only" has the normal number of refs. Wikipedia is not Lake Wobegon, and we should not expect all the articles to be above average. WhatamIdoing (talk) 03:53, 10 October 2024 (UTC)[reply]
    I don't expect that. I expect that we feature quality articles on the main page. Aaron Liu (talk) 11:39, 10 October 2024 (UTC)[reply]
  • Oppose both, 2 strongly. ITN does need to change, but I'm unconvinced that either of these proposals will fix the issues without introducing more, bigger ones. With a limited number of slots available there has to be some sort of gate to stop it being overwhelmed by niche subjects - the current problem is that the gate isn't letting through enough things not that it exists at all. Proposal 2 would do away with the gate entirely which does resolve the problem but only at the cost of worsening the systematic bias and losing the truly notable updates in a flood of minor ones Proposal 1 just throws away all the context of it being on the main page in favour of the context of individual articles - a five sentence update about a newly manufactured "feud" between Kpop stars is entirely encyclopaedic and DUE in those star's articles but not encyclopaedic in the context of the main page of a global, general purpose encyclopaedia. It's not just entertainment topics that will suffer from this - minor political scandals in especially the US and UK will have all the same issues, as will literally dozens of sports results every week (if not more and more frequently) - certainly the result of every single soccer league in every country that has an article (and in the UK at least that goes down into the double digit tiers), things like the opening of (or major milestones in the construction of) a new railway station, the entry into service of a new type of train, plane or cruise ship, weekly (or more frequent) rocket launches, the launch of a new model of car or smartphone, each stage of a criminal investigation and trial, mayor elections in medium and larger sized settlements, etc, etc. Given that most of the content added to the English Wikipedia is written by English-speaking western white men that will automatically bias the content to the topics updated by those editors. Thryduulf (talk) 02:20, 8 October 2024 (UTC)[reply]
    I doubt that your K-Pop example would be considered a due addition or that many of the sources reporting on such feuds are reliable. In any event, I think editors debating over that rather than some subjective notion of what mostly white men consider to be "significant" would be infinitely better and actually allow for a true evaluation of consensus. voorts (talk/contributions) 13:48, 8 October 2024 (UTC)[reply]
    Again, part of the issue with proposal #2 is assuming these concerns are addressed at the article level before a nomination occurs, and as we've seen with some nominations in the past (there seems to be at least one NEVENT concern a week, for example), we can't assume this. DarkSide830 (talk) 17:07, 8 October 2024 (UTC)[reply]
    While the K-pop example may or may not be considered DUE (it's not a topic area I edit in), every other example I gave would definitely be DUE and I didn't think of things like battles, deaths, music and book releases, weather events, sports player transfers, candidates entering or leaving contests like 2024 Conservative Party leadership election or Big Brother, and many, many other examples.
    Separately, I also Oppose option 3 unless and until there is a consensus about to replace it with. Personally I think ITN is fixable and the current problems are not a reason to throw it away. Thryduulf (talk) 20:30, 8 October 2024 (UTC)[reply]
    Why are things like battles, weather events, and sports trades that could receive two due paragrpahs in an article any less appropriate for the front page than the current ITN entries, such as a bus crash (which in my view probably fails NEVENT and likely won't have any sustained coverage beyond this news cycle) and a gang assault of a town in Haiti? To answer my own question, because ITN operates on an extremely subjective significance standard that reflects whether ITN regulars think something is important. Even if options 1 or 2 aren't perfect fixes, nobody has proposed anything better and we should try something. voorts (talk/contributions) 22:16, 8 October 2024 (UTC)[reply]
    It's not that battles, etc. are inherently unsuitable for the main page as a class, but there are so many of them that if all of them were to be posted (as these proposals envisage) then the spell each event would have on ITN would be a matter of hours when, in an ideal world, it should average probably 2-4 days.
    Changes need to be made to ITN, almost everybody agrees with that, but that doesn't mean we should try something that will make things significantly worse (in multiple regards) just because it would be bad in a different way to present. It's much, much better to spend the time to get the right solution that will return ITN to the working state it used to be in rather than to implement something, anything, right now, regardless of whether it will result in a functioning ITN or not. Thryduulf (talk) 22:45, 8 October 2024 (UTC)[reply]
    Why should events last 2-4 days? Ideally, I feel that events should roll off of ITN in 1-2 days (earlier to me is not a problem), which matches with how the other items on the main page work. This rarely happens now at ITN. Natg 19 (talk) 00:30, 9 October 2024 (UTC)[reply]
    2-4 days on average is about the length of time that events of the significance we should be posting remain newsworthy on average. Some die quicker, others slower, partly depending on what unscheduled events happen. Something of the significance of e.g. Hurricane Helene or the UK general election should remain for a couple of days rather than be pushed off in hours because a third tier football team won a title, the leader of the opposition party in South Australia resigned, two musicians independently released an album, a long-running character in a soap opera had their last episode, the King of the Netherlands made a state visit to South Korea, a horse won race, a Formula 1 driver won a race, a NASCAR driver won a race, a rally driver won a race, a motorcyclist won a race, an actress won an Italian reality TV show, a dancer won New Zealand's got Talent, an inquiry into a minor political scandal in Bavaria was announced, a new tram extension was opened, a new model of smart phone was released in Brazil, the date of the next general election in Ireland was announced, a cruise ship broke down in the Caribbean forcing the cancellation of two sailings, a small cargo plane crashed at an airport in Kenya, and the first of three rounds of voting for a provincial governor in Indonesia took place. All of those could plausibly have five or more sentences of well-written prose updated with the same 1-2 days. Thryduulf (talk) 01:38, 9 October 2024 (UTC)[reply]
    I touched on this below. If something is important enough to stay on for several days, then there are going to be new updates that warrant a new blurb or an ongoing slot. Thebiguglyalien (talk) 01:58, 9 October 2024 (UTC)[reply]
    Really? That isn't going to be the case for the majority of national election victories, major sports championships, Nobel Prize awards, Oscar awards, etc. Thryduulf (talk) 02:05, 9 October 2024 (UTC)[reply]
    We follow the sources. If they don't give it extended time, then neither do we. You decided that those are the important things that should stay up, but you are not a reliable source. Thebiguglyalien (talk) 02:09, 9 October 2024 (UTC)[reply]
    Newspapers, etc continue to cover those events for several days with additional reaction, etc. that doesn't generate a new blurb or make it suitable for ongoing. I am not a reliable source, but I took that list of examples from WP:ITNR which consensus has determined are things important enough to always post under the status quo, which we both agree is too conservative. My point is that there needs to be some filter because otherwise lifetime will be measured in hours or minutes, and that at least equally undesirable to the status quo. We can disagree about how many days the ideal length of time is, but it is unquestionably somewhere in the 1-7 range. Thryduulf (talk) 02:19, 9 October 2024 (UTC)[reply]
    What about implementing some form of WP:ROUTINE at the ITN selection level? We already acknowledge many newsworthy topics aren't eligible as standalones or contribute to notability of a larger topic due to being too...NOTNEWSy. Surely a similar concept could be hammered out for which types of otherwise-DUE article updates are "too routine" for the main page? JoelleJay (talk) 02:29, 9 October 2024 (UTC)[reply]
    That is what happens currently. It's just that there is a disconnect between opinions about what is and isn't "NOTNEWSy" Thryduulf (talk) 02:42, 9 October 2024 (UTC)[reply]
    It implicitly happens currently, as part of gauging "significance", but a structured definition of "routine" would preempt some of the problems you and others anticipate occurring under both proposals. JoelleJay (talk) 21:51, 9 October 2024 (UTC)[reply]
  • Oppose both per Masem. APK hi :-) (talk) 04:24, 8 October 2024 (UTC)[reply]
  • Oppose 2: per my comment in discussion. Rollinginhisgrave (talk) 05:38, 8 October 2024 (UTC)[reply]
  • Support 3 which is shut down ITN unless the regulars can self-police and stop their endless bickering. ITN is evanescent and the digital equivalent of bird cage liner. Its only value is to promote article improvement, but that happens best through normal editing to improve articles of interest rather than desperate efforts to get an article on the main page, which is all rapidly forgotten by everyone, especially our readers. I happen to favor creation of articles about new topics, but improving articles should always be prioritized over endless and contentious debates about what should be on the main page for a "little while". All that energy should be deployed to more long lasting goals. Cullen328 (talk) 05:59, 8 October 2024 (UTC)[reply]
  • Close down ITN per Cullen. Duly signed, ⛵ WaltClipper -(talk) 13:44, 8 October 2024 (UTC)[reply]
  • Oppose 1/2 as per Masem. Sharrdx (talk) 16:55, 8 October 2024 (UTC)[reply]
  • Oppose 1 since, besides getting rid of (some of) the worst parts of ITNC, it also gets rid of one of the few parts it gets genuinely right - things like the Turing and Hugo awards are big news in their fields and usually well-updated, but they're hardly front-page-of-traditional-print-newspapers material even in one country. And what does multiple mean, anyway? Two? Five? Two if it's the United States and China, five if it's Nauru, Mauritius, Andorra, Transnistria, and Belize, or Norway, Sweden, Finland, Denmark, and Iceland?
    I'm somewhere between #2 and #3. I starting reading Wikipedia when the main page looked similar to this. I can easily see replacing the ITN box with a list of links to articles recently updated from the news, either to the article itself if it's new, or to a section like HMNZS Manawanui (2019) § Sinking if it's an update. (We can add anchors if that's unclear, so that we could link, say, John Hopfield § Nobel Prize instead of John Hopfield § Awards and honours.) I don't think full-length blurbs are viable if we eliminate WP:ITNSIGNIF entirely, and this also lets us get rid of the inevitable bickering about death blurbs. —Cryptic 17:20, 8 October 2024 (UTC)[reply]
  • 3, 1, 2 in that order of preference, but find a consensus, oppose no change. Any of these proposals are worth trying, and certainly better than doing nothing; my preferences between them are slight.

    Proposal 3, abolish ITN -- meaning, remove it from the main page (TFA can expand to fill the empty space) -- is the right first step IMO, because Wikipedia should get its ITN act together before rolling out a new ITN on the main page. That means experimenting with the format/selection criteria, having a "dry run" of a couple weeks or a month of nominations, then examining whether the format/selection criteria works well, before launching it on the main page. That would be ideal.

    Proposal 1 (as proposer) replaces the subjective judgments of editors for the objective data of current event WP:RSes -- e.g. top-tier mainstream media aka "papers of record." A news item is globally "significant" if it appears on the front pages of multiple countries' papers of record. There are free websites that compile the world's front pages, e.g. [28], [29], [30]. Website front pages are often personalized, but print front pages are not; those are intended for general audiences. We know that RSes agree something is "significant," of broad interest to many readers, if they put it on their print front pages. By looking at multiple countries, we can ensure a global perspective and protect against systemic or parochial bias.

    Proposal 1's criteria can be further tweaked: require only 2 front pages for broad inclusion, require more (3, 4, 5, etc.) for narrower inclusion. It can also be tweaked to further protect against systemic or parochial biases: e.g., require multiple continents, or one from each populated continent/area (e.g. N. Am., S. Am., Europe, Asia, Africa, Pacific); or, require it to be on the front pages in both the Global North and the Global South, or in both the Western world and the Eastern world; or, require multiple languages. We can ensure that news pertaining only to one country is globally significant by requiring that it be on the front pages in countries (or continents, or regions) other than the country where the event took place. There are lots of ways to experiment with this -- and as I mentioned earlier, I prefer to pull ITN, do the experimentation, then re-launch it, hence my preference for Proposal 3 over Proposal 1. But with an objective, data-driven test for inclusion like Proposal 1, we would eliminate subjective arguments over what is "important" and what isn't.

    Proposal 2 is also a good idea and would certainly be an improvement over the status quo. However, my concern about 2 is that it would be over-inclusive; I think the revised update criteria would be met by very many articles, including most if not all of the WP:TOP25 articles (maybe out to the top 100 or more), and this would, in practice, turn ITN into a TOP25 clone (meaning: all popular articles about current events would be listed, rather than just the most "significant," as determined by RS). So I prefer 1 to 2. Still, if we did 3, we could experiment with Proposal 2 (and Proposal 1), and see how it panned out. If Proposals 3 and 1 don't have consensus, Proposal 2 -- essentially live experimentation -- would still be better than the status quo, which only results in endless arguments over editors' subjective opinions of importance, and an ITN that is in equal parts bizarre and stale. Levivich (talk) 18:24, 8 October 2024 (UTC)[reply]

  • Strong oppose both. I don't see how either of these would improve ITN or provide a better service to readers. Option 1 is hugely lowering the bar for what would be posted, and is unworkable anyway. What would count as a 'major national newspaper'? Front pages aren't really a thing any more as newspapers are increasingly online-first or online-only, and they customise their front pages based on geolocation. Option 2 is even more permissive, making everything that has a Wikipedia article somehow important enough to post in ITN given the most minimal update ITN allows. There's no way ITN/C could keep up with the torrent of de minimis items either of these proposals would allow. Nor would it be helpful to readers, who surely want a minimum level of importance for ITN, not a news ticker that posts the most trivial of items. ITN certainly has problems and could do with posting more items, but the problem is primarily getting quality updates, not the significance criterion. I also agree with Masem that there's a compliance issue with WP:NOTNEWS which has had knock-on effects on ITN. Modest Genius talk 18:25, 8 October 2024 (UTC)[reply]
    How is it that Front pages aren't really a thing any more when there are hundreds of them, and I'm linking to three different websites that show you them? They are most certainly still a thing, and print front pages are not customized. A "major national newspaper" is one that is (1) national rather than subnational in distribution, and (2) has the highest circulation in the country (or one of the highest circulations). Finally, something would not be "de minimis," by definition, if it was featured on the front pages of multiple nations' major newspapers. The whole point of looking at print front pages in multiple countries' major newspapers is to determine objectively if it is considered de minimis or de maximus by multiple top current events RS globally. Levivich (talk) 18:35, 8 October 2024 (UTC)[reply]
    Of course print front pages exist, but what newspapers put on them no longer reflects the most important events of each 24 hours. Instead it depends on what images are available, how the time of day the event occurs at lines up with the print schedule etc. On your other points, nations have very different sizes, and 'highest circulation' is a very different criterion than 'major'. It would exclude most quality newspapers, favouring tabloids full of scandals and celebrity gossip, which is a very bad idea. In some cases, the relevant data isn't publicly available (e.g. in the UK many newspapers ceased making their ciculation numbers public in 2020 or 2021). Modest Genius talk 16:07, 9 October 2024 (UTC)[reply]
    What newspapers put on their front pages no longer reflects the most important events of each 24 hours? I don't understand that: you're saying that newspapers put the most important news not on the front page, but somewhere inside the newspaper?
    And what do you mean by "lines up with the print schedule"? Are you saying newspapers don't all print in the morning? It's true that some newspapers have afternoon or evening print editions, but surely you'd agree that even those newspapers also have a morning edition? Are there any RS that say that newspapers no longer put the most important news on their front pages, and they don't print morning editions? When did this change?
    As for circulation and quality, sure they don't always match (e.g. Daily Mail is among the highest circulation in the UK), but I trust editors can figure that out and come to consensus about whether a particular source is an RS or not, as we always do. Levivich (talk) 17:17, 9 October 2024 (UTC)[reply]
    I think the main issue here is that most of the ITN regulars don't have any meaningful content writing experience, so they don't have a solid understanding of how we consider sources on Wikipedia. The "sources first" philosophy—critical to how Wikipedia works—is almost non-existent. Thebiguglyalien (talk) 17:53, 9 October 2024 (UTC)[reply]
    The traditional morning daily newspaper was printed overnight, so it could be delivered early in the morning. The press deadline might be around midnight, and then the printers spend several hours printing the papers. The papers might go to distribution at four or five in the morning, so it could be delivered to homes before most people woke up and to newsstands before commuters were underway. I suppose this is "printed in the morning" in the sense that 2:00 a.m. is "the wee hours of the morning".
    The evening dailies followed the same process back in the day, but offset, with papers being ready for the paperboys to deliver to homes as soon as school let out in the afternoon and to newsstands before the evening rush hour. Those were the ones that really got printed in the (daylight-hours) morning. WhatamIdoing (talk) 18:16, 9 October 2024 (UTC)[reply]
    Right, and both the morning and evening dailies print every 24hrs, and put the most important news from the prior 24hrs--since the last printing--on the front page. I'm surprised somebody would assert that it no longer works this way. Levivich (talk) 20:31, 9 October 2024 (UTC)[reply]
    Rather that "highest circulation", a better limit may be Newspaper of record. --Ahecht (TALK
    PAGE    )     20:26, 14 October 2024 (UTC)[reply]
  • Oppose both per Masem, Thrydulf, Modest Genius. Option 1 will not reduce discussion in practice - what's a major newspaper? What counts as frontpage (and no, no-one will check the printed frontpages, nor those newspaper aggregators)?) Option 2 would open the floodgates for the proverbial K-Pop break-ups, Taylor Swift concert tour updates, etc - it would not be an "In the News" section, but a "Recently updated articles" section. Option 2 would also re-open the gates for each RD being posted as blurb - so when it's not a Pop ticker, it would be an obituary. What I'm missing from the various discussions so far is: what is the "new" ITN section supposed to look like? Without a vision of what we want to achieve, the proposals don't really lead anywhere (and the fact that "abolish ITN" is even a third option - again without a vision of what should replace it, is telling in this respect). Khuft (talk) 19:54, 8 October 2024 (UTC)[reply]
    @Khuft @Khuft what's a major newspaper One that is heavily circulated and nationwide rather than local. An incomplete list can be found at Newspaper of record § Examples of existing newspapers. And no, no-one will check the printed frontpages Yes, they will, this heuristic already has some use at WP:ITNC, which makes sense because print front pages have limited real estate and aren't dynamic like online home pages. Mach61 00:52, 9 October 2024 (UTC)[reply]
  • Oppose proposals for now, status quo, no change. I haven't been following this discussion but I don't see that this is the way to improve ITN. Personally, I think ITN is important and should be expanded. I'm not sure what that would look like, but I think we're resisting the idea that everything in the 21st century is a feed, with social media, and a constant stream of new information. I think a reform to ITN would make it react faster and respond to change quicker. I appreciate the attempt by Proposal 1 to create a more specific set of criteria for inclusion and I think that's a good impulse, but I don't think the front page metric is what I would use. I think a metric based on something more rooted in verifiability and reliable sources would be useful. Andre🚐 20:44, 8 October 2024 (UTC)[reply]
  • Support 3 Shut down ITN as it has been dysfunctional for some time. Every other main page section functions comparatively smoothly, changing its content every day and presenting a reasonably encyclopedic variety of topics. ITN is chronically unable to do this and what it does manage to post is quite peculiar, seeming to be utterly obsessed by death, for example. Andrew🐉(talk) 22:39, 8 October 2024 (UTC)[reply]
  • Support 3, option 1 as second choice. Oppose 2 as this may too easily be gamed (or at least used) by projects, and could lead to very minor stuff like some county election or similar being posted, or some of the myriad of WP:NOTNEWS articles about minor incidents, knife attacks, ... which get created immediately and then deleted later as they turn out to be of no lasting significance at all. Having these articles is bad enough, having them on the front page would make things only worse. And then there is the endless opportunities this will give for companies or fans spamming the new release of song X, movie Y, game Z and smartphone QQQ. It's "in the news" and has some prose, but do we really want it on the front page? Please, no, never. Fram (talk) 07:14, 9 October 2024 (UTC)[reply]
  • Oppose 1 and 2. I don't think 1 will really work very well, and 2 is extremely problematic and will cause the main page of the whole site to be flooded with minor news updates which very few people will care about. Weak Support 3 since ITN has been dysfunctional for a long time now and I'm not sure if it can really be fixed at this point. I also find it unusual that this is the only section of the main page that isn't dedicated to quality content, instead focusing primarily on recent content. QuicoleJR (talk) 15:00, 9 October 2024 (UTC)[reply]
  • Maybe 3, maybe 1 with some provisions. Developing some guidelines covering broad news topics we generally consider "too routine for the main page" would really cut down on the concerns about celebrity and tech news being nominated.
    Something that could address the "bias problem" would be to have some slots that follow our normal qualification process, and then additional slots dedicated to the topics receiving major news coverage in specific regions of the world. These regions could rotate if it's too difficult finding acceptable articles for all of them each cycle.
    I do want to note that for all of the non-Wikipedians I know who regularly look at the main page, ITN and sometimes TFA/P are the only items they care about. I don't think anyone outside of Wikipedians even knows what ITN is "supposed" to be -- my friends certainly think it's just a digest of major world news topics. So if our main focus is to satisfy our readers, the emphasis should definitely be "significant encyclopedic topics in the news" rather than "quality articles covering topics that happen to be in the news".
    EDIT:If there's nothing to replace ITN with, then I don't really support #3. JoelleJay (talk) 22:03, 9 October 2024 (UTC)[reply]
    Off the top of my head I don't think specific regions would work. What comes to mind is something like floods in India that don't get posted because they happen during an Africa week, while equivalent floods in western Europe do get posted because we don't have a slot for that part of the world. We can't control when or where events happen and there will be times when by coincidence there is a disproportionately large or small amount of news from a given part of the world (e.g. if there is a major earthquake in California and a plane crash in Florida on the day of the US presidential inauguration then ITN is going to be heavily US-biased but not through systematic bias, ditto if the events all happen in Indonesia) Thryduulf (talk) 22:18, 9 October 2024 (UTC)[reply]
    Oh I meant we would have like a dozen semi-overlapping world regions but only 4 or 5 slots running at a time, plus a floating slot that could be filled when needed. Like "Middle East" and "Central Asia" might normally be combined but if there are candidates for both in a cycle we could split them using the floating slot. JoelleJay (talk) 23:05, 9 October 2024 (UTC)[reply]
    I'm not sure that would work either. What happens if there are three newsworthy events in the same part of the world at the same time? Thryduulf (talk) 23:48, 9 October 2024 (UTC)[reply]
    There's nothing stopping one of them from being in the main slots...and anyway we already have to make these judgment calls on which items are MP-worthy, I don't see how having dedicated spots for certain regions would change this. JoelleJay (talk) 03:06, 10 October 2024 (UTC)[reply]
  • Oppose both per Masem. Seems like we are trying to fix a problem that does not really exist.  Spy-cicle💥  Talk? 23:09, 9 October 2024 (UTC)[reply]
  • Oppose Proposal 3 Have there been any complaints from IPs or casual readers/visitors about what's included or excluded from the ITN template? If not, it seems a bit strange to see so many experienced editors in a tizzy over 4-5 ITN blurbs, along with a small list of ongoing events and recent deaths, appearing on the Main Page, while most casual readers and visitors don’t appear to have any major concerns with it at all. Is there a disconnect between the editing community and casual, everyday Wikipedia readers? It might be a good idea for WMF or whoever to put together a survey or questionnaire to gather feedback and hear from casual readers and visitors (especially those who aren't in the loop with the behind-the-scenes processes) about their thoughts on the main page of Wikipedia (including ITN, DYK, etc.) before we start "abolishing" anything. Some1 (talk) 23:48, 9 October 2024 (UTC)[reply]
    General readers seem to pay little attention to ITN. Posting of an entry at ITN makes little difference to the traffic for topics in the news as most of their readership comes from search engines such as Google. If such a reader did have some feedback, they would find it quite difficult to comment as Wikipedia is impenetrable for most of our readership and so we get little feedback on anything. Andrew🐉(talk) 06:26, 10 October 2024 (UTC)[reply]
    ... makes little difference to the traffic for topics in the news ...: Depends how you define little. For one recent death post of Eric Sievers (a non-household name), he died on April 10, was posted to RD on April 14, and received ~7,000 more views that day after trending down the previous days.[31] Not sure about the effect of a blurb, or a pictured blurb. —Bagumba (talk) 07:31, 10 October 2024 (UTC)[reply]
    7,000 is a tiny number for a global web site. A topic in the news such as Hurricane Milton will get much more traffic regardless of what ITN does. The top read article yesterday was Ratan Tata with over a million views. That was another recent death and it's a vital topic but its ITN nomination is mired in toxic discussion with the usual disparagement of "OLDMANDIES". Our readers just ignore this gatekeeping and flood past to read the article regardless. Andrew🐉(talk) 08:54, 10 October 2024 (UTC)[reply]
    7,000 is a tiny number for a global web site: That's 7,000 more views than the day before, and it had been in the news for days already. ITN can't make a topic more "intereesting" than it inherently already is, but it does bring it to a reader's attention who might not have been looking for it or even known about the news item. —Bagumba (talk) 10:41, 10 October 2024 (UTC)[reply]
    7,000 in one day is huge. See Wikipedia:Statistics#Page views: The median article gets one page view per week. 93% of our articles don't get 7,000 page views in an entire year. Even if you could attribute only a small fraction of that to the ITN listing, that would be a significant number of readers.
    There's another isolated bump on May 8th.[32] I wonder what caused that. WhatamIdoing (talk) 23:55, 10 October 2024 (UTC)[reply]
    It is all relative. One page for which I've been following page views is Big Bend (Florida), which normally gets about 100 views a day. On September 26 it received over 75,000 views, and the next day over 80,000. There is nothing about that article that would qualify it for ITN, but rather the coast/region was mentioned in news reports as where Hurricane Helene would reach shore. Predicting when or if an article will experience a huge surge in views is not very fruitful, but I doubt placement in ITN is a major factor. Donald Albury 16:16, 13 October 2024 (UTC)[reply]
    @Andrew Davidson, what's your data source for the claim that General readers seem to pay little attention to ITN. Posting of an entry at ITN makes little difference to the traffic? Have you done chronological comparisons via https://wikinav.toolforge.org/ (which identifies the sources of traffic)? Or is this just a personal impression?
    Wikinav is currently displaying August's data. You could pull the August data for September's ITN articles today, and see how their pre-event traffic compares to their post-ITN traffic. September's data will probably be posted very soon. WhatamIdoing (talk) 23:46, 10 October 2024 (UTC)[reply]
    I've started looking at WikiNav which seems an excellent tool but it's a month in arrears, as you say. But the issue seems to be what is meant by "little attention". You seem to think that 7,000 views is huge. For an obscure DYK topic, it's good exposure. For a global news story with a potential audience of billions, it's functionally zero.
    I'm quite concerned that the traffic on Wikipedia articles about prominent topics is generally much lower than it might be. I started the article about the Google Knowledge Graph. That has now evolved to present AI summaries for searches and these tend to push Wikipedia under the surface. When there's such competition, you have to run hard to keep up. ITN is literally an amateurish effort to present the news and, with some professional polish, it could be so much better.
    Andrew🐉(talk) 09:57, 13 October 2024 (UTC)[reply]
  • Oppose Proposal 3. Deleting ITN from the main page would significantly lower the utility of the main page for me. I see no upside to myself our our readers by removing it. The main page is, arguably, the only important portal, and removing ITN from it would make the main page significantly less useful and more boring. Whatever problems ITN has on the back end should be fixed in other ways, without deleting the entire ITN section of the main page and without deprecating the entire ITN page/WikiProject/whatever it is. –Novem Linguae (talk) 00:04, 10 October 2024 (UTC)[reply]
    The only news sources my partner actively visits are Slashdot and ITN...removing ITN without replacement would be a devastating blow to his informedness. JoelleJay (talk) 03:15, 10 October 2024 (UTC)[reply]
  • I actually think a reset of ITN would be a good idea. Most of the time what's featured on ITN doesn't really match what is actually in the news. I like recent deaths, but it's needlessly adversarial (there's no need for people to "oppose" every request, just have a running list of things that still need fixing or something). I do think Wikipedia should have news on the front page, but ITN in its current iteration is both toxic and not doing a good job. Legoktm (talk) 04:19, 10 October 2024 (UTC)[reply]
    • ITN is not meant to reflect what is in the news (ITN is not a news ticker), its meant to feature high quality articles about topics that are in the news, as to match with all other main page content as a reflection of WP's best work. When it is flipped to be trying to feature news on the front page, we get problems with poor quality articles that may likely fail NOTNEWS in the long term. And NOTNEWS itself means we should not have this unhealthy focus on current news, itself a major problem across WP. — Masem (t) 12:34, 10 October 2024 (UTC)[reply]
      To me, hearing someone say "ITN is not meant to reflect what is in the news" confirms my belief that ITN is not doing what it's literally called, and that's a problem. I feel like ITN has invented its own unique sense of what is newsworthy and what isn't, and it seems very out of touch with what basically everyone else considers newsworthy. And then that just leads to toxicity (some actual quotes from ITN/C right now: "OLDMANDIES", "unimportant country") because people aren't on the same page. Idk, a news system that only tells people about hurricanes after they make landfall seems pretty broken.
      The semi-joke that I've been telling people is that people who want to comment on ITN/C (and breaking news things) should first have to take 6 months of journalism school. Someone recently took me more seriously and said we should have a MOOC for it. I don't know what the solution is, but I am supportive of a reset. Legoktm (talk) 15:56, 10 October 2024 (UTC)[reply]
      The purpose of ITN has always been to showcase quality articles related to topics that are in the news, not to be a news ticker. Many people have complained about this over the years but the very few of them who have proposed to change it have always failed to get a consensus to do so. Thryduulf (talk) 15:59, 10 October 2024 (UTC)[reply]
      Yes, Masem said exactly that. I understand what you both think the purpose/goal of ITN is, I am saying that I don't think that's a good goal, because it is disconnected from everyone else considers to be "in the news". (And all the other things I said.) Legoktm (talk) 16:16, 10 October 2024 (UTC)[reply]
  • Whatever is done with ITN, for God's sake we should not remove a section from the main page unless we actually have an idea for something to replace it with. jp×g🗯️ 06:30, 10 October 2024 (UTC)[reply]
    Other sections such as the Featured List and Featured Picture appear intermittently and so the main page structure is not rigid. And we have multiple ideas for replacement in draft below. Andrew🐉(talk) 09:11, 10 October 2024 (UTC)[reply]
    Pish. We can come to a consensus here to remove it, and not actually remove it until a followup RFC figures out what to put there instead. (Plus, we actually have plenty of ideas, stated right in this RFC, for what to replace it with.) —Cryptic 16:24, 10 October 2024 (UTC)[reply]
  • Support option 3 per Alech E. and cullen, who both make cogent arguments; those who argue that we should keep it due to 9/11, or because some not broke-don't fix it thing, miss the point that it is unencyclopedic material. If anything, it should be added to WP:NOTNEWS, rather than lauded on the main page as the example of Wikipedia's finest work at, err, trying to out-NBC/BBC. Per Alech E., also support 2 secondarily. Bring on the bludgeoning!SerialNumber54129 18:48, 10 October 2024 (UTC)[reply]
  • Support 3 per what... everyone else said above. The Main Page should be reserved for the English Wikipedia's best work, whether that be Featured articles, lists, pictures, and DYK which is about new and improved articles. ITN is none of that. As much as I understand why it should be kept, this an encyclopedia, not the BBC. The Main Page is for Wikipedia's best content (For On this day, most articles featured there are pretty good. On this date, October 10th, 4 out of 5 are either good or featured). ITN also clashes with the fact that good articles are stable, and topics in the news are the exact opposite. win8x (talking | spying) 19:55, 10 October 2024 (UTC)[reply]
    Oh and also, by being on Wikipedia, it requires consensus. As a result of this, some news only appear after a full week on the Main Page, when it is no longer "In the news". win8x (talking | spying) 22:08, 10 October 2024 (UTC)[reply]
    I think that some form of option 2 could work to only feature quality. GoodArticles are stable, yes, but quality articles can also be unstable due to expansion. Aaron Liu (talk) 18:36, 13 October 2024 (UTC)[reply]
  • Oppose 3 because I think ITN is clearly valuable on the page as is. No opinion on the other two; my sense from reading the front page is that the result of ITN is not broken even if the process feels broken from the inside, which is IMO an important distinction to make. Loki (talk) 21:14, 10 October 2024 (UTC)[reply]
    The fact that it looks fine from the outside is part of the problem in my opinion. The selective nature of subjects and the participants pushing their own POV about the topics that should go up are creating a warped news feed. And this weird obsession with counting how many people are dying to decide whether something is relevant adds a sensationalistic undertone to the final result. It's not just unhelpful, but it's a disservice to readers to give them a reflection of our own POVs about what subjects are "important" instead of an accurate overview of where there's new information. Thebiguglyalien (talk) 21:27, 10 October 2024 (UTC)[reply]
  • Support 3 Per Masem and Alach E. ITN causes more headaches than it is worth and has accelerated the growth of primary sourced news content that doesn't belong on Wikipedia. Traumnovelle (talk) 03:40, 11 October 2024 (UTC)[reply]
    @Traumnovelle: Masem !voted "Oppose 3". —Bagumba (talk) 06:01, 11 October 2024 (UTC)[reply]
    I know. He believes it can be reformed; I believe it is better off being removed in the current form. Traumnovelle (talk) 06:12, 11 October 2024 (UTC)[reply]
  • Strong Oppose removal of ITN as someone who created 2020 Belarusian protests and 2022 Oder environmental disaster among mamy others, there would be no way those articles would be even half as good if there was no ITN. They were breaking news when I created them, I nominated them to ITN which caused the article's to be expanded significantly with the help of many other editors. As events unfolded, these were also updated accordingly. If we get rid of ITN, we will miss the chance to improve and highlight many many articles, especially biographies which really should be cited. Aside from this, ITN does highlight often news events that otherwise go unreported in vast parts of the world. Abcmaxx (talk) 00:02, 11 October 2024 (UTC)[reply]
    This is the wrong section for the survey, think you wanted to put it in Wikipedia:Village pump (policy)#Survey (In the news criteria amendments) btw. Cowboygilbert - (talk) ♥ 02:03, 11 October 2024 (UTC)[reply]
Oops, moved now. Abcmaxx (talk) 09:41, 11 October 2024 (UTC)[reply]
  • Oppose all About the 1st proposal, blurbing only events "reported on the print front pages of major national newspapers in multiple countries" would be restrictive WP:CREEP in practice that would likely narrow our collaborative coverage and be difficult to consistently enforce. For example, some scientific or archaeological achievements of the magnitude of the discovery of malacidins or new poems by Sappho wouldn't likely appear on the print front pages of major national newspapers, being instead tucked somewhere inside at best. Proposals 2 and 3, with their abolition of ITNSIGNIF and removing ITN, are throwing the baby out with the bathwater. Brandmeistertalk 14:44, 11 October 2024 (UTC)[reply]
    Another example of "ITN should list what I think is important, not what RSes think is important." Levivich (talk) 17:58, 11 October 2024 (UTC)[reply]
    We don't blindly follow RS' choices per WP:NOTNEWS, but apply editorial judgement. Double filtration purifies news reporting as well after the first stage of making into RSes... Brandmeistertalk 20:20, 11 October 2024 (UTC)[reply]
    The reliable sources are writing newspapers for the purpose of making a profit by selling newspapers that portray the news in a manner favourable to the political views of their owner(s) and their target demographic in a specific geographical region. We are writing a neutral, general purpose encyclopaedia for a global audience. What makes you think that what is important for one would (or even could) match what is important for the other? Thryduulf (talk) 20:57, 11 October 2024 (UTC)[reply]
    And this is why I support Proposal 3: what you both are describing -- Wikipedia editors decide what's important and put it on the front page of Wikipedia -- is not something that Wikipedia should be doing. In articles, when we decide what to include, we base it on the prominence given to that aspect or viewpoint by reliable sources, not based on what aspects or viewpoints editors feel are most significant. That's core NPOV policy, a cornerstone of this encyclopedia. That we would reverse it on the main page? Unthinkable. I have far, far more trust in the journalists and editors of the world's profit-seeking major news media than I do in random people on the internet. That's why we have V, NPOV, and NOR: specifically so the encyclopedia doesn't contain what its volunteers think about something, but rather what reliable sources publish. We should not abandon these core policies on our main page. Levivich (talk) 21:36, 11 October 2024 (UTC)[reply]
    News reports are primary sources anyhow and we should not be relying on them to begin with. Traumnovelle (talk) 21:51, 11 October 2024 (UTC)[reply]
    Seconding this, and adding that as far as I'm concerned, it's a type of WP:CPUSH. Thebiguglyalien (talk) 22:06, 11 October 2024 (UTC)[reply]
  • Oppose both 1 and 2. Strongly oppose 3. We need a few changes, but, none of these proposals hit the mark. Ktin (talk) 06:48, 12 October 2024 (UTC)[reply]
  • Support 3. We should endeavor to make the main page representative of our best content in all areas, and ITN does not contribute to that goal. Fritzmann (message me) 01:33, 13 October 2024 (UTC)[reply]
  • Support option 3 per Win8x. ITN is outdated and an outlier. Cremastra (talk) 18:11, 13 October 2024 (UTC)[reply]
  • Oppose all All of these are half-baked ideas that shouldn't be implemented in their current form. Option 1 is promising, but the concerns above (about various forms of possible bias, and the fact that newspapers and encyclopedias have different objectives) are substantial. Option 2 is a non-starter unless we want ITN overrun with sports and film trivia. Option 3 is a non-starter unless there is something new to replace it that will place links to high-profile news stories on the homepage. (A whole scale removal would also get rid of Recent Deaths, which I don't think anyone is complaining about?) Walsh90210 (talk) 20:18, 13 October 2024 (UTC)[reply]
    What's wrong with sports and film updates if they're quality content? Aaron Liu (talk) 23:29, 13 October 2024 (UTC)[reply]
    Individually there is no problem with them, but there are so many of them that there would be no space for anything else. Thryduulf (talk) 23:54, 14 October 2024 (UTC)[reply]
    In that case, I would start working on the other stuff so it's not just sports. Aaron Liu (talk) 00:57, 15 October 2024 (UTC)[reply]
    That would just make the problem worse. There is a finite number of slots (currently 3, a theoretical maximum of 8 if all the blurbs are very short, circa 5 is more common). If every sports update gets posted then each update will be on for only a few minutes at most, then consider all the film updates, book updates, music updates, war updates, politics updates, and criminal justice updates that will also get posted. Then realise that there are also extreme weather updates, theatre updates, product updates, construction updates, and biography updates to post too. After that you can start thinking about the updates to topics I haven't mentioned (science, visual arts, technology, ...). Thryduulf (talk) 02:31, 15 October 2024 (UTC)[reply]
    With the amendments I propose, you're considering the case of a Wikipedia with ~84x our current amount of activity, which we should consider only at that point. Aaron Liu (talk) 02:42, 15 October 2024 (UTC)[reply]
    Eh? All those topics get updates that meet your proposed ITN criteria. Not that many get nominated at ITNC today, but that's in part because almost none of them meet the criteria for ITN. Thryduulf (talk) 02:57, 15 October 2024 (UTC)[reply]
    Could you give an example? Aaron Liu (talk) 12:45, 15 October 2024 (UTC)[reply]
  • Support 3 per Cullen328. Oppose 1 and 2.—S Marshall T/C 15:58, 14 October 2024 (UTC)[reply]
  • Support 3. ITN has been broken for some time now and it needs WP:TNT-ing and rebooting in some other form. The other two proposals don't address this either so Oppose 1 and 2. Caveat: RD seems to work quite well though, and should be part of any replacement ... or could it possibly be absorbed into OTD in some way? Black Kite (talk) 16:05, 14 October 2024 (UTC)[reply]
  • Oppose 3 As a reader of Wikipedia, I find it ITN interesting. Senior Captain Thrawn (talk) 21:59, 14 October 2024 (UTC)[reply]
    I find all sorts of things interesting. That isn't always the best reason, though. Cremastra (talk) 22:04, 14 October 2024 (UTC)[reply]
    ILIKEIT is usually a poor reason to oppose the deletion of an article, but this discussion is not about the deletion of an article. Thryduulf (talk) 23:52, 14 October 2024 (UTC)[reply]
    With all due respect, your argument in favor of abolishing references another argument that ITN doesn't properly feature Wikipedia's best content ([citation needed]), nor does it actually explain why you believe it is "outdated and an outlier" as you claim. DarkSide830 (talk) 02:24, 15 October 2024 (UTC)[reply]
  • Oppose 1 and 2. Option 1 isn't feasible as the sole criterion as hundrers of different topics are mentioned on front pages. Also I fear that in practice it would strengthen the systemic bias, as the topics like the Sudanese civil war (currently the worst humanitanian crisis in the world) are unlikely to appear on the front pages. Option 2 is unclear, how would it work in practice with lots of articles being updated every minute? Alaexis¿question? 11:46, 15 October 2024 (UTC)[reply]
    Only those that get nominated and get consensus that they're quality writing will get posted. I don't see any edits that meet the criteria in the last two minutes of recent changes. Aaron Liu (talk) 12:48, 15 October 2024 (UTC)[reply]
    Well, maybe I've exaggerated a bit, but for sure editors "add[] substantial due coverage" to many more article in a day than it's feasible to feature on the main page.
    Now that I'm thinking about it, this would make things worse from the systemic bias point of view. Wikipedia suffers from it to the extent that reliable sources are affected by it. Historically ITN has worked differently offering a different perspective. I think that implementing proposal #2 would make ITN more similar to generic Western news outlets. Alaexis¿question? 20:11, 15 October 2024 (UTC)[reply]
    Historically ITN has worked differently offering a different perspective. – This is just another way to say it engages in POV pushing by diverging from the sources. Thebiguglyalien (talk) 20:17, 15 October 2024 (UTC)[reply]
    It's also humanly unfeasible to nominate so many updates. If the concern is that hooks move too rapidly, raise the quality requirement. Aaron Liu (talk) 20:20, 15 October 2024 (UTC)[reply]
    hundreds of different topics are mentioned on front pages Not on multiple front pages, which is the Proposal 1 criteria. Look at today's world front pages and you'll be hard pressed to find five different stories that are on multiple front pages in multiple countries. And we can make that criteria tighter or looser by adjusting how many front pages are required, and from where.
    I fear that in practice it would strengthen the systemic bias, as the topics like the Sudanese civil war (currently the worst humanitanian crisis in the world) are unlikely to appear on the front pages. Have you looked at the front pages of African newspapers? Proposal 1 can significantly reduce systemic bias by bringing in front pages from developing nations. We could also do things to fight systemic bias like requiring multiple continents or regions to be represented (so not just multiple Western front pages). I think the risk of systemic bias would be much lower if we based selection criteria on the front pages of newspapers in developing countries, than if we based selection criteria on what a group of overwhelmingly Western, English-speaking, white male volunteers think is important (which is the status quo). Levivich (talk) 22:35, 15 October 2024 (UTC)[reply]

Discussion (In the news criteria amendments)

So it functions as a baseline, and then editors can bring in other considerations to exclude entries such as a controversy at a high school worthy of two paragraphs? Rollinginhisgrave (talk) 01:49, 8 October 2024 (UTC)[reply]
No. There would be no other considerations. The point is to get rid of the significance requirement entirely. voorts (talk/contributions) 01:58, 8 October 2024 (UTC)[reply]
Would that example of a controversy at a high school then be posted on the front page? For example a shooting or it closing down due to economic issues? Rollinginhisgrave (talk) 02:01, 8 October 2024 (UTC)[reply]
It's highly unlikely there would be enough sources to produce multiple paragraphs about a school controversy that would comply with WP:NPOV (WP:DUE/WP:PROPORTION). If someone nominates to ITN with WP:RECENCY issues, the end result will be most of that fluff getting cut from the article. Thebiguglyalien (talk) 02:46, 8 October 2024 (UTC)[reply]
I suppose I disagree. I think two paragraphs about a school shutting down due to a controversy or a shooting would not be UNDUE. Rollinginhisgrave (talk) 02:55, 8 October 2024 (UTC)[reply]
Perhaps a different example, as you are politically minded, every person announcing they were running for president would be eligible for the front page, i.e. Amy Klobuchar 2020 presidential campaign. Rollinginhisgrave (talk) 03:00, 8 October 2024 (UTC)[reply]
That's a more interesting case study. For reference, this is the article one week after it was created: Special:PermaLink/883544133. It's 767 words of prose, and the sources are about her campaign specifically (or her potential campaign for older sources), so there's no immediate challenge to whether it's due content. When I proposed what eventually became option 2, I also suggested that it could exclude newly created event articles (so Amy Klobuchar would need to be the article where multiple paragraphs would be due), but that didn't gain any traction. So yeah, if the oversectioning were fixed, this one possibly could have gone through. But keep in mind that it wouldn't have been hundreds die, solar eclipse, World Cup, Amy Klobuchar is running for president. This change would bring ITN closer to DYK, where lots of things run for a short period instead of a few "big" things for an excessively long period. Thebiguglyalien (talk) 03:19, 8 October 2024 (UTC)[reply]
The churn response is interesting, as the flipside of eliminating significance to get in ITN is significance to get off the front page. The example cited above a lot is 9/11, and I suppose an Amy Klobuchar running for president type event could knock that off the front page in a matter of hours. Which I would find equally disagreeable. Rollinginhisgrave (talk) 03:31, 8 October 2024 (UTC)[reply]
That is a very good point, but ITN already has a way of addressing "big" things that need to stay on long-term: ongoing events. The current criteria to be placed there are that it meets the requirements for a blurb and that it also has regular updates. If something is so big that it's still getting major updates after it rolls off of ITN, then it can be listed in ongoing until those updates stop. Or another option would be that new major updates could start being new blurbs for the same article as the previous one falls off (instead of just rewording the blurb mid-run like we do now), but that would probably be a separate discussion. Thebiguglyalien (talk) 03:44, 8 October 2024 (UTC)[reply]
Could you give an example of how the invasion of Lebanon by Israel would be presented when Israel-Hezbollah conflict is already an ongoing event? Rollinginhisgrave (talk) 03:53, 8 October 2024 (UTC)[reply]
I don't think it would hurt anything to either blurb the invasion article while the conflict article is listed as ongoing or to lift the conflict article out of ongoing for the duration of the blurb, depending on what the community determines is better practice. Thebiguglyalien (talk) 04:02, 8 October 2024 (UTC)[reply]
I apologise, this speaks to my ignorance. Could you describe what you mean by blurb here? Do you just mean list it as an item or feature it with a picture? Rollinginhisgrave (talk) 05:11, 8 October 2024 (UTC)[reply]
Yes, the "blurb" is just the listed item. Thebiguglyalien (talk) 05:15, 8 October 2024 (UTC)[reply]
Specifically, it's a bulleted sentence (as opposed to "Ongoing" which is a mere page link). —Bagumba (talk) 05:19, 8 October 2024 (UTC)[reply]
Also as opposed to RDs (recent deaths), which don't need to be "in the news" and aren't allowed photos (yet). InedibleHulk (talk) 05:29, 8 October 2024 (UTC)[reply]
Thankyou for discussing this with me. I will be voting against 2, as the elevation of niche topics to the expense of large events seems bad. I read Thebiguglyalien's solutions as possible, but also as attempts to launder a significance criterion through existing processes. Rollinginhisgrave (talk) 05:36, 8 October 2024 (UTC)[reply]
This is to disincentivize creating a new article ...: WP:ITNUPDATE currently allows new articles:

In the case of a new, event-specific article, the traditional cut-off for what is enough has been around three complete, referenced and well-formed paragraphs.

It's a general notability question, not ITN specific, on whether a new article is suitable. Per the WP:N policy: This is not a guarantee that a topic will necessarily be handled as a separate, stand-alone page. Editors may use their discretion to merge or group two or more related topics into a single article. —Bagumba (talk) 04:18, 8 October 2024 (UTC)[reply]
  • Is proposal 1 meant to amend WP:ITNSIGNIF to say that and nothing else? That is, will it say in effect "items in x number of different countries' newspapers' of record front pages are posted if the update's sufficient, and those in x-1 or fewer never are", or "items in x number of etc etc, and anything else needs consensus at WP:ITNC"? If the former, then there's numerous completely uncontentious items at WP:ITNR that I doubt would ever be posted again (I blithely assert, not having looked at a physical newspaper for the better part of twenty years). Not to mention the sort of items that relate only to one country, but do so strongly, that WP:ITNCDONT point #2 warns about. —Cryptic 03:44, 8 October 2024 (UTC)[reply]
    I read it as an addition, but it does seem consensus will be tricky to tease out here because many are reading it in other ways. CMD (talk) 04:32, 8 October 2024 (UTC)[reply]
    This proposal would completely replace the current criteria. The purpose is to do away with the subjective aspects of the significance criteria. voorts (talk/contributions) 13:38, 8 October 2024 (UTC)[reply]
  • Abolish ITN discussion A prior discussion in 2020 is at Wikipedia:Village pump (proposals)/Archive 166 § h-Request for comment on the future of Wikipedia:In the news-2020-02-25T17:54:00.000Z—Bagumba (talk) 03:49, 8 October 2024 (UTC)[reply]
    Pre-pandemic, though (Old Normal); people generally seemed surer (to me) about the future of a lot of things back then. InedibleHulk (talk) 04:37, 8 October 2024 (UTC)[reply]
  • Can someone confirm if I'm understanding #2 correctly? Without the significance criterion, the two remaining criteria for posting an ITN blurb are "Updated content" and "Article quality". The latter is unaffected by this proposal, but the update criterion gets an upgrade. In this scenario, any article that meets those two criteria gets blurbed? Firefangledfeathers (talk / contribs) 05:05, 8 October 2024 (UTC)[reply]
    I anticipate that "significance" would then just be enforced by !voters via WP:ITNUPDATE. At the earlier Wikipedia talk:In the news § Litmus test, there was a comment that 2024 United States presidential debates might not be suitable for a blurb because it didn't even merit a five-sentence update to an existing article so they would fail the remaining WP:ITNUPDATE criterion —Bagumba (talk) 05:56, 8 October 2024 (UTC)[reply]
    The debate would qualify under the new ITNUPDATE, so long as the debate is notable and at least five sentences are added to the new article. voorts (talk/contributions) 13:41, 8 October 2024 (UTC)[reply]
    ... at least five sentences are added to the new article: That's my point. People can argue that an update is WP:UNDUE, or people can game the system and bloat an article with a WP:NOTDIARY event. Subjectivity is not gone. —Bagumba (talk) 16:04, 8 October 2024 (UTC)[reply]
    Which itself points to the fundamental issue being the NOTNEWS factor, of what is actually an appropriate encyclopedic article about a current event. There was reasonable agreement to that over a decade ago, but tgats definitely no longer that case because we aren't holding event articles to the NOTNEWS / NEVENT standard. Masem (t) 16:31, 8 October 2024 (UTC)[reply]
    To a certain extent, time can be needed to objectively determine if WP:LASTING and WP:INDEPTH is met. Due to recentism, an AfD the week of an event is more likely to be kept or have no consensus. Deciding whether a topic should be a standalone page is not unique to ITN. There's already the WP:PAGEDECIDE guideline:

    Often, understanding is best achieved by presenting the topic on a dedicated standalone page, but it is not required that we do so; at times it is better to cover a notable topic as part of a larger page about a broader topic, with more context (and doing so in no way disparages the importance of the topic).

    —Bagumba (talk) 06:08, 9 October 2024 (UTC)[reply]
    It's not just recentism that leads to those AfD results - the bar to deletion is correctly higher than the bar to creation. Articles should not be created when significance is borderline, but equally once they have been created they shouldn't be AfDed until significance is no longer borderline, which can take some time. These articles shouldn't be on ITN, because the bar to posting should be high enough that only events where significance is clear can get posted. Thryduulf (talk) 10:26, 9 October 2024 (UTC)[reply]
    ... the bar to posting should be high ...: There's merits to that, but it shoud be tempered with the criticism that stale items remain posted, or that "regulars" have walled off ITN. —Bagumba (talk) 11:40, 9 October 2024 (UTC)[reply]
    That isn't what I said, I said the the bar to posting should be high enough that only events where significance is clear can get posted (emphasis added). That the bar is currently set too high does not negate that, nor does it justify removing the bar (or placing it on the floor). Thryduulf (talk) 11:47, 9 October 2024 (UTC)[reply]
    I think we're roughly in agreement. —Bagumba (talk) 12:21, 9 October 2024 (UTC)[reply]
    Those aren't subjective arguments in the way signifcance is. They are arguments rooted in PAGs for which consensus can be assessed. voorts (talk/contributions) 18:43, 8 October 2024 (UTC)[reply]
    PAGs are also subjective, it's just an improvement over WP:ITNSIGNIF, which is seemingly written for everyone to have a backdoor (or wide open front door) to argue "their" nom. —Bagumba (talk) 05:56, 9 October 2024 (UTC)[reply]
  • It will be impossible to get consensus on this since the conflicts at ITN lie not with an issue of process but rather with an issue of participation. Duly signed, ⛵ WaltClipper -(talk) 13:42, 8 October 2024 (UTC)[reply]
    I would also be supportive of proposals to bring engagement. DarkSide830 (talk) 17:04, 8 October 2024 (UTC)[reply]
    I really do think a step that needs to be done is around engagement. We haven't done a proper analysis of the number of suggested blurbs are made each month (ignoring RD and RD blurbs), how many of those are posted, and how many are those rejected for significance issues (not quality or stale). My gut says that we have fewer noms while the percentage of those that are rejected on significance remain the same, which means it is not the case that significance criteria aren't broken, but a failure to get nominations beyond the usual ITNR or large disaster ones. Masem (t) 16:13, 9 October 2024 (UTC)[reply]

How to replace

For those supporting complete removal of ITN, I think it would be worth offering some insights into what exactly should replace it. Granted, technically this discussion isn't about that, but I think the wider editor and readerbase may be more convinced that such a change is worthwhile if a clearly better alternative is proposed. DarkSide830 (talk) 17:10, 8 October 2024 (UTC)[reply]

The Featured Picture should take the top right slot in the Desktop view as this would balance the Featured Article nicely and they are both supposed to be our best work. This would be an immediate replacement providing time for a new section to be implemented.
A good replacement for ITN would be a section of helpful navigation links. This might be called Topical Topics, to give it a meaningful title. These links would include:
These would provide most of what ITN does without all the discussion and drama. You might have a featured headline topic too – a single blurb for big breaking news like the 9/11 incident which started ITN. But I fear that this would require discussion which would start the drama all over again. Andrew🐉(talk) 18:14, 8 October 2024 (UTC)[reply]
As with my previous comments about POTD taking the top right slot, it removes the way to describe the image and create a blurb like for TFA and TFL but even with a blurb, it could leave out necessary space to show the image off in a good resolution and size. Cowboygilbert - (talk) ♥ 22:35, 10 October 2024 (UTC)[reply]
In addition to Andrew's suggestions, there are other more important aspects of Wikipedia that don't have their own spot on the main page. One option would be a place to feature several good articles of the day, like TFA but several small blurbs instead of one big one. DYK kind of does this, but the emphasis would be on quality over newness. Another option would be a section that explains anyone can edit Wikipedia, explains how to get started, and maybe provides links to basic instructions pages. Thebiguglyalien (talk) 18:37, 8 October 2024 (UTC)[reply]
As stated, I would oppose the GA showcase idea, as it both encroaches on the differentiated function of TFA on the Main Page—and in doing so, it frankly seems likely to emphasize work that isn't our best in a way I'm not comfortable with. Naturally, there would be an extra stage of review for GAs that appear on the Main Page, but I'm not presently convinced the community has the ability to consistently ensure a higher standard of quality than the theoretical minimum—i.e. that one other editor signed off on the article passing WP:GA?. In my opinion, that minimum standard is insufficient to merit a more prominent placement on the Main Page than is currently facilitated by DYK. Remsense ‥ 论 00:19, 9 October 2024 (UTC)[reply]
Such a process could be established, but it would have to be established first, and that would require consensus on what standards to apply and how to apply them and setting up the processes to support that. It would also need a group of editors interested and competent in reviewing content against those criteria and I suspect most people who fit that description are already fully engaged at existing processes like FAC, the existing GA and DYK. Thryduulf (talk) 00:27, 9 October 2024 (UTC)[reply]
I feel like a "Today's good article" would be better than a list of good articles recently promoted. I took a look at another wikipedia, itwiki's Main Page, and it has a section for "Quality Articles" which I am assuming is their Good articles. While I do see some other people in this thread have problems with it being not that well of a process, DYK reviews is less of a process than GA reviews and is allowed to be on the main page. Cowboygilbert - (talk) ♥ 22:43, 10 October 2024 (UTC)[reply]
Right now there are three paths to DYK: (a) new article; (b) GA; (c) 5X (IIRC) expansion. (b) and (c) are maybe 5% of DYKs, which is why DYK has the (deserved) reputation as something of an embarrassment for the daily errors it puts on the front page, not to mention the half-baked articles readers find when they click through. As I advocate below, a number of problems are fixed in one fell swoop by changing DYK rules to eliminate path (a) (and mAYBE (c) -- not sure). Then DYK effectively becomes a GA showcase. The current DYK review process would still be there on top of the GA review, just like now -- a process simultaneously duplicative and full of holes, but no worse than it is now, and with the "new content" route eliminated, errors at DYK would go way down. EEng 23:41, 10 October 2024 (UTC)[reply]
Deciding that would probably just be a clone of TFA. Aaron Liu (talk) 23:06, 10 October 2024 (UTC)[reply]
Wouldn't that defeat the purpose of TFL? Basically a clone of TFA but for lists. Cowboygilbert - (talk) ♥ 02:04, 11 October 2024 (UTC)[reply]
Not sure what you mean. TFL still has value as it's list-exclusive, while "TGA" would just be a much worse clone. Aaron Liu (talk) 20:51, 14 October 2024 (UTC)[reply]
These are all good ideas. I made very basic mock-ups of all four at User:Levivich/sandbox: Topical Topics, POTD, GA, and Learn to edit. Anyone should feel free to edit the sandbox pages directly to change the mock-ups or add new ones of your own. Levivich (talk) 19:38, 8 October 2024 (UTC)[reply]
I like "topical topics" or POTD (today's featured picture). POTD makes a lot of sense next to TFA. Just a note, Wikipedia:Top 25 Report is marked with the {{Humor}} tag, with the text This page contains material that is kept because it is considered humorous. Such material is not meant to be taken seriously., so this should probably not be on the front page, unless it is vetted more by the community. Natg 19 (talk) 20:24, 8 October 2024 (UTC)[reply]
There seems to be less overt humour in WP:TOP25 than you get at DYK which explicitly tries to be quirky and often goes for a cheap laugh. So, as there's no obvious reason for the {{humor}} tag, I've removed it. Andrew🐉(talk) 20:46, 8 October 2024 (UTC)[reply]
With or without the humor tag, those blurbs are not written for general readers and that page should not be on the front page. Schazjmd (talk) 20:55, 8 October 2024 (UTC)[reply]
There are lots of internal Wikipedia pages with bold links on the main page and so our general readers are clearly expected to use them. These include Wikipedia:Teahouse, Wikipedia:Reference desk and Wikipedia:Village pump. These may all have an informal tone and so there's clearly no prohibition of exposing such to our readers. We want our readers to understand that Wikipedia is not written by an exclusive elite but that they are welcome to edit too. Andrew🐉(talk) 21:07, 8 October 2024 (UTC)[reply]
Well, whatever we settle on, my main concern will always be user engagement. ITN may have it's flaws, but I believe in it's purpose as it is to guide readers to articles they may wish to read. My concern with ITN removal is I don't believe most of the proposals I've seen would entice me to engage as a reader rather than an editor. Learn to Edit is an interesting one, but I feel like putting it at or near Other areas of Wikipedia is better (ie, not a box amongst the 4 on the main page). To me, TFP is better as a long box as it is now. I don't think the image without a blurb is really useful for readers, and each box has a dedicated picture as it is. Topical Topics to me seems too mundane and sterile, and just exacerbates the issue ITN has with supposed irregular updates (0 is less than infrequent). And I feel like Recently-listed good articles is just DYK without the interesting hook that may encourage readers to click on the articles (I believe my concern with a TFL section would be the same). DarkSide830 (talk) 18:32, 9 October 2024 (UTC)[reply]
I agree with Dark if we find consensus to abolish. I like the idea of Topical Topics, but it desperately needs actual content instead of just links to not be sterile and provide a glean. Aaron Liu (talk) 21:33, 9 October 2024 (UTC)[reply]
As a regular at POTD, the second one is challenging to look at. The blurb is meant to be like a DYK hook, it's supposed to quickly explain and describe the subject without going into too much detail. Completely removing and it and just having a link to the article and then the image just ruins the teaching ability of POTD. Even with a blurb, there isn't much room to write one. However, the GA and Learn to edit sections are the best imo. Cowboygilbert - (talk) ♥ 22:33, 10 October 2024 (UTC)[reply]
I immediately thought this as well. It seems that, unless a concrete proposal or slate of proposals is promptly established as to what should replace ITN, the !votes for its removal are essentially being thrown away. Remsense ‥ 论 23:55, 8 October 2024 (UTC)[reply]
In my flames of foresight, I see four rows, for TFA, DYK, OTD and TFP. InedibleHulk (talk) 10:32, 9 October 2024 (UTC)[reply]
Wikipedia works on consensus, not one editor's crystal ball. If you want to see that design for the main page you need to actually propose it get consensus for it. Thryduulf (talk) 10:43, 9 October 2024 (UTC)[reply]
Consider it proposed (again). InedibleHulk (talk) 10:50, 9 October 2024 (UTC)[reply]
We could potentially make TFL a daily occurrence instead of something that only appears on Mondays and Fridays, or we could move POTD to ITN's current location. I don't really think highlighting GAs like that is a good idea, since they haven't been vetted as thoroughly as FAs. QuicoleJR (talk) 15:07, 9 October 2024 (UTC)[reply]
I support having Today's featured list as a daily occurance but not to the moving POTD to the ITN section because I feel like it could limit the amount of the blurb that you can write and to show the image in a great resolution and size. It works for TFA and TFL because the image is not the sole purpose of the main page activity. Though the comment of, "since they haven't been vetted as thoroughly as FAs" also doesn't make sense because DYK is allowed on the main page and DYK is easier to pass than a Good Article review. Cowboygilbert - (talk) ♥ 22:30, 10 October 2024 (UTC)[reply]
I've long said that DYK should feature ONLY GAs and drop the riduculous "new content" fetish, which might have made sense 20 years ago but now operates to force into the spotlight largely half-baked articles. Imagine if all the effort that currently goes into DYK reviews went into GA reviews instead (1/3 as may of them of course -- another requisite for improving DYK quality is decreasing throughput). The GA backlog would be cleared in no time. And if there are people who don't want to go to the effort of writing GAs, tough. EEng 23:35, 10 October 2024 (UTC)[reply]
the "new content fetish" quote cracked me tf up lmao
Unfortunately, a lot of articles aren't up to GA standards and have DYK-able quality prose. It's whatever though. Cowboygilbert - (talk) ♥ 02:02, 11 October 2024 (UTC)[reply]
EEng, I completely agree. Any interest in the two of us teaming up so we can make this happen together? Thebiguglyalien (talk) 02:12, 11 October 2024 (UTC)[reply]
+1 Rollinginhisgrave (talk) 02:20, 11 October 2024 (UTC)[reply]
Thebiguglyalien, you vacuous, toffee-nosed, malodorous pervert, I'll have you know that ... Oh wait. You're agreeing with me. OK then. The answer is yes and no. I have zero time for the next week, and very restricted time for the indefinite future after that. But if you'll take the lead I'll be right behind you.
What we're up against is this: if you search the DYK archives you'll find a couple of times where I've suggested that, and was always shot down. It's taken as axiomatic that DYK's function is to "showcase new content". There are a lot of people who like getting links to their new little articles on the main page, without doing too, too much work. It will be very hard to overcome that, as that group dominates the participants at Talk:DYK. It seems to me a two-phase approach might help:
  • Open a discussion (scrupulously avoiding a supports and opposes situation) during which the implications of such a change could be discussed -- the reduction in DYK throughput, increase in quality.
  • Based on what's learned during that discussion, think about where and when to actually propose the change. Talk:DYK is not the place -- such a proposal would absolutely die there. An RfC at VP might be right.
I'm going to ping my goto guys Levivich, Tryptofish, David Eppstein to see if we can get them on board as well. EEng 01:46, 13 October 2024 (UTC)[reply]
I think the function of DYK on the front page is to encourage editors to create new content much more than to encourage readers to read new content. I think that's still a worthwhile thing to encourage. But then, I never intentionally go to the front page so my opinion on what we see there may not be worth much. Also, did you know ...that the did you know section is not shown to mobile app readers? ...that in 2021, roughly twice as many people per day used mobile than desktop? Keeping those things in mind, what we put into DYK may not be very relevant. —David Eppstein (talk) 03:30, 13 October 2024 (UTC)[reply]
...that most mobile readers use the website, which shows DYK, instead of the app? Aaron Liu (talk) 14:22, 13 October 2024 (UTC)[reply]
Aaron Liu is right. Page views for the main page show (for daily averages this month): 1.82 M on desktop, just 51 (that's 51, not 51 M) on the mobile app, and a weighty 2.48 M on mobile web. So 1) unless this month has been wildly divergent (and it doesn't seem to be; I checked the year's averages too), almost nobody uses the mobile app, and more people still use desktop than everyone seems to think.
Here's a piechart of readership for this year, based on the device type for average pageviews:

Percentage of pageviews for the Main Page by platform, yearly average 2024

  Desktop (43.2%)
  Mobile web (56.8%)
  Mobile app (0.00000770884%)
Pie charts aside, I have to disagree with EEng. (Disclaimer: I am, in fact, a person who like[s] getting links to their new little articles on the main page, without doing too, too much work). I think it is fine for DYK to showcase things that are GAs. GAs take time; showcasing some new content on interesting things of decent quality is good. (Disclaimer: I have so far epically failed to elevate an article to GA). It's an encouragement for lazy editors like me. Sometimes it can be a good "first step" where the next ones are peer review, GA, FA, TFA, and RAGFAWKO. Cremastra (talk) 22:51, 13 October 2024 (UTC)[reply]
The mobile app does not use the main page as its landing page, hence statistics of mobile app views of the main page are irrelevant. That said, I'm pretty sure the usage of the mobile web main page is leaps and bounds beyond usage of the mobile app, but I can't find the statistics that I once read. Aaron Liu (talk) 23:36, 13 October 2024 (UTC)[reply]
Nonetheless, it's the main page we're discussing, so it should be main page pageviews we should be looking at. Cremastra (talk) 00:13, 14 October 2024 (UTC)[reply]
David's premise was that most Wikipedia readers don't use Main page (and instead use a landing page with Top 10, FA, and OTD), and thus he argued that DYK is irrelevant to the modern audience. To evaluate this argument, we would need to look at the usage of the mobile app's landing page, not the views of Main page from the mobile app. Aaron Liu (talk) 00:37, 14 October 2024 (UTC)[reply]
(Responding to ping.) If this is a discussion about how to replace EEng, I'm in favor of doing so. If EEng wants me to support the idea of making DYK into a GA showcase, I'm strongly opposed to doing so. I like thinking up hook-y hooks for new pages, and I think all the hyperventilating over DYKs pointing to embarrassing content is a case of protesting too much. Much of Wikipedia as a whole is deeply flawed, because it's a work in progress, and there are even editors who are deeply into FAs who regard GAs as an embarrassment. Personally, I'm not wild about Featured Lists, so there. As for ITN, which seems to be where this discussion started, I'm no fan of recentism, but it's not something I care about that much. I often check the obituaries, perhaps to see if I'm listed there. --Tryptofish (talk) 21:33, 13 October 2024 (UTC)[reply]
Maybe there could be 2 featured articles? A completely random proposition but I don't see why that wouldn't work. win8x (talking | spying) 22:11, 10 October 2024 (UTC)[reply]
I think two boxes that only have two total target links isn't helpful. The Main Page is, by definition, largely focused on featuring quality content which is great, but does an article being featured quality entice readers to read an article enough to justify changing from a multi-target box to a single-target one? DarkSide830 (talk) 23:18, 10 October 2024 (UTC)[reply]
The last I heard, less than one new FA is produced per day and so TFA is already doing reruns and scraping the barrel. It's DYK that is overloaded with fresh content and could use more space. Andrew🐉(talk) 18:48, 11 October 2024 (UTC)[reply]
Wikipedia:Featured articles that haven't been on the Main Page seems exuberantly healthy to me. Aaron Liu (talk) 18:55, 11 October 2024 (UTC)[reply]
15 years ago, that page listed 1200 articles.  10 years age, it listed 1300.  Five years ago, it was 900.  Today it is 700.  The trend is not in a healthy direction. WhatamIdoing (talk) 19:07, 11 October 2024 (UTC)[reply]
I don't see how going from down 400 to down 200 is an unhealthy trend, and the FA criteria has also traveled in a healthy direction. Aaron Liu (talk) 00:46, 12 October 2024 (UTC)[reply]
If the trend continues, and especially if it accelerates, then we will eventually run out of FAs to put on the Main Page. The Main Page needs 365 articles a year. The last time we saw 365 new FAs being promoted in a year was 2013. This is just simple math: If you start with 700 in the pool, add 300 new FAs, take out 365 being shown on the Main Page, then the next year you have 635 in the pool. And in 10 years, you have nothing for the Main Page. WhatamIdoing (talk) 02:05, 12 October 2024 (UTC)[reply]
Would it honestly be a bad thing if featured articles were allowed to reappear on the main page? I get the preference for new stuff, but I don't see why we can't reshow older featured articles. --Super Goku V (talk) 07:08, 12 October 2024 (UTC)[reply]
I agree there isn't an issue if we re-run articles (I'm pretty sure I've seen a featured article appear on the main page twice before). But I don't think there is a need for two featured articles. Traumnovelle (talk) 07:12, 12 October 2024 (UTC)[reply]
The rules were changed in 2017 to permit FA reruns as issues were already apparent then. See discussion, "FAs are not being produced as fast as the TFA slot uses them. The number of available featured articles is also reduced by the fact that many older FAs have degraded to the point where they are no longer suitable for TFA. ..." Andrew🐉(talk) 07:32, 12 October 2024 (UTC)[reply]
FAs can already be rerun since yes, they aren't being produced fast enough. But readers won't remember a featured article from 2014, so I don't think there's an issue with that. win8x (talking | spying) 13:34, 12 October 2024 (UTC)[reply]
The ones from 10 years ago are not usually suitable for running. They're not up to the current standards. In some cases (e.g., medical topics, recent political topics), it requires truly major effort to re-write them. For example, Autism was a TFA years ago. At a glance, about a third of the ~400 sources currently violate WP:MEDDATE. That's just one of the problems in that FFA. I really think that re-running that would basically require starting over from scratch. In the category of less dire situations, Menstrual cycle has appeared twice as TFA, but it required two months' work from multiple editors to make that happen. Some of those editors were giving up time on writing new FAs to rescue this old one. These are both subjects of broad interest that I could imagine editors deciding to run them every five or ten years, but the amount of work necessary to make that happen, and the opportunity costs involved, should not be underestimated. WhatamIdoing (talk) 04:14, 13 October 2024 (UTC)[reply]
Fair. I am in no way involved in TFA or featured articles in general, so I wouldn't know. Thanks for the insight. win8x (talking | spying) 13:47, 13 October 2024 (UTC)[reply]

Toward Next Steps

Firstly, I can see merit in editors who are asking for this thread to be closed. None of the three options being presented are the solution to the issues that we have. I am going to be deliberately provocative here -- but, I will caveat it by saying that it is not directed at one single editor or group. Here goes -- this thread is meaningless and is an example of the WP:BIKESHED fallacy in my opinion. The truth is that we are using 20th century tools to address 21st century problems. Furthermore, we are hoping for a process to solve a problem that is inherently a technology problem. What do I mean by that? While we have gone far far far away from the notion of a static web in all other fields and yet, we continue to operate the ITN box as a static entity made much worse by the fact that we have processes that have degenerated and admin capacity to administer processes practically non existent.

The true future of the ITN panel is in a dynamically (algorithmically) controlled output with some amount of manual interventions to avoid runaway situations. This is a technology solution and the unfortunate truth is that none of the folks in this group can solve this technology problem and hence we will always go round and round on the process front.

I had outlined this earlier at WT:ITN. The future of the panel is in three levels of personalization of the ITN panel and definitely not in some group of editors fighting it out. The three levels are as follows.

  1. Trending topics (no personalization, but still dynamic)
  2. Trending topics near you (personalized by geography) and
  3. Recommended topics for you (personalized for you)

The truth is no one in this group can implement this without working hand-in-hand with the software folks from the foundation. Case in point the grounds-up iOS Wikipedia app has somewhat solved this problem with the trending topics panel. The homepage needs to go toward that solution, not tomorrow, not today, but almost a few years ago. And I repeat, I am being provocative, but, I am being honest -- none of the participants in this discussion forum can solve this one. PS: In the meantime, what we have going is as good as we can get to. We are in a maintenance mode. But, we should not throw away we have going without getting a strong replacement in place. I wish everyone the absolute best. Ktin (talk) 00:18, 13 October 2024 (UTC)[reply]

Any of those are still effectively option 3 (removing ITN), and that's not gaining traction.
As I've commented, I believe the bulk of the problems at ITN stem from the fact that we have not been holding WP to the NOTNEWS standard, which leads to editors creating too many new event articles that really aren't encyclopedic topics in the long term - and the impact on ITN being the nomination of news items stemming from these articles. Until we course-correct on NOTNEWS, so that people are not rushing to create event articles just because a newspaper covered it, and thus cut back on the poor nominations at ITN, then we can see if there's further issues with the significance criteria (which honestly, I don't think that will be the case once we get everyone focused on what are encyclopedic news events and not what should be at Wikinews.) Masem (t) 00:27, 13 October 2024 (UTC)[reply]
We are again falling back to hoping to solve a technology problem through people-processes. Hard no. PS: If you read my message above, you will see that I strongly oppose #3 before putting in place a technology solution. We, unfortunately, are no where near that and this group is not the right group to get us there.Ktin (talk) 00:30, 13 October 2024 (UTC)[reply]
“Should be on Wikinews” I agree with the principle of your statement on NOTNEWS, but there is nothing reviving that corpse of a project and its numerous, numerous, numerous issues. PARAKANYAA (talk) 02:09, 14 October 2024 (UTC)[reply]
I don't see how "top 25 report but blurbless and short-range" would showcase our quality content. Aaron Liu (talk) 01:44, 13 October 2024 (UTC)[reply]
Perhaps the minimum standard of quality ITN bar could be left to DYK. Both of the Wikipedia apps already showcase trending content on their homepages without problems that I'm aware of. Ed [talk] [OMT] 02:26, 13 October 2024 (UTC)[reply]
If it is good for the official iOS and Android Wikipedia apps, I refuse to buy the argument that it is not good for Wikipedia Web. Ktin (talk) 04:13, 13 October 2024 (UTC)[reply]
"has no problems" does not equate "good". I really agree with Alach's featurability principle that the main page should showcase achievement. Aaron Liu (talk) 14:27, 13 October 2024 (UTC)[reply]
I also don't see how an "AI generated" (dynamic) solution is better than the above three proposals. There is no community support for a "trending news" box. If it is desired, I don't believe there is a "technology issue" - it could be done. Natg 19 (talk) 02:19, 13 October 2024 (UTC)[reply]
Dynamic is not necessarily the same as AI generated. Ktin (talk) 04:05, 13 October 2024 (UTC)[reply]
Additionally, I don't know what this means Firstly, I can see merit in editors who are asking for this thread to be closed. I don't see any editors saying this. This is an open discussion that has not yet run its course. Natg 19 (talk) 02:31, 13 October 2024 (UTC)[reply]
Don't know how I read that one wrong. Fixing my comment. Ktin (talk) 04:04, 13 October 2024 (UTC)[reply]
AI will prevail. TNT Wikpedia. Damn Skynet. —Bagumba (talk) 03:48, 13 October 2024 (UTC)[reply]
The apps have a nice option to "customize the feed". Each section of the main page is presented as a card and the display of each card can be turned on and off to taste. The web-based formats are comparatively inflexible and do not allow the reader such choice. The WMF should do more to empower the readers. The idea that a handful of community insiders should decide what the readers get is not sensible. Andrew🐉(talk) 09:24, 13 October 2024 (UTC)[reply]
...which ties back to my idea of having WMF or whoever conduct a survey to gauge what casual readers themselves want on the front page, but I understand there’s a fat chance of that happening. I also seriously doubt that casual readers would be happy with the "insiders"' decision here to remove ITN from the front page and replace it with a boring list of links (to GAs, editing tutorials, portals, etc.) or yet another FA box, which have been proposed in the section above. Some1 (talk) 14:44, 13 October 2024 (UTC)[reply]
If readers want to find something, they can search for it. We don't need social media-style "personalized feeds". Keep people's minds open. How about a big "random article" button? Cremastra (talk) 18:09, 13 October 2024 (UTC)[reply]

split

i think galaxy a3 (2017) galaxy a5 (2017) and galaxy a7 (2017) should be unmerged 2600:6C4E:CF0:9E0:944:9332:35D4:D82 (talk) 23:39, 7 October 2024 (UTC)[reply]

This is the kind of thing to suggest on Talk:2017 edition of the Samsung Galaxy A series. Because the respective sections are so small, you should give substantial reasons for separate articles: either that you would have substantial amounts of content to add separately to each, or that they are such substantially different entities covering different topics to have separate discussions. (An example of the latter would be if the A5, and only the A5, had extensive controversy on launch and massive explosions and lawsuits, a significant digression from the flow of the main A Series article -- that would warrant a separate article for the A5.) SamuelRiv (talk) 00:38, 8 October 2024 (UTC)[reply]
This was discussed in and is the product of Wikipedia:Village pump (policy)/Archive 189#Do we really need over 600 articles on individual Samsung products?. There was a strong sense among participants that many such mergers should be done. I performed the merger of the 2017 Samsung Galaxy A phones creating 2017 edition of the Samsung Galaxy A series. You are probably noticing an inconsistency insofar as these phones don't have standalone articles while many others have. This inconsistency will be resolved over time by also merging those other phones into articles on generations of models.—Alalch E. 00:57, 8 October 2024 (UTC)[reply]

Wikipedia:Indic transliteration and WP:INDICSCRIPT

I know this is biased but I find it to be really unfair that we cannot use the scripts that were written Indian languages all because of one user did something back in 2012. Like, we could have use the scripts for cities for example. SpinnerLaserzthe2nd (talk) 16:18, 12 October 2024 (UTC)[reply]

It seems that WP:IndicScript, for the lede and infobox, has been discussed several times from 2012 thru 2017. Since we're past 7 years from the previous discussion (at least as listed on the policy page), it's probably time to have another discussion, to get the beat from editors as to where ethnonationalist edit-warring on this is at nowadays, and consider a new RfC (even if just to reaffirm the old policy). SamuelRiv (talk) 17:11, 12 October 2024 (UTC)[reply]
Unless some RFC includes a longer moratorium period (I doubt that we currently have, or ever will have, such a long moratorium on anything), any 7-year-old RFC consensus can be reopened because Wikipedia:Consensus can change. Animal lover |666| 10:01, 13 October 2024 (UTC)[reply]
Procedural close or move to some other forum or talk page. No substantive reason to change anything has been expressed. There's no clear proposal either. "Not fair", "one user did something" and "7-year-old RFC" are not actionable items on which it is possible to form a consensus. —Alalch E. 13:13, 13 October 2024 (UTC)[reply]
I suggest starting a thread at Wikipedia_talk:Manual_of_Style/India-related_articles. It looks like the issue has been brought up before, but there's been no updated information on vandalism posted, which is the key consideration. Maybe you'll want to solicit such information first by announcing your intentions beforehand, and post a notice on WP:Wikiproject India.
Then at any time, review the previous WP:Requests for comment linked at WP:IndicScript, and then begin a new one on the MOS talk page, following similar guidelines. SamuelRiv (talk) 16:31, 13 October 2024 (UTC)[reply]
Anecdotally, I tried to propose a relatively small exception to the current guideline a year ago or so and was met with pretty significant pushback, so I'd expect a similar response to any suggestion along SpinnerLaserz's lines, despite being sympathetic to it myself. signed, Rosguill talk 16:49, 13 October 2024 (UTC)[reply]

Default unban appeal terms

Moved from Wikipedia talk:Banning policy

I want to suggest default unban appeal terms. Namely to incorporate WP:SO into it. Something along the lines of this:

Unless stated otherwise in the ban, a community ban may be appealed not less than six months from the enactment, or six months after the last declined (or inappropriate) appeal. This includes bans as a result of repeated block evasion, bans as a result of a block review by the community, and bans occurring de facto. This does not apply if there are serious doubts about the validity of the closure of the ban discussion. A ban from the Arbitration Committee may be appealed not less than 12 months from the enactment, or 12 months after the last declined (or inappropriate) appeal. None of these appeal provisions apply to arbitration enforcement blocks, such as blocks enforcing contentious topic restrictions, or community sanction blocks.

I am pretty sure that this is sensible for most bans. While the ArbCom part will require an ArbCom motion, the community part could happen almost immediately. Awesome Aasim 02:38, 13 October 2024 (UTC)[reply]

Repeating this in VPPL to get further input. I think this should be added to the Banning policy. We can further refine it to get the right wording that can then be added in one swift edit. Awesome Aasim 22:47, 13 October 2024 (UTC)[reply]

Technical

Enhanced editnotice loader

I worked on a module that would serve as an enhanced editnotice loader for Wikipedia. See testwiki:Module:Editnotice_load and Module:Editnotice load (which is an exact copy). Features include category editnotices, better group notices, and editnotices by page ID (which would reduce the need to move pages around).

I want to get further feedback on this loader before it inevitably gets implemented. Please check out the testwiki. It should be backwards compatible with the way we do things, but I would like checks for this first.

If this is to be implemented, there will need to be a couple of changes made, including to:

This would make the editnotice loader much more robust.

Immediately, in preparation for this, I would consider adding the following category editnotices templates:

{{BLP editintro}}

{{Disambig editintro}}

Anything else? Awesome Aasim 19:06, 9 September 2024 (UTC)[reply]

Some documentation on how it works from a user's perspective would be helpful, in order to understand the context and how it would be used in practice, including how security restrictions are enforced. On a side note, I'm not sure that its deployment is "inevitable". isaacl (talk) 22:03, 9 September 2024 (UTC)[reply]
I have some testcases on testwiki. For best results, view when logged out and inspect the HTML when logged in.
testwiki:Taylor Swift should be a good example of me getting category editnotices working. testwiki:Protected title and testwiki:Protected title2 show the protection editnotice on both the create screen and on the "does not exist" screen when a title is protected from creation for other reasons.
testwiki:Special:EditPage/A should show the page notice from testwiki:Template:Editnotices/PageID/54370 (which is for A). You can also see I renamed previous "page notice"s to "title notice"s because the way page notices are bound to currently are actually to titles, not pages. The new "page notice" will remain bound to a specific page because it uses PageID. There will be no need to update the title notices for pages that exist. On the other hand, for pages that don't exist, the title notice will need to be kept up to date. Awesome Aasim 04:01, 10 September 2024 (UTC)[reply]
I can't tell from the article page how to use the feature: where the edit notice lives, how will access be limited, and so forth. Thus it's hard to evaluate the feature without knowing the maintenance cost. isaacl (talk) 09:58, 10 September 2024 (UTC)[reply]
The editnotices live in the same pseudo-space: Template:Editnotices/. See testwiki:Module:Editnotice load/config.
I also moved the editnotice links to a collapsible box because the number of creatable editnotices has gotten relatively high after adding category notices. Awesome Aasim 13:16, 10 September 2024 (UTC)[reply]
OK, I see there's now a link above the edit notice point to its location, so category-based notices are grouped under a "Category" subpage. What are the enhancements for the group-based notices? isaacl (talk) 18:33, 10 September 2024 (UTC)[reply]
There is less ambiguity in how they are handled. For example, on testwiki:Template:A/B/C/D/E, there are five different group editnotices that can be created. So if there is a page where it is desirable that the group Template:A/B needs one group notice, and Template:A/B/C needs another group notice, and Template:A/B/D needs another group notice, that can now be done; there will be one common group notice and two separate group notices for subpages. Awesome Aasim 19:21, 11 September 2024 (UTC)[reply]
I would suggest to phase the rollout into stages, and creating a test plan to ensure nothing regressed. Editing this many interface pages and fully protected templates at once sounds like too much work for an admin to volunteer to. For instance, the specific category editnotices you mention can be left for later as we already have a decent system to handle those categories.
Immediately, in preparation for this, I would consider adding the following category editnotices templates this cannot be done immediately as they also need to be removed from Module:Mainspace editnotice, else they would show up twice when the rest of the changes are deployed. – SD0001 (talk) 08:01, 10 September 2024 (UTC)[reply]
I actually think this might be something that is better done all in one go. Removing the two category editnotices from Module:Mainspace editnotice should be kind of a no-brainer after the rollout. The way that the module currently does these checks, checking the unparsed wikitext, currently sucks.
Do you have an idea for a Scribunto test runner for Module:Editnotice load to ensure that everything works with demo editnotices? Awesome Aasim 16:53, 13 September 2024 (UTC)[reply]

I haven't noticed any bugs or regressions yet, if someone could take a second look at my code maybe then we will be able to identify potential problems. Awesome Aasim 12:52, 2 October 2024 (UTC)[reply]

I submitted an edit request. I think this is something that could be botted by an admin opening up 8 edit windows and then saving all of the proposed changes at once. I have done this before, it gets annoying when you get rate limited but it is not impossible. Awesome Aasim 20:05, 8 October 2024 (UTC)[reply]

Help Escalating security issue with Webauthn

Tracked in Phabricator
Task T358771

With the help of WMF staff we identified a critical issue with webauthn that is likely locking users out of their accounts. The issue prevents webauthn activated on a device from being used on another device, or between browser sessions. This means users can be activating webauthn , intending to secure their account, and end up losing access to wikipedia. Because relatively few users activate this feature in the short term, the issue may not be getting the attention it deserves. It will also discourage future users from activating webauthn, which is a critical security feature to protect the community.

Please help me find the appropriate contact with WMF technical staff to help get the fix merged. It's a one-line fix from upstream repository so it should be low risk. Tonymetz 💬 16:50, 3 October 2024 (UTC)[reply]

I guess that would be us, the Platform Team. I'll raise it with the team and we'll have a look. Matma Rex talk 19:30, 3 October 2024 (UTC)[reply]
Thanks for the note, webauthn has multiple known issues and is certainly in the "experimental" role. As far as our contributors and readers here at the English Wikipedia go: webauthn shouldn't be used by anyone for anything important. Technical reports in phabricator are of course welcome. — xaosflux Talk 00:09, 5 October 2024 (UTC)[reply]
thanks for the context. On the ticket , Reddy mentioned it was completed by a contractor and hasn't been supported. To whom could I appeal to have it turned off? I believe it's locking people out, so it's a liability. Tonymetz 💬 18:00, 7 October 2024 (UTC)[reply]
I think that would also be us. There's already a task: T376021 that lists some problems and suggests turning it off as one possible solution. I think that's currently waiting on some decisions about the new login system (code name "SUL3", see T348388 for some details), which may either let us fix it instead of disabling it, or force us to disable it, depending on which approach we end up going with. Matma Rex talk 01:10, 10 October 2024 (UTC)[reply]
thanks for sharing the context and I'm glad to hear that the concern is being addressed. Thanks again for the updates on that. Tonymetz 💬 02:58, 11 October 2024 (UTC)[reply]

I dislike the visual changes to Mobile Wikipedia

I havent used the community pool before so Im sorry if this isnt in the right village. mobile wikipedia starting today as for some reason started auto directing me to en.m.wikipedia.org instead of the regular en.wikipedia.org. even if i directly remove the ".m" or "m.", it will just autodirect to it again. I really hate it, and find it unbearable to use and love the regular english language wikipedia much more. I dont know what is causing this problem. I havent seen anyone discussing this on either the wikipedia subreddit (where usually any updates are discussed) or on Wikipedia:News. I greatly appreciate any help with this, thank you! 92.236.211.53 (talk) 13:55, 4 October 2024 (UTC)[reply]

Use the "Desktop" link at the bottom of mobile pages to request the desktop version. PrimeHunter (talk) 14:00, 4 October 2024 (UTC)[reply]
Thank you for your quick response! I already tried this and it unfortunately results in it providing the literal desktop version of the website, resulting in large amounts of negative space and awkward text placement next to images due to website trying to work for the horizontal mobile. the site worked perfectly for mobile prior. is this happening on your phone too? 92.236.211.53 (talk) 14:07, 4 October 2024 (UTC)[reply]
im typing from desktop as i also learned today that my phone's ip (this same ip) was caught up in a rangeblock to block a specific user(but is now resolved?). i thought just now that this might be whats causing this but i just made account on mobile and it still autodirects to en.m.wikipedia. i have no idea what to do 92.236.211.53 (talk) 14:28, 4 October 2024 (UTC)[reply]
Device name:Pixel 6a
Model:Pixel 6a
Android version:12
I wish this information perhaps helps in finding out how to reverse this. I sent this from my mobile. 92.236.211.53 (talk) 16:48, 4 October 2024 (UTC)[reply]
The behavior you're experiencing is how it has always worked. The "workaround" Primehunter provided is working how it has always worked. There isn't a way to "fix it". The closest thing you can do is have an account, change the account's skin preference, and then use the "use desktop" link when you are logged in and end up on the mobile website. Perhaps this is sufficient for you. Izno (talk) 18:31, 4 October 2024 (UTC)[reply]
I went back through screenshots I took and saw that you and Primehunter were right, it has always been "en.m.wikipedia". I think there's been an update to mobile Wikipedia's base, light colour scheme that caused the add-on I was using, darkreader to render it differently.
I do notice that the text on tables is larger, and colours are in my opinion not working well together either in the official dark mode or using my add-on on light mode.
Current, disliked Wikipedia (lightmode+darkreader) from today: https://imgur.com/a/wnNflgF
Correct Wikipedia, just darkmode with no add-ons, also today:https://imgur.com/a/4xdBsow
Previous mobile Wikipedia colour scheme (lightmode+darkreader), from 28th of April: https://imgur.com/a/up24a8G
Is there anyway to go back to how it was previously because I really do prefer how it was literally just yesterday? I'm sincerely sorry for the misunderstandings 92.236.211.53 (talk) 19:33, 4 October 2024 (UTC)[reply]
What specifically do you dislike about the "current" version? Izno (talk) 00:09, 5 October 2024 (UTC)[reply]
There is a higher contrast between the letters and the dark background, the purple that lists clicked-on links is a lighter purple so you have to strain your eyes more to discern it, the text on tables is larger than it needs to be while the text on the rest of the articles is currently still at their previous very good and readable size (shown in the imgur comparison linked above), and I dont get how that happened.
I dont know how else to describe it, but it looks like there is a white or blue filter over the articles that makes my eyes hurt. I can make another imgur comparison if that would help explain what im reffering to (just two image links this time tho). 92.236.211.53 (talk) 15:35, 6 October 2024 (UTC)[reply]
If you create an account or add ?useskin=timeless, then the desktop version is more mobile friendly a bit. Gryllida (talk, e-mail) 07:29, 7 October 2024 (UTC)[reply]
Ive made an account and it hasn't reverted the UI to how it previously was sorry.
?useskin=timeless is working very well thank you. It's a hassle to paste it to the URL for each new article I click on since it resets to the awful default on every new link or page loaded or when the editl is opened. Is there anyway to make it the default, since it will also be bad for when I'm reading with mobile data, having to load the site twice. Thank you very much regardless! 92.236.211.53 (talk) 20:11, 9 October 2024 (UTC)[reply]
Yes. You can make it the default by creating an account, logging in with it, then going to your Preferences, and under "Appearance" select the Timeless skin, then Save. But that's what Izno told you five days ago. — JohnFromPinckney (talk / edits) 21:03, 9 October 2024 (UTC)[reply]
Sorry for the late reply. I've logged into this account and and selected timeless in appearance but despite that it's still not automatically going through! Also. I apologize to inzo, I don't think I understood what they are saying then. AssanEcho (talk) 20:37, 12 October 2024 (UTC)[reply]

Sticky table headers placement issue for short/nested tables

It looks like someone tweaked the CSS for the sticky table headers — which can be enabled with the fourth checkbox at Special:Preferences#mw-htmlform-gadget-section-test — so that (if your browser also satisfies a @media screen and (min-width: 1000px) media query) it applies a top: 3.125rem offset to table headers when one is stickied, to prevent the sticky header from either covering or sliding under the also-sticky TOC button.

Nice idea, in theory. Problem is, on pages containing nested and/or short tables that don't exceed the height of the screen, the stickiness can kick in at unexpected times, particularly when there are multiple tables. And when that happens, all of the tables' headers jump down a distance of 3.125rem, potentially covering their first data row.

I first noticed this at Module:Sports results, in the documentation. The "What it looks like" areas of those docs all contain short tables. If you have the sticky headers gadget enabled, then no matter where you scroll on that page, each table's header row will be shoved down to cover the first data row below it.

That's a problem, as it obscures content, and the only way to make it visible is to defeat the CSS rule applying top: 3.125rem. FeRDNYC (talk) 16:16, 8 October 2024 (UTC)[reply]

Actually, it looks like this only affects nested tables, and it may be sufficient to augment the existing CSS rule: 
@media screen and (min-width: 1000px) {
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header > thead {
    top: 3.125rem;
  }
}
with a second one overriding the offset in nested tables:
@media screen and (min-width: 1000px) {
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter .jquery-tablesorter > thead,
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter .mw-sticky-header > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header .mw-sticky-header > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header .jquery-tablesorter > thead {
    top: 0;
  }
}
FeRDNYC (talk) 16:57, 8 October 2024 (UTC)[reply]
...Smaller issue, the nested table headings then end up passing on top of the sticky outer table headers when they cross, instead of underneath them. Looks like some z-index tweaking might also be needed. FeRDNYC (talk) 17:01, 8 October 2024 (UTC)[reply]
Ohh, now I see. The offset isn't to avoid the floating TOC button, but rather the full-width version of the .vector-sticky-header. But the weird thing is, that CSS doesn't kick in until @media screen and (min-width: 1120px), so there's this weird 120px limbo range of browser widths where the table headings are ducking under nothing at all. FeRDNYC (talk) 22:53, 8 October 2024 (UTC)[reply]
Those values change sometimes. I'll make an edit request. —TheDJ (talk • contribs) 08:16, 9 October 2024 (UTC)[reply]
@TheDJ Nice, thanks!
The nested table issue is still a problem, though, whether the breakpoints are synced up or not. When a table's sticky-header activates and the top: 3.125rem; offset kicks in for its header rows, the header rows of all tables nested inside that table will also move down to obscure their own content, unless the offset is defeated for nested tables with something like my second CSS block above. FeRDNYC (talk) 09:18, 9 October 2024 (UTC)[reply]
Yes, this is almost impossible to bypass. Sticky headers are relative to their scrolling context. So every time you introduce a new scrolling context (as done here at Module:Sports_results#L-277), you have to cancel out the offset of the main context. This is part of the reason why the sticky headers are not the default behavior. It is not really possible to make it work predictably in any and all contexts right now. If you want to override this specific situation, you need to make an override for this gadget's behavior in Module:Sports_results/styles.css. —TheDJ (talk • contribs) 11:11, 9 October 2024 (UTC)[reply]
@FeRDNYC: The offset isn't a problem with the change request at MediaWiki talk:Gadget-StickyTableHeaders.css#Interface-protected edit request on 10 September 2024, which adjusts "top" to 0 if the table is wrapped in an "overflow" style. Basically nothing is sticky at Module:Sports results/doc, which is better than unreadable content. Jroberson108 (talk) 05:55, 11 October 2024 (UTC)[reply]

Keep getting logged out

Tracked in Phabricator
Task T372702

Over the past few weeks I've been occasionally getting logged out unexpectedly, despite ticking the "remember me" option every time. Most recently it's happened twice in the past ~24 hours. It always happens when I've been idle for a while, but only on the order of hours not days. I'm not aware that I've changed any of my settings recently. Thryduulf (talk) 20:15, 8 October 2024 (UTC)[reply]

Me too. I believe there is a phab ticket covering this issue. Let me go find it real quick NightWolf1223 <Howl at me•My hunts> 20:55, 8 October 2024 (UTC)[reply]
I've had the same issue for a week or so, I just rather lazily assumed it would get fixed at some point. -- LCU ActivelyDisinterested «@» °∆t° 21:08, 8 October 2024 (UTC)[reply]
Probably the same problem as T372702. Matma Rex talk 16:16, 9 October 2024 (UTC)[reply]
I don't know if this sequence of actions has a trigger in it.
  1. explicitly log out on one machine (this invalidates all login cookies on all devices)
  2. log in to en.wp on a different device, selecting "Keep me logged in (for up to one year)". I now have a fresh new login cookie
  3. Microsoft informs me that updates require installation, so I finish what I am doing ...
  4. ... close Firefox, go for "Start"→"Power"→"Update and restart", wait an age. Make coffee. Clear a pile of snailmail. Open Firefox ...
  5. ... and back to my watchlist. One edit adds an image to an article, which I am suspicious about, so:
  6. visit Commons. It says I am not logged in and should reload the page. In my experience, this never works, but following a different commons link does; so I go to the page history. I am now shown as logged in.
  7. Still on Commons, I follow a link to en.wp - I am not logged in
  8. Return to commons, visit another page, still logged in
  9. go to Meta - I am logged in there
  10. try en.wp again - not logged in
Why might en.wp stop recognising my login cookie when commons and meta are perfectly happy with it? --Redrose64 🌹 (talk) 20:17, 9 October 2024 (UTC)[reply]
Not getting automatically logged in on some wikis sounds like some sort of anti-tracking protection in your browser. Commons and Meta share the same parent domain with login.wikimedia.org where the central session cookie is stored so browser restrictions on cross-wiki cookie access are more relaxed.
Does clicking on the login link at the top of the page on enwiki help? That should work in Firefox. Tgr (WMF) (talk) 18:26, 10 October 2024 (UTC)[reply]
@Tgr (WMF): I think you missed something - my proper login (asking me to enter name and password) was on English Wikipedia. When I went to Commons and logged in there, I became logged out on Wikipedia, but remained logged in on Commons. --Redrose64 🌹 (talk) 20:16, 10 October 2024 (UTC)[reply]
Yeah the logged out part is the bug Matma Rex linked. I'm just saying Commons and Meta login being more "sticky" on some browsers is expected - your enwiki session somehow went missing, your central session on login.wikimedia.org remained, and then other wikimedia.org wikis can recover the session from there but wikis on other domains can't. Tgr (WMF) (talk) 21:31, 10 October 2024 (UTC)[reply]
OK it's not random but it is replicable:
  1. On en.wp, log in (full login using Special:UserLogin, with Username/Password)
  2. Click this link: commons: - observe that you are logged in
  3. Use the browser's "back" button to return to en.wp
  4. Press F5 to reload the page - observe that you are not logged in
  5. Click this link: commons: - observe that you are still logged in at Commons
This also causes loss of session data and more than one lost edit. --Redrose64 🌹 (talk) 21:54, 10 October 2024 (UTC)[reply]
@Redrose64 I cannot reproduce this behavior. RoySmith (talk) 00:49, 12 October 2024 (UTC)[reply]
@Redrose64 if you are able to reproduce it, would you mind doing it with the WikimediaDebug extension enabled and the "Verbose log" option checked? Tgr (WMF) (talk) 15:59, 13 October 2024 (UTC)[reply]
I'm not sure how this could be connected, but I've noticed recently (a few weeks?) that sometimes when I go back to my watchlist after looking at/editing a linked page, I get an earlier version of the watchlist. I've just assumed it has something to do with caching, as clearing the cache brings up the most recent version of the watchlist. Donald Albury 19:50, 12 October 2024 (UTC)[reply]

Adding section after closed discussions

I added a new section using the "*" tab with this edit: https://en.wikipedia.org/w/index.php?title=Talk:Fishing_cat&curid=7607570&diff=1250477244&oldid=1250369650

The new section is included within the closed discussion. I might be able to fix it in this case, but it seems to be a bug.  —  Jts1882 | talk  19:03, 10 October 2024 (UTC)[reply]

It's not really a bug; the person who closed the GA review section forgot to match their {{atop}} template with an {{abot}} template, which means the "close" box didn't end. I've fixed it. Writ Keeper ⚇♔ 19:10, 10 October 2024 (UTC)[reply]
Thank-you. I knew there was a problem but couldn't identify it. It's too easy to cast blame on bugs.  —  Jts1882 | talk  19:18, 10 October 2024 (UTC)[reply]

Problem with {{cite web}}

There appears to be a problem with {{cite web}} and related templates on some pages - see, for example, Beroidae, where all the references display "Lua error in Module:Citation/CS1/Configuration at line 2083: attempt to index a boolean value." rather than the reference. The references are displayed correctly in preview mode, with no template errors shown in the editor. I'm using Firefox with the Monobook skin. Tevildo (talk) 22:25, 10 October 2024 (UTC)[reply]

I WP:NULLEDITed the page and the error went away. No idea of the cause. * Pppery * it has begun... 22:35, 10 October 2024 (UTC)[reply]
This is usually caused when the Citation Style 1 module components used by the cite templates are updated and are out of sync for a few moments. Some pages are re-rendered and cached during that short time, and they can throw errors when new code tries to call older code and fails in some way. With so many millions of pages, it is inevitable that at least a few pages will be affected. Null-editing affected articles re-renders them with all of the updated module components. – Jonesey95 (talk) 00:45, 11 October 2024 (UTC)[reply]
Thanks for the answers, I'll try that if I come across this issue again. Tevildo (talk) 15:50, 11 October 2024 (UTC)[reply]

Matching tags in strings?

I need to create a series of ref tags from wikitext with refs. I'll settle for a very specific pattern of text removed. I tried things like: {{#invoke:string|replace|source=−4,<ref name="cn"/> −2,<ref name="cn"/>|pattern=[−+]%d,<.-><|replace=<|plain=false}} but the left angle bracket never matches. I think the match is being performed on a source or pattern after it has been converted to Help:strip markers. Thus the angle bracket is not in the source during the match. Is there a way around this? Johnjbarton (talk) 23:15, 10 October 2024 (UTC)[reply]

Because <ref /> tags are replaced with stripmarkers before Module:String ever sees |source=:
{{#invoke:string|replace|source=−4,<ref name="cn"/> −2,<ref name="cn"/>|pattern=[−+]%d,<.-><|replace=<|plain=false}}
−4,'"`UNIQ--ref-000000B4-QINU`"' −2,'"`UNIQ--ref-000000B5-QINU`"'
no <ref /> tags to match.
—Trappist the monk (talk) 00:40, 11 October 2024 (UTC)[reply]
Thanks, very helpful. On the plus side the issue I was concerned about, finding my digit-strings like ",9" inside refs, can't actually happen:
{{#invoke:string|replace|source=−4,<ref name="has9">,9</ref> −2,<ref name="cn"/>|pattern=[−+]%d,<.-><|replace=<|plain=false}}
−4,'"`UNIQ--ref-000000B8-QINU`"' −2,'"`UNIQ--ref-000000B9-QINU`"'
On the minus side, templates can't manipulate contents of ref tags I guess. Johnjbarton (talk) 01:55, 11 October 2024 (UTC)[reply]

References

  1. ^ a b c d Cite error: The named reference cn was invoked but never defined (see the help page).

Talk:Battle of Helena

See Talk:Battle of Helena#In appropriate photo when viewing in app. Any idea what's going on with the issue the IP just reported? There were some image vandalism issues over a year ago. There's no infobox image in the article so I don't know what would be causing that. I am unable to really look into this because I am at work and do not want to replicate the reported issue. Hog Farm Talk 16:29, 11 October 2024 (UTC)[reply]

@Hog Farm the article was vandalized at some point (see the edit summary at Special:Permalink/1163371835) and while the vandalism was removed, it's likely that some resource the app is using didn't update their cache correctly. --Ahecht (TALK
PAGE) 19:53, 11 October 2024 (UTC)[reply]

SuggestBot - is it running?

Hi, I submitted a request 20:32, 10 October 2024 (UTC) here, and awaiting a response of suggested articles wikitable. At User talk:SuggestBot I did include @Nettrom, the bot operator. Regards, JoeNMLC (talk) 21:41, 11 October 2024 (UTC)[reply]

It appears not - the recent contribs to User talk pages show that it typically runs twice a day, at 11:24 and 23:24 (UTC), but today's 11:24 run was missed. Have you contacted the botop directly? --Redrose64 🌹 (talk) 21:55, 11 October 2024 (UTC)[reply]
Thanks Redrose64 - I did just now leave a message on Nettrom's talk page. JoeNMLC (talk) 00:10, 12 October 2024 (UTC)[reply]
Well its contribs show that it's making edits (permalink to contributions at time of writing). It seems to be taking its time. At least it's still carrying on the fourth-longest daily editing streak of any user here (I'm at #5 of out of all human editors). Graham87 (talk) 02:44, 12 October 2024 (UTC)[reply]
 Done at 11:26, 12 October 2024 (UTC). Cheers! JoeNMLC (talk) 11:50, 12 October 2024 (UTC)[reply]

Queries

Hey, all,

Just a minor query but I hope someone will know. When I use to visit Wikipedia:Arbitration/Requests/Enforcement or WP:ANI, in the top right corner of a discussion, there was a link to "Archive" the discussion. Instead, now, there is a link to "Subscribe". So, is there an easy way to archive discussions other than cutting and pasting them into an archive page? It used to be easy to do this but now I don't see a way to do this. Is it because of a skin or some setting I have opted into or was this a change to discussion format? There also use to be a Reply link on talk page discussions and I no longer see that link either.

Thanks for any explanation anyone can provide. Liz Read! Talk! 06:06, 12 October 2024 (UTC)[reply]

I had this issue recently and I was told to update / use a new user script. Let me hunt that down for you. Ktin (talk) 06:25, 12 October 2024 (UTC)[reply]
See this post Wikipedia:Village_pump_(technical)/Archive_214#User_Scripts_and_Template_Substitution. I ended up using User:Elli/OneClickArchiver and this works for me. Ktin (talk) 06:29, 12 October 2024 (UTC)[reply]
@Liz In User:Liz/common.js you are loading User:Technical 13/Scripts/OneClickArchiver.js on line 36. That particular version of the one click archiver was deleted in 2023 because it was broken and Technical 13 is arbcom blocked and unable to fix it. You'll need to replace it with an alternative, see Wikipedia:One click archiving for a list of maintained versions. 86.23.109.101 (talk) 17:11, 12 October 2024 (UTC)[reply]

Module:Nihongo and Module:Lang

Hey there. It looks like Japanese sword is having a Lua error. I am guessing that this may have to do with recent changes to either Module:Lang or Module:Nihongo. I can't edit those anyway, but maybe someone here has the ability and/or the ability to test what is going here. Sumurai8 (talk) 15:34, 13 October 2024 (UTC)[reply]

Yup, something is wrong with Module:Nihongo. Many Nintendo-related articles are affected. Anyone with technical knowledge able to fix this? QuicoleJR (talk) 15:54, 13 October 2024 (UTC)[reply]
Update: Everything is working properly now. Thank you, Trappist the monk, for fixing the module. QuicoleJR (talk) 16:14, 13 October 2024 (UTC)[reply]
I am still seeing this on mobile with Module:Lang. It seems to only affect articles after it was changed to langx. "Lua error in Module:Lang at line 1422: attempt to concatenate a nil value" Mellk (talk) 17:05, 13 October 2024 (UTC)[reply]
WP:NULLEDIT is your friend.
—Trappist the monk (talk) 19:25, 13 October 2024 (UTC)[reply]
Thanks. I suspected it was something to do with the cache. Mellk (talk) 07:13, 15 October 2024 (UTC)[reply]

‘Newcomer Tasks’ got a screw loose? Or is it the user?

Wikipedia:Growth Team features didn’t look like the right place to phone this in, so dragging it up here. If what looks like problems with the Newcomer kit, belongs somewhere else, please signpost accordingly.

See this and this. Is this the user making mistakes, or is Newcomer Tasks actually telling them to put refs at the top? MM (Give me info.) (Victories) 15:44, 13 October 2024 (UTC)[reply]

It seems to be just link spam, unrelated to Newcomer Tasks, even though the edits are tagged as such. —⁠andrybak (talk) 15:53, 13 October 2024 (UTC)[reply]
Cpmrev- Jeez, how did I miss that… uw-spam1 it is. Cheers Andry. MM (Give me info.) (Victories) 15:57, 13 October 2024 (UTC)[reply]

I need an advice how to split rows/lines in a wiki-userbox

I made a userbox draft

This user tries to reduce Gender bias on Wikipedia.

,

but I want to put a linebreak between "reduce" and "Gender". Anyone knows how to do this? Walter Tau (talk) 17:31, 13 October 2024 (UTC)[reply]

{{line break}}? MM (Give me info.) (Victories) 17:33, 13 October 2024 (UTC)[reply]
Thank you. It worked ! Walter Tau (talk) 17:37, 13 October 2024 (UTC)[reply]
Very good. Enjoy your breaking of many lines. Thumbs up icon MM (Give me info.) (Victories) 17:38, 13 October 2024 (UTC)[reply]
even simpler, just put <br />. — xaosflux Talk 19:21, 13 October 2024 (UTC)[reply]

This tool does not work. Is there any analogue? Kaiyr (talk) 18:54, 13 October 2024 (UTC)[reply]

@Kaiyr: Do you mean that you couldn't reach the site? Or that there was a server error? It currently appears to be online. Polygnotus (talk) 13:36, 15 October 2024 (UTC)[reply]
Ah when I click "Do it!" it says Server(ServerError { code: 1054, message: "Unknown column 'lt0.lt__namespace' in 'where clause'", state: "42S22" }).
You should probably report that issue over at https://github.com/magnusmanske/petscan_rs/issues Polygnotus (talk) 13:37, 15 October 2024 (UTC)[reply]

how do I restore the copy-paste function to the edit window? (dvorak keyboard)

Tracked in Phabricator
Task T62928

This changed just recently. I first noticed it on Wikt-en, and at the time I had no problem on WP-en, but now it's spread here. It occurs on some other language wikis, like Wikt-ja, but not on Wikt-vi. In the edit window of a WP article or talk page, if I hit control-x I get bold formatting, with control-c I get italic, and with control-v I get superscript. Presumably this has something to do with me using a dvorak keyboard (dvorak x and c correspond to qwerty b and i), but other commands are unaffected. E.g. control-z and -y are still 'undo' and 'redo', despite corresponding to the qwerty keys for t and /. That means that I can't use the keys with qwerty x c v printed on them for cut-copy-paste, because they continue to act as dvorak q j k and either quit the browser or take me to the URL. It doesn't affect normal typing in an edit window, only commands where the 'ctrl' key is used.

This does not happen when I 'respond' to a thread on a talk page, so that a new window opens: Then all keys act as dvorak, both here and on wikt. The skin also does not seem to be the issue. Here I use Monobook, on Wikt I use Vector 2022. I tried Vector legacy on Wikt and the behaviour was the same.

Can I do something with my css to override this behaviour? — kwami (talk) 00:29, 14 October 2024 (UTC)[reply]

The patch that broke it is reverted and going out on the next train on Thursday. phab:T62928 You can turn on syntax highlighting to work around it for now. Izno (talk) 00:47, 14 October 2024 (UTC)[reply]
Thanks!
Syntax highlighter is good fix in the meantime. — kwami (talk) 01:27, 14 October 2024 (UTC)[reply]

Keyboard shortcuts broken for alternative keyboard layouts (macOS, Safari)

For the last couple days, when editing an article and press 'Command-V' to Paste, the text below is inserted instead:

<sup>Superscript text</sup>

When I 'Command-C' to Copy, double single quotes are wrapped around the selected text.

''selected text''

Strangely, when editing THIS PAGE the shortcuts are working fine. But If I got to edit an article or talk page in mainspace, they do the above.

NOTE: macOS, Safari. I type using the Dvorak keyboard layout. Dvorak's C is in the same location as QWERTY's I. The italics issue above leads me to believe the shortcuts have been (recently) hardcoded to the QWERTY locations rather than taking the actual key/letter typed.

Does anyone know what could be wrong or have a better venue to raise this?

PK-WIKI (talk) 16:49, 15 October 2024 (UTC)[reply]

See above. — xaosflux Talk 16:51, 15 October 2024 (UTC)[reply]


Cannot request a move

I have been unable to request a multiple-page move. It goes like this: I am using Wikipedia on an Xbox console (my computer is out of action at the moment), and attempting to request a multiple-page move does not work. Doing so instead yields a mere reply in the form of bare wikitext. You can find those three trainwrecks (or should it be planewrecks, given the topic?) on Talk:Microsoft Flight Simulator. I attempted to request a move of four pages relating to the series in question, as I had previously done with the first game: Microsoft Flight Simulator 2.0, Microsoft Flight Simulator 3.0, Microsoft Flight Simulator 4.0, and Microsoft Flight Simulator 5.0 in a similar vein to my move of the 1982 game, as in moving them to something like "Microsoft Flight Simulator (19XX video game)".


Can someone request a move for me? Ægc's friendly xbox alt (talk) 08:30, 14 October 2024 (UTC)[reply]

Turn off Visual Editor in all its myriad forms (it may be OK for articles, but it's hopeless on talk pages). Use MediaWiki's own plain text source editor - I use the oldest one that still exists (I think that it's called the 2003 wikitext editor), and have no problems at all. Template transclusions and substitutions do exactly what they're supposed to. Any typos are therefore my own fault. --Redrose64 🌹 (talk) 09:41, 14 October 2024 (UTC)[reply]
@Redrose64 I don't think this is good advice in general, and it's not relevant here, because Æ is not using the visual editor here to edit the talk page, but rather the new topic tool. Matma Rex talk 16:00, 14 October 2024 (UTC)[reply]
@Ægc's friendly xbox alt In the top-right corner of the interface for adding new topics, there are two tabs labelled "Visual" and "Source" – try switching to the "Source" tab before writing the move request. Matma Rex talk 15:58, 14 October 2024 (UTC)[reply]

Preview weirdness

Use Navigation pop-ups. Point mouse at Aaron Brennan, an article about a bearded man, with a picture of a bearded man in the infobox, before any other pictures. Be surprised to see, in the pop-up, a picture of an unbearded young lady from several sections down the page. DuncanHill (talk) 11:37, 14 October 2024 (UTC)[reply]

@DuncanHill: And now? Polygnotus (talk) 12:46, 14 October 2024 (UTC)[reply]
@Polygnotus: Works as expected now, thanks. DuncanHill (talk) 23:50, 14 October 2024 (UTC)[reply]
Navigation pop-ups doesn't have access to the result of parsing the wikitext but makes its own primitive analysis of the source text. It can detect file syntax and certain common infobox parameters like image and logo, but apparently not image1. Unlike Page Previews, it can select images outside the lead. PrimeHunter (talk) 14:30, 14 October 2024 (UTC)[reply]
It would only require adding |image1 to this line in MediaWiki:Gadget-popups.js:
			'image|image_(?:file|skyline|name|flag|seal)|cover|badge|logo'
PrimeHunter (talk) 14:39, 14 October 2024 (UTC)[reply]

Standard width of appearance tool does not work properly

Hi, "Standard" width of "Appearance tool" does not work properly. It functions the same as "Wide" width. Please inspect. Thanks, Hooman Mallahzadeh (talk) 12:52, 14 October 2024 (UTC)[reply]

I just tested and it works fine. Is your screen wide enough for the wide mode to even kick in ? —TheDJ (talk • contribs) 14:00, 14 October 2024 (UTC)[reply]
@TheDJ Sorry, I zoomed out my browser and the problem resolved. Please close the thread. Thanks. Hooman Mallahzadeh (talk) 14:13, 14 October 2024 (UTC)[reply]
@TheDJ I really propose that we can disable this functionality in the case that zoom of browser is high, and this functionality does not work properly. We can implement that by a few JavaScript codes. Hooman Mallahzadeh (talk) 14:33, 14 October 2024 (UTC)[reply]

What is happening at Wikipedia:Administrators' noticeboard/Incidents? Of the last 100 edits 62 are tagged as having added disambiguation links - from random checking, most didn't?
The first edit that has it was this, which did add a disambiguation link (MOS:CONSISTENCY). – 2804:F1...D2:B7E7 (talk) 19:57, 14 October 2024 (UTC)[reply]

MOS:CONSISTENCY is a redirect to the disambiguation page Wikipedia:Consistency. MOS is a namespace here at the English Wikipedia while [[MOS:CONSISTENCY]] at other wikis would have been an interlanguage link to https://mos.wikipedia.org/wiki/CONSISTENCY. Maybe this confuses a piece of software. PrimeHunter (talk) 20:39, 14 October 2024 (UTC)[reply]
I've changed it to bypass the redirect, see if that works. – 2804:F1...D2:B7E7 (talk) 21:02, 14 October 2024 (UTC)[reply]
It worked. Your edit [33] was the last to be tagged, and the page still says [[WP:Consistency|MOS:CONSISTENCY]] many edits later. PrimeHunter (talk) 21:38, 14 October 2024 (UTC)[reply]
So it did. I'm guessing it isn't happening here because you also linked the redirect target ... interesting. – 2804:F1...D2:B7E7 (talk) 21:41, 14 October 2024 (UTC)[reply]
Talk:Redhead (bird) also links MOS:CONSISTENCY and was tagged when it was added.[34] I made two dummy edits without triggering the tag so it seems hard to guess when it will be tagged. PrimeHunter (talk) 01:21, 15 October 2024 (UTC)[reply]
That's true. I also noticed at ANI that it had started tagging every edit, but after the bot archived 5 sections (diff), only every other edit or so was tagged. In that edit the bot removes some :MOS links, which, coincidentally, were made :MOS because a bot thought they were accidental language links.
Seems to be some combination with other unknown factors. – 2804:F1...D2:B7E7 (talk) 01:47, 15 October 2024 (UTC)[reply]
I'm guessing it's a bug in mw:Extension:Disambiguator, since it's what sets the disambiguator-link-added tag. jlwoodwa (talk) 00:42, 15 October 2024 (UTC)[reply]
The relevant function is onLinksUpdateComplete. jlwoodwa (talk) 00:49, 15 October 2024 (UTC)[reply]
(To be precise, I mean a bug either directly in that extension, or in its dependencies.) jlwoodwa (talk) 00:51, 15 October 2024 (UTC)[reply]

Tech News: 2024-42

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

  • The Structured Discussion extension (also known as Flow) is starting to be removed. This extension is unmaintained and causes issues. It will be replaced by DiscussionTools, which is used on any regular talk page. A first set of wikis are being contacted. These wikis are invited to stop using Flow, and to move all Flow boards to sub-pages, as archives. At these wikis, a script will move all Flow pages that aren't a sub-page to a sub-page automatically, starting on 22 October 2024. On 28 October 2024, all Flow boards at these wikis will be set in read-only mode. [35][36]
  • WMF's Search Platform team is working on making it easier for readers to perform text searches in their language. A change last week on over 30 languages makes it easier to find words with accents and other diacritics. This applies to both full-text search and to types of advanced search such as the hastemplate and incategory keywords. More technical details (including a few other minor search upgrades) are available. [37]
  • View all 20 community-submitted tasks that were resolved last week. For example, EditCheck was installed at Russian Wikipedia, and fixes were made for some missing user interface styles.

Updates for technical contributors

  • Editors who use the Toolforge tool Earwig's Copyright Violation Detector will now be required to log in with their Wikimedia account before running checks using the "search engine" option. This change is needed to help prevent external bots from misusing the system. Thanks to Chlod for these improvements. [38]
  • Phabricator users can create tickets and add comments on existing tickets via Email again. Sending email to Phabricator has been fixed. [39]
  • Advanced item Some HTML elements in the interface are now wrapped with a <bdi> element, to make our HTML output more aligned with Web standards. More changes like this will be coming in future weeks. This change might break some tools that rely on the previous HTML structure of the interface. Note that relying on the HTML structure of the interface is not recommended and might break at any time. [40]

In depth

  • The latest monthly MediaWiki Product Insights newsletter is available. This edition includes: updates on Wikimedia's authentication system, research to simplify feature development in the MediaWiki platform, updates on Parser Unification and MathML rollout, and more.
  • The latest quarterly Technical Community Newsletter is now available. This edition include: research about improving topic suggestions related to countries, improvements to PHPUnit tests, and more.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 21:17, 14 October 2024 (UTC)[reply]

Mysterious newline

At Wikipedia:Contents/Mathematics and logic § Glossaries, there's an unintended newline between Algebraic geometry and Algebraic topology. Looking at the source (Wikipedia:Contents/Glossaries/Mathematics and logic), there's a newline between all the entries, but all of them are ignored on the subpage, and all but the first are ignored when it's transcluded. Inspecting Wikipedia:Contents/Mathematics and logic in my browser, the first entry is outside the <div> that holds all the other entries. (And I've checked that this isn't skin-specific or browser-specific.) I've tried putting <nowiki /> at the start of Wikipedia:Contents/Glossaries/Mathematics and logic, because I vaguely remember a bug like that, but no dice. Does anybody know what's going on here? jlwoodwa (talk) 00:33, 15 October 2024 (UTC)[reply]

I made the list use actual wikitext list formatting like the other sections. It was using bullet characters with line breaks, which may or may not work, as you saw. Does normal formatting work for you? – Jonesey95 (talk) 00:54, 15 October 2024 (UTC)[reply]
Thanks, that did it. No point in debugging something if it's automatically solved by upgrading to semantic list markup. jlwoodwa (talk) 01:11, 15 October 2024 (UTC)[reply]

Newspapers.com

I've not been able to log in to Newspapers.com since February because I have free account there linked to my paid Ancestry account. I was told it was very hard to maintain that, for very good reasons. I found it very difficult to edit articles because I depended on Newspapers.com for sources. Now I don't even see it as an option in the Library anymore. Have we totally given up on that? I see Ancestry in the library. Is there some way to access newspapers.com for articles that aren't obituaries? I hope I'm asking this in the right place. Oona Wikiwalker (talk) 01:09, 15 October 2024 (UTC)[reply]

Have you applied for access as instructed here? Nardog (talk) 02:31, 15 October 2024 (UTC)[reply]

Hindustan Times

HT sources can no longer be added automatically via ref gadgets like ProveIt and VisualEditor, only manually. Can't this be fixed, the way other websites like The Times of India were? Kailash29792 (talk) 05:20, 15 October 2024 (UTC)[reply]

How can I edit an article in full screen, not a column with preview to the left

I want to have to click preview to preview and have the full edit field available. Thanks. Doug Weller talk 12:16, 15 October 2024 (UTC)[reply]

Ignore, figured it out. Doug Weller talk 12:21, 15 October 2024 (UTC)[reply]

Accounts with no visible creation date on their contribs page

When I visit the contributions page of a user, it shows their account's creation date at the top. But some, like Dennis Brown and Muboshgu, don't. Why? Avessa (talk) 14:10, 15 October 2024 (UTC)[reply]

Because those users were created before user creation times were being logged. —TheDJ (talk • contribs) 14:20, 15 October 2024 (UTC)[reply]
But your account was created seven months earlier than Muboshgu's (21 April 2005 vs. 22 November 2005), and yet the creation date is visible on your contribs page. Then there are also Bearcat (created on 3 October 2003), BD2412 (20 February 2005), Koavf (5 March 2005), etc, which all were created before Muboshgu's account too, and yet have their creation date visible. Avessa (talk) 15:23, 15 October 2024 (UTC)[reply]
Strange things sometimes occur with logins created before WP:SUL went live in May 2008. --Redrose64 🌹 (talk) 16:18, 15 October 2024 (UTC)[reply]
I think the "creation date" for early accounts is a later guess that was added to the database at some point (I remember that it was not there in the beginning; for me, the date given is the date of my first edit, which is probably correct). The list of users by user ID claims to be "by creation date" but that is clearly incorrect. —Kusma (talk) 16:52, 15 October 2024 (UTC)[reply]
@Kusma: well it is by creation date ... in terms of the current database, which was implemented in January 2002 with the Phase II software. The previous UseModWiki login system was quite different, as described at the Wikipedia FAQ on the Nostalgia Wikipedia. Graham87 (talk) 01:58, 16 October 2024 (UTC)[reply]
The sorting is by actual creation date, not by the date given as "creation date". —Kusma (talk) 08:12, 16 October 2024 (UTC)[reply]
The user_registration column wasn't added until MediaWiki version 1.6, which was released on April 5, 2006. There's a script that backfills the column with each user's first edit, but - as best as I've been able to reconstruct - it apparently hasn't been run on enwiki since at least August 24, 2006. Users who registered before 1.6's deployment but didn't edit until after the last time the update script was run still have empty registration times. —Cryptic 16:52, 15 October 2024 (UTC)[reply]

Infinite JS errors?

I happened to disable pop-ups on a WIkipedia page, using some unintended key combination. I now get an infinite number of the following pop-up messages 

 Javascript Error

https://en.wikipedia.org/w/index.php?title=User:Manishearth/orphantabs.js&action=raw&ctype=text/javascript at line 125: Uncaught TypeError: Cannot read properties of null (reading 'document')

Hmm... All the best: Rich Farmbrough 16:40, 15 October 2024 (UTC).[reply]

You can turn off your personal scripts, that one is loading from User:Rich Farmbrough/monobook.js, just comment it out. — xaosflux Talk 16:57, 15 October 2024 (UTC)[reply]

Add buttons to Reply Tool

How can I add buttons to the Reply Tool (part of DiscussionTools)? Polygnotus (talk) 17:38, 15 October 2024 (UTC)[reply]

Unable to use the visual editor for a specific article

For some reason the visual editor is not working on this article. getting the message "sorry this element can only be edited in source mode for now".

Why might this be the case?

Is this normal or is there a problem that has to be fixed? i was told to try clearing my cache and fit that didn't work to ask here.BruceSchaff (talk) — Preceding undated comment added 20:33, 15 October 2024 (UTC)[reply]

Should be fine now. Someone had added some bold that doesn't work in the way it was added. Izno (talk) 20:48, 15 October 2024 (UTC)[reply]

Template:Wikipedia stats issue

The template seems to be having issues with "mos" as a parameter, possibly due to the MOS namespace or related changes. Could someone please take a look at it? In particular, it's used on Wikipedia:List of Wikipedias, and the issue is visible if you uncomment that row of the table. Thanks. Daniel Quinlan (talk) 00:55, 16 October 2024 (UTC)[reply]

It's indeed the MOS namespace which caused problems. I have modified {{Wikipedia stats}} to link the mos wiki as m:mos: which works via a redirect at meta.[41] It's a hack but it works so I have uncommented the mos row.[42] I don't know whether it's possible to make a wikilink which goes directly to the mos wiki. PrimeHunter (talk) 01:42, 16 October 2024 (UTC)[reply]
phab:T363538 included a proposal for a mos-x-deconflict: interwiki, but (judging by how that's a redlink) it doesn't currently exist. Special:Interwiki doesn't show any other prefixes for https://mos.wikipedia.org, so I think m:mos: is the only solution for now. jlwoodwa (talk) 01:59, 16 October 2024 (UTC)[reply]
That was the solution I originally went with (and coded up). The WMF decided to instead embrace the concept of a namespace and an interwiki having the same name, rather than working around it. * Pppery * it has begun... 02:04, 16 October 2024 (UTC)[reply]
Part of that included adding parser functions to explicitly indicate you wanted the interwiki link, but that part hasn't been code reviewed yet. * Pppery * it has begun... 02:05, 16 October 2024 (UTC)[reply]
Thanks! Daniel Quinlan (talk) 02:29, 16 October 2024 (UTC)[reply]

Proposals

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.

Editing Sri Lankan Election 2024 page

This is not a concrete, actionable proposal. The content edit was already made and information on how to discuss content improvements has been provided. — xaosflux Talk 20:35, 5 October 2024 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Could someone edit this page to show that AKD won. Idk how to edit elections Irindu10 (talk) 15:22, 22 September 2024 (UTC)[reply]

Looks like it has already been done. In the future, it is better to ask this on the article's talk page (here, Talk:2024 Sri Lankan presidential election), as it is more likely to be seen by editors more knowledgeable on this specific topic. This page here is for more wide-ranging proposals, rather than to request specific edits. Chaotic Enby (talk · contribs) 02:30, 28 September 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Request for check user is meant to be for request for permission

This is not a concrete, actionable proposal. Information on the topic has been provided. — xaosflux Talk 20:33, 5 October 2024 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

OK 132.147.192.240 (talk) 02:21, 28 September 2024 (UTC)[reply]

Hi! Wikipedia:Requests for checkuser is inactive, and has been replaced by Wikipedia:Sockpuppet investigations. Also, while the names might be confusing, it isn't a request for permission, as it wasn't to request to become CheckUser, but rather to request assistance from a CheckUser in a specific situation. Chaotic Enby (talk · contribs) 02:25, 28 September 2024 (UTC)[reply]
Requests for checkuser access are handled by the Arbitration Committee, see Wikipedia:Arbitration Committee/CheckUser and Oversight for details. It's worth noting here though that it is one of the most restricted rights on the project (for good reason) and cannot (by both policy and technical restriction) be granted to IP editors. Thryduulf (talk) 02:34, 28 September 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Bring dark mode reporting on-wiki.

The current system is very convoluted. Being on a fourth level subpage on a different wiki with 90% of the comments not being signed, and using an emoji system for distinguishing resolved/unresolved issues makes it a nightmare for a) finding issues, b) responding, and c) asking for more details. It would be easier to have a page like Wikipedia:Dark mode reports so more editors could help fix issues. We should import the page here and archive the MediaWiki wiki page. Thoughts? @SCP-2000, FeRDNYC, and I Am Andumé: as editors involved there on fixing issues (if I've missed someone feel free to ping them). —Matrix(!) {user - talk? - uselesscontributions} 14:42, 5 October 2024 (UTC)[reply]

Survey (dark mode reporting)

Following the response from WMF, I think it's a good idea for a survey to check if we want to proceed further. @Xaosflux, FeRDNYC, SCP-2000, Isaacl, Phil Bridger, WhatamIdoing, and Thryduulf: and any other people, please state your position briefly:

Implementation

Okay, the consensus is the people fixing dark mode issues can decide the location, and FeRDNYC has also expressed the current issues with the current system. Dark mode issues are ultimately usually a local problem, and WMF has also said this is technically possible. We would need to do a few things:

  1. Import the MediaWiki page to enwiki with the options "Copy all the revisions for this page" and "Assign edits to local users where the named user exists locally" (this is important for archiving later).
  2. Use User:ClueBot III archiving (User:lowercase sigmabot III relies on signatures which won't work out)
  3. Repoint MediaWiki:Vector-night-mode-issue-reporting-notice-url and make MediaWiki:Vector-night-mode-issue-reporting-preload-content include signatures
  4. Archive the MediaWiki enwiki page.

I think we can start working on this. —Matrix(!) ping onewhen replying {user - talk? - uselesscontributions} 08:57, 12 October 2024 (UTC)[reply]

I'm fine doing the transwiki import for this when ready, but I'm not seeing a consensus in the discussion above yet. The "assign local" part is not needed; I doubt anyone at mwwiki will care about that page, we're not going to delete anything there but can just slap a cross-wiki redirect on it. So what next? Someone that hasn't !voted on this above should eventually close this discussion with a result. For the xmlimport part, feel free to ping me at that time. — xaosflux Talk 11:43, 13 October 2024 (UTC)[reply]
Fair enough. I'll wait for consensus to develop (I just got impatient since no once was participating). —Matrix(!) ping onewhen replying {user - talk? - uselesscontributions} 11:49, 13 October 2024 (UTC)[reply]

Sortition for elevated permissions

Proposal for trial: assignment to a small random group of editors to elevated permissions for a fixed short term by sortition.

  • Test 1: Selected extended-confirmed editors, who have edited in the past 100 days, get AfC and/or new page reviewer, which have backlogs. They still have to read the instructions. (PCR is too weak for a practical experiment imo.)
  • Test 2: Selected auto/confirmed editors, who edited recently, get bumped into extended-confirmed.
  • Rules: Any admin can strike for any behavior at any time; one strike and you're out; no extension of term; no exceptions. Also: you cannot refuse permissions, and your editing or sanction history (but not block history) has no bearing on whether you get or don't get permissions. Every admin and editor with equal permissions capable of oversight will have a readily-accessible list of test editors. (It's not difficult to deduce otherwise.)
  • Numbers: As a conservative estimate for a first experiment, maybe 200 editors on both tests simultaneously for 6 months, depending on the activity level of those in the sample -- if 20 editors substantially increase their activity in response, that's measurable and manageable.

The purpose is to increase engagement by somewhat active editors across the spectrum, and perhaps even motivate requests for permanent permissions and adminship down the line. In that spirit, if a test editor loses permissions in the one-strike rule, it should have minimal or zero bearing on requesting permissions in future. This is a learning and motivational experience. That permissions here are ultimately reversible and have oversight means that, on balance, if an ill-behaved editor now ends up being able to credibly seek permissions in future, this model, should it be causative, was indeed a success.

Research and benefits and cautions

Sortition literature addresses both issues that have zero bearing on WP governance, and issues that are quite important. Additionally, I believe there are issues unique to WP that sortition may address that the literature has not yet done. Review: (TG Bouricius 2013 "Democracy Through Multi-Body Sortition: Athenian Lessons for the Modern Day").

What is proposed is called partial governance by sortition with rotation and mandate (Owen and Smith 2018 "Sortition, rotation, and mandate"). Known and possible benefits and cautions:

  1. Random selection is more likely to give demographic and ideological representation (Ebadian et al 2022 "Is Sortition Both Representative and Fair?"). While WP editors are not representative of general populations, our adminship is even less representative (in Corple 2016 "Beyond the Gender Gap" p.25: 6% vs 15%+).
  2. A high barrier to entry of WP adminship and some permissions, combined with thanklessness of tasks and relatively low social prestige, means that we are probably below rate-of-replacement on adminship, and there are backlogs for areas needing permissions. Sortition, if it results in participation, relieves this burden. It also increases representative fairness and ideological diversity to those who would handle the content and administrative backlogs. (Afaik this is a WP-unique issue.) In Polish Wikipedia the exclusionary effect on new candidates of acquaintancy among admins was studied (Spychała et al 2014 "Does the Administrator Community ... Acquaintance Relation?"); so if a similar phenomenon exists in all permissions then sortition would help disrupt it.
  3. If there is admin corruption (and some editors have claimed as such), sortition is suggested to reduce it (Bagg 2024 "Sortition as Anti-Corruption"). It also potentially is a check against administrative subversion (Sutherland 2011 "What sortition can and cannot do") by cabals of editors, as exposed recently in Croatian Wikipedia.
  4. On the effects of granting priveliges/power: In (Sassenberg et al 2014 "Power corrupts: revisited"), the relationship of elevated power and a sense of communal responsibility vs individual corruption (whether one is elevated as opposed to the other) is complex with contradictory results in the literature. In general, if people are in a socially-oriented environment and goals, which I'd suggest epitomizes WP editing, then power would orient them toward the former. However, the review also suggests that the perception of power as an increase opportunity or promtion, rather than just increased responsibility, is a big part of the increased motivational effects, which would suggest that since sortition may lower the prestige of elevated priveliges, it would have a negative effect on motivation; but this seems again highly social-context- and goal-dependent in the literature.

My brief literature stroll suggested possible routes for future investigation on WP; for further on power and motivation is Pappas APA 2021; and in particular we might push hard to raise the social prestige of elevated priveliges on WP, as well as their associated social responsibilities, per management papers like (Friedrichs 2023 "The benefits of prosocial power motivation in leadership"). Also while it's tempting to consider, if this experiment is successful, a radical future proposed sortition of admins, akin to the admin-for-a-day proposed in 2012, but per WMF this is not legally doable, the prohibitive priveliges being rollback and deleted material. SamuelRiv (talk) 22:39, 7 October 2024 (UTC)[reply]

I have trouble imagining us (i.e., those of us who have achieved a measure of power and control in the current system) being willing to give up control over permissions, no matter how slight this might be.
That said, I think that both Test 1 and Test 2 would be worthwhile experiments, and I specifically suggest considering selecting candidates for Test 2 from among those who are nearly EXTCONF anyway (e.g., they have the time but they're short 100–200 edits, or they have the edits, but they're short 1–2 months).
In terms of the size of the experiment, that really ought to be determined by a Power (statistics) analysis. WhatamIdoing (talk) 17:22, 9 October 2024 (UTC)[reply]
Even if there's an element of power and status to them, the vast majority of what people with advanced permissions do is just drudgery. It seems really unlikely to me that somebody randomly assigned NPP or even admin is actually going to want to use them. And one of the main functions of the perm system is to reduce the attack surface these rights offer by only giving them to people motivated enough to ask for it.
Also, yes AfC and NPP are backlogged, but 'reviewing the reviewers' is also work and there are very few admins doing it. This would massively increase that workload - who's going to pick up the slack? – Joe (talk) 17:58, 9 October 2024 (UTC)[reply]
I imagine that an editor who receives a note saying something like "You've been given this permission temporarily. Please read up and use it if you want" might use it a few times, at least to try it out. If they have a positive experience, they might request to the perm later through the usual channels.
Giving a perm only to those motivated enough to ask means that a higher percentage of the requesters is improperly motivated. Undeclared paid editors will be more motivated to ask for the permission than an ordinary volunteer. WhatamIdoing (talk) 18:20, 9 October 2024 (UTC)[reply]
I am quite a fan of sortition for filling real-world positions, both where it is used in many countries (mainly for selecting juries) and for some other positions. A few thoughts on its applicability to Wikipedia:
  1. I doubt that many people would devote much time to the task, because they have to earn a living, and paying the people selected would cause many other issues.
  2. Many people would try out their new permissions, but most would drop out.
  3. There need to be clear success/failure criteria. Too many things are tried here, then clearly fail, but continue to be used because of the sunken cost fallacy (I know this is controversial, but I would class draft space as being one of these).
I'm sure I could come up with loads more points, both for and against, but I have to go now. Phil Bridger (talk) 19:49, 9 October 2024 (UTC)[reply]
Clear criteria are highly desirable. Unfortunately, I'm not sure that a single metric works (e.g., we don't want to lose these randomly selected editors and we don't want WP:UGLY articles in the mainspace), and it's entirely possible that doing the jobs correctly would result in the selected editors quitting. For example:
  • Existing AFC promotions have a very low rate of deletion at AFD. (I believe that the normal rate is about 75%.) Given that they're supposed to promote articles that are likely (i.e., 51%, not 90%) to survive AFD, this means that they are underpromoting and overrestricting.
  • If the new AFC people collectively promote articles that get deleted only 40% of the time, that's a sign that they're doing it correctly (still underpromoting, actually), even though theirs are getting deleted more often than older AFC folks. Thie AFD metric would show success.
  • But: if each AFD, or the run up to those AFDs, comes with recriminations and complaints about how they're being too "lenient", then the yelled-at editors might quit. The editor-retention metric would show failure.
If we get mixed results, what should we do? WhatamIdoing (talk) 21:50, 9 October 2024 (UTC)[reply]

RfC on In the news criteria

There is a request for comment on the In the news criteria at Wikipedia:Village pump (policy) § RfC: In the news criteria amendments. voorts (talk/contributions) 23:01, 7 October 2024 (UTC)[reply]

Idea lab

Uppercase fullname policy shortcuts

In the spirit essays like WP:WTF? OMG! TMD TLA. ARG! and WP:ALPHABETTISPAGHETTI and WP:UPPERCASE, I'm trying to do a lot more lowercase fullnaming when referencing policies like WP:OriginalResearch or wp:competenceisrequired. I've personally found this less likely to be cognitively associated with shouting or lawyering, more self-explanatory without needing a hover, and much easier on the eyes. Hopefully newer editors have felt the same.

Two things I'd like to address:

  1. Not all subpolicies have redirects in both lowercase and camelcase. I just want to make sure they can all be made without controversy.
  2. On the policy pages themselves, the shortcuts to subpolicies are always uppercase. So we have (in RS) both WP:UBO and USEBYOTHERS as shortcuts in the box, but as only UBO is an acronym, why can't we have the second shortcut suggestion be WP:UseByOthers? (Similar across the P&G.) It's just an indicator that other shortcuts besides UPPERCASE exist.

Relatively minor thing that won't change the actual functionality of anything. It just makes the replaces the suggested full-name spelling (not acronyms) of P&G shortcuts from uppercase to camelcase. SamuelRiv (talk) 19:26, 19 September 2024 (UTC)[reply]

To pre-empt the objection that editors should pipe plaintext to P&G as suggested in the essays I linked: I agree, that's great, if editors actually did it with any regularity. For my own part, piping is an extra bit of typing that may not be as clear that I'm referencing P&G in discussion in the first place, which is often important, since I've found people rarely click links anyway. SamuelRiv (talk) 19:32, 19 September 2024 (UTC)[reply]
I don't think you're likely to get any pushback on point 1. It has long been my practice to refer to such things in whichever case makes most sense in the sentence I am writing (usually lower case or with a capitalised first letter) and, if "show preview" shows it as a red link, create a redirect. I don't think I've ever had anyone revert this. I'll have to think a bit more about point 2 - there's a danger of bloat there. Phil Bridger (talk) 19:50, 19 September 2024 (UTC)[reply]
To be clear on #2: in the box in the P&G that gives the shortcuts in bold blue text: one is an acronym and one is the fullname, so in my linked example, the box says Shortcuts: WP:UBO WP:USEBYOTHERS. I suggest replacing the fullname shortcut in the P&G from allcaps to camelcase, so the box now says Shortcuts: WP:UBO WP:UseByOthers. I'm not sure where you're seeing bloat, as not a single byte is being added or subtracted, and functionally nothing is changed. SamuelRiv (talk) 20:01, 19 September 2024 (UTC)[reply]
I see one possible point of contention: in many skins including legacy vector, the search includes all redirects, and some might be annoyed to see a ton of redirects preemptively clog up the suggestions when they want to find something else after typing the first word. Personally, I like point 2-style redirects much better. Aaron Liu (talk) 23:29, 19 September 2024 (UTC)[reply]
Legacy Vector search is case-sensitive? So if I start searching "mrna", it brings up a list including "Mrna", "mRna", "mRNA", all of which link to the same thing? If that's the case, and someone is still using such software, then the adding or removing of case-sensitive redirects has surely long since stopped being a cause of heartache for that person. SamuelRiv (talk) 07:26, 20 September 2024 (UTC)[reply]
There are a great many ways of searching Wikipedia, some of which are case-insensitive and display a list of possible results as you type. This includes the internal search engine, which is independent of which skin you use (you see the same results in vector, vector legacy, monobook, etc). Thryduulf (talk) 11:29, 20 September 2024 (UTC)[reply]
I don't think the internal search engine brings up multiple results to the same page due to redirects. Aaron Liu (talk) 11:51, 20 September 2024 (UTC)[reply]
That makes sense. Still, I like the CamelCase redirects better since it's very clear where the words separate. Aaron Liu (talk) 11:52, 20 September 2024 (UTC)[reply]
You know what separates words more clearly than CamelCase? Anything spaces. "You're violating our policy about WP:BiographiesOfLivingPeople" vs. "You're violating our policy about WP:biographies of living people." Also easier to type; mostly doesn't need new redirects; and looks way less weird to everyone but programmers. (WP:biographiesoflivingpeople is even worse.) —Cryptic 12:37, 20 September 2024 (UTC)[reply]
I don't advocate for redirects like that and merely repeat the title. The UseByOthers example goes to a section with a different name. Aaron Liu (talk) 12:45, 20 September 2024 (UTC)[reply]
As could WP:Use by others. —Cryptic 12:55, 20 September 2024 (UTC)[reply]
CamelCase is a tiny bit less effort to type and still indicates that the link is a shortcut. I think the reason everything caps is precisely to differentiate them as redirects, and some of that differentiation should be preserved. Aaron Liu (talk) 12:58, 20 September 2024 (UTC)[reply]
Personally I don't feel that the visible link text should be differentiated as redirects. This primarily serves to codify a term (in allcaps or camel case) as jargon. There are times when this can lead to greater concision, but most of the time the gain is small, with a cost of greater confusion for those who don't already know the title of the destination and the corresponding text. For example, often non-neutral points of view get labelled as being WP:NPOV. I appreciate the point of view that learning a community's jargon is part of joining that community. I feel, though, that English Wikipedia has plenty of jargon already without every shortcut being used as jargon. isaacl (talk) 15:55, 20 September 2024 (UTC)[reply]
The reason I'd advocate camelcase as the second suggested redirect (in the little redirects box in the P&G sections), as opposed to spaced-out prose versions (which I'd also like to see used more by editors), is that camelcase is also at least a little suggestive that there is an acronym people use, or i.e. that a newbie following a discussion might more readily deduce 'WP:UseByOthers ↔ WP:UBO'. If everyone here would prefer listing 'WP:Use by others', that's fine by me; one could also put three shortcuts instead of just the two: 'WP:UBO WP:UseByOthers WP:Use by others'. SamuelRiv (talk) 17:38, 20 September 2024 (UTC)[reply]
Furthermore, spelling abbreviations out can at least give clue as to what the jargon means. Aaron Liu (talk) 21:41, 27 September 2024 (UTC)[reply]
@SamuelRiv, if you'd like this to be a bit easier, then try switching from 'Source' to 'Visual' in the Reply tool for a few days.
Use its Link tool for adding links. In the visual mode, just type [[ and it'll notice that you want to make a link and open the tool for you (alternatively, click the button in the toolbar or use the keyboard shortcut (=⌘K on a Mac). Type the shortcut (e.g., WP:CORP) into the link search box, and it will offer you a link to the full title (e.g., Wikipedia:Notability (organizations and companies). For individual sections, open the page in a tab, and paste the whole URL into your comment. For example, I opened WP:SIRS in another tab, and pasting the whole URL gives me a nicely formatted link to Wikipedia:Notability (organizations and companies)#How to apply the criteria.
I suggest trying this out for a few days and seeing whether you like it. WhatamIdoing (talk) 06:14, 25 September 2024 (UTC)[reply]
@WhatamIdoing The source mode's link tool in the toolbar does the same thing. Aaron Liu (talk) 21:40, 27 September 2024 (UTC)[reply]
The [[ sequence only works in the visual mode. WhatamIdoing (talk) 22:03, 27 September 2024 (UTC)[reply]
Yes, but the link icon in the toolbar works the same. (Also, ConvenientDiscussions has an inline-typing linking-assisting pop-up that autocompletes, even though it doesn't automatically expand the redirect.) Aaron Liu (talk) 04:17, 28 September 2024 (UTC)[reply]
Late response, but this is awkward in discussions. In practice, editors have wanted to have a shorthand way to both type out the policy they are referencing and also to read-and-refer to it. The problem is that anyone who hasn't been on discussion pages for years has no idea where to even begin understanding what they mean, so camelcase at least is a middle ground that mitigates two issues: shout-i-ness and un-parse-ability of alphabettispaghetti. The replacement in the side boxes is a completely passive notification to editors that camelcase is simply another option for typing the thing they always type, even though typing the whole policy out, or linking it into prose, would of course (usually) be preferable. SamuelRiv (talk) 22:21, 7 October 2024 (UTC)[reply]
If we are to proceed with advertising such shortcuts in {{sh}} boxes, I'm sure that's visible enough to necessitate an RfC, or at least {{centralized discussion}}. Aaron Liu (talk) 23:27, 28 September 2024 (UTC)[reply]

Fix Draftification with a new template

Draftification has long been criticized as a backdoor to deletion. In New Pages Patrol (NPP), it is common to move new articles that are not ready for mainspace to draftspace. This way, articles that could potentially be suitable for Wikipedia, but are not yet, are preserved. The article creator then gets a chance to improve their article without NPPers breathing down their necks or having it taken to Articles for Deletion. If anyone, including the article creator, objects to draftification, the article should be moved back to mainspace (draftification should be reversed). This is explained by DRAFTNO #6 and #7. No reason is required for the objection.

Problem: However, we also have a rule that drafts that haven't been edited for six months get automatically deleted, under Criterion for Speedy Deletion G13. So, well-meaning New Page Patrollers will unilaterally draftify new articles that are not yet ready for the encyclopedia. The new editors who created the article may disagree with the move, without knowing that they can object. The new users can get discouraged and leave Wikipedia altogether, and after six months the draft is deleted under CSD G13. As this process happens without community discussions, it results in draftification being called a "backdoor to deletion".

Solution: This problem can be solved without changing policy or current practice. We just need to make it very obvious to new users that they can object to draftification. We can also make it easy to reverse the draftication (assuming the new user is autoconfirmed). I suggest we do this by adding a template to all draftified articles. The template would include a big blue button, similar to the "Submit the draft for review!" button at Template:AfC submission/draft, which says "Object to this move". Clicking this button either: 1. Leaves a message on the talk page of the editor who draftified, notifying them that there has been an objection to the move and requesting that it be immediately reversed. 2. Moves the page back to mainspace automatically, or if the editor's account is unable to perform this task, creates an entry at Requested moves/Technical moves to that effect. The latter is better, but also more technically complex. Adding a similar button to Template:Uw-articletodraft, the warning typically given upon draftification, would also be helpful.

Implementation: Once the new template is ready, it can be added to MPGuy's MoveToDraft userscript, which is the most common way for NPPers to draftify articles. It should be placed above the AfC template on all draftified articles.

I would appreciate comments from technically skilled editors, who could create this template (or tell me that it's impossible), from NPPers who draftify articles, and from uninvolved editors who have opinions on the draftification process. Toadspike [Talk] 10:37, 26 September 2024 (UTC)[reply]

This idea isn't really my own, it was obviously sparked by the most recent RfA. A similar idea was previously discussed here, but that discussion proposed a requirement that all editors have to follow (policy), not a technical solution, and turned into a trainwreck. To prevent something similar, I ask all participants to please focus on improving the current situation instead of debating the morality of draftification as a whole. Toadspike [Talk] 11:03, 26 September 2024 (UTC)[reply]
Notifying the users who commented most directly on this topic at the RfA: @Alalch E.@User:Onel5969@User:Hobit@User:Fangz@User:Nsk92. I have also notified the NPP Talk page and posted a message on Discord. I am not sure how to notifying all participants of the previous discussion (aside from doing it manually) and I am not sure that is productive considering how many people were involved and how offtopic it got, so I won't do that for now. Toadspike [Talk] 11:07, 26 September 2024 (UTC)[reply]
Are you sure you want to make this an RfC? Is there a BEFORE somewhere? Aaron Liu (talk) 11:32, 26 September 2024 (UTC)[reply]
Good point, I am not sure if the RfC label applies, so I'll remove the templates. I was looking for ways to notify people and misread RFCBEFORE. Toadspike [Talk] 11:34, 26 September 2024 (UTC)[reply]
  • Oppose: The draftification message could be tweaked, but a big button to reverse the move will lead to more AfDs, higher strain on NPP, more BITEY behaviour, and worse editor retention. Draft space is incredibly valuable, and people have some incredibly warped views about the space. If we did something like this then we'd end up chasing away new editors because learning how to make your article meet our complicated guidelines in under 7 days (AfD tag) is not easy for a lot of folks. Draft space gives them the opportunity to work on the content, to receive advise, and to make articles that will actually survive at AfD and allow them to stick around. Really we need to draftify more, and I've taken it upon myself to begin to do so again and encourage others to do. I'm big on editor retention. This is not the way to do it. Hey man im josh (talk) 12:15, 26 September 2024 (UTC)[reply]
    The problem with unilateral draftification is that it can also be incredibly bitey, especially when done for arbitrary reasons that have nothing to do with any of the reasons why something might be deleted at AfD (although this is less prevalent than the trivial reasons things are rejected at AfC). We should be draftifying fewer articles and not sending them to AfD either but rather leaving them in the mainspace (With appropriate tags where justified) so that they can be found and improved rather than pretending that they don't exist for six months and then deleting them. Thryduulf (talk) 12:34, 26 September 2024 (UTC)[reply]
    I'm not really convinced draftification is any worse than the alternatives - tagging is *also* bitey as well, and one user tagging an article and leaving it in mainspace could lead to another user seeing it and deciding to AfD. Draftification could be a way to protect an article until it enters a better state. But I think the other part I have an issue with is the lack of clear guidelines. Clearly some people have an issue with draftification and others do not, and people have different ideas what it is for. That needs to be made more concrete. Otherwise just saying "we should use draftification less" isn't going to lead to any positive changes. Fangz (talk) 12:43, 26 September 2024 (UTC)[reply]
    I agree with the general sentiment – arguing for more or less draftification does not solve the problem that new users basically can't object to it. Toadspike [Talk] 12:47, 26 September 2024 (UTC)[reply]
    I envision a template (possibly one specific for relatively new users?) being something like:
    1. Hi, this article has been moved to a draft form because another user thinks it has potential but is not ready for the encyclopedia just yet. REASON:
    2. You can continue to work on it while it's not published, though note that if not editted for 6 months it will be deleted. Here are some useful resources.
    3. When you think the article is ready you can submit the article to a review, which can give useful feedback. []
    4. Alternatively you may return the article to the main encyclopedia at any time and have it be editted while part of the main encyclopedia. See WP: Draft Object. Note however that if other users think there are unfixable issues with the article it may be put forward as a candidate for deletion. Fangz (talk) 12:54, 26 September 2024 (UTC)[reply]
    I like the idea for the user warning. Aaron Liu (talk) 12:59, 26 September 2024 (UTC)[reply]
    Tagging never leads to an article being automatically deleted. – Joe (talk) 18:43, 26 September 2024 (UTC)[reply]
    In my view draftified articles should (semi?) automatically return to the mainspace after timeout instead of be deleted. Or at least be re-evaluated for notability. I do not really see the reason for automatic speedy deletion, except as backdoor deletion. Fangz (talk) 18:59, 26 September 2024 (UTC)[reply]
    I like that idea. They don't, though, so it's a bit of a moot point in terms of current policy. – Joe (talk) 06:16, 27 September 2024 (UTC)[reply]
    Why can't they just improve it in mainspace, without the sting on of an initial rejection and a six month deletion countdown hanging over them? I don't get why you keep presenting this as a choice between draftspace and AfD. – Joe (talk) 18:46, 26 September 2024 (UTC)[reply]
    The reason is that "improving it in mainspace" has its own issues. An article in mainspace has to juggle being of service to the reader to being of service to the editor. This implies formal processes and wikijargon for consistency, unified templates for issues in the article, clear and ruthless labelling of problems and so on. There's a strong tendency for the first experience of an editor to be a very public and humiliating fight against established editors who have a better understanding of wikipedia processes, quickly driving the editor away or getting them blocked. It is also very difficult to improve on this experience as it would imply fundamental changes affecting all sorts of things. Meanwhile improving an article in draft mode allows for a more informal process of communication to shepherd an article towards an acceptable state. Fangz (talk) 19:10, 26 September 2024 (UTC)[reply]
    I did a little work on page view statistics recently. The median article gets about one page view per week. So if the new article is typical, then it doesn't have to "be of service to the reader", because there aren't really any readers. Editors (especially NPP and RecentChanges folks) may look at a brand-new article a few dozen times on the first day, but once the reviewers leave it alone, most articles just don't have much traffic.
    I think the reason we are unwilling to "improve it in mainspace" is because we're scared that we'll forget that it was there, and years later, someone will be embarrassed to discover that an WP:UGLY article has been neglected ever since. We are using draftification and other threats as a way to make other WP:VOLUNTEERS improve the article to our idea of acceptable quality. WhatamIdoing (talk) 20:40, 26 September 2024 (UTC)[reply]
    I don't know if we're looking at different draft namespaces, but an "informal process of communication to shepherd an article towards an acceptable state" sounds like the precise opposite of our current AfC process. – Joe (talk) 06:19, 27 September 2024 (UTC)[reply]
I don't like the idea of a button but I do think the template should be changed. I think having a button suggests it's a default option, but I think a link is okay. Fangz (talk) 12:37, 26 September 2024 (UTC)[reply]
  • This is the idea lab so no bolded comment from me, but I have mixed feelings. I am in favour of softening the experience for newcomers, but I'm opposed to the concept of draftification being automatically reversible. If a new page patroller reviews a new article and moves it to draft because it's clearly unsuitable for mainspace, the creator should need to do more than just say "I object" in order to move their clearly unsuitable article back again. I've recently proposed that all of draftspace should be move-protected at the semi level (the proposal was not well received - fair enough). This is probably the rule I ignore more than any other on Wikipedia, mostly dealing with spam sockfarms that try to abuse the rule to promote their garbage. Besides, a new user whose submission is quarantined to draft space and they're left with instructions and a list of suggestions with helpful links is already getting better treatment than most editors ever have or will, and if their reaction to that is to rage-quit then they're probably not a good fit for the collaborative environment of Wikipedia anyway. Ivanvector (Talk/Edits) 12:57, 26 September 2024 (UTC)[reply]
    @Ivanvector, you know the joke about "If you ask three people, you'll get four opinions"? I wonder if we ask three NPPers what "ready for mainspace" means, if we'd get four opinions. AFAICT, "ready for mainspace" most often means "contains at least as many refs as the median article, but higher quality ones". All the children in Lake Wobegon are above average, and all the new Wikipedia articles must be, too. WhatamIdoing (talk) 20:12, 26 September 2024 (UTC)[reply]
    I feel like I might vaguely recall a discussion on that topic sometime in the not too distant past. Folly Mox (talk) 22:55, 26 September 2024 (UTC)[reply]
    176 comments from 22 editors, and I probably had 22 opinions all by myself. ;-) WhatamIdoing (talk) 22:23, 27 September 2024 (UTC)[reply]
    All pages are effectively move-protected at the semi level already. Moving requires an (auto)confirmed account. SilverLocust 💬 07:17, 5 October 2024 (UTC)[reply]
  • As far as I see it draftification should never be used for subjects which pass GNG, and it should only be standard for things like films/TV series/games which are in the works but have not yet begun production. Subjects with debatable notability should be sent to AFD to the issue can be resolved.★Trekker (talk) 13:00, 26 September 2024 (UTC)[reply]
    Subjects that pass WP:GNG should never be draftified at all, instead they should be tagged and dealt with using normal community procedures. I agree that films/TV series/games/political events probably best fit the bill for draftifications, but so do potentially notable but underdeveloped articles. Sohom (talk) 13:33, 26 September 2024 (UTC)[reply]
    This is out of step with the present form of Wikipedia:DRAFTIFY, and I don't think it makes sense anyway. Articles that fail GNG should not be draftified, they should be AfDed. Films etc that are in the works should not be draftified merely because they aren't in production, and it's not really a great use for draft space because there's no guarantee that there would be a change of situation to establish notability within 6 months. Articles should be draftified only if the reviewer believes the article can be editted into an acceptable state within the time window. This implies a pass of GNG - i.e. a belief that reliable sources are potentially out there. Remember that GNG is about the *subject*, not about the state of the article. Fangz (talk) 14:09, 26 September 2024 (UTC)[reply]
    In my view the correct use of draftification is sort of as an alternative version of the WIP template. An acknowledgement that the article is not ready and should be being worked on and will likely have multiple issues, but in a protected sandboxed environment to avoid overly zealous moderation and promotion of misunderstanding for casual readers, and without implying the original editor is the one working on it. For new users it should offer a less formal and jargony process to learning how to improve an article than tagging based methods, because the latter has to balance the need to inform *readers* as well as editors. Fangz (talk) 14:23, 26 September 2024 (UTC)[reply]
    If you evaluate that a article passes WP:GNG, then there is not point in draftifying it, you could just add a {{sources exist}} template, patrol and move on. Alternatively, if you evaluate that a article fails WP:GNG, there is no point in wasting the article creator's time and you should WP:AFD/PROD it.
    The only case where you would draftify a article is if you saw a article that a) had a credible claim to significance/notability b) does not meet/prove notability in it's current state c) has been created in the last week or so by a inexperienced article creator. Sohom (talk) 14:43, 26 September 2024 (UTC)[reply]
    Not sure if we're disagreeing or we're having some semantics thing about what "passes GNG" means.
    But anyway there's issues beyond notability, in my view that's probably more useful. Fangz (talk) 15:08, 26 September 2024 (UTC)[reply]
    If an article has a credible chance of being kept or merged at AfD then it should not be draftified.
    If an article would definitely fail AfD and there is no editing that can fix that it should be sent to AfD. Thryduulf (talk) 15:57, 26 September 2024 (UTC)[reply]
    I think then you're pretty much arguing that the draftification process should be removed entirely, and I don't agree with that. It has its advantages. It should not be made a mandatory process by any means but just as some users prefer to work on articles as a draft and then push to the public wiki, it can be a better resolution to certain issues than the alternatives. Fangz (talk) 17:44, 26 September 2024 (UTC)[reply]
    I'm not sure that the Draft: namespace has any advantages over a user sandbox, and m:Research:Wikipedia article creation and m:Research:AfC processes and productivity says that the Draft: namespace is where articles go to die.
    I do think that we've fallen into a false binary here. The options are not "garbage in the mainspace" vs "auto-deleted as in the draftspace". There are other options (e.g., sticky prods for uncited articles, userification, bold stubbification, bold merging, developing a more consistent and predictable standard for evaluating articles, etc.). WhatamIdoing (talk) 20:20, 26 September 2024 (UTC)[reply]
    I think there is a argument to be made that this landscape might have changed a fair bit since this research was done. The latest data that these projects consider is from 2014-2017. WP:ACTRIAL happened after that research was done, and Wikipedia's policies have changed since those times. Sohom (talk) 20:48, 26 September 2024 (UTC)[reply]
    It's possible that things have changed, and I'm never one to turn down a new research project if you happen to be volunteering to do it (I believe that all the necessary data is public), but looking at the overall deletion rate in that namespace, it seems unlikely that the result will be materially different. WhatamIdoing (talk) 20:31, 27 September 2024 (UTC)[reply]
    I think then you're pretty much arguing that the draftification process should be removed entirely, and I don't agree with that. I'm sorry to pick on you but this is the clearest example yet of the circular reasoning that has got us into this mess: draftification must be good because we do it, so we must keep doing it because it's good. From literally the moment draftspace was created and people started doing this (before that, the equivalent process of userfication was expressly forbidden without prior discussion), others have been pointing out that the underlying logic makes no sense. Draftification is only for articles that shouldn't be deleted, but it's also only for articles that can't be in mainspace. But since fix good content in place is a part of the editing policy and almost all the community accepted reasons for deletion involve the potential of the article, not it's current state, the intersection of those two sets is functionally zero (apart from some consensus-established edge cases like paid creations or upcoming films).
    This is why attempts to clarify and improve policy around draftification—and I've been closely involved in many of them—keep failing. You try to find a solid basis for guidelines and there just isn't one. We really need to stop trying to square the circle of justifying draftification as it is practiced now, and start asking what we the community actually wants to achieve with it and whether what we're doing now fulfils that aim. So far it's not looking good for the send-them-all-to-draftspace-and-the-god-of-notability-will-recognise-his-own camp, because there's not a shred of evidence that it helps improve content, retain editors or manage the NPP workload, and as WAID says above the empirical studies we do have concluded the precise opposite. But that picture could change with more research – somebody just needs to step up and do it! – Joe (talk) 07:01, 27 September 2024 (UTC)[reply]
    @Joe Roe Draftification is only for articles that shouldn't be deleted, but it's also only for articles that can't be in mainspace. That is the exact reason why draftspace exists in the first place. Imagine you see a article with the following content: Nicholas Carlini is an amazing researcher at Google working on adversarial machine learning. created in the last week or so and sourced to a person's personal web-page. On doing a quick google search, you see that the person exists and is a researcher at said company, however, due to your unfamiliarity with adversarial machine learning topic-area you are not able to immediately identify the person's impact on the field. Do you 1) WP:BITEly nominate the article for deletion 2) leave the content up for somebody to deal with it (and hope that the other somebody will not choose option 1) or 3) draftify the article with a note that more sources are required to prove notability? Sohom (talk) 11:25, 27 September 2024 (UTC)[reply]
    @Sohom Datta None of them. What you do is add a template to the article noting the lack of sources, leave a friendly message on the creator's talk page explaining the issues in plain English, and leave a note about it at Wikipedia talk:WikiProject Computer science. Depending on what your research found you could add more information, add some sources that might or might not demonstrate notability, remove the peacock terms, etc. Yes, this is more effort than blinding draftifying or AfDing but it is far more important that things get done well than things get done quickly. Thryduulf (talk) 12:37, 27 September 2024 (UTC)[reply]
    @Sohom Datta, thanks for creating Nicholas Carlini, whose first version does not contain the hypothetical sentence you gave in your comment above. In your example above, why can't that stay in the mainspace? I frankly don't love it, and I'd immediately pull the word "amazing" out, but what's the policy basis for saying "that article truly can't be in mainspace"? WhatamIdoing (talk) 21:10, 27 September 2024 (UTC)[reply]
    @Fangz I'm not arguing for the elimination of draftspace, it has it's uses as an optional space where articles can be developed over time so they don't have to meet all the relevant content policies from the very first edit. I'm also not arguing for the elimination of all draftifcation, just the majority of unilateral draftification because, as Joe has put better than I can, it is not a net benefit to the project as currently practised. Thryduulf (talk) 12:46, 27 September 2024 (UTC)[reply]
    There's a middle ground between meets-GNG-mark-as-reviewed and fails-GNG-send-to-AfD: recently created articles where the sources in the article do not validate GNG, but where the new page reviewer hasn't done a BEFORE search. I think it's perfectly fair (and permissioned within the current draftification process) to say "this recently created article doesn't demonstrate GNG yet, but I'll kick it back to the creator in draft form to put in some more sources." Dclemens1971 (talk) 04:43, 29 September 2024 (UTC)[reply]
    Punting it to draftspace without doing a BEFORE is definitely not something we should be tolerating. Thryduulf (talk) 10:21, 29 September 2024 (UTC)[reply]
    This would mean we're either leaving these articles unpatrolled (which is obviously undesirable), or giving new page patrollers the job of finding sources on every article where the original author hasn't, which would be ideal in, well, ideal conditions, but puts the burden of actually sourcing the encyclopedia on a very small group of editors. In my opinion, there should be a way to ask the original author to add sources to show it meets GNG, beyond just putting a "notability" tag and being done with it. Chaotic Enby (talk · contribs) 19:53, 1 October 2024 (UTC)[reply]
    I agree with Chaotic Enby. Drafification is a good solution because it strongly encourages the author to improve the article, and, most importantly, gets it out of mainspace so that it isn't a problem for innocent readers – without forcing NPPers to clean up other peoples' messes. Cremastra (talk) 20:06, 1 October 2024 (UTC)[reply]
    Drafticiation [...] strongly encourages the author to improve the article. That's the theory but the evidence is that in practice it very rarely does this. There is also little to no evidence that most pages moved to draftspace are actually a problem for innocent readers rather than being a problem for those who want immediate perfection. Thryduulf (talk) 20:47, 1 October 2024 (UTC)[reply]
    About wanting to ask the original author to add sources to show it meets GNG, beyond just putting a "notability" tag and being done with it, I wonder if it's actually possible to do this in a non-coercive way. The options right now are:
    • Just ask (what the {{notability}} tag does).
    • Ask under threat of deletion (WP:BLPPROD and WP:PROD).
    • Move article to Draft: space (essentially holding the article hostage, to be deleted if you give up or can't figure out how to do it).
    • Send to AFD today.
    AFAICT a method for "force another WP:VOLUNTEER to improve the article to my standards" option has proven pretty elusive. But if you want to reach that point, I suggest that you take a baby step towards it in the form of getting a policy (any policy, really) to actually, directly, unambiguously say that every article must cite at least one source. Until the community agrees that this actually is a requirement, then we have no hope of getting them to increase the requirement all the way up to "show it meets GNG". WhatamIdoing (talk) 00:20, 2 October 2024 (UTC)[reply]
If a new editor thinks their article is ready for mainspace, they will put it there. They will also happily revert the move. If a new editor is unsure, they will probably ask for help first or use draftspace. Cremastra (talk) 19:35, 26 September 2024 (UTC)[reply]
I think the concern expressed by Joe and others who support the "backdoor" theory is that new users do not know how to revert the move to draftspace. Do you disagree with that assumption? Toadspike [Talk] 19:53, 26 September 2024 (UTC)[reply]
I think most users do not know how to revert the move, yes. I also think we shouldn't hand it to them on a silver platter, because that likely largely annuls the whole point of draftification. What is the solution to this? I couldn't tell you. Cremastra (talk) 20:09, 26 September 2024 (UTC)[reply]
Is "the whole point of draftification" to make my view of the subject's value more powerful than the newbies' view? Security through obscurity kind of works for that, but not reliably. WhatamIdoing (talk) 20:22, 26 September 2024 (UTC)[reply]
They don't know how, maybe, but more importantly that they don't know that they're allowed to. We have to remember how very unusual our collaborative process is. If an inexperienced editor contributes an article to Wikipedia and then it is swiftly unpublished with a message that there's something wrong with it, they won't think, hmm, I'm not sure if I agree with that, I'm going to revert and/or discuss this with my peer-editors to find a consensus. They'll think that with someone the authority to decide what happens to articles has rejected my contribution, and I'm a mere newbie. At that point they will either give up (the majority) or they'll persevere and get into cycle of trying to satisfy first the NPP reviewer and then a succession of AfC reviewers until they finally give up or manage to write a GA, which seems to be roughly the standard AfC is applying these days Even very experience editors fall into this trap because even though the templated messages try to communicate the full range of options the user has (now at least, after I and others have spent several years fighting for it), it's really hard to communicate that we're all equal and all have a say here within a draft–review structure that implicitly elevates the opinions of reviewers over others. – Joe (talk) 07:31, 27 September 2024 (UTC)[reply]
I've pulled the most recent 10 articles moved to mainspace with the AFCH script. They are:
That's an average of 372.5 words and 12.6 refs. The median article has 338 words and 4 refs. Compared to existing articles, 53% of our existing articles have fewer than 372.5 words, and 83% have fewer fewer than 12.6 refs. One in six articles has fewer words than the shortest in this list. One of three articles is shorter than the second-shortest in this list.
I think it is clear from these numbers that AFC is expecting more refs than existing community practice, and that they are trying to accept only articles that are already as long as ones that editors have been working on in the mainspace for years.
BTW, during the same span of time, more than 100 pages were deleted from the Draft: namespace. You shouldn't assume this means that more than 90% of drafts get deleted, because deletions are bursty and this is a relatively small sample size, but that's about what I expected. WhatamIdoing (talk) 20:56, 27 September 2024 (UTC)[reply]
  • A Conclusion: I am sadly not surprised at the current state of this discussion. Some of the heated off-topic arguments verge on NOTHERE behavior. I am very disappointed to see this from experienced editors. To those of you who simply commented on the proposal: I appreciate you a lot.
Since the default NPP draft template was changed to Template:Draft article a day before this discussion began, I think my proposal is moot. I don't see how we could improve that template much, but I may raise some minor wording changes on the Template Talk. If someone wants to close this discussion, that's fine; if others wish to continue discussing other things here, I wish you the all best. Toadspike [Talk] 21:16, 27 September 2024 (UTC)[reply]
Worth also talking about the usertalk notification MTD leaves, which only provides one option: submit for review. Agree in principle we shouldn't trick people into thinking draftification/AfC is mandatory for a typical article creator. — Rhododendrites talk \\ 13:29, 28 September 2024 (UTC)[reply]
  • Strong Oppose All it will do is destroy the draft system as it stands and eventualy destroy Wikipedia. This almost happened between 2008 and 2012, before the draft process was available, when Wikipedia was flooded with paid/coi editors and there was no effective system to deal with them. Do folk not understand what draftification is. Every publisher has draft process. It is NOT a route to deletion. That is what the detractors of the system say, many of them who are paid to oppose it and destroy it. It is the one of the core safeguards we have against the complete destruction of Wikipedia. scope_creepTalk 11:46, 29 September 2024 (UTC)[reply]
    That comment is almost entirely evidence free assumptions of bad faith. Please try engaging with the discussion rather than just knee-jerking oppose to changing the status quo because it would change the status quo. Thryduulf (talk) 12:56, 29 September 2024 (UTC)[reply]
    Its not evidence free and I resent the fact that you have said my comment bad faith. Why would I make the comment if I didn't know what I was talking about. I've worked in NPP/AFC since it was created and was involved in some of the early discussions. I now how exactly how UPE/paid editors behave. It would lead to an exodus of editors after the place gets flooded with adverts. It would be free-for-all. The reality is that the editor who posted hasn't thought it through and hasn't looked in the archives to see what the situation was like then. scope_creepTalk 16:05, 29 September 2024 (UTC)[reply]
    "Trust me, I was there" is not evidence. Your comment assumes bad faith from those disagreeing with you, and of everybody submitting new articles. Not every editor is paid (and disclosed paid editing is explicitly allowed), not every paid edit (disclosed or otherwise) is bad, not every paid editor (disclosed or otherwise) is attempting to harm the encyclopaedia, not every paid edit (even undisclosed ones) does harm the encyclopaedia. Thryduulf (talk) 16:19, 29 September 2024 (UTC)[reply]
    That is true to certain extent, but the majority of editors who create modern biographical, organisational and product articles which make up the majority are undeclared paid editors. They do not have our best interests at heart and never have done. scope_creepTalk 16:53, 29 September 2024 (UTC)[reply]
    Even if that is true (and you haven't provided any evidence, of either your assertion or the implications of it that these articles harm Wikipedia and/or that draftification as currently implemented and practice prevents that harm), that doesn't mean that draftification as implemented currently can't be improved and that any changes to the status quo will mean the death of Wikipedia. Thryduulf (talk) 17:02, 29 September 2024 (UTC)[reply]
    @Scope creep, what percentage of articles in the draft space do you think get deleted? WhatamIdoing (talk) 18:51, 29 September 2024 (UTC)[reply]
    If drafts get deleted, that's because their creators have abandoned them. That's what G13 is. Perhaps more effort should be spent encouraging article writers to improve their articles after they got moved to draft (where they can be improved without interference), but draftification is not deliberate, malicious backdoor deletion, and I resent it being characterized as such. Cremastra (talk) 19:47, 29 September 2024 (UTC)[reply]
    Is this a Double-barreled question? The comment you're replying to said only "route to deletion", and you've turned it into four separate parts:
    • deliberate
    • malicious
    • backdoor
    • deletion.
    I wouldn't personally characterize any of them as malicious, but I think a fraction of them are deliberate. IMO claiming that nobody ever sent a borderline subject to AFC instead of AFD (which has lower standards in practice) would be rather extraordinary. I frankly don't think we're all so stupid that we can't figure out which route is most likely to end up with the result we prefer.
    If we characterize AFD as the "front door" for deletion, then it seems fair to describe letting articles expire in the Draft: space as the "back door".
    But the original comment is merely that it's not a route to deletion. But if 90–95% all of the articles put on that path actually do end up getting deleted, then is it not basically fair to say that it is one of our routes to deletion? WhatamIdoing (talk) 20:22, 29 September 2024 (UTC)[reply]
  • Oppose. The current verbiage of the tag makes it clear to anyone with a lick of common sense, that the article has potential, but in its current form it is not ready for mainspace. Some of the comments here from folks clearly indicate a lack of understanding of what the draftification process is for. If an article, in its current form, passes GNG, then there are only certain circumstances where it should be draftified (e.g. paid editing), but if an article probably would pass GNG, but does not in its current form (e.g. there are not enough in-depth sources from independent, reliable sources to meet the standard), than that is a poster child for draftification. When I was more active in reviewing articles, I created several custom responses, which took the standard message and massaged it a bit depending on the reason for draftification (e.g. UPE, lack of GNG) or a specific topic (e.g. NFOOTY, Populated places). In some instances those messages contained an offer to ping me directly when they felt the article was ready for mainspace. I am all for article creation, but I also care about the quality and reputation of Wikipedia, which is often seen as the punchline for jokes regarding garbage information on the internet. And I would completely disagree with those who say that draftification is not a net benefit. In fact, I think it is one of the most useful tools to helping improve the quality on WP. Is it always used correctly? No. But that's an education problem with individual users, not an overriding issue with the process itself.Onel5969 TT me 14:34, 29 September 2024 (UTC)[reply]
    I agree with Onel5969. (But also remember to not leave !votes as this is the idea lab, not a formal proposal). Cremastra (talk) 14:36, 29 September 2024 (UTC)[reply]
    Apologies, Cremastra. Onel5969 TT me 19:38, 29 September 2024 (UTC)[reply]
    That might be fine in theory, but it doesn't match the what is happening in practice. Especially given that articles are being moved to draftspace for not being of sufficient quality that are C or even B class. If an article is neutrally written and meets the GNG then there is no justification for moving it to draftspace just because someone might (or might not) have been paid to edit it. Thryduulf (talk) 15:21, 29 September 2024 (UTC)[reply]
    @Thryduulf: Do you have a specific example in mind when you mention C or B class articles? scope_creepTalk 16:13, 29 September 2024 (UTC)[reply]
    See @WhatamIdoing's comment in this discussion. Thryduulf (talk) 16:15, 29 September 2024 (UTC)[reply]
    This list is the state of articles when they come out of the Draft: space. For articles going in to the Draft: space, here's a current list:
    I have skipped redirects, some round-robin page swaps, and a couple of editors moving AFC submissions from User: space to the Draft: space, and tried to include only articles being moved from the mainspace to the Draft: space. I can't get the ORES ratings for these articles, but at a glance, I think that Start and C-class is not an unreasonable description. WhatamIdoing (talk) 19:31, 29 September 2024 (UTC)[reply]
    First, thanks for providing the list. The issue is, in reviewing those drafts, most are solid drafts, and not " Especially given that articles are being moved to draftspace for not being of sufficient quality that are C or even B class." Although I think a more careful explanation could have been made. For example, the first one would have been better with a "more in-depth references from independent, reliable sources" needed, rather than simply saying "more sources needed", as there isn't a single, in-depth reference from an independent, reliable source in the draft. The second and third examples are the exact same issue. The 4th and 5th examples are properly labeled as covert advertising (both editors have been blocked for it - in addition, the 4th one didn't have a single in-depth reference from an independent source, either). The 6th example, while having 3 sources, none are in-depth, and while it might be a spelling difference on the translations of the 2nd and 3rd refs, it does not appear that the article's subject is mentioned in any of them. The 7th article is not a true example of draftification, as it was moved by the author. The 8th and 9th article have zero independent reliable sources (for the 9th, the newspaper referenced does not have a page number, and the link does not appear to bring up anything in depth about the hack lab). Not sure about the 10th, for the history is a bit wacky, but again, does not look like an example of draftification.
I think this illustrates some of the misunderstanding that folks who don't like draftification make. You look at the list provided, and you go, wow, lots of references, most not stubs or micro-stubs, why in the hell were they draftified? Hell, I did that myself, wondering if all 10 were done by a single editor, who perhaps did not have a firm grasp of draftification. But then you dive into the merits of the sourcing, or the upe issues, and it appears all 8 of the draftifications appear justified.Onel5969 TT me 20:32, 29 September 2024 (UTC)[reply]
@Onel5969, I wonder if you could explain "the newspaper" in the 9th article a little better. You say that the article has "zero independent reliable sources", but traditional print newspapers are independent reliable sources. Then you say it doesn't have a page number, but the link takes you directly to a scanned copy of the correct page; the cited article [title given in the citation] is in the last two columns. None of that makes the newspaper less independent. Is your concern that the article appears to predate the use of the name in the article title ("De Zanbak" means "The Sandbox")? WhatamIdoing (talk) 20:51, 29 September 2024 (UTC)[reply]
Could be the translation, but there does not appear to be anything connecting the group mentioned in that article, with De Zanbak. But even if there is, agf, that still is the only in-depth independent source. Onel5969 TT me 01:15, 30 September 2024 (UTC)[reply]
I'm glad we agree that a newspaper is an independent source. WhatamIdoing (talk) 01:20, 30 September 2024 (UTC)[reply]
If a new editor includes 5 sources in their submission and it gets moved to [somewhere I didn't put it] because "more sources needed" or "no sources" how many of them are going to take the time to learn that the experienced editor actually meant none of these sources contain what I think is significant, in-depth coverage in independent reliable sources and then have the confidence to say "actually, this experienced person with the power to remove my article from Wikipedia is wrong and I'm right, I'll learn how to challenge them and how and where to express my view in a way that the powerful people will listen to me" rather than just give up at some point along that path? And before anyone says it, no, just because a few bad faith editors might be among the dissuaded does not justify the loss of good faith editors. Thryduulf (talk) 21:29, 29 September 2024 (UTC)[reply]
I guess that's the difference between editors who care about quality on WP, and those who care about quantity. But that's why I said that the rationale given could have been better. Onel5969 TT me 01:17, 30 September 2024 (UTC)[reply]
Is it really a quality vs quantity question?
Or is this the difference between editors who would rather see a page run through Wikipedia:Articles for deletion or Wikipedia:Proposed article mergers instead of being unilaterally hidden until it gets deleted without the level of community oversight that we expect from AFD? For example, I'm not convinced that "De Zanbak" is a viable subject for an article, but I think there are several ways that we could address that concern, and I don't see the Draft: space helping. In fact, the only thing that moving that page to the Draft: space does that's different from moving that page to the User: space is: It's far more likely to get deleted during the next year if it's in Draft: space than if it's in User: space. WhatamIdoing (talk) 01:26, 30 September 2024 (UTC)[reply]
Well, since draftification isn't a "backdoor to deletion", nor is it "hiding an article", it's definitely a question of quality vs. quantity. Draftification, in short, is a quality control measure. These are articles that might be notable enough for mainspace, but simply aren't in good enough shape to be there. But, like other vehicles in WP, good faith editors might disagree on an article's notability, so for example in the De Zandbak articlem, Jay8g (who tagged it for notability), and Jonathan Deamer (who draftified it) might deem it potentially notable, while you, WhatamIdoing, might have simply sent it to AfD, because you do not feel it notable. But that doesn't mean the system isn't working. Perhaps we can tweak the current verbiage in the template to include where resources about where an editor can reach out for help might be added (e.g. AFC or Teahouse)?Onel5969 TT me 09:20, 30 September 2024 (UTC)[reply]
Well, since draftification isn't a "backdoor to deletion", nor is it "hiding an article", you say that as if there is no possible way good faith editors could disagree, but that simply isn't true. Whether either of those things is true is a matter of opinion (and, in my opinion, one that is consistent with the evidence presented). Thryduulf (talk) 10:07, 30 September 2024 (UTC)[reply]
Hi. No, editors can certainly have different interpretations and disagree on issues. However, in this instance, it is not a matter of disagreement. In order to hold those views indicates a lack of understanding of what the draftification process is. That's not what draftification is, it is, as I've said, simply a quality control measure. It would be like saying, it's a matter of opinion whether or not this person wrote an article about themselves, that can be interpreted as not being COI editing. Of if a an article simply cut and paste the info from Encyclopedia Brittanica, you cannot say it's your opinion that that isn't a copyvio. I mean, I have the utmost respect for you, Thryduulf, and you do a great job on WP. There are things on WP which are subjective (e.g. exactly what constitutes SIGCOV), while others are objective, (e.g. UPE/COI editing, copyvio). What draftification is falls into the latter category. All that being said, we can disagree on whether or not an individual article should or should not have been draftified. You say the evidence presented shows that it was not warranted that those articles be sent to draft. Going through the sources, however, it looks like draftification was justified. That is a difference of opinion. Onel5969 TT me 14:20, 30 September 2024 (UTC)[reply]
It's your opinion that moving an article to the Draft: space is simply a quality control measure.
It's my opinion that moving an article to the Draft: space is also simply a quality control measure that, compared to the available alternatives of leaving it in the mainspace, sending it to AFD, or moving it to User: space, substantially decreases the likelihood of the quality being improved and substantially increases the likelihood of the article being deleted.
Oh, right: Those last two points ("substantially decreases the likelihood of the quality being improved" and "substantially increases the likelihood of the article being deleted") aren't "opinions". They're objective facts. WhatamIdoing (talk) 22:17, 30 September 2024 (UTC)[reply]
Rhodesia Railways 19th class is not a list; it's a train that was in operation for multiple ranges of time. Even if it were a list, the empty headings and only content being a table is nowhere near start-class, maybe even substub. Aaron Liu (talk) 20:47, 29 September 2024 (UTC)[reply]
The existing content in the article is an infobox and a table. Tables are the format preferred by Wikipedia:Featured lists. Empty sections aren't banned, and ratings are based on what is already there. I'd rate it as |class=List today. WhatamIdoing (talk) 20:53, 29 September 2024 (UTC)[reply]
only content being a table have you actually read the page? That infobox is full of content, there are two apparently reliable sources and the table itself has about 20 rows of content. Thryduulf (talk) 21:33, 29 September 2024 (UTC)[reply]
Sorry, yes the infobox as well. I still wouldn't call it a start, though. Aaron Liu (talk) 22:03, 29 September 2024 (UTC)[reply]

Can we consider EC level pending changes?

This is just an idea, and I want to workshop this a bit more, but I think it would be helpful to have pending changes at the extended confirmed level. This could be called "PC2" again (not to be confused with the original PC2) or "PCECP". The idea would be to help enforce WP:ARBECR and similar restrictions where non-extended confirmed users are prohibited from certain topic areas. Under this level, edits by non-extended-confirmed editors would be held for review, while extended confirmed users can approve these edits and thus take responsibility under WP:PROXYING.

I think it would be helpful for pages where (1) parts of the article intersect with a contentious topic, or (2) the article in its entirety intersects with a contentious topic, but not edited frequently. Awesome Aasim 16:54, 27 September 2024 (UTC)[reply]

This seems like it could be useful. It would have to be restricted to infrequently edited pages (likely excluding all current events articles) so as not to overwhelm Pending Changes every time Reuters publishes a new story or an edit war erupts. The big question is: what problem are you trying to solve? Toadspike [Talk] 20:39, 27 September 2024 (UTC)[reply]
There are some contentious topics designated either by ArbCom or the community where only extended confirmed users are allowed to participate. However, admins refuse to protect pages where there isn't enough disruption to justify protection. Although, it should be considered that the XCON restriction applies regardless of whether a page is protected or not.
What PCECP would do is essentially remove fears that there "isn't enough disruption to justify protection" while buffering all non-extended-confirmed contributions so they have to be approved, in line with "non-extended-confirmed can only make edit requests". Templates that are specifically for this case like {{edit protected}} break when the page is not protected. Awesome Aasim 22:00, 27 September 2024 (UTC)[reply]
The problem with that is that the 500/30 rule is specifically designed to keep newer editors out due to extreme amounts of disruption as a rule. There's a good reason why both of the world's main hot wars (the Arab-Israeli conflict and the Russo-Ukrainian war) are under 500/30. And, as has been brought up repeatedly and bears repeating again, high volumes of edits on a given article contraindicate CRASHlock.
But the biggest stumbling block here is that no consensus exists yet for an extended-confirmed CRASHlock. The last discussion about expanding CRASHlock to higher protection levels predates XCP entirely. There would need to be a formal RfC for this, not VP spitballing. —Jéské Couriano v^_^v threads critiques 15:37, 28 September 2024 (UTC)[reply]
XCON protection makes sense for high traffic articles, but low traffic articles? If the edit is minor such as fixing spelling mistakes or grammatical errors, there should be no problem. Fixing spelling and grammar is generally outside of contentious topic areas anyway. From WP:ARBECR: On any page where the restriction is not enforced through extended confirmed protection, this restriction may be enforced by other methods, including ... the use of pending changes.
I probably would set up abuse filters as well to see if a page is in a category that primarily deals with a contentious topic, and then warn and tag the edit in question. Awesome Aasim 16:22, 28 September 2024 (UTC)[reply]
Most low-traffic CT articles don't have any protection since they never saw amounts of vandalism necessitating protection. Protection requests that solely rely on arb enforcement and little to no evidence of vandalism get declined. Aaron Liu (talk) 23:26, 28 September 2024 (UTC)[reply]
Yeah I see that, but the problem is that a non-XCON edit will get approved on pages that not many people are watching. Pending changes still allows non-XCON users to make these edits, but their edits will need to be approved and they can be reverted if in violation of WP:ARBECR. This is also in line with how pending changes is used on low-traffic articles to monitor (not prevent) disruption. Awesome Aasim 18:26, 29 September 2024 (UTC)[reply]
@Aaron Liu Most low-traffic CT articles don't have any protection since they never saw amounts of vandalism necessitating protection. Protection requests that solely rely on arb enforcement and little to no evidence of vandalism get declined. Untrue, articles in ECR topics can and are pre-emptively locked. What actually happens is that articles with minimal disruption are usually not brought to WP:RFPP or noticed by a wayward admin. Mach61 19:53, 29 September 2024 (UTC)[reply]

Untrue, articles in ECR topics can and are pre-emptively locked.

Could you add an example? There is a long list of declined RFPP requests for arbitration enforcement. Aaron Liu (talk) 20:42, 29 September 2024 (UTC)[reply]
See this exchange between an admin who refused to protect based on ECR due to a lack of disruption and a (former) admin who explained to them otherwise. Mach61 19:46, 1 October 2024 (UTC)[reply]
Thanks, I get the "can" now. Aaron Liu (talk) 20:59, 1 October 2024 (UTC)[reply]
Seems reasonable. I've always wondered why pending changes isn't deployed more often. It seems a useful tool, and there are lots of pending changes reviewers so very little backlog Cremastra (talk) 14:18, 28 September 2024 (UTC)[reply]
Because there are enough people who dislike or distrust pending changes that it's hard to get a consensus to use it. See, for example, Wikipedia:Village pump (proposals)/Archive 183#RFC: Pending-changes protection of Today's featured article. Anomie⚔ 14:41, 28 September 2024 (UTC)[reply]
Well, gee, I fucking wonder why? —Jéské Couriano v^_^v threads critiques 15:39, 28 September 2024 (UTC)[reply]
Would you care to elaborate on your point? I'm not seeing it. Anomie⚔ 17:04, 28 September 2024 (UTC)[reply]
@Anomie: Read the "Proposal" section on the linked page. The fact that RfC even exists should give you a clue as to why CRASHlock is so mistrusted by a significant minority of editors. —Jéské Couriano v^_^v threads critiques 18:01, 9 October 2024 (UTC)[reply]
Still not seeing it. People supposedly mistrust it because there was a trial 14 years ago and enwiki admins didn't immediately stop using it after the trial period pending a consensus on the future of the feature? Anomie⚔ 18:43, 9 October 2024 (UTC)[reply]
You familiar with the idiom of the Camel's nose? —Jéské Couriano v^_^v threads critiques 18:47, 9 October 2024 (UTC)[reply]
The TL;DR I'm taking away from this discussion is that you're still butthurt over consensus not going your way 12 or 13 years ago, and assuming that anyone opposed to PC shares that reason and no other. I think it's unlikely continuing this conversation is going to go anywhere useful. Anomie⚔ 18:59, 9 October 2024 (UTC)[reply]
That isn't how consensus works, either. Consensus can be determined by an RfC, yes. But it can also develop just by the way that things are done already, regardless of whether it has formally discussed.
I think about the example given by Technology Connections about "the danger of but sometimes". The LED traffic light is superior in energy savings and much more, but sometimes snow and ice builds up on them, so they are bad. Likewise, XCON pending changes will help with enforcement of WP:ARBECR but sometimes admins might apply this to pages out of policy, so it shouldn't be used again. The correct response would be to place in policy guardrails so that admins don't do that. Awesome Aasim 19:00, 9 October 2024 (UTC)[reply]
How is an RfC from over 13 years ago still reflective of consensus today? I am pretty certain that while some opinions might not have changed, others definitely will have. No one is saying there should be full pending changes. Awesome Aasim 18:16, 9 October 2024 (UTC)[reply]
@Awesome Aasim: The RfC was linked specifically to point out one of the reasons for the mistrust in the PC system. The most recent RfC on CRASHlock, as I said, predates XCP as a concept. —Jéské Couriano v^_^v threads critiques 18:20, 9 October 2024 (UTC)[reply]
Also, please explain what you mean by "crashlock". I cannot find any discussion or glossary entry on "crashlock". Awesome Aasim 18:21, 9 October 2024 (UTC)[reply]
@Awesome Aasim: It should be VERY obvious from context. —Jéské Couriano v^_^v threads critiques 18:26, 9 October 2024 (UTC)[reply]
I guess you might be the only one using this terminology; as it is not in WP:GLOSSARY or anywhere else.
Nonetheless, this is the Idea Lab; it is the place to develop ideas, not to show stark opposition to ideas. That is what the other discussion boards are for; consensus polling. It should be noted that WP:ECP was created originally for the purpose of enforcing arbitration decisions and community sanctions. It was never intended for anything else; it just got used for other stuff de facto. Awesome Aasim 18:40, 9 October 2024 (UTC)[reply]
(edit conflict) All these things you think are obvious really are not. You should try explaining yourself better instead of emphatically waving your hands at something random. Anomie⚔ 18:43, 9 October 2024 (UTC)[reply]
Obvious perhaps, but it still doesn't make much sense. I'm not sure how using your own special terms of unclear implications to disparage things you dislike is helping communication or community understanding here. Cremastra (talk) 19:37, 9 October 2024 (UTC)[reply]
I don't understand. People mistrust PC because of a bureaucratic misimplementation of an experiment over 10 years ago? (In a noncentralized bureaucracy where dumb shit happens all the time?) The RfC is explicit that it makes no normative judgement on PC, and it seems the !voters are not doing so either. SamuelRiv (talk) 18:37, 9 October 2024 (UTC)[reply]
It's one reason, and probably the biggest for some (who viewed the trial's mishandling as trying to force CRASHlock/FlaggedRevisions down our throats). Another reason is that, from 2010 to 2014, CRASHlock RfCs were called at least once a year, with most of them being written by pro-CRASHlock editors. —Jéské Couriano v^_^v threads critiques 18:42, 9 October 2024 (UTC)[reply]
Ok for those not into WP politics, there's an overview opinion piece from the August 2011 WSP that seems to capture the attitude and aftermath. It appears the closure results of the RfCs left admins in an indeterminate state as to whether PC can ever be applied or removed. SamuelRiv (talk) 18:47, 9 October 2024 (UTC)[reply]
as to whether PC can ever be applied or removed True in 2011 when that was written, but later RFCs resolved that. Anomie⚔ 19:02, 9 October 2024 (UTC)[reply]
Could you link to said RfCs? All else that's linked previously regards the main page. SamuelRiv (talk) 19:56, 9 October 2024 (UTC)[reply]
Wikipedia:Pending changes/Request for Comment 2012 established basic consensus to use PC, with Wikipedia:PC2012/RfC 2 and Wikipedia:PC2012/RfC 3 clearing up some details. PC level 2, on the other hand, never got consensus for use and eventually in 2017 there was consensus to remove it from the configuration. Template:Pending changes discussions has a lot of links. Anomie⚔ 22:14, 9 October 2024 (UTC)[reply]
It's worth noting that the 2017 RfC is the last one about any aspect of CRASHlock, to my knowledge. As I said above, there would need to be a new RfC in order to get consensus for extended-confirmed CRASHlock, as PC2 was originally full-protection level and no ECP!CRASHlock question was asked in the 2016 RfCs, none of which were particularly comprehensive. (The last comprehensive RfC was the 2014 clusterfuck.) —Jéské Couriano v^_^v threads critiques 06:47, 10 October 2024 (UTC)[reply]
I think the main reasons editors don't want to expand the use of pending changes are practical: no technical support for fixes (or additional feature development) is on the horizon, in spite of documented bugs; and uncertainty in the community's ability to manage expanded use. There are certainly vocal editors who are wary due to past history, but this has already been a factor in other decisions, and they have accordingly been influenced to be more definitive about how any trials will proceed. isaacl (talk) 18:55, 9 October 2024 (UTC)[reply]

Maybe what is needed is this...

A multi-part RfC asking how ECR should be enforced for existing pages, including based on activity. High traffic pages will need extended protection retroactively as those tend to get the most disruption from ECR violations. Low-traffic pages, not so much, but we can use abuse filters and workshop ECP pending changes for this. Spelling and grammar fixes as far as I am aware are excluded from WP:ARBECR. Awesome Aasim 19:52, 1 October 2024 (UTC)[reply]

I view the ECR in the PIA area to be absolute (no editing full stop by those who do not meet 500/30), so CRASHlock would be off the table there in any event. I'm not sure if this also applies to WP:GS/RUSUKR (which falls into the EE area). —Jéské Couriano v^_^v threads critiques 18:57, 9 October 2024 (UTC)[reply]

#### in [topic]

Should articles about years in topics be linked in articles? For example, The Little Girl Lost's first link is to 1794 in poetry. The link feels like a Wikipedia:OLINK violation, but isn't specifically stated. Links to just years are already gone, but why aren't the ones about topics actively being removed? Roasted (talk) 22:56, 28 September 2024 (UTC)[reply]

Everything started in some year, and linking that year to an article about a bunch of irrelevant info is not helpful. But in an article about a poem written in 1794, it is quite reasonable to link to an article about other very related stuff in that year. That is not a rule but is a defensible view, particularly for poems from 230 years ago where it is a bit of a miracle that we have any record of the poem. Johnuniq (talk) 01:04, 29 September 2024 (UTC)[reply]
I think it's a defensible view, specifically for subjects that are discussed/linked in the article. It's similar to our WP:BIDIRECTIONAL principle for navboxes: if you can get from 1794 in poetry to The Little Girl Lost, then it would be ideal if you could get back.
I think it is more defensible for shorter/narrower subjects than for sprawling pages. 1794 in poetry is fine. 2023 in film might not be. WhatamIdoing (talk) 01:23, 29 September 2024 (UTC)[reply]
List of German films of 2023, from which you can rightly get to 2023 in film, could be a different story though. Thryduulf (talk) 10:19, 29 September 2024 (UTC)[reply]
I'd leave that one up to editors' judgment, and I wouldn't object whatever they decided.
Another thing to consider is the formatting. Compare these sentences:
For the first, the link label is "1794 poem", and if you are surprised that clicking on "1794 poem" takes you to 1794 in poetry, then perhaps you weren't paying attention to what you were clicking on.
In the second, the link label is "2023", and you might expect 2023 instead of 2023 films. I would suggest changing that link so that it includes the words "in 2023" instead of the year alone. WhatamIdoing (talk) 19:37, 29 September 2024 (UTC)[reply]
My 2¢: remove direct links, but put the "YEAR in TOPIC" articles in the "see also" section. This removes any MOS:EGG issues and is if anything more consistent with an analogy to bidirectional navboxes Mach61 03:35, 30 September 2024 (UTC)[reply]
I like this.
(Man, I wish navboxes were in that section. Aaron Liu (talk) 11:43, 30 September 2024 (UTC)[reply]
I think the key issue here (justifying this position) is that while "2023 in poetry" may be related in that it's the same year and not too much poetry was published at that time, that doesn't mean it is relevant or useful in relation to that poem to know what 100 other random poems were published the same year. Mrfoogles (talk) 06:21, 13 October 2024 (UTC)[reply]

URL expansion bots

I agree that short URLs are undesirable. However, wouldn't it be better if a bot auto-expanded those URLs instead of them being blacklisted? For example youtu.be into youtube.com/watch?v= , tinyurl.com/example into example.com (that is its actual target). Elominius (criticize | contributions) 09:19, 30 September 2024 (UTC)[reply]

The reason they're blacklisted is not because they're "undesirable", it's because they can be (and have been) used to get around the spam blacklist and other anti-spam measures. If the link is legitimate, there's no reason the user trying to add it can't expand it. Anomie⚔ 11:25, 30 September 2024 (UTC)[reply]
@Anomie: there's no reason the user trying to add it can't expand it The reason is that the enduser does not know that they have to do that, and the message does not explain that that is what should be done (or how). And several sites use shorter URLs when you use the Share button, which is a type of URL shortener that only goes to one domain, like a domain alias and therefore cannot be abused for malicious purposes. Polygnotus (talk) 23:00, 7 October 2024 (UTC)[reply]
I can certainly see a justification for treating shorteners linked to a single domain (like youtu.be) differently to generic ones like tinyurl. Thryduulf (talk) 23:22, 7 October 2024 (UTC)[reply]
@Thryduulf: See meta:Talk:Spam_blacklist#youtu.be. Polygnotus (talk) 23:43, 7 October 2024 (UTC)[reply]
For that case, as I had written in VPT, the bot could do blacklist checking and reversion if the expanded link hits the blacklist; or we just integrate the automatic expansion mechanism into MediaWiki. MilkyDefer 08:34, 10 October 2024 (UTC)[reply]
This misses the point that people could use a URL shortener to link to spam or malware even if the target is not blocked. A quick check of a diff of someone doing that shows the shortener link and the person checking would need to be fully motivated to examine what happens if they click it. If the original edit adds a link to a marketplace or a dubious site, it is a lot easier to revert. We do not want a bot which blesses external links by expanding them. Johnuniq (talk) 01:32, 11 October 2024 (UTC)[reply]
Possibly the bot could discover who added the link, if the account passes some heuristic tests of trustworthiness, it would be considered reliable-enough for expansion. Lot of work though. How big of a problem are short URLs? -- GreenC 02:50, 11 October 2024 (UTC)[reply]
It depends what problem you are referring to. According to the Meta discussion they are used to post spam links, but they also prevent the addition of good links and may (I don't know of any statistics) discourage the inclusion of sources and/or lead to abandoned edits both of which could negatively impact editor retention (directly or indirectly) - all of which are problems, but different ones.
I think the ideal would be for MediaWiki to perform a pre-save transform to expand short URIs to their full form, then check them against the blacklist, then either save the long form or reject the edit as appropriate (The error message for a rejected edit should display both short and long URIs so editors know which link tripped the blacklist and why). I guess this is something that would need to happen at the software level though? I'm also wondering if there is some means of automatically detecting which URIs are shortened or if that would have to be curated manually? (e.g. would it know that http://sucs.org/uri/as is a short URI (leading to URL shortening) without being told?) Thryduulf (talk) 03:18, 11 October 2024 (UTC)[reply]
. I have not read the meta thread but suspect most cases are good faith and the bad instances are on the edge. It's easy to check, manually go through a couple dozen and see how it looks.
. To expand to long form requires querying a header, external site, or API, might not practical at the MediaWiki interactive layer.
. Shortened URLs could be documented; I made a page that documents archive URLs: Wikipedia:List of web archives on Wikipedia (including some that are shortened URLs). It's easy to start a technical document Wikipedia:List of URL shortening sites on Wikipedia, and hope over time people find it and add knowledge. -- GreenC 04:06, 11 October 2024 (UTC)[reply]

Creating Template:Wikidata Infobox

Hi, I propose to create a template called Template:Wikidata Infobox that creates an infobox from information exists on Wikidata. The same idea is implemented in WikiCommons. See https://commons.wikimedia.org/wiki/Category:Quantum_computing and section infobox which uses {{Wikidata Infobox}}. Cheers. Hooman Mallahzadeh (talk) 13:33, 1 October 2024 (UTC)[reply]

Using Wikidata for infoboxes has been discussed many times here and is surprisingly (to me) controversial. Some specific infoboxes do incorporate information from Wikidata (iirc Mike Peel has done some work on this), but I don't think a single generic infobox, whether pulling information from Wikidata or otherwise, will gain consensus. I'll leave a note about this discussion at Wikipedia talk:WikiProject Infoboxes and Wikipedia talk:WikiProject Wikidata. Thryduulf (talk) 13:42, 1 October 2024 (UTC)[reply]
Yeah… a LOT of resistance to importing data from Wikidata into our infoboxes. The two main concerns are Verifiability/reliability (although WD has improved on this front, they still are not in line with our policies) and ease of editing (having to go to WD to edit information appearing on WP can be confusing).
I’ll share a personal experience of confusion… the data focused structure of WD is often incomprehensible to me as a text focused editor here at WP. When I try to fix errors on WD, I have extreme difficulty doing so. simply locating the information I need to edit is hard. The way WD pages are organized and structured is alien gobbledygook to me. Blueboar (talk) 14:18, 1 October 2024 (UTC)[reply]
Wikidata is a good idea in want of a usable interface. It's use would be massively helped if you could edit data here and it was back flushed to Wikidata. -- LCU ActivelyDisinterested «@» °∆t° 14:39, 2 October 2024 (UTC)[reply]
That's how most of the Wikivoyages are set up. It's not automagic (except possibly at German), so you have complete control over which bits you import locally and which bits of your content you push back to Wikidata. The control is important because some content is different. For example, Wikivoyage usually wants to put the lat/long location at the entrance to an location, and Wikidata usually wants the center. There's no need to override each other's locations if these happen to be significantly different (e.g., entrance to Disney World vs center of Disney World). When they're the same, then you can share them back and forth. WhatamIdoing (talk) 04:23, 3 October 2024 (UTC)[reply]
Commons only has one kind of infobox. We have a lot of them that have very different data displayed. Personally, I'd love to incorporate wikidata into nearly all infoboxes, but one generic infobox is impossible to suit our needs. Aaron Liu (talk) 14:14, 1 October 2024 (UTC)[reply]
I really think that this type of infobox (maybe in collapse form) is the best replacement for infobox of articles that we cannot create any infobox for them like Quantum computing. These data includes links to WikiQuote and its library id etc., which makes them accessible and at hand. I propose to use this kind of infobox in other sections like "See also" section, instead of top, replacing many existing templates like {{Commons category}}. Hooman Mallahzadeh (talk) 14:32, 1 October 2024 (UTC)[reply]
Um, what value could be derived from using d:Q17995793 to populate an infobox for the article Quantum computing? Do we really need an infobox for that article to clarify that the subject is an instance of "academic discipline", subclass of "computation", and is the study of "quantum computer" and/or "quantum supremacy"? This is an excellent example of an article that has no need for an infobox. Folly Mox (talk) 02:31, 2 October 2024 (UTC)[reply]
Oh I see you want to use the infobox at the bottom of an article like a navbox? That's less objectionable, and also a different kind of box in our jargon. Folly Mox (talk) 02:44, 2 October 2024 (UTC)[reply]
@Hooman Mallahzadeh, not every article benefits from an infobox. In my opinion, Quantum computing is one of those. Remsense ‥ 论 06:14, 2 October 2024 (UTC)[reply]
@Remsense There are good links to WikiQuote, Wikiversity, Wikidata, WikiCommons, Library of Congress authority ID, that is attached to the main article by simply transcluding this template. This is a big benefit for Wikidata-Infobox of Quantum computing. But collapsing this Wikidata Infobox by default seems reasonable. Hooman Mallahzadeh (talk) 06:26, 2 October 2024 (UTC)[reply]
We can already do that by linking to the ones that are important at the bottom—this is extremely common, and is already done on that article! That brings up a key point of resistance to this, though. We don't want to outsource much to Wikidata because we can't as easily decide what not to show, lest we pollute articles with metadata that may be useful in a database but is functionally useless garbage in an encyclopedia article. Fundamentally, we shouldn't ever expect editors to have to use Wikidata also.Remsense ‥ 论 06:28, 2 October 2024 (UTC)[reply]
This method is a little hard, ⁣inserting cumulative links «by one template» seems more reasonable to me. Hooman Mallahzadeh (talk) 06:31, 2 October 2024 (UTC)[reply]
No, because the decision whether it's worth linking to Wikiquote on a given article should be up to the editors for that article. Remsense ‥ 论 06:32, 2 October 2024 (UTC)[reply]
I disagree. According to Zeigarnik effect, placing a Wikiquote link that is empty right now, motivates users to complete that page and put some quote about that concept. Hooman Mallahzadeh (talk) 06:38, 2 October 2024 (UTC)[reply]
It's not our job to build Wikiquote, but it is our job not to indiscriminately clutter our encyclopedia articles with useless garbage. Your position would be resented by almost any editor who cares about how the articles they write look and what exactly they present to readers. Remsense ‥ 论 06:59, 2 October 2024 (UTC)[reply]
Most readers don't care about those. The small bit that care are satisfied by it being at the bottom. Aaron Liu (talk) 11:34, 2 October 2024 (UTC)[reply]
Hooman Mallahzadeh, your idea of a single general use template to build sister project links from the associated Wikidata item for use in the ==External links== section does actually sound like a good idea, but people in this subthread have been confused by your use of the term infobox (which live at the top of the article). However, this sounds identical to the existing template {{Sister project auto}}. How does your idea differ? Folly Mox (talk) 12:35, 2 October 2024 (UTC)[reply]
If the notion is to show some source information, it may also be similar in concept to the wider-used template {{Authority control}}. SamuelRiv (talk) 15:07, 2 October 2024 (UTC)[reply]
Right, {{authority control}} is already ubiquitous (~2,131,000 transclusions out of 6,896,678 articles including redirects), is even included in the default output of Wikipedia:ArticleWizard, and {{authority control}} already pulls from Wikidata. Folly Mox (talk) 17:54, 2 October 2024 (UTC)[reply]
So all that considered, @Hooman Mallahzadeh, I'd suggest just making/forking a template along those lines (or editing the existing template in its sandbox), as this basic concept would be uncontroversial. The rest of the discussion here is hypothetical clutter until people see precisely what you have in mind that may be radically different from what is already being used in these templates above. SamuelRiv (talk) 18:41, 2 October 2024 (UTC)[reply]
Something like Category:Earth shows how hard it is to get an automatic, good infobox and not a load of weird entries. "Instance of: "inner planet of the Solar System (Mars, Venus)" And Mercury? if you for some reason list the others here, list them all... "Named after: *soil (Earth) *land (1, 地, 地球) *ball (2, 球, 地球) " Er, what? No idea why the Japanese is shown here. "Inception: 4,541st millennium BC (lead-lead dating, age of the Earth, Young Earth creationism)" Yeah, we sure want a link to Young Earth creationism here... "Dissolved, abolished or demolished date: unknown value (future of Earth)" Not even a link, just the text, as if this is in any way useful. And this is hardly some obscure example. Fram (talk) 14:30, 1 October 2024 (UTC)[reply]
{{Infobox person/Wikidata}}, anyone? — Qwerfjkltalk 18:42, 1 October 2024 (UTC)[reply]
What a great way to introduce unverified intormation (errors) and nonsense into Wikipedia articles. -- Ssilvers (talk) 20:46, 1 October 2024 (UTC)[reply]
Unverified information and incorrect information (what I presume you mean by "errors") are not synonyms. Not everything in WikiData is any of unverified, incorrect or nonsense. Thryduulf (talk) 20:51, 1 October 2024 (UTC)[reply]
@Ssilvers There's an easy parameter to only include information with references. Bad references exist and can be easily fixed using the same methods on both sites. Aaron Liu (talk) 21:01, 1 October 2024 (UTC)[reply]
Wikidata has different sourcing standards than enwiki - sites that are considered unreliable by enwiki consensus are considered quite fine at Wikidata. Wikidata entries are also left out of existing enwiki cleanup mechanisms. So it's not quite as simple as you're suggesting to apply the same methods to both sites - the two sites have neither the same methods nor a shared understanding of what a "bad reference" even is. Nikkimaria (talk) 00:22, 2 October 2024 (UTC)[reply]
Is anyone trying to develop a shared understanding, or does everyone think that it's just OK that the site are disconnected like that, even thought they could help each other much more? If you have links to discussions, I'd be happy to read them. Amir E. Aharoni (talk) 00:46, 2 October 2024 (UTC)[reply]
My perception is it's mutual apathy in both userbases: people who write an encyclopedia aren't coterminous with people who want to build a universal database. While the results are unfortunate, it really would be unreasonable to expect one group of volunteers to operate according to the standards of the other. Remsense ‥ 论 06:07, 2 October 2024 (UTC)[reply]
Then we should make it known to Wikidata why and which sources are bad and often false. I don't see any source that is considered very valid on Wikidata and removed-on-sight on Wikipedia. Aaron Liu (talk) 01:10, 2 October 2024 (UTC)[reply]
[43]. Nikkimaria (talk) 01:25, 2 October 2024 (UTC)[reply]
@Nikkimaria, was this a reply to me? Just one comment from one person? Amir E. Aharoni (talk) 02:15, 2 October 2024 (UTC)[reply]
It was not a reply to you. This one would be a better place to start for your question, though that perspective is also relevant. Nikkimaria (talk) 02:32, 2 October 2024 (UTC)[reply]
Thank you, point taken. In that case, we do need to have parameter-specific overrides at least. Aaron Liu (talk) 02:43, 2 October 2024 (UTC)[reply]
Curiously, one of the arguments in that RfC is "FInd a Grave is sourced from gravestones". Wouldn't citing the gravestone be better in that case instead? Veering off-topic here, though. Aaron Liu (talk) 02:46, 2 October 2024 (UTC)[reply]
The claim that Wikidata is wrong is just a claim. It's a wiki, it is closely integrated with Wikipedia, and it can be as right or as wrong as Wikipedia itself. Amir E. Aharoni (talk) 21:06, 1 October 2024 (UTC)[reply]
Yes, we know Wikipedia is flawed… Which is why we DON’T consider Wikipedia a reliable source, and DON’T use one part of Wikipedia to verify other parts of Wikipedia. Blueboar (talk) 21:18, 1 October 2024 (UTC)[reply]
But what's wrong with that if we can machine-verify that the reused part has a source? This isn't about sourcing to Wikidata, it's about reusing sourced content from wikidata, for all the reasons {{excerpt}} is good. Aaron Liu (talk) 21:20, 1 October 2024 (UTC)[reply]
Is anyone suggesting to use Wikidata to verify things on Wikipedia? I don't think so. I certainly don't.
People are suggesting to insert things that are written on Wikidata into the English Wikipedia in some cases when it's more efficient to do it. They can be verified just like Wikipedia itself. Amir E. Aharoni (talk) 21:32, 1 October 2024 (UTC)[reply]
I don't think Wikipedia should prioritise efficiency. We should prioritise care. If people want to reuse sourced content from Wikidata, they can add the content and add the source. We shouldn't just invite it in uncurated. Folly Mox (talk) 02:41, 2 October 2024 (UTC)[reply]
To paraphrase Shrek: But it is curated. What's the difference if it's curated by a Wikipedia editor or by a Wikidata editor? Wikidata it not a completely separate site. The two sites have always been closely related in terms of both community and technology, and with the same ultimate goal of free knowledge edited as a wiki. If there are differences between them in verifiability policy, I'd think about trying to bridge them instead of dismissing the idea of collaboration outright. Amir E. Aharoni (talk) 13:43, 2 October 2024 (UTC)[reply]
We shouldn't leave curation of content that is included in articles to people who generally aren't looking at or directly editing said articles. This seems very straightforwardly obvious to me. Remsense ‥ 论 13:51, 2 October 2024 (UTC)[reply]
But why do you think that they aren't looking at the articles? I very often edit things on Wikidata because I notice that they appeared incorrectly on Wikipedia, and then I check that the information was updated correctly on both Wikidata and Wikipedia. (It happens more in other languages, such as Hebrew, Spanish, or Russian, because the English Wikipedia uses Wikidata less.)
And what's the difference between changing a thing on Wikidata that will be included in a Wikipedia article and changing a template within Wikipedia that will be included in other pages? (Other than the different URL.) Or changing an image on Commons and Amir E. Aharoni (talk) 14:00, 2 October 2024 (UTC)[reply]
The curation processes between the two sites are entirely different. en.wiki is primarily curated at the individual page level, wikidata seems to be primarily curated at cross-sections where lots of pages intersect. (Also worth considering how much of Wikidata is created by bots pulling from other wikis.) CMD (talk) 14:03, 2 October 2024 (UTC)[reply]
Because they're editing a database! They might not even speak English, never mind take into account the nuances of how the English Wikipedia (or any other project, to be clear) may be affected by what they are directly doing. Whether you think they aren't totally different websites, they are different websites. I really don't think I have to get sociological to discuss a set of social facts here that are fairly obvious to everyone who contributes to a Wikimedia project. "Wikipedia is one site, Wikidata is another" should also answer your second question: if someone breaks a template, it is not a paradigm shift for me to fix it or ask someone else to, because that occurs on the same website. You're a free spirit and that's fine; any design decision that assumes this quality of contributors in general would be a terrible one. Remsense ‥ 论 14:11, 2 October 2024 (UTC)[reply]
Another way to think of it is that they are the same website with different URLs.
And I'm not sure what are you referring to by "quality of contributors" and "free spirit" towards the end. In my understanding, a free spirit in a free encyclopedia is a good thing, but I suspect that you mean something different. Amir E. Aharoni (talk) 19:08, 2 October 2024 (UTC)[reply]
Wikidata is definitely quite a different site, ubiquitous in its low standards for inclusion. Aaron Liu (talk) 19:29, 2 October 2024 (UTC)[reply]
That, by itself, is not a problem. You can include some things from it on Wikipedia, and exclude others. That's more or less what happens on the English Wikipedia already, but it happens more in some other languages, and it works there fairly well. I don't understand the resistance that some English Wikipedians have to include anything from Wikidata. Amir E. Aharoni (talk) 16:14, 3 October 2024 (UTC)[reply]
I agree that it is not a problem. I disagree with what you said about them being the same site and closely related. Aaron Liu (talk) 17:11, 3 October 2024 (UTC)[reply]
They:
  • Are maintained by the same organization.
  • Are built from the outset to be connected, similarly to Commons.
  • Share user accounts.
  • Share a large part of the editing community. I don't have precise numbers, and of course there are some Wikipedia editors who don't do anything on Wikidata and vice versa, but there is a lot of overlap.
So what makes you think that they are not closely related? Amir E. Aharoni (talk) 22:06, 3 October 2024 (UTC)[reply]
Closely related in terms of underlying infrastructure and overlapping goals doesn't equate to being the same website with different URLs. By design, each Wikimedia wiki has its own community, with its own culture, that defines its own guidance and operating procedures. isaacl (talk) 22:14, 3 October 2024 (UTC)[reply]
All I'm trying to say is that it's not very different from Commons. It's separate in some ways and the same in some others. Some data from Commons and Wikidata is useful in the English Wikipedia, some isn't. Emphasizing only the differences, as some English Wikipedians do, is neither correct nor useful. Amir E. Aharoni (talk) 22:22, 3 October 2024 (UTC)[reply]
All en.wiki takes from Commons is essentially file urls. It's a very different place to en.wiki with very different norms. CMD (talk) 23:24, 3 October 2024 (UTC)[reply]
And, um, the files, not just the URLs, right?
Whatever internal norms Commons has, the English Wikipedia takes a lot of files from it. And it can be the same with Wikidata. The English Wikipedia already takes some data from it, and it can take more.
I'm actually not specifically supporting using the generic Wikidata infobox in the English Wikipedia. I'm just trying to understand the resistance that some English Wikipedia editors have to including anything at all from Wikidata. Amir E. Aharoni (talk) 03:12, 4 October 2024 (UTC)[reply]
Key elements of the resistance have been explained elsewhere in this thread. They relate to a lower quality of sourcing, higher vulnerability to vandalism, and difficulty in editing Wikidata. Sourcing issues do not apply to commons, and file modifications there are restricted to those with advanced permissions. En.wiki does not import files from Commons, although it does host files separately when they are ineligible for inclusion on Commons. CMD (talk) 04:17, 4 October 2024 (UTC)[reply]
Commons benefits from the shared requirements set by the Wikimedia Foundation on media usage, so files are readily usable on any Wikimedia wiki. (Of course, media that embeds information, such as annual stats, suffer from similar problems as Wikidata: its accuracy is dependent on the uploader.) For those concerned about the verification standards on Wikidata, unfortunately I don't really have a good suggestion on creating better processes to validate edits while keeping the "anyone-can-edit, everyone verifies" approach. By its nature, the data is very dense, so I think trying to double check all incoming edits is a more tedious and onerous job than can be expected of volunteers to do. isaacl (talk) 06:35, 4 October 2024 (UTC)[reply]
However, the Wikidata editors do not curate content in articles: editors at wikis that use the wiki-data do. Wikidata is the sourced information, and editors decide which ones to include. That is also why I think templates should include per-parameter overrides before switching to wiki-data by default. Aaron Liu (talk) 19:30, 2 October 2024 (UTC)[reply]
As far as I know, per-parameter overrides is what is done in Wikipedia in all the languages in which templates pull information from Wikidata, and it makes perfect sense. If this is not the situation anywhere, I'd be very surprised. Amir E. Aharoni (talk) 16:17, 3 October 2024 (UTC)[reply]
The Wikidata Infobox on Commons came out of initial work that I was doing here on enwiki - it's the same codebase as {{Infobox person/Wikidata}} and the like, but evolved a lot more due to a lot of constructive input on Commons. It has two views - one for people, one for everything else, and that's been shown to work very well overall, and is a lot more scalable and maintainable than thousands of more specialised templates. Technically, Wikidata infoboxes are quite mature now - and similar ones to this are used a lot on different language Wikipedias. Wikidata is also quite well integrated into different workflows across Wikimedia nowadays (including here with WiR redlists). The main question is a social one: whether the enwp community is interested in pursuing Wikidata infoboxes, and spending the time and energy to constructively contribute to improving data and refining template logic, as the Commons community and other language Wikipedia communities have. Thanks. Mike Peel (talk) 21:00, 1 October 2024 (UTC)[reply]
I think that, at this point, we still have too much fear of the unknown and Not invented here syndrome to accept much help from Wikidata. Other wikis will (and do) benefit from it, but we will have to nibble around the edges for another decade.
It's possible that we should be exploring something closer to the bi-directional but manual syncing that the Wikivoyages use (e.g., for official websites and the latitude/longitude of notable locations). If you haven't seen that, then go to your favorite vacation destination at voy: (e.g., voy:en:Paris/7th_arrondissement#See) and scroll down until you find a section that has [add listing] next to the usual section editing buttons. Click that and you'll get a big dialog box. On the right, find the blank for Wikidata and put in a famous landmark (e.g., "Eiffel Tower"; it won't save the edit until you manually tell it to). Click on "quick fetch" to see what Wikidata offers (and then "Cancel" all the way out, so you don't make any changes to the article or to Wikidata). There's also a dialog that lets you choose individual bits (e.g., I want my URL but Wikidata's latitude/longitude, or to remotely replace old information in Wikidata with newer information). Something like this could be done, and could even be set to require sources. Adding sources to Wikidata is usually quite easy, as you just choose the type (e.g., ISBN, DOI, URL...) and add the raw id number/URL directly. WhatamIdoing (talk) 05:49, 2 October 2024 (UTC)[reply]
While agree with your assessment of WP decision processes, and I really do think we should ideally be doing more with WD structured data here, WD does not make anything easy (echoing Blueboar above), and frankly (from my attempts to raise this issue with them) does not seem to have any concern with the concept of UX at all. The Commons interface works well, but as soon as it migrates you over to edit Wikidata fields directly, you are forced into their bafflingly perplexing interface, where something that should be as basic as the difference between a "property" and a "reference" (and where to add a citation, which is recommended -- but which is not a "reference") is beneath several minutes of documentation. (The weirdest thing about all of this is that on the WD Discord it seems that people misplacing or not adding data is their #1 maintenance task.)
The project (in its current state) is usable if we can limit as much user interaction as possible to our end, but even Commons has not able been to do this fully. (Note: I feel free to complain about some WD editorship here because I've raised these same issues to WD editors directly many times already, often with poor responses.) SamuelRiv (talk) 15:03, 2 October 2024 (UTC)[reply]
The main things I would want to have in place before I could support deeper integration of Wikidata into Wikipedia articles are:
  1. an obvious marker in the wikicode for where a parameter is being pulled from Wikidata (like |parameter=:wd or something), with the ability to overwrite it locally just by overwriting it or clearing it
  2. clearer error messages that make it obvious to people with no experience in Wikidata which datum the template is missing or unable to understand, which links directly to the property on the Wikidata item that is causing the problem, or if it's not present, one link to the property description and one link to the source item
I've run into a few template errors where the error arose at Wikidata, and in no case was I ever able to resolve these myself. If pro-Wikidata–integration editors here are willing to put in the work to make their templates friendly to Wikipedia editors with moderate and below technical aptitude, then I might consider getting on board, but at present they act like inscrutable black boxes, and their effect in practice is to disempower a large subset of editors in this community. Folly Mox (talk) 12:47, 2 October 2024 (UTC)[reply]
I agree with this. I remember the fiascos when {{start date and age}} would scream when improper wiki-data returned multiple dates for just one selector. There should be a way for these templates to error themselves without having the error overwritten by outer, wrapper templates. Aaron Liu (talk) 13:05, 2 October 2024 (UTC)[reply]

"Adding sources to Wikidata is usually quite easy, as you just choose the type (e.g., ISBN, DOI, URL...) and add the raw id number/URL directly. "

Random item [44], first unsourced entry: "taxon". "Add reference" opens field "property", which gives a dropdown with 5 possibilities. I want to use a book, so I guess "stated in" would be the right choice. A new dropdown opens, with endless choices, starting with "human"???, "human settlement"???, painting, village, family name... What the bleep is this about??? Perhaps I need to enter "book" and I can continue? Oh, no, it just stops there. Wikidata is extremely non-intuitive and random. Fram (talk) 08:32, 2 October 2024 (UTC)[reply]

I want to use a book, so I guess "stated in" would be the right choice.

Yeah, so just enter the name of the book... Expecting that it can guess what book you want to cite is quite unreasonable.
You can also just choose "ISBN-13" instead of "stated in". Aaron Liu (talk) 11:38, 2 October 2024 (UTC)[reply]
Just like MediaWiki's own "non-intuitive and random" syntax for putting in a reference, Wikidata also has help pages like wikidata:Help:Sources that explain this exact thing to you. Aaron Liu (talk) 11:43, 2 October 2024 (UTC)[reply]
Even if it is possible to learn by reading the manual (I would hope so!) I think their challenge to the characterization of it as simply "easy" was fair enough. Remsense ‥ 论 11:54, 2 October 2024 (UTC)[reply]
It's at least as easy to add a reference in Wikidata as it is in Wikipedia. That the methods are not the same does not change this. Thryduulf (talk) 11:58, 2 October 2024 (UTC)[reply]
I do not dispute this. Remsense ‥ 论 11:59, 2 October 2024 (UTC)[reply]
I do. Fram (talk) 12:21, 2 October 2024 (UTC)[reply]
One difference worth noting is that on en.wiki someone can search Help:Citation and find something, while in Wikidata most Help: pages are Wikidata items. There is a guide at Wikidata:Help:Sources, but it only guides towards sources that are either Wikidata items or urls. CMD (talk) 12:31, 2 October 2024 (UTC)[reply]
Good point on the borked searching, but there is a "Help" button in the main menu.
You seem to have missed the "Different types of sources" section. Aaron Liu (talk) 12:44, 2 October 2024 (UTC)[reply]
Not sure how you come to that odd conclusion. The different types of sources section is a guide to creating Wikidata items, not to sourcing them. CMD (talk) 13:05, 2 October 2024 (UTC)[reply]
It guides you on how you can cite a database with an item ID (the database is indeed a Wikidata item, but usually, the item for the database you use has already been created), a headstone, Wikisource, and archive records. Aaron Liu (talk) 13:11, 2 October 2024 (UTC)[reply]
This threaded conversation is about the assertion of whether adding a Wikidata reference is "usually quite easy", in the context of comparisons to en.wiki. If I stated it was easy to reference something in en.wiki, you just have to create a new article for it, I suspect people would not find that a convincing argument or helpful contribution. CMD (talk) 13:16, 2 October 2024 (UTC)[reply]
New items on Wikidata are not articles. Their difficulty is far from that of new articles. That said, auto-generated reference items from e.g. a URL would help a lot. Aaron Liu (talk) 16:21, 2 October 2024 (UTC)[reply]
I think you underestimate the difficulty people may have in creating Wikidata items. CMD (talk) 03:02, 3 October 2024 (UTC)[reply]
It's genuinely easy. While the "Create a new item" button in the main menu isn't that noticeable, the steps from there are nearly as easy as filling out {{cite book}}. Aaron Liu (talk) 17:12, 3 October 2024 (UTC)[reply]
Having created items it is not quite as easy as the nice en.wiki citation creator, but aside from that I don't see what the value is in ignoring the multiple people who have stated they find it difficult to parse Wikidata. CMD (talk) 23:28, 3 October 2024 (UTC)[reply]
Auto-generated reference items from URLs are planned for Wikidata, and since Citoid will be used to generate them, they'll be just as erroneous and silly as they are here. Folly Mox (talk) 16:14, 3 October 2024 (UTC)[reply]
And that would mean wiki-data included on Wikipedia would be at the same level of quality as the wiki. Aaron Liu (talk) 17:13, 3 October 2024 (UTC)[reply]
That doesn't follow at all. Wikidata with a reference generated by the tool would have similar references as those generated by that tool if the editors involved are the same, and if the scrutiny afterwards is the same. But since Wikidata has for example poor bots creating articles or adding problematic references, and doesn't have the same level of vandalism control as Wikipedia (even though here as well too much slips through the cracks), the end result is that Wikidata quality is too often way below Wikipedia quality. Fram (talk) 18:07, 3 October 2024 (UTC)[reply]
Items included on wikis will be scrutinized as well as the main wiki is, and I'm not sure what problematic bot contributions you're referring to. Aaron Liu (talk) 20:12, 3 October 2024 (UTC)[reply]
As an example, CJMbot[45]. Latest edits include creating an item on a very obscure 17th c. author[46], and then a week later readding the same items and references to it. Another bot then comes along and removes the duplicate items, but adds the duplicate references to the earlier items. Good going... I noticed this bot because at John Cage it added a second date of birth[47] sourced to Museum Dhondt-Dhaenens. Completely unverifiable, the museum exists but what is meant? Some database, a catalogue, information inside the museum? The result is that e.g. the infobox at Commons now since nearly two years shows the correct and an incorrect birthdate. Fram (talk) 07:56, 4 October 2024 (UTC)[reply]
It looks as if that bot has wrecked countless Wikidata items, many subtly, some extremely blatant. Some concerns were raiesd on its talk page, but despite reassurances that the bot owner would look into it, nothing was done apparently, and no one noticed the massive amount of disruption. Which yet again illustrates to me that we should use Wikidata as sparsely as possible, and not trust it to be good enough to add content to enwiki. See [48], a chemical compound that thanks to this bot is also a human with a birth date and so on. Not a one-off, see [49][50][51][52]... Fram (talk) 10:12, 4 October 2024 (UTC)[reply]
Okay, that is problematic. Looking at its request for bot permissions, it takes CSV databases submitted by museums and attempts to match them for people, hence the comments on "this was indeed a problem in the data". There hasn't been any discussions on the bot linking people to chemical compounds yet, somehow. Hopefully this time I start a discussion at a talk page, someone will notice.
However, when such data is included on Wikipedia, I'm sure people will notice whatever incorrect data there is like you did and fix it. The Recent Changes also has a lot of edits that are shown as manually patrolled, so it's not like their vandalism control is that low. Aaron Liu (talk) 13:54, 4 October 2024 (UTC)[reply]
Sorry to disappoint you, but yes, their vandalism control really is way, waaaay too low. I'm still waiting for someone to revert even one of the 5 vandal edits I bookmarked more than 2 days ago, and today it took nearly 4 hours for someone to realise that "Succcca ahahhaha " (English description: "TUA MADRE STR")[53] is not the correct English label of The Lord of the Rings. If even such high profile articles and such blatant vandalism take this long to be reverted... (And yes, this means that the Commons infobox showed this for 4 hours as well). Fram (talk) 15:04, 4 October 2024 (UTC)[reply]
Have you considered that everybody who saw that is doing the same as you and timing how long it takes for someone else to fix it? Has it occurred to you to fix things rather than passively disrupting the wiki to make a point? 15:59, 4 October 2024 (UTC) Thryduulf (talk) 15:59, 4 October 2024 (UTC)[reply]
Yes, it's lacking. I'm saying that it's not too low. Aaron Liu (talk) 16:29, 4 October 2024 (UTC)[reply]
"Yeah, so just enter the name of the book": where? after the "stated in" box? "Stated in" comes with a lengthy explanation, which even on my widescreen ends with "in which a claim is ma..." without any possibility of accessing the remainder of that text. What's the point of the dropdown after you pick "stated in" if none of these make any sense here. But okay, I add a book title after "stated in". Oops, I want to include a book which doesn't have a Wikidata entry: impossible (or what else does the pinkish-red box mean?). Oh right, according to your help page, if you want to use a reference which doesn't already exist as an item on Wikidata, you first have to create an item for it. So easy! If you are truly out of luck, it is a reference with different editions, and then you have to create two new Wikidata items before you can use it as a source. Want to use a newspaper article as a reference? First create a Wikidata itam for the newspaper article. On Wikipedia, I take the dropdown for the type of reference I want to add (only showing things I can actually use, not "human"), it shows me what the standard fields are, and I don't need to create other stuff only to be able to source something. Trying to edit Wikidata is just an endless source of frustration which I happily avoid and don't want to inflict on others at all. Still, it is nice to see how the number of human edits at Wikidata is constantly artificially inflated by e.g. claiming that I have made 951 edits at Wikidata instead of a dozen or so. Oh well, I have bookmarked 5 bits of Wikidata vandalism to see how fast they get reverted, has that visit to Wikidata given me some fun after all. Fram (talk) 12:21, 2 October 2024 (UTC)[reply]

where? after the "stated in" box?

Yeah, there's a reason the param is called "stated in". That's more intuitive than the book icon in the source editor's toolbar.

which even on my widescreen ends with "in which a claim is ma..." without any possibility of accessing the remainder of that text

It displays completely on my standard 1080p.

What's the point of the dropdown after you pick "stated in" if none of these make any sense here.

That's just like how for the "author-link" parameter, TemplateWizard—the visual way of inserting templates—automatically suggests every article that begins with whatever you typed. However, I do agree that just like the TemplateWizard, Wikidata should not be automatically suggesting things when you haven't typed anything.

you first have to create an item for it. So easy!

It's genuinely easy. While the "Create a new item" button in the main menu isn't that noticeable, the steps from there are as easy as filling out {{cite book}}.
Fair point on having to fill it in twice for the edition item.

it shows me what the standard fields are

Wikidata also does. Every class of objects (denoted by whatever you put in for "instance of") has a recommended set of statements that you should fill in; these will be automatically suggested when you click on the "add statement" button. Aaron Liu (talk) 12:58, 2 October 2024 (UTC)[reply]
You must be looking at a completely different Wikidata (and Wikipedia) than I am than. If Visual Editor is as bad as Wikidata, then that's another good reason not to use it. I don't get a "book" icon, I get a nice textual dropdown with "cite book", "cite web", "cite news" and so on. Standard fields: you claim "Wikidata also does.". No, it doesn't. After I have added a book title after "stated in", nothing happens. I don't get e.g. the pages parameter, or "chapter", or anything. I just have to know which ones are expected. Fram (talk) 13:15, 2 October 2024 (UTC)[reply]
If learning how to edit Wikipedia can be a bit steep learning how to use Wikidata is like walking into a brick wall. Especially on mobile I find it simply unusable. I genuinely feel it would be easy to use if you had to write SQL commands. That's not an attack on the concept of Wikidata, rather a criticism of its implementation. -- LCU ActivelyDisinterested «@» °∆t° 14:49, 2 October 2024 (UTC)[reply]
You can basically SQL CMD (talk) 14:57, 2 October 2024 (UTC)[reply]
But not exactly user friendly. -- LCU ActivelyDisinterested «@» °∆t° 15:25, 6 October 2024 (UTC)[reply]
These are pretty good points. Aaron Liu (talk) 16:22, 2 October 2024 (UTC)[reply]
I believe the Drag'n'drop gadget is default-on, and this 22-second-long video: https://www.youtube.com/watch?v=jP-qJIkjPf0 shows that it takes only a couple of seconds to import a source directly from Wikipedia into the ref field in Wikidata.
Manually adding a ref such as the one I added here takes very few steps:
  1. Click the 'edit' button for that item (if you're not already editing the item).
  2. Click '+ add reference'.
  3. Choose a reference type from the dropdown list. This may require a little advance knowledge (equivalent to knowing which of the many citation templates to use), but it usually suggests something sensible, like "reference URL".
  4. Paste the URL (or other ref information) into the box.
  5. Click 'publish'.
I'm certain that every person in this discussion is capable of learning how to do this, and I'm pretty sure that most of us would find that it takes mere seconds after we have learned the simple steps in the process. This takes, at the most, four clicks, pasting the source, plus sometimes typing the name of a suitable reference type (if the type you want isn't already showing in the list).
The drag-n-drop approach doesn't even require that much effort. Just scroll to the list of Wikipedias at the end of the Wikidata item and click [ref] for the language you want to copy the ref from. A copy of the Wikipedia article will open. Find the ref you want to re-use, and drag it over. Script-assisted copying and pasting does not sound like a difficult task to me. WhatamIdoing (talk) 04:18, 3 October 2024 (UTC)[reply]
So I first add the source to Wikipedia, and then copy it to Wikidata to be able to, er, use it on Wikipedia? How does this make life easier? The video uses Mabery Gelvin Botanical Garden[54] and adds a second ref to the state it is in, Illinois. So if we had an infobox generated from Wikidata, it would have shows that it was located in Illinois, just like it does now. Apart from the fact that the state is no longer mentioned at Wikidata for some reason... It was added in 2016 (with a retrieval date of 2012, not good) and removed more than a year ago. Good thing we don't rely on that site. Considering that none of the 5 examples of vandalism I yesterday recorded have been reverted, it seems vandal fighting on Wikidata is still problematic anyway. Fram (talk) 07:38, 3 October 2024 (UTC)[reply]
The tool is for easily importing existing citations. A tool to help create new citations still needs to be made.
Also, the Wikidata item was changed to be in Champaign county, which seems correct. Aaron Liu (talk) 13:57, 3 October 2024 (UTC)[reply]
As said by Chipmunkdavis below, the tool isn't even visible to mere mortals, is it a toggle in the preferences? And I didn't claim that Champaign county is incorrect, but that if the infobox was Wikidata-filled, it would have changed from "Illinois" (good, informative for most people, wanted) to "Champaign county" (not informative for most people, certainly without "Illinois"). Or, to be even more exact, it would have removed "Illinois" from the infobox but not even added "Champaign county" in its place, as on Wikidata, Champaign county is not even referenced... USA wouldn't be shown either, as that is "referenced" to enwiki. The only references in the article are 404 errors. It's not an example I deliberately picked, it's one given by WhatamIdoing (though involuntarily I guess), but it is typical of Wikidata, even after 10+ years. Even when one goes to a basic article, say Illinois[55], it has hardly any reliable sources. Fram (talk) 14:57, 3 October 2024 (UTC)[reply]
Yes, the gadget is not enabled by default and needs to be toggled.
Naming locations as within their provinces is a style convention independent of data. Infoboxes could easily make two calls to Wikidata for the location. Aaron Liu (talk) 15:29, 3 October 2024 (UTC)[reply]
Doesn't seem to be the default. My Wikidata interface (including for Mabery Gelvin Botanical Garden (Q5477670)) has the various wiki links at the bottom of the page, and without [ref] icons. CMD (talk) 09:30, 3 October 2024 (UTC)[reply]
Another key difference (in my experience) between WP and WD: on WP it is acknowledged that there is a learning curve and entry barriers to editing, and in virtually every VP conversation the notion of how to mitigate this is brought up; on WD the conversations I've had seem indicative that editors believe that it is completely intuitive at its core -- either they don't believe they can make it any easier for users, or that users' difficulties are their own fault (this is just the impression I've had from conversations -- admittedly I'm very direct about reporting interface problems). Additionally, when asked, WD editors did not seem interested in running user interaction experiments or examining existing UX data.
Again, this is not to dogpile on WD for no reason. I believe in the project's core purpose, but I feel at this point like I gotta yell at any direction to get them to wake up. SamuelRiv (talk) 14:58, 3 October 2024 (UTC)[reply]
This problem definitely exists on Wikidata, but it exists on Wikipedia, too. Amir E. Aharoni (talk) 16:06, 3 October 2024 (UTC)[reply]

Regarding the work required to update Wikidata: when I last made a change, which was admittedly a long time ago, I had to go down a long rabbit hole creating Wikidata items for each property value I was added to the citation that didn't already exist, which cascaded to creating more Wikidata items for the property values of the initially created items, and so forth. If this is still the case, then I would be a lot more inclined to update Wikidata if there were a tool to help generate the entire tree of cascaded Wikidata items for me to approve for submission. isaacl (talk) 16:35, 2 October 2024 (UTC)[reply]

Continuation

While the initial premise of this thread is challenging. I think it's worth regrouping to deliberate specifically on some other concepts and potentialities vis à vis Wikidata integration others have brought up so far. In particular, I think it's generally agreed that a range of features are potentially viable as long as they're bidirectionally transparent—i.e. Wikipedia users do not have to learn how to use Wikidata or leave Wikipedia in order to pull or update information. We're fairly familiar with this partially being the way short descriptions work, I think? Remsense ‥ 论 03:46, 3 October 2024 (UTC)[reply]

I believe Wikidata pull en.wiki short descriptions (and other languages?) for its relevant field only when there is no existing one on Wikidata, and similarly en.wiki only shows Wikidata if there is no en.wiki short description (unless that has already been disabled?). Wikidata will also pull coordinates and other items, but I don't know if much of this comes bidirectionally back to en.wiki. CMD (talk) 14:07, 3 October 2024 (UTC)[reply]
You can find more about usage of Wikidata on English Wikipedia at Wikipedia:Wikidata. Over 100 Infoboxes make use of Wikidata in some fashion. See Category:Infobox templates using Wikidata.
The other dimension this conversation neglects, is that English Wikipedia editors would have chance to support other language editions, if we maintain interoperability between Wikidata and Wikipedia; with all other language editions of Wikipedia. There are legitimate concerns about interface complexity (for all Wiki projects) and sourcing standards, but let's tackle them instead of carte-blanche rejecting any synergies. ~ 🦝 Shushugah (he/him • talk) 23:24, 3 October 2024 (UTC)[reply]
I'm familiar with our infoboxes using Wikidata. The uses I'm aware of though aren't bidirectionally transparent in the way Remsense mentions, as you very much do have to go into Wikidata to edit them. CMD (talk) 23:31, 3 October 2024 (UTC)[reply]

I'll probably again be accused of "passively disrupting the wiki to make a point"[56], but for anyone who believes that Wikidata has a well-functioning vandal patrol system, here are the 5 random bits of vandalism I bookmarked last week, surprise, none of them have been corrected. They are a varied bunch, from someone creating an unsourced BLP violating article on a non-notable person[57] to someone randomly vandalising some labels[58] (which also affects e.g. Commons), from the obscure but obvious[59] to an editor vandalizing 4 different articles without any problems[60], and ending with a Wikipedia editor with an enwiki article, who died fighting for Ukraine against Russia, being blatantly vandalized and insulted[61]. Fram (talk) 09:47, 9 October 2024 (UTC)[reply]

To sneak in a very brief aside I meant to post before this spawned a subthread, I do think passive disruption is a bit of a tough sell. Folly Mox (talk) 12:49, 9 October 2024 (UTC)[reply]
Putting aside the specifics, would semi-protecting all items used on enwp sufficiently assuage vandalism fears? It would've prevented all of those examples above. It's already the case that high-use items are semi-protected, but I don't really know the culture of semi-protection on Wikidata to predict whether a lower threshold is realistic. Seems worth acknowledging as a possible support condition amid the years-long "it's garbage" vs. "it's useful" debates here. — Rhododendrites talk \\ 12:04, 9 October 2024 (UTC)[reply]
If we transcluded such content onto Wikidata, the selections of content we actually use would be put under the same, quality countervandal lens that has worked for years. Aaron Liu (talk) 12:10, 9 October 2024 (UTC)[reply]
Do you mean "from" Wikidata? Otherwise I don't really understand your comment. And no, in the current system this wouldn't work, vandalism on Wikidata that has an impact here is not detected as quickly as vandalism here (in general, we have vandalism that remains for months or years as well). We can include Wikidata changes in e.g. "recent changes", but then we get things like this included (as "Dm Antón Losada Diéguez (Q3393880); 12:37 . . Estevoaei (talk | contribs) (‎Created claim: Property:P1344: Q12390563)", which has no bearing on Enwiki at all. Which is typical, most of the Wikidata changes we see are either interwiki links, English descriptions (which we don't display anyway), or things like this which will never be shown here. Fram (talk) 12:46, 9 October 2024 (UTC)[reply]
Yes, I meant from, sorry. You indeed don't get RC patrolling, but I think the biggest reason WD vandalism doesn't get detected is that it's not prominently displayed. Any vandalism that escapes initial RC patrolling would have little chance of detection unless the vandal has hubris (c.f. anyone who has nuked someone's contributions) or people actually read the article, which they do, and so they fix. If we increase the prominence of such data by actually using it, we will also substantially increase the countervandalism. I hardly see any vandalism on wiki-data we already include on articles. Aaron Liu (talk) 17:23, 9 October 2024 (UTC)[reply]
At least some of the examples I gave already impacted e.g. Commons, and no one detected it from there either. When the Wikidata descriptions were displayed on enwiki, vandalism of these descriptions was not significantly or rapidly detected on enwiki and reverted on Wikidata. This RfC discussion from 2017 gives many examples of what goes wrong when enwiki relies on Wikidata for its data, and also gives (near the bottom) examples of prominent Wikidata vandalism lasting for hours and impacting a number of enwiki articles, from during that RfC. It happens all the time. Fram (talk) 18:02, 9 October 2024 (UTC)[reply]
Commons isn't very prominent.

lasting for hours

So? That's not abnormal for vandalism, even on Wikipedia. The amount of edits nuking reverts means many cases of vandalism probably are still extant. There's this famous boxer I forgot the name of who had his infobox blatantly vandalized with the nickname changed to something like "imbecile"; it only got reverted after four days. Look at special:Diff/1241738467, which shut off the feedback request service for months. Disregarding the easy protection fix, does that mean all RfCs should be run manually? No. Aaron Liu (talk) 18:35, 9 October 2024 (UTC)[reply]
I doubt that vandalism moving Romania to Moldavia would last for hours on enwiki. This is not some sneaky vandalism, this is in-your-face vandalism. As for Wikidata vandalism being perpetuated across infoboxes in many languages (and not being spotted or corrected by the people at these languages either), we have now (since more than an hour) an impossible date of birth for Johan Cruijff, one of the best soccer players ever and thus an article of some importance. The Wikidata vandalism is visible in Catalan[62], Asturian[63], Galician[64], "ha"[65], Norwegian[66], Welsh[67], and so on. Using enwiki as a pool of editors to do vandal control on Wikidata (which is what the above proposal would boil down to) doesn't seem to be a productive way forward for enwiki. Fram (talk) 12:35, 14 October 2024 (UTC)[reply]
Vandalism moving Romania to Moldavia wouldn't last for hours on Wikidata either. Johan's DOB was reverted 7 minutes after your comment, and thus the wrong birthdate only stood for 1 hour and 15 minutes. And no, that's not because of your comment, as the reverter is a frequent RC patroller. We can see that Wikidata does have countervandalism. As for the wikis not spotting it, don't forget that it's a workday in Europe, and don't forget the boxer. Aaron Liu (talk) 12:56, 14 October 2024 (UTC)[reply]
Found the boxer edit I was talking about: Special:Diff/1249398659. Aaron Liu (talk) 13:04, 14 October 2024 (UTC)[reply]
If you start denying reality, it's hardly useful to continue this discussion. And no, I don't believe in such coincidences. When I posted the previous 5 bits of vandalism (one week after they occurred), one was deleted 2 hours later[68], and the others reverted a few minutes after my post (and a repeat occurrence only lasted for 3 hours, hurrah I guess[69]?). Meanwhile, an editor makes just one vandalim revert, which just happens to come directly after my post here, but doesn't care about other blatant vandalism like the 18 edits here[70], which again vandalizes Catalan Wikipedia[71] and even Spanish Wikipedia[72]. Less obscure articles? Stromae, the great Belgian singer: preferred image vandalized on Wikidata, so the infobox on e.g. Catalan Wikipedia or Norwegian[73] shows a wrong image for hours (oh right, during working hours, when no one uses Wikipedia...), as does Commons[74]. Never mind that since May, the Norwegian Wikipedia proudly displays at the top of their infobox, thanks to Wikidata: "Gary Lineker Golden Bollocks".[75] Clearly, using Wikidata to propulate your infoboxes is stupid and reckless, and only gives vandals an extra outlet to play around with. Fram (talk) 14:36, 14 October 2024 (UTC)[reply]
Alternatively, vandalism transcluded here will be seen and fixed much quicker meaning that for the exact same amount of effort vandal fighters will be fixing vandalism on multiple languages/projects rather than just one. Thryduulf (talk) 14:41, 14 October 2024 (UTC)[reply]
To quote myself from right above: "Using enwiki as a pool of editors to do vandal control on Wikidata (which is what the above proposal would boil down to) doesn't seem to be a productive way forward for enwiki." Wikidata is touted as good for multi-wiki data, some languages fell for this claim, and now enwiki should do the vandal control for them? Everyone here is free to go to Wikidata and do vandal patrolling, no one is stopping you. Some would even argue that if someone like Thryduulf knows that vandalism is affecting Wikidata and other languages Wikipedias, and they make no effort to do any patrolling there, they are actually "passively disrupting" the WMF landscape, no, the knowledge of the world. And as explained above by many editors, no, it's not "for the exact same amount of effort". Never mind e.g. the not yet mentioned issue of duplicated adminning effort, with blocks, protection, ... needed on both sides. Fram (talk) 15:13, 14 October 2024 (UTC)[reply]
We're just going round in circles by now, so I'm just gonna address your only new claim:

only gives vandals an extra outlet to play around with

No, it removes outlets. Previously, vandals can vandalize an infobox from an article on any edition of Wikipedia. Now, when they vandalize, they have to vandalize all of them at once and get more quickly reverted. Simplified: Previously, vandals have like 80 places to vandalize. Now, they only have like 20. Common sense shows that vandalism seen on the Spanish Wikipedia is reverted quicker than that of the Catalan Wikipedia. Wikidata centralizes information, and thus vandal control can be less duplicated.
Since you've been acrimoniously listing vandalism on Wikidata that reflects onto the Catalan edition, why don't you look at this giant list of vandalism on the Catalan WIkipedia instead? Aaron Liu (talk) 15:21, 14 October 2024 (UTC)[reply]
That math doesn't math. If there is a version of an article on 80 Wikipedias and they all draw their infoboxes from Wikidata, then there are still 80+1 places to potentially vandalize, because there's still the rest of the article - this proposal doesn't get rid of that. A vandal who wants to write "poop" at the top of the article on Catalan Wikipedia can now do so at either Catalan Wikipedia or Wikidata, and someone who wants to prevent vandalism from appearing in that article at Catalan Wikipedia needs to monitor both. Nikkimaria (talk) 15:36, 14 October 2024 (UTC)[reply]
Ah, so that's what it means. Fair point. But the information in the infobox is arguably (one of?) the most important part of an article, and the math would math there. Aaron Liu (talk) 16:44, 14 October 2024 (UTC)[reply]
Not if you allow overrides. Nikkimaria (talk) 16:50, 14 October 2024 (UTC)[reply]
A workday in Europe? But it's St Angadrisma's Day today. --Redrose64 🌹 (talk) 14:53, 14 October 2024 (UTC)[reply]
They take days off Christian feast days in Europe? Aaron Liu (talk) 15:07, 14 October 2024 (UTC)[reply]
Have you been to Cardiff on 1 March, or Dublin on 17 March? --Redrose64 🌹 (talk) 17:36, 14 October 2024 (UTC)[reply]
I know there are big saints, but I don't think Angadrisma is one that any country takes time off for. Aaron Liu (talk) 17:47, 14 October 2024 (UTC)[reply]
It's possible to think of it as vandal control on the English Wikipedia that also happens to be vandal control on Wikidata and Wikipedia in other languages. Amir E. Aharoni (talk) 13:34, 14 October 2024 (UTC)[reply]
There are simple implementations, which may perhaps be needed to be coded at WMF level, that we could implement to monitor cross-wiki vandalism from our watchlists here, which seems to be basically what you're talking about -- any change of a wikidata (or commons etc) transcluded material onto a watchlisted article should result in a notification on that editor's WP watchlist (or similarly implemented tool).
Of course, if for example every citation in an article becomes linked to wikidata (and this is beyond the scope of OP), this is a lot of items to place on a watchlist, but I don't know that it matters since the number of expected changes on WD and Commons items is so small (assuming one can watchlist individual properties and not entire items). But automating the process should not be an issue, and notification cross-wiki is already to some extent doable.
Of course it doesn't address what's brought up previously that WD is f-ing awful to edit, which really is something that can be fixed if editors there acknowledge it. SamuelRiv (talk) 15:50, 14 October 2024 (UTC)[reply]

Verifiability does not guarantee inclusion

I have started a new essay, User:Cambalachero/Verifiability does not guarantee inclusion, listing cases of stuff that should not be used in Wikipedia, even if we have references for it. Do you have other ideas, or better ways to explain the current ones? Cambalachero (talk) 18:35, 3 October 2024 (UTC)[reply]

You might consider adding something about "in popular culture" content, as addressed at WP:IPC. Specifically, it generally isn't appropriate for inclusion without a secondary source. DonIago (talk) 19:14, 3 October 2024 (UTC)[reply]
I'm guessing you're aware of WP:Onus and are just writing an explanatory essay for it. Aaron Liu (talk) 20:10, 3 October 2024 (UTC)[reply]
Yes, that section says very little. It says that sometimes content may not be added even if verifiable, but does not explain when. And I have often seen "it's verifiable!" or "it's in the sources!" as a catch-on defense for several other contents that are questionable for other reasons. Cambalachero (talk) 13:00, 4 October 2024 (UTC)[reply]
How does this differ from WP:NOT? Thryduulf (talk) 13:15, 4 October 2024 (UTC)[reply]
Something about celebrity gossip (and even non-celebrity gossip!), may also be appropriate. CapitalSasha ~ talk 13:12, 4 October 2024 (UTC)[reply]
WP:RECENTISM, and WP:10YEARTEST in particular, might have some inspiration. -- LCU ActivelyDisinterested «@» °∆t° 19:34, 5 October 2024 (UTC)[reply]
This follows from our first pillar that "Wikipedia is an encyclopedia" and its corollary that Wikipedia is not an indiscriminate collection of information. Jason Quinn (talk) 12:00, 6 October 2024 (UTC)[reply]

I've been trying to find articles which need creating and from which the topic is important for months, but it seems nowhere to be seen. So, I'm planning to create the project. I just want to pitch the idea here and see if you can think of improvements. 🍗TheNuggeteer🍗 23:36, 5 October 2024 (UTC)[reply]

Wikipedia:Most-wanted articles and/or Wikipedia:Requested articles are probably what you're looking for. Chaotic Enby (talk · contribs) 23:44, 5 October 2024 (UTC)[reply]
Maybe Wikipedia:Broad-concept article? Vital articles tend to be on rather broad subjects, like "Law" or "Animal". WhatamIdoing (talk) 00:49, 6 October 2024 (UTC)[reply]
Might also be Special:WantedPages, although it would be nice to filter that by namespace. Wikipedia:Most-wanted articles hasn't been updated in a year and a half, and includes only #–A as initial title character, and doesn't filter links from template transclusions. Would be pretty cool if someone could do a new query for that page with those two issues fixed. Folly Mox (talk) 01:20, 6 October 2024 (UTC)[reply]
This idea interests me, but I suspect it would either become a duplicate of requested articles, or it would be a machine to churn out stubs without actually giving them the attention we're trying to bring. Thebiguglyalien (talk) 00:52, 6 October 2024 (UTC)[reply]
Then maybe I can expand the Tambayan Philippines de-stubbing force to a Wikipedia-wide project. 🍗TheNuggeteer🍗 07:36, 6 October 2024 (UTC)[reply]
How about a weekly list of 20 articles which are important in this order:
  • Agriculture:
  • Food
  • Art and language:
  • Architecture
  • Paintings
  • Literature
  • Engineering, technology, and mathematics
  • Engineering
  • Technology
  • Mathematics
  • History
  • Historical events and figures
  • Media and drama
  • Films and movies
  • Videos
  • Pictures
  • Music
  • Albums
  • Songs
  • Artists
  • Science
  • Earthquakes and storms
  • Animals
  • Scientists
  • Philosophy
  • Religion
  • Social Sciences
  • Trends
  • Sports
  • Activities
  • Sports teams and events
  • Video games and warfare
  • Wars
  • Video games
Any objection? 🍗TheNuggeteer🍗 07:43, 6 October 2024 (UTC)[reply]
How are you identifying these? Pulling from the relevant Wikiprojects? CMD (talk) 07:52, 6 October 2024 (UTC)[reply]
What do you mean by that? 🍗TheNuggeteer🍗 07:54, 6 October 2024 (UTC)[reply]
How would a list of 20 vital redlinks of such a diverse scope be identified? How would redlinks be found in the first place? CMD (talk) 07:57, 6 October 2024 (UTC)[reply]
By pulling from the relevant WikiProjects like you asked. 🍗TheNuggeteer🍗 07:58, 6 October 2024 (UTC)[reply]
Already created a draft: User:TheNuggeteer/sandbox2 🍗TheNuggeteer🍗 08:03, 6 October 2024 (UTC)[reply]
This is your project, so I'm trying to withhold judgement on your proposed topic taxonomy, but I am a bit mystified by the choices. I'm wondering how Video games and warfare form a logical pair, and I'm thinking there might be more to Science than Earthquakes and storms, Animals, and Scientists. Historical events and figures might be a more populated subcategory than you seem to be bargaining for, and I'm curious as to why Pictures and Trends each warrant a weekly redlink for creation, when topics such as Medicine, Politics, and Geography are wholly absent.
You might be interested in overviewing the WMF's topic taxonomy at :mw:ORES/Articletopic § Taxonomy, although if your source for wanted redlinks is WikiProjects, probably the easiest and most effective taxonomic scheme will just involve pulling one redlink from the twenty most active WikiProjects. Folly Mox (talk) 17:08, 6 October 2024 (UTC)[reply]

Automatically add archive date

The archive URL comes in this format: www.web.achive.org/web/yyyymmdd/https:www.placeholder.com

The date can be automatically entered when the URL is given, instead of having to add the date. Who am I? / Talk to me! / What have I done? 05:03, 7 October 2024 (UTC)[reply]

I know that is true of the Internet Archive, but I seem to remember that other archiving services have different URL formats. Alt.Donald Albury (talk) 12:00, 7 October 2024 (UTC)[reply]
Maybe we can detect the link (starting with web.archive.org), and if it is the internet archive, then the format can be used. The other archives are not used significantly, so this will not impact the process much. Who am I? / Talk to me! / What have I done? 12:43, 7 October 2024 (UTC)[reply]
This is an excellent idea. Archive.org does not use yyyymmdd but, for example, 20031224105129. I manually have to insert dashes at the appropriate points 2003-12-24105129 and remove the timestamp so I end up with 2003-12-24. It seems very very likely that a bot is already doing this task, but to be sure you can ask over at Meta or WP:VPT. Polygnotus (talk) 23:08, 7 October 2024 (UTC)[reply]
Ok, so only the archive URL is needed to fill the citation template. The date can just be filled in automatically
Who am I? / Talk to me! / What have I done? 02:47, 8 October 2024 (UTC)[reply]
Pinging @GreenC for archive.org's date format WhatamIdoing (talk) 17:43, 9 October 2024 (UTC)[reply]
As an idea, I fully support this. I also used to wonder why the heck the template would nag about the missing date when it's available in the URL, and was particularly annoyed by the timestamp mismatch message. However, I've since learned that this is not as easy to implement as it may seem.
  • {{cite}} templates literally can't add the missing parameter or alter it, because templates can only alter their output (i.e. the displayed HTML), not change the wikitext input. I guess strictly speaking this would be possible with subst:-ing, but forcing everyone to do that with {{cite}} isn't going to fly.
  • The editor (software) certainly could make this happen automagically, but I'm pretty sure the devs would (understandably) be disinclined to introduce special treatment for specific templates on a specific wiki. Also, while the visual editor could hide the necessary wikitext change behind the scenes, for the source editor this would have to mean auto-correcting the submitted wikitext after the fact, and AFAIK this is currently not done for any reason.
  • Since {{cite}} is usually placed inside <ref>...</ref>, mw:Extension:Cite could conceivably handle this, but again, good luck convincing the devs.
So, I think "fill in |archive-date= from |archive-url= while the user is editing" is probably going to be a hard sell. There are other considerations, though.
  • Since a missing or mismatched |archive-date= automatically lands the page in Category:CS1 errors: archive-url, is it necessary to nag editors about it (and, especially, put red error messages in the displayed page)? fixemptyarchive and fixdatemismatch functionality of WP:WAYBACKMEDIC can easily fix these errors, so why not have the bot run more frequently than the current every 2-3 months? Not necessarily with its full functionality, just against this particular category. I don't really see why this couldn't happen daily.
  • And to put this more radically: is a separate |archive-date= needed at all when its content merely duplicates that of another parameter? Since CS1 Lua code already has some special handling for archive.org, why not just add taking the date from the URL as well? CS1 predates the availability of Lua, so perhaps this was too inconvenient to implement with the old template functionality and requiring editors to always include this parameter was unavoidable. This no longer seems to be the case, though. Archive information doesn't seem to be needed for COinS (which wouldn't be taken directly from wikitext anyway), nor do I know of any other reason to keep it mandatory for archive.org links (or any others that include the date).
I'm very possibly missing something important regarding the status quo, so hopefully people like @Trappist the monk and @GreenC can chime in.
Gamapamani (talk) 12:29, 12 October 2024 (UTC)[reply]
Thanks a lot for refining the proposal. The second consideration makes a lot of sense. Adding an archive URL is always manual, even if you use the automatic tool, so I think it makes sense to remove the parameter and, using Lua, find the date from the URL. Who am I? / Talk to me! / What have I done? 14:23, 12 October 2024 (UTC)[reply]
--> Category:CS1 errors: archive-url currently has 33 pages. I clear it every 15 days. Last time it was cleared was around October 1. Not a big problem. -- GreenC 19:47, 12 October 2024 (UTC)[reply]
Sure, I didn't mean to imply it should be cleared more often as things stand right now. What I was trying to say was that if |archive-date= nagging in the editor and on the resulting page were dropped for archive.org, the category would presumably fill somewhat faster, but the bot could still handle it. Gamapamani (talk) 02:59, 13 October 2024 (UTC)[reply]

Public figure photos on infoboxes

Hello. I would like to propose a project regarding photos on infoboxes on articles pertaining to executives and other public figures. I believe there is too much inconsistency on Wikipedia, with photos ranging from official, professional portraits to photos taken of them out in the wild, such as on a stage or during a live stream. To maintain consistency and make Wikipedia articles look more presentable, I would like us to move towards having portraits of said individuals whenever possible to avoid copyright infringement. Most articles of politicians follow this trend; and so, I'd like to broaden this to all public figures, especially those who hold or have held C-level positions. I look forward to everyone's thoughts and please let me know if this type of discussion should be moved elsewhere. MikeM2011 (talk) 21:29, 7 October 2024 (UTC)[reply]

Not sure what you want to do that hasn't already been done. The reason there's so much inconsistency in portraits is that we just don't have enough photographers to take pictures of subjects in public places (or get consent to take pictures of subjects in private places). Aaron Liu (talk) 21:36, 7 October 2024 (UTC)[reply]
There are many professional portraits available online we could use. I'm not sure why we can't utilize these with proper citations under the fair use agreement. MikeM2011 (talk) 02:12, 10 October 2024 (UTC)[reply]
You can't because anyone should be able to take a free image of them in a public location, and we can't afford to allow mass uploads and then get sued a ton. Aaron Liu (talk) 02:34, 10 October 2024 (UTC)[reply]
Unfortunately, the rules over non-free content do not allow to use fair use claims on photos of living people, and that policy is way too strong to even consider changing it (I'm not even sure if we can, or if it was decided by the Wikimedia Foundation). That means that, on a lot of things related to images, we don't use or do what we would want, but only what we can with the limited images available to us. I suspect that by "articles of politicians" you mean US politicians, and we have plenty of good images and even portraits because many official sites release their contents under free licenses. But try to write about politicians from elsewhere, and you'll likely have to deal with the same scarcity of good photos of many other topics. Cambalachero (talk) 03:58, 10 October 2024 (UTC)[reply]
I believe that requirement is purely local. We created it, and we can change it. But I share you skepticism that we would choose to change it. WhatamIdoing (talk) 18:13, 11 October 2024 (UTC)[reply]
foundation:Resolution:Licensing policy says An EDP may not allow material where we can reasonably expect someone to upload a freely licensed file for the same purpose, such as is the case for almost all portraits of living notable individuals. Anomie⚔ 20:39, 11 October 2024 (UTC)[reply]

Show good articles on main page

Portals (such as the physics portal) show good articles, so why not on the main page? Electrou (formerly Susbush) (talk) 09:39, 8 October 2024 (UTC)[reply]

We do. New good articles are eligible to be nominated for DYK. Portals aren't really a design pattern worth comparing to given their lack of popularity, and most good articles frankly aren't worth showcasing more than we already do via DYK. Remsense ‥ 论 09:43, 8 October 2024 (UTC)[reply]

Lowercase or uppercase initials at titles of entries as their true spelling

PROPOSAL: the titles of entries at Wikipedias, to be spelt exactly as they are written in their languages. With lowercase or uppercase initials.
This is a proposal for all wikipedias. Every some years, I revisit the subject.
Why here: because this is the largest and most infulential wikipedia. The opinion of the most experienced editors could make possible a global change from forced uppercase/capitals as initials at every single entry to the true and correct spelling in its own language.
Would en.wikipedia editors please consider:

  • No switch to uppercase/capital initial letter without grammatical reason. No violation of the true spelling of words.
  • If not case sensitive (in unison with the Wiktionaries of the same language), at least case tolerant.
    For any spelling at SearchBox both initials (uppercase/capitals and lowercase) would lead to an entry, written correctly:
    e.g. brown (color), Brown (surname), brown (disambiguation) hypothetical examples: BROWN (company), Brown (novel)

I know how difficult this project would be:
technically (cf WP:Naming conventions#Lowercase first letter, Template:lowercase and many discussions)
but mainly, psychologically.
I think, that choosing uppercase/capitals for all entries, at the first days of the design of wikipedias, was a huge mistake. Now, very difficult to correct. But it is never too late to do the correct thing.
Thank you for listening, a wiktionarian (inevitably case-sensitive), Sarri.greek (talk) 16:54, 9 October 2024 (UTC)[reply]

but don't you say "Lithuanian" with a capital L and thus "Wiktionarian" with a capital W? Aaron Liu (talk) 17:12, 9 October 2024 (UTC)[reply]
Of course, M @Aaron Liu:, please excuse my ignorance of English grammar and any misspellings. In my personal writing i tend to use lowercase Sarri.greek (talk) 17:18, 9 October 2024 (UTC)[reply]
  • @Sarri.greek: assuming you mean changing the behaviour of page titles so that they become case sensitive, making e.g. Brown and brown different pages, then I'm not understanding what the benefits of this will be? What has changed now that makes you think the consensuses arrived at in the many previous discussions will be different this time? Thryduulf (talk) 17:08, 9 October 2024 (UTC)[reply]
    M @Thryduulf: At the moment, the page for the colour is entitled Brown. Inexplicable capital initial. I think it should be brown with lowercase or, brown (color) [the full title]. Thank you for your attention. Sarri.greek (talk) 17:15, 9 October 2024 (UTC)[reply]
    @Sarri.greek: That would be because of technical limitations - article titles that start with a letter must start with it capitalised. {{lowercase title}} can be used to force the first letter of an article title to render lowercase (as at iPhone), but this does not change the actual title of the page in software (IPhone). You cannot be seriously suggesting spamming that template across what is certain to be in the low seven-figures of articles, right? —Jéské Couriano v^_^v threads critiques 17:57, 9 October 2024 (UTC)[reply]
    M @Jéské Couriano: >>must start with capitalised<< Why? Was that a WMF decision? An English Wikipedia decision? Sorry that I do not understand the technical reasons of this initial approach (or any tech matter) to write the colour 'brown' capitalised, when it is an isolated word (not in a sentence, not a title of a book or essay, but just a word). Thank you. Sarri.greek (talk) 18:09, 9 October 2024 (UTC)[reply]
    @Sarri.greek: It's a MediaWiki (read: software) decision. You would need to talk to the developers. (Just because the developers are on WMF payroll doesn't mean the WMF made decisions on how to handle article titles, especially since this well predates the WMF's existence.) —Jéské Couriano v^_^v threads critiques 18:36, 9 October 2024 (UTC)[reply]
  • I'm struggling to see how this would be beneficial. If we have our titles in sentence case, shouldn't the first word still be capitalized? Chaotic Enby (talk · contribs) 17:30, 9 October 2024 (UTC)[reply]
    I believe this is a proposal to stop having our titles in sentence case. WhatamIdoing (talk) 17:48, 9 October 2024 (UTC)[reply]
    Which would make the whole thing look more inconsistent, as section titles, for instance, will presumably stay in sentence case. Chaotic Enby (talk · contribs) 19:18, 9 October 2024 (UTC)[reply]
  • I am generally of the opinion that the case sensitivity of Wikipedias was a mistake (and largely disagree with that aspect of WP:DIFFCAPS, although I of course follow it). Similar to why all articles start with an uppercase letter, the case sensitivity made some sense if you look at the origin of Wikis in general where they would auto link CamelCase words without additional syntax needed. As Mediawiki no longer does that, the need for a leading capital letter is largely gone. And why it's still there is, I think, the understanding that the effort (programmatically/technically , content updates, and just everyone getting "used" to the changes) wouldn't be worth the squeeze. Although my guess is most of the technical effort would be making the migration as seamless as possible for readers, as Wiktionary already allows (or at least appears to allow to readers and editors alike) actual initial lowercase (but is case sensitive). I haven't researched enough to know exactly what I'd support or oppose. Skynxnex (talk) 18:31, 9 October 2024 (UTC)[reply]

New fonts

I always wanted to see other fonts on Wikipedia (except Comic Sans MS, that is so bad). Try adding other fonts. Electrou (formerly Susbush) (talk) 16:09, 11 October 2024 (UTC)[reply]

Add this to your Special:MyPage/common.css:
body {
	font-family: "name of font family";
}
, with the part between the double quotes replaced with the actual font family, of course. Aaron Liu (talk) 16:32, 11 October 2024 (UTC)[reply]
Ok. Electrou (formerly Susbush) (talk) 16:54, 11 October 2024 (UTC)[reply]
I want Ubuntu font, can I get the code? Electrou (formerly Susbush) (talk) 17:04, 11 October 2024 (UTC)[reply]
does it support Ubuntu font? Electrou (formerly Susbush) (talk) 17:13, 11 October 2024 (UTC)[reply]
It doesn't work (I tried Ubuntu font) Electrou (formerly Susbush) (talk) 17:17, 11 October 2024 (UTC)[reply]
@Electrou, what web browser and operating system are you using? WhatamIdoing (talk) 18:56, 11 October 2024 (UTC)[reply]
I'm using the latest version of Google Chrome, and I'm on mobile (I use desktop view when needed) Electrou (formerly Susbush) (talk) 20:30, 11 October 2024 (UTC)[reply]
As Chaotic Enby suggests, you can't display Wikipedia in any font that isn't on the device you're using. If you open Google Chrome and go into the settings/preferences, there is an item (on my laptop, it's under "Appearance") that says something like "Customize fonts". It should have a drop-down menu that lists all the fonts. If "Ubuntu" isn't in that list, then your device can't display that font. WhatamIdoing (talk) 20:43, 11 October 2024 (UTC)[reply]
If you can't install it on that device, then you can still use fallback fonts! They're mostly useful if the same page can be viewed from different devices with different sets of fonts installed, and display if the preferred font isn't install.
body {
	font-family: "preferred font", "fallback font", "fallback fallback font";
}
For example, my userpage is best viewed in Josefin Sans, but also has a series of fallback fonts as it is not available on every device. Chaotic Enby (talk · contribs) 21:38, 11 October 2024 (UTC)[reply]
Theoretically, you can also do @import url('https://fonts.googleapis.com/css2?family=Ubuntu:ital,wght@0,300;0,400;0,500;0,700;1,300;1,400;1,500;1,700&display=swap'); to download the fonts automatically. However, I don't think that'll work, since MediaWiki:Common.css is the top stylesheet and I'm not sure if the user's stylesheet is loaded individually. Aaron Liu (talk) 21:47, 11 October 2024 (UTC)[reply]
You can load fonts from other servers such as the Google font server, or the toolforge proxy for the Google font server, should you choose. Note page referrer info will get sent to the font server whenever the font is loaded (typically it will get cached so it will load infrequently), so some people are wary of doing this. Also note the toolforge mirror isn't recommended for general use. isaacl (talk) 22:00, 11 October 2024 (UTC)[reply]
I have installed the font, but it doesn't display it. Electrou (formerly Susbush) (talk) 07:55, 12 October 2024 (UTC)[reply]
Have you installed it on your mobile phone? Chaotic Enby (talk · contribs) 20:36, 11 October 2024 (UTC)[reply]

Pages to be saved offline

It would be a very go thing to have this app where people can download or save Wikipedia for offline. This way, those who do not have access to Wi-Fi (Like me), can be able to research and edit things easily. HippieGirl09 (talk) 14:13, 12 October 2024 (UTC)[reply]

Look at the Tools tab on the article page. On my system, one of the options is to "Download as PDF". Another option is "Printable version". You can use that to print to a file. Actually, you can download all of the English Wikipedia, but you will need a lot of storage space. However, you will need to perform all edits on line.Donald Albury 18:58, 12 October 2024 (UTC) Edited 19:01, 12 October 2024 (UTC)[reply]
@HippieGirl09 The official Wikipedia Android and iOS apps allow you to save individual articles for offline reading. If you're interested in having the whole of Wikipedia available offline, then you might want to check out Kiwix. the wub "?!" 22:35, 12 October 2024 (UTC)[reply]

Adding personal page view history

I think it would be a cool feature to be able to view the history of articles which you have viewed in the past on the web version of Wikipedia (I think this might exist on the app version already?). I go through many Wikilink rabbit holes and I’d like to be able to see a list of all the articles which I have read. Is this a conceivable addition to the Wikipedia software? Cleebadee (talk) 21:10, 12 October 2024 (UTC)[reply]

I suggest using your browser history (which may mean finding a browser with a conveninent way to search your history). I think many users would feel uncomfortable with our Wikipedia reading history easily available for anyone to access on the Wikipedia server. (The information can of course be determined from web server logs, but that's less convenient for bad actors to take advantage of.) isaacl (talk) 21:32, 12 October 2024 (UTC)[reply]
As an analogy, my local library uses software that has an option of whether to retain a record of books I have checked out, which is turned off by default. With the default, the record of a book I have checked out is erased when I return the book. That way, if a government agency demands a record of the books I have checked out, and I have left the option set to not retain a record, the library has no information to turn over. Government agencies and other parties cannot optain records that do not exist. BTW, I might be paranoid, but I have earned it. I have copies of two FBI reports about me (via the US Freedom of Information Act), one about 200 pages long and the other 22 pages long. Donald Albury 22:05, 12 October 2024 (UTC)[reply]
Are you saying that Wikipedia should allow this as an option? It seems like this would be a good way to make it a thing without forcing people to use it. Maybe it could be a tool which is off by default? Cleebadee (talk) 03:28, 13 October 2024 (UTC)[reply]
I am saying that one of the considerations on whether to keep a record on what you have looked at on Wikipedia is that if a record exists it can be subpoenaed or hacked. Another consideration is that if such records do not exist, then the Wikimedia Foundation does not have to expend time and money responding to/resisting government requests for access to those records. If I could have a say on whether to have such an option, I would oppose it. I think users deserve the right to read whatever they want to on Wikipedia without worrying about someone looking over their shoulder. We cannot prevent someone from monitoring what a reader looks at from their end, but we can do what we can to preserve privacy within Wikipedia. Donald Albury 13:54, 13 October 2024 (UTC)[reply]
Would having the record available on Wikipedia itself make it easier to hack than it being available indirectly through one’s search engine history? Cleebadee (talk) 14:31, 13 October 2024 (UTC)[reply]
You can filter your browser history by websites. In the worst case, you can search "Wikipedia" in the history. Aaron Liu (talk) 22:11, 13 October 2024 (UTC)[reply]
I feel like using a hypothetical Wikipedia view history and searching Wikipedia in a search engine history are both easy things for a bad actor to do. So I don’t understand the idea that adding the Wikipedia one would make it easier for bad actors. Is it easier for them to hack into Wikipedia compared to search engines? Cleebadee (talk) 20:12, 14 October 2024 (UTC)[reply]
If you want the data to be synced across devices, you'd need to upload the information to Wikpedia's servers; meanwhile, history is usually not synced by default. It's also additional complexity to the software with very little benefit. Aaron Liu (talk) 20:49, 14 October 2024 (UTC)[reply]
I believe Zotero Connector has this option which you can activate for the wikipedia domain. That is, if you're interested in tracing back your wikipedia history (and of other websites and reading, and of sources for WP editing and general research + writing) beyond simply your browser history, Zotero is a nice thing to have around. SamuelRiv (talk) 22:23, 12 October 2024 (UTC)[reply]
Nice, I hadn’t heard of this website before. I use an iPad so I don’t think I’m able to use this though. Cleebadee (talk) 14:29, 13 October 2024 (UTC)[reply]

Wikipedia Main Page Proposal

Moved from WP:VPT

I think that the Wikipedia main page would be more educative and with a section riddles, proverbs, idioms, wise saying. You know, a collection from many languages around, their origins, past meanings, reforms, present meanings, examples of their usage in history (past & present), their literal meanings, word for word rendering in english, etc. I don't know, who has better ideas? Let Wikipedia be a fun place too for visitors and readers to always learn more. I'm looking forward to seeing this by the start of next year and in other language wikis. Any and all contributions are accepted. elias_fdafs (talk) 20:02, 13 October 2024 (UTC)[reply]

@Elías Fortaleza de la Fuerza Sánchez: I moved your idea to the idea lab here, it was not a technical issue. — xaosflux Talk 20:09, 13 October 2024 (UTC)[reply]
While this does sound more like a Wiktionary or Wikiquote thing, I feel like there might be fruitful discussion to be had about showcasing featured content from sister projects in the general case. Folly Mox (talk) 20:32, 13 October 2024 (UTC)[reply]
Oh dear, another Main Page redesign suggestion. Good luck with that. --Redrose64 🌹 (talk) 20:51, 13 October 2024 (UTC)[reply]
The thing is, one person's "wise saying" is another person's "deepity". I don't think having these on the Main Page, especially in a dedicated section, would actually be very encyclopedic. However, like Folly Mox says, a more general concept of showcasing sister project content (a word etymology, a quote, etc.) could be interesting! Chaotic Enby (talk · contribs) 21:03, 13 October 2024 (UTC)[reply]
How about a small section with whatever the sister project featured thingy is? It could cycle daily. Cremastra (talk) 22:57, 13 October 2024 (UTC)[reply]
That could very well work! Chaotic Enby (talk · contribs) 17:22, 14 October 2024 (UTC)[reply]
The tricky thing is actually transcluding something from another project, which I don't think is possible without mw:Scary transclusion. Cremastra (talk) 17:25, 14 October 2024 (UTC)[reply]
I assume you mean without scary transclusion? jlwoodwa (talk) 18:54, 14 October 2024 (UTC)[reply]
Fixed. Thanks, Cremastra (talk) 18:58, 14 October 2024 (UTC)[reply]
The problem with idioms and proverbs is that, usually, they are regional. They are widely used at some area, but hardly mentioned or even unknown in others. For each user that see such a section and says "oh, that's the origin of that proverb" we'll have several who will say "what, was that a proverb? Never heard about it". Besides, explaining their background is just impossible with the limited text in main page boxes. Perhaps DYK may be a better venue to show those articles in the main page. Cambalachero (talk) 13:18, 15 October 2024 (UTC)[reply]
Articles on idioms would be helpful, especially if they mentioned pitfalls when translating between languages. However, I don't believe that the main page is an appropriate venue. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:58, 15 October 2024 (UTC)[reply]
As I discussed at Wikipedia:Village pump (proposals)/Archive 213 § Proposal: Create quizzes on Wikipedia, I suggest finding people interested in creating that type of content, creating a project page, and producing the content regularly on whatever schedule you can manage. From that experience, you can try to figure out how to make the process sustainable. isaacl (talk) 15:59, 15 October 2024 (UTC)[reply]

WMF

WMF Board of Trustees Election Bug

Tracked in Phabricator
Task T373945

A few minutes ago, shortly after midnight GMT, 3 September 2024, I saw a pop-up message saying that WMF Board of Trustees elections were open, and giving me a link to click. I right-clicked on the link to open a new page, and got a page saying that I was not eligible to vote because 300 edits were required, and I had 39 edits. I tried again, and got the same message. That page was on Meta:, and 39 is in fact my count of edits on Meta:. A few minutes later, that banner was no longer displayed at the top of my English Wikipedia pages. So I think I have at least four questions:

  • 1. Where can I vote for WMF Trustees?
  • 2. Is my analysis correct, that it was using the number of Meta: edits when it should have been using total edits?
  • 3. Was this error corrected promptly?
  • 4. What are the actual voting requirements?

Robert McClenon (talk) 00:26, 3 September 2024 (UTC)[reply]

I have same bug, but eligibility is open to any-one Wiki project. I am not eligible via Meta, but I am via English Wikipedia (exclusive) or Wikidata. Eligibility check here. A direct link to voting should also be linked in meta:Wikimedia Foundation elections/2024 in case the pop-up was accidentally dismissed. ~ 🦝 Shushugah (he/him • talk) 01:41, 3 September 2024 (UTC)[reply]
Thank you. It now says that I am eligible to vote on English Wikipedia, although the number of edits that it says I have made is somewhat different from what CA shows, but still large. Robert McClenon (talk) 04:44, 3 September 2024 (UTC)[reply]
My mistake with a back-end setting on SecurePoll, should be OK now. Voter criteria are at meta:Wikimedia Foundation elections/2024/Voter eligibility guidelines. Joe Sutherland (WMF) (talk) 05:34, 3 September 2024 (UTC)[reply]
If you would like more info about this I filed a bug report, T373945. Joe Sutherland (WMF) (talk) 22:17, 3 September 2024 (UTC)[reply]
How does one get one of these invitations? From what's been said I'm sure I am eligible. Does one have to say nice things about the Foundation to be invited? DuncanHill (talk) 22:26, 3 September 2024 (UTC)[reply]
@DuncanHill Check this link, it will let you vote if you're eligible meta:Special:SecurePoll/vote/400. Further overview at Meta:Wikimedia Foundation elections/2024/Voter eligibility guidelines ~ 🦝 Shushugah (he/him • talk) 22:37, 3 September 2024 (UTC)[reply]
@User:Shushugah thanks, will you be messaging every other eligible voter who hasn't been told? Tagging @User:JSutherland (WMF) too as he has WMF in his name. DuncanHill (talk) 22:41, 3 September 2024 (UTC)[reply]
The problem was a bug in the setup; everyone eligible should now be able to vote and doesn't need an exemption. If you're not able to vote even now (and you are eligible please email the Elections Committee. Joe Sutherland (WMF) (talk) 22:48, 3 September 2024 (UTC)[reply]
@User:JSutherland (WMF) but how does anyone KNOW they can vote if nobody has bothered to tell them there is an election for them to vote in? I only found out because I have this page watchlisted and saw Robert's question. DuncanHill (talk) 22:52, 3 September 2024 (UTC)[reply]
Enwiki is probably going to run a watchlist notice for a week. MediaWiki talk:Watchlist-messages#WMF Board of Trustees elections. –Novem Linguae (talk) 22:55, 3 September 2024 (UTC)[reply]
There's also a CentralNotice banner, and an email was sent to Wikimedia-l earlier today. There will probably also be an email sent mid-vote, which is at this point customary in Board elections. Joe Sutherland (WMF) (talk) 23:00, 3 September 2024 (UTC)[reply]
I've had no notice and no email. And yes, I have checked my junk folder, I always check my junk folder. DuncanHill (talk) 23:02, 3 September 2024 (UTC)[reply]
I found out about the vote via a large WP:CentralNotice banner. If there is a bug, it would be worthwhile investigating, but being condescending makes me less inclined to want to investigate with you. ~ 🦝 Shushugah (he/him • talk) 22:55, 3 September 2024 (UTC)[reply]
I've not had any such notice. DuncanHill (talk) 22:59, 3 September 2024 (UTC)[reply]
Create a report at Meta:CentralNotice/Report an issue and include your operating system, screenshots, what skin you are using. And perhaps someone more knowledgeable can debug and figure out why this is happening. ~ 🦝 Shushugah (he/him • talk) 23:05, 3 September 2024 (UTC)[reply]
I've reported it here. This is the page to communicate with WMF. Monobook, Win 11, Edge. I do not feel safe on Meta after previous experiences there. I am sure I'm not the only editor not to have received notification. People on en-Wiki need to know. DuncanHill (talk) 23:08, 3 September 2024 (UTC)[reply]
Just checking: do you have "Governance" banners ticked in the banners tab of Special:Preferences? If you have unticked that, then you won't see election banners. the wub "?!" 23:35, 3 September 2024 (UTC)[reply]
@User:the wub I have them all ticked. And even if I didn't, I would rather have assumed that "Certain platform notices, such as those relating to site maintenance and special notices considered necessary to all users, will always be displayed" would cover WMF trustee elections as "special notices considered necessary to all users". DuncanHill (talk) 23:44, 3 September 2024 (UTC)[reply]
Are you saying that you think that who has ultimate control over the Wikipedia servers is really "considered necessary to all users"? Maybe you and we think so, but maybe some people think that is an abstraction, or maybe they think that the "movement" and the servers are only incidentally related. And I haven't seen statements or questions that seem directly relevant to our servers anyway. Robert McClenon (talk) 21:24, 5 September 2024 (UTC)[reply]
I was going to answer that but then I realised it would be pointless. DuncanHill (talk) 21:35, 5 September 2024 (UTC)[reply]
FYI I received an email just now about being eligible to vote and containing a link to vote. Looks like WMF is doing a massive email blast today to eligible voters. Hopefully this addresses concerns farther up in the thread about folks not being sufficiently informed. –Novem Linguae (talk) 18:50, 6 September 2024 (UTC)[reply]

Donation banners

Why are these banners so persistent? I've managed to get no less than 10 of these banners in the space of just a few minutes. 88.97.195.160 (talk) 19:28, 10 September 2024 (UTC)[reply]

88, do you allow tracking cookies from wikipedia.org in your browser? If not, the site won't remember that you've dismissed the banner already. Another option is to create an account (it's free and a single step; doesn't even require email confirmation), which will allow you to hide donation banners. Folly Mox (talk) 11:02, 11 September 2024 (UTC)[reply]

Wikimedia Foundation Bulletin September Issue 1

Here is a quick overview of highlights from the Wikimedia Foundation over the first half of September 2024. Please help Translate.

Upcoming and current events and conversations Talking: 2024 continues


Annual Goals Progress on Infrastructure See also newsletters: Wikimedia Apps · Growth · Research · Web · Wikifunctions & Abstract Wikipedia · Tech News · Language and Internationalization · other newsletters on Mediawiki.org

  • Users of all Wikis will have access to Wikimedia sites as read-only for a few minutes on September 25, starting at 15:00 UTC. This is a planned datacenter switchover for maintenance purposes.
  • The Alternative Text suggested edits feature has now been fully deployed to production on the iOS App for Spanish, Portuguese, Chinese, and French Wikipedias! This feature, part of WE1.2, is designed to enhance how newcomers add alt text to images, aiming to improve accessibility and engagement. For more details, visit the project page and explore the new feature in the app!
  • Editors and volunteer developers interested in data visualization can now test the new software for charts. Its early version is available on beta Commons and beta Wikipedia. This is an important milestone before making charts available on regular wikis. You can read more about this project update and help test the charts.
  • A new draft text of a policy discussing the use of Wikimedia’s APIs has been published on Meta-Wiki. The draft text does not reflect a change in policy around the APIs; instead, it is an attempt to codify existing API rules. Comments, questions, and suggestions are welcome on the proposed update’s talk page until September 13 or until those discussions have concluded.
  • More recent tech updates from Tech News.
  • The latest status updates from Wikifunctions.
  • Help us find WikiProjects or other online collaboration spaces!


Annual Goals Progress on Equity See also a list of all movement events: on Meta


Annual Goals Progress on Safety & Integrity See also blogs: Global Advocacy blog · Global Advocacy Newsletter · Policy blog


Board and Board committee updates See Wikimedia Foundation Board noticeboard · Affiliations Committee Newsletter


Other Movement curated newsletters & news See also: Diff blog · Goings-on · Wikimedia World · Signpost (en) · Kurier (de) · other newsletters:

Subscribe or unsubscribe · Help translate

Previous editions of this bulletin are on Meta. Let askcac@wikimedia.org know if you have any feedback or suggestions for improvement!


MediaWiki message delivery 21:40, 12 September 2024 (UTC)[reply]

Wikimedia Foundation Bulletin September Issue 2

Here is a quick overview of highlights from the Wikimedia Foundation over the second half of September 2024. Please help Translate.

Upcoming and current events and conversations

Wikimedia at the United Nations General Assembly HQ
Wikimedia event at the United Nations

Talking: 2024 continues

Annual Goals Progress on Infrastructure See also newsletters: Wikimedia Apps · Growth · Research · Web · Wikifunctions & Abstract Wikipedia · Tech News · Language and Internationalization · other newsletters on Mediawiki.org


Annual Goals Progress on Equity See also a list of all movement events: on Meta


Annual Goals Progress on Safety & Integrity See also blogs: Global Advocacy blog · Global Advocacy Newsletter · Policy blog


Foundation statements


Other Movement curated newsletters & news See also: Diff blog · Goings-on · Wikimedia World · Signpost (en) · Kurier (de) · other newsletters:

Subscribe or unsubscribe · Help translate

Previous editions of this bulletin are on Meta. Let askcac@wikimedia.org know if you have any feedback or suggestions for improvement!


MediaWiki message delivery 17:10, 27 September 2024 (UTC)[reply]

Add A Fact malfunctioning

See Talk:JD Vance#Add A Fact: "Walz vs Vance in VP debate" where Add A Fact has recommended something that not only isn't a fact... It fails verification. Add A Fact doesn't appear to have pulled a fact from the source, Add A Fact appears to have made up a questionable fact. Horse Eye's Back (talk) 16:25, 3 October 2024 (UTC)[reply]

Hi @Horse Eye's Back, thanks for flagging this. To clarify, the way this tool works requires the user (must be logged in and autoconfirmed on English Wikipedia) to manually select a snippet of text in a source (in this case, a Reuters article) to check against Wikipedia. That text snipped itself is not modified in any way by the tool (it's not even possible for the user to modify it once they've elected to look it up on Wikipedia via this tool). So I suspect what happened here is actually that the source itself (i.e., the Reuters article) was edited by Reuters after this user found the claim and sent it as a suggestion to the talk page via the tool. There appears to be an "updated a day ago" message at the top of the article, indicating that this may be the case. So I think the user of this tool unintentionally caught some possibly-fishy information that Reuters itself was putting out there and then walking back... Maryana Pinchuk (WMF) (talk) 19:40, 3 October 2024 (UTC)[reply]
Thank you for the explanation of how the tool works. Horse Eye's Back (talk) 21:47, 3 October 2024 (UTC)[reply]

Wikimedia Foundation Bulletin October Issue 1

Here is a quick overview of highlights from the Wikimedia Foundation over the first half of October 2024. Please help Translate.

Upcoming and current events and conversations

WikiArabia 2024
WikiArabia 2024

Talking: 2024 continues


Annual Goals Progress on Infrastructure

See also newsletters: Wikimedia Apps · Growth · Research · Web · Wikifunctions & Abstract Wikipedia · Tech News · Language and Internationalization · other newsletters on Mediawiki.org


Annual Goals Progress on Equity

See also a list of all movement events: on Meta


Annual Goals Progress on Safety & Integrity

See also blogs: Global Advocacy blog · Global Advocacy Newsletter · Policy blog


Board and Board committee updates

See Wikimedia Foundation Board noticeboard · Affiliations Committee Newsletter


Other Movement curated newsletters & news

See also: Diff blog · Goings-on · Wikimedia World · Signpost (en) · Kurier (de) · Actualités du Wiktionnaire (fr) · Regards sur l’actualité de la Wikimedia (fr) · Wikimag (fr) · other newsletters:

Subscribe or unsubscribe · Help translate

Previous editions of this bulletin are on Meta. Let askcac(_AT_)wikimedia.org know if you have any feedback or suggestions for improvement!


MediaWiki message delivery 23:30, 10 October 2024 (UTC)[reply]


Miscellaneous

How is everyone today?

You guys good or bad or whatever? Personally I’m decent. Jasonbunny1 (talk) 20:18, 5 October 2024 (UTC)[reply]

I'm as good as can be expected thanks, but that's by-the-by. We usually allow a bit of latitude for general chit-chat here, but I think this question strays too far from discussion of Wikipedia editing even for this page. Phil Bridger (talk) 20:53, 5 October 2024 (UTC)[reply]
Oh, my bad then. Sorry! Jasonbunny1 (talk) 21:30, 5 October 2024 (UTC)[reply]
Hey, @Jasonbunny1, thanks for your edit to Liliaspis. Would you mind taking a look at these 18 articles or these 9 articles, which are tagged as wanting some work on refs? If the tag's out of date, or if you're able to add some refs, then please just remove the tag when you're done. It would really help a lot. WhatamIdoing (talk) 22:54, 5 October 2024 (UTC)[reply]
Yeah I'm doing well, thanks for asking! —Matrix(!) {user - talk? - uselesscontributions} 15:13, 6 October 2024 (UTC)[reply]
No problem! Jasonbunny (talk) 21:52, 6 October 2024 (UTC)[reply]
im sad, because of 7 october massacres in israel, my condolonces to these civilian victims of terrorism. ----modern_primat ඞඞඞ TALK 21:51, 7 October 2024 (UTC)[reply]
Me too Saankhyareddipalli (talk) 10:44, 8 October 2024 (UTC)[reply]

User page design

Hi everyone, I recently redesigned my user page and would massively appreciate another editor (or editors) taking a quick look at it to let me know of any improvements I could make or issues which need to be addressed. Thanks! harrz talk 21:54, 7 October 2024 (UTC)[reply]

Everything looks okay in Firefox on my Mac, and everything except the center-top 'ad' looks good in Safari. (I think the space for the ad might be too narrow.) WhatamIdoing (talk) 22:58, 7 October 2024 (UTC)[reply]
Ok, thank you. I'll work on formatting the ad soon. harrz talk 15:38, 8 October 2024 (UTC)[reply]

Donald Trump 2024 presidential campaign

(non-admin closure) Nothing proposed. Regular ol' baloney. Talk:Donald Trump/Response to claims of bias. Babysharkboss2!! (Trout me, pull the trigger.) 15:34, 8 October 2024 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This page was obviously written by opponents of Donald Trump. Do you really want to take a political side with Wikipedia, the results would be disastrous. Especially to the funding of Wikipedia and if he is elected, to your platform and user group. Over half of America supports Trump. I would suggest this article be eliminated and especially with it's woke jargon and criticisms. It is also protected so that whoever wrote it (DNC) has the writes to edit it and not allow peer review by Republicans.. so sad especially because Wikipedia has previously been a fairly reliable source for many. 162.192.94.207 (talk) 14:33, 8 October 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Indigenous_peoples_in_Canada#Peoples

Where I can get this kind of statistics for Alaska for 2020? Kaiyr (talk) 17:01, 8 October 2024 (UTC)[reply]

Hi Kaiyr. It looks like Canada conducts censuses every 5 years, so 2021 is the closest you'll get to 2020. For future reference, questions like this would be better suited to one of our reference desks. Firefangledfeathers (talk / contribs) 17:12, 8 October 2024 (UTC)[reply]
I mean for USa. Alaska. Kaiyr (talk) 17:22, 8 October 2024 (UTC)[reply]
@Kaiyr, Alaska Natives#Ethnicity by region uses the 2010 census. This article on Census.gov gives figures for Alaska Native tribes in 2020 (table 2). Schazjmd (talk) 17:46, 8 October 2024 (UTC)[reply]

Too much "Personal life" type detail and trivia in bio "Early life" sections?

The notability of individuals having a dedicated Wikipedia article usually stems from their professional or societal achievements as opposed to their personal lives. Accordingly, "Personal life" sections typically appear later in an article, once professional aspects have been covered. A significant exception to this appears to be "Early life", which often includes extensive amounts of subject matter which by its nature seems better suited for "Personal life".

Is this based on general consensus or simply a tendency of more literary-inclined editors to attempt to establish some sort of a narrative about their subject? Wouldn't it in most cases be more appropriate to keep the "Early life" section as "dry" as possible (born when, where, to whom, educated at school A, university B, etc.)? I'm trying to keep this question as general as possible, so I don't want to link specific articles, but I don't think lengthy coverage of the subject's family situation and especially their parents' pasts should be in "Early life". Except for those whose entire claim to fame intrinsically stems from their lineage, like royals and nobles.

MOS:CHRONOLOGICAL directs editors to In general, present a biography in chronological order, from birth to death, except where there is good reason to do otherwise. However, since "Personal life" is separated anyway, is there a good reason to give special treatment to "Early life"? 186.86.52.215 (talk) 03:05, 9 October 2024 (UTC)[reply]

These sections tend to be popular with readers. You might be interested in reading "Obsessed with Wikipedia ‘personal life’ entries? You’re not alone" from The Washington Post.
Sometimes the ==Early life== sections don't connect well with the rest of the article, but often they do. It frequently makes sense to have a paragraph about the subject's family of origin, followed by a paragraph about education. If the coverage of non-subjects (e.g., a parent's past) really takes over articles to the point of cloaking the nominal subjects, then we call those Wikipedia:Coatrack articles. That said, one or two paragraphs wouldn't be a problem, because reading (for example) about the parents' background can help people understand the subject (e.g., Joe Film went into acting because both of his parents were actors). In principle, the amount of time spent on the subject's early life, education, and personal life should be proportionate to the amount of interest in those subjects shown in reliable sources. A CEO's biography might gloss right over those and start with the meteoric rise through the management ranks. A child actor (or the child of an actor) would probably have more about their early life.
(The early goal for Wikipedia's writing style was called Wikipedia:BrilliantProse; to the extent that "dry" means "boring", then that's not really the goal. You'd probably have better success if you argued for "encyclopedic concision".) WhatamIdoing (talk) 04:10, 9 October 2024 (UTC)[reply]
I'm not against including this material per se, I just don't think a subject's "Early life" section should detail other relationships of their parents, all their half-siblings, other stuff like that. This usually has very little to do with why the subject is notable. If someone went into acting because their parents were actors then of course that has relevance and makes sense to include. But you seem to be saying that if someone is a gossip magnet to the extent that even "reliable sources" feel compelled to cover that more than their professional work, then this proportion should be replicated here? I don't think I can agree with that. Reliability is not the issue here, all of the material may be true and verifiable as well, but it shouldn't be front and center here, I think. "Personal life" can accommodate all those looking for "sizzle". If the only way to make "Early life" not boring is to include extraneous relationship drama and such, then I'm sorry, but I don't find that an acceptable practice for Wikipedia. 186.86.52.215 (talk) 04:45, 9 October 2024 (UTC)[reply]
In-depth biographies are holistic: they cover a person's life, and examine interconnections between different parts of it. Most people with Wikipedia articles do not have in-depth biographies written about them, and so this type of info isn't available. But for those who do, meeting Wikipedia's requirements for appropriate independent, reliable sources, their Wikipedia articles can be more inclusive of details in their lives that relate to their significant actions and characteristics. isaacl (talk) 04:25, 9 October 2024 (UTC)[reply]
Like I said, I'm not against including at least some "in-depth" personal detail about people, but if who the subject dated and married is normally kept separate from the great discovery they were working on at the time, then so should the subject's mother's affair be kept separate from telling the reader what school the subject was attending at the time. For some reason this separation all too often isn't being followed in "Early life" sections, even though it is elsewhere. That's what I have a problem with. 186.86.52.215 (talk) 05:07, 9 October 2024 (UTC)[reply]
In short, use appropriate biographies as as guide. If they exist and aren't making interconnections between personal info (beyond some basic family info) and other aspects of the subject's life, then the Wikipedia article shouldn't, and the personal info may then be irrelevant to the article. isaacl (talk) 05:15, 9 October 2024 (UTC)[reply]
I don't think it's necessarily irrelevant as it may still be good for background, but if it's not really a part of the subject's notability, it should be demarcated, and in "Early life" sections it often isn't. 186.86.52.215 (talk) 05:34, 9 October 2024 (UTC)[reply]
Perhaps there's a bit of a Demarcation problem with "the subject's notability". In some cases, "the subject's mother's affair" could be something that gets a lot of attention and thus is part of the subject's notability. WhatamIdoing (talk) 00:43, 11 October 2024 (UTC)[reply]
I’ll say that I have noticed on a few biographies of people that the Personal life tends to be merged in the early life (like religious beliefs for example) when they are less notable than, say, George Washington. It’s a poor comparison I’d admit, but still one nonetheless. Wolfquack2 (talk) 16:43, 11 October 2024 (UTC)[reply]

Internet Archive hacked

For those who haven't seen this yet: https://www.bleepingcomputer.com/news/security/internet-archive-hacked-data-breach-impacts-31-million-users/ RoySmith (talk) 23:46, 9 October 2024 (UTC)[reply]

Looks like a registered user email address leak. The passwords are hashed and salted so those shouldn't be useful to a hacker unless the user had a weak password or is reusing passwords. internetarchive.org and the Wayback Machine are up and working as of right now when I tested it. –Novem Linguae (talk) 00:16, 10 October 2024 (UTC) Added some caveats. –Novem Linguae (talk) 00:28, 10 October 2024 (UTC)[reply]
With that said, it wouldn't hurt for people to change their passwords, especially if they use the same password for their email address (which you shouldn't!). I imagine most Wikipedians are going to have Internet Archive accounts given how difficult it is to write articles without its library. Thebiguglyalien (talk) 00:21, 10 October 2024 (UTC)[reply]
I'm quite upset about this. Not only because this interfered with my work, but because I can't fathom why someone would want to DDOS one of the most useful services on the internet. Speaking of, I hope Wikimedia's own DDOS mitigation systems are solid... --Grnrchst (talk) 14:27, 10 October 2024 (UTC)[reply]
"Internet Archive hacking drama: why did they do it?". -- GreenC 16:29, 11 October 2024 (UTC)[reply]
I read about that GreenC and honestly I find it pathetic. I’m going to refuse to bring politics into this discussion (which while they contribute slightly to this, I infer it is rather unnecessary), but this must be the lowest way I have ever seen someone try to protest; it’d be like burning Buckingham Palace to protest the Monarchy. Wolfquack2 (talk) 16:39, 11 October 2024 (UTC)[reply]
To alliterate, it’s result will only be in the group you’re demonstrating a “protest” disliking you even more. Wolfquack2 (talk) 16:51, 11 October 2024 (UTC)[reply]
I doubt it. As the editorial says, this kind of attack is done for advertising purposes. They probably hope someone will think "Wow, they must be expert hackers" and hire them. They are probably hoping that potential employers will not think "Seriously? That's the biggest, hardest target you can handle?"
As for results, being unfairly attacked is usually good for a non-profit's income stream in the short term. WhatamIdoing (talk) 20:26, 11 October 2024 (UTC)[reply]
Still down as of 8 43am est oct 11 •Cyberwolf•talk? 12:44, 11 October 2024 (UTC)[reply]
I’m surprised hardly any Wikipedians are replying to this serious topic. Actually I’ve seen hardly ANYBODY in general (social, news etc) that have gotten noteworthy attention. CNN, FOX, CBC and other mainstream medias aren’t even mentioning the issue. Driving me nots honestly. I wish the masses and higher ups would understand how important this library is, not only because of the Wayback but also the thousands of documents stored on it. Wolfquack2 (talk) 16:32, 11 October 2024 (UTC)[reply]
I’m saying this as someone who has a interest in Lost Media. The Archive being lost in the future could be devastating for that community. Several books that have been out of print and lost to time are stored there. Not every library in the states or elsewhere probably contains that vast of information. Wolfquack2 (talk) 16:34, 11 October 2024 (UTC)[reply]
I think this gets at a pretty gaping vulnerability with centralised infrastructure as a way to preserve information. This is only a problem because we have nowhere else to go for these books and archived web pages; we have the Internet Archive, rather than many Internet Archives (from mirrors to alternatives). If we want to ensure that such things won't be so devastating to our work in future, we need to build redundancy. To some extent, this applies to Wikipedia too. It only becomes the Library of Alexandria if we let it remain so. --Grnrchst (talk) 21:44, 11 October 2024 (UTC)[reply]
@Grnrchst I certainly agree with that. The problem is that I don’t think many are willing to make alternatives since it takes a lot of time and effort to run one of these things. Then again this situation may open those opportunities… who knows. Wolfquack2 (talk) 17:41, 12 October 2024 (UTC)[reply]
As far as mainstream media, I see reports in Newsweek, Forbes, ABC, Times of India, and The Hill. Plus of course the techie places like Wired, The Verge, etc. But, yeah, less coverage than I would have thought. RoySmith (talk) 16:46, 11 October 2024 (UTC)[reply]
What I was confused about to @RoySmith. You’d think that 31 million users would develop some type of significant coverage right? Apparently not. Wolfquack2 (talk) 16:54, 11 October 2024 (UTC)[reply]
To clarify; I’m not saying that the “tech-neck” news (as I like to call them) aren’t real media/news, I’m merely saying that the more, say, “infamous” medias (for a lack of better terms) appear to be not covering such. If you ask me, the Internet Archive is more important than the 2024 Election. Wolfquack2 (talk) 16:57, 11 October 2024 (UTC)[reply]
Speculation here, but I can think of a few motives, or 'anti motives' as it were, for why the MSM not covering it - first, the claimed source of the hack being 'pro palestinian', and the MSM's tendency towards deference to that side of the political issue. Also, an awful lot of MSM folks have been not just embarrassed, but in some cases 'canceled', due to the existence of the archive as the internet's memory - people who have made egregious statements in the past, and having them dredged up later - long after they were deleted - and weaponized against them. Third - the fact that the MSM is largely a dying concern, and the fact that the archive can in some cases cause a loss in revenue. For example, lots of older news articles are paywalled by the publishers, the largest and most well-known being the NYT and WaPo. Via the archive, a great many of those articles can be accessed without restriction.
As I said, this is all speculation. I wish there was more information available about how the archive manages their data. Considering all of the 'ransomware' incidents that have happened in recent years, that sort of exploit could indeed be ruinous - many petabytes of data encrypted by malefactors who refuse to share the key unless millions of dollars are paid. Unlike the Wikimedia foundation, the archive doesn't have an Everest-sized stack of cash lying around to pay such a ransom. cheers. anastrophe, an editor he is. 17:50, 11 October 2024 (UTC)[reply]
It's serious, because all of the Wayback Machine links on Wikipedia are down at the moment, with no clue as to when they might be back again. This is believed to be the result of a separate DDoS attack, but the Wayback Machine will not be back until all of this is fixed. --♦IanMacM♦ (talk to me) 17:54, 11 October 2024 (UTC)[reply]
Do we know just how many of our articles have wayback machine links? It would be quite illuminating to understand just how deeply this has affected us. --Grnrchst (talk) 21:51, 11 October 2024 (UTC)[reply]
@Cyberpower678 and Harej: operate WP:IABOT, so one of them may have some stats on this. RoySmith (talk) 22:03, 11 October 2024 (UTC)[reply]
Although, I see that User:InternetArchiveBot has 5,338,042 edits, so that may be a reasonable guess at the answer. RoySmith (talk) 22:05, 11 October 2024 (UTC)[reply]
Some crude searching gives ~44,000 articles[76], ~960 templates[77] and ~5,559,000 files[78]. I may be doing something wrong. NebY (talk) 22:18, 11 October 2024 (UTC)[reply]
Globally, IABot has added Archive URLs to over 22 million dead links. —CYBERPOWER (Message) 03:03, 12 October 2024 (UTC)[reply]
Enwiki itself has 12.5M wayback links in 2.5M articles (as of July), out of nearly 7M articles, or about one third of articles contain a wayback link(s), each containing 5 on average. -- GreenC 20:15, 13 October 2024 (UTC)[reply]
@Anastrophe I wouldn’t be surprised if that was the case you mentioned in the latter. And considering that the signatures to possibly overrule the Hacchett vs IA is only 40,000 signs away, I wouldn’t be shocked if this is something that scummy publishers are involved. Wolfquack2 (talk) Wolfquack2 (talk) 19:07, 11 October 2024 (UTC)[reply]
I don't think it's a good idea to speculate about motives or try to uncover grand plots. Thebiguglyalien (talk) 19:15, 11 October 2024 (UTC)[reply]
Fair point. Wolfquack2 (talk) 17:39, 12 October 2024 (UTC)[reply]
“But someday I'll prove (I'll prove, I'll prove, I'll prove)
There's a big conspiracy” -Weird Al Yankovic Wolfquack2 (talk) 17:43, 12 October 2024 (UTC)[reply]
Only way i think to fix it is shut it all down for a few days implement major security fixes and features. Wikipedia foundation wink wink could y’all help them. •Cyberwolf•talk? 18:42, 11 October 2024 (UTC)[reply]
Yep, that's exactly what the plan is per their most recent post https://x.com/brewster_kahle/status/1844790609573277792. They have it offline intentionally right now and estimate it will be back up in a few days. I'd love if the WMF were to help—besides the Wayback Machine, losing the IA library significantly affects my ability to expand several articles I'm working on. Thebiguglyalien (talk) 18:50, 11 October 2024 (UTC)[reply]
Me too race result archives and news papers •Cyberwolf•talk? 18:52, 11 October 2024 (UTC)[reply]
Not to mention how lost media can now become lost-lost media if this happens to a greater extent. Wolfquack2 (talk) 19:00, 11 October 2024 (UTC)[reply]
I suggest checking out Wikipedia:The Wikipedia Library. I spent a couple of hours earlier this year really digging through the offerings, and it's amazing. It doesn't cover everything, but it covers a lot. The central search bar at the top is nice, but it doesn't search everything, so it's useful to do publisher-specific searches occasionally.
It's probably also worth looking into your local library's offerings. The online resources from my local library, which tend to be more pop culture in nature, complement TWL's offerings, which tend to be more scholarly in nature. WhatamIdoing (talk) 20:37, 11 October 2024 (UTC)[reply]
Oh, for sure. I can't give enough praise to Oxford University Press and Springer, among others. But unfortunately it doesn't have everything (yet)! Thebiguglyalien (talk) 20:49, 11 October 2024 (UTC)[reply]
My comments about this in Wikimedia Commons village pump, if anyone is interested.
Here at Wikipedia village pump, as well as in the Commons one, I've talked previously about the dangers that Archive faces, and I also suggested WMF collaboration to adress that. I hope recent Archive's partnership with Google provides them with the needed money, but its current infrastructure (according to their publicly available information) needs to be improved without doubt. For a collection so critical to humanity, 2 production copies in San Francisco Bay Area, with no proper backups, all or part of it is only one earthquake or one cyberattack from disaster. I would like this to change. MGeog2022 (talk) 16:16, 13 October 2024 (UTC)[reply]
Looks like the web archive is provisionally back up at least. Alpha3031 (t • c) 07:24, 14 October 2024 (UTC)[reply]
Yes, things seem to be getting back to normal. Let's hope that this kind of event don't happen again in the future, but above all, if it happens, let's hope that it will be like this time, without any loss of data. MGeog2022 (talk) 17:46, 15 October 2024 (UTC)[reply]
IA should hopefully get a little bit more robust each time it happens. Speaking generally, security and disaster recovery go from being low priority to top priority every time an incident happens. Over time organizations will iterate and harden their defenses. –Novem Linguae (talk) 17:53, 15 October 2024 (UTC)[reply]
The group claiming to be behind the hack seems to have copy-pasted text from the Wikipedia article on the Internet Archive (specifically regarding lawsuits by publishers and record companies) in a twitter post justifying the attack;[79] it appears they're siding with the copyright claims of large corporations against the IA. --Grnrchst (talk) 11:38, 14 October 2024 (UTC)[reply]

The devil can cite Scripture for his purpose.
An evil soul producing holy witness
Is like a villain with a smiling cheek,
A goodly apple rotten at the heart.
Oh, what a goodly outside falsehood hath!

William Shakespeare, The Merchant of Venice
NebY (talk) 11:50, 14 October 2024 (UTC)[reply]
So, are my e-mail and password safe, or not? I am confused. Thanks, Cremastra (talk) 23:56, 15 October 2024 (UTC)[reply]
Your email and your password hash were both stolen. A password hash is your plaintext password one-way encrypted, and usually looks something like this: $2y$10$rTgZnDT6ZB93l5gY6eO.r.g2C1L3taBEL.mM1M5PFdtj3tca.UlOe. Password hashes are usually not possible to crack, with some rare exceptions such as it being a really weak password. Your plaintext password is probably safe, although it wouldn't hurt to change it anyway. –Novem Linguae (talk) 00:01, 16 October 2024 (UTC)[reply]
Thanks, so given that my password was not re-used, other accounts should be fine? I assume I may get some spam in the coming days if my e-mail is stolen. Cremastra (talk) 00:02, 16 October 2024 (UTC)[reply]
Yeap, that about sums it up I think. –Novem Linguae (talk) 00:10, 16 October 2024 (UTC)[reply]
All right, thanks very much. Cremastra (talk) 00:12, 16 October 2024 (UTC)[reply]

Heads up for accidental logouts

Tracked in Phabricator
Task T372702

There's a bug that's been going around for a few weeks where users get logged out, apparently at random. I'm aware of a few incidents where people have been logged out (presumably due to this bug), didn't notice, and leaked their IP address. So this is just a heads up to be mindful of your login status. If you're running a non-default skin and/or custom CSS, it might be obvious when you get logged out. If you're running all the defaults, not so much. So just try to be alert to this. RoySmith (talk) 01:41, 11 October 2024 (UTC)[reply]

A little more information is at Wikipedia:Village pump (technical)#Keep getting logged out. Johnuniq (talk) 22:34, 11 October 2024 (UTC)[reply]

Adding Hindustan Times sources

I do not know if this is the right place to discuss this or seek remedy, but HT sources can no longer be added automatically via ref gadgets like ProveIt and VisualEditor, only manually. Can't this be fixed, the way other websites like The Times of India were? Kailash29792 (talk) 17:29, 11 October 2024 (UTC)[reply]

Are you saying that Visual Editor -> Cite -> Automatic -> pasting a hindustantimes.com URL and clicking "Generate" isn't generating good citations for that website? There's a procedure for fixing that but I forget the details. I think it might have to do with submitting a pull request upstream to Zotero? Anyway, you might have better luck posting this at WP:VPT. –Novem Linguae (talk) 19:37, 11 October 2024 (UTC)[reply]
Yup, you are absolutely right. Previously it could, but I don't know what happened. Kailash29792 (talk) 00:54, 12 October 2024 (UTC)[reply]
There are several possibilities, some of which we can fix and some of which we can't. This periodically happens to nytimes.com too, which is inconvenient. Mvolz (WMF) can usually figure out which kind of problem it is. WhatamIdoing (talk) 02:16, 12 October 2024 (UTC)[reply]

translations

I edit in wikipedia in different languages and I want please 3 things that I do not manage to do from translators:

1. Translate for me to Hungarian the sentence "In October 12 2024 Matip announced his retirement from professional football at the age of 33" to put in Joël Matip's page

2. Translte my english user page that you can see in the link bolow to Hungarian, and put it here

3. Translate Joel Matip's page to Icelandic Latin clash (talk) 14:59, 13 October 2024 (UTC)[reply]

@Latin clash, I think you are looking for m:Meta:Babylon. WhatamIdoing (talk) 01:03, 16 October 2024 (UTC)[reply]

Preliminary results of the 2024 Wikimedia Foundation Board of Trustees elections

Hello all,

Thank you to everyone who participated in the 2024 Wikimedia Foundation Board of Trustees election. Close to 6000 community members from more than 180 wiki projects have voted.

The following four candidates were the most voted:

  1. Christel Steigenberger
  2. Maciej Artur Nadzikiewicz
  3. Victoria Doronina
  4. Lorenzo Losa

While these candidates have been ranked through the vote, they still need to be appointed to the Board of Trustees. They need to pass a successful background check and meet the qualifications outlined in the Bylaws. New trustees will be appointed at the next Board meeting in December 2024.

Learn more about the results on Meta-Wiki.

Best regards,

The Elections Committee and Board Selection Working Group


MPossoupe_(WMF) 08:25, 14 October 2024 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(all)&oldid=1092610382"