At Wikipedia:Village pump (policy)#Discussion (Non-primary sourcing in NGEO) multiple editors have expressed that they feel there are currently too many concurrent noticeboard discussions regarding notability, deletion and related matters (and two others thanked me when I initially suggested a moratorium). Since then the discussion above has been opened, so it seems a formal proposal is needed:

Proposal: Until such time as all the discussions listed below are closed, withdrawn or archived without formal closure and any appeals and disputes regarding such closures have concluded, no new RFC or similarly large proposal or discussion of policy may be opened that relates to the following topics, all broadly interpreted.

1. Notability,
2. The inclusion/exclusion of types of content on a large number of pages
3. Draftification, and/or
4. Deletion

If a proposal or policy discussion meeting these criteria is opened between this proposal passing and the moratorium expiring any uninvolved administrator may close it without prejudice to the same question being asked after the moratorium expires. Reverting such a closure requires an active consensus of uninvolved editors. In borderline cases it is recommended to get agreement from a few other editors before speedily closing. The discussions concerned are:

• Wikipedia:Village pump (policy)#Admins and being paid to advise on editing
• Wikipedia:Village pump (policy)#Relationship between Notability guidelines and WP:NOR
• Wikipedia:Village pump (policy)#Requirement for non-primary sourcing in NGEO Withdrawn
• Wikipedia:Village pump (policy)#RfC on the "Airlines and destinations" tables in airport articles
• Wikipedia:Village pump (proposals)#Changes to GEOLAND Withdrawn
• Wikipedia:Village pump (proposals)#Request for comment: Unreferenced PROD Closed

Any relevant discussions/proposals omitted from the list (e.g. any begun after the proposal was made) should be added to the list (unless the proposal is rejected). Discussions that are closed, withdrawn or archived should be struck (not removed).

This is explicitly not intended to prevent or limit the asking of genuine questions, the functioning of specialist noticeboards/discussion venues (e.g. WT:CSD, WP:RSN, WikiProject talk pages, etc) as long as such discussions are not used to avoid needed wider community consensus. Thryduulf (talk) 01:10, 7 October 2023 (UTC)

Survey (temporary moratorium on new proposals)

• (Support) As proposer. The large number of discussions is exhausting editors resources and hindering their ability to productively improve the encyclopaedia. Thryduulf (talk) 01:11, 7 October 2023 (UTC)
• (Support) * Pppery * _{it has begun...} 01:16, 7 October 2023 (UTC)
• (Support) Per Thryduulf: it is genuinely getting hard to do any real work here (including deletion) for having to repetitively check forum after forum for discussions on matters related to deletion or notability. The repeated RfCs are quite literally exhausting and are encouraging uncivil discourse. Espresso Addict (talk) 01:23, 7 October 2023 (UTC)
• (Support) The sheer number of proposals, the speed with which they are being proposed, and the sheer number of comments in those discussions, is making it impossible for other editors to get anything useful done elsewhere on the project. This has been going on for some time, and there have been a number of other proposals that were closed recently, in additions to the ones listed above. If you look at the ideas lab, and the talk pages of a number of the notability guidelines, there are a large and increasing number of discussions planning for further RfCs in the immediate future. There appears to be a real possibility of the village pump being flooded with an even larger number of RfCs. James500 (talk) 01:47, 7 October 2023 (UTC)
• Support per nom and James500. Dave (talk) 03:48, 7 October 2023 (UTC)
• (Support) Yes, I've stopped reading this page but saw this proposal on my watchlist. Johnuniq (talk) 03:59, 7 October 2023 (UTC)
• Oppose. If someone wants to propose a small but substantial tweak or clarification to a policy, I see no reason why they should be prohibiteed from doing so. Moreover, the language discussion of policy may be opened that relates to the following topics... deletion is overbroad; certainly we are able to have discussions of policy as it relates to deletion—when they are in the contexts of specific XfD nominations. The proposal also bizarrely includes a prohibition on discussing the various deletion/notability policies until a completely unrelated discussion (i.e. Wikipedia:Village pump (policy)#Admins and being paid to advise on editing) is closed, which is nowhere near narrowly tailored towards the problem that some are experiencing with discussion burnout. Moreover, the Reverting such a closure requires an active consensus of uninvolved editors line will inevitable lead to a closure review at AN for times when this is invoked, which will further the amount of time spent discussing these sorts of things while also simultaneously directing editor energy towards procedural matters rather than substantial ones. As written, the proposal is overbroad in its scope, and it may well create more work than if the proposal were to never have been made. — Red-tailed hawk _(nest) 04:05, 7 October 2023 (UTC)
• Support - it's counterproductive to pile the blasted things up as has been done recently. Ingratis (talk) 05:16, 7 October 2023 (UTC)
• Oppose, per RTH. Notability might be a hot topic right now, but it is still a topic that we are being productive on with many of the recently closed discussions have substantial results - and while I understand that many editors may disagree with those results, disagreeing with results in not a reason to shut down a topic. BilledMammal (talk) 07:26, 7 October 2023 (UTC)

  This is not shutting anything down, it's just pressing pause on any future discussions until the current ones have concluded so that all the discussions can be productive without disrupting the encyclopaedia. Thryduulf (talk) 11:18, 7 October 2023 (UTC)

• Support. This is starting to get the feel of certain editors attempting to get their way not by achieving actual consensus, but by exhausting so many of the contributors who have other better things to do in their wiki-editing that only the notability-crackdown enthusiasts are left. —David Eppstein (talk) 07:27, 7 October 2023 (UTC)
• Oppose, this is far too broad. All the referenced RfCs appear to be unrelated and all opened by different editors. I don't think any of those editors should open up new large RfCs, but I'm not sure we should moratorium new ones from other editors. On these sorts of RfCs, I think it is useful to keep them open for a bit longer than normal so that there is more time for editors to add to them, at least until discussion dies down naturally, and pressure to close might pre-empt that. CMD (talk) 09:23, 7 October 2023 (UTC)
• I fully understand the underlying sentiment, but I'm not convinced this is the right way to deal with the issue. We do seem to have a lot of RfCs with possibly wide-ranging consequences recently (not always advertised at all the places that would be affected by the proposal in violation of WP:LEOPARD). Some kind of rate limit and/or rejection of more under-prepared RfCs might be a good idea; this proposal is an emergency brake that doesn't really fix anything going forward. —Kusma (talk) 09:55, 7 October 2023 (UTC)

  This is intended to allow some time and space for long-term solutions to be identified and developed. Thryduulf (talk) 11:17, 7 October 2023 (UTC)

  On balance, I support. Discussions that are postponed by this will have more time to draft better RfCs in userspace or at the idea lab. —Kusma (talk) 13:30, 7 October 2023 (UTC)

• Support, excellent idea. I think we're passed the point where these attempts to tighten notability standards have become disruptive. The volume, the bludgeoning, the attempts to make major changes based on local consensus – these are not the signs of a good faith attempt to build consensus. I hope this can cool things down, otherwise the next step has to be arbitration. – Joe (talk) 09:58, 7 October 2023 (UTC)
• Support I have little to no skin in the game, and even I think some should keep NODEADLINE higher in their minds. ~~ AirshipJungleman29 (talk) 10:09, 7 October 2023 (UTC)
• Oppose The numerous discussions are a sign that this complex area needs work, not that we should prohibit working on it. It might need better organization / coordination, but broadly nuking it like this is not a good idea. North8000 (talk) 10:22, 7 October 2023 (UTC)

  This does not "nuke" anything, it simply requires that current discussions are concluded before starting any new ones - i.e. that better organisation/coordination you agree is needed. Thryduulf (talk) 11:15, 7 October 2023 (UTC)

  i.e. that better organisation/coordination you agree is needed That's not what this proposal is asking for; even proposals that are well organized and coordinated would be prevented. If that was all this proposal was asking for I would support it - although there are other pages I would support it on first, such as WP:RSN which has far too many RSP-related RFC's. BilledMammal (talk) 11:25, 7 October 2023 (UTC)

  No discussions will be prevented. They will just need to wait until the current discussions have concluded first. Thryduulf (talk) 11:28, 7 October 2023 (UTC)

  One of the proposals on this list was work-shopped over repeated revisions for a period of months before being brought here. Particularly, the proposal should be neutrally-worded (which this one is not) and well-thought out so as not to have unexpected side-effects (which this one is not).

  What I'm hoping the proposer is getting a feel for here is, it's actually very difficult to bring a proposal here and I doubt any of the people doing so are doing so lightly. FOARP (talk) 22:40, 7 October 2023 (UTC)

• Oppose More activity and discussion >> Less activity and discussion. Selfstudier (talk) 11:27, 7 October 2023 (UTC)
• Oppose The large, dare I say say overwhelming, number of unsourced or poorly sourced stubs needs to be addressed, and the search for an approach that will receive a broad support should not be limited. - Donald Albury 12:20, 7 October 2023 (UTC) (Edited 12:25, 7 October 2023 (UTC))
• Strongly oppose: far too broad. Also per Selfstudier. My first thought on seeing this was: why the hell would we want to stymie discussion on important topics? Edward-Woodrow • talk 12:33, 7 October 2023 (UTC)

  We don't want to stymie discussion, we want to facilitate productive discussion alongside productive contribution to the encyclopaedia without burnout. If there are too many concurrent discussions this is not possible. Thryduulf (talk) 13:19, 7 October 2023 (UTC)

• Support It seems to me we need a bit of cooling off of the broad topic area, a lot of these discussions seem to have the same sides bludgeoning each other with increasing allegations of ABF on both sides. And I include the "paid advising" RFC in that.
  I note this type of behavior isn't specific to this topic area, a month or two back we had the same thing happen with proposals related to MOS:GENDERID where people jumped on the bandwagon of proposing things and forked off several new RFCs as old ones got too heated. In fact, it seems some of the same people were deeply involved in those as are in this one too... Anomie⚔ 12:36, 7 October 2023 (UTC)
• Oppose - the problem isn't too many RFCs, it's a few editors bludgeoning the crap out of them. Deal with the bludgeoning editors instead of having a moratorium on RFCs. Levivich (talk) 14:47, 7 October 2023 (UTC)
• Oppose. Badly thought out, and more or less certain to result in more round-in-circles arguing if anyone was so misguided as to try to enforce it in any but the most trivial cases. AndyTheGrump (talk) 14:59, 7 October 2023 (UTC)
• Oppose I can understand the sentiment, but this would have far to many consequences. Also why is Wikipedia:Village pump (policy)#Admins and being paid to advise on editing, it has nothing to do with "deletion, notability and related matters". I agree with others here that less replying to replies, of replies, of replies, etc.. would make a big improvement. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:24, 7 October 2023 (UTC)
• Support something to halt the notability-RFC-after-notability-RFC-after-notability-RFC pattern - this is getting dizzying for me how many different notability proposals by the same group of editors are active. BeanieFan11 (talk) 18:17, 7 October 2023 (UTC)

  I have to wonder... I am one of those editors? Edward-Woodrow • talk 18:31, 7 October 2023 (UTC)

  I don't know anymore...if you are one, I've lost track because of the sheer quantity of proposals. BeanieFan11 (talk) 18:33, 7 October 2023 (UTC)

  Five is the quantity of notability proposals listed in this proposal. These five proposals were made by five different editors: Newimpartial, BilledMammal, Sunnya343, FOARP, and Edward-Woodrow. I'm not sure how they constitute the same group of editors, as I'm unaware of them ever doing anything as a group, like repeatedly voting the same way in other RfCs or AfDs or anything. Five is not too many RFCs for me to keep track of, although if one writes a dozen or more comments per RfC, then I could see how doing that in five RFCs would be overwhelming. For everyone. Levivich (talk) 18:57, 7 October 2023 (UTC)

  The "same group of editors" also implies there's some kind of deletionist conspiracy going on. Edward-Woodrow • talk 19:07, 7 October 2023 (UTC)

• Opposed - Having multiple large RFCs (on unrelated topics) hitting the Pump at the same time is nothing new, and is hardly disruptive. And it shouldn’t be a time sink. Just formulate your thoughts, state your opinion on the question as clearly as you can and move on to your regular editing. Don’t respond to other editor’s comments unless they directly ask you to clarify something you said. I know it is tempting to refute every opinion that disagrees with your own. Don’t do it. Don’t bludgeon the discussion. Blueboar (talk) 18:57, 7 October 2023 (UTC)
• Oppose any attempt to shut down discussion on these topics. Also, what Levivich said. Certain editors (including the odd admin) need to take a step back and stop bludgeoning these RfCs every time someone disagree with them. _wjemather^{please leave a message...} 19:24, 7 October 2023 (UTC)

  Once again this is not an attempt to "shut down" any discussion on anything, just to spread the discussions out in time. Thryduulf (talk) 19:34, 7 October 2023 (UTC)

  The framing of the proposal (including the title) and several of the comments and contributions, both here and in the discussions listed, tell a different story. And you continue to bludgeon. _wjemather^{please leave a message...} 06:32, 8 October 2023 (UTC)

  If you wish to read something other than what I have written, and characterise the proposal based on what I haven't written, then that is your prerogative but please do not expect me to agree with you. Thryduulf (talk) 10:04, 8 October 2023 (UTC)

• Oppose and Bad RFC - This is a non-neutrally-framed RFC question that simply assumes the proposals to be bad faith, and in some way connects a group of people who basically aren't connected. Particularly where they say "This is explicitly not intended to prevent or limit the asking of genuine questions" - does the proposer think the RFCs weren't genuine questions? The proposal would also block discussions that recently passed (but which the proposer opposed...) such as the LUGSTUBS draftification proposals. BM already agreed to withdraw their proposal on notability, so why is this proposal necessary? This is "temporary" moratorium that could last an indefinitely long amount of time given it being tied to the closure (after any review or other process) of five mostly unconnected discussions. Moreover the area banned for discussion includes a topic (mass creation of articles) that ARBCOM literally mandated discussion of (albeit that was withdrawn after no conclusion was reached, though obviously we should still try to reach some kind of conclusion).
  If you are exhausted in discussing certain issues then don't discuss them. If you want to do other things, then go and do them. It is the very essence of WP:BLUD/WP:BATTLEGROUND to think you have to rebut every single point in a discussion and cannot do anything else because you have to "win" for your "side".
  Finally, can I point out the extreme irony of attempting to shut down "exhausting" discussions by . . . making a proposal to shut them down then responding to people opposing with repetitive comments like "Once again this is not an attempt to "shut down" any discussion on anything"? FOARP (talk) 22:24, 7 October 2023 (UTC)

  Not an RfC. Edward-Woodrow • talk 22:29, 7 October 2023 (UTC)

  I didn't know we could just jump over the neutrality requirement by simply not using the template? FOARP (talk) 22:34, 7 October 2023 (UTC)

  This isn't an RFC, assumes nothing about the merits or otherwise of anybody or any discussion, assumes no good or bad faith about anything, does not connect the discussions in anything other than subject matter and makes no connections between those starting proposals (it doesn't even mention the discussion initiators at all so I'm puzzled where you've got this idea from?). No discussions are or will be "prohibited" or "blocked", no topic area is "banned" (as I've explicitly said multiple times now). Also, the moratorium idea was endorsed by multiple people with differing views on the merits of the different proposals, so this is not one side trying to "win" anything - the only suggestion of a battleground is from you. TLDR, almost none of what you've written relates to what has actually been proposed here, almost everything that does relate is incorrect. Thryduulf (talk) 23:06, 7 October 2023 (UTC)

  Literally the whole first paragraph is about why your proposal is a great idea - not a neutral question even in the slightest. ”as I’ve explicitly said multiple times now” - maybe learn something from this? FOARP (talk) 05:21, 8 October 2023 (UTC)

  Whether it is neutral or not, exactly none of it assumes anything about the nature of the discussions, the merits of the discussions, or the initiators of the discussions. Try reading what I wrote rather than what you want me to have written. Thryduulf (talk) 10:00, 8 October 2023 (UTC)

• Support It seems like a good idea to pace ourselves and obtain one consensus at a time, so that later discussions can refer to earlier ones. XOR'easter (talk) 00:17, 8 October 2023 (UTC)
• Oppose. The listed discussions are only loosely related at best, and the proposed moratorium is unwarranted and absurdly broad. Adumbrativus (talk) 09:42, 8 October 2023 (UTC)
• Oppose: Far too broad of a proposal and purports that other proposals are a burden upon others in some unclear way. Nom appears to be a long-winded case of WP:IDONTLIKEIT as it pertains to gaining the support of the wider community for various issues. User:Let'srun 12:50, 8 October 2023 (UTC)
• Oppose This feels like a proposal in search of a problem, and a non-neutral framing of the situation. No one forces any editors to engage with any or all proposals, and they're not actually related to the same things. If there's an issue with vexatious RfCs or conduct therein, that can be dealt with at an editor level. Der Wohltemperierte Fuchs ^talk 17:58, 8 October 2023 (UTC)
• Support - Many of the articles are being removed/drafted without proper research being done to see if they are or aren't notable. There's been many articles that were proven to be notable that were marked anyway to be drafted, yet nothing changes and nobody seems to care. I think it's wrong to ask people to look through a thousand articles at a time to check for notability. This is just turning into an endurance contest and that should not be what this is about. The best part about all of this is that it is becoming the exact same thing that mass article creations were about - getting things done fast and in large quantities, then worrying about the details later.KatoKungLee (talk) 21:18, 8 October 2023 (UTC)
• oppose I don't think this make sense from a procedural perspective. In the first place, I don't see how anyone who wasn't here for this should feel in the last bit bound by it. Second, since the effect is basically to shut out those who have a problem with the status quo, it isn't really a moratorium for the proposers. Third, the only reason I can see for a moratorium is to discuss a larger scale proposal, which isn't out there yet. Mangoe (talk) 04:43, 9 October 2023 (UTC)
• Oppose per Levivich, FOARP, and David Fuchs. XAM2175 ^(T) 23:14, 13 October 2023 (UTC)
• Oppose: A good faith idea that is impractical to implement. This is certainly a non-neutrally-framed RFC question. Per user CMD's comments we can simply leave an entry open as long as there are recent comments. -- Otr500 (talk) 19:06, 14 October 2023 (UTC)

Discussion of temporary moratorium on new proposals

• Comment. Not sure the discussion on paying administrators to consult is on topic? Espresso Addict (talk) 01:26, 7 October 2023 (UTC)

  @Thryduulf, should Wikipedia talk:WikiProject Boxing#RfC on readding upcoming fights in professional boxing record tables be in your list? WhatamIdoing (talk) 04:31, 7 October 2023 (UTC)

  I wasn't aware of that discussion, but it could qualify. At present it doesn't seem to be utilising a lot of editor time, so I'll leave it off for now but it can be added if that changes. Thryduulf (talk) 11:25, 7 October 2023 (UTC)

  I agree, the admin discussion seems unrelated to the problem of too many open fronts in the deletionist-inclusionist war and should be removed from the proposal. —Kusma (talk) 06:43, 7 October 2023 (UTC)

  I included that discussion as it is a large discussion featuring a lot of the same editors with similar consequences for editor time. The point of this proposal is not a "deletionist-inclusionist war" (or any other "war") but too many large discussions open concurrently. This proposal would not stop a new discussion on that subject but I don't think that is likely. Thryduulf (talk) 11:23, 7 October 2023 (UTC)

  If that's the case you may have wanted to title the section something other than Temporary moratorium on new proposals regarding deletion, notability and related matters. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:30, 7 October 2023 (UTC)

  The title does accurately reflect the scope of the actual proposal being made. That doesn't mean it's perfect but I'm not sure I can come up with something that is both concise and not misleading - you might be able to (concise summaries are not my strong suit) but I'd prefer if comments could be restricted to matters related to the proposal as written rather than matters related to what a different proposal with this title might have said. Thryduulf (talk) 18:22, 7 October 2023 (UTC)

  How is "Admins and being paid to advise on editing" related to deletion and notability? BilledMammal (talk) 05:31, 8 October 2023 (UTC)

  In fact, I'm not even sure how "RfC on the "Airlines and destinations" tables in airport articles" is related to deletion and notability; if you could explain that as well I would appreciate it. BilledMammal (talk) 05:32, 8 October 2023 (UTC)

  It is a discussion with potential destructive consequences for many articles. —Kusma (talk) 07:38, 8 October 2023 (UTC)

  Which one? Regardless, that might be your opinion, but it doesn't explain how it is related to deletion or notability? @Thryduulf:, can you explain why you believe those two discussions are related to deletion or notability? BilledMammal (talk) 09:11, 8 October 2023 (UTC)

  For the airlines discussion see point 2. For the admin discussion see previous answers. Thryduulf (talk) 09:57, 8 October 2023 (UTC)4

  Point 2 doesn't seem to be related to "notability and deletion"? Even on the basis of that, I have to agree with AD that your title is inaccurate and does not accurately reflect the scope of the actual proposal being made.

  For admin discussions, are you referring to I included that discussion as it is a large discussion featuring a lot of the same editors with similar consequences for editor time.? That doesn't explain how it is related to "notability and deletion"? BilledMammal (talk) 10:08, 8 October 2023 (UTC)

  The title is "deletion, notability and related matters". If you read the whole of the answer you quote and replies you will see I have already answered your question regarding admin discussions. Thryduulf (talk) 10:11, 8 October 2023 (UTC)

  The title is "deletion, notability and related matters". Yes. How is The inclusion/exclusion of types of content on a large number of pages related to deletion and notability?

  The rest doesn't answer my question; it's a discussion unrelated to "notability and deletion", and shouldn't be in the scope of this proposal. I agree with the above editors that you either need to reword the proposal, or remove that discussion. BilledMammal (talk) 10:42, 8 October 2023 (UTC)

• This isn't how consensus works. We don't put gag orders on topics. The frequency of these discussions (and I expect more in the near future) indicates that there's a series of interrelated, long-standing problems that editors are finally attempting to fix. Even if this was something at all enforceable, I see little to gain by saying "fix them more slowly". Thebiguglyalien (talk) 18:34, 7 October 2023 (UTC)
• BM’s RFC (which I think has been productive) has been withdrawn, as had been agreed before this present discussion even opened. The GEOLAND discussion I previously opened only had a relatively short period of time left before it was due to be archived anyway, and discussion there had come to a natural conclusion, but I’ve withdrawn it all the same. If these discussions truly were as taxing as made out here, closure of them could have been requested through the ordinary channels: I ask the proposer here to be consistent with their own statements about how tiring and distracting they find these discussions, and withdraw this one, which I do not believe is likely to pass. FOARP (talk) 11:27, 8 October 2023 (UTC)

Indeed, with the closure of the prod discussion, I think we're now down to a reasonable number of discussions, so closing this one too would seem sensible. Espresso Addict (talk) 23:01, 9 October 2023 (UTC)

• Comment I agree with the above that having such a vast blanket mortarium on new proposals is misguided but I would like to express my concern/general worries about not just the haste and successiveness of these proposals but also the reach. A lot of the articles I've made/contributed to would be significantly affected by some of the proposed changes (particularly those in the deletionism/inclusionism field) but I only figured out about these proposals from random chance (one of the editors involved in these discussions happened to send me an unrelated message to me and took a while to respond so I got worried and noticed their contributions on the proposals). While in an ideal world going through proposals quickly and efficiently would be great, there has to be much more done in the way of notifying affected users, especially those who would be significantly impacted by each proposal or are an active, major contributor to a wikiproject that would be affected. That said, given the number of open discussions on the page has dropped sufficiently low, this proposal isn't really necessary (e.g. a mortarium isn't necessary) but it would be beneficial to take a patient/slow approach with future high-impact proposals (maybe extended the time a discussion could be kept open/active depending on the context?). Also, while I guess it would depend on the articles in question, it would also be good to have discussions about mass-deletions of fewer, more narrowly defined articles (I'm thinking specifically of the LUGStubs proposals which were overly expansive and poorly executed, imo). In any case, these are just my experiences, thoughts, and opinions but hopefully they have some bearing on this and future proposal discussions. Cheers, Dan the Animator 01:59, 10 October 2023 (UTC)

  This requirement cuts both ways though - we've seen in the past stub articles created at a rate of hundreds a days by an individual editor based on a single, primary source, with the explicit idea that other editors would expand the resulting stubs, but without anyone ever really being consulted on the idea. When it turned out that the sources they were using had been epicly mis-understood/were inaccurate and that there was no actual secondary sourcing on which those stubs could be expanded, it was already way too late for any intervention from the community to stop Wikipedia being spammed with tens of thousands of useless and inaccurate stubs. When confronted with this, the editor simply responded with bizarre accusations and quit the project. That was more than two years ago and we're still trying to clean up the resulting mess.

  No-one should simply build up a fait accompli of unimprovable stubs so numerous that none of the processes we have in place can handle them, without any discussion with anyone about it. We even had an ARBCOM ruling on this: "Editors who are collectively or individually making large numbers of similar edits, and are apprised that those edits are controversial or disputed, are expected to attempt to resolve the dispute through discussion. It is inappropriate to use repetition or volume in order to present opponents with a fait accompli or to exhaust their ability to contest the change. This applies to many editors making a few edits each, as well as a few editors making many edits." FOARP (talk) 07:44, 10 October 2023 (UTC)

• I fundamentally believe editor time is a precious resource we should try to be thoughtful about expending. But I don't understand, on a practical level, how this moratorium does anything productive. In order to do something productive in the end I feel like we'd have to set some priorities so that the questions that lots of editors care about aren't forced to wait in some queue for things relatively few people care about to be finished. And I just have trouble imagning that working. And frankly I think we could do better with being more decentralized in general. "Back in the olden days" these kinds of discussions were happening all the time, and no one saw it as a problem. Partly this is because of the editor base we had at the time (which wasn't necessarily larger but which was distributed and focused in different ways), but also, crucially, people didn't feel like decisions were as fixed so if you didn't have time at the moment it wasn't like you lost your chance to weigh in on the topic forever. Doing something about that feels equally as manageable as some kind of nebulous moritorium. Barkeep49 (talk) 22:14, 11 October 2023 (UTC)

