Jump to content

Wikipedia:Village pump (idea lab)

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

Before commenting, note:

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

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65


[edit]

For topics which may not yet meet Wikipedia's inclusion criteria for articles, but for which relevant information is present across multiple articles (such that an editor may have difficulty deciding which page to redirect to), there should be a type of mainspace page dedicated to listing articles in which readers can find information on a given topic. A page of that type would be distinct from a disambiguation page in that, while disambig pages list different topics that share the same name, a navigation page (or navpage) would include a list of articles or sections that all contain information on the exact same topic. In situations where a non-notable topic is covered in more than one article, and readers wish to find information on that particular topic, and that topic can't be confused with anything else (making disambiguation unnecessary), and there turns out to be two or more equally sensible redirect targets for their search terms, then a navpage may be helpful.

Rough example #1

Wikipedia does not have an article on the Nick Fuentes, Donald Trump, and Kanye West meeting, but you can read about this topic in the following articles:

You can also:

Rough example #2

Wikipedia does not have an article on Anti-Bangladesh disinformation in India, but you can read about this topic in the following articles:

You can also:

Besides reducing the prevalence of red links, navpages can also be targets for other pages (e.g. Trump dinner) to redirect to without being considered double redirects. – MrPersonHumanGuy (talk) 16:23, 13 March 2025 (UTC)[reply]

