Wikipedia:Village pump (idea lab)/Archive 50

Add links
From Wikipedia, the free encyclopedia
Village pump (idea lab) archive  

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

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

Sockblocks and ambiguous loss

A few times a year, we get some high-profile sockblock that really catches the community off-guard. In the two most recent such cases, I'd been involved in the investigation, so that's given me a perspective to watch with a bit of detachment how the community responds.

Clearly, it throws people. Many are visibly upset, even those who've been here long enough to know the dark side of the wiki. And that makes sense. Such blocks are a form of ambiguous loss, a relationship (be it close or the wiki equivalent of colleagues waving hello in the hallway) that is taken away with no real chance of closure. People not only don't know what to feel, but they don't know how to feel.

A personal anecdote: When I was in high school, a classmate confided in me and a few others that she was being abused by her parents. She said she wanted to run away to live with friends in another state, so we all chipped in to help her. When the cops found her, they thoroughly investigated her family before sending her back, and found that not only was there no evidence of abuse, but many other things she'd told all of us, even little inconsequential things, were fabricated wholecloth. That was a shock to all of us, and not one we had any expectation of being able to address with her. So we sat and talked it through, various groupings of about 40 kids sharing our feelings over the course of a few days. It wasn't closure but it was something.

WP:DENY is one of the guiding principles of dealing with sockpuppetry, and Wikipedians aren't always the most "talk about your feelings" crowd, and these things make it hard to address this kind of ambiguous loss in the same way my peers and I did in high school. But is there something we can do to address the emotional impact of these cases? Maybe just an essay to write that people could point to in the future, or maybe a place to have a discussion that would be blanked or even deleted at the end, or... I don't know. I think too often we neglect editors' emotional needs, expect everyone to be cold and stoic; but I don't have a great solution in mind here. -- Tamzin[cetacean needed] (she|they|xe) 19:43, 7 June 2023 (UTC)

You are free to write such an essay. Ruslik_Zero 20:25, 7 June 2023 (UTC)
Well, yes, but I'm wondering if anyone has any better ideas. -- Tamzin[cetacean needed] (she|they|xe) 20:38, 7 June 2023 (UTC)
What bothers me most is often the nagging doubt that the CUs have got it wrong. Maybe there was a genuine WP:LITTLEBROTHER using the same device. Maybe the birthday paradox reared its ugly head. Maybe there was some unknown unknown that wasn't even considered. No matter how low the probability, I have trouble changing my opinion of someone based on evidence I can't see.
And the ones blocked as "socks" when no one will publicly name the master are the worst. Are they some sociopath planning to game CU rights for themselves and out everyone? Or are they some teenager who was CIR-blocked a dozen times when they were 10, and are too embarrassed to request an unblock from the original account? Suffusion of Yellow (talk) 21:05, 7 June 2023 (UTC)
I agree with the lack of information being an issue. The practice of Template:Blockedwithouttags is a deliberate reduction of information to other editors, resulting not only in nagging doubts but also hampering wider ability to deal with these problems. CMD (talk) 02:53, 8 June 2023 (UTC)
But then you get vandals whose sole objective is to fill a category with themselves, which is remarkably common, and then you get impersonators, copycats, and fanboys. Personally I'll often try to remember to add a name in the block log, even if it's only periodic. Often, with checkuser blocks, like a lot of LTA and VOA blocks, we might not even have a 'master' to name. If you look at Gustin Kelly's SPI, they didn't have a public name for at least 6 months. It might also be a joe-job, which is another common problem. And with checkuser blocks, by definition, there's probably non-public data involved. But I do think most checkusers/admins will usually be happy to answer any queries, even if they can't tell you much. As for the rest of this thread, users and admins have easily located talk pages. I'm not sure what else would be wanted. -- zzuuzz (talk) 13:06, 8 June 2023 (UTC)
I understand the arguments, but as time has gone on I've felt less and less like they balance the downsides. CMD (talk) 13:57, 8 June 2023 (UTC)
I'm less concerned with the obviously disruptive users who are blocked as socks-with-no-master; that's just an indication of why no one assumed good faith. (Welcome to Wikipedia. One of your recent edits forged an admin's signature to close an AFD. So if you could not do that again, that would be great...)
I'm talking about well-established users, who, to all outward appearance, were here to build an encyclopedia. That's when I have my doubts. This is no different than wondering if the police really arrested the right person. They are innocent until proven guilty in a court of law. We don't have the resources for anything like that on Wikipedia, but that's a necessary evil that we shouldn't pretend is good. Suffusion of Yellow (talk) 16:25, 9 June 2023 (UTC)
We don't automatically revoke TPA, though even when that avenue is available it isn't often used, there's also e-mail through which correspondence can be continued even if on-wiki access is revoked, although as with TPA you may be talking to a void. In the past I've tolerated socks on my own user talk page so long as they weren't acting unhinged or disrupting things elsewhere, though I don't think my words were very often taken to heart.
Historically community discussion about these blocks has taken place across a variety of user talk pages and on the noticeboards. In a high-profile case comments are virtually guaranteed on the talk page of blocker and blockee alike, though norms limit the tenor of those discussions. Perhaps somewhere with a different set of norms would help, perhaps it would just add to the drama.
There are bad CU blocks, we don't like to talk about it, but there are. I suppose that's what ARBCOM is supposed to be for, yet there are public cases where even they are nearly evenly split, follows that holds true in some private ones too.
I guess I hit resignation a long time ago, there are some things I don't understand, and will never understand; I don't judge. My advice has generally been to approach it all with dispassion, but as with so many things, that is easier said than done. 74.73.224.126 (talk) 02:19, 8 June 2023 (UTC)
@Tamzin: Exactly which sock users are you talking about? Feel free to let me know privately if necessary, but I'm sure I'm not the only one who's curious ... I skim-read the noticeboards and these village pumps but I haven't heard of a case like this in recent memory. I do sometimes miss things though ... Graham87 08:54, 8 June 2023 (UTC)
I'm happy with the answer in the recent thread on my talk page, unless of course Tamzin you want to add something there (or by email). Graham87 10:12, 9 June 2023 (UTC)
This is inspired but kind of tangential to the idea of "balancing the downsides":
I've been thinking about the problem of disclosing information. Security is complicated. Disclosing nothing is usually the safest outcome. For one thing, if I say "Alice got blocked, but I want to reassure you that it's not for any criminal reason", but for Bob, I say "Hmm, I can't really say anything about Bob", then people are going to guess that Bob was blocked because of a criminal investigation, and having that be publicly suspected could hamper the investigation or prompt inappropriate reactions (e.g., criminal harassment of the accused). Consequently, nobody can have information about any of the cases.
Another factor is our tendency to hope for justice. Specifically, if someone gets blocked for reasons we don't understand (or agree with), we worry that we, too, could be unjustifiably blocked. For core community members, a long-term block feels like getting fired from your real-world job, or having all your friends reject you. It is like a social "death sentence". You want to stay part of the community, so you watch for the behaviors that get others thrown out: People get blocked for vandalism, so you don't vandalize (not that you would want to anyway). People get blocked for unintentionally screwing up, so you're careful about your edits. People get blocked for throwing temper tantrums, so you try your best to stay cool. People get blocked for pushing too hard for a particular point of view, so you avoid contentious topics or let it go.
Against this background of you trying really hard to fit in, someone you know gets blocked or banned. And you have no idea what happened. How do you prevent yourself from making the same mistake if you don't know what the mistake is? This event adds uncertainty to your plan. The uncertainty worries you. You feel stressed. The community may have rid itself of a problematic user, but the downside is that you are more stressed than you were before. And from where you sit, the downside is large, personal, and concrete, but the upside is remote and theoretical at best.
Sure, there's always a gossip calling for "transparency" because he wants to revel in the juicy details, and there's always someone who wants "transparency" because he wants an excuse to share his views that rape threats aren't bad enough to justify blocking an editor. But I think that most editors are concerned about this because (a) they want to avoid getting blocked, and (b) they feel that they will not be able to do that unless they know every possible block-worthy offense.
I've been thinking a lot recently about the loss of trust in institutions. This is a global, real-world thing driven largely by the pandemic's isolating effects, but it's also a problem on wiki. We trust ArbCom less than we did. We trust admins less than we did. This isn't because ArbCom or the admin corps or any other group is objectively worse than it was pre-pandemic. It's because we are individually feeling less safe in trusting anything and anyone, and that includes our institutions on wiki. We have always had editors experience uncertainty over surprise blocks. What's different now is that we are experiencing that uncertainty in combination with a loss of trust. Previously, we were shocked and surprised that the editor who was nice to us was blocked for undisclosed reasons, but many of us could reassure ourselves that the decision was likely correct, because we believed that good, smart, trusted people and groups made the decision. Now, we are shocked and surprised and not as willing to believe that anyone except ourselves can make good decisions. Without personally having full information, I can't check your work and prove to myself that you made the correct decision this time, so I assume that you are wrong. It is easier for us to believe that you are wrong than for us to believe that villains don't display bad behavior in every single action throughout their entire lives. WhatamIdoing (talk) 18:00, 8 June 2023 (UTC)
I am not sure that the community as a whole has less trust in admins than it did years ago. There has always been a current of distrust of admins, although how it is expressed may have changed. For instance, I don't remember seeing a serious rant about the admin cabal for several years, now. Of course, my viewpoint may be biased, having been an admin for more than 16 years. From my perspective, there are enough checkusers and Arbcom members who do have full access to the information behind blocks (other than office actions) to prevent one or a few checkusers from misusing blocks. Every action with the CU tools is subject to review by every other checkuser. In the same vein, there are enough Arbcom members to prevent a cabal from acting inappropriately. If the community cannot trust a committee that is elected by secret ballot under strict security in two tranches, then community cannot survive. Yes, it is annoying not being in on the details, especially if the editor who was blocked was someone you knew and liked, but there are privacy and other issues that mean some things have to remain unavailable to anyone who has not signed an NDA with the Foundation. Donald Albury 18:40, 8 June 2023 (UTC)
Well... the reliable sources say that humans around the world have lost trust in institutions during the last few years.[1][2][3][4][5][6][7][8][9] Editors are humans, and we have institutions here. I doubt that the humans who contribute to Wikipedia and the institutions they create and maintain are magically immune to an effect that is destabilizing basically all other people and all other institutions. Or, to put it another way, I start with the very Wikipedian assumption that I am not a reliable source, and that when all the sources say that trust in institutions has been declining for several years and that it got worse during the pandemic, then I assume that they are more likely to be correct than my own personal experience. I assume that you do, too. WhatamIdoing (talk) 23:57, 8 June 2023 (UTC)
But, do any reliable sources says that Wikipedia editors have lost trust in its institutions? I'm pretty sure that there isn't any polling history on the topic. Donald Albury 19:32, 9 June 2023 (UTC)
We have reliable sources saying that people in general have lost trust in all institutions. We would need a source that says "except Wikipedia" to overcome that. We shouldn't start from a position of Wikipedian exceptionalism.
The only polling history I'm aware of is m:Community Insights, and it doesn't ask specifically about ArbCom (probably because it's a global survey, and very few wikis have an ArbCom). WhatamIdoing (talk) 19:52, 9 June 2023 (UTC)
We trust ArbCom less than we did. Please substantiate this claim. This isn't about "exceptionalism", it's about having a source that actually says that 1) ArbCom acts as such a body and 2) that there is evidence that people indeed trust it less. From what I have observed, the wiki seems to trust it more rather than less in the past 5 years. Extrapolating from both corporate and political bodies to onwiki bodies which are neither of those two is a false equivalence. Izno (talk) 22:22, 9 June 2023 (UTC)
I've been away for about a decade. Admins are better now than they were back when I was an admin. The same is true of ArbCom. The community has higher standards. --A. B. (talk • contribs • global count) 23:25, 9 June 2023 (UTC)
I do not think there is any solution. As some may remember, some time ago I blocked two users for edit-warring, was dragged to ANI, was forced to apologize ("either you unblock and apologize immediately or you get a personal ArbCom case filed against you"), got a personal case anyway, was fully cleared by ArbCom, and now one of the two users is blocked as a sock and another one is topic banned, mind you, for exactly this bad behavior - did anyone on Wikipedia, just any user, from that ANI crowd, came to my talk page and apologize? Nope. It just remains my personal problem to remember who is a piece of shit here. Ymblanter (talk) 14:32, 10 June 2023 (UTC)
I'm sorry you had to go through that. It's good that your blocks have been affirmed later on. But man, that's tough. SWinxy (talk) 18:14, 10 June 2023 (UTC)
If Wikipedia editors feel emotionally bereft when someone is blocked then they are making a serious category error. People that you only "know" from an online site are not your friends. They are people who you have actually met and have an attachment to. And being blocked only means that you can't edit just one web site. It's not as if blocking takes away your money, your liberty or (in some countries) your life, as criminal sanctions can do. If the emotional impact of someone being blocked lasts more than a few minutes then that's a sure sign that you are spending too long on Wikipedia. Phil Bridger (talk) 20:06, 10 June 2023 (UTC)
If an editor feels emotionally bereft after someone is blocked from (or ghosts) an online space, that means they are capable of forming emotional attachments in more than one way, which expands their potential domain of experience and connection with others. The flip side, of course, is that they can feel real loss if it is interrupted, but that's the risk you take when you open yourself up, but one that is worth taking, at least to those who experience it. Mathglot (talk) 04:02, 12 June 2023 (UTC)
Ignoring problems because their causes are things that someone should not have done, when a large amount of people do it anyway, is not how we make progress, even if you are right. Snowmanonahoe (talk · contribs · typos) 14:36, 12 June 2023 (UTC)
Telling people how they "should" feel is generally a waste of time, but I don't agree with this. Of course, some of us have met editors in person; beyond the usual in-person events, I understand that there are a handful of marriages in this community. But it's "the community" that I think is the key aspect. If you feel like you belong, that you have been accepted, that you are part of this community, then having the community kick you out is going to hurt. IMO you can't have a community without having some people be inside the group and others be outside of it. If you want to be inside the fold, and the others force you out, then of course you're going to feel rejected and excluded. That's just how normal humans respond to being rejected and excluded. WhatamIdoing (talk) 03:59, 14 June 2023 (UTC)

Rethinking autoconfirm rules

Right now, autoconfirmed means 10 edits and 4 days, in either order. That's good enough to catch random impulsive vandals, but we all know that LTAs routinely warehouse sleepers which they can trivially activate whenever they need a new confirmed account. I'm thinking it would work better if it the 4 day clock started running after your 10th edit. Then at least it would become more obvious which accounts are sleepers and which are perfectly innocent new users who simply haven't edited yet. There's a number of technology changes in the past year or two which have really eaten into the utility of checkuser. This would help move the balance back in the other direction.

The number of edits and number of days are configurable per-wiki, but this would require code changes. Let's assume for the moment that's not a blocker. -- RoySmith (talk) 17:13, 13 June 2023 (UTC)

It's not a bad idea. One reservation I have is that it would be pretty annoying for xwiki users without global rollback, especially if this were to be adopted by other wikis with edit counts for autoconfirmed. Snowmanonahoe (talk · contribs · typos) 17:20, 13 June 2023 (UTC)
I'm not following what the xwiki issue would be. -- RoySmith (talk) 17:23, 13 June 2023 (UTC)
That seems like a pretty sensible change. A fair number will still still create accounts, make 10 edits to their sandbox and wait to log back on, but that is a bit more visible. ScottishFinnishRadish (talk) 17:26, 13 June 2023 (UTC)
Is there a way within the existing settings that we could exclude edits to commonly gamed pages from counting towards autoconfirmed? Or would that just lead to the same behaviour, just on different targets? Sideswipe9th (talk) 18:17, 13 June 2023 (UTC)
  • Sorry, but I'm going to reject that needing software to be created and deployed to production isn't a blocker, because it is. There are other potential options in moving autoconfirmed out of base autopromote and in to flaggedrevs that are at least somewhat more feasible. In flaggedrevs there are all these options:
		$wgFlaggedRevsAutoconfirm = [
			'days'				=> 30, # days since registration
			'edits'			   => 50, # total edit count
			'spacing'			 => 3, # spacing of edit intervals
			'benchmarks'		  => 7, # how many edit intervals are needed?
			'excludeLastDays'	 => 2, # exclude the last X days of edits from edit counts
			// Either totalContentEdits reqs OR totalCheckedEdits requirements needed
			'totalContentEdits'   => 150, # $wgContentNamespaces edits OR...
			'totalCheckedEdits'   => 50, # ...Edits before the stable version of pages
			'uniqueContentPages'  => 8, # $wgContentNamespaces unique pages edited
			'editComments'		=> 20, # how many edit comments used?
			'email'			   => false, # user must be emailconfirmed?
			'neverBlocked'		=> true, # Can users that were blocked be promoted?
		];
  • So I think exploring what already has some support would be better. (And with enwiki being huge moving to this may not be feasible, but it is much more feasible than rewriting the autopromote software). — xaosflux Talk 17:32, 13 June 2023 (UTC)
    OK, fair enough. Putting on my software developer hat, one of the things that drives me nuts is requirements which are half "this is what I want to do" and half "this is how you should implement it". So, guilty as charged on that count. If there's a better way to implement what I want, I'm all for it. -- RoySmith (talk) 17:48, 13 June 2023 (UTC)
    Just being realistic, no way an extension for just enwiki is going to go over for this; and I really doubt that core autopromote will be rewritten (but feel free to open a feature request in the meantime, worst case it just gets ignored). On the other hand, there are other projects using FR options. I expect the "what you want" (dealing with sleepers) can be addressed with some of those options (putting aside the "use x days THEN y edits" implementation part, much less building software to implement that requirement). Looking over th FR options, could you see some of those fixing the underlying issue? (They work in AND mode). — xaosflux Talk 17:54, 13 June 2023 (UTC)
    (For what it is worth, this also has other tech issues, as the "autoconfirmed" mechanism is designed primarily to stop spam-bots - but we could make another group and move certain permissions from autoconfirmed to it). — xaosflux Talk 17:57, 13 June 2023 (UTC)
    I've never used FR, so I'd have to do some research, but from a naive reading of the flag definitions, it sounds like "edits >= 10 and excludeLastDays == 4" is pretty much what I'm asking for. -- RoySmith (talk) 17:59, 13 June 2023 (UTC)
    @Xaosflux OK, If I understand things right, flaggedrevs is only exposed on enwiki via the pending changes protection mechanism? I've never used that before, so I've played around a little with Wikipedia:Pending changes/Testing/10. I'm kind of hazy on the details. It looks like you have to pre-define sets of flaggedrevs criteria, and the only one that currently exists is PC1 (Review revisions from new and unregistered users). How do I create other sets? -- RoySmith (talk) 18:13, 14 June 2023 (UTC)
    @RoySmith that requires configuration requests; the possible idea was to use the flaggedrevs promotion system that is more flexible as a possible option - but what the desired outcome really needs to be sussed out (e.g. delay the ability to create 'articles', require captcha more often, prevent moves, etc). Introducing a new "protection level" probably isn't needed. — xaosflux Talk 18:17, 14 June 2023 (UTC)
    spacing and benchmarks look interesting: that could avoid promoting someone who makes ten edits in quick succession to game the system. However, it might make it harder to explain to someone why they've not yet been autoconfirmed despite making twenty unfortunately spaced edits over eight days. Certes (talk) 17:57, 13 June 2023 (UTC)
    @Certes indeed. An underlying item to consider is: what do you want these people to not be able to do? (All of the autoconfirmed permissions, just a subset of them?) — xaosflux Talk 17:59, 13 June 2023 (UTC)
    That's a question for RoySmith, but I'd guess we want to stop them creating client biography/CV articles. Certes (talk) 18:05, 13 June 2023 (UTC)
    If that is the real primary problem, "createpagemainns" permissions could come off of "autoconfirmed" and get applied to a new higher threshold. — xaosflux Talk 18:22, 13 June 2023 (UTC)
    Another thing paid editors tend to do is create a new draft, make ten edits to it, and then move it to mainspace. Perhaps the uniqueContentPages param could be set higher. Sungodtemple (talk • contribs) 12:55, 14 June 2023 (UTC)
    If that is a common pattern, we should not make it harder to detect by making people edit differently. With paid editing, the focus needs to be on catching it (we can't prevent that it happens unless we destroy the wiki by locking down everything). —Kusma (talk) 13:04, 14 June 2023 (UTC)
Genuine new non-autoconfirmed editors already face enough hurdles and are made unwelcome. Vandalism is overall quite low compared to 15 years ago. In my view the suggested change goes in the wrong direction. —Kusma (talk) 18:18, 13 June 2023 (UTC)
Come work SPI for a while. -- RoySmith (talk) 18:21, 13 June 2023 (UTC)
Apart from the fact that your suggestion is still trivial to bypass for determined LTAs, I think the threat to the wiki from pissing off potential new editors is greater than that of socks. I don't have data to back up my gut feeling, do you? —Kusma (talk) 18:43, 13 June 2023 (UTC)
Unfortunately, the privacy requirements around checkuser prevent me from giving specific examples, but I can say that on a regular basis, when I do range checks, I often find lots of newly created accounts which are good technical matches but with zero edits, it's difficult to justify a block as a sleeper. I'm sure any CU will tell you the same. On the other hand, with a brand new account which made 10 garbage edits and then didn't do anything else, it would be pretty obvious what was going on. -- RoySmith (talk) 18:58, 13 June 2023 (UTC)
The problem is that the kind of clever and obsessive LTAs that this targets tend to watch things closely and would adapt quite quickly. What are we going to do if they start making easy minor constructive changes to start instead? By what measure is a garbage edit anyway? Our obsolete markup isn't familiar to most people and there's a dizzying array of policies, guidelines, norms, and expectations to navigate for good-faith new users, how do we avoid false positives? Even if we take the view that all accounts that make exactly 10 edits before going quite should be blocked, they'll quickly shift to making some random number between 11 and 20.
The Autoconfirmed permission is simply tied to too many different things to be tinkered with casually, and I doubt there would be community consensus to do so anyway.
Soft-blocking potential sleepers is another option, but not one well supported by current policy. 74.73.224.126 (talk) 19:25, 13 June 2023 (UTC)
I read RoySmith as addressing the subset of accounts that are good technical matches which make exactly 10 edits and then go quiet, not all such accounts with that behaviour. Not sure how that affects your analysis, IP editor. Folly Mox (talk) 20:07, 13 June 2023 (UTC)
Good technical match is a bit of a squishy term; in some parts of the world people editing on common technically indistinguishable mobile devices can share IPs within minutes of each other. But as I said, the bigger concern is that LTAs are not static, we make a move, they make a move. In this case several low-effort countermoves that leave us exactly where we were before suggest themselves with just a moments thought, so we should find a better move instead. Feel free to refer to me as 74, since no other unregistered users beginning with those numbers are currently commenting in this discussion. 74.73.224.126 (talk) 20:19, 13 June 2023 (UTC)
I ran a query recently looking for suspicious editing patterns (exactly ten edits in quick succession, then nothing). I found very few, and those I did find seemed to be constructive good-faith editors, rather than obvious red flags such as adding and removing a space five times. Certes (talk) 21:50, 13 June 2023 (UTC)
mw:Growth/Personalized first day/Welcome survey#2022 responses might be worth a perusal, but I'm not sure it applies directly. Folly Mox (talk) 19:22, 13 June 2023 (UTC)
I'd also like to make good-faith new editors feel more welcome, though I do appreciate the problem with unwanted editing, especially UPE. My comments above were addressing the technical aspects rather than whether we should tighten things up at all. As others have implied, it might be better to improve the identification of UPEs rather than create hurdles which will bamboozle genuine newcomers but soon be overcome by a professional sock farmer. Certes (talk) 13:25, 14 June 2023 (UTC)
I don't think "tighten things up" is the right way to think about this. By making it easier to differentiate between legitimate new users and obvious sleeper creations, this will reduce the number of erroneous blocks of legitimate new users because right now there's no way to tell, and in a situation where sleepers are coming out of the woodwork, you're likely to err on the side of blocking. Also, we often semi-protect pages that are frequent targets and then have to bump that up to ECP because semi is providing no protection in the face of large sleeper warehouses. If it were harder to warehouse sleepers, we wouldn't have to resort to ECP as often, and that would be a net plus for that large set of editors who don't meet ECP requirements. I also disagree with the argument that "the hard-core LTAs and UPEs will just adjust their game". With an attitude like that, we wouldn't do anything at all. -- RoySmith (talk) 14:33, 14 June 2023 (UTC)
I'm still mulling over the suggestion writ large (particularly vis-a-vis the technical obstacles), but I agree with RoySmith that the proposed change's effect on new editors operating only their one account would be minimal, and that the net effect would be that fewer new editors would be erroneously blocked for sockpuppetry. signed, Rosguill talk 14:42, 14 June 2023 (UTC)
Speaking only for myself and North800 encapsulates the same idea below quite succinctly, the point in bringing up the dynamic nature of the issue is not to say we shouldn't look for ways to minimize disruption with as little collateral as possible, just that we need to think through the problems to find solutions that are more optimal and efficient find a better move.
Take for example ECP. The reason it works is not because it flawlessly prevents all disruption, it can be and is in fact gamed routinely, but because it shifts an important dynamic in our favor. They spend an hour to game it, and we b/lock them in two minutes. It's far from perfect, and the collateral is greater than we would like, but judiciously applied it's quite satisfactory. Now we are dealing with obsessives, so it doesn't stop them, but it does reduce the frequency.
For this proposal however, and even setting aside the technical issues, I don't really see what non-trivial dynamics this shifts in our favor. More formally it's unclear that costs will outweigh benefits. I'm not trying to shut down discussion by any means this is what VPI is for after all, I'm all ears for a better way to handle LTAs, I just don't think this is it. 74.73.224.126 (talk) 16:43, 14 June 2023 (UTC)

Wouldn't it be ultra easy for bad actors to adapt to this change? If so, the benefit would be microscopic. North8000 (talk) 16:37, 14 June 2023 (UTC)

Bot creation to replace a blacklisted ref

Following this discussion with an admin, it appears a pseudoscience source frequently used by novice medical editors is going to be blacklisted by consensus at WP:RSN. The admin reports the source is already in use at some 500 articles, which may be disrupted by a blacklisting notice when completed.

Could a bot be generated - similar to the rapid function of AnomieBOT to restore deleted references - to find and replace the blacklisted source with [citation needed|date]? Zefr (talk) 18:10, 16 June 2023 (UTC)

User:Zefr: I just did this for another RSN case at WP:URL_change_requests#Purging_all_mainspace_links_to_fmg.ac/Projects/MedLands which was in about 1000 pages .. you can make a request on that page, I can probably do it. -- GreenC 19:03, 16 June 2023 (UTC)
GreenC - thanks for the reply and possible solution. I agree with your recommendation in that discussion to remove the content and the blacklisted source together (rather than just leaving a [cn] notice), although that may need admin input. Would the bot 1) find and revert the blacklisted source and edit for the 500 existing uses (note: as an example, AnomieBOT gives an explanation of its activity) and 2) notify future input editors that the source is blacklisted and prevent the edit before publishing per WP:SPB? cc: Ohnoitsjamie. Zefr (talk) 21:31, 16 June 2023 (UTC)
I think for 1) the answer is yes. My bot can (only) 'terminate with extreme prejudice' eg. eliminate the entire reference between ref tags including the ref tags, links in external links, etc.. everything related to this source including named refs like <ref name="example" /> disappears. The text the cite sources would stay in place, there is no revert of prior edits, only deletion of citations. It could replace ref citations with a cite needed. If you want to keep the reference but eliminate the URLs, I think Headbomb's program might be able to do that. For 2) the bot is not involved with the spam blacklist. --GreenC 22:15, 16 June 2023 (UTC)
This sounds on the face of it like a project that will require some human oversight. In cases where there are bundled citations in a single pair of ref tags, or multiple references supporting the same prose, the default behaviour won't lead to good outcomes. Regarding removing named references to blacklisted sites, you'll have to track down any other uses of the named references to make sure Anomie Bot doesn't rescue them and restore the blacklisted source. Folly Mox (talk) 22:27, 16 June 2023 (UTC)
Every edit is checked, there is no way to do this kind of work 100% full auto with no checks. -- 22:35, 16 June 2023 (UTC) GreenC 22:35, 16 June 2023 (UTC)
Headbomb, this seems to be in your wheelhouse if you have any thoughts given WP:UPSD. KoA (talk) 19:24, 16 June 2023 (UTC)
I'm waiting for formal closure before updating WP:UPSD Headbomb {t · c · p · b} 19:27, 16 June 2023 (UTC)

