Wikiwand AI

Wikipedia:Village pump (proposals)/Archive 211

From Wikipedia, the free encyclopedia

Village pump (proposals) archive  

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

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

Proposal: Remove the topicons for good and featured articles

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.

WP:SNOW closing this proposal as a clear consensus to keep topicons for good and featured articles. I find it very unlikely that consensus will change from here given the overwhelming !vote to keep. (non-admin closure) JML1148 (talk | contribs) 07:51, 10 March 2024 (UTC)

We recently rejected a proposal that would put the vital article topicon on the page. Discussion: Wikipedia_talk:Vital_articles/Archive_25#Proposal_for_a_VA_"top_icon". Some editors in that discussion said that they would support removing the good and featured article topicons as well. If either readers or editors are interested in whether they are good or featured articles, they can be found on the talk page. Interstellarity (talk) 00:30, 2 March 2024 (UTC)

Support (remove GA & FA topicons)

  1. As proposer. Interstellarity (talk) 00:30, 2 March 2024 (UTC)
  2. Strongly support removing GA topicons. GA reviews are essentially random. It's just one editor reviewing it and there is literally no training or qualifications that the reviewing editor needs to have. To suggest a GA article has gone through any kind of meaningful review process is misleading the reader. All it means is someone else has read it. Exhibit A is the editor from a year and a half ago who had hundreds of GAs that turned out to be full of misinformation (and copyvio and other stuff, the editor ended up indef'd).

    I'm neutral about removing FA topicons. At least that process can be said to involve multiple editors reviewing it, and the FA folks take their FA reviews pretty seriously AFAIK (unlike GAs, which some take seriously but others don't). I don't think it matters much if the FA topicon is there or not -- I don't think readers know or care about that -- but GA should definitely go IMO. Levivich (talk) 04:02, 2 March 2024 (UTC)

    Actually, I support removing FA top icons too. I'd forgotten that most FAs no longer meet the criteria. Levivich (talk) 17:19, 2 March 2024 (UTC)
  3. I support removing both. — Fourthords | =Λ= | 14:02, 2 March 2024 (UTC)
  4. - due to the fact readers have no clue what these mean and the fact the majority no longer meet their FA and GA criteria and 60%+ are mobile viewers don't even see them anyways. I can see how they are an incentive to get editors to improve articles though. That said I would slow down on rfcs that will go nowhere..... Time wasters.Moxy- 16:50, 2 March 2024 (UTC)
  5. Our loyalty is to the WP:READER, to whom these icons—where they're even noticed, that is (on mobile view they don't exist!)—are merely inside baseball. Their real purpose to allow editors a chance to gussify their user, talk pages etc. Stick em a table on a subpage if you have to  :) ——Serial 16:58, 2 March 2024 (UTC)
  6. As others have ably noted, these icons provide no discernible benefit to the reader. We would therefore better serve the reader by eliminating this visual noise. Frankly, we would probably do well to reconsider the centering of FA and GA work in general. The hundreds of hours it takes to nurse a single article through FAC would surely be better spent improving some of the millions of articles that have been substantially untouched for a decade or more. But in any event this would be a good step. -- Visviva (talk) 03:07, 4 March 2024 (UTC)
  7. I don't think I've ever met a reader who knew we had FA topicons, let alone what they meant. —TheDJ (talk • contribs) 19:24, 4 March 2024 (UTC)
  8. The icons are not for readers. The 2004 article ranking system devised in Wikipedia:Version 1.0 Editorial Team and still in use today needs revision to be practical. GA ranks are varying quality; FA ranks are easier to attain for less popular topics than highly read ones where they are most needed. Removing icons could be the start of recognizing that our quality reporting system is insufficient for meeting its objective. Bluerasberry (talk) 15:28, 6 March 2024 (UTC)
  9. The top-icons lack context. I'm in favor of removing them or improving the top-icons to something that make more sense to readers. CactiStaccingCrane (talk) 16:31, 6 March 2024 (UTC)