I started a proposal on Talk:2023_Israel–Hamas_war#Question_2:_Should_the_video_be_blacklisted_from_the_English_Wikipedia? about blacklisting a particular piece of media. You might want to read that discussion for context before commenting. Awesome Aasim 15:06, 16 October 2023 (UTC)

PS you can add an RfC tag before this proposal. Awesome Aasim 15:09, 16 October 2023 (UTC)

The blacklisting has already been discussed at the correct place (MediaWiki talk:Bad image list) and rejected. —Kusma (talk) 15:19, 16 October 2023 (UTC)

Uhhh.... I am pretty sure the edit protected template must be used after obtaining consensus. Since there was no consensus established and it turned out to be a contentious matter I withdrew my request. Awesome Aasim 16:47, 16 October 2023 (UTC)

Consensus determines whether or not an image is used in an article. The Bad image list is mostly an anti-vandalism tool, where the inclusion is on basis of need. You do not need to show consensus, but necessity. —Kusma (talk) 18:49, 16 October 2023 (UTC)

 You are invited to join the discussion at Wikipedia talk:WikiProject Articles for creation § Where should we place the scam warning?. Ca ^{talk to me!} 14:04, 18 October 2023 (UTC)

An unrecognized state in Nagorno-Karabakh no longer exists, the city of Khankendi is completely under the control of Azerbaijan, they even hung a state flag there. But the Armenian moderator cancel edits about renaming the city, leaving the unrecognized and irrelevant name “Stepanakert”. Please make the title "Khankendi" in the article 109.87.192.15 (talk) 09:17, 22 October 2023 (UTC)

Per Wikipedia:Official names, we do not change the name of an article just to recognize an official name. The naming of the article should be in accordance with the provisions of Wikipedia:Article titles#Deciding on an article title. Discussion about renaming the article should continue on the article's talk page. Donald Albury 12:03, 22 October 2023 (UTC)

Hello, I’ve noticed that many Hebrew words are transcribed wrongly. For example, on of the cities in Israel is transcribed <Holon> instead of <H̱olon>, so are many other places in Israel. I suggest changing all names according to this very list: https://hebrew-academy.org.il/2022/06/27/%d7%a8%d7%a9%d7%99%d7%9e%d7%aa-%d7%94%d7%99%d7%99%d7%a9%d7%95%d7%91%d7%99%d7%9d-%d7%91%d7%99%d7%a9%d7%a8%d7%90%d7%9c/

This isn’t only for English, but for any language that uses the Latin alphabet – French, German and even Turkish. מושא עקיף (talk) 03:19, 21 October 2023 (UTC)

The general rule on English Wikipedia is to use the name most commonly used in reliable English-language sources, even if that differs from the official transliteration. In the case of Holon/H̱olon, it seems as though the transliteration without the diacritic is common and the usage is in line with our usual policy Caeciliusinhorto (talk) 13:18, 22 October 2023 (UTC)

Whether a Wikipedia Book was created using the Book Tool or not, this page needs to be reopened immediately even if the namespace was removed or if the tool is not working. The more general concept of a Wikipedia Book still exists. ModernDaySlavery (talk) 20:26, 21 October 2023 (UTC)

The page tell us about a tool and namespace that are no longer functioning or available. Book tool no longer functions and namespace deleted. Moxy- 22:53, 23 October 2023 (UTC)

Book tool still does function, just the PDF functionality doesn't function. Also I removed references to the namespace. Also if you want I can even add the book tool is no longer supported (even only a feature of it isnt supported) but the concept of a book made of wikipedia article is very important and therefore the page should still continue. ModernDaySlavery (talk) 23:00, 23 October 2023 (UTC)

As the Book Creator no longer generates copies of Wikipedia books, its primary working feature directs users to order printed Wikipedia books from PediaPress, a third-party company. Editors in discussion valued the user experience of Wikipedia readers over the business prospects of PediaPress. Moxy- 23:37, 23 October 2023 (UTC)

It does generate Wikipedia books just not in PDF form. See User:Lasertrimman/Books/Hart / OSI. In addition there is also MediaWiki2LaTeX that allows you to download Wikipedia Books. Also like I said the concept of a Wikipedia Book remains, a Wikipedia Book doesn't even need to be created by the Wikipedia Book tool, it just refers to a collection of Wikipedia articles. Creating a new Article for the concept doesn't make sense. ModernDaySlavery (talk) 23:57, 23 October 2023 (UTC)

WP:RFCEND says that by default, Legobot will assign a 30-day period to an RfC and then "forget" about it. I have encountered some unclosed RfCs in the archives. Currently, to create a request, a user must manually submit it to CR. Because most discussions are closeable at the 30-day mark, it would make sense to list all of these "old discussions" so that people direct their attention to them. Can someone write a piece of code that would contain the following info:

• Where the discussion is
• How old it is (determined by timestamp of when the rfc started)
• How many comments were submitted during the past 7 days to the discussion
• Some boilerplate text (eg. This discussion has likely reached maturity. An uninvolved editor is asked to close it if its outcome is already clear). Szmenderowiecki (talk) 17:03, 26 October 2023 (UTC)

See WP:WHENCLOSE. Not everything needs a formal close, and if everybody has moved on without one then that's usually a sign one wasn't needed. Also, some discussions are very much not mature at the 30 day mark. Together this means that this proposal would fill up WP:CR with discussions that don't need closing (yet) making it harder for prospective closers to find the ones that do. Thryduulf (talk) 19:56, 26 October 2023 (UTC)

2023 Israel–Hamas war has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. BilledMammal (talk) 01:50, 27 October 2023 (UTC)

What should be done with emoji redirects, particularly with emoji redirects that are found to represent vague concepts that are not well reflected on Wikipedia? Utopes _{(talk / cont)} 02:52, 16 October 2023 (UTC)

Update: The options have been recontextualized. If an article mentions or refers to an emoji, such as Face with Tears of Joy emoji, it is currently practiced to have the emoji in question (😂 in this instance) exist as a redirect to such page. This is the status quo for these situations, which is not being disputed. This RfC was intended to address the gray area where there isn't a perfect match for a target, so I've narrowed the options as follows:

For emoji redirects that don't have an associated article in existence, should we:

• Option 1: Retarget all other emoji redirects to lists of symbols by default, such as emoji which appear on Supplemental Symbols and Pictographs or Symbols and Pictographs Extended-A.
• Option 2: Retarget to pages where the emoji's depiction is deemed unambiguous, such as 🔥 being a redirect to fire, and retarget ambiguous emoji to relevant lists of symbols.
• Option 3: Retarget to pages where the emoji's depiction is deemed unambiguous, such as 🔥 being a redirect to fire, and delete all other emoji redirects with ambiguous meanings.
• Option 4: Delete all other emoji redirects without associated articles.

