Wikipedia:Village pump (proposals)/Archive 208

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

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

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Temporary moratorium on new proposals regarding deletion, notability and related matters

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)

Notice of proposal to blacklist an image

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)

Discussion at Wikipedia talk:WikiProject Articles for creation § Where should we place the scam warning?

 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)

Stepanakert/Khankendi

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)

Hebrew in Latin

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)

Reopen Wikipedia:Books page since the concept of a "Wikipedia Book" still exist

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)

Signature wiki markup

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Increase the character limit for signatures if it is wiki markup. Wiki markup is far longer than regular text making the current limit rather stifling, especially if you are using many formattings/templates. G'year talk·mail 22:41, 22 October 2023 (UTC)

Then don't use so many formattings, and do not use (unsubsted) templates, parser functions, images, and so on . See Wikipedia:Signatures#Length for why the current technical limitation is embraced by our signature guideline, so even though you've apparently found a way around it you're not allowed to make use of it. Anomie⚔ 11:42, 23 October 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Elon Musk

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

It usually isn't a good idea to feed the trolls or fan the flames, but should editors draft a formal response to Musk's increasing attacks on Wikipedia? He is, after all, one of the most influential people in the world — ironically according to the "mainstream media" that he hates. Musk has always been critical of Wikipedia (and by extension, the WMF), but recently he has been mounting an all-out attack on the platform formally known as Twitter: [1] [2] [3] [4] [5] [6] [7] [8]. InfiniteNexus (talk) 17:01, 23 October 2023 (UTC)

I say no. He's the ultimate troll. Jimbo has done a fine job of responding on his own. – Muboshgu (talk) 17:05, 23 October 2023 (UTC)

Ignore. It’s all hot air. Loads of people gripe about Wikipedia. He can join the queue. Barnards.tar.gz (talk) 19:15, 23 October 2023 (UTC)

Ignore. Musk is just scared. The Banner talk 00:34, 24 October 2023 (UTC)

• I would be somewhat more concerned about the potential of trolls coming here and trying to create exactly the kind of chaos one might predict from that high-profile tweet. Yes, I know we are already dealing with that all the time, but let's apply some extra caution. BD2412 T 00:53, 24 October 2023 (UTC)
• I agree with everybody else here that the best solution here is to ignore Musks immature gripings. Hemiauchenia (talk) 01:31, 24 October 2023 (UTC)

There's around a thousand admins. We can edit the main page. That's a million dollars each. Who's with me?! ScottishFinnishRadish (talk) 01:33, 24 October 2023 (UTC)

Unfortunately for you, the 12 interface admins, who can modify the MediaWiki files and change the name of the site everywhere, have a better chance of claiming the money. Plus, it's almost 100 million each - who could blame them? BilledMammal (talk) 01:37, 24 October 2023 (UTC)

Brb, opening a request at WP:BN. ScottishFinnishRadish (talk) 01:39, 24 October 2023 (UTC)

Keeping it that way a full year is absurd. Would he pro-rate the payment so that we could just do it for a day and get $2.74 million? jp×g 04:34, 24 October 2023 (UTC)

• DNFTT. AndyTheGrump (talk) 01:34, 24 October 2023 (UTC)
• No, per AndyTheGrump. -- Euryalus (talk) 01:47, 24 October 2023 (UTC)
• To be honest, Musk makes some legitimate points. I mean, not the one about rebranding, that was just silly. But this tweet about excessive fundraising makes much the same criticisms as WP:CANCER. This tweet about editorial hierachy and bias is another fair observation. This tweet about source bias might indicate a misunderstanding of our purpose (we're source-summarisers, not truth-finders), but let's be honest, the average reader probably does think of us as truth-finders, and if you think Wikipedians ought to be truth-finders then it's an arguable point. Rather than attack or ignore Musk's points, we should do what we always do: take feedback on board and keep working to improve the encyclopedia. – Teratix ₵ 02:19, 24 October 2023 (UTC)

  He distorts, bullies, misrepresents, lies, personally attacks. He's doing it for a reason, but it's not to legitimately criticize Wikipedia for ours, or anyone's benefit, only his own. Furthermore, nothing he said is original, he has no new insights. Don't try to legitimize or normalize it. -- GreenC 05:27, 24 October 2023 (UTC)

  We shouldn't ignore criticisms because we don't like who they come from or because other people have made them before. Please don't insinuate my response was intended to "legitimize or normalize" lies or attacks. – Teratix ₵ 06:49, 24 October 2023 (UTC)

  Criticism needs to be rooted in facts. Say what you want about Guy and Andreas, at least there is some substance to their grievances. This is just fear mongering, attacking institutions and knowledge. It's classic populism, amplified by right wing media who are whipping up a frenzy because they are sad. —TheDJ (talk • contribs) 11:52, 24 October 2023 (UTC)

  To be fair, we do some truth-finding by limiting input to sources which, in our subjective opinion, are reliable. That's a useful function and performed as objectively as possible, so I'd see it as a point in Wikipedia's favour rather than valid criticism. Wikipedia isn't perfect but, if recent changes at Twitter are any indication, Musk's involvement might not lead to improvement. Certes (talk) 10:18, 25 October 2023 (UTC)

  Maybe I'm looking in the wrong place, but I don't see any criticisms in common between the excessive funding tweet and WP:CANCER, except the overarching claim that it doesn't cost as much to run Wikipedia as the money it raises. The only specific point made in the tweet is the false statement that Wikipedia can fit on a phone. And when Musk says Wikipedia is "inherently hierarchical", what is he talking about? Bryan Henderson (giraffedata) (talk) 18:56, 25 October 2023 (UTC)

• Surely, in a free country, some guy is entitled to log onto his own website and write a post on it that some other website is stupid, whether or not his post is itself stupid. Of course, I guess we could put together an essay saying his post was stupid. It was kind of stupid. Of course, it was also kind of true. Anyway, we are always willing to publish good writing in the Signpost. Perhaps that'd be better than letting other news outlets valiantly defend our honor by reassuring their readers that everyone on Wikipedia is 100% in favor of all WMF spending. jp×g 04:32, 24 October 2023 (UTC)
• Just ignore him. --Malcolmxl5 (talk) 15:02, 24 October 2023 (UTC)

Never heard of him. Levivich (talk) 02:29, 25 October 2023 (UTC)

• Support accepting the $1 Billion offer. Sports stadiums sell (temporary) branding rights, and here we have a $1 Billion offer by Musk to change our name to "Dickipedia". Before you get on your "not for sale" or "haggling about the price" soapbox, just consider how we could spin the marketing here, have a little fun with it, and laugh all the way to the bank. We could stick a cartoon of Dick Tracy on the main page and explain how editors do detective work ("Dick" is a 19th/20thC slang for detective[9]) to find reliable sources to improve articles. After just one year, Musk says we can change the name back. And if in October 2024, Scrooge McDuck wants to buy the one-year naming rights for "Duckipedia", then we should take his money too. Hold Musk to his word—the former management and shareholders of Twitter are glad they did. Cheers! BBQboffin (talk) 05:08, 25 October 2023 (UTC)

  I think you're on to something here. Let's just have an RFC on this and then split the money between the RFC voters. Levivich (talk) 05:47, 25 October 2023 (UTC)

  Would we have to deprecate WP:DONTBEADICK? Certes (talk) 10:14, 25 October 2023 (UTC)

  @Certes, WP:BEADICK is just waiting to be written. — Qwerfjkltalk 16:11, 25 October 2023 (UTC)

  Stop your dicking around, will you? GenQuest ^"scribble" 17:40, 25 October 2023 (UTC)

• Oppose WMF already has more money than it needs (acquired from people who want to support Wikipedia (not WMF)) and spends too much of it elsewhere and not enough on Wikipedia. Also, as back of the envelope estimate, the main value of Wikipedia is the approx $50 Billion in unpaid volunteer time that has gone into it. You don't get renaming rights on that by giving $1 Billion to somebody else (WMF). North8000 (talk) 12:18, 25 October 2023 (UTC)

Hear! Hear! GenQuest ^"scribble" 17:40, 25 October 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Article renaming

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi, my problem is the article renaming of Dobrujan Tatar, we did make some discussions, but there is no result. Where I think it's better to rename it to "Dobrujan Tatar language". But everytime it's rejected, for the first time it was called "Dobrujan Tatar", we did make a discussion, there was the result "Dobrujan Tatar dialect", for the second discussion was actually not result to find (but there was an Idea, called "Dobrujan Tatar dialects"). And also I think the name "Dobrujan Tatar dialect" was wrong. Zolgoyo (talk) 22:15, 22 October 2023 (UTC)

@Zolgoyo: Consensus is that that is not the right name for the article. Edward-Woodrow • talk 21:21, 23 October 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Automatically put RfCs that are 30+ days old to WP:CR

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

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)

