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

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

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

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

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

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

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

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

I’m not the one you have to convince. Blueboar (talk) 17:45, 22 June 2023 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

What principle? I’m confused which comment you’re replying to Dronebogus (talk) 22:41, 23 June 2023 (UTC)[reply]

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

I did not know that. What is the principle we’re working with here? Dronebogus (talk) 22:43, 24 June 2023 (UTC)[reply]

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

@Phil Bridger, I would suggest the word " greatly unethical" as perhaps more accurate than "morally objectionable." Sm8900 (talk) 13:34, 26 June 2023 (UTC)[reply]

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

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

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

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

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

  would you like to suggets some dieas for a possible policy, @Visviva? thanks. Sm8900 (talk) 17:07, 14 July 2023 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Oppose solution in search of a problem. Headbomb {t · c · p · b} 17:37, 5 July 2023 (UTC)[reply]
• 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)[reply]
• 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)[reply]

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

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

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

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

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

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

We really should improve the move dialog. —Kusma (talk) 21:57, 5 July 2023 (UTC)[reply]

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

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

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

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

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

  PT:? PJ:? Edward-Woodrow :) _[talk] 13:13, 12 July 2023 (UTC)[reply]

  WP: for "Wikipedia Project", since we're used to that? Certes (talk) 14:15, 12 July 2023 (UTC)[reply]

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

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

See the proposal

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

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

Require that sources with broad usage are listed at WP:CENT and linked from WP:VPP? BilledMammal (talk) 16:36, 9 July 2023 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

See ((Monarch of New Zealand, current)).-gadfium 20:58, 13 July 2023 (UTC)[reply]

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

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

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

Start here: Wikipedia:Perennial_proposals#Hierarchical_structures. -- zzuuzz ^(talk) 22:40, 20 July 2023 (UTC)[reply]

Well, that makes sense. Thanks. Edward-Woodrow :) _[talk] 22:47, 20 July 2023 (UTC)[reply]

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

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: [1].)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  That looks like a very nice feature, I look forward to trying it out. Thanks! Mathglot (talk) 07:49, 27 July 2023 (UTC)[reply]

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