— Preceding unsigned comment added by Utopes (talk • contribs) 16:45, 16 October 2023 (UTC)

Background (emoji redirects)

Over the last several months, there have been several Redirects for Discussion entries at increasing frequency about the justification for the existence of emoji redirects. At this point, there are often several different discussions happening on a weekly basis, which often boil down to the same general viewpoints about how to deal with redirect emojis as a whole. Some past discussions that have recently closed in September and early October include the following: RfD on 🤪, RfD on 🙀, RfD on 🤭, RfD on 👩%E2%80%8D💻, RfD on 💨, RfD on 🫸, among many discussions which were also ongoing during this period, as well as many others which have cropped up and still have not been closed. The only precedence which has been recorded is in an RfD subset page which documents the common outcomes of discussions, and under the section for WP:REMOJI. During recent discussions, however, this documentation has been challenged and dated, particularly relating to emoji that can be depicted and interpreted differently on multiple platforms and different people, and whether or not a redirect is necessary for these emoji in the first place. Comments on this matter would be appreciated to help determine whether or not all emoji should inherently be considered as "likely search terms" and automatically exist as redirects, or whether there should be criteria for inclusion for emoji redirects to exist in the first place. Utopes _{(talk / cont)} 02:52, 16 October 2023 (UTC)

Survey (Emoji redirects)

• I sympathize most with Option 2, and I would further suggest that most or almost all such 'single-glyph redirects' should be treated in basically this way, as I see this system as being the most helpful to the reader (though I am happy to be persuaded otherwise! :D). For example, suppose I were to encounter the symbol ❦, unfamiliar to me, in a digital document; to learn about it, my most obvious course of action would be to copy and paste that single character into the search bar. If I were to do so right now, I would be redirected to fleuron (typography), which explains what this glyph is and how it's used. This behavior makes sense to me. Moreover, if an article specifically about some glyph does not exist (as is the case for ⌀), then it makes sense to me that a search for that glyph should redirect to whatever location deals most specifically with it as a glyph (in this case, diameter#Symbol). At the moment, this seems like helpful redirect behavior, and I don't see why emojis in particular should be treated much differently. Tl;dr: I think redirects from emojis should generally point the reader to a location that discusses the emoji as an emoji. Shells-shells (talk) 03:44, 16 October 2023 (UTC)

  I am not sure about my terminology, so feel free to substitute grapheme or character or some other term in the place of glyph as you like. Shells-shells (talk) 04:06, 16 October 2023 (UTC)

• Option 2, was writing more but Shells-shells covered it very elegantly. Glyphs should redirect to the location where readers can learn more about that glyph. If the best is a list of glyphs, redirect there. Don't redirect to a particular interpretation of meaning, emojis take on different meanings in conversation far removed from the official intention. CMD (talk) 03:51, 16 October 2023 (UTC)

  Note to closer When I wrote this option 2 was entirely different, it should not be taken as support for the (as of this timestamp) current option 2. CMD (talk) 01:35, 26 October 2023 (UTC)

• Option 7, do not try to prescribe this centrally, but let RFD do its thing on individual redirects based on individual consensus. Do not mass-create, do not mass-delete. —Kusma (talk) 09:24, 16 October 2023 (UTC)

  We've tried to this, with not-so-pretty results. Edward-Woodrow • talk 12:13, 16 October 2023 (UTC)

  I would strongly push back against that characterization. -- Tavix ^(talk) 13:26, 16 October 2023 (UTC)

  I agree with Tavix. The recent discussions of emoji redirects have pretty much all ended in a clear consensus and the discussions have been perfectly civil affairs. Thryduulf (talk) 14:49, 16 October 2023 (UTC)

  In addition, keep all emoji redirects that are potentially affected by this discussion but haven't been tagged for deletion, per WP:LEOPARD. Option 8 is also better than the options presented above. —Kusma (talk) 13:32, 16 October 2023 (UTC)

  I disagree. Individual debates are often long and ineffective. Martin Tauchman (talk) 14:13, 16 October 2023 (UTC)

  ... but aren't they more likely to produce the correct result for individual emoji? —Kusma (talk) 15:57, 16 October 2023 (UTC)

• Option 3 (the numbers changed?): the "definitions" of emojis, frequently touted by Keep !voters at RfD, may be subject to change, and, furthermore, the interpretation of what an emoji means is wholly subjective and may vary from person to person. Worse, display varies across operating systems and devices, adding another layer of complexity. In this way, I believe ambiguous emoji redirects should be deleted, as their interpretations may vary, and no target is good. Retargeting to the emoji block is not very helpful to the reader, as all it tells them is "wow, it's an emoji", while targetting to the "definition" is only one of many interpretations. Straightforward emoji redirects, like the fire example mentioned, should probably be kept, as they indirectly inform the reader of the meaning of the emoji.
  Take 🤪. Is that silliness? Zanyness? Insanity? Drunkenness? Or just someone having a really good time? Who knows? The consensus of that discussion was retarget to Supplemental Symbols and Pictographs, which is better than the alternatives, I guess, but not really helpful to the reader, as explained above. Edward-Woodrow • talk 12:21, 16 October 2023 (UTC)

Option 2 is my second choice. I strongly oppose Option 8. We should not have to create entire DAB pages for emojis. We're not emojipedia. And, as a side comment, there is a tendency at RfD that the "definition" of the emoji as listed in unicode is the end-all of potential interpretations. Edward-Woodrow • talk 19:45, 16 October 2023 (UTC)

And also, I maintain that emojis are unlikely search terms, that we're not emojipedia, and that we should have to provide results for people pasting emojis into the search bar for who-knows-what reason. But consensus seems unlikely to swing that way. Edward-Woodrow • talk 19:48, 16 October 2023 (UTC)

• I personally would find Supplemental Symbols and Pictographs useful, as it tells me the unicode number for 🤪. There are other websites I suppose, but I don't think a redirect to information about the emoji is a bad thing for en.wiki. CMD (talk) 12:26, 16 October 2023 (UTC)

  Note the official Unicode character names cannot change, to the point where errors are left uncorrected. See Unicode Technical Note #27, Known Anomalies in Unicode Character Names for examples. isaacl (talk) 16:04, 16 October 2023 (UTC)

• Option 6 deals soundly with vacuous, cretinous inanity. Serial 12:24, 16 October 2023 (UTC)
• (edit conflict) Option 8. Emojis with articles should target those articles, other emoji with meanings that clearly correspond to one article should target that article. Emojis with meanings that correspond to multiple articles should target a list, disambiguation page, set index or other place where readers can follow links to the article(s) relevant to their search. Other emojis should redirect to relevant lists of symbols. Emoji should be redlinks only when we want to encourage the creation of an article about that emoji and/or its meaning. Thryduulf (talk) 12:31, 16 October 2023 (UTC)

  So we should create emoji disambiguation pages? Because what existing DAB page covers the potential meanings of 🤪? Edward-Woodrow • talk 19:42, 16 October 2023 (UTC)

  I see no reason not to if that is the best option, that's why Stuffed flatbread was created, but 🔴 targetting the pre-existing Red Circle disambiguation page is going to be the more common example. Thryduulf (talk) 20:15, 16 October 2023 (UTC)

• Option 8 sounds good to me. Option 7 was tempting but RfDs don't attract enough attention to provide consistent treatment. Certes (talk) 12:46, 16 October 2023 (UTC)
• Option 8 is a good summary of the status quo and consensus at recent RfDs. -- Tavix ^(talk) 13:26, 16 October 2023 (UTC)

I'm now in favor of finalizing a list of emoji and retargeting them all there. Draft:List of emojis (faces) looks excellent! -- Tavix ^(talk) 19:51, 20 October 2023 (UTC)

I support that too, given that it clears up the ambiguities effectively. Edward-Woodrow • talk 19:57, 20 October 2023 (UTC)

• Option 8 seems like a good solution here. And in general I'm against deletion of any emojis just as I would be against deletion of letter glyphs being deleted. --Gonnym (talk) 13:43, 16 October 2023 (UTC)

  Gonnym, could you elaborate on your reasoning? It's not self-evident why someone would oppose the deletion of redirects from letters on principle, so it's not clear what to infer from that analogy to the case of emoji. _signed, Rosguill ^talk 13:50, 16 October 2023 (UTC)

  Are you serious? If the letter A did not have an article, are you seriously saying you think that Wikipedia would be better off without a redirect from the letter to a more general place where that article is dealt with? Other examples would be Ƞ redirecting to a descriptive title such as N with long right leg or א leading to the English language title. Do you believe these should be deleted and users should just have to find the best targets for themselves? These are the same for emojis and in fact, the numerous past RfD have shown that some of the nominations have been the result of the nominator not understanding them, so deleting them would result in even less clarity. Gonnym (talk) 14:05, 16 October 2023 (UTC)

  What about letters with accents, which could be resolved as either the letter or as the accent? Or letters for which, for one reason or another, we don't have a suitable target yet? Or letters that are also the names of actual things/places (such as Å, which could refer to 12 different towns in Scandinavia, or Angstroms, or just the letter). Or uncommon digraphs such as fl (which currently points to a less-than-helpful disambiguation page), including letters such as ƣ that have ambiguous codepoints (that symbol currently is used for both Turkic gha and as a Medieval Latin digraph for oi, but those are two letters with distinct histories that should not and in the future may not have the same codepoint). Or letters that are themselves notable enough to meet WP:REDYES criteria? What about logographic characters used in Chinese or Japanese? _signed, Rosguill ^talk 14:27, 16 October 2023 (UTC)

  All valid. Gonnym (talk) 18:18, 16 October 2023 (UTC)

  I find this perspective to be absolutist to a degree that is in total dissonance with the general approach of our policies and guidelines, and further a startling lack of care with respect to the intricacies and differences between single-character symbols and their possible referents. _signed, Rosguill ^talk 19:58, 21 October 2023 (UTC)

• Option 2 makes the most sense. Emoji's frequently have contested meanings - so we should not guess where a redirect should go. --Enos733 (talk) 15:09, 16 October 2023 (UTC)
• Option 8 per Thryduulf. Enix150 (talk) 20:20, 16 October 2023 (UTC)
• We should be treating these the same way we do foreign-language redirects. Lorry is an English-language word for the same concept as "truck", and so redirects there. (It could have been the other way around.) "Lastkraftwagen", "camion", and "貨物自動車" are how that concept is spelled in German, French, and Japanese; they don't redirect to truck because trucks don't have anything in particular to do with Germany, France, or Japan. They don't have anything to do with iconography, either, so ⛟, 🚚, and 🚛 are just as inappropriate. It's a different matter entirely for an article like smiley, which is specifically about little pictures of happy faces, just as it is for Deutschland, département, and 東京都. —Cryptic 20:47, 16 October 2023 (UTC)

I've added a partition here, as the options' wording has been adjusted. For the suggested Options 7 and 8 proposed above, Option 8 now more closely aligns with the current Option 2 (minus the redlink clause), whereas Option 7 would be the rejection / opposition of all other options, and to deal with redirects on a case by case basis. Utopes _{(talk / cont)} 16:50, 16 October 2023 (UTC)

The new option 2 does not closely match option 8 as it is missing the important clause about emoji with multiple article matches (e.g. 🔴 → Red Circle (a disambiguation page), 🥙 → Stuffed flatbread (a set index)) as well as the redlink clause. Thryduulf (talk) 18:07, 16 October 2023 (UTC)

@Thryduulf:. Apologies for the delay, I've been extremely busy this last week and wasn't able to properly return until addressing the RfC situation that has since formed.

For what it's worth, I said that the new option 2 was more close to the Option 8 as suggested, but not exactly due to the redlink clause. It was more close due to the narrowed range of "only emoji redirects without articles". As for the rest of Option 8's contents, I didn't (and still don't particularly) agree that the "multiple article matches" is important as stated to include within the text of the Option (to otherwise differentiate it from Option 2), because the intent of Options 2&3 was to be the catch-all options for any other article possibilities beyond databases or deletion respectively. Because of this, set index articles and disambiguation pages would fall under this if appropriate, because from my point of view the 4 options presented were wholly encompassing of all possibilities. There were essentially 2 proposed criteria, with 2 fully-encompassing binary solutions to deal with them. While the first binary of "keep (at database) or delete emoji redirects where no other target is appropriate" is present in the form of 1&2 versus 3&4, the second binary would be the one that this interpretation is relevant to: Options 1 and 4 suggested to treat ALL emojis the same regardless, whereas Options 2 and 3 proposed that emojis should be treated differently on a case-by-case basis depending on how the image is depicted. From my point of view, Option 8 has the same intention as that, but keeps going with extra examples that to me seem as if it would still be supported by Option 2's solution. The only difference, however, is the mention of red-linked emojis, which I see to be a different subject matter entirely which falls outside the scope of the 2 x 2 binary options. Set index articles are still articles, so I don't see how that is different from the provided example of 🔥 to the fire article. 🥙 still unambiguously depict a Stuffed flatbread, which happens to be a set index article. To me it seems like yet another valid example.

I'll concede that this intention behind the Option could have been confusing, however, as only the fire was shown to explain what it might look like. Furthermore, I guess it can be said that "maybe this type of RfC question shouldn't have been designated with options to begin with". In removing options entirely, this could allow for more involved possible solutions. To me though, this broad path did not feel correct or needed, as there are a seemingly small number (2) of crossroads that needed solutions (such as whether or not a gray area exists). Open forums can work well in RfCs, but here it would effectively be picking and choosing different emoji to assign with different solutions... that all still match the same overarching precedent that "there IS no precedent and each should be dealt with on a case by case basis, depending on whether a regular article, set index article, or a disambiguation page seems to be most appropriate from the depiction". These all fall under the same umbrella, and can be summed up without needing to declare which styles of articles that can and can't be targeted, effectively declaring criteria to set index, criteria to disambiguate, criteria to red-link and etc.

Because of this, I feel like I once again lean back towards the thought that the 4 options were sufficient enough. The second binary option posed by 1&4 vs 2&3, in my eyes, was essentially asking to choose between "There is no gray area (treat all the same, i.e. 1&4)" or "There is a gray area (case by case, i.e. 2&3)". At the risk of duplicating my words, there is no gray area between the two binary conclusions of "there is gray area" or "there isn't". If there's ANY gray area, the latter option (represented by 2&3) would seem to me to be sufficient to capture that, which is what the proposed Option 8 does. The only difference, because of this, would appear to be the redlink clause, which wasn't a part of the two binaries (and also feels to be a different can of worms because emoji's without articles will never be red, as they will appear the same regardless of whether they are an article or not. The cases of emoji with associated articles is easily countable (exactly 8 as of now) so the referred-to cases of emoji that could receive articles but don't have them already feels like it should be a separate topic for "which redirects should be deleted to encourage article creation")