Trust Network

There used to be a "Vertrauensnetz" (Web of Trust) on the German Wikipedia, I was hoping we could do something similar here but with a Template on a smaller more decentralized scale, I was thinking it could have three parameters, 1st the name of user B whom user A trusts, then a reason parameter (Voluntary) with for example "this user trusts user B, because of user Bs extensive knowledge in X topic" and one uneditable parameter which always says "This user trusts" so nobody can manipulate it into saying something mistrusting about another user. Is something like this even allowed? Crainsaw (talk) 16:52, 17 June 2023 (UTC)

It would be a nice idea, but, unfortunately, I'm sure it would be gamed by untrustworthy editors trusting one another. The way that content is trusted is via reliable sources, so the particular Wikipedia editor doesn't come into it. Phil Bridger (talk) 17:37, 17 June 2023 (UTC)
Untrustworthy editors trusting each other is not necessarily a problem. A web of trust is supposed to give a path from someone you trust to other people; if there's no connection between your web and the untrustworthy editors' web, the fact that they all "trust" each other isn't supposed to make a difference.
The question I'd have about this is what this "trust" is supposed to be for. Does anything we do here rely on trust where a web would be useful? RFA and other elevated permissions rely on trust to some extent, but a web of it doesn't seem too useful there. Anomie⚔ 11:38, 18 June 2023 (UTC)
Makes sense, the Trust Network shouldn't have any formal power, it should just be a tool that makes Editors trust each other more, for example if a certain editor is on someone else's Trust list, they'll become friendlier, and trust the other editor more. Crainsaw (talk) 11:42, 18 June 2023 (UTC)
You say "There used to be a "Vertrauensnetz" (Web of Trust) on the German Wikipedia" - what happened to it, and why? Johnbod (talk) 12:30, 18 June 2023 (UTC)
It was shut down because along with the Trust network, they also created a Mistrust Network (Self-explanatory), it was created to stop canvassing (Since editor A couldn't ping other editors if their page said that editor B distrusts edition C who's in discussion with editor A). But then people started to view it as personal attacks, and for reasons I still don't understand the rage somehow spilled over to the Trust network and both were shutdown. That's why I'm only for a template rather than entire user subpages dedicated to the criteria about how they trust/mistrust user's, and their extensive lists of users. And also why I'm only for a trust network and not a mistrust network Crainsaw (talk) 13:38, 18 June 2023 (UTC)
Interestingly, the template-based/decentralised method seems to have been attempted in 2006, as far as I can work out from Wikipedia:Trust network - I don't think it got any traction. Andrew Gray (talk) 19:33, 18 June 2023 (UTC)
It was also tried by some users such as here, but I was thinking a smaller more compact template which you would put at the end of your userpage, with the template being:
This user trusts:
User A
User B
...

Crainsaw (talk) 19:39, 18 June 2023 (UTC)

Unified Review Forum

The idea of a unified review forum has been raised a few times recently; the primary benefit would be that it would provide us a location where we can take closes that currently lack a clear location for reviews to take place (mergers, splits, redirects, miscellany, etc).

Depending on the specifics, it may also allow us to move RfC close reviews out, shifting the administrators' noticeboard back towards being an administrators' noticeboard - i.e., a place primarily used by administrators to coordinate administrative tasks - and away from its current state as a catch-all dramaboard.

In addition, it may also allow us to merge move and deletion reviews in; this would allow us to diversify the range of editors who contribute to those discussions as currently the boards are comparatively insular, reduce the number of noticeboards editors may wish to pay attention to, and also permit us to create a unified process by which reviews should be conducted - for example, and this would not be part of the proposal, we could always split reviews into two sections, one for uninvolved editors to !vote, and a second for involved editors to do so.

As an initial draft for an RfC on this I suggest the following:

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.

RfC on creating a unified close review forum

Should WP:Close reviews be created to review all closes not currently covered by a designated forum?

RfC on creating a unified close review forum - RfC close reviews

If the forum is created, should close reviews of RfC's be relocated from WP:AN to the forum?

RfC on creating a unified close review forum - Move reviews

If the forum is created, should WP:MRV be closed and move reviews relocated to the forum?

RfC on creating a unified close review forum - Deletion reviews

If the forum is created, should WP:DRV be closed and deletion reviews relocated to the forum?

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.

BilledMammal (talk) 12:40, 24 May 2023 (UTC)

First obvious question: Why WP:Village pump (close reviews) and not just WP:Close reviews or WP:Close reviews noticeboard? The general idea behind a village pump is that it's where people hang out and chat about Wikipedia (e.g., ideas for improving it, problems they need solved, etc.). None of them are for handling specific processes. WhatamIdoing (talk) 23:39, 24 May 2023 (UTC)
That's a good point. Changed to Close reviews noticeboard, thank you. BilledMammal (talk) 13:04, 25 May 2023 (UTC)
If you wanted, you could probably keep the format for the other reviews (WP:CRV currently redirects to an essay, but the redirect is only used on 63 pages). If your sub-suggestions are rejected, close review could just direct users to the other pages (WP:MRV and WP:DRV) for the type-specific close reviews.
I saw a variant of this presented (section link) at WP:VPP, and, at the time, I was going to indicate my support, but the conversation seemed to have been dying down, and I wasn't that confident about it. But, having been on Wikipedia a bit more since then, I feel a bit more confident now.
Still, based on the oppose votes, I'd be somewhat cautious about suggesting MRV and DRV be merged into a close review forum; I think that might actually lead people to be more wary of that forum existing at all (and, as some editors said then, there's some practical merit to separating off reviews that can only be done by admins). Just a thought.--Jerome Frank Disciple 17:09, 25 May 2023 (UTC)
That's a good point; I've changed to WP:Close reviews.
I'd be somewhat cautious about suggesting MRV and DRV be merged into a close review forum That's part of the reason I've split them off into separate questions, or are you thinking the general association might be enough to cause people to oppose the creation of the forum?
there's some practical merit to separating off reviews that can only be done by admins Deletion reviews typically need to be closed by admins, but move reviews don't. Perhaps if we just remove the question about DRV? BilledMammal (talk) 02:20, 29 May 2023 (UTC)
The first question ("closes not currently covered by a designated forum") is going to be unclear. Specific examples (e.g., merges and splits) would probably help.
The three sub-questions could be delayed to another day, but they could also be handled as a single question: "There are three existing designated forums: AN (for RFCs), MRV and DRV. Do you want any of those to be added to the new noticeboard, if it's created?" I could imagine editors saying, e.g., yes to everything except merging DRV into the new process. WhatamIdoing (talk) 04:29, 1 June 2023 (UTC)
Good point!
I also think WhatamIdoing makes a good point about the confusion in the first question, but I'm not sure there's any avoiding that.
Just as a potential structure, you could have:
  1. WP:CRV—close reviews—an non-noticeboard that merely lists where to review certain actions, containing:
    1. WP:DRV
    2. WP:MRV
    3. WP:OCRV (other close reviews?)
Not sure about that, but just food for thought.
Honestly I think your suggestion makes a ton of sense. The more I've thought about it, the more I support it. The only frustrations here come from the fact that this wasn't done in the first place!--Jerome Frank Disciple 20:27, 5 June 2023 (UTC)
I'd call it a review process rather than a noticeboard, to dampen the inevitable "we don't need another noticeboard" opposes. Apparently people disagree on what a noticeboard is. With merging DRV and MRV, it doesn't hurt to ask, but I doubt it will find consensus. – Joe (talk) 08:29, 19 June 2023 (UTC)

Can chatgpt be used on Wikipedia

Concept already beyond the "idea lab" stage, and extensive discussion in progress elsewhere. Don't fork it. DMacks (talk) 20:04, 19 June 2023 (UTC)

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.

please tell me Pastalavist (talk) 19:08, 19 June 2023 (UTC)

if bots can be used to get rid of vandalism why shouldn't they be used to create articles Pastalavist (talk) 19:09, 19 June 2023 (UTC)
This question is currently being debated at Wikipedia:Large language models and its talk page. ChatGPT might be helpful if used carefully and with close supervision, but we're very unlikely to allow AI bots to create articles without human scrutiny. Certes (talk) 19:15, 19 June 2023 (UTC)
No. ChatGPT is a stochastic parrot that generates superficially believable word salad and fake references. We already have more than enough trouble dealing with misfiring bots. The last thing we need is to hook Wikipedia up to an algorithmic sewer pipe. XOR'easter (talk) 19:55, 19 June 2023 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

New design

Hey everyone, I suggest considering that the Template:village pump has been the same for years, a more modern and attractive design should be considered for it. 𝔹𝕒𝕣𝕗𝕚𝕣𝕥𝕒𝕝𝕜 18:37, 19 June 2023 (UTC)

Do you have a proposal for a design ? —TheDJ (talk • contribs) 21:13, 19 June 2023 (UTC)
More importantly, is this important? Dronebogus (talk) 13:13, 23 June 2023 (UTC)

Merging help forums Teahouse and Help desk

Is there any reason why WP:Teahouse and WP:Help Desk are two different forums? They essentially achieve the same thing (asking about "how to use or edit Wikipedia"). I think this is an unnecessary split of volunteers and is confusing for beginners. I would like to propose a merge, but I want to know if I missed anything. Carpimaps talk to me! 14:28, 18 June 2023 (UTC)

The key question is what do the participating volunteers think? The help desk and teahouse have different approaches and so may interest different types of volunteers. isaacl (talk) 15:43, 18 June 2023 (UTC)
Help Desk volunteers are people who are willing to answer the question "how do I create an article" twice a day, Teahouse volunteers are people who are willing to answer it more than twice a day.[Humour] -- Random person no 362478479 (talk) 16:11, 18 June 2023 (UTC)
They are intended for different audiences: the Teahouse for complete beginners, the Help Desk for people who know their way around Wikipedia in general, but have questions on details. Looking at the questions asked in both this separation seems to work to a certain degree. Of course some questions end up in the "wrong" place, but in general Teahouse questions do seem to tend to be on a more basic level. I don't know whether or not there really is an issue that new users are too intimidated to ask at the Help Desk. As a still relatively new user I asked my first question at the Teahouse, but I would have had no issues asking it at the Help Desk. In general I don't have the impression that people asking elementary questions at the Help Desk are treated poorly, but of course it is possible that this is only due to the fact that they don't pop up all the time. One thing I noticed is that Help Desk questions tend to get more answers than Teahouse questions and while that can sometimes be explained by the nature of the question that is not always the case. On the question of merging the two I have no strong opinions one way or the other. -- Random person no 362478479 (talk) 16:26, 18 June 2023 (UTC)
As a regular at both venues, I oppose a merge per my short answer over at WT:HD. —Tenryuu 🐲 ( 💬 • 📝 ) 03:30, 19 June 2023 (UTC)
Oppose per random. Dronebogus (talk) 13:15, 23 June 2023 (UTC)
I already withdrawn this on the Help desk talk page. Ca talk to me! 15:41, 23 June 2023 (UTC)

Pronouns for Individuals

I think that in the biography section of Individuals it should list their pronouns, therefore making it easier for someone to search how someone identifies without going to check across the page. wookiepedia added that feature and it really helps CatdemonBlahaj (talk) 21:09, 14 June 2023 (UTC)

What would you consider appropriate sourcing for such statements? AndyTheGrump (talk) 21:26, 14 June 2023 (UTC)
WP:ABOUTSELF allows any source published by the individual themselves to be reliable sources.
Maybe this can be useful for people whose pronouns are not immediately obvious from the picture/prose. A parameter in the Infobox would be a nice place for it. Carpimaps talk to me! 14:33, 18 June 2023 (UTC)
I like the idea in theory, but I would note that info boxes and lead paragraphs are targeted by vandals much more than the rest of the prose. Wikidata has personal pronoun (P6553), so there is precedent on other projects for recording the information. ⁓ Pelagic ( messages ) 02:34, 24 June 2023 (UTC)

CSD for LLM written articles requiring WP:TNT

We're having more and more articles that are clearly written by large language model with fake sources. I just deleted Voice acting in India as a G3 hoax, as it was made up by a language model, and then a bunch of fake sources were added. Should we have a CSD specifically to cover LLM creations, or is G3 sufficient? ScottishFinnishRadish (talk) 17:27, 12 June 2023 (UTC)

I think it’s too early in the LLM era to state definitively that articles created by (or with the assistance of) LLMs cannot be valid. Models are improving in capability very rapidly. We should monitor this and be vigilant, but in the meantime, I think G3 (and possibly A11) should suffice. Barnards.tar.gz (talk) 18:43, 12 June 2023 (UTC)
We already have a draft WP:LLM policy which strongly discourages their use.
There's two main issues with them:
1. LLMs are completely unaware of Wikipedia policy and are thus very likely to commit copyright infringement, say something libelous about a living person, rely on sources we wouldn't consider acceptable, or violate NPOV.
2. LLMs are very likely to hallucinate completely false info and even fake citations. Loki (talk) 18:52, 12 June 2023 (UTC)
Not sure. Could you describe the scale of the problem in more concrete terms? Loki (talk) 18:52, 12 June 2023 (UTC)
The scale? No idea. I noticed this one because the editor's user page was on my watchlist from some warnings I left them a year ago. I know others have found LLM created articles as well. It's also an issue that's going to get worse. ScottishFinnishRadish (talk) 22:26, 12 June 2023 (UTC)
I think the LLM-written articles that we need to worry about are the ones where the use of an LLM is not obvious. That would not then be a valid CSD reason. Phil Bridger (talk) 19:29, 12 June 2023 (UTC)
This is the problem. LLM detection tools are prone to both false positives and false negatives. Often, they themselves use LLMs. Policies like these tend to be based on the obvious cases, but the reason those cases are obvious is because they flagrantly violate some other existing policy. What happens when it's unclear? Gnomingstuff (talk) 15:22, 13 June 2023 (UTC)
I think any new article filled with fake sources, regardless of what tools might have been used to create it, should be subject for deletion, and G3 as a blatant hoax seems like a suitable criterion. Not having any sources at all is a trickier issue, since traditionally deletion discussions are based on whether or not the subject meets English Wikipedia's standards for having an article, rather than the current state of the article. isaacl (talk) 20:51, 12 June 2023 (UTC)
That's why I specifically called out a TNT situation. It's likely Voice acting in India is a notable enough topic, but what was there was irredeemably tainted. G3 somewhat applies, but CSD is normally pretty tightly interpreted. If there's consensus that G3 covers it, in happy with that, but it seems like it might be stretching in some situations. ScottishFinnishRadish (talk) 22:24, 12 June 2023 (UTC)
When you asked "Should we have a CSD specifically to cover LLM creations," did you mean just LLM creations that had fake sources? If not, then the question would be when the current state of an article should be deemed irredeemable as a starting point. Personally I would prefer to focus on the characteristics of the article that make it irredeemable, regardless of what tools may have been used to create it. isaacl (talk) 23:06, 12 June 2023 (UTC)
I should have repeated it in my main question, but as the section heading says, specifically for TNT situations. There's nothing worth keeping when an article is a hallucinatory essay written by an algorithm. ScottishFinnishRadish (talk) 23:28, 12 June 2023 (UTC)
If an article warrants deletion due to no redeeming characteristics, it doesn't matter if it was written entirely by hand or with the assistance of a program. I'm not sure there's a good way to define that in a clear-cut manner in the nature of the speedy deletion criteria, though. isaacl (talk) 23:44, 12 June 2023 (UTC)
We delete bad content rather than taking an ad hominem (ad machina?) approach, but it's useful to have some way of finding pages that smell of AI so they can be judged, not on author but on article quality (or lack of it). Certes (talk) 00:01, 13 June 2023 (UTC)
(ad machinam) Folly Mox (talk) 23:04, 13 June 2023 (UTC)
How large is the problem quantifiably? Are the number of articles created that this criterion would apply to large enough that AfD would be stressed? Tazerdadog (talk) 22:22, 12 June 2023 (UTC)
AfD is already stressed. Aside from that, is AfD the venue to bring an article that was created with no effort by an algorithm with no real sources? Editor time is the most valuable resource in Wikipedia, so anything that avoids waste is important. ScottishFinnishRadish (talk) 22:31, 12 June 2023 (UTC)
When we say "editor time" in this context, we often mean "people who don't really create content". We don't seem to care much about wasting the time of the editors who created the articles.
I see two relevant possibilities:
  • The accurate identification: The article was created by an LLM, and was correctly identified as being a problematic article.
  • The false accusation: The article was not created by an LLM, but someone wants to get rid of it (for any reason, including a genuine mistake about its origin).
In the first case, AFD might waste the AFD respondents' time; in the second case, CSD would definitely waste the content creator's time. The question is: Whose time do we want to waste?
Since whether a page was created by an LLM is not uncontroversial, and CSD is supposed to be for uncontroversial deletions, I don't think we can stick to the principles of CSD and also have CSD for articles that one editor claims, usually without indisputable evidence, that its origin involved LLM. WhatamIdoing (talk) 04:10, 14 June 2023 (UTC)
By editors we should mean editors, rather than splitting the community based on personal opinions. Wasting the time of any editor on articles that took seconds to create and are likely full of AI hallucinations, is time that they could have spent on improving the encyclopedia. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:09, 14 June 2023 (UTC)
How do you know that a given article "took seconds to create"? Just guessing based on how fancy the result looks? WhatamIdoing (talk) 12:32, 25 June 2023 (UTC)
Do we have any tools (bots?) for checking that the source URLs in new articles exist? Of course, sources that don't exist may be valid (RS deleted an ephemeral news item) or good-faith errors (mistyped URL); and sources which exist may be invalid (unreliable source cited, either wilfully or in error); but a check that they exist might flag up some LLM content in a useful way. Certes (talk) 23:53, 12 June 2023 (UTC)
I suppose there's IABot, which can analyze a page and then tag everything as a dead link. Snowmanonahoe (talk · contribs · typos) 23:56, 12 June 2023 (UTC)
I wonder if it could wave a red flag in a suitable venue if it finds a new article full of dead links. Certes (talk) 23:58, 12 June 2023 (UTC)
Not a bad idea. Snowmanonahoe (talk · contribs · typos) 23:59, 12 June 2023 (UTC)
Not a bad idea but an imperfect one, since LLMs can also hallucinate print sources (or, worse, spit out the name of a real book that has absolutely nothing to do with the "fact" it stated). Gnomingstuff (talk) 15:29, 13 June 2023 (UTC)
There was no consensus for a new CSD at WT:CSD a month ago or four months ago. So I support G3 for this. No one wants to waste hours fixing LLM outputs that took a second to add, and no one wants to come to Wikipedia to read raw LLM outputs when they can get the same shitty output directly from the LLM. Many LTAs will delight in adding this stuff. If we don't clamp down on that spam, many editors & readers will give up on Wikipedia altogether, and its newfound perception of reliability among the press will wither away. See also broken windows theory: if vandals add raw LLM outputs and notice that nothing is done about it, they'll be emboldened, and if readers notice these articles, they might join in on the "fun". To respond to WAID, I'll repeat what I said at WT:LLM: right now, it's mostly easy to tell and uncontroversial (for example, see this unanimous MfD), so this isn't an issue. DFlhb (talk) 12:49, 14 June 2023 (UTC)

A Wikipedia Museum

in my opinion i think that if what vandals did were archived in some way it would be good.

i think that when people see that Wikipedia doesn't tolerate vandal it will discourage people from becoming vandals. showing the horrors of what vandals did would put into peoples minds the idea that vandalism of Wikipedia is bad and shall not be tolerated .

i would like to hear your opinions on the mater

Pastalavist (talk) 18:43, 19 June 2023 (UTC)

Oppose. We should WP:DENY recognition to vandals. I think it unlikely the proposed target audience of "potential vandals" will see it. There are already numerous ways good-faith/curious readers can learn about the damage vandalism can do and that it is not acceptable. DMacks (talk) 18:52, 19 June 2023 (UTC)
yo think of it as glorification i think of it as learning about the dangers of vandalism Pastalavist (talk) 18:58, 19 June 2023 (UTC)
the "yo" was meant to be you
sorry Pastalavist (talk) 18:59, 19 June 2023 (UTC)
A Wikipedia Museum could be valuable, but it should not curate vandalism per WP:DENY. A collection of landmark discussions that those with institutional memory consider to have been important in shaping the current culture and policy could be a nice thing to have. @Graham87 and Iridescent:, do you know of any such collection? Folly Mox (talk) 19:00, 19 June 2023 (UTC)
it should not curate vandalism. rather it should curate anti-vandalism Pastalavist (talk) 19:02, 19 June 2023 (UTC)
Every contribution to Wikipedia is archived, except for deleted pages and deleted revisions. It is its own museum, but of course it is far too large and complex to be appreciated in one visit. There are various attempts to curate the history and guide the visitor. A few pages such as Wikipedia:List of hoaxes on Wikipedia document specific types of vandalism, but generally it is something we prefer not to celebrate or encourage. Certes (talk) 19:19, 19 June 2023 (UTC)
thank you certes for giving me clarity Pastalavist (talk) 19:26, 19 June 2023 (UTC)
@Folly Mox: There's an old page at Wikipedia:History of Wikipedian processes and people, Wikipedia:Milestones (for earlier years especially), and the Historical archive for some really out-of-the way pages. For more recent news there's the Signpost archives which go back almost uninterrupted to 2005. Curating a history of Wikipedia would be difficult because different people's ideas of what is and is not historically significant vary wildly and the importance of a particular page/discussion might not become apparent until much later. To this end I made a personal Wikipedia timeline which might interest some here. Graham87 04:23, 20 June 2023 (UTC)
Thank you User:Graham87; I knew you were the right person to ask. Very interesting and educational. Folly Mox (talk) 05:37, 20 June 2023 (UTC)
OP blocked as NOTHERE. Doug Weller talk 18:39, 25 June 2023 (UTC)

Automatic inflation adjustment?

There is a Wikipedia-style website (a personal blog) where currency values are automatically adjusted for inflation as time goes on.

Dollar amounts are written like [$10](2022-01-01), then in the future users can view the original (nominal) amount as well as the inflation-adjusted (real) amount for the current year.

(The pandoc module that the above website uses is open source here, no rights reserved).

This future-proofs articles and makes them more informative. Should Wikipedia adopt this? Chrett (talk) 19:10, 25 June 2023 (UTC)

@Chrett, we already have {{inflation}}, which implements this functionality in articles where authors think it appropriate. —Kusma (talk) 19:23, 25 June 2023 (UTC)

The Education Resource of Debate in Talk for Controversial Articles

There is sometimes almost emotional debate in the Talk sections of some articles. The Donald Trump article is a very good example. This could be an educational resource for education outreach programs at Wikipedia because it presents how ideas can be discussed with proper references in terms of what is said and how it said. The education resources are how a biography of a living person (BLP) is to be written on Wikipedia and a variety of other resources as well. Starlighsky (talk) 15:25, 26 June 2023 (UTC)

Redirect hatnote link

{{redirect}} and similar templates generate a hatnote atop an article or section, such as "Telegram" redirects here. Would it be helpful to include a link to that redirect, e.g. "Telegram" redirects here.? That might encourage editors to create an article on the subtopic, or at least to visit and categorise or otherwise improve the redirect. The top of the article already has a small link when arriving via that redirect, e.g. (Redirected from Telegram), but there are other ways to reach the target article, and the link is normally off the top of the screen when arriving at a section or other anchor. Certes (talk) 13:35, 26 June 2023 (UTC)

It seems to be formatted at Module:Redirect_hatnote#L-66. Curiously, the latest discussion at Template talk:Redirect actually talks of unneeded linking. --Joy (talk) 14:20, 26 June 2023 (UTC)
We don't usually want readers to click on such a link, so we should not include it other than the tiny one at the top. —Kusma (talk) 20:03, 26 June 2023 (UTC)
Thanks for the replies. I've set up local JavaScript to link the title for me. I find it helpful, but if others don't then let's not change things. Certes (talk) 22:06, 26 June 2023 (UTC)
It would be nice if you could specify a parameter such as link=yes for the section cases. --Joy (talk) 19:29, 27 June 2023 (UTC)

Do we need to make categories more accessible and/or deprecate “navigational” lists?

Recently I’ve sent a bunch of “X by Y” listcruft articles to AfD. They’re poorly maintained and do not provide anything a category, which is automatically curated, doesn’t. But it’s been stated that, besides WP:NLIST giving clearance for lists about seemingly any notable topic, categories are not accessible on mobile. I think making categories more accessible is obviously a good thing and we should do it. I also think we should subsequently deprecate purely “navigational” lists that effectively duplicate categories. Thoughts? Dronebogus (talk) 13:06, 23 June 2023 (UTC)

