*'''Comment'''- LOL, "takeover bid". What absolute nonsense. [[User:Reyk|<b style="color: Maroon;">Reyk</b>]] <sub>[[User talk:Reyk|<b style="color: Blue;">YO!</b>]]</sub> 14:10, 2 May 2021 (UTC)
*'''Comment'''- LOL, "takeover bid". What absolute nonsense. [[User:Reyk|<b style="color: Maroon;">Reyk</b>]] <sub>[[User talk:Reyk|<b style="color: Blue;">YO!</b>]]</sub> 14:10, 2 May 2021 (UTC)
*'''Support''' Per NickMoyes's data above. We should not be dividing our efforts because having too many venues confuses newbies. It's best to steer new editors to a single place to ask questions or make requests, and the Teahouse got 30x more traffic than WP:EAR in 2020 so I think we should go with that one. Editors active at EARS can still continue to fulfill requests, just watch the Teahouse for them instead. <span style="white-space: nowrap;">— [[User:Wugapodes|Wug·]][[User talk:Wugapodes|a·po·des]]</span> 06:47, 3 May 2021 (UTC)
*'''Support''' Per NickMoyes's data above. We should not be dividing our efforts because having too many venues confuses newbies. It's best to steer new editors to a single place to ask questions or make requests, and the Teahouse got 30x more traffic than WP:EAR in 2020 so I think we should go with that one. Editors active at EARS can still continue to fulfill requests, just watch the Teahouse for them instead. <span style="white-space: nowrap;">— [[User:Wugapodes|Wug·]][[User talk:Wugapodes|a·po·des]]</span> 06:47, 3 May 2021 (UTC)
*'''Support'''. I don't see the value in having multiple venues with overlapping focus, and I think it creates more issues than it solves:
:* It's confusing for newcomers, who are already confronted with a huge number of [[Wikipedia:Noticeboards|noticeboards]], [[wikipedia:help|help pages]] and discussion forums. As an example, if you were looking to find out if a source is usable in a draft you're writing you could be directed to [[WP:TEA]], [[WP:RSN]], [[WP:HD]], [[WP:AFCHELP]] or [[WP:EAR]], all of which could be suitable places for asking your question.
:* It splits volunteer contributors across multiple pages, which means helpers who are experts in one aspect of editing may miss questions posted on a help forum they don't check often, resulting in lower quality answers.
:* People asking for help on the lower traffic noticeboards will have an unnessasarily longer waiting times for responses. Some of the questions on [[WP:EAR]] took 3 hours or more to get a response, which isn't ideal for a newcomer in the middle of writing their first page. [[Special:Contributions/192.76.8.91|192.76.8.91]] ([[User talk:192.76.8.91|talk]]) 16:45, 3 May 2021 (UTC)
===Proposal1: Replace Main Page Help Desk link with Teahouse link===
===Proposal1: Replace Main Page Help Desk link with Teahouse link===
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}}talk14:34, 10 January 2021 (UTC)[reply]
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}}talk14:34, 10 January 2021 (UTC)[reply]
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)[reply]
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)[reply]
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}}talk19:12, 10 January 2021 (UTC)[reply]
Excellent idea. I suspect if editnotices had existed when these templates started this problem would not have arisen. ϢereSpielChequers18:50, 10 January 2021 (UTC)[reply]
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)[reply]
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·des02:54, 11 January 2021 (UTC)[reply]
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)[reply]
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}}talk11:05, 11 January 2021 (UTC)[reply]
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)[reply]
SupportGreat 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)[reply]
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)[reply]
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)[reply]
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)[reply]
Support – reducing talk page template bloat and helping new editors understand Engvar at the same time sounds like a clear win-win to me. AngryHarpytalk12:47, 11 January 2021 (UTC)[reply]
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)[reply]
Creation is "trivial for a bot". Maintenance and filtering through the noise in the template namespace looking for anything but edit notices? Yeah, not so much. --Izno (talk) 01:39, 12 January 2021 (UTC)[reply]
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)[reply]
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) DarthFlappy18:53, 12 January 2021 (UTC)[reply]
@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)[reply]
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)[reply]
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. Levivichharass/hound04:53, 13 January 2021 (UTC)[reply]
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)[reply]
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. Levivichharass/hound17:27, 13 January 2021 (UTC)[reply]
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}}talk00:06, 14 January 2021 (UTC)[reply]
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)[reply]
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)[reply]
@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}}talk01:58, 15 January 2021 (UTC)[reply]
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. - NovovTC07:57, 15 January 2021 (UTC)[reply]
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)[reply]
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}}talk13:05, 15 January 2021 (UTC)[reply]
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. - NovovTC07:57, 15 January 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I think I have used that edit notice. But the idea is to only insert the notice if it really needs to be noticed, ie there is a chronic problem with numerous edits on the page. So in general it should not be added in my opinion. Graeme Bartlett (talk) 23:59, 18 January 2021 (UTC)[reply]
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)[reply]
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, LindsayHello14:10, 22 January 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Support, ideally with the notice stripped down to its bare essentials. Perhaps just 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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}}talk07:08, 3 March 2021 (UTC)[reply]
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}}talk07:39, 3 March 2021 (UTC)[reply]
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. 🐔ChicdatBawk to me!11:22, 5 March 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
In the cases where it's already in the edit notice, I think we'd just leave it there and only remove it from the talk page. --Paul ❬talk❭ 17:07, 10 January 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Given how infrequently a page's variety of English should be changed this sounds like a benefit to this proposal - ensuring that it only happens when there is a good reason to do so. Thryduulf (talk) 11:12, 11 January 2021 (UTC)[reply]
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)[reply]
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. Levivichharass/hound06:16, 13 January 2021 (UTC)[reply]
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. :)
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)[reply]
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)[reply]
@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. — xaosfluxTalk11:45, 16 January 2021 (UTC)[reply]
@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)[reply]
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)[reply]
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}}talk21:15, 14 February 2021 (UTC)[reply]
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)[reply]
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}}talk00:12, 13 February 2021 (UTC)[reply]
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)[reply]
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.
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)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
RfC on limiting minor edits
Question: Should the minor edit functionality be limited to a group of users (such as autoconfirmed or extended-confirmed users)?
Option 0 (status quo): Limit minor edits to registered users.
Option A: Limit minor edits to autoconfirmed (or confirmed) users.
Option B: Limit minor edits to extended-confirmed users. (No change to bots or admins which currently have this access)
This is a follow-up to this RfC on effectively disabling minor edits. As there was no consensus then, this is to establish clearer consensus regarding an alternative proposal. (This is my first time requesting comment, please let me know if I'm doing anything wrong.) Tol | Talk | Contribs (formerly Twassman) 00:02, 1 April 2021 (UTC)[reply]
Survey (minor edits)
Question What about the Gordian-knot solution, just get rid of the concept of "minor edit" entirely? Was that considered? --Trovatore (talk) 00:23, 1 April 2021 (UTC)[reply]
Well, that one says something like "limit by policy to anti-vandalism reverts", which is not really a simplification and adds another layer of things people can and can't do. What I'm talking about is, the whole concept of "minor edit" goes away entirely; it's not that some people can do it and some people can't; it's not that there are rules about when you can do it; it's that it just doesn't exist, period. Even historical edits would no longer distinguish minor vs non-minor. Like it never existed at all. I would support that. --Trovatore (talk) 00:37, 1 April 2021 (UTC)[reply]
You are right that the RfC was specifically about restricting minor edits rather than removing entirely, but what I meant is many of the arguments in opposition would apply just as well for a proposal to remove them entirely, so I don't see that reaching consensus. — ⊥ɥǝ Ǝɐɹʍıƃ (ʇɐlʞ) 00:45, 1 April 2021 (UTC)[reply]
The !voters may not have taken into consideration the advantage of a genuine simplification, for once, given that none was offered. --Trovatore (talk) 00:47, 1 April 2021 (UTC)[reply]
Support B, then A. As I said in the other RFC, currently it's about as useful as the evil bit. The point of the minor edit checkbox is to say "you can safely ignore this edit"; so long as vandals, spammers, and "what does this button do?" types can use it, "minor" edits still need to be reviewed. For new users, this will be one less thing to worry about, and one less thing to get yelled at for misusing. Suffusion of Yellow (talk) 00:34, 1 April 2021 (UTC)[reply]
Indeed, I would support that too. But in the other RFC there was significant opposition to this idea, so let's at least remove it for the users most likely to be spammers, vandals, or clueless. Suffusion of Yellow (talk) 00:49, 1 April 2021 (UTC)[reply]
Meh, can't get excited about that. If the concept is useless, remove it. If we're not going to remove it, then since I'm pretty much going to ignore it anyway, I don't really care who can use it. --Trovatore (talk) 00:52, 1 April 2021 (UTC)[reply]
Support A, Oppose B per my arguments in the previous RfC. I am not in favor of expanding the scope of EC if it means taking rights away from autoconfirmed users. The threshold for EC is too high for a feature as minor (no pun intended) as this one. — ⊥ɥǝ Ǝɐɹʍıƃ (ʇɐlʞ) 00:53, 1 April 2021 (UTC)[reply]
Option A/B (as requester): minor edits are frequently abused or incorrectly used by new users, and this could limit this feature to users who can be better trusted not to misuse it. Tol | Talk | Contribs (formerly Twassman) 01:09, 1 April 2021 (UTC)[reply]
Support 0, strong oppose B: I'm shocked to find out the VPR discussion, which I'd filed away mentally as "some weird discussion between people with outlier opinions that's probably fizzling out", made its way here, and I at first thought this was an April Fool's RfC that hadn't been tagged properly. I can grudgingly recognize an argument for autoconfirmed (selects away some-but-not-all of the people with actively negative amounts of clue) but overall think that an example of over-bureaucracy at the terror of Spammers And Vandals taking away a minor, useful, and mostly noncontentious function. Limiting it to extended confirmed is beyond parody -- do you know what 500 edits sounds like to someone who isn't Into Wikipedia? We use extended confirmed protection as a last resort for the most massively controversial and abused articles to make sure they're only edited by people who are in too deep to continue it. I do not see the point of restricting something to vested contributors (B) or the patient (A) that can very well be better explained with replacing "This is a [[subtle link|minor edit]]" with "This is a minor edit [[less subtle link|(when to check this box)]]". Vaticidalprophet01:12, 1 April 2021 (UTC)[reply]
I'd see your point if it was a feature that had any direct benefit to the user. But (like autopatrolled) it can only benefit other people. How is the non-extendedconfirmed user harmed by the removal? Suffusion of Yellow (talk) 01:21, 1 April 2021 (UTC)[reply]
Autopatrolled not benefitting the end user is something I've always found more said than true -- having pages indexed by Google (and by extension around the top of it for most subjects) is indeed a benefit for the page's writer, in that it means their work will be viewed. Similarly, I don't believe minor edits are useful only to other people in either the corest sense of "to the editor, directly, in a void" or the sense of "the editor as they actually are, interacting with other people" (e.g. it is quite meaningful well before the point someone hits extended-confirmed if they have 10% minor edits or 90%). Even in the one-man-is-an-island sense, being able to tag your own edits is helpful for personal categorization and tracking. I'd like to flip the position you're presenting here -- to limit minor edits, especially to limit them only to people with edit counts that sound absolutely insane to people who are not themselves prolific Wikipedia editors, would in my opinion require a far more serious abuse than I've seen either in practice or that you're proposing. "This should only be possible for 0.1375% of the people who have joined Wikipedia" is a proposal that shouldn't happen without major cause. Vaticidalprophet01:30, 1 April 2021 (UTC)[reply]
Support B/A Support B, but wouldn't mind A. There often are users(often newer) who use minor edit for things they think are minor changes but aren't Wikipedia minor edits. WikiVirusC(talk)01:48, 1 April 2021 (UTC)[reply]
Support B as first choice, A as second choice. Most uses of minor edits by new users are by newbies exploring Wikipedia for the first time, vandals, spammers and sockpuppets, making the concept useless with respect to non-autoconfirmed users. Since autoconfirmed is so easy to game and it is unlikely a new user will get the point by that point, we should restrict minor edits only to those who understand what they are, and what their purpose is. JavaHurricane04:03, 1 April 2021 (UTC)[reply]
Are "most" uses of minor edits malicious? Does it take a month and the 99.8625th percentile of edit count to learn something that can be learned by clicking the link piped from 'minor edit'? Are minor edits as massively contentious as articles about intense global political disputes, our primary use-case for limiting an action to the 99.8625th percentile of editors? Vaticidalprophet06:47, 1 April 2021 (UTC)[reply]
Having been doing RCP and counter-LTA activities for quite a while now, I daresay most uses of the minor mark are either malicious, or tests, or rollbacks of tests and vandalism. And yes, it took me that long to get fully the concept of minor edits. JavaHurricane08:13, 1 April 2021 (UTC)[reply]
If you work in the part of the project that deals with the worst edits, you'll pattern-match the worst edits to everything. This does not mean that the majority of minor edits are bad, it means the majority of minor edits you personally encounter are bad. I have not seen any argument in favour of making minor edits more restricted than actual rollback (any autoconfirmed user can install Twinkle), or indeed as restricted as it, that doesn't sound like either "then we should make the link to Help:Minor edits more obvious" or "then you shouldn't filter minor edits in your watchlist". (I personally pay attention to every diff for the watchlist articles I care most about, including Amantio running AWB over it, in case a poor edit is hidden behind them.) Vaticidalprophet19:58, 1 April 2021 (UTC)[reply]
Oppose B - Editors should become familiar with the edit summary system much before 500 edits. Anyone who is very concerned with missing something because it is marked minor can simply stop filtering those out of their watchlist. — Godsy (TALKCONT)15:08, 1 April 2021 (UTC)[reply]
@Xaosflux: No, I should have made this more clear. Option B would not remove this capability from admins or bots. I intended to mean removing minor edits from human users who have not been extended-confirmed (bots not being human and admins having been XC at some point). Tol | Talk | Contribs (formerly Twassman) 19:18, 1 April 2021 (UTC)[reply]
Support A or B I have also seen this feature misused by bad actors. The purpose of this feature is to allow minor edits by trusted editors to be less prominent on watchlists, not as a privilege to certain editors. As I see it, adding an activity requirement before it shows up would make this feature more useful to those who review changes. (t · c) buidhe15:21, 1 April 2021 (UTC)[reply]
Support something between B and A I was originally going to just support B but as stated above by Godsy, Wikipedia editors should become familiar with the edit summary before 500 edits.But becoming autoconfirmed (as far as I know, I'm not completely sure) is easy to do. However I completely oppose Option 0 because any user can register an account and then vandalize an article while marking it as minor. We need to take note that not all vandals are IP editors. So I think if we did something between A and B (maybe semi-autoconfirmed or possibly a separate thing entirely just for minor edits) then it would still make it harder for vandals to do what they do best while not making it too hard for good users to make minor edits. A Wild Wolf has appeared! | Gotta catch 'em all! (talk) 15:29, 1 April 2021 (UTC)[reply]
Support B, then A I personally believe every user uses minor edits differently, but only with WP:ECP users, is there going to even be a discernible pattern. Non ECP users by definition will have fewer than 500 edits anyways Shushugah (talk) 15:41, 1 April 2021 (UTC)[reply]
Support 0 - I vaguely recall participating in the previous RfC, but this is a case where what logically makes sense (either A or B) actually doesn't. One of the best RCP "tells" is mis-use of minor edits. It raises efficiency appreciably, and that alone makes me prefer to keep as-is. Nosebagbear (talk) 16:04, 1 April 2021 (UTC)[reply]
Support 0 with A as a very distant second choice. Despite all the discussion here and in the previous discussion, I've never actually been convinced that there is a problem that needs fixing here or that the proposed changes would actually fix things. The issues people have are one of user behaviour and limiting use of the minor edit feature is not going to solve that. Thryduulf (talk) 16:25, 1 April 2021 (UTC)[reply]
Support A, second choice 0, weak oppose B. The designation is almost entirely uninformative for very new users. (Contrary to the "honeypot hypothesis", I think it's essentially uncorrelated with vandalism, not reliably anticorrelated to any degree to actually be useful.) Even for the more experienced, there are different standards of what constitutes a minor edit. But it's also basically harmless. Somewhere between 10 and 500 it starts to acquire a small amount of usefulness, but given the choice I'd rather it kick in sooner rather than later. As for the preference for 0 over B, if nothing else it gives IPs one more incentive to register. MarginalCost (talk) 17:21, 1 April 2021 (UTC)[reply]
The correlation is likely not between "minor edit" and "vandalism" alone. The correlation is between "minor edit & large diff size" and "vandalism". ~ ToBeFree (talk) 17:32, 1 April 2021 (UTC)[reply]
In all the years I have edited here, I do not recollect ever before having actually registered a comment in an RfC, only to say that I don't care. But I don't. If you don't want to take "you can safely ignore this edit" for granted, here's a very effective fix: don't. I can see requiring some additional experience before allowing it, but it won't really matter. --Tryptofish (talk) 19:19, 1 April 2021 (UTC)[reply]
Option 0, if we're limited to the options above. I don't see the point in limiting who can use the minor edit checkbox, if the problem is how it's being used. I might consider supporting a proposal that would add a technical limit on how many characters/bytes could be changed and still have the edit marked minor, such that minor edits are effectively limited to spelling corrections in one or two words, or the addition/removal of 3-5 bits of punctuation, but that option is apparently not currently under consideration and I have no idea if it's technically feasible or not. ~ ONUnicorn(Talk|Contribs)problem solving19:29, 1 April 2021 (UTC)[reply]
Support 0. The fact that almost anything can be abused by a small minority is not a good reason to ban this feature from the majority that use it responsively. Also, doing it would be counterproductive as Nosebagbear points out. – Finnusertop (talk ⋅ contribs) 19:59, 1 April 2021 (UTC)[reply]
Support 0 - I edit in topics that are subject to frequent vandalism and POV editing... and often the vandals try to “hide” their edits by intentionally misusing the “minor edit” tag. Thus, when I see an edit flagged as a “minor edit” (in these topics), my reaction is the opposite of what is intended... I pay extra attention to the edit. I know this is not the purpose of the flag, but it actually HELPS me discover and correct vandal/POV edits... so I WANT the vandals and POV editors to keep misusing it. Blueboar (talk) 00:49, 2 April 2021 (UTC)[reply]
Support 0 Anon editors are human as well. I don't see why they shouldn't get minor edits. If anything, removing them will almost certainlyy increase bad edits as they allow for small changes and removing that will have severe consequences on the editing process. Swordman97talk to me01:22, 2 April 2021 (UTC)[reply]
First, anonymous (IP) editors already cannot use minor edits; this RfC is to discuss whether the bar should be moved up from registered accounts to autoconfirmed or extended-confirmed accounts. This does not remove their ability to make edits which are minor edits as defined in Help:Minor edit, it only removes their technical ability to mark the edits as such. It has absolutely no impact on what edits they can make. It may help other editors who ignore minor edits, as by preventing these new editors (who may not understand what a minor edit is) from making minor edits, all edits by these new editors will show up on watchlists. Tol | Talk | Contribs (formerly Twassman) 16:35, 2 April 2021 (UTC)[reply]
Oppose B - While I support the idea of having to request a permission to make minor edits, extended-confirmed is not the right permission to bundle it with. Neutral between the status quo and auto-confirmed; certainly some minor edits by new users are vandalism or incorrectly tagged but it doesn't seem to be disproportionate. User:力 (power~enwiki, π, ν) 01:29, 2 April 2021 (UTC)[reply]
Strong Support 0 Misusing makes it easier to detect vandals per Blueboar. It also makes it easier to detect sockpuppets, since their previous account(s) likely learned about minor edits. 🐔ChicdatBawk to me!10:32, 2 April 2021 (UTC)[reply]
@ProcrastinatingReader:, would you care to elaborate? If you mean what I think you mean, nobody was talking about using minor edits to "trap" good-faith editors. For that matter, minor edits alone cannot trap anyone - they were saying as how minor edits assist them in spotting socks and vandals; but they aren't "busted" for using the minor edit feature, but for socking and vandalising. A good faith editor who is not socking or vandalling can't be wrongly accused of such just for using minor edits Firejuggler86 (talk) 22:02, 2 April 2021 (UTC)[reply]
Option 0 with a strong oppose option B (or removal of minor edits altogether). Editors supporting restrictions don't seem to be balancing the odds right—at least, not if we take their comments at face value. The question at hand is: are sufficiently many minor edits made by non-autoconfirmed/non-EC (a) unconstructive and (b) not caught by standard anti-vandalism procedures (ClueBot, Huggle, watchlisting, RCP) that it is a net negative to the system? From my own experience, I don't see how this could possibly be the case. The vast majority of unconstructive edits are not marked as minor. The proportion of minor edits which are unconstructive is lower than the proportion of major edits. And I think it's clear that anything minor by a new user that says (+2,167) is still likely to be caught by our existing processes (I think users above are saying "m(+2,167)" makes them more likely to read the edit, and it does for me too). The only thing minor edits really do is help someone with a large watchlist find the most important changes first, and I don't think we're doing these people a favour. I am also concerned by the attitude people are showing behind the purpose of marking an edit as minor. I mark an edit as minor if and only if I think "I would be very surprised if an editor wanted to know that this edit had happened (because they might want to discuss it or have some improvement to make on what I've done)". If an editor is repeatedly marking contentious edits as minor then approach them in the first (and maybe second) instance and if they continue and do not reply constructively then report them, because such malicious actions are sanctionable. Literally my first registered edit was minor (marked as such and genuinely such). There's a button saying "This is a minor edit", with an uncontroversially clear meaning. It's not hard for a beginner to use it correctly. — Bilorv (talk) 13:18, 2 April 2021 (UTC)[reply]
Minor edits are effectively worse than evil bits right now because they have an unclear meaning that's basically "hey you don't have to look at this edit"; this is a part of why I don't believe new editors don't use it (sort of vague meaning). At the same time though, restricting it to extended confirmed or autoconfirmed won't change that. Minor spelling and grammar corrections are often disputed as well as layout issues or whatever else; that's why the MOS pages/infoboxes are under discretionary sanctions and why there was endless discussions about the second Star Trek remake's capitalization. Minor edits should be replaced with a more robust tagging system to allow editors to self-tag edits as falling under different categories kind of like the common edit summaries tool. Right now minor edits are supposed to simply just mean "uncontroversial" but the subjects they're applied to can often be very controversial or need review. That or it's just used as a vandalism cover that doesn't work.
A system where editors could tag edits as being grammar/spelling correction, style/layout issues, rv vandalism, wikilinking things, or a few other topics would serve the dual purpose of being a more useful tag for filtering/sorting purposes (maybe you want to see corrections of factual errors but not grammar/spelling corrections on your watchlist) and assist new editors who don't really know how to use edit summaries or the existing system. Said system has a slim to none chance of actually being implemented though (too busy making margins bigger) so I have to go with Option 0 for now. Chess (talk) (please use {{reply to|Chess}} on reply)Template:Z18101:56, 3 April 2021 (UTC)[reply]
Option 0 per WP:BROKE. Strongly oppose Option B. There's virtually no evidence of disruption to demonstrate that limiting minor edits is actually necessary. This is a pointless proposal. OhKayeSierra (talk) 02:02, 3 April 2021 (UTC)[reply]
Option A. Too often I see noobs misusing this (intentionally or not) to semi-hide edits which are quite substantive (and often unconstructive). And too many "brand new editors" are socks of banned users, or other unhelpful parties, so they should not be able to partially disguise what they are doing from the scrutiny of many longer-term editors. It does not hurt us in any way for a brand new legit editor, already unfamiliar with the existence of a "[ ] This is a minor edit" feature, which was not available to them as an anon, will still not have that option until after they've been around long enough that we don't think they're a sock or troll. There's just no down-side to this. However, I think option B is excessive. We don't need to wait that long to permit fairly basic functionality to be available. — SMcCandlish☏¢ 😼 05:39, 3 April 2021 (UTC)[reply]
Option 0 or A From a new editor, it's a warning about half the time, based on the figures below. I and many of us actually use that waring. The change wouldn't remove disruption, but makes it harder to detect. I think it would be even more helpful to give unregistered editors the same ability; DGG ( talk ) 09:28, 3 April 2021 (UTC)[reply]
Support 0, maybe A We're going to inevitably require registration for edits eventually, but I see no point of this current proposal. I can maybe see minor edits for confirmed, though, as that's not too onerous. – John M Wolfson (talk • contribs) 14:15, 3 April 2021 (UTC)[reply]
Support 0 Status quo: because, right now, the minor edit tick (when combined with a new account status), often acts like an indicator of vandalism and bears further scrutiny, especially when used on edits with the addition/removal of a whole paragraph, several sentences, or even several characters. GenQuest"scribble"16:05, 3 April 2021 (UTC)[reply]
O first choice, but if we're doing this A. Limiting it to autoconirmed users as we do with other abilities such as creating or moving pages isn't entirely unreasonable, limiting it to ECP users is a rather large overreaction. Slightly favor status quo per the comments about vandal detection. Beeblebrox (talk) 19:12, 3 April 2021 (UTC)[reply]
Remove minor edits Honestly, what an editor considers a "minor" edit is based on perspective. A simple spelling change can meet opposition or what is deemed as a spelling correction could lead to a dispute. I've seen it happen before, disputes over trivial things such as spelling change marked as a minor edit. Just get rid of the whole "minor edit" system, even if it were used for a simple grammar correction. Filling out the edit summary will do just fine. If not that, at least have the "minor edit" system stop marking rollbacks and page moves as minor. Jerm (talk) 22:01, 3 April 2021 (UTC)[reply]
The problem there, as noted in the proposal, is that an RFC to basically do that failed less than two weeks ago with a strong consensus against it. Beeblebrox (talk) 22:05, 4 April 2021 (UTC)[reply]
B This make things simpler for new editors, the concept of minor edits can be introduced to them after they have made 500 edits. ϢereSpielChequers09:09, 4 April 2021 (UTC)[reply]
Option 0 This seems like pointless bureaucracy. Who cares about a quite literal minor flag on an edit? Leave it be and focus on the stuff that realistically matters. Remagoxer (talk) 12:31, 4 April 2021 (UTC)[reply]
Option 0, plus new filters on the History panel of each page to filter out edits by extended-confirmed and/or autoconfirmed users. Those who want to only review edits by vandals, spammers, and "what does this button do?" types can do so. The current proposal of limiting minor edits does not help people who want to more effectively review problematic edits. feminist (talk)05:24, 5 April 2021 (UTC)[reply]
+1 for better filtering, searching, and colour-coding in History. Is there some underlying technical reason this can be done in Recent Changes but not page history? Pelagic ( messages ) – (17:18 Sun 25, AEDT) 06:18, 25 April 2021 (UTC)[reply]
Option 0 per hardly-a-problem looking for a major solution; also per all the other Option 0ers, who each present cogent arguments. ——Serial13:14, 5 April 2021 (UTC)[reply]
Status Quo, Strongly oppose B. While it is true that there are lots of bad faith minor edits, lots of newer user also started up with minor edits. Not all people would be bold and change major things, some people started by minor edits such as fixing punctuation or capitalization, or adding minor facts, or doing minor rewording of sentences. If these new users are presented with "No you can't edit minor stuff because we don't trust you enough" it would be discouraging. Limiting minor edits to extended-autoconfirmed will be useless as vandals wouldn't care anyway. As someone who loves to revert vandalism (and made some bad calls too time to time) what stands out are the content of the vandalism, not whether it is minor edit or major edit. SunDawn (talk) 07:42, 6 April 2021 (UTC)[reply]
How would making the "minor edit" checkbox vanish make users less likely to make edits such as fixing punctuation or capitalization? No one ever gets yelled at for failing to check that box when fixing a typo. Plus the newest users won't even know that it ever existed. The interface will just be a bit simpler. Suffusion of Yellow (talk) 16:56, 6 April 2021 (UTC)[reply]
B 1st choice, A 2nd choice - This makes things simpler for new users (who will not have to worry about the minor flag), and simpler for experienced users (who will know the minor flag is only being used by experienced users). Levivichharass/hound03:20, 7 April 2021 (UTC)[reply]
Option 0 Pointless. Why limit it to more experienced users if new users will probably not use it anyway? What is there to gain? There's no policy against making a minor edit not minor. ThePlatypusofDoom(talk)13:49, 7 April 2021 (UTC)[reply]
To me the answer to "why" is: so that I can filter out minor edits from my watchlist, and be confident that anyone using the minor flag is an experienced editor, and I'm not missing vandalism that is marked as minor by new vandalism-only accounts. Levivichharass/hound17:07, 7 April 2021 (UTC)[reply]
Option 0, strong oppose B Minor edits, in my opinion, are an essential part of organizing edits. Also, there's no policy against making a minor edit not minor. EpicPupper18:03, 7 April 2021 (UTC)[reply]
Option AB+ If this proposal actually passed, then I would filter out minor edits from my watchlist. The reason I don't already is because it feels like a lot of the time those edits are really some form of disruption or vandalism. –MJL‐Talk‐☖04:50, 8 April 2021 (UTC)[reply]
Support B, then A per numerous others. There needs to be a way to mark things that are truly inconsequential, such as fixing broken syntax in a call to a template or removing an extra period, etc. But there is no reason to allow it to be abused. Desertborn (talk) 17:42, 8 April 2021 (UTC)[reply]
Support B first, then A. Should we be allowing brand new users a way to make an edit not appear on watchlists with one click? No... the "solution looking for a problem" group needs to get over themselves; obviously there is an apparent problem to some people, or B and A would have received no support at all. Aza24 (talk) 23:10, 11 April 2021 (UTC)[reply]
Strong oppose limiting the "minor edit" function to a select group of Wikipedians. I did not even know that the status quo is to limit marking edits as minor to registered users, and would oppose even this, because I think any one who edits Wikipedia should have the right to mark an edit as minor. Marking edits as minor is useful, because when one looks at the history of an article, it makes sense to see what edits have only been corrections of spelling mistakes in a single word or removal of superfluous punctuation marks. Rollo August (talk) 16:55, 18 April 2021 (UTC)[reply]
Option 0 per AdmiralEek and Blueboar. I love it when vandals click "minor edit" on a 2,000kb entry. This feature helps me identify vandals, rather than hiding them. I see no worries with the status quo. Huggums537 (talk) 13:50, 22 April 2021 (UTC)[reply]
Option 0 I generally find the minor edits tag an entirely useless feature (though, in good faith, I try to use it appropriately). This entire debate is a tempest-in-a-teacup, and I see no reason to deviate from the status quo. --Jayron3213:59, 22 April 2021 (UTC)[reply]
Support B, then A. However noble the intention of minor edits, we should accept that in practice, there's issues, especially with new users. I feel some of the "status quo" votes are akin to https://xkcd.com/1172/ ... I'm sure it's true that some non-smart vandals use "minor" as a clever technique to try to disguise vandalism that may make the vandalism even more obvious to some watchers, but that's very off the beaten path. The intended use is still not working great. I think that being able to mark edits minor at all is still a useful feature, but it's privilege, not a right - there's no real disadvantage to editors who can't use minor edits. So there's essentially no harm in further restrictions, and minor gain in clarity. "Minor" should really mean "said to be minor by a mildly trusted source", there's no use in "said to be minor from an untrusted source." SnowFire (talk) 04:28, 24 April 2021 (UTC)[reply]
Support A, then 0. User:Vaticidalprophet's arguments (and others in the same vein) have convinced me that B is too high a bar. Keeping a feature that some people misunderstand and others intentionally but naïvely abuse just as a honeypot for the latter has moral issues. On the other hand, AC is a very low bar, is there enough volume of non-AC "minor" edits to make it worth the change? Pelagic ( messages ) – (19:07 Sun 25, AEDT) 08:07, 25 April 2021 (UTC) (oops, forgot to sign)[reply]
Quick and dirty answer to my own question: recent changes, human not bot, page edits, main namespace, newcomers, latest 250 (which is approximately an hour and a half). Counted 65 bold m's, about a quarter of total newcomer edits. (I’m not in a position to work through all of them and score true-minor versus false-minor.) Pelagic ( messages ) – (19:19 Sun 25, AEDT) 08:19, 25 April 2021 (UTC)[reply]
Support A, then 0. The thing about minor edits is that people can always ignore the tag if they want to, especially if it comes from an IP, so there's no need to make this so restrictive. Kokopelli7309 (talk) 14:27, 25 April 2021 (UTC)[reply]
Support 0. The minor edit function seems like a simple and non-contentious part of Wikipedia, so restricting it would just cause unneeded restrictions and potentially create larger issues than any problem it's solving. User:Heyoostorm_talk!14:59, 25 April 2021 (UTC)[reply]
Support B or A as being helpful for admin but it isn't a huge deal. Most real new users aren't going to know what a "minor" edit is until they are autoconfirmed at the earliest, so I don't see how they could miss it, nor how it would affect them negatively. Dennis Brown - 2¢17:57, 25 April 2021 (UTC)[reply]
Strong support B, support A, oppose 0: worrying about confusing new users is a red herring; by their nature, they won't know what has changed. Or care, for that matter. ——Serial12:36, 29 April 2021 (UTC)[reply]
Strong support B, support A, oppose 0: The occasional benefits of the minor edit checkbox are not worth the costs, which are that (1) they are a non-intuitive contribution to the cliff-like learning curve for new editors, and (2) they impose a small but persistent cognitive burden on all registered editors. I'm surprised that others aren't mentioning (2). I've had to think about whether to check the box over 17,000 times. It's not always a tough decision, but that still adds up to a tonne of time and mental effort that could have been directed elsewhere. The proposed changes at least fix (1). Adrian J. Hunter(talk•contribs)10:36, 30 April 2021 (UTC)[reply]
At last! Someone who brings up this tremendously annoying and unregulated borderline anarchist feature! To answer the question: YES YES YES, VERY MUCH SO! Minor edits in its current relaxed implementation is absolutely awful. I come across very very few cases were it's used properly. In the vast majority of cases it's either used improperly, mostly by decently experienced users and not unusually to hide potentially controversial edits, or as outright vandalism. I mostly lurk in sports articles, and most editors in that subject mark updates (change of information) as minor even though that clearly is NOT what minor is meant for. Look in a bunch of sports season/event articles and you will find plenty of that. It's tremendously annoying and a huge waste of time to mentally scan and filter them in good or bad edits.
I support B with a twist, calling it Option B2, where it additionally includes Pending changes reviewers, Rollbackers and/or Patrollers (even though I've been here for 4 years and contributed more than most but still not qualifies for any of those groups) as well as bots. Autoconfirmed is too easy to get around. It could also be limited to byte size, preferably it would be clever enough to figure out when someone reverts data-rich vandalism.
I saw User:The Earwig suggesting in the earlier RfC that the minor edit feature could be blocked from a user if it's misused. I think that's a splendid idea.
User:Vaticidalprophet made an important note that the minor edit feature could be used by the poster to themselves distinguish them in their own statistics. So a compromise would be that minor edits can be marked by (auto)confirmed users but doesn't show to anyone else. Not until that user is extended confirmed will marks show, and then only marks made after the user has become extended confirmed.
User:Chess suggested that it could be replaced with another system instead, where one categorises the edit based on type, like grammar/spelling correction, style/layout issues, revert vandalism, wikilinking things, and so on. That is a terrific idea!
If nothing of this, then I lean towards a complete removal or at least limiting to administrators and bots rather than the microstep to limit it to (auto)confirmed or – heaven forbid – status quo. Even now as I checked, I discovered that two persons I spotted misusing it and pointed out for, were in fact extended confirmed users! So this feature is absolute garbage right now, worse than not having it at all. But if it stays and gets regulated, I also think minor edits should become an official guideline.
It's disheartening to see so many in favour of status quo specifically for the abuse. It's completely backwards thinking and a testimony to how broken the feature is. Even more so from the ignorant and selfish people saying there's no problem at all, implying for anyone. --Mango från yttre rymden (talk) 23:57, 2 May 2021 (UTC)[reply]
Data on usage of minor edits
Quickly sorting through the past 100 minor edits to the mainspace by human editors of each of the following categories (specific revisions available here), I have some data. Note IP (unregistered) users cannot use minor edits. I am also erring on the side of assuming an edit to actually be minor.
Registered but not autoconfirmed users: 42% actually minor (many were also vandalism)
Autoconfirmed but not extended-confirmed users: 50% actually minor
Extended-confirmed users: 82% actually minor
I had to remove ClueBot NG edits because apparently even the "Human (not bot)" checkbox doesn't exclude its edits.
Tol | Talk | Contribs (formerly Twassman) 01:22, 2 April 2021 (UTC)[reply]
I think this is only half the story—where's the control sample? The information I think we need is how many minor edits in each of the categories are vandalism/bad faith/unconstructive and how many major edits in each of the categories are the same. For instance, based on what I see in my watchlist (obviously selectively biased) I would expect more than 58% of registered-and-non-autoconfirmed edits to need reverting wholesale, so that 58% of minor edits that need attention is not necessarily a flaw in the system. — Bilorv (talk) 13:18, 2 April 2021 (UTC)[reply]
Looking in each category on Recent Changes (new data), and highlighting edits tagged as reverted, 20% of minor edits by registered users were reverted, compared with 1% for autoconfirmed, and none for extended-confirmed. Tol | Talk | Contribs (formerly Twassman) 16:32, 2 April 2021 (UTC)[reply]
Part of the issue we have with minor edits is that our definition of minor is not intuitive, and this means that we have to assume that people misusing the box are doing so out of ignorance, which makes it very difficult to do enforcement. I propose that, should Option A or Option B be adopted, the first time an editor checks the minor edit box, a notice pop up with a brief definition of what we mean by "minor" (perhaps similar to the wording at {{uw-minor}}) that the editor would have to okay. This would ensure that everyone making a minor edit can be expected to understand what it means. {{u|Sdkb}}talk16:00, 5 April 2021 (UTC)[reply]
Sensible. Also works well with the options that don't make minor edit a possibility until you have been here a while. There is much to learn when you start to edit and a lot of sense in postponing some of that to make things simpler for new editors on their very first edits. ϢereSpielChequers07:18, 8 April 2021 (UTC)[reply]
Support. To be quite honest, it took me quite a while for me to figure out what constituted a minor edit back when I started, and I believe this would be useful. Sdrqaz (talk) 20:56, 9 April 2021 (UTC)[reply]
Support. I'm a new editor. I've already misused "minor edit" because I thought adding an extra external link wasn't a major change to a page. A lot of new editors are going to make this mistake; it seems almost vain and self-glorifying to suggest that such a small change constitutes a major improvement in a page. There are a lot of rules and policies in Wikipedia; mistakes will be made in good faith not only by newbies but also by longer-term, occasional editors. Little pop-ups triggered at strategic moments would help to educate us. Elemimele (talk) 10:48, 29 April 2021 (UTC)[reply]
Support — I think this is a better solution than removing the functionality from new users altogether. This would allow good-faith editors to use the button correctly from the start (instead of assuming they'll find out what it is over time), while vandals will probably disregard the message (so people's RC patrol worries should be alleviated). Tol | Talk | Contribs17:56, 1 May 2021 (UTC)[reply]
I strongly support this. IT took me a while to understand what i really meant. It's a lot to take in in the beginning if one wants to go a little deeper than just pure text alteration. All the things to read and check before posting something... And not being a native English speaker doesn't help either. When I think of it I have come across a lot of level 1-2 English speakers that made loads of erroneous minor edit marks in good faith. --Mango från yttre rymden (talk) 23:57, 2 May 2021 (UTC)[reply]
An extended comment/rebuttal to option 0
I, the proposer of this RFC, have seen rather many confusing option 0 responses; I will counter those here.
Mike Peel, Thryduulf, TonyBallioni, OhKayeSierra, John M Wolfson, ThePlatypusofDoom, and Stifle say there is no obvious problem to be solved. The problem is that many edits marked as minor by new users are not actually minor. Therefore, the option to hide minor edits on watchlists is ineffective, as it may hide edits which are not actually minor. (I probably should have included this in the RFC itself.)
Nosebagbear, CaptainEek, Blueboar, Chicdat, and GenQuest argue that a questionable edit marked as minor is an indicator to recent changes patrollers that the edit may be vandalism (a honeypot). That may be, but the whole point is that these edits are not actually minor. Recent changes patrollers will still check the edit, and this provides tangible benefits to people who use the watchlist and want to filter out minor edits. ProcrastinatingReader also noted this.
Finnusertop and Bilorv believe that most new users use the feature correctly, so it would be unhelpful to remove it from all new users. A quick look at minor edits from new users shows otherwise, as I saw (see my #Data on usage of minor edits). This only removes the feature from new users, who are unlikely to use it correctly.
Andrew Davidson says it would be confusing if the interface changes. I believe, if anything, it would be less confusing, as (for new users) there would no longer be a checkbox with a potentially unclear meaning.
Swordman97 and SunDawn seem to think that this would ban new users from making edits which are minor. (Note the wording.) This does not propose that, rather, it proposes that new users cannot mark edits as minor. They can still make edits which fulfill the minor edit criteria, but they cannot tick the box which marks it as minor.
EpicPupper says two things. First, he or she says that minor edits are an essential part of organizing edits. Sure, but they work poorly because they are frequently misused by new users. He or she also says that there's no policy against making a minor edit not minor. I assume this means making a minor edit, but not ticking the box. As far as I know, people do this all the time, and there is not much of an argument for making everyone tick the box when the edit is minor — all that will happen if one leaves it unticked is that it may show up on more watchlists.
King of Hearts says that recent change patrollers always look at every edit, minor or not. That's not the point, the point is that people who use the watchlist may want to only look at edits which are not minor. This doesn't hurt recent changes patrollers, but it significantly helps those who wish to filter out minor edits from watchlists.
@TonyBallioni: As I said, the watchlist function allows users to hide minor edits. With these edits, which are not minor but are marked as such, someone who hides minor edits on his or her watchlist will not see these edits even though he or she wants to. As most of these edits are by new users, I believe restricting the feature to more experienced users (who are more likely to use it correctly) is a good idea. Tol | Talk | Contribs (formerly Twassman) 22:33, 11 April 2021 (UTC)[reply]
And I disagree that what you are describing is actually problematic. Maybe it's because I've never hidden minor edits on my watchlist, but if someone makes the choice to hide them, that's on them. There's no reason to restrict it because of that. TonyBallioni (talk) 22:36, 11 April 2021 (UTC)[reply]
I agree completely with Tony. I don't know why people choose to hide minor edits on their watchlist (the only edits I hide are my own), but that's not the primary function of the flag. As has been said multiple times by multiple people, the solution to what you are seeing as a problem is to teach people how to correctly use the minor edit flag not to remove their ability to use it. Thryduulf (talk) 22:45, 11 April 2021 (UTC)[reply]
@Thryduulf: The reason to hide minor edits would be because one wants to see the substantive edits to the article but skip the minor ones. For teaching people: we do have {{Uw-minor}} for this purpose, and while I've tried to use it as much as possible, there isn't a "new users' minor edits patrol" akin to RCP to teach people about minor edits. I do agree that education on minor edits is definitely preferable to removing it from new users, but I'm not sure how to do that effectively. Now I have an idea for a bot, hmm... Tol | Talk | Contribs (formerly Twassman) 23:00, 11 April 2021 (UTC)[reply]
While it (to put it coarsely) sucks that many users abuse the "minor edit" functionality, and I wouldn't be opposed to removing it entirely (though nor would I entirely support it), I think it's hardly a reason to impose such an onerous restriction. – John M Wolfson (talk • contribs) 22:30, 11 April 2021 (UTC)[reply]
I didn't say that most new users use the feature correctly (name any step to editing and most new users do it wrong) and my argument doesn't rest on that fact. Your data remains lacking a control sample (what you replied to my comment with is not a control sample or the data that I said was missing). — Bilorv (talk) 22:37, 11 April 2021 (UTC)[reply]
@Bilorv: Thanks for following up. The control sample would be made of a mixture of all three categories, and I didn't see much of a point in repeating the tedium of sorting edits a fourth time. From the data I already sampled:
Non-AC: 100 edits from 22:03 to 23:59 (1 hr 56 min), so ~0.864 minor edits per minute, weight 9%
AC non-XC: 100 edits from 23:26 to 00:27 (1 hr 1 min), so ~1.64 minor edits per minute, weight 17%
XC: 100 edits from 00:45 to 00:59 (14 min), so ~7.14 minor edits per minute, weight 74%
From this, it is evident that extended-confirmed users make many more minor edits than other groups (around three quarters of minor edits). Weighting the samples with minor edits per minute, the reconstituted "control"-ish sample gets ~73% of total edits are actually minor. Tol | Talk | Contribs (formerly Twassman) 22:54, 11 April 2021 (UTC)[reply]
Read what I wrote again. The control sample for the factor that is relevant to the argument I make is the proportion of non-minor edits which are reverted per group (which can be compared to the 20%/1%/0% data you give). This still assumes that "reverted" is synonymous to "unconstructive", but I presume you aren't willing to read through 600 edits and assess whether they're constructive or not manually. — Bilorv (talk) 23:02, 11 April 2021 (UTC)[reply]
Ahh, thanks for the clarification. Based on new RC data, 11% non-AC, 3% AC non-XC, 0% XC (percent of non-minor edits reverted). This indicates that for non-AC, the minor edit may be a flag or honeypot, but for autoconfirmed users minor edits are more likely to be constructive. Tol | Talk | Contribs (formerly Twassman) 23:09, 11 April 2021 (UTC)[reply]
Your rebuttal to both my and TB's group don't really seem to be convincing to me. Recent Changes Patrollers don't check every edit (if they did, we'd never find vandalism more than 10 minutes old!), prioritisation is key. Nosebagbear (talk) 23:19, 11 April 2021 (UTC)[reply]
@Nosebagbear: Thanks for the reply. I do not think the removal of minor edits from new users will have much impact on recent changes patrol. I certainly take into account a minor edit flag in RCP, but only when it's combined with something else (such as a large byte change size or a questionable or missing edit summary). I believe that the amount of vandalism that would not be reviewed without a minor flag is inconsequential. Tol | Talk | Contribs (formerly Twassman) 23:27, 11 April 2021 (UTC)[reply]
The thing is, a lot of users just aren't getting the point. If we pop up a notice saying, "Are you sure you want to mark this edit as minor? A minor edit is..." then the maliciously intending editors will just skip the notice and mark their edit as minor. If we limit it to autoconfirmed or extended confirmed, then the maliciously intending editors will just make the necessary amount of edits and time, and then go on a disruptive "minor" spree. If we limit the character change of minor edits, then the maliciously intending editors will just change all the 4 letter words on the page to "****" and/or change the 5 letter words on the page to "penis". If, on the other hand, we block the maliciously intending editors before they can go on a disruptive "minor" spree, and keep the status quo, then the maliciously intending editors will never get to edit. Period. 🐔ChicdatBawk to me!10:12, 12 April 2021 (UTC)[reply]
Comment on mobile editing
Note that the mobile web source editor does not have a minor-edit checkbox/toggle. Mobile VE and iOS app editor do.
On mobile, I have sometimes resorted to hand-typing "[minor]" in the edit summary, though you can't filter that from your watchlist.
It suggests that, at the time mobile / Minerva was designed, minor-edit (along with several other features) was deemed unnecessary or too confusing for "typical" mobile users, or too cluttered for smaller screens. But the devs' thinking on that seems to have changed.
I do not believe that any restriction based on numbers of edits is worthwhile. For what it's worth, my approach is that I don't omit minor edits from my watchlist, but usually don't bother to check minor edits by editors who I trust to mark edits appropriately. These are not necessarily the same as editors who I usually agree with, and certainly do not correlate with numbers of edits made. I would expect most people to take a similar approach. For myself I don't believe that I ever mark non-minor edits as minor, but often forget to mark minor edits as such. Whatever system we have apart from removing minor edit functionality completely will always be vulnerable either to editors who don't know what should be tagged or to malicious editors who want to fly under tha radar, and I'm sure there are quite a few extended confirmed editors who fall into those categories, as anything based on numbers of edits is very easy to game. Phil Bridger (talk) 16:26, 25 April 2021 (UTC)[reply]
What I would support is a policy that states that minor edits have to be used sensibly. (and repeated offenses made blockable) That's vague, but on Commons I once ran into an admin who had "Mark all edits as minor" enabled in their preferences. (this option doesn't appear to exist on enwiki though) That's obviously disruptive. If use cases can be presented, maybe a proposal could be made to make minor edits a user right that can be revoked. — Alexis Jazz (talk or ping me) 16:50, 25 April 2021 (UTC)[reply]
Redesigning the featured, good, and article assessment icons
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
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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? Vaticidalprophet22:27, 2 April 2021 (UTC)[reply]
@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}}talk23:04, 2 April 2021 (UTC)[reply]
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)[reply]
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)[reply]
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. GoPhightins!22:34, 2 April 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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×g23:59, 2 April 2021 (UTC)[reply]
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)[reply]
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)[reply]
Comment Here's an icon for "Rearranging deck chairs on the Titanic": . EEng03:26, 3 April 2021 (UTC) P.S. Someone's calendar is off. This came a day late for April Fools.[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. — xaosfluxTalk10:23, 3 April 2021 (UTC)[reply]
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)[reply]
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)[reply]
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! ——Serial13:30, 3 April 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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. ϢereSpielChequers12:03, 15 April 2021 (UTC)[reply]
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 • contribs01:28, 22 April 2021 (UTC)[reply]
Alternative proposalI'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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. Vaticidalprophet06:17, 3 April 2021 (UTC)[reply]
(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.) Vaticidalprophet06:25, 3 April 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Licensing
Ideally, any new icons would be licensed as CC0 or PD so that the icons be used unlinked, without the need for the link for attribution. -- WOSlinker (talk) 09:01, 3 April 2021 (UTC)[reply]
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)[reply]
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·des23:29, 8 April 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
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.
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.
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·des22:25, 10 April 2021 (UTC)[reply]
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)[reply]
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.
I don't know exactly what the difference between Teahouse and Help desk is (in this MP discussion other editors raised this point), possibly the former is considered useful for newbies and the latter for experienced editors? Though skimming the Teahouse and HD I don't really get the impression that these are really distinct in terms of questions asked. More importantly, my feeling is that Wikipedia:Editor assistance should probably be redirected somewhere, as that venue is completely inactive and mostly goes back to pre-2011, and WP:EAR should probably be redirected to either Teahouse or the help desk as it doesn't seem to have any distinguishing features from either. ProcrastinatingReader (talk) 16:10, 20 April 2021 (UTC)[reply]
The latter two are mostly or entirely historical AFAIK. The Teahouse is for the newest of the new. The help desk is generally for more complicated questions, but not unwelcoming for people who end up there as opposed to THQ. GMGtalk16:13, 20 April 2021 (UTC)[reply]
Broadly speaking, the Teahouse is designed for new users, unfamiliar with Wikipedia, its culture, and its jargon, while the Help Desk is designed for people who are more familiar with Wikipedia in general. Which is not to say that it works out so 100% of the time, but in general that is how it is supposed to work. As a result, a person answering a question at the help desk would feel free using shortcuts, referring people to technical documents, and using wikijargon to answer questions there; however the Teahouse is supposed to presume that the OP would know none of that, and strives to treat users as though they need to have their hands held through the process, and responders should adopt a tone in their response that they are dealing with Wikipedia newbies who wouldn't know how to read a Wikipedia namespace document, what a diff is, or what any of the terms d'art that we use in daily conversation at Wikipedia mean at all. We need both of those two help desks to keep that distinction available. EAR has long been moribund, and I'm actually shocked to see it hasn't since been marked historical. --Jayron3216:16, 20 April 2021 (UTC)[reply]
The editor assistance page isn't a venue in itself but a place to find a specific willing helper. I agree though that the help desks are as good a place to find a helpful editor and make a personal connection. isaacl (talk) 16:54, 20 April 2021 (UTC)[reply]
I think our helpers are more than capable of determining what level of help to provide to users. I think combining the help desk and the Teahouse could be a useful turn of events. Experienced users shouldn't mind, and new users will be less confused. We have so many possible pages for new users, consolidation is key to accessibility. We really need to be thinking hard on how to make it easier to onboard new users. On a side note, calling it the Teahouse feels confusing to me. I wish it was just called the "help desk", which is self explanatory, but it should retain the cultural norms of the Teahouse. AdmiralEek (talk) 23:29, 20 April 2021 (UTC)[reply]
I support keeping the Teahouse and the Help desk separate as I have the Help desk watchlisted and occasionally contribute, but I would find it onerous to follow Teahouse guidance and explain every Wikipedia process in my own words rather than linking to the process and answering any follow up questions. The Help desk has a prominent link to the Teahouse and the Teahouse page should probably have a similar link the Help desk. Both links should probably be followed by a request to post queries in one venue rather than both. TSventon (talk) 12:19, 21 April 2021 (UTC)[reply]
Per TSventon, the Teahouse and Help desk should definitely be kept separate, and are intended to meet the needs of different types of editors, even if there is often some overlap. At WP:TH we strive to communicate in plain English, and in a friendly tone, assuming little or no prior knowledge by the questioner. As has already been said, WP:HD is shorter, more succinct, and often more technical in the tone, both in terms of questions asked, but especially in the answers given. Welcoming new editors and answering their questions in a simple, friendly manner at the Teahouse does make engagement with newcomers much lengthier, but, as has been pointed out by Vahurzpu above, research by Jmorgan (WMF) and colleague showed that the Teahouse makes a significant contribution to new editor retention - and that's what we all want, isn't it? It also continues to provide a testbed for research on editor retention (see this post by Maximilianklein at WT:TH in January 2020).I note that ProcrastinatingReader's question linked to a partly agreed discussion that they closed on agreement to add a link to the Teahouse on the Main Page, and it's there that the distinction on target audiences really ought to be made, though the precise wording would need further attention. I would certainly be in favour of that link being added, and the different active venues made clear. Of course, if a question at WP:THis too technical for the poor Teahouse Hosts to respond too, we do sometimes refer people on, though that would most often be to WP:VPT - or WP:REFDESK for the off-topic ones. (I do, however, wish WP:TH had a better archive naming system, more akin to that at WP:HD as it would make it much easier for a newcomer to find their old, archived post when they're in a dated format.) With regards to any suggestion to merge WP:TH/WP:HD, this comment from Maineartists sums it up: "if it ain't broke, why fix it?". But, as for WP:Editor Assistance - yes, this probably does need marking as historical, and I note that Kudpung suggested precisely that back in 2018. But as I've never been there (who has?), I can't comment further from any personal experience on where would be the best redirect. I'm guessing WP:TH might make the most sense. Nick Moyes (talk) 22:39, 21 April 2021 (UTC)[reply]
I agree with Procrastinating Reader that the help venues ought to be consolidated, and I'm fine with marking the editor assistance forum as historical. One of the things that newcomers most often say about Wikipedia is that the number of back-end pages is overwhelming, so it is not good that editors are encountering potential confusion over where to ask their question in the first place.Regarding the point made about the intended difference between the TH and the HD, that's all fine and dandy, but the key word is intended. There are currently lots of complete newcomers ending up at the HD, and relying on them to read the hatnote and switch to the Teahouse if they want a friendly response is not working. We need to do a better job of pointing to the TH rather than the HD in all newcomer-facing areas, and making the latter a much quieter venue that gets only non-obvious questions from established editors. {{u|Sdkb}}talk01:41, 23 April 2021 (UTC)[reply]
I was the main user answering at WP:EAR for a few years. It was one of the principal help venues until the The Tea House opened. My original comment about closing EAR down was in fact in 2013. I'm surprised no one has taken the initiative to deprecate it and close down all the links to it. Kudpung กุดผึ้ง (talk) 05:12, 23 April 2021 (UTC)[reply]
In a volunteer environment, I think groups interested in an initiative should be free to decide how to organize it, as long as it doesn't impose an undue burden on others. In this context, I think the following questions should be examined regarding any potential burden:
Are questions being asked and answered effectively?
Are responders able to deal with questions effectively?
Regarding the first question, different types of venues appeal to different editors, so it can be useful to have a metaphorical teahouse setting as well as a more terse question-and-answer format. Regarding the second question, as noted by others, different responders may be interested in answering at different levels of detail. Is having multiple venues effective at supporting this, versus the tradeoff of some responders having to monitor several places? Related to both questions, if someone asks a question in one place that, based on the level of detail needed by the questioner, is better suited for another place, is that question still handled effectively (by still answering at the desired level, by smoothly moving it to the other place, or by other means)?
In short, I'd like to hear from the people on the ground: does having two venues hinder your ability to get appropriate responses or to adequately respond to questions? Do we need to have a wider mix of people watching the help desk or teahouse in order to deal with different expectations on level of detail? Is eliminating one going to actually draw more watchers to the other? I'm not enthusiastic about telling volunteers to stop contributing to a productive initiative, even if I think they could equally help another productive initiative. isaacl (talk) 19:46, 24 April 2021 (UTC)[reply]
I occasionally stop by both the Teahouse and Help Desk, and even answer questions. I wouldn’t call myself highly experienced in either. I do see a lot of overlap (but also much difference). If someone asks a noob question at HD, it’s better to answer them in-place rather than tell them to go off and re-ask at Teahouse. Vice-versa, having some more-clueful questions at Teahouse helps break the monotony there. If we did want to maintain a strong separation, rather than an intent, then we could move discussions from one forum to another, just like this discussion has been moved from VPP to VPR. But moving threads on MediaWiki is a bit more cumbersome than on some other discussion platforms. I do think we're a bit curt with people asking a question in both places: having two fora is potentially confusing and asking for help in more than one place isn't in the same league as forum-shopping across DR–AN–ANI. Both HD and TH are limited by the high volume and rapid archiving, especially Teahouse. I recall one new editor who was quite miffed that the Teahouse is presented as a place to have a friendly chat, but is in practice mostly a rapid-fire Q&A feed. If we were a smaller community, we could have all chat at le Bistro or the Beerhall, rather than compartmentalising it into multiple silos (VP* is a good example). This brings us to a practical limitation. Merging the two would exacerbate the situation with high volume of questions. And there’s also the nature of the questions: the merged Help venue could be overwhelmed with so much repeated "how i make new article for non-notable thing?", "my thing's not showing up in Google", and "why AFC take so long?". Talking about practical as opposed to intended differences, a big difference between Teahouse and Help Desk is the entry points. New users often get a big welcome message directing them to the TH.
For those wondering what the differences are between EA/EAR and Teahouse/Help Desk; If you take a close look, you will notice that many EAR requests are dispute/content related, something I think Teahouse/Help Desk either do not deal with, or do not promote being that they are mainly promoted as Q and A forums. Other things that are promoted heavily on EA/EAR, but not on Teahouse are the ability to contact a list of helpful editors directly and make edit requests. While these features might be technically possible at the Teahouse, they are not promoted in any way that makes them functionally useful such as they are at EA/EAR. Huggums537 (talk) 16:03, 1 May 2021 (UTC)[reply]
Comment. I've been active answering requests at WP:EAR lately. I like it because it's low traffic, but not completely inactive. I can keep it on my watchlist without it bloating to 100+ revisions a day, and I have a decent chance of being able to answer (before someone else provides a good answer, making the need for me to answer unnecessary). –Novem Linguae (talk) 23:19, 1 May 2021 (UTC)[reply]
Proposal: deprecate WP:EA/WP:EAR and close down all active templates or help pages linking to it
Yes, this does help because I can see the "inactive" tag was improperly attributed to a forum that is actually just "less active", a misrepresentation I wouldn't have been so miffed about if it had been properly presented as "nearly" or "almost" inactive. Huggums537 (talk) 10:57, 2 May 2021 (UTC)[reply]
Ok Nick Moyes, I owe you an apology for harping about the "inactive" tag bit. Upon further investigation, it seems the idea originated from the original post of ProcrastinatingReader who said the venue was, "completely inactive", leading others such as GreenMeansGo, Levivich, and Sdkb to conclude the venue was of a "historical" nature. ProcrastinatingReader could you explain why you described the venue as "completely inactive"? I'm assuming good faith that you were referencing the EA signup page not the EAR project page, and had no intention to misdirect anyone. I also agree that page is not very active. However, I think it is very similar to the signup page of many other projects, and that it is not intended to be be all that active since it's only real purpose is for people to sign on to the project. Many of these project signup pages are not really that active. This is hardly grounds for putting any project into a "historical" condition, or calling it completely inactive when an editor signed up for the project just a month and a half ago. Huggums537 (talk) 12:31, 2 May 2021 (UTC)[reply]
The statement is quite clear: More importantly, my feeling is that Wikipedia:Editor assistance should probably be redirected somewhere, as that venue is completely inactive and mostly goes back to pre-2011, and WP:EAR should probably be redirected to either Teahouse or the help desk as it doesn't seem to have any distinguishing features from either. It does not say what you seem to think it says. The last 5 registrations go back to 2018, and the last 10 go back to 2012, almost a decade ago. That's "completely inactive". ProcrastinatingReader (talk) 13:16, 2 May 2021 (UTC)[reply]
@Huggums537: While they may not be entirely dead, there is still probably some calculation to be done there about whether we're confusing new editors by having unnecessary duplication of forums that have very little variation in scope. As already covered, there is a non-overlapping region for TH and HD. That's largely due to efforts like HostBot, that specifically target new users.But we're not doing ourselves any favors if we have so much redundancy that "where do I ask my question" ends up being somebody's first question. Alternatively, if you have links to helping forums far and wide, and a new user that doesn't know hot to use their contribution history, and can't find the question once they've asked it. GMGtalk16:05, 2 May 2021 (UTC)[reply]
I agree more calculations would need to be done because I very seriously doubt we would be facing any "where do I ask my question" issues. This is an irrational fear-based argument that has no basis in reality since the status quo has not already produced any significant amount of such issues that I'm aware of. There is no reason to expect that leaving the EA/EAR and TH/HD intact would cause things to change in that way. However, removing EAR removes options available to a user that are not available in the other help forums such as the ability to make certain dispute/content/edit requests. This is entirely useful for those who have no interest in a venue so vile as the peanut gallery. I recently discovered the joy of Wikipedia:Dispute resolution requests and found it extremely helpful to have dispute options available so that I could find a more friendly and suitable way to resolve a dispute. More options are better. See my bathroom argument below. Huggums537 (talk) 16:47, 2 May 2021 (UTC)[reply]
We have lots of issue-specific noticeboards and general question venues. Unnecessarily splitting up conversation reduces good outcomes, both in terms of answers to question asked and in confusion to the asker. There's a legitimate argument that merging HD+TH would cause the volume to be so high that the merge is counter-productive (hence it hasn't been proposed). Same is not true of EAR. We have {{edit request}} and WP:DR venues like WP:DRN and WP:3O. If EAR is duplicating the work of 4 different systems, and doing so in an inferior manner, then that's absolutely not a productive venue. ProcrastinatingReader (talk) 17:11, 2 May 2021 (UTC)[reply]
The key question as I mentioned previously is whether or not the requestors and responders feel the system works well for them. I don't like telling volunteers that they should stop working in a way they find productive just because I think they could be productive elsewhere. isaacl (talk) 17:20, 2 May 2021 (UTC)[reply]
It's not just because they'll be productive elsewhere, it's because having too complex a system scares off new volunteers. There's a survivorship bias in who actually makes it to posting a question, and many editors get intimidated simply when faced with multiple places to ask a question. While we would like them to be bold and pick one, many people are afraid of choosing wrong and getting yelled at so they just don't post. Duplicating work can be harmful, and if volunteer workflows are harming efforts to bring in more volunteers then yes I think we should ask them to learn a new workflow. — Wug·a·po·des06:54, 3 May 2021 (UTC)[reply]
Wugapodes, where is your data or any evidence to suggest that any such harms have been occurring with the current processes? I grow weary of these fear-based arguments rampant on Wikipedia without any rational evidence to back them up. This proposal is essentially asking that we go intrude upon a group happily conducting business, and force them to pack up shop to do business in places they may not want to, and in ways that are not exactly the same as they are accustomed to all because we think we know better, or don't like what they are doing, and all in the name of less activity. That makes just about as much sense as boarding up the guest room so nobody can use it at all since it doesn't get used that much anyway. Huggums537 (talk) 11:27, 3 May 2021 (UTC)Also, your argument suggests we should put a sign over the boarded guestroom door that says, "Harmful! Do not enter!" It's kind of comical actually. All this talk about "duplicating" work as if we are somehow going to be multiplying things just by leaving them as they happily have been is really absurd. The Wikipedified logical mentality mystifies me. Huggums537 (talk) 11:48, 3 May 2021 (UTC)[reply]
It would probably be impossible to know. I guess we could look on the user talk pages of the editors listed there for any questions asked, but it'd be impossible to know WP:EA is where they came from. With ~150 pageviews per month, I'm not optimistic. In any case, the format is IMO archaic and inferior to newer systems. ProcrastinatingReader (talk) 17:43, 2 May 2021 (UTC)[reply]
Well, there are the requests on the request page for which you can see the responses and response time. If you're thinking about direct contact with helpers, personally I wouldn't call it an inferior mechanism: one-on-one assistance can be effective. In any case, I don't think a shutdown should be imposed. Feel free to have a chat with the editors involved and reach a consensus that answering questions at the help desk would be essentially equivalent. isaacl (talk) 18:45, 2 May 2021 (UTC)[reply]
Oppose because this seems like a useful venue to me, and I don't understand why anyone thinks the venue is inactive since there are currently 15 open requests. I also don't understand why notice was given about this discussion on the Teahouse and Help Desk talk pages, but not the other two, so I will do that now. Huggums537 (talk) 14:32, 1 May 2021 (UTC)[reply]
Support it may have been useful historically, but now it seems to be an unnecessary duplication of the Help Desk. – Teratix₵14:38, 1 May 2021 (UTC)[reply]
Except the Help Desk does not offer dispute resolution or take edit requests like EAR does even though they might be able to do so if asked, but it isn't offered as a standard feature, so it's not really a duplicate. Huggums537 (talk) 10:57, 2 May 2021 (UTC)[reply]
That's also just half the point, the other is that it causes needless redundancy and unproductive decentralization. Aza24 (talk) 07:22, 2 May 2021 (UTC)[reply]
The main thing I notice from the stats above is that the person who adds the most text to the Teahouse is one Nick Moyes. So, what we have here is a takeover bid in which smaller rivals are crushed and destroyed. The trouble is that you do not get economies of scale in Wikipedia. Bigger is not better because wiki pages become unusable when they get too large, becoming unreadable and having technical trouble with template overload. And, if you force people to do things in the one true way, then volunteers who don't care for this will tend to withdraw their labour. So then fewer volunteers are given a larger workload. This may work for a while but you then get burnout of a single point of failure. Notice how the Signpost is in crisis again because its centralised structure is burning out the chief editor once more. My !vote stands. Andrew🐉(talk) 08:56, 2 May 2021 (UTC)[reply]
I kind of agree with Andrew Davidson. This logic that we already have a place being used for help so we don't need another is akin to the family who upgraded their home from a 1 bed/1 bath up to a five bedroom home and said to themselves; "we don't need another bathroom, we need a centralized place for everyone to pee to make things easier". It's completely senseless. Also, there is no redundancy in keeping EAR when you are comparing two forums that offer different kinds of services and EAR offers services the others do not. However, even if it were a "redundant" service, I think my "more bathrooms is better" argument still applies. Huggums537 (talk) 10:57, 2 May 2021 (UTC)[reply]
Support Per NickMoyes's data above. We should not be dividing our efforts because having too many venues confuses newbies. It's best to steer new editors to a single place to ask questions or make requests, and the Teahouse got 30x more traffic than WP:EAR in 2020 so I think we should go with that one. Editors active at EARS can still continue to fulfill requests, just watch the Teahouse for them instead. — Wug·a·po·des06:47, 3 May 2021 (UTC)[reply]
Support. I don't see the value in having multiple venues with overlapping focus, and I think it creates more issues than it solves:
It's confusing for newcomers, who are already confronted with a huge number of noticeboards, help pages and discussion forums. As an example, if you were looking to find out if a source is usable in a draft you're writing you could be directed to WP:TEA, WP:RSN, WP:HD, WP:AFCHELP or WP:EAR, all of which could be suitable places for asking your question.
It splits volunteer contributors across multiple pages, which means helpers who are experts in one aspect of editing may miss questions posted on a help forum they don't check often, resulting in lower quality answers.
People asking for help on the lower traffic noticeboards will have an unnessasarily longer waiting times for responses. Some of the questions on WP:EAR took 3 hours or more to get a response, which isn't ideal for a newcomer in the middle of writing their first page. 192.76.8.91 (talk) 16:45, 3 May 2021 (UTC)[reply]
Proposal1: Replace Main Page Help Desk link with Teahouse link
Support Whilst we're here: to follow up from this discussion which closed with consensus to add a Teahouse link but wasn't sure on which form it should take. It seems like there's probably a consensus to keep TH and HD separate for now. So I think replacing the Help Desk link on the Main Page with a link to the Teahouse would be better. Editors coming from there are probably newcomers, and it's too confusing/bloaty to have them both listed trying to explain the differences IMO. ProcrastinatingReader (talk) 07:46, 24 April 2021 (UTC)[reply]
Commment Whilst happy to support this, I am slightly concerned about removing the Help Desk link entirely. Wouldn't the following work OK?:
Community portal – Bulletin board, projects, resources and activities covering a wide range of Wikipedia areas.
Teahouse - A help desk for novice editors. A friendly space to ask about editing Wikipedia.
Local embassy – For Wikipedia-related communication in languages other than English.
Reference desk – Serving as virtual librarians, Wikipedia volunteers tackle your questions on a wide range of subjects.
Site news – Announcements, updates, articles and press releases on Wikipedia and the Wikimedia Foundation.
Village pump – For discussions about Wikipedia itself, including areas for technical issues and policies.
I wouldn't want to undermine any attempt at gaining a consensus by offering a formal counter-proposal at this early stage, but do add one if it helps. Nick Moyes (talk) 09:12, 24 April 2021 (UTC)[reply]
This works for me, although I'd say put the Teahouse above HD in order, and replace the Help desk description with something like "For more experienced editors to ask questions about editing Wikipedia." I still think I prefer replacing the link altogether, as I think the Teahouse does a better job at helping newbies and that giving unnecessary choices is bad UX and adds a slight bit of friction. ProcrastinatingReader (talk) 09:44, 24 April 2021 (UTC)[reply]
Support one link. Oppose two links. We don't need and shouldn't have two forums for asking questions (so help desk and teahouse ought to be merged). If we do have two forums, TH should be linked on the main page (so support this proposal). Under no circumstances should both be linked; that will just confuse people. Levivichharass/hound13:24, 24 April 2021 (UTC)[reply]
Support Teahouse link on Main Page and, if we have both links, putting it above the Help Desk. If we retain both, the Helpdesk blurb line should include something that it is for non-novice editors. I am neutral to removing the Helpdesk from main page and just having Teahouse there. Nosebagbear (talk) 14:02, 24 April 2021 (UTC)[reply]
I do not support this good-faith, well-intentioned suggestion. I support adding an additional link to the tea house and I have no objections whatsoever to placing that link above the help desk link. But as long as the help desk is open and we want editors to use it then we need to link to it. I strongly recommend a separate discussion focused solely on whether we can and should consolidate these two efforts; I would strongly support such a motion but it seems to be a much larger proposal than what has been put forth here that warrants a separate, dedicated discussion with a clear header so other editors can see what is being proposed. ElKevbo (talk) 02:59, 25 April 2021 (UTC)[reply]
Link to both but put the Teahouse above the Help Desk. Adding another line won't damage the layout, but it will allow more people to get the assistance they need. —Naddruf (talk ~ contribs) 17:11, 25 April 2021 (UTC)[reply]
Further comment on Main page wording I'm uncertain what words are best if the Teahouse goes above the Help desk on the Main page links. I've racked my brain, and this is the best I can come up with:
Teahouse - A help desk for novice editors. A friendly space to ask about editing Wikipedia.
Help desk – Ask questions about using Wikipedia. Aimed mostly at those with some editing experience already.
Support removing the Help Desk link and replacing it with a link to the Teahouse. The Main Page is likely where new editors will go for information. Experienced editors can still manually go to the Help Desk.EpicPupper20:26, 27 April 2021 (UTC)[reply]
Support link to both as proposed by Nick Moyes here. My logic is that we need two different places to get either advanced or novice answers. As a newer user, I'm glad to now be aware the help desk exists. I've been going to the Teahouse for answers, and while I appreciate the friendly, and helpful manner, it kinda sucks getting treated like a day one IP user getting spoon-fed answers. Now I know I have a place I can go to get answers I can handle. I think other users will like to know this too. Huggums537 (talk) 14:48, 1 May 2021 (UTC)[reply]
But you didn't learn this information from a link on the Main Page, and other established editors won't either. — Bilorv (talk) 23:18, 1 May 2021 (UTC)[reply]
But still, I learned about Teahouse from my talk page, and if there had been a descriptive Teahouse link on the main page with a contrasting descriptive Help Desk link right below, I most likely would have picked up on it much sooner. Huggums537 (talk) 12:31, 2 May 2021 (UTC)[reply]
Support: just a link to the Teahouse is preferable (don't make people confused before they've even clicked on a help forum, because they don't know which one is right for them) but a link to both Teahouse and Help Desk would be an improvement, as the Teahouse is friendlier. — Bilorv (talk) 23:18, 1 May 2021 (UTC)[reply]
Support replacement of link....only need one and the teahouse is better at recruitment for new editors. This past year has seen a good increase in the amount of individual edits but a decrease in registration.....perhaps the Teahouse can help us fix this problem.Moxy-23:08, 2 May 2021 (UTC)[reply]
What's the point of this? I mean, the archiving bots could be setup to create permanent, dated archives if that were deemed useful (verses the current rolling archives). But there's simply so many reports made I just don't see how it could be useful. ProcrastinatingReader (talk) 11:17, 21 April 2021 (UTC)[reply]
I guess it'd be up to RfPP admins if they'd find that helpful, but if they think yes then it'd probably be better to WP:BOTREQ a bot to reply to RfPPs with links to permalinks of previous protection requests. Even if you did manage to compile all RfPP archives on your page (a very laborious task to do by hand), it'd take so long for that page to load and then to ctrl-f the page title that it just wouldn't be particularly effective. ProcrastinatingReader (talk) 12:51, 21 April 2021 (UTC)[reply]
Probably unnecessary but also probably harmless. Admins (anyone, actually) can already review the protection log of a page to see how recently and how often the page has been protected. Reviewing a log of times that a protection request was declined is (IMO) not really useful in deciding on protection. Ivanvector's squirrel (trees/nuts) 12:54, 21 April 2021 (UTC)[reply]
As an admin who used to patrol RFPP a lot (and still drops by from time to time), I would find this functionality useless; I mean if you want to do it because someone else might find it useful, go ahead, I'm just saying it would have no impact on my RFPP work; I base my protection decisions almost entirely on the article history page and protection log, where prior protections are easily visible and can be tracked just fine. So basically, I don't object to it if someone else finds it useful, I just wouldn't. --Jayron3212:55, 21 April 2021 (UTC)[reply]
Agreed, but the same bot is responsible for lots of other non-seperable clerking of bot reports so "just shut it down" isn't as easy as it sounds. I'll give the bot operator a ping, but I don't expect action given that he was first requested to do this in 2019 and never did. * Pppery *it has begun...21:25, 22 April 2021 (UTC)[reply]
Agreed, it's not as easy as pushing the big red button. But, if there's a request for the bot to change or stop doing something that it's currently doing, and the operator is unresponsive, I won't hesitate to block it. Ivanvector's squirrel (trees/nuts) 15:03, 27 April 2021 (UTC)[reply]
I also just don't get how this helps. To me this is like archiving WP:UAA or WP:AIV. These are boards that receive new reports all, day, every day. Archiving all these requests would create mountains of new pages that would almost certainly be largely unmaintained and basically ignored as old business. I don't see the benefit. Beeblebrox (talk) 20:19, 22 April 2021 (UTC)[reply]
While the utility is a little questionable, again it does no harm. And in the absence of that harm, if the editor feels it is either beneficial or enhances transparency then I support them doing so. Nosebagbear (talk) 20:29, 22 April 2021 (UTC)[reply]
I'll add on that I support this (although my comments above imply it to some extent), primarily on the argument of consistency: nearly every other noticeboard is fully archived (including ANI, which gets approximately the same number of edits per day as RFPP), so it seems odd to me not to do it in one case. * Pppery *it has begun...21:53, 25 April 2021 (UTC)[reply]
Not really though. ANI is a place for discussion of complex issues. AIV, UAA, and RFPP are for quick action in more obvious cases. That's why they aren't archived and also why archiving them would not be useful. Beeblebrox (talk) 01:22, 1 May 2021 (UTC)[reply]
There are several different types of noticeboards. There are the ones that have good reasons not to be archived (i.e. AIV and UAA). There are the ones that are archived (AN, ANI, AN3, BN, IAN, EFN, RSN, COIN, BLPN). There are the ones that are archived, but in a strange manner (PERM, XfD, SPI). And then, there's RFPP. Some users want it to go with AIV and UAA. Others want it to go along with the Ns. 🐔ChicdatBawk to me!11:02, 2 May 2021 (UTC)[reply]
Can we come to a consensus on when it is appropriate to "rescue" live links in an article with IABot?
If you visit the history page of any article, at the top you'll see "Fix dead links". This takes you to a page on https://iabot.toolforge.org where you can use IABot's database to add archive links to the page. There is a box for "Add archives to all non-dead references (Optional)" and it's that little box that I'd like to talk about here.
As I understand it, clicking that box does not archive the page. That has already been done by the bot and stored in an off-wiki database. All it does is copy the archive links that already exist into the article en masse. Many people have taken to just going around to various articles that do not have dead links and "rescuing" all of the live sources.
The reasons why this is good: I think the main reason people think is good is because it archives all the links (i.e. misunderstanding how it works), but there's something to be said for having everything already in the article, just in case IABot goes down, stops being maintained, etc.
The reasons why this is not good: It adds significantly to the size of the page without adding any meaningful functionality. See for example, this diff which was just the most recent on my watchlist and not the largest I've seen. It adds 12k to the page with no dead links rescued. This means the page is larger, of course, but also means anyone using the source editor has to scroll through even larger citation templates. It also throws off the various tools we have to understand authorship of a page. Controversial subject, I know, but sometimes it's useful to take a look at the xtools page statistics in order to see who's been working on an article, which isn't always apparent just by looking at the most recent history. In this case, someone who simply rescued links that didn't need to be rescued is now listed as the primary author of this page. (Apologies to YoungForever, who was just trying to help here. I don't mean to single you out -- there are a lot of people who use the tool this way.) We also know that some Wikipedians are motivated by making large numbers of contributions, and I'd suggest the ability to quickly make these large, semi-automated edits at any article could also be a motivating factor for some (I've seen people, in a long string of edits, go to dozens of articles just to rescue live links).
TL;DR - If it is desirable to have all archive links in the article, a bot should do it, rather than leave it to arbitrary drive-by rescuing of things that don't need rescuing. If it's not desirable, this option either shouldn't be available to users or we should be clearer in the displayed text for that option and allow reverting if used improperly. If it is sometimes desirable to rescue links that aren't dead, what are those cases? — Rhododendritestalk \\ 14:27, 23 April 2021 (UTC)[reply]
I agree it shouldn't be done arbitrarily. It should be a step for a practice like in the final preparation for a GA/FA and subsequent maintenance once that's been achieved. (eg once 90% of the refs have archive-url's, bot-archiving the rest is not a problem). I can also see it being done for a topic where the bulk of the sourcing does exist only from web pages, such as many current event articles, but that should be some time well after the article is created where the possibility of link-rot may arise - at least if not more than a year out from creation, not in that first year for certain. --Masem (t) 14:43, 23 April 2021 (UTC)[reply]
@Masem: Just to clarify, when you say I can also see it being done where the bulk of the sourcing does exist only from web pages, are you saying that archiving those links is what should be done so that if one dies an archive can be added semi-automatically? Or that all of those links should be added directly to the article preemptively in addition to being archived by IABot off-wiki? IABot is archiving/storing them whether we use that interface or not. The question is when to move the archive links into the article text. — Rhododendritestalk \\ 14:51, 23 April 2021 (UTC)[reply]
I'm talking about when they are added to the wikipage. We do want the backgrounding of Archive links to happen regardless, I feel, but adding those to Wikipages is where the problem lies and should only be done for polishing purposes (GA/FA) or if the article is heavily reliant on online sourcing. --Masem (t) 15:04, 23 April 2021 (UTC)[reply]
If it is desirable to have all archive links in the article, a bot should do it, rather than leave it to arbitrary drive-by rescuing of things that don't need rescuing.Rhododendrites, I agree with that. And there is another reason to add archive links: WP:EVADEGDPR. By the way, when it comes to the concern of longer wikitext (never really bothered me), this could be reduced significantly by adjusting templates. The citation template on Dutch Wiktionary for example requires no archive date and allows omitting the live URL. — Alexis Jazz (talk or ping me) 15:05, 23 April 2021 (UTC)[reply]
Years ago my proposal to automate the archive-date (based on parsing the archive-url of common archive sites) was rejected. Can't find it in the archives at the moment. I generally support reducing redundancy among fields. However, I don't support removing the url if there is an archive-url, because it makes it more confusing to scan for specific refs or update the ("where the hell is the URL itself? Oh right, it's encoded as part of another URL in a different field."). DMacks (talk) 15:57, 23 April 2021 (UTC)[reply]
DMacks, on Dutch Wiktionary it isn't common to omit live URL either and if specified the entered URL will be used. The template just doesn't make a fuss about omitting the URL. I'm not really sure if structurally omitting the live URL would be a good idea, but I wanted to mention that technically it's possible. — Alexis Jazz (talk or ping me) 17:36, 23 April 2021 (UTC)[reply]
Thanks for explaining the origin of these edits. The term "rescuing" on my watchlist kept confusing me when links were all live (it's not clear that there is any bad situation that is being remedied). DMacks (talk) 15:29, 23 April 2021 (UTC)[reply]
100% agree with OP. I used to make this mistake when I first got here: I went about to articles, checked the optional box and added all the archive links. I thought this was archiving the links. Someone at some point set me straight, and now I realize this adds a lot of unnecessary bloat to articles. It also messes up authorship stats. I am listed as a main author of Alexandria Ocasio-Cortez and Yellow vests movement but it's only because I added like 40k of archive links with one click. That optional checkbox should at least have a warning if not removed or moved somewhere else. Levivichharass/hound16:57, 23 April 2021 (UTC)[reply]
I don't really use the IABot that much. I only used it when I come across a canceled TV series that ended already, a miniseries (only 1 season) ended already, dead person, or film that has been out for a while as the urls of the articles may not work or updated with information that may not be relevant to the articles anymore. I didn't think it is a big issue to add archive urls to live links as I seen a lot of veteran editors using the IABot to do that as well. — YoungForever(talk)19:43, 23 April 2021 (UTC)[reply]
Assuming the information at WP:EVADEGDPR is true, I support editors (or bots) adding archive links to anything already archived on the Internet Archive (WayBack Machine) website, so long as bots are not doing so without either an editor requesting it for a particular article, or because the bot is rescuing other dead links on the articles. I don't really have an opinion one way or the other about a bot doing so for all pages without being asked to, but I wouldn't necessarily oppose it. -bɜ:ʳkənhɪmez (User/say hi!) 01:58, 24 April 2021 (UTC)[reply]
So perhaps this is due for an RfC. I think it ultimately comes down to:
Option 1 - Turn off the option to "rescue" links that aren't dead in the IABot interface because all links should be accompanied by an archive link, and we should have a bot add these automatically.
Option 2 - Turn off the option to "rescue" links that aren't dead in the IABot interface because IABot already archives all links and we don't need them in the article until the link actually goes dead.
Option 3 - Allow users to "rescue" links that aren't dead but set up rules for when it's allowed. (e.g. certain types of topics, or when actually rescuing a dead link) and add a warning to the interface.
Option 4 - Allow users to "rescue" links that aren't dead on a whimat their own discretion (status quo).
More or less? To be clear, I'm not asking for people to pick one of these here -- I'm making sure these are more or less the correct options to present, acknowledging that #3 would of course require follow up. — Rhododendritestalk \\ 02:19, 24 April 2021 (UTC)[reply]
I think add an option for "add a warning/advisory to the checkbox" (as opposed to #3's "rules"), and explicitly identify #4 as the status quo (w/more neutral wording). Otherwise looks good and thanks. Levivichharass/hound02:51, 24 April 2021 (UTC)[reply]
Regarding "rules" isn't that what we really need, though? Conditions when it's acceptable? Otherwise what would the advisory say? And yeah, I didn't actually intend "on a whim" to make it into an RfC. :) — Rhododendritestalk \\ 13:31, 24 April 2021 (UTC)[reply]
Rhododendrites, I would like to remove option 2. This tool is also used outside of enwiki and they have different practices. Amending number 1, disabling that option would be moot if we have IABot add archive automatically. Ultimately, this is a tool that anyone is free to use, but isn't being forced to. If it comes to what is allowed to be used and not, it should be policy centered, not implementing customized restrictions on an external tool. —CYBERPOWER(Around)14:01, 24 April 2021 (UTC)[reply]
@Cyberpower678:Facepalm thanks for the reminder that the english wikipedia is not the only project that uses these tools (and that I am susceptible to enwikicentrism). The issue with policy centered is our policies don't readily address this. So it seems like this will need to be rethought not in terms of removing the option but perhaps just (a) determining whether we want the bot to add all archives; if not then (b) developing our own rules for it and, if applicable, (c) adding an advisory when the option is selected saying (using general wording about it not being allowed on all projects or pointing to some documentation somewhere). How does that sound? — Rhododendritestalk \\ 14:28, 24 April 2021 (UTC)[reply]
As far as cons of archiving live links, does it slow down loading for readers? And are the longer references something readers will find annoying, or will it be potentially helpful if a link dies but is not yet identified as such? Those seem like more important, reader-centric questions to me than authorship percentages (which fundamentally is a fault of the tool's oversimplicity; tools should serve editing, never vice versa) or clogging up the source code (which fundamentally is a UI problem the WMF needs to solve). If we decide they're more annoying than helpful, one option would be to store archive links in the wikitext but not display them to readers so long as |url-status=live. {{u|Sdkb}}talk04:12, 24 April 2021 (UTC)[reply]
I imagine an extra 5, 10, 15, or in some cases 40-50k of data per page would have some affect. The WP:Article size guideline addresses page size at WP:CHOKING, where it explains that 32k takes about 5 seconds to load on a dial-up connection and long pages present problems with some mobile devices. I think as with so many things it's worth talking about how much useful it is compared to any costs. And I wouldn't fully discount costs to editors. Some things may "just" be a design issue that WMF or someone should fix, but that doesn't mean it'll actually happen. That's quite a tangent, though, and yes, readers are fundamentally the priority. I do think that storing the archive information in wikitext but not displaying it is the worst of all worlds, though. I've not heard of anyone annoyed by the appearance of archive links. I mean, long-term this is something that should be exported to Wikidata/WikiCite, but we're not there yet. — Rhododendritestalk \\ 13:18, 24 April 2021 (UTC)[reply]
We are not supposed to worry about *server-side* performance. We can still worry about adding to download and parsing times on the client side ("parsing" refers to any time added by extra parameters to the setting up of data structures that make the mouseover action happen). Fighting link rot by mindlessly adding massive numbers of archive-links doesn't enhance verifiability, when it's helpful to check for better original links (esp. when lost merely due to website reorganization), for availability of more up-to-date sources, and whether sources and text match. I would reserve IABot to, say, one-article-at-a-time usage, for those editors who don't care to learn the extra reference markup (e.g. archive-url, archive-date, url-status). Dhtwiki (talk) 14:53, 25 April 2021 (UTC)[reply]
No. We're trying to figure out whether there's consensus to add archive links to live references en masse. I don't think that would affect an individual decision to include an archive link for a particular citation. — Rhododendritestalk \\ 18:21, 25 April 2021 (UTC)[reply]
One might consider augmenting the "Add archives to all non-dead references (Optional)" capability with another option that allows the user to try and selectively add archives to specific references. I'm not sure how frequently this happens, but I have seen some "live" links that have actually died and been replaced by spam. The link is technically "live", so IABot passes over it and says something like, "no changes made" because there are no dead links. Well, I know I actually need to add an archive link to have the correct content, so I can go search the multiple archive sites for my URL, or I can take a shot at adding all archive links, and hope I get the right one. Sure everything else will get an archive link as well, but that's OK, right? Go ahead and do it. Sometimes I will search Wayback and Archive.today, but I'll tend to stop there. It depends on how lazy I'm feeling. Anyway, this doesn't necessarily solve the proposal, but it might slightly reduce the frequency of using add all archives. -2pou (talk) 17:05, 26 April 2021 (UTC)[reply]
MJL, Of course it does. If the objective is to add archive URLs to ALL references, and some of them don't yet exist in the Wayback Machine, then IABot will have the Wayback Machine save them and the URL of the snapshot will then be added to Wikipedia. —CYBERPOWER(Chat)15:34, 28 April 2021 (UTC)[reply]
@Cyberpower678: But it's not necessary to activate IABot in order to archive links because IA already automatically crawls Wikipedia and archives all its links, is that correct? For example, yesterday I created an article sourced to recent press stories. I don't need to "check the box" and add archive links to the Wikipedia article via IABot because those links in the article have already been archived, simply by virtue of being on an indexed Wikipedia page. Is that right? Also, if one of those links should go dead, there's a bot that will automatically replace the dead link with an archive link at that time, is that right? Just trying to see if I understand how it all works. Thanks for taking the time to explain this to us noobs. Levivichharass/hound16:15, 28 April 2021 (UTC)[reply]
In my experience, new links are usually but not always archived within a couple of days of being added. About a week ago I checked the links in Fagradalsfjall and manually archived several that had not been done automatically. Thryduulf (talk) 10:42, 29 April 2021 (UTC)[reply]
Levivich, yes. That is how the system is supposed to work. But sometimes, things can go wrong and some links are missed or failed to archive. It's not a common occurrence, but it can happen. Internet Archive after all has a massive infrastructure to maintain. —CYBERPOWER(Around)16:30, 29 April 2021 (UTC)[reply]
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.
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. Vaticidalprophet08:52, 26 April 2021 (UTC)[reply]
After reading comments below: I think the idea and the technical execution are different things. Turning all those indef sysop move protected pages into indef (?) page mover move protected pages has a similar end result. Some really high-visibility stuff could remain sysop move protected, but for some reason we have endless articles with decade-old indef sysop move protection. Spot-checking some entries in the sysop move-protected list I see next to nothing that couldn't be changed to pagemover move-protected. I see a ton where the move protection could be removed altogether or changed to extended confirmed. — Alexis Jazz (talk or ping me) 22:14, 26 April 2021 (UTC)[reply]
If we're doing this, then, yeah, I also support it. Naturally, since I also ran across the blockage a few weeks ago. As everyone does. The question is, I guess, is how urgent the issue really is; how long is the average wait to get an admin to undo the move protection? ——Serial11:37, 26 April 2021 (UTC)[reply]
Serial Number 54129, in the case above it wasn't. An admin carried out the move, but the page remains move protected. If the organization gets renamed in the future, we'll need an admin again. — Alexis Jazz (talk or ping me) 11:41, 26 April 2021 (UTC)[reply]
Support, although I would say that the reason move-protected pages aren't reviewed is that nobody asks for such reviews. Mjroots (talk) 11:39, 26 April 2021 (UTC)[reply]
I'd support this. We should expect that anyone being granted page mover isn't a page-move vandal and that they know not to move controversial pages without consensus. Elli (talk | contribs) 12:02, 26 April 2021 (UTC)[reply]
Comment If I recall correctly, this isn't possible without also giving page movers the ability to edit protected pages too. Anomie⚔12:37, 26 April 2021 (UTC)[reply]
That seems easily resolvable with a situation similar to template editors, where the vast majority of move-protected pages are reclassified as PMR-protected and the very few that dead-cannot be edited by non-admins ever (Main Page type stuff) are kept at full. Vaticidalprophet12:45, 26 April 2021 (UTC)[reply]
Support The issue with protection levels is that you have wayyyyy too many overprotected pages. In particular, there's overprotected redirects, overprotected salted titles, and overprotected move protection. Many seem to be pre modern protection policy standards and pre-ECP. These overprotections are unsolvable - too many pages are subject to it such that it can only be solved by a bot, and the discussions at AN to do something en masse (eg based on protection reason) tend to end in no consensus due to vague 'concerns'. The typical argument is that one can request it be lowered at WP:RFPP. Yes, that's true, one can request a specific page's protection be lowered at the perennially backlogged WP:RFPP. But if you're going to chuck the task into someone else's bucket you might as well just file a WP:RM/TR (which is what I do). This is an artificial backlog at best, and just a waste of multiple people's time. We adequately vet page movers, and the standards for PMR currently are likely higher than those to become an admin in 2004. If this proposal passes, PMRs moving move-protected pages should be limited by policy to do so only in the same circumstances as admins. As such, there is no real risk here. ProcrastinatingReader (talk) 14:24, 26 April 2021 (UTC)[reply]
Strong Oppose with the assumption that this proposal is actually "allow page movers to move pages that have administrator-only move protection" (as they can already move pages that have move protection that is within their edit levels). Not only does this technical capability not exist (preventing this from actually being able to be fufilled without developer work - that they may not be interested in doing), but there is no way I'd want a "page mover" messing with pages such as these or these. We don't even let the much higher scrutinized template editors do that, and the bar to entry for page mover is much lower. — xaosfluxTalk14:53, 26 April 2021 (UTC)[reply]
If this is actually about something else, such as creating a new protection level, I don't really have opposition, but don't really think it is needed - so Neutral in that case. — xaosfluxTalk14:56, 26 April 2021 (UTC)[reply]
@Xaosflux: IMO you're assessing the proposal and risk factors by the wrong criteria. The technical ability to move a page doesn't mean the page will be moved, and I can't imagine a page mover trying to move Module:Math just because they can technically do it. In my mind the argument is equivalent to saying giving DYK/ITN admins technical access to Special:MergeHistory is going to result in broken page histories.
The right criteria to assess this by would be: a) does it have a material benefit on backlogs and/or our move-related processes (ie: does it improve the encyclopaedia); b) is the proposal too risky. I don't think anyone can reasonably disagree on the first point, so that just leaves the second (risk). Pages should (broadly) be move-protected due to vandalism, edit warring, or preventative protection (eg high usage templates/modules) where there may be an elevated risk of vandalism or good-faith moves that misunderstand the level of consensus needed to move. (unless I'm missing other cases?)
Vandalism: Those with PMR are not going to be vandals.
Well-intentioned bad moves: Page movers are adequately vetted for a track record of requesting successful moves at WP:PERM/PM, and IMO the standards are about right (except in the case of requests on the basis of WP:R2 deletions for draftifying pages, a task which should be done by a bot IMO), so you'd expect them to have good judgement on when they might or might not be the appropriate editor to move a page or close an RM. Probably the average page mover is more likely to be competent at this task than the average admin (as most don't work in the area of page moves).
Misuse in content disputes: There's plenty of passionate admins who are involved in disputes too, and they don't edit their controversial opinions over a fully protected page locked for edit warring, even though they can technically do so. I don't think this will be different, and if there is misuse pulling an unbundled perm isn't difficult. ProcrastinatingReader (talk) 15:30, 26 April 2021 (UTC)[reply]
In regards to the questions about "content" type pages that are admin-move-protected; just like with other protections these should only be protected to the level and duration necessary to prevent disruption; if there are bad protections they should get reviewed and adjusted. A random click in the list of full-move-protected-articles came up with Trevor Lock for example, which I can't see any good reason for needing admin-only move protection on (which I just removed) for example. — xaosfluxTalk16:10, 26 April 2021 (UTC)[reply]
@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)[reply]
@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. — xaosfluxTalk00:00, 27 April 2021 (UTC)[reply]
@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)[reply]
Regretful oppose allowing pagemovers to move fully-protected pages as the potential for (likely unintentional) disruption is too high and would require developer time better discharged elsewhere. Weak oppose also creating a new protection level of "PMR-protected" as this will also require dev time, and I doubt would actually solve Vaticidalprophet's original issue. ƒirefly ( t · c ) 15:03, 26 April 2021 (UTC)[reply]
I can absolutely confirm that changing sysop-protected pages that didn't absolutely demand it for security reasons to PMR would have prevented/solved my original issue. Vaticidalprophet16:09, 26 April 2021 (UTC)[reply]
Oppose. This makes sense for the kind of cases mentioned, sure, but xenoxaosflux makes the good point that there are page that we definitely want as few people as possible to be able to remove. A more viable solution to the problem might be to create a new page mover move protection protection level and encourage the use of that over full protection. That also depends on developers being willing to implement it, though, and does sound a little creepy. – Joe (talk) 15:10, 26 April 2021 (UTC)[reply]
Right problem, wrong solution - the solution is to lower the protection level of pages that are overprotected. There is a proper place for admin-only move protection; unfortunately too many pages are full protected (not just admin move protection but admin edit protection too). The answer is to reduce the protection level of these pages. Generally speaking it seems to me that there is or was some ethos in the admin corps that protecting a page is better than blocking an editor, but I think, e.g., if ECP editors are move warring, they should be blocked rather than the page move protected. I guess maybe partial blocks will change this. Levivichharass/hound15:20, 26 April 2021 (UTC)[reply]
Oppose per Xaosflux; this is moving the technical abilities of page movers too far from their social abilities, and that sort of split tends to erode with time. Neutral on creation of a separate protection level for page movers. * Pppery *it has begun...15:35, 26 April 2021 (UTC)[reply]
Can the opposers please !vote as they would for PMR-protection, then? This is a frequent problem, and had particularly terrible consequences for me today offwiki. This is not something I'd be happy with having fail because people agreed on the facts but disagreed on the implementation. We're not up to 'formal RfC' stage yet; it's fine to spend some time figuring out the nuances of how to implement this. Vaticidalprophet15:51, 26 April 2021 (UTC)[reply]
Creating a separate PMR protection level would probably be a mess. Immediate issues I can think of:
You'd have to lower all 'appropriate' full protections somehow, and get consensus for a criteria to do that, probably via bot as (unlike high-risk templates) there's too many protected pages to do by hand.
Unlike high-risk templates, where you don't get a new one every day, move protections are not infrequent. How do you educate 1,100 admins on the policy change, that they should now use "PMR protection" in almost all cases?
Would you need some admins continuously policing fully protected pages lowering full protections to PMR protection when admins unfamiliar with the new policy make what would then be considered an overprotection? How much of a time-sink would that become (consider WP:RAAA, and the current difficulties getting even ancient overprotections lowered at WP:RFPP).
The chance of this proposal passing is low, and it doesn't really matter whether the opposes have an logical, evidence-based foundation (if we wanted to discuss evidence we'd check WP:RM/TR for requests by page movers, or look at the number of reverted moves/RM closes by PMRs). Unbundling proposals seem to just get knee-jerk opposes, even though the concerns never seem to materialise when the same (or nearly equivalent) proposal eventually passes. Consider TfD NAC deletes (then the same proposal passed in the name of 'close as orphan' and no calamity happened),[2] page mover having the perms it has now (originally failing in WP:PMRRFC), a new group to edit protected templates (now template-editor), etc. ProcrastinatingReader (talk) 16:21, 26 April 2021 (UTC)[reply]
W/r/t PMR-protection, I'm unsure, as I don't feel I have enough information to form an opinion. One concern is the dev time issue. I'm sorry you had a crappy day today Vat and I can understand why you're frustrated, but with all due respect, and maybe I'm misunderstanding the proposal, but the PMR-protect proposal is coming across to me like, "one editor had a bad day today because of a page they couldn't move, so we want the devs to code a new level of protection." That seems, well, unnecessary. As has been asked by others here, how widespread is this problem? Will creating a PMR-protect encourage admins to protect to that level, ultimately increasing the number of pages that can't be moved by ECP editors? If so, I don't think that's a good thing. Will page movers respond any faster/better to unprotect or move-protected requests than admins do currently? I don't know, as we have many more admins than page movers. I agree with you there is a problem with too many pages being protected, including move protected, mostly but not only in mainspace, and I support any efforts you make to investigate and develop consensus around a solution to that problem. Right now, I'm not convinced PMR-protect is the right solution, but I'll keep an open mind and an eye out for future proposals. Levivichharass/hound17:39, 26 April 2021 (UTC)[reply]
Thanks for the sympathy (genuinely -- it occurs to me that sentence sounds a bit flippant). I did, as I note, make this proposal before things went pear-shaped. This is the second time quite recently I've ran into sysop-protected moves, over both recent disputes and long distant ones, and I had another one a couple weeks back that stayed on RM/TR for over 24 hours. I watchlist RM/TR, as I think most of our active PMRs do, and I routinely see "closed by PMR, sysop-protected" requests that stick around while requests PMRs can handle get resolved. Vaticidalprophet17:47, 26 April 2021 (UTC)[reply]
Oppose per Xaosflux. Just make half of the page movers admins, then no additional protection level is required. —Kusma (t·c) 16:25, 26 April 2021 (UTC)[reply]
Is this that big of an issue? I have closed a few RMs that needed admin privileges, and I have seen Buidhe post several to RM/TR as well. As a watcher of the RM/TR page, I know that Anthony Appleyard frequents the page and clears the backlog on pretty much a daily basis (if not more often other times), and I know there are other admins that stop by there as well. If a RM is closed, but the move is still pending, people should be patient. If someone raises a stink... well this whole project is a WP:WIP and there's honestly WP:NORUSH to completion, in my opinion, if it's actually in the queue to get done. The RM went through a 7-day wait, and another one or two to complete the closure should not be a big deal. One can always augment the closing note, or add a note below the closed discussion stating that the move is pending. I think Aseleste did that regularly for NACs of pages that just had blocking redirects before getting move privileges. That all sounds negative, but all that said, I would welcome the privilege, not oppose it; I just don't think it's too high a priority. As to opposing this because of highly technical cases like Modules and Templates, that seems to be throwing out the baby with the bathwater. A page mover should know what they're comfortable moving, and if it's too complex, they should let someone else handle it. I know that several Template moves are posted on RM/TR, but they linger there for longer than other requests, and I have to assume that this is because some movers think that another mover would be better off handling it for fear of breaking something. If someone over-reached on a valid request, "It's OK to make mistakes. Try to fix them and learn from them, too.". If someone just abused their privilege or did something stupid, revoke the right. Unfortunately it will need cleanup from someone else, but it can still be fixed. Still... seems like a "nice to have" more than a need, but if some developer needs something to do, sure. -2pou (talk) 16:39, 26 April 2021 (UTC)[reply]
There are several thousand mainspace articles that are admin move protected. I don't know whether the solution is to reduce overprotection of pages or allow page movers to move fully move protected pages in mainspace. I agree that those in template space are a separate issue. (t · c) buidhe16:45, 26 April 2021 (UTC)[reply]
PMRs can also close RMs for more recent situations, though -- plenty of RMs are created after move wars. I've had the worst day I've had this year as a consequence of trying to find an admin to stop a constant barrage of talk page messages about an incomplete move, and just downgrading protections wouldn't have pre-empted that situation, whereas "simple move warring, PMR protect" would have. (For clarity, I made this VPR thread before things went pear-shaped.) Vaticidalprophet17:23, 26 April 2021 (UTC)[reply]
I agree that the bigger problem here is the abundance of over-protected pages. That's not exclusive to move protection, but also applies to edit protection and creation protection. Most of those cases date to the early years of the project, when the page-mover or extended-confirmed user rights did not yet exist, but there are still protections being applied that are unjustifiably strict or unreasonably long (see this case study of salting). This problem is only going to get worse over time, so sooner or later we'll need to start a project to systematically re-examine all indefinite full protections, starting from the oldest ones. – Uanfala (talk)20:37, 26 April 2021 (UTC)[reply]
I would support starting such a project. We need to check all full protected pages (both edit and move) in all namespaces. I spend a lot of time cleaning Special:LintErrors and regularly come across overprotected pages. A month ago I had to get full protection removed from around 1,400 pages in Wikipedia namespace alone. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 08:51, 27 April 2021 (UTC)[reply]
Oppose - even if we allow pagemovers to move sysop-move-protected pages, there's still a requirement to check with the protecting admin before editing through protection, so the change is functionally meaningless. Yes, there are probably a lot of pages protected at that level that don't need to be (I believe the ability to EC-move-protect only became available within the last two years) but the solution is as Uanfala proposes: a systematic review of all move-protected pages. Or, in reality, this is nowhere near as big a deal as it's being made out to be: if a protected page needs to be moved, there's a few hundred admins active at any time that can do it, so this can easily be addressed on a case-by-case basis. Ivanvector's squirrel (trees/nuts) 21:25, 26 April 2021 (UTC)[reply]
I would support replacing extended-confirmed-move-protection with pagemover-move-protection, but would oppose creating another new protection level. If a page needs to be protected below admin level then it makes much more sense for the editors already vetted and trusted for their experience in moving pages to have the ability (and one that can be revoked for abuse), rather than (as now) all users who pass an extremely low bar for the most basic participation. I can see no good reason why move protection needs to be more granular than those two levels. Ivanvector's squirrel (trees/nuts) 21:47, 26 April 2021 (UTC)[reply]
there's still a requirement to check with the protecting admin before editing through protection, so the change is functionally meaningless surely that's not true? If it were, all admins on WP:RM/TR would have to ping the protecting admin before completing the request (or only the protecting admin could process the request). ProcrastinatingReader (talk) 22:07, 26 April 2021 (UTC)[reply]
Not a written rule AFAIK, it would kind of be an Asshole John rule, but generally speaking any administrator about to modify another admin's action (like editing/moving through protection) is expected to consult with the protecting admin first, or in WP:IAR situations, notify the other admin of the action immediately after the fact. Modifying another admin's action without bothering to consult at all is a good way to be a jerk, and could be seen as wheel warring. If we're going to give non-admins the technical ability to modify admin actions in this way, then that privilege should come with the same expectations of accountability. I would think that if a page is protected it shouldn't qualify for a technical move, but again, IAR. Ivanvector's squirrel (trees/nuts) 14:41, 27 April 2021 (UTC)[reply]
Comment. I'd like to see page move protection and SALT protection default to extended confirmed, and only pick sysop if necessary. For example, if extended confirmed users are move warring. I think some folks in their minds usually set this to sysop without thinking much about it. I'd also like to see expiration dates, perhaps one year after the move war. –Novem Linguae (talk) 21:58, 26 April 2021 (UTC)[reply]
Xaosflux, to what degree is what Novem Linguae suggests possible? I've just checked elsewhere and I couldn't even restrict moving a file page to file movers. I could select all users (no protection), autoconfirmed, template editors+admins or admins. Nothing else. I also wonder if it's possible (if sysop move protections are still being placed today) to create an edit filter that warns an admin when trying to sysop move protect a page. — Alexis Jazz (talk or ping me) 22:27, 26 April 2021 (UTC)[reply]
@Alexis Jazz: The move protection defaults to "inherit from edit protection"; when no edit protection is set sysops have an extra click to enable it at all, then it defaults to "allow all" with a drop-down box, sysop is already the last of 5 options. The default protection setting is indefinite, with admins expected to follow the protection policy when deciding on what is appropriate. Does that answer your question? — xaosfluxTalk23:11, 26 April 2021 (UTC)[reply]
Xaosflux, the question was actually "can you apply page mover move protection?" You said you have 5 options. What are they? — Alexis Jazz (talk or ping me) 07:34, 27 April 2021 (UTC)[reply]
Isaacl, well I couldn't restrict it to bots, rollbackers or any other arbitrary group either. But I'm talking about another wiki with differences in configuration. I just wonder if it's even possible to restrict moving to page movers right now. — Alexis Jazz (talk or ping me) 22:49, 26 April 2021 (UTC)[reply]
@Alexis Jazz: mostly, we could remove the ability of move pages from sysops, and from all other groups except that group - but there is no way we are going to do that; besides all the sysops would just grant themselves pagemover to restore it unless we further locked that down. Why would you want to prevent sysops from being able to move a page anyway? — xaosfluxTalk23:14, 26 April 2021 (UTC)[reply]
Xaosflux, if you read the original proposal again, it actually doesn't really specify the technical execution. (maybe vague hints but it's not specific I think) One way to implement the proposal is to change every page that is currently under indef sysop move protection to indef(?) page mover move protection. If that's currently not possible we'd have to file a Phabricator ticket first. I'd be fine with leaving out Template:, Module: and high visibility pages (like Main Page) from that. The way I read the proposal it only applies to move-protected pages, not to pages that are also sysop edit protected. — Alexis Jazz (talk or ping me) 07:41, 27 April 2021 (UTC)[reply]
@Alexis Jazz: It would be possible and require several changes: (1) create another new protection level, (2) create a permission that allows editing of this new protection level, (3) assign this permission to groups (likely sysops, bots, page movers, staff, stewards, global interface editors); (4) update the protection policy to specify the rules around when the new protection level can be used (5) have an admin (possibly bot aided) review and adjust all existing sysop-only protected pages and lower their protection level to the new level when appropriate. Think that is about it - notably #5 will be time consuming - and could be done right now to reduce uneeded sysop-only move protections. — xaosfluxTalk10:05, 27 April 2021 (UTC)[reply]
Strong oppose this is basically another unbundling proposal and pointless. If something is admin protected, there's a reason for it and it would take no time at all to request a reduction in protection. Unbundling this also would make admin-move protect useless, so you'd be better off proposing removal of that protection entirely (which I'd also oppose) TAXIDICAE💰22:41, 26 April 2021 (UTC)[reply]
Oppose right problem, wrong solution. A radical proposal: all pages are automatically locked from non-pagemover moves and then all pages are un-move-protected. You simply can't move pages unless you're a page-mover. User:力 (power~enwiki, π, ν) 01:22, 27 April 2021 (UTC)[reply]
Moving pages (say, you've made a typo or realise you've used the wrong disambiguator, or you want to use userspace drafts) is such a basic part of editing that we'd have to give the right to almost everyone. (This is what we do now: autoconfirmed editors are the only ones allowed to move pages, while IPs and new editors are not allowed). —Kusma (t·c) 09:09, 27 April 2021 (UTC)[reply]
Obviously there would need to be a lot of fine print; moves within or out of one's own userspace are obviously fine, and you probably need something for typos in article creation. But I see a lot of risk in page-move vandalism, and very little harm to having new-ish editors use a "move" template (with Twinkle) rather than moving pages themselves. User:力 (power~enwiki, π, ν) 17:57, 27 April 2021 (UTC)[reply]
The idea of removing new users' unrestricted access to page creation was supported by more than two-thirds of over 500 editors who commented in 2011, and it still took the WMF more than seven years to act on the proposal, and then only as a time-limited trial. They then shut it off arbitrarily and refused to turn it back on without another discussion (which was numerically 207-26 in favour), and even after that multiple devs tried to subtly change the ticket so it wouldn't happen, or just openly refused to work on it. It took one of our functionaries acting as a project manager, several enwiki volunteers holding devs' feet to the fire, and intervention by WMF managers and a board member to get it to go forward at all. The idea of taking away another basic editing function from new editors and restricting it so heavily is, to put it mildly, unlikely to go anywhere. Ivanvector's squirrel (trees/nuts) 18:41, 27 April 2021 (UTC)[reply]
Do I need to check if there has been any stealth page-move vandalism in the past week? Or has somebody else (hopefully) already checked for that? More broadly: I remember when we didn't have an encyclopedia. Now we do have one. The tools needed to build an encyclopedia from scratch are different from the ones needed to edit one. User:力 (power~enwiki, π, ν) 03:40, 28 April 2021 (UTC)[reply]
Oppose I agree that this is not the right solution. Most pages do not need full, admin-only move protection, but that those that do need it, need it. The actual solution is a review of full-move-protected pages to weed out pages that do not need the absolute highest level of protection to prevent moves. Beeblebrox (talk) 21:02, 27 April 2021 (UTC)[reply]
Oppose but moral support. I agree with Kusma: make more page movers admins. In all seriousness, I have security and technical concerns. When a protected page is moved, the protection is duplicated. If we allow non-admins to move full-protected pages then suddenly page movers are able to full-protect redirects which creates a lot of potential problems, some similar to why the protect user right is required to edit through WP:CASCADE protection. — Wug·a·po·des06:47, 29 April 2021 (UTC)[reply]
Oppose I agree that this is not a good solution as well. An alternative has already been seen here, which is conducting a review of the ongoing move protections. Unbundling what normally are admin privileges shouldn't be done lightly. --pandakekok9 (talk) 07:51, 29 April 2021 (UTC)[reply]
People can't create a new article on English Wikipedia
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hi Wikipedia!
People can't create a new article on English Wikipedia. It doesn't appear the page that contains the link "Start the article wizard" but appears: The page x doesn't exist. You can create as a draft..."
We want to return the option for article wizard page or if not, the drafts created to have an option "Submit the draft for a review" in order to review the draft and move or not on the main articles, which this option doesn't exist on created drafts.
Once your account has been autoconfirmed (four days old and 10 mainspace edits) you can create pages in the main space. This minor throttling feature is in place to head off unregistered (IP address) and newly registered accounts from abusing the ability to create articles, which can be a cleanup nightmare. Once your account has been autoconfirmed, you can create all the articles you want; the article wizard is an optional process, as is the "Draft and review" process. Newer users (and even autoconfirmed ones) are steered through the draft-and-review process as a means to discourage the creation of a new article that is likely to be quickly deleted, often without explanation. However, once you are autoconfirmed, there is no technical barrier to creating new articles. I would recommend you don't until you learn a little bit about what makes a worthwhile Wikipedia article (see WP:42 and WP:YFA for a short, and long, version of that), but once you reach that 10 edits/4 days threshold, you'll be fine. --Jayron3214:45, 27 April 2021 (UTC)[reply]
@NSHPUZA: Access to the article wizard should be available on any red linked page you are trying to create. For example, click here: Red link demo for NSHPUZA, and at the top of the page (Source Editor) or in the popup notice window (Visual Editor and 2017 Wikitext Editor/New wikitext mode), you should see this message in bold that sends you to the Article Wizard:
I just checked NSHPUZA's contributions, and this post was tagged "(Tags: Mobile edit, Mobile web edit)". I tested a red link on my phone (in Mobile View), and it does not provide the same access to the article wizard. Perhaps that is the request? I have no idea how easy it would be to try and create an article from the wizard in mobile view, but that may be the root of the question. -2pou (talk) 17:19, 27 April 2021 (UTC)[reply]
@Xaosflux: Thanks. It looks like the problem was that I was logged in while trying it out. While logged in, it displays the notice window for a split second before going to a text field to edit and no way to exit/view the window. While logged out, as an IP (or presumably non auto-confirmed editor), you're right, the option is presented because in that case, I'm not allowed to directly create in main space. So, NSHPUZA, if not auto-confirmed, the message actually reads this to get to the wizard:
You cannot create this article. You may need to log in or create an account and be autoconfirmed to start this page. Alternatively, you can use the Article Wizard, or add a request for it.
Mobile-phone editors also get new IPs on each new session, so if you edit from the mobile, your ability to autoconfirm gets harder. Create an account to overcome that issue. GenQuest"scribble"18:49, 27 April 2021 (UTC)[reply]
@NSHPUZA: please see everything above. Article Wizard should be available for new article creation still; if you are not seeing this please post over at WP:VPT for technical support, including the exact steps you are following. Thank you, — xaosfluxTalk13:03, 29 April 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Nowrap for scoring within sporting articles
Hi! I've never actually suggested anything here, so excuse me if this isn't quite right, or if this needs to go through a second channel to get some thoughts before the actual proposal can begin. At a recent FAC, it was questioned if sporting scores (or at least the ones on this article), should be enclosed with NOWRAP. I'm not sure if there is a minor part of the MOS that I'm missing, but I didn't see it. I've done a little bit of digging, but didn't find any prior conversations about this. Here's the question:
300—267 has em dash. It should be 300–267 with en dash, but it appears to make no difference for wrapping. Wrapping is browser dependent. Change window width to see where text wraps when there is no nowrap.
On Windows 10 with current browser versions: Firefox never wraps above. Internet Explorer, Google Chrome, Microsoft Edge and Opera always wrap. PrimeHunter (talk) 13:29, 30 April 2021 (UTC)[reply]
Sorry, I mistyped! I am specifically talking about scores such as 10–5, which is what the MOS currently fits, it's not so much as if it currently nowraps, more should we require scores to be wrapped, so they display on the same line for all browsers? Best Wishes, Lee Vilenski(talk • contribs)13:36, 30 April 2021 (UTC)[reply]
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)[reply]
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)[reply]
This article is written in American English, and this should not be changed without consensus. Learn more.
. EEng 03:26, 3 April 2021 (UTC) P.S. Someone's calendar is off. This came a day late for April Fools.
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)
Moved from Wikipedia:Village pump (policy)23:08, 2 May 2021 (UTC)
Facepalm thanks for the reminder that the english wikipedia is not the only project that uses these tools (and that I am susceptible to enwikicentrism). The issue with policy centered is our policies don't readily address this. So it seems like this will need to be rethought not in terms of removing the option but perhaps just (a) determining whether we want the bot to add all archives; if not then (b) developing our own rules for it and, if applicable, (c) adding an advisory when the option is selected saying (using general wording about it not being allowed on all projects or pointing to some documentation somewhere). How does that sound? — Rhododendrites talk \\ 14:28, 24 April 2021 (UTC)
