View text source at Wikipedia

Wikipedia:Village pump (proposals)/Archive 180

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, 215, 216

Make page movers eligible to move move-protected pages

I have finally trudged to VPR after running into this twice in as many days and with the fact such RM/TRs frequently stay open for long periods, as the area is patrolled by more PMRs than admins. I cannot consider a good reason not to have this be the case; there aren't many page movers, it's a fairly guarded perm, and any chronically move-warring PMR can get the bit yanked quickly. A surprising number of pages are under indef sysop move protection, which seems to be almost never reviewed (I ran into one where it was placed over a small-scale move war from 2008), and it's fairly inhibiting to PMRs to not be able to perform a significant subset of the page moves we were given the right to do at all. Vaticidalprophet 08:52, 26 April 2021 (UTC)

  • @Xaosflux: how would page-movers be able to move template-protected or fully-protected pages? They still need to be able to edit them to move them, which they would be unable to. I think you might be misunderstanding the proposal scope here. Elli (talk | contribs) 23:49, 26 April 2021 (UTC)
    @Elli: well part of the problem is that the proposal is quite poorly presented. There is no definition to make page movers eligible to move move-protected pages - for example they already CAN do this, provided the move-protection is a level they can move; it appears to be suggesting that some new technology is invented to allow this group to have a new permission that allows moving a page regardless of its protection level. — xaosflux Talk 00:00, 27 April 2021 (UTC)
    @Xaosflux: I'm pretty sure the proposal is to just make move-protection not apply to page movers entirely - any other editing protection would still apply. I don't see how this is really that hard to implement technologically. Elli (talk | contribs) 00:24, 27 April 2021 (UTC)

What if we had different colored links for featured articles. For non-existent articles, we have red, but I think having different colored links to highlight colored articles would make it quicker to find a featured article related to another topic. Terminator21738 (talk) 20:36, 4 May 2021 (UTC)

You might be interested in User:Anomie/linkclassifier.js and User:Anomie/linkclassifier.css, which change the default colour of wikilinks depending on the target page, and can be customized to some extent although I've never bothered to change the default settings. Also, in your preferences under Gadgets -> Appearance, you can enable "Display an assessment of an article's quality in its page header" which changes the colour of the page's title depending on its assessment. Ivanvector's squirrel (trees/nuts) 23:12, 4 May 2021 (UTC)

Convert all English variant notices to editnotices

No consensus to implement - There seems to be a general preference to avoid clutter (due to potential banner blindness, etc.), whether in the article, the edit notice, or the talk page. There also were concerns noted that an edit notice would not appear on the mobile app, and also that only those with advanced permissions could edit an edit notice to add a template. There were also some isolated ideas for some technical feature additions, but none had broad consensus from this discussion. No prejudice against starting a new discussion concerning one or more of those, of course. - jc37 02:33, 26 April 2021 (UTC)

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 proposal arises from an ongoing discussion at the idea lab about how to reduce the clutter of excessive talk page banners, a phenomenon that leads to banner blindness, overwhelming and confusing new editors and reducing the visibility of the more important notices.

One idea I put out that seems to have gotten particular traction is that there is no need to have English variant notices (e.g. {{British English}}) appear on the talk page, rather than just as an editnotice that appears in the edit window while one is editing the article. The primary rationale is that no one is policing the English variety used on talk pages, so the only place this is needed is the editnotice. I'm therefore proposing here that we convert all existing English variant notices on talk pages to editnotices on the corresponding page. This would be done via a bot task, and once completed Module:English variant notice would be configured so that it produces an error notice if placed on an article talk page. {{u|Sdkb}} talk 14:34, 10 January 2021 (UTC)