Do any readers actually use categories? Or are they just there to give a few editors something to do? I would like to see the results of any research that has been conducted into this subject. Phil Bridger (talk) 22:04, 23 June 2023 (UTC)
This would be trivial to figure out if there were logs available showing flows of how people got from one wiki page to another. Tracing these flows is a standard feature of analytics tools, so it should shouldn't be hard to implement. Not much more than logging HTTP Referer data. I have no idea if these logs exist, or if they do, if they're publicly accessible. RoySmith (talk) 22:37, 23 June 2023 (UTC)
Do tou mean Shouldn’t be hard to implement? Dronebogus (talk) 22:39, 23 June 2023 (UTC)
Yeah. Fixed. RoySmith (talk) 22:41, 23 June 2023 (UTC)
@RoySmith You can access that data at toolforge:wikinav, though it is frequently semi-broken. 192.76.8.66 (talk) 23:53, 23 June 2023 (UTC)
Cool, thanks. RoySmith (talk) 23:54, 23 June 2023 (UTC)
@RoySmith I forgot to mention that you can also download the data from https://dumps.wikimedia.org/other/clickstream/readme.html 192.76.8.66 (talk) 15:21, 24 June 2023 (UTC)
@RoySmith Unfortunately I don't think the clickstream data includes anything identifiable as categories; it only identifies mainspace to mainspace links. There is an other-internal grouping but it's not clear if this is only interwiki links or if it would count project/category space links as well, and in any case it's not broken down further.
However we can get pure visitor counts using the usual pageviews tool - eg category:Living people gets about 1400/day. Category:Brazil averages 4, Category:2023 deaths averages 782 (though skewed by a big spike in early January), Category:Donald Trump averages 7, Category:Chemical elements averages 40 (with some intriguing usage patterns). A bit of a random selection, but you get the idea - viewer numbers look pretty low in the context of articles in those categories, so clickthroughs from them are unlikely to be significant.
One major factor here is likely to be that all desktop readers see categories, but mobile readers don't unless they're logged in. As a result, over 80% views across those sampled categories are from desktop users, while they only make up about a third of all views across the project. Andrew Gray (talk) 17:56, 24 June 2023 (UTC)
A quick addendum to that: I pulled down the full pageview file to sample it for one month. There were 7.75bn pageviews on enwiki in May 2023. 37.4m of those were category pages, or approximately 0.5% of the total.
Other namespaces for context -
  • File: (linked prominently from articles) is about the same at 0.5%
  • Wikipedia: is about 0.2%
  • Talk: is 0.1%
  • Help: is 0.05%
  • User: is 0.035%
  • User_talk: is 0.02%
  • Wikipedia_talk is about 0.005% (though even this small-sounding share is still ~13.5k views/day)
So Category: is reasonably well used by the standards of non-main namespace categories, but it's still pretty low throughput, and given the very large number of categories the averages are very low - about 21.5 hits/month, less than one per day.
A bit of poking around suggests there are some extremely active categories skewing the averages - the top is Category:Office_365 with ~350k hits and a strange pattern over time - May 2023 was actually on its downslope. Andrew Gray (talk) 19:37, 24 June 2023 (UTC)
And one last interesting number: lists are used 5-6x as much as categories. 2.8% of all traffic was to an article (or a redirect) with "list of" in the title. Portals are much less used - 0.04% of hits were in portal space, though the recent cleanup of portals has had a substantial effect there; it was almost twice as much in 2019. Andrew Gray (talk) 21:35, 24 June 2023 (UTC)
Great number work Andrew Gray. Very interesting also. The forum for Wikipedia guidance (WP talk) then can be said to be used by 1 in 50,000 editors. That is telling. Makes one feel sort of special I guess. Regards, Thinker78 (talk) 00:02, 27 June 2023 (UTC)
I can anecdotally say that I've always found categories to be the most useful tool to get a sense of "here's what Wikipedia has on this topic", even long before I was an editor. Thebiguglyalien (talk) 03:12, 24 June 2023 (UTC)
Categories, which can be very useful for browsing, do have very few views. But I think it is because people don't know about them or their use. One option to make them more visible is to have their own heading in articles, to let people know about them in the table of contents. I did this in John F. Kennedy, although I don't know if it's gonna stick or gonna be reverted. Also, it's unclear if the experiment will attract more views. I suspect it may. Regards, Thinker78 (talk) 07:37, 24 June 2023 (UTC)
Thinker78 This is an interesting idea. It's always bothered me a little that the navboxes and categories are technically placed in the bottom section by virtue of being at the end of the article. I wouldn't mind if this became the norm. I do expect someone to come along and remove it, but I'd be interested to see if it generates increased traffic. Thebiguglyalien (talk) 01:27, 25 June 2023 (UTC)
That is a very clever ideas Thinker78 Dronebogus (talk) 14:30, 25 June 2023 (UTC)
Lists and categories are very different and serve different purposes. Lists can contain detailed information and images whereas categories are simply a set of links. Therefore, lists should not be deprecated. Regards, Thinker78 (talk) 07:22, 24 June 2023 (UTC)
My anecdatum is that I don't personally find categories useful, since they represent only one piece of information and no other context. In desktop with navigation popups enabled they're all right, but on mobile they're just an alphabetised list of article titles with no other information. And if I'm already in desktop mode I'll probably just use a navigation template instead. That said, I don't object to there being multiple ways to index articles on related topics. Yes, List of etc articles don't auto update, but even outdated lists are more useful in my experience due to the additional context they're able to provide, as well as the ability to include non-article list items, whether they're section links or list items that fail N but pass NLIST. I would want a software change such that category view displays an article's short description following its title before I'd support removing the list articles. Folly Mox (talk) 20:06, 24 June 2023 (UTC)
To make manually curated lists without in-depth information even more redundant, one idea could be to have a toggle to display short descriptions of the articles on category pages. —Kusma (talk) 15:41, 25 June 2023 (UTC)
Because they are API-accessible, categories are used a fair bit by bots. Bots may explain some of the high use categories. Several of my bots navigate via categories. Whereas the lists are used by the humans. Hawkeye7 (discuss) 21:53, 26 June 2023 (UTC)
Can you provide examples of purely “navigational” lists that effectively duplicate categories? And you only want to deprecate such lists as opposed to all lists or navigational lists? Regards, Thinker78 (talk) 00:48, 27 June 2023 (UTC)
List of female superheroes was just kept. It duplicates Category:Female superheroes with minimal difference Dronebogus (talk) 01:34, 27 June 2023 (UTC)
The list had 8,000 views in May and the category had less than 100. Regards, Thinker78 (talk) 05:28, 27 June 2023 (UTC)
That’s because the category is largely a container for other categories. It has less than 50 entries but contains subcats with over 200. Dronebogus (talk) 19:35, 27 June 2023 (UTC)

I've never used categories to search and I'd have to research to even know how to use them. IMO newer search capabilities has made them obsolete. To use such a thing you need to do at least two things: 1. learn the system, architecture, data rules, and "how to use it" type stuff. 2. Be dependent / try to guess subjective decisions that the person making the classification made. This was fine when more modern methods were non-existent or weak, but that era has passed. Same for portals. Sincerely, North8000 (talk) 00:13, 24 June 2023 (UTC)

Categories have also this characteristic: it's like looking specifically for a book. You find the book among other books of maybe the same topic. But at the end of the book you find a list of other related books that might interest you that may have a different flavor than the search results. Consider categories and search different niches. Regards, Thinker78 (talk) 07:50, 24 June 2023 (UTC)
Phooey - to learn how to edit categories you might have to learn a little, to use them you just have to click. They are extremely useful for the things they are good for - I've no idea what "newer search capabilities" might mean - I'm a big fan of WP searches, but often they are a very blunt instrument. I hardly ever look at lists, and ones without commentary are generally useless and should be discouraged. Johnbod (talk) 02:40, 25 June 2023 (UTC)

Lists can be useful, as items which may not have enough for their own article, but do provide part of the story of the lists reason, and can then have a small synopsis. List of supermarkets can give a picture of the history of their development, including ones that have faded from history and have little available refs now for an article. Getting rid of lists and just making categories would lose this.Davidstewartharvey (talk) 16:24, 24 June 2023 (UTC)

It used to bother me that we had categories, and lists, and dab pages, and set indexes, and maybe a few other things. I still don't understand how a set index is different from a dab page, but I don't let it bother me any more :-) RoySmith (talk) 16:36, 24 June 2023 (UTC)
Oh, yeah, portals. How could I forget portals? RoySmith (talk) 16:37, 24 June 2023 (UTC)
What about those “Outline of…” articles? What’s the point of those? Dronebogus (talk) 00:35, 25 June 2023 (UTC)
Link? Regards, Thinker78 (talk) 01:51, 25 June 2023 (UTC)
Type "outline of" into a search box and see what you get. For example, Outline of academic disciplines or Outline of the Russo-Ukrainian War RoySmith (talk) 02:08, 25 June 2023 (UTC)
I didn't know about those. Regards, Thinker78 (talk) 02:58, 25 June 2023 (UTC)
@Thinker78 There's a surprisingly large number of these. A db query is showing 1353. RoySmith (talk) 14:44, 25 June 2023 (UTC)
I think the idea is that they are for top-down navigation of a subject area, something I never do. I would be happy to see all of these go. —Kusma (talk) 14:37, 25 June 2023 (UTC)
You mean outlines, or “all of the above”? Because we definitely should not purge all lists, categories, and dab pages (I honestly don’t know what a set index is). Dronebogus (talk) 14:40, 25 June 2023 (UTC)
As far as I can tell, a set index is something that looks exactly like a dab page except that if you edit it to make it comply with MOS:DAB, you get yelled at. RoySmith (talk) 14:47, 25 June 2023 (UTC)
Maybe we need to discuss getting rid of those… Dronebogus (talk) 14:48, 25 June 2023 (UTC)
I mean outlines. Lists and categories have their uses. Unlike navboxes on articles with more than two navboxes. —Kusma (talk) 15:33, 25 June 2023 (UTC)
Yes, I certainly wouldn't mourn the loss of all "outline of" pages, and I suspect most people wouldn't miss them at all. Apparently some people do look at them, though: Outline of ancient Greece averaged 23 views per day last year, which isn't much compared to Ancient Greece's 3520 views per day, but there are plenty of less-viewed articles! (I also wouldn't mourn the loss of portals, or the distinction between set indexes and dabs, while we are at it...) Caeciliusinhorto-public (talk) 11:14, 26 June 2023 (UTC)
I agree that portals are pretty much obsolete but didn’t want to suggest deleting them without view statistics. Dronebogus (talk) 18:34, 26 June 2023 (UTC)
I suspect you would find deleting portals to be an uphill battle. There's a lot of history. See WP:ENDPORTALS and WP:Arbitration/Requests/Case/Portals. I personally don't see much distinction between outline pages and portals; they're both human-curated guides to our coverage of a topic. But they both do seem to have their advocates, and I don't see how either is doing any harm, so meh. RoySmith (talk) 21:33, 26 June 2023 (UTC)
Portals, I can live with. They’re quaint and outdated, but I guess kinda serve as “the main page” for a given wikiproject to show off its work, so I get why people are attached to them. Outlines on the other hand just seem to exist to serve as yet another dust-collecting, poorly maintained internal link farm for users to (not) “navigate” with. Dronebogus (talk) 23:42, 26 June 2023 (UTC)
Someone did do a lot more work designing portals than categories though. Regards, Thinker78 (talk) 01:50, 25 June 2023 (UTC)
David: I don’t want to get rid of all lists, just lists that are simply collections of bare entries with no context Dronebogus (talk) 00:39, 25 June 2023 (UTC)
You have AfDs for that. Regards, Thinker78 (talk) 01:53, 25 June 2023 (UTC)
Which I have done, but failed in since “navigational lists” of bare links are as it is totally fine. Which brings us full circle. Dronebogus (talk) 14:31, 25 June 2023 (UTC)
Then that may just mean there is no consensus about doing away with the lists you want to get rid of. Regards, Thinker78 (talk) 00:49, 26 June 2023 (UTC)
That consensus is fine by current policy, but I started this discussion to see if consensus is against that policy itself. Dronebogus (talk) 18:36, 26 June 2023 (UTC)
What policy? Regards, Thinker78 (talk) 00:04, 27 June 2023 (UTC)
WP:NLIST + whatever people are talking about when they cite “navigational list” as a reason to keep something Dronebogus (talk) 00:08, 27 June 2023 (UTC)
  • It's categories that should be deprecated and rethought. They typically fail WP:V because they don't support citations. And their tree structure is quite arbitrary and dysfunctional, which results in constant confusion and dispute.
To provide a better generic search facility, categories should be replaced by a system of attributes. For example, for biographies you need a set of attributes such as nationality, sex, occupation, century and so forth. Then if you wanted a list of 19th-century, female, French flutists, you specify the desired attributes and a search tool would compile it. Wikidata is working along these lines and its flexible database structure is far better suited to the task than the category tree.
Pending better integration with Wikidata, I reckon that infoboxes would provide a good basis for a restructured facility. These provide a standard set of attributes for a class of articles and they have already been added to lots of articles. So, for example, if you wanted a list of battles with casualties greater than 100,000, say, infobox entries would be a reasonably systematic basis for generating it. Creating categories for such numeric thresholds would be unworkable.
Andrew🐉(talk) 12:30, 27 June 2023 (UTC)
Does anyone actually use Wikidata, even compared with categories? Dronebogus (talk) 19:26, 27 June 2023 (UTC)
Plus I think deprecating categories is fairly radical considering most if not all wikis use them as a fundamental backbone. Dronebogus (talk) 19:30, 27 June 2023 (UTC)
Yes, most wikis use them, but as a fundamental backbone? Without seeing evidence I rather doubt that. How many readers would notice if categories suddenly disappeared? Phil Bridger (talk) 20:31, 27 June 2023 (UTC)
Categories are not fundamental because they were added in 2004–5 after Wikipedia had been running for several years. They are just an alternative way of assisting navigation per WP:CLN and so could be removed completely without great difficulty. Andrew🐉(talk) 00:01, 28 June 2023 (UTC)
Though as mentioned that’s unlikely to go anywhere because people do, in fact, use them. Dronebogus (talk) 00:06, 28 June 2023 (UTC)
And killing categories would kneecap quite a few bots Dronebogus (talk) 19:32, 27 June 2023 (UTC)
Bots serve humans, not vice versa. Phil Bridger (talk) 20:31, 27 June 2023 (UTC)
It's certainly true that if we flipped a switch tomorrow and made all the categories go away suddenly, that would break a lot of stuff for no good reason. On the other hand, it's reasonable to say "Categories are deprecated. All new bots should use XXX instead, and existing bots should be migrated to use XXX by such-and-such a date". I'm not saying we should do that, but from the software engineering point of view, breaking changes are made all the time, and that's how you mitigate the carnage. RoySmith (talk) 21:28, 27 June 2023 (UTC)
I don't think categories should be deprecated because they serve a different niche. Browsing is a different action than searches. When you go to certain libraries, you can browse through books to see what interests you. Another thing is asking the librarian to search for certain topic and provide you the books. I did this in the Library of Congress regarding fairy tales expecting big books and the librarian handed me a couple of very small books. I was very disappointed. I like browsing and searching. Also, Google picks and chooses what it shows you when you search. I don't like that. Regards, Thinker78 (talk) 04:47, 28 June 2023 (UTC)
I don't understand the logic here. You say that you don't like that Google picks and chooses what it shows you, but how is that any different from a category? Somebody chose which articles to put in that category, and that's what you see. The same is true for all of the navigational tools we're discussing. When you go to a library and ask the librarian to bring you books on fairy tales, you're asking them to perform a curated search for you. The value they add is that they're familiar with the library's collection, and the tools for searching it, and also an added layer of human judgement about what you're probably looking for.
I also like browsing. Just walking up and down the stacks in a library or the aisles in a bookstore exposes me to all sorts of interesting material I might never find by doing a database search. But even then, I'm depending on the judgement of some human who decided how to shelve the books. RoySmith (talk) 14:12, 28 June 2023 (UTC)
True but you see literally the category instead of relying on the unknown parameters someone else used to conduct a search with your input terms. We don't know what code Google uses to find pages. But we know what a category says. Regards, Thinker78 (talk) 20:54, 28 June 2023 (UTC)
  • IMO the main accessibility issue with categories is categories with thousands of members, forcing readers to step through one page at a time. Lists improve on this by (usually) including all members, allowing users to use their browser’s find function. Barnards.tar.gz (talk) 19:57, 27 June 2023 (UTC)
    I never really thought about that Dronebogus (talk) 22:18, 27 June 2023 (UTC)

Okay, at this point I’m seeing a general consensus against deprecating navigational lists, which is all I was looking for. Deprecating set indexes, outlines, portals, and categories were all brought up but if someone wants to discuss those I’d recommend starting a new thread— though deprecating portals was brought up and rejected in the recent past and I highly doubt there would be a consensus to depreciate categories, which are still relatively well-used (roughly 0.5 of traffic, same as files and higher than most non-mainspace pages) even if it’s minuscule next to articles. Dronebogus (talk) 22:26, 27 June 2023 (UTC)

There is plenty of overlap between categories, list articles (including SIAs), outlines, portals, Wikidata and disambiguation pages. Each medium has its strengths and weaknesses. Ideally, we'd have one type of page which offered the best of all worlds, but we lack the technology for that and it's probably impossible even with unlimited resources. If one of those types is clearly inferior to another in every way then let's get rid of it, but I don't think that's the case. Categories can be hard to discover (at the bottom of the page near the licence terms no one reads, or worse still in a collapsed navbox beside the portal link) and sometimes hard to use due to size and unintuitive organisation into subcategories. They're for experienced and patient readers and editors rather than the casual visitor, but I think they still have a useful role. As a gnome, I use categories almost daily for finding problems to solve. Certes (talk) 23:30, 27 June 2023 (UTC)
I'm late to the party, but Certes has summed it up well; each of these mechanisms has its own strengths, and its own users. I would not be surprised to find that the vast majority of "real" readers arrive via a web search engine, bypassing categories and lists. Within Wikipedia, I suspect the only things that really matter are wiki-links (to reach related concepts) and dab-pages (when Google has failed to be specific). Technically, categories are better than lists because they're better curated (we have flocks of wikitaxonomists who dedicate their lives to fiddling about with categories, while curation of lists tends to be nothing more than the occasional skirmish between the dedicated enthusiasts of a particular list and a disgruntled deletionist wondering about the point of List of blue-green things shown on Tuesdays on Netflix, or the notability, sourcing and inclusion criteria for List of cars with sexy design features). But ultimately the problem is that most non-specialist readers neither know nor care that categories exist. I'd keep both them and lists, in hopes that someone, somewhere, finds it all useful. Elemimele (talk) 16:37, 29 June 2023 (UTC)
You kind of hit the nail on the head as to my frustration with lists. Nobody actually works on these things until someone nominates them for deletion and a bunch of inclusionists (I wouldn’t even say “enthusiasts of a particular list”) spring into action. Dronebogus (talk) 22:13, 29 June 2023 (UTC)

Suggestion : New Home for Reddit readers

WRONG VENUE
This isn't a enwiki issue. The place to propose something like this is meta:Proposals for new projects.

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.


Reddit editors are having issues with the Reddit editors, which are in turn called by google/

We should create a new wiki or a space within wikipedia that has similar features to reddit. The copyright content should not be owned to WMF as their charter allows for them to be sold, or data to be sold. Wakelamp d[@-@]b (talk) 09:00, 30 June 2023 (UTC)

If Reddit continues along its current path of pricing out useful API applications then a publicly run alternative will probably emerge, in the same way that Mastodon is replacing some uses of Twitter, but I'm not sure that Wikipedia (or the WMF) is the right organisation to organise it. Certes (talk) 09:19, 30 June 2023 (UTC)
Agree you can't create and grow communities through central planning, PR, or outreach ...
Maybe just offering server space with a wiki might be enough. The code was open sourced until 2017 )Reddit .We could just support Mastadon ID. Or give then banner time advertising them - most of the year we run stuff for WMF brand awareness. Wakelamp d[@-@]b (talk) 11:17, 30 June 2023 (UTC)
The servers used by Wikipedia and similar projects are owned by the WMF, so they'd have to be the ones supporting a Reddit clone. If budget for technical development suddenly appears, there's a long queue of MediaWiki enhancement requests I'd like to see fulfilled before expanding into new projects. Certes (talk) 11:28, 30 June 2023 (UTC)
Bothe Wikipedia and Wikimedia Foundation exist for a specific purpose (the provision of 'free knowledge'. loosely defined). Neither are intended to be providers of social media services, and it would be a highly-questionable use of funds to do so. AndyTheGrump (talk) 11:43, 30 June 2023 (UTC)
You may want to ask Jimbo about WT Social. I use neither Reddit nor WT Social but Jimbo might be interested in providing a home for former Redditors. —Kusma (talk) 12:54, 30 June 2023 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipoints (suggestion)

I have an idea in which auto-confirmed users get points based of their contributions. When you look at edit history on articles or your contributions list, they always have that either red or green (+11) (-1) thing. What if we had like a points system (called Wikipoints) about that and you start off with the amount of edits you have? You can share your points on your user page (perhaps a userbox) or compete with other users if you like. You can always gain and lose some points by thanking someone on an edit (gain), or vandalize/sockpuppetry/any other thing frowned upon in Wikipedia (loss). A little bit like the automated Wikipediholism test. Just a fun little idea between users and its only between auto-confirmed users, and above, which would persuade others to join Wikipedia. ｡ 🎀 𝒫𝓊𝓇𝓅𝓁𝑒𝓁𝒶𝓋𝑒𝓃𝒹𝑒𝓇𝓂𝒾𝒹𝓃𝒾𝑔𝒽𝓉𝓈 𝟣𝟩 🎀 ｡ (talk) 18:20, 26 June 2023 (UTC)

Strong oppose. Doing something like this would make Wikipedia akin to a social network, which it isn't. The point system is going to get gamed very, very quickly. The additions and subtractions refer to how many bytes have been added or removed in the editor's revision, and serves as a quick-glance as to what the editor could have possibly done in their edit. —Tenryuu 🐲 ( 💬 • 📝 ) 21:52, 26 June 2023 (UTC)
hmm..... how many points do I get for a topical navbox? ok, how about a period navbox? this idea sounds like it might be interesting. however, I can't really see any actual or practical way for us to implement this, though. Sm8900 (talk) 22:10, 26 June 2023 (UTC)
Wow, hold your horses, this is the idea lab and AFAICT the OP isn't suggesting that the byte differences be directly converted to points. Some opt-in, non-competitive (and preferably externally hosted) gamification that rewards some bragging rights is not necessarily a bad idea for editor retention, though like Sm8900 I can't imagine a way that doesn't require so many caveats (not reflective of contribution quality, etc.) that it ceases to be rewarding. Nardog (talk) 22:20, 26 June 2023 (UTC)
I know the OP isn't saying that byte changes should be converted into a point system. The proposal for a point system is going to result in a lot of edits that try to garner as many points as possible, and I can already think of a few ways to exploit it depending on the rules set out, which has the unfortunate side effect of lowering encyclopedia quality. —Tenryuu 🐲 ( 💬 • 📝 ) 04:36, 27 June 2023 (UTC)
Oppose Ehhh, no. I think bold!opposing in idea lab is fine for very bad, totally unworkable ideas that should be nipped in the bud, and this is one of those. Assuming perfectly good faith of course, but Tenryuu is right. Dronebogus (talk) 23:50, 26 June 2023 (UTC)
How would the points work? Removing bad content will result in negative count in the edit history, but we should reward that, not penalize it. However, I will say that we don't want to gamify Wikipedia, we have enough issues with WP:GAMING and WP:EDITCOUNTITIS RudolfRed (talk) 00:27, 27 June 2023 (UTC)
Anything that incentivises quantity over quality leads inevitably to shoddy work. Folly Mox (talk) 01:15, 27 June 2023 (UTC)
As a fun little thing I see the appeal, but I also think this idea needs some more time in the oven before it's ready.
E.g. I'd kinda like a userbox that counts the number of times I've been thank'd. That seems neat. Loki (talk) 01:18, 27 June 2023 (UTC)
Worth noting that en.wiki already has a point system through the Wikipedia:WikiCup. This is voluntary, and points are checked rather than being automatic. Feel free to participate! CMD (talk) 05:15, 27 June 2023 (UTC)
  • Idea. ok, I have an idea. how about a set of whimsical cumulative point amounts, that can be awarded like Barnstars? such as " User ___ hereby awards you 10,000 points for helping people get along." maybe? thinking.... Sm8900 (talk) 06:34, 27 June 2023 (UTC)
I've made about three or four major navboxes, and no one has given me a barnstar or any recognition at all. so that seems like the other extreme from this idea. so this proposal seems like it might have a little bit of positive value. Sm8900 (talk) 06:36, 27 June 2023 (UTC)
ok it's fixed now.  Done. and by the way, i didn't mean to have the last word in this colloquy!! Sm8900 (talk) 13:14, 28 June 2023 (UTC)
I think this could be a good idea, but better if there are multiple (or unlimited) different ways of deriving a score. For example, I would like to have a better way of quantifying work on article improvement, or sometimes in particular my work on article improvement in particular categories or at a particular level of the topical hierarchy. Another editor might want ways to quantify their participation in policy debates or their work on template/module code. -- Visviva (talk) 19:35, 1 July 2023 (UTC)

Reliable source tracking on Talk pages

