Theproposals section of thevillage pump is used to offer specific changes for discussion.Before submitting:
Check to see whether your proposal is already described atPerennial proposals. You may also wish to search theFAQ.
This page is forconcrete, actionable proposals. Consider developing earlier-stage proposals atVillage pump (idea lab).
This is a high-visibility page intended for proposals with significant impact. Proposals thataffect only a single page or small group of pages should be held at a correspondingtalk page.
Currently, we block allWP:Tor exit nodes such that any user wanting to edit through a Tor exit node would first need to contact a administrator and obtain theWP:IPBE user right before making any edits. (i.e. convince a admin that you will edit constructively and not sock, which is a much higher bar than typical autoconfirmed). However, currently MediaWiki artificially extends the period of time a user needs to edit for to be autoconfirmed to be atleast 90 day with a edit threshold of 100 edits. Given the way we currently handle Tor IPs, adding this extended time period seems counter intuitive. Would it be a good idea to remove the 90 day, 100 edit barrier forWP:AC users (especially those who have been granted IPBE)? (cc @W00zles and @Stwalkerster who were involved in the request, and @Risker, who I know has a lot of institutional knowledge of why certain features were implemented v/s weren't) -- If the community is okay/open to the idea of reducing/removing theWP:AC time/edit extension, I'll file a phabricator task to reduce the period!Sohom (talk)20:07, 26 September 2025 (UTC)[reply]
I'm generally supportive, but a couple of points. Global IPBE (torunblocked) can be granted by stewards, even for accounts which don't exist on this wiki. In those cases, and in some cases on this wiki, the bar can be very low - often we'll just take a look whether we believe someone is in China, or Iran, or wherever. No edits required. That said, having a high bar for AC doesn't really add much in today's environment. --zzuuzz(talk)20:34, 26 September 2025 (UTC)[reply]
I support this motion. I will admit that this directly benefits me as a Tor editor. Failing the accepting of this proposal, I would ask that the tools that check for autoconfirmed to be unified. A lot of sources don't agree with the autoconfirmed status of Tor users. The MediaWiki API returns that I am confirmed, but the internal tools such asSpecial:UserRights indicates to me I only have IPBE. My Preferences page also disagrees with the API.W00zles (talk)21:58, 26 September 2025 (UTC)[reply]
Some groups are actually assigned in the database, while others are implicitly assigned at runtime. It appears thatTorBlock changes the implicit assignment based on the source of the incoming request, so you when using Tor you'll see the higher requirements being applied even when you look at the implicit groups of other users who never use Tor. OTOH, if you're making the API request via Tor and it's not applying the higher requirements, that's probably a bug.Anomie⚔22:18, 26 September 2025 (UTC)[reply]
Z@Anomie, I think the problem here is that they see very different results compared to me, if I make a query through the API, I see them as autoconfirmed, whereas when they try to edit a page that has a autoconfirmed restriction, they can't. If the answer is "keep the extended period", then we need better tools as administrator to know that this restriction is being applied.Sohom (talk)13:37, 27 September 2025 (UTC)[reply]
I'm not certain what your proposal is here, so I'll give two answers. I think I'm opposed to reducing Tor autoconfirmed statusbelow non-Tor statusespecially if GIPBE allows Tor editing, but I don't have any reasons why we shouldn't equalise it between Tor/non-Tor while a blanket ban on non-(G)IPBE Tor users exists so I'm weakly supportive of that.stwalkerster (talk)22:28, 26 September 2025 (UTC)[reply]
I support. Tor requires IPBE, which isn't exactly an easy feat for a new user. I don't see much of a reason to have the higher bar these days, with the global ban on Tor.EggRoll97(talk)15:20, 27 September 2025 (UTC)[reply]
Responding to ping. Tor is a form of open proxy, which is generally banned throughout the Wikimedia world for a lot of complex reasons. There are attribution issues, there is the longterm dramatically higher rate of vandalism, and there is the simple fact that Tor historically was used regularly by two groups: vandals and activists of various stripes. I genuinely do not know if the extended period for autoconfirmed applies only to those using Tor, or if it applies to all users with IP block exemption. (Logically, it should apply to all accounts with IPBE, because there is no "special" permission above that to enable access via Tor.) All known Tor exit nodes are blocked globally, and pretty much have been since the "no open proxies" global policy and philosophy was introduced. In response toEggRoll97, I can honestly say that probably 1/2 of IPBE requests coming in through the central checkuser VRT queue are from comparative newcomers; in about 5-10% of cases, we actually have to create their accounts for them. It's really not hard to find us or to ask for it.I'd suggest that the real debate here is whether the no open proxies policy needs to be revisited, in light of (often justified) concerns about personal internet security throughout the world, not just regions with authoritarian governments. I realize that doesn't really answer the subject of this thread, but on reading things through, I can't tell if this is a local issue or a global one; and given my personal opinion on autoconfirmed is that I'd rather increase the requirements for everyone, I'm probably not the best person to weigh in.Risker (talk)15:43, 27 September 2025 (UTC)[reply]
My recollection of the discussion is that there was seeming consensus for 7 days/20 edits, but (as I recall), the devs went with 4/10, as a preliminary test. Perhaps enough time has gone by to revisit this. -jc3704:24, 14 October 2025 (UTC)[reply]
I should clarify, my main reason for calling it not an "easy feat" is the specific case you mentioned, which is that they would need to go through the VRT queue. That's already a lot just to get an account created, involving manually contacting CheckUsers (I don't believe there's really an automated way to just submit a request to the CU VRT queue). I know it probably doesn't sound like a lot of work, but comparatively to just creating an account as normal, that's a much more involved process.
Side note, I do think it probably would be good to start discussing autoconfirmed being bumped a bit, the low standard may be intentional, but it feels far too easy to game autoconfirmed socks with the current requirements.EggRoll97(talk)16:21, 27 September 2025 (UTC)[reply]
I can say in my personal experience attempting to get my account usable was a real challenge. I had to go to an admin in real life and ask them to confirm me. I never got a response from the stewards when I made the IPBE request after getting my account made for me over Tor, leaving me with little ability to do anything.
I am not opposed to a raised autoconfirm requirement due to vandals but I do think, as mentioned in the other reply thread, it should be equal at a minimum between IPBE and not.W00zles (talk)23:10, 29 September 2025 (UTC)[reply]
When discussion hasended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
Background, currently, we block allWP:Tor exit nodes such that any user wanting to edit through a Tor exit node would first need to contact a administrator and obtain theWP:IPBE user right before making any edits. (i.e. convince a admin that you will edit constructively and not sock, which is a much higher bar than typical autoconfirmed). However, currently MediaWiki artificially extends the period of time a user needs to edit for to be autoconfirmed to be atleast 90 day with a edit threshold of 100 edits. This is enforced by the theTorBlock extension which was addedsome time in 2008. Since then, our policies have shifted, in the current day, due to ourNo open proxies rules, editing through Tor exit nodes are typically always blocked locally (and many times globally). Due to this, the bar for editing through Tor proxies has become "request the IPBE userright" + the aformentioned extended autoconfirmed userright. Given this, I would like to propose that we remove the special extended time period to get autoconfirmed for Tor users, and instead equalize the bar for recieving the autconfirmed userright for both Tor and non-Tor users. -- 14:56, 3 October 2025 (UTC)
Support, per what I have said above, getting IPBE userright is not a small task for users with no edits to show (since the bar often used is "has constructive contributions/will not edit disruptively" which is hard to show when you are blocked from making any edits). As such, the bar for getting IPBE is a higher one than to be autoconfirmed (which for normal users is 4 day and 10 edits) and given that IPBE is basically mandatory to edit through Tor, it does not make sense to create another meaningless hurdle here. Note that this proposal does not preclude (and is mutually exclusive from) discussion about increasing the level required for autoconfirmed users for everyone. --Sohom (talk)14:56, 3 October 2025 (UTC)[reply]
Support per Soham Datta, the proposal and the preceding discussion. There is no reason to treat tor and non-tor users differently in this regard.Thryduulf (talk)17:06, 3 October 2025 (UTC)[reply]
Support, Being on the receiving end of this policy, it's difficult to do useful work that would be expected of a typical editor.W00zles (talk)23:11, 5 October 2025 (UTC)[reply]
Support. Using any other VPN through IPBE probably doesn't suffer from this issue. If we believe that autoconfirmation needs to have higher thresholds for people editing from blocked addresses, then that should be the criterion, not the use of a specific anonymization service.~ ToBeFree (talk)21:38, 13 October 2025 (UTC)[reply]
How would that work? Just setting autoconfirmed to X for anyone with IPBE? Interesting idea. Though I think admins get that by default as well. I think it's worth discussing. -jc3704:29, 14 October 2025 (UTC)[reply]
@Jc37, In essence this would just be a mediawiki configuration change which removes/resets two configuration values to 0 (which previous defined the elevated cap for Tor users)Sohom (talk)15:10, 14 October 2025 (UTC)[reply]
Oppose. First, this will affect an extremely small number of users. Second, the unintended real consensus in the discussion above is "we need to increase standards to make accounts autoconfirmed". So, let's work on that before we start modifying the autoconfirmed level for one specific and very small group of users. After we increase the requirements for autoconfirmed for non-Tor accounts, then ironically Tor accounts will hit autoconfirmed before anyone else.Risker (talk)21:13, 21 October 2025 (UTC)[reply]
Some clarification is needed here. The extension involved is a core Wikimedia MediaWiki extension and is deployed on all Wikimedia projects. I'm not seeing any discussion about whether this specific parameter is variable project by project, or if changing this parameter would affect all Wikimedia projects equally. I am also very concerned that the cart appears to be being put before the horse here. A lot of the comments above have made it clear that there are serious concerns about the current auto-confirm parameters being too low, and it seems rather absurd to reduce the parameters for Tor users to current levels if it is fairly likely that a similar discussion would increase the levels for non-Tor users. How about we settle what the right parameters are for auto-confirm, before we go monkeying around with a parameter that affects perhaps 25 people throughout the entire project?Risker (talk)17:41, 21 October 2025 (UTC)[reply]
@Risker, Wrt to your first point,Extension:TorBlock has two parameters$wgTorAutoConfirmAge and$wgTorAutoConfirmCount both of which need to be matched (over and above the normal autoconfirmed threshold) for a user to be autopromoted. These two variable can be configured to different values on a per wiki basis (as with all other configuration values). In this case, the change should only be made on enwiki. By setting them to zero, the normal auto-confirmed takes over, and if and when we decide on a elevated threshold, the newer elevated threshold will apply to Tor users as well by default. (i.e. with zero additional configuration change). Your assertion above thatAfter we increase the requirements for autoconfirmed for non-Tor accounts, then ironically Tor accounts will hit autoconfirmed before anyone else. is just incorrect, based on my reading of the codehere if the Tor configuration value is lowered to a number below the number of normal autoconfirmed threshold, the normal autoconfirmed threshold will prevail. I think you are conflating two very different things here, this RFC is "should Tor and non-Tor users have the same auto-confirmed threshold regardless of what it is", not "Tor users will be forever assigned the lower current threshold". --Sohom (talk)22:19, 21 October 2025 (UTC)[reply]
Permission to create beetle articles at a pace that exceeds the normal limit
Hello everyone. I have been creating stubs and expanding existing articles on beetle species for a while. They range from very short, to start class (I guess).If they are very short, they always include: a taxobox (with all relevant info, including all synonyms), distribution of the species and host plant/prey (if known). It seems I create articles at a pace that has raised some eyebrows for some fellow wikipedians. See:User_talk:B33tleMania12 andWikipedia_talk:Notability_(species) to read all about it. What I am requesting is permission to add beetle articles like I am doing (which may include a range of thesevery short articles). I was told that the normal daily limit is between 20-50 articles per day. I guess that if I could get a waiver to create about 100 per day, that would at least make clear to everyone that it is ok what I am doing. That being said: I am now working on a source that allows me to create thesevery short basic stubs. I do intend to get back to making more sizeable articles after that, see for examples all species articles I created for this genusCephaloleia (but I might in the future like to work on a list of these basic stubs again if I find a good source).B33tleMania12 (talk)22:26, 26 September 2025 (UTC)[reply]
Oh, I dont make automated or semi-automated articles. I use a template in notepad which includes the static info. That is why the request is not a pure MASSCREATE request.B33tleMania12 (talk)22:29, 26 September 2025 (UTC)[reply]
I think this is okay. The subjects are all notable perWikipedia:Notability (species), and there is basically no chance of them being deleted. A spot check shows that he's citing two sources in each stub. The{{Taxonbar}} links indicate that most of these have another half-dozen reliable sources available. Unlike other species, there doesn't seem to be an authoritative, comprehensive database for beetles, so I'm glad that he's checking them individually. Looking at articles such asBrontispa cyperaceae, even the shortest ones provide basic information (name, type, family, location, what it eats), plus the usual{{Speciesbox}}. Articles such asGonophora whitei provide even more (that one even qualifies forWP:DYK).
"The normal rate", or at least the normal maximum underWP:MASSCREATE, is 25–50 articles per day. I think B33tlemania12 recently created about 100 or so articles in one day. That's a lot, but reviewing these is so much quicker and easier than for, e.g., BLPs, that it's IMO not unmanageable on our end. I have seen discussions about the creations, and none of the comments are about an unfair load on page patrollers.
Based on prior discussions, I believe that any complaints will take one of two forms:
People who (incorrectly) think that systematic article creation (as opposed to hopscotching through whatever catches your eye) turns Wikipedia into a database.WP:NOTDATABASE is about not putting unexplained raw data into an article; it's not about writing an ordinary sentence about whether we know what a given beetle eats.
As someone has unilaterally draftified a few of these, I want to say that there is no point in sending these through AFC; species articles are evaluated only for notability, which means that species articles get kicked right back out into the mainspace. (AFC's job is not "protect my delicate eyes from all theseWP:UGLY little stubs"; it's job is to determine notability of thesubject, rather than the beauty of the current revision, and to get pages moved to the mainspace as soon as the AFC reviewer is confident that the article is unlikely to be deleted if it's sent to AFD.)
I don't think that either of these are valid reasons to prevent or slow down the creation of these articles. IMO these are decent, if usually brief, articles on obviously notable subjects, and the creator should be encouraged to continue creating articles with a minimum of two cited reliable sources. If someone wanted to create, say, 500 articles a day, then I think we should have another discussion, but for anything in the 500 a week range, I think we're just fine.WhatamIdoing (talk)23:22, 26 September 2025 (UTC)[reply]
" The links indicate that most of these have another half-dozen reliable sources available. " Nope. E.g.Aspidispa maai has 8 links in the taxonbar, but at least two of them (Wikidata and iNaturalist) are not reliable sources, others are not independent of each other: Open Tree Taxonomy is an automatic representation of data from GBIF, also included in the taxonbar, similarly Catalogue of Life is a rehash of ITIS, and ITIS is already a reference in the article anyway. I wasn't able to access BioLib (thanks to AI scrapers overload), but the others are at best interdependent databases, not a series of reliable independent sources.Fram (talk)13:45, 30 September 2025 (UTC)[reply]
No, but we don't count them as multiple sources (e.g. multiple newspapers reposting the same Reuters report = one source). The Taxonbar doesn't indicate what you claimed it did.Fram (talk)08:50, 1 October 2025 (UTC)[reply]
The notability of a species doesn't depend on how many sources exist.
Those links overlap, but I think most of those sources also contain some unique information. For example, inAspidispa maai, the first link in the taxonbar has very little information, but gives the family's common name of 'leaf beetles'; the second link says that it's an accepted species, which isn't in the first, and doesn't say anything about the common name, which is; the third link says it has bilateral symmetry, which isn't in either of the prior ones, and so on. Unlike the example of a Reuters or otherwire service article, they are not simply duplicates of each other.WhatamIdoing (talk)15:30, 1 October 2025 (UTC)[reply]
Your first sentence is a rpeply to nothing. The "first link in the taxonbar" is to Wikidata, which is not a reliable source. Like I said already. The second link is another wiki, again not a reliable source, third one is one I had no issue with, and then you "and so on" the ones I actually did discuss to indicate that your "another half dozen reliable sources" was incorrect (three wikis, one other already used as a reference, so immediately you are down to 4 anyway; and then something like the "Catalogue of Life" entry[1] is just a copy of ITIS, the exact same data presented in a different layout; this is not "another" reliable source, this is two instances of the same database (just like opentree is a gbid copy, not a new source). So the taxonbox on this article gives us two new databases.Fram (talk)15:57, 1 October 2025 (UTC)[reply]
Well, for this subfamily, there will always beat least three reliable sources (if you include ITIS and its 'copies' if you want to classify them as such). That is: 1. World Catalogue of Hispines, 2. The original description of the species (this must exist for it to be an accepted species) and 3. ITIS. For most, more will exist, but I think these three would be enough to get it at least at the level ofAspidispa maai (which could be longer if I would have included more detail about the species description, but I think that would make it too technical and I don't want to add words just to make a certain imaginary threshold. I do copy the full species description from old sources sometimes, because they are written in such a way that make it hard for me to rewrite (I do try to make proper sentences though, which is often not the case in the original. All of that being said: I wont be able to get access to point 2 sources (the original description) if they are behind a paywall or in a language I dont understand (and if google translate isnt able to make me understand). However: even if that part of the article would be missing (for now or worst case forever), as I understood it, these would still be acceptable articles. So the debate is not IF I am allowed to make them, but at which pace. At least, that was the intention of the discussion. To add to this (I wont use any user names to spare them the ) but I have seen other articles being added constantly that are lower quality (bare URLs, only one sentence, etc.) and I have looked at the Talk pages for these users, and there is no discussion (sometimes suggestions to improve, that are not followed by that user, at which point nothin happens), so I am wondering what that is about. Besides not following the suggestion to merge species into genus pages and making too many in a short amount of time, I have (I think) taken to heart every comment made by others to improve the articles. Anyway: I think there will be no end to this discussion and I don't know how this works now.. the question was if I could make more than the normal daily limit. So far, there is not a clear answer I think?B33tleMania12 (talk)17:37, 1 October 2025 (UTC)[reply]
I was not commenting on the request you made (although I would prefer in general that much more often similar short articles would be combined into lists, by all editors), I was commenting on typical clearly incorrect statements by WhatAmIDoing. Requests like yours should be discussed on their actual merits, not on misconceptions from other editors.Fram (talk)08:21, 2 October 2025 (UTC)[reply]
My first sentence ("The notability of a species doesn't depend on how many sources exist") is a reply toyour comment thatwe don't count them as multiple sources – as if that could be a problem, given thatWP:NSPECIES does not require multiple sources.
I ignored Wikidata in counting the links, because obviously we don't use wikis as reliable sources. I'm not sure where BioLib falls in theWP:UGC spectrum. The website says "Unlike other systems such as Wikipedia users are not directly changing content of BioLib but the added data is added as "unconfirmed" and our administrators review it first before accepting it among verified data". This constitutes "editorial oversight", to use the wording in WP:V and WP:RS, but is itgood oversight, or rather perfunctory? Someone would have to know more about that site than I do. At first glance, though, I wouldn't describe it as a wiki myself.WhatamIdoing (talk)23:41, 2 October 2025 (UTC)[reply]
I agree with the above that this seems OK. Being efficient and systematic are not problems. It sounds like enough care is being taken to avoid bad information being included in the encyclopedia, which is the most important thing.Stepwise Continuous Dysfunction (talk)15:36, 27 September 2025 (UTC)[reply]
I likewise agree. People may prefer longer articles, but these are longer than the alternative, which, unless you are prepared to write about the subject yourself, is of zero length.Phil Bridger (talk)16:41, 27 September 2025 (UTC)[reply]
Ok, thanks for your input all. I do not know how much time must pass to come to a conclusion, but I am going to at least move the drafted stuff back to Live.B33tleMania12 (talk)12:04, 28 September 2025 (UTC)[reply]
I do question whether having separate articles onevery species of beetle is the rightapproach (I would probably go with a list), but that is more a quibble with the notability guideline itself and not with therate at which the articles are created. THAT is more an issue of not overwhelming new article reviewers. If they are comfortable with this, I don’t see a problem.Blueboar (talk)17:12, 27 September 2025 (UTC)[reply]
Oppose. If all the content you have for an article isthis then please do not create a new article. Consider adding it to a list instead, as I have suggested to you multiple times. I do not understand why editors want to create so many low quality articles. You should get more satisfaction from writing afeatured list and this would serve readers much better. In my opinion 25 new articles in a day is plenty, and allowing more means that editors will not be giving due attention to the new articles they create — Martin(MSGJ · talk)08:26, 30 September 2025 (UTC)[reply]
It is not the only thing I have, but like I said numerous times also: it is easier to first make the page at the right place (i.e. get the taxonomy right) before adding more detail. If I add more info right away, I have to do a dive into taxonomic changes for each individual species. The source to expand the article you just mentioned would be this:Wayback Machine, but I would like to get the species pages added first, so I don't waste time adding species that have now been placed in synonymy, moved to other genera, etc.B33tleMania12 (talk)08:40, 30 September 2025 (UTC)[reply]
Do we have any statistics that show how likely a separate article is to be expanded, as compared to an entry on a list? Intuitively it feels to me that a separate article is much more likely to be expanded.Phil Bridger (talk)10:51, 30 September 2025 (UTC)[reply]
The point of comparison would be what articles are created from a redlink on a list (or unredlinked item?), rather than expansion on the list itself.CMD (talk)13:01, 30 September 2025 (UTC)[reply]
Depends on the list? A table-formatted list, or one with descriptions for each item, might see expansion. A list of bare names (seeAspidispa#Species, for the example Martin gives) is unlikely to be expanded in the list. I guess the answer to your question is: B33tleMania12made that list of redlinked species, and is now turning the red links blue, and Martin recommends that they should go make the list...that they already made.WhatamIdoing (talk)15:25, 30 September 2025 (UTC)[reply]
Yeah, and I'd rather that admins didn't restore potential copyright violations[2] added by an editor with a history of source fraud, socking, and nationalist POV stuff, after being told they were likely copyright violations,[3], and I'd also really like it if their most recent article creation didn't have a bunch ofclose paraphrasing of a tourism site (ad) that theysplit from the main article, but I guess those were more satisfying? Beetle guy's article contributions are higher quality that than, anyway. If they want to make these articles, then I saylet them.GreenLipstickLesbian💌🦋09:39, 1 October 2025 (UTC)[reply]
I'm with Martin, I don't support this but I also don't necessarily oppose it. It's worth noting that you've been denied autopatrolledtwice, most recently in August, so I don't know if mass-creating would be the best idea.EF513:11, 30 September 2025 (UTC)[reply]
To be fair, one of those denies was down to the fact that the editor creates articles that 'are easy reviews' (which did strike me as an odd rationale!) and the other was that the editor hadn't created any long articles (when they clearly create very short ones). It appears to me that many, many of these species type stubs are out there and the bar for creation (ie: not applying WP:GNG to the letter) appears to have long been set low for species stubs, no? BestAlexandermcnabb (talk)14:20, 30 September 2025 (UTC)[reply]
It's not that odd a rationale if you consider why autopatrol exists. It is a means of reducing the work involved in new page patrolling, rather than a hat to be collected.Phil Bridger (talk)15:47, 30 September 2025 (UTC)[reply]
Fair enough, but an editor creating hundreds of valid species articles (and I couldn't find one that NPP had rejected/tagged/draftified) could - and I believe should - be autopatrolled, even if each article isn't a huge overhead to review. But, hey, that's just me... BestAlexandermcnabb (talk)16:10, 30 September 2025 (UTC)[reply]
I did not ask for autopatrol myself, so I was not aware that I was 'denied'. I do not care for myself either, but I guess it would help others. Anyway: it seems reasonable not to give autopatrol too soon. You never know how that might turn out in the end.B33tleMania12 (talk)16:32, 30 September 2025 (UTC)[reply]
It's fine I bet the boys and girls at New Page Patrol love you... The articles are indeed valid (and have been universally patrolled as such by NPP) and a nice, easy new page review at that! BestAlexandermcnabb (talk)08:39, 30 September 2025 (UTC)[reply]
Oppose this is aWP:PAGEDECIDE issue and here the answer is often "no". Instead of aiming for completion, we should ask: do these articles help the reader? And the answer isno, because the reader wants an encyclopedia article, which is not what they're getting.Wikispecies is a worthy project, but it's not this project. Microstubswhich have very little hope of expansion aren't helpful; they're an annoyance.Cremastra (talk·contribs)21:45, 30 September 2025 (UTC)[reply]
I have a few suggestions for this. First, you could create pages in draft space and submit them for promotion. Second, as some have suggested above, you could start with list articles creating summaries of this information with many redirects pointing to those lists.BD2412T22:32, 30 September 2025 (UTC)[reply]
@WhatamIdoing Species to genus redirs are fine if there is, as BD suggests, actually information at the target. What generally get deleted is when the genus article is just a list of species which redirect back to the same article, with no actual information anywhere.Cremastra (talk·contribs)22:58, 30 September 2025 (UTC)[reply]
Sure, that is all possible. The way I wanted to work is create a basic stub and then use a source to expand them. Because this seems to keep going forever. I also refute the claims above that these 'can never be expanded'. So (as I already did before), I spend some extra time fleshing some out. If these are still not satisfactory, then I guess I am done with Wikipedia and wish future editors good luck with the bureaucrats. For the work I did the past hour on expanding:User contributions for B33tleMania12 - WikipediaB33tleMania12 (talk)22:43, 30 September 2025 (UTC)[reply]
Support. I have frequently encounteredB33tleMania12's articles while doingnew page patrolling. At first, I thought there was something up - the number of new creations in so short a time, and the brevity of the articles. But looking at new page criteria, all of the articles, while essentially stubs (at least initially) meet our criteria. Sure, there's an argument that theycould be just some list articles, but theyare being expanded, and - well, anyone is free to create a list article if they want? Why not both? (Also,Alexandermcnabb - yes! ;-)BastunĖġáḍβáś₮ŭŃ!09:52, 2 October 2025 (UTC)[reply]
Support. Up to 100 per day seems OK to me. These are not going to flood watchlists and there's no question of notability. Re the argument that they are permastubs: some are likely to remain stubs for a very long time, but as far as I can that's generally because there are a lot of them, not because they are inherently incapable of expansion.Mike Christie (talk -contribs -library)11:22, 2 October 2025 (UTC)[reply]
So we're looking at about 400,000 articles. Is that an issue? It would be nice to have 400,000 images to go with them. But an enduring, free to access, record of them is a good thing, no? BestAlexandermcnabb (talk)16:56, 5 October 2025 (UTC)[reply]
I would say yes(create all of them), as long as the article is more than a bare taxonomic list, i.e., it has some description, and some indication of its range (I really dislike reading that a snail species is "endemic to the United States" [which was copied from a database] when it is actually endemic to a single spring.) The premise of the recent RfC establishing NSPECIES was that a description of the species had to have been published for it to be accepted by the relevant authority. So, at least summarize that description in our article. If you cannot find the description for a particular species, move on to another species for which you can find the description. There will be plenty of such species to write about for a long time to come.Donald Albury17:40, 5 October 2025 (UTC)[reply]
It would take me a lot longer than that. It has taken me a year to create eight new articles and expand 36 stubs in a plant genus, and there are 43 stubs and four redlinks to go. Of I course, I am continually being distracted by rabbit holes.Donald Albury19:53, 5 October 2025 (UTC)[reply]
Support On condition that you make the new articles as fleshy as possible. A meaty stub of no less than 1kb readable prose ideal. Given that I've been running contests to reduce the number of stubs, I would prefer it if you were able to generate start class ones over 1.5 kb if possible. Rate of creation is of no issue to me as long as they are accurate and error free. No short database stubs please.♦Dr. Blofeld20:19, 5 October 2025 (UTC)[reply]
Support and I say this as a reviewer who has accepted hundreds of their creations already. I don't see any policy-based reason for these species to not be deserving of articles.Lynch4400:20, 17 October 2025 (UTC)[reply]
Oppose Pages likePrionispa vethi are incredbly low-quality. Articles should not be created if you aren't going to include more than a statement of existence and a country. Improvement of genus articles likePrionispa would be more beneficial than countless species pages.Reywas92Talk14:35, 17 October 2025 (UTC)[reply]
Well, the idea is to expand them to something like this:Oncocephala camachoi, or thisOncocephala cuneata. However: especially for species that were described long ago: It would be highly beneficial to have them at their current name and with synonyms. If they are, you can just go and insert the original descriptions from that old source and add them to stubs already in place. That at least, was the whole idea. To get those basic articles on wikipedia however, I would need to add them. I try to expand the ones I happen to have a good source about right away, however: other sources might be behind paywalls or scattered all over the internet. But all that aside though: the discussion is about thepace, not about the articles itself, since I now know enough to be confident that they are allowed.B33tleMania12 (talk)15:56, 18 October 2025 (UTC)[reply]
@B33tleMania12, open it in the visual editor (https://en.wikipedia.org/wiki/Oncocephala_camachoi?veaction=edit should work). Put your cursor at the end of a paragraph, where you want the little blue clicky number to end up. Click the "Cite" button in the middle of the toolbar, and choose the "Reuse" tab. Click the big blue button to publish your changes. The software will handle everything automatically for you.
Oppose - We should not be generating possibly hundreds of thousands of articles that will never be expanded. No objection for redirecting to lists.FOARP (talk)12:58, 18 October 2025 (UTC)[reply]
So... just to be clear here, the question isn't whether we are "generating possibly hundreds of thousands of articles that will never be expanded". Notable subjects are notable even if the article isWP:UGLY. The only question here is whether they'll be created at a rate of, say, 20 a day vs 60 a day. (Also, we haveevidence that this editor actually does expand stubs later.)WhatamIdoing (talk)18:53, 18 October 2025 (UTC)[reply]
Support - we have in this case a relatively recent notability guideline (WP:NSPECIES) with community consensus, supported by an active project that includes subject-matter experts. We have an editor who is following that guideline and producing results that conform to our policies and guidelines. That editor would like flexibility in creating up to 500 articles per week rather than 50 per day - I see no reason to deny them.
I've seen a few !oppose votes by editors who are using this request as a pretext to object to NSPECIES. I don't think those arguments should carry any weight in the decision about the request, since they are in effect arguing that these policy- and guideline- compliant articles should not be created at all. Such an argument isoff-piste in a discussion of whether 200 or 500 is a better number of articles to create in a week, IMO.Newimpartial (talk)20:09, 18 October 2025 (UTC)[reply]
Comment It seems to me that sometimes there is genuinely very little to say about an individual beetle. In other words, we cannot expect these articles to be expanded much because there is literally no more information to add. Is that a fair take? Or is the intent to create the articles first and expand them down the line?Pinguinn🐧23:02, 21 October 2025 (UTC)[reply]
No, I don't think that's true. Look at an article likeCallispa cumingii (created by the OP in August and expanded by the OP in September). It's 12 sentences/more than 200 words long with two sections after the lead. For reference, the median English Wikipedia article has just 13 sentences, so this is definitely a statistically normal size of article for the English Wikipedia. Since we spend more time at bigger articles, I think editors forget what an average article looks like. We have never had a rule requiring a minimum size for articles. I've just added a table toWP:SIZERULE that should let editors compare the size of an article against the distribution. For example, 20% of our articles have ≤100 words, a third of them cite ≤2 sources, and so on. Whenever you're feeling like an article is unusually short, it's probably worth checking the table, because "feels too short" often falls into the statistically normal range for article length.
It might be possible to expand articles likeCallispa cumingii article even further (e.g., in this case, to say that the first published scientific description was byJoseph Sugar Baly in 1858, whether the beetle causes agricultural/economic concerns, what the binomial name means...). There will be some for which this much isn't easy to do, but only because interested editors have trouble getting their hands on the right sources, not because it isn't possible in principle.WhatamIdoing (talk)01:44, 22 October 2025 (UTC)[reply]
This assumes that most Wikipedia articles are already the size they should be, rather thanalso being too short. Fully 36% of our non-redirect, non-disambig mainspace pages are explicitly marked as in need of expansion, either with a stub template (the overwhelming majority), one of the article- or section-scope templates listed atTemplate:Expand, or both. Being as long as the median article, when it's been skewed low by that many articles that are known to be too short, doesn't mean it's good enough. —Cryptic02:28, 22 October 2025 (UTC)[reply]
This assumes that (nearly) all non-deleted Wikipedia articles are a size that the community actually does accept, which is IMO a valid definition of "good enough".
If we want to have a rule that says "Articles must have at least X words in them within 24 hours of their creation", then let's make that rule, but let's not pretend that there already is such a rule and that therefore these articles are somehow non-compliant with the non-existent rule. (Though if you want to make new rules, I'd suggest trying to get consensus for a rule saying that "All articles must cite at least one source, even if the article is so short and boring that it contains noinformation for which an inline citation would normally be required" first. Because we don't actually have that rule on the books either, no matter how much we like to pretend otherwise.)WhatamIdoing (talk)02:48, 22 October 2025 (UTC)[reply]
Just commenting on the initial question: yes, the idea is to expand if I have access to a source that lets me. Every species has at least a description. Problems are: sometimes I dont have access to that description (pay-walled stuff) or (especially in the case of the group of species I am working on now [but am almost done with]) were originally described in German/French/Italian or even just in Latin. I have found a lot of these original descriptions, but I am not confident in my ability to properly translate these descriptions. For a lot of the species in that category, there are also descriptions in English available, but these are often also pay-walled.B33tleMania12 (talk)07:44, 22 October 2025 (UTC)[reply]
If you have the original descriptions but are not confident in translating them, just include them as an external link.CMD (talk)08:22, 22 October 2025 (UTC)[reply]
I support what this editor is doing. It's a little unorthodox and understandably raises some eyebrows. In addition to filling content gaps, this editor exhibits many desirable attributes by seeking input here and acknowledging the value of new page patrol. Thank you,B33tleMania12, for your contribution to the encyclopedia! —Myceteae🍄🟫(talk)16:02, 25 October 2025 (UTC)[reply]
The following discussion is an archived record of arequest for comment.Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
The current CC image license tags (e.g.Template:CC BY-SA 4.0) are quite barebone, providing little information to the reuser. This is a proposal to make them more descriptive, like the equivalents at Commons, e.g.c:Template:Cc-by-sa-4.0. 15:46, 11 October 2025 (UTC)
to share – to copy, distribute and transmit the work
to remix – to adapt the work
Under the following conditions:
attribution – You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
share alike – If you remix, transform, or build upon the material, you must distribute your contributions under thesame or compatible license as the original.
(The above are just mockups) 15:46, 11 October 2025 (UTC)
This is just a mockup (I was a bit lazy to subst all the int statements) - I plan to create templates likec:Template:Cc-by-sa-layout on enwiki, obviously with a bit of reworking to remove unnecessary i18n. I also think width: 100% could be used, since we don't need to narrow width for a short license statement, unlike text. Please reply with whether you support or oppose the change along with comments. Thanks, —Matrixping mewhen u reply (t? -c)20:06, 2 October 2025 (UTC)[reply]
Weak oppose - I'd rather editors who aren't familiar click through and get the official short and long license explanations, rather than duplicating it here and possibly misleading. But that's just my opinion right now, it could change.SarekOfVulcan (talk)20:11, 2 October 2025 (UTC)[reply]
If we have a CC image on en.wiki, it should be moved to commons, so I would not worry too much about our templates hereMasem (t)20:12, 2 October 2025 (UTC)[reply]
Support aligning to Commons. If we had universal cross-wiki templates, this would be a no-brainer application of them. We unfortunately don't. But this is a hugely important template at Commons, where they have presumably put a lot of thought into it, whereas the template here is rather niche (as Masem points out) and quite possibly underdeveloped/outdated. The best approach is therefore to follow whatever Commons does. For editors who oppose the design spelling out the terms more explicitly, I'd suggest taking that up on Commons as a far more impactful course of action than arguing about the local version of the template.Sdkbtalk21:22, 5 October 2025 (UTC)[reply]
Support per Sdkb – ideal to have consistent templates cross-wiki, especially since many of its uses here are for files to be copied to Commons, and I trust Commons editors on this one.ChaoticEnby (talk ·contribs)15:28, 12 October 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.
Removing the Births and deaths sections of 20th and 21st century years
I would like to consider removing the births and deaths for all 20th and 21st century years. Right now, they are only removed in years after 1980 and just have categories. I would like to extend this to all years starting from 1900 so that the Births and deaths sections only have categories and pages. I tried implementing this with AWB, but the edits didn't turn out good. I would like to initiate a discussion to achieve consensus on whether to implement this or not. I will leave a notice atWT:YEARS so that we can get some input.Interstellarity (talk)22:17, 15 October 2025 (UTC)[reply]
@Interstellarity, could you link to the discussion that did away with post-1980 births and deaths? (I'm just curious to read the reasoning behind it, have no opinion on it myself.) (Thebiguglyalien linked it below)Schazjmd(talk)23:29, 15 October 2025 (UTC)[reply]
Oppose complete removal which would violate the policyWP:PROPORTION. If you look at reliable sources that are chronologies, they do include births and deaths. See, for example, the "Births and Deaths" sections inChronology of the 20th Century (Helicon, 1996)[4]. It might be reasonable to removeexcessive births and deaths, starting with those of relatively unimportant persons that are not referenced to a specifically "chronological" source, like that book.James500 (talk)21:16, 16 October 2025 (UTC)[reply]
If there is a source that demonstrates a birth or death to be a significant fact about that year, then it could be due for inclusion. The problem with births and deaths on year articles has always been where they have been added without any sourcing to support significance.Barnards.tar.gz (talk)16:02, 17 October 2025 (UTC)[reply]
I closed that 2023 RfC. Just clarifying a couple points:
Consensus developed tosplit large articles. This means there's no existing consensus forremoval, and as far as I'm aware, births and deaths are still in places likeBirths in 2001 andDeaths in January 2001 (similar articles exist for all the other months).
Since the consensus was based mainly on size concerns, 1980 is not a strict cutoff date. Anyone could split a pre-1980 article based on size concerns, citing the existing consensus.
Oppose removal.Iff the lists of births and deaths on a specific year's article (any year) is so large that it is disproportionate to the rest of the contents then they should be split to separate articles. If the list of births and deaths on a specific year's article (any year) is short enough that the whole article is not dominated by the list then it should remain a single article. In cases where the length of the list is borderline, discuss it on the talk page of the article concerned and follow the individual consensus.Thryduulf (talk)13:17, 23 October 2025 (UTC)[reply]
Links are interactive elements, and interactive elements should clearly indicate that you can interact with them. Colored links indicate interactivity poorly or don't indicate it all (e.g.Template:AFL Women's; links' color is the same as non-interactive text's color), therefore they should be underlined, as that's the only way to know that something is a link, besides color (obviously).
Best solution would be to follow our basic accessibility protocols and fix the hidden links as perMOS:COLOUR"Links should be clearly recognizable to readers as clickable. The appearance of wikilinks are standardised in the default skin" andWP:NAVBOX"Each link should clearly be identifiable as such to our readers. In general, text colors should be consistent with Wikipedia text color defaults, so links should be blue; dead links should be red; and red and blue should not be used for other (non-link) text". I like the idea of a work around... but I'm also concerned this will cause more usage.... instead of this being fixed to the betterment of our readers.Moxy🍁19:54, 16 October 2025 (UTC)[reply]
Oppose: Where is this even an issue? Links should never be manually colored in article prose, so I don't know where this might be an issue. If you, like me, miss the days before thea{text-decoration:none;} trend, you can change your skin to one that still underlines or setPreferences →Appearance →Advanced options →Underline links:. Having a mix of underlined and not-underlined links would be messy and goes against users' preferences settings (some might have their skins set to never underline).Dan Leonard (talk •contribs)20:09, 16 October 2025 (UTC)[reply]
I don't know where this might be an issue - navboxes, sidebars. Also, people are going to manually color them in prose anyway.you can change your skin - I'm proposing to modify the template because I believe that this addition will be an improvement forthe readers; not editors or myself.sapphaline (talk)20:16, 16 October 2025 (UTC)[reply]
Ah, I missed the link to{{AFL Women's}}: that's definitely an unfortunate template. However, it's a problem with that template's bizarre decision to hardcode the same color for text and links. An easy solution would be to use one color for unlinked header text and one for linked header text. For instance, keep the use of#FFFFFF white for the header text but use#ADD8E6 lightblue for the links in the header.As forpeople are going to manually color them in prose anyway: I have never seen that.Dan Leonard (talk •contribs)20:19, 16 October 2025 (UTC)[reply]
Well the use of#FFFFFF white on top of a#F16C51 background fails WCAG anyway. My proposed colors, of course, were a shot from the hip.#000000 black seems to have acceptable contrast with the orange color, so could be used for regular text just fine. Or just give up on that garish orange altogether.Dan Leonard (talk •contribs)20:34, 16 October 2025 (UTC)[reply]
Yes, the template is the issue and should be fixed. I predict one of these days we'll get fed up with all the hassle that navbox aesthetic coloring causes, and just ban it.FWIW I've gota few lines in my common.css that do a dashed underline, which I find a bit less obtrusive than the solid one. --Tamzin[cetacean needed](they|xe|🤷)20:26, 16 October 2025 (UTC)[reply]
I'd support having a bot check every{{navbox}} wrapper for abackground: value that is unlikely to support a WCAG-compliant text-and-link color contrast (maybe there's a band of hues or something that we could decide are forbidden for use as backgrounds) and reset it to the default blue.Dan Leonard (talk •contribs)20:49, 16 October 2025 (UTC)[reply]
Would the bot check for hardcoding as well? We have many sidebars and nav templates the have colored links but don't use the template.Moxy🍁21:13, 16 October 2025 (UTC)[reply]
The bot could check pages' HTML (rather than their wikicode) for elements within an<a>...</a> tag that have a color attribute set, which ought to cover all of the different ways someone might color a link. --Tamzin[cetacean needed](they|xe|🤷)21:30, 16 October 2025 (UTC)[reply]
Oppose This clearly is going to go against user preferences and harm readability. The underline is not expected when using the template, and shouldn't be included. Not to mention, per Dan Leonard, I see no reason why article-space guidelines would apply to this instance, since they aren't applicable with a lack of usage in mainspace. The use of inherit in the template should remain.EggRoll97(talk)17:24, 18 October 2025 (UTC)[reply]
Oppose, this sidesteps the actual issue (colored links being overused in templates and impeding readability). Yes, many templates have this problem, but it should be addressed directly, even if that takes more effort, instead of working on a surface change that may have the effect of encouraging it.ChaoticEnby (talk ·contribs)15:26, 20 October 2025 (UTC)[reply]
Make articles accepted through AfC patrolled by default
When an article is accepted throughAfC, it already has to have been reviewed by anextended-confirmed editor who applied for access to the Helper Script.NPP already has a huge backlog, and reviewing new articles that were already reviewed before being moved to mainspace takes up new page reviewers' time that could be spent reviewing articles that haven't been looked at at all.Shocksingularity (talk)00:04, 17 October 2025 (UTC)[reply]
One major problem with this (I believe discussed atWP:NPP prior), is that the criteria and bar for getting AfC perms and NPP perms is very low. This effectively means that any AfC person has the ability to patrol mainspace pages (provided they move something from draft). If we make the bar for both same, then the AfC backlog suffers the same fate of NPP. CC @Novem Linguae.~/Bunnypranav:<ping>05:13, 17 October 2025 (UTC)[reply]
No, for several reasons. 1. A list of unpatrolled, AfC-accepted pages is kept atWP:NPPEASY and is typically fairly short. These articles are already on a fast track through NPP. I'm not sure this change would meaningfully reduce the NPP backlog. 2. Having the two user groups separate is important for evaluating candidates and quality control. It lets us set a higher bar for new page reviewers, and applicants can be evaluated based on their AfC record. 3. NPRs can already mark articles they accept via AfC as patrolled if they choose, and this is done automatically for Autopatrolled AfC reviewers. I don't have numbers, but I suspect a large proportion of AfC-accepted drafts are immediately marked as patrolled like this. 4. I like having the option, when I accept a draft of dubious quality, to leave it unpatrolled for an NPR to give a second opinion.Toadspike[Talk]13:17, 17 October 2025 (UTC)[reply]
I think that most AFC folks already have the NPP user right (or are admins), and AIUI when someone with both rights accepts an article, it's defaultly cleared from the NPP queue. If someone wanted to minimize having two sets of eyes look at an article, then encouraging the other AFC folks to request NPP rights would be an efficient way to do it.WhatamIdoing (talk)00:30, 19 October 2025 (UTC)[reply]
No, an AfC accepts done by an NPR or adminwithout autopatrolled are not reviewed automatically. If the reviewer wants to mark it as reviewed, they have to click the "mark as reviewed" button after accepting.Toadspike[Talk]11:15, 19 October 2025 (UTC)[reply]
Good thought, but I don't think it's necessary. The only thing that NPP does to an acceptable article is make it indexable on search engines, which happens after 90 days anyway. In my experience, AfC takes much longer than 90 days, so anyone going through AfC is already playing the long game, with patience. The main usefulness of NPP is actually in sorting out inadequate articles. I have great respect for AfC reviewers and NPP, neither of whose jobs I could ever do, but I think it useful that AfC be backed up by subsequent NPP, perToadspike.Elemimele (talk)15:24, 17 October 2025 (UTC)[reply]
Interesting idea. PerWP:AFCPURPOSE, the core criterion AfC ought to be reviewing by is whether or not an article would survive a deletion discussion. In practice, the bar is much higher, but that's still the theoretical goal. Whereas for NPP, there are a bunch of other basic steps, like adding appropriate maintenance tags and projects, that are generally expected. Making an AfC approval also carry an NPP patrol would require us to raise the expectations of an AfC review, which could worsen the AfC backlog.Sdkbtalk21:08, 20 October 2025 (UTC)[reply]
IMO the appropriate goal for NPP is to set CSD-worthy pages on a path towards deletion. Everything else (e.g., maintenance tags) is IMO an optional nicety that the rest of us could do. When you look at what most NPPers actually do (they mostly check pages created within the last hour, and edit almost none of the pages they check), that seems to align with reality.WhatamIdoing (talk)02:08, 21 October 2025 (UTC)[reply]
adding appropriate maintenance tags and projects. This was made optional for NPP reviewers a couple years ago in order to speed up reviewing. Gnomes can handle this part. The important part of NPP is checking for notability, speedy deletion, page title, stuff like that. –Novem Linguae(talk)05:15, 21 October 2025 (UTC)[reply]
Oppose. Right now, it is easier to get the AFC perm than the NPP perm, and this is because NPPs double check AFC accepts. If we were to make an AFC accept also cause an NPP auto accept, then we'd have to raise our screening for AFC reviewers, and might as well at that point get rid of AFC reviewers entirely and just require them to be NPP reviewers. For this reason, I think the status quo is superior. AFC reviewing provides a warmup / training ground / proving ground for future NPP reviewers, while reducing the risk since accepted drafts by non-NPPs get a review by NPPs. –Novem Linguae(talk)05:13, 21 October 2025 (UTC)[reply]
Here's an idea that came to me today after seeing a message in the Teahouse from an editor who said that work in his sandbox was being reverted. I can't imagine why someone would do that to a draft article other than malicious pleasure — and hopefully it happens only rarely — but with that in mind I'd like to share an idea to help avoid that sort of thing.
A while back I discovered it's possible to create additional sandboxes, with the idea of providing me a place to work on more than one article at a time (e.g., "sandbox2"). After coming across the Teahouse message today, I decided to see if it were possible to create sandbox-like pages using other titles (e.g., "Adventuring") where drafting of articles could go on with even more privacy. I found it was.
So now I wonder what other Village Pump frequenters think of suggesting the creation of sandbox-like personal pages as a way to compose articles a bit more privately and less likely to get reverts from outside. Although there's probably no way to ensure a 100% guarantee that outsiders never find and mess up an article being drafted, perhaps making this workaround known would cut down on the likelihood.Augnablik (talk)09:06, 17 October 2025 (UTC)[reply]
You can create all the subpages to your userpage that you find useful, as long as they generally conform to the requirements of theWikipedia:User pages guideline. I have for many years composed new articles on a sub-page and only moved them to main space when I am satisfied they are ready. I currently have close to 70 subpages containing lists of things to work on, draft articles in various stages of completion, list of potential sources, essays in various states of development, etc. I will note that it has taken me 20 years to accumulate those pages, and I would advise new editors to only create subpages when they are for a purpose that will help improve the encyclopedia.Donald Albury17:53, 17 October 2025 (UTC)[reply]
Good heavens, @Donald Albury, 70 “subpages”! That’s impressive, but also a little astounding. It would seem you’d need some sort of a table of contents with so many pages.
So, then, @Pinguinn, seeing such an article shows that this idea has come up before in Wikipedia. Do you know if there’s been much discussion of it, especially about benefits to editors?Augnablik (talk)08:14, 18 October 2025 (UTC)[reply]
I don't think there's been any centralized discussion, but I've certainly seen the essay posted multiple times in different discussions when topics like this come up, so clearly people are aware of it. It's far too opinionated of an essay to be bumped up to guideline or policy IMO, but I think that's ok.Pinguinn🐧09:10, 18 October 2025 (UTC)[reply]
If I understand the inquiry correctly, Augnablik, you are asking about the cost-benefit of more or less fully private sandboxes? If so, while I understand why your initial impulse is to see the benefit of encouraging editors to work on content without concern that their work in progress will be derailed by violating some content policy (or some random user's idiosyncratic view thereof), I do think there would also be substantial community concerns about such a system. Such pages would be highly susceptible to ending up hosting all manner of content that violates our user page guidelines or even more basic and non-negotiable policies (WP:CHILDPROTECT andWP:LIBEL come to mind), even if the content weren't public facing. If nothing else, I would imagine that maybe even the majority of such pages would end up violatingWP:NOTWEBHOST in various respects. The potential liabilities and drain on technical resources of the clutter that would accumulate in these namespaces hidden from most users--and thus not subject to the usual oversight and clearing for variousWP:WWIN reasons--would end up being non-trivial very quickly, I would think. Ultimately, a big part of this project's success and resilience is down to it's high levels of transparency, and I think the community would have a hard time squaring the idea you propose with those values and needs, just to provide you frankest possible feedback I can.SnowRise let's rap16:08, 18 October 2025 (UTC)[reply]
Thank you, @Snow Rise, for such a comprehensive response! Much appreciated. I didn't think of my question as a "cost-benefit" one. But you understood what I had in mind, and you brought up some things I hadn't thought of as issues.
From your comments, I see where Wikipedia would have objections to general promotion of the idea I'd asked about. But I'd really like to quietly have a few such pages where I could work without worrying about others creeping around. I have zero interest in adding morally offensive content. Hmm ...Augnablik (talk)18:09, 18 October 2025 (UTC)[reply]
Pages that hardly anyone reads and nobody edits do not create a "drain on technical resources". Remember, "deletion" doesn't free up disk space; it keeps all the revisions of all the deleted pages, and merely hides them from non-admins – and generates extra log entries to record the deletion. In general,Wikipedia:Don't worry about performance.
@WhatamIdoing, I think @Donald Alburydid mean he has something like 70 subpages — thisWikipedia:Sandbox seems to be more of a place to try things out before drafting an article in our own personal sandboxes, though I'd forgotten all about it till you provided that link.
But I was a little confused when I followed the link and noticed article mentioned we could also use our personal sandbox or the "Sandbox" link at the top right, because I didn't see that link. That statement seemed to me to be referring to yet a third type of sandbox link, though I can't picture why there'd need to be one.Augnablik (talk)11:26, 19 October 2025 (UTC)[reply]
Before the creation of the draft namespace, that's what editors did when they wrote a draft: they created a subpage of their user page. When the draft namespace was created, the community consensus at the time was that the new namespace did not obsolete this prior practice. So your proposal is already current practice. If you aren't planning to use the articles for creation process, the only reason to use the draft namespace is because you want others to potentially find it and collaborate.isaacl (talk)23:49, 18 October 2025 (UTC)[reply]
In light of both your comments, @WhatamIdoing and @Isaacl, I think I've just grasped something that explains a misunderstanding I seem to have had about sandboxes, all due to there being two different kinds of them. If "sandbox" weren't used with slightly different meanings, I doubt that my misunderstanding would have arisen.
Although I vaguely recall hearing long ago about a sandbox where editors could play around trying out different Wiki features, it was maybe just once ... and besides, we can play around that way in ourpersonal sandbox, not just create articles. The only kind of sandbox I've been familiar with over my 3+ years with Wikipedia is my personal sandbox, then additional ones I found it was possible to create like "Sandbox2."
With this in mind, I think you can see from the brief Teahouse discussion where I got misled, thinking that CyberTheTiger was saying the edits in hispersonal sandbox were being reverted. He must have meant his edits in the more general sandbox. Here's what it looked like.
Topic title: "Sandbox edit reversion"
Why don't I get notifications when my edits to the sandbox are reverted unlike other pages?Cyberthetiger🐯 (talk)
I think it's because the bot that reverted yours and other editors' edits after yours has manually reverted those edits. Everytime when someone manually reverts an edit of mine, I never get notified for it for some reason.Hacked (Talk|Contribs)
So I withdraw the proposal I started off with, but I would like to see other editors become aware of the value of creating more than one sandbox if they find a need to work on more than one non-AfC article or other Wiki things at the same time. Obviously some have figured this out, but I doubt many.Augnablik (talk)18:31, 19 October 2025 (UTC)[reply]
I would guess you are looking for a way to make newly registered users aware ofWikipedia:Subpages (which is linked from the "Subpages" definition inWikipedia:User pages#Terminology and page locations. One problem is that there are many different pages that we would like all new editors to become aware of, but there is a danger of overwhelming those users before they gain their footing. Off hand, I don't have an answer for that.Donald Albury18:46, 19 October 2025 (UTC)[reply]
It's my hope, @Donald Albury, once I finish up several other edit priorities, to begin working on some ideas for helping newbies navigate this overwhelming new world of Wikipedia in a little more functional way than I — and probably many others — did. There's no reason that many tips like the value of using subpages, and how, need to overwhelm recent arrivals.
Or that there need to be so many "pain points." That's what a much more senior editor to me calls the agonizing discoveries Wiki editors make after doing tasks incorrectly or getting into a bit of trouble. Knowing that in real life I'm an instructional designer, he encouraged me to make a collection of my own, which I've been doing.😅Augnablik (talk)13:12, 20 October 2025 (UTC)[reply]
The biggest problem we have with the documentation is duplication. If you could update or consolidate existing pages, that might help more than creating any new ones.WhatamIdoing (talk)02:11, 21 October 2025 (UTC)[reply]
That is indeed a basic problem, and I’ll be happy to help with that. There are also quite a few other needs with easy remedies, requiring just investment of time.
What I’d love to do when I get free for such a project is draw not only from my own collection of personal “pain points” and observations but also from interviews or questionnaires with senior editors, admins, and patrollers to ask what they wish green arrivals would understand and be able to do — as well as those further along but still rather wet behind the ears. (But when do we leave that stage? 😅)Augnablik (talk)07:02, 21 October 2025 (UTC)[reply]
Thanks so much for this, @WhatamIdoing, especially for reminding me of Clovermoss' project in that same area. It will be a good starting point for what I have in mind.
"Sandbox" is a description of how a page is used: as a testing ground to experiment. To make it easy for a new user to find a place to experiment, the documentation directs people to a couple of pages that can be used in this manner (Wikipedia:Sandbox or the sandbox subpage under your user page). However from a technical perspective any page, created anywhere, can be used as a testing ground. By convention, if the sandbox is associated with some other page, WikiProject, or user, the sandbox is normally a subpage of the corresponding page. Draft articles in theory can also be created anywhere, though they shouldn't be created in a way that can cause confusion with mainspace articles. In practice the convention is that new drafts are created as subpages of a user page or a WikiProject page, or as a page in the Draft namespace. Though there is a semantic difference between a draft article and a sandbox page, I appreciate that there isn't any practical difference with respect to using them.isaacl (talk)16:25, 20 October 2025 (UTC)[reply]
It’s little things like that overlapping sandbox terminology that can drive us still on the learning curve to distraction!
So too incomplete directions that don’t give enough information about how to handle editing situations. And directions slathered with jargon.Augnablik (talk)07:15, 21 October 2025 (UTC)[reply]
Although it has its disadvantages, I do think the most straightforward name for the default testing grounds is "sandbox", and that it will be hard for the community to start using a longer term to refer to the general concept (the attractiveness of a concise term is too strong).Help:Your first article does describe the common conventional locations for new draft articles, including a user subpage. It's linked from thenewcomer homepage and various welcome templates.isaacl (talk)16:21, 21 October 2025 (UTC)[reply]
In 2006 Sullivan foundedSearch Engine Land with Chris Sherman. Search Engine Land is anews website that coverssearch engine marketing andsearch engine optimization. It which shares information aboutkeyword research, trends in search marketing (SEM), paid search advertising (PPC) and search engine optimization (SEO) as well as analysis, advice, tips, tactics and how-to guides for search marketing.
Search Engine Land and otherThird Door Media brands were acquired bySemrush in October, 2024.
Don't restore (at least for citation uses) that needlessly gives off a false implication that the term has its own page or is likely to warrant one. Starting an RFC was completely unnecessary as those tend to just drag conversations out for too long and you're trying too hard to maintain a pointless use. It at best comes off as excessive emphasis on a minor term, andWP:Manual of Style/Linking saysDo not link to draw attention to certain words or ideas. I also don't buy the argument that many folks would think they're going to arrive at Sullivan's bio instead of a page for the actual Engine perWP:Linking dos and don'ts, so linking to something that points to him wouldn't be a target readers plausibly anticipate. If someday the Engine actually does get a separate page, then linking at that point would be preferable. It's ideal to use links with their own main space articles, but you show no concern for this.SNUGGUMS (talk /edits)01:38, 20 October 2025 (UTC)[reply]
Special:WhatLinksHere/Search Engine Land shows that every mainspace link toSearch Engine Land has been removed. The argument that "many folks would think they're going to arrive at Sullivan's bio instead of a page for the actual Engine" reads as an argument to delete the redirect atWikipedia:Redirects for discussion. If the consensus at RfD is to delete the redirect, then all the mainspace links should be removed. The mainspace links should not be removed before any such consensus is reached at RfD.
Wikipedia:Manual of Style/Linking says, "The purpose of linking is to clarify and to provide reasonable navigation opportunities, not to emphasize a particular word. Do not link to draw attention to certain words or ideas, or as a mark of respect." The aim of these links is not "to draw attention to certain words or ideas". It is to direct readers to an article that provides information about Search Engine Land.
I also don't buy the argument that many folks would think they're going to arrive at Sullivan's bio instead of a page for the actual Engine perWP:Linking dos and don'ts, so linking to something that points to him wouldn't be a target readers plausibly anticipate. – the same could be said about the poodle and dog example given in the guidelineWikipedia:Manual of Style/Linking#Redirects, which says,Suppose you need to linkpoodle, and there is no such article yet. You might want to create a redirect from "poodle" to "dog" as follows: Link as usual:She owned a [[poodle]]. When you save or preview this, you see:She owned apoodle. Follow the red link, and you are invited to create a new page forpoodle; enter (perhaps)#REDIRECT [[Dog]], so that readers clicking onpoodle are taken, for now, to the dog article. The guideline supports these kinds of links.
I think these links to "Search Engine Land" are very useful to readers, not "a pointless use". There are other editors who think the redirects are useful too since the redirect was linked in 39 articles. I asked repeatedly for you to self-revert this contested removal of links in39 edits but you declined. I did not want to spend a significant amount of time manually undoing these 39 edits and risk getting into edit wars across many pages. I was unsure where to raise this to get the community's opinions so started an RfC at village pump proposals. If there is a better venue, I am open to suggestions.Cunard (talk)03:51, 20 October 2025 (UTC)[reply]
While it's not clear how many folks already knew the title was only a redirect when first inserting links, we shouldn't automatically presume all who did would agree doing so was for the best after learning that. I doubt you'd come across lots of people who find it as enhancing as you do regardless of whether they personally have a preference to keep such uses. Not often do people seem to go as far as you have to advocate for linking terminology. If there are particular pages where you somehow feel it would be especially good within prose to have the engine linked, then you could make your case on their respective talk pages as AndyTheGrump suggested below instead of here, and even in those instances a time-sinking RFC frankly would still be over-the-top. The links for that within citations were definitely negligible.SNUGGUMS (talk /edits)11:28, 20 October 2025 (UTC)[reply]
This RfC is in an entirely inappropriate location, and should be closed forthwith. A discussion regarding a redirect for a single article isn't a 'proposal' within the scope of this noticeboard. Please do not clutter this noticeboard with random disputes that per normal practice can be dealt with perfectly well on the relevant article talk page.AndyTheGrump (talk)09:43, 20 October 2025 (UTC)[reply]
This dispute concerns 39 affected articles so cannot be discussed on a single article's talk page. I chose the village pump for proposals because I could not find a better venue.Cunard (talk)09:53, 20 October 2025 (UTC)[reply]
Restore I think. If they were over-links to a common source, I might not object (but even there it's useful to see the political stance of news outlets in other countries - and everywhere is abroad to someone), but this is an unusual source so linking to even a small amount of context is useful. I don't see any relevance in the fact that this is a redirect to a section. All the best:RichFarmbrough12:17, 20 October 2025 (UTC).[reply]
I think thatrestoring these is not unreasonable, especially for links in refs. The existence of a blue link does not, as claimed above, imply that there is a completely separate article with that title.WhatamIdoing (talk)02:13, 21 October 2025 (UTC)[reply]
I'm turning off the RFC button. A singular issue with a singular editor who has a reasonable argument against linking these is not a sufficient case for the RFC tag. I would generally point out however that you could also revert these changes per generalWP:BRD and then it is up to them to show it is improvement to remove a link.Izno (talk)17:21, 21 October 2025 (UTC)[reply]
Izno, if this affected a single page, I would have reverted the link removal perWP:BRD. But this affects 39 pages. It would take me more than half an hour to revert all these changes since I don't useWikipedia:AutoWikiBrowser or any other automated editing tool. If my 39 reverts were then reverted, that would be a multi-page edit war that could lead to me getting blocked.
Restore. Wikilinking sources is a common practice. There is no reason to limit the practice to publications that have a full-blown article. I do not see this practice as promotional or aggrandizing. Readers probably do expect to find a full article but this is not a reason to remove the link. We have{{R to section}} precisely for this purpose, when we have some information on a subject that doesn't have its own article. —Myceteae🍄🟫(talk)00:41, 25 October 2025 (UTC)[reply]
When discussion hasended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
There have been some perennial discussions about removal of|slogan= from various infoboxes, but I could not find a case that discussed makingWP:SLOGAN essentially policy.
NowWP:SLOGAN isjust an essay which I know many people object to, but hence the reason for this RFC. I encourage everyone to read the essay but here are the key points (This is copied fromWP:SLOGAN)
Mission statements generally suffer from some fundamental problems that are incompatible with Wikipedia style guidelines:
Even though mission statements are verifiable, they arewritten by the company itself, which makes them a primary source.
Perthis search there are at least 37 infoboxes that have some form of slogan in them. The question is should all of those be removed? This does not mean that slogans cannot be mentioned in the body of an article, that is another conversation about whether they meet notability and are encyclopedic. My question is purelydo they belong in the infobox?
In addition to this, what about mottos? It seems as though they are used rather interchangeably in Infoboxes...This search shows at least 72 infoboxes with amotto type parameter. Should some of those be removed? Personally I'd say keep it for settlement type infoboxes, but the way it is used on{{Infobox laboratory}} or{{Infobox ambulance company}}, it is performing the same functionality as a slogan and has the same issues.
No A slogan is one of those trivial things people go on Wikipedia to find out. (What company's slogan is "leave the driving to us"?) The claim that they conflict with Wikipedia style guidelines is nonsense. Quoting a slogan isn't endorsing it, anymore than the quotations inMein Kampf endorse Naziism. --Isaac Rabinovitch (talk)01:19, 21 October 2025 (UTC)[reply]
I don't care how this cookie crumbles, but slogans coming from primary sources, or "not being verifiable though third party sources", really is irrelevant to whether or not to include them.Headbomb {t ·c ·p ·b}02:29, 21 October 2025 (UTC)[reply]
No (and doubly no for mottos). But I do think editors should use some discretion when deciding whether to include one.Nike can haveJust Do It.Apple Inc. can haveThink different.Disneyland can have "Happiest Place on Earth".M&M's should have "Melts in Your Mouth, Not in Your Hands". But slogans that almost nobody recognizes should be excluded through editorial judgement, not through removing the option entirely from the infobox.WhatamIdoing (talk)02:40, 21 October 2025 (UTC)[reply]
No. Mottos are absolutely often promotional, but oftentimes so are names/logos/etc. They can still be essential pieces of information about an organization. I'd rather we encourage tight editorial discretion about which mottos are notable enough to warrant inclusion than ban them outright by removing the fields for them. Perhaps a good minimum standard would be secondary coverage (i.e. a source explicitly noting that they have a particular motto).Sdkbtalk04:51, 21 October 2025 (UTC)[reply]
No each use should be determined on a case by case basis. If it is famous slogan (finger licking good) or (the fish others reject) then may as well include it. But if it is excessive or ridiculous, then omit it.Graeme Bartlett (talk)08:25, 21 October 2025 (UTC)[reply]
Comment the RFC question is not neutral -- it has a deletionist bias. If the arguments given in the No-votes above gain consensus, the slogan parameter should be restored in the infoboxes it was removed from. This would be a new global consensus overriding the local consensus at the infobox talk page archive.Joe vom Titan (talk)14:14, 21 October 2025 (UTC)[reply]
I'm with Blueboar on this, if secondary sources are mentioning it then we should to. I'd also add that we are a global site, writing for a global audience, I doubt all of these slogans are global, or even consistent across the Anglosphere.ϢereSpielChequers09:55, 23 October 2025 (UTC)[reply]
No. Slogans, mission statements, etc. are a basic piece of information about a company. They are reasonable to include and inclusion is not really promotional. We include logos and mention marketing stylization like all-caps but don't consider these promotional. A primary/self-published source is fine for this. Readers know what a slogan is and seeing one reproduced in an infobox is not going to be interpreted as Wikipedia declaring its accuracy. Secondary sources should be used to resolve any discrepancies or doubt, I suppose. All that said, I don't know that every company articleneeds to have the slogan included. Individual cases should be discussed on talk. —Myceteae🍄🟫(talk)01:01, 25 October 2025 (UTC)[reply]
Permos:fakeheading, pseudo-headings created with description term markup (;) are discouraged; the same section of the MoS recommends using boldface markup (''' ''') for them.
I agree with the discussion on the bot request page that the choice of replacement can depend on context. I think more investigation should be done to survey the actual instances in current articles to learn more about what is the best replacement in each case, and the relative frequency of each preferred option.isaacl (talk)16:34, 21 October 2025 (UTC)[reply]
That suggested replacement is never the correct one, it's just a "do enough" one. I am not sold that this would be a context bot with the requirement that it be followed by a note or ref list.Izno (talk)17:17, 21 October 2025 (UTC)[reply]
"the MoS recommends using boldface markup () for them." ... euh no it doesn't... it says use the heading level that is appropriate. Except for people too stubborn to use headings because they F with their mental idea of how many things should be in the ToC. Those people who don't want to use html properly because they are super stubborn but who we unfortunately cannot get to follow a proper system, those people can use bold sometimes when these 'headings' are below level 4. —TheDJ (talk •contribs)19:07, 21 October 2025 (UTC)[reply]
This is context-dependent - sometimes it should be boldface, sometimes it should be a proper heading, maybe there are times it should be something else instead and it's not impossible that there are instances where this markup is actually correct. This isn't suitable for an unsupervised bot.Thryduulf (talk)21:48, 21 October 2025 (UTC)[reply]
I don't know how to find examples (and search isn't helping) but I literally explained in my comment why it is context dependent: sometimes it should be boldface, sometimes it should be a proper heading. I've seen examples of both in my time on Wikipedia (although I've not seen any examples of this markup in article space recently, so I can't remember where I saw them). In project space of course we do have examples of this markup being used appropriately (e.g. atWikipedia:Requests for review of admin actions).Thryduulf (talk)22:54, 22 October 2025 (UTC)[reply]
Maybe you missed the requirements expected e.g. one of which is;thing(newline){{reflist}}. There are of course appropriate uses of the semi colon in the context of definition lists, but that limitation immediately cuts that off as uninteresting.
Here is asearch of the kind of use that should be cleaned. Most of those notes could go either way, but it's quite clear that any that appear in a section dedicated to our usual appendices should not have this form. (Funnily enough, I made a bad search at[5] and those just simply need removal.) But these are cases that can be worked through as part of bot trials.Izno (talk)01:12, 23 October 2025 (UTC)[reply]
I would have thought that the relevant removal situation is when the next line doesn't start with a:. Aren't these the possible cases?
Line starting with; followed immediately by line starting with: – correct; leave it alone
Line starting with; followed a blank line and then a line starting with: –WP:LISTGAP; fix it
Line starting with; followed anything else (including*) – incorrect; change formatting
(Though any script would have to check for both separate lines and putting the formatting on a single line.;Word:Definition is a case of "followed immediately by:".)
The "change formatting" step seems to be the sticking point:'''bold''' or== heading ==, and which level of heading for the latter? The proposal here tried to limit it to a very specific case to avoid that, but still ran into it.Anomie⚔19:42, 24 October 2025 (UTC)[reply]
No. Although outside of mainspace, editors misuse the colon syntax for generic unbulleted lists, in mainspace the resulting HTML syntax should conform with the indicated semantics from the W3C, for best accessibility. Description lists should be used for pairs of terms and definitions.{{Unbulleted list}} should be used for unbulleted lists, if deemed necessary. The only place where description lists are appropriate that I've come across are glossary articles.isaacl (talk)16:40, 25 October 2025 (UTC)[reply]
RFC: What should be done about unknown birth/death dates
When discussion hasended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
With the implementation ofModule:Person date, all|birth_date= and|death_date= values in Infoboxes (except for deities and fictional characters) are now parsed and age automatically calculated when possible.
With this implementation, it was found that there are a large number of cases (currently 4332) where the birth/death date is set toUnk,Unknown,? or##?? (such as 19??). Full disclosure,Module:Person date was created by me and because of an issue early on I added a number of instances of|death_date=Unknown in articles a few weeks ago. (I had not yet been informed about the MOS I link to below, that's my bad).
PerMOS:INFOBOX:If a parameter is not applicable, or no information is available, it should be left blank, and the template coded to selectively hide information or provide default values for parameters that are not defined..
There is also the essayWP:UNKNOWN which says, in short,Don't say something is unknown just because you don't know.
So the question is what to do about these values? CurrentlyModule:Person date is simply tracking them and placing those pages inCategory:Pages with invalid birth or death dates (4,332). It has been growing by the minute since I added that tracking. Now I am NOT proposing that this sort of tracking be done for every parameter in every infobox... There are plenty of cases of|some_param=Unknown, but with this module we have a unique opportunity to address one of them.
I tried to find a good case where the|death_date= truly is Unknown, but all the cases I could think of use|disappeared_date= instead. (SeeAmelia Earhart for example).
The way I see it there are a few options
Option A - Essentially do nothing. Keep the tracking category but make no actual changes to the pages.
Option B - Implement a{{preview warning}} that would sayThis value "VALUE" is invalid perMOS:INFOBOX &WP:UNKNOWN. (Obviously open to suggestions on better language).
Option C - Take B one step further and actually suppress the value. Display a preview warning that saysThis value "VALUE" is invalid perMOS:INFOBOX &WP:UNKNOWN. It will not be displayed when saved. then display nothing on the page. In other words treat|death_date=Unknown the same as|death_date=. (Again open to suggestions on better language for the preview warning).
We definitely shouldn't be using things like "Unk" or "?" - if we want to say this is not known we should explicitly say "Unknown". Should we ever say "unknown" though? Yes, but for births only when we have reliable sources that explicitly say the date is unknown to a degree that makes values like "circa" or "before" unhelpful - even "early 20th Century" and is more useful imo than "unknown". "Unknown" is better than leaving it blank when we have a known date of birth but no known date of death (e.g.Chick Albion). I'm not sure how this fits into your options.Thryduulf (talk)00:24, 22 October 2025 (UTC)[reply]
Agreed. There are cases where no exact date is given but MOS:INFOBOX and WP:UNKNOWN do not apply because thelack of known date can be sourced reliably. If the module cannot account for this, I really think only option A is acceptable. —Rutebega (talk)18:15, 22 October 2025 (UTC)[reply]
@Rutebega andThryduulf: So I can very easily make it so that|..._date=Unknown<ref>... is allowed but just plain|..._date=Unknown is not. That is just a mater of tweaking theregular expression. Not hard at all to do at all. That being said (mostly for curiosity sake) can you give me an example of a page wherethe lack of known date can be sourced reliably? Every case I could think of (and I really did try to find one) either has a relevant|disappeared_date= (so you don't need to specify that|death_date=Unknown) or you can least provide approximate dates (i.e.{{circa|1910}},1620s or12th century).Zackmann (Talk to me/What I been doing)18:23, 22 October 2025 (UTC)[reply]
Metrodora isn't quite date unknown, but the only fixed date we have is the manuscript which preserves her text (c.1100 AD), and her floruit has been variously estimated between the first and sixth centuries AD. Of course, so little is known for certain about Metrodora that every single infobox field would be "unknown" were it filled in, and therefore there's little point having an infobox at all.
Corinna's dates are disputed: she was traditionally a contemporary ofPindar (thus born late 6th century and active in the fifth century BC) but some modern scholars argue for a third-century date. If the article had an infobox, a case could be made either for listing her floruit as either "unknown", "disputed", "5th–3rd century BC", "before 1st century BC" (the date of the first source to mention her) or simply omit it entirely.
@Caeciliusinhorto-public: thanks for some real examples. I think your point that so little is known that Infoboxes don't make sense is a good one... If there were other info that made sense to have in an Infobox I think the dates would still be able to be estimated (even if the range is hundreds of years). You could still put|birth_date=5th-3rd century BC or, of course, just leave it blank! Leaving it blank to me implies that it is Unknown, though it does leave ambiguous whether is it Unknown because no editor has taken the time to figure it out or whether it is Unknown because the person live some 2,200 years ago and we have no real way of knowing when they were born...Zackmann (Talk to me/What I been doing)09:05, 23 October 2025 (UTC)[reply]
This is above my pay grade but can you give us an idea of how much "It has been growing by the minute". The scale of those additions may inform our view as to how best to deal with it.Lukewarmbeer (talk)16:34, 22 October 2025 (UTC)[reply]
@Lukewarmbeer: so this is mostly a caching issue. I don't think very manynew instances of this are being created each day, it just takes a while for the code to propagate. I really don't have an objective way of saying how many new instances are being created daily...Zackmann (Talk to me/What I been doing)17:13, 22 October 2025 (UTC)[reply]
FWIW, about 15% of our biographies of living people have unknown birthdates (based on a count by category I did in 2023). I would assume that deceased biographies are perhaps more likely to miss this data, so we're looking at a number in the low hundreds of thousands? Not all of those will have infoboxes, of course.Andrew Gray (talk)20:39, 22 October 2025 (UTC)[reply]
@Andrew Gray: when you sayhave unknown birthdates do you mean "no birthdates are given"? Because that is NOT what we are talking about here... We are talking about|birth_date=Unknown, where someone has specifically stated that the date is Unknown, not just left it blank.Zackmann (Talk to me/What I been doing)20:42, 22 October 2025 (UTC)[reply]
@Zackmann08 ah, right - I think I misunderstood, apologies. If the module does nothing when the birthdate field is blank or missing, that sounds good.
Perhaps the problem is the multiple meanings of "Unknown". Some may have filled it meaning "nobody knows about the early life of this historical guy, only that he became relevant during the X events, already an adult", and others "unknown becauseI don't know". We may make it so that "Unknown" has the same effect as an empty field, and require a special input for people with truly unknown dates. And note that any biography after whatever point birth and death certificates became ubiquitous should be treated as the second case.Cambalachero (talk)14:09, 23 October 2025 (UTC)[reply]
Option D The variant on option C where it's permittediff there's a citation seems like a good solution to me. By a similar argument toWP:ALWAYSCITELEAD, I think a citation should always be required to assert that someone's date of death is outside the scope of human knowledge. FromWP:V we should always citematerial that is likely to be challenged, and I think the assertion that someone's date of death is "unknown" falls well within that scope; in particular I myself will always challenge it if unsourced.lp0 on fire()16:32, 23 October 2025 (UTC)[reply]
I think whether someone's date of birth or death being unknown falls into the category ofmaterial that is likely to be challenged is party a factor of when and where they were born and the time, place and manner of their death and how much we know about them generally. It is not at all surprising to me that we don't know the date of birth or death of a 3rd century saint or 18th century enslaved person, or when a Peruvian athlete who competed in the 1930s died; we do need a citation to say that we only know the approximate date of death forDennis Ritchie andGene Hackman.Thryduulf (talk)16:50, 23 October 2025 (UTC)[reply]
Do you think the citation always needs to be inside the infobox? Our article aboutMetrodora has a couple of paragraphs about which century she might have lived in. There's no infobox at the moment, but if we added one, would you insist that the citations be duplicated into the infobox?WhatamIdoing (talk)18:40, 24 October 2025 (UTC)[reply]
Option D Allow Unknown but not other abbreviations. Require citations for dates. Rationale: Looking at theSven Aggesen it’s easy to see that “Unknown” is helpful because it’s communicating that the person is dead. In my opinion it’s still stating a fact. So Unknown should be allowed. “?” Should not. It seems like dates of birth and death should always be cited. Thanks for your work on this!!Dw31415 (talk)17:54, 23 October 2025 (UTC)[reply]
In the case of Sven Aggesen I think we could reasonably expect a reader to infer from "born: 1140? or 1150?" that he is probably dead! In the case of people born recently enough that there might be confusion, I can't imagine there are many cases where both (a) they are known to be dead and (b) their date of death is known so imprecisely that we don't have a more useful value than "unknown" for the infobox.Caeciliusinhorto (talk)20:35, 23 October 2025 (UTC)[reply]
When discussion hasended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
Should the community harmonize the rules that govern community-designated contentious topics (which are general sanctions authorized by the community) withWP:CTOP? If so, how? 19:55, 22 October 2025 (UTC)
Background
Before 2022, thecontentious topics process (CTOP) was instead known as"discretionary sanctions" (DS). Discretionary sanctions were authorized in a number of topic areas, first by the Arbitration Committee and then by the community (under itsgeneral sanctions authority).
In 2022, ArbCom made anumber of significant changes to the DS process, including by renaming it to contentious topics and by changing the set of sanctions that can be issued, awareness requirements, and other procedural requirements (seeWP:CTVSDS for a comparison). But because the community's general sanctions are independent of ArbCom, these changes did not automatically apply to community-authorized discretionary sanctions enacted before that date.[a]
In anApril 2024 RfC, the community decided thatthere should be clarity and consistency regarding general sanctions language and decided to rename community-authorized discretionary sanctions to "contentious topics". However, the community did not reach consensus on several implementation details, most prominently whether the enforcement of community CTOPs should occur at thearbitration enforcement noticeboard (AE) instead of theadministrators' noticeboard (AN), as is now allowed (but not required) by ArbCom's contentious topics procedure.[b]
Question 1: Should the community align the rules that currently apply in community-designated contentious topics withWP:CTOP,mutatis mutandis (making the necessary changes) for their community-designated nature?
Question 2: Should the community authorize enforcement of community contentious topics at AE (in addition to AN, where appeals and enforcement requests currently go)?
^Specifically, AE may consider "requests or appeals pursuant to community-imposed remedies which match the contentious topics procedure, if those requests or appeals are assigned to the arbitration enforcement noticeboard by the community." –Wikipedia:Arbitration Committee/Procedures § Noticeboard scope 2
Yes to both questions. For almost three years now, we have had two different systems called "contentious topics" but with different rules around awareness, enforcement, allowable restrictions, etc. In fact, becauseWP:GS/ACAS follows the new CTOP procedure but without AE enforcement, we actually havethree different systems. We should take this chance to make the process meaningfully less confusing. There is no substantive reason why the enforcement of, for example,WP:GS/UYGHUR andWP:CT/AI should differ in subtle but important ways. As for using AE, AE is designed for and specialized around CTOP enforcement requests and appeals. AE admins are used to maintaining appropriate order and have the benefit of standard templates, word limits, etc., while AN or ANI are not specialized around this purpose. As a result ofWP:CT2022, ArbCom nowspecifically allows AE to hearrequests or appeals pursuant to community-imposed remedies which match the contentious topics procedure, if those requests or appeals are assigned to the arbitration enforcement noticeboard by the community. We should take them up on the offer asBarkeep49 firstsuggested at the previous RfC. FYI, I am notifying all participants in the previous RfC, as this RfC is focused on the same topic. Best,KevinL (akaL235·t·c)19:57, 22 October 2025 (UTC)[reply]
Yes to both - I don't see a downside to this standardization, and it would appear to both make the system as a whole easier to understand, and allow admins to take advantage of the automated protection logging bot for the currently-GS topics.signed,Rosguilltalk20:01, 22 October 2025 (UTC)[reply]
Yes to both. The CTOP system is complicated even without these three different regimes and confuses almost everyone involved. AE can be a great option for reducing noise in discussions, compared to AN.—Femke 🐦 (talk)20:20, 22 October 2025 (UTC)[reply]
Yes to both but as I said in the previous RFC, if we're going to go in this direction, we should also be moving towards a process where the community eventually takes over older ArbCom-imposed CTOPs, especially in areas where the immediate on-wiki disruption that required ArbCom intervention has mostly settled down but the topic itself remains indefinitely contentious for off-wiki reasons. ArbCom was intended as the court of last resort for things the community failed to handle; it's not supposed to create policy. Yet currently, huge swaths of our most heavily-trafficked articles are under perpetual ArbCom sanctions, which can only be modified via appeal to ArbCom itself, and which arefunctionally the same as policy across much of the wiki. This isn't desirable; when ArbCom creates long-term systems like this, we need a way for the community to eventually assume control of them. We need to go back to treating ArbCom as a court of last resort, not as an eternal dumping ground for everything controversial, and unifying ArbCom and community sanctions creates an opportunity to do so by asking ArbCom to agree to (with the community's agreement to endorse them) convert some of the older existing ArbCom CTOPs into community ones. --Aquillion (talk)20:51, 22 October 2025 (UTC)[reply]
Yes to both per nom. Consistency is great, and eliminating the byzantine awareness system (where you need an alert every 12 months) is essential.WP:AE is a miracle of a noticeboard (how is the noticeboard with the contentious issues the relatively tame one?), and we as a community should take advantage of ArbCom's offer to let us use it. Best,HouseBlaster (talk • he/they)22:10, 22 October 2025 (UTC)[reply]
Yes to both, and a full-throated "yes" for using AE in particular. The other noticeboards are not fit for purpose with respect to handling CTOP disruption.Vanamonde93 (talk)22:24, 22 October 2025 (UTC)[reply]
Yes to both – This has been a mess for more than a decade. Harmonising the community and ArbCom general sanctions regimes will cut red tape, and eliminate confusion over which rules apply in any given case. I am also strongly in favour of allowing community sanctions to be enforced atWP:AE. Previously, there were numerous proposals to create a separate board for community enforcement, such asUser:Callanecc/Essay/Community discretionary sanctions, but all failed to go anywhere. In my opinion, the most important aspect of community sanctions (as opposed to ArbCom sanctions) is that the community authorises them, and retains control over their governance. Enforcement at AE does nothing to reduce the community's power to enact sanctions; if anything, it will ensure that these regimes are enforced with the same rapidity as ArbCom sanctions. It would be foolish to not take advantage of ArbCom's offer to allow us to use their existing infrastructure.Yours, &c.RGloucester —☎23:54, 22 October 2025 (UTC)[reply]
Yes to both. I was in favor of this during the March 2024 rfc but was relcutant to push it too hard since I was then on arbcom. I am no longer on arbcom and thus can freely and fully support this thoughtful and wise pproposal for the same reasons I hinted at in the previous discussion. Best,Barkeep49 (talk)02:00, 23 October 2025 (UTC)[reply]
Yes to both, and future changes to either sanction procedure should be considered for both. Not to be unduly repetitive of others above, but the system is more complex than it needs to be. AE as an additional option is a positive.CMD (talk)04:38, 23 October 2025 (UTC)[reply]
Yes to both. We already have overlapping CSes (Arbcom-imposed) and GSes (community-imposed) - A-A and KURD, at least, where the community chose to impose stricter sanctions on a topic area than ArbCom mandated (in both of those cases, the community chose to ECR the topic area). This has caused confusion for me as an admin a few times, for a regular user it can only be more so. Harmonizing the restrictions, with the only difference being who imposed them, can only make sense. -The BushrangerOne ping only20:02, 23 October 2025 (UTC)[reply]
Yes andYes - The same procedures should apply to topics that the ArbCom has found to be contentious as to topics which the community has found to be contentious. The differences have only caused confusion.Robert McClenon (talk)20:56, 23 October 2025 (UTC)[reply]
No I understand what Arbcom is perWP:ARBCOM and it seems to be a reasonably well-organised body with good legitimacy due to it being elected. But what's the community? PerWP:COMMUNITY andWikipedia community, it seems to be be any and all Wikipedians and this seems quite amorphous and uncertain. Asking such a vague community to do something is not sensible. In practice, I suppose the sanctions were cooked up at places likeWP:ANI which is a notoriously dysfunctional and toxic forum. That's not a sensible place to get anything done.
I looked at one of these community sanctions as an example, and it was some special measure for conflict about units of measurements in the UK:WP:GS/UKU. Now I'm in the UK and so might easily run afoul of this but this is the first I heard of this being an especially hot topic. And I've been actively editing for nigh on 20 years. Our general policies about edit-warring, disruption and tendentious editing seem quite adequate for such an issue and soWP:CREEP applies. That sanction was created over 10 years ago and so should be expired rather than harmomised. The other general sanctions concern such topics asMichael Jackson, who died 16 years ago and that too seems quite dated.
So, I suggest that all the general sanctions be retired. If problems with those topics then recur, fresh sanctions can be established using the newWP:CTOP process and so we'll then all be on the same page.
Create a new page such asWikipedia:General sanctions/Log which would only log enforcement actions for community contentious topics (subpages would be years)
Continue logging at each relevant page describing the community contentious topics (Wikipedia:General sanctions/Topic area), and if 2 or 3 are chosen, the page would transclude these relevant pages.
2+3+4 as proposer, one of the problems I do notice is that loadingWP:AELOG does take a lot of time because the page has a lot of enforcement actions. The advantage of 2 is having a single page that can be quickly searched.Aasim (話す)20:42, 22 October 2025 (UTC)[reply]
BTW except for 1 the other options are mutually exclusive. If option 1 is chosen, options 2-4 are irrelevant. I am not asking people to pick one and be done, people can choose any combination.Aasim (話す)21:32, 23 October 2025 (UTC)[reply]
2 >1 – Both ArbCom and community CT are forms of general sanctions (seemy incomplete essay on the subject); the only distinction is who authorises them. For this reason, '3' does not make sense. Eliminating the sprawling log pages that currently exist for community-authorised regimes should be a priority if our goal is to eliminate red tape, therefore '4' does not make sense either. That leaves me with 2, which allows for a centralised log for both forms of sanctions. I am perfectly fine with creating subpages as needed, but centralisation is paramount in my mind.Yours, &c.RGloucester —☎00:02, 23 October 2025 (UTC)[reply]
In the past, there have been concerns raised about it being clear if the enacting authority is the arbitration committee or the community. Thus I do not feel option 1 is the best choice.
Regarding searching: I feel the typical use case is to search for actions performed within a specific topic area. If necessary, Wikipedia search with a page prefix criterion can be used to search multiple subpages.isaacl (talk)16:19, 23 October 2025 (UTC)[reply]
2 I am in favor of fewer, larger pages because they are easier to find and to search. If a searcher needs to confirm that somethingisn't there, for example, fewer pages, even if very large, are much easier to work with.Darkfrog24 (talk)13:33, 23 October 2025 (UTC)[reply]
1 - in keeping with the spirit for Q1 and Q2, the whole point here is to merge everything into a single system that is simpler to follow. We already have a practice of splitting off subpages when specific sections in the log get too large.signed,Rosguilltalk13:52, 23 October 2025 (UTC)[reply]
2 as a first choice, as centralization is helpful, but the currentWP:AELOG is ultimately an ArbCom page and shouldn't have jurisdiction over community sanctions. I agree with Rosguill's point about splitting off subpages, and I presume this would be encouraged to a greater extent here. I could also be convinced by1 (to avoid an unnecessary transclusion, although it should be made clear that it isn't an ArbCom-only page anymore) or by a temporary3 (to avoid a lag spike until the main subpages are sorted out).ChaoticEnby (talk ·contribs)17:04, 23 October 2025 (UTC)[reply]
Actually, I'm realizing that 2 doesn't help with centralization compared to 3, and creates a bit of an inconsistency between some topics being directly logged there and others being transcluded. Count3 as my first choice, with the possibility of a combined log transcluding both for reference.ChaoticEnby (talk ·contribs)19:34, 23 October 2025 (UTC)[reply]
1 > 3 > 4, but my actual preference is todelegate this to a local consensus of those who are involved in implementing this. 1 is my preference, like Rosguill, because centralizing where the existing logs live promotes simplicity and would avoid the need for admins to check which types of CTOPs are which (one goal I have is for the community CTOPs and ArbCom CTOPs to feel almost identical). Not to mention, it would preserve compatibility with tools likeWP:SUPERLINKS that check AELOG but not other pages. The biggest hurdle in my mind is that #1 would require ArbCom approval, which I think is likely but not certain (given that ArbCom allows AE for community CTOPS, why not AELOG?). Best,KevinL (akaL235·t·c)19:29, 23 October 2025 (UTC)[reply]
Comment I understand the functional difference between an AE sanction and AN sanction is that an AE sanction can be removed only by a) the exact same admin who placed it, called the "enforcing admin" or b) a clearly-more-than-half balance of AE admins at an AE appeal while a sanction placed at AN can be removed by c) any sufficiently convinved admin acting alone. To give an example of how this would change things, I found myself in a situation in which I was indefinitely blocked at AE and then the enforcing admin left Wikipedia, which removed one of my options for lifting a sanction. Some of our fellow Wikipedians will think making it easier to get a sanction lifted is a good thing and others will think it's a bad thing, but we should be clear about that so we can all make our decision. Am I correct about how these changes would affect those seeking to have sanctions removed?Darkfrog24 (talk)13:31, 23 October 2025 (UTC)[reply]
@Darkfrog24: I think this is incorrect. As it stands now, restrictions imposed under community CTOPs are only appealable to the enforcing administrator or to AN (see, e.g.,WP:GS/Crypto, which saysSanctions imposed may be appealed to the imposing administrator or at the appropriate administrators' noticeboard.). Q1 is about aligning the more subtle but still important differences between community CTOPs and ArbCom CTOPs, while Q2 is about adding AE as aplace (but not changing the substantive amount of agreement needed) for enforcement requests and appeals. Best,KevinL (akaL235·t·c)13:43, 23 October 2025 (UTC)[reply]
Comment: Is there any way that we could implement the semi-automated logging process that is used for page protection of CTOPS here? Is there any expectation that if any of these options were chosen, that process would revert to manual?⇒SWATJesterShoot Blues, Tell VileRat!18:17, 23 October 2025 (UTC)[reply]
Comment – If we are to create a seperate log for community-authorised contentious topics as in alternative 3, it should not be subpage ofWikipedia:General sanctions. 'General sanctions' is a broad category that includes ArbCom sanctions, and also non-contentious topics remedies such as the extended confirmed restriction. This is a recipe for confusion. Please consider an alternative naming scheme.Yours, &c.RGloucester —☎00:19, 24 October 2025 (UTC)[reply]
The title can always be different. The title I named was just an example title to explain the purpose of the question.Aasim (話す)01:30, 24 October 2025 (UTC)[reply]
Support – Articles that contain obvious evidence of unreviewed AI use are evidence of acompetence issue on the part of their creator that is not compatible with the GA process. Having reviewers perform a spot check forobvious signs of AI use will help militate against the recent problem whereby AI-generated articles are being promoted to GA status without sufficient review.Yours, &c.RGloucester —☎10:08, 26 October 2025 (UTC)[reply]
Support Per nomination. This would not prohibit AI use per se, but would rule out promoting any low effort usage of AI. AI use in this manner could be argued to be a failure of GA criteria 1 and 2 as well, but explicitly stating as such will give a bit more weight to reviewers' decisions. --Grnrchst (talk)10:45, 26 October 2025 (UTC)[reply]
Oppose. GAs should pass or fail based only and strictly only on the quality of the article. If there are AI-generated references then they either support the article text or they don't, if they don't then the article already fails criteria 2 and the proposal is redundant. If the reference does verify the text it supports then there is no problem. If there are left-over prompts then it already fails criteria 1 and so this proposal is redundant. If the AI-generated text is a copyright violation, then it's already an immediate failure and so the proposal is redundant. If the generated text is rambly, non-neutral, veers off topic, or similar issues then it already fails one or more criteria and so this proposal is redundant.Thryduulf (talk)12:20, 26 October 2025 (UTC)[reply]
I sometimes use AI as a search engine and link remnants are automatically generated. I'd rather not face quickfail for that. I'm also not seeing how the existing criteria are not sufficient; if links are fake or clearly don't match the text, that is already covered under a quickfail as being a long way from demonstrated verifiability. Can a proponent of this proposal give an example of an article they would be able to quickfail under this that they can't under the current criteria?Rollinginhisgrave (talk |contributions)10:47, 26 October 2025 (UTC)[reply]
What's "obvious evidence of AI-generated references"? For example, I often use the automatic generation feature of the visual editor to create a citation template. Or I might use a script to organise the references into the reflist. The proposal seems to invite prejudice against particular AI tells but these include things like using an m-dash, and so are unreliable.Andrew🐉(talk)10:53, 26 October 2025 (UTC)[reply]
What about something similar toWP:G15, for example6. It contains content that could only plausibly have been generated by large language models and would have been removed by any reasonable human review.Kovcszaln6 (talk)10:59, 26 October 2025 (UTC)[reply]
This would be the first GA criterion that regulates the workflow people use to write articles rather than the finished product, which doesn't make much sense because the finished product is all that matters. Gen AI as a tool is also extremely useful for certain tasks, for example I use it to search for sources I may have missed (it is particularly good at finding multilingual sources), to add rowscopes to tables to comply withMOS:DTAB, to double check table data matches with the source, and to check for any clear typos/grammar errors in finished prose.IAWW (talk)11:05, 26 October 2025 (UTC)[reply]
Underline links:. Having a mix of underlined and not-underlined links would be messy and goes against users' preferences settings (some might have their skins set to never underline).Dan Leonard (talk •contribs)20:09, 16 October 2025 (UTC)[reply]