RfC: Enabling collapsible templates on the mobile site

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should a JavaScript gadget be installed and enabled by default to enable collapsible templates on the mobile site? — Alexis Jazz (talk or ping me) 09:35, 3 September 2023 (UTC)

Background (enabling collapsible templates on the mobile site)

When users of the mobile site encounter content in a collapsed template, they always see the content in an uncollapsed state with no way to collapse it. On some pages this can result in a long list to scroll past. For example, compare the "official status" section in the infobox of the article about the English language on the mobile site with the same article on the desktop site.

This has been a longstanding issue, phab:T111565 has been open since 2015. In response to myself and @Izno, @Matma Rex (who works for the WMF) said the following: As there are people opposed to making this change in MediaWiki core, I would suggest doing it in your wiki's MediaWiki:Common.js or a gadget, as long as your community finds that agreeable.

The reason some oppose making the change in MediaWiki core is the "fat finger problem", some people may have difficulty to tap short links titled "Hide" or "Show". The proposed gadget alleviates this issue by enforcing a minimal link element width of 6em.

The gadget can be tested on betacommons. If any bugs or serious issues with the gadget surface the deployment will be delayed until those issues are resolved. Similar to WP:ENOM, if the gadget is deployed this will be done in waves. — Alexis Jazz (talk or ping me) 09:35, 3 September 2023 (UTC)

Survey (enabling collapsible templates on the mobile site)

• Support as proposer. — Alexis Jazz (talk or ping me) 09:44, 3 September 2023 (UTC)
• Oppose Default for now - the use case is niche for forcing a gadget on to every single reader on every single page load. — xaosflux ^Talk 10:39, 3 September 2023 (UTC)

  Mostly indifferent on Opt-In along with user:Folly Mox below. — xaosflux ^Talk 15:22, 3 September 2023 (UTC)

  @Xaosflux, @Izno in supporting below notes that it's only about 10 lines of code. Is your argument that even this is going to create an unacceptable performance impact? (Is there any way to measure that?) Or is there another reason besides performance that having gadgets addressing niche use cases is bad? {{u|Sdkb}} ^talk 05:12, 28 October 2023 (UTC)

• Support at least making the gadget available as opt-in. Although honestly this should be done in the mediawiki core without concern for whether or not people will be able to register a tap on the expand / collapse element at default zoom. The "back to citation" carets (and letters for reused citations) to hop from the References section back to the prose are already too small to register a tap reliably, but of course mobile users know to zoom in on anything they're not able to select due to size.
  I feel like up until a few months ago, collapsible templates were always just stuck in their default state, so anything set to autocollapse was just hidden entirely and required hopping into desktop view. Having everything uncollapsed everywhere is better, but still incredibly inconvenient for certain pages. For example this page, WP:VPR, which still currently features WP:LUGSTUBS2 at the top, with an uncollapsed list of over a thousand entries to scroll past before reaching the discussion, or User:XOR'easter/sandbox/ReferenceExpander, with something like 2300 table entries to scroll past before reaching the diffs that have not yet been repaired.
  This doesn't address the larger issue of the mobile interface hiding navigation templates, but it feels like a step directly towards that direction. Folly Mox (talk) 13:35, 3 September 2023 (UTC) Switched to full support 18:14, 4 September 2023 (UTC)
• Support as opt-in. Edward-Woodrow :) _[talk] 20:31, 3 September 2023 (UTC)
• I have no true objections. Overall i think collapsibility is generally a failure of authorship, but that ship has long since sailed. —TheDJ (talk • contribs) 12:25, 4 September 2023 (UTC)
• Support as default - This would bring a much-needed basic function to the mobile interface. Any solution should be enabled by default for logged-out users since they make up the vast majority of our readership and don’t have the ability to opt-in or, for all intents and purposes, ask for changes to be made. –dlthewave ☎ 14:30, 4 September 2023 (UTC)

  But logged-in users don't make up the mast majoriy of our readership, just the majority of the editorship. Kind of a big difference. Only about 6% of our readers have ever edited here.  — SMcCandlish ☏ ¢ 😼  23:20, 5 September 2023 (UTC)

• Support as default for logged-out users. Don't much care what the default is for logged-in users, as long as each user can select their own preferred setting. MichaelMaggs (talk) 14:56, 4 September 2023 (UTC)
• Support as an option, unsure on whether to make it default. People who want collapsible stuff on mobile should be able to get collapsible stuff. I do think further discussion is needed on whether this should be the default for logged out users. I get that it could be useful, but I also have to give due consideration to the idea of the gadget potentially being "forced" on users. Ideally, I'd like for Wikipedia to avoid any situation reminiscent of the Vector 2022 RFC, or the niche but much more controversial recent drama on the Minecraft server 2b2t. InvadingInvader (userpage, talk) 16:58, 4 September 2023 (UTC)

  How would you feel about enabling the feature but not collapsing anything by default? Pages would display as they do now, there would just be a Show/Hide button that readers could use if they wanted to. –dlthewave ☎ 00:01, 5 September 2023 (UTC)

  Stil unsure. InvadingInvader (userpage, talk) 18:25, 12 September 2023 (UTC)

• Support, but prefer collapsed not the default. Collapsibility should work, but content shouldn't be hidden by default. No reason to distinguish between logged-out and logged-in users, if possible, except to allow logged-in users to set a preference that sticks.  — SMcCandlish ☏ ¢ 😼  23:20, 5 September 2023 (UTC)
  • SMcCandlish, just to clarify here: the gadget enables collapsible templates just like the desktop site. (with one exception: "autocollapse" is always collapsed, but this affects pretty much exclusively navboxes which aren't rendered on mobile anyway atm and I suspect many people don't even know how autocollapse actually works autocollapse also functions the same as on desktop now) Whether anything is collapsed by default depends on the classes/template parameters used, just like the desktop site currently. — Alexis Jazz (talk or ping me) 09:10, 6 September 2023 (UTC)

    Great. That works for me.  — SMcCandlish ☏ ¢ 😼  18:44, 6 September 2023 (UTC)

• Support, including for editors logged out. The gadget is only about 10 lines of code and brings the mobile website inline with how the desktop website works. Editors logged in don't use the mobile website, more or less. We're trying to target the ones using the mobile site, which is the set of people who don't have access to an opt in. Subsequently, I don't really understand why the several editors above have said "only opt in". Izno (talk) 00:34, 7 September 2023 (UTC)
• Oppose - Right now, the mobile and desktop experience is very fragmented and inconsistent, but the long term solution is not to bodge together some JavaScript gadget that will be unnecessary and that might break when the two are reunified. There is this long term goal of unifying the mobile and desktop experiences through making Vector 2022 responsive (see phab:T106463) but that seems mostly stalled because some editors really despise responsive skins. And I agree - coming from wikiHow, where a responsive skin was deployed in 2020, responsive designs done wrong can make the experience worse for everyone. But when done right, like in Timeless, it makes the experience so much more consistent. Aasim - Herrscher of Wikis ❄️ 13:58, 7 September 2023 (UTC)
  • Awesome Aasim, just to clarify, the gadget doesn't really implement collapsible templates. After checking if any collapsible elements are present on the page it just loads the MediaWiki module that handles this. If native MediaWiki support arrives some day, it'll be virtually identical. This also means that if support for collapsible elements on Minerva is ever added to MediaWiki core this gadget can simply be disabled as it's expected to be functionally identical anyway. See also the patch that was submitted but sadly not merged.
    Note that plwiki has already deployed something similar, though somewhat less efficient because they load the module unconditionally. — Alexis Jazz (talk or ping me) 15:25, 7 September 2023 (UTC)