Checking to see if the reliability of a source has been discussed is a pain. While there are some publication titles that are easy to search the WP:RSN archives for, others are combinations of common words which leave you with a lot to go through. Additionally, many reliability discussions never reach that noticeboard; they are just carries out on the Talk page of whatever article people were trying to use that source on. Many things have a discussion or two, but not enough to end up on the [[WP:RSNP|Reliable Sources - Perennial] list.

Thing is, a lot of the sources (whether publications or self-published possible experts) have articles about them in Wikipedia, and thus have a Talk page as well. If there is a Talk:Jane's Guide to Scooby Doo Fanfic, might it be possible to include a template that says "The use of Jane's Guide to Scooby Doo Fanfic as a source on Wikipedia has been discussed at..." and then list links to discussions? Yes, it would have to be populated by hand, and yes, it's not what the central goal of the Talk page is for as it's not discussing the editing of the article about the source, but it seems like it would be handy in many cases. (I would think we'd avoid listing the results of the discussions, as they can be very contextual, so its better to look at the details.) -- Nat Gertler (talk) 14:45, 4 July 2023 (UTC)

There are definitely non-reliable sources, but reliability of a source must also be paired with the claim associated. That said, please support meta:WikiCite/Shared Citations which would provide an overview of commentary/usage of citations across different wikipedias/articles. ~ 🦝 Shushugah (he/him • talk) 19:03, 4 July 2023 (UTC)
That looks like a real good idea with a lot of implementation difficulties that is way far in the future. I liked one of the things they mention towards the top, fr.wiki's Reference: namespace. We could probably repurpose the Portal: namespace without anyone noticing. But something like assessment of reliability for borderline sources might be a little bit outside its scope, as they do need to be assessed in the context of the claim they're supporting.
There was someone at one of these VPs a few months ago, with a similar suggestion to link directly to RSN discussions of a source from its article. While we're waiting for a full solution, a talk page template doesn't seem like a bad idea. If this were treated as a WikiProject, overall source assessment could be wrapped in the talk page banner shell, but since the overall theme here is centralising information, it might still be good to have a separate projectspace subpage for individual sources that links all the relevant discussions, which also gives the option to support sources that have no Wikipedia article (which is the vast majority of them), and we could have a fully built citation template on the page for easy copypasta. Folly Mox (talk) 20:43, 4 July 2023 (UTC)
There are a couple of gadgets which highlight various types of sources, including those listed as deprecated or unreliable at RSP, such as User:SuperHamster/CiteUnseen and User:Headbomb/unreliable which may be of interest to anyone who isn't already aware of them Caeciliusinhorto-public (talk) 11:13, 5 July 2023 (UTC)

AI add-on for illustration

The advent of image generation, such as with DALL-E 2 and Midjourney, has created an increasingly attractive opportunity for use in illustration. I would like to make (perhaps as a team) or see made a site plugin where a user is shown a generated image for the article that they are currently reading in a non-intrusive way, with the option to add the image to that article in one-click if it improves its understandability. Thoughts?   — C M B J   01:50, 4 July 2023 (UTC)

Do you have examples of articles without images where understandability would be improved by an AI's artistic interpretation of a prompt relating to the article content? What's the copyright status of images created by these AI tools? I'm a little concerned about AI art proliferating outwards from here and misleading people in search results where it's not clearly attributed as AI art. Folly Mox (talk) 02:06, 4 July 2023 (UTC)
  • 1) I am thinking of all the fringe and bland-er low traffic core topics that we have across the project. Many of them are pretty straightforward conceptually from the opening paragraph.
  • 2) The copyright status is public domain for these images with all the major providers.
  • 3) Such an addon might automatically disclaim with a licensing template that it is AI generated.
  • 4) The quality of depiction is sufficient (on at least two services) to depict almost any non-technical topic at a level of comprehension and visual quality that far exceeds the ability of most artists, and I say this as someone who has professionally created graphics for profit. But a user could be prompted to ensure, and confirm as a human, that the image adequately and correctly represents a reading and interpretation of the article's content in a way that they understand.
Keep in mind that this could be an advanced feature that is enabled in a user's profile, not enabled by default. Most users who reach that point should recognize some level of content integrity.  — C M B J   20:13, 5 July 2023 (UTC)
We've already established that AI -generated art is not appropriate on WP, outside of cases where it is being used to illustrate articles about the use of AI art. Too much of a copyright issue involved there. Masem (t) 02:35, 4 July 2023 (UTC)
The question is how do you determine if a picture is AI-generated or not. Anyone could claim a picture is "self-created" while it is not. ✠ SunDawn ✠ (contact) 04:08, 4 July 2023 (UTC)
I see the point. Loads of maths articles would be much more understandable if there were carefully-thought-out visual diagrams illustrating the underlying idea. But creating diagrams like that is really difficult. It requires a good understanding of the maths, and also a good understanding of human nature. There will be other examples; lots of signal-transduction pathways in biology are most easily understood if presented in graphical form. But at the moment, I'm utterly convinced that AI will get more wrong than it gets right. There is nothing wrong with someone experimenting with creating such images, but if we had a tool to create them and accept them in one-click, then I'm afraid we'll end up with a lot of enthusiastic one-clickers adding all sorts of nonsense diagrams. It's better not to encourage this, because those who are capable of creating a good AI-image, and capable of vetting it and understanding what tweaks their creation needs, will do the work anyway, without a tool. Those who need the tool will produce rubbish. Elemimele (talk) 09:11, 4 July 2023 (UTC)

Merging templates

Merging of Template Wikisource and WikisourceLang

We can have a third parameter in Wikisource template for entering the name of language. We don't need Wikisourcelang template as a third parameter to Wikisource template does the same.

Instead of writing 

{{Wikisourcelang|hi|T}}

We can write 

{{Wikisource|T||hi}}

And get same results

Hindi Wikisource has original text related to this article:
T

If third parameter not entered, it will automatically select English.

Prinaki (talk) 10:13, 2 July 2023 (UTC)

@Prinaki make a suggestion at Template talk:Wikisourcelang and Template talk:Wikisource. I can imagine one template using the other as a wrapper, to preserve backward compatibility ~ 🦝 Shushugah (he/him • talk) 19:07, 4 July 2023 (UTC)
Prinaki, Primefac opened a discussion to merge those two and more: Wikipedia:Templates for discussion/Log/2023 July 5#Template:Wikisource author. SWinxy (talk) 14:33, 7 July 2023 (UTC)

Page blocks for editors subject to editing restrictions

I've been considering a proposal like this for a while, originally prompted by Lugnuts violating his topic ban on cosmetic edits by edit warring with an editor trying to correct lint errors. At the time the violations went without response, because the editor they were edit warring with was not aware of the restrictions and our current system of enforcement is based on editors who are aware of restrictions noticing them.

I consider this flawed, and to correct this I propose that any editor who is subject to an editing restriction is page blocked from WP:Editing restrictions, with a brief description of what their edit restrictions are. This will allow editors with the option "Strike out usernames that have been blocked" selected to see a dashed line underneath the editors name, and thus increase awareness of any restrictions and prevent violations like the one we saw with Lugnuts.

The exception would be editors who are only subject to interaction bans, as it is impossible to violate those restrictions without at least one editor who is aware of the restriction being present.

If there was a consensus for this then going forward it would be done every time a new topic ban is added to the list; retroactively, I would suggest only doing it for active editors, as doing it for inactive ones could result in them being reminded of their restrictions via an email notification which I would consider unnecessary and harsh. BilledMammal (talk) 05:22, 2 July 2023 (UTC)

Wouldn't at some point they be found out to have violated their editing restrictions? It's a smart suggestion though. This would maybe improve detection, deterrence, and speed of discovery. SWinxy (talk) 14:41, 7 July 2023 (UTC)
Depends on the restriction, I think, and how easy it is to determine if a violation has occurred. The cosmetic error restriction, for example, would only be caught if someone was looking careful through their contribution history - I know that Lugnut's did escape detection for most of his violations, and would have escaped detection for the lint error one if the topic of his signature causing lint errors hadn't come up during the ARBCOM case. BilledMammal (talk) 04:47, 12 July 2023 (UTC)

Discussion on consensus at ITN

I've made a post at ITN regarding the development of consensus there and thought that folks here might be interested. voorts (talk/contributions) 13:24, 14 July 2023 (UTC)

"Current leader" templates

Just had an idea: what if there were templates for some "current leaders". For example, Joe Biden's name could be summoned from a {{Current president of the United States}} and then whenever he is succeeded, that template could just be updated to the new president, rather than having to change the US president's name across WP articles. Any thoughts?

Was just looking at the Order of the British Empire#Current Knights and Dames Grand Cross where it says "Sovereign: King Charles III"—presumably in need of an update when Charles is succeeded (but not if a template is used).

I see that {{Current president of Slovenia}} already exists. Aza24 (talk) 15:47, 13 July 2023 (UTC)

See {{Monarch of New Zealand, current}}.-gadfium 20:58, 13 July 2023 (UTC)
This sounds like a good idea. However, the flip side of being able to update multiple articles like that is that vandals can disrupt multiple articles then. Oh well, there is page protection. Edward-Woodrow :) [talk] 12:56, 16 July 2023 (UTC)

question re policy for BLP items

opening section

I have a question about usage of WP:BLP. we currently have articles on two minors below the age of ten, highlighting their royal status as members of a royal family. these two individuals have had absolutely no voice in whether these articles should be established or not. their parents have publicly distanced themselves from the referenced royal family.

I am wondering if BLP can be used to preserve the privacy of individuals who have not reached adulthood, and hopefully please remove the articles until they reach adulthood. I am sincerely trying to consider the long-term well-being of these two minors. eventually they will presumably gain access to the Internet, once they are old enough to do so. furthermore, they do not currently reside in the country where they would have royal status.

I don't feel that wikipedia should be increasing these minors' public visiblity, before they've had a chance to decide what public role they wish to have, if any. can anything be done to help with this situation? I'm truly open to any ideas. I recognize that our policy may or may not apply. thanks. --Sm8900 (talk) 19:56, 21 June 2023 (UTC)

You might try asking on WP:BLPN too. You are very vague about the details, so it's hard to tell, but for instance your description applies to the children of Prince Harry, Duke of Sussex. In that case, they are for better or worse subjects of intense media attention, and they are naturally going to be the subject of editors' interest; I can't think of any policy-based reason that we shouldn't have an article on them (which isn't to take a position on whether we morally should, just to say that current BLP policy allows it!), and I don't know that without a strong policy based reason you would be able to find consensus to delete or even merge these articles. There is an essay, WP:MINORS, which basically says "be even more careful editing about living children than even other living subjects", but even that doesn't suggest that we shouldn't have articles on notable minors. Caeciliusinhorto-public (talk) 12:06, 22 June 2023 (UTC)
There's also WP:BLPREQUESTDELETE which says that if a relatively unknown person requests deletion of their article, a no-consensus discussion can be closed as delete; even if we took that to include parents requesting deletion on behalf of their minor children I don't know whether e.g. Harry & Meghan's kids would count as "relatively unknown"... Caeciliusinhorto-public (talk) 12:08, 22 June 2023 (UTC)
@Caeciliusinhorto-public ok. let's expand the usage of "relatively unknown." because in fact no one knows these kids. in any way. they have made no public statements. even their own grandfathers don't know them! and one of those grandfathers is the basis for any supposed royal status! their utter absence of any public role, actions or statements, does in fact extend this protection to them. Sm8900 (talk) 14:27, 22 June 2023 (UTC)
  • I don’t think there is a “one size fits all” rule for this. In the case of children of royalty, I would say that (as a minimum) they should be discussed in the article about their Royal parent… but whether and when they would deserve a separate article is a more difficult question. Blueboar (talk) 12:24, 22 June 2023 (UTC)
the points above from all of you are all notable. however, for me the problem is that these kids literally haven't done anything at all in any public role at all... except, ya know, be born, and live in Montecito. shouldn't there be some way to take down an article on a minor, if it is based on a public role that they do not and probably will not ever actually assume in any practical way?
In other words, the minute that one of them actually makes any public statement, or takes any action, or even visits their supposed home country for literally the first time, (other than as infants), then maybe we could consider if any article is warranted or justified. --Sm8900 (talk) 14:05, 22 June 2023 (UTC)
Well, you are welcome to nominate the articles for deletion at WP:AFD, but I suspect the consensus will be to keep. People do tend to think Royals are notable just for existing, and there are sources that have discussed them. Your best arguments would probably be “privacy of a minor”, and “merge” into article on parents. Good luck. Blueboar (talk) 14:21, 22 June 2023 (UTC)
thanks @Blueboar! in 10 or 15 years, the press coverage may have melted away. these kids may be trying to get on with their own normal adolescent lives. meanwhile, do we really need an entire wikipedia article on them? what happens when they try to go to their first house party in montecito, and just want to chill with their preteen friends? haven't we all been there at some point in our lives? do we really have any basis or reason to put this albatross of an article onto them? your reply above is helpful. Sm8900 (talk) 14:25, 22 June 2023 (UTC)
I’m not the one you have to convince. Blueboar (talk) 17:45, 22 June 2023 (UTC)
true enough. and by the way, I was serious when I said your comment is truly helpful. Just wanted to clarify that so noone will misconstrue my meaning, or think I was being ironic in any way. thanks, @Blueboar. Sm8900 (talk) 14:09, 23 June 2023 (UTC)

Section break for comments

  • This is an area where I am definitely in disagreement with current Wikipedia policy. Current policy makes no distinction according to the age of anyone mentioned on Wikipedia. It should. I don't have the time to undertake the process for such a change myself, but I would certainly support any reasonable proposal made in that direction. Phil Bridger (talk) 17:50, 22 June 2023 (UTC)
    that's an excellent point. i may formulate something, and then post it on the tab for policy here at village pump, Sm8900 (talk) 02:28, 23 June 2023 (UTC)
    how this?
    proposed text:
    I would like to propose a new rule to be added to BLP; the proposed rule is that any minors who have made no public actions and have done nothing notable on their own, should not have any article created about them based on the public role of their parents.
    does that make sense, @Phil Bridger? what else can or should be added, to fully address this? Sm8900 (talk) 02:55, 23 June 2023 (UTC)
    This whole thing is smacking of WP:GREATWRONGS. It’s not our problem what the media choses to cover, and we can’t arbitrarily kill notable articles because we think their existence morally objectionable. What about Abu Ghraib torture and prisoner abuse? I don’t think the victims approved of the “coverage” they received, but we can’t, and shouldn’t, delete that article because of that. Dronebogus (talk) 13:12, 23 June 2023 (UTC)
    @Dronebogus, thanks for your point, but I see this differently. this is an unnecessary intrusion into the private lives of two young people, who have done absolutely nothing to warrant any such intrusion. and, just to posit one possible but purely specualtive scenario, the first time that one of those kids has to see that article printed out and taped to their school locker, the burden of guilt will fall upon our entire community here at wikipedia. these are just two innocent children growing up in montecito, who just want to have a nice life. I would like to allow them to do so. we are talking about an innocent child's future here, two of them.
covering current public issues is one thing. but these two children's titles are nothing but a miniscule fraction of a footnote to an obscure molehill lost in the mists of history. it's likely these entries will be deleted in a few decades, but only after some degree of discomfort to the two individuals. I would like to spare these decent youngsters any discomfort whatsoever. we can include their titles in the entries for their parents. that is fully sufficient to cover any supposed encyclopedic relevance for these titles. If I can help a young person to have a better chance to live their life in peace, I'd be glad to take any steps available.
by the way let me just say I do truly appreciate your taking the time to reply and to discuss this. we disagree somewhat, but I do appreciate your input. thanks. Sm8900 (talk) 14:02, 23 June 2023 (UTC)
Saying they’ll probably be deleted in 20+ years is WP:CRYSTAL. In fact literally everything here is basically WP:CRYSTAL with a side of appealing to guilt. Dronebogus (talk) 17:52, 23 June 2023 (UTC)
there's no basis for applying rules and policies to a good-faith post at the Idea Lab; doing so might in fact be a case of Wikipedia:JUSTDONTLIKEIT. Sm8900 (talk) 18:23, 23 June 2023 (UTC)
Um… no, rules and policies should be considered when developing new ones. Idea lab isn’t for back-slapping and thumbs-upping. Dronebogus (talk) 18:26, 23 June 2023 (UTC)
Idea lab is for positive collaborative brainstorming. it is fine to disagree and express differing views, but any debate should be based on the content of the ideas themselves. if someone is offering a proposal for a new idea, or a new item or a new approach, et cetera, then of course it runs somewhat outside of existing policies or existing established procedures, to some degree; if it did not, then there would not be a need to present it at idea lab for discussion, would there? Sm8900 (talk) 21:02, 23 June 2023 (UTC)
@Dronebogus, that principle was rejected very many years ago, when we developed the WP:BLP policy. Phil Bridger (talk) 21:58, 23 June 2023 (UTC)
What principle? I’m confused which comment you’re replying to Dronebogus (talk) 22:41, 23 June 2023 (UTC)
The principle that "it’s not our problem what the media choses to cover, and we can’t arbitrarily kill notable articles because we think their existence morally objectionable". I think I got the indentation right, but I apologise if it was not. Phil Bridger (talk) 20:32, 24 June 2023 (UTC)
I did not know that. What is the principle we’re working with here? Dronebogus (talk) 22:43, 24 June 2023 (UTC)
the principle is "we have the prerogative as a community to delete or remove notable articles, because we think their impact on affected individuals is highly detrimental and unethical." the underlying context for this is that this principle already exists to some degree within WP:BLP, in some form. Sm8900 (talk) 13:32, 26 June 2023 (UTC)
@Phil Bridger, I would suggest the word " greatly unethical" as perhaps more accurate than "morally objectionable." Sm8900 (talk) 13:34, 26 June 2023 (UTC)
I agree that there should be stricter criteria for BLPs of minors; not sure of the right criteria yet, have to think on it. Should be something that establishes why we have a stand-alone BLP for Blue Ivy Carter but not North West. Schazjmd (talk) 14:31, 23 June 2023 (UTC)
Has North West won a grammy? Blue Ivy has won an individual grammy, which clearly makes her independently notable. Dronebogus (talk) 17:54, 23 June 2023 (UTC)
I didn't question her notability or disagree with her having a stand-alone article. However, there's lots of media coverage of North, but we don't have an article on her (which, again, I agree with). I was saying that I think we should come up with minor-BLP criteria that supports having an article on Blue Ivy and not on North West, that it's not just about the two royal children. Schazjmd (talk) 18:00, 23 June 2023 (UTC)
  • Personally I would support much stronger protections for BLPs of minors (and minor-BLP content in other articles), even something far more drastic than suggested so far, such as requiring prior community approval on BLPN for article creation. (I am assuming, perhaps incorrectly, that just excluding such content entirely would be a non-starter.) The potential harm to the subject should weigh pretty heavily against the generally extremely minimal benefit to the project and its users. I have no great ideas about policy wording, but the WP:BLPMINOR essay might be worth a look. It might also be worth considering carefully borrowing concepts from privacy law, as WP:BLP already does in places. -- Visviva (talk) 19:30, 1 July 2023 (UTC)
    @Visviva I agree with all of your points entirely. i will look over the articles you suggest later today. i will come up wth some proposed wording, and will suggest it here. Sm8900 (talk) 14:13, 6 July 2023 (UTC)
    would you like to suggets some dieas for a possible policy, @Visviva? thanks. Sm8900 (talk) 17:07, 14 July 2023 (UTC)
    I don't have any great ideas, but for the sake of discussion, if I were going to improvise a nutshell guideline right now, I might try something like this:
    Wikipedia has a strong presumption against including personal information about identifiable living minors (individuals under the age of 18). This presumption applies not only when the minor is the subject of an article, but also when they are being discussed in connection with some other topic. Overcoming that presumption requires showing that the information (1) is publicly available from multiple independent reliable sources, and (2) is necessary for our encyclopedic purpose. In particular, in article space, information about an identifiable living minor that is not supported by an in-line citation to an independent reliable source should be removed immediately and without discussion, even if it is not controversial or likely to be challenged.
    Writing that, it occurs to me that the fair use guideline might provide some food for thought -- an analogous situation in which we allow problematic content but only to the extent necessary to achieve our encyclopedic goals. -- Visviva (talk) 17:42, 14 July 2023 (UTC)
    @Visviva, that draft sounds pretty good to me. I'm going to take some time, and give this some thought, and then perhaps I will move ahead with some version of this. your ideas and comments are always welcome. thanks. Sm8900 (talk) 17:04, 17 July 2023 (UTC)

Rename Wikipedia namespace to Project namespace

I see many users, myself included get confused by the Wikipedia namespace, which contrary to the name, does not mean you're publishing on Wikipedia in the typical sense. I was looking at Wikidata, where their project level discussions are held at d:Wikidata, which made me wonder why don't we have a unified namespace for projects of all Wikimedia projects, e.g. P:Village Pump (idea lab), d:P:Village Pump (idea lab) would be me symmetric, and not repeating itself, because the url already contains prefix to specific Wikimedia project.

There are technical reasons/long conventions to keep existing namespaces, so this is an open starting conversation. WikiProjects are another confusing name, from Wikipedia namespace, but that"s for another idea thread. ~ 🦝 Shushugah (he/him • talk) 18:59, 4 July 2023 (UTC)

The namespace is already called Project, in the sense that Project:Example is a valid link to Wikipedia:Example, but we rarely use that prefix. Certes (talk) 20:23, 4 July 2023 (UTC)
This seems like a huge change for a relatively small reward, especially with the millions of links that currently point to the "Wikipedia:" namespace. But if I woke up one morning and Wikipedia: had been replaced by Project: across the board, I wouldn't mind. Thebiguglyalien (talk) 21:32, 4 July 2023 (UTC)
  • Support, unequivocally, as proposed. I would have proposed this myself long ago if I didn't think there would be a reactionary opposition. I would still keep core policies at Wikipedia: titles, but would move everything relating to support of article construction to a Project: namespace. BD2412 T 21:37, 4 July 2023 (UTC)
    We wouldn't need to move anything: it's already there. We would just need to refer to it as, for example, Project:VPT rather than Wikipedia:VPT (still a major change), and probably unset $wgMetaNamespace back to its default value. Oh, and add [ 'Wikipedia' => NS_PROJECT ] to $wgNamespaceAliases, if it's not already there, and repeat for the talk namespace. Certes (talk) 22:34, 4 July 2023 (UTC)
  • Oppose: I think it's just too late for such a major change. Wikipedia's over 20 years old; it's a major change to a lot of links. Would it have been better had it been that? Perhaps. But I'm not sure that "Project" is even all that much clearer. Adam Cuerden (talk)Has about 8.5% of all FPs. 21:54, 4 July 2023 (UTC)
    When an article is draft namespace and you want to publish it, the Wikipedia namespace seems right and editors say to publish on Wikipedia or main space by which they mean article space, yet they don’t mean it that way and so on. I was pleasantly surprised to learn Project alias already exists though. ~ 🦝 Shushugah (he/him • talk) 22:54, 4 July 2023 (UTC)
    The very first namespace available about where you would publish your article is literally labeled (Article). If somehow that is still confusing, more help text could be added in MediaWiki:movepage-summary. — xaosflux Talk 02:47, 5 July 2023 (UTC)
  • This seems problematic - to start with, Shushugah what are you trying to say about Wikidata? Their "project" namespace is called "wikidata" (e.g. see d:Wikidata:Administrators' noticeboard), our project namespace is called "wikipedia". In both cases these are namespaces that house things related to what they are called - "Template" houses templates, "wikipedia" houses meta-things about Wikipedia, etc. — xaosflux Talk 02:44, 5 July 2023 (UTC)
    The Template, File namespaces make sense, but stuff like Draft or Wikipedia are rather confusing, and on top of it, Article namespace, does NOT have an article prefix, so confusingly when someones tries to find the right namespace to publish on, Wikipedia seemingly appears to be the right one. ~ 🦝 Shushugah (he/him • talk) 07:49, 5 July 2023 (UTC)
    I think article mainspace lacking any prefix is the most natural approach, matching the URL structure of typical web sites. Given that people generally will first experience Wikipedia by reading an article, they will have exposure to this URL format beforehand. "Draft:" seems intuitive to me. isaacl (talk) 16:08, 5 July 2023 (UTC)
    Do people actually have this problem? If you're moving an article to mainspace, you have enough edits to have come across the project namespace at least once. If not, moving a page makes you select a namespace. (article) vs. all the other ones should be abundantly clear what that means. SWinxy (talk) 14:28, 7 July 2023 (UTC)
    Any "Confirmed" has the ability to move pages, which only requires 4 days and 10 edits. So, not everyone is likely to know about project space. I've even come across editors with more than 200 edits do this mistake. —CX Zoom[he/him] (let's talk • {C•X}) 14:58, 7 July 2023 (UTC)
  • Oppose solution in search of a problem. Headbomb {t · c · p · b} 17:37, 5 July 2023 (UTC)
  • My comment, since this is the idea lab: If it ain't broke, don't fix it. I don't see a sufficient reason to make the change, and I don't think that there's a way to workshop this to make the proposal any different in a way that would improve acceptability (it's a binary choice). — Red-tailed hawk (nest) 17:47, 5 July 2023 (UTC)
  • Reminder to everyone that this is the Idea Lab, not a place to support/oppose proposals... -- Tamzin[cetacean needed] (she|they|xe) 20:24, 5 July 2023 (UTC)