I do wish in hindsight that I could have painted a better picture with clearer intentions behind the option description, because I did feel when putting this together that the 4 options listed sufficiently covered the two main goals of the RfC. I think that focusing on just the new 4 to begin with would have made things a lot easier to wrap heads around, because shifting the goalpost inward was still a shifting of the goalpost. But even then, it seems to me that from the beginning, Option 8 was still covered within the worlds of combining old Option 2 and old Option 3 (making Option 8 a warranted combo-solution at the time). Post-revision, though, it looked to me as if Option 2 was just it, minus the redlink clause. As for the other alternative suggestion, Option 7 was just in opposition towards using an RfC to come up with a solution, which seems to be a paradox and was only given a number for formality. (It's certainly a valid position to be opposed to using the RfC to prescribe a universal solution, but voting for an Option called "7" through the means of the RfC would still be prescribing a universal solution of "no universal solution"... The text is more closely akin to a "none of the above" pathway. I guess it could be given a number for ease of reference, but it certainly falls squarely outside of the proposed grid of 6 solutions -> 4 revised solutions.)

It seems that this RfC may be restarted, which is fine and definitely understandable. I was talking with the User King of Hearts in the discussion section, which was the very first message in the RfC which is where the 4-option alternate setup was first proposed. The conversation between us developed throughout the evening, and I implemented the suggestion on the same day the RfC started. Because the context behind the change was completely available, I believed that restructuring the votes based on the immediate RfC feedback would be uncontroversial as the context behind the change was all quickly accessible, and I figured that collapsing the original options and partitioning the original votes would make things clear moving forward. I did not expect the older alternatives solutions to carry over past the partition line, but this was on me for not clearly structuring the vote options to begin with. I do think a vote will eventually happen on this topic in some capacity, but using this space to figure out what to cover in the future emoji-redirect RfC seems like what will happen at this juncture, whether it is more of an open forum, a series of yes/no propositions, or what have you. Utopes _{(talk / cont)} 07:54, 28 October 2023 (UTC)

@Utopes: I've only skimread your comment (tl;dr applies) so apologies if I've missed anything, but the "grid" you keep talking about needing to fit things into seems completely arbitrary? That multiple keep are supporting options not in your first or revised set suggest that the considerations left out are important. As for changing options midway through an RFC, that's rarely not going to result in confusion. Thryduulf (talk) 09:58, 28 October 2023 (UTC)

No worries, I'm going to be heading to bed soon but it was something I had on my mind after seeing the direction things went in regards to the RfC post-option refinement. This could be my misinterpretation as well, but I feel cumulatively we may be saying the same thing in regards to Option 2 vs 8, possibly. Option 2 as above is written "Retarget to pages where the emoji's depiction is deemed unambiguous". The emoji 🔴, to this effect, unambiguously refers to a red circle. Therefore, my view of Option 2 is that it would suggest this emoji be redirected to Red Circle. Such target happens to be a disambiguation page, but it is a page nonetheless, hence why I viewed Option 8 to be redundant on this factor (and in part was why I was concerned things were getting out of hand with the 2 vs 8 😅). If this interpretation of Option 8 is correct and the same as how you described it here, I feel now could be a worthwhile time to workshop and prepare for a potential RfC redo, as the option switch certainly did not make it easier by any means, although I underestimated its negative effect. Utopes _{(talk / cont)} 10:12, 28 October 2023 (UTC)

• This is one of those RFCs that I wish had been formatted as a Request for Actual Comments instead of a simplistic Request for Numbered Votes. Here's what I want: If I paste an emoji into the search bar, I want it to take me to some place that tells me what that thing is. It doesn't actually matter if it's perfect. As a general rule, I'm just trying to figure out what that tiny little thing is. I can read without my glasses on, but I can't tell you what 🤾 is even with them on. Please redirect those to some sensible page. If you send them to a list, then please make it really easy to figure out which list item it's being redirected to. WhatamIdoing (talk) 19:54, 16 October 2023 (UTC)

  For 🤾, I'm guessing a discus thrower, a frisbee player, a dancer, or a track athlete. Edward-Woodrow • talk 19:56, 16 October 2023 (UTC)

  It's "person playing handball". The emoji redirects to Handball, so the question is answered correctly. -- Tavix ^(talk) 20:00, 16 October 2023 (UTC)

  Its Unicode name is simply "HANDBALL", so the question's answered even more correctly. Certes (talk) 21:29, 16 October 2023 (UTC)

  Without my glasses on, it looks kind of like sparkles. Confetti, maybe? With them on, maybe it's a dancer. WhatamIdoing (talk) 05:46, 17 October 2023 (UTC)

  This is exactly the reason why I see redirects from emojis as a Good Thing and it's the principle behind my option 8 of retargetting to the most specific place we have. Thryduulf (talk) 21:05, 16 October 2023 (UTC)

• I'm in favor of Option 2 for the reasons described more elegantly than I could above (thanks to Shells-shells and others). But what I want to add to the discussion is that we should be more perscriptivist than descriptivist because the nature of emoji's creation is technical, rather than their use, which can be covered in an article if necessary, like the one described above where the emoji now gets an article such as Face with Tears of Joy emoji. That's where editors should be allowed to use secondary sources to delve into the descriptivist side of things using secondary sources. That's the nuanced that's missed when we allow 👩‍💻 to redirect to Women in computing but 👨‍💻 gets Information technology, maybe? That's not what was written when the standard was created. Yes, ❦ leads to Fleuron (typography) because that's what it is. If there isn't a 1:1 match for the description of the character as set by the standard (🔥 to Fire, and 🛑 to Stop sign), or an article about the technical thing it describes such as (⏯️ play/pause button to Media control symbols and 💨 dashing away to The Lexicon of Comicana § Briffits) then it should be redirected to the technical list so people can see the perscribed definition of a technical glyph. 🙀 should not be cat because the nuance can't be captured in a redirect--it's a weary cat, 👩‍💻 isn't women in computing, it's a women technologist, and 🫸 isn't a hand (not that I'd be able to tell, it doesn't load on this browser) it's a rightwards pushing hand--because I can't see it, that's required nuance that I'd miss if I were redirected to hand.
  In summary, I think much like the importance of keeping the redirect for simple and uncontroversial emojis is required for an encyclopedia, losing the nuance of a technical glyph via non-specific redirect hurts the purpose of an encyclopedia. For that reason, we need to make sure there's diligence and clear directives not to allow broad redirects, and to save the nuance. And that's accomplished by redirecting to the list with technical descriptions. microbiologyMarcus ^{(petri dish)} 21:05, 16 October 2023 (UTC)

• Other I suggest creating a new article titled List of emojis (similar to the List of emoticons article), and suggest all those emojis redirect to that 'List of emojis' article instead. Some1 (talk) 23:02, 16 October 2023 (UTC)
• Comment (completely confused by the change in available options). I agree with above commenters that someone pasting such a character into Wikipedia search is most likely to be looking for an idea of what it is generally considered to represent, and redirection to that particular symbol if we have an article, or to a list of symbols including it if we do not, is most likely to be useful. I'm not sure why we have a list of emoticons but not a list of emojis that states the usual associated meanings? I also don't think redirecting, say, 🔥 to Fire should necessarily be the norm, even where a 1:1 correspondence can be agreed; after all we often deliberately don't redirect foreign language terms. (And in that particular case, I've seen it used as "you're on fire" or "go you!" or "hot!" kinds of metaphorical meanings, rather than the literal one.) Espresso Addict (talk) 00:04, 17 October 2023 (UTC)
• Support Option 8 seems to be reasonable --Lenticel ^(talk) 00:14, 17 October 2023 (UTC)
• I agree with WhatamIdoing, if I search for an emoji I just want the article that is most helpful. Emojis with articles should redirect to those articles, emojis without articles should redirect to a new list articles explaining the emojis with appropriate links as needed. I don't think emojis should be redirected to articles about the subject they represent. 🤾(Person Playing Handball, as mentioned above) redirects to Handball, but that article makes no mention of the emoji so it's hardly helpful for someone looking for details about the emoji itself. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:17, 17 October 2023 (UTC)
• Option 1 - specifically this is a vote against redirecting 🥕 to Carrot or 🔥 to Fire. The title for an emoji should have information about the emoji, not the concept it represents. Ideally, there will be a link to the concept (or several related concepts) on the target page.
  Deleting these outright is asking for a long series of well-intentioned re-creations; some redirect should be maintained for these titles. Walt Yoder (talk) 21:39, 17 October 2023 (UTC)
• Strong oppose Option 4, neutral on others. Frostly (talk) 22:00, 17 October 2023 (UTC)

  @Frostly: May I ask why? Edward-Woodrow • talk 22:37, 17 October 2023 (UTC)

  Emojis greatly aid in navigation, especially for younger generations. Including them as redirects is one more step towards modernizing the site. Frostly (talk) 23:17, 17 October 2023 (UTC)

• Option 1 Any other outcome feels nonsensical. Why would we redirect 🔥 to fire?? If I'm googling an emoji, I want to see it in its emoji context, i.e. the list of emojis. I know what a fire is. What I don't know is the background behind the fire emoji. CaptainEek ^{Edits Ho Cap'n!}⚓ 00:50, 18 October 2023 (UTC)
• Start again. There are references to options 7 and 8 which don't ever seem to have been defined. You can't move the goalposts halfway through. Stifle (talk) 11:47, 18 October 2023 (UTC)

  Option 8 was proposed by Thryduulf. "Emojis with articles should target those articles, other emoji with meanings that clearly correspond to one article should target that article. Emojis with meanings that correspond to multiple articles should target a list, disambiguation page, set index or other place where readers can follow links to the article(s) relevant to their search. Other emojis should redirect to relevant lists of symbols. Emoji should be redlinks only when we want to encourage the creation of an article about that emoji and/or its meaning." Enix150 (talk) 03:21, 21 October 2023 (UTC)

• Redo RFC, per Stifle. The new option numbers overlap with the old option numbers reusing the same numbers for different options. The survey is thus essentially incomprehensible. Sandizer (talk) 12:27, 18 October 2023 (UTC)

  IMO, we should just cancel the RfC and let editors work on the List of emojis article (non-redirect), along with its subpages (Draft:List of emojis (faces), etc.) Some1 (talk) 12:35, 18 October 2023 (UTC)

• #️⃣1️⃣ - info about the emoji, not the concept it represents. 👍 Levivich (talk) 14:04, 18 October 2023 (UTC)
• Restart RFC per Stifle.The 🏎 Corvette 🏍 ZR1^{(The Garage)} 17:07, 18 October 2023 (UTC)
• Restart per Stifle as they have a good point as well as what Sandizer mentioned Isla 🏳️‍⚧ 19:55, 19 October 2023 (UTC)
• Do we really need an RfC for this? The point of RfD is to discuss where a redirect should point to. If there is no agreement as to what the title means, it usually results in deletion or disambiguation. Status quo is fine. Awesome Aasim 13:07, 20 October 2023 (UTC)

  Because there is no firm policy on emoji redirects, which makes discussion difficult; it descends into a matter of opinions. A policy, or at least a guideline, addressing what to do with these things, would make discussion much easier (I've noticed that on old log days, emoji discussions are almost always the last to be closed). Edward-Woodrow • talk 19:33, 20 October 2023 (UTC)

  Yes, we do. It helps significantly to establish the pros and cons of emoji redirects before discussing them, as currently there's a lot of talking past one another going on in these RfDs. J947 † ^edits 23:29, 20 October 2023 (UTC)

  Okay, but this is a pain to follow. Procedural restart, in the section immediately below. I am going to list on WP:RFCL because I am not sure if this makes me involved or not. Note that this is entirely procedural, not reflective of my opinions here. Awesome Aasim 23:19, 30 October 2023 (UTC)

  Awesome Aasim, the RfC has already been semi-closed (the RfC tag has been removed), so there's no need for formal closure. Edward-Woodrow • talk 23:34, 30 October 2023 (UTC)

• Option 1 - although I agree with the above editors that this RfC needs to be restarted, as the options have changed since many editors !voted. I prefer option 1 as no emoji is unambiguous; for example, 🔥 can mean fire, but it can also mean spicy, attractive, popular or trending, urgency, excellent performance, and far more. Effectively, emoji's are a pictograph language where context provides meaning; it is rare that there is a single appropriate target for them. BilledMammal (talk) 03:29, 21 October 2023 (UTC)

  What do you think of emoji redirects to country flag articles like 🇺🇸? They're surely unambiguous, right? ObserveOwl (chit-chat • my doings) 18:59, 25 October 2023 (UTC)

  Should 🇺🇸 target U.S. or U.S. Flag? I'd expect the former, but the norm seems to be the latter. Edward-Woodrow • talk 19:43, 25 October 2023 (UTC)

  If I used an emoji to search with I'd be looking for information about the emoji. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:03, 28 October 2023 (UTC)

  I'd usually want to know what on earth the blob with a squiggle that I just copy-pasted is supposed to represent, though there are dedicated sites for that. Certes (talk) 21:27, 28 October 2023 (UTC)

• Option 3 If we can give a straightforward answer, let's do it. Otherwise, we're just playing charades. --BDD (talk) 18:31, 25 October 2023 (UTC)
• Option 8 per Thryduulf.-- Patar knight - ^chat/_{contributions} 15:43, 27 October 2023 (UTC)
• Thryduulf's option 8 makes the most sense here; those options are the most likely to send our readers to the information they're looking for when searching an emoji. I'd also be open to keeping some wiktionary redirects, such as 🥺 (which has been discussed at RfD, leading to that result). Elli (talk | contribs) 17:24, 27 October 2023 (UTC)

Discussion (Emoji redirects)

Notifying @Edward-Woodrow:, @Lenticel:, @Gonnym:, @Thryduulf:, @Tavix:, @Enix150:, @Illusion Flame:, @MicrobiologyMarcus:, @Yoblyblob:, @TartarTorte:, @Hey man im josh:, @Qwerfjkl:, @Ivanvector:, @Polyamorph:, @Rosguill:, @A smart kitten:, @Pppery:, @ClydeFranklin:, @BDD:, whom have weighed in on one of the currently ongoing emoji redirect discussions. Utopes _{(talk / cont)} 03:15, 16 October 2023 (UTC)

@Utopes: I'm not sure the options are set up optimally. It should be completely uncontroversial that emojis with articles should target those articles, such as Face with Tears of Joy emoji, no matter which option we choose for the rest. Then we have four options for emojis without articles: a) redirect all to Unicode block (same as your 1 & 2); b) redirect to unambiguous subjects, else default to Unicode block (same as your 3); c) redirect to unambiguous subjects, else delete (same as your 4); d) delete all. -- King of ♥ ♦ ♣ ♠ 03:21, 16 October 2023 (UTC)

@King of Hearts: I think you're probably right in the sense that a delete-all option would be a beneficial "nuclear option", so I will go ahead and add that. With that out of the way, in that case, would your suggestion be to remove Option 1 or 2 and shift everything else up? My reasoning for including a difference between #1 and #2 was to have an option that was close to nuclear while allowing some valid exceptions, i.e. "emoji redirects are only valid to articles about emoji". I think this differs from Option 1, which I felt would be the standard nuclear option that is directly opposite of mass-deletion, using the stance that "emojis shouldn't ever be redirects to topic articles, and should only ever target lists of symbols (because emoji are symbols)".

If you think its too uncontroversial, I'll strike it out, but wanted to make sure I was understanding your thought process first. Utopes _{(talk / cont)} 04:19, 16 October 2023 (UTC)

@Utopes: I think there are way too many options now, which just makes it more confusing. And the problem is that outside of Options 2 and 5, it is unclear what is being proposed for emoji redirects to direct targets. Instead there are two orthogonal questions: 1) If there is an article on an emoji (as the subject of the article), should the emoji redirect to that article? (Note that this question does not ask what to do if the answer is no. I assumed the answer here is obviously yes, but maybe it's not so obvious and it doesn't hurt to ask.) 2) For all emoji redirects that have not been explicitly allowed under the previous question, what should be the criteria for inclusion? (Here we have my four previously proposed options.) -- King of ♥ ♦ ♣ ♠ 08:31, 16 October 2023 (UTC)

I see what you mean. I think the current option setup made a bit more sense in my head than in practice. I viewed there to be three different "priorities" that emoji redirects could have. They could be treated as "symbols" and symbols only, they could be treated as the image they depict, or they could not be dealt with at all (and deleted). In other words, a "Yes", a "Yes, AND", and a "No". In general, I feel like 6 options is likely the "maximum" number to be able to wrap around (especially if its fundamentally a 3x2), although it also depends on the options themselves. Option 1 and 6 might have been too extreme of choices by ignoring obvious alternatives to mass-deletion/redirection, and unnecessarily add complexity because of it, so I'll take your advice and re-contextualize the solutions. Utopes _{(talk / cont)} 16:28, 16 October 2023 (UTC)

• Could lists in addition to Miscellaneous Symbols and Pictographs be provided for reference? That list doesn't seem to have any of the emojis that were subject to rfds listed. CMD (talk) 03:39, 16 October 2023 (UTC)

•  Done Utopes _{(talk / cont)} 04:26, 16 October 2023 (UTC)

fwiw, I don't think I received this ping, not sure anyone else did. _signed, Rosguill ^talk 13:48, 16 October 2023 (UTC)

No, pings only work when they are signed in the same edit. The ping edit was not signed. -- Tavix ^(talk) 14:38, 16 October 2023 (UTC)

Huh, I didn't realize that the ping's functionality depended on a signature; I put the ping-list together after setting things up to alert people that it's live. At this rate, I'm not sure whether it would be worth it to re-send the pings though. Utopes _{(talk / cont)} 15:46, 16 October 2023 (UTC)