• Support, as opt-out. I would prefer to not have collapsed as the default though. Some page elements in mobile can be very unwieldy and often annoying to scroll through. Given that most of our traffic comes from mobile devices, we shouldn't have elements that are hidden in mobile only. I feel adding a small show/hide button on collapsible elements would cause the least amount of disruption. Ca ^{talk to me!} 23:41, 7 September 2023 (UTC)
• Support, as in mobile such templates could not be seen which makes the reading experience worse than desktop. Lightoil (talk) 03:40, 20 September 2023 (UTC)
• Strong support The collapsible templates, among other stuff, make navigation between articles which are thematically connected a much easier task; the lack of their implementation on the mobile site was a major downside of the latter. Handmeanotherbagofthemchips (talk) 17:47, 5 October 2023 (UTC)
• Strong support as well, this seems like a really useful feature for us mobile users. I think it's best to be done as a global default.PHShanghai | they/them (talk) 16:12, 23 October 2023 (UTC)

Discussion (enabling collapsible templates on the mobile site)

@Xaosflux, there are actually quite some use cases. {{Sidebar with collapsible lists}} for example is disabled on mobile because mobile can't collapse anything. As a result, any content that is shown using that template is inaccessible on mobile. {{Sidebar with collapsible lists}} is transcluded nearly 90.000 times. While this template won't suddenly become visible with this gadget (it uses the nomobile class), editors will be able to decide on a case-by-case basis if such a sidebar should also be visible on mobile which can be viable once collapsible elements are made available. For another example of an even longer list of countries in an infobox, see IPhone 14.
Some numbers on performance impact: the gadget is currently just 911 751 bytes and gets cached in localStorage. Measuring how long the script takes to load on a page without collapsible elements is difficult because a duration of less than 1 millisecond is hard to measure accurately. — Alexis Jazz (talk or ping me) 11:09, 3 September 2023 (UTC)

I'm pretty sure that discussion has already occurred that it was appropriate to not show this content on mobile; if it isn't it should be just fixed. — xaosflux ^Talk 15:20, 3 September 2023 (UTC)

Xaosflux, if at some point collapsible elements become available on mobile, like with this gadget, the editorial decision could be made on a per-article basis. There are other considerations regarding sidebars and navboxes, but there would be options. The status quo for existing usage of {{Sidebar with collapsible lists}} wouldn't change, but for existing usage a parameter could be implemented to suppress the nomobile class or it could switch to a different template. Module talk:Sidebar/Archive 6#How to override "class=nomobile" to display sidebar in mobile view? is an example where this could be done. According to that thread, "nomobile is used because the old class vertical-navbox is already hard-coded to be removed on mobile, but I wanted to change that class name to reflect the name of this module and because it was shorter for the purposes of TemplateStyles, so I added nomobile as a result." It doesn't say why, but the fact nothing can be collapsed on mobile will surely be one of the reasons for this.
nomobile is actually a hack, quote from User talk:Jon (WMF)#nomobile is my current annoyance today: "as the Minerva maintainer I'd love to remove the `nomobile` class in the Minerva skin eventually. Now all that said I wouldn't rely on `nomobile` at all to be honest. It was a short term fix for a long term problem. If you are using TemplateStyles just add a media query and display: none anything that you don't want to show on mobile and avoid the class entirely. There's no need to rely on it. Sure this will increase the HTML payload of mobile, but leave that to us WMF staff - we can always add rules for DOM-heavy elements at a later date."
The overall sentiment seems to be that navboxes should be enabled on mobile. See also phab:T124168. In what exact form is TBD, but one thing seems clear: without the ability to make elements collapsible on mobile, it can't ever happen. As a side note, the proposed gadget has one extra trick up its sleeve: it enables the creation of elements that are collapsible on mobile but don't become collapsible on desktop. This would make it possible to make long lists or tables collapsible on mobile only, potentially saving mobile users from some lengthy scrolling. Update: this mobile-only feature has been commented out for now and may be revisited if the gadget gets enabled as a default gadget. This gadget now more purely aims to replicate the functionality of the desktop site without alterations. — Alexis Jazz (talk or ping me) 01:32, 4 September 2023 (UTC)

The reason these don't display on mobile is partially the display. But a bigger reason is that navboxes do not suit the mobile need, which is predominantly get in and get out with the desired fact. This quality, combined with the basically useless and usually quite large HTML downloaded just to inevitably not need a navbox is why these are "disabled". (Why yes, MobileFrontend does rip them fully out of the HTML.) IznoPublic (talk) 15:45, 6 September 2023 (UTC)

Question - As a Gadget, would this be enabled for logged-out users? –dlthewave ☎ 14:35, 3 September 2023 (UTC)

Dlthewave, the way I phrased the proposal ("installed and enabled by default"), yes. However, if many votes include the condition that it be made opt-in I would consider that a valid outcome as well. If it would be enabled by default it would allow editors to assume the feature is available to mobile users when writing templates and articles which won't be the case if it's opt-in, but c'est la vie. If the proposal passes (without opt-in condition) the gadget will be deployed in waves. At first it'd be enabled for admins only and every week or so another group would be added: WP:extendedconfirmed, wp:autoconfirmed and finally everyone (including logged-out users). — Alexis Jazz (talk or ping me) 01:44, 4 September 2023 (UTC)

Good! I wasn't quite sure how gadgets worked, wanted to make sure it would eventually be available to all users. –dlthewave ☎ 02:44, 4 September 2023 (UTC)

Dlthewave, a gadget is a collection of JavaScript and/or CSS pages, similar to WP:User scripts. Unlike user scripts, they are centrally governed in MediaWiki:Gadgets-definition. Some gadgets, for example mw:Reference Tooltips, have the "default" parameter set in MediaWiki:Gadgets-definition, those are enabled and loaded by default. The wording "enabled by default" in the proposal refers to the default parameter in Gadgets-definition. — Alexis Jazz (talk or ping me) 06:57, 4 September 2023 (UTC)

Thanks for working on this. I left some suggestions for the implementation at Wikipedia talk: MakeMobileCollapsible.

Before enabling the gadget, please consider whether the "mobile-only collapsible" feature is really desirable. Personally I think we should avoid adding any mobile-only and desktop-only features these days, to avoid confusion for people who only use desktop or only mobile and see different things. It might also lead people to use collapsible elements in cases where other approaches would be better (per MOS:COLLAPSE): moving the content to a separate section (which are already collapsible on mobile, and easier to navigate using the TOC on desktop), or to a separate page – and since it would be mobile-only, the desktop power-users might not notice it.

And while we're talking about MOS:COLLAPSE, it will need some updating about the mobile support. Matma Rex talk 12:33, 4 September 2023 (UTC)

Matma Rex, interesting points. I added the "mobile-only collapsible" feature because it was easy and I believe there is a difference between mobile and desktop here: scrolling is more labor-intensive on mobile devices as you have no page up/page down keys and dragging the scrollbar is more difficult without a mouse or touchpad. If it turns out the feature goes unused or causes people to use less optimal approaches it could be removed easily and any existing uses could be updated by a bot in that case.
Header levels above level 2 don't become collapsible on mobile. I guess the only way to find out if it's a good idea is to just see if and how people would use it. If people don't use it or only use it when other approaches would be better, it could be scrapped at a later point. Btw, one way to use that feature is to combine mw-collapsible with mw-collapsed-mobileonly, resulting in a collapsible element on both mobile and desktop but which is only collapsed by default on mobile. I also think mobile-only collapsing could be an alternative for the nomobile class in some cases. — Alexis Jazz (talk or ping me) 13:32, 4 September 2023 (UTC)

Firefox won't even let me drag the scrollbar. It only supports manual scrolling. On the pages I linked to in my not-vote, it might take me forty or sixty seconds to scroll all the way down to what I'm tryna read. Usually I end up all the way at the foot of the page and have to work my way back up, but too aggressive of an upscroll will – alas – trigger a page reload. Anything to help ameliorate this would be quite welcome. Folly Mox (talk) 18:11, 4 September 2023 (UTC)

While we're on this tangent, adding a collapsibility to level three subheadings, defaulted to uncollapsed, would be pretty nice. Some of those get real long, and it would be convenient to collapse them if I'm editing them one after another. Folly Mox (talk) 18:31, 4 September 2023 (UTC)

I agree with Matma Rex here: let's not introduce mobile specific behavior, especially since that's not the primary point of the change we're trying to make here. (And were you going to do it, using the same class namespace as core functionality is a bad idea "mw-".) IznoPublic (talk) 15:51, 6 September 2023 (UTC)

@Matma Rex, what specifically needs updating about MOS:COLLAPSE? IznoPublic (talk) 15:48, 6 September 2023 (UTC)

For example this part: "the mobile version of the site, which has a limited set of features and does not support collapsing". Matma Rex talk 16:50, 6 September 2023 (UTC)