Yes, people sometimes move pages to the Wikipedia namespace when they intend to move to mainspace. Renaming the Wikipedia namespace could help with that. But so could redesigning the move dialog. In the Dark Ages, it didn't have the namespace drop down. The good thing was that people rarely moved articles into Wikipedia space. The bad thing was that lots of pages that were supposed to be in other namespaces ended up as typos in mainspace, like Wikiepdia:ANI or similar.
Would some sort of warning when people attempt to move drafts to the Wikipedia namespace do the trick? —Kusma (talk) 20:45, 5 July 2023 (UTC)
I like this idea, I also like idea of perhaps calling it Project namespace purely within move dialogue. Very few people move/use the Wikipedia/Project namespace, whereas this would be a net win to the larger number of new users who want to move to Article namespace. And that would be minimal change for remaining users/rest of website. ~ 🦝 Shushugah (he/him • talk) 15:56, 6 July 2023 (UTC)
Interesting idea. Perhaps the Wikipedia: namespace could be referred to within the page move interface and in the page creation interface (where a warning could pop up too) as Wikipedia (Project) Edward-Woodrow :) [talk] 13:12, 12 July 2023 (UTC)
  • Nice idea, in fact "Project" is the default namespace in MediaWiki software. "Wikipedia" is a localised namespace which equates to what is otherwise "Project" namespace. I would strongly support this idea due to a number of issues it causes already cited above (Shushugah, Kusma), provided that "Wikipedia", "WP", "Wikipedia talk", "WT" are retained as aliases to avoid breaking of millions of incoming links on and off-Wikipedia. —CX Zoom[he/him] (let's talk • {C•X}) 21:30, 5 July 2023 (UTC)
Part of this might be a UI thing too. The dropdown (in desktop mode) may indeed have (Article) as the very first option, but on mobile you're presented with a modal centred on the page's current namespace, and if you scroll up (from Draft, most likely), you encounter Wikipedia before reaching (Article), tucked away at the very top. Folly Mox (talk) 21:37, 5 July 2023 (UTC)
I went to the move page of a draft article, and on desktop too, it defaults to Draft namespace, and I have to scroll upwards and I reach Wikipedia before I reach (Article). These are ordered by WP:NAMESPACE numbers btw. —CX Zoom[he/him] (let's talk • {C•X}) 21:48, 5 July 2023 (UTC)
We really should improve the move dialog. —Kusma (talk) 21:57, 5 July 2023 (UTC)
Maybe if we had a three-option dropdown first, with the options {"rename in same namespace","publish in main article space","move to another namespace"}, with the first two setting the destination namespace and the third one bringing up the current menu? It feels a bit jank, but covers the two commonest use cases before any confusion can occur (unless people don't understand my terrible menu option copy and no one improves it). Folly Mox (talk) 22:19, 5 July 2023 (UTC)
I don't imagine it would be too hard to put the current NS at the top of the list on mobile... but that only partly addresses the problem, since the NS ordering is, as you say, dictated by NS numbers (most of which just reflect the order in which the NSes were added), while the average user's likelihood of needing to cross-namespace move to a given NS probably goes, roughly, (article) > Draft > User > Template > everything else. Which are NSes 0, 118, 2, and 10 respectively. -- Tamzin[cetacean needed] (she|they|xe) 22:00, 5 July 2023 (UTC)
  • Oppose Might have been a goosd idea in 2003, but now it's too late. The proposed name is not all that clear either. Johnbod (talk) 16:04, 7 July 2023 (UTC)
    Why should the time matter? If change is necessary, it should be made. It's not too late. Edward-Woodrow :) [talk] 22:00, 20 July 2023 (UTC)
  • Sounds good to me. I guess Wikipedia would remain an alias, like how Project:Namespace currently works. So there'd be no functional difference, all existing links would still work, and anyone who doesn't like the change could continue to use Wikipedia: or WP: in the links they type out. Brightgalrs (/braɪtˈɡæl.ərˌɛs/)[ᴛ] 02:57, 10 July 2023 (UTC)
  • This is a pretty solid idea really just because we already call it "projectspace". As noted above, this is simple enough to do technically. I think the main hurdle (aside from getting people to buy in) is that people will inevitably want P:<whatever> shortcuts, but that is already used by Portal. Legoktm (talk) 03:56, 10 July 2023 (UTC)
    PT:? PJ:? Edward-Woodrow :) [talk] 13:13, 12 July 2023 (UTC)
    WP: for "Wikipedia Project", since we're used to that? Certes (talk) 14:15, 12 July 2023 (UTC)
Oppose would just confuse long-term users (or even just established users like me) who think it means WikiProject. Dronebogus (talk) 21:42, 17 July 2023 (UTC)
  • Oppose, at the risk of being "reactionary", if it ain't broke, don't mess with it. The occasional accidental move to the WP: namespace that was intended for mainspace is fixed easily enough, and realistically anyone who does that probably doesn't have sufficient experience to be directly creating mainspace articles anyway. This would be a large-scale change, and I see no reason to believe there is a correspondingly serious problem that would be addressed by it. Seraphimblade Talk to me 22:09, 17 July 2023 (UTC)
  • The "project" namespace on every project is named for the type of project. Thus, all Wikipedias have a Wikipedia namespace (in their local language), all Wikisources have a Wikisource namespace, all Wikivoyages have a Wikivoyage namespace. Meta has the Meta namespace. Commons has the Commons namespace. I can't see the value in renaming the "project" namespace on a single project. At the same time, I can't see the value of renaming that namespace so it is the same on every single project. As best I can tell, there isn't a single project (after having randomly sampled about 75 in different languages) that does not follow this pattern. Risker (talk) 02:58, 18 July 2023 (UTC)

See the proposal

See Wikipedia:Village_pump_(proposals)#Improve move page dialogue

WP:STUB and images in stub templates: de facto versus de jure

WP:STUB, an official guideline, states that:

Adding a small image to the stub template (the "stub icon") is generally discouraged because it increases the strain on the Wikipedia servers but may be used, so long as the image must be public domain or have a free license—fair use images must not be used in templates. Stub icons should be small, preferably no more than about 40px in size.

For something "generally discouraged", stub icons are awfully widespread. Some templates even have two! De facto, practically all stub templates have them. De jure, they probably shouldn't. I have two questions: a) does anything need to be done, or is it not really a problem, and b), if this is a problem, should the stub templates be amended to conform with the guideline, or should the guideline be amended to conform with reality? Edward-Woodrow :) [talk] 13:08, 12 July 2023 (UTC)

@Edward-Woodrow Looking back through the histories, I think we can call this one "definitely overtaken by events". It sounds like there was a technical issue with this in 2005/6, when serving images in general was suggested as being a major strain on the servers - this may actually not have been as much of an issue as it was interpreted as being, but people did get worried about it for a while. WP:STUB got heavily redrafted a little while later, & this mention got put in.
And so it has stayed ever since, possibly without anyone really noticing. Since then the discussion on stub images seems to have been stylistic, not "should we have them at all", and as you say it's a de facto standard to include them. I think you'd probably be safe to update this, but commenting on the guideline talkpage first might not be a bad idea. Andrew Gray (talk) 17:21, 12 July 2023 (UTC)
This is pretty much what I was thinking. I'll go ahead and comment on the talk page. Edward-Woodrow :) [talk] 19:30, 12 July 2023 (UTC)
These days that is fairly clearly in the WP:Don't worry about performance territory. Those images are relatively tiny compared to most of the images our CDN deals with. Taavi (talk!) 18:19, 12 July 2023 (UTC)
  • I just went ahead and removed that text, along with the stuff about shoeing the horses, chopping the firewood, and so on. EEng 23:10, 20 July 2023 (UTC)

New sub-sysop user groups

Currently, there are three user rights that sysops automatically get- new page patroller, pending changes reviewer, and rollbacker. I call these "sub-sysop groups". Is there any community support for creating more of these sub-sysop user groups- I was thinking maybe "Page protector" and "Full-Protection editor". These could help respond more quickly, as there is a limited number of sysops. For "Page protector" I was thinking they would only be allowed to protect at pending-changes and semi-protected levels. Edward-Woodrow :) [talk] 22:29, 20 July 2023 (UTC)

Start here: Wikipedia:Perennial_proposals#Hierarchical_structures. -- zzuuzz (talk) 22:40, 20 July 2023 (UTC)
Well, that makes sense. Thanks. Edward-Woodrow :) [talk] 22:47, 20 July 2023 (UTC)
@Edward-Woodrow There have been proposals in the last four years or so that have pursued this at several routes (despite a full awareness of the perennial aspect). Two have "nearly" succeeded (that is, perhaps 40% of the !votes), one to allow a very limited page protection (time-limited, SP-only, automatic review) and one a vandalism-blocking equivalent - both designed to alleviate the issues of when we have few admins online. A trawl through the various village pumps should find them, although there have been comparable but less successful proposals.
As to the full-protection editor, in the "actual editor" status (that is, editing a fully-protected article), such a thing doesn't have much need. Articles only hold that status briefly, and editing during them is limited to edits that have consensus on the talk page. That is, an admin can't make a regular edit for themselves through full-protection. This requires very few admins to handle, so a sub-sysop version wouldn't change much.
It is possible that a version with rule-restrictions (that is, non-technical limitations) that were designed to alleviate issues with cascade protection could find success. I've not seen such a proposal, but it's a more possibly open area for discussion. Nosebagbear (talk) 20:30, 21 July 2023 (UTC)

Notifying when sources are at WP:RSN

When a template is up for deletion, a message appears inline of every usage notifying interested parties of the ongoing discussion. When a source is up for deletion at RSN, no one knows about it, except those who follow RSN. As a result when sources get deleted/blacklisted many people are taken unaware. The effective result is a small number of people at RSN wield a lot of influence over what is permissible to cite, which has impacts on AfD outcomes (what is a reliable source), and the content articles contain. It's sort of a key control lever for the entire project.

This doesn't mean every RSN thread requires notifications. And it might also include the WP:SBL.

Any ideas how we might better notify the community when a source is being discussed for sanction? -- GreenC 16:34, 9 July 2023 (UTC)

Require that sources with broad usage are listed at WP:CENT and linked from WP:VPP? BilledMammal (talk) 16:36, 9 July 2023 (UTC)
Is there a problem that needs solving here? When I'm reviewing DYK submissions, I look up sources in RSN all the time. I can't remember the last time I looked at a discussion and thought, "What are those idiots at RSN doing? How could they possibly think this is/is not reliable?" So, is there something broken that needs fixing? RoySmith (talk) 16:38, 9 July 2023 (UTC)
I think a perfect example was Who's Who. There was some editors who work in bios that didn't know that it had been downgraded.Davidstewartharvey (talk) 17:33, 9 July 2023 (UTC)
Oh, I misunderstood the issue here. I was thinking about ensuring more input to the conversations at RSN to make sure they didn't make stupid decisions. You're talking about disseminating the decisions after they've been made so the community knows about them. RoySmith (talk) 17:57, 9 July 2023 (UTC)
No, I think you understand the main issue perfectly well, but it does roll over into people not knowing what has happened at WP:RSN. Phil Bridger (talk) 19:16, 9 July 2023 (UTC)
The problem with that particular example is that there are several unrelated publications in the English-speaking world with "Who's Who" in their title. Which are you talking about? Phil Bridger (talk) 19:21, 9 July 2023 (UTC)
As someone who does keep an eye on RSN, the last Who's who to come up there was Who's Who in Ghana, which looked generally reliable. I take most of what happens there as advice rather than scripture, other than full RFCs of course. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:25, 9 July 2023 (UTC)
I can't remember the last time I looked at a discussion and thought, "What are those idiots at RSN doing? How could they possibly think this is/is not reliable?" My usual example for this is Sixth Tone, one of the most solidly reliable Anglophone sources for Chinese culture (not politics), which had a discussion between six people overwhelmingly about politics that RS/PS interpreted as "politically unreliable, apolitically ???", that source highlighter scripts interpreted as "red don't use". In general, extreme focus on political applications over the other 99% of use cases is a tricky problem for sourcing discussions. Vaticidalprophet 01:11, 10 July 2023 (UTC)
The discussion says it's reliable for things other than politics, which matches your assessment. The source highlighter script is something created by a separate user. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:59, 10 July 2023 (UTC)
The discussion was formally closed as "no consensus" for things other than politics, because almost none of the conversation was about things other than politics, meaning it's officially considered about as reliable (sic) as Business Insider. Source highlighters are one of the main ways people interact with RS/PS, and particularly so at content assessment processes (GAN/FAC), so they're relevant to discussions of how RSN and RS/PS permeate into the community. Vaticidalprophet 14:40, 11 July 2023 (UTC)
The close says Specifically not reliable for political information and probably reliable for non-political cultural and social information. I wouldn't read that as no consensus, as no source is said to be absolutely reliable, but rather that there is concenus that the source is probably reliable for non-political information. My point on the source highlighter is that it's a script maintained by an editors not RSN, how it uses the discussions at RSN isn't controlled by RSN. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:02, 11 July 2023 (UTC)
Unfortunately Eggishorn hasn't been active since April last year, so it's not possible to ask them how the close should be read, but reading the actual discussion I can't see any reason the close would be against its use for non-political details. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:08, 11 July 2023 (UTC)
I think that Vaticidalprophet is correct that "Source highlighters are one of the main ways people interact with RS/PS". Some editors who use those scripts have a really high level of trust in them and no understanding of (or even any apparent interest in) the nuances. For some of them, their goal seems to be "nothing flagged by the script" rather than "appropriate sources are used appropriately in this article". That leads to things like editors removing Daily Mail sources for sentences that simply say "The Daily Mail published this", or Chinese state media for a statement about a Chinese official's job title. WhatamIdoing (talk) 19:14, 23 July 2023 (UTC)
Absolutely agree that some editors misuse source highlighter, but it is not maintained by RSN and RSN has no way of controlling how it interprets RSN discussions. It's the same with all scripts, for instance the endash scripts are regularly misused to incorrectly change refnames, template parameters, titles or quotes but MOS has no way of stopping such misuse. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:28, 23 July 2023 (UTC)
Some of the sources we discuss at RSN don't have articles that we could notify, as a source can be reliable without it meeting GNG. There's also more than a few sources whose article consists of a redirect to their parent company. So a pure talk page notification approach wouldn't cover all bases. You could maybe make a feed for interested WikiProjects to subscribe to, though without filtering it based on some sort of interest tagging you'd likely just be repeating the RSN table of contents.
For the sources that do have articles however, we could maybe create a template that can be added to a discussion based on editor discretion, that a bot then picks up on and notifies the relevant articles. You'd just have to make sure it's properly parametrised for sources where the article name doesn't 1-to-1 match the source's name for disambiguation reasons. Sideswipe9th (talk) 15:13, 11 July 2023 (UTC)
I think the proposal is closer to "If someone challenges The New England Journal of Medicine, then notify Medicine, Cancer, Haemophilia, Lead, Recreational drug use, Vaccination, Infant mortality, etc.", rather than "post at note at Talk:The New England Journal of Medicine". WhatamIdoing (talk) 19:18, 23 July 2023 (UTC)

Setting bounds on mass-creation RFCs

In the currently running RfC on Lugnuts-created cricket stubs, some editors have expressed opposition to the proposal for mass draftification on the grounds that this will create a precedent for future mass removal of articles without individual scrutiny at AfD, an implicit alternation of our deletion practices that lacks explicit support from the community. Others have rejoined that as these RfCs only apply to articles that were mass created, this process is inherently limited and does not create a future precedent for deletion. (Others have commented suggesting that they do see this as a community-established process for deletion at scale: [10].)

Unfortunately, the recent RfC on mass creation demonstrated that there is no community consensus on what constitutes "mass creation", so that doesn't clarify the situation nearly as much as one might hope.

I think some of this activity is justifiable as an invocation of WP:IAR: as with, say, the Neelix redirects, some of these problems, particularly the Lugnuts stubs, are of a scope that overwhelms the workflow created by our policies. However, the burden of proof for applying IAR is high. Consensus-seeking about individual cases, whether in the form of AfD or a draftification RfC, does not allow us to overthrow policies through defeat in detail. Mass draftification, listification, etc. should be limited not just to "mass creation", whatever that means, but to cases where following established deletion policy would be not just tedious but absolutely unworkable. Cases that egregious should be identifiable now and are indeed well-known (the Lugnuts stubs and the Carlossuarez Iranian villages are the ones that come immediately to my mind, and I think there are a few others). However, crafting the individual mass-removal RfCs for each case is a delicate, arduous, and time-consuming process, and one can't expect all of them to happen immediately.

What I would propose to make the limits of the mass-removal RfCs more concrete is that the community ratify a list of their maximum possible scope. A reasonable deadline should be given for editors to identify instances of mass creation like the two of them above. The community will then be asked to decide, for each instance, whether dealing with the mass creations out-of-process is justified. If that is the case, a mass-removal RfC can be crafted at a later date dealing with the precise scope of articles in that creation to be dealt with and how they are to be disposed. Of course, a particular instance could be dealt with entirely within-process and never warrant a mass-removal RfC.

A moratorium of several years would be imposed on mass-removal RfCs for topics not identified (being either insufficiently egregious to warrant IAR mass-removal) or which failed community ratification. I think that is a reasonable timescale consistent with how long it's taken the community to deal with the current batch of problematic mass creations, and that we are vigilant enough that no one will be able to build up a new backlog on that scale.

Defining the scope of these RfCs would have two advantages:

  1. Editors opining on the mass-removal RfCs would be able to concentrate on the specifics of the individual case, without having to temper their opinion for fear of it being applied as an open-ended future precedent on different topics. That will make it easier to generate consensus about those particular cases.
  2. It would remove the temptation to identify more and more marginal cases of "mass creation" to process in this fashion, avoiding ordinary deletion.

I think this would be a good way to allow us to deal with the most problematic mass creations without creating a vehicle for imposing views on notability, article creation and length, etc. that have failed to gain community consensus. The two issues seem to have become intertwined, in part, because of the personalities involved in crafting and arguing these RfCs, and I think establishing a clean separation between them would lower the emotional temperature and reduce the risk of disruptive behavior. I would like to know what others think, and whether this is worth elaborating into a concrete proposal. Choess (talk) 16:17, 23 July 2023 (UTC)

Are you saying that before starting a mass-deletion of mass-creation RfC, there should be a separate discussion that identifies the purported set of mass-created articles, and once identified, there would be a consensus process (RfC?) to see if there should be an RfC to delete the articles? -- GreenC 16:59, 23 July 2023 (UTC)
Close, but I think not quite. To break it down into steps:
  1. Assemble list of purported sets of [problematic] mass-created articles
  2. For each set, consensus process/discussion evaluates whether a mass-removal RfC could be warranted. (I'm using "mass-removal" to elide the distinction between deletion, draftification, etc.)
  3. For each set where the community has agreed "yes, some of these articles might have to be dealt with in large batches beyond what AfD can cope with", editors can frame mass-removal RfCs at their leisure and discretion.
  4. If an individual mass-removal RfC gains consensus, articles from that incident that fall within the scope specified by the mass-removal RfC can be dealt with as the RfC directs.
So there are two levels of consensus-building: 1) is this case so bad that we need to make an exception to our normal processes to deal with it? (which should be relatively easy to answer, because it should require an exceptional level of badness) 2) what are the exact terms of that exception that we can achieve consensus on (delicate, time-consuming, exhausting). Choess (talk) 18:15, 23 July 2023 (UTC)
I'm struggling to understand what you are proposing; can you lay out an example that demonstrates how you see it working? BilledMammal (talk) 20:14, 23 July 2023 (UTC)
@Choess, when you say "maximum possible scope", are you thinking about the individual RFCs? For example, I could have 100 RFCs on 100 articles each (=10,000 articles), and you could have 100 RFCs on a different 100 articles each, and someone else could have another 100 RFCs on 100 articles each, and over time, between the three of us, ultimately we end up with 30,000 articles being considered in these RFCs, but each RFC can't cover more than 100 articles, or I can't start more than 100 of them myself?
Or are you thinking about an overall limit, like "If it's not reasonable for AFD to consider an average of 10 more articles per day for the next five years, then it also isn't reasonable for the Draft: space to get an average of 10 more articles per day for the next five years, so no more than n thousand articles can be placed in the Draft: space under this system at any given point in time". WhatamIdoing (talk) 17:00, 23 July 2023 (UTC)
When I say "incident", I'm thinking something like "User X created nnn articles about topic Y using source Z. User X is now blocked and source Z has been shown to be badly inaccurate/not associated with a lowest-common-denominator assessment of notability." What editors are being asked to endorse, for each incident, is that there is probable cause to believe that cleanup of this incident will require mechanisms that bypass our normal deletion processes and their checks and balances (AfD including bulding.) If editors do so find, an RfC on that specific incident can be drafted and proposed, setting terms for which articles from that incident will be affected and how they will be dealt with. When I say "scope", I was thinking not so much of numerical limits as "Here are a few special cases we can agree are so troublesome we have might have to make exceptions to policy. You are not allowed to tax the community's time and energy by arguing for more exceptions indefinitely; make your choices now and then take your time working out the details." I think each incident is going to have numerically different scoping depending on how bad the problems are. Given the tenor of the LUGSTUBS debates, I don't think the number of "incidents" the community would endorse would be all that large, although of course a very large number of articles could still be on the table. Choess (talk) 18:15, 23 July 2023 (UTC)
So this is more like "We can use a weird process for Lugnuts' articles, because frankly some of us are still mad at him, and maybe for that sock, and maybe for that copyvio jerk, but don't think about stretching this to other articles that you think are in similar condition – we're putting some hard stops on that slippery slope". WhatamIdoing (talk) 19:45, 23 July 2023 (UTC)
That seems like a fair colloquial summary, yes. Or to put it another way, we're currently playing off the energies of people who, if left to their own devices, would be vastly more lax about notability, etc. than the community's standard, and those who would be vastly more strict. We have sort of an antipattern in these cases of declaring scrutiny of the less-objectionable faction off-limits for years, belatedly realizing they have also been disruptive for an extended period, and suddenly pillorying them. I think having a hard stop would prevent that overreach and antipattern. Choess (talk) 21:32, 23 July 2023 (UTC)
I always like an optimist. ;-) WhatamIdoing (talk) 00:10, 31 July 2023 (UTC)
The reason that people are concerned about their comments establishing precedent for future mass deletions is that "stretch[ing] the boundaries of what the process can be used for" has been explicitly stated as the goal of the RfC -- although this statement was withheld from the RfC's background, and any outsiders who stumbled upon it were immediately questioned with "how did you find this page?" Gnomingstuff (talk) 15:28, 25 July 2023 (UTC)
I don't really know what this is about, but if people can't agree on what exactly the threshold for mass creation is, everyone can agree that whatever Lugnuts' was doing was mass creation. Headbomb {t · c · p · b} 15:33, 25 July 2023 (UTC)
This is the discussion that produced the current RfC on cricketer articles in which "some editors have expressed opposition to the proposal for mass draftification on the grounds that this will create a precedent for future mass removal of articles without individual scrutiny at AfD." The precedent that people are concerned about isn't mass creation, but mass deletion/de-facto deletion" -- and they are correct to be concerned. Gnomingstuff (talk) 15:52, 25 July 2023 (UTC)
  • The problem I have with these discussions is that they veer too much into the "using two wrongs to make something right" type thinking. If mass creations are wrong, mass deletions are just as wrong, and the problems created by mass creations are equal in magnitude and nature to those created by mass creations. If we want people to only create articles thoughtfully and after due diligence, then we should only delete such articles thoughtfully and with due diligence. It doesn't matter if they were created by inappropriate mass creation processes (whatever that means), they exist now, and the correct way to handle them is not to abandon our principles, but rather to double down on them. Each individual article should be considered on its terms, treated against the standards irrespective of the process that created it, and conclusions about how to deal with that article should be done thoughtfully and diligently. We can't fix the past, but we can move forward in the right way. As a side note, this applies to articles created in good faith and not for obvious hoaxes or batch vandalism or stuff like that. Burn that with fire. --Jayron32 16:19, 25 July 2023 (UTC)
    That just enshrines WP:FAIT: the logical response to mass-creation is mass-draftification. It also ignores the fact that articles in Wikipedia's periphery can receive no editor scrutiny for many years, as certain hoaxes have shown. This burden of [thoughtful] due diligence is time-consuming; it'll either not be carried out, or it will be, at the expense of articles in much more dire need of this attention. DFlhb (talk) 16:31, 25 July 2023 (UTC)
    I disagree that the logical response to "the wrong thing" is "the same wrong thing, but in a different direction". Wrong is wrong, in this case. --Jayron32 16:33, 25 July 2023 (UTC)
    Also, allow be to clarify a bit. Since you were confused, when I said my thinking was "not for obvious hoaxes or batch vandalism", what I meant by that was that my thinking was "not for obvious hoaxes or batch vandalism". I hope that is easier to understand. --Jayron32 16:35, 25 July 2023 (UTC)
    What's with the condescension? I use hoaxes as evidence of the lack of attention our peripheral articles get. Not to refer to mass-deletions of hoaxes. Who's confused here? DFlhb (talk) 17:15, 25 July 2023 (UTC)
    "Articles in much more dire need of this attention" gives away the game here. Either the mass-created articles are an urgent priority that must be addressed now, which has been the implication of dozens of discussions here and the rationale for wanting to nuke thousands of articles right now, or they are not. If they are, then the thoughtful due-diligence is correctly placed. If they aren't, then people should be focusing on the ones in dire need of attention, instead of waging a years-long campaign of moral outrage over the non-dire ones. Gnomingstuff (talk) 18:33, 27 July 2023 (UTC)

I think that an unspoken intuitive principle helps make sense out of all of this. If someone spends a substantial amount of time building a particular article, then it gets treated like something that represents a greater investment of time and typically more content and sourcing, including having a separate AFD (and the related 15-90 minutes or more of volunteer time) if deletion is proposed. This also follows the idea of a commensurate investment of time. If it was mass created it probably only had a couple minutes or less invested on a particular article and none of those particulars or expectations are the case. To summarize, it is legitimate and with much basis to treat mass-produced articles differently. North8000 (talk) 17:07, 25 July 2023 (UTC)

Template creation

Editors who are not autoconfirmed cannot create articles. Should we also prevent them from creating templates and modules? I've seen the occasional autobiography and hoax in Template: namespace, presumably because the author failed to create it in mainspace. The only downside I can see is that it might hinder an editor porting a template or module to enwp from their home wiki. Certes (talk) 22:55, 30 July 2023 (UTC)

Is the level of miscreations in template and module namespace so bad that it warrants a total creation block? I would be reluctant to support this without evidence. IMO, occasional autobiography and hoaxes can be speedy deleted and moved if necessary. Also, template and module is not really read by casual readers so I would think there is little impact on the main encyclopedia's quality. Ca talk to me! 16:23, 2 August 2023 (UTC)
The volume of edits is very low, but I've yet to see a constructive one. It's just a place to put unwanted articles when mainspace creation fails. Certes (talk) 18:22, 2 August 2023 (UTC)
I can't see this making sense until and unless it also does for every other indexed namespace (that is, everything but User:, Draft:, and their talk pages), and changing indexing on a per-page basis via magic words or their template. We're not at the point that it's necessary for namespaces - certainly not for Template: and Module:, though we see more of it in Wikipedia: - but I wouldn't shed a tear if some enterprising EFM prevented the non-autoconfirmed from indexing the fake articles they're so fond of creating on their user pages.
In the meantime, hoaxes can be speedied no matter their namespace, and if someone creates an otherwise A7able autobio in a non-articlelike namespace, most admins won't object to deleting those either. —Cryptic 19:40, 2 August 2023 (UTC)
I would also like to see the actual instances of this. Worth noting that a newly created template could be transcluded into a popular article and due to caching, it would be hard to undo the impact in some cases, which is perhaps a reason to pay attention to Template namespace more than others. ~ 🦝 Shushugah (he/him • talk) 21:15, 2 August 2023 (UTC)
If considering the use case of a newly created page (versus taking over an existing template in wide use), then this risk exists with more than just the Template namespace. isaacl (talk) 21:33, 2 August 2023 (UTC)
I'm thinking of examples like {{EDP445 (Internet Personality)}}, but it also applies to good-faith templates that aren't ready for use such as {{Country data Berwick upon tweed}} and {{Mediaarts-db}}. However, as I mentioned, it's low volume. Certes (talk) 08:11, 3 August 2023 (UTC)

Subscribing to a Draft so I'm notified at the five-month delete-warning