At this point it can't hurt. Notifying @Edward-Woodrow:, @Lenticel:, @Gonnym:, @Thryduulf:, @Tavix:, @Enix150:, @Illusion Flame:, @MicrobiologyMarcus:, @Yoblyblob:, @TartarTorte:, @Hey man im josh:, @Qwerfjkl:, @Ivanvector:, @Polyamorph:, @Rosguill:, @A smart kitten:, @Pppery:, @ClydeFranklin:, @BDD:. Edward-Woodrow • talk 19:57, 16 October 2023 (UTC)

• Comment I don't particularly see much encyclopaedic value of using emojis to navigate wikipedia. The best scenario in my mind would be to redirect either to an article on that specific emoji or to a general article on emojis. We should not be using emojis to redirect to articles that don't relate to emojis. Polyamorph (talk) 20:39, 16 October 2023 (UTC)
• What are people referring to numbered choices that are not on the list, such as "Option 8"? –LaundryPizza03 (dc̄) 13:31, 17 October 2023 (UTC)

  The higher numbered options were introduced during #Survey (Emoji redirects) and are explained there. Certes (talk) 14:17, 17 October 2023 (UTC)

  @LaundryPizza03 the RFC question originally had 6 options. Kusma and I preferred options that were not on that list, and so detailed them as options 7 and 8 respectively. The RFC question was then rewritten with 4 options replacing the original 6, but options 7 and 8 are still not covered. For easier reference I've copied those options below:

  • Option 7: do not try to prescribe this centrally, but let RFD do its thing on individual redirects based on individual consensus. Do not mass-create, do not mass-delete.'
  • Option 8: Emojis with articles should target those articles, other emoji with meanings that clearly correspond to one article should target that article. Emojis with meanings that correspond to multiple articles should target a list, disambiguation page, set index or other place where readers can follow links to the article(s) relevant to their search. Other emojis should redirect to relevant lists of symbols. Emoji should be redlinks only when we want to encourage the creation of an article about that emoji and/or its meaning.

  Thryduulf (talk) 14:26, 17 October 2023 (UTC)

Comment I think this has completely spiraled as a result of the numbers changing and I'm not sure what information we can glean from the current state of the RfC. microbiologyMarcus ^{(petri dish)} 13:45, 18 October 2023 (UTC)

Support closing the RfC and workshopping a second one here. Edward-Woodrow • talk 19:37, 18 October 2023 (UTC)

Some1 I like the idea of a list of emojis, as a middle ground between targeting the literal meaning and targeting the block. That would also give us room to note different meanings (at least those that reliable sources discuss). Here's my vague idea for what an entry would look like:

😨 Fearful Face (U+1F628) used to x or sometimes y.

Edward-Woodrow • talk 21:30, 17 October 2023 (UTC)

@Tavix, Gonnym, Thryduulf, Enix150, and Utopes: what do you think of that idea? Edward-Woodrow • talk 21:31, 17 October 2023 (UTC)

There are 3,664 emojis as of the latest update so if such a list would be created, it would probably be needed to split into a few pages, but in general I'm not opposed to anything that can make the target more clear. Gonnym (talk) 08:37, 18 October 2023 (UTC)

I agree with Gonnym. It should have a link to the relevant Wikipedia article, so perhaps something like:

😨 Fearful Face (U+1F628) see Fear.