It... Doesn't, still. We just went from "displays nothing" to "displays everything", so I think that statement remains valid. (Perhaps less than obviously the context of that section ignores MF collapsing whole sections.)

As for limited set of features for mobile, yeah, less true, but also not totally relevant to that section, so removing it in toto might be called for. Izno (talk) 00:20, 7 September 2023 (UTC)

Oh, "will need". Missed the auxillary verb. Izno (talk) 00:36, 7 September 2023 (UTC)

Matma Rex, following your and Izno's comments, I commented out the mobile-only collapsing feature for now. If the gadget gets enabled by default I plan to open a discussion on enabling it again. Maybe in some more limited form, like only changing the default collapse state on mobile. For now, the gadget just aims to replicate the collapsing functionality from the desktop site. — Alexis Jazz (talk or ping me) 12:34, 7 September 2023 (UTC)

• Mobile viewers should be able to see the same templates as desktop users. It's somewhat baffling to me that we have different versions of the site for desktop and mobile viewers. The latter cannot, for example, expand a {{cot}} or a {{hat}} (why?). Many navigation templates in articles are just unusable on mobile, meaning that if you want readers to actually be able to see what you're writing, you must include it twice. jp×g 21:32, 19 September 2023 (UTC)
  • JPxG, the answer to your "why?" question is in the background info: The reason some oppose making the change in MediaWiki core is the "fat finger problem", some people may have difficulty to tap short links titled "Hide" or "Show". The proposed gadget alleviates this issue by enforcing a minimal link element width of 6em.
    This is why jquery.makeCollapsible doesn't get loaded on the mobile site. The proposed gadget loads jquery.makeCollapsible on the mobile site. @Awesome Aasim, I should have mentioned it in my reply to you above some time ago, but jquery.makeCollapsible is the module that I was talking about. A WMF developer suggested that individual projects should load this module using MediaWiki:Common.js or a gadget, so this isn't expected to break anything in the future. — Alexis Jazz (talk or ping me) 22:31, 19 September 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC about the criteria for existence of emoji redirects

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)

Initial options

Option 1: All emoji redirects should target lists of symbols by default, such as emoji which appear on Supplemental Symbols and Pictographs or Symbols and Pictographs Extended-A. Option 2: Emoji redirects should only target pages where the emoji is directly mentioned or referred to, such as Face with Tears of Joy emoji. All other emoji should instead exist as redirects to relevant lists of symbols. Option 3: Emoji redirects should only target pages where the emoji's depiction is deemed unambiguous, such as 🔥 being a redirect to fire. All other emoji should instead exist as redirects to relevant lists of symbols. Option 4: Emoji redirects should only target pages where the emoji's depiction is deemed unambiguous, such as 🔥 being a redirect to fire. All other emoji with ambiguous designs should be deleted, and not target lists of symbols. Option 5: Emoji redirects should only target pages where the emoji is directly mentioned or referred to, such as Face with Tears of Joy emoji. All other emoji redirects should be deleted. Option 6: Delete all emoji redirects.

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)

RFC could use some additional input

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This infobox discussion on Georges Feydeau is wrapping up and could use some more input. All feedback is welcome to help find a consensus. Thanks! Nemov (talk) 19:35, 30 October 2023 (UTC)

Given you already posted on this RFC when it opened, is it the best use of this noticeboard to keep posting reminders to the same process? - SchroCat (talk) 20:07, 30 October 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Petition on change.org for English Wikipedia to use curly quotes instead of straight quotes

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Would you please consider the change.org petition for Wikipedia to change the Manual of Style to require curly quotes instead of straight quotes in articles? --Agusbou2015 (talk) 18:24, 1 November 2023 (UTC)

Considered and  Not done. Remsense聊 18:25, 1 November 2023 (UTC)

How about no? Bon courage (talk) 18:26, 1 November 2023 (UTC)

I regret that you have refused to act on this petition, but I would like to know the reasons for this refusal. --Agusbou2015 (talk) 18:39, 1 November 2023 (UTC)

Wikipedia operates according to WP:CONSENSUS, not external pressure. If you have a proposal, make it at WT:MOS. Bon courage (talk) 18:43, 1 November 2023 (UTC)

@Agusbou2015 Please see Wikipedia:Manual of Style#cite_note-curlyq-7. If you have arguments to make, you're welcome to make them here or at the Manual of Style talk page. AntiCompositeNumber (talk) 18:43, 1 November 2023 (UTC)

In case anyone else had difficulty finding it, the petition can be found by searching for "wikipedia curly" on that website (which I can't link as it's blacklisted). It has been running for five years and has attracted 159 signatures and has three comments, all from the proposer. Certes (talk) 20:33, 1 November 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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)

Automatic talk page banners

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)

Rule that will cover anachronistic informations in the articles

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)

To create an Editor Communication Feedback noticeboard

See also: Wikipedia:Village pump (proposals)/Archive 116 § Do Away with RFC/U

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)

Determining the future of B-class checklists

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)

3D models in infoboxes

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)

Bot to empty out Category:Talk pages with comments before the first section?

(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)

(redundant) Find general sources template

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)

RfC: Increasing the maximum size for uploaded files

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should the maximum size for uploaded files be increased from the previous technical limit of 4GB to the current technical limit of 5GB? — Alexis Jazz (talk or ping me) 21:24, 9 November 2023 (UTC)

Background (increasing the maximum size for uploaded files)

This would be achieved by requesting a configuration change to increase $wgMaxUploadSize for English Wikipedia. Previously this couldn't be set any higher than the current 4GB (the file size used to be stored as a 32 bit unsigned integer), but that technical limit was recently lifted: phab:T191805. The new technical limit of 5GB is a limit of OpenStack#Swift.

There is no actual downside to doing this.