More than once, I've missed out on some Draft I'm interested in, because someone else created it, and they're the only one to get the courtesy notice at the five-month point, a month before it gets WP:G13ed. I want to somehow "subscribe" to, or "adopt", or template my username onto the page or something, so that when that notification goes out at five months to the creator, a copy also goes out to my UTP. Ditto upon actual deletion. (Yes, I know about WP:REFUND—assuming I realize it's gone—but I want the alert.) Mathglot (talk) 09:01, 26 July 2023 (UTC)

  • This is a good idea, but one with broader applications than drafts, I think. I know I've said it before, but it would be really useful to have fine-grained notification settings on a page-by-page basis: changes, moves, requested moves, requested merges, redirects, filters, maintenance tags, deletion tags, etc. I've long wanted to be able to see notifications when obscure, hardly-edited pages on my watchlist get an edit, but not the highly active ones, for example. If there were an edit filter for the 5 month notification linking to the article, that could be something one could turn on for draftspace, for example. — Rhododendrites talk \\ 14:18, 26 July 2023 (UTC)
  • (I've also said this before, but) watch the creator's talk page. If they're very active, they probably won't let the draft get G13'd anyway; if they're completely inactive after creating the draft, it won't clog your watchlist; and if they're in the middle and created a draft you thought worth saving, they're probably worth mentoring. —Cryptic 15:02, 26 July 2023 (UTC)
    I appreciate this tip, and I will follow it, however, I would consider this a "weak work-around", the reason being that I have many user talk pages on my watchlist, and when scanning the list at any given time, I won't be thinking, "Maybe there's a G13 warning here", it'll just be one of many items from that namespace in my list. Five months later, it's unlikely I would remember even registered username anymore, much less an IP, as a possible draft creator. Mathglot (talk) 23:44, 26 July 2023 (UTC)
  • I support Mathglot's idea but more like Rododendrites. I too have wanted to receive notifications for certain things that I deem more important to my interests than the rest of the pages in my watchlist. I would like for example receive notifications of certain pages, even just for changes of certain sections or subsections of pages. This latter would be most useful in pages with a lot of changes daily. The more individually customizable the notification system, the better. Regards,
Thinker78 (talk) 21:57, 26 July 2023 (UTC)
  • If the MediaWiki feature phab:T58362 comes to a pass, your mom-and-pop bot operators would easily be able to write bots that provide all of the above requested features, and even more! Approved bots would be able to deliver updates to the notifications tab – which is currently accessible only to the core software.
    Until then, we have to live with less perfect solutions, one of which is User:SD0001/W-Ping. – SD0001 (talk) 07:19, 27 July 2023 (UTC)
    That looks like a very nice feature, I look forward to trying it out. Thanks! Mathglot (talk) 07:49, 27 July 2023 (UTC)
  • I'm confused by "I've missed out on some Draft I'm interested in, because someone else created it", per WP:OWN, even drafts can be edited by anyone, so you're quite allowed to improve a draft (or even move it to the main space) at any time, for any reason, whenever you want. What exactly is the issue you have been having? What is preventing you from editing these drafts yourself, improving them, or moving them to the mainspace if you believe them to be mainspace ready? --Jayron32 17:50, 3 August 2023 (UTC)
    @Jayron32, sorry I wasn't clear: this request is about improving the courtesy notification system regarding automatic draft deletion defined in criterion for speedy deletion G13. Currently, the creator of a draft, but no one else, is notified at the five-month point that their draft is about to be deleted. This request would mitigate the "but-no-one-else" part by enabling a wider, opt-in notification for non-creators of a draft, so they could be notified, too. To your question: nothing is stopping me from editing drafts, and I often do. The problem occurs when I wake up one morning and fail to recall that approximately five months ago (or longer, if someone continued editing it), some draft I'm interested in was created, and is about to be deleted. A solution would alert me to the impending deletion, just as it alerts the creator of the draft. I hope this is clearer. Mathglot (talk) 22:41, 3 August 2023 (UTC)
    This exchange highlights how the desire to be able to subscribe to these type of alerts aligns with the Third Pillar. —siroχo 22:52, 3 August 2023 (UTC)
    Gotcha. I thought you believed that only the creator could edit the draft. Could the notification system notify everyone who's in the edit history instead? It would seem to me to be a plausible implementation. --Jayron32 12:02, 4 August 2023 (UTC)
    Could the notification system notify everyone who's in the edit history instead? Hmm. I'm not sure I want to get alerts regarding every draft article I fixed a typo on. I think it should be something one opts-in to, not opts-out. Edward-Woodrow :) [talk] 21:28, 7 August 2023 (UTC)
    Agree with Edward; it should be opt-in. Mathglot (talk) 03:49, 8 August 2023 (UTC)

A bot could add the five-month warning to the draft, or its talk page. Then anyone who wishes to see it can simply watchlist the draft. Such notifications would have to be disregarded when determining whether a draft has been untouched for six months, otherwise it would sit there forever with the clock restarting every five months. Or use W-Ping. Certes (talk) 10:17, 8 August 2023 (UTC)

A tool to monitor and improve images in Wikiprojects

Hi there! I am interested in improving Wikipedia’s visual content and I built a tool that could help detect visual gaps in Wikiprojects.

I called it Visual Content Assessment Tool, or simply VCAT.

A working version of VCAT can be found at VCAT-dashboard, you can try it using one of the samples of data I already extracted, or you can extract data for any Wikiproject using the extraction tool, a command line tool I created for this purpose.

Some of the actions you can do with this tool are:

  • Monitoring the visual content coverage in a Wikiproject
  • Detecting articles needing images (eg. articles without images)
  • Detecting low resolution images to improve (eg. raster diagrams to be vectorized(

What do you think? Could it be a useful tool? MingoBerlingo (talk) 15:00, 26 July 2023 (UTC)

Damn! This is cool! I like it :) SWinxy (talk) 21:42, 1 August 2023 (UTC)
Thanks! I am still improving it, expecially the extraction which is quite tricky. If you have any suggestion please tell me. MingoBerlingo (talk) 08:15, 3 August 2023 (UTC)
@MingoBerlingo: Very nice! One comment, in the "Low resolution images you can improve" section, I think you should remove the "Contribute" button, and make clicking on the image itself link to the file description page.
I don't know anything about Wikitech, but can you/are you planning to host it on Toolforge?
Also, do you plan on making the extraction tool available on the web version? I know basically nothing about programming, so I don't know if it's even possible.QuickQuokka [⁠talk • contribs] 14:38, 6 August 2023 (UTC)
Thanks for your feedback! I'd like to use Toolforge, but I am not familiar with it. Maybe I could contact someone who's more into it and ask for advices. And also maybe with Toolforge I can move the extraction tool online, making somaething similar to PetScan MingoBerlingo 💬 08:55, 7 August 2023 (UTC)
@MingoBerlingo: Also, another thing: I saw that there's no licensing information in the Github repository and video guide, so maybe it's a good idea to release them under a free license, since that's in the spirit of Wikipedia? QuickQuokka [⁠talk • contribs] 14:46, 6 August 2023 (UTC)
Sure, good idea! Do you know any source or guide where I can learn more about this? (I'm still a newbie here) MingoBerlingo 💬 08:57, 7 August 2023 (UTC)
@MingoBerlingo: Well,
  • For GitHub open the repository, click Add new file → Create new file → Name it LICENSE → Click Choose a license template, then pick one. I may be biased, but I would publish it under a permissive license like MIT or BSD, but you should do your own research as to what fits you best. You should absolutely not choose a non-commercial license, however.
  • For YouTube see this support page. You should click on Edit video → Advanced → License and rights ownership → Creative Commons - Attribution
If you need any more support, I'm always happy to help . Also, please {{ping}} me and other people when you reply to them! QuickQuokka [⁠talk • contribs] 15:40, 8 August 2023 (UTC)
@QuickQuokka: Thankss! 🙏 MingoBerlingo 💬 14:27, 9 August 2023 (UTC)

A place for non-encyclopaedic material

This probably qualifies as a truly misguided and crackpot idea, which is why I'm nervous of posting it even here in the Idea section, where crackpot is open for proposition, even if all it creates is a lovely firework display as it descends in multicoloured pyrotechnics, sinks, and is never seen again.

Could we have another parallel space beyond main-space and talk-space, where each article can have an "extra material" space? I'm proposing this to solve dilemmas such as useful original research, additional explanation of complex subjects, tables of relevant data, etc. etc.

For example, at Abbots Ripton rail accident we have a long and well-written article whose author has gone to the trouble of checking census reports to find out the subsequent career paths of people involved in this serious 1876 incident (see notes 14 and 19). They've included - unfortunately unsourced - background railway information that is extremely useful to the reader (e.g. note 2, concerning the intermediate caution position of an early semaphore signal). There is also quite a lot of logical deduction based on individual fact (eg notes 9 & 11 where our editor has carried out calculations of stopping distances and timings), and personal interpretations of opinion (e.g. note 4). The original research is a real problem to me; by rights it shouldn't be in the article, but since it's cited to something that a reader could potentially check (albeit a very primary source, 1881 census data) we've got as much reason to believe the research is true as we do any of the rest of the article, which means that I really, really don't want to delete it. The personal deductions are the same, and this editor's work does set the accident in context in a way that is lacking in the only cited source, the accident report.

So if we had an "extra material" space, we could move sourced original research into it, thereby preserving "encyclopaedic" articles without having to throw away valuable human knowledge and deduction.

An "extra material" space would also be useful in barely-comprehensible technical articles. Here there's often the dilemma that if anyone attempts to add explanatory material, it runs into editors who point out that we're not a text book, who respond that we aren't here to hold hands with the ignorant, and if someone can't understand the main article, the subject is beyond them. The maths world, for example, frowns on simple, explanatory material supported by references to textbooks, as these are seen as tertiary sources, doing a different job, not the "real deal". It's even more dubious about websites with teaching/explanatory material set up by university professors, even though these are often the most approachable explanatory material, and have been produced by people who are acknowledged as competent. So again, we could put explanatory stuff based on such sources in the "extra material" section.

I'm not proposing that it should be a junk-heap. It does need restrictions. I'd say "closely related to the subject and demonstrably true" should be a minimum.

Is this a completely disastrous idea? Elemimele (talk) 14:30, 9 August 2023 (UTC)

Is this a completely disastrous idea? Probably.
sourced original research – isn't that an oxymoron?
Is this new namespace linked from the article? Edward-Woodrow :) [talk] 14:47, 9 August 2023 (UTC)
@Edward-Woodrow: Good questions. (1) Yes, a new linked namespace. It would mean that (some) articles would have three buttons at the top instead of two: "Article", "Talk" and "Extras" or some hopefully better alternative.
(2) By "sourced original research" I mean things like the Abbots Ripton "Notes" where the editor has gone to quite obscure primary sources (the 1881 census data) to work out what happened to the signalmen and stationmasters involved in this particular accident in their subsequent lives; and they've drawn conclusions from what they found (that the Abbots Ripton signalman can't have been regarded as too guilty by his superiors as he remained employed as a signalman). To my mind, this goes beyond what an encyclopaedia editor should do (summarise secondary sources) but is nevertheless "sourced original research" because they've indicated clearly from where they found their information. The synthesis aspect is less bothersome because the thought-process is obvious and the reader can either disagree or agree. Elemimele (talk) 15:05, 9 August 2023 (UTC)
I strongly suspect that this would turn into a monumental time-sink. Any content in a 'parallel space' would need monitoring for WP:BLP violations, breaches of copyright, vandalism, and the rest. And unless it was an utter free-for-all we'd still have to restrict what could be placed there, with the inevitable disputes, XfD discussions etc. If people want to publish original research, they have plenty of other options (Wikiversity might be appropriate for some), and facilitating it here is a distraction from the core purpose of the project - a tertiary encyclopaedia based on published sources. AndyTheGrump (talk) 15:31, 9 August 2023 (UTC)
I was just going to ask whether the OP was aware of Wikiversity? That sister project allows for some original research (such as analysis of primary source material to form original conclusions). Perhaps this is what you are seeking? Blueboar (talk) 15:36, 9 August 2023 (UTC)
Or Wikibooks? I think Wikipedia:Transwiki-ing is the solution for this. WhatamIdoing (talk) 19:48, 10 August 2023 (UTC)
Wikiversity appreciates good quality original research. We then could do with a link to the content if it has value. Graeme Bartlett (talk) 04:41, 12 August 2023 (UTC)
Isn't this what WP:External links is for? RoySmith (talk) 16:39, 9 August 2023 (UTC)
That would help with professorial tutor-pages, but what am I supposed to do with the original research in Abbots Ripton? There isn't an external link because the Wikipedian did the research. But it's good research... Elemimele (talk) 18:00, 9 August 2023 (UTC)
Still not something for Wikipedia, I think . Edward-Woodrow :) [talk] 18:01, 9 August 2023 (UTC)
There is nothing wrong with an editor using "quite obscure primary sources" so long as they hew to the restrictions in WP:PRIMARY. Although this is considered research outside Wikipedia, it is not what we call original research. Drawing conclusions from primary sources is what we call synth, and is forbidden. You can let the reader draw their own conclusions though. If you have some original research, you can publish it outside Wikipedia. Hawkeye7 (discuss) 20:33, 9 August 2023 (UTC)
That article is certainly waaay too detailed and too based on primary sources. Honestly I think fandom sites would be the best place for OR and such things. JoelleJay (talk) 00:13, 10 August 2023 (UTC)
There's no such thing as an article that is way too detailed. Hawkeye7 (discuss) 01:44, 10 August 2023 (UTC)
No such thing as too detailed?
Anyway, I concur - there are many free options available for self-publishing original research, and if such research eventually becomes good enough it could even become a source for the article. Barnards.tar.gz (talk) 08:05, 10 August 2023 (UTC)
...if such research eventually becomes good enough it could even become a source for the article. That depends on where it is published. - Donald Albury 12:32, 10 August 2023 (UTC)
One view is that the place for non-encyclopaedic material is in a non-encyclopedia, i.e. another site. However, you may be surprised at what is encyclopedic. Certes (talk) 21:15, 10 August 2023 (UTC)
It's a very good idea, and its something that the WikiMedia foundation is missing in its mission to be the 'sum of all human knowledge'
This could be facilitated by linking Wikipedia articles entries in WikiData to a new project with your suggestion in scope
Additionally, there's no reason, in theory, why Wikipedia couldn't host discussion/OR/miscellania regarding an article on an appropriate subpage by changing the settings of its MediaWiki instance
What you're describing is something that the internet sorely needs. As it stands, people find information on a topic that isn't appropriate for Wikipedia by typing reddit.com/r/[TOPIC]. There are obvious flaws with this. A WikiMedia foundation alternative would be a great thing.
Such a space could operate as a forum, place for research, reference repository, and / or all manner of other things in respect of the entries we have on WikiData Jack4576 (talk) 13:56, 11 August 2023 (UTC)
Iirc, Wikibooks allows original research and general purpose publications, and Wikiversity is more focused on textbooks for academic courses. Of course, it won't get nearly as much reach as Wikipedia, but they are alternatives. One does not have to resort to Fandom to write these sorts of things. — Red-tailed hawk (nest) 14:41, 11 August 2023 (UTC)
  • Everything2? I have occasionally found useful ORish things there unavailable anywhere else. It began in 1998 and has a massive amount of [mostly junky] content with some gems. -- GreenC 17:54, 11 August 2023 (UTC)
    @GreenC: thanks for the suggestion, I'd never heard of Everything2. My first look confirms your view: a lot of rubbish, but a few genuine gems. Maybe that's why the idea of an OR/extras space in Wikipedia is not so great; it would also end up containing much more trash than value. I don't know... but I still haven't the heart to tackle Abbots Ripton! Elemimele (talk) 10:23, 16 August 2023 (UTC)

What to do with User:Jaiquiero redirects

User:Jaiquiero who has been blocked for disruptive editing, has created a multitude of redirects (over 50), a few of which are good, some of which I R3'd, and many which I'm hesitant to R3, but should still be considered for deletion – many are unlikely search terms or just pointless. Taking these remainders to RfD would be an incredible waste of time and effort. What should be done? Pinging Ivanvector who, at RfD, suggested Delete all effectively per WP:X1. Mass- and likely automated creation of barely-plausible redirects is net negative for Wikipedia, and the creator is blocked for exactly that. Edward-Woodrow :) [talk] 14:23, 12 August 2023 (UTC)

I mentioned WP:X1 because it was a temporary emergency criterion we created to address nonsensical redirects created by a different user, but in that case there were many more redirects - at one point a list was compiled of that user's redirects that had 50,072 entries, and that excluded any that had been edited by any other editor. And they were far more obviously nonsense than Jaiquiero's: just before being banned and action being taken, the user created 126 redirects to micromastia, including such titles as "tuberous boobies", "diminutive titties", "minute breasts", "little tits", and "herniated areolar complexes". They also created all 126 of those over a span of one hour and 25 minutes. Actually much of their later work had to do with breast ailments, but earlier they had focused on nonsensical modifications of dictionary words, like classificationally, occasionalness, or violetishness. The criterion was created because there was resistance to just mass-deleting every one of their redirects, as a tiny proportion were deemed useful but we didn't want to have every one listed at RFD. It took many editors two and a half years to go through them all. An admin commented on Jaiquiero's talk page that of 3,871 articles they created, 3,610 have already been deleted, which seems like a lot but is a blip compared to the user we created X1 for. Also, my X1 comment was in reference to a different user's redirects from these two, and they've been blocked as a sockpuppet so G5 applies to those anyway.
To answer the question, if there is an affirmative consensus that all of Jaiquiero's redirects should be deleted, then that's all that's needed for an admin to mass-delete them - they can just refer to that discussion (or this discussion, if that's what we're doing), or any other user could tag them WP:G6 and refer to the discussion. Probably this should be happening at WP:ANI, though. Ivanvector (Talk/Edits) 16:00, 12 August 2023 (UTC)
I think that if you have already been through the lot, then it may be possible for others to join in a bulk RFD for the ones you are hesitating on. So if you can open up a discussion for them and list the ones you are unsure on in one big RFD, it should do it justice. Graeme Bartlett (talk) 07:33, 13 August 2023 (UTC)
For what it's worth, Edward-Woodrow, you are right in saying that Jaiquiero has created "over 50" redirects, well over 50. In fact the account made a total of 3,420 redirects, of which all but 36 have now been deleted. Not quite up to Neelix's level, but still grossly excessive. JBW (talk) 19:40, 16 August 2023 (UTC)
I have just checked a random sample of 10 of the remaining redirects. Two were, in my opinion, perfectly good redirects. Four seemed to me sufficiently pointless that I can't imagine anyone would bother to create them, but they are relevant enough that now they exist I feel they may as well stay. that leaves four which in my opinion were so pointless that I deleted them under speedy deletion criterion R3; they were either redirects from a subject with some connection to the topic of the target article but not actually mentioned there or just redirects from arbitrary modifications to the name of the article subject which nobody would actually be likely to search for. I did not see any of the grossly unsuitable redirects which Jaiquiero made; perhaps they have all been deleted already. JBW (talk) 19:53, 16 August 2023 (UTC)

List for gore websites

Hi. I have been thinking for couple weeks now, if I should create an article that would contain all gore websites. Basically a list that would contain all operational and defunct gore content websites. However, I'm not sure if the topic is widespread enough, so I'm asking here. Would list of gore websites be notable enough or not? Or should it perhaps be added to List of online video platforms? Or should such list even be included in Wikipedia? I know those websites are sometimes called shock sites, and the ones I know of, have very disturbing content in them, but since Wikipedia doesn't censor anything, I don't think that it would be an issue here either. --Pek (talk) 15:48, 8 August 2023 (UTC)

With such an article I'd ask what the definition of "gore websites" is and how you source that a given website is a "gore website". Jo-Jo Eumerus (talk) 16:02, 8 August 2023 (UTC)
Well, according to Wiktionary the word gore stands for; murder/bloodshed/violence. Can't really find any better definitions. So anything that is graphical and violent. Also, since when lists need to be sourced? Back in 2017 I made list of metal detecting finds and nobody asked me to source it. Also, the websites in this (list of online video platforms) also don't have references. --Pek (talk) 16:43, 8 August 2023 (UTC)
We know what gore is, we don't know what a gore website is (and, based on your descriptions, I don't want to know). Edward-Woodrow :) [talk] 16:54, 8 August 2023 (UTC)
Items on list articles need either their articles that show they should be on the list or referencing to allow verification that they should be on the list. Lists are also subject to notability per WP:NLIST, although this is usually a very easy standard to pass. Also you would need some kind of inclusion criteria, for instance why would news website that have videos including murder / bloodshed / violence not gore sites? I'm not saying they are, but how do you create an inclusion criteria that doesn't include them, etc. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:23, 8 August 2023 (UTC)
I have tagged list of metal detecting finds as lacking sources. Even lists must be verifiable. – Teratix ₵ 21:05, 9 August 2023 (UTC)
Compare Wikipedia:Glossary#uncited and Wikipedia:Glossary#verifiable. WhatamIdoing (talk) 18:51, 14 August 2023 (UTC)
The point stands. – Teratix ₵ 22:09, 14 August 2023 (UTC)
I agree that lists must be verifiable. However, that one is verifiable (=sources exist in the real world). The problem with that list is that it's uncited. You could fix that problem yourself, if you wanted it done. WhatamIdoing (talk) 16:06, 17 August 2023 (UTC)
Sites like https://algore.com? 😀 Anomie⚔ 20:58, 14 August 2023 (UTC)
A separate list of shock sites is so 2006. Graham87 10:33, 9 August 2023 (UTC)
WP:5P1... in particular: "not...an indiscriminate collection of information, nor a web directory." Jason Quinn (talk) 21:05, 13 August 2023 (UTC)

I have done due diligence search but can't find these being asked previously

Hi, 

I am curious about/seeking answers to...
 
1. Why does the landing page not automatically place the cursor in the search
box so someone can start typing straight away instead of having to click in
the box first?
 
2. It would make use much easier if the search box remained static at the top
of the screen when scrolling down an article so a new search could be
immediately initiated instead of having to return to the top of the page.
 
Thoughts gratefully received,
 
Richard 90.242.188.126 (talk) 14:02, 20 August 2023 (UTC)
Re 2.: When you are logged in with an account there is a sticky header bar that includes a magnifying class. When you click it a search field opens. -- Random person no 362478479 (talk) 10:13, 21 August 2023 (UTC)
True for desktop. Mobile users have to do a full scroll to the top. Frustratingly, on some devices / browsers this is the same gesture that will reload the page if done too quickly. Folly Mox (talk) 12:52, 21 August 2023 (UTC)
(The OP appears to have posted from the desktop site.) WhatamIdoing (talk) 22:12, 22 August 2023 (UTC)
In the android app (and presumably the ios app) you only have to scroll up a little for the header to appear (at least when you're logged in). -- Random person no 362478479 (talk) 13:14, 23 August 2023 (UTC)
Q1: Wikipedia:FAQ/Main_Page#Why_doesn't_the_cursor_appear_in_the_search_box,_like_with_Google?. — xaosflux Talk 13:47, 21 August 2023 (UTC)

Travel article external link spamming proposal

@Primefac has directed me to WP:VPR, but since I think this proposal still needs work, I’ll start here.

Past discussions of relevance: original discussion and external link blacklist request.

The general idea is that there should be a general sanction on editors of “Visa policy of COUNTRY” articles as these are prone to external link spamming of unofficial third-party travel/visa agency websites (with a risk of them being fraudulent too). And/or a protection policy regarding “high-risk” articles, since it’s usually IPs or newly created accounts who add these sorts of links.

See the original discussion above for links to examples of diffs where I removed inappropriate external links.

Per Primefac regarding a possible general sanction: maybe to also include "phone numbers in X" articles - spam is one thing but I have also noticed (both in the visa and phone number articles) that people have a really bad habit of putting incredibly personal info in these pages (visa ID numbers, phone numbers, etc), to the point where protecting it not only stops the spam but also decreases the proliferation of personal info that needs to be suppressed.

@Daniel Quinlan: for your info. Fork99 (talk) 09:13, 10 August 2023 (UTC)

What does it mean a general sanction on editors of “Visa policy of COUNTRY” articles? You mean anyone who edits these articles should be constrained (how) from doing (what)? -- GreenC 17:59, 11 August 2023 (UTC)
I mean that’s why I brought it here, I’m not 100% sure how it should work. Initially, I proposed making a few exceptions to the page protection policy to preemptively (possibly pending changes protect) a few higher risk countries/articles that seem to be targeted by inappropriate external links. Fork99 (talk) 20:09, 11 August 2023 (UTC)
I’ve come up with an interim solution in the meantime, and that is to add a piece of hidden text below the “External links” sub-heading of each article warning that links added should be discussed first at the talk page, any unofficial links placed will be deleted. It would also say that if they persist, their website will get blacklisted.
Something to the effect of:
<!-- ({{NoMoreLinks}}) --> <!-- DO NOT ADD MORE LINKS TO THIS ARTICLE. WIKIPEDIA IS NOT A COLLECTION OF LINKS NOR IS IT A PLACE FOR ADVERTISING (WP:ADV) ----- If you think that your link might be useful, instead of placing it here, put it on this article's talk page first for editor discussion. Links that are to UNOFFICIAL travel and/or visa agency websites WILL BE DELETED. IF YOU PERSIST, YOUR WEBSITE WILL BE BLACKLISTED BY WIKIPEDIA AND/OR WIKIMEDIA. --> Fork99 (talk) 23:28, 12 August 2023 (UTC)
Don't get your hopes up about that working too well. Check out the "editing box" here [11] for what I had to do in one article -- and it works only so-so. (That link might not work in the distant future when article sections have moved around.) EEng 23:56, 12 August 2023 (UTC)
Top and tail the external links section then, perhaps? Hm yeah the things people obsess over on Wikipedia! Fork99 (talk) 00:05, 13 August 2023 (UTC)
You might have more success by reporting the websites to the Wikipedia:Spam blacklist. That should keep them out of all the articles. WhatamIdoing (talk) 18:55, 14 August 2023 (UTC)
Give the spammers warnings on their talk pages using the uw-spam series of warning templates so they’re duly warned. If they persist, blacklist.
Blacklisting may carry implications beyond Wikipedia; there are unconfirmed reports that other web sites or even search engines may also use or consult our blacklist. They don’t want to get on our blacklist!
—A. B. (talk • contribs • global count) 01:20, 24 August 2023 (UTC)

Refideas notification upon editing an article

I've been kicking this idea around in my head for a while now, so I'm testing to see what interest there might be. Plenty of people park good sources on article talk pages using Template:Refideas when they don't have time or interest in working on the article themselves, or perhaps don't know what to do with the sources, and/or generally hope that someone will be able to use them at some point. It's a great idea, but part of the problem is that... people don't look at the talk page as often as they could, so these sources may sit there unused for a very long time, even on a frequently edited article.

So here is an idea, I don't know if it would be technically feasible, and I don't know if people think it would generally clutter up a page, but how about when someone hits "Edit" on an article that is using the Refideas template on the talk page, they get maybe something like a little yellow box above the editing window with a single short sentence saying something like "There are suggestions for sources on the talk page that you may find useful." Does that sound doable and something that people would appreciate?

This would be especially useful for both people looking into whether an article should be deleted (oh, look, there are good sources after all, never mind), as well as people with a genuine interest in improving an article who have the time to put the work in. How does this sound as an idea? BOZ (talk) 22:55, 18 August 2023 (UTC)

Excellent plan. Edward-Woodrow :) [talk] 22:57, 18 August 2023 (UTC)
Pinging @Timur9008, @KGRAMR @JimmyBlackwing, and @Sciencefish as I think I have seen them using Refideas the most. BOZ (talk) 23:04, 18 August 2023 (UTC)
+1 I will never be able to use all the sources I park in refideas. I think this proposal will help improve the encyclopedia. Donald Albury 00:30, 19 August 2023 (UTC)
Sounds like a pretty good idea to me. I've added refs to hundreds of talk pages but I've always been aware that they may go unseen. If there was some kind of notification, it would most likely help. JimmyBlackwing (talk) 03:51, 19 August 2023 (UTC)
Great idea!
—A. B. (talk • contribs • global count) 01:25, 24 August 2023 (UTC)
I do like this idea, but apparently the use case for {{Refideas}} – which I didn't know existed – is how I've been using the ==Further reading== section 🙃 Folly Mox (talk) 02:26, 24 August 2023 (UTC)
Hey, I get it, I've done that myself, which apparently rankled some people, so that's part of what led me to this idea. :) I'm feeling some unanimous support here so far so I'm planning to add it to proposals in the near future. :) BOZ (talk) 11:42, 24 August 2023 (UTC)
Late reply but the idea sounds nice :) Timur9008 (talk) 13:32, 24 August 2023 (UTC)
Agree in thinking that this would be helpful. Typically, I use refideas as just a place to dump sources for my own use, but this change would encourage other editors to look at those sources, which otherwise would be hidden away. ~ F4U (talk • they/it) 19:36, 24 August 2023 (UTC)