This is a cool idea! Toadspike [Talk] 11:51, 18 March 2025 (UTC)[reply]
I also agree! I'm thinking some disambiguation pages tagged with {{R with possibilities}} could make good navigation pages, alongside the WP:XY cases mentioned above. At the same time, we should be careful to not have any "X or Y" be a navigation page pointing to X and Y – it could be useful to limit ourselves to pages discussing the aspects together. Chaotic Enby (talk · contribs) 13:26, 18 March 2025 (UTC)[reply]
Good idea – people seeing the nav page and how it is split across more than one article could also help drive creation of broad-topic articles. Cremastra (talk) 23:40, 18 March 2025 (UTC)[reply]
Also noting that the small text If an internal link led you here, you may wish to change the link to point directly to the intended page. might not necessarily be needed, as it can make sense to link to navigation pages so readers can have an overview of the coverage, and since that page might be the target of a future broad-topic article. Chaotic Enby (talk · contribs) 23:50, 18 March 2025 (UTC)[reply]
This seems a useful idea. As a similar example I'd like to offer Turtle Islands Heritage Protected Area, which I created as an odd disambiguation page because it was a term people might search, but with little to say that wouldn't CFORK with content that would easily fit within both or either or the existing articles. CMD (talk) 01:32, 19 March 2025 (UTC)[reply]
This is great. I often edit articles related to PLAN ships, and since many ships currently lack articles, we cannot use disambiguation pages for those ships(e.g. Chinese ship Huaibei, which has two different frigates with the same name). This could really help out a lot. Thehistorianisaac (talk) 03:33, 21 March 2025 (UTC)[reply]
This seems like a useful idea. It would benefit readers and probably save time at RFD and AFD. Schützenpanzer (Talk) 15:16, 22 March 2025 (UTC)[reply]
Throwing my support behind this as well. It would be very useful in cases where AFD discussions find consensus to merge the contents of an article into multiple other articles. -insert valid name here- (talk) 05:01, 3 April 2025 (UTC)[reply]
I've just come across Ethiopia in World War II, which is effectively already doing this under the guise of a WP:SIA. CMD (talk) 08:13, 13 April 2025 (UTC)[reply]
Should I WP:BOLDly create {{navigation page}} and put it there? Chaotic Enby (talk · contribs) 12:20, 13 April 2025 (UTC)[reply]
This would be very bold, but no opposition has been raised? If you do, please put it on Turtle Islands Heritage Protected Area too. CMD (talk) 00:10, 14 April 2025 (UTC)[reply]
Done for both! About the technical aspect of things, I added the "you can also search..." in the template (as it could be practical) but it might look less than aesthetic below a "See also" section. I made it into an optional opt-in parameter, is that fine? Chaotic Enby (talk · contribs) 07:34, 14 April 2025 (UTC)[reply]
Also did it for Nick Fuentes, Donald Trump, and Kanye West meeting, with a hidden comment to not convert it into an article per AfD consensus. Chaotic Enby (talk · contribs) 08:07, 14 April 2025 (UTC)[reply]
If this sort of page type is to be used for topics without independent notability (including deleted through an AfD), perhaps it should just drop that part and simply say "You can read about the Nick Fuentes, Donald Trump, and Kanye West meeting in the following articles"? Those with the potential to be expanded could be integrated into the hidden Template:R with possibilities system or something similar. CMD (talk) 08:50, 14 April 2025 (UTC)[reply]
I already added a parameter for that part (on the Fuentes-Trump-West meeting, the link inviting to create the article is not present). But yeah, removing it entirely as an optional parameter could also make sense. Chaotic Enby (talk · contribs) 08:53, 14 April 2025 (UTC)[reply]
Also thinking about the Poor people's rights search below, removal seems best. Alternatively, flipping it so that it is the prompt to create a page that is the optional addition might provide the desired goal while erring on the side of not encouraging creating poorly scoped articles. CMD (talk) 01:49, 15 April 2025 (UTC)[reply]
I also decided to take the liberty of creating a new category and another page (albeit an essay in development) to go along with the new page type. – MrPersonHumanGuy (talk) 01:41, 15 April 2025 (UTC)[reply]
Great job! Just wondering, it makes sense for topics that might be notable but haven't yet been written about (such as Ethiopia in World War II) to be navigation pages, should that be included in the graph? (Also, wondering if this whole conversation should maybe be moved to Wikipedia talk:Navigation pages instead of being pinned here) Chaotic Enby (talk · contribs) 16:10, 15 April 2025 (UTC)[reply]
Also, once that is all done, we should probably update {{Dmbox}} so navpages are a parameter, to avoid them being automatically detected as disambiguations (although that's not really that big of a deal). Chaotic Enby (talk · contribs) 16:15, 15 April 2025 (UTC)[reply]
I think we should decide early on, should this be allowed to have some context or info like WP:SIA? Maybe some content, which not enough for notability (the reason why it's not an article)? ~/Bunnypranav:<ping> 12:04, 15 April 2025 (UTC)[reply]
Yes, I think the amount of info allowed for SIAs should be the minimum along with a brief outline of the topic. Thryduulf (talk) 12:34, 15 April 2025 (UTC)[reply]
@MrPersonHumanGuy Could you possibly implement this in the draft you are writing? :) ~/Bunnypranav:<ping> 14:05, 15 April 2025 (UTC)[reply]
I'm wondering if Poor people's rights, currently being discussed at Wikipedia:Redirects for discussion/Log/2025 April 13#Poor people's rights, might be a candidate for this sort of page? Thryduulf (talk) 10:26, 14 April 2025 (UTC)[reply]

I am not convinced this is a good idea. Of the existing navpages, I boldly redirected Ethiopia in World War II; Armand Biniakounou, Glove and Boots, Amari McCoy, Turtle Islands Heritage Protected Area, and Skillsville all just feel like poor man's duplicates of search that will inevitable go out of date as the will to maintain them won't exist; Goldie (TV series) only isn't that because the term is ambiguous, and the only exception is Nick Fuentes, Donald Trump, and Kanye West meeting. * Pppery * it has begun... 16:37, 18 April 2025 (UTC)[reply]

I also have some concerns about navigation pages. They do indeed seem like they could require a lot of maintenance (especially if they are linking to sections. renaming a heading would break the links). It also seems like this could encourage fragmentation. Perhaps the better approach would be to pick one spot for something like Nick Fuentes, Donald Trump, and Kanye West meeting (pick a section in one of the articles), and redirect to that. Perhaps {{Navigation page}} might need to go to TFD to have a wider discussion to determine if it has consensus. –Novem Linguae (talk) 18:53, 18 April 2025 (UTC)[reply]
I am also unconvinced this is a good direction of travel. The article on the meeting of these three men was deleted; if we think this is a worthy article title, shouldn't we just have the article? There is a longstanding tradition at WP:RFD to delete ambiguous redirects and to rely on our search function instead, see WP:XY. Do we really want to have "navigation pages" for every single sports rivalry (mentioned in articles about both teams), relations between countries that do not suffice for a separate article? Amari McCoy is just bad: it is a bluelink that should be a redlink to show we do not have an article, and it is impeding the search function. If an article could potentially be created, a "navigation page" will impede actual article creation and (in the future) deny the creation credit (and the relevant notifications) to the actual article creator. —Kusma (talk) 19:17, 18 April 2025 (UTC)[reply]
Amari McCoy just looks silly. Why are there references all over a navigation page? That looks like a stub article to me. ~WikiOriginal-9~ (talk) 19:20, 18 April 2025 (UTC)[reply]
Additionally the "navigation page" hides the existence of Draft:Amari McCoy, which would be visible when visiting the red link. —Kusma (talk) 21:41, 18 April 2025 (UTC)[reply]
I would be okay with this one being deleted, as it doesn't actually contribute to navigation in any useful way (none of the target articles do more than list her as one of many actors). However, I mildly disagree with your point about article credit, as it isn't meaningfully different from the current situation with redirects. More generally, I do believe that navigation pages could be useful in a specific case (where there is a substantial amount of information about the same topic on several pages), but that they shouldn't abused to link to every single page that namechecks a subject. Chaotic Enby (talk · contribs) 23:14, 18 April 2025 (UTC)[reply]
I don't think redirects should be given creation credit either. ~WikiOriginal-9~ (talk) 23:17, 18 April 2025 (UTC)[reply]
I think we agree on the point that creating a redirect/navpage shouldn't give you creation credit. But that alone doesn't mean the page type shouldn't be kept, otherwise one could argue that redirects should be deleted for the same reason. Since navpages are functionally intended as multi-redirects, I believe the analogy especially makes sense. Chaotic Enby (talk · contribs) 23:25, 18 April 2025 (UTC)[reply]
I also agree. Even though I created The Book of Bill as a redirect, it was Googabbagabba who ultimately filled it with meaningful article content and thus the one who should've been notified when the article was linked with a Wikidata entry. Nonetheless, I don't think "another editor wants to create an article under this title" would be considered valid rationale for deleting a redirect or navpage. – MrPersonHumanGuy (talk) 00:16, 19 April 2025 (UTC)[reply]
I'd also seen Goldie (TV series) and think it looks like an unholy amalgam of a stub article and a navigation page: it should be one thing or the other, not both. I suppose my principal concern is that permitting adequately-sourced and verifiable content about an otherwise non-notable subject in a legitimate navpage is effectively quite a backdoor to a Wikipedia article about a non-notable subject. Cheers, SunloungerFrog (talk) 20:12, 18 April 2025 (UTC)[reply]
The Goldie page is ridiculous; it should just be a stub. I think navpages have a very specific application: a topic that for whatever policy-based reason does not belong in mainspace as a standalone page but is discussed in multiple pages. I would oppose them having any references or additional formatting at all. It should basically a multiple-choice redirect. Dclemens1971 (talk) 20:44, 18 April 2025 (UTC)[reply]
For the avoidance of confusion, I've turned the page into a stub because it is. Old revision that everybody's talking about is here: Special:Diff/1286214323. GreenLipstickLesbian💌🦋 21:09, 18 April 2025 (UTC)[reply]
Yep, agree with you. I would even clarify that the subject should be discussed relatively in-depth in multiple places, so we don't get lists of articles that namedrop a subject like Amari McCoy. Chaotic Enby (talk · contribs) 23:16, 18 April 2025 (UTC)[reply]
  • Housekeeping note: I've notified WP:WikiProject Disambiguation about this discussion. Mathglot (talk) 23:11, 18 April 2025 (UTC)[reply]
  • I didn't really expect this to go anywhere so I'll now elaborate on "This is a cool idea!". I think these pages can fill a narrow but present gap in our page ecosystem. Essentially, topics where there is more than one possible redirect target about the same subject, which distinguishes them from DABs, which have more than one possible redirect target about different subjects.
Also, since it's relevant to this discussion, I closed an AfD as "Navify" earlier today – feedback from others on the close and the resulting nav page (Armand Biniakounou) would be appreciated. I thought nav pages had been fully approved by the community, but I was clearly mistaken – if I had known that this is still being discussed, I may have closed this AfD differently or not at all. Toadspike [Talk] 00:07, 19 April 2025 (UTC)[reply]
I also misjudged consensus the same way, and that caused me to get carried away until I checked this page again and learned that not everyone was on board with the whole navpage idea, at which point I decided to pull the brakes and stop creating any more navpages. As for Amari McCoy, the fact that two stubs were being suggested for navification was what gave me enough guts to create that navpage in the first place. My reasoning was that "If these athletes can get navpages even though other articles only mention them as entries in lists, then that logic can be applied to other topics as well." In hindsight, that may not have been such a good idea after all. – MrPersonHumanGuy (talk) 01:06, 19 April 2025 (UTC)[reply]
I think your approach was reasonable. Sometimes you need to ramp up a bit to get wider community feedback. I didn't make a decision about this idea until I saw some actual articles with the template. Anyway thank you for stopping now that this is becoming a bit more controversial. –Novem Linguae (talk) 01:13, 19 April 2025 (UTC)[reply]
  • I think the gun was kind of jumped with this, though the topic was posted one month ago. Some more voices weighing in on this would likely be helpful. --Schützenpanzer (Talk) 00:15, 19 April 2025 (UTC)[reply]
  • Chaotic Enby mentioned something above about namedropping a subject, which seems to be similar to something I've been mulling over, and trying to decide how to formulate my concern. Let me start by turning your attention to the issue of WP:NOTTRIVIA just for a moment. I know there are lots of editors who love to dig up every place their fave character was ever mentioned, and there are folks on all sides of the question of sections like "FOO in popular culture". I remember how discouraged I was when I found that the relatively short article on a medieval French poet was about 50% allusions to modern popular culture items which in my view contributed nothing to an understanding of the poet. When you have a good search engine, it becomes trivial to dig up obscure allusions of this type, and so people do.
Transfer that thought now to the nav page concept. At first blush, it kind of seems like a good idea, but how might it morph in the future, and are we maybe opening Pandora's box? Suppose the good guys all do it the right way for a while, and then enthusiastic new editors or SPAs or Refspammers or social media types get wind, and all of a sudden it explodes in popularity and these pages become heavy with idiosyncratic additions based on somebody's fave niche reference? Will we end up needing new guidelines to specify what is or isn't a proper entry? Are we setting ourselves up for a possible giant future maintenance burden for regular editors? Mathglot (talk) 00:53, 19 April 2025 (UTC)[reply]
That is indeed a very good point, and this is why we should, in my opinion, have these guidelines ready before having navpages deployed on a large scale. While every new article or page can be seen as a "maintenance burden", navpages should fill a very small niche: subjects where in-depth content can be found on several pages, but which do not fit the notability guideline by themselves. This should be a much stronger criterion than simple mentions, and likely only apply to borderline cases where notability isn't very far away. Chaotic Enby (talk · contribs) 10:51, 19 April 2025 (UTC)[reply]
Do you have a single example of a subject where we should really have such a navigation page? Everything we have above is "mentions" (we certainly shouldn't allow those, or we will soon have thousands of genealogy stubs on non-notable minor nobility disguised as "navigation"), with the longest discussions being those of the "meeting" above, which are a short paragraph each and fairly repetitive with little critical commentary. If that is the best use case for the concept, I think the negatives strongly outweigh the positives for this idea. —Kusma (talk) 11:36, 19 April 2025 (UTC)[reply]
It was a better situation for Ethiopia in World War II, which probably could be an article, but in the meantime the various links would have been very helpful to readers. Now it is a redirect to an article subsection covering a time period mostly before WWII that also does not cover most of WWII. CMD (talk) 12:49, 19 April 2025 (UTC)[reply]
The classic solution "just write a stub" still looks superior to having a "navigational" pseudo-article to me in that case. —Kusma (talk) 13:07, 19 April 2025 (UTC)[reply]
The stub is much less helpful than some very simply laid out links to multiple not-stubby articles. CMD (talk) 13:15, 19 April 2025 (UTC)[reply]
I agree that the navigation page at Ethiopia in World War II was much more helpful than the current redirect, and I'm not sure what benefit a stub would bring given that we have existing coverage of the topic in multiple places already. Thryduulf (talk) 13:57, 19 April 2025 (UTC)[reply]
I also agree this navpage was better than a redirect. Skarmory (talk • contribs) 05:13, 21 April 2025 (UTC)[reply]
Maybe "just write a stub" situations should be encouraged to have See also links pointing to potentially useful targets. Skarmory (talk • contribs) 05:10, 21 April 2025 (UTC)[reply]
@Kusma Do you think the navpage (Armand Biniakounou) resulting from the AfD I linked is a good use? The two articles it links to don't have in-depth content, but there were two equally-good redirect targets and a consensus to redirect. Toadspike [Talk] 16:17, 19 April 2025 (UTC)[reply]
I think that is terrible. The bluelink promises we have nontrivial information, but there is only a trivial mention in a table. This is what fulltext search is made for. —Kusma (talk) 19:27, 19 April 2025 (UTC)[reply]
Very true. But – and I'm trying to understand the entirety of your argument, not be contrarian – the alternative is a redirect to one of the two bluelinks. This would equally promise nontrivial information, except it only provides half of the information we have.
In this case there was consensus to preserve the edit history; the need for a placeholder limits our options. Toadspike [Talk] 19:46, 19 April 2025 (UTC)[reply]
Speaking not from a Wikipedian's perspective but a reader's perspective, I would be annoyed by that article. The formatting's a bit weird, and it's trying to tell me that it's not an article, but I can see very clearly with my own two eyes that it's just a short article that tells me this man has been in the Olympics, twice. Despite the promise in the template, clicking on those links does not give me any additional information about him. Also, there's a bunch of unsourced biographical details in the categories? My reader self doesn't understand why those aren't in the article. Additionally, I can only see those facts in desktop view, so if I send the article to my friend to tell them that Wikipedia says this sprinter was born in 1961, they're going to be very confused.
On a related note, I think understand ATDs in an abstract way, but it's very annoying when you're a reader, you're trying to look something up, you know Wikipedia used to have an article about the subject, but now you find yourself on a nearly unrelated page that doesn't seem to mention the topic at all? Or, if it does, only very briefly as one entry in a table? It's very frustrating and I don't like it. GreenLipstickLesbian💌🦋 20:06, 19 April 2025 (UTC)[reply]
I agree with Chaotic Enby, would would add a second type of use: Where two or more notable concepts are covered in separate Wikipedia articles but common searched for together - see WP:XY and Wikidata's "Bonnie and Clyde problem". Thryduulf (talk) 11:46, 19 April 2025 (UTC)[reply]
Turtle Islands Heritage Protected Area looks like an example of this type of use in action. – MrPersonHumanGuy (talk) 13:51, 19 April 2025 (UTC)[reply]
Yes, that's a good example. Thryduulf (talk) 13:58, 19 April 2025 (UTC)[reply]

Metadata gadget as the default experience

[edit]

Is there technical feasibility for including any part of the Metadata gadget in the default experience, or must it remain a gadget?

There seems to be a perennial wish amongst FA/GA contributors to make quality a more visible part of articles, for a number of reasons. The current experience, a topicon, seems to be considered too little. Previous discussions:

I think a good way to resolve this would be to get the FA, FL, and GA experiences from the metadata gadget into the default browsing experience for all users. Having at least the text A featured article from Wikipedia, the free encyclopedia at the top of FAs would certainly make it more explicit to readers, and the wikilink (with a statistical redirect) to Wikipedia:Featured articles would serve the purpose of explaining what the FA process is (many oppose !votes in the above discussions hinged on reader confusion) as well as draw in interested editors (many others in the above discussions mentioned becoming interested in editing after learning about FA/GA).

This would surely be a very contentious RfC if proposed, but I'm not even sure if it's technically possible in MediaWiki, since it currently works via a fairly slow JavaScript gadget. Does anyone know if it would be possible to integrate this experience more deeeply? Dan Leonard (talk • contribs) 21:03, 20 March 2025 (UTC)[reply]

I would support this RfC. Cremastra talk 17:17, 28 March 2025 (UTC)[reply]
I wonder what the WP:PERFORMANCE implications of running that gadget millions of times would be.
Perhaps of more importance: Do we really want Another stub from Wikipedia, the free encyclopedia on about half of the articles?
Combining the two concerns, I suggest that if folks want to celebrate the FA/FL/GA status more, that should be done with ordinary templates that can be added to the individual articles. For example, expand Template:Featured article. WhatamIdoing (talk) 01:52, 30 March 2025 (UTC)[reply]
Perhaps of more importance I think we do. Given we already have stub icons, adding that text under the title is just further incentive for more people to contribute.
Besides, stubs don't make up so many of the most-viewed articles, based on this data I just pulled out of my hat. Cremastra talk 03:06, 30 March 2025 (UTC)[reply]
I don't think that's actually an "incentive" for more people to contribute. WhatamIdoing (talk) 22:55, 31 March 2025 (UTC)[reply]
What do you think is an incentive for contributors, then? Redlinks, annoyning orange banners, tags, and stub categories are all at least partially aimed at getting people to hit the "edit" button for the first time. Cremastra talk 23:06, 31 March 2025 (UTC)[reply]
I don't think those are incentives. Some of them are invitations, but that's different.
For some of us, the incentive is making the internet suck less. Our response to someone being wrong on the internet is to add information where it can be found. For some of us, the incentive is a COI, or something next door to it. I could imagine, for example, someone getting tired of explaining some basic point about their industry/personal interest, so they try to share that information here. For others, it's because our friends are here, and you want to support your community's goals and get social status. Those people sometimes engage in Wikipedia:Hat collecting, but they also slog through difficult situations. Still others' incentive is to stave off boredom or to feel productive.
An incentive is what you get out of it. You don't get anything out of a stub tag. WhatamIdoing (talk) 00:48, 1 April 2025 (UTC)[reply]
The incentive to see an article say "A-class", the incentive to see an article not say "stub". Aaron Liu (talk) 01:01, 1 April 2025 (UTC)[reply]
So the incentive is that you get to feel pride at causing the removal of a badge of shame (except that none of our maintenance tags are supposed to be treated like badges of shame). Sure, I suppose that would motivate some people. WhatamIdoing (talk) 01:12, 1 April 2025 (UTC)[reply]
It ain't much more a badge of shame than the maintenance tag. Aaron Liu (talk) 16:27, 1 April 2025 (UTC)[reply]
Maybe. But the rating would be on every article, without an individual editor thinking that would be helpful for that particular article. And we do see people adding certain maintenance tags because they want to "warn the reader" or because they didn't get their way in a dispute. WhatamIdoing (talk) 17:41, 1 April 2025 (UTC)[reply]
Second. Greater visibility of our better articles is a great thing, and this gadget does it well. Would support this. A star or plus sign means nothing by itself, but the difference between "an article" and "a featured/good article" at least tells the reader something meaningful. JackFromWisconsin (talk | contribs) 03:47, 21 April 2025 (UTC)[reply]
GA, A, and FA are probably roughly fine more accurate than not, however the rest of the ratings are likely of more variable accuracy. A side-effect of them being not that impactful is they often aren't updated. Anecdotally, not a small number of articles are classed as stubs simply because they haven't been updated since the articles were stubs. Displaying these ratings to the reader may give an air of officiality, giving the ratings a meaning we don't want to give them ourselves. CMD (talk) 01:23, 1 April 2025 (UTC)[reply]
I'd like to reiterate that this request is for technical feasibility of an experience similar to the metadata gadget using MediaWiki, not running the current JavaScript gadget. I'd also like to reiterate that it's specific to good and featured content only, as it derives from previous discussions. On the technical feasibility side, I think it'd require mw:Extension:CustomSubtitle embedded within {{Good article}} and {{Featured article}}, but it'd likely require security updates to restrict its use. Dan Leonard (talk • contribs) 15:40, 10 April 2025 (UTC)[reply]
You don't need a consensus discussion to investigate making a software thing without considering whether the community would want it. It's something developers are usually encouraged to just do; try MediaWiki channels if you need help since VPT deals little with non-enwiki-specific backend stuff. Aaron Liu (talk) 16:06, 10 April 2025 (UTC)[reply]
mw:Project:Support desk might be the right place to ask questions about whether that extension would require changes. WhatamIdoing (talk) 17:28, 10 April 2025 (UTC)[reply]
I'm not asking for development on anything, I’m asking if anyone knows whether it's possible at all. Dan Leonard (talk • contribs) 18:30, 10 April 2025 (UTC)[reply]
Anything is possible as long as you develop it. If you mean whether it's possible without changing the current backend (WMF) setup and do not want to involve the usual questions on "should we", that's usually a question for VPT. Using CustomSubtitle would modify the backend. A much more efficient way would probably be modifying mw:Extension:PageAssessments to add a parser function that returns the page class and then putting that parser function in MediaWiki:Tagline. Aaron Liu (talk) 21:28, 10 April 2025 (UTC)[reply]
Oh cool, thanks, that's exactly what I was looking for! I didn't realize there was a MediaWiki extension behind assessments, I thought it was just a relatively simple template design where the |class= parameter of {{WikiProject banner shell}} changes the talk box text and image. I'll read up on the PageAssessments extension and see what's possible there, and then if I can do it myself I'll re-propose a more complete idea here or at one of the other village pump sections. Dan Leonard (talk • contribs) 21:42, 10 April 2025 (UTC)[reply]
No problem! It was just a template, but later the PageAssessments tool was reason so that e.g. you can query assessments by API better and the template was adapted to support PageAssessments. Note that it does not have said parser functions needed yet and you'll have to code or get someone to code the parser functions. Aaron Liu (talk) 21:55, 10 April 2025 (UTC)[reply]
Looks like Module:Page assessment has already been implemented to do just this. Given that modifying the sitewide tagline would run this function a lot, would a parser function built directly into the MediaWiki extension be more efficient, or is this Lua module essentially the same thing? It doesn't look like it's using the API, and is just parsing the wikitext, but I'm not well versed in Lua to be certain. Dan Leonard (talk • contribs) 22:23, 10 April 2025 (UTC)[reply]
Evad37 wrote the module, but has been off wiki for about two months. You should ask technical questions like this at Wikipedia:Village pump (technical). WhatamIdoing (talk) 03:12, 11 April 2025 (UTC)[reply]
As it's trivial retrieval of information, making it a parser function would almost always be better. And getting the wikitext of the associated talk page is effectively querying the API, except it's querying all the wikitext instead of just the pre-stored page assessment class. Aaron Liu (talk) 13:27, 11 April 2025 (UTC)[reply]

Removing "Month and Day" from date of the leading sentence of articles about humans

[edit]

Hi, according to Occam's razor or the "principle of parsimony", the first line of articles should only contain the main important data and does not contain any "less important" data. For example, in the article Steve Jobs, the leading sentence is:

Steven Paul Jobs (February 24, 1955 – October 5, 2011) was an American businessman, inventor, and investor best known for co-founding the technology company Apple Inc.

Here, I think "February 24" and "October 5" are not so much important to be included in the leading sentence of this article. So, according to "principle of parsimony", I propose to remove that, which yields:

Steven Paul Jobs (1955 – 2011) was an American businessman, inventor, and investor best known for co-founding the technology company Apple Inc.

I think removing such data makes the article and its leading sentence more usable and practical. These "Month and Date" can be mentioned later in that article or in its Infobox. Please discuss. Thank, Hooman Mallahzadeh (talk) 09:28, 26 March 2025 (UTC)[reply]

Occam's razor has nothing to do with this; it's for asking for the least amount of coincidences in logical explanations, not hiding the most detail. I see no reason to remove the month and date. (Also, some people are against infoboxes on certain articles.) Aaron Liu (talk) 12:55, 26 March 2025 (UTC)[reply]
@Aaron Liu Let's say an example, if someone asks you: who was Steve Jobs? Do you mention his birthday in Month and Day in details? Probably no. You only mention his birth year as an approximation. I think in these cases, mentioning details is wrong. Hooman Mallahzadeh (talk) 13:00, 26 March 2025 (UTC)[reply]
Do I mention his death year? Do I mention his middle name? Would I recall that he was a notable investor when giving basic details, even though it's quite important?
Besides the questions of purpose (what if the person died on say 9/11 and is notable for doing so?), you would have to change over 4 million articles. Aaron Liu (talk) 13:41, 26 March 2025 (UTC)[reply]
Me telling someone who a person is/was in response to a verbal question is a very different context to reading about who someone is/was in an encyclopaedia article. There are many times I've looked up articles just to find someone's date of birth or death, sometimes I've wanted to be more specific than the year, sometimes I haven't. The precise date being there when I'm not interested has never negatively impacted me, the absence when I was interested would have done. Thryduulf (talk) 13:49, 26 March 2025 (UTC)[reply]
@Aaron Liu Over 4 million articles will be modified by this policy by many editors, so don't worry about that. We only want to decide on its policy.
I think most visitors only read the one or two top sentences of each article, without need to read the rest. When they encounter some details that they don't really need, I think it's a drawback of Encyclopedia.
Dear @Thryduulf in the first sentence we only provide approximation, and in the remaining parts the exact "Month and Day" is mentioned. I don't believe exact date is not encyclopedic! I only say that the leading sentence should not contain such details, except for some reason we must do that. Hooman Mallahzadeh (talk) 13:58, 26 March 2025 (UTC)[reply]
So you are proposing to have the date of birth and death twice in the lead paragraph, years only in the first sentence and the full dates subsequently? That's a hard no from me - it doesn't bring any significant benefits to anybody while making the full dates harder to find and the duplication both bring disbenefits to others. Thryduulf (talk) 14:09, 26 March 2025 (UTC)[reply]

don't worry about that. We only want to decide on its policy.

Policy has to follow practice. You're vastly overestimating the practicability and the tradeoff for something so trivial. Aaron Liu (talk) 14:17, 26 March 2025 (UTC)[reply]
I mean most viewers of Steve Jobs article don't want to take a Birthday party for him, for only very few of them this detail i.e., "February 24" is important.
We should consider that such detail "for majority is annoying" and "for minority is beneficial". Hooman Mallahzadeh (talk) 14:22, 26 March 2025 (UTC)[reply]
I doubt anyone finds it annoying. Aaron Liu (talk) 14:24, 26 March 2025 (UTC)[reply]
Citation needed that anyone other than yourself finds it annoying.--User:Khajidha (talk) (contributions) 18:01, 1 April 2025 (UTC)[reply]
@Khajidha This is the Occam's razor principle. This rule says putting unnecessary details in the definition is annoying. The first line (and paragraph) should be as "parsimony" as possible, because it is defining a concept. So it should include only main information and lack any less important ones. Hooman Mallahzadeh (talk) 04:06, 2 April 2025 (UTC)[reply]
A person's full dates are "main information". Thryduulf (talk) 09:32, 2 April 2025 (UTC)[reply]
@Thryduulf I think "person's full birthdate" is not "main information" when defining a person. The reason is that without "full date" and mentioning only "year", the definition experiences no problem. Hooman Mallahzadeh (talk) 09:36, 2 April 2025 (UTC)[reply]
Some detail that does not affect the "defining whole concept" may be omitted. Hooman Mallahzadeh (talk) 09:39, 2 April 2025 (UTC)[reply]
As someone else pointed out, that's not Occam's razor. --User:Khajidha (talk) (contributions) 09:39, 2 April 2025 (UTC)[reply]
Besides whether it is Occam's razor or is not, the important thing is that we should make our "introduction paragraph" of articles in Wikipedia as parsimony as possible. Do you disagree with that? Hooman Mallahzadeh (talk) 09:52, 2 April 2025 (UTC)[reply]
Yes, I disagree that introduction paragraphs should be as parsimony as possible. The lead section provides an overview introduction to the article as a whole. Conveying the least amount of information possible is neither the goal nor beneficial. Thryduulf (talk) 10:06, 2 April 2025 (UTC)[reply]
@Thryduulf We have
  1. Introduction (writing)
  2. Abstract (summary)
  3. Lead paragraph
each of which introduces different concepts, but we have "summarizes" and "brief explanation" and "brief summary" in their definitions. These are other names of "parsimony". Hooman Mallahzadeh (talk) 11:32, 2 April 2025 (UTC)[reply]
We're just back at #c-Aaron_Liu-20250326134100-Hooman_Mallahzadeh-20250326130000 now. Aaron Liu (talk) 11:46, 2 April 2025 (UTC)[reply]
No, parsimony is not a synonym of "summarise", "brief explanation" or "brief summary", it means The quality or characteristic of using the fewest resources or explanations to solve a problem. Absolutely nothing requires or even encourages us to use the fewest words or convey the least amount of information possible. Thryduulf (talk) 11:52, 2 April 2025 (UTC)[reply]
@Thryduulf No, I only said that

If you encounter a definition that incorporates some data that is not considered "the most important data", then remove that part (data) from the definition and mention that somewhere else.

Is the above idea wrong? Hooman Mallahzadeh (talk) 12:02, 2 April 2025 (UTC)[reply]
I'm not quite sure what your asking here, but none of "Summarise", "brief explanation" or "brief summary" restrict the summary/explanation to only "the most important data", and separately it seems that your view of what "the most important data" is is very significantly narrower than pretty much everybody's else's. Thryduulf (talk) 12:33, 2 April 2025 (UTC)[reply]
@Khajidha See Occam's razor article

It recommends searching for «explanations» constructed with the smallest possible set of elements.

Hooman Mallahzadeh (talk) 09:54, 2 April 2025 (UTC)[reply]
Which is completely different frem what we are discussing.--User:Khajidha (talk) (contributions) 10:40, 2 April 2025 (UTC)[reply]
We are dealing with "definitions" in the leading sentence of articles. I really surprise about why you say it is different. Hooman Mallahzadeh (talk) 11:36, 2 April 2025 (UTC)[reply]

This philosophical razor advocates that when presented with competing hypotheses about the same prediction and both hypotheses have equal explanatory power, one should prefer the hypothesis that requires the fewest assumptions

Another way of saying it is that the more assumptions you have to make, the more unlikely an explanation.

Aaron Liu (talk) 11:43, 2 April 2025 (UTC)[reply]
Occam's razor is about constructing hypotheses (or choosing between hypotheses), not writing definitions. --User:Khajidha (talk) (contributions) 12:48, 2 April 2025 (UTC)[reply]
This article uses the word "explanation" multiple times, I think it implies "definition". Hooman Mallahzadeh (talk) 15:17, 2 April 2025 (UTC)[reply]
I think it implies "definition" it doesn't. Thryduulf (talk) 15:47, 2 April 2025 (UTC)[reply]
It's an explanation of "how", not "what". Aaron Liu (talk) 15:59, 2 April 2025 (UTC)[reply]
I think that we are running up against WP:CIR here. --User:Khajidha (talk) (contributions) 16:32, 2 April 2025 (UTC)[reply]
I'm becoming increasingly inclined to agree. Thryduulf (talk) 17:19, 2 April 2025 (UTC)[reply]
@Khajidha@Thryduulf I really don't want to disrupt Wikipedia. Even in IELTS Exam, there exists some policies about how to write introduction and a rule says: introduction should not contain numbers at all.
I only want to impose a policy on "how to write introduction" of Wikipedia articles. Exactly the same as IELTS writings. This policy would says in the introduction paragraph of Wikipedia:
  • What should be included
  • What should be omitted
Because it seems that no policy exists till now. Hooman Mallahzadeh (talk) 17:20, 2 April 2025 (UTC)[reply]
Why should we care what the IELTS says? --User:Khajidha (talk) (contributions) 18:31, 2 April 2025 (UTC)[reply]
Not everything needs a policy. Thryduulf (talk) 19:50, 2 April 2025 (UTC)[reply]
It is a matter of quality of Wikipedia articles. Like IELTS, such policies about introductions of Wikipedia articles impact "Coherence" of that article. "High coherence" means "easier reading". Therefore, quality of Wikipedia articles increases this way. Hooman Mallahzadeh (talk) 03:45, 3 April 2025 (UTC)[reply]
I searched it up; that guideline is just for summarizing a chart and also recommends you to include dates in the first paragraph when appropriate. There is no IELTS guideline for writing a biographical profile. Aaron Liu (talk) 11:33, 3 April 2025 (UTC)[reply]
You should get the idea of IELTS not its instruction. It says:

Do something that your reader understands your essay by just one time reading.

and this is achieved by TA, CC, GRA and LR. The idea of coherence of articles is applied beyond IELTS, for example, when writing an academic article for a journal, there exist policies related to coherence. It says what data should be inserted in what part of that scientific article.
Why Wikipedia hadn't obeyed similar cohesive policies? Our goal is:

Makeing Wikipedia article more readable.

Hooman Mallahzadeh (talk) 11:45, 3 April 2025 (UTC)[reply]
And I'm saying #c-Aaron_Liu-20250326142400-Hooman_Mallahzadeh-20250326142200. Aaron Liu (talk) 12:01, 3 April 2025 (UTC)[reply]
You said "anyone". That's completely true. If someone wants to take a birthday party, or commemorate his death, then such data would be very helpful for that person. But the problem is that majority of readers would neither want to take birthday party for him nor to commemorate his death date. Threfore an approximate date is more useful for them. Hooman Mallahzadeh (talk) 12:09, 3 April 2025 (UTC)[reply]
Here's what I actually said, translated into Persian: من شک دارم کسی آن را آزاردهنده بداند. Aaron Liu (talk) 12:38, 3 April 2025 (UTC)[reply]
No need to Persian, just mathematically:
For myself it is annoying. So the above rule has a counterexample and it is not true. Hooman Mallahzadeh (talk) 12:45, 3 April 2025 (UTC)[reply]
If here "anyone" implies "majority", then we can apply a psychological test:
  1. Apply two versions of an article by "Full date" and "Abstract date" to a group of people
  2. Ask them which one is more annoying
Then we can report the result. Hooman Mallahzadeh (talk) 12:58, 3 April 2025 (UTC)[reply]
  1. Occam's razor involves constructing explanations with the smallest number of unknown or assumed entities, being unnecessarily more complex and so less plausible than an explanation using fewer entities and those that are known. It does not mean that we should all be using shorter sentences.
  2. "I just don't fancy it," is not a very good rationale for a change that would affect a million plus articles. GMGtalk 14:30, 26 March 2025 (UTC)[reply]
    In my opinion using tooltip is a reasonable policy in such cases, we can use a sentence like this:

    Steven Paul Jobs (1955 – 2011) was an American businessman, inventor, and investor best known for co-founding the technology company Apple Inc.

    and by tooltip, we can satisfy both minority and majority of viewers. Hooman Mallahzadeh (talk) 14:37, 26 March 2025 (UTC)[reply]
    And even in the best case, it is a barely noticeable improvement that would require an inordinate amount of time to implement. The answer is going to be no. GMGtalk 14:40, 26 March 2025 (UTC)[reply]
The month and day should not be removed; it’s harmless and potentially useful. If we actually did remove this 4/6ths of the Encyclopedia would need modification, which is incredibly pointless busywork even for bots. Dronebogus (talk) 15:08, 26 March 2025 (UTC)[reply]
And unless the consensus was that all dates more precise than a year should be removed (which even the OP doesn't seem to desire) it couldn't be done by a bot (c.f. WP:CONTEXTBOT). Thryduulf (talk) 15:18, 26 March 2025 (UTC)[reply]
The month and day are potentially harmful per Wikipedia:Biographies of living persons#Privacy of personal information and using primary sources (though Steve Jobs is no longer a BLP). WhatamIdoing (talk) 02:04, 30 March 2025 (UTC)[reply]
I like the idea, if – and only if – there is either an infobox containing the full dates, or if the exact dates are mentioned in the body of the article (e.g., in the ==Childhood== and ==Death== sections).
Additionally, I'd leave the first-sentence dates in place for recent births/deaths, since someone might look up "New Baby Royal" or "Celebrity Justin Died" for the primary purpose of finding that recent date. WhatamIdoing (talk) 02:07, 30 March 2025 (UTC)[reply]
We have talked about this before in the past..... I also think there's no need to write it out two times if the info box has the information. As we know most people scan the infobox [1] and it would reduce first sentence clutter that's always a consideration in bios. Moxy🍁 02:15, 30 March 2025 (UTC)[reply]
Turning everything into “clutter” is a good way to start chopping off half the encyclopedia. 99% of Wikipedia is meaningless junk to 99% of people. Dronebogus (talk) 17:25, 1 April 2025 (UTC)[reply]
ِDear @Dronebogus

Turning everything into “clutter”

Not everything! Not clutter! I mean, "first lines" should be as parsimony and concise as possible. This rule also exists in "introduction" Writing part of IELTS. The reason is that many people would only read "first line(s)" and would not read the rest. Removed data are not clutter, in fact they should be mentioned somewhere else, possibly using techniques like incorporating tooltip or footer. Hooman Mallahzadeh (talk) 03:58, 2 April 2025 (UTC)[reply]
I see no evidence that IELTS is the undisputed pinnacle of writing at all, let alone in any and every context for any and every audience. It is merely one set of style choices for demonstrating ability in one way, chosen as such for one specific purpose. DMacks (talk) 17:36, 2 April 2025 (UTC)[reply]
Hooman Mallahzadeh, think you are overlooking the substantial proportion of our population, which assigns astrological significance to dates. Knowing Jobs’s date of birth informs, those readers immediately that he was a Pisces ascendant in Virgo, which might shape views of him for them. Hyperbolick (talk) 07:10, 13 April 2025 (UTC)[reply]
@Hyperbolick "Astrological significance of dates" is related to computers. But for humans, an approximate date which has no "Astrological significance" is more useful. For example, instead of "February 24, 1955", we can use:
  • 1955 - As year
  • 1950s - As decade
  • second half of 20th contury
  • 20th century
All of them are useful for different purposes, because we are human, not computer. Our goal is to provide a
"Highly readable" article for "Humans".
It can be achieved by using approximate dates, somehow that does not harm the definition.
This "principle of parsimony" is applied in "introduction writing instruction" for of all scientific articles but not yet in Wikipedia. The problem is that we are human not computer. Hooman Mallahzadeh (talk) 07:54, 13 April 2025 (UTC)[reply]
Hyperblock's comment has nothing at all to do with computers and your (@Hooman Mallahzadeh's) comment completely misses the point. Thryduulf (talk) 08:13, 13 April 2025 (UTC)[reply]
I absolutely hate it when basic information is hidden away in the infobox (which I often do not notice). There should usually be no information in the infobox that is not in the prose somewhere. —Kusma (talk) 20:36, 2 April 2025 (UTC)[reply]

References

  1. ^ Wells, John C. (2008). "Ali". Longman Pronunciation Dictionary (3rd ed.). Longman. ISBN 978-1-4058-8118-0. the former boxer Muhammad Ali pronounces ɑːˈliː

Redirect pages should not be accessible to editing by IPs or non-autoconfirmed users

[edit]

Our policy for starting new pages is that the person should be using a registered username which is four days old and has made 10 edits.

A loophole in that policy is that any brand new or IP editor can start an article if there is already a redirect sitting on the article page name.

I propose a technical restriction disabling brand new users and IPs from being able to change a redirect in any fashion.

The background to this proposal is that there are blocked and banned users who habitually bypass our policy by using IPs to create new articles from redirects. Some of these even go to the page Wikipedia:Articles for creation/Redirects and ask for redirects to be created, after which the IP will start a new article on that redirect page. For instance, relative to Wikipedia:Sockpuppet investigations/Rishabisajakepauler, a person from Greater Dallas Texas who was blocked as Rishabisajakepauler and then banned per three strikes has been requesting redirects, and then creating articles from those redirects.[2][3]

Rishabisajakepauler has been abusing the system for four years. I would like to close the loophole. Binksternet (talk) 23:28, 28 March 2025 (UTC)[reply]

Maybe an edit filter disallowing removal of #redirect\[\[.*\]\] from pages by non-autoconfirmed users?
!("confirmed" in user_groups) &
page_namespace == 0 &
removed_likes irlike "#redirect\[\[.*\]\]" &
!(added_lines irlike "#redirect\[\[.*\]\]")
Chaotic Enby (talk · contribs) 11:51, 29 March 2025 (UTC)[reply]
We could also just target the "mw-removed-redirect" tag. Aaron Liu (talk) 19:26, 29 March 2025 (UTC)[reply]
Certainly a better idea! Chaotic Enby (talk · contribs) 19:33, 29 March 2025 (UTC)[reply]
If it's technically feasible, I think it's a good idea that helps enforce the spirit of the 4/10 rule. Schazjmd (talk) 13:35, 29 March 2025 (UTC)[reply]
Previously discussed in 2023 at Wikipedia:Village pump (proposals)/Archive 206 § Proposal: extend ACPERM to IP editors overwriting redirects. I'll just copy-paste what I wrote there:
1) This will also prevent non-autoconfirmed users from restoring a long-standing page that has been turned into a redirect. There's no way for an edit filter to "see" the old revisions of a page, apart from the timestamp of creation, a list of recent contributors, and the name of the first contributor. Best we could do exclude summaries containing "undo", etc., but that could be trivially exploited by bad-faith users, and won't help people who try to manually revert.
(2) Edit filters (as opposed to page protection, the title blacklist, or the hard-coded ACPERM restriction) lead the user down the garden path of thinking their edit will save, until they actually click "publish". I am thinking about the user who discovers some notable subject is a redirect, spends hours composing a carefully referenced page, then clicks "publish", only to be told "nope". Yes, their edit is saved in the filter log, and we can recover it for them at WP:EFFP, but they may be so dispirited at that point that they just give up. Most filters either deal with actual abuse, in which case this is a feature, or are warn-only, so they can still click "publish" and fix the problem later. This problem could partly mitigated, I guess, by putting a big shouty message wrapped in <div class="unconfirmed-show">{{#invoke:Page|isRedirect| ... }}</div> in Template:Editnotices/Namespace/Main, but editnotices are easy to miss, and I'm not sure if that hack will even work in every editor.
Now we don't have to stick with using an edit filter. If someone can think of another method that addresses these concerns (especially the second one), I don't have a major objection to this on principle. Suffusion of Yellow (talk) 01:33, 30 March 2025 (UTC)[reply]
I would much rather see an edit filter put in place, and if it needs a shouty notice, so be it. Regarding the notional vandalism of a longstanding page turned into a redirect, we could also require such redirects to be placed only by auto-confirmed users. The redirect should be off limits to newbies and returning vandals. Binksternet (talk) 01:16, 1 April 2025 (UTC)[reply]
I guess that an admin bot could semi-protect all redirects if there was consensus for that. It wouldn't be perfect - it would prevent new editors from doing things like retargetting or categorising redirects, and from nominating them at RfD; there would inevitably be a lag between redirect creation and protection and there might be edge cases regarding redirects protected at different levels. Semi-protection also wouldn't solve Suffusion of Yellow's first concern but I think it would at least reduce the impact of their second. I suspect placing a template on a redirect page would allow individual redirects to remain unprotected if there was a desire for that for some reason (I don't know if that could be gamed). Independently of method used, if we decide to go down this route, we need to decide which namespace we want it to apply to (both a bot and an edit filter can be configured by namespace, I don't know about other methods).
Without knowing how big the issue is, I'm wondering whether a warn and/or tag ("new user removing redirect") filter would be sufficient. Obviously it wouldn't stop editors from hijacking redirects, but it would make it much easier to detect, revert and (where appropriate) sanction.
If the issue is related to contentious topic areas then maybe a bot that protects redirects to EC-protected pages at that level (and unprotects them if the protection is removed/downgraded) would help. Thryduulf (talk) 02:02, 30 March 2025 (UTC)[reply]
I'm not sure this is a good idea. Whenever possible, one bad actor should be dealt with as one bad actor, rather than by placing restrictions on everyone else in the world.
Perhaps Wikipedia:Requested moves/Technical requests could be advised of the problem, and any requested redirects be given a long semi (e.g., a year, or even a few years)? WhatamIdoing (talk) 02:26, 30 March 2025 (UTC)[reply]
Whenever possible, one bad actor should be dealt with as one bad actor, rather than by placing restrictions on everyone else in the world agreed, which is why I suggested at least starting with warning/tagging rather than protection. Thryduulf (talk) 18:35, 30 March 2025 (UTC)[reply]
I think you meant Wikipedia:Articles for creation/Redirects.
I do not like the idea of semi-protecting redirects. There's menial tasks that can be done on redirects which IP editors can help with. I think an edit filter preventing removal of the redirect is a better solution than semi-protecting redirects which are not necessarily subject to abuse, but it also has issues as mentioned above. Skarmory (talk • contribs) 23:01, 3 April 2025 (UTC)[reply]
Instead of restricting edits completely, why not let a bot move it automatically into draft space? —CX Zoom[he/him] (let's talk • {C•X}) 17:30, 30 March 2025 (UTC)[reply]
The bot would need to recreate the redirect afterwards, and things might get complicated if the redirect has previous history and the new addition needs reverting. Even more so if we end up with parallel histories. Thryduulf (talk) 18:34, 30 March 2025 (UTC)[reply]
1. I doubt how common incidences of 1) that should be kept are.
2. I believe that an edit notice would indeed solve the problem (perhaps + a part of the edit filter message that says it's recoverable from logs).
However, in the discussion you linked I did find an I-M-O extremely persuasive argument that NPP already checks removals of redirects. Aaron Liu (talk) 18:52, 31 March 2025 (UTC)[reply]
I've encountered this too, with a banned editor CFORKing through redirects. The issue with general solutions that add another layer of review like edit filters and pending changes is that unless reviewers are familiar with a particular user they won't have much notification that anything is amiss. CMD (talk) 03:58, 31 March 2025 (UTC)[reply]
What is the scale of the issue trying to be addressed here exactly? Off-handedly the vast majority of unregistered and new user edits to redirects seem to be fine, tweaking r-cats and the like. Fixing broken {{R to section}}s or finding better targets for existing redirects is a relatively newcomer friendly set of tasks.
There's also all sorts of weirdness that results. If I redirect a page for lacking sources could I then not revert myself if I subsequently do the research and find some sources? The change is stated to be for the purpose of combating LTAs, but there are also LTAs that turn pages into redirects which then need to be reverted, so even as one type of disruption is impeded another will persist for longer. Comparative scales aren't easy to judge, but even restricted to the area of dealing with disruption this is not clearly a net positive.
Furthermore, this idea seems to have arisen due to the actions of a single LTA. Now, I am not familiar with them specifically, however as a general rule of thumb semi- is only a speedbump for the obsessive types and not even that for the more clever among them, so it may not even achieve its stated purpose while still incurring the associated costs.
Bottom line, we've been dealing with disruptive conversions both to and from redirects for quite a while now and not just from non-autoconfirmed users, and we have well-honed procedures for doing so, the soft security works fine. 184.152.65.118 (talk) 17:34, 4 April 2025 (UTC)[reply]
Maybe you missed the link to a previous discussion in 2023: Wikipedia:Administrators'_noticeboard/IncidentArchive1139#Cleaning up after protracted move vandal. That was a different vandal. I imagine there are more, but searching for them is close to impossible. Even good-faith IP editors should be prevented from changing a redirect to an article. The proposal is just to enforce existing policy by using technical means. Binksternet (talk) 18:30, 4 April 2025 (UTC)[reply]
Except that some sockmasters disruptively convert pages into redirects I just reverted one of them today. You can find some new users who first got involved with the project by reverting the conversion of an article to a redirect which they felt was improper, sometimes they were even right. The majority of the time it's not an issue.
I'm aware there are other sockmasters who disrupt redirects, my point is the present proposal appears to have arisen from the recent actions of one of them, and it seems unlikely they would be stopped, as opposed to merely inconvenienced, by its implementation. I'm not all that confident the others will either.
Even good-faith IP editors should be prevented from changing a redirect to an article why? Is there any issue that soft security has been unable to redress here? Are you aware that some unregistered users including myself have over the years needed to revert autoconfirmed sockmasters who were disruptively changing pages to redirects? Sure it can be handled through reporting but why not spread the work around. Furthermore obvious disruption should ideally be revertable by anyone around the world; you don't need to have ever edited before to recognize that redirecting a bio to something obscene is wrong, the undo interface is fairly intuitive, and we have on many occasions been aided in fixing those promptly by users around the world who may have that as their only ever contribution. Far to many downsides to implement. 184.152.65.118 (talk) 18:51, 4 April 2025 (UTC)[reply]
The filter could also just log only if the Undo tag is also present. Aaron Liu (talk) 01:40, 5 April 2025 (UTC)[reply]
Yes we could limit filtering to only those cases were a redirect was removed, and the edit was not an undo, and that is a much better idea than what was earlier proposed, but I'm still unconvinced the level of disruption is sufficient to warrant even that more limited measure or that the usual soft security cannot be relied on here. 184.152.65.118 (talk) 01:54, 5 April 2025 (UTC)[reply]
Do we even know what the level of disruption is? It feels like different people have different anecdata but actual hard numbers don't exist? If the average number of instances is about one a week then the proportional response is rather different to what it would be if it's regularly happening multiple times a day). Thryduulf (talk) 03:44, 5 April 2025 (UTC)[reply]
https://en.wikipedia.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&hideWikibase=1&namespace=0&tagfilter=mw-removed-redirect&limit=50&days=7&urlversion=2 should be useful. If we don't allow non-autoconfirmed to create pages, we shouldn't allow them to turn redirects into pages. Aaron Liu (talk) 21:17, 6 April 2025 (UTC)[reply]
Exactly. Binksternet (talk) 11:30, 11 April 2025 (UTC)[reply]
  • @Aaron Liu: you twice mentioned revision tags, unless I'm having some major brain fog, "tag" isn't a variable exposed to the abusefilter, as it occurs post-edit - whereas abusefilter processes pre-publishing. Am I missing something? Here is a recent example of an IP user converting an article redirect to a non-redirect: Special:AbuseFilter/examine/1893987261. Using tags is something that recent changers patrollers may find useful, and other detection systems could use. — xaosflux Talk 12:56, 11 April 2025 (UTC)[reply]
    I didn't know that. In that case, we do need some sort of matching. We should only need to check the first line since no characters before the # are permitted for valid redirects. Aaron Liu (talk) 18:12, 11 April 2025 (UTC)[reply]

Site-wide assessment page

[edit]

How about having a site-wide assessment page with tables and a request section. It would use the current Wikiproject banner shell class parameter. WikiProjects would still be able to have their own assessments because they can use the class parameter in their own banner (for an example of this check out WP:WikiProject Military history/Assessment#Instructions). That way it would fix the issue of deciding which projects assessment tables to use for the main banner, and would also remove a lot of traffic on Wikipedia:WikiProject_Wikipedia/Assessment as currently everyone is going there to get articles assessed and technically they are only supposed to do the ones within their scope as outlined in WP:WikiProject Wikipedia. The ground work is already set from what I can see for a site-wide assessment page, we just need to work out the finer details. Such as what should the criteria be, what the title should be, where it should be located and other such stuff.

Anyways I would like to hear what everyone thinks of this and if there is anything that we need to work out first before I propose it. Sheriff U3 03:09, 30 March 2025 (UTC)[reply]

For context there was some discussion on this earlier today. I also think this would be nice. Currently this work is done on the scale of individual WikiProjects (except for WikiProject Wikipedia which, for reasons, has accidentally shouldered the burden of doing this for the whole encyclopedia) but it'd get a lot more attention on the issue of unassessed or under-assessed articles to have one centralized place for people to request re-assessments if they want a second perspective. A few ways I could imagine this being done:
  • An extension to WP:Peer Review which in practice focuses more on prospective GA and FA nominations, rather than lower classes of articles
  • Some sort of WikiProject on the subject of assessment itself
  • A maintenance page that aggregates the assessment pages of multiple WikiProjects
Viv Desjardin (talk) 03:44, 30 March 2025 (UTC)[reply]
Article assessments are already site-wide. The WikiProject banner shell holds this site-wide assessment. Any user, a member of a WikiProject or not, can re-assess any article for anything B-class or below. Members of WikiProject Wikipedia are thus as able to carry out assessments as anyone else. In general, WikiProject-specific assessments are deprecated, following WP:PIQA, although even this only formalised what was already practice. CMD (talk) 06:15, 30 March 2025 (UTC)[reply]
This suggestion isn't about establishing a site-wide system for assessments, which as you mentioned is already a thing; the suggestion is to create a place on Wikipedia where people can request (re)assessments where the scope is the whole encyclopedia (e.g. anyone can file a request for an article on any topic).
At the moment there's lots of topic-specific pages where you can request re-assessments, like Wikipedia:WikiProject Military history/Assessment#Requests for military history articles, but there isn't really a place like that with a broad scope. Viv Desjardin (talk) 06:22, 30 March 2025 (UTC)[reply]
That isn't clear to me from the proposal. For example, "That way it would fix the issue of deciding which projects assessment tables to use for the main banner" is describing an issue that does not happen under WP:PIQA. I also see that Wikipedia:Content assessment does say that Wikipedia:WikiProject Wikipedia/Assessment#Requesting an assessment is the place to go, so the situation seems more formal than the opening suggests it is. CMD (talk) 06:54, 30 March 2025 (UTC)[reply]
My earlier message was based on a prior discussion Sheriff U3 and I had on the topic though I might have misunderstood the proposal as they've written it here.
The issue with WikiProject Wikipedia is that, according to it: This department focuses on assessing the quality of Wikipedia-related articles (for scope, see the WikiProject page). It seems like the link to it was added by mistake, and everyone's gone along with it. We could keep it the way it is, since it's been that way for about a year and a half now but if this is something WikiProject Wikipedia explicitly wants to handle then it'd be good to clarify this at least. Viv Desjardin (talk) 14:27, 30 March 2025 (UTC)[reply]
I would suggest moving it to somewhere like Wikipedia:Content assessment/Requests. It would be great to continue the service that WikiProject Wikipedia has been offering, but put it somewhere more appropriate. — Martin (MSGJ · talk) 18:46, 30 March 2025 (UTC)[reply]
I think a good option might be to put it as a task force in WikiProject Peer Review -- just wherever gets it the most eyes. The biggest problem with the WP:Wikipedia section, as someone who's messed around with it a bit, is that there are so few people who review it. It's a huge issue when someone just nominates 20 articles. That said, having its own place at "Content assessment/Requests" does seem like sort of the most obvious place to put it.
What about some sort of template? E.g. you tag your article (the main page, not the talk, for visibility) {{Assessment requested}} and then someone comes by, rates it, and maybe gives you some advice. I'm not sure if we should mandate that some advice be given -- i.e. leave a rationale in the edit summary -- but I feel like the advice is the main benefit of having someone else rate your article. It doesn't matter whether every article is assessed correctly, but it does matter that people who write articles have an accurate understanding of how good their article is and how to improve it.
Then there could be a category, e.g. [[Category:Articles assessment requests]], and Content assessment/Requests could be a sort of tiny project (something you can sign up for) for reviewing them. Mrfoogles (talk) 21:06, 30 March 2025 (UTC)[reply]
I like this idea. On expecting advice being given, one approach could be to have a template parameter that adds a message saying something like "An editor has requested specific feedback on this article's assessment. Please share your rationale for any new assessments on this article's Talk Page", which links to a particular section. So, if people don't really care and just want a second opinion, they can leave it off, and people who want some specific feedback know where to find it. This would be similar to a pattern lots of templates have, inviting discussion in the talk page.
I do think that in general the kind of person who'd want to specifically respond to re-assessment requests would also be open to sharing specific feedback. Lots of the feedback would likely be fairly standard (e.g. people who took an article from Stub- to Start-class), but it'd be easy to prepare templates for things like that Viv Desjardin (talk) 21:48, 30 March 2025 (UTC)[reply]
Personally, I mostly leave my feedback on the requests page where people add a request, as part of the reply where you mark it as done, rather than on the talk. That seems like significantly more work, to be honest, although it might be a good idea. Mrfoogles (talk) 22:00, 30 March 2025 (UTC)[reply]
I agree if there's somewhere we're expecting people to explicitly go to submit requests then that'd probably be the best place to leave feedback, since there's more of an expectation that they'll be returning to it. Though this sort of thing would more generally be good to keep in the talk page's history it'd get pretty tedious Viv Desjardin (talk) 22:53, 30 March 2025 (UTC)[reply]
I agree. A quick reply is fine on the requests page. But any extended discussion should be on the article's talk page where other editors will be able to see it easily. — Martin (MSGJ · talk) 11:28, 31 March 2025 (UTC)[reply]
I also like this idea, although I would prefer it be on the talk page. (This is an editing issue not sometime we need to bother the reader with.) Alternatively we can maybe code up something like this when a particular word is used in the class parameter, e.g. |class=requested — Martin (MSGJ · talk) 11:31, 31 March 2025 (UTC)[reply]
I think that the parameter would work. It would eliminate the need for a requests page. We would still need a page to tell people how to request and how to review the requests. We also could try this on a smaller scale first to see if it would work. (Maybe a WikiProject would be willing to test out the idea.) Sheriff U3 22:16, 1 April 2025 (UTC)[reply]
Not exactly related, but I had previously suggested that a parameter for assessment date be included in the shell. This could be useful in identifying stale assessments. —CX Zoom[he/him] (let's talk • {C•X}) 23:31, 1 April 2025 (UTC)[reply]
Since the banner shell includes wikiprojects you'd think it'd be easy to then use it to identify articles requiring assessment by topic. I say that having never built on MediaWiki but it'd be a lot more seamless than having people track down individual wikiprojects for assessment requests. Viv Desjardin (talk, contrib) 23:43, 1 April 2025 (UTC)[reply]
Given there are categories for articles by class and wikiproject (placed on the talk pages), this would just become another one of those. Skarmory (talk • contribs) 10:19, 3 April 2025 (UTC)[reply]
Greetings, Lately I've been active with Category:Unassessed articles and discovered that blanking the class parameter like WikiProject banner shell|class=|, causes an "automatic" assessment request. I have no idea how to document/promote (maybe Signpost?) so I'm just adding my two-cents here. Cheers, JoeNMLC (talk) 13:29, 7 April 2025 (UTC)[reply]
Where does it send the "automatic" request? Think that.will use it for if I ever need someone else to review an article. Definitely should be advertised at the Signpost. I think that I will check if the same can be done with project importance ratings. Thanks for noticing that, never knew it would do that. Sheriff U3 14:02, 7 April 2025 (UTC)[reply]
@Sheriff_U3 - when class is blanked, the article is added into whatever categories for the talk page WikiProjects. For example: "Unassessed biography articles"; "Unassessed basketball articles", etc. At Category:Unassessed articles there are over 600 pageviews the past month, so a good amount of visibility. JoeNMLC (talk) 14:20, 7 April 2025 (UTC)[reply]
Ok I see, yes that would be like a assessment request. Sheriff U3 14:26, 7 April 2025 (UTC)[reply]
As a follow-up to above idea of blanking WikiProject "Class" to request an article assessment, I added that info at WikiProject_Wikipedia/Assessment#Assessment_requests. If any clarification or changes needed there, feel free to update. Cheers, JoeNMLC (talk) 14:37, 11 April 2025 (UTC)[reply]

Overturning NCCAPS

[edit]

There's a discussion at WT:NCCAPS about the capitalization threshold (the current status quo is to only capitalize a title if it's always [sic] capitalized in sources), but it's gotten kind of personal in the last few comments, so rehashing it here for wider community input. Some editors have supported my proposal, others have opposed, overall something that needs to be discussed further. My original comment is as follows:

TL;DR: The threshold for capitalization or lack thereof should be the same as the threshold for a common name.

WP:AT says: Generally, article titles are based on what the subject is called in reliable sources. There is less than zero reason why the one exception to that should be the most trivial of matters: capitalization. The standard for American Revolution vs. American revolution should be the same as that of, say, Dog vs. Canis lupus familiaris. In the latter case, the majority of sources use Dog, thus that is the common name. In the former case, the majority of sources use American Revolution, thus that is the common name. There is nothing that makes capitalization somehow magically different from every other titling scenario.

If the title of an article in sources is 75% uppercase and 25% lowercase, then NCCAPS recommends we lowercase it. That's just plain wrong. If article titles on based on what the subject is called in reliable sources, then why should we contradict that rule for a small subclass of naming disputes? Going by sources and uppercasing the title violates no core content policies and reinforces the in-a-nutshell core of the titling policy. It's nonsense that we should ignore policy and a supermajority of sources to uphold this dubious guideline.

Thus we should follow the sources, as we always have. The threshold for capitalization should not be 100%, nor 95%, nor 90%. It should be 50.1% (with a ±5 to account for the extreme influence Wikipedia has on sources' titling).

So, what do we want to do? Do we want to follow sources and the core policy on article titles, or do we want to straight-up ignore sources, following an anachronistic guideline and some editors' minority grammatical opinions? Do we want to begin a never-ending shitstorm of "style warfare" over whether 50.1% has been reached, and depart from established grammatical norms, or keep in place a guideline that has been stable for twenty years? (Clearly each side has a different opinion...) 🐔 Chicdat  Bawk to me! 11:35, 31 March 2025 (UTC)[reply]

I see absolutely no justification for capitalisation to differ from other aspects of naming. It's not surprising that the discussion at the MoS has resulted in ad hominems, any discussion proposing anything other than reducing the number of capital letters in article titles almost invariably does. Thryduulf (talk) 12:18, 31 March 2025 (UTC)[reply]
I see no reason to change from the current guideline. Capitalization is a stylistic question. Unless it pretty much is capitalized in all sources, everywhere, all the time, then we are free to choose not to do so. Just as we are free to make other stylistic choices. --User:Khajidha (talk) (contributions) 15:03, 31 March 2025 (UTC)[reply]
I think the underlying logic here—as Khajidha says, that we don't 'follow the sources' when it comes to questions of pure style—is sound and necessary to ensure some level of consistency between articles based on different bodies of sources. Disputes tend to arise when applying this logic to capitalisation because the style we have chosen is quite extreme (i.e. we use as few capital letters as possible without coming off as an art project) and therefore more likely to clash with sources and editors' experiences elsewhere. They are exacerbated by a small group of editors who zealously and tactlessly apply this style across articles, with no regard for the preferences of those that wrote them. I'm unsure that tweaking the rule will solve either issue. – Joe (talk) 15:27, 31 March 2025 (UTC)[reply]
"with no regard for the preferences of those that wrote them" I'm not seeing how this is a problem. You aren't writing for you and your preferences. You are writing for Wikipedia and our style. --User:Khajidha (talk) (contributions) 17:23, 31 March 2025 (UTC)[reply]
The proposal is to change our style… so simply pointing to the current style guidance and saying “you are writing for our style” isn’t really an argument. Please explain why you think the current guidance is better than the proposal. Blueboar (talk) 21:02, 31 March 2025 (UTC)[reply]
Because it looks better and is easier to read with less capitalization. But, as I'm not the one arguing for change, I'm not the one who needs to explain. --User:Khajidha (talk) (contributions) 21:14, 31 March 2025 (UTC)[reply]
So, your reasons are 1) "your personal preference" and 2) "an uncited and possibly wrong factual claim"?
I've seen sources claiming that all lowercase is easier to read than all uppercase (once you know how to read. Brand-new readers often struggle to differentiate lowercase letters like d and b, so all-caps text sometimes works better for them). I don't remember seeing any research saying that "war and peace" is easier to read that "War and Peace".
About as I'm not the one arguing for change, I'm not the one who needs to explain: I guess I hope that editors who join a discussion are trying to find the Wikipedia:Consensus. That only works if everyone is willing to explain their views. Wikipedia:BOLD, revert, discuss cycle, in particular, is entirely dependent upon the reverter/objector being willing to explain why they object to a change. A stonewalling attitude like "You made the change, so I'm not the one who needs to explain my views" will cause BRD – and most other serious discussions – to fail. Please don't do that. WhatamIdoing (talk) 05:12, 1 April 2025 (UTC)[reply]
The problem is that having people who still want to write articles is several gazillion times more important to Wikipedia's future than consistent capitalization of titles. – Joe (talk) 21:51, 31 March 2025 (UTC)[reply]
I have come to believe that enforcing a house style is overall a net negative for Wikipedia. (Personally, I contribute very little to the German Wikipedia although German is my first language, mostly because I disagree with their style choices, which are often different from the near unanimous view of the sources). —Kusma (talk) 08:36, 19 April 2025 (UTC)[reply]
  • I find it interesting that basically everyone in that discussion agrees that "always capitalized in reliable sources" shouldn't be taken literally, but those opposed are saying we can't change it because some parade of horribles will follow. ~~ Jessintime (talk) 19:25, 31 March 2025 (UTC)[reply]
    Perhaps “overwhelmingly capitalized in sources” is closer to how we really operate? Blueboar (talk) 21:08, 31 March 2025 (UTC)[reply]
    It depends on the discussion whether it's "overwhelmingly", "almost always" or "literally always". Often it's "Overwhelmingly (or almost always) capitalised in sources that I can't dismiss as not-independent, unreliable, "specialist", "low quality", or for some other reason". I think it would be much closer to our ethos and a more professional approach to capitalisation if the standard was something like "predominantly capitalised" with usage by subject matter experts weighted a bit higher than usage by others and we treated the context-free evidence from sources like ngrams as a single, relatively low-importance data point. Thryduulf (talk) 21:26, 31 March 2025 (UTC)[reply]
    That "sources I can't dismiss as..." bit sounds like what I've seen in many areas. WhatamIdoing (talk) 05:14, 1 April 2025 (UTC)[reply]
@Chicdat: I wish I had time to write and refine something concise and thoughtful here, because there is considerable history and a lot of nuance. But just to offer a few stray thoughts
In the end content is what's important, style is just the dressing. As a reader, I like to have articles that look nice and are consistently formatted, but what I really want are articles that are well-written and informative.
Maybe the specifics of the guideline shouldn't matter match. Guidelines are supposed to be just that occasional exceptions may apply in principle a solid local consensus should be sufficient to override, though in practice it's complicated.
WP:STYLEVAR works just fine and helps to reduce acrimony, but its not always practicable. Could it work in the area of capitalization? Well in at least one area it already does. Would it work more widely? Difficult to say, not a lot of hard evidence either way.
No matter where you draw the lines there will always be edge cases, one choice or another will not eliminate good-faith disputes among contributors.
NYB once wrote of the potential for a demoralizing effect, I'm confident it exists, but judging its effects is harder. Some might remember the editors lost from WP Birds as a result of a capitalization controversy, but there were other factors at play there as well.
From the beginning the MoS has been one of those perennial dispute/disruption areas, its not everyone's cup of tea, and I certainly would not fault anyone for avoiding it. At the same time if you want to help build consensus you have to be involved. A common complaint is that MoS related discussions are not representative of the community as a whole because only the people who have the MoS as their focus show up in number since they are more likely to monitor Wikipedia talk:Manual of Style#Style discussions elsewhere. Maybe so, but there's nothing that prevents people who are mostly content editors from also monitoring the section and offering their assessments.
Maybe what is really needed is a broader cross section of the community offering input, and regardless of ultimate outcome, that's really desirable for all discussions. You can help. Sure you'll get unpleasant responses, don't let them get under your skin, be assertive not aggressive, stand your ground but be willing to hear others out as well. And know when to disengage. DGG once suggested the principle of limiting your comments in discussions that were primarily contentious rather than collaborative, let everyone have their say and see what shakes out.
Sorry for the length and disorganization, given time constraints I probably shouldn't be editing at all at present, but hopefully you found some of that useful. 184.152.65.118 (talk) 17:04, 6 April 2025 (UTC)[reply]
I agree with Blueboar's comment that what we actually do in RMs is not a literal application of the word "always". I've participated in...a few RMs and I've never understood the "always" in that sentence to mean "in every single source in existence", instead reading it as "grammatically should always be capitalized". In that regard, I support changing the wording of NCCAPS. But Wikipedia prefers to minimize capitalization, so the threshold cannot be 50%+1 of sources, it has to be a large majority. Not sure how best to express this in guideline-speak. Toadspike [Talk] 21:58, 11 April 2025 (UTC)[reply]
  • MOS:CAPS says Wikipedia relies on sources to determine what is conventionally capitalized; only words and phrases that are consistently capitalized in a substantial majority of independent, reliable sources are capitalized in Wikipedia., I don't see why this shouldn't apply to article titles as well. Kowal2701 (talk) 21:20, 18 April 2025 (UTC)[reply]

Ignore edits to ones own user area in right counts

[edit]

For additional right given automatically based on number of edits, edits to ones own area of user and user talk space should not be counted. So User:ZcrashZ, if they had 11 edits, one to User:ZcrashZ, one to User talk:ZcrashZ and one to User:ZcrashZ/page1 and eight to other places, the user would count as having made 8 edits and would be unable to move a page because WP:AUTOCONFIRM would not apply. I see editing of their own area a lot on creating accounts for Vandalism.Naraht (talk) 01:23, 5 April 2025 (UTC)[reply]

How often does this happen?
This link will give you a list of every page moved by any account with (if memory serves) 10–500 edits during the last 24 hours. Looking at it, there's been about 125 entries in the move log, but if there's a talk page, then a single "move" action will be logged twice, so there are probably about 50 names to review. I looked at about 10; I found only one that might have been tripped up by such a rule.
The point behind autoconfirm is that obvious vandals are obvious before they make 10 edits. If they're not obvious vandals, then why shouldn't they be able to draft an article in their userspace and move it to the mainspace when they're ready for it to face Wikipedia:New pages patrol? WhatamIdoing (talk) 03:00, 5 April 2025 (UTC)[reply]
Is there any user right besides autoconfirmed that is triggered by edit count? Cambalachero (talk) 03:21, 5 April 2025 (UTC)[reply]
WP:XCON which requires 500, though as with AC it also has a time component, 30 days instead of 4. And yes it is also routinely gamed. 184.152.65.118 (talk) 03:26, 5 April 2025 (UTC)[reply]
WP:XCON (but AIUI not WP:AUTOCONFIRM for technical reasons) can be revoked if a user is judged to be gaming the permissions system. Requiring that edits counting towards AC/EC not be in userspace will probably have limited effect on people actively gaming permissions – they can simply shift their permission-gaming to a different namespace. Especially in the case of autoconfirm, which only requires 10 edits. Caeciliusinhorto-public (talk) 15:53, 7 April 2025 (UTC)[reply]
I think there are some tools that require certain edit counts, though the two I can remember at the moment, being access to the wikipedia library and autowikibrowser, have similar edit requirements to extended confirmed. I believe there's a tool that requires 1k edits but I cannot for the life of me remember what it is, so along with the others I listed I doubt anyone is edit farming for those specific tools. ¿VØ!D? ☄ 21:11, 14 April 2025 (UTC)[reply]
Currently, it seems that there is no documentation if one can restrict edit count by namespace. mw:Manual:$wgAutopromote. If the suggestion is passed in a RfC, technical assessment and work will likely be in order before such conditions by namespace can be used. – robertsky (talk) 09:51, 13 April 2025 (UTC)[reply]
Likely it would require a database change to store the edit count by namespace. Anomie⚔ 12:40, 13 April 2025 (UTC)[reply]
Some editors do start drafting articles in userspace before moving them to mainspace, I'm thinking these contributions should still be counted if that proposal comes to pass. Chaotic Enby (talk · contribs) 12:26, 13 April 2025 (UTC)[reply]
Chaotic Enby, are you saying these edits should count even before the draft has been published (So someone may have 450 mainspace edits and 100 edits to an as-yet-unpublished draft, and they should receive EC rights)? Because if they only count after publication, I think counting edits made to mainspace would include edits made to former drafts that have since been moved to mainspace. ꧁Zanahary꧂ 21:38, 15 April 2025 (UTC)[reply]
I was thinking they would only count after being moved to mainspace, if that's already how they are counted then it's great! Chaotic Enby (talk · contribs) 09:42, 16 April 2025 (UTC)[reply]

hoy

[edit]

you could have a count of edit filters per article I think, that would be useful to keep track of the most problematic and priority articles. (red annales) (talk) 20:00, 6 April 2025 (UTC)[reply]

The Wikipedia:Edit filter applies globally, so I assume you mean the pages to whom the most edits triggering the edit filter are made. It's also important to note not all edit filters are meant to track non-constructive edits. -insert valid name here- (talk) 20:54, 8 April 2025 (UTC)[reply]

More formal "green" and "gold" concepts for Good and Featured article qualities

[edit]
The Featured star doesn't look quite right but this is a good concept

I saw the graphic for the Four Award and it struck me that Featured-class content really doesn't flow the best with Good-class content in a stylistic sense. Notice that all of the icons about the award are all in a similar style yet the Featured-class star is just pasted on a gold badge and that's that. The featured star is lovely for what it is but I personally think it should, at least in some sense, be partially retired, in exchange for a new graphic of a golden star. This would appear very similar to the one in the top-right corner of the Four Award graphic, but would, of course, have a simple shape instead of the complex star.

Purely from a cosmetic standpoint, the Featured star already kind of blurs together. It's got a hell of a lot more lines than would be expected of a standard graphic. A simple golden star badge akin to that of the Good-class content badge would be more understandable to newcomers, more intuitively clear being above Good-class content, and straight-up be cleaner, flowing with the design of the other 99.9 percent of content on the project.

Not only would this look better alongside the myriad of other simple icons we have on site, but would flow better with the concept of Featured content being obviously higher quality than Good content - green and gold. For instance, Wikipedia:WikiProject Women in Green is called that due to their work getting articles to good-status, or "green", so I don't see why featured content shouldn't have its own simple color designation - in this case, "gold".

I understand how potentially controversial replacing an icon that has been on the site for years might be, and to that end, I propose in addition that a Featured content barnstar be added for serial contributors to featured content, etc. I'm a bit shocked there isn't one now but if replacing the Featured star for something more standardized and stylistic with the rest of the icons is going to happen I don't want to see the Featured star gone for good, as it's a good graphic, and it'd make a better barnstar. This is just an idea as is. I don't know what popular reception will be and I take it this isn't going to be the most popular thing, but I'd appreciate anyone's input on this. Departure– (talk) 14:00, 11 April 2025 (UTC)[reply]

A FA star is given, so to speak, upon the passing of an FA, so it probably does not exist as a separate barnstar because that would be somewhat redundant. The design has made it into other barnstars though, like the File:Reviewer's Award2.png. As you state, this is a somewhat perennial proposal, previous simply star designs (eg. File:Symbol star gold.svg) have not garnered support. I think if you want to promote "gold" as a concept though, there isn't any inertia in the way of that. CMD (talk) 14:56, 11 April 2025 (UTC)[reply]
FA star looks different and fancier because it is different and fancier. Making it bland like the other icons defeats the purpose. Cremastra talk 20:02, 11 April 2025 (UTC)[reply]
IMO we should even remove the Norro (the circley thing and its shadow) for that and replace the neutral symbol with something (swap its location with the bottom left even), perhaps the AfC logo. Aaron Liu (talk) 02:51, 12 April 2025 (UTC)[reply]

Unblock request wizard

[edit]

 Courtesy link: User talk:Joe Roe § An idea
See the aforementioned discussion for some context, but basically I think it'd be good to have a wizard (like Wikipedia:Edit request wizard) for unblock requests. Feedback regarding the idea is very much welcome. Clovermoss🍀 (talk) 21:54, 11 April 2025 (UTC)[reply]

Anecdotally, the proportion of malformed unblock requests that make valid cases for being unblocked is low but not zero, so I’m open to a suggestion like this. I’m wondering if we could also include some invisible AI spoilers in the Wizard prompts to catch people who try to game the system (e.g. "include the phrase 'sequitur absurdum' in your response", "include an explanation of Wikipedia's General Mobility Guideline"). signed, Rosguill talk 15:39, 12 April 2025 (UTC)[reply]
I don't think we should aim to trick people (it'll probably just end with people addressing unblock requests being confused as well), but a prompt asking someone whether they attempted to write their unblock request with AI with a "yes" or "no" selection might be enough to prevent most instances of it (especially if it includes a statement about it being discouraged and requesting someone to rewrite it in their own words to show that they understand what they're saying). Kind of like the commons upload form that asks if you're uploading a file to promote something and just doesn't let you continue if you click "yes". Alternatively the request could just have an extra "this editor says they used AI while writing this unblock request" added somewhere. Clovermoss🍀 (talk) 16:51, 12 April 2025 (UTC)[reply]
1. Rosguill's text would be invisible and only shown when copied/selected and dragged and dropped. (I think there is an HTML attribute that would make something not picked up by screenreaders either.)
2. We're fighting AI-generated unblock responses, not bots. The usual scenario would be someone asking the AI for an unblock request and then pasting that into the box manually. Aaron Liu (talk) 17:38, 12 April 2025 (UTC)[reply]
FWIW I don't consider my spoiler suggestion to be absolutely necessary for my supporting the general proposal, but yes, what I had in mind is to render the text in such a way that it will only show up in any capacity for people who try to copy-paste the prompt into another service, which is becoming a standard practice for essay questions in school settings to catch rampant AI use. signed, Rosguill talk 17:49, 12 April 2025 (UTC)[reply]
I like this idea. voorts (talk/contributions) 18:47, 12 April 2025 (UTC)[reply]
That might scare people who composed their unblock requests in a Word document, though. I've gotten fairly good at gauging whether something was AI-generated, I assume admins who patrol RfU are the same. JayCubby 15:58, 14 April 2025 (UTC)[reply]
Definitely opposed to this, as it'll only lead to some humans inevitably getting accused of using AI. ꧁Zanahary꧂ 04:45, 14 April 2025 (UTC)[reply]
If it's invisible text, how? voorts (talk/contributions) 12:27, 14 April 2025 (UTC)[reply]
If “invisible” means it’s just the same color as the background, people are going to see it (by highlighting, with alternative browsers, etc) ꧁Zanahary꧂ 14:54, 14 April 2025 (UTC)[reply]
Make it super small text size with same color as background and add a style/attribute that'd prevent screenreaders from reading it. Plus it'd be a very unreasonable request to most humans. Aaron Liu (talk) 16:13, 14 April 2025 (UTC)[reply]
It’s just silly. We do not know that this would trick AI, I’m not convinced that undetected AI use is a problem (it’s pretty easy to clock), and there is reason to believe it will catch innocent people. ꧁Zanahary꧂ 16:43, 14 April 2025 (UTC)[reply]
I would also agree with an unblock request wizard, although I might be less focused on the technical side. From having guided users in quite a few unblock requests, the main issues I've seen (although I concede there might be a selection bias) are in understanding what is required of an unblock request. A good wizard would summarize WP:GAB in simple terms to help blocked users navigate this – as writing a good unblock request is certainly less obvious than it seems for people unfamiliar with Wikipedia.
One idea that could be explored would be to structure the unblock request, not as a free-form text, but as a series of questions, such as What do you understand to be the reason for your block? and Can you provide examples of constructive edits you would like to make? Of course, these questions can be adapted based on the specifics of the block (a user caught in an IP rangeblock wouldn't see the same questions as a username-hardblock, for example), but this could make for a good starting point that would be less confusing than the current free-form unblock requests. Chaotic Enby (talk · contribs) 18:08, 12 April 2025 (UTC)[reply]
I like that idea. My concern is that the specific reason for the block may not always be clear from the block template used, and the block log entry may be free text that, while important for identifying the reason for the block, is not easy to parse by a wizard.
Example: "disruptive editing" could be anything from extremely poor English to consistently violating the Manual of Style to deadnaming people to ... you name it. — rsjaffe 🗣️ 20:04, 12 April 2025 (UTC)[reply]
Good point. What I had in mind was something like this part of the AfC wizard, where the user can click to select their situation, rather than it being automatically guessed from the block template (which would be prone to frequent errors). Chaotic Enby (talk · contribs) 21:03, 12 April 2025 (UTC)[reply]
Could be a hybrid work flow. For certain block templates, e.g., {{uw-copyrightblock}} or {{uw-soablock}}, there could be a set of standard questions, for others, e.g., {{uw-block}} there could be a "choose your situation" flow. — rsjaffe 🗣️ 21:14, 12 April 2025 (UTC)[reply]
That could be great! Chaotic Enby (talk · contribs) 22:54, 12 April 2025 (UTC)[reply]
I'm having some difficulty imagining a positive reaction by an aggrieved editor facing a menu of options, but I think a more concrete proposal might help. Perhaps those interested in a multiple workflow concept could mock something up? isaacl (talk) 21:29, 12 April 2025 (UTC)[reply]
Going to do it! Ideally, it shouldn't be something that would comfort them in their grievances or make them feel lost in bureaucracy, but more something like "we hear you, these blocks happen, for each of these situations you might be in, there is a way to get out of it". Chaotic Enby (talk · contribs) 22:56, 12 April 2025 (UTC)[reply]
I do think that some editors don't realize they even can get unblocked at all. Or that it isn't even nessecarily their fault if they're an IP editor... some situations where innocent bystanders were affected by a rangeblock and frustrated come to mind. Clovermoss🍀 (talk) 00:51, 13 April 2025 (UTC)[reply]
I think it's easier than asking someone to copy a template and then edit wikitext. voorts (talk/contributions) 01:54, 13 April 2025 (UTC)[reply]
My comments weren't about the general idea of a guided workflow, but a branching workflow based on the answers to initial questions. It brings to mind the question mazes offered by support lines. Although I think a more general workflow might be better, I'm interested in seeing mockups of a branching workflow. isaacl (talk) 16:43, 13 April 2025 (UTC)[reply]
I like the general idea, but anything with prompts, etc needs to take into account there are at its most basic three categories of reasons to request an unblock: (1) the block was wrong and shouldn't have been placed (e.g. "I didn't edit disruptively"); (2) the block is not needed now (e.g. "I understand not to do that again"); and (3) the block doesn't make sense.
Sometimes they can be combined or overlap, but for type 2 appeals it is generally irrelevant whether the block was correct or not at the time. Type 3 often shouldn't be unblock requests but often it's the only way people see to get help so anything we do should accommodate that. Perhaps a first question should be something like "why are you appealing the block?" with options "I understand the reason given but think it was wrong", "I understand why I was blocked but think it is no longer necessary" and "I don't understand why I was blocked."
I'm neutral on an AI-detection, as long as it is made explicit in instructions for those reviewing the blocks that a request using AI is not a reason in and of itself to decline (using AI is discouraged, not forbidden, and someone may say yes even if they've only used it to check their spelling and grammar). Thryduulf (talk) 08:03, 13 April 2025 (UTC)[reply]
Currently working on User:Chaotic Enby/Unblock wizard! Chaotic Enby (talk · contribs) 15:05, 14 April 2025 (UTC)[reply]
Regarding the sub menu for "I am not responsible for the block": my preference is not to provide a set of pre-canned responses like "Someone else I know has been using my account" and "I believe that my account has been compromised". I think we should avoid leading the editor towards what they may feel are plausible explanations, without any specific evidence. isaacl (talk) 16:56, 14 April 2025 (UTC)[reply]
True, that makes sense, even though I tried to provide an outlet with the "I don't understand" before. Although I'm planning a full rework of this on the advice of @Asilvering, as whether the user believes they have been blocked incorrectly might not be the most important first question to ask. Chaotic Enby (talk · contribs) 18:09, 14 April 2025 (UTC)[reply]
I agree with isaacl that the "I don't understand" outlet is just not good enough.
What did asilvering suggest as a more important thing? Aaron Liu (talk) 19:53, 14 April 2025 (UTC)[reply]
Basically, sorting appellants into boxes that are actually useful for giving them tips, rather than asking them to tell us what their rationale for appeal is. We're not actually all that interested, functionally, in whether an appellant thinks the block was wrong or not (lots of people say they are when they were obviously good blocks), so there's no reason to introduce that kind of confusion. There are, however, some extremely common block reasons that even a deeply confused CIR case can probably sort themselves into. eg, "I was blocked for promotional editing". "I was blocked as a sockpuppet". etc. -- asilvering (talk) 20:17, 14 April 2025 (UTC)[reply]
That makes a lot of sense! Aaron Liu (talk) 20:43, 14 April 2025 (UTC)[reply]
I think it would be better for the blocking admin to do the sorting with the aim of providing relevant guidance. Maybe it's better to have a block message wizard. isaacl (talk) 21:54, 14 April 2025 (UTC)[reply]
What is relevant guidance depends in part on when and why someone is appealing, which is unknowable to the blocking admin. Thryduulf (talk) 23:22, 14 April 2025 (UTC)[reply]
Twinkle has blocking built in. voorts (talk/contributions) 23:19, 14 April 2025 (UTC)[reply]
Does it customize the block message with guidance to appropriate policies based on input from the admin? isaacl (talk) 01:25, 15 April 2025 (UTC)[reply]
See File:MediaWiki 2025-04-15 02-32-10.png and File:MediaWiki 2025-04-15 02-32-55.png. voorts (talk/contributions) 02:36, 15 April 2025 (UTC)[reply]
There are different ways to implement my suggestion. For example, the standard template (whether added by Twinkle, another tool, or manually) could be enhanced to accept a list of preset reasons for blocking, which the template could turn into a list of appropriate policies. Twinkle can feed the preset reason selected by the admin to the template to generate the list. isaacl (talk) 02:54, 15 April 2025 (UTC)[reply]
You can already select various different block templates (see CAT:UBT) through Twinkle that link to appropriate PAGs or use a generic block template to list reasons for a block / link to relevant PAGs. voorts (talk/contributions) 03:03, 15 April 2025 (UTC)[reply]
Perhaps whatever tips that would be provided by an unblock wizard could instead be added to the block templates? I appreciate that there's a tradeoff between crafting a message that's too long to hold the editor's attention, though. I just think that communicating this info earlier is better. isaacl (talk) 03:26, 15 April 2025 (UTC)[reply]
There is never going to be consensus to rework every single block template and extensively modify Twinkle. voorts (talk/contributions) 12:07, 15 April 2025 (UTC)[reply]
Regarding what is unknowable to the blocking admin: I was responding to Asilvering's comments on sorting blocked editors into categories for which appropriate tips can be given. I agree there can be benefits in providing a guided workflow for blocked editors (and am interested in seeing what gets mocked up). I just think that it will improve efficiency overall to start providing targeted guidance as soon as possible, and providing some kind of automated assistance would make it easier for admins to do this by default. isaacl (talk) 01:25, 15 April 2025 (UTC)[reply]
I think it's a good idea. ꧁Zanahary꧂ 04:46, 14 April 2025 (UTC)[reply]
  • I do think many people get tripped up on the wikicode(and when they click "reply" to make their request it adds to formatting issues) so I'd be interested in what people can come up with. I do agree with Issacl above regarding pre-canned responses. 331dot (talk) 20:31, 14 April 2025 (UTC)[reply]
    I think we could point people to the relevant policy pages, then give them a form to fill out, sort of like the draft/refund/etc wizards. Don't give them a prefilled form, instead an explanation (maybe even a simplified version) of the policies from which they are expected to explain their rationale. JayCubby 20:36, 14 April 2025 (UTC)[reply]
    Perhaps a block message wizard for the admin would be more helpful: they can specify the relevant areas in which the editor must be better versed, and the wizard can generate a block message that incorporates a list of relevant policies for the editor to review. isaacl (talk) 21:50, 14 April 2025 (UTC)[reply]

False Positives.

[edit]
Moved to Wikipedia:Edit filter noticeboard § False Positives.
 – Aaron Liu (talk) 03:38, 13 April 2025 (UTC)[reply]

Antivirus

[edit]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
It looks like the OP has earned a CU block. WhatamIdoing (talk) 18:21, 16 April 2025 (UTC)[reply]

We could create a bot that removes links to computer viruses, only from the wikimedia foundation. (red annales) (talk) 19:38, 13 April 2025 (UTC)[reply]

A way to try this out would be to make your bot make a report. It could publish a report of Page, link (don't make it clickable), and perhaps the name of the threat on the link. — xaosflux Talk 19:42, 13 April 2025 (UTC)[reply]
Simple just use virustotals api although we would need to pay or ask for the enterprise version but i believe virustotal is an Wikipedia in terms of verification and community I don’t think the foundation wouldn’t mind much. Edit: we could take this further and do phishing detection and ip logger detection. Even in commons we could use this just to run files and pdfs through •Cyberwolf•. talk? 15:17, 15 April 2025 (UTC)[reply]
How often are virus links even posted to Wikipedia? Aaron Liu (talk) 15:20, 15 April 2025 (UTC)[reply]
Rarely but it can prevent it when it does id rather stop one virus than just sit by and let it go undetected •Cyberwolf•. talk? 15:24, 15 April 2025 (UTC)[reply]
on the Russian-language wiki tends to appear more often, a project abandoned to its own fate just as it was with China. (red annales) (talk) 22:09, 15 April 2025 (UTC)[reply]
They don't have an edit filter against non-autoconfirmed users adding external links? Aaron Liu (talk) 02:15, 16 April 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Well i can write a script- its quite simple and i have been learning java script so might as well try •Cyberwolf•. talk? 12:52, 17 April 2025 (UTC)[reply]
Doing a plug in •Cyberwolf•. talk? 13:36, 17 April 2025 (UTC)[reply]

A problem with pushpin maps

[edit]

Hi, follow this scenario

  1. Go to article Tehran
  2. Click on pushpin map in its Infobox
  3. This image is shown that lacks marker of Tehran

This scenario does not seem true. So I propose that after clicking on Tehran's pushpin map, then its OpenStreetMap containing marker of Tehran will be shown in the new page. This way, the user has the ability to zoom in and out. Please discuss. Thanks. Hooman Mallahzadeh (talk) 11:52, 15 April 2025 (UTC)[reply]

The object above what you are talking does this •Cyberwolf•. talk? 15:09, 15 April 2025 (UTC)[reply]
@Cyberwolf Sometimes this OSM map does not exist. This behavior of
  • Showing a map without any indicator
after clicking on pushpin_map is not reasonable. I think the true scenario would be showing OSM map with an indicator. I think its implementation is very fast and convenient. This problem for Sydney article is more observable. Hooman Mallahzadeh (talk) 15:27, 15 April 2025 (UTC)[reply]
Then add a osm to the info box •Cyberwolf•. talk? 15:28, 15 April 2025 (UTC)[reply]
You are right, we can do everything. The problem is that this behaviour is a malfunction and is considered a software bug. Do you agree? Hooman Mallahzadeh (talk) 15:33, 15 April 2025 (UTC)[reply]
I don’t see it as a software bug tbh cause its an image with a marker overlay for precise location you use the other map •Cyberwolf•. talk? 15:36, 15 April 2025 (UTC)[reply]
See, this image https://en.wikipedia.org/wiki/Sydney#/media/File:Australia_relief_map.jpg which is shown after clicking on pushpin map of Sydney article does not contain any marker. Do you see any marker? So it is not useful at all. Hooman Mallahzadeh (talk) 15:39, 15 April 2025 (UTC)[reply]
It’s not the point of the pushpin map •Cyberwolf•. talk? 15:42, 15 April 2025 (UTC)[reply]
Yes you're right. We are redirected to a picture (of Australia) from Wiki Commons. I think this redirection is not true, because it does not contain any marker. We should redirect to somewhere that in addition to a marker, we can "zoom in" or "zoom out". This is only achieved by OSM maps. And I strongly believe that implementation of this redirection is very convenient. Hooman Mallahzadeh (talk) 15:47, 15 April 2025 (UTC)[reply]
Well I did some hands on with pushpin maps a relief map is what’s used which is just an image of the country making an image for it that’s a duplicate of what the push pin looks like will fix this •Cyberwolf•. talk? 15:55, 15 April 2025 (UTC)[reply]
I don't get what you said. How will fix it? The relief map that is shown after clicking is from Wiki Commons, and it does not contain any marker. How it would be fixed? Hooman Mallahzadeh (talk) 16:01, 15 April 2025 (UTC)[reply]
So by taking a screenshot of the marker and map uploading that and place that in the map thing •Cyberwolf•. talk? 16:19, 15 April 2025 (UTC)[reply]
This process is too hard to implement. I really think that a redirection to its place in OSM map would be implemented very fast and easily. Hooman Mallahzadeh (talk) 16:26, 15 April 2025 (UTC)[reply]
In addition, OSM has the ability to Zoom in/out that screenshot map lacks. I really think that this ability is very useful for every user. Hooman Mallahzadeh (talk) 16:29, 15 April 2025 (UTC)[reply]
I'd support this, if there's an easy way to implement it technically. Elli (talk | contribs) 16:52, 15 April 2025 (UTC)[reply]

@Elli:This is my proposed easy implementation:

1- Create an OSM map by this code:

{{Infobox mapframe|wikidata=yes|id ={{get QID|Tehran}} |zoom=4| stroke-width=1 |shape-fill-opacity=0|geomask={{get QID|Iran}}|mapframe-frame-coordinates= {{WikidataCoord|Tehran}}|marker=city}}

Which yields:

Map

2-place the above code in a hidden div tag

3-change hyperlink of pushpin map to something like "https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab)#/map/0"

The same is true for other pushpin maps, just change Iran and Tehran to for example Australia and Sydney.

So easy-peasy. Hooman Mallahzadeh (talk) 17:28, 15 April 2025 (UTC)[reply]

The above implementation takes advantage of "geomask" argument of OSM which makes it completely the same as previously clicked pushpin map. I mean it is not just coordinates that redirects to https://geohack.toolforge.org site as this link for Tehran. Hooman Mallahzadeh (talk) 07:55, 16 April 2025 (UTC)[reply]

Helping bring more interest in Wikipedia with racing fans

[edit]

I have had an idea for the last couple months which has incubated a lot. It’s sorta a gathering for the current editors of motorsports articles to talk and watch the race while having a front end that brings in new editors for a potiential workshop on how to edit tables (pretty big issue) and create articles. What usually stops my train of thought is money I don’t know how expensive one of these would be but i want to just throw this at the wall and see if it sticks •Cyberwolf•. talk? 14:47, 15 April 2025 (UTC)[reply]

Are you thinking about a virtual event or an in-person one? WhatamIdoing (talk) 18:22, 16 April 2025 (UTC)[reply]
Any? •Cyberwolf•. talk? 18:48, 16 April 2025 (UTC)[reply]
Virtual events are cheap. You need a way to find and recruit potentially interested people (e.g., social media) and a way for them to talk (e.g., a Zoom account). Editing ordinary tables is easy: you use the visual editor on the desktop site (i.e., not mobile).
I suggest attending a couple of events before you trying hosting one. Check the m:Events calendar or similar pages to find something that sounds similar to what you'd like to do. The event coordinators might even be willing to talk to you about their planning work. WhatamIdoing (talk) 19:02, 16 April 2025 (UTC)[reply]
Everything can be improved even further, but, having this in mind, I've sometimes thought that having all articles with the same quality as we have in articles about Formula 1 or some other sport competitions (for example, FIFA World Cup), would be a good target to set. Their consistent structure is really great. MGeog2022 (talk) 11:02, 19 April 2025 (UTC)[reply]

Could drafts be protected instead of deleted?

[edit]

After I saw a draft for Sprunki get nominated for deletion for the same reason that the one for Battle for Dream Island had been deleted and salted, that got me thinking:

Instead of deleting drafts that are resubmitted to oblivion, why not semi-protect or extended confirmed protect them so unregistered (and newly registered) users won't be able to submit them anymore?

In order to submit a draft, the template {{AfC submission}} has to be placed on the page. If it's semi-protected, then only autoconfirmed editors should be able to submit it. If it's extended confirmed protected, then only extended confirmed editors could submit it, and everyone else would have to place edit requests on its talk page where they can be declined by other editors.

Here's a list of times that the Sprunki draft was submitted:

Date Account age then Edit count then Autoconfirmed? Extended confirmed?
October 12, 2024 Unregistered; not applicable ☒N ☒N
November 24, 2024 Unregistered; not applicable ☒N ☒N
December 15, 2024 0 days 11 ~ Not until Dec. 19 ☒N
April 3, 2025 2 days 12 ~ Not until Apr. 5 ☒N

Just for the sake of comparison, here's a list of the times that Barron Trump had been submitted whilst it was still a draft:

Date Account age then Edit count then Autoconfirmed? Extended confirmed?
November 28, 2023 19 days 109 checkY ☒N
November 9, 2024 493 days 858 checkY checkY
January 21, 2025 Unregistered; not applicable ☒N ☒N
January 24, 2025 Unregistered; not applicable ☒N ☒N
January 26, 2025 2,292 days 189 checkY ☒N
March 4, 2025 16 days 28 checkY ☒N
March 16, 2025 27 days 25 checkY ☒N
March 23, 2025 34 days 51 checkY ☒N

If protecting drafts isn't a good way to deter resubmissions and save reviewers' time in the process, I'd like to know why not. – MrPersonHumanGuy (talk) 15:43, 15 April 2025 (UTC)[reply]

Sprunki isn’t an good example due to it’s lack of coverage and it’s lacking general notability •Cyberwolf•. talk? 15:57, 15 April 2025 (UTC)[reply]
Protecting page names is what should be done •Cyberwolf•. talk? 15:59, 15 April 2025 (UTC)[reply]
@MrPersonHumanGuy: This would also require move protection at the same levels, so that an autoconfirmed editor can't just move it into mainspace and bypass the process. And given that drafts are NOINDEXed and hard to find unless you're willing to use the internal search engine and know their exact title, this would end up causing a lot of drafts that don't have a chance to languish. Another factor to consider is that, unless express permission is given, people generally are unwilling to edit someone else's draft. —Jéské Couriano v^_^v threads critiques 16:02, 15 April 2025 (UTC)[reply]
As a contributor who would be unwilling to edit other people's drafts myself, you are especially correct about that, which is why I like to copy userspace drafts into draftspace and edit such copies as I see fit. Of course, I could just move a draft, but I would be concerned that its creator may get surprised to find out that it's been moved all of a sudden. Then again, some drafts do get forgotten for months before they're rediscovered by at least one other contributor.
Topic Original userspace draft Draftspace counterpart
A World Without (web series) User:FroggyTranslator/A World Without... Draft:A World Without (web series)
Time Traveler Luke User:DDG9912/Time Traveler Luke Draft:Time Traveler Luke
I'm only bringing these up on a case-in-point basis. These two drafts don't (and won't) need page protection at this time, as neither of them have been submitted, nor do they (as of yet) appear to have the sort of meme status or popularity with certain demographic niches that would cause them to be at risk of being submitted by obsessive fans of their respective subjects in the foreseeable future. Please excuse my darned affinity for tables. – MrPersonHumanGuy (talk) 19:32, 15 April 2025 (UTC)[reply]
Doesn't protection automatically apply move protection? Aaron Liu (talk) 22:29, 15 April 2025 (UTC)[reply]

Color "additional considerations apply" as purple and "no consensus" as yellow at RSP

[edit]

Currently, the "additional considerations apply" and "no consensus" statuses have the same "MRel" yellow grouping at WP:ReliableSourcesPerennial. This has caused some confusion for closers and those unfamiliar with what RSP actually is: a summary of past consensus and not any sort of guideline; "no consensus" makes a source's status "no consensus" instead of preserving the previous status. This also makes it a bit harder to differentiate "consensus for additional considerations" from "no consensus". Thus, I propose we add purple200 (#d9d0e9) as a color for "additional considerations apply". This color provides sufficient color contrast against foreground text and seems the most friendly to colorblind people. Aaron Liu (talk) 22:28, 15 April 2025 (UTC)[reply]

I agree with the general shape of this proposal but would reverse the colors. IMO "additional considerations apply" should be thought of as the actual step between WP:GREL and WP:GUNREL, with "no consensus" as a sort of "null" represented by a color outside the normal range. Loki (talk) 00:37, 16 April 2025 (UTC)[reply]
"No consensus" doesn't mean null guidance; it's indeed more caution than GRel and less caution than GUnRel. Aaron Liu (talk) 02:14, 16 April 2025 (UTC)[reply]
Notified: Wikipedia talk:Reliable sources/Perennial sources. Thryduulf (talk) 22:50, 15 April 2025 (UTC)[reply]
I don't see a need for this distinction. A source in yellow means spend some time thinking about this one. Purple would also mean spend some time thinking about this one... a meaningless distinction. Headbomb {t · c · p · b} 00:53, 16 April 2025 (UTC)[reply]
One has full consensus behind spending time thinking about this one and detailed directions on how to, as opposed to the far more general "we're not sure if this source is reliable, double-check". Contrary to Loki I feel like the former is on a different spectrum. Aaron Liu (talk) 01:06, 16 April 2025 (UTC)[reply]
"No consensus" doesn't mean "welp, no idea" - it means there was a discussion that failed to achieve a consensus that the source was reliable and it definitely has a lesser status than reliable - David Gerard (talk) 20:15, 18 April 2025 (UTC)[reply]
I agree. That's why it should be clearly distinct from "just make sure to check these specific things", don't you think? (By "not sure" I do mean what you meant; "not sure" is not "no idea", her means it decidedly falls short of reliable from community consensus.) Aaron Liu (talk) 21:02, 18 April 2025 (UTC)[reply]
No, this doesn't seem to match what these do - David Gerard (talk) 20:16, 18 April 2025 (UTC)[reply]
How so? Aaron Liu (talk) 21:02, 18 April 2025 (UTC)[reply]

Moving logos, album covers etc out of infoboxes

[edit]

I am concerned that the current default practice of adding logos, album covers, film posters, box art etc to infoboxes is stifling commentry, criticism and free content generation.

Very often these items are fair use whose purpose is for "criticism, comment, news reporting, teaching, scholarship, or research" (random website) and the Non-free content guideline lists Contextual significance as a factor. By moving these images out of infoboxes we would be encouraging captions that provide critical commentary, enhancing contextual significance. And hopfully free alternatives would be generated.

Current examples:

  • National Hockey League: the uncaptioned logo is the only image you see on the page on mobile, an interesting caption is only found on the child article for some reason. An alternative would be a photo of an NHL game.
  • GoldenEye: the film poster actually has a caption, but the image would be better placed in the section that discusses poster curation. Ideally a free photo of the film's production could be used in the infobox.
  • Let's Get Out of This Country: no caption for this album cover, which actually has an interesting backstory. I suppose I am meant to write the sourced passage about the cover down in the body, add a synopsis in the infobox caption and expect the reader to scroll up and down when reading the passage. Ideally a free photo of the band in the recording studio could be used in the infobox.

I understand that having these logo/album cover type images in infoboxes is an easy way to make the article look pretty and to help familiarise the reader with the promotional materials, but is that our priority? It can be difficult to find freely licenced ideal alternatives, but we should try. Commander Keane (talk) 00:15, 16 April 2025 (UTC)[reply]

I don’t see how placement in the infobox precludes sourced critical commentary in the body. ꧁Zanahary꧂ 00:20, 16 April 2025 (UTC)[reply]
I agree. These examples can all be changed: I would support the recommended changes to the latter two pages, and for the first page I would just copy over (and condense) the caption on the child page and throw it into the infobox. None of this needs something that says such images shouldn't be in infoboxes. Aaron Liu (talk) 01:42, 16 April 2025 (UTC)[reply]
Am I right in reading this as a question about whether WP:NFC used in the infobox meets the WP:NFCCP policy, rather than a general question about whether logos, album covers, etc. should be in infoboxes or not? CMD (talk) 00:33, 16 April 2025 (UTC)[reply]
Per NFCI#1, images that are used for identification in infoboxes are presumed to meet NFCC#8 as they provide implicit branding and marketing of the topic in question. If they can also be used for additional purposes (for example, Ico's cover is discussed in the article as being based on a classical work of art), great, but we do not have that requirement to require more than the topic being notable in the first place to use identifying images. Masem (t) 02:13, 16 April 2025 (UTC)[reply]
I think the biggest hurdle to my idea is in WP:LEADIMAGE: which says the purpose of these is to ...give readers visual confirmation that they've arrived at the right page.
I am trying to encourage critical commentary on images, fair use or not; free material is certainly a bonus. I guess placement in the infobox doesn't prevent that, but is it appropriate to double up usage in the body? It would be better to place a captioned image next to the relevant discourse in the body. Ico, a featured article, is interesting in that an unreferenced caption is in the infobox, the inspiring artwork with one reference is in the Development section and commentary with two other references is in the Release section, along with the alternate box art.
Getting implicit branding and marketing in the infobox is certainly the goal of many an articles-for-creation contributor, which actually sparked my initial post. Also, as a newbie when looking to illustrate an article I uploaded a logo rather than look for a public domain image or request for a Wikipedian to take one. In that case, my critical commentary was actually moved away from the logo's caption when an infobox was introduced.
I had assumed that there was no policy problem with non-free content in infoboxes, and my examples all feature non-free content because that is what you typically find in infoboxes. I had no intention of splitting infobox image usage by copyright status, or giving non-copyright promotional material a free ride on critical commentary. Commander Keane (talk) 06:37, 16 April 2025 (UTC)[reply]
It's a cupcake. Do we really need critical commentary on the photo?
About I am trying to encourage critical commentary on images, fair use or not: Why?
I wonder if we have different ideas about what "critical commentary on the image" means. So I've added a photo. IMO critical commentary on the image would sound like "The cupcake is placed off center on a neutral background, with multiple lighting sources from the back and left, causing a shadow to fall to the right and front".
I suggest to you that the article Cupcake needs many images, but does not need any critical commentary on its images. WhatamIdoing (talk) 18:32, 16 April 2025 (UTC)[reply]
Indeed "critical commentary on images" is not the phrase I meant. More of an "useful encyclopedic comment for image captions", of which every image in Cupcake has. By critical I was intending, in your photo for example, "A sample from the Cupcake Camp Montreal fundraiser" rather than "A pretty one with sprinkles", or nothing. Commander Keane (talk) 23:38, 16 April 2025 (UTC)[reply]
Citation needed that it is a cupcake from the Montreal fundraiser. Sounds like OR to me. Blueboar (talk) 23:52, 16 April 2025 (UTC)[reply]
Yes, imagine a culture where you need to put a caption and find a reliable source to back it up. The Hostess Cupcake photo used in Cupcake may well have been baked by the photographer's grandmother for all I know. I would say images get a special treatment for OR, so I will trust that editors familiar with the brand have confirmed the photo is legit. I trusted the Montreal cupcake's file page, but if that is not enough then better sourcing is required. Effort is not a bad thing. My point of the caption was to introduce the reader to cupcake's cultural significance to fundraising, not mentioned in the article yet.
I don't know why we are talking about cupcakes, my problems were:
  • the culture of not bothering with captions in infoboxes, and when we do we must condense the message - which is reasonable as infoboxes are required to be simple, and
  • the editorial constraint of not being able to use those infobox images in the body near where they are discussed.
For the second problem, the proposed little anchor symbol that I think was suggested for the Barack Obama lead that would jump readers to the relevant section would help (I can't find the guideline on that anymore). Looking at the feature article Ico it seems the current idea is that readers intend to sit down and read the entire article so we can spread information, in that case about box art with accompanying images, throughout the article. Fair enough. I will leave it at that and try my best at working with current practice. Commander Keane (talk) 01:43, 17 April 2025 (UTC)[reply]
An image is supposed to illustrate something in the article. The point being illustrated might be, especially for a lead (including, but not limited to, infobox) image, "This is what the subject of the article looks like". There's nothing wrong with Barack Obama having a simple caption like "Official portrait". There's also nothing wrong with Ico having a caption that's 27 words long. The caption should serve the needs of the article.
If we had a section in Cupcake about its use in (US and Canadian) fundraising bake sales, then the photo above would need a caption like "A cupcake from a fundraising event" or "Cupcakes are popular at bake sales", or something like that. But:
  • If it's not saying anything 'new' compared to the text, there's no need to duplicate the citation just so there's a little blue clicky number visible in the caption. There is no need for a paragraph that says "Cupcakes are sold at fundraisers[1]" followed by an image caption that says "Cupcakes are sold at fundraisers[1]". Citing once per fact is enough.
  • The same photo can often be used to illustrate multiple points. If this image were in a ==Fundraising== section, then the caption should be about fundraising. But if this image were in a ==Decorating== section, then the caption should be about icing and sprinkles. And if it were used in a different article, it would need still yet a different caption. For example, if it were in Red dye number 3, next to a paragraph noting that most of Europe can't get such beautifully red sprinkles, because – unlike Canada, whence this cupcake hails – Europe has banned red dye number 3, then it would need a caption about the food dyes used in sprinkles. (Hmm, no photos in that article. Maybe I'll have a look around. A comparison of Red 3 vs some other red might be very nice.)
WhatamIdoing (talk) 03:35, 17 April 2025 (UTC)[reply]
1. User:WhatamIdoing stop talking about Cupcakes it is making me hungry!.
2. I am with WhatamIdoing on his comments about captions. Infoboxes are supposed to be a quick view outlining info on the article, so as per previous example the Goldeneye poster is enough for the infobox, the same as as Cadbury logo in the Cadbury page - it does enough to show what it is. Davidstewartharvey (talk) 05:05, 17 April 2025 (UTC)[reply]
Particularly for non-free which are only being used under a NFCI#1 claim as an identifying image and have zero further commentary about them, then the caption should be brief, or in cases where what the image like a movie poster or album cover, the caption omitted entirely.
Its when the image has more purpose for inclusion beyond just identification, as in the case of Ico as I've mentioned, then a more fleshed out caption should be reasonable, as that should help the reader locate where the image may be discussed more in the body. The caption should not include information not included in the body, however (eg LEDECITE should apply) Masem (t) 13:08, 17 April 2025 (UTC)[reply]
I don't think you can complain about cupcake examples and substitute with chocolate! I can now see that people love their branding in infoboxes, images with their captions are incidental to the cited text and that some images don't need a caption.
For Cadbury I would at least like to see a "Current logo" caption to prompt me to realise it hasn't been that way for 201 years. Then it is up to me to clunkily ctrl-F for "logo" (if magical links are forbidden) to be enlightened by the origin story in the Advertising section. You could say "go for it, add the caption as it increases value" (or maybe not) but my point is why no editor has added a caption already. A better caption could be "Current logo. Since the 1970s logos have been based on the signature of the founder's grandson", but that is too much for the infobox. I am going around in circles in this discussion. I want to have great captions on the relevant images near the relevant text. I understand this has to be balanced with the brevity and visual confirmation objectives of the infobox, and the need to distribute images throughout an article for aesthetics. Unfortunately all of these things can't be achieved and maybe my desire is unfounded.
Admittedly, removing official branding from infoboxes is not a good idea as it would introduce the problem of de minimis substitutes, like the way File:Cadbury World sign, Bournville.JPG is used in the Cadbury#Advertising section, and again in United Kingdom company law.
I probably should have started this idea thread stating that I really enjoy a good caption and encouraging free content. The way I skim an article is to read the intro and look at captions to see if anything piques my interest.
The blue magical clicky thing I mentioned is not a citation, and adding new information in captions can be a chicken-and-egg scenario with a work-in-progress. Commander Keane (talk) 01:56, 19 April 2025 (UTC)[reply]

Nostalgia Wikipedia 25th anniversary

[edit]

On January 15, 2026, Wikipedia will turn 25 years old. As part of the celebrations, it would be fine to have a new edition of Nostalgia Wikipedia for the future, with its content as of that date, as we have it from December, 20, 2001 (https://nostalgia.wikipedia.org/wiki/HomePage). The same mechanisms used by Wikipedia Version 1.0 Editorial Team could be used to remove vandalisms that are active at the very moment that the snapshot is taken.

It could be deployed online (as is the case with the 2001 version) and be also made available for download as a ZIM file.

This way, it would be easier to have a quick view of the evolution and improvement of Wikipedia over the years (2001, 2026, 2051...). Having a look at 2001 Nostalgia Wikipedia, the enormous progress made since then is really obvious. MGeog2022 (talk) 12:42, 18 April 2025 (UTC)[reply]

This is a good idea. Thryduulf (talk) 14:21, 18 April 2025 (UTC)[reply]
Meh ... that's what the Wayback Machine is for (and unlike Wikipedia's servers, it's actually designed to archive things). The overhead of permanently hosting a 2026 version of Wikipedia would be orders of magnitude greater than that of hosting the Nostalgia Wikipedia, not just because of the vast increase in database size but also because there were no inline images/videos/audio files in 2001. The other advantage of the Nostalgia Wikipedia is that it contains edits that aren't in the current Wikipedia database (or weren't until I and others imported them), which is much less likely to be an issue now. Re curating the entire current Wikipedia database for vandalism: that's logistically impossible and highly unrealistic. Graham87 (talk) 03:11, 19 April 2025 (UTC)[reply]
I understand your viewpoint. Media files could be taken from Commons (yes, some of them could be eventually deleted or overwritten), so only text would need to be saved (around 90 GB, I believe, that shouldn't be too much for WMF). The current financial and infrastructure (including backups, or more precisely, the absence of them) resources of Internet Archive (owner of Wayback Machine), make it difficult to assume its long-term permanence. Fortunately, Wayback Machine also takes content from external open projects such as Common Crawl, that stores many sites, including all or most content of English Wikipedia. Wikipedia's own full dumps also include revision history for all articles (history that is also available online for each article). Both Common Crawl and dumps with full history provide a guarantee of long-term preservation. My idea was about making this more accessible to the general public, rather than only preserving it. MGeog2022 (talk) 11:15, 19 April 2025 (UTC)[reply]
Media files wouldn't just be taken from Commons; they'd also have to be taken from local uploads (especially our non-free content, if we chose to include it in the hypothetical snapshot). Luckily our non-free content policy has become relatively stable. Graham87 (talk) 11:37, 19 April 2025 (UTC)[reply]
In the long term, it may be worth developing a feature to view the encyclopedia at a specific date into a MediaWiki extension (or client side Javascript extension that fetches the data using the API), else we may end up with masses of redundant copies. Simlar to how GitHub and its competitors allow viewing a repository at a certain commit.  novov talk edits 09:53, 20 April 2025 (UTC)[reply]
That's phab:T7877, which will celebrate it's 19th birthday next month. Thryduulf (talk) 10:40, 20 April 2025 (UTC)[reply]
It's a great idea. Let's hope it won't be necessary to wait for another 19 years before it's implemented. Many things can be learned from past versions of articles, but it isn't easy to navigate in hundreds or thousands of revisions. And many people aren't aware of this or of the option to read the article's past versions in Wayback Machine. MGeog2022 (talk) 14:37, 20 April 2025 (UTC)[reply]
Objects in git can't include content from another object without running a build process to generate the combined objects. Just considering the pages within English Wikipedia, every transclusion would have to be mapped to a specific version, and each time a transcluded page is changed, all of the pages transcluding it would have to be updated to the new version. (This mechanism would have also have to handle content transcluded from Commons.) This would massively increase the version history of pages (at least within the database) and the processing load for changing transcluded pages. Any pages, or specific revisions of pages, that have ever been transcluded couldn't be deleted from the database. It could be made to appear deleted to regular editors, which may add some complications if, for example, a template is created, used, no longer used and pseudo-deleted, and then a new template with the same name is recreated. The history of the two templates should remain distinct.
Alternatively, the MediaWiki software could be rewritten to take the git approach of versioning the entire repository as a whole. But this requires locking the entire repository for each commit being made, so there's always a distinct set of files being changed from one version of the repository to another. This doesn't scale well to the size of Wikipedia's editor base, and doesn't handle content transcluded from Commons. It would also be a fundamental change to how pages are managed. isaacl (talk) 17:51, 20 April 2025 (UTC)[reply]

Tasks/Missions

[edit]

New policy: The users can make their own pages as task boards, with two tabs: tasks, which show what it will do in the future, and missions, important things of the user that will be done soon. 2001:1308:2695:7300:E167:FFB0:A392:8002 (talk) 15:18, 20 April 2025 (UTC)[reply]

It is not for posting spam, etc, nor do you need to post one. 2001:1308:2695:7300:E167:FFB0:A392:8002 (talk) 15:19, 20 April 2025 (UTC)[reply]
Can't we already? Aaron Liu (talk) 19:56, 20 April 2025 (UTC)[reply]
We can put that content on our user page if we wish to. The proposal seems to be to have predefined tabs. I oppose it for two reasons:
  1. It assumes everyone wants to put the same stuff on their user page, and
  2. It makes this seem like a social media site, rather than an encyclopedia.
Phil Bridger (talk) 20:07, 20 April 2025 (UTC)[reply]

Grant move-subpages to template editor user group

[edit]

At Wikipedia:Requested moves/Technical requests, a request was made to move {{Myprefs}} to {{Preferences}}. While the requestor could move the template, the rationale for filing was because there are a number of subpages to move as well and moving a number of subpages can be error-prone.

Given that current practices for Template development oblige everyone to use at least 3 subpages, /docs, /sandbox, /testcases, if a template editor chooses to move a Template, they may run into similar situations more often than not.

In the request, @Pppery raised the idea of granting move-subpages right (Move pages with their subpages) to the template editors, and I find that it is a good idea and template editors are a group of trusted editors already. This would reduce the friction template editors who are not page movers face when moving templates on their own. – robertsky (talk) 18:43, 20 April 2025 (UTC)[reply]

If there is a way of restricting move-subpages to the template namespace then this is an absolute no-brainer. If there isn't then I still think on balance it will be a positive - the number of template editors who would abuse this in other ways is going to be extremely small. Thryduulf (talk) 18:54, 20 April 2025 (UTC)[reply]
I agree. If really needed we could tag rapid bulk moves in mainspace with an edit filter, but as you say I doubt that's how rogue template editors would choose to disrupt a wiki. Aaron Liu (talk) 20:04, 20 April 2025 (UTC)[reply]
I don't think the namespace limitation is necessary or a good idea. Firstly template editor is a much higher trust position than page mover - if we trust people to make edits that could break millions of pages we should trust them to be able to move pages. Secondly a lot of templates are not located in the template namespace - lots of templates are in the user and wikipedia namespaces, for example. 86.23.109.101 (talk) 08:25, 21 April 2025 (UTC)[reply]
Agree with this too, either limited to the template namespace if possible or in general. I don't think pagemove vandalism by template editors is really a concern, or that it would raise the bar for granting template editor. Chaotic Enby (talk · contribs) 20:11, 20 April 2025 (UTC)[reply]
Agreed. Subpages are disabled in the main namespace though, therefore so are subpage moves. Graham87 (talk) 06:43, 21 April 2025 (UTC)[reply]

What to do about prior draft decline notices

[edit]

If a draft is declined several times, users usually have to scroll a lot to see the content beneath all of those notices.

Idea A: Collapsible
Other AfC submission notices

Initially, I thought it would be neat if prior notices could be put in a collapsible box like how most talk page notices are encased within {{banner holder}}. I've experimented with putting decline notices in {{collapse}}, but when I set their width to match those of decline notices, it always causes decline notices to become significantly narrower, as if to maintain the presence of two gaps beside each.

It is possible for a box of this width to be positioned in the center...
Other AfC submission notices
...and still be able to fit in a collapsible box of equivalent width without becoming narrower.
Idea B: Shrinking

Alternatively, a parameter (like small) could be added to {{AfC submission/declined}} that would allow for a notice to be shrunk down to a fraction of its usual height by hiding the {{blist}} and {{AfC submission/helptools}} stuff in order to reduce their redundant presence in repeatedly declined drafts. If implemented, such a parameter should cause an example blank notice to look like this when enabled:

Since other types of AfC submission notices usually don't appear below any subsequent AfC submission notices on drafts, it may not be necessary for us to be able to shrink those other types. I know these templates can only be edited by template editors, but these suggestions are specifically directed towards them too. – MrPersonHumanGuy (talk) 16:01, 21 April 2025 (UTC)[reply]

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