Use cases on English Wikipedia are somewhat limited (Commons has more use cases, but they'll need to run their own RfC) but over the coming years various feature films will become {{PD-USonly}} and those can't be uploaded to Commons. Uploading them with the best available quality may require more than 4GB in some cases. While it's only a minor improvement, 5GB is 1GB better than 4GB.

Survey (increasing the maximum size for uploaded files)

• Support as proposer. No downside, could be useful in some cases. — Alexis Jazz (talk or ping me) 21:24, 9 November 2023 (UTC)

Discussion (increasing the maximum size for uploaded files)

Is there a way to see some examples of where large files like this are used on Wikipedia? I must admit I would have imagined the existing limit to be set much lower. Barnards.tar.gz (talk) 21:57, 9 November 2023 (UTC)

Barnards.tar.gz, I think that would be [14]. Over the years there have been various unrelated issues that limited the maximum file size and various files have been moved to Commons so it would seem the largest file is currently just shy of 300MB: File:Nosferatu (English version).webm. That is a PD-USonly feature film though. It happens to be a standard definition capture, but analog film has no fixed resolution. For example, here's a 1080p version of Faust (1926 film): https://archive.org/details/faust-1926-1080p. There's a higher bitrate version out there, but this one is already 1.7GB. It would probably end up being bigger here as it's most probably using the HEVC codec. (I can tell you in about half an hour once my download finishes..) MediaWiki streams/transcodes files with a less efficient codec (VP9) for compatibility and patent reasons, so expect that movie to be bigger if/when uploaded here.
Edit: here's Die Nibelungen, only 40GB: https://archive.org/details/silent-die-nibelungen-siegfried. That would have to be transcoded anyway, but a 5GB transcode will be better than a 4GB transcode. — Alexis Jazz (talk or ping me) 23:10, 9 November 2023 (UTC)

This does make me wonder whether Wikipedia is the right place to host these kind of files and whether we should be enabling/encouraging it by having the maximum upload size set as high as 4GB. Archive.org, Wikisource, and Wikimedia Commons all seem like better options. If File:Nosferatu (English version).webm is PD-USonly, does that mean it's non-free, and if so, how does hosting the full movie comply with items 2 and 3 of the non-free content policy? Barnards.tar.gz (talk) 09:27, 10 November 2023 (UTC)

PD-USonly is free content for the purposes of Wikipedia policy. Jo-Jo Eumerus (talk) 09:54, 10 November 2023 (UTC)

Does Commons allow the upload of files this large? Because if so, we can simply send people there for most files (I can't imagine how a 4GB non-free file could meet the "minimal use" provision of the non-free policy). Jo-Jo Eumerus (talk) 09:55, 10 November 2023 (UTC)

@Alexis Jazz: While we are happy people are excited about the possibility of larger media files, I would suggest you pause any discussion yet on that. This option is NOT available for English Wikipedia yet- what you saw is that it will be available for MediaWiki software on next release (that is the software changelog), but it is not yet ready for Wikimedia sites, and it will take some time to be ready (as you can imagine, preparing the storage at our scale for such a change takes time, and we have yet to discuss the implications of it among infrastructure maintainers. It will be announced properly when it is ready. Technical details at: phabricator:T191804#9321802 --JCrespo (WMF) (talk) 09:56, 10 November 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Shorten most clean up messages to two sentences

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)

RfC on Module:Find sources - replace New York Times with Associated Press

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

This RFC presents two questions as one, so I'm going to have to split them in order to determine consensus. First, there is no consensus to remove the NYT from Module:Find sources. There were decent arguments, and counter-arguments on both sides. Most of the discussion focused around accessibility and width of focus, with some discussion taking place about the political POV. Accessibility was the biggest bone of contention, with strong points on both sides. Cullen328 made a strong argument that quality sources often have paywalls, and that the depth and analysis provided by a newspaper, rather than by a news service, is valuable. This was echoed in many other statements. Those supporting the removal point out that the vast majority of our readers cannot access the source, and Levivich makes a strong point that the ease that some see in getting access to the NYT is certainly not true for all. The Americacentric reporting was also brought up, as was that NYT does provide international coverage, and BluePenguin18 points out that they provide international coverage that AP does not.

All of that said, while the arguments on both sides are good, neither did much to sway the other side, and neither is an over-the-top slam dunk that destroys the other. With the numbers being fairly close that leaves us at a solid no consensus.

The second question at issue is the adding of AP to the module. I see consensus to include AP in the module. Many of those opposing the removal of the NYT supported the addition of AP and other sources.

There seems to be a reasonable consensus that other sources should be included, which would have to be addressed in another discussion. That the module should provide a way to search sources, rather than for articles from a single source, was also brought up by multiple editors. This didn't gather much traction in this discussion, but it may be worth a more focused discussion in the future. ScottishFinnishRadish (talk) 23:23, 15 November 2023 (UTC)

---

Currently, the only media outlet in Module:Find sources/templates/Find sources is the newspaper The New York Times (nytimes.com). Should we replace it with the news agency Associated Press (apnews.com)? Previous discussions here and here. starship.paint (RUN) 04:18, 9 September 2023 (UTC)

Survey (Find sources: NYT vs AP)

• Support as proposer on these three fronts. (1) Accessibility: The New York Times requires a paid subscription to read, the Associated Press does not. We should avoid paywalls for our editors and readers. (2) Content focus: The Associated Press is more internationally focused and operates in 94 countries, while the New York Times is more U.S.-focused and operates in around 30 countries. (3) Less biased: The Associated Press has been rated as less left leaning, and more neutral, than The New York Times by two media bias assessors - Media Bias Fact Check on NYT versus AP, AllSides on NYT versus AP. starship.paint (RUN) 04:20, 9 September 2023 (UTC)
  • I'd also like to add that I did not propose news agency Reuters as it requires registration, while news agency Agence France Presse doesn't seem to actually post news articles on its website? Or maybe it is here but you need a login? starship.paint (RUN) 04:28, 9 September 2023 (UTC)
• Support per nom, with particular emphasis on (1). Directing editors to a source which requires a paid subscription after opening five(?) articles is just not best practice. In addition to making it more difficult for editors to find sources initially, it also has the potential knock-on effect of increasing the number of citations to the NYT in mainspace, citations which are more difficult to verify than those to free sources (this is a dumb concern and I'm dumb for saying it.)
  Associated Press is internationally regarded as – at minimum – a pretty good press agency. It should be more than adequate as a replacement suggestion in this module. The main downside I can think of is that Citoid works impeccably with the NYT, always correctly resolving authorship and publication date, only missing the |url-access=subscription parameter. I don't remember if AP always works so consistently, although it might. Folly Mox (talk) 04:53, 9 September 2023 (UTC) edited 08:20, 9 September 2023 (UTC)

  Oh no, now I remember that Citoid does correctly identify the important parameters from AP sources, but invariably chooses to render the |work= parameter in all caps, as "AP NEWS". Pretty trivial downside all things considered. Folly Mox (talk) 05:04, 9 September 2023 (UTC)

  Not at all opposed to just adding more sources, for clarity. Folly Mox (talk) 08:22, 9 September 2023 (UTC)

  Speaking of ALL CAPS, what's annoying about citiod and the NY Times is that it doesn't handle the historical NY Times style of ALL CAPS headlines.. It's annoying having to manually convert those into title case as required to pass a GA review (I can't actually find anyplace in the MOS which requires that, but reviewers seem to insist on it). RoySmith (talk) 21:24, 14 September 2023 (UTC)

  I also find Conde Nast publications pretty annoying because Nast, Conde always seems to be the byline. Valereee (talk) 16:28, 15 September 2023 (UTC)

  Heh. I took a look at the HTML they generate:

  <head>...<meta name="author" content="Condé Nast">...</head>

  So, yeah, we're just believing what they tell us. RoySmith (talk) 16:47, 15 September 2023 (UTC)

• Support AP, and other options as well. I think that the NYT, nothing against it as a reliable source, should not be considered the most reliable source and promoted the same way as it is. The NYT is nowhere near deprecation like the Daily Mail, but it should be treated as a source with a lean-left American bias. I personally think that the AP and Reuters are best, and for non-Qatari content, Al Jazeera should also be encouraged due to its general lack of bias on non-Qatari topics based on its ownership. Inclusion of the NYT should only be in concurrence with a counter-balancing reliable source, such as the Wall Street Journal. InvadingInvader (userpage, talk) 04:57, 9 September 2023 (UTC)
• I'd be happy to see apnews.com on the list, but why "replace"? Why not just "add"? WP:PAYWALLED sources are okay. I'd be happy to see half a dozen news sources. Maybe we need to add the BBC and The Globe and Mail, too. WhatamIdoing (talk) 05:25, 9 September 2023 (UTC)
  • Using paywalled sources is okay, but what we are doing here is recommending a paywalled source to everyone, which would surely cause inconvenience to non-subscribers as the paywall can prevent them from reading article text. Why make life harder in this way? starship.paint (RUN) 06:55, 9 September 2023 (UTC)

    I don't think that convenience is the right way to measure news. First of all because it's not a primary factor when selecting verifiable sources, but also because convenience seems to be a placeholder for free. The first AP news article I opened was indeed without up-front cost, but has infinite tracker-laden Tablooa spam all over it; that is definitely not convenient from a privacy or bandwidth perspective. In practically all other areas of Wikipedia, sources are measured by the fundamental quality they bring to the encyclopedia, and I don't see why news should be treated differently. Orange Suede Sofa (talk) 07:26, 9 September 2023 (UTC)

• Oppose removal of the NYT -- as has been pointed out elsewhere on this page the NYT's factual reporting is neutral, and removing something because it has a paywall I think is a mistake -- we should recommend the best sources, not the most accessible ones. I'd be fine with adding other reliable sources, including the AP, as WhatamIdoing suggests. Mike Christie (talk - contribs - library) 07:12, 9 September 2023 (UTC)

  this is a distraction. no discussion supported "addition of nyt" https://wiki.riteme.site/w/index.php?title=Module%3AFind_sources%2Ftemplates%2FFind_sources&diff=prev&oldid=722553515 . you first need to find support for "addition of nyt", before debating about its "removal". RZuo (talk) 09:35, 9 September 2023 (UTC)

  @RZuo, -- and to be clear, this is not a comment on the proposal, just on this argument, which you've made several times -- it's not actually correct that there had to be some discussion supporting the addition before it was made. The addition was made in (2016? too lazy to check) and apparently created no controversy at the time. The fact it's remained this long, even with occasional discussions about removing it, is the evidence for consensus. You'd be better off dropping this argument and simply arguing merit rather than process. Valereee (talk) 11:41, 9 September 2023 (UTC)

  Wikipedia:Consensus#Through_editing: "An edit has presumed consensus until it is disputed or reverted."

  Wikipedia:Silence_and_consensus#Silence_is_the_weakest_form_of_consensus: "Consensus arising from silence evaporates when an editor changes existing content or objects to it."

  even if there ever were any implicit consensus, it has evaporated no later than 2018. RZuo (talk) 12:46, 9 September 2023 (UTC)

  I'll answer at your talk, as this probably is becoming tangential. Valereee (talk) 12:49, 9 September 2023 (UTC)

  @RZuo, I'm having a hard time interpreting this as meaning anything but that you don't actually want to discuss unless it's in a public forum? Trying really hard to AGF here...why did you delete that instead of responding? Would you prefer I explained it here, where it doesn't really add anything? I was trying to avoid distracting people from the question at hand. Valereee (talk) 18:48, 9 September 2023 (UTC)

  I just wanted to comment, whether or not there is pre-existing consensus for somethings inclusion does not make an editors !vote to include it any less valid. Googleguy007 (talk) 14:44, 26 September 2023 (UTC)

  "...and removing something because it has a paywall I think is a mistake -- we should recommend the best sources, not the most accessible ones." I'm pretty sure no one has had this discussion with the small group of editors who have been allowed to WP:OWN the recent deaths lists. For years and years, I observed an obsession with replacing sources because of paywalls and "European access blocks", while at the same time observed no regard given to malicious links and links leading to geographically distant sources who regurgitate someone else's content in order to provide an additional venue for their array of clickbait ads. Sourcing in general throughout the encyclopedia leaves a lot to be desired. RadioKAOS / Talk to me, Billy / Transmissions 03:03, 13 November 2023 (UTC)

• Oppose removal of NYT, support addition of AP - No special fondness for NYT, but in the areas I edit in, it's more useful than AP. I agree with the editors saying having a greater mix would be better. Red Fiona (talk) 14:14, 9 September 2023 (UTC)
• Support - for the above reasons as articulated by starship.paint. The associated press I think it is fair to say, is a source moreso associated with worldwide NPOV viewpoints than the NYT. On pages like this sources like the AP are preferable as to avoid centering the US perspective. Wikipedia can and should be more than an American website Jack4576 (talk) 11:55, 9 September 2023 (UTC) {this is a copied comment}
  • Note: I copied this over from my talk page because Jack4576 is blocked from Wikipedia-space pages like Wikipedia:Village pump, but Jack4576 has said that he is not topic banned from Wikipedia-space. starship.paint (RUN) 14:48, 9 September 2023 (UTC)
• Support removal of NYT because of the paywall, and therefore support addition of AP in its place. I could propose a scheme where ENWP would establish a floating account with the name of Nicholas Bourbaki to read NYT articles, but that would be too complicated and weird. We need our reliable source to be accessible, because most of us have the disability of not having paid the NYT. Robert McClenon (talk) 16:13, 9 September 2023 (UTC)
• Oppose removal of the NYT for reasons described in the previous discussions and mentioned below. The NYT is an excellent, top tier source that is exactly the kind of thing that should be offered as a suggestion, including for non-American news. I have no opinion on the AP, but the decision should be whether to add the AP, not to replace the NYT with the AP. SnowFire (talk) 04:30, 10 September 2023 (UTC)
• Support As I said previously, a choice is better but no real reason to prefer NYT (or the BBC) over a global news source.Selfstudier (talk) 14:14, 10 September 2023 (UTC)
• Support as proposed, still, for the reasons listed in the nomination and that I gave in the last discussion. We don't need to clog talk pages with multiple listings in "Find sources", and AP is international, not paywalled, and neutral. SandyGeorgia (Talk) 22:15, 10 September 2023 (UTC)
• Oppose as the NYT is a high quality source and has more in-depth coverage in some areas than the AP; though I do agree with the argument that it is too US-centric. I think we shouldn't favour one publication over all others though, so the most ideal option in my mind would be to add multiple sources or remove all sources and make the "WP refs" search (which retrieves results from plenty of newspapers including both NYT and AP) more prominent. ― novov (t c) 07:55, 11 September 2023 (UTC)
• Support Removal of NYT. Oppose adding of AP. I absolutely understand the frustration of New York Times paywalls. However, I don't think switching to another for-profit journalistic source is the solution. We can maybe also link to NPR, PBS, CBC, BBC, (Australia)BC, and other not for profit journalism that is more in line with our goals. Aasim - Herrscher of Wikis ❄️ 17:11, 11 September 2023 (UTC)

  Can you clarify "more in line with our goals"? A news source that is non-profit is not more in line with our goals as an encyclopedia than one with a reputation for high-quality journalism, even though it might align ideologically. Mike Christie (talk - contribs - library) 13:18, 15 September 2023 (UTC)

  I am not doubting that NYT is high quality journalism. But public broadcasters and several news sources are not incentivized by advertising in general. The removal of NY Times is less to do with its quality as it has to do with being able to ensure that Wikipedians are able to quickly access a good source for stuff like WP:V and WP:N. Aasim - Herrscher of Wikis ❄️ 13:25, 15 September 2023 (UTC)

  I'm all for "information should be free", and would certainly support adding entries for other sources, but we would be shooting ourselves in the foot if we started down the road of deprecating sources behind paywalls just because they're behind paywalls. Full disclosure: I'm a paid NYT subscriber. RoySmith (talk) 13:48, 15 September 2023 (UTC)

  I never said that NYT should be deprecated. Only that it should not be included in {{find sources}}. If there is a way to access NYT through programs like WP:TWL then that is what should be linked. Aasim - Herrscher of Wikis ❄️ 14:13, 15 September 2023 (UTC)

  Removing it from {{find sources}} is a step down that road. I agree it would be wonderful if the NYT were available through WP:TWL, but whether it is or not should not be a factor in how we treat it as a source. RoySmith (talk) 14:17, 15 September 2023 (UTC)

  Maybe I misread the question, but I thought this was about {{find sources}} for a minute, not the associated module. I think the only entries that should be listed there are those related to what the module is for - finding sources. Linking to one publisher in the module is not "find sources", it's "find source". In other words, I only think search engines querying a wide variety of databases and curated news reports across the world should be there. Google News and Bing News which in turn pull up articles from NYTimes and AP and other high (and low) quality sources will suffice enough. Aasim - Herrscher of Wikis ❄️ 14:33, 15 September 2023 (UTC)

  That's a much more acceptable (to me) argument. RoySmith (talk) 14:52, 15 September 2023 (UTC)

• Support removal of NYT. Oppose adding AP. I don't like the idea of promoting one or two specific media outlet(s) above others. Perhaps a set of several, but that's not really in scope for this RFC. —siroχo 17:46, 11 September 2023 (UTC)
• Oppose addition of AP. The value of having nytimes.com comes from its archival nature. Searching there returns matches dating back to 1851. On apnews.com, on the other hand, I can't even find an article from earlier than 2021. It's pretty clear which is useful for a wider range of subjects. If regionality is a concern, replace it with Google Newspapers (I'm surprised it's not there). Nardog (talk) 07:37, 12 September 2023 (UTC)
• Oppose removal of the New York Times, which is by far the best and most comprehensive US newspaper source. Most high quality journalistic sources are behind paywalls these days. I subscribe to several paywalled sources and limit my usage of others that restrict my access to X articles a month or whatever. But I will never support any limits on or any discouragement of other editors using paywalled sources. The Associated Press is great for routine coverage of breaking news and the like, but it is a news agency, not a newspaper. AP does not decide which of their content that actual newspapers run. Those decisions are made instead by actual living and breathing newspaper editors. The AP does not cover stories with anywhere near the depth or breadth that the New York Times does. Or the Washington Post, the Wall Street Journal, the Los Angeles Times, the San Francisco Chronicle and many others, or my little hometown paper, The Union, which has been published since 1864. It would be a terrible mistake to start down the path of deprecating sources behind paywalls. That is where the very best journalism can be found these days. The expectation that outstanding journalism can always be consumed for free is pernicious, and will lead to the death of independent journalism if followed to its logical end. Cullen328 (talk) 08:03, 12 September 2023 (UTC)

  +1! Donald Albury 14:46, 12 September 2023 (UTC)

  then why nyt? why not the union or wsj? RZuo (talk) 14:31, 14 September 2023 (UTC)

  Well, this proposal was to replace NYT with AP. Any other outcome will require a new RfC. Donald Albury 17:17, 14 September 2023 (UTC)

  for anyone who still hasnt read the discussion or understood the origin of this rfc: nyt was added without any consensus or discussion https://wiki.riteme.site/w/index.php?title=Module%3AFind_sources%2Ftemplates%2FFind_sources&diff=prev&oldid=722553515 , so any user supporting using nyt should first explain why nyt should be chosen over any other sources.

  yet i could readily give 2 reasons why for example wsj is a better us newspaper than nyt. RZuo (talk) 07:24, 15 September 2023 (UTC)

  RZuo, Valereee responded to this argument of yours, above and on your talk page, giving what I would consider good reasons for discounting your point. You've ignored their post above and silently deleted their post from your talk page. If you're going to continue making this argument I think it would be helpful if you explained why you disagree with their response. Mike Christie (talk - contribs - library) 14:04, 15 September 2023 (UTC)

  RZuo, I'm not sure it's fair to assume the edit was made with no discussion simply because no discussion was referenced in the edit summary. The editor who made that edit thinks there had been discussion. The fact no one has dug it out doesn't mean it doesn't exist. As I mentioned at your talk, we should at minimum assume good faith on that. This argument, which you have made over and over again, including after objections, is starting to feel like an intentional unsupported accusation of bad faith. Valereee (talk) 16:12, 15 September 2023 (UTC)

  instead of busy lecturing other users, you two can answer the question at hand instead: why is nyt chosen over all other sources? RZuo (talk) 18:23, 15 September 2023 (UTC)

  I've given my reasons for keeping the NYT in my !vote above; I have no objection to adding other sources. Mike Christie (talk - contribs - library) 19:19, 15 September 2023 (UTC)

  did you know whether you answered why nyt is chosen over all others? no?

  you merely said nyt is neutral.

  many more newspapers are neutral. many more are more neutral than nyt. RZuo (talk) 20:35, 15 September 2023 (UTC)

  I don't know why it was chosen, but I assume it was because some 2016 discussion suggested it. I can't know because I haven't seen the original discussion which, as someone AGFing, I assume happened. It doesn't mean it was the best choice, it doesn't mean consensus hasn't changed since, and I'm completely open on the question.

  @RZuo, I am going to tell you: stop making unsupported accusations of bad faith. The fact this pisses you off does not mean you can accuse another editor of intentionally operating in bad faith without evidence. Valereee (talk) 19:31, 15 September 2023 (UTC)

  @Valereee:

  1. you're making a claim without evidence. that's not what "assumption of good faith" means. you better stop.
  2. you're falsely accusing me of assumption of bad faith. you better stop. i've been asking a simple question, which any supporter of nyt can answer, regardless their awareness of a non-existent discussion you're handwaving to.

  RZuo (talk) 20:29, 15 September 2023 (UTC)

  You've accused another editor of intentionally acting in bad faith. Your first intimation was here. You accused the other editor of editing without discussion or consensus, implying BOLD didn't exist or apply and that because there was no mention of a discussion in the edit summary, there was no discussion, even though the other editor said they thought there was discussion, here and here and here and here. I objected here and here. You ignored/deleted my attempts to discuss.

  I literally have no opinion on this question. Please explain what you mean by "handwaving to", as I am not sure what you're saying. Valereee (talk) 21:49, 15 September 2023 (UTC)

• Oppose removal of the NY Times. It has a comprehensive archive and most stories contain an attributed author. Not opposed to adding additional sources. --Enos733 (talk) 21:06, 14 September 2023 (UTC)
• Oppose Absolutely not. The NYT is, in my view, the single most high-quality respected news publication in the Western world of all time. InfiniteNexus (talk) 00:43, 15 September 2023 (UTC)

  This a bit of an WP:ILIKEIT argument, and one underpinned by a healthy dose of Americo-centrism. Tomorrow and tomorrow (talk) 05:47, 1 November 2023 (UTC)

• Support defaulting to a global source focused on factual reporting improves Wikipedia's neutrality. – Teratix ₵ 00:44, 21 September 2023 (UTC)
• Oppose removal, but support addition. In general, I would have multiple newspapers listed, rather than just one. Google has been getting shittier and not pulling up everything. AP, WaPo, AFP, Reuters, etc. would all be useful, in addition to the NYT. The NYT is still a very reliable source for information, globally. SWinxy (talk) 04:13, 21 September 2023 (UTC)

  I have a love-hate relationship with Google search. On the one hand, they're the most comprehensive compendium of what's available on the internet; any search for sources which didn't include Google in some way is clearly defective. On the other hand, I hate how much information Google collects about their users, and from a more practical point of view, the results they give are biased by your previous browsing (and other application use) history. I use Duck-Duck-Go as my everyday search engine, but I still do Google searches as needed to ensure complete coverage.

  As for WaPo, I think they're a great news source. I maintain paid subscriptions to both NYT and WaPo. On the other hand, I recognize that those two papers overlap in both their US-centric coverage (obviously they have great international coverage, but overall, US-centric) and in their political biases (i.e. liberal-leaning). I would like to see more news outlets listed, but we should make an effort to cover both the political spectrum and geographic diversity. Surely we can satisfy that without compromising on journalistic excellence. RoySmith (talk) 14:54, 21 September 2023 (UTC)

• Oppose on all points. The Wikipedia Library represents WMF recognition that the highest-quality reliable sources often exist behind paywalls. Google News is linked for those who can only afford free sources, allowing for focus on the NYTimes' comprehensive reporting and archives stretching to 1851 at a cost of $4/month. As for international coverage, counting national bureaus is hardly indicative of the breadth of reporting. For example, neither news organization maintains a permanent office in Vanuatu, but only the NYTimes website offers pre-2021 coverage and has far more long-form reporting on the island nation. Lastly, Media Bias Fact Check and AllSides are not objective determinations of media bias. One can argue that the NYTimes' in-depth coverage necessitates fact-finding that exposes it to further claims of bias. BluePenguin18 🐧 ( 💬 ) 23:49, 23 September 2023 (UTC)
• Support adding AP on the basis that it's less USA-centric: on many articles where it's included, this template is useless because there's nothing useful to be found. Paywall status is relevant but I'm not sure it's dispositive here: AP will probably become paywalled like Reuters at some point, and NYT is very easy to access for free on any privacy-conscious browser or through the Internet Archive. I'm also ok with outright removing the NYT or replacing it with some of the other sources mentioned like The Guardian, for reasons given by others above. Nemo 16:03, 24 September 2023 (UTC)
• Support removing NYT and adding AP. Though they are equivalent in quality and bias, AP is easier to access (no paywall) and more international than NYT. Levivich (talk) 16:36, 24 September 2023 (UTC)
• Support: AP is easier to access, more international and less biased. a455bcd9 (Antoine) (talk) 07:47, 26 September 2023 (UTC)
• Oppose removal Proposer's rationale for removal are unconvincing, including false claim about "left-leaning" factual reporting, as opposed to editorial stance. Other sources can be added to address other of OP's concerns, e.g. Reuters, NPR, BBC, AP... SPECIFICO talk 19:19, 26 September 2023 (UTC)
• Support removal (from Template:Find sources, Template:Find general sources, and similar). This is not a free-floating debate about how good of a source the New York Times is. This is about what gets included in templates plastered indiscriminately across AfCs, AfDs, talk page headers, etc. There should be as little as possible; less is more. What gets included should be of exceptionally broad and global applicability, and (like a point made by Aasim above) should consist only of tools to actually "find sources" and not any particular source or publisher. Adumbrativus (talk) 10:38, 28 September 2023 (UTC)
• Support - Never paid for paywalled stuff and never would when there's free alternatives out there, I do agree with Cullens point 99% of those alternatives won't be as good as NYT but I also don't believe it's useful to anyone linking to paywalled articles when like I say there's free alternatives out there. I would also support BBC over AP but that's just me personally. –Davey2010^Talk 11:00, 28 September 2023 (UTC)

  Nothing under discussion requires use of a paywalled site. SPECIFICO talk 19:28, 7 October 2023 (UTC)

• Support - no point leading readers to a site that the VAST majority cant view. Our goal should be to guide readers to a place that will be accessible for the research the template is intended for.Moxy- 19:22, 12 October 2023 (UTC)
• Oppose. The New York Times has an enviable world-level reputation for fair and accurate reporting. We should always make every effort to use the very best sources available to us, and this is surely one of them. There's no paywall, just a minor (but rather aggravating) pay-obstacle – if you can't read a particular article online, all you need to do is go to the public library and read it there. The walk will probably do you good. Justlettersandnumbers (talk) 19:49, 12 October 2023 (UTC)

  Kind of a privileged, first-world take. Not everyone has a public library at all, or in walking distance, or can walk, and not every public library subscribes to NYT. Levivich (talk) 20:56, 12 October 2023 (UTC)

  That's a reason to provide other sources that are more universally accessible, certainly. I don't see it as a reason to remove a high-quality source that many editors can indeed access. Mike Christie (talk - contribs - library) 21:18, 12 October 2023 (UTC)

• Oppose False dichotomy, just add both. Curbon7 (talk) 21:40, 12 October 2023 (UTC)
• Support People here might be surprised that Americans who are left of center consider the NYT to be part of the corporate media which sucks up to the PTB. Despite having Paul Klugman on its staff. (And by "left of center" I mean individuals who are far more moderate than members of the Party for Socialism and Liberation. More accurately labeled progressive Democrats.) A chronic problem of the US mainstream press is this baffling need to "present a balanced view", which always means giving more attention to conservative POVs, & the NYT is as guilty of this as practically every other US publication. -- llywrch (talk) 23:48, 28 October 2023 (UTC)
• Support adding AP Oppose removing NYT No need for this to be NYT vs. AP. An excellent pair. Perhaps add paywall as a parenthetical for NYT. O3000, Ret. (talk) 18:31, 10 November 2023 (UTC)
• Oppose removal of NYT, support addition of AP--Lukewarmbeer (talk) 11:41, 11 November 2023 (UTC)

Discussion (Find sources: NYT vs AP)

• @SandyGeorgia, Shibbolethink, Sdkb, Mathglot, SilkTork, Mr. Stradivarius, Wikmoz, Hog Farm, SnowFire, ProcrastinatingReader, and Nemo bis: - notified from past discussion. starship.paint (RUN) 04:24, 9 September 2023 (UTC)
• @RZuo, JohnFromPinckney, Zaathras, Schazjmd, Stultiwikia, Masem, Joseph2302, Shakescene, UnironicEditor, Orange Suede Sofa, Dylnuge, Jack4576, GreenC, Fiachra10003, WhatamIdoing, Folly Mox, Valereee, Enterprisey, Mike Christie, InvadingInvader, and Selfstudier: - notified from above discussion. starship.paint (RUN) 04:33, 9 September 2023 (UTC)

• Are these the right metrics? Without expressing a preference for any of the choices, I'm not sure the metrics given above are what we should be prioritizing. First being paywall; we should strive for the most neutral and accurate sources, not the most free-as-in-beer. Unlike media (such as images or sound), for which we prefer freely-licensed content as we host and display that content directly, news sources should be the most accurate available, as it is in many other areas in Wikipedia that are not news-oriented. Next is international coverage— the "countries operated in" statement is not quite accurate. For example, NYT has actively staffed bureaux in many countries but that's more of a logistics matter; they will send reporters to any country in the world as needed and permitted. And I found at least three different figures in different areas of the AP site so I'm not sure what is going on there. Finally, I fear that a lot of this is moot because many news organizations' public-facing search capabilities are often terrible. As a test, I took the first linked term in today's WP:ITN (Tharman Shanmugaratnam) and tried it with both the AP and NYT search. The AP search returned nothing and the NYT search returned a lot of things, yet notably none of them relevant to the ITN item in question. Are we focusing on the right issues here? Orange Suede Sofa (talk) 05:59, 9 September 2023 (UTC)

  https://www.reuters.com/site-search/?query=Tharman+Shanmugaratnam

  https://www.bbc.co.uk/search?q=Tharman+Shanmugaratnam RZuo (talk) 06:23, 9 September 2023 (UTC)

• Some premises are wrong here and strongly suggest that interested editors read the previous discussions. In particular, the claim that the NYT is "left-leaning" is misleading. It is well-known that the NYT's editorial section is mostly left-leaning (although, interestingly enough, they've gotten heat from the left in the past year as well - see this article for example). However, "find sources" is about the news stories as editorials should only be referenced rarely, so the claim that this is addressing some left-wing bias is weak. (The same is true in reverse of the Wall Street Journal.) The larger concern is accuracy - the NYT is handy for having fairly deep coverage of many topics, and from the sources cited on bias as pointed out by Mathglot in the previous discussion:
  • They are considered one of the most reliable sources for news information due to proper sourcing and well-respected journalists/editors.
• If the NYT were a "conservative" outlet in its editorial page but still had lines like that, then they'd still be fine to use. Maybe we can add AP stories but NYT is a good start and not in any way "problematic." SnowFire (talk) 06:09, 9 September 2023 (UTC)

  I'd second the comment about the strict wall that most U.S. newspapers follow in separating hard news (reporters' own personal opinions, or lack of opinion, disregarded so long as they report all sides fairly) from opinion-editorial and both of them from the business side (advertising and circulation).

  A good counter-example is The Wall Street Journal, whose conservative opinion-editorial bent is if anything sharper than the Times' left-liberal one. Nonetheless, liberal and left-wing Americans constantly cite the Journal both for important economic and corporate facts, and for the enterprising original investigations that its reporters (of any persuasion or none) undertake. The American socialist leader Michael Harrington told young socialists fifty years ago that they should read the Journal regularly, and a very bohemian friend of mine pointed out that the business press (cf. The Financial Times) can't let politics or ideology interfere with the hard facts that their readers need to make sound corporate, financial and investment decisions. However both The WSJ and The FT have rigid paywalls that are, if anything, higher than the NYT's. —— Shakescene (talk) 14:22, 9 September 2023 (UTC)