I added a proposal to Wikipedia:Village pump (proposals)#Refideas notification upon editing an article for anyone who wants to vote on it, and pinged everything who replied here. BOZ (talk) 17:51, 25 August 2023 (UTC)

Multinational bands and music groups

The vast majority of bands and music groups are based in a single country with performers from that country. Most articles begin "Bandname is a Nationese genretype band", such as The Velvet Underground was an American rock band. Today, more multinational bands are being formed, either by corporations, producers or because performers migrate or co-locate. In such cases a national descriptor without specific detail may become misleading. Editors have different views about nationality or may rely on poorly-researched entertainment media or compromise on a dual-national descriptions. Debatable descriptors appear in Alias (band), Kamelot, Kaachi, Le Sserafim, Sculptured, The Pretenders, The Band, Rainbow_(rock_band) and many more.

The assumption in the guidelines under Wikipedia_talk:Manual_of_Style/Music is that performers and composers are individual. Wikipedia:Manual of Style/Biography is helpful but assumes individuals. In contrast Wikipedia:Manual_of_Style/Television and Wikipedia:Manual_of_Style/Film explain how to describe multinational productions. I started some unfruitful discussion here at Wikipedia_talk:WikiProject_Music and Wikipedia_talk:Manual_of_Style/Music. I propose inserting a 4th point under Nationality to avoid implying something false about any principal performer's known nationality, when applying a band/group's national descriptor. Travelmite (talk) 08:16, 18 August 2023 (UTC)

Why not just say "x is a multinational *something* band yadda yadda yadda"? Edward-Woodrow :) [talk] 13:10, 18 August 2023 (UTC)
Yes, or even "is a *something* band yadda yadda yadda", and explain the multinationalism in a later sentence. I think Travelmite has a good general point, but we do not need to prescribe a specific approach; it will vary by article. E.g. "is a *something* band based in Nigeria with members from Nigeria and Sengal" or whatever. I think it's correct that we need to say something about not misleadingly identifying a multinational band and a national one; e.g. "is a Nigerian band, with some members also from Sengal" is potentially confusing and smacks of a "put a national identifer on everyone and everything" fetishism.  — SMcCandlish ☏ ¢ 😼  16:10, 18 August 2023 (UTC)
My starting point is Wikipedia:Biographies of living persons which strictly prohibits inserting a contentious descriptor to a person, even by implication. In everyday language, a Nationese group is a group of Nationese. Readers are more likely to assume bands and performance groups, are friends to each other, rather than as a corporate entity. Local fans often write such pages and feel it's just normal to think this band is Nationese. Travelmite (talk) 09:03, 20 August 2023 (UTC)
Maybe that's not quite a complete description of the BLP policy? Contentious descriptors are approved by WP:BLP if the "person is commonly described that way in reliable sources". Also, BLP doesn't apply to corporations, businesses, or other groups (except to the extent that people make up these groups). WhatamIdoing (talk) 22:10, 22 August 2023 (UTC)
The BLP policy line you've quoted is under Wikipedia:Biographies_of_living_persons#Tone and specifically refers to contentious labels and loaded words such as "sexist, terrorist or freedom fighter" as per Wikipedia:Manual_of_Style/Words_to_watch#Contentious_labels. It could be contentious to describe a performer as an "icon", "famous" or "controversial", however in this discussion we are talking about the mundane fact of the performer's nationality, which would not be disputed by reliable sources. I have already discussed legal entities, like corporations. Are you suggesting that when people read "Nationese rock band" it forms a Legal person rather than a group of people? Travelmite (talk) 13:10, 24 August 2023 (UTC)
Travelmite, respectfully, if you are under the impression that nationality is always mundane and never contentious, you have been well isolated from certain areas of the project. Folly Mox (talk) 17:49, 25 August 2023 (UTC)
Paris Combo, which has had members from France, Australia, Algeria, and Madagascar, has started with "Paris Combo is a musical group based in Paris, France ..." for more than 17 years. The countries of origin of the members are only listed in the Members section. Donald Albury 18:01, 18 August 2023 (UTC)
Yes, some articles are factually-written and that is not a problem. Travelmite (talk) 09:08, 20 August 2023 (UTC)
It might sound reasonable enough to describe The Velvet Underground as an American rock band but John Cale was Welsh (noted right in the lede) and Nico German. Can't think that the plurality of nationalities the group changes anything to be honest. 2A01:E0A:D60:3500:EF89:C1D:F31C:961A (talk) 11:42, 25 August 2023 (UTC)
Not sure where to put this comment, but I feel like it's a good general rule of thumb that if something is going to take some explaining to contextualise, it shouldn't go in the lead sentence, or otherwise be used as a label. This is the sprout of many an edit war, especially when the thing that requires some explanation is nationality or ethnicity. Folly Mox (talk) 17:42, 25 August 2023 (UTC)
That's a good rule of thumb. I'll try to hold to it. Edward-Woodrow :) [talk] 19:56, 25 August 2023 (UTC)

"Bibliography:" namespace

There's a somewhat contentious RFC going on in Wikipedia talk:Notability (academic journals) § RfC on notability criteria. While we almost certainly need a better SNG for journals, there is one point there that is confounding the issue to some degree. There is a valid (though not WP:PAG-backed) desire to include information on the sources Wikipedia uses to build its articles. It does make sense that we want to provide information to our readers about the sources we use to construct Wikipedia. But maybe trying to force encyclopedia articles about these sources is the wrong approach.

I think we could address this specific issue by creating a "Bibliography:" namespace, and allowing for bibliographic entries for journals or other sources, that don't need to hold up to WP:N. We can require a template at the top of each entry that makes it clear that "This is a Wikipedia bibliography entry for a source used in Wikipedia articles" with some verbiage noting that it's not an article itself etc. We'd require most policies and guidleiness to be met, with a specific different "notability" criterion allowing only for inclusion of bibliographic entries on sources that Wikipedia relies upon, e.g., Bibliography:Niche Reliable Journal.

A key for this namespace is that it would be intended primarily for readers, to give them information on what Wikipedia is using -- hence its purpose would be different from WP:RSN/WP:RSP, WP:CITEWATCH, etc which are meant for editors to evaluate sources.

What do you think? —siroχo 23:37, 11 August 2023 (UTC)

I really like the bones of this idea, but I don't think a whole nother namespace is the solution. Couldn't we collate this sort of information under the auspices of a WikiProject? Folly Mox (talk) 23:42, 11 August 2023 (UTC)
I think I might have misunderstood what you were suggesting. With the links to the discussions you led with, I thought you were talking about general information about the sources we cite, not a compilation how those sources are cited in articles, which seems more in line with a similar namespace created by fr.wp to hold citations for reuse. Or maybe I'm dumb and just don't understand what is being workshopped here at all. Folly Mox (talk) 00:48, 12 August 2023 (UTC)
Indeed I was I was thinking about general information about the sources we cite, intended for readers. Basically so we can provide some level of Wikipedia-style information on the resources we cite, even normally we would not construct an article about the source due to our policies and guidelines.
If folks see value in expanding such an effort into a compilation of how those sources are cited, I'd be intrigued but haven't put too much thought into that yet.
I am not sure if a WikiProject necessarily works, because those are generally groupings of editors and tasks/initiatives the editors want to work on, rather than meant for readers. —siroχo 00:58, 12 August 2023 (UTC)
I personally love the idea of providing our readers more information about our editorial processes, including how we view our sources. I'm sure there exists a contrary perspective holding that the only reader-facing namespace should be article. I'm sure of this because it's a position I personally held just a season ago, as evidenced by my comment on a similar idea at Wikipedia:Village pump (proposals)/Archive 202#Proposal to show the status of reliability within articles (which was geared towards RSP specifically rather than a bespoke bibliographical entry). Folly Mox (talk) 01:45, 12 August 2023 (UTC)
Ohhh... I thought it was like a {{Harvard citation}} except they displayed on another page, so that the in-text references were minimalist and the longer reference was in a list in the Bibliography namespace. @Folly Mox: is this frwiki namespace active, or just a proposal? I'm curious. Thanks, Edward-Woodrow :) [talk] 11:31, 12 August 2023 (UTC)
fr:Aide:Espace référence is, according to the Foundation's proposed citation reuse initiative, meta:WikiCite/Shared Citations, currently in use as of 2022 (I can't read French to verify). An easy way to consolidate and reuse citations, as well as holding metadata about their perceived reliability, comes up an awful lot. The WMF's proposal is appropriately the most thorough and ambitious, but I only know about it because this idea came up on this page last month, at Wikipedia:Village pump (idea lab)/Archive 50#Reliable source tracking on Talk pages. Folly Mox (talk) 12:03, 12 August 2023 (UTC)
Based on my limited knowledge of French, it looks like it's a namespace for listings of information regarding multiple editions of a work (e.g., ISBN, pages, etc). Edward-Woodrow :) [talk] 12:07, 12 August 2023 (UTC)
Yeah, according to the example listed prominently on the associated WikiProjet, the namespace holds basic bibliographical information with citation template code for easy copypasta, but it looks like it could comfortably hold information about reliability, and presumably there's a way to program a module to fetch an appropriate reference from Référence: space and have it spit out the citation template you want, which would populate Special:WhatLinksHere for the associated reference. The module would probably only need per-cite specifics like |page=, |quote= etc. as optional parameters and you'd be up and running without needing to understand or fill out citation templates at all for any sources sufficiently detailed in the namespace under discussion. Folly Mox (talk) 12:20, 12 August 2023 (UTC)
Could be useful – would help reduce clutter long citations cause. I believe wiktionary has something somewhat similar – a "citations" namespace dediacted to quotes supporting usage of the word. Edward-Woodrow :) [talk] 23:48, 11 August 2023 (UTC)
This could also be useful for newspapers as well. Curbon7 (talk) 01:18, 12 August 2023 (UTC)
I think this would be a much better place to host all the journal articles that amount to nothing more than a non-independent primary database entry. One of my concerns in the "are journals in selective citation indices inherently notable" RfC is the fact that readers/editors coming across our journal articles will assume they are like any other Wikipedia non-biography article and have met GNG, and thus expect that the prose content will be a summary of independent secondary reliable SIGCOV (or at least has the potential for this) rather than a pure derivative of ABOUTSELF. A namespace dedicated to curating bibliographic data, where there is no expectation that an entry is based on IRS SIGCOV (or has received such, even if not cited), wouldn't mislead people into thinking a homeopathy journal is reputable just because the article doesn't mention any criticism of it. JoelleJay (talk) 02:02, 12 August 2023 (UTC)
If it is data about sources, then Wikidata is the place to put it. Then every Wikipedia can use it. Perhaps we can have a way to more neatly present the info to English language readers from the data, but I don't think we need a name space. We used to have doi's as templates. But I would think that Wikipedia: is better than Template: for this. But a template could interpret the wikidata to display. Graeme Bartlett (talk) 04:38, 12 August 2023 (UTC)
"Wikipedia:" namespace is meant for editors. I'm hoping to find a way to provide information to readers about the sources used to construct the encyclopedia, especially when articles don't exist for the sources due to notability reasons. Wikidata may be a good answer for this, but how would we display it to readers? —siroχo 06:03, 12 August 2023 (UTC)
I'm a little bit sus about outsourcing information to Wikidata. It's really good at what it does, but it is a different project, so it's difficult to keep an eye on for changes, it acts as a black box when chasing down errors, and the learning curve is pretty steep. The other, other, other time the idea of a separate namespace for citation reuse came up recently at the VPs, at Wikipedia:Village pump (proposals)/Archive 197#Migrating inline references to a separate 'References' space, the Wikidata solution was characterised as a non-starter.
Wikidata is great for uh data, but if we're concerned with things like subjective assessments of reliability, we're going to lose a lot of important context in translation. I'll close with the perennial reminder that reliability can only be properly assessed at the intersections of sources and the claims they make. Folly Mox (talk) 12:41, 12 August 2023 (UTC)
Sorry when I said I'll close, I meant my comment, not the discussion! Sure, let's make a Reference: namespace while WikiCite is approved, roadmapped, developed, and launched. Why not give it a go? Folly Mox (talk) 19:33, 14 August 2023 (UTC)

Subsection

See also: Wikipedia:Village pump (proposals)/Archive 202 § Proposal to show the status of reliability within articles
See also: Wikipedia:Village pump (idea lab)/Archive 50 § Reliable source tracking on Talk pages
See also: Wikipedia:Village pump (proposals)/Archive 197 § Migrating inline references to a separate 'References' space
  • Desideratum: central storage for bibliographic information (including built in citation templates and source analysis by editors)
  • Theory of change: I don't know what this means, so I'm including it to make myself look dumber.
  • Technical requirements
    • a new namespace, with a unique identifier that doesn't just lead to us reinventing Wikidata or Worldcat in-house (i.e. human readable and ideally guessable)
    • a per-item set of mutable and immutable parameters (so we can always fetch author and title etc. but vary in page number, edition, |ref= for different shortened footnote styles, etc.)
    • a module that translates a Referencespace call into an appropriate citation template in a way that links the Reference and the target visibly in both directions
    • links to and from RSN and either a section of the Reference or its Reference Talk page.
  • Benefits
    • executed properly, citing sources is greatly reduced in hassle and duplicated work
    • reliability of sources around some claim or category of claims is easy to locate, same for independence of that source with respect to other entities
    • scripts automatically generating citations from Referencespace items will always be correct and complete
    • partially complete existing citations to a source available in Referencespace can be turned into complete ones en masse
    • internal "citation impact": we can see what is cited and how often, easy to generate interesting reports for internal and external use
    • to the extent the space is populated, it creates an annotated bibliography of the encyclopaedia
    • new citation template parameters can be added once to populate everywhere
    • a translator module to import a commonly used citation data format could create these by the lots, cutting back on entry labour
    • abnegates the need for any further custom templates for citing a specific source, since it's basically a general case of that
    • could be integrated into VisualEditor so newcomers can cite way better easily
  • Problem areas
    • Unique identifiers. If we use anything other than what a human would think of when naming a reference, this makes it more difficult to cite, because you have to search the namespace first just to figure out how to cite the thing you want. We'll need a lot of redirects and there will be a lot of conflicts between sources with similar parameters.
    • Also since we only want one set of reliability discussions and publisher information per source, we might have to organise the whole namespace by work rather than by title, making it extra complicated.
    • We're not going to be able to put every source in here (every weather report from every news station ever cited? every obituary? every Olympedia entry? there's no way), so sometimes we'll be able to use the namespace while sometimes we'll have to use a regular citation template, and it's extra effort to identify which case we're operating under.
    • Some sources are identical at multiple URLs, and / or multiple DOIs. Do we pick one? If not, do we list the known options? Should we allow manual override of every template parameter, just in case?
    • Similarly, what about articles with different citation styles? Do we have multiple officially valid output templates? A single style parameter that can switch between popular options?
    • Can {{sfnp}} and {{harvnb}} be made to work across namespaces like this, or will they always generate no-target errors?
    • Also, we're pushing the boundaries of what is appropriate for the project and what is appropriate for Wikidata, the (hopefully) future WikiCite, etc. Risking a lot of duplicated effort.
    • There's also potential for abuse, like someone changing the |work=The Sunday Times to |work=i peed in your car or |work=[[File:commons:Porn but somehow also racist.tif]] and having it transclude to a thousand articles on load instantaneously until all the caches are purged.
    • Oh right all the data entry as well

Idk does this seem like a thing that's possible? The benefits seem really good, but the work seems super a lot. Does a smaller scope make sense? How would the scope be ensmalled? Would it still be worth it? Is there any intersection point between costs and benefits with a positive ROI? If we did outsource this to Wikidata, how on earth would that look?

Apologies for the disorganised thoughts. I did the best I could with the bullet points. Folly Mox (talk) 03:58, 24 August 2023 (UTC)

This is awesome, thanks, no apology necessary. I'll respond in kind, just some more thoughts :) We can address this grand plan but start with a smaller scope. I think this could be approached in steps so as not to make it take too much effort.
Milestone 1
  1. Decide on inclusion criteria.
    • Is it literally a bibliography for every source Wikipedia uses? Probably not. Set some reasonable guidelines.
    • Do we want citation-level items, or only full works (Journals, Books, Newspapsers, etc) I think for the first milestone we probably just need the full work to get us rolling.
  2. Settle on a format for how sources are "written about" in the bibliography. Much of it could be structured data as you suggest (special infoboxes, basically?). There would be some amount of prose allowed, since we want all types of readers to be able to benefit.
  3. Create namespace. This is milestone 1. We have something useful to readers (and editors) at this point. This largely addresses the notability problem, where we have no way to communicate to readers about some of the sources we use.
Milestone 2
  1. (just an idea) Automatically point redlinks only in citation templates to Bibliography entries if they exist to make it easier for readers to learn about a source we use.
Milestone 3
  1. Start allowing individual papers, chapters, articles, etc. They should probably be subpages of the main bibliography entry. Eg. if you have Bibliography:Nature, you could have Bibliography:Nature/My Paper, This is not wikidata, we need it to be primarily human readable, with structured data as a bonus. As such, disambiguation, PRIMARYTOPIC, redirects, etc are fine and should be embraced. My preference is to benefit the human, both reader and editor.
  2. At this point, updating citation templates to allow use of the available structured data becomes valuable. Something like {{cite-bib|bib:Nature/My Paper|page=13}}. (Yes, there are good faith accidental move and vandalism risks here to be discussed.)
Milestone 4+
  1. All the other nice things you mentioned and more. Fancy bots to do things we haven't thought of yet, visual editor, etc.
—siroχo 05:10, 24 August 2023 (UTC)
Having unique identifiers rather than the details appearing in the article proper would make it much harder for novice editors to correct any obvious errors they find issue. Instead of simply correcting the details in the article they would have to learn that these unique identifiers where, find the one in the article, and then change what they know needs to be changed in the new namespace. After which they would probably be reverted, as what they actually needed to do was use a different unique identifier that already has the different details that are required in the article.
Or more simply new users would give up, as they already do with another implementation of this idea. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:25, 24 August 2023 (UTC)
That's a pretty good point. What if instead of having a relatively opaque module call like for instance {{cite RefSpace |ref="Pines 2014 T'oung Pao" |p=22 }}, the module would do a subst and just paste in the template from the Referencespace item, along with the unique identifier it called? Then there could be some kinda bot that checks the templates with Referencespace identifiers against the templates present in the Referencespace item and generate a report or add to a tracking category whenever the templates differed in an unanticipated way? This list could then form the set of excluded citations whenever an update is made to the Referencespace default output template, since someone has already changed it and we wouldn't want to overwrite their edit with a script that doesn't know why the template was changed. Folly Mox (talk) 17:51, 26 August 2023 (UTC)

Should Wikipedia block AI web crawlers?

Should Wikipedia block AI web crawlers as The New York Times has? Schierbecker (talk) 20:51, 23 August 2023 (UTC)

Regardless of whether we do, AI developers could just get the data from the data dumps (and indeed most already do). Even before the most recent generation of large language models, Wikipedia has been widely used as a data source for exactly that reason (some examples). Ultimately, Wikipedia is licensed under the CC-BY-SA 4.0 license, which allows using Wikipedia's content in any medium or format, such as for training AI. Vahurzpu (talk) 21:11, 23 August 2023 (UTC)
Per Vahurzpu, basically, no. Being "the free encyclopedia" includes being free to crawl. Besides, don't we want our future AI overlord to have access to high-quality Wikipedia information? BD2412 T 21:25, 23 August 2023 (UTC)
Why should we? Edward-Woodrow :) [talk] 21:26, 23 August 2023 (UTC)
The only reasons I could thing of would be for site performance or because the AI isn't honoring the CC-BY-SA 4.0 license. Performance issues are for the WMF to determine and deal with, not us. If there's a license issue, that too should probably start with WMF looking into it for us, as they pay for actual lawyers. Anomie⚔ 22:25, 23 August 2023 (UTC)
It seems quite unorthodox to suggest that CC/GPL/etc licenses stipulate that if, for example, you read a dictionary released under said license, you are permanently required to attribute its editors every time you use one of the words you learn for the rest of your life. jp×g 02:29, 31 August 2023 (UTC)
Good thing no one has suggested that in this discussion, then. Anomie⚔ 11:24, 31 August 2023 (UTC)
Well, I don't get how a language model would violate CC attribution requirements simply by reading Wikipedia articles and remembering some of the facts contained in them. If it replicated them in toto, maybe, but I don't think it's even physically possible for them to do that (LLaMA checkpoints, for example, are orders of magnitude smaller than even heavily compressed versions of the codices used to train them). jp×g 19:26, 31 August 2023 (UTC)

Make video thumbnails less obscured by icons

Example from a current FAC

Embedded videos are increasingly used, but their dual use as illustrative thumbnail images (as encouraged by the "thumb time" parameter) are hampered by play and timer icons obscuring the thumbnail, as can be seen here:[12] This was actually changed last time I complained about it, with the play button moved to the lower left, and back then, the circle around the play button was a translucent grey. For some reason, in the meantime the icon has been changed back to the middle of the image, with a background of opaque black (same with the timer), which obscures even more. Is there any good reason why there can't be a compromise? FunkMonk (talk) 12:36, 24 August 2023 (UTC)

Yeah, because it’s just me doing anything for the player in some very rare spare time. If you want to hire a designer to improve the design and implement AND maintain the design for 10 years, you can do so. —TheDJ (talk • contribs) 22:51, 24 August 2023 (UTC)
And 1 man’s compromise is another person’s very hated design btw. —TheDJ (talk • contribs) 22:51, 24 August 2023 (UTC)
This is not a personal complaint against you, this is about a feature that is used throughout Wikipedia and should therefore work optimally. I'm merely pointing out that it worked fine at some point, and wonder what led to the current version, and why it is considered an improvement. FunkMonk (talk) 23:26, 24 August 2023 (UTC)
Wait, really? What??? It's just one guy? jp×g 19:27, 31 August 2023 (UTC)

Include an option in preferences page to allow page previews for non-mainspace pages

Right now, when hovering over a link to a page outside of mainspace (WP:THIS, for example, compared to This), no page preview appears. Not sure why it's like this, (maybe for people who just read Wikipedia and don't really venture outside the mainspace much) but it would be nice to have this rather than just a tooltip with the article name, or, for psuedo-namespaces, an error. (There was another type of page previews, but it looked really weird when I tried it, and this should be a feature with the default anyways.)

Does anyone have any thoughts on this, or...? LOOKSQUARE (👤️·🗨️) talk 01:53, 1 September 2023 (UTC)

On hover, I see a page preview popup for WP:THIS same as for This.(I have Navigation popups enabled in Preferences > Gadgets) Schazjmd (talk) 13:20, 1 September 2023 (UTC)
Right, that's what they were called. I was just saying it would be nice for the default page previews because I didn't really like the navigation popups :P LOOKSQUARE (👤️·🗨️) talk 13:28, 1 September 2023 (UTC)

Uniformity required?

I saw that the articles which are in the category Category:Lists of fishes by country have lots of non-uniformity in their titles. It may create additional efforts for readers to see quick search for the other articles of similar type/topic. Some articles have names like "List of fish of....". Some have names like "List of fishes of....". Some articles have "in" instead of "of". Isn't uniformity in the page titles required? What does the wikipedia community think about it? Haoreima (talk) 17:54, 2 September 2023 (UTC)

  • Uniformity is often helpful… but, no, it isn’t “required”.
One reason it isn’t required is that different varieties of English use different vocabulary (example: “flashlight” vs “torch”). But there are other reasons as well. Blueboar (talk) 18:07, 2 September 2023 (UTC)
Special:Search will be able to locate the articles by keyword even there is a difference in plural form, in/of, etc. It's not required for everything to be uniform. Folly Mox (talk) 21:15, 2 September 2023 (UTC)
It's not a requirement - not because it wouldn't be nice, but because it's rather difficult to achieve. Perhaps, if this is an issue that's important to you, you might try to address it - I, for one, think that uniformity on such things would be more professional and encyclopedic. Pecopteris (talk) 00:35, 3 September 2023 (UTC)
I would suggest opening a multi RM on the basis of WP:CONSISTENCY if you are interested in uniformity in their titles. BilledMammal (talk) 00:37, 3 September 2023 (UTC)