The link should be to the article(s)/dab/etc that most closely matches the definition, unless we have reliable sourcing that it is used for some other/additional meaning (otherwise it's WP:OR). Thryduulf (talk) 09:57, 18 October 2023 (UTC)

Here is an initial attempt Draft:List of emojis (faces). Gonnym (talk) 10:59, 18 October 2023 (UTC)

@Gonnym, that looks good to me, though it might be worth adding images as well. I'm seeing boxes for a few of them. — Qwerfjkltalk 19:43, 21 October 2023 (UTC)

I like this, but is there any reason we can't do this out of the previous emoji block articles (just adjust their format)? Skarmory (talk • contribs) 21:17, 23 October 2023 (UTC)

At this point I think it's probably best to wait until the new version is completed and then propose a merge or redirect. Thryduulf (talk) 21:52, 23 October 2023 (UTC)

• Comment This is listed on CENT, so I have come here from there. What the heck is going on with the options? Who hatted a bunch of them and completely re-numbered the rest halfway through an RfC? It is now basically impossible to tell what anyone was talking about in the above comments. Can this be undone? jp×g 05:20, 18 October 2023 (UTC)

  @JPxG the who was Utopes. As for whether this can be undone, I think that would just move the problem to the comments left between the renumbering and the unrenumbering. Especially now we have a third option not listed in the options it's probably better to cancel the RFC bit of this but treat it as pre-discussion for a better prepared RFC. Thryduulf (talk) 10:00, 18 October 2023 (UTC)

  I agree this RfC is damaged beyond repair. Jc3s5h (talk) 20:14, 20 October 2023 (UTC)

  Well, it's de-RfC'd now, so maybe we can discuss the issues raised, instead of my, isn't this RfC bad?' Edward-Woodrow • talk 20:19, 20 October 2023 (UTC)

• Per the above comments, I've removed the RfC tag. The discussion can stand or continue as a pre-RfC discussion, where participants workshop the best possible options for further discussion. The mid-RfC changes to the options have made it untenable. Firefangledfeathers (talk / contribs) 20:03, 20 October 2023 (UTC)

Would blanket redirect of all emojis to a table with anchors to the specific emoji and then the descriptions, with interwiki links not be the best use case then? I've begun workshopping a draft in the draftspace: Draft:List of Emojis microbiologyMarcus ^{(petri dish)} 15:16, 26 October 2023 (UTC)

I would probably support Option 2-prime Redirect to list of ... meanings. Compare A, X, 7, !, Æ. Some emoji only have one notable, natural meaning; others might have a "literal" meaning and multiple notable figurative meanings; in the latter case, yes there should be a disambiguation page. And if there's a group of closely-related emoji with similar meanings and history, it might be appropriate for each to be a redirect to an anchor-within-a-table within an article about the group. DavidLeeLambert (talk) 21:07, 26 October 2023 (UTC)

I really like the way Wiktionary (you know, the project where glyphs-as-glyphs are in-scope) handles these. Compare wikt:🥙, wikt:🤾, wikt:🔴. —Cryptic 22:27, 26 October 2023 (UTC)

Two of those currently don't have entries, but, yes, I agree I like wiktionary's approach (they're freer because unlike us, they are a dictionary). An option is to retarget them all to wiktionary (which been done with a few already, I think). Edward-Woodrow • talk 12:01, 27 October 2023 (UTC)

Part of my point is I like the way Wiktionary handles them even when it doesn't have entries - for one-character-long entries in their main namespace, they transclude wikt:Template:character info on wikt:Mediawiki:Noarticletext. —Cryptic 04:14, 28 October 2023 (UTC)

Follow-up commentary

We should probably address this sort of thing in a policy or guideline somewhere, probably in WP:NOT. There are lots and lots of petitions on Change.org (and probably at similar sites) about Wikipedia, almost all of them aimed at pushing a particular PoV agenda. So this kind of idea will probably come up again.

In this specific case ("/p/high-ranked-wikipedia-contributers-curly-quotation-marks-in-english-wikipedia" at Change.org – cannot be linked directly because of our URL blacklist), the "petition" has almost no input even for a Wikipedia-related petition (a truly trivial 159 "votes"). But some of them are much larger. These petitions are basically nonsense. Wikipedia pays no attention to them at all, and we should not, because there is no way to connect votes to users-in-good-standing of Wikipedia, nor connect a single vote to a single user even of just Change.org. And the petitions are of course non-neutral in nature unlike our RfCs (valid ones, anyway), and show only support for an idea not opposition to it. E.g., there is one to try to get Wikipedia to treat ayurveda as real medical science instead of pseudoscience ("/p/wikipedia-we-are-against-wikipedia-s-statement-which-says-ayurveda-is-pseudo-scientific" at Change.org). It has 33,600+ "signatures" (probably broadly canvassed through campaigning, since there are millions of petitions on Change.org and one would not find this buried item by accident). But untold numbers of people would disagree with it, and there is no measurment of them.

It's just meaningless noise, and we don't need to entertain it or have to respond to it with anything but something like "Hatted/reverted per WP:NOT#PETITION."  — SMcCandlish ☏ ¢ 😼  11:54, 2 November 2023 (UTC)

Can't we just cite WP:NOTDEMOCRACY? It would appear to be applicable to these and would save us from having to add more content to that page. BilledMammal (talk) 11:56, 2 November 2023 (UTC)

I added something there.[10] See what you think? Bon courage (talk) 12:07, 2 November 2023 (UTC)

WP:NOT#DEMOCRACY is certainly where I would put it, and Bon courage's edit above is just right to me, though someone may revert it for lack of prior discussion, and necessitate a thread about it at WP:NOT.  — SMcCandlish ☏ ¢ 😼  12:22, 2 November 2023 (UTC)

Yeah, I sometimes wish WP:DRNC was part of the WP:PAGs, because ... it's right! Bon courage (talk) 12:28, 2 November 2023 (UTC)

Also agree with this edit. FOARP (talk) 06:10, 3 November 2023 (UTC)

SMcCandlish, Yeah, seems worth a hatnote to say "if you want to talk about changing Wikipedia, don't do it elsewhere, do it on Wikipedia, as is the point of Wikipedia — Remsense聊 12:11, 2 November 2023 (UTC)

Bon courage's tweak linked above probably gets at the issue.  — SMcCandlish ☏ ¢ 😼  12:22, 2 November 2023 (UTC)

Is there a way we can make talk pages automatically display certain banners at the top? For instance, ((Talk header)) for basically all pages, ((American English)) for articles with a ((Use American English)) tag, ((Talk page of redirect)) for redirects, and ((WikiProject Disambiguation)) for DAB pages. Systematic edits like this one often make me wonder: why are editors needlessly triggering others' watchlists through unnecessary but harmless mass edits, and why are these editors only bothering to add the banners to a few pages when many other pages do not have these templates? If we're going to add these templates to a few pages, might as well do it to all of them and without disruption. InfiniteNexus (talk) 05:06, 6 November 2023 (UTC)

I believe that automatically including comments and templates in new talk pages is a good idea, but that automatically adding them to existing talk pages is a bad idea. As as compromise, perhaps facilitate adding them during the next edit, if any, subject to confirmation . -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:47, 6 November 2023 (UTC)

We don't need to clutter up talk pages with e.g. ((American English)) which isn't really needed on most talk pages. Talk pages already have too many banners usually (which causes banner blindness) Galobtter (talk) 23:07, 6 November 2023 (UTC)

I agree in principle, and I have never added that template to talk pages myself. But the template exists, and time and again I see editors add it to random talk page. I have no grounds to revert them, since there's no harm per se, but it's an unnecessary edit. Same goes with the other templates I listed — there is no positive or negative from adding them, but people do it anyway, and it just triggers people's watchlists for no reason. I am doubtful that editors will agree to mass-delete those templates, hence this proposal (if it is at all feasible). InfiniteNexus (talk) 23:17, 6 November 2023 (UTC)

There's an extension in testing, not yet enabled here, that'll let us do this. —Cryptic 23:42, 6 November 2023 (UTC)

Given that there is a possibility that mention of modern nations in the context of historical figures is an anachronism, as far as I know from my editorial experience this is not acceptable in articles given that time context in which a person lived must be used. I think there should be a rule that will solve this question. This same rule should determine the guidelines in which it must be proven that some information is anachronism. While the second part of the rules would determine what is done in such cases. Considering that without this rule we have uneven articles, I think that this rule is inevitable and necessary. The same rule will apply to all cases of anachronism in articles. I think that debating some things for 20 years does not make sense, it is better to adopt a new rule that will make the work of editors easier.

I am asking interested editors are you in favor of adopting a new rule which will concern the problem of anachronism in the articles? If necessary, I will write a new rule myself and put it up for discussion.

Mikola22 (talk) 08:20, 27 October 2023 (UTC)

I might be sleepy, but I don't understand what exactly is being proposed here. We shouldn't have anachronisms in articles? We have to provide a source when removing anachronisms? We should have anachronisms when they help the general reader understand a topic in a specific historical context that is not well understood by non-specialists? Folly Mox (talk) 11:08, 27 October 2023 (UTC)

Wikipedians argue indefinitely about a lot of things, it's kind of our thing. I don't think we can come up with a blanket rule on how to deal with anachronisms. For example, the vast majority of articles on archaeological sites describe them as being located in a modern country, which is technically anachronistic, but it wouldn't be very helpful for readers to learn that Nibru was a city in Kengir. It needs to be decided with on a case by case basis, following the lead of reliable sources. – Joe (talk) 12:21, 27 October 2023 (UTC)

@Folly Mox and Joe Roe: There is no rule on Wikipedia regarding information which are out of time context. Let's say a certain historian from Rome and the Roman Empire is presented as an Italian in the article. And now for 20 years there has been a debate whether he was Italian or Roman. I think that in such case it would be good to have a rule or guideline that we can refer to, so that the article contains information in accordance with the sources and time context. Furthermore, we now have a situation where the time context is respected in some articles and not in others. The situation is anarchic in this regard. If something else needs to be clarified, feel free to ask. @Joe Roe In any case, everything depends on the sources, if 5 RS says that a person from the first century is Roman and 5 RS says that he is Italian, we won't going to debate for 20 years about who he was? If something is an anachronism and this is determined by the opinion of editor majority, then we cannot keep this information in the article. For now, such informations are legitimate because there is no guideline that would regulate this situation. Mikola22 (talk) 12:58, 27 October 2023 (UTC)

Even if there was agreement on whether any particular item is an anachronism, it would be extremely difficult to write guideline or policy that encompasses all topics in a way that captured the many possible nuances out there. Suggesting that an editor majority overrules reliable sources is even more unlikely to be a solid basis for policy. Nationality is a particularly tricky topic, MOS:NATIONALITY has some existing guidelines. CMD (talk) 13:57, 27 October 2023 (UTC)

Regarding 'editor majority overrules', I meant in the sense that guideline or policy which concerns anachronism exist. If that guideline or policy defines anachronism as forbidden, it would be sufficient that some RFC establish that some information is anachronism, and such information would gain legitimacy for removing from the article. Mikola22 (talk) 18:13, 27 October 2023 (UTC)

I think I understand the proposition now, but I'm not sure I would support it. For one thing, it shouldn't take an RFC to determine if something is anachronistic. A reliable source should suffice, although I accept there may be edge cases where published experts disagree. The other thing is that anachronism can be helpful to anchor understanding in a familiar context, as Joe Roe mentions, and as is also common in my topic area, early China, where toponyms are almost universally located with respect to present-day geography, names are written in modern Chinese characters, etc.

Whether a particular instance of anachronism is helpful enough or necessary enough to be present in an article, and whether it needs to be called out as anachronistic and where: these are questions that RfCs can answer, but usually only after normal editing and normal discussion, I feel. Folly Mox (talk) 20:19, 27 October 2023 (UTC)

I always look at the RFC in which the arguments must be consistent with the sources. And in that sense anachronism would be determined on the basis of sources in which would be written that some information is not in accordance with the time context. I know from Christopher Columbus sources where one RS states that Christopher Columbus is not Italian because Italy did not exist at that time. But in the article he is presented as Italian although there are many sources which talk about him as a Genovese. So this information are not enough by itself to remove anachronistic name Italian from the article. But if there was a rule which determines this question, the Italian fact would be replaced tomorrow. It wouldn't even need RFC in a wider sense. This rule can also regulate question of old toponyms etc in a manner that is acceptable for today's time. Some information can also be excluded, etc. Mikola22 (talk) 03:52, 28 October 2023 (UTC)

Huh? What source states he was not Italian? Walrasiad (talk) 06:17, 28 October 2023 (UTC)

Christopher Columbus by Ernle Bradford, first page[11] Mikola22 (talk) 06:23, 28 October 2023 (UTC)

It doesn't say Columbus was not Italian. It uses some rather careless wording to emphasize that individual loyalties may be parochial. But Italy existed. Indeed, Genoa was a fief of the Kingdom of Italy. Walrasiad (talk) 06:36, 28 October 2023 (UTC)

He uses wording in the context of anachronism. However, this is not the issue we are dealing with here, so it is not really important. Mikola22 (talk) 07:31, 28 October 2023 (UTC)

It illustrates that editors have different interpretations of sources, and what is or is not anachronistic, and how different terms are used in different contexts. That's what talk page discussions are for. Walrasiad (talk) 14:46, 28 October 2023 (UTC)

That's a 50-year-old book. Levivich (talk) 20:36, 28 October 2023 (UTC)

As I pointed out in Wikipedia talk:Manual of Style/Biography#Ethnicity, one issue is that a false apparent consensus among sources can occur. Italy is a good one to look at. A hypothetical book like Most Significant Italian Inventions or Great Italian Women in History might refer to people as "Italian" because they are mentioned only in passing, even if a book about them specifically or that mentioned them in detail would describe the people as "Tuscan" or "Venetian" or "Genoese" or "Roman" or etc. I think we should roughly follow the majority of sources, but not in any given case where someone presents 20 sources for "Italian" and 10 sources for "Tuscan". If the person was born and grew up in the Duchy of Tuscany or the March of Tuscany we should prefer such a label even if most of the sources selected in any given survey use a more generic term if it is because they have a more generic treatment. To me it is more of a WP:SKYBLUE observation in that case. WP:VERIFIABILITY demands that a fact stated be verifiable, but not how we interpret generic vs. specific sources. This is all hypothetical here but we can get into individual examples if that helps. My two cents. —DIYeditor (talk) 11:16, 31 October 2023 (UTC)

For your example, that's not really an issue unless you do some serious accidental WP:SYNTH, whereby 1) you think those sources not about the history of Italy are trying to say something about the history of Italy, and 2) you don't have robust sources about said history where they belong, to which you can point to about the geopolitical situation. Remsense聊 20:31, 31 October 2023 (UTC)

• No need for a “rule”… we already have procedures for disputes like this - as with any content concern, raise the anachronism on the article talk page, discuss, examine what the sources say, try to reach consensus. If that proves difficult, call in non-involved editors and if necessary hold an RFC. Blueboar (talk) 20:28, 31 October 2023 (UTC)

Maybe I should have replied about a week ago, before other editors mostly agreed with what I was thinking of writing. In my opinion, this page is the wrong forum for what seems to be a partially baked idea, which should be discussed and possibly clarified in the Idea Lab. The OP isn't specifying what they want to do about "anachronism", and so I don't consider this to be a "proposal". Robert McClenon (talk) 02:45, 7 November 2023 (UTC)

The other problem with this partially baked idea is that some editors disagree strongly with the cases that appear to be the main concerns of the OP, which are persons born on the Italian peninsula between 476 AD and 1860 AD. The Italian peninsula was a known geographic region during and after the Roman Empire, so Marco Polo and Christopher Columbus were Italian, as well as being Venetian and Genoese, respectively.

We can either leave this idea alone to be ignored, or start a discussion at the Idea Lab. The former option is fine with me. Robert McClenon (talk) 02:45, 7 November 2023 (UTC)

Communication is crucial in society in general and Wikipedia in particular as an essential part of the editing and consensus process. As such I was thinking it would be a good idea to have an Editor Communication Feedback noticeboard. Therefore, I propose creating it to promote good communication between editors. Currently there is no place to discuss communication between editors, except as a disciplinary issue. I am aware there used to be a Requests for comment/User conduct project but my proposal is diametrically different and addresses the main points of contention of that former venue.

From the discussion to discontinue said RfC/Uc,

The community is of the opinion that it no longer serves a useful purpose, that it has a tendency to prolong disputes without helping their resolution, suffers from a lack of participation, attracts biased input, and that it pales in comparison to other processes. There is no consensus for any specific replacement, nor that finding one is required before deprecating RFC/U. Other components of the dispute resolution process should be used, such as ANI and ArbCom. There are some legitimate concerns regarding those alternatives, specifically that ANI isn't well equipped to handle long term issues while at the same time the bar for ArbCom is quite high, meaning a lack of proper venue for handling certain kind of disputes, but they don't justify maintaining a system recognized as inefficient (in those cases too).

The noticeboard would be for constructive and positive feedback, neither as an instrument to impose sanctions, nor to further disputes, nor to condemn.

1. The purpose of the noticeboard would be to promote (not enforce) good communication between editors.
2. The objective of the discussions would be to provide neutral feedback to editors on how to improve communication, what could have been done better in the thread being analyzed, what could have been avoided, what strategies could be used in the future.
3. The noticeboard should not be used for negative actions against editors such as evidence in disciplinary proceedings.
4. Some rules,
   1. Provide respectful and constructive feedback, avoiding attacks or condemnation.
   2. Limit participation in the analysis discussions to extended confirmed editors.
   3. Barring from the discussion analysis participation of editors involved in the dispute wouldn't participate in the discussion. Any doubts about the motives or objectives of their communications would have to be figured out by those participating in the discussion because after all if they can't figure it out, that signals there was a communication roadblock.
   4. Barring from the discussion analysis editors who have had disputes or edit warring with the editors whose thread is being analyzed would be restricted from participating in the discussion.
   5. Restricting editors who may act as proxies of editors who have had disputes with the editors whose thread is being analyzed advising them not to participate in the discussion.
   6. Participating editors should avoid taking any given disputing editor side.

Thinker78 (talk) 19:48, 22 October 2023 (UTC) Edited 22:03, 22 October 2023 (UTC)

Pinging @Cenarium, Robert McClenon, and Jehochman:, main participants of the former RfC about the User Conduct forum. Thinker78 (talk) 19:51, 22 October 2023 (UTC)

Rules 4.3, 4.4, and 4.5 do not parse.

If rule 4.5 is interpreted as forbidding proxying for another editor, it may do more harm than good, if it allows editor C to claim that editor B is proxying for editor A.

More generally, if rules 4.3, 4.4, and 4.5 all exclude editors, the result may be that there may be as much quarreling over whether editors are excluded as discussion of the original topic. Robert McClenon (talk) 20:50, 22 October 2023 (UTC)

Rule 4.3 has littler room for misinterpretation or different interpretation. Rule 4.4 could be instead barring in the discussion editors who have had edit summary or talk page interactions with the editors in dispute, so as to reduce the risk of disputes in the interpretation. Rule 4.5 would advise proxy editors from intervening but that would be a honors system because difficult to establish who may want to proxy. Then as long as rules 1 and 6 are respected, there would be less risk of an issue even if they are secretly proxying for the interests of other editors.

Although of course, no system is perfect. Regards, Thinker78 (talk) 22:14, 22 October 2023 (UTC)

It is true that there seems to be only one interpretation of what 4.3 is trying to say. It still doesn't parse. Robert McClenon (talk) 03:44, 23 October 2023 (UTC)

A key challenge with the former requests for comments on user conduct process was that there was no incentive for the user in question to read any of it. I'm not clear how your proposal addresses this. With your proposed rule 3, the incentive is also reduced for participation by anyone if it means that either poor behaviour on the proposed noticeboard cannot be discussed in other venues, or if specific poor behaviour discussed on the proposed noticeboard cannot be discussed in other venues. isaacl (talk) 23:39, 22 October 2023 (UTC)

1. "there was no incentive for the user in question to read any of it". The WP:Dispute resolution noticeboard also has the same issue. In fact, it states, "You are not required to participate". The proposal is to promote good communication. Certainly not everyone would want to read the analysis but certainly many others may. It would be one more tool for those editors in the dispute resolution process and also those interested in improving or seek feedback in their communication.
2. "poor behavior on the proposed noticeboard cannot be discussed in other venues". Rule 3 doesn't state this, it is about the threads themselves of the noticeboard not being used in disciplinary proceedings. The behavior of course can be discussed wherever.

Regards, Thinker78 (talk) 00:29, 23 October 2023 (UTC)

Without addressing how to provide incentives for the user to engage, I do not feel you have addressed a main point of contention with the RfC/U process.

If someone lays out poor behaviour X, Y, and Z in a thread on the proposed noticeboard, then someone later raises these behaviours at the incidents' noticeboard, the subject can claim via rule 3 that since the behaviour was already discussed, no sanctions should be given. This is a disincentive for others to use the noticeboard, which will reduce its effectiveness. isaacl (talk) 04:03, 23 October 2023 (UTC)

"Poor behaviour" would be addressed by newly minted rule 7: Include about the issue a brief, neutral statement or question. Therefore, poor behavior wouldn't be accepted as a neutral statement or question about the issue.

Should rule 3 be discarded? Regards, Thinker78 (talk) 04:38, 23 October 2023 (UTC)

Discussing what could have been done better in the thread being analyzed, what could have been avoided will result in discussing undesirable behaviour. isaacl (talk) 18:34, 26 October 2023 (UTC)

That's one of the objectives, with the aim to improve communication between editors. Regards, Thinker78 (talk) 22:18, 26 October 2023 (UTC)

Exactly; thus your proposed rule 7 is a non-sequitur to the concern I raised. isaacl (talk) 22:49, 26 October 2023 (UTC)

No because although the editors in the noticeboard would discuss communication issues that may include undesirable behavior, it doesn't mean that they should state it is undesirable behavior or that editors should refer to the case as undesirable behavior. Check also rules 2 and 4.1. Regards, Thinker78 (talk) 22:57, 26 October 2023 (UTC)

Yes, I quoted rule 2. Discussing what could have been done better in the thread being analyzed, what could have been avoided is equivalent to discussing behaviour that is undesirable, as it should have been avoided and could be improved. A basic tenet of providing effective feedback is to identify the concern. isaacl (talk) 23:10, 26 October 2023 (UTC)

Yes but it is not necessary to state that it is undesirable behavior. It should be stated in neutral or positive terms for constructive criticism what could have been done better or how it could be better. After all, behavior that is undesirable for some is desirable for others. Regards, Thinker78 (talk) 02:23, 27 October 2023 (UTC)

Proposed rule 3 doesn't rely on whether or not something is called undesirable behaviour; it bars use of any of the discussion no matter how it's worded. That's why proposed rule 7 isn't relevant to my concern.

Regarding constructive criticism: saying a behaviour should be avoided is equivalent to saying (in the speaker's view) that it is undesirable. Clearly describing problematic behaviour can still be constructive, with the commenter providing clear reasoning, and ideally based on common agreed-upon principles. isaacl (talk) 04:01, 27 October 2023 (UTC)

Should rule 3 be discarded? Regards, Thinker78 (talk) 04:34, 27 October 2023 (UTC)

• One of the problems with RFC/U was that it was "a process laden with bureaucratic nonsense" (as one commenter put it in the linked RfC). This too seems to have a lot of WP:BURO which will invite wikilawyering and need clerking/policing. I'm also confused what its purpose is meant to be: a friendly space for a chat? or somewhere to bring a specific ongoing "dispute" or "issue" as referred to later in the rules? Bon courage (talk) 05:19, 23 October 2023 (UTC)

  I have noticed that oftentimes in talk pages there are storms of disputes where communication could be better. I think this noticeboard could help sort out such situations without resorting to ANI or the Committee and help provide feedback to editors seeking to improve their communication skills with fellow editors. Regards, Thinker78 (talk) 18:46, 23 October 2023 (UTC)

  Also, the idea is to have a forum that is a mix or could mirror somewhat RFC, Third Opinion, and the dispute resolution noticeboard or other noticeboards, but for analysis of cases of communication between editors. Regards, Thinker78 (talk) 18:59, 23 October 2023 (UTC)

  Sounds fanciful. Anyway to enforce your rules you'd need clerks to do things like making sure 'barred' editors were barred, and so on, and you'd need completely uninvolved editors willing to comment. God only know what sort of people would be attracted to that task! Perhaps you could point at two or three of these 'storms of disputes' where you think this proposal would help? Bon courage (talk) 19:08, 23 October 2023 (UTC)

  I think any experienced editor who has participated in discussions knows by personal experience about what can happen in discussions and how they can become very stormy. Regards, Thinker78 (talk) 20:10, 23 October 2023 (UTC)

  But I don't know what you mean by 'stormy' exactly. If editors are telling each other to fuck off, that's one thing; but do you include robust exchanges? Many editors mis-construe robust argumentation about propositions as being personal. What do you mean by stormy? Where is the line crossed? Examples please! Bon courage (talk) 06:33, 24 October 2023 (UTC)

  Editors would be free to submit threads in which they were involved for review even if there was no dispute but the editor simply wants feedback about hisher communication. Regards, Thinker78 (talk) 21:14, 24 October 2023 (UTC)

  Above you wrote "this noticeboard could help sort out such situations". What "situations"? Is this a problem that actually exists? Can you point to some (hell, even one) and sketch a "before and after" where this noticeboard does the sorting out you mention? Bon courage (talk) 01:50, 25 October 2023 (UTC)

  "storms of disputes where communication could be better." Thinker78 (talk) 03:04, 25 October 2023 (UTC)

  Okay, the question is being evaded. Can somebody close this waste of time? Bon courage (talk) 03:10, 25 October 2023 (UTC)

  There is your example. Also, it illustrates the point of rule 4.4 "Barring from the discussion editors who have had disputes or edit warring with the editors whose thread is being analyzed". We had a dispute some time ago. Regards, Thinker78 (talk) 04:16, 25 October 2023 (UTC)

I can't picture how this would work in practice. If parties are snarking at each other, and someone steps in to criticise their communication skills, is that really going to mollify them? I have a feeling it would just open up a new frontier in the dispute, probably moving the discussion even further away from content. Barnards.tar.gz (talk) 20:58, 23 October 2023 (UTC)

That would ring true about any other noticeboard though. Besides, the Feedback noticeboard would analyze a discussion only if editor (s) involved in the discussion brings the case (although they would not participate in the discussion). Regards, Thinker78 (talk) 22:14, 23 October 2023 (UTC)

• I'm not sure what benefit there is to a forum where people who were not involved in a contentious discussion then discuss that discussion; a person with poor communication skills is not going to improve by being scolded on the internet. I think a better solution is to have some sort of peer mediator program, but even that isn't a replacement for touching grass or going to a therapist instead of getting heated and nasty over an edit dispute. voorts (talk/contributions) 00:33, 26 October 2023 (UTC)

  The noticeboard wouldn't be for "scolding", but to provide impartial analysis using positive feedback. Or at least that's the idea. Although I recognize some people get nasty because of their particular life issues, in other situations editors may be nasty in a discussion but later snap out of it and sincerely want to check what went wrong. Also, there are other situations where editors might simply seek feedback even if there was no particular nastiness. Regards, Thinker78 (talk) 00:49, 26 October 2023 (UTC)

• I suspect we have too many user-behavior noticeboards. AN, ANI, and WP:XRV come to mind. It may make sense to move in the direction of consolidating them towards ANI, rather than creating new ones. –Novem Linguae (talk) 01:57, 26 October 2023 (UTC)

  I think AN and ANI are more suitable for complaints than for general feedback. Also, they dissuade participation with boomerangs. Regards, Thinker78 (talk) 05:55, 7 November 2023 (UTC)

There is an ongoing discussion about the future of B-class checklists and the possibility of dropping them. Please comment there if you have any input — Martin (MSGJ · talk) 12:25, 7 November 2023 (UTC)

Hi, folks. Any thoughts on adding 3D models to infoboxes where available, such as Statue of Liberty, The Thinker, and so on? I feel that this would be a good action, as most typically plain images are used as the main image in infoboxes, but models can also contribute greatly to one's understanding of such a subject as a specific building, sculpture, or otherwise three-dimensional object. However, it has been argued by User:Randy Kryn (who I must apologise to for mentioning a second time now) that this is intrudes upon the rest of the page, particularly on articles with large infoboxes. I can also see the reasoning for this, and I do agree that readability is a matter of utmost importance.

Given the number of articles across various topics which would involve such a thing, but the fact that this isn't quite at a RfC level nor a WP:DR type of dispute, I originally placed this at the Teahouse, before being recommended to move it here in order to get further input from editors. Thanks in advance for your inputs!

Mupper-san (talk) 05:46, 1 November 2023 (UTC)

Assuming you mean this 3D model for the Statue of Liberty, then I would be strongly opposed to using it as the main image in the infobox, since it is a model, not a real representation of what one sees when looking at the statue, which a good photograph will convey. There may be a case for inclusion elsewhere in the article but that's a topic to be decided by consensus on the article's Talk Page. Mike Turnbull (talk) 11:37, 1 November 2023 (UTC)

I echo Mike Turnbull's thoughts. Most of the time an image is going to be a better choice than a 3D model in an infobox. Thanks! Nemov (talk) 12:03, 1 November 2023 (UTC)

If one wanted to put those in an infobox, I think it'd be better to create a parameter that just generates a link to it (e.g. |model=[[:File:Statue of Liberty.stl]] producing "3D Model [12] "). Even then, though, it might be better just to display it in a gallery later on in an article, since that way readers won't have to navigate to a completely separate page to see it. 2600:1012:B16F:B937:ADEF:7254:405D:8DF2 (talk) 19:43, 1 November 2023 (UTC) (Send talk messages here instead)

Oh, that's really cool, Mupper-san. If you click on the "3D" button, you can spin it around to see it at different angles.

I think this should be included, but I'm happy to have it in the gallery at the end, rather than in the infobox at the top. WhatamIdoing (talk) 19:49, 1 November 2023 (UTC)

I don't in principle oppose adding 3-D models to infoboxes (that might actually be very helpful for things like proteins), but I think it should be case-by-case and decided on an article's talk page. — Red-tailed hawk _(nest) 03:45, 8 November 2023 (UTC)

At the Statue of Liberty page, which has an already large infobox, the 3-D addition did not benefit the page. There, and probably almost everywhere else, the 3-D presentation may or may not be a good addition to the body of the article or in a gallery, but changing infobox protocol to allow inclusion of these images to any infobox seems unneeded and too open-ended. Randy Kryn (talk) 05:11, 8 November 2023 (UTC)

Any inclusion of 3D images in infoboxes should be a replacement to the 2D images (or hidden with a switcher as seems to be spreading), not in addition. The longer an infobox gets the more it disrupts formatting elsewhere in the article on desktops, and the longer mobile viewers have to scroll to get to most of the lead. CMD (talk) 05:52, 8 November 2023 (UTC)

(relatively) Recently, a category, autopopulated by MediaWiki, has been created that lists talk pages with comments before the first section. I propose a bot which, using AWB's WP:GENFIXES, will add a == Untitled == header above the comment(s). There are, however, three potential issues with this, those being intentional header exclusions, vandalism which should be removed, and multiple unheadered comments. For the first one, the bot will be exclusion compliant, the second one is an "oh well" which would be no different with or without this, and the third one is another "oh well" where a partial fix is better than no fix. The bot will run one-time until the category is empty, after which it will run occasionally to keep it empty. Note that BattyBot already does this when doing unrelated talk page issues. Thank you. — Clyde _{[trout needed]} 05:51, 7 November 2023 (UTC)

I am going to actively disagree; error reports are actually one of the best ways of catching certain types of vandalism from users (e.g. Special:Diff/1183662455 which was caught by CheckWiki's "Heading should end with "="" filter), which corresponds to issues #2 and #3 that you listed. So instead of being automatically incorporated into an article, errors like those (like talk page comments preceding other sections) should be logged, but otherwise left alone so another editor can visit them and figure out whether to incorporate, revert, or do something else to the offending edit--a decision no bot can intelligently make. 2603:8001:4542:28FB:498F:967B:D9D7:D85B (talk) 17:03, 7 November 2023 (UTC) (Please send talk messages here instead)

It's seems the majority of these are were the first comment doesn't have any section header. Maybe a one time bot run could clear up all comments not made in the last 18 months or so. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:54, 7 November 2023 (UTC)

I once spent awhile doing some gnoming on vital article banners that led to finding and fixing a number of instances of different types of vandalism that had been helpfully 'fixed' by a bot. From memory, examples included random deletions that deleted parts of banners and parts of text below, which if it removed headers created the of comments before the first section. The bot action here adding a header will not only make it harder to catch and fix those, but also might lead to the archiving of the remaining text sequesting the vandalism into the archives. While I expect most instances are simply old unheaded comments, I don't see the category as a problem requiring an active bot fix. CMD (talk) 01:54, 8 November 2023 (UTC)

On the third potential issue mentioned, I just had a look at Talk:4×4=12 (oldid:[13]). This was three completely unrelated comments in reverse chronological order, and adding a header might to more to hide that then to solve it. CMD (talk) 06:37, 8 November 2023 (UTC)

rfc policy tech The ((Find general sources)) template produces this list of search options: "Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL". Should we change the items in the list? If yes, then what changes should be made? Boud (talk) 12:52, 25 November 2023 (UTC)

Please withdraw this RfC, the one above just started Mach61 (talk) 12:55, 25 November 2023 (UTC)

Sorry, I missed that.  Done Boud (talk) 12:57, 25 November 2023 (UTC)

This proposal might be a bit radical, however, I do think this is necessary for reasons to be explained. In my opinion, current clean up templates are longer than it should be and is an example of instruction creep. Most templates in Wikipedia:Template index/Cleanup should be simplified to two sentences (within the realm of the proposal's spirit):

1. stating the problem, and
2. saying "Please improve this article if you can" and link to other policy/guideline/how-to pages/resources (including the removal notice).

This is because the content after the first sentence are either a truism for Wikipedia in 2023 like:

• Please add secondary reliable sources
• Unsourced material may be challenged and removed
• This article needs to comply with the Wikipedia quality standards

or just a redundant rephrase of the first sentence:

• ((importance section)): This section contains information of unclear or questionable importance or relevance to the article's subject. Please help improve this section by clarifying or removing indiscriminate details. (it is obvious already from the first sentence that these information should be removed or fixed)
• ((context)): This article provides insufficient context for those unfamiliar with the subject. Please help improve the article by providing more context for the reader. (If there is insufficient context, the obvious step is to add context to the reader)
• ((advert)): This article contains content that is written like an advertisement. Please help improve it by removing promotional content and inappropriate external links, and by adding encyclopedic content written from a neutral point of view. (First point is obvious, second point is somewhat obvious which can be answered by a link to Wikipedia:External_links#Advertising_and_conflicts_of_interest, third point is obvious)
• see more at Wikipedia:Template index/Cleanup.

Making the clean up template shorter will make the template less BITEy to newcomers and easier to gloss over by editors, which in turn will increase the likelihood that the issue mentioned in the template itself will be fixed. The template should not be a place to exhaustively list possible actions to deal with the issue, because we can add link to other resources that would talk about the problem in much more nuance than any template tag can do.

However, I think it might be controversial to remove the "Please improve this article if you can" phrase. This is because even now many readers have no idea that you can edit Wikipedia and they can help fixing the problem itself (but see below for a counterpoint).

There is precedence that shorter clean up messages does not reduce the context of the cleanup problem:

• In 2010, cleanup templates have look more or less like our current templates, but the messages usually has only two sentences. To my knowledge, nobody has complained about it back then.
• ((multiple issues)) and small or section-sized templates has trimmed down the cleanup messages to just plainly stating the problem in one sentence, yet nobody has given any complaint about this.
• Inline cleanup template only has a few word and a link to the issue. Again, the community has decided that this is enough context to explain the problem at hand without needing to list solutions to solve the problem or saying "Please improve this article if you can".

CactiStaccingCrane (talk) 15:12, 28 October 2023 (UTC)

I think it might be controversial to remove the "Please improve this article if you can" phrase. This is because even now many readers have no idea that you can edit Wikipedia and they can help fixing the problem itself (but see below for a counterpoint). What did you intend as the counterpoint? That Template:Multiple issues hides each template's call to action in favor of its own call? Or that inline templates are just a word or two but link to a page that hopefully has a call to action? Anomie⚔ 16:36, 28 October 2023 (UTC)

Multiple issues. Sorry if I haven't clarify it in the proposal. CactiStaccingCrane (talk) 04:11, 29 October 2023 (UTC)

Some of these cleanup templates are overly-long and repetitive. Please help improve these templates by removing any overly-long or repetitive content. Levivich (talk) 20:41, 28 October 2023 (UTC)

Yeah, strongly support. The simpler the better. DFlhb (talk) 08:26, 29 October 2023 (UTC)

Hmm, if the proposal is so obvious, should I just... do it? CactiStaccingCrane (talk) 15:36, 29 October 2023 (UTC)

• I think I  Disagree with this, not necessarily because passers-by wouldn't know you can edit Wikipedia, but because the fairly frequent, dispersed reiteration of such is important to demonstrating the culture. If I can project back, I think seeing the relatively common beckonings for contribution made it much more likely that I would eventually end up contributing.
• I don't think additional terseness makes articles less BITEy, quite the contrary, actually.

— Remsense聊 19:28, 29 October 2023 (UTC)

• I'm largely in favor of removing these in general unless there are specific, actionable, things that need doing. The notability tags are worthless the vast majority of the time--there just aren't sources that anyone has been able to find. It's a badge of shame, not for actual improvement. The needs more citation tags are in theory useful, but somehow are mostly in articles that have a dozen plus citations rather than those with zero. On the whole, I'd prefer to remove the banners. If they do have a useful part, it's telling people *they* can fix it. I'd rather not remove that. Also, see my user page for my thoughts on the issue... Hobit (talk) 15:39, 30 October 2023 (UTC)

  Huh, what on earth? It's not a 'badge of shame' to point out when things stated in an article require verification. It's a cherished part of the process (for me), not a shameful state to be in. Everything on the wiki is constantly changing. Remsense聊 16:09, 30 October 2023 (UTC)

  Oh a "citation needed" is fine. A "This may not meet notability requirements" isn't helpful in any way IMO. YMMV. Hobit (talk) 22:34, 30 October 2023 (UTC)

  I think it is, when one considers that the message isn't just for the person who initially wrote the article. — Remsense聊 22:35, 30 October 2023 (UTC)

  I find "This may not meet notability requirements" helpful often. I place it myself when it's a subject I know little about and am not interested in spending the time assessing, hoping a future editor who arrives there with some combination of knowledge and interest will address it. I often fix such tags when it's an article I do have knowledge of and/or am interested in improving, and I occasionally arrive at such an article about a topic I'm quite suspicious is not notable, do a BEFORE, and AfD. Valereee (talk) 12:01, 31 October 2023 (UTC)

  As a note, I just encountered a group of non-Wikipedia people who discounted an article as having useful information because it had a tag on the top of it. Yes, they are ignorant, but yes, we are encouraging that behavior by placing such tags in such a prominent location. Hobit (talk) 15:50, 7 November 2023 (UTC)

  @CactiStaccingCrane, it's interesting that you picked 2010 as your baseline, because there was some WMF-supported work on making messages clearer, shorter, and more friendly right around that time. I agree with you that a sentence basically repeating the same content isn't a good idea, but if we are still hoping that these messages convert readers into editors, I think it's helpful to have a Call to action (marketing). Perhaps just stop as "Please improve this article", or change it to "You can edit this page, even if you don't have a free account"?

  I have long been doubtful about the utility of most messages, and I find some irritating. (Do we really think that readers are so stupid that they can't see that a two-sentence stub has no/very few little blue clicky numbers?) Their value is unproven, and when we hid them on the mobile site for years and years and years, there was no reason to believe that anyone missed them, especially for the more boring "Bringing this article up to my personal standards is somebody else's problem" maintenance templates. I have wondered occasionally what would happen if we ran an A/B test in which half of the instances for templates like ((more footnotes)) were hidden (e.g., via CSS based on the month/year stated in the template) for a year. Would the articles get fewer edits? Would they get more, e.g., because an editor thought it was really important to have the tags showing? WhatamIdoing (talk) 20:24, 1 November 2023 (UTC)

  Yes, it's obvious that that such banner tags don't work and so should be removed as dysfunctional clutter. The latest grotesque example I saw was at Bertrand Russell. The tag was ((ref-cleanup)) and read

  This article has an unclear citation style. The reason given is: Citation styles are inconsistent, a mix of CS1, plain text, and minimally-formatted links, sometimes with webarchive templates. The references used may be made clearer with a different or consistent style of citation and footnoting.

  This article has a huge bibliography and over 200 citations so it's not surprising that there's some inconsistency in such a mass of detail. But, of course, there's no detailed discussion to explain exactly what's required. As it has been a GA and FA candidate, such vague nagging should be left to the next round of promotion rather than distracting the thousands of daily readers.

  Note that every page has much more important reminders for our readers such as the copyright licence, the general disclaimers and the toggle for desktop/mobile view. Those all go at the foot of the page which is quite inconvenient as I often want to use the toggle. It's absurd that a minor cleanup matter should get more prominence.

  Andrew🐉(talk) 15:53, 4 November 2023 (UTC)

  It's unfair to cherrypick examples, that's survivorship bias at best. Plenty of editors specifically use banners and other maintenance tags as a roadmap to go through articles and fix specific types of issues. I agree that it's better form to be more specific to aid a potential remedy, but in a ton of cases, a nonspecific tag is better than no tag, while there is certainly a class where this is not so. Remsense聊 16:01, 4 November 2023 (UTC)

  It might be better if such banner tags expired automatically so that the ones which are not effective then disappear rather than remaining for years to mystify every reader. The ((orphan)) tag does something like this now after there were numerous complaints about it. Andrew🐉(talk) 16:23, 4 November 2023 (UTC)

  I would support that for some category of maintenance tags, certainly. Remsense聊 16:41, 4 November 2023 (UTC)

  The problem is not so much the tag as the huge banner. I usually put some standard tags at the start of each article such as ((short description)), ((use British English)), ((coord)). These are either silent or display in a more restrained way.

  As cleanup tags are usually only actioned by specialist gnomes, the giant banners are not helpful. All that projects like WP:GOCE need are the cleanup categories. Banners should not be displayed unless they are actually useful to readers.

  Andrew🐉(talk) 12:43, 5 November 2023 (UTC)

  I would also support there being some flexibility based on scope/action-ability of the problem and who is likely to solve it. Remsense聊 12:44, 5 November 2023 (UTC)

  Many banners could be transformed into topicons DFlhb (talk) 16:28, 5 November 2023 (UTC)

  @Remsense, you said Plenty of editors specifically use banners and other maintenance tags as a roadmap, and I ask: Are they, really? Specifically, are they using the visible message at the top of the page, or are they doing what I do, which is using the category the banner adds? I clean up tagged articles; however, I do not clean up tagged articles by loading a bunch of pages and seeing what banners are at the top. I use category-based tools such as https://bambots.brucemyers.com/cwb/bycat/Medicine2.html#Cites%20no%20sources

  We could have those cats even if we took away the huge banners. WhatamIdoing (talk) 17:26, 13 November 2023 (UTC)

  WhatamIdoing, I think it's possible the footprint of many banners could be reduced, but on articles I feel like I can help with, I think the presence of banners genuinely does help direct my work, in tandem with the navigation-by-categories mode I mentioned above. Remsense聊 17:38, 13 November 2023 (UTC)

  So for you, personally, your process for finding articles to improve, is just to click on random links to see whether there is a banner at the top of the page? WhatamIdoing (talk) 18:58, 13 November 2023 (UTC)

  No, it's when I'm reading and clicking through articles on topics I care about, which I imagine is not a process unique to me. Regardless, to be clear I'm not against some downsizing like you propose. Remsense聊 19:16, 13 November 2023 (UTC)

  Thanks for explaining this. I largely stopped reading articles years ago, so I don't have the same process. (I assume you also improve articles that aren't tagged.) Within the articles I'm most likely to click on (e.g., to see whether the link I'm making will point to the right article), I usually find that the banners are uninformative or outdated. WhatamIdoing (talk) 00:36, 17 November 2023 (UTC)

Well, the proposal has stalled. I've made a small edit proposal about this in ((Advert)) to start making things moving again. CactiStaccingCrane (talk) 13:15, 9 November 2023 (UTC)

Implementation

@ScottishFinnishRadish: did you add AP to the module as per the consensus you determined?--RZuo (talk) 10:01, 19 November 2023 (UTC)

RZuo, I did not, no. ScottishFinnishRadish (talk) 14:37, 19 November 2023 (UTC)

@ScottishFinnishRadish: can you please edit the module(s)?--RZuo (talk) 08:55, 20 November 2023 (UTC)

I generally don't make edits related to RFCs I've closed due to WP:INVOLVED concerns. As Val suggests below, you should make an edit request at the module talk page linking to the RFC result. ScottishFinnishRadish (talk) 13:03, 20 November 2023 (UTC)

that's some weird way your group of users work in. RZuo (talk) 14:57, 20 November 2023 (UTC)

It needs a template editor or an admin familiar with editing modules. I wouldn't go near it myself. RZuo, you could make an edit request at the appropriate talk and reference the closing. Valereee (talk) 15:04, 19 November 2023 (UTC)

When editing on my Android phone, I do not see a Changes page or display, only a Preview of rendered edit. Does functionality exist to show Changes, or can it be added? Haven't found discussion of this issue. DonFB (talk) 21:22, 19 November 2023 (UTC)

DonFB, your question isn't really a proposal. It's probably better asked at the Village Pump for technical matters. Seraphimblade ^{Talk to me} 23:47, 19 November 2023 (UTC)

I was thinking of it as a proposal to add the function, but hedged my comment, because I'm not certain it does not exist. But I can ask there also. DonFB (talk) 23:52, 19 November 2023 (UTC)

It looks like the mw:Mobile visual editor has this option, but I don't see it in the mobile wikitext editor. You don't need a community consensus to ask the mw:Editing team to improve the editing tools; they'll do the research when/if it fits in with any of their assigned projects. You can reach them through @Trizek (WMF) or leave a note at their page on MediaWiki.org. WhatamIdoing (talk) 05:28, 20 November 2023 (UTC)

@DonFB, are you editing on the Android App, or do you edit using the mobile website (in your browser)? Trizek_(WMF) (talk) 14:06, 20 November 2023 (UTC)

I don't use app; am using the mobile website. Is the app a Playstore thing or available from Wikimedia? DonFB (talk) 19:25, 20 November 2023 (UTC)

While I think utilizing a block log is beneficial, people change and just like in the regular world, there should be a purge after a certain number of years. I think 5-10+ years is a good enough number to start the discussion with. Sir Joseph ^(talk) 17:56, 17 November 2023 (UTC)

How about 10 years, or twice the duration from the first block to the most recent block (including blocks of socks), whichever is longer. Jc3s5h (talk) 20:41, 17 November 2023 (UTC)

So if a person got blocked once, then in 10 years, it could be hidden, but if they were blocked twice, removing the oldest would require 10 years plus no blocks in the most recent five years? Or:

• Given a 2010 block and a 2014 block, with none since: First block hidden in 2020, second block hidden in 2024 (10 years).
• Given a 2010 block and a 2019 block, with none since: Everything remains visible (until at least 2028 [twice the duration between the first block and the most recent block]).

WhatamIdoing (talk) 23:32, 18 November 2023 (UTC)

Sir Joseph, are you talking about purging just logs or also the blocks themselves?
No unblock request will ever succeed again after a purge because everyone will simply assume the worst. — Alexis Jazz (talk or ping me) 20:45, 17 November 2023 (UTC)

The real problem is that people read too much into block logs. Or, more to the point, people read too much into their own block logs. My RfA carried no small amount of controversy, and yet no one had concerns about my indefinite block in 2012. The block log is an objective record of that incident, of the fact that for 3 hours an admin thought the project was better off without me. What point is served by hiding that? I don't think it would really change anyone's opinion of me—hopefully, after 10 years, they associate me more with something other than that block. This just seems like caving in to people's anxieties that a past block defines them. The better response is to tell people that they're judged much more by their reputation now than their reputation 10 years ago, both for better and for worse. -- Tamzin^{[cetacean needed]} (they|xe|she) 20:52, 17 November 2023 (UTC)

It's good for editors to see that admins are human, reputations are reparable, and old blocks may not even block one from becoming an admin. O3000, Ret. (talk) 21:11, 19 November 2023 (UTC)

Absolutely not. We shouldn't read too much into people's old blocks, but purging has many bad side effects. For example, if somebody has been blocked repeatedly, deleting the early blocks makes it more difficult to understand the later blocks. We also don't want people to let one of their accounts lay dormant for five years after receiving a block, just to wait out the log. —Kusma (talk) 21:10, 17 November 2023 (UTC)

No thank you, this is an important part of administrator transparency. We should not hide actions taken by administrators just because some time has passed. — xaosflux ^Talk 21:24, 17 November 2023 (UTC)

Sorry? You're proposing we reduce transparency? Edward-Woodrow (talk) 13:51, 18 November 2023 (UTC)

• Strong Oppose per the above. Good faith proposal, but this is just a bad idea. Transparency is extremely important, especially where admin actions are involved. -Ad Orientem (talk) 21:12, 19 November 2023 (UTC)
• Absolutely strong oppose. Logs are logs. They should not go down the memory hole after some specified period; they are meant to show what happened. In my experience, people are very rarely concerned with very old block log entries; I've got one in mine from 2006 and no one considers it in any way significant any more. But it is still a part of both my history and that admin's history on the project, so it should be retained. We should no more purge "old" block logs than we should purge "old" edit histories. Seraphimblade ^{Talk to me} 21:16, 19 November 2023 (UTC)
  • Seraphimblade, note that old edit histories can't be purged for legal reasons. They're needed for the "attribution" part in Creative Commons Attribution-ShareAlike. — Alexis Jazz (talk or ping me) 23:10, 19 November 2023 (UTC)

    I'm well aware of that. But even if it weren't for that, I would be firmly against any redaction or purging of public logs, be they edit histories, admin actions, or whatever else have you. The whole idea is that anyone can see what happened, be that twenty minutes or twenty years from when it was done. Seraphimblade ^{Talk to me} 23:43, 19 November 2023 (UTC)

• I can see some merit in this idea. There are times that I've blocked good editors which was necessary at the time but it seems a shame that people will draw conclusions from that block even many years after the issue was resolved. HJ Mitchell | Penny for your thoughts? 21:21, 19 November 2023 (UTC)
• I think the problem is real, but this is not the right solution. Tamzin's block log (or mine) isn't really a great example, because the unblock reason is pretty clear. What about those 24-hour edit warring blocks that just expire without explanation? Or the really immature editors who get blocked a half dozen times (for good reason), then finally grow up? A block log like that can leave you perpetually more likely to get blocked, or reported to ANI, in the future. "Oh, previously blocked twice for sockpuppetry? No need to check with CU if that's a joe-job, obviously they're just up their old habits..." or "Oh, five edit warring blocks? Yeah, this time they weren't quite at 3RR and maybe there's kinda sorta a BLP exception, but obviously this is a troublemaker...", and so on.
  Maybe, instead, just make the old blocks a little harder to find. That is, one extra click, each time, on a "show blocks older than X years" checkbox. The act of clicking will hopefully force you to slow down and think "these blocks are old, maybe this person has changed".
  Or maybe, just color the old blocks differently. As in, slightly faded (but still barely WCAG compliant) text. Again, this will just slow you down, and make you notice the date. Suffusion of Yellow (talk) 21:45, 19 November 2023 (UTC)
  • I would support this. Divide the subject into "Recent blocks" (perhaps within the last five years), with a click to get to "Older blocks", which appears only if there are older blocks. BD2412 T 22:00, 19 November 2023 (UTC)

    +1. There are times that we need to review an editor's block log, for example there could be a years-long pattern of behaviour, but forcing people into an extra click or showing logs in a different colour might make people pause before they go dredging up ancient history. HJ Mitchell | Penny for your thoughts? 22:08, 19 November 2023 (UTC)

    That idea, I could get behind. The logs should certainly not be purged entirely, but an extra step to view them which also emphasizes "These happened long ago" does not violate that and could very much work. Seraphimblade ^{Talk to me} 23:41, 19 November 2023 (UTC)

  • I like this idea. Would suggest the click over the different color, you can't fade it enough while remaining WCAG compliant. — Alexis Jazz (talk or ping me) 23:35, 19 November 2023 (UTC)
• Oppose - yes people change, but thats also demonstrated by a block log showing no blocks in ten years. I dont see the gain here, and I say that as somebody who would see all of their past indiscretions hidden away by this proposal. nableezy - 23:23, 19 November 2023 (UTC)
• Support For as long period like 10 years (not 5 years). People will inevitably read too much into them, including not factoring in for age. And something 10 years old is not relevant for any purpose for looking at a block log. North8000 (talk) 23:31, 19 November 2023 (UTC)

  @North8000 for your 10 years, when would you start counting? — xaosflux ^Talk 23:40, 19 November 2023 (UTC)

I'd go 10 years before the present date. North8000 (talk) 02:01, 20 November 2023 (UTC)

@North8000 so for example here is a block log entry, it is more than 10 years old, it is still currently active - are you proposing we should purge this, leaving the user blocked with no explanation? Special:Redirect/logid/445581. — xaosflux ^Talk 20:03, 20 November 2023 (UTC)

@Xaosflux: I hadn't thought about 10 year old still-active blocks. And the large amount of dead accounts (socks etc.) covered by that. So I'd need to change my recommendation to 8 (or 10) years after the block ended. North8000 (talk) 20:23, 20 November 2023 (UTC)

(ec) Surely it would have to be X years after the block ends? It makes no sense to purge a 10-year block which ended yesterday but not a 31-hour block which started and ended nine years ago. But I still don't support any of this anyway. Certes (talk) 20:26, 20 November 2023 (UTC)

• Does this take WP:DENY into account? Is hiding old blocks from non-sysops an (feasible) option in that case, then? FMecha (to talk|to see log) 04:59, 20 November 2023 (UTC)
• Oppose, unless this were more comprehensive, like voiding/suppressing topic bans, interaction bans, and other editing restrictions after a decade or whatever, too, not just blocks. We have no interest in hiding the fact that someone was so disruptive they got a long block, but memorializing forever that they were less disruptive and just got a T-ban or other lesser restriction. Even then I might still oppose, since I'm not sure this is ultimately in the best interests of the community as a whole, even if it would be nicer/fairer to various particular invididuals who have matured as editors. It would give a green light to too many who have not.  — SMcCandlish ☏ ¢ 😼  07:57, 20 November 2023 (UTC)

  That's a good point. We shouldn't be tricked into assessing someone with visible minor sanctions as more disruptive than someone with hidden blocks. Let's leave it to the reader to decide whether a 10-year-old block is relevant. It may be for some purposes but not for others. Certes (talk) 10:03, 20 November 2023 (UTC)

• In response to the idea of "hiding" old blocks from the logs, I would oppose anything that makes links to old blocks no longer work or require extra clicks. I could be persuaded to have a new "recent blocks" thing that is prominently displayed from the contributions page instead of the full block log, but the logs should be fully and easily accessible to those who want to see them. —Kusma (talk) 11:45, 20 November 2023 (UTC)
• Personally I think this is more of an issue with our culture. We expect that a good user to do everything perfect and we tend to forget that failing is also a way for us to learn to be better in the future. CactiStaccingCrane (talk) 11:46, 20 November 2023 (UTC)

From what I have seen, they are usually easy vandalism targets, and semi-protecting them similarly to TFAs until they automatically get pushed off would prevent this. DrowssapSMM (talk) (contributions) 12:57, 20 November 2023 (UTC)

Compared to TFAs, these are much more likely to benefit from additional non-vandal edits. We should keep them open for editing as much as possible. —Kusma (talk) 13:55, 20 November 2023 (UTC)

• Strong Oppose not only per Kusma's reasoning but also on principle. We should not WP:PREEMPTIVEly protect pages. We are the encyclopedia anyone can edit and we should keep as close to that as possible. Edward-Woodrow (talk) 20:44, 20 November 2023 (UTC)

• Withdraw proposal. After reading these responses, I have concluded that this is definitely an idea of the bad variety. I did not know about WP:PREEMPTIVE, so thank you for bringing that page to my attention. DrowssapSMM (talk) (contributions) 01:24, 21 November 2023 (UTC)

This page moving sandbox would be a sandbox where, mainly new, but maybe from time to time, an experienced editor, would practice their page moving. There would be a few ground rules, such as the two below:

1. The page it is moved to must stay in the Wikipedia: namespace.
2. The page it is moved to must not be inappropriate or offensive.

To reset this sandbox, a user would move the page back to "Wikipedia:Page moving sandbox" or whatever this page is named. Opinions, comments, questions, anyone? ThatOneWolf ^{(talk|contribs)} 00:41, 21 November 2023 (UTC)

@ThatOneWolf this would likely end up breaking and causing admin work; if someone wants to test how to move a page they can move their own user sandbox to another name (e.g. User:ThatOneWolf/sandbox/test to User:ThatOneWolf/sandbox/test2). — xaosflux ^Talk 01:21, 21 November 2023 (UTC)

Yes, I guess I didn't really think about that. I'm always thinking about external wikis, and one of them only needs autoconfirmed status to suppress redirects. That's not the case here, and an admin would have to delete the redirects to reset. Totally forgot that. ThatOneWolf ^{(talk|contribs)} 03:31, 21 November 2023 (UTC)

There's an ongoing discussion about adding an infobox on the article of Fred Sullivan. All feedback is welcome. Thanks! Nemov (talk) 21:35, 15 November 2023 (UTC)

@Nemov How is this RfC a suitable topic here? Is it more important than any other? Doug Weller talk 08:24, 16 November 2023 (UTC)

Wikipedia:Requests for comment#Publicizing an RfC suggests notes like this at a village pump "if relevant", and we generally give editors pretty wide latitude to decide what counts as relevant. WhatamIdoing (talk) 21:59, 21 November 2023 (UTC)

Hello, I am proposing the following barnstars be integrated towards WikiLove throughout Wikipedia:

	((subst:The Most Improved Editor's Barnstar|1=message ~~~~))	The Most Improved Editor's BarnstarThe Most Improved Editor's Barnstar The Most Improved Editor's Barnstar is awarded as part of editor retention efforts, to editors striving to learn and adopt best practices of the project, aiming to improve their contribution. Introduced by Santasa99 on 16 January 2021.
	((subst:The Anti-anon Barnstar|1=message ~~~~))	The Anti-anon BarnstarThe Anti-anon Barnstar The Anti-anon Barnstar is awarded to editors who have encouraged and/or assisted unregistered users to join the Wikipedia community. Introduced by Jerium on 6 November 2023.

Jerium (talk) 19:50, 21 November 2023 (UTC)

@Jerium, I like these. I wonder if that last one could have a new name, though. IPs aren't anonymous, and people who encourage them to register aren't "anti" them. WhatamIdoing (talk) 21:56, 21 November 2023 (UTC)

Yeah, I like them. Like WhatamIdoing said, they are very nice additions, if you change the last one. ThatOneWolf ^{(talk|contribs)} 21:59, 21 November 2023 (UTC)

WhatamIdoing I based the title, partial on the criteria, and design on Template:user anti-anon. I'm fine with changing the title, someone just come up with one. Jerium (talk) 22:05, 21 November 2023 (UTC)

@Jerium: Maybe something like Recruiter Barnstar? Or, we could do something like IP account suggester. Maybe one of those? ThatOneWolf ^{(talk|contribs)} 22:16, 21 November 2023 (UTC)

@ThatOneWolf, "recruiter" seems to have the right tone. Schazjmd (talk) 22:18, 21 November 2023 (UTC)

IMO, I do like "Recruiter Barnstar" better than the other one. ThatOneWolf ^{(talk|contribs)} 22:19, 21 November 2023 (UTC)

I also like the "Recruiter" idea. WhatamIdoing (talk) 18:46, 22 November 2023 (UTC)

• Done I've gone and moved the template to "The Recruiter Barnstar", but how do these get added on the WikiLove throughout Wikipedia for everyone to use? Jerium (talk) 19:11, 22 November 2023 (UTC)

  @Jerium, it looks like the request would need to be made at MediaWiki talk:WikiLove.js. However, looking at previous requests on its talk page, they suggest getting consensus at Wikipedia talk:WikiProject Wikipedia Awards first. Schazjmd (talk) 19:40, 22 November 2023 (UTC)

Schazjmd It makes no sense getting consensus from there, when I am WP:WPWPA. I am the current lead for making new barnstars and remastering older ones to meet WP:B2G (see barnstars made) once Antonu stopped editing. Jerium (talk) 19:55, 22 November 2023 (UTC)

The names of both of these are problematic. The first implies a contest or review process by the community to select a single person as "most improved", but that's not what it is (and we wouldn't want such a process). Might be better as "Greatly Improved Editor" or something. The second is even more obviously wrongheaded, in setting itself up as opposition to anonymous editors. This should probably be more like "Registration Helper Barnstar". And the text in in it wonky as well. "Unregistered" (i.e. anon IP) users are still part of the Wikipedia community, just less integrated into it. Maybe somethign like "encouraged or assisted unregistered users to more fully join the Wikipedia community by creating accounts".  — SMcCandlish ☏ ¢ 😼  20:49, 23 November 2023 (UTC)

The Anti-anon was changed to the “ Recruiter Barnstar” already, and I like “Greatly Improved Editor Barnstar “. Jerium (talk) 21:30, 23 November 2023 (UTC)