Survey (English varieties)

  • Support as nominator. To address two potential concerns: (1) In the rare instance that there's a talk page discussion about changing the variant, it's easy for the proposer to provide the context. I can't think of any other situation in which people on the talk page need to pay attention to the variant. (2) Modifying editnotices currently requires advanced permissions; my understanding is that this is for technical reasons rather than because of any editorial consensus. This is an issue that ought to be addressed on its own at some point, but I don't think it's an insurmountable impediment here, as most pages developed enough to be tagged with a variant notice are monitored by editors able to modify it, and if not, they will be prompted to create an edit request, which is quite straightforward. {{u|Sdkb}} talk 14:34, 10 January 2021 (UTC)
  • Support This is a good idea and should be implemented, provided any technical issues are addressed eventually (new permission?). GenQuest "scribble" 15:34, 10 January 2021 (UTC)
  • Support there's a dual benefit as it simultaneously improves both the talk page (by reducing clutter) and the edit screen (by displaying relevant info), a win-win. --Paul ❬talk❭ 16:55, 10 January 2021 (UTC)
  • Oppose The proposal seems half-baked because it doesn't address the use of templates like {{Use British English}} which are what I see most often. For talk pages, we could use something like an infobox which would contain key pieces of information about the article such as its size and quality rating. The dialect would fit best in such a summary of the article's properties. Andrew🐉(talk) 17:26, 10 January 2021 (UTC)
    Regarding the "use" templates, this wouldn't affect them one way or another; they'll continue being available for when it's desirable to designate a variant but there's not enough erroneous editing for there to be a need for a notice. We could discuss down the line how often to have something visible vs. invisible, but for now I think getting all the visible notices into editnotice format is the best first step.
    Regarding your idea for a hypothetical talk page infobox, I'd suggest proposing that at the broader idea lab discussion. I could support it if it's implemented well, but it's beyond the scope of the more narrow change I'm trying to achieve here. {{u|Sdkb}} talk 19:12, 10 January 2021 (UTC)
  • Excellent idea. I suspect if editnotices had existed when these templates started this problem would not have arisen. ϢereSpielChequers 18:50, 10 January 2021 (UTC)
  • Strong support if implemented, this would be huge for reducing talk page clutter, and actually making the english variety notices effective. As I said at the idea lab, the people who are disregarding or ignoring an established English variety aren't going to be on the talk page and see it there. As such, I'm convinced that the current position on the talk page is basically worthless. Aza24 (talk) 21:03, 10 January 2021 (UTC)
  • Support this seems like a way to make the information more effective and reduce talk-page clutter at the same time. Thryduulf (talk) 22:06, 10 January 2021 (UTC)
  • Support we do this for a few Canadian articles already...like Template:Editnotices/Page/Canada....still not seen in mobile view :-( --Moxy 🍁 01:06, 11 January 2021 (UTC)
  • Oppose Arguments below convince me this is not a great idea. I think that it's better to use the "silent" {{Use American English}} etc and at worst let gnomes fix the problems. — Wug·a·po·des​ 23:07, 16 March 2021 (UTC) Support great idea. One added benefit is that it reduces ownership of articles by preventing new users from posting useless engvar tags. Since only admins, template editors, and page movers can add these if we make them edit notices, it also gives template editors and page movers something to do. — Wug·a·po·des​ 02:54, 11 January 2021 (UTC)
  • Support for all of this genre of notices (engvar, date formats etc.), but -- perhaps heretically -- I would support all top-of-the-page cleanup notices going into editnotices as well, so people who just want to consult an article for information aren't bothered with them. Beyond My Ken (talk) 03:17, 11 January 2021 (UTC)
    Beyond My Ken, by top-of-the-page cleanup notices are you referring to things like {{NPOV}} or {{Original research}}? I think those notices are pretty necessary from a reader perspective, since readers deserve to know when an article has significant problems so that they can read it with due caution and skepticism (yes, people should always be doing that, but they trust us enough they de facto often don't). That's more true for some notices than others, though; I could see a case for many of the yellow style ones like {{Cleanup bare URLs}} to be converted to be shown to editors only. The question at that point becomes whether we're wasting an opportunity to convert readers to editors by offering them an easy task. All this is tangential to the current discussion, so maybe take it elsewhere if you want to develop it further, but I hope my comment is food for thought. {{u|Sdkb}} talk 11:05, 11 January 2021 (UTC)
    No, you are correct, I was referring to the "yellow style" ones which primarily concern editors only. Beyond My Ken (talk) 21:26, 11 January 2021 (UTC)
    I would argue that a fair number of the yellow banners are useful to readers (eg Template:Overcoloured letting colourblind users know that they may not interpret something on the page correctly, or Template:Essay-like). Further, as I've been editing even the ones which non-editor readers may not find useful now inform how I read. For example, seeing Template:Debate wouldn't have changed how I read something in the past, but now it suggests to me that people may have POV forked, there may not be great usage of reviews/meta-analyses (in the case of scientific articles), or its editing may have been a series of unconnected additions. They're also useful for the purpose of editing - I will detour from doing other tasks to correct an article if I notice some kinds of banners, including when I wasn't intending to edit it. --Xurizuri (talk) 10:55, 12 January 2021 (UTC)
  • Support Great idea, this banner contributes to creep and I hope that this reduces needless conflict, as many well intentioned edits from new and IP editors are related to ENGVAR. --Tom (LT) (talk) 03:20, 11 January 2021 (UTC)
    • Having read through some comments below I have come to change my mind. As pointed out below this is likely to result in a large amount of editnotices that is likely to frustrate and deter editors. Tom (LT) (talk) 10:56, 6 April 2021 (UTC)
  • Support not useful on talk pages, useful when editing which shows on editnotice. No need for new permission, nor should editing editnotices be available to all, PMR & TPE can do this. If the TPER queue becomes too long, we can get a bot with TPE to carry over additions from the talk page into the editnotice. ProcrastinatingReader (talk) 09:21, 11 January 2021 (UTC)
    Striking in favour of using hidden templates such as {{Use British English}} on the article prose, as said by Whatamidoing, and removing all the editnotices and talk page banners and converting them into hidden templates such as {{Use British English}}. Alternatively, a {{article standards}} template, as described in the thread by Levivich. Arguments by Levivich & L235 are compelling imo. ProcrastinatingReader (talk) 15:15, 5 February 2021 (UTC)
  • Support per proposal ~ ToBeFree (talk) 11:09, 11 January 2021 (UTC)
  • Support – reducing talk page template bloat and helping new editors understand Engvar at the same time sounds like a clear win-win to me. AngryHarpy‍talk 12:47, 11 January 2021 (UTC)
  • I think I oppose for sympathetic reasons. 2 reasons: 1) I do not think this is technically feasible. It asks to make an edit notice for essentially 6 million pages. That's an awful lot of infrastructure. (Someone tell me I'm wrong.) 2) I do think the correct remedy is removing these in their entirety from talk pages. We do not need them present in both their canonical place as article tags as well as talk pages. (Replace as needed on the article proper.) --Izno (talk) 14:41, 11 January 2021 (UTC)
  • Support This seems like a good idea worth pursuing. --Jayron32 18:16, 11 January 2021 (UTC)
  • Support Reducing talk page clutter is a good idea. Remagoxer (talk) 20:51, 11 January 2021 (UTC)
  • Support. It'd be more useful as an edit notice - I know I never check first, and it's a pain to have to open the talk page in a new tab (especially as I have ADHD and sometimes forget the variant as soon as I close said tab). Ideally, similar notices about the style of writing in a given article would also be great to have as edit notices. However, a concern would be that by reducing talk page clutter, we need to not just relocate the clutter (sweeping it under the carpet, so to speak). --Xurizuri (talk) 10:55, 12 January 2021 (UTC)
  • Support, but what about protected pages? There might be an increase of (incorrect) ENVAR edit request, I guess you would also add a en-varent message on the talk page too? (please ping) DarthFlappy 18:53, 12 January 2021 (UTC)
    @DarthFlappy: I would expect that the vast majority of edit requests come from people trying to edit a protected page (that they don't meet the requirements of), clicking the button to request an edit and filling in the form. You might have noticed many are blank—this is because people don't read what's on their screen and just click the big blue "Submit" (maybe thinking that they're requesting permission for them to be given edit access). But anyway, I wouldn't think the talk page banner would really make a difference on edit request content. — Bilorv (talk) 23:49, 14 January 2021 (UTC)
  • Oppose Will only worsen banner blindness. CaptainEek Edits Ho Cap'n!⚓ 20:41, 12 January 2021 (UTC)
  • Support but not at scale, and only as a pilot. As I understand this could affect millions of articles, so please try it first as a pilot for 100s of articles. Big changes like this are best done with test cases, time passing, multiple requests for comment, and documentation. This already has my general support and also I anticipate supporting again in the future, but the proposal as it is has no limits. The scale and pace of the changes matters to me. I am only expecting volunteer-level documentation and not the best and most complete, and I encourage the pilot. I recognize the existence of the problem and feel that it will only grow. There are various possible solutions, and perhaps we have to use several solutions at once to address this issue. Please develop this one solution first. Blue Rasberry (talk) 20:51, 12 January 2021 (UTC)
  • Oppose editnotice banners are far more annoying than talk page notices. They slow down editing. Graeme Bartlett (talk) 22:18, 12 January 2021 (UTC)
  • Oppose — Enwiki has got to be the only publication in the world that writes a single work using multiple varieties of English. Engvar isn't important enough to have talk page banners for, I agree, but the solution is to remove them altogether. Moving them to the edit notice will create edit notice blindness instead of talk page banner blindness, and that's even worse, because in theory, edit notices have the really important stuff, even moreso than talk page headers. Creating thousands or millions of edit notices is a huge overhead and maintenance increase. Edit notices are annoying and largely ignored anyway. They don't show at all for mobile users. In all, I think this moves the problem to a worse place rather than alleviating it. Levivich harass/hound 04:53, 13 January 2021 (UTC)
    This is a fair point. I was thinking the notice should be trimmed down, literally into a bullet point like: “* This article uses British English.”. Alternatively, we can have a single “Article conventions” talk page template which is highly trimmed down and signifies standards like the variety of English used — this assumes that there are other types of standards other than English and date variety that could possibly apply. A bit like {{article standards|lang=British|dates=dmy}}. ProcrastinatingReader (talk) 09:16, 13 January 2021 (UTC)
    An article conventions template sounds like a very good idea. There are probably others besides engvar and usedmy, but those two are good examples. I would find iconography to be the most efficient way of communicating these sorts of things, but I'm not sure if everyone would be on board for that. So like a little British flag somewhere if it was use BrEng, a US flag for AmEng, something like that. Levivich harass/hound 17:27, 13 January 2021 (UTC)
    I agree that the notices should be kept unobtrusive and concise. Regarding the "just remove them entirely" point, we already have the e.g. {{Use British English}} family of templates, which set the standard without displaying anything, just as you describe. I'm undecided about whether/when we should use that compared to {{British English}}, but I think that, in circumstances where it is important enough to warrant a banner, that banner should be proximate to the place it actually applies, which means putting it in the edit notice next to the article rather than the talk banners next to the talk. {{u|Sdkb}} talk 00:06, 14 January 2021 (UTC)
  • Oppose We should save banners for the truly important stuff like BLP, rather than spelling. (t · c) buidhe 18:35, 13 January 2021 (UTC)
  • Oppose per Graeme Bartlett and CaptainEek. ~ HAL333 22:19, 13 January 2021 (UTC)
  • Support: seems like a no-brainer. Banner blindness on a talk page is already a massive issue, and ENGVAR isn't relevant to reading the talk page, it's relevant to editing the page, so it should be where it's relevant. Sceptre (talk) 23:33, 14 January 2021 (UTC)
  • Oppose: it's absolutely a reasonable proposal, but I'd prefer removal of these banners from the talk page instead. I just don't buy that language variant is important enough to warrant this kind of attention, and instead it will just cause reader blindness wherever it appears. I understand that it's very frustrating to be reverting the same good-faith spelling changes over and over again (I've lost count of the number of times I've had to revert "installment" back to "instalment" on the BritEng Black Mirror series of articles), but I've found that most unregistered editors will not see an editnotice, a wikicode template or a hidden comment in the middle of a word that keeps being changed (I don't know why the last doesn't work, but it doesn't), or possibly just willfully ignore them all. So I believe that this proposal, though it seems like the common sense logical position to move the template to, would just create blindness and have little-to-no effect on averting editing redundancies. — Bilorv (talk) 23:40, 14 January 2021 (UTC)
    @Bilorv: Your point about having to correct the same word over and over gives me a thought: what if we had an edit filter so that e.g. anyone trying to introduce "installment" to an article tagged with British English would get a big caution notice when they try to publish? {{u|Sdkb}} talk 01:58, 15 January 2021 (UTC)
    I think it is unreasonable for new/IP users to have no way of knowing this info before editing. Yes, they most likely won't read the notice, but "there's a notice that you ignored" is much better than "there's a policy hidden in our arcane (to new users) WP namespace that you don't even know about". And given that the varieties of English are largely identical, it's sometimes difficult to tell what variant the article is in; the notice is a nice reminder. - Novov T C 07:57, 15 January 2021 (UTC)
    To Sdkb, that's possibly something I could support, but I really don't like edit filters targeted at newbies because it's one more barrier to entry. If there was a way to say "literally the only changes in this edit are a bad spelling changes" then that would be ideal. I know that's asking a lot. To Mir Novov, many good faith edits I see by new/IP users that I have to revert are something I couldn't reasonably expect them to understand. There's been a discussion on the talk page? The lead doesn't mention this because of due weight? This source is unreliable even though it's a newspaper one million people read per day? It's wrong to call a section "Controversy" even though you've seen 1000 other articles with that bad heading? If anything it seems to me that "this article uses Australian English because it's about an Australian show" is so much easier to explain than most common mistakes made. — Bilorv (talk) 09:37, 15 January 2021 (UTC)
    Bilorv, in my idealized 2030 version of Wikipedia, the way that filter would work is that someone would go in and try to make a bad switch to another variant within an otherwise fine edit, and when they click publish, a notice would pop up saying "Hey, you switched 'instalment' to 'installment', which appears to go against the British English used for this article. Would you like to (a) publish, but keep British English? [works in one click], or (b) publish anyways?"
    Even with that, though, I agree with Novov that, for pages where switches are common (which is the group we're discussing here), it's better not to make someone do all the work before giving them the alert. And it's not just newcomers—I didn't know that "installment" was one of the words that differed until you mentioned it above, so I could easily see myself making that error. Whereas if there's an editnotice that (again, thinking futuristically) automatically detects that "instalment" is used a lot on that page and therefore includes it in the examples, that'll let me know not to touch anything. {{u|Sdkb}} talk 13:05, 15 January 2021 (UTC)
  • Support - This information is most useful for actually editing pages, not discussions. Logically, it should belong there, and such a relocation would be useful to the IP editors that have "corrected" spelling . Yes, some other info is on the talk page that should be read, but a lot of people don't read that, and wishful thinking won't make that fact go away. - Novov T C 07:57, 15 January 2021 (UTC)
  • Oppose. Instruction creep, overly intrusive and will just lead to more edit notice blindness. Neutralitytalk 19:43, 15 January 2021 (UTC)
  • Oppose per Neutrality. Personally, I dislike edit notices and more edit notices that would intrude on the editing interface is something that I would not want. Perhaps something similar to the Template:Use mdy dates template would be better. A whole host of edit notices on the national varities of English (sometimes where editnotices are already in place) would be worse than talk page banner blindness for content creators hoow would have to scroll past the edit notice every time they edit. Plus, the national varities of English really isn't that important and as such, this is why we should keep them on talk pages. P,TO 19104 (talk) (contribs) 23:08, 15 January 2021 (UTC)
  • Oppose per Graeme Bartlett and CaptainEek. Cavalryman (talk) 03:14, 16 January 2021 (UTC).
  • Oppose. Varieties of English are not important enough to warrant placement as an editnotice. Just try and notice what variety the article is using and emulate that; if you get it wrong, someone will help you fix it. In my view, the talk page banner exists only to attempt to avert edit wars over this stuff, with one side being able to point to the banner. The rest of the time it's not useful, whether on the talk page or as an editnotice. KevinL (aka L235 · t · c) 20:07, 18 January 2021 (UTC)
    • Further to this, there are some truly important editnotices (e.g. DS notices that create blockable offenses), and the more editnotices we add the more banner blindness we get. Talk page notices are already ignored; let's not consign editnotices to the same fate. KevinL (aka L235 · t · c) 20:09, 18 January 2021 (UTC)
    Whilst I see your argument, to be fair, the editnotice format already exists right now and is placed arbitrarily; admins/TE/PMRs will place it themselves or on request for other editors, also in line with the current documentation for these templates. The pages that only have a talk notice are usually arbitrary. ProcrastinatingReader (talk) 20:12, 18 January 2021 (UTC)
    • There's an editnotice already? That's awful. Let's delete it. KevinL (aka L235 · t · c) 20:22, 18 January 2021 (UTC)
      • Yeah, see doc of {{British English}}. It’s done using a parameter, but the idea is (I think) to use both. To clarify, my point isn’t that we should enshrine a pattern that may not make sense, but if we don’t want language editnotices we should remove them entirely rather than the arbitrary system currently.
        Personally I think either trim it down to literally a bullet point not a hefty notice, or create a {{article standards}} for talk pages. Each option has a different purposes of course: the former is intended to alert editors writing to tailor their language, the latter to help copyeditors ‘fix’ errors. Personally, I don’t know other varieties of English so I make my ‘errors’ and let someone else copyedit their fixes if they care, so possibly the latter is smarter. ProcrastinatingReader (talk) 20:26, 18 January 2021 (UTC)
  • Oppose - editnotices should be reserved for important article- and page-specific instructions, and should be used as minimally as we can manage. Opening editnotices to general advisories about article styles will lead to clutter and significantly diminish the usefulness of editnotices for those article- and page-specific notices. See also this discussion from a couple years back about this exact thing which led to consensus that style notices shouldn't be used this way without evidence of disruption. In the same discussion, several users smarter than me also suggested that doing this would pollute the database with a few hundred thousand new pages and increase the loading time of articles, for no particularly important reason. Ivanvector's squirrel (trees/nuts) 01:04, 20 January 2021 (UTC)
    Furthermore, we still haven't solved the issue that editnotices aren't visible to mobile editors, so they're not well suited to editorial advisories anyway. Ivanvector's squirrel (trees/nuts) 01:06, 20 January 2021 (UTC)
  • Oppose as this proposal appears to ignore the fact that editnotices don’t show on mobile. SK2242 (talk) 06:41, 20 January 2021 (UTC)
    Neither do talk notices. Or, well, they're well hidden. ProcrastinatingReader (talk) 23:00, 21 January 2021 (UTC)
  • Weak oppose; how many times have you read on AN or ANI a reminder along the lines of, "Dear OP, did you miss the violently orange notice when you posted here?" If they miss that, do we really think that an editnotice will prevent page watchers from having to revert to the correct EngVar? Personally, i think that editnotices should be kept for the very most important things ~ things that if you cross or miss might end up with your privileges restricted. happy days, LindsayHello 14:10, 22 January 2021 (UTC)
  • Support but only if there's an option for logged-in editors to turn off the notifications. Lugnuts Fire Walk with Me 17:23, 22 January 2021 (UTC)
  • Oppose having more edit notices. In the visual editor and the 2017 wikitext editor, you have to click to get past the edit notices every single time you open that page to edit. Also, just as Ivanvector's squirrel says, you stop reading them when they're common. WT:MED has an edit notice that I've clicked past most days for the last several years, and I no longer know what it says. When we need to have notes about the language variant to use, please make them all "invisible" templates that carry the necessary information in the title, such as {{Use British English}}. WhatamIdoing (talk) 19:58, 22 January 2021 (UTC)
  • Support. As many others have said, very few editors will actually notice talk page banners, especially IPs and newbies. And failure to heed ENGVAR instructions has often led to disruptive, pointless edit wars. Of course, we need to be mindful of not accumulating so many edit notices that people will stop paying attention, but that's a separate discussion of how to condense the edit notices. ChromaNebula (talk) 23:20, 26 January 2021 (UTC)
  • Support: Even if people ignore the notice, it won't be worse than it is now. This is a great way to stop people from changing between English varieties unnecessarily. And, also, since more people are seeing the fact that "you can tag articles for types of English?", there'll be more people tagging, which, in turn, leads to more standardisation and organization. Opal|zukor(discuss) 22:10, 29 January 2021 (UTC)
  • Support, ideally with the notice stripped down to its bare essentials. Perhaps just United States This article is written in American English, and this should not be changed without consensus. Learn more. I see using editnotices as an improvement in multiple ways. Talk pages become less cluttered. Newbies who don't know about our approach to English varieties are more likely to learn about it and avoid making unwanted changes. And more experienced users editing articles without strong national ties can quickly see how they should write without having to either check the talk page or scan the article for clues as to the preferred variety. the wub "?!" 23:35, 30 January 2021 (UTC)
  • Support - this seems like a good idea. Rollo August (talk) 17:32, 3 February 2021 (UTC)
  • Oppose per Levivich and L235. AVSmalnad77 talk 04:04, 5 February 2021 (UTC)
  • Oppose. Edit notices make it harder to edit. They should be reserved for important matters. Espresso Addict (talk) 07:54, 11 February 2021 (UTC)
  • Strongly oppose.: Instead, eliminate the editnotice versions. We do not need to browbeat editors, especially new ones, about style trivia every single time they edit the page. If someone gets it wrong, some gnome will fix it later, as with all other style quibbles. MoS is a guideline, not a policy, for a reason. No editor is required to follow it when adding new content; they're not permitted to disruptively and stubbornly change material to be noncompliant after they've been asked to stop doing it. Trying to effectively make following an MoS line-item mandatory to edit the page at all is an end-run around WP:EDITING policy, is WP:BITEy, is WP:CREEP of the highest order, and is also an end-run around nearly two decades of consensus that no style matters aside from some key points about article titling rise to policy level. While we're at it, also just get rid of the talk page banners for this. The "silent" templates like {{Use British English}} at the top of the actual article is entirely sufficient.  — SMcCandlish ☏ ¢ 😼  18:01, 13 February 2021 (UTC)
  • Weak support, this is one option to reduce current clutter. These templates already exist as edit-notices, so whether or not they should be needs to be a different discussion. Either way, as a talkpage tag or edit notice, they should be sharply reduced in prominence/space in line with similar comments above, first of all by removing flags/other images per the spirit of WP:FLAGCRUFT. Frankly these notices could be reduced to two words (eg. "British English", "American English") left somewhere consistent on the talkpage/edit notice. CMD (talk) 17:46, 14 February 2021 (UTC)
  • Oppose per SMcCandlish. Editnotices should be reserved for important instrctions/information only. --NSH001 (talk) 10:04, 20 February 2021 (UTC)
  • Oppose clutters the editnotice space with hundreds of thousands of pointless editnotices, while making sure editnotices need to be even flashier for users to read them. Ideally, we'd have a standardized location in the editor displaying the English variety - and editnotices are a hacky - and bad - way to somewhat emulate this. Elliot321 (talk | contribs) 01:45, 28 February 2021 (UTC)
    Elliot321, a standardized location in the editor is an interesting thought. Where would you envision it going? Are there any phab tickets seeing if the WMF could look into adding something? {{u|Sdkb}} talk 07:08, 3 March 2021 (UTC)
    Sdkb sure, here's a mockup I made for source editor (what I use): File:English Variety mockup - source.png. I'm unsure of if there are any phab tickets. Elliot321 (talk | contribs) 07:21, 3 March 2021 (UTC)
    Elliot321, that looks pretty good to me! Hovering over the word "British" could perhaps provide a tooltip with word examples (ideally tailored to the actual words used on the page). If you go forward and turn the mockup into a more formal proposal, I'd support. My read of this discussion is that there's definitely desire to make the language tag less prominent but just disagreement about how to do it, so I think your solution might have strong support if it can be implemented. {{u|Sdkb}} talk 07:39, 3 March 2021 (UTC)
    Sdkb yeah, that would be my idea.
    Now, the question is how to set it? Though I suppose the {{Use blah English}} templates do that just fine, and that could probably be detected in the editor. Elliot321 (talk | contribs) 07:43, 3 March 2021 (UTC)
  • Support Most users don't bother to look at the talk page unless they want to post a discussion there. A new user might not even know that talk pages are there! This is a very useful proposal. 🐔 Chicdat  Bawk to me! 11:22, 5 March 2021 (UTC)
  • Opppose. I support aggressively cutting talk page clutter, but this notice to an even-more-visible edit notice does not accurately reflect its importance (it's a MoS issue, and I concur with SMcCandlish that we should not bludgeon editors about it, like an edit notice would do). — Goszei (talk) 16:37, 8 March 2021 (UTC)
  • I have long thought that the Variant notice should go on the Article page, and not the Talk Page. Just a simple one line hat note saying something like “This article uses UK spelling and grammar” at the top of the page would be enough. Blueboar (talk) 16:50, 8 March 2021 (UTC)
  • Oppose per above.  Spy-cicle💥  Talk? 18:52, 10 March 2021 (UTC)

Discussion (English varieties)

  • If this is adopted, how would it be implemented relative to existing editnotices that already incorporate English variety? That is, see Wikipedia:Featured articles/Editnotice templates for a list of all medical featured article editnotices, that already include English variety, incorporating a custom list of words from the article. (Not a techie, please spell this out in Dummy 101 detail.) SandyGeorgia (Talk) 16:46, 10 January 2021 (UTC)
  • Shifting banners from talk to the edit notice helps talk but makes it even more unlikely that people will read the edit notice. I would want to see a draft of exactly how this proposal would be implemented (create a million new edit notices? create one central edit notice with magic code to show the language variety?), and exactly how it would appear. Try editing Donald Trump to see what an edit notice can look like. Johnuniq (talk) 22:59, 10 January 2021 (UTC)
    • You're emphasis of how big of a change this will be is certainly valid, though I don't know if I agree that moving to an edit notice makes it even more unlikely that people will read the edit notice – even just the flag of the UK or US in the edit notice would do more than right now. The only alternative I can see to the current situation or the proposed solution above is to completely remove the english variety, which is a more or less impossible scenario. Aza24 (talk) 00:10, 11 January 2021 (UTC)
    • We make the editnotice form smaller? ProcrastinatingReader (talk) 09:25, 11 January 2021 (UTC)
      • I'm not sure how feasible this is in a technical sense, but if an editnotice template is about the formatting (eg date order), language variant, etc, then could those be smaller and all placed together right above the editor? It'd make it less obtrusive, while still being easy to locate all the relevant little pieces of information re writing conventions. Those could alternatively be in an expandable bar, like some of the category lists at the end of articles are. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)
    @Johnuniq, I believe that this will involve creating tens of thousands of edit notices. WhatamIdoing (talk) 20:01, 22 January 2021 (UTC)
  • Many old time editors, most newer editors, and virtually all IPs never make it a habit to look at the talk page before editing an article page. English version notices on the talk page are worthless. GenQuest "scribble" 23:30, 10 January 2021 (UTC)
    • Completely agreed, and this proposal should address that appropriately I believe. The current placement of English variety templates are virtually invisible to the intended audience. Aza24 (talk) 00:10, 11 January 2021 (UTC)
      • As a newer editor, I have never intentionally checked before editing so that's at least some anecdotal evidence for your point. However, I'm not sure if this is a function of the notice on the talk page, but on the visual editor on some articles there's a little prompt right under the title (eg Education in Australia). I'm a big fan of those little prompts. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)
  • The need for an administrator to intervene will force an non-administrator-editor who notices a a change to the English variety is clearly warranted to spend two edit sessions on the page. The first session would be to place a protected edit request. The second would be to actually change the variety. Jc3s5h (talk) 01:02, 11 January 2021 (UTC)
  • I expect that the opposers on the basis of "we shouldn't have them in the first place" will actually do something about that and propose that we remove them all together (were this proposal not to pass) . Otherwise, you're wasting everyone's time. Aza24 (talk) 06:08, 13 January 2021 (UTC)
    Opposing a change from the second-best solution (talk page banners) to the third-best solution (edit notices) is not a waste of time, even if one doesn't propose the best solution (no banners). Making a proposal that doesn't have a reasonable chance of success is a waste of time. Oftentimes, "second-best" is status quo because it's the compromise. Levivich harass/hound 06:16, 13 January 2021 (UTC)
    You are mistaken if you believe this discussion cannot generate the consensus to remove these from talk pages without replacement. RFCs are not votes.
    Secondly, we are not wasting time regardless. We should prefer the best solution, however we get to it. It is a logical fallacy to argue that we also must do things consistent with our position, especially as this is a volunteer mission. (I have no problem being called a hypocrite if you like. :)
    Thirdly, this is maybe the least concerning thing on the wiki today. We don't need the polarism on your part. --Izno (talk) 22:09, 13 January 2021 (UTC)
    Izno, literally no where did I say anything like this discussion cannot generate the consensus to remove these from talk pages without replacement, and I certainly wasn't intentionally trying to generate "polarism"; the misrepresentations are not appreciated. I think I was pretty clear about what would be "wasting time" – a situation where people who oppose on the basis of "we shouldn't have them in the first place", the proposal fails, yet these opposers don't start some proposal to remove English variety banners. Because in a situation where a problem is brought up, consequently unresolved by the introduction of a bigger problem and neither end up being addressed is a waste of time. Aza24 (talk) 22:39, 13 January 2021 (UTC)
  • Obviously, the best solution would be a bot that automatically (and quietly) corrected spelling and usage to whatever variant was designated (assuming that a variant has been designated)... with an edit summary explaining what was done and why. Then editors could simply write, and not worry about whether they were writing in the designated variant. Blueboar (talk) 14:00, 15 January 2021 (UTC)
    @Blueboar: editors that are writing any new content shouldn't be overly concerned with this already - it is really about avoiding refactoring the existing text over and over again. — xaosflux Talk 11:45, 16 January 2021 (UTC)
    @Xaosflux: Is there evidence that such refactoring has been a significant problem thus far? Because if not then I think that Blueboar's suggestion is correct. Nsk92 (talk) 00:31, 4 April 2021 (UTC)
  • At the very least, the banners should be reduced and have the flags or other images removed. English varieties don't always neatly follow political boundaries, and at any rate we have WP:FLAGCRUFT for such situations in articles and yet flags are spammed across talk pages. Removing them also helps reduce space and prominence for a template that is probably mostly seen when explicitly being looked for. CMD (talk) 16:47, 17 January 2021 (UTC)
    I agree that the banners should be trimmed down, but I think the flags are actually quite helpful as a visual shorthand, so they're an element I think we should keep. {{u|Sdkb}} talk 21:15, 14 February 2021 (UTC)
  • My main concern here is that editnotices only can be edited by page movers, template editors and admins. I get that a bot can do the initial move but how will we go about additions of these in the future? I don't mind if the consequence is that these notices become rarer, but in that case it should be a deliberate choice and not just an oversight. I also don't think it's a good use of time to significantly increase the number of trivial WP:TPERs with changes to engvar notices. --Trialpears (talk) 21:46, 11 February 2021 (UTC)
    Trialpears, as I mentioned a bit in my !vote, I see this as an underlying problem—there are lots of situations in which anyone autoconfirmed ought to be able to edit a page's editnotice but can't (not because of any editorial consensus, but just because of something about the back-end technical structure of editnotices). That's a problem that we should solve (and if this goes through, it might nudge us toward doing so), but I don't think we should handicap ourselves here and reject this because of it. To do that would both obscure the level of need to resolve the issue and give ourselves more work down the road once it is resolved. {{u|Sdkb}} talk 00:12, 13 February 2021 (UTC)
    I feel like that would in general be a good idea, but I still see some reasons for the protection. Vandalism at editnotices would likely not be detected most of the time and even if it was detected most editors would probably not be familiar how to solve it. Putting misinformation in them could be significantly worse. I would definitely support enabling it for extended confirmed users though. With regards to implementation the restriction is governed by MediaWiki:Titleblacklist which can easily switch it to requiring autoconfirmed. It should also be possible to use a editfilter instead which could implement an extended confirmed restriction instead. --Trialpears (talk) 21:26, 16 February 2021 (UTC)
    Sdkb I don't see an issue with keeping editnotices to people who can override the blacklist - needing to edit editnotices is quite niche and they should, in most cases, be using templates which are not on the blacklist and thus can be edited.
    As long as edit requests are fulfilled quickly, this is fine. Perhaps more people should apply for page mover? Elliot321 (talk | contribs) 07:29, 3 March 2021 (UTC)
  • I personally feel that to reduce possible banner clutter and the talk page clutter, it should be only visible in the edit source for an article but in perhaps a different more vibrant color so it will be easy to notice and can inform editors without causing any/much clutter. Discount Horde (talk) 18:18, 22 April 2021 (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.

Making Ds/alert notices less scary for newbies

A proposal regarding template {{Ds/alert}} which may help support editor retention is under discussion at Template talk:Ds#Add optional param to support editor retention. Your feedback would be welcome. Thanks, Mathglot (talk) 20:06, 6 May 2021 (UTC)

New user landing page should link to search results

Tracked in Phabricator
Task T204234

I think the new user landing page should have a link to search results for whatever page name they typed, just like the regular landing page. A new user is less likely to be qualified to create a page than a regular user, yet the current system makes them less likely to see the other alternative (that a page exists for what they're looking for under a different name). —Lights and freedom (talk ~ contribs) 01:03, 5 May 2021 (UTC)

I'm sorry I have to ask this, but: what is "the regular landing page"? Can you link an example of it? — JohnFromPinckney (talk) 02:44, 5 May 2021 (UTC)
@JohnFromPinckney: The page which you get when you go to any article that does not exist. —Lights and freedom (talk ~ contribs) 04:46, 5 May 2021 (UTC)
That page is actually Template:No article text. Feel free to make edit requests for it. It's indeed possible for the template to distinguish new users using the CSS classes for user groups. – SD0001 (talk) 08:16, 5 May 2021 (UTC)
@SD0001: There is also this page Wikipedia:New user landing page, where new users with an account get directed. —Lights and freedom (talk ~ contribs) 17:33, 5 May 2021 (UTC)
Okay, Lights, thanks. I just went to https://en.wikipedia.org/wiki/Farfle in this browser (signed in) and in another, anonymously. The only difference I detect is the "Start the Farfle article..." vs "You cannot create this article", owing to the fact that I am autoconfirmed here. But they both have "Search for "Farfle" in existing articles", and I don't agree (or don't see) that they are less likely to see that a page exists for what they're looking for under a different name. I mean, I guess, that I don't see what you're proposing. Both "landing pages" already have a link to search results for whatever page name they typed, which is what you seemed to be asking for. — JohnFromPinckney (talk) 12:32, 5 May 2021 (UTC)
@JohnFromPinckney: New users with an account get directed to this page: Wikipedia:New user landing page. I'm not sure if it lasts until they're autoconfirmed, or something else. —Lights and freedom (talk ~ contribs) 17:32, 5 May 2021 (UTC)
Ah, didn't know. I was only new just the one time, and that was long ago, before that page was created. — JohnFromPinckney (talk) 19:45, 5 May 2021 (UTC)
This sounds easy enough to incorporate, but I don't feel like unwinding the workflow right now - can someone make clear the workflow steps that actually lead an editor to seeing Wikipedia:New_user_landing_page? That is, exactly what do they have to type/click on, in what order. (Might be good to document that at Wikipedia talk:New_user_landing_page). — xaosflux Talk 13:16, 6 May 2021 (UTC)
Think this was somehow routed through the ACWorkflow - just don't remember the mechanics. — xaosflux Talk 13:58, 6 May 2021 (UTC)
Had a min - still falling down the rabbit hole ... mw:Extension:ArticleCreationWorkflow references $wgArticleCreationLandingPage. (What we need to dig for is how/if the original search page is preserved - because if it isn't something being passed in to manipulate we can't just add a search text link for it and this may need to go to the extension developers). — xaosflux Talk 14:34, 6 May 2021 (UTC)
This uses the default Project:New user landing page as the "landing page". — xaosflux Talk 14:36, 6 May 2021 (UTC)

Requesting outside feedback on wikiproject mergers

I believe this is likely the one and only place I can bring up wikiproject mergers for outside feedback. It is being proposed that WP:METEOROLOGY, WP:WPTC, and WP:SEVERE be merged into WP:WEATHER. I would like to give a rundown of what has been done thus far and what is being proposed exactly. In the case of Meterology, the project is quite inactive and the articles need to be sorted out into different topics/taskforces so we can see where everything stands. Some articles were already moved over to taskforces in Weather before the WPTC and WP severe mergers were disputed. Weather is supposed to supersede the meteorology project directly. WP:CLIMATE was entirely defunct, not even having a talkpage template to sort normal climate articles underneath it. This project was moved over to Wikipedia:WikiProject Weather/Climate task force and had nearly 200 articles sorted into it. The flood, droughts & wildfires, and met instruments were moved out of WP Met and over to WP Weather, becoming official taskforces. All have since had articles added to them. WP:NTROP was a project that was defunct for quite a while and was barely on life support. I migrated it over to a taskforce given the support from its members, moving all of its subpages over to allow it to function as a subproject/task force underneath WP:WEATHER.

That being said, the coverage of floods, droughts & wildfires, non-tropical systems, and weather outside the United States is in bad shape. It is being proposed that we have one, united weather project. While WPTC and WP:SEVERE are active and doing pretty well, the rest of the weather has unfortunately suffered from years of neglect. It is being proposed that WPTC and WP:SEVERE be merged over into WP:WEATHER (with all subpages moved over) and operate as subprojects/task forces of WP:WEATHER. The goal here is not to drastically change how these projects currently operate. The biggest changes would be talkpage templates would switch over to WP:WEATHER and the titles of project pages would become task force pages. Having one project would allow for shared resources, such as more reviewers, as well as a standardized assessment of articles across the topic of weather. Hopefully, this would also make cooperation easier as everything would be under one roof. There is a lot of overlap between weather topics, such as tropical cyclones spawning tornadoes (severe weather), becoming extratropical cyclones (non-tropical), ending droughts, causing floods, and starting wildfires via lightning or winds. Topics that have been neglected may see more help with them as there would be increased awareness since everything is no longer partitioned off into separate projects. Tornado and tropical cyclone articles seem to be the main focus for weather on WP at this point, but we need to address the problem of lacking coverage outside these areas. Smaller projects are difficult to maintain and I believe it to be in the best interest of everything else that WPTC and WP:SEVERE be merged into WP:WEATHER. Please feel free to participate in the merge discussion here. NoahTalk 23:51, 9 May 2021 (UTC)

Authority control

{{Authority control}} is a template with 1.86 million transclusions. It is generally added to articles at scale and indiscriminately (eg) and visually looks like a bunch of weird words lobbed together, often irrelevant to the article (eg, with links like this). There was a recent RfC here about visual improvements, with a sub-section discussing the value of the template at all, and rough support for scrapping it. The close suggested a follow-up discussion about this. I do not think this template meets the WP:NOTLINK policy or the Wikipedia:External links guideline: it is not Wikipedia's purpose to include a lengthy or comprehensive list of external links related to each topic. No page should be linked from a Wikipedia article unless its inclusion is justifiable according to this guideline and common sense. The burden of providing this justification is on the person who wants to include an external link. I don't see why this template exists in the first place, much less why it's mass-added to articles? It just seems like clutter for our readers and surely adding dozens of disparate, usually useless, external links cannot be said to comply with policy. ProcrastinatingReader (talk) 11:49, 4 May 2021 (UTC)

You claim the links provdied by {{Authority control}} are "useless". They - and more importantly the information presented by the template in its current form - are not. The rest of your diatribe is thus of no merit. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:36, 4 May 2021 (UTC)
I guess it's subjective whether they're "useless". Yes, in my opinion stuff like this is useless for 99.9% of readers and 99.9% of articles. But objectively, adding ~10-30 external links per article, usually to random links with machine-like data values, cannot possibly meet the requirements of WP:NOTLINK or WP:EL. I also do not understand how editors could be exercising "judgement and common sense" on the appropriateness of each link on a given article, when this template is being added at rates of dozens per minute (without bot approval; likely a violation of WP:BOTPOL). Apparently we used to have an actual bot approved for this purpose, on the basis of a rather dubious BRFA where the linked discussions did not show the appropriate levels of (or any) advertisement or broad consensus. I think it's appropriate to raise the issue to the community, in line with the close of the preceding RfC. ProcrastinatingReader (talk) 13:09, 4 May 2021 (UTC)
Usefulness to you may be subjective, but usefulness per se is not. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:52, 4 May 2021 (UTC)
That's a novel definition of objective (or of usefulness). Usefulness is context- and person-dependent, and usually isn't a yes-or-no question but a more-or-less one (more or less useful for you, useful for more or less people, for more or less uses). Fram (talk) 15:31, 4 May 2021 (UTC)
I have never used a parachute, nor do I plan to. I would not argue "Parachutes are useless". YMMV Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:27, 4 May 2021 (UTC)
To make pancakes, yes, they are pretty useless. To survive jumping out of a plane at altitude, they are useful. Similarly, people may argue that the AC links in our articles are useless. Such claims are made in a context, not in a void. They may be wrong in this case, or they may be right, but that doesn't make useful or useless suddenly an objective measure. "It's useless to have these on enwiki because we have all of them, and usually many more (and sometimes better ones) at Wikidata anyway" is a valid position, just like "it's useful to have them here, it saves me one click" is a valid position. Simply dismissing someone's claims that they are not useful because they are objectively useful is not helping the discussion one bit, is not listening to what the other side has to say, it is just taking a doctrinary, absolutist position which tends to either annoy people or to simply get ignored. Fram (talk) 16:41, 4 May 2021 (UTC)
To run with the analogy, a parachute is very useful in the Air Force. That doesn't mean we should distribute a parachute to every single person in the Air Force, as they're useless for most Air Force personnel most of the time. The case can be made that a parachute is useful to pilots, so we shouldn't take parachutes away from everyone in the Air Force, either. We should have parachutes where they're useful, and not have parachutes where they're not useful. Similarly, we should have authority control where it's useful, and not have authority control where it's not useful. Right now, we (or rather a few editors) are putting authority control everywhere. That's not useful. The question is: where, if anywhere, is this template useful? Levivich harass/hound 19:03, 4 May 2021 (UTC)
One of the problems is that the links are added automatically to articles, no matter if they are relevant for our readers or not. While the current redesign of the template makes it much more immediately clear what each link is (thus avoiding much bewilderment), it doesn't help with the problem that you get e.g. on Alejandro Rodriguez (psychiatrist), a Venezolan-American pediatrician and psychiatrist, a link to the Czech National Library[2] which would never be accepted as a simple External link. I have tried (a first, small step) to reduce this kind of clutter with Template:Authority control (arts), which for arts related articles only shows authority control links which are either in English or about art (or, with a country parameter added, have a link to the country of the article subject). Such templates can also be created for other subjects (e.g. by country or by language, whatever people like most). This template will automatically get the new layout of the main authority control template. Other options are removing the least useful links from the authority control template, or indeed just scrapping it: but it will be a tough battle to get that result, and you should make sure, before making such a suggestion, that you have plenty of representative examples of why we are better off without it. Just claiming that it is useless will get counterclaims that it is indispensable for the united librarians of the world and for some software, somewhere, that might stupidly use this template instead of the links on Wikidata. Fram (talk) 12:53, 4 May 2021 (UTC)
"{{Authority control (arts)}}" And, like anyone who dabbles in something they don't properly understand, you've made a right hash of it. Unless, of course, you wish to argue that no-one who works as an artist has every published anything in an academic context? Or designed an album cover? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:39, 5 May 2021 (UTC)
As you are well aware, in those cases the general template can still be used, if necessary. But thanks for the very polite way of bringing your message, a shining example here. Fram (talk) 15:51, 5 May 2021 (UTC)
"the general template can still be used, if necessary" Haven't you been using tools to mass remove {{Authority control}} and replace it with your fork of it - there are now 14K instances of the latter, largely if not mostly your doing. Done without prior community consensus. On how many articles did you leave the original template, for the reasons I mention? Can you give us a few examples? Mind, I'd be impressed if you managed to examine 14K articles for such nuances. Or did you just blindly swap the templates, without thinking to check, as someone who dabbles in something they don't properly understand? Do you even know on how many of those articles you removed identifiers relating to the academic publications or album design activities of artists? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:02, 5 May 2021 (UTC)
You nominated the template for deletion in February (completely misunderstanding or misrepresenting the template in your nomination), and it was kept. From that discussion, but also from comments in this very discussion, it is clear that many people see this as a step in the right direction. And yes, when I replace the template, I check the articles I do it on. Doesn't mean I don't make mistakes, but e.g. from the short Category:Icelandic painters, I skipped Elínborg Halldórsdóttir, Sölvi Helgason and Edda Heiðrún Backman. Fram (talk) 08:01, 6 May 2021 (UTC)
I have never misunderstood the purpose of your template fork, which is quite blatantly to bypass the community's decisions to reject your attempts to delete and to remove popular identifiers from it. The template narrowly escaped deletion, despite a majority in favour of deleting it, thanks to a supervote. I asked for examples of template replacemnts skipped because of academic publishing or designing album sleeves; none of those you list meet those criteria. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:05, 6 May 2021 (UTC)
Sadly, I don't have a list of articles I haven't edited, with the reason why I haven't edited them included. And I don't really have any interest in indulging your bad faith postings any longer. I have shown that I do skip articles during my template replacements,for a variety of reasons. No idea where you get the idea of "popular" identifiers, have you some statistics showing which identifiers are more popular than others? Fram (talk) 13:18, 6 May 2021 (UTC)
Well, you claimed that I had to say something rather undefined to the BL and the LoC, two institutions I hadn't discussed or mentioned. If you don't make it clear what it is I have to say to those, I can only speculate. You have all the space you want to correct me and clarify your meaning, but that's up to you of course. Until then, it looks as if you tried to score some rhetorical point which backfired. Fram (talk) 08:16, 5 May 2021 (UTC)
OK, it's good to know that you think the British Library and Musicbrainz are equally reliable. But I'm going to re-adopt my policy of not bothering to reply to anything you say, it's better for my blood pressure. Mike Peel (talk) 09:09, 5 May 2021 (UTC)
For someone who gets all worked up about people putting words in your mouth when they are asking you questions about what you meant, you sure don't have any problems putting incorrect words in my mouth, do you? I discussed MusicBrainz among the unreliable ACs, the wikis, the problematic ones: I discussed BL as one of the important, reliable ones (which we don't use in the AC template anyway, but well, you brought it up, so...): I never said and I don't think they are even remotely "equally reliable". It may indeed be best if you stop replying, as you are not making much sense. Fram (talk) 12:15, 5 May 2021 (UTC)
But there is no need to “verify the article topic”... we only need to verify the information about the topic that we discuss in the article. Blueboar (talk) 11:27, 5 May 2021 (UTC)
But how will you do that without an authority control like this[3]? Or how will you otherwise ever know that the Indian footballer Mohammed Salim (footballer) (1904-1980) (full name "Mohammed Abdul-Salim Bachi Khan") is the same as the author Muḥammad al-Ḥabīb Ibn Sālim (1903-1980) who published one book in Tunis in 1973? Without "Authority Control" and Wikidata, we would never have known this, we could never have verified the importance, the notability, the reliability of this amazing fact! These are reliable and indispensable! Fram (talk) 12:38, 5 May 2021 (UTC)
Fram sums up a lot of my negativity towards Wikidata well. For the record, I DO think Wikidata is a useful project... I just don’t think that it should be intertwined with Wikipedia. I would not object to a relatively unobtrusive message saying “Our sister project, Wikidata, has stuff related this topic” with a link to the relevant WD page. What I do object to is importing that “stuff” into the WP articles. My antagonism probably stems from the fact that I think WP should be text oriented, and not data oriented. I see this AC “data” as unwanted clutter... something that belongs at WD, but not something that should be imported into WP.
So, my take is: Link to WD... don’t import from WD. Blueboar (talk) 16:49, 5 May 2021 (UTC)
@Blueboar: "I think WP should be text oriented, and not data oriented" - text is what WP does best, data is what WD does best. What I'd like to see is the decent fusion of the two: rather than trying to handle data in text, like we do with a lot of templates/infoboxes, use WD for that. Sadly there are people that think nuclear and want to get rid of WD usage completely, which is a shame, causes a lot of unnecessary arguments, and is generally very 1980s (think about how many websites use databases in their back end). Thanks. Mike Peel (talk) 17:08, 5 May 2021 (UTC)
If you are suggesting we shift all the infoboxes and most of our templates to Wikidata... I would support. Infoboxes and templates cause half the arguments around here, so WD is welcome to them! As for 1980’s... if you are referring to a golden age when people understood the difference between an encyclopedia and an almanac, then yup... All for it! Better yet... we could try for the 1960s - when things ran analog, but ran well. Blueboar (talk) 17:35, 5 May 2021 (UTC)
@JohnFromPinckney: I assert that no human should read or type an identifier except in the rare circumstance of some failure in everyday technology. The template currently says things like, "SNAC: w6zm66qw". I do not oppose the link, but the machine code is an arbitrary placeholder not meant for humans to consider. If we want arbitrary placeholders then we could use any alternative, like a link to the information with an emoji for wiki article info on the database. "📃 SNAC" We could probably list multiple design options. I recognize that as you say a human could conceivably type this, but if I made a guess, I would say the incidence of a human typing an identifer is less than 1 in 5 million uses. For those millions of other readers, it seems like poor design to expose them to computer code. Blue Rasberry (talk) 15:39, 7 May 2021 (UTC)

Summary of ideas

So, to get the discussion back on track slightly. If I'm clear the proposals made here so far are:

How do we tweak these ideas to move forward to an RfC? Which ideas are most viable? ProcrastinatingReader (talk) 13:23, 6 May 2021 (UTC)

It was also suggested above to put it, or something equivalent, into the sidebar. MichaelMaggs (talk) 13:47, 6 May 2021 (UTC)
Thanks, added. ProcSock (talk) 13:59, 6 May 2021 (UTC)
Or to make it autocollapsed? Fram (talk) 13:52, 6 May 2021 (UTC)

Authority Control - asking a slightly different question

Reading all the discussion above, I would like to ask a slightly different question than was originally asked. Let’s assume that Authority Control data is useful to at least some of our readers, and that we DO want to help them to find it. The next question then becomes:

In both methods, a reader looking for AC data will find the data... it is more an issue of HOW and WHERE they find it. Please share your thoughts. Blueboar (talk) 21:00, 6 May 2021 (UTC)

Yes and no... yes, shifting AC from being DIRECTLY listed in WP articles to being INDIRECTLY linked would make the current template obsolete (and thus likely to be deleted)... but we would be replacing that template with an INDIRECT link (similar to our link to commons for images). This would NOT delete AC, just change WHERE the information is hosted (at WD instead of at WP), and HOW it is accessed (via an indirect link instead of a template). Blueboar (talk) 13:36, 9 May 2021 (UTC)
No, it's deletion, plain and simple. Compare with the current situation of the template + the sidebar link. The information is already hosted at Wikidata, it's different ways of displaying it. Mike Peel (talk) 13:51, 9 May 2021 (UTC)
How is it deletion when the information can still be easily accessed? Blueboar (talk) 14:00, 9 May 2021 (UTC)
The template is still deleted from the articles and the content no longer shown in the articles, no? Wikidata's user interface is designed more for editing than viewing, it's normal that templates like this one reformat the data so it displays better. Mike Peel (talk) 14:40, 9 May 2021 (UTC)
Ah, Ok... you are focused on the visual aspects while I am focused on the functional aspects. Fair enough. I still don’t see the suggestion as a “deletion”, but I do understand how you might. Blueboar (talk) 15:35, 9 May 2021 (UTC)

Unique identification and/or useful links?

the {{Authority control}} box currently serves the double goal of:

There may be other objectives for the template (feel free to mention those), but I suppose the above two are the main ones. These two goals are not mutually exclusive, and accomplishing both in a single pass seems commendable. In practice, however, they may be less compatible than anticipated: e.g., cleaning up excessive external links WP:EL-wise may hamper the unique identification goal. Trimming excessive identification (e.g. according to systems that hardly ever use an English-language word) may lead to removal of more useful external links. So it might be a good step to see whether we can find consensus on any of these:

  1. Both main goals have equal (high) importance: inclusion/exclusion of linked identifiers should seek a middle way of what optimizes both goals with as little as possible drawback for either goal.
  2. External links in the box are subject to the WP:EL guidance: only those external links that are most useful to a general readership should be retained, discarding those that would not normally otherwise be included in an external links section.
  3. Unique identification, as in authority control, is paramount, and should show as many connections as useful for the precise identification of the article's topic.
  4. Neither goal is very suitable for an {{Authority control}}-like box: external links should be included elsewhere in the article (e.g., in references grouped at the bottom of an article, and/or in a usual format adopted for lists of external links), not in a type of box that was designed after models for grouping internal links (navbox format), and unique identification is rather something for Wikidata (no need to echo that in English Wikipedia: a link to the Wikidata "authority file" for the article suffices).

Rather than exclusively mentioning which of the above options is or are closest to what you think best, it would be interesting to know how you would accomplish the goal(s) you'd like to see pursued first. And additional ideas are welcome too, that is, inasmuch as they help to distinguish which should be the main goals of the template. --Francis Schonken (talk) 12:32, 7 May 2021 (UTC)

Comments:

Mass deletion of redirects of non-diacritic articles

This is not going to happen, primarily due to the argument that the original assumption is inaccurate - and despite questions to the OP and their otherwise continuing activity they have not come back to clarify this. Additionally, the proposed benefit is also inaccurate, deleting a page consumes more server space - not less, as the space isn't actually removed and then the deletion actions have to be stored. No actual explanation of how "page loading" time would be impacted has been put forward either. — xaosflux Talk 23:07, 12 May 2021 (UTC)

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.

Since this is automatically handled nowadays by the MediaWiki software, I propose mass deletion of such redirects to free server space and possibly make page loading faster. --Heymid (contribs) 12:18, 9 May 2021 (UTC)

There may be other reasons to do this, however performance/space concerns are not one of them. (Mass-deletion would actually increase server space usage as new entries for the deletions would be added to the database.) –xenotalk 12:35, 9 May 2021 (UTC)
Oversighters can remove entries from the database. --Heymid (contribs) 12:54, 9 May 2021 (UTC)
Oversighters cannot remove entries from the database. The revision remains in the database and edit history but is marked such that it is only visible to editors with the oversight user right. The flag is applied independently to the content and edit summary and is fully reversible, nothing is actually deleted. This is explained more fully at Wikipedia:Oversight. Thryduulf (talk) 21:28, 9 May 2021 (UTC)
Are you saying that only developers can truly delete edits and log entries? --Heymid (contribs) 12:56, 9 May 2021 (UTC)
That's correct. MediaWiki never deletes old revisions. Anomie⚔ 13:04, 9 May 2021 (UTC)
Anomie, Do you know how often this happens? I would imagine it's exceptionally rare and probably only in response to something like a court order. -- RoySmith (talk) 18:24, 10 May 2021 (UTC)
I don't know that it has ever happened, since the very early days of Wikipedia before the current software was fully in place. Anomie⚔ 22:14, 10 May 2021 (UTC)
Does Wikipedia:Administrators' noticeboard/Archive126#Adding useless revisions to pages to make them undeletable count as the developers permanently deleting old revisions? * Pppery * it has begun... 22:41, 10 May 2021 (UTC)
(after edit conflict) This would not save any server space (deleted pages are simply flagged as deleted, rather than actually removed from the servers) and I would doubt very much that it would have any discernable affect on page loading time, but if such redirects are performed automatically (something that I wasn't aware of, but you learn something new every day) then why bother to maintain manual redirects? Phil Bridger (talk) 12:40, 9 May 2021 (UTC)
If you delete a page and then move another page to that page, all revisions of the deleted page are deleted from the database. --Heymid (contribs) 12:54, 9 May 2021 (UTC)
That is not correct. The deleted revisions remain, and may even be undeleted to merge the histories of the two articles. Anomie⚔ 13:04, 9 May 2021 (UTC)
Can you provide more information on the automatic handling of redirects, such as some documentation or announcements of the feature? isaacl (talk) 17:31, 9 May 2021 (UTC)

It's not clear which redirects you are proposing to delete, but I presume you mean things like Cliche (→Cliché). If so then I will strongly oppose because while the software automatically takes you to the title with the diacritic in some circumstances it doesn't in all of them (it depends on what method you are using to navigate and possibly what device you are using). Additionally, there are likely to be cases where multiple titles differ only by different diacritics, I don't know what the software does in that situation but it seems far better to be able to control it manually. Finally, some of the redirects will need to be retained for attribution reasons and/or contain other important edit history. Thryduulf (talk) 21:23, 9 May 2021 (UTC)

The premise is flawed 1) since this is not automatically handled by the software in any way (searching is, yes, but not redirections) 2) this would not save any server space nor would it affect load times 3) this would hamper typo fixing effects when diacritics are concerned by depopulating Category:Redirects from titles without diacritics (including scripts and semi-automated editing that make use of this category). Headbomb {t · c · p · b} 21:26, 9 May 2021 (UTC)
  • @Heymid: multiple comments above suggest your premise that there is some automatic title handling overriding everything else is incorrect, can you point to any documentation about how this is always being resolved? — xaosflux Talk 10:14, 10 May 2021 (UTC)
  • I second the question -- is this documented somewhere? I thought something new was added to MediaWiki. But from the above comments, it seems this only applies to searching as it has for a while. None of the ways I manually tried to go to a diacritic-ed page actually did so. —  HELLKNOWZ   ▎TALK 10:37, 10 May 2021 (UTC)
  • If, as seems to be the case, the OP's opening statement is false then this proposal is an obvious non-starter. Phil Bridger (talk) 17:49, 10 May 2021 (UTC)
  • Oppose, for the record. I can conceive of circumstances where a word spelled the same except for varying diacritics has differing targets (i.e., where a Föo properly redirects to a Foo, but a Fóo properly redirects to a Fao), where having the diacritic redirects saves readers confusion. The diacritic terms may be harder to type, but don't underestimate the propensity of readers to copy and paste terms of interest from things they are reading on the web. BD2412 T 18:46, 10 May 2021 (UTC)
  • Oppose the "save server space" argument is so ridiculous I shouldn't need to respond, but I will. First, deleting redirects doesn't actually save server space. Second, there's no shortage of server space. Beyond that, the redirects are valuable if somebody wants to create a different article at the non-diacritic title. There can be ambiguous redirects to/from diacritic pages. And other commenters suggest the "automatic redirect" is just auto-complete in the search box, not an actual redirect. User:力 (power~enwiki, π, ν) 22:14, 12 May 2021 (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.

