This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Make page movers eligible to move move-protected pages
Latest comment: 3 years ago67 comments31 people in discussion
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
@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)
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)
@Xaosflux: how would page-movers be able to move template-protected or fully-protected pages? They still need to be able to edit them to move them, which they would be unable to. I think you might be misunderstanding the proposal scope here. Elli (talk | contribs) 23:49, 26 April 2021 (UTC)
@Elli: well part of the problem is that the proposal is quite poorly presented. There is no definition to make page movers eligible to move move-protected pages - for example they already CAN do this, provided the move-protection is a level they can move; it appears to be suggesting that some new technology is invented to allow this group to have a new permission that allows moving a page regardless of its protection level. — xaosfluxTalk00:00, 27 April 2021 (UTC)
@Xaosflux: I'm pretty sure the proposal is to just make move-protection not apply to page movers entirely - any other editing protection would still apply. I don't see how this is really that hard to implement technologically. Elli (talk | contribs) 00:24, 27 April 2021 (UTC)
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)
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)
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)
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)
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)
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)
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),[1] 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)
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)
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)
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)
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)
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)
@Buidhe: I'd support a review and likely mass reduction of ns:0 pages that are only indef admin-move protected, where the protection is very old. — xaosfluxTalk16:50, 26 April 2021 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
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)
@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)
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)
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)
@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)
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)
@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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
Generally oppose any proposal to transfer trust-requiring sysop-only permissions to existing non-sysop groups, as this will either decrease the amount of trust practically required to perform the sensitive action, or increase the amount of trust required to obtain a previously-useful low-trust permission. This either results in a higher risk of damage in sysop-restricted areas, or in a lower amount of group members that would use the group to perform the original tasks. ~ ToBeFree (talk) 19:01, 4 May 2021 (UTC)
Different color for featured articles?
Latest comment: 3 years ago3 comments3 people in discussion
What if we had different colored links for featured articles. For non-existent articles, we have red, but I think having different colored links to highlight colored articles would make it quicker to find a featured article related to another topic. Terminator21738 (talk) 20:36, 4 May 2021 (UTC)
You might be interested in User:Anomie/linkclassifier.js and User:Anomie/linkclassifier.css, which change the default colour of wikilinks depending on the target page, and can be customized to some extent although I've never bothered to change the default settings. Also, in your preferences under Gadgets -> Appearance, you can enable "Display an assessment of an article's quality in its page header" which changes the colour of the page's title depending on its assessment. Ivanvector's squirrel (trees/nuts) 23:12, 4 May 2021 (UTC)
Is there a color you have in mind? Per the (routinely ignored) instructions at the top of this page, it is supposed to be for concrete proposals. {{u|Sdkb}}talk23:35, 4 May 2021 (UTC)
Convert all English variant notices to editnotices
Latest comment: 3 years ago113 comments58 people in discussion
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)
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)
Support there's a dual benefit as it simultaneously improves both the talk page (by reducing clutter) and the edit screen (by displaying relevant info), a win-win. --Paul ❬talk❭ 16:55, 10 January 2021 (UTC)
Oppose The proposal seems half-baked because it doesn't address the use of templates like {{Use British English}} which are what I see most often. For talk pages, we could use something like an infobox which would contain key pieces of information about the article such as its size and quality rating. The dialect would fit best in such a summary of the article's properties. Andrew🐉(talk) 17:26, 10 January 2021 (UTC)
Regarding the "use" templates, this wouldn't affect them one way or another; they'll continue being available for when it's desirable to designate a variant but there's not enough erroneous editing for there to be a need for a notice. We could discuss down the line how often to have something visible vs. invisible, but for now I think getting all the visible notices into editnotice format is the best first step.
Regarding your idea for a hypothetical talk page infobox, I'd suggest proposing that at the broader idea lab discussion. I could support it if it's implemented well, but it's beyond the scope of the more narrow change I'm trying to achieve here. {{u|Sdkb}}talk19:12, 10 January 2021 (UTC)
Excellent idea. I suspect if editnotices had existed when these templates started this problem would not have arisen. ϢereSpielChequers18:50, 10 January 2021 (UTC)
Strong support if implemented, this would be huge for reducing talk page clutter, and actually making the english variety notices effective. As I said at the idea lab, the people who are disregarding or ignoring an established English variety aren't going to be on the talk page and see it there. As such, I'm convinced that the current position on the talk page is basically worthless. Aza24 (talk) 21:03, 10 January 2021 (UTC)
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)
Support for all of this genre of notices (engvar, date formats etc.), but -- perhaps heretically -- I would support all top-of-the-page cleanup notices going into editnotices as well, so people who just want to consult an article for information aren't bothered with them. Beyond My Ken (talk) 03:17, 11 January 2021 (UTC)
Beyond My Ken, by top-of-the-page cleanup notices are you referring to things like {{NPOV}} or {{Original research}}? I think those notices are pretty necessary from a reader perspective, since readers deserve to know when an article has significant problems so that they can read it with due caution and skepticism (yes, people should always be doing that, but they trust us enough they de facto often don't). That's more true for some notices than others, though; I could see a case for many of the yellow style ones like {{Cleanup bare URLs}} to be converted to be shown to editors only. The question at that point becomes whether we're wasting an opportunity to convert readers to editors by offering them an easy task. All this is tangential to the current discussion, so maybe take it elsewhere if you want to develop it further, but I hope my comment is food for thought. {{u|Sdkb}}talk11:05, 11 January 2021 (UTC)
I would argue that a fair number of the yellow banners are useful to readers (eg Template:Overcoloured letting colourblind users know that they may not interpret something on the page correctly, or Template:Essay-like). Further, as I've been editing even the ones which non-editor readers may not find useful now inform how I read. For example, seeing Template:Debate wouldn't have changed how I read something in the past, but now it suggests to me that people may have POV forked, there may not be great usage of reviews/meta-analyses (in the case of scientific articles), or its editing may have been a series of unconnected additions. They're also useful for the purpose of editing - I will detour from doing other tasks to correct an article if I notice some kinds of banners, including when I wasn't intending to edit it. --Xurizuri (talk) 10:55, 12 January 2021 (UTC)
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)
Having read through some comments below I have come to change my mind. As pointed out below this is likely to result in a large amount of editnotices that is likely to frustrate and deter editors. Tom (LT) (talk) 10:56, 6 April 2021 (UTC)
Support not useful on talk pages, useful when editing which shows on editnotice. No need for new permission, nor should editing editnotices be available to all, PMR & TPE can do this. If the TPER queue becomes too long, we can get a bot with TPE to carry over additions from the talk page into the editnotice. ProcrastinatingReader (talk) 09:21, 11 January 2021 (UTC)
Striking in favour of using hidden templates such as {{Use British English}} on the article prose, as said by Whatamidoing, and removing all the editnotices and talk page banners and converting them into hidden templates such as {{Use British English}}. Alternatively, a {{article standards}} template, as described in the thread by Levivich. Arguments by Levivich & L235 are compelling imo. ProcrastinatingReader (talk) 15:15, 5 February 2021 (UTC)
Support – 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)
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)
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)
Support. It'd be more useful as an edit notice - I know I never check first, and it's a pain to have to open the talk page in a new tab (especially as I have ADHD and sometimes forget the variant as soon as I close said tab). Ideally, similar notices about the style of writing in a given article would also be great to have as edit notices. However, a concern would be that by reducing talk page clutter, we need to not just relocate the clutter (sweeping it under the carpet, so to speak). --Xurizuri (talk) 10:55, 12 January 2021 (UTC)
Support, but what about protected pages? There might be an increase of (incorrect) ENVAR edit request, I guess you would also add a en-varent message on the talk page too? (please ping) DarthFlappy18:53, 12 January 2021 (UTC)
@DarthFlappy: I would expect that the vast majority of edit requests come from people trying to edit a protected page (that they don't meet the requirements of), clicking the button to request an edit and filling in the form. You might have noticed many are blank—this is because people don't read what's on their screen and just click the big blue "Submit" (maybe thinking that they're requesting permission for them to be given edit access). But anyway, I wouldn't think the talk page banner would really make a difference on edit request content. — Bilorv (talk) 23:49, 14 January 2021 (UTC)
Support but not at scale, and only as a pilot. As I understand this could affect millions of articles, so please try it first as a pilot for 100s of articles. Big changes like this are best done with test cases, time passing, multiple requests for comment, and documentation. This already has my general support and also I anticipate supporting again in the future, but the proposal as it is has no limits. The scale and pace of the changes matters to me. I am only expecting volunteer-level documentation and not the best and most complete, and I encourage the pilot. I recognize the existence of the problem and feel that it will only grow. There are various possible solutions, and perhaps we have to use several solutions at once to address this issue. Please develop this one solution first. Blue Rasberry (talk)20:51, 12 January 2021 (UTC)
Oppose — 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)
This is a fair point. I was thinking the notice should be trimmed down, literally into a bullet point like: “* This article uses British English.”. Alternatively, we can have a single “Article conventions” talk page template which is highly trimmed down and signifies standards like the variety of English used — this assumes that there are other types of standards other than English and date variety that could possibly apply. A bit like {{article standards|lang=British|dates=dmy}}. ProcrastinatingReader (talk) 09:16, 13 January 2021 (UTC)
An article conventions template sounds like a very good idea. There are probably others besides engvar and usedmy, but those two are good examples. I would find iconography to be the most efficient way of communicating these sorts of things, but I'm not sure if everyone would be on board for that. So like a little British flag somewhere if it was use BrEng, a US flag for AmEng, something like that. Levivichharass/hound17:27, 13 January 2021 (UTC)
I agree that the notices should be kept unobtrusive and concise. Regarding the "just remove them entirely" point, we already have the e.g. {{Use British English}} family of templates, which set the standard without displaying anything, just as you describe. I'm undecided about whether/when we should use that compared to {{British English}}, but I think that, in circumstances where it is important enough to warrant a banner, that banner should be proximate to the place it actually applies, which means putting it in the edit notice next to the article rather than the talk banners next to the talk. {{u|Sdkb}}talk00:06, 14 January 2021 (UTC)
Support: seems like a no-brainer. Banner blindness on a talk page is already a massive issue, and ENGVAR isn't relevant to reading the talk page, it's relevant to editing the page, so it should be where it's relevant. Sceptre (talk) 23:33, 14 January 2021 (UTC)
Oppose: it's absolutely a reasonable proposal, but I'd prefer removal of these banners from the talk page instead. I just don't buy that language variant is important enough to warrant this kind of attention, and instead it will just cause reader blindness wherever it appears. I understand that it's very frustrating to be reverting the same good-faith spelling changes over and over again (I've lost count of the number of times I've had to revert "installment" back to "instalment" on the BritEng Black Mirror series of articles), but I've found that most unregistered editors will not see an editnotice, a wikicode template or a hidden comment in the middle of a word that keeps being changed (I don't know why the last doesn't work, but it doesn't), or possibly just willfully ignore them all. So I believe that this proposal, though it seems like the common sense logical position to move the template to, would just create blindness and have little-to-no effect on averting editing redundancies. — Bilorv (talk) 23:40, 14 January 2021 (UTC)
@Bilorv: Your point about having to correct the same word over and over gives me a thought: what if we had an edit filter so that e.g. anyone trying to introduce "installment" to an article tagged with British English would get a big caution notice when they try to publish? {{u|Sdkb}}talk01:58, 15 January 2021 (UTC)
I think it is unreasonable for new/IP users to have no way of knowing this info before editing. Yes, they most likely won't read the notice, but "there's a notice that you ignored" is much better than "there's a policy hidden in our arcane (to new users) WP namespace that you don't even know about". And given that the varieties of English are largely identical, it's sometimes difficult to tell what variant the article is in; the notice is a nice reminder. - NovovTC07:57, 15 January 2021 (UTC)
To Sdkb, that's possibly something I could support, but I really don't like edit filters targeted at newbies because it's one more barrier to entry. If there was a way to say "literally the only changes in this edit are a bad spelling changes" then that would be ideal. I know that's asking a lot. To Mir Novov, many good faith edits I see by new/IP users that I have to revert are something I couldn't reasonably expect them to understand. There's been a discussion on the talk page? The lead doesn't mention this because of due weight? This source is unreliable even though it's a newspaper one million people read per day? It's wrong to call a section "Controversy" even though you've seen 1000 other articles with that bad heading? If anything it seems to me that "this article uses Australian English because it's about an Australian show" is so much easier to explain than most common mistakes made. — Bilorv (talk) 09:37, 15 January 2021 (UTC)
Bilorv, in my idealized 2030 version of Wikipedia, the way that filter would work is that someone would go in and try to make a bad switch to another variant within an otherwise fine edit, and when they click publish, a notice would pop up saying "Hey, you switched 'instalment' to 'installment', which appears to go against the British English used for this article. Would you like to (a) publish, but keep British English? [works in one click], or (b) publish anyways?"
Even with that, though, I agree with Novov that, for pages where switches are common (which is the group we're discussing here), it's better not to make someone do all the work before giving them the alert. And it's not just newcomers—I didn't know that "installment" was one of the words that differed until you mentioned it above, so I could easily see myself making that error. Whereas if there's an editnotice that (again, thinking futuristically) automatically detects that "instalment" is used a lot on that page and therefore includes it in the examples, that'll let me know not to touch anything. {{u|Sdkb}}talk13:05, 15 January 2021 (UTC)
Support - This information is most useful for actually editing pages, not discussions. Logically, it should belong there, and such a relocation would be useful to the IP editors that have "corrected" spelling . Yes, some other info is on the talk page that should be read, but a lot of people don't read that, and wishful thinking won't make that fact go away. - NovovTC07:57, 15 January 2021 (UTC)
Oppose per Neutrality. Personally, I dislike edit notices and more edit notices that would intrude on the editing interface is something that I would not want. Perhaps something similar to the Template:Use mdy dates template would be better. A whole host of edit notices on the national varities of English (sometimes where editnotices are already in place) would be worse than talk page banner blindness for content creators hoow would have to scroll past the edit notice every time they edit. Plus, the national varities of English really isn't that important and as such, this is why we should keep them on talk pages. P,TO 19104 (talk) (contribs) 23:08, 15 January 2021 (UTC)
Oppose. Varieties of English are not important enough to warrant placement as an editnotice. Just try and notice what variety the article is using and emulate that; if you get it wrong, someone will help you fix it. In my view, the talk page banner exists only to attempt to avert edit wars over this stuff, with one side being able to point to the banner. The rest of the time it's not useful, whether on the talk page or as an editnotice. KevinL (aka L235·t·c) 20:07, 18 January 2021 (UTC)
Further to this, there are some truly important editnotices (e.g. DS notices that create blockable offenses), and the more editnotices we add the more banner blindness we get. Talk page notices are already ignored; let's not consign editnotices to the same fate. KevinL (aka L235·t·c) 20:09, 18 January 2021 (UTC)
Whilst I see your argument, to be fair, the editnotice format already exists right now and is placed arbitrarily; admins/TE/PMRs will place it themselves or on request for other editors, also in line with the current documentation for these templates. The pages that only have a talk notice are usually arbitrary. ProcrastinatingReader (talk) 20:12, 18 January 2021 (UTC)
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)
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)
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)
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)
Oppose having more edit notices. In the visual editor and the 2017 wikitext editor, you have to click to get past the edit notices every single time you open that page to edit. Also, just as Ivanvector's squirrel says, you stop reading them when they're common. WT:MED has an edit notice that I've clicked past most days for the last several years, and I no longer know what it says. When we need to have notes about the language variant to use, please make them all "invisible" templates that carry the necessary information in the title, such as {{Use British English}}. WhatamIdoing (talk) 19:58, 22 January 2021 (UTC)
Support. As many others have said, very few editors will actually notice talk page banners, especially IPs and newbies. And failure to heed ENGVAR instructions has often led to disruptive, pointless edit wars. Of course, we need to be mindful of not accumulating so many edit notices that people will stop paying attention, but that's a separate discussion of how to condense the edit notices. ChromaNebula(talk)23:20, 26 January 2021 (UTC)
Support: Even if people ignore the notice, it won't be worse than it is now. This is a great way to stop people from changing between English varieties unnecessarily. And, also, since more people are seeing the fact that "you can tag articles for types of English?", there'll be more people tagging, which, in turn, leads to more standardisation and organization. Opal|zukor(discuss)22:10, 29 January 2021 (UTC)
Support, ideally with the notice stripped down to its bare essentials. Perhaps just 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)
Strongly oppose.: Instead, eliminate the editnotice versions. We do not need to browbeat editors, especially new ones, about style trivia every single time they edit the page. If someone gets it wrong, some gnome will fix it later, as with all other style quibbles. MoS is a guideline, not a policy, for a reason. No editor is required to follow it when adding new content; they're not permitted to disruptively and stubbornly change material to be noncompliant after they've been asked to stop doing it. Trying to effectively make following an MoS line-item mandatory to edit the page at all is an end-run around WP:EDITING policy, is WP:BITEy, is WP:CREEP of the highest order, and is also an end-run around nearly two decades of consensus that no style matters aside from some key points about article titling rise to policy level. While we're at it, also just get rid of the talk page banners for this. The "silent" templates like {{Use British English}} at the top of the actual article is entirely sufficient. — SMcCandlish☏¢ 😼 18:01, 13 February 2021 (UTC)
Weak support, this is one option to reduce current clutter. These templates already exist as edit-notices, so whether or not they should be needs to be a different discussion. Either way, as a talkpage tag or edit notice, they should be sharply reduced in prominence/space in line with similar comments above, first of all by removing flags/other images per the spirit of WP:FLAGCRUFT. Frankly these notices could be reduced to two words (eg. "British English", "American English") left somewhere consistent on the talkpage/edit notice. CMD (talk) 17:46, 14 February 2021 (UTC)
Oppose clutters the editnotice space with hundreds of thousands of pointless editnotices, while making sure editnotices need to be even flashier for users to read them. Ideally, we'd have a standardized location in the editor displaying the English variety - and editnotices are a hacky - and bad - way to somewhat emulate this. Elliot321 (talk | contribs) 01:45, 28 February 2021 (UTC)
Elliot321, a standardized location in the editor is an interesting thought. Where would you envision it going? Are there any phab tickets seeing if the WMF could look into adding something? {{u|Sdkb}}talk07:08, 3 March 2021 (UTC)
Elliot321, that looks pretty good to me! Hovering over the word "British" could perhaps provide a tooltip with word examples (ideally tailored to the actual words used on the page). If you go forward and turn the mockup into a more formal proposal, I'd support. My read of this discussion is that there's definitely desire to make the language tag less prominent but just disagreement about how to do it, so I think your solution might have strong support if it can be implemented. {{u|Sdkb}}talk07:39, 3 March 2021 (UTC)
Support Most users don't bother to look at the talk page unless they want to post a discussion there. A new user might not even know that talk pages are there! This is a very useful proposal. 🐔ChicdatBawk to me!11:22, 5 March 2021 (UTC)
Opppose. I support aggressively cutting talk page clutter, but this notice to an even-more-visible edit notice does not accurately reflect its importance (it's a MoS issue, and I concur with SMcCandlish that we should not bludgeon editors about it, like an edit notice would do). — Goszei (talk) 16:37, 8 March 2021 (UTC)
I have long thought that the Variant notice should go on the Article page, and not the Talk Page. Just a simple one line hat note saying something like “This article uses UK spelling and grammar” at the top of the page would be enough. Blueboar (talk) 16:50, 8 March 2021 (UTC)
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)
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)
Shifting banners from talk to the edit notice helps talk but makes it even more unlikely that people will read the edit notice. I would want to see a draft of exactly how this proposal would be implemented (create a million new edit notices? create one central edit notice with magic code to show the language variety?), and exactly how it would appear. Try editing Donald Trump to see what an edit notice can look like. Johnuniq (talk) 22:59, 10 January 2021 (UTC)
You're emphasis of how big of a change this will be is certainly valid, though I don't know if I agree that moving to an edit notice makes it even more unlikely that people will read the edit notice – even just the flag of the UK or US in the edit notice would do more than right now. The only alternative I can see to the current situation or the proposed solution above is to completely remove the english variety, which is a more or less impossible scenario. Aza24 (talk) 00:10, 11 January 2021 (UTC)
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)
Many old time editors, most newer editors, and virtually all IPs never make it a habit to look at the talk page before editing an article page. English version notices on the talk page are worthless. GenQuest"scribble"23:30, 10 January 2021 (UTC)
Completely agreed, and this proposal should address that appropriately I believe. The current placement of English variety templates are virtually invisible to the intended audience. Aza24 (talk) 00:10, 11 January 2021 (UTC)
As a newer editor, I have never intentionally checked before editing so that's at least some anecdotal evidence for your point. However, I'm not sure if this is a function of the notice on the talk page, but on the visual editor on some articles there's a little prompt right under the title (eg Education in Australia). I'm a big fan of those little prompts. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)
The need for an administrator to intervene will force an non-administrator-editor who notices a a change to the English variety is clearly warranted to spend two edit sessions on the page. The first session would be to place a protected edit request. The second would be to actually change the variety. Jc3s5h (talk) 01:02, 11 January 2021 (UTC)
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)
I would agree with this. Requiring two edits isn't unreasonable for something that defines how the entire article is written. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)
I expect that the opposers on the basis of "we shouldn't have them in the first place" will actually do something about that and propose that we remove them all together (were this proposal not to pass) . Otherwise, you're wasting everyone's time. Aza24 (talk) 06:08, 13 January 2021 (UTC)
Opposing a change from the second-best solution (talk page banners) to the third-best solution (edit notices) is not a waste of time, even if one doesn't propose the best solution (no banners). Making a proposal that doesn't have a reasonable chance of success is a waste of time. Oftentimes, "second-best" is status quo because it's the compromise. Levivichharass/hound06:16, 13 January 2021 (UTC)
You are mistaken if you believe this discussion cannot generate the consensus to remove these from talk pages without replacement. RFCs are not votes.
Secondly, we are not wasting time regardless. We should prefer the best solution, however we get to it. It is a logical fallacy to argue that we also must do things consistent with our position, especially as this is a volunteer mission. (I have no problem being called a hypocrite if you like. :)
Thirdly, this is maybe the least concerning thing on the wiki today. We don't need the polarism on your part. --Izno (talk) 22:09, 13 January 2021 (UTC)
Izno, literally no where did I say anything like this discussion cannot generate the consensus to remove these from talk pages without replacement, and I certainly wasn't intentionally trying to generate "polarism"; the misrepresentations are not appreciated. I think I was pretty clear about what would be "wasting time" – a situation where people who oppose on the basis of "we shouldn't have them in the first place", the proposal fails, yet these opposers don't start some proposal to remove English variety banners. Because in a situation where a problem is brought up, consequently unresolved by the introduction of a bigger problem and neither end up being addressed is a waste of time. Aza24 (talk) 22:39, 13 January 2021 (UTC)
Obviously, the best solution would be a bot that automatically (and quietly) corrected spelling and usage to whatever variant was designated (assuming that a variant has been designated)... with an edit summary explaining what was done and why. Then editors could simply write, and not worry about whether they were writing in the designated variant. Blueboar (talk) 14:00, 15 January 2021 (UTC)
@Blueboar: editors that are writing any new content shouldn't be overly concerned with this already - it is really about avoiding refactoring the existing text over and over again. — xaosfluxTalk11:45, 16 January 2021 (UTC)
@Xaosflux: Is there evidence that such refactoring has been a significant problem thus far? Because if not then I think that Blueboar's suggestion is correct. Nsk92 (talk) 00:31, 4 April 2021 (UTC)
At the very least, the banners should be reduced and have the flags or other images removed. English varieties don't always neatly follow political boundaries, and at any rate we have WP:FLAGCRUFT for such situations in articles and yet flags are spammed across talk pages. Removing them also helps reduce space and prominence for a template that is probably mostly seen when explicitly being looked for. CMD (talk) 16:47, 17 January 2021 (UTC)
I agree that the banners should be trimmed down, but I think the flags are actually quite helpful as a visual shorthand, so they're an element I think we should keep. {{u|Sdkb}}talk21:15, 14 February 2021 (UTC)
My main concern here is that editnotices only can be edited by page movers, template editors and admins. I get that a bot can do the initial move but how will we go about additions of these in the future? I don't mind if the consequence is that these notices become rarer, but in that case it should be a deliberate choice and not just an oversight. I also don't think it's a good use of time to significantly increase the number of trivial WP:TPERs with changes to engvar notices. --Trialpears (talk) 21:46, 11 February 2021 (UTC)
Trialpears, as I mentioned a bit in my !vote, I see this as an underlying problem—there are lots of situations in which anyone autoconfirmed ought to be able to edit a page's editnotice but can't (not because of any editorial consensus, but just because of something about the back-end technical structure of editnotices). That's a problem that we should solve (and if this goes through, it might nudge us toward doing so), but I don't think we should handicap ourselves here and reject this because of it. To do that would both obscure the level of need to resolve the issue and give ourselves more work down the road once it is resolved. {{u|Sdkb}}talk00:12, 13 February 2021 (UTC)
I feel like that would in general be a good idea, but I still see some reasons for the protection. Vandalism at editnotices would likely not be detected most of the time and even if it was detected most editors would probably not be familiar how to solve it. Putting misinformation in them could be significantly worse. I would definitely support enabling it for extended confirmed users though. With regards to implementation the restriction is governed by MediaWiki:Titleblacklist which can easily switch it to requiring autoconfirmed. It should also be possible to use a editfilter instead which could implement an extended confirmed restriction instead. --Trialpears (talk) 21:26, 16 February 2021 (UTC)
Sdkb I don't see an issue with keeping editnotices to people who can override the blacklist - needing to edit editnotices is quite niche and they should, in most cases, be using templates which are not on the blacklist and thus can be edited.
I personally feel that to reduce possible banner clutter and the talk page clutter, it should be only visible in the edit source for an article but in perhaps a different more vibrant color so it will be easy to notice and can inform editors without causing any/much clutter. Discount Horde (talk) 18:18, 22 April 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Making Ds/alert notices less scary for newbies
Latest comment: 3 years ago1 comment1 person in discussion
I think the new user landing page should have a link to search results for whatever page name they typed, just like the regular landing page. A new user is less likely to be qualified to create a page than a regular user, yet the current system makes them less likely to see the other alternative (that a page exists for what they're looking for under a different name). —Lights and freedom (talk ~ contribs) 01:03, 5 May 2021 (UTC)
That page is actually Template:No article text. Feel free to make edit requests for it. It's indeed possible for the template to distinguish new users using the CSS classes for user groups. – SD0001 (talk) 08:16, 5 May 2021 (UTC)
Okay, Lights, thanks. I just went to https://en.wikipedia.org/wiki/Farfle in this browser (signed in) and in another, anonymously. The only difference I detect is the "Start the Farfle article..." vs "You cannot create this article", owing to the fact that I am autoconfirmed here. But they both have "Search for "Farfle" in existing articles", and I don't agree (or don't see) that they are less likely to see that a page exists for what they're looking for under a different name. I mean, I guess, that I don't see what you're proposing. Both "landing pages" already have a link to search results for whatever page name they typed, which is what you seemed to be asking for. — JohnFromPinckney (talk)12:32, 5 May 2021 (UTC)
Had a min - still falling down the rabbit hole ... mw:Extension:ArticleCreationWorkflow references $wgArticleCreationLandingPage. (What we need to dig for is how/if the original search page is preserved - because if it isn't something being passed in to manipulate we can't just add a search text link for it and this may need to go to the extension developers). — xaosfluxTalk14:34, 6 May 2021 (UTC)
@Lights and freedom: from the task I linked to above, this does not appear to be technically possible today, unless we remove the new user landing page all together. So where to go from here? (1) Follow up on the technical improvements in phab:T204234; (2) Remove the new user article workflow extension; (3) make some improvements to Wikipedia:New_user_landing_page that don't have this functionality. For 3, you can suggest edits at Wikipedia talk:New_user_landing_page. Based on this information, can you refine what you are proposing at this time (or we can revisit this if/after (1) ever gets completed). — xaosfluxTalk11:36, 7 May 2021 (UTC)
I can't do any of this stuff. From what I've seen, everytime something in "Phabricator" is mentioned, it's been waiting for years. So somebody will have to deal with it. —Lights and freedom (talk ~ contribs) 17:40, 7 May 2021 (UTC)
OK, well if anyone else wants anything done on this before this archives, those are the routes available. — xaosfluxTalk10:26, 8 May 2021 (UTC)
Requesting outside feedback on wikiproject mergers
Latest comment: 3 years ago1 comment1 person in discussion
I believe this is likely the one and only place I can bring up wikiproject mergers for outside feedback. It is being proposed that WP:METEOROLOGY, WP:WPTC, and WP:SEVERE be merged into WP:WEATHER. I would like to give a rundown of what has been done thus far and what is being proposed exactly. In the case of Meterology, the project is quite inactive and the articles need to be sorted out into different topics/taskforces so we can see where everything stands. Some articles were already moved over to taskforces in Weather before the WPTC and WP severe mergers were disputed. Weather is supposed to supersede the meteorology project directly. WP:CLIMATE was entirely defunct, not even having a talkpage template to sort normal climate articles underneath it. This project was moved over to Wikipedia:WikiProject Weather/Climate task force and had nearly 200 articles sorted into it. The flood, droughts & wildfires, and met instruments were moved out of WP Met and over to WP Weather, becoming official taskforces. All have since had articles added to them. WP:NTROP was a project that was defunct for quite a while and was barely on life support. I migrated it over to a taskforce given the support from its members, moving all of its subpages over to allow it to function as a subproject/task force underneath WP:WEATHER.
That being said, the coverage of floods, droughts & wildfires, non-tropical systems, and weather outside the United States is in bad shape. It is being proposed that we have one, united weather project. While WPTC and WP:SEVERE are active and doing pretty well, the rest of the weather has unfortunately suffered from years of neglect. It is being proposed that WPTC and WP:SEVERE be merged over into WP:WEATHER (with all subpages moved over) and operate as subprojects/task forces of WP:WEATHER. The goal here is not to drastically change how these projects currently operate. The biggest changes would be talkpage templates would switch over to WP:WEATHER and the titles of project pages would become task force pages. Having one project would allow for shared resources, such as more reviewers, as well as a standardized assessment of articles across the topic of weather. Hopefully, this would also make cooperation easier as everything would be under one roof. There is a lot of overlap between weather topics, such as tropical cyclones spawning tornadoes (severe weather), becoming extratropical cyclones (non-tropical), ending droughts, causing floods, and starting wildfires via lightning or winds. Topics that have been neglected may see more help with them as there would be increased awareness since everything is no longer partitioned off into separate projects. Tornado and tropical cyclone articles seem to be the main focus for weather on WP at this point, but we need to address the problem of lacking coverage outside these areas. Smaller projects are difficult to maintain and I believe it to be in the best interest of everything else that WPTC and WP:SEVERE be merged into WP:WEATHER. Please feel free to participate in the merge discussion here. NoahTalk23:51, 9 May 2021 (UTC)
Authority control
Latest comment: 3 years ago102 comments31 people in discussion
{{Authority control}} is a template with 1.86 million transclusions. It is generally added to articles at scale and indiscriminately (eg) and visually looks like a bunch of weird words lobbed together, often irrelevant to the article (eg, with links like this). There was a recent RfC here about visual improvements, with a sub-section discussing the value of the template at all, and rough support for scrapping it. The close suggested a follow-up discussion about this. I do not think this template meets the WP:NOTLINK policy or the Wikipedia:External links guideline: it is not Wikipedia's purpose to include a lengthy or comprehensive list of external links related to each topic. No page should be linked from a Wikipedia article unless its inclusion is justifiable according to this guideline and common sense. The burden of providing this justification is on the person who wants to include an external link. I don't see why this template exists in the first place, much less why it's mass-added to articles? It just seems like clutter for our readers and surely adding dozens of disparate, usually useless, external links cannot be said to comply with policy. ProcrastinatingReader (talk) 11:49, 4 May 2021 (UTC)
You claim the links provdied by {{Authority control}} are "useless". They - and more importantly the information presented by the template in its current form - are not. The rest of your diatribe is thus of no merit. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits12:36, 4 May 2021 (UTC)
I guess it's subjective whether they're "useless". Yes, in my opinion stuff like this is useless for 99.9% of readers and 99.9% of articles. But objectively, adding ~10-30 external links per article, usually to random links with machine-like data values, cannot possibly meet the requirements of WP:NOTLINK or WP:EL. I also do not understand how editors could be exercising "judgement and common sense" on the appropriateness of each link on a given article, when this template is being added at rates of dozens per minute (without bot approval; likely a violation of WP:BOTPOL). Apparently we used to have an actual bot approved for this purpose, on the basis of a rather dubious BRFA where the linked discussions did not show the appropriate levels of (or any) advertisement or broad consensus. I think it's appropriate to raise the issue to the community, in line with the close of the preceding RfC. ProcrastinatingReader (talk) 13:09, 4 May 2021 (UTC)
That's a novel definition of objective (or of usefulness). Usefulness is context- and person-dependent, and usually isn't a yes-or-no question but a more-or-less one (more or less useful for you, useful for more or less people, for more or less uses). Fram (talk) 15:31, 4 May 2021 (UTC)
To make pancakes, yes, they are pretty useless. To survive jumping out of a plane at altitude, they are useful. Similarly, people may argue that the AC links in our articles are useless. Such claims are made in a context, not in a void. They may be wrong in this case, or they may be right, but that doesn't make useful or useless suddenly an objective measure. "It's useless to have these on enwiki because we have all of them, and usually many more (and sometimes better ones) at Wikidata anyway" is a valid position, just like "it's useful to have them here, it saves me one click" is a valid position. Simply dismissing someone's claims that they are not useful because they are objectively useful is not helping the discussion one bit, is not listening to what the other side has to say, it is just taking a doctrinary, absolutist position which tends to either annoy people or to simply get ignored. Fram (talk) 16:41, 4 May 2021 (UTC)
To run with the analogy, a parachute is very useful in the Air Force. That doesn't mean we should distribute a parachute to every single person in the Air Force, as they're useless for most Air Force personnel most of the time. The case can be made that a parachute is useful to pilots, so we shouldn't take parachutes away from everyone in the Air Force, either. We should have parachutes where they're useful, and not have parachutes where they're not useful. Similarly, we should have authority control where it's useful, and not have authority control where it's not useful. Right now, we (or rather a few editors) are putting authority control everywhere. That's not useful. The question is: where, if anywhere, is this template useful? Levivichharass/hound19:03, 4 May 2021 (UTC)
One of the problems is that the links are added automatically to articles, no matter if they are relevant for our readers or not. While the current redesign of the template makes it much more immediately clear what each link is (thus avoiding much bewilderment), it doesn't help with the problem that you get e.g. on Alejandro Rodriguez (psychiatrist), a Venezolan-American pediatrician and psychiatrist, a link to the Czech National Library[2] which would never be accepted as a simple External link. I have tried (a first, small step) to reduce this kind of clutter with Template:Authority control (arts), which for arts related articles only shows authority control links which are either in English or about art (or, with a country parameter added, have a link to the country of the article subject). Such templates can also be created for other subjects (e.g. by country or by language, whatever people like most). This template will automatically get the new layout of the main authority control template. Other options are removing the least useful links from the authority control template, or indeed just scrapping it: but it will be a tough battle to get that result, and you should make sure, before making such a suggestion, that you have plenty of representative examples of why we are better off without it. Just claiming that it is useless will get counterclaims that it is indispensable for the united librarians of the world and for some software, somewhere, that might stupidly use this template instead of the links on Wikidata. Fram (talk) 12:53, 4 May 2021 (UTC)
"{{Authority control (arts)}}" And, like anyone who dabbles in something they don't properly understand, you've made a right hash of it. Unless, of course, you wish to argue that no-one who works as an artist has every published anything in an academic context? Or designed an album cover? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits15:39, 5 May 2021 (UTC)
As you are well aware, in those cases the general template can still be used, if necessary. But thanks for the very polite way of bringing your message, a shining example here. Fram (talk) 15:51, 5 May 2021 (UTC)
"the general template can still be used, if necessary" Haven't you been using tools to mass remove {{Authority control}} and replace it with your fork of it - there are now 14K instances of the latter, largely if not mostly your doing. Done without prior community consensus. On how many articles did you leave the original template, for the reasons I mention? Can you give us a few examples? Mind, I'd be impressed if you managed to examine 14K articles for such nuances. Or did you just blindly swap the templates, without thinking to check, as someone who dabbles in something they don't properly understand? Do you even know on how many of those articles you removed identifiers relating to the academic publications or album design activities of artists? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits19:02, 5 May 2021 (UTC)
You nominated the template for deletion in February (completely misunderstanding or misrepresenting the template in your nomination), and it was kept. From that discussion, but also from comments in this very discussion, it is clear that many people see this as a step in the right direction. And yes, when I replace the template, I check the articles I do it on. Doesn't mean I don't make mistakes, but e.g. from the short Category:Icelandic painters, I skipped Elínborg Halldórsdóttir, Sölvi Helgason and Edda Heiðrún Backman. Fram (talk) 08:01, 6 May 2021 (UTC)
I have never misunderstood the purpose of your template fork, which is quite blatantly to bypass the community's decisions to reject your attempts to delete and to remove popular identifiers from it. The template narrowly escaped deletion, despite a majority in favour of deleting it, thanks to a supervote. I asked for examples of template replacemnts skipped because of academic publishing or designing album sleeves; none of those you list meet those criteria. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits13:05, 6 May 2021 (UTC)
Sadly, I don't have a list of articles I haven't edited, with the reason why I haven't edited them included. And I don't really have any interest in indulging your bad faith postings any longer. I have shown that I do skip articles during my template replacements,for a variety of reasons. No idea where you get the idea of "popular" identifiers, have you some statistics showing which identifiers are more popular than others? Fram (talk) 13:18, 6 May 2021 (UTC)
I agree strongly with ProcrastinatingReader here, in a lot of articles that this has been added to this template serves as little more than external link clutter. for what proportion of our readers is the GND ID of cheesecake such essential information that it needs to be included in the article? How about the Microsoft Academic ID of a Giraffe, or the National Diet library ID of a screw? In my opinion this type of structured identifier information should be kept on wikidata for the most part, as it simply isn't that useful for most readers. I would like to propose that we run a little experiment here - find a couple of highly viewed articles with authority control templates with a lot of ID's on them, and for each article replace the authority control template with a dummy, where every link is actually a piped redirect to a page that contains the actual authority control template and an explanation of what's going on. By comparing the page views of the article and the redirect we would be able to get a rough idea of what proportion of our readers are actually using the links in the template. 192.76.8.91 (talk) 13:03, 4 May 2021 (UTC)
We tend to block people for vandalism. Also, your point about giraffes and screws misses the point; whether {{Authority control}} should be used on such articles is a different matter to whether it should be used on articles about people, or creative works, or - as here - at all. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits14:52, 4 May 2021 (UTC)
Threatening people with vandalism blocks for thought experiments which aren't vandalism at all is not a good way to have a discussion. Fram (talk) 15:31, 4 May 2021 (UTC)
Yeah, that's the essential point here, whether it is a "thought experiment" or a "proposal for an actual experiment". You threatened someone with a vandalism block for a good faith, constructive proposal. Again, a very good way to get people to avoid discussing things with you, as it is much more fruitful to simply ignore you. Fram (talk) 16:41, 4 May 2021 (UTC)
"We tend to block people for vandalism." is not threatening anyone with a vandalism block? It simply is your way of saying "hello" to an IP making a consetructive suggestion? Silly me. Fram (talk) 15:51, 5 May 2021 (UTC)
I don't know why you're threatening me with a block, that's completely unnecessary and over the top. Using redirects to track whether readers are actually using features is something we've done in the past, e.g. when we wanted to see whether readers were actually using the COVID-19 ITN banner we redirected all their traffic through Coronavirus disease 2019* to see where traffic was coming from. Someone started categorising these type of redirects using {{R from statistical redirect}} earlier this year, and there's a (very incomplete) draft policy on their use at Wikipedia:Statistical redirects.The reason I bring up those article specifically is that they illustrate why I think this template has received such huge amounts of pushback and has been recurrently been brought up here - the template has been indiscriminately added to articles seemingly without any thought as to whether the resulting links are relevant to our readers. I would argue that a link to an academic's ORCID ID is useful (it's actually probably important enough to be imported directly into the academic infobox), there's a very good argument to be made that there's use in linking artists to their entries in art databases and that things like ISBN numbers should be included in articles on books. Do articles like Lego, Varnish and Electric light really benefit from having links to "Categorise everything in the known universe" databases, which in turn link to basically every publication vaugeley related to that concept? In my opinion, not really. 192.76.8.91 (talk) 15:49, 4 May 2021 (UTC)
I find it very useful whenever I'm looking at (and editing) articles. It's like proposing to get rid of the links in the references because they don't meet the external links requirement - ridiculous. Mike Peel (talk) 13:28, 4 May 2021 (UTC)
I'm sure I said this in the previous discussions, but references verify text in the article, and Wikipedia:External links do not, so it's an apples to oranges comparison really. And WP:EL also explicitly says: these external-link guidelines do not apply to citations to reliable sources within the body of the article.ProcrastinatingReader (talk) 14:12, 4 May 2021 (UTC)
Then think of these authority control links as references, if that helps, providing citations for the notability of the article. Mike Peel (talk) 14:16, 4 May 2021 (UTC)
Except that they don't. Having an entry on e.g. Musicbrainz gives zero notability. Combining "citation" and "notability" as justification for a template which provide neither citations nor notability is not the strongest argument. Fram (talk) 14:18, 4 May 2021 (UTC)
Oh boy... "The word authority in authority control derives from the idea that the names of people, places, things, and concepts are authorized, i.e., they are established in one particular form.". The links provided as authority controls can be completely unreliable, wikis (like Wikidata), whatever. Authority control is a terrible name, as it often leads to this kind of confusion and gives the links an allure of importance, of reliability, which they don't deserve: but I hoped that the people who work with it a lot would at least know this. Fram (talk) 14:34, 4 May 2021 (UTC)
What, that Musicbrainz, or Wikidata (never mind some ACs used on Wikidata, like Quora, FindAGrave, ...) are not reliable and having an entry there doesn't give any notability? That simply being an "authority control" is in this context or for these purposes meaningless? That the LoC or the BL don't get their importance, their reliability, from being an authority control, but from being a trustworthy institution known for their fact-checking, their efforts to get their information right and neutral? I doubt that they would be interested in this conversation at all, but I have no qualms in saying that to them, no. What's your rhetorical point? Fram (talk) 15:31, 4 May 2021 (UTC)
If you're going to persist in deliberately misunderstanding and trying to put words in my mouth, then just go away. Mike Peel (talk) 16:52, 4 May 2021 (UTC)
Well, you claimed that I had to say something rather undefined to the BL and the LoC, two institutions I hadn't discussed or mentioned. If you don't make it clear what it is I have to say to those, I can only speculate. You have all the space you want to correct me and clarify your meaning, but that's up to you of course. Until then, it looks as if you tried to score some rhetorical point which backfired. Fram (talk) 08:16, 5 May 2021 (UTC)
OK, it's good to know that you think the British Library and Musicbrainz are equally reliable. But I'm going to re-adopt my policy of not bothering to reply to anything you say, it's better for my blood pressure. Mike Peel (talk) 09:09, 5 May 2021 (UTC)
For someone who gets all worked up about people putting words in your mouth when they are asking you questions about what you meant, you sure don't have any problems putting incorrect words in my mouth, do you? I discussed MusicBrainz among the unreliable ACs, the wikis, the problematic ones: I discussed BL as one of the important, reliable ones (which we don't use in the AC template anyway, but well, you brought it up, so...): I never said and I don't think they are even remotely "equally reliable". It may indeed be best if you stop replying, as you are not making much sense. Fram (talk) 12:15, 5 May 2021 (UTC)
They verify the article topic. Quite often they could also be used for references, particularly if you extended AC for monuments etc. I'm very against having external links in articles in general, since I agree that external links rarely do add value, but for me these don't fall under that category. Mike Peel (talk) 14:28, 4 May 2021 (UTC)
But there is no need to “verify the article topic”... we only need to verify the information about the topic that we discuss in the article. Blueboar (talk) 11:27, 5 May 2021 (UTC)
But how will you do that without an authority control like this[3]? Or how will you otherwise ever know that the Indian footballer Mohammed Salim (footballer) (1904-1980) (full name "Mohammed Abdul-Salim Bachi Khan") is the same as the author Muḥammad al-Ḥabīb Ibn Sālim (1903-1980) who published one book in Tunis in 1973? Without "Authority Control" and Wikidata, we would never have known this, we could never have verified the importance, the notability, the reliability of this amazing fact! These are reliable and indispensable! Fram (talk) 12:38, 5 May 2021 (UTC)
To expand on my comment, I find statements like "I find it useful" to be useless. I don't give a hoot what a handful of editors find useful, and we shouldn't make project-wide decisions based on that. What no one has explained (yet) is what the template's use is: what is the template used for? (It's obviously not for any WP:V or N purpose, which seems to be the only specific use mentioned in this discussion so far.) Looking at the examples above, like Giraffe, I have a hard time imagining what the use is of having those links at the bottom of that article. I understand the use in linking an author article to their Worldcat entry, or a book article to its LOC listing, but those specific links seem better included in an info box or some specific template for specific subjects, as opposed to this one-size-fits-all authority control template we have now. Levivichharass/hound18:53, 4 May 2021 (UTC)
Oppose getting rid of it, of course. I've used it. I know people who use it. People who work with data and libraries tend to like it as soon as they realize it's there. Oppose any evaluation based on "what percentage of readers find it useful" (as though we have any good way to find that out beyond anecdotes). Most readers don't use an awful lot of the stuff that we've decided to include in Wikipedia because we're not only trying to maximize the interest of the largest number of people, but also providing a reference work that's can be a first stop for research and deeper learning about a topic. — Rhododendritestalk \\ 14:42, 4 May 2021 (UTC)
Oppose getting rid of it, also. This is quite useful to have in articles, it's not reasonable to expect readers to go to Wikidata. Including the information in a discrete way here is preferable, which is what this does. Elli (talk | contribs) 15:30, 4 May 2021 (UTC)
Oppose getting rid of it outright - the information is clearly useful to some readers, and I don't see how a case can be nor has been made that one small line of data links at the very bottom of a page is somehow disruptive to readers. If it is, has anyone proposed moving {{authority control}} to talk pages? Create a Wikipedia:WikiProject authority control and add the links to that project's talk banner, which would autocollapse in certain situations like all the others. Ivanvector's squirrel (trees/nuts) 15:52, 4 May 2021 (UTC)
Yes, and it was shouted down by the usual wikidata crowd. The Authority Control template exists to shoehorn Wikidata onto articles not to provide useful information to a human reader of an article. Its of limited usefulness for the vast majority of the human readers on its best day. Some identifiers are useful to a very tiny subset of people who look at an article. But then, as Fram has pointed out when he created his arts template, of the total identifiers available on a given topic, some are useful, some are not useful, and some are actively things we should be avoiding (unreliable user-generated sites like find-a-grave). Fram's template which actually sought to constructively apply AC to an article in a way that made it useful, was nominated for deletion in yet another of Andy's disruptive actions regarding anything to do with wikidata. Once you understand the purpose of the template is to integrate wikidata into an article, the actions of the various wikidata editors in trying to prevent it being modified in a useful way make more sense. Less links shown in the template - less wikidata. Given Wikidata has the standards of the Daily Mail when it comes to sourcing of information on there, you can see why its annoying. Only in death does duty end (talk) 17:28, 4 May 2021 (UTC)
"The Authority Control template exists to shoehorn Wikidata onto articles" The template predates Wikidata by several years. Got any other AGF-busting inventions you'd like to throw into the discussion? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits19:59, 4 May 2021 (UTC)
Well, what about in the left sidebar, then, with all the interlanguage and "on other projects" links? And how about integrating that with new fields in Wikidata to store the link info? We could limit the available link fields to only those that are deemed useful. Ivanvector's squirrel (trees/nuts) 13:35, 5 May 2021 (UTC)
I mean literally the links that are in the AC boxes now, just put them in the sidebar instead, in their own section let's say below Languages. The "Wikidata item" is just a link to the topic on Wikidata, isn't it? I suppose merging AC into Wikidata might be a good approach too, although I'd prefer if the links remained visible from Wikipedia, and that sidebar is a lot of wasted space on any article longer than a stub. Ivanvector's squirrel (trees/nuts) 15:56, 5 May 2021 (UTC)
I am all for “Less Wikidata”... what I want to know is: How do we get to “NO Wikidata”? Would love that. Blueboar (talk) 18:17, 4 May 2021 (UTC)
It's less useless than much of the clutter at the bottom of articles. Certainly most useful than links to portals. I'd oppose getting rid of it. Guettarda (talk) 19:12, 4 May 2021 (UTC)
Oppose getting rid of it. WP is an encyclopedia – this is likely to be useful for researchers, etc. These appear at the very bottom of articles and don't appear at all in mobile view. I can't see how it's troubling readers. I also don't think this violates WP:EL either. In particular, #3 of WP:ELYES, #4 and #6 of WP:ELMAYBE are applicable and met by authority control links. – SD0001 (talk) 20:41, 4 May 2021 (UTC)
Oppose Authority control is clearly useful for topics about authors, researchers, translators and the like, providing an authoritative list of holdings in major libraries such as the Library of Congress. As most of our readers use the mobile interface and don't read past the lead of articles, then it's in the perfect place for the serious researchers and scholars who will understand and use it. Andrew🐉(talk) 20:54, 4 May 2021 (UTC)
Support either getting rid of it or seriously reducing its visual signature, it currently adds unnecessary clutter to the bottom of the page. It appears the most compelling case to retain it is some experienced editors find it useful when researching the article's topic, said editors could most likely navigate to Wikidata. If another link to Wikidata is required then perhaps amend the template to something similar to {{Commons}}, which could link to Wikidata discreetly at the bottom of the page, as opposed to the current navbox-like clutter which only distracts from the actual navigational aids. Cavalryman (talk) 23:33, 4 May 2021 (UTC).
Weak oppose—in general, I don't really think their existence is negative. My take is that most readers only read the lead anyways, and it seems likely that the further readers go into the article the more interested they are (pure speculation, but perhaps not a huge stretch in thinking). If they somehow end up at the bottom of the page, providing links to other databases doesn't really seem like a negative thing, hopefully it could full fill the reader's interest. To be honest, this seems to have become (by some) an argument of "I like it" and "I don't like it"—but I'm having trouble rationalizing how a neatly kept list of database links is in such dire need of deletion. I understand some people's dislikes of having so many links; I think limiting these is a separate conversation, but one that certainly has merit. Aza24 (talk) 15:59, 5 May 2021 (UTC)
I think it is a combination of (for popular pages certainly) too many links, often of limited value (which I try to solve with something like Template:Authority control (Arts)); a sea of obscure acronyms followed by meaningless numbers (which we are solving at the main template at the moment); and a dislike of having many links which are not really checked, and which can get remotely vandalized (see e.g. my example above of Mohammed Salim (footballer), who has AC links for another person with a similar name and nearly the same year of birth and death: this get bot-added ad Wikidata, and semi-bot added here, and for 2 1/2 years no one noticed this issue, probably because no one really used these in the first place). The replacement of local, human editing and maintenance with remote, bot-maintained editing is often hailed as much safer, better, reliable by the proponents: but the way too common counterexamples of dubious, useless or plain wrong information being added and escaping scrutiny in this way have created pushback and led to a group of people who'ld rather have as little Wikidata-based stuff in enwiki as possible. Fram (talk) 16:12, 5 May 2021 (UTC)
I don't know Fram, it seems like both of the primary issues you present have a good chance on being addressed. From what I could tell with the acronym discussion (which was admirably presented) there is clear consensus behind such a thing; the TFD for Ac Art might have resulted in deletion, but were you to bring a proposal here about having such a thing for various topics, it would also have a solid chance of passing. I just think people put too much weight on how "crufty" it looks; as I said earlier, most readers aren't looking there in the first place, and those that are likely seeking extra information anyways. I'm impressed that you found the Mohammed Salim (footballer) example—rather random...!—but I don't know that we have any reliable data to prove that kind of thing happens particularly often, or more than our own EnWiki messups like Abu-Ali Urbuti. Aza24 (talk) 16:27, 5 May 2021 (UTC)
Especially in stubs like Special:Permalink/1019401732 it's massively intruding in a purple box without even having to scroll down. The bottom of an article is WikiSpeak for the place to dump lots of random stuff, and that's both distracting and looks unprofessional. While, indeed, the keep arguments are "I like it", the removal arguments aren't; WP:NOTLINK is policy and WP:EL also says Long lists of links in articles are not acceptable. It's policy not to have a "list of database links" in articles, especially when mass-added to 1.8 million of them without clear prior consensus to do so. I don't care for the entire Wikidata argument (and think WD is a good idea), I'd be equally unhappy with these boxes if the data was stored on enwiki. ProcrastinatingReader (talk) 16:31, 5 May 2021 (UTC)
I don't really follow how the center of my argument is "Like" or "don't like" at all—that seems like pure generalization. Clearly there is something to be said about the status quo, so saying there was never consensus seems a bit dubious. I apologize, but I just don't see the box as intrusive, and if anything I see them as helpful in my aforementioned example. But the reason my oppose is "weak" is because I don't see the use of removing the template, when much of the issues could be adjusted in the AC art manner and/or acronym manner, the latter of which will probably happen anyways. Aza24 (talk) 16:56, 5 May 2021 (UTC)
Fram sums up a lot of my negativity towards Wikidata well. For the record, I DO think Wikidata is a useful project... I just don’t think that it should be intertwined with Wikipedia. I would not object to a relatively unobtrusive message saying “Our sister project, Wikidata, has stuff related this topic” with a link to the relevant WD page. What I do object to is importing that “stuff” into the WP articles. My antagonism probably stems from the fact that I think WP should be text oriented, and not data oriented. I see this AC “data” as unwanted clutter... something that belongs at WD, but not something that should be imported into WP.
@Blueboar: "I think WP should be text oriented, and not data oriented" - text is what WP does best, data is what WD does best. What I'd like to see is the decent fusion of the two: rather than trying to handle data in text, like we do with a lot of templates/infoboxes, use WD for that. Sadly there are people that think nuclear and want to get rid of WD usage completely, which is a shame, causes a lot of unnecessary arguments, and is generally very 1980s (think about how many websites use databases in their back end). Thanks. Mike Peel (talk) 17:08, 5 May 2021 (UTC)
If you are suggesting we shift all the infoboxes and most of our templates to Wikidata... I would support. Infoboxes and templates cause half the arguments around here, so WD is welcome to them! As for 1980’s... if you are referring to a golden age when people understood the difference between an encyclopedia and an almanac, then yup... All for it! Better yet... we could try for the 1960s - when things ran analog, but ran well. Blueboar (talk) 17:35, 5 May 2021 (UTC)
Support reduction or removal. Per the OP, WP:External links clearly states that ELs have to be relevant to the article. The fact that the subject merely exists in some other database does not mean that we should include that link in its Wikipedia page. ELs should be curated per article, or possibly per topic/group/category, but the current one size fits all approach is not appropriate. If the status quo is to be maintained, WP:External links should be updated to allow for the (near) universal inclusion of AC links. -M.Nelson (talk) 20:25, 5 May 2021 (UTC)
Most of the time I don't mind having this at the bottom (and while I dislike the name, it appears to be the correct technical term in library science). It is at the bottom of the article, together with the navboxes that my brain is trained to ignore completely. For articles with many AC entries, it does become a bit noisy, though, and I think collapsing the template or using more targeted links like the ACarts template are reasonable ways forward in such cases. We should integrate well with databases and wikidata, but we don't need to go for an all-or-nothing approach. —Kusma (t·c) 13:30, 6 May 2021 (UTC)
Support removal or revision I oppose the inclusion of machine information in spaces which are for human eyes. This template presents lists of machine identifiers which only computers can read, and it puts this information in front of human eyes. I oppose the use of published identifiers in Wikipedia generally, so this applies to infoboxes as well which sometimes collect this content. There is no reason to manage machine information in Wikipedia and the master collection of this should be in Wikidata anyway. To the extent it is in Wikipedia, it should be presented as human readable text. Blue Rasberry (talk)15:45, 6 May 2021 (UTC)
Blue Rasberry, that's a surprisingly Luddite viewpoint coming from someone who makes so many contributions to an online encyclopedia. More concerning is your characterisation of the information; it doesn't seem (to me) to be "machine information" any more than a URL or telephone area code is. These aren't machine identifiers which only computers can read, they just don't do anything useful for most people. They certainly don't do anything for me. When you say, it should be presented as human readable text, I think, "it is, but it's not human (readily) usable text". I, personally, have no use for it. But I could use it (though I am human) if I developed the need/interest. — JohnFromPinckney (talk)18:51, 6 May 2021 (UTC)
@JohnFromPinckney: I assert that no human should read or type an identifier except in the rare circumstance of some failure in everyday technology. The template currently says things like, "SNAC: w6zm66qw". I do not oppose the link, but the machine code is an arbitrary placeholder not meant for humans to consider. If we want arbitrary placeholders then we could use any alternative, like a link to the information with an emoji for wiki article info on the database. "📃SNAC" We could probably list multiple design options. I recognize that as you say a human could conceivably type this, but if I made a guess, I would say the incidence of a human typing an identifer is less than 1 in 5 million uses. For those millions of other readers, it seems like poor design to expose them to computer code. Blue Rasberry (talk)15:39, 7 May 2021 (UTC)
Question for those who find the AC links useful: could you walk through an example scenario where you would use these links? e.g. "I go to article X seeking information Y. I follow authority control link Z and then...". I'm one of the users who finds these links completely inscrutable, but I want to better understand the other side. Colin M (talk) 17:08, 7 May 2021 (UTC)
Oppose so much as this is a vote, I am opposing changes. There are 1.8 million of these templates, and I am confident at least 200k of them are clearly net benefits. Some people may say "that's only 10%", but it's still a lot of improvement. Some improved guidelines on where Authority Control is used would be helpful; I'm not sure there are any guidelines at all now. UI improvements (such as moving to the sidebar) may also help. User:力 (power~enwiki, π, ν) 17:18, 7 May 2021 (UTC)
Summary of ideas
So, to get the discussion back on track slightly. If I'm clear the proposals made here so far are:
Scrap it entirely
Do an A/B test to measure usage (detailed in the IP's suggestion), and proceed accordingly
Limit the usage of this template to 'appropriate articles' (would need to define a criteria)
Some other way to let users who want to see the template see it. Perhaps using an opt-in gadget to make the boxes visible, for example.
Move it into the sidebar. Possibly in a form like the Cite this page page
Amend policy to make this template permissible. Would we carve out an exemption just for this template, or some kind of 'general principle' of this template, or possibly consider removing the policy altogether if it doesn't have consensus.
Oppose The point made at the outset was that "{{Authority control}} is a template with 1.86 million transclusions." This tells us that the template is already permissable and that it is widely used. There doesn't seem to be a problem that needs fixing and so further discussion is not needed. See WP:CREEP. Andrew🐉(talk) 15:54, 6 May 2021 (UTC)
@Andrew Davidson: Two issues with this argument. First, WP:CREEP is about policy creep. Here we already have a policy that isn't being followed. Second, WP:FAIT is not an excuse. In the CS1 parameters RfC the community seemed to show great concern with bots or WP:MEATBOTs altering articles at scale without wider community input. There is no evidence presented that its installation to 1.8 million articles had consensus, or that the wider community actually thinks this template at this scale adds value for readers. In any case, if this is deemed acceptable then WP:NOTLINK needs to be amended, because then that would not be accurately reflecting consensus. ProcrastinatingReader (talk) 16:44, 6 May 2021 (UTC)
One point no one has seem to made yet: in the old days, {{Authority control}} was de facto limited to biographies, and this made sense. People tend to have written books or created works of art etc. and that's what most of these authorities catalogue. It makes sense to want to access a library record of a writer's corpus and that's what {{Authority control}} makes possible. It also eliminates the need to fight over which library search links are relevant enough for a particular biography to be included in an EL section as this varies by the nationality, influence and languages of authors. Many people above are questioning the utility of seeing identifiers for a topic like cheesecake. But for biographies, they are essential and I'm convinced that {{Authority control}} is the best way to handle the issue. – Finnusertop (talk ⋅ contribs) 10:30, 7 May 2021 (UTC)
We only have 1 million BLPs. Even if every BLP had AC, at least another million are not BLPs. Further, many of these "Authority controls" are just blank pages. They aren't lists of the published works of an individual. ProcrastinatingReader (talk) 11:19, 7 May 2021 (UTC)
Authority Control - asking a slightly different question
Reading all the discussion above, I would like to ask a slightly different question than was originally asked. Let’s assume that Authority Control data is useful to at least some of our readers, and that we DO want to help them to find it. The next question then becomes:
Should Authority Control data be placed DIRECTLY into Wikipedia articles, or should we instead LINK to an exterior site (such as Wikidata) where the data is located?
In both methods, a reader looking for AC data will find the data... it is more an issue of HOW and WHERE they find it. Please share your thoughts. Blueboar (talk) 21:00, 6 May 2021 (UTC)
Link to Wikidata would be useful. It could tell the reader what the link leads to (like "other database entries"), and would take up less room. That comes at the cost of an extra click, but I think that's a good trade off, because most readers won't use this, so the reduced clutter benefits all and the extra click only inconveniences some. Levivichharass/hound21:15, 6 May 2021 (UTC)
Articles do already have a link to Wikidata. To pick a random article – this has a AC template which gives 6 links: GND, LCCN, NKC, SUDOC, VIAF, WorldCat Identities. The sidebar also has a link under Tools called Wikidata item which, unsurprisingly, links directly to the Wikidata item. The Wikidata page then has a section at the end called Identifiers which lists a massive 39 links. Not sure why the AC template selects those 6 links out of the 39 possible ones. It might be better to have a sidebar link (like the Page information link?) that is to a local page that acts like an expanded AC template and then includes a link to Wikidata. The Wikidata layout is not at all friendly, so an intermediate local page would be a chance to explain things more fully and provide links to other information about the identifiers — GhostInTheMachinetalk to me21:43, 6 May 2021 (UTC)
Great idea, strong support. As Francis Schonken's example shows (convenient edit conflict), we treat Commons the same way. We don't show a gallery of images curated by Commons on every Wikipedia page; WP editors individually select the media that are relevant to the encyclopedia article and include them where helpful to the article, and provide a link to the full selection at Commons at the bottom of the page. For AC, if editors decide specific links are particularly relevant to a given article, the link should already be included as a reference or external link (e.g. WP:ELLIST); if a reader would like the full selection of connected resources, they should navigate to the project which specializes in connecting things. -M.Nelson (talk) 09:21, 7 May 2021 (UTC)
I'd support this, but only in the form of an external link template like {{commons}}. The buried sidebar link is not visible enough, and I understand sidebar links are not visible at all on mobile. Ivanvector's squirrel (trees/nuts) 12:39, 9 May 2021 (UTC)
Yes and no... yes, shifting AC from being DIRECTLY listed in WP articles to being INDIRECTLY linked would make the current template obsolete (and thus likely to be deleted)... but we would be replacing that template with an INDIRECT link (similar to our link to commons for images). This would NOT delete AC, just change WHERE the information is hosted (at WD instead of at WP), and HOW it is accessed (via an indirect link instead of a template). Blueboar (talk) 13:36, 9 May 2021 (UTC)
No, it's deletion, plain and simple. Compare with the current situation of the template + the sidebar link. The information is already hosted at Wikidata, it's different ways of displaying it. Mike Peel (talk) 13:51, 9 May 2021 (UTC)
The template is still deleted from the articles and the content no longer shown in the articles, no? Wikidata's user interface is designed more for editing than viewing, it's normal that templates like this one reformat the data so it displays better. Mike Peel (talk) 14:40, 9 May 2021 (UTC)
Ah, Ok... you are focused on the visual aspects while I am focused on the functional aspects. Fair enough. I still don’t see the suggestion as a “deletion”, but I do understand how you might. Blueboar (talk) 15:35, 9 May 2021 (UTC)
I think the idea of linking to Wikidata has merit, but also think that Mike makes a good point: Wikidata entries aren't really designed to be casually browsed; they're to be queried. Maybe a possible solution would be to develop a template on Wikidata which presents identifiers in a neat way like our authority control template tries to do, and we link to that. Or I guess just use this template on Wikidata? I'm not sure I'm entirely sold on replacing it with a link, but if the original goal here was to make it more user-friendly, just linking to a Wikidata item doesn't achieve that. — Rhododendritestalk \\ 16:45, 9 May 2021 (UTC)
Ghost mentioned above the idea of linking to an intermediate page that queries WD and presents the information in a readable format (kind of like our Page Information link). Whether that intermediate page should be hosted on enwiki or WD I'm not sure, but I think this idea has promise. Levivichharass/hound16:51, 9 May 2021 (UTC)
What if an {{authority file}}-like box could link to a subpage which would import the links from Wikidata and present them in a standardized reader-friendly format? I'm sure someone who knows what they're doing (i.e. not me) could whip up a template for this purpose pretty easily. Ivanvector's squirrel (trees/nuts) 13:20, 11 May 2021 (UTC)
Oppose I have dabbled with Wikidata but don't find its interface and content to be easy. The current {{authority control}} template is comparatively straightforward and simple and so we should continue to use it. Andrew🐉(talk) 16:35, 10 May 2021 (UTC)
There may be other objectives for the template (feel free to mention those), but I suppose the above two are the main ones. These two goals are not mutually exclusive, and accomplishing both in a single pass seems commendable. In practice, however, they may be less compatible than anticipated: e.g., cleaning up excessive external links WP:EL-wise may hamper the unique identification goal. Trimming excessive identification (e.g. according to systems that hardly ever use an English-language word) may lead to removal of more useful external links. So it might be a good step to see whether we can find consensus on any of these:
Both main goals have equal (high) importance: inclusion/exclusion of linked identifiers should seek a middle way of what optimizes both goals with as little as possible drawback for either goal.
External links in the box are subject to the WP:EL guidance: only those external links that are most useful to a general readership should be retained, discarding those that would not normally otherwise be included in an external links section.
Unique identification, as in authority control, is paramount, and should show as many connections as useful for the precise identification of the article's topic.
Neither goal is very suitable for an {{Authority control}}-like box: external links should be included elsewhere in the article (e.g., in references grouped at the bottom of an article, and/or in a usual format adopted for lists of external links), not in a type of box that was designed after models for grouping internal links (navbox format), and unique identification is rather something for Wikidata (no need to echo that in English Wikipedia: a link to the Wikidata "authority file" for the article suffices).
Rather than exclusively mentioning which of the above options is or are closest to what you think best, it would be interesting to know how you would accomplish the goal(s) you'd like to see pursued first. And additional ideas are welcome too, that is, inasmuch as they help to distinguish which should be the main goals of the template. --Francis Schonken (talk) 12:32, 7 May 2021 (UTC)
Comments:
Option 4 – an {{Authority control}}-like box is neither very suitable for external links, nor for unique identification. Re. how to accomplish that: see my proposal in #Authority Control - asking a slightly different question above. If forced to say which of both goals mentioned in the OP of this subsection should be most prominent for the box, then I'd think the "unique identification" goal: external links already have designated places elsewhere in the article – "authority control" is the template's USP. --Francis Schonken (talk) 12:32, 7 May 2021 (UTC)
On the subject of WP:EL - External links in the box are subject to the WP:EL guidance: only those external links that are most useful to a general readership should be retained - the guidance about keeping them to a minimum is about the external links section, not all external links on a page. The page doesn't account for authority control, but does explain that there are parts of the page where this guidance doesn't apply (citations, not to mention other namespaces). I suppose we should really have some information about it there, because we otherwise don't include multiple ELs like that and don't have another template which operates similarly. In other words, when that guidance was written, the EL section would just be a long list and not a separate, standardized template with a particular purpose. The relevant bit is really just ELNEVER. As such, either #2 should be rewritten or another option, I guess: The links are a major goal, and should not include any links along the lines of ELNEVER, but should be subject to a different kind of inclusion evaluation than links presented as normal in the external links section. — Rhododendritestalk \\ 13:02, 7 May 2021 (UTC)
I won't pretend to know the answer, but this is the question that needs answering before we get on to technical details of implementation, i.e. what is authority control for? I had always assumed that the answer is the first of Francis's points, which is a very difficult question for libraries, but the way that this template is used seems to lean more towards the second. If it is to provide a single unique identifier than we should only include organisations that actually do some serious fact-checking into the issue. I have the feeling that some of the organisations linked don't do that but only use what others have done or vague feelings that namesakes, or alternative names possibly for the same person/thing, are or are not the same. If the purpose is to provide external links to organisations with information about a topic then I don't see why those links should be treated any differently from links in an "external links" section. Phil Bridger (talk) 16:07, 9 May 2021 (UTC)
Mass deletion of redirects of non-diacritic articles
Latest comment: 3 years ago22 comments13 people in discussion
This is not going to happen, primarily due to the argument that the original assumption is inaccurate - and despite questions to the OP and their otherwise continuing activity they have not come back to clarify this. Additionally, the proposed benefit is also inaccurate, deleting a page consumes more server space - not less, as the space isn't actually removed and then the deletion actions have to be stored. No actual explanation of how "page loading" time would be impacted has been put forward either. — xaosfluxTalk23:07, 12 May 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Since this is automatically handled nowadays by the MediaWiki software, I propose mass deletion of such redirects to free server space and possibly make page loading faster. --Heymid (contribs) 12:18, 9 May 2021 (UTC)
There may be other reasons to do this, however performance/space concerns are not one of them. (Mass-deletion would actually increase server space usage as new entries for the deletions would be added to the database.) –xenotalk12:35, 9 May 2021 (UTC)
Oversighters cannot remove entries from the database. The revision remains in the database and edit history but is marked such that it is only visible to editors with the oversight user right. The flag is applied independently to the content and edit summary and is fully reversible, nothing is actually deleted. This is explained more fully at Wikipedia:Oversight. Thryduulf (talk) 21:28, 9 May 2021 (UTC)
Anomie, Do you know how often this happens? I would imagine it's exceptionally rare and probably only in response to something like a court order. -- RoySmith(talk)18:24, 10 May 2021 (UTC)
I don't know that it has ever happened, since the very early days of Wikipedia before the current software was fully in place. Anomie⚔22:14, 10 May 2021 (UTC)
(after edit conflict) This would not save any server space (deleted pages are simply flagged as deleted, rather than actually removed from the servers) and I would doubt very much that it would have any discernable affect on page loading time, but if such redirects are performed automatically (something that I wasn't aware of, but you learn something new every day) then why bother to maintain manual redirects? Phil Bridger (talk) 12:40, 9 May 2021 (UTC)
If you delete a page and then move another page to that page, all revisions of the deleted page are deleted from the database. --Heymid (contribs) 12:54, 9 May 2021 (UTC)
Can you provide more information on the automatic handling of redirects, such as some documentation or announcements of the feature? isaacl (talk) 17:31, 9 May 2021 (UTC)
It's not clear which redirects you are proposing to delete, but I presume you mean things like Cliche (→Cliché). If so then I will strongly oppose because while the software automatically takes you to the title with the diacritic in some circumstances it doesn't in all of them (it depends on what method you are using to navigate and possibly what device you are using). Additionally, there are likely to be cases where multiple titles differ only by different diacritics, I don't know what the software does in that situation but it seems far better to be able to control it manually. Finally, some of the redirects will need to be retained for attribution reasons and/or contain other important edit history. Thryduulf (talk) 21:23, 9 May 2021 (UTC)
The premise is flawed 1) since this is not automatically handled by the software in any way (searching is, yes, but not redirections) 2) this would not save any server space nor would it affect load times 3) this would hamper typo fixing effects when diacritics are concerned by depopulating Category:Redirects from titles without diacritics (including scripts and semi-automated editing that make use of this category). Headbomb {t · c · p · b}21:26, 9 May 2021 (UTC)
@Heymid: multiple comments above suggest your premise that there is some automatic title handling overriding everything else is incorrect, can you point to any documentation about how this is always being resolved? — xaosfluxTalk10:14, 10 May 2021 (UTC)
I second the question -- is this documented somewhere? I thought something new was added to MediaWiki. But from the above comments, it seems this only applies to searching as it has for a while. None of the ways I manually tried to go to a diacritic-ed page actually did so. — HELLKNOWZ ▎TALK10:37, 10 May 2021 (UTC)
Oppose, for the record. I can conceive of circumstances where a word spelled the same except for varying diacritics has differing targets (i.e., where a Föo properly redirects to a Foo, but a Fóo properly redirects to a Fao), where having the diacritic redirects saves readers confusion. The diacritic terms may be harder to type, but don't underestimate the propensity of readers to copy and paste terms of interest from things they are reading on the web. BD2412T18:46, 10 May 2021 (UTC)
Oppose the "save server space" argument is so ridiculous I shouldn't need to respond, but I will. First, deleting redirects doesn't actually save server space. Second, there's no shortage of server space. Beyond that, the redirects are valuable if somebody wants to create a different article at the non-diacritic title. There can be ambiguous redirects to/from diacritic pages. And other commenters suggest the "automatic redirect" is just auto-complete in the search box, not an actual redirect. User:力 (power~enwiki, π, ν) 22:14, 12 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Adding Pronouns to Prominent Figures
Latest comment: 3 years ago11 comments7 people in discussion
We have discussed this before. For usual kinds of pronouns, (he or she) just use them in the text. If the subject has expressed their wishes in a reliable source about pronoun use, then we should cover it in the text. But don't use templates, or make stuff up. If writers use "they", it is unclear if it is bad writing, or a subject request. So it should be made clear in text of the article. Graeme Bartlett (talk) 07:59, 3 May 2021 (UTC)
Wikipedia is not for social advocacy. As much as some people might like it to be, and have arguably succeeded in other ways, we're not here to be an advocate for social change like "normalizing" pronouns. We're here to describe on the world as it is, in as neutral a manner as we can. Our most appropriate social advocacy lies in doing exactly that: writing about the world as it is, without ignoring notable encyclopedic topics that have historically been ignored. But trivia like pronouns or blood types generally aren't notable or relevant from an encyclopedic perspective. Anomie⚔11:53, 3 May 2021 (UTC)
Generally speaking, we know the sex and/or gender of the person so can use "he" or "she". If it's unknown -- this'd be really rare I suppose, but I mean if we're describing the person who, I don't know, carved the Venus of Willondorf or is an anonymous blogger, we could use "he or she" maybe, and try to use more specific pronouns in those cases ("the carver", "the blogger"). "They" would imply that we're talking about the person's group as a whole. "It was found in an area where the Bugboy Tribe had lived, and they probably created it around 2000 BC. The carver appears to have been skilled for the times, and he or she clearly was influenced by the Woowoo culture." Substituting "they were" in the second sentence for "he or she was" alters the meaning. (It also still makes some people claw the draperies too, and all things equal that's not maximally accommodating.)
I suppose there are some people whom we know who they are but their sex or gender is simply unclear. I can't think of any, but it's a big world. I dunno, but must be rare, I guess case-by-case would be have to be the rule.
I all debatable cases, subject preferences is a data point, and certainly worth considering, especially if the person is alive. But at the end of the day we decide. I had a subject named "M. L. Something" (she went only by her initials) who wanted her name written everywhere as "ML Something" -- sporty, I guess. Some sources did and some didn't, so our normal MoS trumped her wishes. If someone wants to be known as "xe" or "heshe" or what have you, fine, but we mainly want to know what pronouns the Times of India and the Chicago Tribune etc. use.
And then the system is subject to going off the rails. Keiynan Lonsdalewants his pronoun to be "tree" ("Londsdale was slated to appear in Glad To See You, but tree got sick", I guess). We certainly don't want a system where we're required to use "tree" in Mr Londsdale's article and so on. So maybe no rule at all would be best for now. Herostratus (talk) 23:33, 3 May 2021 (UTC)
I don't think the sentence and substitution you suggest really alters the meaning, although it does create some ambiguity: I find myself asking "Is this singular they, or someone writing at a middle school level?" Most of the time I find singular they unambiguous. Anomie⚔12:22, 4 May 2021 (UTC)
As I say every time somebody brings this up - if there is a reliable source for the information, we can absolutely state the preference of a subject in an article, and we do, consistently. If there is not a reliable source stating this information (and no, the use a specific set of pronouns in passing in an otherwise reliable source does not really count IMO - a source which explicitly refers to a subject self-determining their pronoun use would be needed), then we can't explicitly say "<x> stated that she uses 'she/her'," or similar. Otherwise, I am reticent to draw specfic attention because it's consistently a target for vandalism on articles about trans folk, and it makes more work for the shrinking minority of content editors who contribute good, well-sourced verifiable edits to that area. -- a they/them | argue | contribs12:41, 4 May 2021 (UTC)
This seems reasonable to me. Obviously when someone has not expressed a preference, it shouldn't be used, but I don't agree that if someone expressed a preference it would always make sense to include it in the prose of the article. Also, because we use pronouns one way or the other, simply using pronouns doesn't imply an expressed preference. I would reject entirely the idea that specifying pronouns is in any way "social advocacy." It's something that some people do, and which Wikipedia tries to respect. An alternative to the infobox might be to have a template like {{use dmy dates}} (call it {{uses they/them pronouns}}) which would need a citation parameter and wouldn't affect article text beyond adding pages to a category for future editors to take into consideration. — Rhododendritestalk \\ 16:46, 13 May 2021 (UTC)
Back when people started advocating that everyone specify their pronouns, the people advocating it to me specifically said they were doing it as a form of social advocacy. Anomie⚔23:58, 13 May 2021 (UTC)
The current way we handle someone specifying pronouns is to dedicate a line of prose in the article about it. This is fine sometimes, but seems to present undue weight in some cases, especially as this becomes more and more commonplace. It sounds there are some objections about including pronouns in an infobox (I have mixed feelings, but this seems pretty clear for the time being). But what about a third way? When an article uses {{use dmy dates}} it doesn't affect article content; it just adds the page to a maintenance category and clarifies to future editors which format should be used. So I envision e.g. {{use they/them pronouns}} to function similarly. — Rhododendritestalk \\ 18:49, 13 May 2021 (UTC)
Allow related Wikinews original reporting in articles
Latest comment: 3 years ago14 comments13 people in discussion
I am a Wikinews and Wikipedia editor. I was not aware of a change that was made in 2018 that mainly restricted Wikinews links using Template:Wikinews to the bottom of the article/external link area. Previously, I had put my Wikinews articles within Wikipedia articles — for example, I put an article I wrote on the 2021 Kernadec Island earthquakes in 2021 Kermadec Islands earthquakes#Earthquakes. I understand why articles like this, which contain no new original reporting, and are based off existing articles that should, ideally, already be cited, have no need to be cited inline.
But, I don't understand why original reporting would not be relevant to the reader. The process of verifying, for example, interviews on Wikinews, is that the content is reviewed by a community reviewer before being published. In my experience, though mine is not universal, I conduct interviews via email, post the text of the email on the talk page, and forward the email onto a scoop email which I believe reviewers have access to. It's not a perfect process by any means, but I think it's a reasonable process to verify the validity of the content.
It also does provide additional helpful information to the reader. In the context of, again using my own example, an article on the 2020 Groom by-election, interviews with the candidates do help the readers, and it's useful to have it listed in the relevant section. Again, obviously there are limits to this. An article about the history of Australia, for example, doesn't need an inline link to an interview with an Australian historian. Common sense can be used. But I think that it can be helpful to the reader to have relevant Wikinews original reporting inline in an article. --LivelyRatification (talk) 02:46, 10 May 2021 (UTC)
That's my thoughts, yeah, that Wikinews is separate. Obviously if we added to the article "[x] candidate said [y]" using Wikinews as a source it'd be different, but we wouldn't be adding any material to the article prose, just pointing readers to original research done by one of our sister projects. To use another example, if information from a Wikivoyage article was put into a Wikipedia article verbatim, it'd be unreliable because it didn't cite any sources, but it's acceptable to link to articles in that project, even if Wikivoyage doesn't have the same standards of verification and sourcing as Wikipedia. --LivelyRatification (talk) 20:53, 10 May 2021 (UTC)
From my perspective wikinews seems to be an appropriate external link following WP:ELYES #3 since we can't incorporate the information because of our NOR policy but it is still relevant to an encyclopedic understanding of the proposal. On the other hand I quite agree with the 2018 RfC in that there really isn't a good reason for special highlightning of WikiNews links. They should imo be treated like external links like any other and go in the external link section, preferably without a large box. --Trialpears (talk) 21:06, 10 May 2021 (UTC)
Wikinews aims to be a news outlet, and we should treat it exactly the same as we treat every other news outlet, without any sort of favoritism just because it falls under the WMF umbrella. The 2018 discussion did that pretty well. What other news outlet gets its own template, or even placement in the external links section? The proper way to include Wikinews would be the same as the proper way to include any other news outlet—as a reference. That'd require establishing consensus that Wikinews is a reliable source, though, and I see at RSP that editors do not currently feel that it is. So sorry, but I do not see a path for Wikinews to be used on Wikipedia unless that consensus changes. {{u|Sdkb}}talk05:27, 11 May 2021 (UTC)
The article on Wikinews says that, unlike other Wikimedia projects, Wikinews allows original research. Since any reader of Wikinews can edit the site, would Wikinews be counted as a reliable source? Rollo August (talk) 21:38, 11 May 2021 (UTC)
The documentation at Template:Wikinews says clearly (though below the fold):
NDo not place this template in the main body of the article.
My personal opinion is that we should never direct people to Wikinews in any way. It's coverage is arbitrary original research, not professional journalism. I don't know why it still exists at all but we shouldn't direct people to it as if it is a reliable source or a real news organization. Beeblebrox (talk) 19:55, 12 May 2021 (UTC)
A big no Just as we don't cite other Wikipedia articles, we shouldn't use Wikinews as a source. ~ HAL33320:44, 13 May 2021 (UTC)
Oppose expanding the inclusion of wikinews in articles. Wikinews already gets a massive amount of preferential treatment due to being a sister project - no other external link gets an eye-catching template or near automatic inclusion in any vaguely related articles - we don't automatically include links to related news articles published by the BBC or The times in articles, for example. If we treated wikinews with complete fairness then any discussion on the reliable sources noticeboard or the external links noticeboard would most likely end with the site being judged unsuitable for use in articles and would probably result in the site being added to Xlinkbot for automatic removal. A site where anonymous contributors with no requirement to have any kind of journalistic training or skills can write "news" articles on anything, which are then published with editorial oversight being more anonymous contributors with no requirement to have any skills or experience as an editor is not the kind of site we should be driving readers to - it's little better than a Facebook page or a personal blog. The content on the site broadly falls into two categories: original reporting, which is unusable due to the lack of proper editorial control and hugely variable quality; and interviews, which are unusable in articles due to being primary sources - Wikipedia articles are not interested in what the subject of the article says about themselves. 192.76.8.91 (talk) 09:13, 14 May 2021 (UTC)
Latest comment: 3 years ago13 comments7 people in discussion
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.
Hello everyone -- I'm following up here to let everyone know that the Growth features are now available to test on English Wikipedia. They are not being assigned to any newcomers yet, but experienced users may turn them on in preferences to try them. We hope you try them out on desktop or mobile and leave any notes here (or on the project talk page). After a couple weeks, and after we iron out any issues, we plan to start giving the features to 2% of newcomers to get a sense of how they work on this wiki, and so that we can make plans for next steps.
To test the features, please go to your user preferences and then:
Just from looking, this looks amazing to give new editors who are motivated a way to get advice/help. Some questions I have:
Are the mentors randomly selected from all editors, or only those who intend to be mentors? If it is randomly of all editors, what is the selection criteria to ensure only editors likely to respond to new users are randomly given as mentors?
Will there be a way to select mentors based on the topic areas a new editor selects on the homepage, or based on their most common topic areas they have edited already?
"Create a new article" is currently grayed out for me - will this be expanded to at least allow for people to start on a draft as soon as they want to, regardless of "other steps" completed? I think this is likely going to push people away if it's "more steps" they have to do until they get a "new draft" option.
Will there be a way to "customize" the homepage to include links specific to topic areas? As an example, most new editors probably don't need to see WP:MEDRS and WT:MED - but for those interested in biology/medicine articles, those two links would likely be good to include on the homepage. Ideally, imo, this would be a subpage of WikiProjects that could be transcluded with guidance for WikiProjects on how to craft a short intro to their topic area.
Thanks for checking out the features, @Berchanhimez! I'm glad you think we're on the right track. Here are my responses to your good questions:
The mentors are selected randomly from a list of users who sign up to be mentors. For small wikis (e.g. Czech Wikipedia), they tend to only need something like five mentors so that the mentors don't get too many questions. Larger wikis, like French Wikipedia, tend to need more like 40 mentors. As we test the features here on English, we'll get a sense of how many mentors will be appropriate for the much larger flow of newcomers into this wiki. This is the English sign up page now, where we need just 5-10 mentors for the 2% test (and we don't want too many, because then it will be rare for each mentor to get questions).
The idea of selecting mentors on topic areas has come up a lot! I definitely think that's a good improvement and I'm glad you mentioned it.
Here's the idea behind "create a new article" being grayed out: many newcomers are trying to create a new article immediately after creating their account. It's one of the most common reasons people create an account. But we know from our research that the vast majority of them fail to create the article and end up having a bad first experience on Wikipedia. In our feature, we want to encourage newcomers to try easier edits before diving into creating a new article, and we put the grayed out box there because we know many of them of the newcomers are looking for where to create an article. We want to indicate that we know they want to create a new article, but we recommend against it. Does that make sense? What do you think?
I haven't heard this idea before, but I like it! We know that it can help newcomers succeed if they can find others who share their interests. I could imagine this being something like: after the newcomer selects their topics of interest, a module brings up links to the wiki communities who focus on those topics, and they can go explore. I filed a task here, so that our team can keep the idea in mind.
MMiller (WMF), appreciate the answers! On the topic of having a bad experience creating a new article, I think it's important to realize that many new editors their sole purpose for registering is to create an article of some kind - and in fact some of our new medical articles have been by new editors that we may be able to retain. I don't think limiting it is the best idea - having a mentor through creating a new article would be better in my opinion. I understand the position you're taking and I'm not wholly opposed to it because I mostly agree with you - most people have a bad experience with new articles - but the solution imo isn't to make it harder for them to do so but to be able to guide them more. I think guidance can help them realize on their own that it's not a good idea to create an article to start - and that will help them stay. Overall I really appreciate and agree with the responses here - and I think this is likely to be a good thing :) Thanks for the response :) -bɜ:ʳkənhɪmez (User/say hi!) 04:14, 9 May 2021 (UTC)
MMiller (WMF), yeah I think this may be best - because unfortunately, some people are just going to leave the tools completely and go back to the old way if they can't find a clear (not necessarily easy, but clear) pathway to their goal of a new article. Even a tooltip or hover-tip that says "creating a new article will be available through this tool after x" whether that's autoconfirmed, or whatever, would be helpful in my opinion. Alternatively, if the herding them towards "easier edits" in a topic area works well, it may be beneficial to just gray it out and the tooltip say "please ask your mentor for assistance in creating a new article as the process is not easy to automate in this tool" or similar - basically it takes the blame off of the tool, and encourages mentorship throughout that process. Tailoring the mentorship to specific topic areas, whether through automatic randomization based on WikiProject participation or similar will certainly make it more viable to gray out - i.e. the graying out won't just shove them back into the normal "I'm gonna do it anyway" mindset, but it'll give them a clear path. Is that something that's been considered - the automatic randomization based on a selection of topic area and related WikiProjects' participation/active user lists? I know some WPs are better at keeping those lists up to date than others, but it'd be a good integration of WPs into new editors. That way, the first question they're asked when they open it is "What topic area are you most interested in" - with perhaps some more sub-questions for areas with a lot of projects (ex: locale specific WikiProject focusing on a topic area, etc). -bɜ:ʳkənhɪmez (User/say hi!) 21:44, 11 May 2021 (UTC)
Thanks for these thoughts, @Berchanhimez! I like your idea of encouraging the newcomers to ask their mentors for help with creating new articles. I could imagine us adding something to the homepage nudging them to do that. And the idea of matching mentors to newcomers based on topics is something that has been brought up in many communities with the Growth features. One way we could do it is to ask mentors to select a few topics of interest when they sign up to be mentors, and it would be the same list of topics that newcomers choose from. Then we could match them up without relying on WikiProjects, but rather on a more recent response from the mentors about their interests. Do you think that would work?
I think this gets at a broader idea: as newcomers start their journeys, the more that people who share their interests can have eyes on their work, the more likely their work will be appreciated and nurtured.
I will say, though, that in the coming month's the Growth team's focus will be on building new "structured tasks" for newcomers to do. We'll also be working on "positive reinforcement" -- the features that help newcomers see the impact of their edits, feel proud, and then level up to more challenging tasks. For mentorship, the big upcoming improvement is the "mentor dashboard", so that mentors can see who their mentees are and how they're doing. That's all to say that I'm not sure when we'll be able to take action on the ideas we've discussed here about new articles and mentors, but let's keep thinking about it. MMiller (WMF) (talk) 20:15, 14 May 2021 (UTC)
Works great and looks good. Only concern I have echoes those of ProcrastinatingReader.... our target pages for more help should be the parent Wikipedia help page that is edited and overseen by the community. There are many concerns with the tutorial pages.... accessibility in mobile view..... sandwich text in destop view.... the need to click and load action butons to multiple pages to derive serviceable information. The tutorial has a serious editor retention problems. Moxy-02:36, 9 May 2021 (UTC)
Thanks for checking things out, @ProcrastinatingReader and @Moxy. I'm glad to hear things look good to you. For those help pages, we automatically populated them based on Wikidata, but they are totally customizable for this wiki. A few other people noticed, too, and we have a discussion going here about how to change them. Please feel free to weigh in so that we can make them the right pages for English Wikipedia! MMiller (WMF) (talk) 03:50, 9 May 2021 (UTC)
Redesigning the featured, good, and article assessment icons
Latest comment: 3 years ago82 comments57 people in discussion
This proposal is unsuccessful. This discussion was originally closed per WP:SNOW, but reopened after criticism about how quickly the idea was shot down. This proposal stems from an earlier village pump discussion that identified certain issues with the current FA and GA designs (e.g. the current FA icon's overly detailed design causes issues when rendered at small sizes, and the GA icon is used to mean different things in different contexts), but in this discussion, it's clear that there isn't consensus to adopt these specific proposed designs. There were a variety of objections ranging from simple preference (e.g. not liking silver/gray to indicate GA) to accessibility concerns (the use of color as the only distinguishing factor between FA and GA). Respectfully, Mz7 (talk) 18:33, 16 May 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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)
Support with the following reservations I highly doubt that non-editors will know what any of this means, nor necessarily should they. In any event, the interwiki list has (I think) silver for a good article in another language (see James Thompson (surveyor)) and gold for a featured article in another language (see World War II for several examples of this). I think the colors should be brought to those respective standards if not already done so. The former article/former candidate, etc., stuff doesn't belong as a topicon and should instead go to the talkpage, IMO. – John M Wolfson (talk • contribs) 21:16, 2 April 2021 (UTC)
I don't see anywhere suggesting that the former stuff would now be put on the article page (that would almost certainly require its own, separate proposal), I would assume their replacement is with their respective icons on the talk page. Aza24 (talk) 21:22, 2 April 2021 (UTC)
The former, candidate, etc. are only seen on on talk pages. You will only see the "Promoted" icons at the top right of the page. Pbrks (talk) 22:13, 2 April 2021 (UTC)
Support in principle Repeating my earlier comment: The icons should be changed to something the average reader is familiar with. The current icons are nice, but they're nice to Wikipedians. The average reader probably has no idea what this means. We should aim to use images which readers will understand. For example: silver star, gold star. A tick / double tick. Or something along those lines. It should be obvious to a reader what it symbolises. I'm not so sure about this specific set, though. ProcrastinatingReader (talk) 14:04, 3 April 2021 (UTC)
Support per Pbrks and Ivanvector (in the section below). The current icons are terrible at the size they're normally displayed. --Ahecht (TALK PAGE) 03:13, 12 April 2021 (UTC)
Support in principle, but there could or even should be some improvements. At first I was going to shoot this down because they lacked "atmosphere" and I have a spinal core reflex that goes against anything flat sans serif and iOS-fication designs, which I absolutely hate. Such things get created just because it looks modern without any concern to its purpose. But on a second thought I think they're really good and fits the purpose well. Since they're going to be small when in actual use, it's good that they're simple and have clear colours. Gold and silver for the top classes is brilliant GUI design, as well as simplifying the lineup and the design that hints in themselves of what it means, with a question mark for candidate no matter if first time or not, X for rejected, holed star for former and filled star for current. You need to work on the gold and silver hue though, it's a little too soft and blends in. For the other ones is it great with clearer hue and more contrast. The tilting on the current gives character but is also harder to see miniaturised. Serif typefaces are easier to read in small sizes, which is the point of serifs, so consider that. If you make a new batch with serif typefaces for the letters I'm sure you will gain more support. However for precisely all these reasons do I reject the proposed stub and start icons. The current ones are excellent just as they are, symbolises perfectly those classes. The new ones are cluttered and way too similar. A general criticism is that edges are too soft, they need to be accentuated, perhaps even have contour lines, at least the FA and GA icons. The question mark is slightly too big or too swollen, it comes too close to the ring at the top. --Mango från yttre rymden (talk) 23:57, 2 May 2021 (UTC)
Support. Come on, people. I get the criticism about the GA icon not being green and the stars in the new GA and FA icons not being too transparent, but the icons we are currently using are out of date and were made in the late 2000s, and they show. That's definitely something broken that needs to be fixed. I do like the 3D feel of the old FA icon on closer look, but the medal looks more bronze then gold, IMO, and you won't notice how 3D the icon is while reading a FA cause it's so small. I feel the new icon has a golder color. Plus, most of the new icons are the same color as the old ones anyway. They are also way more in touch with the current graphic design of most websites and commercial products today, and you know what happens to businesses that don't modernize. 👨x🐱 (talk) 20:19, 4 May 2021 (UTC)
Support with comment. As a (relatively new ?) editor, I can say that the proposed version certainly helps new editors get a quick understanding of what those icons mean. I just don't get to see much difference between a full star and a broken star when they are up there on some article. Plus, the new icons are uniform in nature and give a much cleaner and simplistic view, much in line with the modern graphic design as HumanxAnthro mentioned. However, I have some reservations with the two icons featuring the question marks, which feels as if it were an article on some unidentified subject. Moreover, maybe we can get some transition period wherein the old and new versions could be shown side by side, like, inside a rectangular box or something, so that older and experienced editors can get themselves accustomed with the new icons. CX Zoom (talk) 15:58, 13 May 2021 (UTC)
Oppose (article icons)
Where exactly is the need to replace the current icons with some hideous Web Whatever.0 design? How have I been running into so many "well, everyone in the tiny discussion on VPR supported it" lately? Why did we have a watchlist notice for the worst, most heat-over-light RfC I've seen in my life and yet no watchlist notices for "people want to restrict minor edits to the 99.8625th percentile of editors" or "people have decided the current quality icons are bad for some unclear reason" that have impact on actually writing an encyclopedia? How many of the thirteen people in the prior discussion are highly involved in the article quality process? Vaticidalprophet22:27, 2 April 2021 (UTC)
@Vaticidalprophet: The prior discussion was widely advertised everywhere of relevance short of CENT (including at the article quality forums). I sympathize with the feeling of coming across a discussion I would've wanted to participate in after it's closed, but the rationale behind changing the icons was thoroughly discussed and won clear support, and the process at this point has moved to the next stage. This thread is seeking to figure out how to change the icons, not if we should change them. Let's please not relitigate settled terrain; the whole point of the prior discussion was to resolve that part. {{u|Sdkb}}talk23:04, 2 April 2021 (UTC)
Never saw the discussion, and don’t see it as having any kind of broad consensus now that I have seen it. People, if you want to keep messing with content review processes at least notify them. This is make work. So while I’m here, Oppose the notion that any change is needed or helpful. SandyGeorgia (Talk) 23:38, 2 April 2021 (UTC)
Nor did I, and mildly alarmed to find myself on the "selection of people I might expect to have opinions"! I seem to have arrived here just in time to see the stern of the ship sinking below the waves, so I'll just say that on a quick look the proposal seemed uncompelling. As Martin Poulter says below, the main problem with our icons is that most readers don't know we have them, nor understand them. Can't see this changing that. Johnbod (talk) 03:05, 3 April 2021 (UTC)
With respect, this seems like a solution in search of a problem. Insofar as, right now, readers see the gold star or the green icon in the top right of an article and know that means the article has been through some kind of peer review (which, anecdotally, I know is a benchmark many non-Wikipedia users use, for better or worse, to assess the veracity of an article), why we would want to change that for the sake of our own design preferences is beyond me. Minor cosmetic changes that keep the basic gold star and green icon for the FA/GA classes are fine, but I strongly oppose changing the green icon to something that is a completely different color. GoPhightins!22:34, 2 April 2021 (UTC)
As well as thinking these changes are unnecessary, I view the symbols as being no more clear than the current ones, and in the case of the good articles, significantly less clear, as well as visualy unappealing. Nosebagbear (talk) 22:48, 2 April 2021 (UTC)
I don't think that the A–Disambig icons need to be changed. Just going to point out that with the change to flat, what about the other 10 icons that will be left with a shadow/3d, nothing quite like inconsistency. The stub/start will probably be harder to differentiate between since the icons are so small. I don't mind the FA/GA but I don't support replacing already acceptable icons. Terasail[✉]22:51, 2 April 2021 (UTC)
The though process was, if we indeed do come to a consensus for the FC/GA icons, then the other icons (A - dab, the other 10 you are referring to) would/should be changed for consistency. No reason we couldn't keep the start/stub icons the way they look now just without the drop shadow stylization. Pbrks (talk) 23:19, 2 April 2021 (UTC)
There was weak to no consensus for the idea the icons needed to change at all (I never saw that discussion), and this has all the same issues I mentioned back in the other discussion at Wikipedia:Village pump (proposals)/Archive 174 that was broadly attended. Pretty much, the changes aren’t needed, please go write and review some articles people; better yet, please initiate a badly needed GA sweeps. On the surface, it appears that the proposed icons are obscuring the fact that no other content review process except FAC is a community-wide process, rather one person’s opinion at one time, rarely re-reviwed, and seek to elevate GA to the same plane as FA by demoting the bronze star to a gold something the same as GA’s silver. Misleading. Others ahead of me, in this and both discussions, have explained the problems. Or, as Johnbod said once, Oppose per the Opposers. SandyGeorgia (Talk) 23:28, 2 April 2021 (UTC)
SandyGeorgia, "go write and review some articles" as a personal directive is absolutely inappropriate. People are allowed and should be encouraged to constructively edit Wikipedia however they like. If that's writing articles, great. If that's anti-vandal work, great. And if that's trying to improve the icons we use, great. Be kind and show some respect. Ed[talk][majestic titan]14:14, 13 April 2021 (UTC)
I think the proposed logos are not only less clear (grey question mark in a circle means "Good Article Candidate" -- really?), but too childlike and less visually appealing. — Goszei (talk) 23:36, 2 April 2021 (UTC)
Sorry. Respect the effort you've put into this; I understand design is difficult... but I don't like the new icons, particularly for FA. It's generic and fades into the background at small scales. I don't think there's enough padding between the star and the border. I might support a change to the GA icon, but not sure this is the right one. It's unclear what is being communicated to me by the stub and start icons. The changes to the others are fine, but minor. — The Earwig (talk) 23:37, 2 April 2021 (UTC)
I don't know about these. I agree that, overall, the icons used on Wikipedia might benefit from some kind of comprehensive review. For example, the fact that "good article" and "support vote" use the exact same image is a profoundly dogshit situation. Who decided that was a good idea? The distinctions between "FA candidate", "former FA", and "former FA candidate" are also bizarre and non-intuitive (to someone who is not a hardcore Wikipedia editor, these all look like random injured starfish). Moreover, the scale of quality goes magenta, dark green, red, orange, yellow, green, blue, green, yellow. While I agree that some change ought to be made (and there should be an enormous watchlist-pinging WP:CENT about it with several suggestions for icon schemes), I don't think it needs an update, and this one in particular doesn't really spark joy for me. Notably, the "silver" being used to denote GAs is... that doesn't look silver, it looks gray. Also, it removes some good stuff: right now, the jagged former-GA icon very clearly shows that it was a GA and then was "broken", whereas a little dotted star shows nothing. jp×g23:59, 2 April 2021 (UTC)
I don't think the proposed icons improve over the current ones aesthetically, but there are also more serious problems. The use of a question mark is too firmly associated with DYK and should be kept out of FA/GA icons to avoid confusion. Moreover, the proposed FA and GA icons have exactly the same geometric design and are distingished only by colors. IMO that already renders the entire proposal unacceptable. A substantial portion of our readers are color blind. They will face a great difficulty in telling the GA and FA icons apart and some just won't be able to do so. The FA and GA icons need to be clearly geometrically different from each other, and one should not have to rely on the color scheme to tell them apart. Nsk92 (talk) 00:06, 3 April 2021 (UTC)
I like the icons myself, but I must oppose the changing of the GA palette to gray. It does not and will not stand out against the default white background of Wikipedia. It must remain green. –♠Vami_IV†♠00:17, 3 April 2021 (UTC)
Comment Here's an icon for "Rearranging deck chairs on the Titanic": . EEng03:26, 3 April 2021 (UTC) P.S. Someone's calendar is off. This came a day late for April Fools.
Oppose. "Ain't broke, don't 'fix' it." One obvious problem with the extreme anti-skeuomorphism that is the current trendy fashion in UI (but which is already seeing a lot of pushback and probably won't last long), is that it can't visually represent gold and silver, they just come out as yellow and grey, since adding white and dark highlights to simulate metallic shine is not possible in an anti-skeuomorphic approach. And grey in user-interface design means "disabled, unavailable, or inapplicable". So, FAIL. — SMcCandlish☏¢ 😼 05:30, 3 April 2021 (UTC)
Oppose: I do not see a strong enough reason to change the icons. I think Nsk92 raises some very good points about this. Aoba47 (talk) 06:20, 3 April 2021 (UTC)
oppose - some of the individual logos aren't fantastic, but the suggested ones are significantly worse. I'm not here to say that everything we have is perfect, but maybe we should update an image at a time? I agree that the difference between a former featured article, and a failed featured candidate is a bit odd, but then these are generally only used in templates next to where it rights what it means. I do think we would benefit from explaining to users what a good and featured article is (when I first used the site, I got what "stub" and "featured" was, but not much else), but changing the logo designed doesn't help. Best Wishes, Lee Vilenski(talk • contribs)07:26, 3 April 2021 (UTC)
Oppose. Whatever consensus was reached at the previous discussion, the number of opposing opinions here suggests that it is not very strong. The previous discussion should have been advertised better (i.e. at RFC or CENT). – Finnusertop (talk ⋅ contribs) 08:47, 3 April 2021 (UTC)
Oppose - this seems to be a solution in search of a problem. I'm not entirely sure what changing the icons will accomplish. ƒirefly ( t · c ) 09:41, 3 April 2021 (UTC)
Oppose at least for now, I want to see the actual proposed image files (see discussion section below) - looks like we only have a picture of the pictures so far? Also, agree that greyscale icons aren't as useful. — xaosfluxTalk10:23, 3 April 2021 (UTC)
Oppose. I am not against changing the icons in principle, although I would want to see much fuller discussion, but the suggested alternatives are hideous. And I agree with the comments that this all seems to be a solution in search of a problem; for example, "the overly detailed FC icon, which causes it to render poorly as small sizes" - I have it at 15px on my user page and it looks fine to me.Gog the Mild (talk) 12:26, 3 April 2021 (UTC)
Oppose. I don't think that the consensus achieved at that October 2020 thread is very strong, judging by the response here. As for the actual proposed icons, gray does not mean "positive" or "good", that's universally green. Question mark is for help. The proposed stub and start-class symbols are too similar. As an aside, I can't wait for this current trend of over-simplifying symbols to go away soon. RetiredDuke (talk) 13:20, 3 April 2021 (UTC)
Opposed (echoed). A consensus of eight is insufficient to change the mechanisms—however superficially—of multiple, highly active projects. Regardless of whether This thread is seeking to figure out how to change the icons, not if we should change them, it looks like you arenow enjoying a consensus to overturn a consensus. Land ahoy! ——Serial13:30, 3 April 2021 (UTC)
Oppose. I didn't want to have to write here, but as it has been reopened I guess I will. I'm not set against the idea of changing the icons, although I equally don't really see a need to do so as I don't really find any of the reasons given particularly convincing (for much the same reasons as the others). However if you do still feel the need for change, work out what your design goals are, talk to the folks at Wikipedia:WikiProject Accessibility and follow their advice about how to make your ideals compatible with best practice. Only then will it be worth getting the pencils out. Thryduulf (talk) 17:46, 10 April 2021 (UTC)
Weak opposeI agree with Thryduulf there is no real need to revise most of these. However, in my humble opinion, i think you made fair points that the FA article's icon goes to waste as you cannot see the full details. I'll mention my opinions in detail on what should be done.Blue Pumpkin Pie (talk) 18:07, 10 April 2021 (UTC)
Oppose such a big change should come after a well advertised discussion involving a large number of editors. This is not the way to make such changes that affect everyone. Also the proposed new icons are ugly. --Ita140188 (talk) 05:38, 13 April 2021 (UTC)
Oppose I'm happy to have the icons improved. But I prefer the current set to the proposed new ones. A system of Gold stars for FAs and silver for GAs would make sense. But the most common hierarchy is gold, silver, bronze, so bronze then silver would be confusing. ϢereSpielChequers12:03, 15 April 2021 (UTC)
Oppose I have no problem with the current icons, but it would be fine if they were modified. However, it's not just to the editors that spent their own time making the icons to have them replaced with logomakr.com stars. Lettlerhello • contribs01:28, 22 April 2021 (UTC)
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)
Oppose the proposed set of icons over the current set, but would support maybe a different improved set over the current set. If my feedback helps, it was my dislike for the gray, and the way the stub, start class, and question mark symbols left me wondering what they were supposed to represent that swayed my decision. Huggums537 (talk) 05:42, 1 May 2021 (UTC) On a positive note, I like all the rest of the proposed icon set. Change the gray to some other color-blind friendly color, choose different symbols to replace the question mark, and represent the start/stub classes and I'm on board... Huggums537 (talk) 05:57, 1 May 2021 (UTC)
Discussion (article icons)
@Pbrks: (or anyone) can you make a table of before/after for these - that has been quite helpful in similar discussion about icons. — xaosfluxTalk21:18, 2 April 2021 (UTC)
@Pbrks: do you have these as actual files that are already uploaded that can be in a normal table instead of a picture of a table? — xaosfluxTalk23:45, 2 April 2021 (UTC)
I agree that the icons we use need to change and that they don't make much sense to casual users of the site, which is a loss because markers of quality are really important fo a critical engagement with Wikipedia. When I give training, it is almost always completely new information to people that Wikipedia even has a quality scale. I like the "promoted" and "former" icons, since "gold star" and "silver star" seem like a visual metaphor that people can understand from an early age, across a lot of contexts. The Featured buttons could be in a deeper hue to stand out more, but that's not much of a change. That said, the Candidate icons with a question mark in a circle, look like a "Help" or "Info" icon that a user would click on to get help with the user interface. The Former Candidate icons with a cross look a lot like the "Close tab" or "Close application" of some interfaces: buttons that a user would click to make something disappear. I can see what the List icon represents, but it looks an awful lot like the hamburger menu which is a very common navigational feature of web sites, and is the sort of thing that a user would click on to see a list of preferences or options. These potential confusions mean I can't support this iteration of the proposal, but I do think it is going in the right direction. MartinPoulter (talk) 21:26, 2 April 2021 (UTC)
The star outlines for former featured/good status are very thin—at small sizes I'd guess these are essentially just empty circles, which is presumably not the intention, right? I'd make them thicker. Even a full border (but hollow interior) would be visually distinct enough from current featured/good. At some point it would be good to play around with the individual image files in a sandbox, which you can't easily do with the icons all as one image, though I understand mass uploading of all the icons could be a bit tedious. — Bilorv (talk) 21:31, 2 April 2021 (UTC)
I don't oppose the concept of people designing new art work, allow editors to edit to their strengths. Just because something is new doesn't mean it's bad. I'm not a fan of the "Start" and "Stub" icons, may want to come up with something a bit different there. I don't see any ships sinking, deck chairs being rearranged, and I certainly wouldn't insult someone for proposing an idea as an April Fool's joke. Perhaps just in an effort to get some sort of "social capital" in the name of humor? But, as they say, YMMV. — Ched (talk) 07:16, 11 April 2021 (UTC)
Taking a step back
I started this proposal after a closure request for the previous one decided that the outcome was fairly self evident with support ... editors interested in taking on this work have a mandate to do so. and the request moved forward at the Illustration workshop. It's fine that Prop 1 wasn't held in high regard, but it's just a proposition -- things can be changed, style can be changed. However, it's a bit disheartening and demoralizing to get comments of hideous Web Whatever.0 design and to go write and review some articles instead. I don't understand why people can't just give their opinion without being nasty about it. It's human nature to resist change, I get that, but the fact remains that this renders terribly at 20px and has literally confused people in the past, as it also is used for the "support vote" symbol. Moreover, the subicons for these (particularly the GA icon) don't make much of any sense. The former FC icon has a unsightly, stylistically different "X" through it. The reassessment icon is a broken GA icon? The former GA icon is the same as the former GA candidate icon ? All three of the aforementioned are the same except for color (in which Nsk92 makes a good point about color blindness)? To believe that nothing needs to be changed is beyond me. I don't see much of a reason to move forward with any different kind of proposition given the previous comments. Pbrks (talk) 05:31, 3 April 2021 (UTC)
The only argument of the bunch that rings in any way true to me is 's ambiguity, and even that I'm skeptical about -- the only real context I ever see it used to denote support votes is...GAN, where it in fact makes perfect sense. Is hyper-anti-skeuomorphism and a redesign ten people asked for really a better solution than "rename " or just straight up "we have a million support vote symbols, some will overlap"? It's also honestly bizarre to me that the previous proposal was closed as a mandate when it had no participation from the people highly involved in the relevant process, many of who have since come out in strong opposition. Vaticidalprophet06:17, 3 April 2021 (UTC)
(Addendum: readers interested both in the 'million support vote symbols' comment and in why trying to redesign Wikipedia's house styles for icons is both a huge job and a thankless/anti-thanked one are pointed here.) Vaticidalprophet06:25, 3 April 2021 (UTC)
I just responded to the "go write and review some articles" comment. As a personal directive, it's absolutely inappropriate. People can (and should!) constructively edit Wikipedia however they'd like. Ed[talk][majestic titan]14:19, 13 April 2021 (UTC)
I appreciate your efforts in design, Pbrks, even though I don't support the change. The rudeness in this discussion towards you was particularly blatant and unacceptable. — Bilorv (talk) 22:08, 19 April 2021 (UTC)
Class icons B, C, Start, and Stub don't need to be revised as their icons aren't visible on the article or talk page. I do think Good Article and Featured Articles are great milestones that need to be highlighted in the article. I like the Gold-Star, Silver-star because they can illustrate to both readers and editors that they are the cream of the crop. Especially with a Silver Star instead of a Green Plus symbol can give editors an indicator that it's almost a Featured article (Gold Star). But the recreated icons don't stand out enough for new readers to notice or for editors to care about. If the icons are going to be revised, they have to be visually appealing and something that readers/editors can approve of.
I googled the words "Quality" and "Icon" and I found a lot of metals with ribbons attached to them. We can have a gold jigsaw puzzle to indicate the Featured article, and a silver jigsaw puzzle to indicate Good Article. I'm just being creative at the moment. So long as these icons shine and stand out positively, then maybe editors may support the proposal more. The dotted line forming a star isn't clear to me, and the Question mark resembles the DYK icon. I think it would be easier to use a magnifying glass over the current icons for representing re/assessment. The current Red X and Broken GA (in my humble opinion) are upsetting and can be discouraging. The red-painted cross over the featured article and the broken GA symbol is just not professional icons in my opinion and even look like there's anger involved.Blue Pumpkin Pie (talk) 20:11, 10 April 2021 (UTC)
Personally, there are just a handful of reasons for me personally to support this, and the main one is that this is more enticing to readers. Sure, many Wikipedians don't care about "Web 3.0 minimalist design", but a lot of casual readers expect it, especially on a highly visited site like WP. EpicPupper (talk) 04:41, 9 May 2021 (UTC)
Licensing
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)
Post-close
It's regrettable that a constructive idea was shot down so quickly (less than a day!) and for such poor reasons. Sometimes it's good to discuss new ideas even if they're not immediately going to fix an urgent problem, we might uncover issues that the early knee-jerk WP:AINTBROKE crowd hadn't thought of. And frankly our FA icon at topicon resolution (where readers normally see it) looks like it was drawn on the back of a napkin with a sharpie and digitized with one of those old hand-held roll scanners, or else shrunk from its original size down to 10px and then scaled up again. Putting this blighted icon on a featured article makes the article less good. I realize it's what readers and editors are used to, but that's not a good enough reason on its own to keep it, and certainly not to shut down a discussion about it after just over 18 hours. Just a plain bordered star in the same colour would be not so much of a departure from the current icon as to be confusing, and would be a fair improvement. But I guess nobody wants to talk about improving the encyclopedia. Ivanvector's squirrel (trees/nuts) 19:22, 8 April 2021 (UTC)
I agree. Since the close mentions SNOW, I also want to point out this section of the essay saying: "It can sometimes be better to allow a few extra days even if current discussion seems very clearly to hold one opinion, to be sure that it really will be a snowball and as a courtesy to be sure that no significant input will be excluded if closed very soon." In general, I like the proposed designs for FA and GA (though agree that the good-article-grey is a bad color choice). They read much better at small sizes, are symbolically more clear (an absent star and question mark are a lot more intuitive than the existing symbols), and the style matches the recently redesigned protection icons providing a more unified design. I hope we can give these ideas more serious consideration next time around. — Wug·a·po·des23:29, 8 April 2021 (UTC)
Agreed, though the proposal in its fullest form might be seen a snow close, a lot of opposers offered sympathy for specific improvements. The latter is valuable information that could thoroughly inform future discussions, but has been halted unnaturally. Aza24 (talk) 23:34, 8 April 2021 (UTC)
I disagree - this specific proposal was correctly SNOW closed because it was very clearly never going to get a consensus. There is nothing stopping you or anyone else going back a step or two and initiating a discussion to generate a broad consensus for the need for change (which hasn't yet occurred). If there is a consensus for change, then the next step is to workshop multiple designs, implementing the results of feedback received, before presenting a small number of well developed proposals for adoption. Getting more of the same feedback on this proposal and more reminders about the lack of consensus that a need for changes exists is not going to help that. Thryduulf (talk) 17:12, 9 April 2021 (UTC)
Yes, how terrible for Wikipedia that someone with an idea wanted to talk about it, but didn't get permission from The Community first. What a sterile, needlessly bureaucratic place this is becoming. Ivanvector's squirrel (trees/nuts) 12:55, 10 April 2021 (UTC)
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)
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)
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)
A bit late, but I'd suggest reaching out on wikitech-l. There used to be a specific design mailing list, but it's not really used these days. Legoktm (talk) 07:35, 16 May 2021 (UTC)
I'm not sure the reopening here will really help. Putting together the prior discussion and this one, my read is that there's substantial discontent with the current icons and weak consensus that they ought to be changed, but also fairly clear consensus that the specific proposal here isn't yet ready to be adopted. I think the best path forward is to take a step back and work on refining the design, and then come back to a prominent venue when that is ready.
The 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.
Latest comment: 3 years ago13 comments8 people in discussion
As many will know, User:SlimVirgin has passed away. There are a little over 120 subpages in her userspaces, some of which are drafts for articles or collections of notes. Many are currently blank but have substantial edit history of past draft work. Someone should curate these pages. If she had drafts in progress, her intent may have been to eventually work these into articles. BD2412T02:19, 10 May 2021 (UTC)
Fortunately there is no deadline for userspace pages. If she had anything in progress in draftspace though it would be best to work on them before they get G13ed - I don't know what happens regarding notifications for users who've opted out of bot messages? Thryduulf (talk) 02:39, 10 May 2021 (UTC)
True, but my point was that before worrying about what to do with pages that have no deadline, ascertain whether there are any that do and, if so, work out what you want to do with those first. Thryduulf (talk) 23:08, 10 May 2021 (UTC)
I appreciate your note to let us know. by the way, some of those pages are actually empty, with no content. is it okay to delete those? it would be a bit convoluted to sift through the edit history of each page, wouldn't it? ---Sm8900 (talk) 🌍 23:14, 10 May 2021 (UTC)
Yes, in retrospect I would think those pages, having been blanked by SV, would be ripe for deletion. If SV had wanted their edit history to be noted somewhere, she knew how to do that. BD2412T23:23, 10 May 2021 (UTC)
Why is there a need to do ANYTHING with her sub-pages? I say just leave them alone ... untouched... forever. Blueboar (talk) 13:42, 15 May 2021 (UTC)
I assume the need/desire is to ensure that the assuredly-high-quality content in her user space becomes living wiki content, per our encyclopedic mission. Izno (talk) 03:30, 16 May 2021 (UTC)
Not so much a need, but an opportunity for anyone who wants to collaborate one more time with the editor. isaacl (talk) 04:40, 16 May 2021 (UTC)
Latest comment: 3 years ago2 comments2 people in discussion
This proposal would need much more development for even a subset of it to be implemented, moving this to Idea Lab to avoid just snow-closing this. — xaosfluxTalk14:00, 19 May 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Citations
Latest comment: 3 years ago5 comments4 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I think the ability to be able to select and place "citation needed" through the cite feature in the visual editor with a single click would be helpful. Not needed but it would save time. TigerScientistChat > contribs21:05, 18 May 2021 (UTC)
Copy the following text and paste it in any article: {{cn}} This will simply work with the visual editor in the way you're requesting. ~ ToBeFree (talk) 21:09, 18 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Minor edits
Latest comment: 3 years ago5 comments4 people in discussion
I sometimes forget to toggle minor edits. Maybe the a bot or something automated can automatically determine if it is minor or not. It is already pretty simple so I can see why people wouldn't want to put so much effort into this. TigerScientistChat > contribs20:00, 24 May 2021 (UTC)
Bots don't have the technical ability to change the minor tag of another person's edit (I think), so this is technically impossible. The MediaWiki software could, but it'd probably be a fair bit of work to cook up a decent algorithm to predict whether an edit is minor or not. ProcrastinatingReader (talk) 22:41, 24 May 2021 (UTC)
Per the instructions that this page is for concrete actionable proposals, brainstorming like this belongs at the idea lab, not here. To address the idea directly, this is a bad task for a bot, since our definition of WP:Minor edit is whether or not an edit is potentially controversial. Massive edits can be minor if they're just reverting vandalism, whereas single-word edits to hot topics can be very not-minor. {{u|Sdkb}}talk00:25, 25 May 2021 (UTC)
This belongs in the idea lab rather than here since this isn't a firm proposal that you want implementing, but this isn't possible for two reasons:
It's impossible to edit the minor edit flag once a revision has been saved, it's permanently burned into the database, just like the edit summary, timestamp and revision ID.
Just like your suggested link bot this program would need to have near human intelligence to determine what is a minor edit or not. Removing a large chunk of text added as vandalism is a minor edit, removing a large chunk of text because it is undue is not. Replacing a dead link in a citation with an archive link is a minor edit, replacing a dead citation with a different site is not. Replacing a number in a table because the previous editor made a typo copying it from a source is a minor edit, replacing a number in a table with a more recent one from the same source probably is not. Removing a Bengali name from an article where it is completely misplaced (e.g. Computer) would be a minor edit, removing an armenian/azeri name from a place in Nagorno-Karabakh would not be.
Your proposed bot would need to be making editorial judgements about what is "uncontroversial" - that is something that would essentially require a AI. 192.76.8.73 (talk) 09:43, 25 May 2021 (UTC)
Highlighting system
Latest comment: 3 years ago10 comments6 people in discussion
Recently I have been copyediting some Wikipedia articles and fixing grammar issues, however I have noticed that the templates don't specify where is the issue in the article, and it becomes a tedious problem in a long one. I was just wondering about proposing a new system in which editors can highlight the actual issue in the articles, so that way it becomes easier to find the paragraph or sentence that needs to be fixed, especially in lengthy articles.
Pink Saffron (talk) 16:54, 18 May 2021 (UTC)
A template "language problems" and another one called "spelling issues" might be needed yes.
I think something like this would be a good idea. Two things I dislike: 1)- a tag that is vague with no obvious issue and nothing on the talk page. Maybe it is just too much work to travel all the way to the talk page. A simpler system to go along with a tag might certainly make a difference, 2)- A career tag dated 2007 (any tag in the 3-year range) and many edits and editors since then until now. If I can't find the issue that a tag is supposedly used for I have removed them with talk page comments. I have also sent messages to the editor that placed the tag. All of this creates a longer maintenance time for each article and less available time to look at more articles. Otr500 (talk) 19:00, 18 May 2021 (UTC)
@Finnusertop: That's glad to hear! Thanks for notifying me
Too bad they are not used as much as they should be. We can turn on highlighting editing that I think would be of less importance than highlighting issues. Of course, some talk page comments would go a long way. Otr500 (talk) 01:12, 19 May 2021 (UTC)
I am generally in favour of more specific marking of tagged content. Pale highlighting could work. Explanation/reasons could be added via edit summary. Might be good to leave a mouse-over to show the reason and identify the tagger as well. · · · Peter Southwood(talk): 15:37, 19 May 2021 (UTC)
If the highlight only show up on mouse-over of the tag they would be less obtrusive, alternatively they could require an opt in setting to be default visible. · · · Peter Southwood(talk): 15:42, 19 May 2021 (UTC)
I'd honestly think a more suitable addition would be a more aesthetically pleasing highlighter marking so that it doesn't look like a blushing tomato Pink Saffron (talk) 17:40, 19 May 2021 (UTC)
I think that the best system would be to return to what I'm sure there was when I started editing Wikipedia - that there should be an expectation that, unless the issue is blindingly obvious, the tagger should state their concerns on the talk page. It is unlikely that this will actually happen, because many people who add tags seem incapable of doing anything that is not automated by Twinkle. We really need to stop valuing quantity over quality. Phil Bridger (talk) 18:23, 19 May 2021 (UTC)
I agree 100% (see above). Career tags that were only clear to the tagger at the time serve little purpose. Another solution is to just delete the tag with talk page comments. -- Otr500 (talk) 04:36, 28 May 2021 (UTC)
Edit filter for AWS URLs that expire
Latest comment: 3 years ago11 comments6 people in discussion
This is a proposal to create an edit filter to block the addition of URLs that pull content from AWS with an expiration time. Example (search on &Expires)
URLs of this type can be identified if they include &Expires=1621985387 where "1621985387" is a unix timestamp seconds since 1970 (converter). The expiration time is often 1 hour or less, after which the URL ceases to function and becomes link rot.
I set up a program to monitor for new inclusions, and issue a SavePageNow at Wayback before it expires, however this is not really working well: the URLs are often already expired by the time the content is committed to Wikipedia and/or the URL was copied from another page or revision and long since expired and/or the program which runs twice an hour doesn't catch it in time and/or the content also requires a password/login which Wayback can't get beyond.
There were old cases in about 550 pages, I ran a bot and checked for working Wayback links to "save" them, it found 35, or about 6% were salvageable the rest were permanently dead with no hope of saving. New one's are being added at about 5-7 a week. These URLs can usually be substituted with more permanent links to the same content (example) - but users will continue to add these links because they work in the moment and there is no realization they expire. -- GreenC00:31, 26 May 2021 (UTC)
So why? What should the editor use instead? WP:SAYWHEREYOUGOTIT says to do just that. Now, it could be that these are just purley unreliable sources - and that would be a reason, and the deny reason could tell the editor why. Basically, if we want to deny this on a basis that they are always bad, it needs to be coupled with a message of why this is an unacceptable source. — xaosfluxTalk00:42, 26 May 2021 (UTC)
The source (ie. citation), and the URL, are different things. URLs are not required in a source, they are optional. Unclear why we are knowingly adding dead URLs that can never be archived, taking up the |url= spot. -- GreenC01:50, 26 May 2021 (UTC)
Is it dead on arrival? What if it "expires" in 20 years - does that make it useless for readers now? In the example you put above, if the editor would have left that blank instead of putting in that cloudfront.net link - wouldn't it have been worse for a reader or other editors? — xaosfluxTalk10:50, 27 May 2021 (UTC)
Sounds like a good idea. Mathglot recently raised a similar issue with library proxied URLs which could maybe be addressed with an edit filter as well. We should't stop people copying and pasting an unstable URL from their address bar instead of the permalink from the page, but it wouldn't hurt to have an informative warning telling them it's a bad idea. – Joe (talk) 11:05, 27 May 2021 (UTC)
Filters can be requested at WP:EFR, but I think this falls into bad use for a filter, because the filter should mainly be used for abuse, not to enforce possibly 'bad' edits. A bot would be preferable, if there's consensus. ProcrastinatingReader (talk) 13:25, 27 May 2021 (UTC)
I agree that a bot would be better, or even increased frequency if one already runs. Edit filters run on every edit which is a lot of work for little gain, so it might be better to fix it after the fact or notify those who added it (like disambiguation links) rather than check every edit for expired links. — Wug·a·po·des20:27, 27 May 2021 (UTC)
Reverting to a stable version of a page, to stop continuous editing of a section, while it is being discussed on a Talk page section
Latest comment: 3 years ago28 comments10 people in discussion
I wanted to ask about the practice of reverting to the previous stable version of a page, while the content of a page is being discussed.
I have seen this in practice, where a talk section is established to discuss specific article content, (or an RFC) – and while it was going on, editors were asked to not make changes, and the page was reverted to the long standing version of the page that reflected the section that was being discussed. Then after the consensus was achieved, the page was changed to reflect the decision of the consensus.
The point of this being (1) it stopped random editors who were making changes to the section (with the possibility of starting an edit war) rather than being part of the discussion (2) reverting to the stable version meant that people coming to the talk page discussion, could see the content on the page that was the subject of the discussion.
There’s no rule about this that I could see, I have seen this done, and assumed it was normal, but is this common practice on Wikipedia?... If not, is it a good idea?... I would appreciate your thoughts Deathlibrarian (talk) 02:18, 25 May 2021 (UTC)
WP:BRD and WP:STATUSQUO may be relevant here. BRD refers to the bold, revert, discuss cycle, where someone makes a WP:BOLD edit, which is reverted, then a discussion should be started instead of the bold edit being reinstated and beginning and edit war. STATUSQUO refers to leaving the status quo ante while the issue is being discussed, so the first, stable version remains until the issue is resolved. —El Millo (talk) 04:22, 25 May 2021 (UTC)
Ah, ok, brilliant, thank you! That may be the policy I couldn't find. It looks like the editors were in fact following this policy. I'll have a read, cheers. Deathlibrarian (talk) 04:43, 25 May 2021 (UTC)
WP:STATUSQUO has very wide acceptance, but unfortunately it's located within an essay, not a policy or guideline, so I've occasionally seen WP:NOTPOLICY raised in response. It'd be nice if we rectified this. {{u|Sdkb}}talk16:48, 25 May 2021 (UTC)
Yeah, "During a dispute discussion, until a consensus is established, you should not revert away from the status quo" I've seen people do it and assumed it was standard protocol, but when I did it, I got called out on it and couldn't find the policy for it. Thanks so much, that was driving me nuts!!! Deathlibrarian (talk) 09:01, 26 May 2021 (UTC)
Depends very much on the context. If it's a current event and being heavily edited, this isn't sustainable. If it's a historical event on a mostly stable article, then this is a good idea. And then there's all the in between. Generally it's less contentious and more collaborative to revert to a revision that once had consensus, or is less controversial, while one works on building consensus for the change. ProcrastinatingReader (talk) 12:07, 26 May 2021 (UTC)
I rarely find that focusing on what past version might be "stable" to be useful once other editors are involved in talk page discussions and it's clear that editors are disputing content based upon content policy. Hence WP:WRONG VERSION.
But if you really want to know good practice, a few additions to what's above: Stable versions should generally be free from disputed content, especially if the disputed content was recently added and there's no strong consensus for it as expressed on the article talk page.
Consensus can change: It's usually best to focus on creating a stronger consensus than identifying a past "stable" version.
WP:LOCALCONSENSUS: Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. Focusing on a "stable" version can easily become a LOCALCONSENSUS violation, when policy-based arguments are being deferred in order to decide upon what past version may have had "consensus".
In the recent edit-warring situation that Deathlibrarian was involved (here), the so-called "stable" version in dispute was created by Deathlibrarian [4] and there was no associated discussion at all. To argue that there was consensus for this version misses what consensus means when faced with policy-based objections, and comes across as ownership. --Hipal (talk) 15:42, 27 May 2021 (UTC)
As other people have said, WP:BRD and WP:STATUSQUO are relevant, though note that they are just essays (albeit ones with a lot of support.) Technically the relevant policy is WP:IMPLICITCONSENSUS and Wikipedia:Silence and consensus; longstanding material that has existed without disputes or objections for an extended period of time is presumed to enjoy consensus, so it's reasonable to roll back to it when consensus is otherwise unclear. But note that there are a whole bunch of considerations. For clearly WP:BLP-sensitive issues you have to default to the "BLP safe" version, for instance; and if current consensus is clear then it overrides older implicit consensus. Also, it's incorrect to say that you have to revert the entire article back to that state - only the part that is actually contested. If there's a bunch of uncontroversial edits to the page that nobody is objecting to, they enjoy WP:IMPLICITCONSENSUS too and you shouldn't just revert them away; part of WP:PRESERVE means not discarding stuff nobody objects to with a sweeping revert in a situation like that. But in complex situations (eg. lots of people editing a disputed section at once in different and not-easily-compatible ways) there's sometimes no alternative but to revert the whole section, especially if you're not confident about declaring any recent edits uncontroversial. --Aquillion (talk) 16:19, 27 May 2021 (UTC)
The problem with implicit consensus is that in many of our articles, "implicit consensus" and "obscure article with a major problem no one noticed for years because it is obscure" look identical. It works only on high-visibility pages. It doesn't work everywhere, and we shouldn't take longevity as the be-all-end-all in determining consensus. --Jayron3216:31, 27 May 2021 (UTC)
Oh, yes, implicit consensus is the weakest sort of consensus and even its limited strength depends on whether many eyes have actually seen and accepted the edit in question. That said, when there's no clear other consensus (and it's not a WP:BLP issue or something), implicit consensus is better than nothing. And, I mean, ultimately - if the problem is major, but you can't get a consensus that it's major or even a consensus for a quick temporary fix, then it may not be as obviously a major problem as you think. (If you disagree, of course, that's what noticeboards are for - I'll agree that many of my most frustrating interactions on Wikipedia have been intractable disputes on pages with very few people watching them, dealing with 1-on-1 disputes where the other person just said "no" to almost any change I proposed, with nobody else there to hash out a consensus. But that's when you go to a noticeboard to gather more opinions, or an RFC if you think the issue can wait long enough or are confident it will WP:SNOW out. There's a reason we have noticeboards for the most pressing types of issues. In all but the most serious of situations it's usually fine for the page to remain where it was for at least a bit longer while those processes proceed, and if it is a serious situation, bringing it to people's attention on a noticeboard should immediately produce a consensus to fix it.) --Aquillion (talk) 17:33, 27 May 2021 (UTC)
I suppose my bar for 'serious issue on a BLP' is lower than most. I'd say any content that seems questionable (per our core content policies; such as being made up, misrepresenting sources, or being blatantly biased) and may have the effect of damaging the reputation of a BLP is a serious issue. Using this definition, I've seen 'serious issues' (IMO) be reported at WP:BLPN and have little to no response for weeks. ProcrastinatingReader (talk) 10:58, 28 May 2021 (UTC)
I feel that it is often difficult for someone to judge the severity and significance of an issue while they are embroiled in it, but I will point out that there is always another option. If something is a clear-cut, unambiguous BLP violation, WP:BLPREMOVE empowers you to remove it instantly, and remove it again if restored, as often as necessary, without regard for the WP:3RR (and, indeed, if someone persists in restoring it, it's probably a matter for WP:AE anyway - someone who is doing that ought to be made to stop somehow so they don't just do it on another article.) Obviously, taking that route requires putting your own editing rights on the line - as it should, since we don't want people invoking it frivolously; ignoring 3RR and the prohibition against edit-warring is a big deal. If you're not confident enough to take that step then you might want to consider the possibility that the situation is not as severe as you thought at first and can go the slow route of normal consensus-building, especially if BLPN doesn't seem inclined to react quickly either. --Aquillion (talk) 22:23, 28 May 2021 (UTC)
It is way to situationally dependant for us to make any firm recommendations one way or another. I can come up with a dozen good reasons why you would want to go back to the status quo ante bellum, for just one example, if the stable version had a clear WP:BLP violation, and I can come up with a dozen more why we would want to return to the status quo. My own personal belief is that the most reasonable guidance is WP:BURDEN, and that in the case of a dispute, the text under dispute should remain out of the article in question, regardless of what the "stable" version was, until such time as there is consensus that it is added back. But I also recognize that the situation is always variable, and that different edit wars need different responses. --Jayron3216:28, 27 May 2021 (UTC)
They are both complimentary, and both equally state that inclusion requires consensus. WP:ONUS is unambiguous on this "The onus to achieve consensus for inclusion is on those seeking to include disputed content." WP:BURDEN similarly unambiguous "burden to demonstrate verifiability lies with the editor who adds or restores material" In both cases, they both advise that including material requires explicit consensus. There is nowhere written a similar, explicit statement that non-inclusion of text requires explicit consensus, with the exceptions of NOCON, but that is a much broader concept that covers changes to text (which is not necessarily inclusion or non-inclusion of ideas, and also includes such things as organization, phrasing, tone, etc.) Deciding whether or not some bit of text does or does not belong in an article is a much narrower subset of ideas, and in two different contexts (WP:BURDEN for verifiability and WP:ONUS for relevance) the default state is "don't include", in the absence of a clear consensus. --Jayron3217:12, 27 May 2021 (UTC)
This has been debated elsewhere so I don't want to get into it too much unless you can direct me to other past discussions, but my interpretation is that ONUS does not apply to material that had already achieved explicit or silent consensus. Kolya Butternut (talk) 17:32, 27 May 2021 (UTC)
Explicit consensus (as in, we've discussed this and we've decided it's good) yes. "Silent consensus" is not a thing; as I noted elsewhere in this discussion, silent consensus is a synonym for "obscure stuff no one noticed until today". --Jayron3216:22, 28 May 2021 (UTC)
WP:SILENT. There are certainly some situations where something is, for instance, on a low-traffic article or otherwise not prominent and hasn't seen much attention; in those cases it wouldn't apply. But if something has been on a high-traffic article for an extended period of time then it is presumed to enjoy consensus, and you must demonstrate explicit consensus to remove it, even if it has never been discussed before. This is well-established in both policy and practice, and if you repeatedly tried to remove it after eg. an RFC showed no consensus to do so, you could (and absolutely would, if you refused to WP:DROPTHESTICK) get taken to ANI or AE for it and could ultimately end up blocked or topic-banned for editing against consensus. If you disagree with this you are free to try and change the relevant policies, or to argue that the current (well-established and completely uncontroversial) practice does not reflect the literal wording of text; but you should not flatly misstate policy and practice as you are doing here. What you are saying is unambiguously incorrect - a no-consensus RFC outcome on whether to remove longstanding text always retains it, fullstop, and whether it has previously been discussed or not is immaterial. --Aquillion (talk) 22:08, 28 May 2021 (UTC)
I was involved in crafting both ONUS and BURDEN ... and we intentionally focused both provisions on the addition of material rather than on removal. The reason we did so is because it is possible to prove that sources exist to support an addition (just cite them). However it is impossible to “prove the negative” (ie you can not “prove” that sources don’t exist). Blueboar (talk) 20:57, 27 May 2021 (UTC)
The issue with WP:ONUS is that we've started to see disputes along the lines of... editor A wants to remove longstanding, sourced text (which is not obviously exceptional or a BLP violation or something else that would make the answer easy); editor B wants to retain it. Nobody else weighs in so there isn't a clear consensus at the moment; or they hold an RFC that reaches no consensus. Editor A now argues that WP:ONUS requires explicit consensus for inclusion and that the simple fact that they're challenging it means consensus must now be demonstrated to retain it, and removes it. Editor B argues that the stable version should remain in effect per WP:BRD and WP:STATUSQUO and that it enjoys WP:IMPLICITCONSENSUS and reverts them. Both editors now strongly believe that policy supports their version remaining in place during discussions, and that their version will be the outcome will be the default if consensus-making process stalls or breaks down. That is not a recipe for effective consensus-building; and this is the rough dispute you see playing out above. With WP:BURDEN this is not an issue because the requirement for sources is more straightforward and clearly established elsewhere. But while you can't demonstrate the non-existence of sources, you absolutely can demonstrate a consensus to remove longstanding material; and in practice, while implicit consensus is complex and not all longstanding material is equal, editors do generally have to show that consensus to remove it, which is something WP:ONUS completely ignores. Was the intent of WP:ONUS to change that, ie. to make the default no-consensus outcome for an RFC over longstanding material to be removal, and to push BRD towards being "bold, revert, delete, discuss" when dealing with such disputed removals? --Aquillion (talk) 21:49, 27 May 2021 (UTC)
FWIW: I've seen horrible text on BLPs, technically verifiable but awfully UNDUE, which I've removed, cited ONUS on, and later indeed consensus decided to keep it out. Often when I close RfCs as no consensus I'll say whether it implies the text should remain or be removed. If the article is a BLP, my interpretation of policy is that it usually errs in favour of removal. I don't know if a general rule on this is possible, or even a good idea, but I suppose with sufficient input a carefully worded one could be helpful. ProcrastinatingReader (talk) 10:55, 28 May 2021 (UTC)
@Aquillion: On the flip side, what I have personally witnessed far too many times to count, is that people believe that having a source is the entirety of what is necessary to include a piece of text, even in the face of overwhelming consensus. It's almost meme-level at this point that on any given day, there will be a minimum of a half-dozen reports on various DramaBoards where someone's entire complaint is that "so-and-so removed sourced text". As though all that text needs is a source, and then it becomes impervious to any objection. Sources are necessary, but sources by themselves are not sufficient. Things like relevance, tone, NPOV, WP:UNDUE, etc. etc. are all important, and unlike sources, those things require active and explicit consensus. If no one objects, fine, go ahead and add your sourced statement. But once someone comes along in good faith and says "Hey, this seems wrong because WP:UNDUE" or whatever, then we should take the text out and hash it out on the talk page. And, once again, "long term" and "implicit consensus" is just a synonym for "obscure enough that no one noticed until now". --Jayron3216:29, 28 May 2021 (UTC)
In highly visible, frequently edited pages, implicit consensus may be inferred. For more obscure pages, implicit consensus cannot be inferred. --Jayron3215:27, 1 June 2021 (UTC)
As mentioned before, WP:BRD is only an essay and is rarely enforceable, even though it is often an unofficially accepted maxim. Really though, discussion and common sense should be the guiding principle in any dispute. Note that when it comes to policy, we have WP:3RR which is pretty much the opposite of BRD in that if two editors keep reverting each other with neither blinking, then it's the editor who favours the status quo that will end up with the blockable fourth revert, while the edit warrior favouring change will get their way. Of course, we hope for disputes never to reach such a situation... — Amakuru (talk) 16:35, 27 May 2021 (UTC)
The real fun starts when two wikilawyers get into a debate over which version should have “status quo” or “stable” status. Blueboar (talk) 16:48, 27 May 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Many place entries (ie. Karachi, Santa Monica, Chittagong, etc.) include that location's time zone. It would be very helpful if these entries also included the current time.
For example, the listing for Pakistan contains an attribute of Time Zone, which indicates "UTC+05:00 (PST) DST is not observed." However, this doesn't tell the visitor what time it currently is in Pakistan.
The current time is not standard information in that it needs to be dynamic. This can be accomplished using an API or javascript to calculate the current time in the place entry's location.
NOTE: This feature would not be available for place entries that span multiple time zones.
NOTE: Pages for the various Time Zones display the "Current Time". For example, the page for "UTC+05:00" displays "Current Time" as "22:33, 2 June 2021 UTC+05:00" and includes a link for refreshing this value. So why can't this information be included in all pages that list Time Zone as "UTC+05:00"? It will save everyone from having to navigate away from the original page just to see the current time in that Time Zone.
I look forward to hearing everyone's thoughts on this feature request/proposal.
There might be technical barriers to this (e.g. WP:Purging), but to focus on the editorial side, I'm somewhat wary that this might run afoul of WP:NOT as unencyclopedic short-term information. It's an interesting thought, though. {{u|Sdkb}}talk05:38, 2 June 2021 (UTC)
Technical problems aside, we are WP:NOTPAPER so I don't think WP:NOT should stop us from including the time. It's an extension of encyclopedic material (time zone) that uses our electronic medium so I can understand why it's suggested. If it were actually possible, I think it would be a good idea. — Wug·a·po·des21:31, 2 June 2021 (UTC)
Strong Opppose - this would either require invalidating caching, or as suggested require running client-side scripts on every single page to modify the document - which will not be consistent across clients. Now, if someone wants to make a USERSCRIPT that will query wikidata:Property:P421 and try to figure something out, then more power to you. Keep in mind that many articles about locations will span multiple time zones, and summertime values may also vary widely. — xaosfluxTalk14:05, 2 June 2021 (UTC)
Oppose. We have enough issues with ages not getting updated on articles; trying to keep a clock accurate is a technical feat of another order. Besides the multiple time-zone issues, there is also the issue of summer time, which has widely different applications. Best option is a link to the time zone for the user to look it up themselves; second best alternative is a link to a site(s) that show local time. —C.Fred (talk) 18:06, 2 June 2021 (UTC)
Oppose. While "Wikipedia is not a clock" isn't specifically mention in WP:NOT perhaps it should be - maybe under WP:NOTGUIDE. C.Fred's mention of the problems with the way daylight savings time is observed (or not in some cases) is a major stumbling block as well. There is also the case of places like the state of Indiana in which some counties are in the eastern time zone and some in the central. MarnetteD|Talk18:18, 2 June 2021 (UTC)
Comment It looks like most of the comments above are thinking about it from the perspective of having the current time in the wikitext (directly or via parser functions), which would be insane. If we were going to do something like this, the HTML should include machine-readable markup and the actual time display should be entirely done via JavaScript. If someone lacks JavaScript in their browser, they would just see the timezone as they would now. Anomie⚔22:14, 2 June 2021 (UTC)
I take it this would be a quite large addition to common.js then? I have to admit that does sounds slightly less like a non-starter than parser functions or bots. Still, I doubt this is a good idea. --Trialpears (talk) 22:18, 2 June 2021 (UTC)
Maybe not, if we limit it to browsers that support Intl.DateTimeFormat's timeZone option with the appropriate input value. Anomie⚔11:59, 4 June 2021 (UTC)
Question. If it is feasible to display the current time in all the Time Zone entries, why is it not feasible on the pages that reference that Time Zone? Can we not just use the same mechanism?Nbardach (talk) 23:16, 2 June 2021 (UTC)
@Nbardach: in short: it isn't. Going to any of those pages as a normal reader is most likely to provide the wrong time - making the article normally inaccurate - those should probably be removed. Also, for "places" in general - as noted above many places span multiple time zones with multiple summertime adjustments. For example Australia is obviously a "place" - what is the time there right now? — xaosfluxTalk14:16, 3 June 2021 (UTC)
@Xaosflux: Thanks for the explanation. To answer your question, per my note above, "places" spanning multiple Time Zones would not display a Current Time. Another solution would be to display the current time next to any instance of a Time Zone (ex. "UTC+05:00 (22:33, 2 June 2021)). Your thoughts? Nbardach (talk) 15:50, 3 June 2021 (UTC)
@Nbardach: same caching problem - but also even for a place that only has one canonical time zone, "local time" would also needs to account for summertime offset (and a quick random sampling of places appear that they don't programmatically include their summertime windows). Again, I'm fine with anyone that wants to run a userscript to insert something to their own view - but not to try to force every page to load such a script for readers across all platforms - or to try to use a template that will not update the cached output until next publishing (so that it will basically always be inaccurate). — xaosfluxTalk16:01, 3 June 2021 (UTC)
@Xaosflux: I see. UTC is always a dependable time. Perhaps just displaying the time at UTC for each instance of a Time Zone would work? (ex. "UTC+05:00 (UTC: 17:33, 2 June 2021)" ). Nbardach (talk) 16:08, 3 June 2021 (UTC)
@Xaosflux: Don't mean to drag this out, but can you please clarify. Why is there a local offset issue if the proposed format for each instance of a Time Zone is "[TIME ZONE] UTC: [UTC CURRENT TIME]"? Ex: "UTC-09:00 (UTC: 18:15, 3 June 2021)" Nbardach (talk) 18:16, 3 June 2021 (UTC)
Because of summertime. For example, where I live right now it is officially UTC-5, but for a large portion of the year the local time is UTC-4. And when (and even if) summertime starts and ends varies by locale. — xaosfluxTalk18:45, 3 June 2021 (UTC)
@Nbardach, I've sent a note to one of the devs to confirm, but assuming I'm right, the way it works is this:
You edit a page at 18:15, 3 June 2021 (UTC). Let's say that you put a "current time" code on the page.
The server turns the wikitext into HTML at 18:15, 3 June 2021 (UTC) (or maybe a minute later). When it does that, the current time, which is 18:15, 3 June 2021 (UTC), gets written as plain old text in the HTML.
If no further edits/updates are made to that article, then that HTML copy gets used for the next 30 days ("cacheing"). In practice, this means that:
When you read it an hour later, it still says the time is 18:15, 3 June 2021 (UTC).
When you read it the next day, it still says that the time is 18:15, 3 June 2021 (UTC).
When you read it the next week, it still says that the time is 18:15, 3 June 2021 (UTC).
To do what you want, they would have to change the server's system from "unless there are more edits, then one copy lasts for 30 days" to "unless there are more edits, one copy lasts for only one minute". Whatamidoing (WMF) (talk) 18:38, 3 June 2021 (UTC)
Although this is true, we can bypass caching via purging (~1440 req/day, per 500 pages) or use JavaScript. Technically this is feasible, if consensus wanted to proceed. ProcrastinatingReader (talk) 00:19, 5 June 2021 (UTC)
The current UTC time is the same everywhere, so I'm not sure I see the point in displaying it any time a time zone offset is mentioned in an article. isaacl (talk) 20:15, 3 June 2021 (UTC)
Oppose as a solution looking for a problem, and the myriad implementation issues mentioned above. firefly ( t · c ) 12:08, 4 June 2021 (UTC)
Opposed - the YouTuber, Tom Scott, has a wonderful video on why this would be a programmer’s nightmare. Search for: “The Problem with Time & Timezones - Computerphile”. Blueboar (talk) 13:34, 4 June 2021 (UTC)
Grateful to everyone for their critical thinking and feedback. That proposed infobox is SWANK!! I think I'm going to reformulate my proposal as a different display for UTC. This would be less technically challenging (b/c UTC is constant) and should address many of the issues that have been raised here. Cheers, N Nbardach (talk) 04:30, 5 June 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This article is written in American English, and this should not be changed without consensus. Learn more.
Do not place this template in the main body of the article.
02:36, 9 May 2021 (UTC)
Current good article icon
Current featured content icon
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.
. 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 to WP:VPI