Oppose (remove GA & FA topicons)

  1. The topicons are useful for readers as indicators that an article has gone through some kind of review process. This is in contrast to vital articles which is editor facing information. Barkeep49 (talk) 00:40, 2 March 2024 (UTC)
  2. I think all quality ratings should be shown, not just GA/FA. Analogous to maintenance tags, it's useful for readers to know how much they should trust what they're reading on Wikipedia. Moreover, topicons are unobtrusive and might have the benefit of converting a few readers to editors. As an aside, I think the distinction that's been drawn between quality ratings and vital article status is strained. Both are done through the work of a relatively small group of editors and both indicate something important to the reader about how the community has assessed an article. voorts (talk/contributions) 00:46, 2 March 2024 (UTC)
    Why should a reader care about how vital wiki editors think an article is? The reader has their own ideas about how vital that article is to them in that moment and in general. The idea of showing all rating indicators is an interesting one in terms of helping readers clue into what they are. I'd love to see that discussed more. Best, Barkeep49 (talk) 00:49, 2 March 2024 (UTC)
    By that logic, I think one could say: Why should a reader care about that one editor came to the conclusion that an article is GA quality and 5-10ish editors—none of whom are necessarily subject matter experts—came to the conclusion that an article is FA quality? I'll make a note to return to the topic of showing all ratings after this discussion closes. voorts (talk/contributions) 00:55, 2 March 2024 (UTC)
    I've had a similar thought before myself, but I've come to believe that in practice, the distinction between Start/C/B-class is often too poorly defined to be useful information to the reader. —Compassionate727 (T·C) 15:34, 2 March 2024 (UTC)
    This is how I think about the distinctions: start is longer than a stub, but either not very well-cited or written, C is a start class article that's starting to meet some core PAGs, and for B we have clear criteria. voorts (talk/contributions) 20:41, 2 March 2024 (UTC)
    Plus from my experience it is often not kept up to date as the article content changes. ― novov (t c) 01:58, 3 March 2024 (UTC)
  3. Oppose. The topicons are useful, and have been this way for a long time. What exactly is the advantage of removing them? –Novem Linguae (talk) 00:50, 2 March 2024 (UTC)
  4. Per Barkeep. Nikkimaria (talk) 00:59, 2 March 2024 (UTC)
  5. Per Barkeep. I'm not sure how valuable fronting the lower ratings would be (they're often out of step with the quality of the article) but I'm not immediately opposed to adding them. Thryduulf (talk) 01:14, 2 March 2024 (UTC)
  6. Oppose: It's good to show readers in an unobtrusive way that the article they're reading has been reviewed and is of quality. There is no benefit to removing them. 🌺 Cremastra (talk) 01:59, 2 March 2024 (UTC)
  7. Oppose: per Barkeep, however, the GA topicon was a bit confusing to me when I was only a reader and I wouldn't mind a reform. ❤HistoryTheorist❤ 02:36, 2 March 2024 (UTC)
  8. Why? I think it's a convenient way to show that articles are of a decent quality to our readers. It's not causing any problems. Elli (talk | contribs) 03:51, 2 March 2024 (UTC)
  9. Oppose per Barkeep49. Headbomb {t · c · p · b} 04:19, 2 March 2024 (UTC)
  10. Oppose per Barkeep49. We should be making the icons more prominent, not less. Sdkb talk 07:03, 2 March 2024 (UTC)
  11. Oppose: GA and FA symbols are no guarantee of any kind of quality, but it is one piece of information that media literate readers should be using to help them assess the reliability of what they read. These topicons may also be motivating to editors who put articles they have improved through GA/FA processes. — Bilorv (talk) 09:41, 2 March 2024 (UTC)
    +1 Sdkb talk 16:19, 2 March 2024 (UTC)
  12. Oppose per all the opposers, but I'm mainly here to comment: I consider it a win that no one has even mentioned featured lists in this discussion or the previous one. The process basically works, and judging from the silence, it doesn't seem to be contentious these days. Congratulations all around. - Dank (push to talk) 15:32, 2 March 2024 (UTC)
    Featured lists should undoubtedly follow featured articles in this regard. If any decision is ever made to change or remove the FA icon, featured lists should get the same result. Animal lover |666| 16:38, 4 March 2024 (UTC)
  13. Per Barkeep. —Compassionate727 (T·C) 15:33, 2 March 2024 (UTC)
  14. The topicons are what first informed me of the GA and FA processes back when I was an unregistered lurker. I can imagine other unregistered users falling down a rabbit hole and potentially getting involved with curating content after seeing one of them. Also Barkeep49 presents another good rationale for keeping them. The Night Watch (talk) 17:22, 2 March 2024 (UTC)
  15. Oppose We need to make them more prominent, not less. Sohom (talk) 17:35, 2 March 2024 (UTC)
  16. Oppose per Barkeep and Bilorv. Moreover, just because mobile readers are unable to see them it does not mean we should remove them from PC readers (if anything it means that we should add them to mobile view).  Spy-cicle💥  Talk? 17:43, 2 March 2024 (UTC)
  17. Oppose per Spy-cicle. – SD0001 (talk) 21:48, 2 March 2024 (UTC)
  18. Oppose, per Barkeep and Bilorv. ♠PMC♠ (talk) 00:02, 3 March 2024 (UTC)
  19. Oppose Like voorts, I would not object to all ratings being shown. In fact, I use a plugin that does just that. Hawkeye7 (discuss) 00:51, 3 March 2024 (UTC)
    I use the same plugin, which is where the idea came from. voorts (talk/contributions) 00:59, 3 March 2024 (UTC)
    Link? Queen of Hearts talk
    she/they
    stalk     23:47, 6 March 2024 (UTC)
    May be referring to the Wikipedia:Metadata gadget mentioned below. Aaron Liu (talk) 23:56, 6 March 2024 (UTC)
  20. Oppose - I agree with Levivich that the quality of the GA process can be inconsistent, but in practice I still find that they are almost always better than your average non-good article. Yes there can be stuff like what Doug Coldwell did, but the same goes for every other part and process of Wikipedia. Most readers aren't likely to grasp what the means anyway, in my mind it serves as more of a motivational little trinket for editors, and I'm concerned that removing the most prominent area where it's featured could decrease the impetus to improve content. ― novov (t c) 01:57, 3 March 2024 (UTC)
  21. Not clear what the harm is, and if the only benefit is making people feel good about getting an article to GA/FA (by having a shiny icon on the article) that seems enough. Galobtter (talk) 01:58, 3 March 2024 (UTC)
  22. Oppose. The provided rationale is extremely unconvincing - "some people mentioned it?" Lay out the case yourself if you believe it. Marking quality is fine (which is what FA / GA icons do), the problem with VA marking was - too many to list, see previous discussions. This proposal comes across as an extremely weak "well this one proposal was voted down, let's do the same thing in a separate vaguely similar area out of some misguided fairness." SnowFire (talk) 02:27, 3 March 2024 (UTC)
    RfC statements are required to be brief and neutral, and the fact that earlier discussions occurred at that RfC satisfies WP:RFCBEFORE. voorts (talk/contributions) 02:39, 3 March 2024 (UTC)
      • @Voorts: The statement is expected to be neutral, yes. However, somewhere (whether in a separate section after the description, or in the nominator's initial !vote) there's expected to be some reasoning for why the heck we're voting on this at all and some sort of case to modify the status quo. The RFC creator gave no such explanation other than what I already cited that "other people mentioned it" and "readers can find out on the talk page" which is not conversant at all with the issues involved. People could propose random changes all day; why is this change being proposed? You shouldn't start an RFC as just a thought experiment, that's what a normal discussion is for. SnowFire (talk) 05:15, 3 March 2024 (UTC)
  23. Oppose: Not causing any harm, and is a nice bit of encouragement for editors. ARandomName123 (talk)Ping me! 02:46, 3 March 2024 (UTC)
  24. Oppose If my GA/FA articles didn't get the topicon, I rather doubt I'd have even known they existed, or felt compelled to get my articles to that status. The badge is useful to readers, and a great inducement for editors. CaptainEek Edits Ho Cap'n!⚓ 03:26, 3 March 2024 (UTC)
  25. Oppose, mostly per voorts. We should show more of this, not less; readers deserve to know if an article has passed some quality gate. On the topic of substandard GA/FAs, yes they exist, no we shouldn't let perfect be the enemy of good. ~ A412 talk! 04:24, 3 March 2024 (UTC)
  26. Oppose. This does not really seem like a good idea to me; if there's a bunch of crappy GAs we do not need to address topicons to deal with them. jp×g🗯️ 06:07, 3 March 2024 (UTC)
  27. Oppose. I would prefer we go in the opposite direction and make the icons more visible and more intuitive. Readers will not know which one is more "trusted". —Femke 🐦 (talk) 07:48, 3 March 2024 (UTC)
  28. Oppose - Nothing wrong in letting readers know which articles are trusted and have underwent community review. The Herald (Benison) (talk) 09:14, 3 March 2024 (UTC)
  29. also noting that I will support introducing FA and GA topicons to mobile and apps, but not supporting the entire removal of the badges. Toadette (Let's discuss together!) 16:58, 3 March 2024 (UTC)
  30. Oppose. Do not see any positive from this action. On the contrary, will be some amount of value subtraction (if that is even a term). Ktin (talk) 17:49, 3 March 2024 (UTC)
  31. Oppose The great majority of Wikipedia's readers are unaware that there is a quality scale. Indicators of article quality need to be more visible, not less. MartinPoulter (talk) 18:16, 3 March 2024 (UTC)
  32. Oppose I'm piling on to say that FA and GA are very important tools for developing quality articles and qualifying articles should be highlighted. The icons are also a learning experience for anyone wanting to click them. Johnuniq (talk) 02:54, 4 March 2024 (UTC)
  33. Strong oppose Might actually reduce the amount of FAs and GAs that will start coming out because there will be less motivation to do so. ‍ Relativity 05:31, 4 March 2024 (UTC)
  34. Oppose The FA topicon linked to the first projectspace page I read. It probably contributed to me becoming an editor. Snowmanonahoe (talk · contribs · typos) 13:57, 4 March 2024 (UTC)
  35. The proposal might be an argument for a double-check system for GAN's, but it isn't a reason to remove the topicons. They at least show articles that have been through some vetting. Courcelles (talk) 14:21, 4 March 2024 (UTC)
  36. Oppose The icons are an extremely powerful motivator to get involved and improve Wikipedia. It only works because they are shown by default. I'm sure it would be trivial to squelch display with a script for an opt-out option. GreenC 16:41, 4 March 2024 (UTC)
  37. Oppose - articles exist for the benefit of the readers, no tenth editors. A reader has no idea how good an article is without reading a significant part of it; how vital it is requires little more than a definition. There is no need to tell a reader how vital an article is; there is much more to tell the reader about the quality. Animal lover |666| 16:36, 4 March 2024 (UTC)
  38. Oppose - FA/GA topicons highlight Wikipedia's best content in-place. Readers shouldn't have to go to a talk page or a list somewhere else to see that the content they're reading has been reviewed and is considered Wikipedia's finest, and there is benefit to distinguishing it from content that hasn't been through or has failed such a review. Ratings below that level are part of a content rating system that's been dead in the water for 20 years (though projects still use it) and there's no point in highlighting it for readers since there are practically no standards to the ratings, but if you want to see these ratings when reading articles anyway you can enable Wikipedia:Metadata gadget (Preferences > Gadgets > Appearance). Ivanvector (Talk/Edits) 17:26, 4 March 2024 (UTC)
  39. Oppose These are meaningful, particularly FA. North8000 (talk) 17:28, 4 March 2024 (UTC)
  40. Oppose These are important. SportingFlyer T·C 18:59, 4 March 2024 (UTC)
  41. Oppose. The indication that an article has had internal quality-control is very useful to a reader. Vanamonde93 (talk) 19:26, 4 March 2024 (UTC)
    Adding: I fully acknowledge that both review processes have serious issues, but the average quality of a GA/FA far outstrips that of other articles. Vanamonde93 (talk) 19:29, 4 March 2024 (UTC)
  42. Oppose. The topicons are an easy-to-find, yet also unobtrusive, way to indicate that an article has received (and passed) some level of vetting. The fact that they're visible in mainspace also means that they're relatively easy for readers to find and interpret as well, a benefit that would be lost (or at least reduced) if the indicators were kept confined to talk pages. (I also second the comments made by Barkeep, Bilorv, and The Night Watch.) ModernDayTrilobite (talk • contribs) 19:33, 4 March 2024 (UTC)
  43. Oppose per Voorts. Acknowledging the lack of professionalism at WikiProject Good Articles, the icons at top mean something. I'd suggest Wikipedia:Metadata gadget should be "on" by default because the readers are not savvy enough. Chris Troutman (talk) 21:55, 4 March 2024 (UTC)
  44. Strong oppose per the commenters above. These are not mere decorations; the icons signify that the GAs and FAs have undergone their respective quality control processes, and are thus helpful to the WP:READER. If GAs and FAs don't meet criteria, then WP:GAR and WP:FAR are that way. The reader may not know what they mean initially, but they'll certainly know if they click on them - the solution is to make it more obvious that the article has undergone a quality control process, not less so. There are some valid issues with the GAN and FAC processes, but they are in no way relevant to the use of topicons. Epicgenius (talk) 15:34, 5 March 2024 (UTC)
    To add: I agree with Aaron Liu's rebuttal, below, as to the "randomness" of GA reviews. Any bad GAN review can be deleted, and any bad FAC/FLC review can be stricken through. My point is that the existence of bad reviews is not a good argument, in my view, for removing the topicons. – Epicgenius (talk) 00:07, 6 March 2024 (UTC)
  45. Oppose. These icons bring more visibility to the assessment project, motivate editors, draw in readers, and are informative. Zanahary (talk) 16:52, 5 March 2024 (UTC)
  46. FA/FL/GA is about quality while VA is about being on a list drawn up by a wikiproject --Guerillero Parlez Moi 21:06, 5 March 2024 (UTC)
    FA/FL/GA are also a lkist drawn up by a project. The point is that they are about article quality whereas VA is a bout article importance. Hawkeye7 (discuss) 22:53, 5 March 2024 (UTC)
  47. Oppose: The usefulness of these icons is different than the possible usefulness of a vital articles topicon. Also not seeing an actual reason listed for why we would want to remove these. Hey man im josh (talk) 21:37, 5 March 2024 (UTC)

  48. the majority no longer meet their FA and GA criteria

    Then nominate them for delisting.

    GA reviews are essentially random. It's just one editor reviewing it and there is literally no training or qualifications that the reviewing editor needs to have.

    There are great guidelines for reviewing, and bad GA reviews can be overturned.

    readers have no clue what these mean

    I don't see any evidence of that, and having a tooltip and link seems obvious enough.

    I don't think I've ever met a reader who knew we had FA topicons, let alone what they meant.

    I don't think a reader knows what "topicons" are either. Aaron Liu (talk) 22:45, 5 March 2024 (UTC)
  49. Oppose Useful indicators of top quality. Curbon7 (talk) 23:05, 5 March 2024 (UTC)
  50. Piling on. Same reasons as Barkeep. — Rhododendrites talk \\ 00:18, 6 March 2024 (UTC)
  51. Oppose per Curbon7. - Master of Hedgehogs (converse) (hate that hedgehog!) 14:07, 6 March 2024 (UTC)
  52. Oppose per Barkeep, Bilorv, Epicgenius, Aaron Liu, and others. I don't see any point in removing topicons; I find them useful and evidently a lot of others do too. Even if readers don't care about them (which I haven't seen any good evidence of, just assumptions), they're helpful from an editor's point of view. If I see a blatantly terrible article with a little green icon on the top right, that catches my attention and makes me want to either send it to GAR or fix it up. sawyer * he/they * talk 02:16, 7 March 2024 (UTC)
  53. As primarily a reader of Wikipedia, I find the GA/FA top icons to be useful information. Removing them would do some readers a disservice, and there is no advantage to removing them. Senior Captain Thrawn (talk) 03:41, 7 March 2024 (UTC)
  54. Oppose per above and because of throwing the baby with the bathwater. Brandmeistertalk 01:17, 8 March 2024 (UTC)
  55. Strongly oppose Opponents of the GA and FA topicons claim they are visual noise, yet they criticize the choice to not include them in mobile viewing as proof the review process is wasteful. While Levivich is correct that the peer review process can be hijacked by sockpuppeting, they present no evidence that this is widespread to convincingly argue the review process' collaborative editing is a net waste. While the GA and FA criteria are no different from the normal aims of article editing, the pursuit of specific quality metrics encourages greater compliance. BluePenguin18 🐧 ( 💬 ) 04:59, 8 March 2024 (UTC)
  56. Oppose removal and Support addition of sitewide ratings for all mainspace articles and for all devices. The purpose of such a system is to indicate an article's quality to readers in advance, so they could anticipate whether an article is worth reading or not - or at least have a glimpse of what to expect. It's no different than rating systems for various things, like for movie, book, video game and music reviews. PantheonRadiance (talk) 06:10, 8 March 2024 (UTC)

Neutral (remove GA & FA topicons)

  • I suspect that the vast majority of our readers pay absolutely no attention to article ratings and their associated topicons. However, because I don’t think they harm the project in any way… I am neutral on the question. Blueboar (talk) 13:16, 2 March 2024 (UTC)
    If it helps 1% of the readers, that should be a good enough reason to retain them, unless they actually harm the site or reduce it's quality, at least for some readers. If it's 100% neutral for 99% of the readers, this should not weaken the fact that it helps the other 1%. Animal lover |666| 16:41, 4 March 2024 (UTC)
  • I don't feel strong enough to sit on either side of this discussion. There are genuine grounds for concern about quality control and the ad hoc nature of the review process. It does seem that the topicons are very much inside baseball, so to speak. Nevertheless, despite the extreme example highlighted above (for which I have direct experience) I still think indicating some kind of independent review has taken place is worthwhile, no matter how limited in nature...I might have an easier time supporting this proposal if an alternative was being proposed. Regards, --Goldsztajn (talk) 01:36, 3 March 2024 (UTC)

Discussion (remove GA & FA topicons)

Barkeep49, as far as I know, we have no evidence that ordinary readers have any idea that those topicons exist or what they mean. WhatamIdoing (talk) 03:42, 2 March 2024 (UTC)

That's probably true. But that's a reason to improve them, not remove them. Sdkb talk 07:04, 2 March 2024 (UTC)
This 2022 study might interest you, unless you're already familiar with it :) Shells-shells (talk) 07:32, 2 March 2024 (UTC)
We having no evidence for something doesn't necessarily mean it isn't true. Readers curious to find out the meaning of the icon would hover over it - it says "This is a featured article. Click here for more information". The click leads to WP:FA which begins with "Featured articles are considered to be some of the best articles Wikipedia has to offer". – SD0001 (talk) 07:54, 2 March 2024 (UTC)
The vast majority of readers don't see these anyways because they are not displayed in mobile view. Moxy- 17:18, 2 March 2024 (UTC)
We can actually figure out how many people click these. I've created Wikipedia:Good articles*Wikipedia:Good articles* and Wikipedia:Featured articles*Wikipedia:Featured articles* and changed the links in the template accordingly, so after a month or so we should have good data on how many clicks these get. Elli (talk | contribs) 17:36, 2 March 2024 (UTC)
Great work....thank you! Moxy- 20:13, 2 March 2024 (UTC)
Yes, that's a good idea. WhatamIdoing (talk) 02:32, 3 March 2024 (UTC)
Related to this: I wonder what a reasonable comparison would be. (If it's 1,000 clicks, is that a lot or a little?) I wonder whether it could be compared against the Portal: links that used to be at the top of the Main Page. We could scale it for page views (which I think could be obtained through https://pageviews.wmcloud.org/massviews/ for the FAs and GAs). WhatamIdoing (talk) 22:05, 6 March 2024 (UTC)
I agree with Skdb. Best, Barkeep49 (talk) 08:16, 2 March 2024 (UTC)
I've nothing against the topicons; I'd be happy to keep them just because they're useful to experienced editors, a nice reward for hard work, and traditional for the site. However, I don't think we should be making this decision on the grounds that we speculate that they're useful to non-editing readers, when
  • we don't know that they're useful,
  • we have a limited amount of evidence suggesting that they're not (or that the utility is very limited), and
  • we know that most readers don't see them because 66% of page views are on the mobile site.
A month from now we will know whether those topicons get clicked on at any significant rate. WhatamIdoing (talk) 02:57, 3 March 2024 (UTC)
I have occasionally told people who have questions about whether/when Wikipedia articles are reliable to look for the topicons. —Compassionate727 (T·C) 15:38, 2 March 2024 (UTC)
Question: how often are ratings/topicons reevaluated and lowered due to subsequent crappy edits? Blueboar (talk) 01:53, 3 March 2024 (UTC)
There's WP:FAR and WP:GAR. Galobtter (talk) 01:57, 3 March 2024 (UTC)
I think that a modified version of Wikipedia:Metadata gadget without the colored title text would make the most sense here. It shows the article assessment in an intuitive way and clearly indicate links for curious readers to read more about our assessment criteria. CactiStaccingCrane (talk) 16:35, 6 March 2024 (UTC)
Courtesy ping to WhatamIdoing. CactiStaccingCrane (talk) 16:37, 6 March 2024 (UTC)
I use and value that gadget. Also, I think it's Inside baseball (metaphor). Nobody except the tiny minority of high-volume Wikipedia editors cares about how we rate articles. Like: there are 8,000,000,000 people in the world, and maybe 8,000 of us care about the ratings. WhatamIdoing (talk) 22:02, 6 March 2024 (UTC)
On one hand, it's definitely an improvement over nothing, and should minimize confusion. On the other hand, topicons look better, and nobody might care enough anyways so that these who care would click on the icons to learn more... Aaron Liu (talk) 23:15, 6 March 2024 (UTC)
Many editors have stated that finding out about the GA/FA process has made them motivated to contribute to Wikipedia. I think the article ratings should be made more explicit to the reader, but if we can't bother to improve the top-icons, then we should get rid of it. CactiStaccingCrane (talk) 00:07, 7 March 2024 (UTC)
  • If we are going to remove an icon, I would hide the protection icons from logged out users (I don't see the benefit - they are anyways shown a "view source" button instead of "edit source" if they can't edit the article). That truly is inside baseball unless you actively try to edit an article. Galobtter (talk) 02:01, 3 March 2024 (UTC)
  • Any argument about reader understanding of topicons applies equally to page protection topicons. Anecdotally, some years ago, in a former life, I was observing a high school social studies class in the American Midwest and the teacher, as part of a lesson on research methods, told the class that the lock icon in the upper corner meant that it was vetted. We should be discussing how better to present this information for readers, not its removal. The 2023 GA proposal drive agreed to start an RFC for options on making GA status more prominent in mainspace. I've also been a big proponent of requesting Foundation staff to run user testing on some of our community design norms, i.e., banner blindness or in this case topicon literacy. I can track down those requests if useful. czar 13:57, 8 March 2024 (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 move, create and upload protection locks to the top right corner

Relevant links: Wikipedia:Protection policy and Special:MovePage/Wikipedia:Protection_policy (To see what it looks like to try and move a protected page. non admins only). Originally posted at the village pump (ideas)

Currently, articles that are protected from editing have the relevant lock in the top right hand corner. Userpages may not have the relevant edit lock on the top right. With regarding edit protection, it will stay as it is but why don't we do the same for move, create and upload so that articles (other than user pages) require all types of protection to be shown on the top right. The lock icon will display in the same way shown in the protection policy page (linked above). With move protection, the only way to tell that the page is protected is if the move button is not seen (this article for example, doesn't have the move button for me, but it does have subscribe) with the possible exception for administrators as they can move any page even if it's protected. Even if accounts are able to edit semi and EC protected pages, the relevant lock is still there. But like I said, that will not change. Admins will also be able to see if a page is move protected from the green lock icon at protection policy page.

The only way to see the green (move) and blue (create/also known as salting) lock is if the URL was typed for some reason, like here and here respectively. (for ECP create protection this appears instead). JuniperChill (talk) 21:40, 22 February 2024 (UTC)

Also, I forgot to realize most people (I think) replying to be are actually ECP, so please do not even try to recreate the linked page. I am not ECP myself (have ~260 edits). This is just an example of what it looks like for non ECP users to try and (re)create a salted page. You may wish to use an incognito tab to do so.

JuniperChill (talk) 15:57, 27 February 2024 (UTC)

Support, though what's stopping us from doing this right now? Aaron Liu (talk) 16:03, 27 February 2024 (UTC)
{{Pp}} already supports move protection, it just needs admins to apply the template when they move protect a page. It cannot be used for create and upload protection as there is no page to put the template on. It might be possible to add the padlock icon to MediaWiki:Nocreatetext, but that seems redundant. --Ahecht (TALK
PAGE) 20:12, 27 February 2024 (UTC)
Comment {{pp-move-indef}} hasn't displayed a visible icon since 2009 , and visible display for {{pp-move}} was removed following this TfD because participants saw it as unnecessary bloat. Personally I always found them a little useful, even though us unregistered types haven't been able to move pages for a long time since it was still a quick indicator that a title was potentially contentious, but I can understand why it was removed. 184.152.68.190 (talk) 20:52, 27 February 2024 (UTC)
I'm fine with a lock icon for creation-protected pages if technically feasible (obviously not by placing a lock template on the non-existent page). I'm also fine with an upload protection icon although almost all files are at Wikimedia Commons and we don't need to invest a lot of time into improving the display of the few remaining local image pages. A move protection icon, however, is an unneeded gimmick that is more likely to confuse readers than to help the few editors who intend to move the page. ~ ToBeFree (talk) 21:08, 27 February 2024 (UTC)
Displaying a lock for move-protected articles would confuse far more people than it would help, I agree with ToBeFree. I'm ambivalent about displaying a lock for the other two cases. Daniel Quinlan (talk) 08:24, 29 February 2024 (UTC)
Alternate proposal: What if we grayed out the move button and put a lock next to it? I agree with Daniel and ToBeFree that locking the edit button would be too confusing, but this could work if technically possible. QuicoleJR (talk) 21:40, 7 March 2024 (UTC)
IMO just greying it out would be enough. Putting an icon draws too much attention to it for an otherwise icon-barren menu. Aaron Liu (talk) 21:56, 7 March 2024 (UTC)
That is true. Greying it out would likely be enough. QuicoleJR (talk) 22:02, 7 March 2024 (UTC)
@JuniperChill, Aaron Liu, Daniel Quinlan, and ToBeFree: What do you think of my alternate suggestion of simply greying out the move button? QuicoleJR (talk) 19:43, 10 March 2024 (UTC)
Erm, I said one comment above in support of just greying it out. I suppose this proposal would be a strong recommendation to the WMF to implement such a feature. Aaron Liu (talk) 19:45, 10 March 2024 (UTC)
Oops, sorry. I missed that when checking who I needed to ping. QuicoleJR (talk) 20:24, 10 March 2024 (UTC)
That might be alright but then thing is, if a page is (edit) protected, then the lock is still there, even if they are able to edit it themselves. So that is why I proposed a plan to introduce the green move icon lock in the top right to be shown to all. Again, like with edit locks, the move lock will be there for all, including unregistered users and admins. If a page is not move protected, then the lock will not show even to unregistered users despite the fact that unregistered users cannot move pages anyway.
In addition, the pending changes protection (check mark) and semi protection (user icon) are both grey with the semi protect lock being slightly darker so all could be grey, but I still prefer it to be green.
The reason I propose those changes is because they are shown in the relevant links but the non edit protection locks are barely used. It also tells users that the page is protected (the move option should be visible to admins if protected) With regarding salted pages (see red link example for an example), the lock could be displayed within the infobox or even the top right, or somewhere before the 'This page is protected from creation, so only administrators can create it'. JuniperChill (talk) 20:02, 10 March 2024 (UTC)
Actually, edit locks do not show up for users who can edit the article anyway, at least not on mobile. I have not seen them for EC-protected articles since I reached extended confirmed. QuicoleJR (talk) 20:26, 10 March 2024 (UTC)
Mobile shows no padlocks whatsoever. Not all anons are mobile users. Aaron Liu (talk) 20:27, 10 March 2024 (UTC)
That is not true, I still see the lock over the edit button when I go to, for example, Brianna Wu. The colors are all the same, but it is there. QuicoleJR (talk) 20:29, 10 March 2024 (UTC)
That's a different thing. I was talking about the standard padlock images. Aaron Liu (talk) 20:31, 10 March 2024 (UTC)
Oh, I see what you are talking about now. I think that the padlock would be a type of topicon, and those really should be visible on mobile. QuicoleJR (talk) 20:37, 10 March 2024 (UTC)

If a page is not move protected, then the lock will not show even to unregistered users despite the fact that unregistered users cannot move pages anyway.

Then what purpose would the lock serve? Why would we want anons to see them? I don't think this or "it's not used much" are valid reasons to use them.

I still prefer it to be green.

The color of the padlock would not change.

With regarding salted pages (see red link example for an example), the lock could be displayed within the infobox or even the top right

What do you mean by "infobox"? If we can add it, it'd be ideally where padlocks usually are. Aaron Liu (talk) 20:28, 10 March 2024 (UTC)
I proposed it so that users are able to see if the page is move protected or not, just like edit protected. With regarding salted pages, I meant to add, they would also be on the top right if at all possible, otherwise I suggested the alternatives.
And with someone requesting move locks at WP:US/R, I think they must have read this. JuniperChill (talk) 20:43, 10 March 2024 (UTC)
Why should someone who can't move any page anyways see if a page is move-protected? They can edit most of them, so edit padlocks are definitely needed. Aaron Liu (talk) 20:55, 10 March 2024 (UTC)
As a tangent, someone asked for a script for move locks at WP:US/R, so I made one. Aaron Liu (talk) 20:25, 10 March 2024 (UTC)
I think graying out the Move button is a bit dubious from a UX perspective. The warning on the Move page after clicking on the button is already quite clear. Trying to illustrate that a page is move protected prior to an attempt to move a move-protected page when it's such an uncommon occurrence seems to have very little if any benefit. The lock icons not being used often is a non-problem. And most users that want to move a move-protected page are going to click on the button regardless of the color. If you just want to gray it out for yourself, it would be possible to do that with some JavaScript that you could put into your common.js. Daniel Quinlan (talk) 20:44, 10 March 2024 (UTC)

Proposal: Implement a community-based process for appointing CheckUsers and Oversighters

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
WP:SNOW, there's a clear consensus against this being a good idea. Galobtter (talk) 02:24, 11 March 2024 (UTC)

I propose that we implement a community-based process for appointing CheckUsers and Oversighters similar to how RFAs are run. Because these positions require a high degree of community trust, I believe consensus should be higher like in appointing bureaucrats and interface administrators. I believe in this way, the community has more of a say of who gets to be a CU and OS other than our current arbitrators who currently hold those positions. I would also be open to saying with arbitration approval. Interstellarity (talk) 13:57, 26 February 2024 (UTC)

Support (CU and OS appointments)

  1. As proposer. Interstellarity (talk) 13:57, 26 February 2024 (UTC)
  2. (Moral Support) I'd love arbcom to be out of the CUOS business, primarily so that we can focus on putting people on the committee primarily on the strength of their dispute management skills. — xaosflux Talk 15:42, 26 February 2024 (UTC)
  3. It might be good to take something off of ArbCom's plate. ArbCom has many responsibilities. SWinxy (talk) 17:42, 26 February 2024 (UTC)
    ARBCOM were elected on the basis that this would be one of their responsibilities. They can tell us if they think they've got too much on their plate. Phil Bridger (talk) 19:46, 26 February 2024 (UTC)
    Arbcoms tell us this year after year through their very slow action. Levivich (talk) 15:17, 27 February 2024 (UTC)
    If you look at what proposals come out of the committee to increase their productivity, they are almost always about streamlining case management and especially dealing with appeals. That none of them relate to CU or OS appointments should give you a clue that it's really not a significant aspect of their workload. Over the last five years, functionaries have been asked by arbitrators to evaluate 26 candidates for CU and 16 for OS (people applying for both tools are included in both counts), This is not a large burden. Thryduulf (talk) 15:27, 27 February 2024 (UTC)
  4. Per nom and above, and also the arbcom appointment process has generated too many false positives. Levivich (talk) 15:07, 27 February 2024 (UTC)
    Please can you give some examples of these "many false positives" and explain how a different process would have produced a different outcome. Thryduulf (talk) 15:18, 27 February 2024 (UTC)
    That is an inappropriate question and you're old enough to know that Thryd. No, I'm not going to name the CUs/OSs who I think shouldn't have been appointed over the years. But for starters, the ones who were suspended or removed from those positions would be good examples.
    Arbcom elections and RFAs have also produced false positives, in fairness, but I think RFA has produced the fewest false positives (proportionately) of the three systems.
    But you really should be ashamed for asking for names. I'll give you one name: yours. That's not nice but neither is what you just asked me. Levivich (talk) 15:30, 27 February 2024 (UTC)
    OK, that wasn't a well phrased question. I was trying to understand what you meant by "false positive" (which you've now made clear means people who were appointed who you think should not have been) and importantly why you think an RFA-like process would have produced a different result. I will also follow-up your answer regarding me by asking why you feel I was/am a "false positive"? Thryduulf (talk) 15:43, 27 February 2024 (UTC)
    You know what I meant by "false positive": that people were appointed who shouldn't have been. You're not confused about that. What you are asking is for me to substantiate the claim, which is an inappropriate question, because it would require naming names.
    I never said I think an rfa-like process would produce a better result. The proposal is for a community based process, not an rfa-like one. I think rfa is terrible, hence my voting in favor of various reforms, consistently for years. I said I thought rfa produced fewer false positives (for rfa), but that's not the same thing as saying an rfa-like process would produce fewer false positives for CU/OS appointments. I don't know if it would or wouldn't.
    But I'm in favor of trying a community based system because it might be better than the current system. In general, I think community-based systems work better than representative-based systems on Wikipedia. ANI works better than AE. RFA for all its problems yields better results on average than arbcom CU/OS appointments (calculate the #-removed-per-#-selected ratio and you'll see a much higher % of CU/OS appointments are reversed than the % of RFA passes who are later desysoped, even though both are extremely rare).
    As for you personally, not really the place to discuss that nor a topic I care to spend time on, but for example this line of questioning was a poor choice. Levivich (talk) 16:02, 27 February 2024 (UTC)
    ANI works better than AE if this is your opinion, then I think I understand why we feel so differently about this issue. From my perspective, AE is a very significantly better board (for the situations where they overlap) than is ANI, which vies with RFA for the title of worst venue on the project. Thryduulf (talk) 16:50, 27 February 2024 (UTC)
    @Thryduulf: I'm sorry for personalizing this discussion with my earlier comments. I thought by personalizing this discussion I could make a point about not naming names and personalizing the discussion, but that was a dumb idea on my part in retrospect, my apologies. Levivich (talk) 05:29, 28 February 2024 (UTC)

Oppose (CU and OS appointments)

  1. I see no current problem with ArbCom selecting them, and this has the slightly greater risk of granting the power to the wrong people. Moreover, it could lead to a flood of premature self-nominations. Aaron Liu (talk) 14:11, 26 February 2024 (UTC)
  2. I don't think there's a shortage right now? Mach61 (talk) 14:58, 26 February 2024 (UTC)
  3. No clear motivation. * Pppery * it has begun... 15:18, 26 February 2024 (UTC)
  4. Per WP:NOTBROKEN. Sdkb talk 15:39, 26 February 2024 (UTC)
    lol, that's a page about redirects. You're looking for the WP:AINT essay. Levivich (talk) 15:09, 27 February 2024 (UTC)
  5. The last year in which CUOS were selected by the community (it has been done before) was a disaster for providing the relevant privileges. Izno (talk) 16:21, 26 February 2024 (UTC)
    The one from 15 years ago? That wasn't really a direct community process. It started with arbcom being able to veto any candidate and was then advisory in nature only. 15 years is a long time in the project, I'm not sure we should discard an idea based on such an old example. There are certainly things that can be learned from it - along with years of experience in how many other projects have been able to run CUOS elections themselves. — xaosflux Talk 18:04, 26 February 2024 (UTC)
  6. The current process is that applications, which are accepted at any time, are scrutinised by ARBCOM, those that cannot be dismissed out of hand are passed to the functionaries to for scrutiny. Based on the feedback from functionaries and arbitrators' own discussions, applications that are clearly unsuitable are closed as unsuccessful, community input is sought for all the others. All the comments (arbs, functionaries, community) are then evaluated by arbcom and the successful applicants appointed. An RFA-like process would lead to mostly the same people being appointed as now, just with a greater likelihood of acrimony, incivility, and clearly inappropriate nominations and an increased risk of untrustworthy people being appointed. I'm not clear what problem this is attempting to solve. Thryduulf (talk) 18:07, 26 February 2024 (UTC)
    If that summary is correct (and I have no reason to doubt it) then it sounds like an ideal way to appoint people to those positions. Certainly better than any RFA-like process. Let's remember that ARBCOM is elected by popular vote. Phil Bridger (talk) 19:40, 26 February 2024 (UTC)
    Mostly - except that that is the general "routine" process, arbcom also can just appoint anyone they want if they pass with a 50%+1 committee vote (we see this the most when there is a request from a former funct.) — xaosflux Talk 22:02, 26 February 2024 (UTC)
    This is equivalent to former admins regaining the tools on request as long as at least one 'crat is happy to flip the bit. The only difference is that there is no written activity requirement to be regranted CU/OS (although there is to retain the tools). Thryduulf (talk) 22:33, 26 February 2024 (UTC)
    That process is also generally done in secret without requiring an opportunity for community feedback. — xaosflux Talk 14:17, 27 February 2024 (UTC)
    That the two are essentially the same was my point. Thryduulf (talk) 14:41, 27 February 2024 (UTC)
  7. Thryduulf gives a good summary. I don't currently suspect that the CU/OS system we have is appointing the wrong people, and RfA is exceedingly toxic. — Bilorv (talk) 18:45, 26 February 2024 (UTC)
  8. Oppose. I'm uneasy about making people go through the fiery pits of hell thrice total if they want CUOS. That aside, my bigger concern is the wider community's ability to judge whether someone is trustworthy enough to handle private information. CUOS isn't admin or crat, they're specific roles used to fulfill specific purposes. They carry no "social" value (no accountability requirements, etc.), and if someone who hasn't held an NDA role before asks for it, the whole thing basically boils down to "will this person invade upon privacy or leak personal information?". I sure as hell cannot answer that question. Can you?
    ...yeah, you probably can, because you've probably been here for 15 years or something. But you are not the only demographic that goes to RfX, and with this system it won't be any different.
    If the problem is that you want arbcom out of the way, then sure, I could potentially get behind that. But experienced, non-temperamental people need to make this decision, not the RfA mob. Snowmanonahoe (talk · contribs · typos) 00:45, 27 February 2024 (UTC)
  9. Oppose as I said in the RFA 2024 review @ proposal 15. I dare not to repeat the same statement. Toadette (Let's discuss together!) 07:28, 27 February 2024 (UTC)
  10. Oppose What is the problem that has to be solved? The present RfA-process is quite a bit of mud slinging, so it only decreases the number of able & willing candidates. The Banner talk 08:53, 27 February 2024 (UTC)
  11. Oppose per above. Solution in search of a problem, nothing is broken. -Fastily 09:51, 27 February 2024 (UTC)
  12. The last attempt at community-based CUOS appointments was a total failure, and the current system is more than good enough. JavaHurricane 13:37, 27 February 2024 (UTC)
  13. Previous attempts to try this have descended into a popularity contest and produced no useful feedback about the candidates' suitability for these specific roles. These roles do not necessarily need popular editors who avoid sticking their heads above the parapet for fear of not being elected, but trustworthy, active admins who know how to use the tools and deal with abuse within the bounds of policy. ArbCom appointments with community consultation strikes the right balance in my opinion. HJ Mitchell | Penny for your thoughts? 14:13, 27 February 2024 (UTC)
  14. Oppose A very sensitive position (including being able to do real life harm to people) which has very specific proven-trust requirements. I'm more comfortable with some experienced (elected) people making that analysis and decision. Sincerely, North8000 (talk) 15:23, 27 February 2024 (UTC)
  15. Current system does just fine. NW1223<Howl at me•My hunts> 15:48, 27 February 2024 (UTC)
  16. Oppose A process "similar to how RFAs are run"? Good God, no. Also, per HJ Mitchell.-- Ponyobons mots 19:40, 27 February 2024 (UTC)
  17. Not only is the current system not broken, the community as a whole is very poorly placed to judge an admin's skill at handling those areas that are mostly directly relevant to CUOS skills; revision deletion, SPI activity, deletion-related activity at RC patrol, VTRS activity, and more technical areas like edit-filter work. Non-admins cannot scrutinize most of this activity at all. While trust and judgement are important aspects of being a functionary, there's more to it than that. Community scrutiny is necessary but not sufficient, and the current system of the community being able to provide feedback is exactly what it should be. Vanamonde93 (talk) 19:45, 27 February 2024 (UTC)
  18. This seems to be a solution in search of a problem. Seraphimblade Talk to me 20:07, 27 February 2024 (UTC)
  19. Arbcom managing this seems to be working well, and producing both enough permission holders to get the work done but not spreading access too widely. Arbcom is exceedingly unlikely to appoint any person the community expresses a decent amount of reservation in, and is aware of things the community is not that may make an individual unsuitable. Courcelles (talk) 16:35, 28 February 2024 (UTC)
  20. RfA is a broken process as it is, leading in part to a shortage of admins. Doing the same for CUOS without improving the RfA process is asking for trouble, not in the least because CUOS deals with way more sensitive data and the community as a whole is ill equipped to assess trustworthiness. ConcurrentState (talk) 18:58, 28 February 2024 (UTC)
    In discussions about the low number of applicants for functionary permissions in the 2023 round it was noted that the shortage of new administrators was likely an influential factor. RFA's brokenness is the most significant reason for the shortage of new administrators. Thryduulf (talk) 15:05, 29 February 2024 (UTC)
    I don’t disagree in the slightest. I was just hedging to avoid nitpicking about all the possible factors that lead to a shortage of admins. ConcurrentState (talk) 19:28, 29 February 2024 (UTC)
    I was actually agreeing with you, just noting a downstream problem of the one you identified. Thryduulf (talk) 20:13, 29 February 2024 (UTC)
    Ah! My bad, I misinterpreted your comment. ConcurrentState (talk) 21:35, 29 February 2024 (UTC)
  21. Solution in search of a problem. Sandstein 14:55, 29 February 2024 (UTC)
  22. In agreement with Sandstein. TrangaBellam (talk) 18:17, 29 February 2024 (UTC)
  23. The process often requires considerable privacy. ArbCom may have to learn, or deal with, very personal information of potential CUOS. An RfA like process is incapable of handling such sensitive issues. We already ask for community feedback for candidates. Why would we want more RfA, when RfA is concededly broken? (case in point: the concurrently running RfA RfC). If it ain't broke, don't fix it. CaptainEek Edits Ho Cap'n!⚓ 05:14, 1 March 2024 (UTC)
  24. Appears to be a solution looking for a problem. Stifle (talk) 10:22, 1 March 2024 (UTC)
  25. RfA, while it might be the only method we've come up with for selecting administrators, is not such a glorious success that we ought to be using it as a model for anything else, at least not when the current system is perfectly functional. And there are substantial differences between CU / OS and admins - adminship involves a large number of often very subjective judgments on things like eg. whether someone is likely to continue to be a problem in the future and what sanctions are necessary to prevent this. CU / OS, by comparison, are much more rigid and technical - there is a bit of subjectivity around the edges, but not nearly so much, and it mostly comes down to very simple categorizing using a few straightforward rules. This means that while judgment is important for those roles it doesn't imply as much need for additional community trust. Admins need to understand, and be trusted to accurately enforce, essentially all of Wikipedia's policies and practices; CU / OS are each mostly about a much more narrow slice of it, and a slice that generally involves a bit less subjectivity at that. --Aquillion (talk) 00:46, 2 March 2024 (UTC)
    Have to be honest, but I think this is backwards in terms of how much trust is required. Admin actions can be and are scrutinized easily and regularly, that can't happen in the same way with CU/OS. OS is maybe straightforward in the way you describe though the information involved can be as sensitive as can be. CU, on the otherhand, is far from categorizing a few straightforward rules. There is a huge amount of discretion involved and judgement calls are regularly required in terms of whether a check has been justified and if it has whether the results indicate a violation of policies and guidelines. I also think most admins only operate in a narrow slice of the admin universe so they don't actually need to know every policy and guideline. Best, Barkeep49 (talk) 00:56, 2 March 2024 (UTC)
  26. RfA has serious problems and I don't think we want to replicate them to other processes. The current system for CU and OS appointments seems to work well, and allows adequate community feedback. the wub "?!" 16:55, 3 March 2024 (UTC)
  27. Per Sandstein. ‍ Relativity 05:35, 4 March 2024 (UTC)
  28. Oppose - CU and OS are both high-trust roles with real-world legal implications, with access to advanced tools to manage very sensitive information, which can do serious real-world harm to real persons and the project itself if they are misused. They are chosen by a committee which understands the purpose of the roles and evaluates individuals' aptitude and suitability for them, as well as whether or not a candidate fills an identified need. The community elects that committee, Arbcom, and community input is part of the appointment process. Making these specialized positions open to general election puts us at fairly serious risk from motivated malicious groups wanting access to the politically valuable information available; frankly it's already too much of a risk IMO that Arbcom members gain access to these tools through election. Ivanvector (Talk/Edits) 17:11, 4 March 2024 (UTC)
  29. Oppose These roles have real-world legal effects and are required to sign an NDA. We definitely shouldn't elect them by popular vote. The current system works just fine. QuicoleJR (talk) 21:43, 7 March 2024 (UTC)
  30. Oppose per Thryduulf finding only 42 CU/OS evaluations over the past five years, suggesting that the current system poses a minimal burden on ArbCom while avoiding the toxicity of RfA. BluePenguin18 🐧 ( 💬 ) 06:45, 8 March 2024 (UTC)
  31. Oppose for the nth number of good reasons above, plus ArbCom just started essentially open instead of timed applications - which was the big step forward needed in this process. Lets give it a chance to work. -- Amanda (she/her) 02:09, 11 March 2024 (UTC)

Neutral (CU and OS appointments)

  1. I'm indifferent at this point. Both systems appear to have their flaws and their benefits. voorts (talk/contributions) 15:55, 3 March 2024 (UTC)

Discussion (CU and OS appointments)

Note managing access to CheckUser and Oversight tools is currently in the scope of the arbitration committee by policy. Changing this requires an amendment to the arbitration policy. isaacl (talk) 18:20, 26 February 2024 (UTC)

So that would be 100 petition signatures and a majority on an up and down vote? I believe that is what it was on the vote that removed any remaining provision for an appeal to Jimbo.--Wehwalt (talk) 20:06, 26 February 2024 (UTC)
I didn't want to repeat the process since I linked to it, but mostly yes. An amendment can be also be proposed for ratification if it is approved by the committee. The majority vote to ratify must have at least 100 supporting statements. isaacl (talk) 20:38, 26 February 2024 (UTC)
Maybe ... while changing the arbcom policy requires those hoops, changing the cu/os polices don't really. This would really need to be well supported to make the change either way (with more than enough support to do both). — xaosflux Talk 22:19, 26 February 2024 (UTC)
I think the wording in the current arbitration policy has given sole responsibility to the arbitration committee for appointment of checkusers and oversighters. I agree that meta:Oversight policy states that local elections can still be preferred over appointment by the arbitration committee, and it could be argued that meta:CheckUser policy leaves the question open. However by ratifying the arbitration policy, the community agreed on giving this responsibility to the arbitration committee, as well as agreeing that this scope has to be altered via the arbitration policy amendment process. isaacl (talk) 22:54, 26 February 2024 (UTC)
It could certainly create one of those community consensus crisis sort of situations. Regardless, I certainly would want a wholesale cleanup of everything related, including the arbpol, if this were to gain traction. Realistically, I think this proposal should have gone through more development and leaves more questions open then the change it is trying to promote. — xaosflux Talk 23:11, 26 February 2024 (UTC)
I'm not sure if there would be a crisis. The stewards would have to ignore the English Wikipedia arbitration policy and accept community-requested assignments, and it doesn't seem to me that's likely to happen. I agree that it would have been fruitful to have more discussion to develop a rationale and proposed process. isaacl (talk) 23:24, 26 February 2024 (UTC)
I'm inclined to trust the steward when he says such a situation with the stewards would create a crisis. Perhaps it would be resolved the way you suspect but perhaps not. Best, Barkeep49 (talk) 23:07, 29 February 2024 (UTC)
In essence I agree with Xaosflux that the arbitration policy should be amended to align with community desires on appointing checkusers and oversighters. Thus I raised this need in my initial comment. In theory the arbitration committee could just agree to rubberstamp community appointments, but I think the community wouldn't feel satisfied by an approach that relied on the benevolence of the committee. isaacl (talk) 23:38, 29 February 2024 (UTC)
It would end up being a case if changing the local checkuser policy to allow elections were to be strongly supported by the community, and then there we to be an actual successful election - and how much of a counter argument the committee wanted to put up. This sort of change would certainly require a very well attended RFC for a project this size (where the supporters would likely already be over 100 as well). The best case would be that if successful a graceful transition from the current committee happened. I could see the stewards team stalling any appointment pending additional community deliberations over collisions between multiple policies. — xaosflux Talk 23:39, 29 February 2024 (UTC)
Sure, that would be a reasonable approach. We might be thinking of different connotations for the word crisis. I agree that most likely there would be sufficient support to amend the arbitration policy at the same time. isaacl (talk) 00:03, 1 March 2024 (UTC)
Likely - it certainly wouldn't stop people from reading or creating articles! — xaosflux Talk 00:11, 1 March 2024 (UTC)
This is a tangent, but if any of you are willing to take on these roles, please consider volunteering. I am worried that whenever m:IP masking/mw:Help:Temporary accounts gets here (not in the next few months, but could possibly be later this calendar year), that we might need more CUs than we have now, particularly during the first few months of the transition. WhatamIdoing (talk) 04:22, 27 February 2024 (UTC)
Another point that I don't think has been made is that, particularly for OS applicants, one thing that is often significant is what the requests they've submitted have been like as this can give an indication of what their judgement will be like in assessing requests from other people. For example I likely would not support an application from someone who frequently asked us to suppress things that clearly don't need it, and I likely would support someone whose reports were almost always of things that do need suppression. However, editors who are not oversighters do not have access to this information (indeed when oversight works perfectly almost nobody knows it has happened). Thryduulf (talk) 01:11, 2 March 2024‎ (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.

Proposed formatting changes to the universal editnotice

 You are invited to join the discussion at MediaWiki talk:Editpage-head-copy-warn § New design. Sdkb talk 17:10, 11 March 2024 (UTC)

Converting of the sandbox reset link to a button

Moved from Template talk:Sandbox heading

Hello! In case you're wondering, my suggestion is to make the "Click here to reset the sandbox" link go from this:

Click here to reset the sandbox.

To this:

Click here to reset the sandbox.

Is it possible? - Master of Hedgehogs (converse) (hate that hedgehog!) 13:51, 6 March 2024 (UTC)

I'm pretty sure that it's possible, although that question would be better asked at WP:VPT. The more interesting question, that belongs here, is whether it is desirable. Phil Bridger (talk) 20:10, 6 March 2024 (UTC)
This new design is eye catching and could be more user friendly. Ktkvtsh (talk) 04:24, 7 March 2024 (UTC)
How about <div class=plainlinks>[https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit&preload=Template:Sandbox+reset&summary=Reset+sandbox&oldid=596189391 {{Clickable button 2 | '''Click here to reset the sandbox''' |link =no |color = blue}}]</div> which renders as
Click here to reset the sandbox
See and the subsequent diff. I'm on mobile right now so no idea about how it works on PC. Sincerely, Novo TapeMy Talk Page 17:58, 7 March 2024 (UTC)
I did it. - Master of Hedgehogs (converse) (hate that hedgehog!) 01:07, 10 March 2024 (UTC)
I think it is a good idea, and it seems more user-friendly. It draws more attention to itself, but I don't think that is a problem. QuicoleJR (talk) 19:46, 10 March 2024 (UTC)
Agree, I think it's better for users new to the sandbox to have it emphasized that you can reset it. Pksois23 (talk) 09:09, 15 March 2024 (UTC)

Reworking Sandbox Heading

Hello! I am requesting that {{sandbox heading}} be changed to this:

More information Proposed sandbox heading text ...
Close

Should this change be made? - Master of Hedgehogs (converse) (hate that hedgehog!) 18:31, 10 March 2024 (UTC)

Yes, it should be changed to this version. 23.245.44.64 (talk) 18:34, 10 March 2024 (UTC)
Support. This makes the reset option more visible. It might make people pay less attention to the heading, but I doubt it. Sincerely, Novo TapeMy Talk Page 16:17, 11 March 2024 (UTC)
Noting that I've left an invitation to this discussion at Template talk:Sandbox heading. All the best. ‍—‍a smart kitten[meow] 19:35, 16 March 2024 (UTC)

Creating Disambiguation page

The page “People’s Publishing House” is redirecting to a Beijing based People’s Press.

please remove this redirect and instead create a disambiguation page of “People’s Publishing House”, so that other pages with similar names, for example “People’s Publishing House (India) can be listed on that disambiguationmpage. Pallav.journo (talk) 10:20, 20 March 2024 (UTC)

If they really are of equal importance then a two-entry disambiguation page may be the best solution. However, the new article you created, People’s Publishing House (India), currently has only one primary source and may be at risk of deletion. Even if the new article remains, People's Publishing House may be retained as a primary redirect if the Chinese state press is deemed much more significant than a private company. Certes (talk) 10:48, 20 March 2024 (UTC)

Make Todays Featured List appear exactly every 3 days instead of 3-4 days

I'm not sure if this is the right place to ask, but I'll ask it here.

Something that I've always been confused about is why TDL has a schedule where one list will appear three days after a list and then the next list will appear 4 days after instead of just three days again. I don't see how this could be for "we could run out of unique lists" purposes because there are over 3100 lists that haven't been featured on the main page.

So I propose that Todays Featured List should appear every 3 days instead of every 3-4 days on the main page. Onegreatjoke (talk) 00:41, 18 March 2024 (UTC)

Per Wikipedia:Today's featured list, it's because TFL appears Mondays and Fridays, aligning with days of the week. That seems to work fine, so I don't see a need for a change. Sdkb talk 08:12, 18 March 2024 (UTC)
Exactly. Keep it on Mondays and Fridays! Bduke (talk) 05:20, 20 March 2024 (UTC)
I think the "every Monday and Friday" pattern makes it easier for people to know when to look for it than your proposal would. --User:Khajidha (talk) (contributions) 14:23, 20 March 2024 (UTC)
If you want to have more TFLs (no idea whether that is a good idea or not), just go for three times per week. —Kusma (talk) 17:09, 22 March 2024 (UTC)
Well, amn't i the fool! I can't remember how long we've had TFLs and how long i've been reading them, years and years though, and until this moment i have never realised that they are on a schedule; i have always just scrolled down the Main Page wondering if there'll be a TFL. Boy, do i feel stupid embarrassed today, ~ LindsayHello

Sources: clarify that they may be on a linked page

MOVED
to WP:VPP. Closing to keep the discussion centralized. NotAGenious (talk) 17:19, 23 March 2024 (UTC)

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


I wish to seek to change the wikipedia policy WP:SOURCE. Currently this states "Any material lacking an inline citation to a reliable source that directly supports the material may be removed and should not be restored without an inline citation to a reliable source." in the section Responsibility for providing citations. I propose amending this with the additional sentence "Sources may be contained in a linked article."

 RATIONAL FOR THE PROPOSED CHANGE

I believe that requiring sources on every page brings a number of problems: 1) it is onerous and inefficient and discourages linking relevant articles to pages, especially for new editors: 2) the relevant article may include more sources, mentions of the article might only include one, so anyone looking for useful information might not see it; 3) in a rapidly moving field sources may be updated in an article but that might be missed on linked pages. In any case it is easy for anyone to click on the link to see the article with all relevant sources. Hewer7 (talk) 13:24, 23 March 2024 (UTC)

  • Comment I'm not too familiar with how things work here at the village pump but I believe policy changes should be discussed at Wikipedia:Village pump (policy).