• Actually, who is the target audience here? When was the last time anyone in this discussion ever had Module:Find sources appear in the course of normal editing, then clicked on a link in it to find sources? I feel like most of us probably have our methods already, and will do the same kinds of searches at the same places for similar kinds of information.
  I fielded a question at one of the helpdesks the other day, where a user was trying to get information about some 19th century book. I pointed them at Internet Archive, google scholar, Jstor, and told them to check their school library resources, like they had zero idea where to start since we didn't have an article specifically about this one book. I kinda get the impression that this find sources template has a similar purpose, and I think for this use case, finding easier sources does make a difference, even if for a more experienced user going through a quality assessment process, it absolutely doesn't.
  It may in fact be the case that NYT has more information readily available via search than AP does per Orange Suede Sofa's comment. That's a pretty strong argument against this particular swap. Higher quality sources are always going to be ceteris paribus more important than easy sources. I just don't think for the people this template most benefits, that all other things are equal.
  I'm never going to argue that ease of access or ease of verification are the most important things about a source. My own topic area of concentration, Early China, is woefully outdated and often doesn't reflect modern scholarly consensus, because so much of the sourcing is from centuries-old classics that have been digitised and are freely available multiple places. It sucks. But if someone hit me up with no idea where even to start, I'd probably still point them at things I know they'll have access to at home for free with no special accounts anywhere. It's a better starting point than asking if someone can afford a subscription or a particular book. Folly Mox (talk) 08:15, 9 September 2023 (UTC)