DVD repository?

There's an article in today's NY Times[1] saying that Netflix is shutting down their DVD business and letting customers just keep the disks in their final orders. The article concludes with "A spokesman said Netflix had not determined what it would do with its remaining inventory." Maybe out of scope for WMF, but I wonder if there's any way we could get them. Maybe as part of commons? Maybe as some new collection? I know, all sorts of problems with licensing, but if this could somehow be made to work, it would be a fantastic thing, and it would be a damn shame if all those disks went into the proverbial dumpster. RoySmith (talk) 18:58, 25 August 2023 (UTC)

The Internet Archive surely must be interested. Perhaps send them a message? I'll point out that there are reasons to preserve DVDs beyond simply to hold an obsolescent digital copy of a film; for instance, there is ephemera worth preserving, like DVD menu art, that's embedded within the format and not really saved anywhere else. I would enjoy a collection of emulated DVD menus; it would fit right into the emulation station. :) Shells-shells (talk) 19:31, 25 August 2023 (UTC)
Shaun from WMF Legal here. This definitely sounds like something the Internet Archive would be interested in. It's accurate to say that the licensing issues and even anti-circumvention laws might prevent Wikimedia from doing much with this, but preservation of things like DVD menus seems pretty important since they will be lost ephemera in 10 years. Good luck with reaching out to them. SSpalding (WMF) (talk) 04:07, 26 August 2023 (UTC)
I'm a bit confused by this discussion. Netflix was not the sole provider of DVDs, and does not own the intellectual content of the discs. New DVDs are still being manufactured, and many of the titles in Netflix's inventory are still available to purchase from stores (or library distributors like Midwest Tape) in new condition. I'm sure Netflix does have some specific titles that are out-of-print and hard to find, but legally, what could the WMF do with them besides warehouse them somewhere? And I don't know why the Internet Archive would have any special legal protections to host that content. Zagalejo (talk) 15:20, 27 August 2023 (UTC)
To clarify, Internet Archive would not have any different protections. But they have a much different mission than the Wikimedia projects and as a result have a much different perspective on fair use and anti-circumvention laws to move that mission forward. This has gotten them in some trouble in the past, but they are also at forefront of online archiving. I can see why access to a corpus of low cost or free rare or semi rare DVDs could be appealing to them. SSpalding (WMF) (talk) 12:08, 3 September 2023 (UTC)

References

  1. ^ "Netflix Says You Can Keep Their DVDs (and Request More, Too)". nytimes.com. Retrieved 25 August 2023.

Moving WP:PURGE to Help namespace?

Seems like that the WP namespace isn't the best place for documenting a much more technical feature to Wikipedia, and something maybe even more belonging on Meta. I think that maybe moving WP:PURGE to Helpspace could make a lot more sense for the page. It's admittedly a bit of a trivial move, but I personally feel it belongs better there than where it is now. InvadingInvader (userpage, talk) 06:38, 3 September 2023 (UTC)

I'd support the move. WP:RM? Edward-Woodrow :) [talk] 15:15, 3 September 2023 (UTC)
I went ahead and boldly did the move, intentionally leaving the Wikipedia:Purge redirect in place.
Apparently this was in the Help namespace originally, til someone moved it in 2005. - jc37 15:27, 3 September 2023 (UTC)

Patrolling a random sample of edits by autopatrolled editors

As has been discussed at ANI recently, the autopatrolled right is mainly a tool to reduce patrollers' workload. On the other hand, it has the disadvantage that it completely removes these editors' articles from the scrutiny of patrollers and new page reviewers. What would people think of creating a bot that unpatrols a random sample (I am not sure of the correct number; a first guess would be 5–10%) of autopatrolled editors' new edits, so that they can be checked by patrollers? This would keep the vast majority of the benefit of reducing reviewers' workload but also make sure that all editors are having at least some of their edits checked by a third party (who can then add additional scrutiny to the editor's other edits if anything strange is detected). CapitalSasha ~ talk 14:14, 29 August 2023 (UTC)

That or something like it would be good. I am currently one of the few editors actually checking new articles from all editors, independent of the "patrolled" status. One of the problems is that of course I can't check them all, and that editors who I do notice get all criticism from me and not from others, which isn't helping. We have had multiple cases of autopatrolled editors creating all kinds of problematic articles, e.g. copyvios, spam, poorly formatted ones, and so on, and often the aautopatrolled ones are among the more prolific editors as well. A random check, and a lightweight method of removing the autopatrolled flag, would be beneficial. Fram (talk) 15:08, 29 August 2023 (UTC)
That and more. IMO the right should be eliminated. Everybody needs a second set of eyes. Also it's sort of backwards who they give it to. Anybody who creates a large quantity of articles in the 22 year old encyclopedia is the one who needs the closest scrutiny yet those are the very people that they give it to. Sincerely, North8000 (talk) 15:22, 29 August 2023 (UTC)
Wouldn't a feed of all new pages created by autopatrollers be better? It would be easier to recognize patterns of misbehavior and wouldn't clutter Special:NewPagesFeed during times of backlog. Schierbecker (talk) 15:42, 29 August 2023 (UTC)
The New Pages Feed has a filter that can show all articles created by autopatrolled users. Schazjmd (talk) 15:52, 29 August 2023 (UTC)
When autopatrolled was first unbundled from admin, I gave it back to myself. I later decided that I do not create new articles often enough to burden NPP, and it is a good idea to have other eyes look at my creations, considering how bad I am at copyreading my own work. I do not see why any editor should object to having at least some of their new articles reviewed by NPP. Whether the new page reviewers want the extra work is another question. Donald Albury 16:24, 29 August 2023 (UTC)
Many many years ago, before I gave up doing npp myself (because it was soul-destroying and mostly futile), once per session, I'd deliberately seek out a page recently created by a username I recognized. I don't recall ever coming across the sorts of problems Fram has, but that was kind of the point - patrolling at least one known tolerable article after standing in front of the firehose of copyvios and self-promotion was good for my own sanity, even if I never had to do more than disambiguate a link or two, and mostly not even that much. —Cryptic 21:05, 29 August 2023 (UTC)
Nothing prevents anyone from review page creations by autopatrolled editors, they just don't show up as unpatrolled - anyone can view the list of new pages regardless of the patrolled status. — xaosflux Talk 22:29, 30 August 2023 (UTC)
Any possibility of it being tiered so the articles get handled as if they were auto-patrolled, but do not become indistinguishable from those that have been manually patrolled? Graywalls (talk) 19:57, 31 August 2023 (UTC)

The problems that I've seen is when they create large amounts of articles of certain types where it's an edge case at best that they should exist or rejected that they should exist when the community discovers it after the mass production. Then when one is questioned they say "but it's standard practice" and point to the zillion similar articles they or their group made which never went through NPP. These should be reviewed by someone or the community earlier in the that process. North8000 (talk) 21:19, 29 August 2023 (UTC)

I also found one, Louisa Henrietta de Rivarol, that isn't directly problematic, but involved the creator deleting the article that was present half an hour before creating a replacement article themselves. I'm not certain that was appropriate, but editors who are able to see the deleted version may be able to comment in more detail.
Overall, nine of dubious quality out of 25 is not a good ratio, and on that basis it would make sense to me to abolish autopatrolled - but S Marshall makes a good point, that increasing the workload of NPP by 33% is likely not a good idea. Perhaps instead if we tightened the rules around who could be given autopatrolled? BilledMammal (talk) 08:53, 30 August 2023 (UTC)
FYI the one deleted revision of Louisa Henrietta de Rivarol was a redirect to Antoine de Rivarol, created by the same user in 2014. Overall a pointless deletion but not actively bad AFAICT. Anomie⚔ 11:02, 30 August 2023 (UTC)
Ah, @Victuallers:. The edit summary "new stub based on ref given, Antoine de Rivarol and wikidata - a work in progress" is their attempt to indicate that they have literally copied text from Antoine de Rivarol. I have tried in vain to get them to comply with our "copying within Wikipedia" rules of attribution, and I have also in vain asked them to voluntarily relinquish their autopatrolled right (also because of Wikipedia:Contributor copyright investigations#Victuallers), and they are one of those editors where it would be very good if I wasn't the one always harping on about the shortcomings in these articles, but instead NP patrollers would look at them. The "pointless" deletion is probably because they are one a "create one article on women per day" streak, and turning a redirect into an article wouldn't count... Fram (talk) 11:21, 30 August 2023 (UTC)
I can remember trying to create an article a day. That didn't last long, and they were (and mostly still are) of rather poor quality. I don't know about how other editors work, but these days it takes me weeks or even months to get an article I've created from scratch ready for prime time, although I may be working on two or three at a time. Donald Albury 17:51, 30 August 2023 (UTC)
I also did one article per day at one point, the articles are fine but it was soul-crushing and took away all the joy of writing. Curbon7 (talk) 20:35, 30 August 2023 (UTC)
If 33% of new articles are made by autopatrolled users, this proposal would not increase the NPP workload by 33% but rather by 3.3%, because only a small fraction of autopatrolled users' articles would be put into the queue for patrolling. Also, autopatrolled users' articles are likely to be of better quality, so NPP on them would be easier. CapitalSasha ~ talk 17:43, 30 August 2023 (UTC)
That's true. I think I could support that but I'll want to see what NPP thinks.
We would also need to work out what to do when NPP does need to reject an article from an autopatrolled editor - how should that right be reviewed, and when should it be taken to review (after one rejected article? After several? After dozens?) BilledMammal (talk) 18:03, 30 August 2023 (UTC)
  • I'm a NPP'er and on the subject of workload and IMO and extra 3% or 30% addition of articles that clearly should be articles would be handle-able. But I suggest starting with just a sampling because I think that what will be uncovered will be a can of worms. I just scanned a bunch of autopatrolled articles and at first glance about 1/4 look like they either shouldn't be an article or are an edge case. For example, mass production of stubs on restaurants and stats-only sports articles. I think taking a sampling of these for review would be a way to explore this and sort it out. It could be pretty simple to implement. Just establish a norm of un-marking a random sampling of autopatrol articles. North8000 (talk) 21:28, 30 August 2023 (UTC)
    The idea of diverting a small proportion of autopatrolled articles back to NPP is an excellent one. There are all kinds of fancy ways to do this, but for starters something simple will be very informative, assuming someone (not me) is willing to code a bot. Before I make a detailed proposal, can someone get me a list of editor names and how many autopatrolled creations they made in the last 7 days, 30 days, 90 days, 180 days?
    Also, is there a volunteer experienced in writing bots or scripts who can help me work out what is or is not realistic in terms of what we ask the bot to do (particularly state it can remember from run to run)? EEng 22:07, 30 August 2023 (UTC)
    User list and creation counts. —Cryptic 23:04, 30 August 2023 (UTC)
    Great work, thanks, that's really helpful! I'm busy IRL so I'll need several days to think though a sampling approach that's simple but effective, with minimum added load to NPP. Two points:
    • During each of those periods, what was the number of creations that are subject to NPP review? (Sorry, should have thought of this before.)
    • The query's documentation mentions that only creations directly in mainspace are picked up, not e.g. pages created in Draft: or User: and then moved to mainspace. That's fine for present purposes, but if this effort goes somewhere then we'll need to circle back to that point. Someone make a note.
    EEng 05:48, 31 August 2023 (UTC)
    I'm a bit distracted IRL so I'll want several days to think over a sampling technique that will be simple but effective.
    Total pages created in the main namespace (with the same caveat about moves) is at quarry:query/76266. So non-autopatrolled creations are that minus the "--TOTAL--" row at the end of the previous query (roughly, since the sampling intervals started and ended a few hours later).
    Any sort of unpatrolbot wouldn't use a method like this to find which pages to unpatrol; it has to use the api anyway to unpatrol a page, so it would in all likelihood also use it to pull candidate pages directly from Special:NewPagesFeed. The backend tables for that are less convenient to datamine than the page creation log. —Cryptic 06:51, 31 August 2023 (UTC)
    I asked for the above so I could understand the amount of additional work that would be imposed by various possible sampling approaches. As long as NewPagesFeed can give me all creations by autoreviewed editors for the last X days, that's all that would be needed. My IRL distraction has become something of an emergency, so there will be some further delay on my end, unfortunately. EEng 07:04, 4 September 2023 (UTC)
    Mass-creating stats-only sportsperson articles should be grounds for AP revocation since that is explicitly against our guidelines. JoelleJay (talk) 00:56, 31 August 2023 (UTC)
    On the quick review I just made the stats-only sports articles were things like "The 2021 season of the XYZ team" with like one sentence and then all of the stats including results of all of their games for that year. North8000 (talk) 02:08, 31 August 2023 (UTC)
  • If sampling reveals autopatrolled editors creating poor-quality articles, that is certainly grounds for looking into removing autopatrol from the editors concerned, but I'm not sure it's grounds for diluting autopatrol itself. – Teratix ₵ 04:43, 31 August 2023 (UTC)
Autopatrolled discussions frequently seem very backwards to me, because most of them are premised on the idea autopatrolled doesn't mean anything to the editor with the right, and would change nothing about their experience. Given the entire purpose of NPP is that articles that are patrolled appear on search engine indices (which means, roughly, that they become the first hit for all eternity), this is backwards -- if anything there is no other unbundled right (and I'm not sure about the bundled rights) that has a bigger impact, because the rest are all definitionally backstage processes of less concern to readers. This is especially true when, for instance, writing on current events.
In general, AP and metadiscussions of it show a lot of the dissociation and disagreement in "what is NPP and what role does it serve in the project?". Albury's example stands out to me, because other eyes [...] copyreading my own work isn't in NPP scope. NPP is not another word for GAN (nor is AfC), and no one quite agrees on what the limit of NPP's concern should be, but it's fairly clear that higher-reading interpretations are part of what creates hesitancy to get involved and climbing of backlogs. WhatamIdoing I think has a fairly long explication of this. Because no one agrees what purpose NPP serves or what standards articles should be judged by, no one agrees what AP is either, even though it has an extremely clear and objective function from which its actual purpose (allowing articles that we know can skip the queue to skip the queue) should trivially spill out.
A side note on "NPP is not GAN, and not even low-reading GACR, and not anything at all like a quality assessment process": I just patrolled 2013 Midwestern U.S. floods, a GA. It managed to pass GAN before passing NPP. I think we can broadly agree that there's no reason an article that can pass an actual quality assessment process should be technically prohibited from search engine indexing. I would argue this (de jure or de facto) is exactly what "throw back in random articles of people who have demonstrated many times they can do that" is. Vaticidalprophet 07:21, 31 August 2023 (UTC)
  • False The OP claims that "it completely removes these editors' articles from the scrutiny of patrollers and new page reviewers". This is quite false. The new page feed shows all new articles and any editors can be specially selected for attention. The recent drama and the discussion above shows that there are plenty of patrollers who know no bounds in their enthusiasm to find fault. And New Page Patrol is just the start. There are many patrollers who work along other lines and so every page gets repeated attention from their grinding. As the outcome of the latest incident is not a happy one, we should not encourage more such conflict. Andrew🐉(talk) 08:16, 31 August 2023 (UTC)
  • On the whole I think I oppose this idea. It's a bit of a solution looking for a problem; as others have noted, NPPers can and do see autopatrolled editors' latest creations, and some of them do check some of those articles. I don't create new articles any more except for the occasional redirect expansion (though there are a few stored in my userspace), and I was always relatively unprolific for someone with the user right, but one day my latest was reviewed; I wish I could find it in my user talk archives, because what I remember is that the reviewer made a suggestion that was completely a matter of taste, and I felt a bit put out. However, that one is outweighed by the number of times I've had an article AfD'd or even nominated for speedy deletion, one each of those without even the courtesy of a user talk notification (both are back in / still in mainspace). Autopatrolled isn't an impregnable shield, or much of any shield in fact; ideas of suitability for an encyclopedia vary (indeed, our standards of notability are intentionally fluid at the edges and shift in response to discussions) and so, as Vaticidalprophet notes above, do ideas of what NPPers should be looking at and what standards they should apply. The notion of entrenched camps of "deletionists" and "inclusionists" locked in battle is a pernicious meme, but so is the notion that the encyclopedia is "nearly complete". There's a delicate balance between indulging bad actors and mistaken enthusiasts on the one hand, and discouraging editors willing and able to extend our coverage on the other—especially experts, who are particularly vulnerable to the "not interesting / not online / not in English / never heard of it" crowd. Personally, I regret the "professionalization" of NPP; it encourages eager editors to apply for the right so they can seek out problem articles, whereas it used to be something all experienced editors were encouraged to do, which integrated it into our normal shared editing processes. But that ship's sailed; and to be fair, nothing can stop Wikipedians from critiquing others' articles and in many cases tweaking them: for example, since that just came up, not merely tagging but fixing bare links, or for another example, years ago EEng was irked that I was doing n-dashes and m-dashes using HTML and out of the blue told me the alt+ keys to make them. But now that we have draft space, which can be used to oubliette an article, I suspect the annual drip of useful articles down the drain owing to well meaning patrollers is considerable, and any kind of blanket deprecation or discounting of autopatrol won't just increase the stress on teh NPPers who don't treat it like a shooting gallery, it will further unbalance things toward viewing new articles as a burden (which is how they are explicitly viewed on de.wikipedia).
    The actual problem, I believe, is with some editors who have the right. Some shouldn't have been given it (it may have been given purely on the basis of quantity of articles, for example), some have gotten away from our purpose or standards in some way (like the recent AN/I case, who turns out to have drifted into creating articles that were really intended for people living in a portion of their US state) or have continued to create articles reflecting a long-ago concept of notability and/or adequacy (Lugnuts' tiny stubs on participants in the Olympics based on a single database, not even looking for other grounds of notability or other sources). We don't need to cast the net of suspicion over all autopatrolled editors, or even to automatically sample the articles they create, to identify those problem editors; existing editorial scrutiny is enough, and is also fairer; the NPPer may identify a problem where there's just a recondite topic area or a non-templated referencing style. Rather, we need to act faster to inform such editors and get them to fix their articles when a problem is found; or to pull autopatrolled if they don't see the problem. That last discussion at AN/I was alarming both for the editor's elevated sense of the importance of the autopatrolled right, and for the number of editors not appreciating the problem. It may or may not fall within an NPPer's purview to identify WP:V failure; that's part of the problem, and we shouldn't single out autopatrolled editors to check their adherence to WP:V, or WP:N. This is a wiki, we should all be on the lookout and frankly, most of us are. But autopatrolled is indeed not so much a "right" as a safety valve for NPP, so in problematic cases, it should be easy go. Yngvadottir (talk) 09:24, 31 August 2023 (UTC)
    I'd add that a lot of the "most AP issues are from a subgroup of AP editors who get the right on volume" is a subset of the "no one quite agrees what NPP and AP are, in ways that get very detached from what they technically are" issue. There's a subset of editors who feel AP is best understood as essentially enwiki's take on the flood flag, specifically to avoid NPP numbers rising during high-intensity article creation. This is the most consistent understanding with how we talk about AP -- as something completely detached from individual editors and relevant only to the collective of unpatrolled articles. However, it's not one I share, because imo it neglects the "search engine indexing" core -- such articles aren't necessarily suitable for autoindexing. Vaticidalprophet 09:37, 31 August 2023 (UTC)

Consensus when policies/guidelines don't apply

Most of the time, RfCs concern whether a particular policy/guideline applies, how to apply it, how to interpret it, etc. When those discussions are closed, the closer is supposed to weigh the strength of policy/guideline-based arguments to assess consensus. But once in a while there's a question that's a purely preference-based editorial decision. "What order should these two paragraphs be in?" for example.

I'd like to throw out a suggestion: rather than close these based on a pure headcount, give more weight to the opinions of the people who actually contribute to the article. That is, the people most familiar with how it's written and the sourcing and who have wrestled with the many possibilities of how to summarize and present the information. Headcounts are fraught for a number of reasons, not the least of which being they weigh a preference based on kneejerk reaction or whim as equal to a preference informed by hours/days of work.

In some areas, we already have a precedent of deferring to the active article writers and/or the creator, such as with WP:CITEVAR/WP:ENGVAR. Sometimes there's a policy/guideline-based reason for consensus to go against those who write the article, which isn't what I'm talking about; I'm talking about when it's purely down to preference.

It occurs to me this sounds like I'm talking about infoboxes. I suppose I could be, but I'm not. Points to anyone who responds without just linking to WP:OWN. :) — Rhododendrites talk \\ 14:30, 2 September 2023 (UTC)

I can see the reasoning behind this suggestion. But I also see it as a potential problem. It's not uncommon for an RfC to be started because the "contributing" editors have become entrenched in a specific approach that walls out reasonable criticisms and suggestions for changes. The RfC encourages input from uninvolved editors (with the assumption that they'll provide objective input) to break that logjam. Being "familiar with how it's written" can be both a strength and a weakness; they [should] know the content and the sources better than those reading it for the first time, but that same familiarity can sometimes lead to tunnel vision and status quo bias. RfC closers should weigh the strength of arguments even when policies/guidelines don't apply without arbitrarily discounting or overemphasizing arguments solely based on who made them. Schazjmd (talk) 15:45, 2 September 2023 (UTC)
reasonable criticisms and suggestions for changes Sure, but the premise here is a situation where there's no clear policy/guideline reason and we're talking about different purely preference-based solutions. Why should a group that hasn't worked on the article be able to force their preference? I'd argue that stonewalling is only really a problem when we're talking about applying policy (e.g. how to neutrally write a passage, whether WP:NOT applies to a specific section, etc.). At the end of the day, though, I wouldn't argue with RfC closers should weigh the strength of arguments even when policies/guidelines don't apply. — Rhododendrites talk \\ 18:18, 2 September 2023 (UTC)
I think this is bound to incentivize WP:STONEWALLING and runs counter to the spirit of WP:CONSENSUS. It would also almost certainly reduce the acceptance of RfC outcomes and lead to a lot of uncertainty and the unnecessary drama that comes with it. -- Random person no 362478479 (talk) 17:26, 2 September 2023 (UTC)
Looks like an efficient way to generate a whole new set of arguments about what constitutes an 'active article writer', thus making it harder to resolve issues. AndyTheGrump (talk) 17:29, 2 September 2023 (UTC)
Meh. There would be a lot of gray area, but especially for topics that don't get a lot of eyeballs, it's not uncommon for 1-3 people to have written >90% of the article based on xtools or for there to be an obvious falloff. It's even easier to tell when someone hasn't had any involvement at all. And within the gray areas, I for one wouldn't be sad if there emerged a pattern to "game" such an "active article writer" requirement by actually making some improvements to the article first. — Rhododendrites talk \\ 18:18, 2 September 2023 (UTC)
When there are no other considerations (caveat to come later) other than "I like it this way" reasoning, I agree that groups of interested editors should be able to decide for themselves the best way of proceeding. This probably comes up more often with implementing processes and procedures than mainspace content. In mainspace, the examples I can think of relate to content that has to be updated regularly, like some navigation boxes, and information about ongoing events/campaigns/competitive seasons. In general, I don't like one set of editors deciding to give an ongoing bill to a different set of editors for them to pay on a matter that doesn't impose an undue burden on the general community. I acknowledge, though, that there are lots of ways a certain decision might affect the overall maintainability of the project, and so there's a balance between what works well for interested editors and what is reasonable for the editing population at large. (Infoboxes don't fit into the type of decisions I'm thinking of, as they are more of an upfront cost than an ongoing one.) isaacl (talk) 17:34, 2 September 2023 (UTC)
One would have to define "actually contribute to the article". Does one edit in the past year count as "actually contributing"? 5 edits in the past 6 months? If this were a guideline, I see opportunity for this to be abused, wherein the loudest and most focused editors drown out those who are less "active". Also, I believe there is already a problem on Wikipedia with small sub-communities forming around articles and "guarding" them. I'm skeptical of any idea that takes power away from the broader community and puts it in the hands of those who are the most "active" - sometimes, the actions of the most active contributors to an article are precisely the reason why broader community input is required. Even if it is about something as innocuous as "in which order should we arrange these paragraphs?", a neutral set of eyes, from someone uninvolved with the article's creation, can actually be better than leaving such things to those who wrote the content - that's why most published authors don't copyedit their own works. Pecopteris (talk) 19:35, 2 September 2023 (UTC)
There has always been a tension between the concept of the encyclopaedia as a compendium of knowledge and the concept of an encyclopaedia that anyone can edit. Many people feel the latter entitles them to their own facts, and consider their ignorance to be equal to your knowledge. This form of anti-intellectualism is often widely accepted in the culture they come from. More importantly, they have numbers and support in the broader community, most of who do little actual editing. Hawkeye7 (discuss) 00:02, 3 September 2023 (UTC)
I think the xtools authorship pie chart is generally pretty good at showing which editors have contributed to an article, although it cannot differentiate between content and markup syntax. User:Pecopteris, I think you might be using a second definition of active editor: I read the original idea as distinguishing between editors who have put greater or lesser amounts of work into the article; the second definition seems to be centred around talkpage activity? There will likely be some overlap, but also some outliers. Folly Mox (talk) 06:56, 3 September 2023 (UTC)
I can think of many discussions where this would have been a very bad decision. All editors have a POV, and those involved in an article are those most likely to have the strongest opinions about the topic. Surely one of the purposes of an RFC is to bring in uninvolved editors, isn't that why notifications happen. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:01, 2 September 2023 (UTC)
I assume this relates to the Barbenheimer RfC and the post RfC discussion where you discuss how the most prolific contributors to that discussion had made minimal contribution to the article, and per my close the result was a purely preference-based editorial decision?
I sympathize with the frustration with that discussion. However, for the most part I think it is beneficial to bring in uninvolved editors, even when our policy and guidelines are silent on the question. I also think that trying to weight !votes in this manner is likely to cause considerable drama, and I don't think the drama is worth it. BilledMammal (talk) 15:36, 3 September 2023 (UTC)
Just to say while it was inspired by the Barbenheimer RfC, what I'm floating wouldn't actually have affected it -- there were active editors on either side of the dispute and I'm not objecting to it. — Rhododendrites talk \\ 21:26, 3 September 2023 (UTC)
  • I am concerned that this proposal would encourage WP:OWNERSHIP. Blueboar (talk) 16:20, 3 September 2023 (UTC)
The main contributors to the article probably already have enough of an advantage in disputes. They will have set the status quo, which puts them on the right side of a “no consensus to change” close. Barnards.tar.gz (talk) 18:54, 6 September 2023 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_50&oldid=1179082437"