CanonNi (talk) 13:30, 23 March 2024 (UTC)
Thanks. But I thought I saw that proposals should be discussed here first? Hewer7 (talk) 13:39, 23 March 2024 (UTC)
You are trying to change a existing policy, not create a new one, so WP:VPP is the correct place. CanonNi (talk) 13:40, 23 March 2024 (UTC)
I see. Thanks. Hewer7 (talk) 13:48, 23 March 2024 (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.

Feedback sought for proposal to drop archival bot notice params from Template:Talk header

Your feedback would be appreciated at Template talk:Talk header#Proposal to drop archiving params. The {{Talk header}} template has no control over Talk page archiving, but it does have four params used to generate a "bot notice" in the header box which says something like: "Archiving: 90 days" (plus a tooltip with more info). It's just a string displayed in the header, which may or may not reflect what the actual archiving period is. A recent change to Template:Talk header automates the generation of this string directly from the archive config, rendering the four Talk header params unnecessary. Imho, they should be deleted from the template in order to prevent misleading bot notices in the Template header box when the given params get out of sync with the config. More details at the proposal discussion. Thanks, Mathglot (talk) 04:43, 29 February 2024 (UTC)

Template:Talk header is a highly visible template, so I've added {{subst:DNAU|3|weeks}} to this discussion to give it sufficient time to air. Mathglot (talk) 10:37, 3 March 2024 (UTC)

GeoHack preference

The GeoHack system offers a choice of about two dozen map applications. I always choose the same application, but I have to make that choice every time I use GeoHack. It would be nice if my choice could be saved in a preference setting so that whenever I click on a coordinate I go directly to my preferred map app instead of having to again select which app. Sbowers3 (talk) Sbowers3 (talk) 14:13, 23 March 2024 (UTC)

Same. jp×g🗯️ 17:38, 24 March 2024 (UTC)
Magnus Manske is listed as one of the maintainers for mw:GeoHack. He might know whether a bit of .js or something could solve this problem. If he isn't on wiki in the next couple of days, I suggest taking this question to Wikipedia:Village pump (technical) instead of asking here. WhatamIdoing (talk) 04:51, 26 March 2024 (UTC)

Showing "Redirected from" notice at top of section

Tracked in Phabricator
Task T360255

When one arrives at an article via a redirect, the page is rendered with an additional line saying "(Redirected from [...])", directly (?) below the "From Wikipedia, the free encyclopedia" byline below the article title.

For most of the many redirects that target sections of articles, instead of entire articles, that means that this line isn't in view, which makes little sense to me. After all, if the page includes any {{redirect}}-type dab templates, those are placed as section hatnotes, not article hatnotes, which makes a lot of sense.

Why not show the notice below the section title, either instead of or in addition to where it is now?

- 2A02:560:5829:B000:7D78:FB68:39A:4A28 (talk) 16:22, 16 March 2024 (UTC)

I think this is a good question. The notice linking to the redirect is useful as a way to get to the redirect page. and it informs the reader why they are at a place they would not expect to be, but it should be displayed where it can be seen, and preferably where it is most relevant, which would usually be at the redirect target. At the section header would be appropriate for R to section. Not sure about R to anchor. Cheers · · · Peter Southwood (talk): 17:03, 16 March 2024 (UTC)
Ah, yes, anchors, good thinking. Their essential invisibility tends to make me fail to consider them more often than not. In this context, I recken that's probably fine, though, because keeping the thing itself hidden but then implicitly or explicitly drawing attention to it in a visible notice would be a bit weird, even if there were a nice space for it.
That said, I suppose a generic phrasing like "(Redirected from [...] to this location)" would work for both, or even all three, cases. That'd leave the space issue to be solved.
- 2A02:560:5829:B000:7D78:FB68:39A:4A28 (talk) 22:46, 16 March 2024 (UTC)
Good idea. Cuts down on confusion. How it would be implemented is another question. 🌺 Cremastra (talk) 17:17, 16 March 2024 (UTC)
+1 Good idea. I'd suggest filing a task on Phabricator to get some developer attention. Sdkb talk 18:19, 16 March 2024 (UTC)
Yeah, I've noticed that. Thanks for proposing this. Donald Albury 18:54, 16 March 2024 (UTC)
This would've been a perfect technical wishlist submission if they hadn't just gotten rid of the technical wishlist. --Ahecht (TALK
PAGE) 13:41, 17 March 2024 (UTC)
Definitely "in addition", rather than "instead of". At the very least, this would help editors whose muscle memories have them press Home when following a redirect to a section. jlwoodwa (talk) 04:57, 18 March 2024 (UTC)
There is a counterargument to be made, using the same scenario: If, after jumping to the top of the article, for whatever reason, one decides one wants to go back to the redirect's target location, again for whatever reason, the proposed change adds a new way to do that - Ctrl+F "redirected". Works either way, of course, but a bit better when there are no duplicates elsewhere.
Ah, but now that I imagine myself doing that, selecting "redirected" in the notice at the top, then Ctrl+F, then just hitting Enter once or twice may be even more convenient than typing it in. Never mind!
- (OP) 2A02:560:5829:B000:99D:3DCE:4DAE:FDB (talk) 14:19, 18 March 2024 (UTC)
I totally support this idea, you should definitely file this on Phabricator! Cocobb8 (💬 talk • ✏️ contribs) 13:50, 18 March 2024 (UTC)
I will just mention that it works completely differently on mobile. Here, no matter where it sends you, a notice appears for a few seconds at the bottom of the screen, and then disappears. QuicoleJR (talk) 13:23, 21 March 2024 (UTC)
I occasionally want to Rcat redirects. When I'm redirected to a section, I have to scroll all the way up and click the link. I would like it if it was just there, too. SWinxy (talk) 14:28, 28 March 2024 (UTC)

Tracking categories template proposal

I propose a new design for the tracking categories template which is used to mark category pages as tracking categories. If I am not mistaken, we can group tracking categories into three groups:

  1. Core tracking categories (core to MediaWiki)
  2. Extension tracking categories (added to MediaWiki by extensions)
  3. Template/Module tracking categories (implemented by templates/modules)

I believe that the third group is the largest of the three. Such tracking categories are used to track missing or invalid parameters in template transclusions amongst other things. They are not integrated into the MediaWiki instance and are therefore not listed on Special:TrackingCategories. In theory, it is possible to have tracking categories which are manually included on pages the same way content articles are manually categorised, but I am not aware of such tracking categories.

The aim of this proposal is to add some technical clarification to the template but also simplify its use. I find the current template clumsy looking and over-engineered in its 3-in-1 approach (i.e. certain templates can be transcluded if certain parameters are used. Why not just transclude them explicitly on category pages instead if they are needed?). To complicate things further, there is a template called Maintenance category which can convey the respective messages of the templates Tracking category and Container category. I shall refer to templates that transclude others based on parameter usage as combination templates.

I therefore propose the following:

  1. That a redesign of Tracking category (demonstrated below) be adopted.
  2. That one template be used for each purpose instead of combination templates or a mix of combination templates and individual templates per the current practice.
  3. That the template Possibly empty category be deprecated and its message conveyed instead by Tracking category. It should be obvious to any administrator not to delete tracking categories, but it can be stated that tracking categories may at times be empty or even most of the time.
  4. That the combination template Maintenance category be reduced to a simple message box for those maintenance categories which are not tracking categories.

Core tracking categories

This is what the template could look like on the category page Pages with template loops.

This is a tracking category which MediaWiki expects to exist. It is used for the maintenance of the project and may be empty occasionally or even most of the time. Its name is localised via the message Template-loop-category.

The transclusion code may look something like this:

{{Tracking category
| message = Template-loop-category
}}

Extension tracking categories

This is what the template could look like on the category page Pages with syntax highlighting errors.

This is a tracking category which the extension SyntaxHighlight expects to exist. It is used for the maintenance of the project and may be empty occasionally or even most of the time. Its name is localised via the message Syntaxhighlight-error-category.

The transclusion code may look something like this:

{{Tracking category
| message = Syntaxhighlight-error-category
| extension = SyntaxHighlight
}}

Template/Module tracking categories

This is what the template could look like on the category page Articles needing coordinates.

This is a tracking category which the template Coord missing expects to exist. It is used for the maintenance of the project and may be empty occasionally or even most of the time.

The transclusion code may look something like this:

{{Tracking category
| template = Coord missing
}}

If the tracking category is implemented by a module, then the parameter name module would be used instead. If the editor is lazy and only puts {{Tracking category}} on the page, then the template should simply say: "This is a tracking category which is expected to exist. It is used for the maintenance of the project and may be empty occasionally or even most of the time."

Each category page should go into further detail about its purpose. On core and extension tracking category pages the information would most likely be included on the pages themselves but in the case of template/module tracking categories the information would most likely be transcluded from dedicated templates.

Thank you for your attention. Stefán Örvar Sigmundsson (talk) 01:02, 31 March 2024 (UTC)

How would you handle tracking categories like Category:All articles with unsourced statements, which are expected to exist by a fairly long list of templates? Anomie⚔ 12:13, 31 March 2024 (UTC)
This is a tracking category which many templates expect to exist. It is used for the maintenance of the project and may be empty occasionally or even most of the time.
{{Tracking category
| many_templates = true
}}
The number or nature of the many templates should be stated on the category page itself. Stefán Örvar Sigmundsson (talk) 20:31, 31 March 2024 (UTC)
Re your idea to combine "tracking category" and "possibly empty category" based on the idea that tracking categories shouldn't be deleted, dated categories like Category:Articles with unsourced statements from July 2022 don't fall under that generalization. Once their month has passed and they've been emptied, they're deleted. Anomie⚔ 12:20, 31 March 2024 (UTC)
This is a tracking category which the template Citation needed expects to exist. It is used for the maintenance of the project and should be deleted once its purpose is served.
{{Tracking category
| template = Citation needed
| delete = true
}}
The purpose of the category and how long it is expected to exist should be specified on the category page itself. Stefán Örvar Sigmundsson (talk) 20:31, 31 March 2024 (UTC)

Should (some or all) of Renamed user g5s6n3yi8z7g08cs's unapproved bot edits be reverted?

Thread: Wikipedia:Bots/Noticeboard#Fully automated edits without BRFA - Request for assistance

Summary: Renamed user g5s6n3yi8z7g08cs made unapproved automated edits performing various tasks over the course of a couple months using PAWS. Some of the tasks should perhaps be mass-reverted. Pppery made a list of them in the other bot runs section. Snowmanonahoe (talk · contribs · typos) 01:41, 2 April 2024 (UTC)

AI for WP guidelines/ policies

Advertising sister projects

Is it time for a new design for the main page?

Proposal: Add a link to the WP:Contents page either on the Main Page itself or on the mobile sidebar

Bring back the Book Creation Tool.

Deprecating new unsourced articles

Related Articles

Timelines

Top Qs

Fact Checks