• Comment I am concerned that we not set a precedent that accessibility is more important than reliability in ranking sources. For many topics, the best sources are on paper, or, if available on-line, are behind paywalls. I understand that many editors are at a disadvantage over access to such sources, but I think we still need to recommend the best sources first. Freely-accessible sources are fine, it they reliably support the content they are cited for, but they should not be a permanent substitute for better sources that may be behind paywalls or only available on paper. - Donald Albury 13:46, 10 September 2023 (UTC)

  Absolutely right. This is the most important comment that anyone has made here. MichaelMaggs (talk) 14:06, 10 September 2023 (UTC)

  I agree though there should be a preference for sources not behind paywalls be it subscriptions to news outlets or academic journals. UnironicEditor (talk) 07:27, 12 September 2023 (UTC)

• For most topics, the emphasis in sourcing should be on scholarly sources rather than breaking news. Both NYT and AP are not ideal sources for an encyclopedia simply because they are news sources and may not reflect scholarly consensus on a particular topic. Their only notable advantage is being more up to date, thus being citable for current events. (t · c) buidhe 15:37, 15 September 2023 (UTC)

https://www.nytimes.com/2023/10/23/pageoneplus/editors-note-gaza-hospital-coverage.html

so much for "NYT's factual reporting is neutral", "by far the best and most comprehensive US newspaper source", "enviable world-level reputation for fair and accurate reporting"... lmao.--RZuo (talk) 20:27, 23 October 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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)

Visibility of edit changes in mobile

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)

Purge Block Logs after X years

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)

Autoprotect recent deaths on the Main Page

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)

Page moving sandbox

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)

RFC - infobox on Fred Sullivan

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)

More barnstars for WikiLove

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

The Most Improved Editor's Barnstar	{{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.
The Anti-anon Barnstar	{{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)