Adding Pronouns to Prominent Figures

Just thought maybe it would help normalize pronouns for everyone if they’re seen on prominent people. — Preceding unsigned comment added by 72.83.246.196 (talk) 02:18, 3 May 2021 (UTC)

We have discussed this before. For usual kinds of pronouns, (he or she) just use them in the text. If the subject has expressed their wishes in a reliable source about pronoun use, then we should cover it in the text. But don't use templates, or make stuff up. If writers use "they", it is unclear if it is bad writing, or a subject request. So it should be made clear in text of the article. Graeme Bartlett (talk) 07:59, 3 May 2021 (UTC)
Wikipedia is not for social advocacy. As much as some people might like it to be, and have arguably succeeded in other ways, we're not here to be an advocate for social change like "normalizing" pronouns. We're here to describe on the world as it is, in as neutral a manner as we can. Our most appropriate social advocacy lies in doing exactly that: writing about the world as it is, without ignoring notable encyclopedic topics that have historically been ignored. But trivia like pronouns or blood types generally aren't notable or relevant from an encyclopedic perspective. Anomie⚔ 11:53, 3 May 2021 (UTC)
Generally speaking, we know the sex and/or gender of the person so can use "he" or "she". If it's unknown -- this'd be really rare I suppose, but I mean if we're describing the person who, I don't know, carved the Venus of Willondorf or is an anonymous blogger, we could use "he or she" maybe, and try to use more specific pronouns in those cases ("the carver", "the blogger"). "They" would imply that we're talking about the person's group as a whole. "It was found in an area where the Bugboy Tribe had lived, and they probably created it around 2000 BC. The carver appears to have been skilled for the times, and he or she clearly was influenced by the Woowoo culture." Substituting "they were" in the second sentence for "he or she was" alters the meaning. (It also still makes some people claw the draperies too, and all things equal that's not maximally accommodating.)
I suppose there are some people whom we know who they are but their sex or gender is simply unclear. I can't think of any, but it's a big world. I dunno, but must be rare, I guess case-by-case would be have to be the rule.
I all debatable cases, subject preferences is a data point, and certainly worth considering, especially if the person is alive. But at the end of the day we decide. I had a subject named "M. L. Something" (she went only by her initials) who wanted her name written everywhere as "ML Something" -- sporty, I guess. Some sources did and some didn't, so our normal MoS trumped her wishes. If someone wants to be known as "xe" or "heshe" or what have you, fine, but we mainly want to know what pronouns the Times of India and the Chicago Tribune etc. use.
And then the system is subject to going off the rails. Keiynan Lonsdale wants his pronoun to be "tree" ("Londsdale was slated to appear in Glad To See You, but tree got sick", I guess). We certainly don't want a system where we're required to use "tree" in Mr Londsdale's article and so on. So maybe no rule at all would be best for now. Herostratus (talk) 23:33, 3 May 2021 (UTC)
I don't think the sentence and substitution you suggest really alters the meaning, although it does create some ambiguity: I find myself asking "Is this singular they, or someone writing at a middle school level?" Most of the time I find singular they unambiguous. Anomie⚔ 12:22, 4 May 2021 (UTC)
There was a very unfavorable ruling on this in Wikipedia:Village pump (idea lab)#Pronouns in Infoboxes. 🐔 Chicdat  Bawk to me! 12:33, 4 May 2021 (UTC)
As I say every time somebody brings this up - if there is a reliable source for the information, we can absolutely state the preference of a subject in an article, and we do, consistently. If there is not a reliable source stating this information (and no, the use a specific set of pronouns in passing in an otherwise reliable source does not really count IMO - a source which explicitly refers to a subject self-determining their pronoun use would be needed), then we can't explicitly say "<x> stated that she uses 'she/her'," or similar. Otherwise, I am reticent to draw specfic attention because it's consistently a target for vandalism on articles about trans folk, and it makes more work for the shrinking minority of content editors who contribute good, well-sourced verifiable edits to that area. -- a they/them | argue | contribs 12:41, 4 May 2021 (UTC)

Maintenance templates for pronoun use

Following on what I said above, I created an experiment: Category:Pronoun use templates.

The current way we handle someone specifying pronouns is to dedicate a line of prose in the article about it. This is fine sometimes, but seems to present undue weight in some cases, especially as this becomes more and more commonplace. It sounds there are some objections about including pronouns in an infobox (I have mixed feelings, but this seems pretty clear for the time being). But what about a third way? When an article uses {{use dmy dates}} it doesn't affect article content; it just adds the page to a maintenance category and clarifies to future editors which format should be used. So I envision e.g. {{use they/them pronouns}} to function similarly. — Rhododendrites talk \\ 18:49, 13 May 2021 (UTC)

Hmm. Someone pointed out that we do have a talk page banner and a an editnotice, which may render these redundant. I'm not sure. Would appreciate additional thoughts about the best way forward. — Rhododendrites talk \\ 18:51, 13 May 2021 (UTC)

I am a Wikinews and Wikipedia editor. I was not aware of a change that was made in 2018 that mainly restricted Wikinews links using Template:Wikinews to the bottom of the article/external link area. Previously, I had put my Wikinews articles within Wikipedia articles — for example, I put an article I wrote on the 2021 Kernadec Island earthquakes in 2021 Kermadec Islands earthquakes#Earthquakes. I understand why articles like this, which contain no new original reporting, and are based off existing articles that should, ideally, already be cited, have no need to be cited inline.

But, I don't understand why original reporting would not be relevant to the reader. The process of verifying, for example, interviews on Wikinews, is that the content is reviewed by a community reviewer before being published. In my experience, though mine is not universal, I conduct interviews via email, post the text of the email on the talk page, and forward the email onto a scoop email which I believe reviewers have access to. It's not a perfect process by any means, but I think it's a reasonable process to verify the validity of the content.

It also does provide additional helpful information to the reader. In the context of, again using my own example, an article on the 2020 Groom by-election, interviews with the candidates do help the readers, and it's useful to have it listed in the relevant section. Again, obviously there are limits to this. An article about the history of Australia, for example, doesn't need an inline link to an interview with an Australian historian. Common sense can be used. But I think that it can be helpful to the reader to have relevant Wikinews original reporting inline in an article. --LivelyRatification (talk) 02:46, 10 May 2021 (UTC)

That's my thoughts, yeah, that Wikinews is separate. Obviously if we added to the article "[x] candidate said [y]" using Wikinews as a source it'd be different, but we wouldn't be adding any material to the article prose, just pointing readers to original research done by one of our sister projects. To use another example, if information from a Wikivoyage article was put into a Wikipedia article verbatim, it'd be unreliable because it didn't cite any sources, but it's acceptable to link to articles in that project, even if Wikivoyage doesn't have the same standards of verification and sourcing as Wikipedia. --LivelyRatification (talk) 20:53, 10 May 2021 (UTC)

Growth Team en-wiki Trial

Hi all,

The Growth Team have proposed a plan for trialling the new Growth Team features to 2% of new accounts to en-wiki, after various successful trials/rollouts on other projects.

MMiller (WMF) is one of the most community responsive WMF product managers we've ever had the fortune to have, so if interested please go and drop any comments in. Nosebagbear (talk) 23:12, 23 April 2021 (UTC)

Hello everyone -- I'm following up here to let everyone know that the Growth features are now available to test on English Wikipedia. They are not being assigned to any newcomers yet, but experienced users may turn them on in preferences to try them. We hope you try them out on desktop or mobile and leave any notes here (or on the project talk page). After a couple weeks, and after we iron out any issues, we plan to start giving the features to 2% of newcomers to get a sense of how they work on this wiki, and so that we can make plans for next steps.
To test the features, please go to your user preferences and then:
This will give you access to the homepage (Special:Homepage), and, from there, you will be able to:
  • contact your mentor
  • select your favorite topics and tasks to make some suggested edits
  • browse help pages
  • see your impact
You will also see the help panel being visible when editing, or when browsing help pages.
-- MMiller (WMF) (talk) 01:41, 9 May 2021 (UTC)
Just from looking, this looks amazing to give new editors who are motivated a way to get advice/help. Some questions I have:
  1. Are the mentors randomly selected from all editors, or only those who intend to be mentors? If it is randomly of all editors, what is the selection criteria to ensure only editors likely to respond to new users are randomly given as mentors?
  2. Will there be a way to select mentors based on the topic areas a new editor selects on the homepage, or based on their most common topic areas they have edited already?
  3. "Create a new article" is currently grayed out for me - will this be expanded to at least allow for people to start on a draft as soon as they want to, regardless of "other steps" completed? I think this is likely going to push people away if it's "more steps" they have to do until they get a "new draft" option.
  4. Will there be a way to "customize" the homepage to include links specific to topic areas? As an example, most new editors probably don't need to see WP:MEDRS and WT:MED - but for those interested in biology/medicine articles, those two links would likely be good to include on the homepage. Ideally, imo, this would be a subpage of WikiProjects that could be transcluded with guidance for WikiProjects on how to craft a short intro to their topic area.
Overall I think this is a great idea - and this is just my first feedback. Regards -bɜ:ʳkənhɪmez (User/say hi!) 01:53, 9 May 2021 (UTC)
Thanks for checking out the features, @Berchanhimez! I'm glad you think we're on the right track. Here are my responses to your good questions:
  1. The mentors are selected randomly from a list of users who sign up to be mentors. For small wikis (e.g. Czech Wikipedia), they tend to only need something like five mentors so that the mentors don't get too many questions. Larger wikis, like French Wikipedia, tend to need more like 40 mentors. As we test the features here on English, we'll get a sense of how many mentors will be appropriate for the much larger flow of newcomers into this wiki. This is the English sign up page now, where we need just 5-10 mentors for the 2% test (and we don't want too many, because then it will be rare for each mentor to get questions).
  2. The idea of selecting mentors on topic areas has come up a lot! I definitely think that's a good improvement and I'm glad you mentioned it.
  3. Here's the idea behind "create a new article" being grayed out: many newcomers are trying to create a new article immediately after creating their account. It's one of the most common reasons people create an account. But we know from our research that the vast majority of them fail to create the article and end up having a bad first experience on Wikipedia. In our feature, we want to encourage newcomers to try easier edits before diving into creating a new article, and we put the grayed out box there because we know many of them of the newcomers are looking for where to create an article. We want to indicate that we know they want to create a new article, but we recommend against it. Does that make sense? What do you think?
  4. I haven't heard this idea before, but I like it! We know that it can help newcomers succeed if they can find others who share their interests. I could imagine this being something like: after the newcomer selects their topics of interest, a module brings up links to the wiki communities who focus on those topics, and they can go explore. I filed a task here, so that our team can keep the idea in mind.
MMiller (WMF) (talk) 03:42, 9 May 2021 (UTC)
MMiller (WMF), appreciate the answers! On the topic of having a bad experience creating a new article, I think it's important to realize that many new editors their sole purpose for registering is to create an article of some kind - and in fact some of our new medical articles have been by new editors that we may be able to retain. I don't think limiting it is the best idea - having a mentor through creating a new article would be better in my opinion. I understand the position you're taking and I'm not wholly opposed to it because I mostly agree with you - most people have a bad experience with new articles - but the solution imo isn't to make it harder for them to do so but to be able to guide them more. I think guidance can help them realize on their own that it's not a good idea to create an article to start - and that will help them stay. Overall I really appreciate and agree with the responses here - and I think this is likely to be a good thing :) Thanks for the response :) -bɜ:ʳkənhɪmez (User/say hi!) 04:14, 9 May 2021 (UTC)
@Berchanhimez -- got it; thanks. Perhaps we should consider creating guidance around new articles sooner than we planned. MMiller (WMF) (talk) 04:22, 9 May 2021 (UTC)
MMiller (WMF), yeah I think this may be best - because unfortunately, some people are just going to leave the tools completely and go back to the old way if they can't find a clear (not necessarily easy, but clear) pathway to their goal of a new article. Even a tooltip or hover-tip that says "creating a new article will be available through this tool after x" whether that's autoconfirmed, or whatever, would be helpful in my opinion. Alternatively, if the herding them towards "easier edits" in a topic area works well, it may be beneficial to just gray it out and the tooltip say "please ask your mentor for assistance in creating a new article as the process is not easy to automate in this tool" or similar - basically it takes the blame off of the tool, and encourages mentorship throughout that process. Tailoring the mentorship to specific topic areas, whether through automatic randomization based on WikiProject participation or similar will certainly make it more viable to gray out - i.e. the graying out won't just shove them back into the normal "I'm gonna do it anyway" mindset, but it'll give them a clear path. Is that something that's been considered - the automatic randomization based on a selection of topic area and related WikiProjects' participation/active user lists? I know some WPs are better at keeping those lists up to date than others, but it'd be a good integration of WPs into new editors. That way, the first question they're asked when they open it is "What topic area are you most interested in" - with perhaps some more sub-questions for areas with a lot of projects (ex: locale specific WikiProject focusing on a topic area, etc). -bɜ:ʳkənhɪmez (User/say hi!) 21:44, 11 May 2021 (UTC)
Thanks for these thoughts, @Berchanhimez! I like your idea of encouraging the newcomers to ask their mentors for help with creating new articles. I could imagine us adding something to the homepage nudging them to do that. And the idea of matching mentors to newcomers based on topics is something that has been brought up in many communities with the Growth features. One way we could do it is to ask mentors to select a few topics of interest when they sign up to be mentors, and it would be the same list of topics that newcomers choose from. Then we could match them up without relying on WikiProjects, but rather on a more recent response from the mentors about their interests. Do you think that would work?
I think this gets at a broader idea: as newcomers start their journeys, the more that people who share their interests can have eyes on their work, the more likely their work will be appreciated and nurtured.
I will say, though, that in the coming month's the Growth team's focus will be on building new "structured tasks" for newcomers to do. We'll also be working on "positive reinforcement" -- the features that help newcomers see the impact of their edits, feel proud, and then level up to more challenging tasks. For mentorship, the big upcoming improvement is the "mentor dashboard", so that mentors can see who their mentees are and how they're doing. That's all to say that I'm not sure when we'll be able to take action on the ideas we've discussed here about new articles and mentors, but let's keep thinking about it. MMiller (WMF) (talk) 20:15, 14 May 2021 (UTC)
Okay, this page looks quite cool. Initial comments on the "Get help with editing" widget in the bottom right though, I think some of the link targets could be changed. "How to create a new article" goes to Wikipedia:Article wizard/version1 which is superseded, "How to write a good article" goes to the WP:MOS which, while the style guide, is a bit much for a newcomer to jump into reading and I think we have better guides on how to write a good article (I have a couple at User:ProcrastinatingReader/sandbox#Writing, and I guess there's also Wikipedia:Writing better articles). ProcrastinatingReader (talk) 02:22, 9 May 2021 (UTC)
Works great and looks good. Only concern I have echoes those of ProcrastinatingReader.... our target pages for more help should be the parent Wikipedia help page that is edited and overseen by the community. There are many concerns with the tutorial pages.... accessibility in mobile view..... sandwich text in destop view.... the need to click and load action butons to multiple pages to derive serviceable information. The tutorial has a serious editor retention problems. Moxy- 02:36, 9 May 2021 (UTC)
Thanks for checking things out, @ProcrastinatingReader and @Moxy. I'm glad to hear things look good to you. For those help pages, we automatically populated them based on Wikidata, but they are totally customizable for this wiki. A few other people noticed, too, and we have a discussion going here about how to change them. Please feel free to weigh in so that we can make them the right pages for English Wikipedia! MMiller (WMF) (talk) 03:50, 9 May 2021 (UTC)
Looks great, nice and intuitive interface for new editors. EpicPupper (talk) 04:37, 9 May 2021 (UTC)
I like it. Great idea! Huggums537 (talk) 07:03, 14 May 2021 (UTC)

Redesigning the featured, good, and article assessment icons

This proposal is unsuccessful. This discussion was originally closed per WP:SNOW, but reopened after criticism about how quickly the idea was shot down. This proposal stems from an earlier village pump discussion that identified certain issues with the current FA and GA designs (e.g. the current FA icon's overly detailed design causes issues when rendered at small sizes, and the GA icon is used to mean different things in different contexts), but in this discussion, it's clear that there isn't consensus to adopt these specific proposed designs. There were a variety of objections ranging from simple preference (e.g. not liking silver/gray to indicate GA) to accessibility concerns (the use of color as the only distinguishing factor between FA and GA). Respectfully, Mz7 (talk) 18:33, 16 May 2021 (UTC)

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.

Related icons
  • Former good article icon
    Former good article icon
  • Good article reassessment icon
    Good article reassessment icon
  • Good article candidate icon
    Good article candidate icon
  • Former featured article icon
    Former featured article icon
  • Former featured article candidate icon
    Former featured article candidate icon
  • Featured article candidate icon
    Featured article candidate icon
  • Article for improvement icon
    Article for improvement icon
  • Good topic icon
    Good topic icon
  • Good topic candidate icon
    Good topic candidate icon
  • Featured topic icon
    Featured topic icon
  • Featured topic candidate icon
    Featured topic candidate icon
  • Former featured topic icon
    Former featured topic icon
  • Former featured topic candidate icon
    Former featured topic candidate icon

This proposal seeks to establish consensus for new icons that appear in the upper right corner of good articles (GAs) and featured content (FC) pages to mark their status, as well as the variant icons of these (candidate, former featured/good, former candidate). For the sake of consistency, it also proposes new assessment (A-B-C-Start-Stub-List-Disambig) icons.

Background: There was recently a Village Pump proposal (here) discussing whether or not to change the FA and GA icons. Main issues brought up were the overly detailed FC icon, which causes it to render poorly as small sizes, as well as the confusing GA icon, as it also is used as a "support vote" icon. In short, Support for the proposal outnumbered opposition, 2-to-1. As such, I have created new icons that I believe alleviate these issues. I've made quite a few variants of these icons, a large number of them that can be found here: File:FA-GA icon proposal.png, but for the sake of streamlining this process, I have chosen what I believe to be the most clear and intuitive ones in the proposal. As opinions come in, we can make new proposal sets of icons.

Proposal 1

  • New icons, Proposal 1
    New icons, Proposal 1
  • Side-by-side with old. Note that the default size of the image is such that the individual icons are 45px wide, which is around the size they would be rendered in talk pages.
    Side-by-side with old. Note that the default size of the image is such that the individual icons are 45px wide, which is around the size they would be rendered in talk pages.

Key points:

  • FC icons simplified, with GA icons matching the format of FC.
  • GA icons changed to silver, as it is a very natural was to color these.
  • FC/GA former icons have dashed outline of a star, representing that they once held that distinction.
  • FC/GA candidate and reassessment are represented by the same icon, as they both serve the same purpose – assessing whether or not they should be classified as FC/GA.
  • FC/GA former candidates have an "x" representing that there were items not satisfied in the FC/GA criteria.
  • Start and Stub class articles get new icons.

Support (article icons)

  • Support – As proposer. These icons are simple enough that they will render well as small scales, the new color and matching format for GA makes it clear and obvious that they are related, while FC is clearly a higher distinction, and the new icons have intuition behind them as to what they mean. Pbrks (talk) 21:02, 2 April 2021 (UTC)
  • Support with the following reservations I highly doubt that non-editors will know what any of this means, nor necessarily should they. In any event, the interwiki list has (I think) silver for a good article in another language (see James Thompson (surveyor)) and gold for a featured article in another language (see World War II for several examples of this). I think the colors should be brought to those respective standards if not already done so. The former article/former candidate, etc., stuff doesn't belong as a topicon and should instead go to the talkpage, IMO.  – John M Wolfson (talk • contribs) 21:16, 2 April 2021 (UTC)
    • I don't see anywhere suggesting that the former stuff would now be put on the article page (that would almost certainly require its own, separate proposal), I would assume their replacement is with their respective icons on the talk page. Aza24 (talk) 21:22, 2 April 2021 (UTC)
    • The former, candidate, etc. are only seen on on talk pages. You will only see the "Promoted" icons at the top right of the page. Pbrks (talk) 22:13, 2 April 2021 (UTC)
  • Support in principle Repeating my earlier comment: The icons should be changed to something the average reader is familiar with. The current icons are nice, but they're nice to Wikipedians. The average reader probably has no idea what this means. We should aim to use images which readers will understand. For example: silver star, gold star. A tick / double tick. Or something along those lines. It should be obvious to a reader what it symbolises. I'm not so sure about this specific set, though. ProcrastinatingReader (talk) 14:04, 3 April 2021 (UTC)
  • Support per Pbrks and Ivanvector (in the section below). The current icons are terrible at the size they're normally displayed. --Ahecht (TALK
    PAGE    ) 03:13, 12 April 2021 (UTC)
  • Support per above. EpicPupper 21:38, 12 April 2021 (UTC)
  • Support As per above and I prefer uniformity.  Saha ❯❯❯ Stay safe  08:41, 14 April 2021 (UTC)
  • Support in principle, but there could or even should be some improvements. At first I was going to shoot this down because they lacked "atmosphere" and I have a spinal core reflex that goes against anything flat sans serif and iOS-fication designs, which I absolutely hate. Such things get created just because it looks modern without any concern to its purpose. But on a second thought I think they're really good and fits the purpose well. Since they're going to be small when in actual use, it's good that they're simple and have clear colours. Gold and silver for the top classes is brilliant GUI design, as well as simplifying the lineup and the design that hints in themselves of what it means, with a question mark for candidate no matter if first time or not, X for rejected, holed star for former and filled star for current. You need to work on the gold and silver hue though, it's a little too soft and blends in. For the other ones is it great with clearer hue and more contrast. The tilting on the current gives character but is also harder to see miniaturised. Serif typefaces are easier to read in small sizes, which is the point of serifs, so consider that. If you make a new batch with serif typefaces for the letters I'm sure you will gain more support. However for precisely all these reasons do I reject the proposed stub and start icons. The current ones are excellent just as they are, symbolises perfectly those classes. The new ones are cluttered and way too similar. A general criticism is that edges are too soft, they need to be accentuated, perhaps even have contour lines, at least the FA and GA icons. The question mark is slightly too big or too swollen, it comes too close to the ring at the top. --Mango från yttre rymden (talk) 23:57, 2 May 2021 (UTC)
  • Support. Come on, people. I get the criticism about the GA icon not being green and the stars in the new GA and FA icons not being too transparent, but the icons we are currently using are out of date and were made in the late 2000s, and they show. That's definitely something broken that needs to be fixed. I do like the 3D feel of the old FA icon on closer look, but the medal looks more bronze then gold, IMO, and you won't notice how 3D the icon is while reading a FA cause it's so small. I feel the new icon has a golder color. Plus, most of the new icons are the same color as the old ones anyway. They are also way more in touch with the current graphic design of most websites and commercial products today, and you know what happens to businesses that don't modernize. 👨x🐱 (talk) 20:19, 4 May 2021 (UTC)
  • Support with comment. As a (relatively new ?) editor, I can say that the proposed version certainly helps new editors get a quick understanding of what those icons mean. I just don't get to see much difference between a full star and a broken star when they are up there on some article. Plus, the new icons are uniform in nature and give a much cleaner and simplistic view, much in line with the modern graphic design as HumanxAnthro mentioned. However, I have some reservations with the two icons featuring the question marks, which feels as if it were an article on some unidentified subject. Moreover, maybe we can get some transition period wherein the old and new versions could be shown side by side, like, inside a rectangular box or something, so that older and experienced editors can get themselves accustomed with the new icons. CX Zoom (talk) 15:58, 13 May 2021 (UTC)

Oppose (article icons)

  • Where exactly is the need to replace the current icons with some hideous Web Whatever.0 design? How have I been running into so many "well, everyone in the tiny discussion on VPR supported it" lately? Why did we have a watchlist notice for the worst, most heat-over-light RfC I've seen in my life and yet no watchlist notices for "people want to restrict minor edits to the 99.8625th percentile of editors" or "people have decided the current quality icons are bad for some unclear reason" that have impact on actually writing an encyclopedia? How many of the thirteen people in the prior discussion are highly involved in the article quality process? Vaticidalprophet 22:27, 2 April 2021 (UTC)
    @Vaticidalprophet: The prior discussion was widely advertised everywhere of relevance short of CENT (including at the article quality forums). I sympathize with the feeling of coming across a discussion I would've wanted to participate in after it's closed, but the rationale behind changing the icons was thoroughly discussed and won clear support, and the process at this point has moved to the next stage. This thread is seeking to figure out how to change the icons, not if we should change them. Let's please not relitigate settled terrain; the whole point of the prior discussion was to resolve that part. {{u|Sdkb}} talk 23:04, 2 April 2021 (UTC)
    The reaction thus far to this proposal does not sound like "whether to change the icons or not was uncontroversially litigated and everyone who might possibly have been interested decided there was a problem". (There are quite a few prominently missing names in that conversation -- pinging @SandyGeorgia, Ealdgyth, Gog the Mild, Wehwalt, Ian Rose, Casliber, The Rambling Man, Epicgenius, Vami IV, Lee Vilenski, JPxG, Johnbod, and Serial Number 54129 as a small selection of people I might expect to have opinions, and I'm probably missing tons of names.) Vaticidalprophet 23:12, 2 April 2021 (UTC)
    Never saw the discussion, and don’t see it as having any kind of broad consensus now that I have seen it. People, if you want to keep messing with content review processes at least notify them. This is make work. So while I’m here, Oppose the notion that any change is needed or helpful. SandyGeorgia (Talk) 23:38, 2 April 2021 (UTC)
    Nor did I, and mildly alarmed to find myself on the "selection of people I might expect to have opinions"! I seem to have arrived here just in time to see the stern of the ship sinking below the waves, so I'll just say that on a quick look the proposal seemed uncompelling. As Martin Poulter says below, the main problem with our icons is that most readers don't know we have them, nor understand them. Can't see this changing that. Johnbod (talk) 03:05, 3 April 2021 (UTC)
  • With respect, this seems like a solution in search of a problem. Insofar as, right now, readers see the gold star or the green icon in the top right of an article and know that means the article has been through some kind of peer review (which, anecdotally, I know is a benchmark many non-Wikipedia users use, for better or worse, to assess the veracity of an article), why we would want to change that for the sake of our own design preferences is beyond me. Minor cosmetic changes that keep the basic gold star and green icon for the FA/GA classes are fine, but I strongly oppose changing the green icon to something that is a completely different color. Go Phightins! 22:34, 2 April 2021 (UTC)
  • As well as thinking these changes are unnecessary, I view the symbols as being no more clear than the current ones, and in the case of the good articles, significantly less clear, as well as visualy unappealing. Nosebagbear (talk) 22:48, 2 April 2021 (UTC)
  • I don't think that the A–Disambig icons need to be changed. Just going to point out that with the change to flat, what about the other 10 icons that will be left with a shadow/3d, nothing quite like inconsistency. The stub/start will probably be harder to differentiate between since the icons are so small. I don't mind the FA/GA but I don't support replacing already acceptable icons. Terasail[✉] 22:51, 2 April 2021 (UTC)
    • The though process was, if we indeed do come to a consensus for the FC/GA icons, then the other icons (A - dab, the other 10 you are referring to) would/should be changed for consistency. No reason we couldn't keep the start/stub icons the way they look now just without the drop shadow stylization. Pbrks (talk) 23:19, 2 April 2021 (UTC)
  • There was weak to no consensus for the idea the icons needed to change at all (I never saw that discussion), and this has all the same issues I mentioned back in the other discussion at Wikipedia:Village pump (proposals)/Archive 174 that was broadly attended. Pretty much, the changes aren’t needed, please go write and review some articles people; better yet, please initiate a badly needed GA sweeps. On the surface, it appears that the proposed icons are obscuring the fact that no other content review process except FAC is a community-wide process, rather one person’s opinion at one time, rarely re-reviwed, and seek to elevate GA to the same plane as FA by demoting the bronze star to a gold something the same as GA’s silver. Misleading. Others ahead of me, in this and both discussions, have explained the problems. Or, as Johnbod said once, Oppose per the Opposers. SandyGeorgia (Talk) 23:28, 2 April 2021 (UTC)
    • SandyGeorgia, "go write and review some articles" as a personal directive is absolutely inappropriate. People are allowed and should be encouraged to constructively edit Wikipedia however they like. If that's writing articles, great. If that's anti-vandal work, great. And if that's trying to improve the icons we use, great. Be kind and show some respect. Ed [talk] [majestic titan] 14:14, 13 April 2021 (UTC)
  • I think the proposed logos are not only less clear (grey question mark in a circle means "Good Article Candidate" -- really?), but too childlike and less visually appealing. — Goszei (talk) 23:36, 2 April 2021 (UTC)
  • Sorry. Respect the effort you've put into this; I understand design is difficult... but I don't like the new icons, particularly for FA. It's generic and fades into the background at small scales. I don't think there's enough padding between the star and the border. I might support a change to the GA icon, but not sure this is the right one. It's unclear what is being communicated to me by the stub and start icons. The changes to the others are fine, but minor. — The Earwig (talk) 23:37, 2 April 2021 (UTC)
  • I don't know about these. I agree that, overall, the icons used on Wikipedia might benefit from some kind of comprehensive review. For example, the fact that "good article" and "support vote" use the exact same image is a profoundly dogshit situation. Who decided that was a good idea? The distinctions between "FA candidate", "former FA", and "former FA candidate" are also bizarre and non-intuitive (to someone who is not a hardcore Wikipedia editor, these all look like random injured starfish). Moreover, the scale of quality goes magenta, dark green, red, orange, yellow, green, blue, green, yellow. While I agree that some change ought to be made (and there should be an enormous watchlist-pinging WP:CENT about it with several suggestions for icon schemes), I don't think it needs an update, and this one in particular doesn't really spark joy for me. Notably, the "silver" being used to denote GAs is... that doesn't look silver, it looks gray. Also, it removes some good stuff: right now, the jagged former-GA icon very clearly shows that it was a GA and then was "broken", whereas a little dotted star shows nothing. jp×g 23:59, 2 April 2021 (UTC)
  • I don't think the proposed icons improve over the current ones aesthetically, but there are also more serious problems. The use of a question mark is too firmly associated with DYK and should be kept out of FA/GA icons to avoid confusion. Moreover, the proposed FA and GA icons have exactly the same geometric design and are distingished only by colors. IMO that already renders the entire proposal unacceptable. A substantial portion of our readers are color blind. They will face a great difficulty in telling the GA and FA icons apart and some just won't be able to do so. The FA and GA icons need to be clearly geometrically different from each other, and one should not have to rely on the color scheme to tell them apart. Nsk92 (talk) 00:06, 3 April 2021 (UTC)
  • I like the icons myself, but I must oppose the changing of the GA palette to gray. It does not and will not stand out against the default white background of Wikipedia. It must remain green. –♠Vami_IV†♠ 00:17, 3 April 2021 (UTC)
  • Comment Here's an icon for "Rearranging deck chairs on the Titanic": . EEng 03:26, 3 April 2021 (UTC) P.S. Someone's calendar is off. This came a day late for April Fools.
  • Oppose the need for a redesign in general, and especially the use of gray to indicate a GA. SounderBruce 05:02, 3 April 2021 (UTC)
  • Oppose. "Ain't broke, don't 'fix' it." One obvious problem with the extreme anti-skeuomorphism that is the current trendy fashion in UI (but which is already seeing a lot of pushback and probably won't last long), is that it can't visually represent gold and silver, they just come out as yellow and grey, since adding white and dark highlights to simulate metallic shine is not possible in an anti-skeuomorphic approach. And grey in user-interface design means "disabled, unavailable, or inapplicable". So, FAIL.  — SMcCandlish ☏ ¢ 😼  05:30, 3 April 2021 (UTC)
  • Oppose: I do not see a strong enough reason to change the icons. I think Nsk92 raises some very good points about this. Aoba47 (talk) 06:20, 3 April 2021 (UTC)
  • oppose - some of the individual logos aren't fantastic, but the suggested ones are significantly worse. I'm not here to say that everything we have is perfect, but maybe we should update an image at a time? I agree that the difference between a former featured article, and a failed featured candidate is a bit odd, but then these are generally only used in templates next to where it rights what it means. I do think we would benefit from explaining to users what a good and featured article is (when I first used the site, I got what "stub" and "featured" was, but not much else), but changing the logo designed doesn't help. Best Wishes, Lee Vilenski (talk • contribs) 07:26, 3 April 2021 (UTC)
  • Oppose. Whatever consensus was reached at the previous discussion, the number of opposing opinions here suggests that it is not very strong. The previous discussion should have been advertised better (i.e. at RFC or CENT). – Finnusertop (talk ⋅ contribs) 08:47, 3 April 2021 (UTC)
  • Oppose. I actually like the old ones better (sorry). Cas Liber (talk · contribs) 09:37, 3 April 2021 (UTC)
  • Oppose - this seems to be a solution in search of a problem. I'm not entirely sure what changing the icons will accomplish. ƒirefly ( t · c ) 09:41, 3 April 2021 (UTC)
  • Oppose at least for now, I want to see the actual proposed image files (see discussion section below) - looks like we only have a picture of the pictures so far? Also, agree that greyscale icons aren't as useful. — xaosflux Talk 10:23, 3 April 2021 (UTC)
  • Oppose. I am not against changing the icons in principle, although I would want to see much fuller discussion, but the suggested alternatives are hideous. And I agree with the comments that this all seems to be a solution in search of a problem; for example, "the overly detailed FC icon, which causes it to render poorly as small sizes" - I have it at 15px on my user page and it looks fine to me.Gog the Mild (talk) 12:26, 3 April 2021 (UTC)
  • Oppose. I don't think that the consensus achieved at that October 2020 thread is very strong, judging by the response here. As for the actual proposed icons, gray does not mean "positive" or "good", that's universally green. Question mark is for help. The proposed stub and start-class symbols are too similar. As an aside, I can't wait for this current trend of over-simplifying symbols to go away soon. RetiredDuke (talk) 13:20, 3 April 2021 (UTC)
  • Opposed (echoed). A consensus of eight is insufficient to change the mechanisms—however superficially—of multiple, highly active projects. Regardless of whether This thread is seeking to figure out how to change the icons, not if we should change them, it looks like you arenow enjoying a consensus to overturn a consensus. Land ahoy! ——Serial 13:30, 3 April 2021 (UTC)
  • Oppose No need for this. Paul August ☎ 16:22, 3 April 2021 (UTC)
  • Oppose. I didn't want to have to write here, but as it has been reopened I guess I will. I'm not set against the idea of changing the icons, although I equally don't really see a need to do so as I don't really find any of the reasons given particularly convincing (for much the same reasons as the others). However if you do still feel the need for change, work out what your design goals are, talk to the folks at Wikipedia:WikiProject Accessibility and follow their advice about how to make your ideals compatible with best practice. Only then will it be worth getting the pencils out. Thryduulf (talk) 17:46, 10 April 2021 (UTC)
  • Weak opposeI agree with Thryduulf there is no real need to revise most of these. However, in my humble opinion, i think you made fair points that the FA article's icon goes to waste as you cannot see the full details. I'll mention my opinions in detail on what should be done.Blue Pumpkin Pie (talk) 18:07, 10 April 2021 (UTC)
  • Oppose such a big change should come after a well advertised discussion involving a large number of editors. This is not the way to make such changes that affect everyone. Also the proposed new icons are ugly. --Ita140188 (talk) 05:38, 13 April 2021 (UTC)
  • Oppose I'm happy to have the icons improved. But I prefer the current set to the proposed new ones. A system of Gold stars for FAs and silver for GAs would make sense. But the most common hierarchy is gold, silver, bronze, so bronze then silver would be confusing. ϢereSpielChequers 12:03, 15 April 2021 (UTC)
  • Oppose I have no problem with the current icons, but it would be fine if they were modified. However, it's not just to the editors that spent their own time making the icons to have them replaced with logomakr.com stars. Lettlerhello • contribs 01:28, 22 April 2021 (UTC)
  • Alternative proposal
    I'm also leaning towards keeping the current icons. However, I drafted an alternative proposal using Microsoft Paint, so this could also be taken into consideration. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 21:54, 24 April 2021 (UTC)
  • Oppose Sorry, but the proposed icons are a no-go. And thanks for the needed chuckle 1234qwer1234qwer4. ;) ~ HAL333 20:38, 28 April 2021 (UTC)
  • Oppose all of the proposed designs per WP:AINT, we should focus on bigger issues. - Knowledgekid87 (talk) 17:49, 29 April 2021 (UTC)
  • Oppose the proposed set of icons over the current set, but would support maybe a different improved set over the current set. If my feedback helps, it was my dislike for the gray, and the way the stub, start class, and question mark symbols left me wondering what they were supposed to represent that swayed my decision. Huggums537 (talk) 05:42, 1 May 2021 (UTC) On a positive note, I like all the rest of the proposed icon set. Change the gray to some other color-blind friendly color, choose different symbols to replace the question mark, and represent the start/stub classes and I'm on board... Huggums537 (talk) 05:57, 1 May 2021 (UTC)

Discussion (article icons)

@Pbrks: (or anyone) can you make a table of before/after for these - that has been quite helpful in similar discussion about icons. — xaosflux Talk 21:18, 2 April 2021 (UTC)
@Xaosflux: Yes, I will make them shortly. Pbrks (talk) 21:26, 2 April 2021 (UTC)
@Pbrks: do you have these as actual files that are already uploaded that can be in a normal table instead of a picture of a table? — xaosflux Talk 23:45, 2 April 2021 (UTC)
  • I agree that the icons we use need to change and that they don't make much sense to casual users of the site, which is a loss because markers of quality are really important fo a critical engagement with Wikipedia. When I give training, it is almost always completely new information to people that Wikipedia even has a quality scale. I like the "promoted" and "former" icons, since "gold star" and "silver star" seem like a visual metaphor that people can understand from an early age, across a lot of contexts. The Featured buttons could be in a deeper hue to stand out more, but that's not much of a change. That said, the Candidate icons with a question mark in a circle, look like a "Help" or "Info" icon that a user would click on to get help with the user interface. The Former Candidate icons with a cross look a lot like the "Close tab" or "Close application" of some interfaces: buttons that a user would click to make something disappear. I can see what the List icon represents, but it looks an awful lot like the hamburger menu which is a very common navigational feature of web sites, and is the sort of thing that a user would click on to see a list of preferences or options. These potential confusions mean I can't support this iteration of the proposal, but I do think it is going in the right direction. MartinPoulter (talk) 21:26, 2 April 2021 (UTC)
  • The star outlines for former featured/good status are very thin—at small sizes I'd guess these are essentially just empty circles, which is presumably not the intention, right? I'd make them thicker. Even a full border (but hollow interior) would be visually distinct enough from current featured/good. At some point it would be good to play around with the individual image files in a sandbox, which you can't easily do with the icons all as one image, though I understand mass uploading of all the icons could be a bit tedious. — Bilorv (talk) 21:31, 2 April 2021 (UTC)
  • Meta point -- should the bullet points in support/oppose be converted to numbered lists for readability? Vaticidalprophet 00:12, 3 April 2021 (UTC)
  • I don't oppose the concept of people designing new art work, allow editors to edit to their strengths. Just because something is new doesn't mean it's bad. I'm not a fan of the "Start" and "Stub" icons, may want to come up with something a bit different there. I don't see any ships sinking, deck chairs being rearranged, and I certainly wouldn't insult someone for proposing an idea as an April Fool's joke. Perhaps just in an effort to get some sort of "social capital" in the name of humor? But, as they say, YMMV. — Ched (talk) 07:16, 11 April 2021 (UTC)

Taking a step back

  • I started this proposal after a closure request for the previous one decided that the outcome was fairly self evident with support ... editors interested in taking on this work have a mandate to do so. and the request moved forward at the Illustration workshop. It's fine that Prop 1 wasn't held in high regard, but it's just a proposition -- things can be changed, style can be changed. However, it's a bit disheartening and demoralizing to get comments of hideous Web Whatever.0 design and to go write and review some articles instead. I don't understand why people can't just give their opinion without being nasty about it. It's human nature to resist change, I get that, but the fact remains that this renders terribly at 20px and has literally confused people in the past, as it also is used for the "support vote" symbol. Moreover, the subicons for these (particularly the GA icon) don't make much of any sense. The former FC icon has a unsightly, stylistically different "X" through it. The reassessment icon is a broken GA icon? The former GA icon is the same as the former GA candidate icon ? All three of the aforementioned are the same except for color (in which Nsk92 makes a good point about color blindness)? To believe that nothing needs to be changed is beyond me. I don't see much of a reason to move forward with any different kind of proposition given the previous comments. Pbrks (talk) 05:31, 3 April 2021 (UTC)
    The only argument of the bunch that rings in any way true to me is 's ambiguity, and even that I'm skeptical about -- the only real context I ever see it used to denote support votes is...GAN, where it in fact makes perfect sense. Is hyper-anti-skeuomorphism and a redesign ten people asked for really a better solution than "rename " or just straight up "we have a million support vote symbols, some will overlap"? It's also honestly bizarre to me that the previous proposal was closed as a mandate when it had no participation from the people highly involved in the relevant process, many of who have since come out in strong opposition. Vaticidalprophet 06:17, 3 April 2021 (UTC)
    (Addendum: readers interested both in the 'million support vote symbols' comment and in why trying to redesign Wikipedia's house styles for icons is both a huge job and a thankless/anti-thanked one are pointed here.) Vaticidalprophet 06:25, 3 April 2021 (UTC)
    I participated in the first discussion and I think I'm highly involved in the GA/FA/FL process. — Bilorv (talk) 22:08, 19 April 2021 (UTC)
    I just responded to the "go write and review some articles" comment. As a personal directive, it's absolutely inappropriate. People can (and should!) constructively edit Wikipedia however they'd like. Ed [talk] [majestic titan] 14:19, 13 April 2021 (UTC)
    I appreciate your efforts in design, Pbrks, even though I don't support the change. The rudeness in this discussion towards you was particularly blatant and unacceptable. — Bilorv (talk) 22:08, 19 April 2021 (UTC)
  • Class icons B, C, Start, and Stub don't need to be revised as their icons aren't visible on the article or talk page. I do think Good Article and Featured Articles are great milestones that need to be highlighted in the article. I like the Gold-Star, Silver-star because they can illustrate to both readers and editors that they are the cream of the crop. Especially with a Silver Star instead of a Green Plus symbol can give editors an indicator that it's almost a Featured article (Gold Star). But the recreated icons don't stand out enough for new readers to notice or for editors to care about. If the icons are going to be revised, they have to be visually appealing and something that readers/editors can approve of.
I googled the words "Quality" and "Icon" and I found a lot of metals with ribbons attached to them. We can have a gold jigsaw puzzle to indicate the Featured article, and a silver jigsaw puzzle to indicate Good Article. I'm just being creative at the moment. So long as these icons shine and stand out positively, then maybe editors may support the proposal more. The dotted line forming a star isn't clear to me, and the Question mark resembles the DYK icon. I think it would be easier to use a magnifying glass over the current icons for representing re/assessment. The current Red X and Broken GA (in my humble opinion) are upsetting and can be discouraging. The red-painted cross over the featured article and the broken GA symbol is just not professional icons in my opinion and even look like there's anger involved.Blue Pumpkin Pie (talk) 20:11, 10 April 2021 (UTC)
  • Personally, there are just a handful of reasons for me personally to support this, and the main one is that this is more enticing to readers. Sure, many Wikipedians don't care about "Web 3.0 minimalist design", but a lot of casual readers expect it, especially on a highly visited site like WP. EpicPupper (talk) 04:41, 9 May 2021 (UTC)

Licensing

Post-close

It's regrettable that a constructive idea was shot down so quickly (less than a day!) and for such poor reasons. Sometimes it's good to discuss new ideas even if they're not immediately going to fix an urgent problem, we might uncover issues that the early knee-jerk WP:AINTBROKE crowd hadn't thought of. And frankly our FA icon at topicon resolution (where readers normally see it) looks like it was drawn on the back of a napkin with a sharpie and digitized with one of those old hand-held roll scanners, or else shrunk from its original size down to 10px and then scaled up again. Putting this blighted icon on a featured article makes the article less good. I realize it's what readers and editors are used to, but that's not a good enough reason on its own to keep it, and certainly not to shut down a discussion about it after just over 18 hours. Just a plain bordered star in the same colour would be not so much of a departure from the current icon as to be confusing, and would be a fair improvement. But I guess nobody wants to talk about improving the encyclopedia. Ivanvector's squirrel (trees/nuts) 19:22, 8 April 2021 (UTC)

I agree. Since the close mentions SNOW, I also want to point out this section of the essay saying: "It can sometimes be better to allow a few extra days even if current discussion seems very clearly to hold one opinion, to be sure that it really will be a snowball and as a courtesy to be sure that no significant input will be excluded if closed very soon." In general, I like the proposed designs for FA and GA (though agree that the good-article-grey is a bad color choice). They read much better at small sizes, are symbolically more clear (an absent star and question mark are a lot more intuitive than the existing symbols), and the style matches the recently redesigned protection icons providing a more unified design. I hope we can give these ideas more serious consideration next time around. — Wug·a·po·des​ 23:29, 8 April 2021 (UTC)
Agreed, though the proposal in its fullest form might be seen a snow close, a lot of opposers offered sympathy for specific improvements. The latter is valuable information that could thoroughly inform future discussions, but has been halted unnaturally. Aza24 (talk) 23:34, 8 April 2021 (UTC)
I disagree - this specific proposal was correctly SNOW closed because it was very clearly never going to get a consensus. There is nothing stopping you or anyone else going back a step or two and initiating a discussion to generate a broad consensus for the need for change (which hasn't yet occurred). If there is a consensus for change, then the next step is to workshop multiple designs, implementing the results of feedback received, before presenting a small number of well developed proposals for adoption. Getting more of the same feedback on this proposal and more reminders about the lack of consensus that a need for changes exists is not going to help that. Thryduulf (talk) 17:12, 9 April 2021 (UTC)
Yes, how terrible for Wikipedia that someone with an idea wanted to talk about it, but didn't get permission from The Community first. What a sterile, needlessly bureaucratic place this is becoming. Ivanvector's squirrel (trees/nuts) 12:55, 10 April 2021 (UTC)
  • @Ivanvector, Wugapodes, and Thryduulf: Re-opened per request. --TheSandDoctor Talk 17:31, 10 April 2021 (UTC)
  • Is there any evidence that any more than a minuscule percentage of our readers understand the current icons, and that any more would understand redesigned icons? In the absence of that this seems like yet another make-work project that imposes change for change's sake on both readers and editors, taking people away from improving the encyclopedia. There seems to be a theme of following the advice of self-appointed experts in both programming and design, but ignoring the people who actually create this encyclopedia. Phil Bridger (talk) 18:01, 10 April 2021 (UTC)
    1. You're probably right that only a minuscule percentage of our readers understand the current icons. I mean, there's a reason why one of the files is called File:Symbol support vote.svg and is usually used for supporting/opposing permission requests/deletion discussions (eg on meta/commons). It's doubtful that this is a carefully thought out icon set that works well in cohesion with other icons, rather than just stuff formed independently over time. This is hence something we might be able to improve.
    2. I dislike the recent themes of trying to create a bit of a "us vs them" (ie "content creators" vs "admins/software developers/designers/whatever else"). Everyone is trying to achieve the same thing here - a decent free resource for information. Some people are better at different things. No doubt the people who have 90 FAs under their belt are great at writing content and valuable contributors. Also no doubt the people that write bots that save hundreds/thousands of hours of repetitive manual labour are also valuable contributors. Similarly, those who have experience with design and user interfaces are more likely to know what makes for a good, intuitive layout. There's no reason to think that those with one type of skill are better than any other type of editor, or are more apt at doing every task than others.
    3. I don't think anyone is ignoring anyone. Pbrks made a proposal based on a prior RfC, and above appears to be trying to work with people to figure out issues and improve. It is unlikely that this proposal is the best possible solution, but it can only be improved with feedback, and if people discuss their issues perhaps Pbrks (and/or others) can adapt the icons based on that. It's impossible to just guess what people want. But at least some of the ideas presented, such as using a question mark to represent a GAR/FAR(C), are broadly good ideas and more intuitive than the current representations.
    ProcrastinatingReader (talk) 19:00, 10 April 2021 (UTC)
    I dislike the recent themes of trying to create a bit of a "us vs them" I agree strongly with this. The proposal requires literally nothing from Phil (unless he manually draws the FA icon every time we promote an article), yet somehow he seems deeply concerned about the burden this will impose on editors. Seriously? Just say you don't like the design and move on, but don't pretend like you have veto power over how volunteers decide to spend their time. If you want to rail against "self-appointed experts" wait until you find out who writes our content. — Wug·a·po·des​ 22:25, 10 April 2021 (UTC)
  • Does the foundation have a usability team that supports the software we use and can provide us with recommendations on issues like this? ElKevbo (talk) 21:38, 10 April 2021 (UTC)
    There is the Design team, and they seem to do nice work (see mockups at mw:Streamlined Infoboxes for example). No idea how you'd get in touch with them though. Phabricator task maybe, but the backlog on those looks long... Email or IRC perhaps? ProcrastinatingReader (talk) 23:51, 10 April 2021 (UTC)
    A bit late, but I'd suggest reaching out on wikitech-l. There used to be a specific design mailing list, but it's not really used these days. Legoktm (talk) 07:35, 16 May 2021 (UTC)
  • I'm not sure the reopening here will really help. Putting together the prior discussion and this one, my read is that there's substantial discontent with the current icons and weak consensus that they ought to be changed, but also fairly clear consensus that the specific proposal here isn't yet ready to be adopted. I think the best path forward is to take a step back and work on refining the design, and then come back to a prominent venue when that is ready.
The one thing I'd say while this is in the spotlight is that, for any editors graphically-inclined, it'd really be helpful to have additional help with that. Wikipedia:Graphics Lab/Illustration workshop/Archive/Sep 2021#Good article and featured article topicon redesign has been sitting around for months and hasn't yet gotten the level of engagement that I'd hope for it to get. {{u|Sdkb}} talk 23:00, 12 April 2021 (UTC)
This should be re-closed per WP:DEADHORSE, its been a month already. - Knowledgekid87 (talk) 01:53, 4 May 2021 (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.

User:SlimVirgin userspace pages

As many will know, User:SlimVirgin has passed away. There are a little over 120 subpages in her userspaces, some of which are drafts for articles or collections of notes. Many are currently blank but have substantial edit history of past draft work. Someone should curate these pages. If she had drafts in progress, her intent may have been to eventually work these into articles. BD2412 T 02:19, 10 May 2021 (UTC)

Fortunately there is no deadline for userspace pages. If she had anything in progress in draftspace though it would be best to work on them before they get G13ed - I don't know what happens regarding notifications for users who've opted out of bot messages? Thryduulf (talk) 02:39, 10 May 2021 (UTC)
There is no deadline, but they could be forgotten and left to sit undeveloped forever. BD2412 T 02:49, 10 May 2021 (UTC)
True, but my point was that before worrying about what to do with pages that have no deadline, ascertain whether there are any that do and, if so, work out what you want to do with those first. Thryduulf (talk) 23:08, 10 May 2021 (UTC)
I appreciate your note to let us know. by the way, some of those pages are actually empty, with no content. is it okay to delete those? it would be a bit convoluted to sift through the edit history of each page, wouldn't it? ---Sm8900 (talk) 🌍 23:14, 10 May 2021 (UTC)
Yes, in retrospect I would think those pages, having been blanked by SV, would be ripe for deletion. If SV had wanted their edit history to be noted somewhere, she knew how to do that. BD2412 T 23:23, 10 May 2021 (UTC)
BD2412, I'll take a look. — Alexis Jazz (talk or ping me) 23:37, 10 May 2021 (UTC)
User:SDZeroBot/SlimVirgin_drafts shows an overview of the remaining pages. – SD0001 (talk) 08:55, 15 May 2021 (UTC)
BD2412, Thryduulf, SD0001: I've added snippets to User:Alexis Reggae/SlimVirgin userspace pages (similar to the page from SDZeroBot but no updates) and sorted some more. (nowhere near done) The only page creation in Draft: seems to be Draft:Maya Morsy, a redirect. She contributed to Draft:List of countries by prevalence of circumcision and female genital mutilation. @GreenMeansGo:, any chance you could help with anything? — Alexis Jazz (talk or ping me) 07:34, 19 May 2021 (UTC)
This proposal would need much more development for even a subset of it to be implemented, moving this to Idea Lab to avoid just snow-closing this. — xaosflux Talk 14:00, 19 May 2021 (UTC)

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.

Moved to WP:VPI

I have been through Category:All articles with too few wikilinks and I think a bot to link every word with a article on it would be good. It would mean editors don't have to go and make links anymore. Give me your opinions. TigerScientist Chat > contribs 20:21, 18 May 2021 (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.

Citations

Moved to Wikipedia:Village pump (idea lab) § Citation needed tagging in VisualEditor
 – Tol | Talk | Contribs 05:10, 25 May 2021 (UTC)

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.

I think the ability to be able to select and place "citation needed" through the cite feature in the visual editor with a single click would be helpful. Not needed but it would save time. TigerScientist Chat > contribs 21:05, 18 May 2021 (UTC)

Copy the following text and paste it in any article: {{cn}} This will simply work with the visual editor in the way you're requesting. ~ ToBeFree (talk) 21:09, 18 May 2021 (UTC)
ehh I guess maybe. TigerScientist Chat > contribs 15:10, 19 May 2021 (UTC)
You may want to post this on Phabricator if you really want this, however I think that just using the template is easy enough personally. EpicPupper (talk) 19:00, 19 May 2021 (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.

Minor edits

I sometimes forget to toggle minor edits. Maybe the a bot or something automated can automatically determine if it is minor or not. It is already pretty simple so I can see why people wouldn't want to put so much effort into this. TigerScientist Chat > contribs 20:00, 24 May 2021 (UTC)

Bots don't have the technical ability to change the minor tag of another person's edit (I think), so this is technically impossible. The MediaWiki software could, but it'd probably be a fair bit of work to cook up a decent algorithm to predict whether an edit is minor or not. ProcrastinatingReader (talk) 22:41, 24 May 2021 (UTC)
Interesting. TigerScientist Chat > contribs 23:12, 24 May 2021 (UTC)
  • It's impossible to edit the minor edit flag once a revision has been saved, it's permanently burned into the database, just like the edit summary, timestamp and revision ID.
  • Just like your suggested link bot this program would need to have near human intelligence to determine what is a minor edit or not. Removing a large chunk of text added as vandalism is a minor edit, removing a large chunk of text because it is undue is not. Replacing a dead link in a citation with an archive link is a minor edit, replacing a dead citation with a different site is not. Replacing a number in a table because the previous editor made a typo copying it from a source is a minor edit, replacing a number in a table with a more recent one from the same source probably is not. Removing a Bengali name from an article where it is completely misplaced (e.g. Computer) would be a minor edit, removing an armenian/azeri name from a place in Nagorno-Karabakh would not be.
Your proposed bot would need to be making editorial judgements about what is "uncontroversial" - that is something that would essentially require a AI. 192.76.8.73 (talk) 09:43, 25 May 2021 (UTC)

Highlighting system

Recently I have been copyediting some Wikipedia articles and fixing grammar issues, however I have noticed that the templates don't specify where is the issue in the article, and it becomes a tedious problem in a long one. I was just wondering about proposing a new system in which editors can highlight the actual issue in the articles, so that way it becomes easier to find the paragraph or sentence that needs to be fixed, especially in lengthy articles. Pink Saffron (talk) 16:54, 18 May 2021 (UTC)

A template "language problems" and another one called "spelling issues" might be needed yes.

--Joujyuze (talk) 17:41, 18 May 2021 (UTC)

I think something like this would be a good idea. Two things I dislike: 1)- a tag that is vague with no obvious issue and nothing on the talk page. Maybe it is just too much work to travel all the way to the talk page. A simpler system to go along with a tag might certainly make a difference, 2)- A career tag dated 2007 (any tag in the 3-year range) and many edits and editors since then until now. If I can't find the issue that a tag is supposedly used for I have removed them with talk page comments. I have also sent messages to the editor that placed the tag. All of this creates a longer maintenance time for each article and less available time to look at more articles. Otr500 (talk) 19:00, 18 May 2021 (UTC)
@Pink Saffron, Joujyuze, and Otr500: We have {{Verify spelling}}, {{Clarify}} and similar templates that can be used inline. {{Copy edit}} also supports per section tagging. All of those also support a reason parameter that can specify the exact problem. – Finnusertop (talk ⋅ contribs) 00:38, 19 May 2021 (UTC)
@Finnusertop: That's glad to hear! Thanks for notifying me
Too bad they are not used as much as they should be. We can turn on highlighting editing that I think would be of less importance than highlighting issues. Of course, some talk page comments would go a long way. Otr500 (talk) 01:12, 19 May 2021 (UTC)
I am generally in favour of more specific marking of tagged content. Pale highlighting could work. Explanation/reasons could be added via edit summary. Might be good to leave a mouse-over to show the reason and identify the tagger as well. · · · Peter Southwood (talk): 15:37, 19 May 2021 (UTC)
If the highlight only show up on mouse-over of the tag they would be less obtrusive, alternatively they could require an opt in setting to be default visible. · · · Peter Southwood (talk): 15:42, 19 May 2021 (UTC)
I'd honestly think a more suitable addition would be a more aesthetically pleasing highlighter marking so that it doesn't look like a blushing tomato Pink Saffron (talk) 17:40, 19 May 2021 (UTC)
I think that the best system would be to return to what I'm sure there was when I started editing Wikipedia - that there should be an expectation that, unless the issue is blindingly obvious, the tagger should state their concerns on the talk page. It is unlikely that this will actually happen, because many people who add tags seem incapable of doing anything that is not automated by Twinkle. We really need to stop valuing quantity over quality. Phil Bridger (talk) 18:23, 19 May 2021 (UTC)
I agree 100% (see above). Career tags that were only clear to the tagger at the time serve little purpose. Another solution is to just delete the tag with talk page comments. -- Otr500 (talk) 04:36, 28 May 2021 (UTC)

Edit filter for AWS URLs that expire

This is a proposal to create an edit filter to block the addition of URLs that pull content from AWS with an expiration time. Example (search on &Expires)

URLs of this type can be identified if they include &Expires=1621985387 where "1621985387" is a unix timestamp seconds since 1970 (converter). The expiration time is often 1 hour or less, after which the URL ceases to function and becomes link rot.

I set up a program to monitor for new inclusions, and issue a SavePageNow at Wayback before it expires, however this is not really working well: the URLs are often already expired by the time the content is committed to Wikipedia and/or the URL was copied from another page or revision and long since expired and/or the program which runs twice an hour doesn't catch it in time and/or the content also requires a password/login which Wayback can't get beyond.

There were old cases in about 550 pages, I ran a bot and checked for working Wayback links to "save" them, it found 35, or about 6% were salvageable the rest were permanently dead with no hope of saving. New one's are being added at about 5-7 a week. These URLs can usually be substituted with more permanent links to the same content (example) - but users will continue to add these links because they work in the moment and there is no realization they expire. -- GreenC 00:31, 26 May 2021 (UTC)

So why? What should the editor use instead? WP:SAYWHEREYOUGOTIT says to do just that. Now, it could be that these are just purley unreliable sources - and that would be a reason, and the deny reason could tell the editor why. Basically, if we want to deny this on a basis that they are always bad, it needs to be coupled with a message of why this is an unacceptable source. — xaosflux Talk 00:42, 26 May 2021 (UTC)
The source (ie. citation), and the URL, are different things. URLs are not required in a source, they are optional. Unclear why we are knowingly adding dead URLs that can never be archived, taking up the |url= spot. -- GreenC 01:50, 26 May 2021 (UTC)
Is it dead on arrival? What if it "expires" in 20 years - does that make it useless for readers now? In the example you put above, if the editor would have left that blank instead of putting in that cloudfront.net link - wouldn't it have been worse for a reader or other editors? — xaosflux Talk 10:50, 27 May 2021 (UTC)
Sounds like a good idea. Mathglot recently raised a similar issue with library proxied URLs which could maybe be addressed with an edit filter as well. We should't stop people copying and pasting an unstable URL from their address bar instead of the permalink from the page, but it wouldn't hurt to have an informative warning telling them it's a bad idea. – Joe (talk) 11:05, 27 May 2021 (UTC)
Would it be possible to bot replace such links? Jo-Jo Eumerus (talk) 11:19, 27 May 2021 (UTC)
No, other than adding a {{dead link}} -- GreenC 00:04, 29 May 2021 (UTC)
Filters can be requested at WP:EFR, but I think this falls into bad use for a filter, because the filter should mainly be used for abuse, not to enforce possibly 'bad' edits. A bot would be preferable, if there's consensus. ProcrastinatingReader (talk) 13:25, 27 May 2021 (UTC)
I agree that a bot would be better, or even increased frequency if one already runs. Edit filters run on every edit which is a lot of work for little gain, so it might be better to fix it after the fact or notify those who added it (like disambiguation links) rather than check every edit for expired links. — Wug·a·po·des​ 20:27, 27 May 2021 (UTC)
What would a bot do, though? I don't think these can be automatically fixed. – Joe (talk) 11:40, 28 May 2021 (UTC)
User:Wugapodes suggested a talk page notification. Plus a {{dead link}} .. might be a way to go. -- GreenC 00:04, 29 May 2021 (UTC)

Simplify your signature

Moved to Wikipedia:Village pump (miscellaneous)/Archive 66 § Simplify your signature
 – {{u|Sdkb}} talk 17:42, 30 May 2021 (UTC)

Reverting to a stable version of a page, to stop continuous editing of a section, while it is being discussed on a Talk page section

I wanted to ask about the practice of reverting to the previous stable version of a page, while the content of a page is being discussed. I have seen this in practice, where a talk section is established to discuss specific article content, (or an RFC) – and while it was going on, editors were asked to not make changes, and the page was reverted to the long standing version of the page that reflected the section that was being discussed. Then after the consensus was achieved, the page was changed to reflect the decision of the consensus.

The point of this being (1) it stopped random editors who were making changes to the section (with the possibility of starting an edit war) rather than being part of the discussion (2) reverting to the stable version meant that people coming to the talk page discussion, could see the content on the page that was the subject of the discussion.

There’s no rule about this that I could see, I have seen this done, and assumed it was normal, but is this common practice on Wikipedia?... If not, is it a good idea?... I would appreciate your thoughts Deathlibrarian (talk) 02:18, 25 May 2021 (UTC)

WP:BRD and WP:STATUSQUO may be relevant here. BRD refers to the bold, revert, discuss cycle, where someone makes a WP:BOLD edit, which is reverted, then a discussion should be started instead of the bold edit being reinstated and beginning and edit war. STATUSQUO refers to leaving the status quo ante while the issue is being discussed, so the first, stable version remains until the issue is resolved. —El Millo (talk) 04:22, 25 May 2021 (UTC)
Ah, ok, brilliant, thank you! That may be the policy I couldn't find. It looks like the editors were in fact following this policy. I'll have a read, cheers. Deathlibrarian (talk) 04:43, 25 May 2021 (UTC)
WP:STATUSQUO has very wide acceptance, but unfortunately it's located within an essay, not a policy or guideline, so I've occasionally seen WP:NOTPOLICY raised in response. It'd be nice if we rectified this. {{u|Sdkb}} talk 16:48, 25 May 2021 (UTC)
Yeah, "During a dispute discussion, until a consensus is established, you should not revert away from the status quo" I've seen people do it and assumed it was standard protocol, but when I did it, I got called out on it and couldn't find the policy for it. Thanks so much, that was driving me nuts!!! Deathlibrarian (talk) 09:01, 26 May 2021 (UTC)

Add Current Time to place entries

CLOSED
Proposal is Rejected by the community; Heavy snow close. GenQuest "scribble" 05:11, 5 June 2021 (UTC) Non-Administrative closure

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.

Many place entries (ie. Karachi, Santa Monica, Chittagong, etc.) include that location's time zone. It would be very helpful if these entries also included the current time.

For example, the listing for Pakistan contains an attribute of Time Zone, which indicates "UTC+05:00 (PST) DST is not observed." However, this doesn't tell the visitor what time it currently is in Pakistan.

The current time is not standard information in that it needs to be dynamic. This can be accomplished using an API or javascript to calculate the current time in the place entry's location.

  • NOTE: This feature would not be available for place entries that span multiple time zones.
  • NOTE: Pages for the various Time Zones display the "Current Time". For example, the page for "UTC+05:00" displays "Current Time" as "22:33, 2 June 2021 UTC+05:00" and includes a link for refreshing this value. So why can't this information be included in all pages that list Time Zone as "UTC+05:00"? It will save everyone from having to navigate away from the original page just to see the current time in that Time Zone.

I look forward to hearing everyone's thoughts on this feature request/proposal.

The design.

Thanks, Noah — Preceding unsigned comment added by Nbardach (talk • contribs) 04:57, 2 June 2021 (UTC)

  • There might be technical barriers to this (e.g. WP:Purging), but to focus on the editorial side, I'm somewhat wary that this might run afoul of WP:NOT as unencyclopedic short-term information. It's an interesting thought, though. {{u|Sdkb}} talk 05:38, 2 June 2021 (UTC)
    • Technical problems aside, we are WP:NOTPAPER so I don't think WP:NOT should stop us from including the time. It's an extension of encyclopedic material (time zone) that uses our electronic medium so I can understand why it's suggested. If it were actually possible, I think it would be a good idea. — Wug·a·po·des​ 21:31, 2 June 2021 (UTC)
  • Strong Opppose - this would either require invalidating caching, or as suggested require running client-side scripts on every single page to modify the document - which will not be consistent across clients. Now, if someone wants to make a USERSCRIPT that will query wikidata:Property:P421 and try to figure something out, then more power to you. Keep in mind that many articles about locations will span multiple time zones, and summertime values may also vary widely. — xaosflux Talk 14:05, 2 June 2021 (UTC)
  • Oppose. We have enough issues with ages not getting updated on articles; trying to keep a clock accurate is a technical feat of another order. Besides the multiple time-zone issues, there is also the issue of summer time, which has widely different applications. Best option is a link to the time zone for the user to look it up themselves; second best alternative is a link to a site(s) that show local time. —C.Fred (talk) 18:06, 2 June 2021 (UTC)
  • Oppose. While "Wikipedia is not a clock" isn't specifically mention in WP:NOT perhaps it should be - maybe under WP:NOTGUIDE. C.Fred's mention of the problems with the way daylight savings time is observed (or not in some cases) is a major stumbling block as well. There is also the case of places like the state of Indiana in which some counties are in the eastern time zone and some in the central. MarnetteD|Talk 18:18, 2 June 2021 (UTC)
  • Question. Surely this would require changing times in articles too frequently to be a practical proposal? Rollo August (talk) 21:14, 2 June 2021 (UTC)
  • Comment It looks like most of the comments above are thinking about it from the perspective of having the current time in the wikitext (directly or via parser functions), which would be insane. If we were going to do something like this, the HTML should include machine-readable markup and the actual time display should be entirely done via JavaScript. If someone lacks JavaScript in their browser, they would just see the timezone as they would now. Anomie⚔ 22:14, 2 June 2021 (UTC)
    I take it this would be a quite large addition to common.js then? I have to admit that does sounds slightly less like a non-starter than parser functions or bots. Still, I doubt this is a good idea. --Trialpears (talk) 22:18, 2 June 2021 (UTC)
    Maybe not, if we limit it to browsers that support Intl.DateTimeFormat's timeZone option with the appropriate input value. Anomie⚔ 11:59, 4 June 2021 (UTC)
  • Question. If it is feasible to display the current time in all the Time Zone entries, why is it not feasible on the pages that reference that Time Zone? Can we not just use the same mechanism?Nbardach (talk) 23:16, 2 June 2021 (UTC)
    • @Nbardach: in short: it isn't. Going to any of those pages as a normal reader is most likely to provide the wrong time - making the article normally inaccurate - those should probably be removed. Also, for "places" in general - as noted above many places span multiple time zones with multiple summertime adjustments. For example Australia is obviously a "place" - what is the time there right now? — xaosflux Talk 14:16, 3 June 2021 (UTC)
    • @Xaosflux: Thanks for the explanation. To answer your question, per my note above, "places" spanning multiple Time Zones would not display a Current Time. Another solution would be to display the current time next to any instance of a Time Zone (ex. "UTC+05:00 (22:33, 2 June 2021)). Your thoughts? Nbardach (talk) 15:50, 3 June 2021 (UTC)
      • @Nbardach: same caching problem - but also even for a place that only has one canonical time zone, "local time" would also needs to account for summertime offset (and a quick random sampling of places appear that they don't programmatically include their summertime windows). Again, I'm fine with anyone that wants to run a userscript to insert something to their own view - but not to try to force every page to load such a script for readers across all platforms - or to try to use a template that will not update the cached output until next publishing (so that it will basically always be inaccurate). — xaosflux Talk 16:01, 3 June 2021 (UTC)
        • @Xaosflux: I see. UTC is always a dependable time. Perhaps just displaying the time at UTC for each instance of a Time Zone would work? (ex. "UTC+05:00 (UTC: 17:33, 2 June 2021)" ). Nbardach (talk) 16:08, 3 June 2021 (UTC)
          • That is still the exact same problem about actual local offset, and about caching. — xaosflux Talk 17:35, 3 June 2021 (UTC)
            • @Xaosflux: Don't mean to drag this out, but can you please clarify. Why is there a local offset issue if the proposed format for each instance of a Time Zone is "[TIME ZONE] UTC: [UTC CURRENT TIME]"? Ex: "UTC-09:00 (UTC: 18:15, 3 June 2021)" Nbardach (talk) 18:16, 3 June 2021 (UTC)
              • Because of summertime. For example, where I live right now it is officially UTC-5, but for a large portion of the year the local time is UTC-4. And when (and even if) summertime starts and ends varies by locale. — xaosflux Talk 18:45, 3 June 2021 (UTC)
              @Nbardach, I've sent a note to one of the devs to confirm, but assuming I'm right, the way it works is this:
              • You edit a page at 18:15, 3 June 2021 (UTC). Let's say that you put a "current time" code on the page.
              • The server turns the wikitext into HTML at 18:15, 3 June 2021 (UTC) (or maybe a minute later). When it does that, the current time, which is 18:15, 3 June 2021 (UTC), gets written as plain old text in the HTML.
              • If no further edits/updates are made to that article, then that HTML copy gets used for the next 30 days ("cacheing"). In practice, this means that:
                • When you read it an hour later, it still says the time is 18:15, 3 June 2021 (UTC).
                • When you read it the next day, it still says that the time is 18:15, 3 June 2021 (UTC).
                • When you read it the next week, it still says that the time is 18:15, 3 June 2021 (UTC).
              To do what you want, they would have to change the server's system from "unless there are more edits, then one copy lasts for 30 days" to "unless there are more edits, one copy lasts for only one minute". Whatamidoing (WMF) (talk) 18:38, 3 June 2021 (UTC)
              Although this is true, we can bypass caching via purging (~1440 req/day, per 500 pages) or use JavaScript. Technically this is feasible, if consensus wanted to proceed. ProcrastinatingReader (talk) 00:19, 5 June 2021 (UTC)
              The current UTC time is the same everywhere, so I'm not sure I see the point in displaying it any time a time zone offset is mentioned in an article. isaacl (talk) 20:15, 3 June 2021 (UTC)
  • Grateful to everyone for their critical thinking and feedback. That proposed infobox is SWANK!! I think I'm going to reformulate my proposal as a different display for UTC. This would be less technically challenging (b/c UTC is constant) and should address many of the issues that have been raised here. Cheers, N Nbardach (talk) 04:30, 5 June 2021 (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.