Wikipedia:Village pump (proposals)/Archive 174

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

Village pump (proposals) archive  

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

---

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

Move good/featured article topicons next to article name

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.

---

Firstly, apologies if this has been brought up before, I couldn't find it in a search of the archives.

My suggestion is pretty simple: move the topicons indicating good or featured status from the top-right corner to after the article name, as is done on other language projects, such as here on the Danish Wikipedia. They are much more visible this way without being more obtrusive.

Why? Because I think the current icons are too well-hidden for the average visitor to notice, tucked away in the corner - I've been using Wikipedia for years and I barely ever notice the little gold star as my eyes jump to scanning through the content below. In my extensive, highly accurate survey of a couple of non-editor friends, they didn't know there's a recognised difference in quality between a long C-class article (say, Operation Market Garden) and a shorter featured article, because they didn't know good & featured articles existed.

Both have a standardised peer review process (the only subsection of Wikipedia's content that goes through this process) and have been around for a long time. Making this clearly visible is valuable for exactly the same reasons we undertake good & featured reviews: informing readers that the article is considered to meet a higher standard than average Wikipedia content; promoting greater trust in the content (vs. other Wikipedia content); increasing transparency of Wikipedia's processes (i.e. some sections of content have been peer-reviewed, others haven't); etc.

The objections I can see are that it could encourage people to think that the visible version of the page is mistake-free, to which I would respond that 1) the icons are already there, it's just that people aren't noticing them and 2) Wikipedia has been around for long enough for most people to know it's not a reliable source, and icons don't guarantee accuracy. I look forward to hearing others' thoughts on this. Cheers, Jr8825 • Talk 13:38, 6 October 2020 (UTC)

• Support Seems like an improvement to have the icon right next to the article title to make the meaning more clear. Having review icons next to names is becoming more common recently,(e.g. Twitter and Youtube verified accounts) so it makes sense to evoke some of that design language, since GA/FA also involves a kind of external review. Without knowledge of what a GA/FA is, it's not obvious from the current context what the function of the icons is. Seems like a clear improvement for WP:READER who isn't familiar with Wikipedia's internal article review process. 〈 Forbes₇₂ | Talk 〉 15:06, 6 October 2020 (UTC)
• Support increased prominence for GA/FA icons, per the nom's excellent rationale. I'll need to think/research/hear out others a bit more before committing to this specific remedy, but we certainly ought to do something. {{u|Sdkb}} ^talk 16:36, 6 October 2020 (UTC)

  Clicking through to Danish Wikipedia, the icon there looks fantastic, so I'm moving to full Support unless anyone comes up with a better idea for how to display the icons to give them more prominence. {{u|Sdkb}} ^talk 00:42, 7 October 2020 (UTC)

• For some reason, it doesn't show when using the Timeless skin. If that can be solved, I'd consider supporting. Isabelle ^🔔 22:39, 6 October 2020 (UTC)
• Oppose I'm sympathetic to the arguments provided, and I do agree with most of the rationale, but I'm opposing because I think the current way of doing it is more aesthetically pleasing. I think that putting it right next to the article title does look a bit obtrusive. As a side-note, regulars of the FAC and GA processes should probably have been notified of this discussion here and here. Ichthyovenator (talk) 22:54, 6 October 2020 (UTC)

  Ichthyovenator, I notified WikiProject Usability, which is probably the most relevant WikiProject, even though it's not super active. The GA and FA folks have now been notified as well.

  Regarding your opposition, do you have any ideas about alternative ways we might emphasize FAs/GAs? {{u|Sdkb}} ^talk 23:04, 6 October 2020 (UTC)

Sdkb I personally really like how it is handled now but I do see how someone not familiar with Wikipedia and the FA/GA process would miss the icons. What I'm fearing is that putting big icons next to the article titles will make it look cluttered. I can see that I'm clearly in the minority here; maybe i just need to see some concrete design suggestions, it is probably possible to move the icons as per your suggestion without making it look cluttered or obtrusive. Ichthyovenator (talk) 10:22, 7 October 2020 (UTC)

• Support. Including GA articles. Current icons are not really visible, especially on the mobile site. T8612 (talk) 23:00, 6 October 2020 (UTC)
• Support You are right. The icons remains unnoticed by the common readers. I noticed that, here, in India, most Wikipedia readers don't know what the GA and FA are. --Gazal world (talk) 23:02, 6 October 2020 (UTC)
• Support placing alongside article title in mobile view. I think the current arrangement for desktop is ok though. Peacemaker67 (click to talk to me) 23:09, 6 October 2020 (UTC)

  @Peacemaker67: Sdkb has pointed out this is currently a technical limitation on mobile. My issue with desktop is I don't feel that reader's eyes naturally go to the top-right corner when they open and read an article, particularly if they're doing so quickly. Jr8825 • Talk 00:44, 7 October 2020 (UTC)

  I've commented there. I'm not sure I like the idea of sitting the star next to the article title in desktop though, mainly from an aesthetic/professional appearance perspective. Peacemaker67 (click to talk to me) 00:55, 7 October 2020 (UTC)

• Support - I like this idea. — Rhododendrites ^talk \\ 23:13, 6 October 2020 (UTC)
• Weak support I think it's probably better for the reader, but I don't like it as an editor. Full support for placing alongside title in mobile view. Seems like a pretty simple thing to do, happy to expand on my rationale if wanted. Eddie891 ^Talk _Work 23:31, 6 October 2020 (UTC)
• I don't agree with the premise. I don't think additional prominence is required for the good article/featured article icons. Readers are very good at judging the quality of articles on their own, without needing more intrusive cues. isaacl (talk) 23:54, 6 October 2020 (UTC)

  I'm not saying that readers can't judge the quality of an article (although I would probably disagree with you about how easy it is to do this as a reader), it's that I suspect many people are unaware that featured/GA content exists and that this means most of the text will have been peer-reviewed and undergone some methodical scrutiny, unlike the majority of articles. It also tells readers what to expect, rather than requiring them to pick up through their reading whether an article is accurate or not. Jr8825 • Talk 00:05, 7 October 2020 (UTC)

  My personal view is that most readers give their own personal judgment greater weight than an internally assigned icon, and thus the icon doesn't need additional prominence. isaacl (talk) 00:18, 7 October 2020 (UTC)

  @Isaacl: I'm with Jr8825 here; I strongly disagree that readers are sufficiently aware of the GA/FA system. Ask a non-Wikipedian in your life how the website indicates its highest-quality articles, and I suspect most people will be stumped. Similarly, ask them whether it's better for an article to have a bronze star or a circled green plus sign, and most won't have a clue. There's more than a little tragic irony when you think about it: we put a massive amount of effort into identifying which articles are worthy of being designated with our quality markers, yet because our user interface is so terrible, the 50% of readers on mobile don't see them at all and most of the desktop readers miss their meaning. {{u|Sdkb}} ^talk 00:39, 7 October 2020 (UTC)

  My assumption is the icon isn't visible enough to some readers to notice/process it, so it's not being factored in to their judgements at all. And my other presumption is that encouraging readers to be aware of and consider FA/GA status when they decide how much they trust what they're reading is generally a good thing. Jr8825 • Talk 00:46, 7 October 2020 (UTC)

  I agree that in all probability, many readers are unaware of what a bronze star or circled green plus icon means (that would be another worthwhile discussion: are there better icons or some other indicators that can be used?). In my view, though, I think readers place more importance on their own judgment than the evaluation of a pseudonymous set of persons within the Wikipedia community, and so giving the icons more prominence is unwarranted. isaacl (talk) 00:47, 7 October 2020 (UTC)

  On that tangent, to communicate article quality to readers, a familiar paradigm (1-star, 2-star, 3-star, 4-star) would be most recognizable and more easily understood than abstract icons. Use 1 for stub/start/nonrated, 2 for B/C, 3 for GA, 4 for FA. Schazjmd (talk) 00:58, 7 October 2020 (UTC)

  In such a scheme, I maintain that the distinction between B, C and GA is indistinguishable; they are all adequate at best, dangerous at worst. SandyGeorgia (Talk) 01:29, 7 October 2020 (UTC)

  I've been thinking about launching an initiative to redesign the GA/FA topicons for a while. You've inspired me to kick it off at the graphics lab: see Wikipedia:Graphics Lab/Illustration workshop/Archive/Sep 2021#Good article and featured article topicon redesign. {{u|Sdkb}} ^talk 05:14, 7 October 2020 (UTC)

• I would support for mobile view (though note the subsection below) and am neutral on desktop view - other suggestions for prominence per Jr's rationale may be a better idea, unless the icon is put before the title to maintain a standard alignment. Kingsif (talk) 00:29, 7 October 2020 (UTC)
• Strong oppose: this is a well intentioned but very bad idea because it will mislead our readers even further. (As a regular FA participant, who also edits medical FAs, this potential misleading of readers would be critical wrt our medical content, most of which is not up to FA standards. See User:SandyGeorgia/sandbox2#Medical FAs.) We will be sending a more prominent signal to readers that the articles with some sort of icon next to their name have been checked, vetted, reviewed, or are somehow better than other articles on Wikipedia, but those readers won't necessarily have the skills or knowledge of Wikipedia to understand in what circumstances those icons are (or mostly, are not) still valid. Average readers probably don't know how to check the article milestones to discover when the article passed content review, whether the original authors are still actively engaged, whether the article has changed substantially since it passed content review, and whether the pass was a good one even when it occurred. With months-long efforts at WP:FAC and WP:FAR to get editors to actively engage in reviewing our out of compliance and very old FAs at Featured article review, we still have a considerable backlog of unreviewed older FAs (many more than those for which talk page notice has been given), and basically, no one is interested in engaging at FAR to deal with them. The situation with GA is even worse, as they start out as one person's opinion, and ... I can't even remember how long ago the last GA sweeps were. The situation now is obscure; the average reader probably doesn't know how an article is rated. But telling them more prominently that an article is well-rated when at least one-third of our FAs are not, and GAs were never more than one person's opinion, would mislead them even further. Article assessment is an internal matter that experienced editors know how to interpret: we can go to the talk page, look up the history, and say, "Oh, that article was passed ten years ago on only three supports, it has grown to twice the size since then, and the original editors are no longer watching, so the article has taken on lots of inaccurate cruft". The average reader might not be able to do that. We should keep assessments as an internal matter, that experienced Wikipedians know how to interpret. That the average reader doesn't know what the icon in the upper right hand corner means is just fine; let's not make a more prominent, and misleading, statement about the quality of our pool of GAs or FAs.
  Oh, and please go and nominate some articles, and review some articles, at WP:FAR. The pool of FAs is only as good as the worst of them. SandyGeorgia (Talk) 00:50, 7 October 2020 (UTC)

  I completely understand where you're coming from, the reason I feel differently is that I feel making FA/GA content more visible may encourage readers to understand how Wikipedia works better, particularly if they're encouraged to click on the icon and read more about how featured content works (see the example on the Danish Wikipedia, which has a tooltip saying This is a featured article. Click here for more information). Then all that's needed is a better explanation of what featured content is at WP:FA, as the current text just makes it sound like it's perfect. Honestly, I can imagine this being a great way to spread awareness to readers about how Wikipedia really works - i.e. any revision can be good or bad. Ed: And to me, it seems pointless putting in all the effort of ensuring FA articles meet FA quality, if readers are completely oblivious to their existence. Jr8825 • Talk 00:54, 7 October 2020 (UTC)

  I also can't see why such a tooltip couldn't say 'A version of this article was assessed as Featured in January 2010. Click here for more information'. Jr8825 • Talk 01:01, 7 October 2020 (UTC)

  That won’t work either. That would send our readers to a dated 2006 version for Tourette syndrome, which I have constantly maintained and overhauled. And, for a GA example, it would send our readers to the embarassing GA pass which misidentified a well know historical figure, Douglas MacArthur. I can provide worse examples of GA issues; I have already provided a list of medical FAs with issues. SandyGeorgia (Talk) 01:24, 7 October 2020 (UTC)

  Sorry, just to clarify, I didn't mean that the icon should send them to an old revision, just that the tooltip could also indicate when the assessment was made while encouraging viewers to click through (linking to WP:FA as it currently does). Jr8825 • Talk 01:27, 7 October 2020 (UTC)

  Same, regardless. Tourette’s passing in 2006 might imply it is no longer at standard. Which is misleading. SandyGeorgia (Talk) 01:32, 7 October 2020 (UTC)

  Perhaps 'This article reached Featured status in January 2010. Click here for more information'. (The German Wiki uses similar text.) Although I'm not sure whether it's a bad thing to say that a previous version was judged as standard, after all it's the most accurate statement and helps shows how much Wikipedia's quality varies with revisions. Jr8825 • Talk 01:35, 7 October 2020 (UTC)

  I think this is a perfectly reasonable concern about FAs, but it goes way beyond the scope of this discussion. What you seem to be proposing is that FAs/GAs have become so unreliable that they should not be considered reader-facing. Perhaps that's true, but that's a much larger discussion that would entail removing the topicons entirely and eliminating links to reader-facing pages like WP:Featured contents. For better or worse, the system we have right now is one that commits to making featured designation visible to readers, and so long as that's the case, we should make it work well enough that readers are aware of it as intended. If you want to change the fundamental purpose of the featured content system, you'll need to start a separate discussion about that. {{u|Sdkb}} ^talk 02:13, 7 October 2020 (UTC)

  I don’t believe I have typed what you are reading. SandyGeorgia (Talk) 02:39, 7 October 2020 (UTC)

  Finishing the thought. It is not a "concern about FAs"; it is a statement of fact about GAs and FAs, and a reminder that our processes only work if people use them. Participation has fallen off at FAC and FAR, while GAR is practically unheard of, relative to the numbers of old GAs. IIRC, GAs were last re-evaluated ten years ago. Wikipedia does not regularly re-assess articles at any level, and shouldn't pretend to our readers that we do (but on that score, FA does a better job than GA).

  Reading Wikipedia:Wikipedia Signpost/2008-06-23/Dispatches (How Wikipedia's 1.0 assessment scale has evolved) may help you understand that assessments are, and always were, internal processes, best understood to experienced Wikipedians, and unlikely to be understood by others.

  Sticking a link to WP:FA or WP:GA next to an article title is not going to increase reader knowledge about the pros and cons of those processes, or help them understand how to interpret them. Experienced Wikikpedians can look at a GA pass and say "that was a good pass" or "those were bad passes". Or that was passed so long ago, and the article has changed so much, it's no longer relevant. We are to serve the reader; giving them a link to something meaningless to them—while potentially misleading them about quality—does not serve the reader. And the only difference between B-class and GA-class is exactly one editor's opinion.

  As to how to best use this page, it might have been more productive to first get feedback and ideas at WT:FAC or WT:GAN before proposing something here. SandyGeorgia (Talk) 13:22, 7 October 2020 (UTC)

  You bring up some valid concerns here, but the discussions about the lack of participation in GA/FA, or whether GA/FA icons should be reader-facing at all are separate questions altogether. I appreciate your efforts to address broader issues with the review system, but this proposal just a narrow question about the location of icons on a page. The question is whether the upper right or next to the article name is a more clear location. You're right that there are other issues with the review process that need addressing, so I hope eventually we can address those other problems as well. 〈 Forbes₇₂ | Talk 〉 17:58, 7 October 2020 (UTC)

• I realize our icons our different, but the Danish example above reminds me a lot of blue checkmarks on Twitter (I'm not saying it's a bad thing, just a thing). As an alternative, we could put the icons to the left of the title but still right next to it. -- Calidum 02:28, 7 October 2020 (UTC)

  They have an extra tier below good article ("promising"), my first example wasn't the best as it's from that category. You can see a GA here. Jr8825 • Talk 02:33, 7 October 2020 (UTC)

• Oppose Rearranging icons is not helpful. We should assume that readers are interested in article content, not how attractively the icons appear. It won't help a general reader to see that a particular article is GA or FA or other, and the icons raise questions that distract from the content. Also, positioning the icons requires Javascript that seem unnecessary. Johnuniq (talk) 04:07, 7 October 2020 (UTC)

  My point is not about attractiveness. It's about whether a GA/FA icon is of any use to a reader (it seems I disagree with you, as I think it is helpful for the general reader) and whether it should be more visible. Jr8825 • Talk 04:30, 7 October 2020 (UTC)

• Just a note on the point of ~"non-Wikipedians don't care." In talking with hundreds of academics about Wikipedia over the years, including a whole lot of instructors who want to learn in order to help students learn about a site they use every day, they are almost invariably surprised to learn about GAs/FAs. They value these little symbols because it's one more tool in the information literacy toolbox that allows people to understand the content they're reading. It's not the only tool by any means, or even the primary tool, but the sheer volume of people who say (a) I never noticed that, and (b) that's very useful tells me changing the position may help.

On the subject of whether it would make any difference: Rather than just speculating that this would be helpful, though, maybe we should test it out. Wikipedia doesn't use cookies like other sites, but we can experiment in other ways. For example, display a topicon that links not to WP:GA but to a dedicated subpage of the article it's displayed on with similar information. Check the pageviews after a month, move it closer, check pageviews after a month. Something like that? — Rhododendrites ^talk \\ 13:22, 7 October 2020 (UTC)

• I agree with you generally, having also encountered this issue. But I view it not as a problem, rather as a good thing-- that the average reader is not misled into believing that every GA or FA they access is somehow recently vetted and approved. How about if someone were to run a bot and determine the dates on all of our GA passes; I wonder what that would reveal relative to the GA sweeps of a decade ago. I don't see it as helpful to mislead our readers into thinking that when they access a GA, they are necessarily accessing a dependable, reliable article. Also, I'm not sure what would be on this subpage your suggest? As in the examples I give above about Tourette syndrome ... we could at best show at 2006 FA pass, which doesn't address that the article is constantly overhauled and updated, compared to some 2010 to 2013 medical FAs that are now outdated. What would say on this subpage that would be digestible and understandable to a reader who doesn't understand the vagaries of a project that "anyone can edit", and where editors who once labored over the quality of an article move one, and the article goes to crap? SandyGeorgia (Talk) 15:33, 7 October 2020 (UTC)

  It seems like there are a few different things here. It would be good to have a process of reviewing promoted articles on a set basis, but as I think you were getting at above, we don't have the volunteer resources to keep up with the current backlog of initial reviews to begin with, nevermind re-reviewing. It's probably something best handled on a project basis, since there are a lot of historical articles, articles about books/media, etc. that don't really change much in 10 years while medicine, political figures, etc. certainly may. But on the next question of what could go on the subpage: I think it would be useful to explain what GA means, what it doesn't mean, and, along these lines, set expectations accordingly. A bot should be able to automatically create these fairly easily I imagine, including different blocks of text depending on how long ago the review was. Maybe even a faded icon if, say, 10 years have gone by. Maybe a link to the version that was reviewed and a link to the review itself. Of course that stuff is already on the talk page, but I think people would be far more likely to click a shiny icon next to the title than to find it in a sea of banners on the talk page. And the way we present it on the talk page doesn't provide much context. We can't really expect readers to click more than one additional link IMO... (I'm spitballing, in case it's unclear). — Rhododendrites ^talk \\ 16:24, 7 October 2020 (UTC)

• Oppose. While our FA process is helpful editorially, the tag necessarily ends up being applied unevenly. So many great articles are not FAs, and some that are, are not really that great. Making the FA tag more conspicuous will mislead our readers into thinking it has been uniformly applied, when in fact it hasn't. Paul August ☎ 15:12, 7 October 2020 (UTC)

  It's fair to point out that a featured article isn't necessarily better written than any other article, it's just an article that has passed review. Ideally, I think we all wish that FA and GA status was a more reliable measure of relative article quality. However, even when that is not true, passing a review is represents the article has at least a certain level of absolute quality. We can work improving throughput for the FA/GA review, but let's not wait for a perfect process if the current one is already a net positive. 〈 Forbes₇₂ | Talk 〉 17:20, 7 October 2020 (UTC)

  The process is good enough for its intended purpose, i.e. to motivate editors to improve an article. But not good enough (and never could be) for our readers to use as a reliable way to evaluate the quality of an article. But this is precisely what most readers will assume if we do this. Paul August ☎ 17:37, 9 October 2020 (UTC)

  Why wouldn't it be a "reliable way to evaluate the quality of an article"? Reading the criticism about GA/FA that some users make here, I'm wondering why we even bother with assessements and reviews. T8612 (talk) 21:28, 9 October 2020 (UTC)

  As I've tried to explain above, it's unreliable because of the fact that the process is not applied uniformly. Most article's are never reviewed, and lack of review is not a measure of quality. And the quality of reviews that are done are uneven. Both of these problems are intrinsic to the bottom-up nature of our project. But, that doesn't mean that the reviews don't serve a useful purpose, because they do! They help improve articles ;-) Paul August ☎ 12:16, 11 October 2020 (UTC)

  But, precisely, we lack reviews because most users don't know about GA/FA. If we displayed icons more prominently we could expect more people to engage in the reviews. I discovered about the review process on an user's talk page. T8612 (talk) 15:44, 11 October 2020 (UTC)

  The main reason we lack reviews is because the costs are high and the rewards are low. No matter how well publicized the review process is, only a tiny fraction of our articles will ever undergo that process. So while making the FA/GA icons more conspicuous might increase that tiny fraction by another tiny fraction—it will do so at the cost of misleading our readers. Paul August ☎ 20:50, 11 October 2020 (UTC)

• Do not use icons at all. The above comment from Rhododendrites is anecdotal evidence that readers often do not "notice" the icons at all. Label a Featured Article with the text "Featured Article" and a good article with the text "Good Article". Extend these labels to give the date when the status was awarded and have the status "fade" over time. — GhostInTheMachine ^{talk to me} 15:24, 7 October 2020 (UTC)
• Oppose. Admittedly, I'm a little biased in that I have the gadget that changes the header color to match the assessment, but leaving aside that I share some similar concerns as Sandy. I think the comparison made upthread about "verified" badges and similar is a solid one, but my concern dovetails with that connection—FAs are generally quality work, but literally putting the star or plus side right next to them implies a level of official certification that is writing a check we can't back up. Der Wohltemperierte Fuchs ^talk 23:11, 7 October 2020 (UTC)
• Support A/B testing the idea per Rhododendrites. These icons help with advancing information literacy by alerting readers to the state of our content in the same way that all of our cleanup-banners do. There is a very real possibility that this could actually improve not only reader engagement, but create a greater incentive for editors to use the content review processes. We should be able to test it out on a few pages to see if the change causes the effects we want. We could create Wikipedia:Good article topicon placement test control and Wikipedia:Good article topicon placement test manipulation as a redirects to Wikipedia:Good articles. For pages in the control group, the topicon would be in the usual place, and for those in the manipulation group, the topicon would be closer to the title. If changing the location is actually effective, we should see more page-views in the manipulation group than the control after a few months (normalized by daily page-views probably since some people will click on things just because it's new). We could even do second round tests where one of the redirects is turned into a reader-facing info page on our quality review processes, or add links to the article's review page so readers can easily audit our review processes and come to their own decisions about the reliability of the quality rating. We should come up with a testing plan before doing this, but I think this is an interesting enough idea to try it out for a bit. — Wug·a·po·des​ 01:01, 8 October 2020 (UTC)

  Wugapodes, sounds good to me. To be clear, WP:GA and WP:FC are already supposed to be reader-facing pages (the latter was linked from the left sidebar until a few months ago). To the extent that they've drifted from that intended state, that's been because of unwanted creep. {{u|Sdkb}} ^talk 06:02, 10 October 2020 (UTC)

• Support A/B testing the idea per Wugapodes. I personally don't like the idea aesthetically, but we should focus on function over form, and testing the idea a bit seems entirely reasonable. On a separate note, I maintain* the "metadata gadget" that retrieves article ratings and highlights them in the tagline and title, and highlighting article ratings in an icon or icon-like format beside the title was a proposal that MGalloway made while employed at the WMF, with the idea that it would help colourblind users. I rejected the idea at the time: icons requiring a hover interaction would be strictly worse than the current text-focused approach of "put all the info as text in the tagline and provide 'bonus' colouring in the title". However, she mocked up some ideas that are to date still unarchived at MediaWiki talk:Gadget-metadata.js, which might be relevant here for design purposes. (*I haven't done much recent maintenance at all, in part because I haven't picked up the interface admin right I'd now need to edit it directly, but that's a different story.) {{Nihiltres |talk |edits}} 17:41, 8 October 2020 (UTC)
• Oppose a strong reason hasn't been given --Guerillero | Parlez Moi 03:20, 9 October 2020 (UTC)
• Oppose per Paul, I don't participate in the GA/FA area however if what Paul says is correct then these shouldn't be used next to titles and shouldn't further mislead our readers. –Davey2010^Talk 13:26, 9 October 2020 (UTC)
• Oppose per SandyGeorgia and, especially, Fuchs. Avis11 (talk) 15:34, 9 October 2020 (UTC)
• Support Somewhat tentatively as good points are raised regarding quality control. However I feel this should be an all or nothing case. If we are hiding the icon away because we don't trust the process then we should not even be displaying it. I think an advantage in making it more visible is that editors unfamiliar with GAs and FAs might become aware of them and choose to partake (even if it is just to point put an article is not up to standard). We lack volunteers for reviewing and even more so for reassessing these articles, so to my mind we need to be encouraging editors to get involved any way possible. It might even lead to better quality control. AIRcorn (talk) 21:35, 9 October 2020 (UTC)
• Oppose per SandyGeorgia and Fuchs. I think this proposal had good intentions. I have also talked to non-editor friends and family members about Wikipedia, and none of them knew about the content assessment systems, but I think the benefits are outweighed by the concerns brought up by SandyGeorgia and Fuchs. It is nice though to see an active discussion about this. Aoba47 (talk) 21:38, 9 October 2020 (UTC)
• Support on testing - the GA/FA icons are unnoticeable to the casual user, and obviously in mobile too. If the icons are displayed more prominently, it may encourage more users to participate in these content assessment processes. There's a huge backlog in GA/FA, so the more users who take an interest, the better. What is the point of GA/FA then - why would editors spend so much time improving articles, only for them not to be noticed? I understand there are many poor quality GAs/FAs, and we don't want to mislead readers, but perhaps one solution is to display a disclaimer of some sort - that Wikipedia doesn't guarantee the accuracy of these articles even though it's a GA/FA. (I would hope that the average reader with a bit of common sense and intelligence knows that Wikipedia is editable by anyone!) For me though, it is about making these review processes more accessible and transparent to the casual reader. It doesn't give us, editors, much confidence in Wikipedia, or our processes for that matter, if we keep the GA/FAs obscured from readers! L150 18:23, 10 October 2020 (UTC)
• Oppose (a) on aesthetic grounds, (b) because, per SandyGeorgia, it would elevate these often very inconsistent reviews to a misleading status, and (c) because it's completely unnecessary - the small coloured icons at the top right are quite eyecatching in any case and I very much doubt they are missed by readers - they are usually the first thing I notice when I open an article page and I doubt it's different for others. All the other icons are displayed in the top righthand corner and for consistency that's where they should stay. Gatoclass (talk) 15:38, 11 October 2020 (UTC)
• Oppose per Gatoclass Asartea ^{Talk | Contribs} 15:45, 11 October 2020 (UTC)
• Support a test/trial, per Wug et al. ProcrastinatingReader (talk) 22:48, 11 October 2020 (UTC)
• Oppose. Gatoclass has summed up my opinion perfectly: (a) it's ugly (b) it elevates a misleading metric, and (c) it's already eyecatching. — Goszei (talk) 07:04, 16 October 2020 (UTC)
• Oppose - I do get the reasoning, but I feel it radically stresses its status and looks visually cluttered. Having FA status stressed isn't that big of an issue to me, but it's perhaps more of a concern with GAs - we know what is involved in a GAR, but others do not. They do also seem fairly eye-catching to me, but I'm willing to accept that I don't know what a general reader's view is on that. The desktop/mobile split isn't ultra clear, so I would say that I am support for this on mobile, if you can get it to work. Nosebagbear (talk) 09:40, 19 October 2020 (UTC)
• Remove icons altogether. The majority of our best articles don't go thru the FA process because our best writers rarely waste their time with the GA/FA process. I am sure most will agree that FA GA criteria does not necessarily mean a good article years after the fact. All that rant said.... the proposed icons do look better and placement wouldn't change prominence in my opinion...thus Support ....someone should suggest vital articles have more prominence over GA articles that no longer meet the criteria.--Moxy 🍁 00:42, 22 October 2020 (UTC)
• Support I agree the Danish choice is more clear. I do hear the concerns of SandyGeorgia and I think it would be good to do a push to re-evaluate the subset of good articles and features articles that may do harm if they contain misinformation (in addition to health I'm thinking climate change and controversial political topics). Femke Nijsse (talk) 09:02, 26 October 2020 (UTC)

  The problem with making FA/GA icons more prominent, is more than just that some may contain misinformation. They will mislead our readers into thinking that these assessments represent a complete and uniform review of all our articles, when they don't. Paul August ☎ 17:23, 2 November 2020 (UTC)

• Strong support: we as Wikipedians are cataclysmically stubborn in approving any design change, and unfortunately that's what I'm seeing in the opposition (as well-written as some of it is). Most of it seems to correspond just as well to arguments against including the topicons on the right, which we currently do, but such a motion would fail if proposed today because we reject almost any design change. The readers don't notice the icons where they're positioned and it is one more tool in, as Rhododendrites eloquently puts it, the information literacy toolbox that allows people to understand the content they're reading. Give them a better opportunity to see it.
  Also, someone should shove whoever is necessary to get the GA/FA icons on mobile approved, because that is actually much more important than this decision here, as the majority of our readers are on mobile (and this will only continue to grow as more countries gain widespread smartphone/internet access). — Bilorv (talk) 02:12, 31 October 2020 (UTC)

  This is more than just a mere "design change". This change will make the GA/FA icons more prominent, which, as several editors have argued above is a bad thing. Paul August ☎ 17:23, 2 November 2020 (UTC)

• Oppose because it will mislead our readers. There are very good articles out there that aren't FAs because their main contributors don't want to go through the process, and a significant number of FAs that haven't been reviewed in many years. I think that the wider community is, sadly, unaware of this. I invite everyone to help in WP:FAC and specially WP:FAR, where we are trying to review many old FAs that achieved the status before the criteria considerably tightened up to current standards. RetiredDuke (talk) 17:53, 13 November 2020 (UTC)

  Sure, but the FA/GA process already exists, and so do the icons. So this argument just seems to implicitly imply they aren't advertised well enough, and that the processes are imperfect so we shouldn't promote the icons. But, by consensus, we already do (albeit imperfectly). This is also slightly circular. Perhaps if we have it more prominent, more people take articles to GA/FA, so we get more articles, and hopefully more reviewers too. Just because every good article isn't a GA/FA, doesn't mean we should completely abandon all efforts of letting our readers know when an article is reasonably good. ProcrastinatingReader (talk) 23:46, 14 November 2020 (UTC)

• Oppose. This is visual clutter, and both GA and FA are basically wikiprojects, not formal Wikipedia policy matters. They should not be thrust into the faces of our readers, especially given how much WP:DRAMA and subjectivity is involved in the GA/FA sausage-making.  — SMcCandlish ☏ ¢ 😼  08:54, 15 January 2021 (UTC)

  SMcCandlish really should not be !voting within an archive, but he's insisted on doing so. To briefly respond to his point, he is completely wrong that GA/FC are not intended to be reader-facing—they have long been made easily accessible from the reader-facing Main Page, and WP:FC and WP:GA are clearly designed for non-editing readers (and are tagged as such). And, of course, they're already reader-facing in that the topicons already appear on articles. {{u|Sdkb}} ^talk 04:01, 21 January 2021 (UTC)

Mobile display

Tracked in Phabricator
Task T75299

@Eddie891 and Peacemaker67: You both mentioned mobile view in your !votes. There currently isn't any way to display topicons in mobile—see Wikipedia:Village pump (technical)/Archive 183#Featured/GA topicons for mobile—so GAs/FAs aren't currently being identified. There's a phabricator ticket for the issue but it has not yet been resolved. I suggest we stick to discussing desktop display above and discuss mobile here. {{u|Sdkb}} ^talk 00:26, 7 October 2020 (UTC)

• OK. The lack of mobile topicons on mobile is highly problematic. Readers need to be easily able to see what the quality of the article they are reading is. I don't use the mobile version often, but am aware that many readers do. This should be a high priority in terms of development, as article quality is at the centre of what we do on WP. Peacemaker67 (click to talk to me) 00:51, 7 October 2020 (UTC)

  Agreed. I commented on the phabricator ticket, but I've never quite figured out how to boost a development task's priority; it seems to be mainly up to the whims of the WMF folks. {{u|Sdkb}} ^talk 01:57, 7 October 2020 (UTC)

  Most developers are volunteers like you, not WMF employees, so the best way to increase a task's priority is to volunteer to fix it. Creating a phab task is like placing a cleanup template on an article: unless you plan to fix it yourself, the request will probably just languish until someone cares enough to get around to it. Unlike cleanup tags, there's far fewer hands on deck to fix non-critical phab tasks. — Wug·a·po·des​ 01:10, 8 October 2020 (UTC)

  Add it to the {{Short description}} like this. It will appear in the search but, like the short description, it will not appear at the top of the page. Or you could have another template that could use "FA", "GA", "Polar bear liver", etc and explain what the ratings mean. CambridgeBayWeather, Uqaqtuq (talk), Huliva 14:40, 8 October 2020 (UTC)

  I see what you mean, but please do not add other semantics to the short description — it should be a description only. If the FA/GA status is output as text then the mobile display would also show it.

  (Depending on how the short description is edited, it may also be pushed into Wikidata, which means that the FA/GA tag may incorrectly show up in article for other other WPs.) — GhostInTheMachine ^{talk to me} 18:01, 8 October 2020 (UTC)

  I didn't intend to do it but the Wikidata short description is no longer imported to the English Wikipedia. All short descriptions are here. CambridgeBayWeather, Uqaqtuq (talk), Huliva 03:49, 9 October 2020 (UTC)

  Wugapodes, many times a WMF team needs to sign off on it, though. In this case, technically enabling it on mobile is not difficult (it's a few lines of code, I've done it on my local install). The issue is that the design team needs to sign off on it and decide where to place it. That's where the task is currently jammed. ProcrastinatingReader (talk) 15:38, 10 October 2020 (UTC)

Discussion

I would find it sad if this proposal ends up at no consensus→default to no action. As I've discovered through experience, making design changes to Wikipedia is hard, even in situations where change is clearly warranted, since not only does the consensus system favor the status quo by default, but editors' human tendency to prefer the familiar can also make it seem like proposals aren't as desirable as they'd seem if everyone was forced to live with them for a week before !voting on them. If this doesn't win outright support, I'd hope it'd be possible to at least try out the A/B testing, which is a much less disruptive action and should therefore require a somewhat lower bar to activate. The point is not to throw caution to the wind, but I do think we need to be less afraid of a little more design experimentation. As a result of the above factors, Wikipedia's design is notoriously outdated compared to other major websites, so there's a lot of room for improvement. Trying out a new position for the star icon won't bring about the apocalypse. {{u|Sdkb}} ^talk 05:44, 10 October 2020 (UTC)

It's why I said I disagreed with the premise. In order to do A/B testing, there needs to be an agreement on success criteria, and for that, there has to be an agreement on a problem statement. isaacl (talk) 07:09, 10 October 2020 (UTC)

My opposition, along with others, has nothing to do with "favoring the status quo", nor from a "fear of design experimentation". Rather it has to do with the fact that this change will mislead our readers. Paul August ☎ 16:38, 10 October 2020 (UTC)

Besides what Paul August says (that I agree with), I see several other issues here. First, it can be less hard to make design changes if you first consult the groups of editors most involved in or affected by what will be changed. You did not discuss this before with either GAN or FAC, where you might have heard the problems with your proposal. I doubt that many FA or GA participants are unaware of the shortcomings, pros and cons of those processes. Second, there were attempts to stifle the discussion here by several parties, indicating a lack of understanding about how consensus is formed. We don't just "yea or nay"; we explain our reasoning and discuss. And yet, two different editors discounted my reasoning, saying to take it elsewhere, this isn't the page ... although I was only explaining my reasoning for opposing. They didn't seem to understand that one SHOULD explain their reasoning. Third, you then went on to another proposal, about redesigning the icons, again without consulting with the involved pages or seeming to understand that the A,B,C, start, stub are WP assessments, GA is one-person, and FA is a community-wide process. If you will take the time to consult-- and listen-- you might find a lower number of failed proposals at design changes. SandyGeorgia (Talk) 22:44, 10 October 2020 (UTC)

@SandyGeorgia: I don't feel your characterisation of my suggestion as being naive or attempting to exclude regulars is fair. The village pump seemed to be the obvious place to make this suggestion, I wasn't at all attempting to bypass FA/GA participants and I'm very glad that others more familiar than myself with the bureaucracy notified the relevant talk pages. It didn't occur to me to bring up my suggestion at these places because I wasn't aware of their existence (also, a site-wide visual change seems out of the scope of those venues). I explicitly asked for feedback on my original statement and while it's shame we don't all see eye-to-eye I actually thought the discussion above was very valuable. Personally, I didn't think Sdkb and Forbes72 intended to stifle the discussion or discount your argument, both acknowledged you raised an important point and I thought they were trying to explain why they disagreed in this context. Ultimately this is a straw man, as it detracts from the main reasons you disagree with the suggestion, particularly that there's a risk of making readers feel the reliability of what they're reading is guaranteed.

I agree that this is the biggest issue, and I acknowledged this when I outlined my rationale. The discussion above has definitely reiterated the current FA/GA system's flaws, and this may, on balance, mean that my suggestion is unpalatable to the majority of editors here, which I would understand. I explained why I myself think the change could be beneficial overall at the start of the discussion: the layout could encourage readers to click to find out more about FA/GA, and this could increase awareness among readers and editors of how Wikipedia's internal processes work; it will more effectively promote the best work we have; if more readers were aware of FA/GA, it might produce greater scepticism towards other long articles that look well-written but have failed or not gone through peer reviews; most readers are already aware that Wikipedia is unreliable. The next thing that occurs to me is to only trial moving the featured star, as only featured content should be "featured" because only it has gone through a group peer review, rather than an individual one. Jr8825 • Talk 01:21, 11 October 2020 (UTC)

@SandyGeorgia: I raised the objection that your concern (which I actually agree with—I brought a page to WP:FAR not long ago that survived as a FA for way too long; you're clearly a passionate crusader for the issue and I'd be happy to see it discussed more elsewhere) was out of scope of the present discussion. I stand by that concern. You are arguing that FA/GA designations are unreliable, and there are only two ways to apply that to this discussion. The first would be to say that they're so unreliable that FA/GA designations should not be reader-facing, which is what I responded to above. That's a change that would overturn a longstanding consensus, and would require its own discussion; I expect that the closer will ignore !votes like GhostInTheMachine's (for not displaying stars) that are clearly speaking to that discussion, not this one. The second would be to say that they're reliable enough to be presented to readers but not reliable enough to be presented to readers in a way that they're likely to actually notice. That's a nonsensical way to parse things: either it's good for readers to know the FA status of an article or it's bad, and we need to stand by whatever we decide.

Regarding your attempt to pull rank based on your more active GA/FA participation, that's not how Wikipedia works. We value expertise, and the relevant projects have been appropriately invited to this discussion, but we also value input from a broad range of editors, including those less in the trenches who can often bring outsider's insights. (And if you want to get into qualifications, you may want to figure out who the most active and successful design/usability editors are.) {{u|Sdkb}} ^talk 03:18, 11 October 2020 (UTC)

Can the rhetoric be ramped down a bit? I don't think it's necessary to describe reasoning other than a good or bad interpretation to be nonsensical. And I don't think it is necessary to tell people who are engaging in discussion to consult and listen. I appreciate that it is disquieting for discussions to follow different paths than one might feel is optimal. For better or worse, there are always going to be slipups in communications. I trust we can overlook them and seek out common ground. isaacl (talk) 04:04, 11 October 2020 (UTC)

This seems wise. @SandyGeorgia: Admittedly, it's been a while since I've done anything with GA reviews, so maybe it would be a good time for me to help with the backlog. There's obviously some disagreement above, but we're all on the same team here. 〈 Forbes₇₂ | Talk 〉 04:34, 11 October 2020 (UTC)

How aware are readers of GA/FA?

There's an empirical factual question here that seems to be influencing many !votes: To what extent are non-editing readers noticing the icons and aware of their significance?

On one side, JR8825 offers that in their survey of a couple of non-editor friends, none knew about it. Rhododendrites asserts In talking with hundreds of academics about Wikipedia over the years, including a whole lot of instructors who want to learn in order to help students learn about a site they use every day, they are almost invariably surprised to learn about GAs/FAs. Aoba47 concurs: I have also talked to non-editor friends and family members about Wikipedia, and none of them knew about the content assessment systems.

On the other side, we have Gatoclass's assertion, bolstered by subsequent "per" !votes, that the small coloured icons at the top right are quite eyecatching in any case and I very much doubt they are missed by readers - they are usually the first thing I notice when I open an article page and I doubt it's different for others. Guerillero argues a strong reason hasn't been given for a change, likewise dismissing that there is any problem.

Since this is a factual question, whichever side is incorrect should be appropriately discounted by the closer. What I notice is that everyone so far who has actually asked non-Wikipedians has found them unaware, whereas those arguing they are surely aware have provided nothing except speculation. This comes across to me as a classic example of the difficulty of putting ourselves in readers' shoes (a problem CJK09 has written eloquently about): yes, of course the GA/FA icons stand out to us, since we all already know about GAs/FAs; that doesn't mean they will to our grandparents. It would be ideal if we could uncover some formal research into the question, but in the absence of that, all the evidence so far seems to point to readers being largely unaware. {{u|Sdkb}} ^talk 22:33, 21 October 2020 (UTC)

(Yes, I'm aware some portion of the !votes/discussion above focused more on the question of how aware readers should be than the one of how aware they are. I am posing solely the are question here, since the should question has already been considered at length above.) {{u|Sdkb}} ^talk 22:33, 21 October 2020 (UTC)

I hope I'm not flogging a dead horse here, but I've have noted a number of relevant comments in a different discussion below in which several editors have expressed their view that very few readers ever notice these icons, and that it would be a positive thing if they did. This was the rationale for my original suggestion. I wonder if anyone else has a view on this? Jr8825 • Talk 22:43, 30 October 2020 (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.

Priority watchlisting

I would like the ability to specify a few favored articles to appear at the top of my watchlist, and out of the main reverse-chrono sequence, anytime they meet the regular criteria for watchlist display. My use case is this: I occasionally monitor editing by student editors working on articles at Wikipedia as part of their university coursework through WikiEd, Wikipedia's collaborative program involving colleges and universities. It's important for me to see changes by student editors to any of my watchlisted articles right away, so I can respond in a timely manner. But, I have thousands of articles on my watchlist, and I might miss contributions if I don't log in for a day or two.

So, I'd like to see these articles at the top of my watchlist (or otherwise prominently displayed; perhaps a collapse button that renders everything else as display:invisible?) I realize this probably involves db and code changes and isn't going to happen overnight. But I would like to see if there is interest among other editors in something like this, and to find out what your use case might be, or how you might alter this proposal. Thanks, Mathglot (talk) 19:44, 6 November 2020 (UTC)

Watchlist suggestions seem to feature a lot on the meta:Community Wishlist. eg meta:Community Wishlist Survey 2017/Watchlists, meta:Community Wishlist Survey 2019/Watchlists. Getting the dev effort to get it done seems unlikely, but you could propose it on meta:Community Wishlist Survey 2021. Perhaps DannyS712 may have thoughts too, since he's working on mw:Extension:GlobalWatchlist. ProcrastinatingReader (talk) 19:59, 6 November 2020 (UTC)

@Mathglot Hmm, User:MusikAnimal/customWatchlists might meet your needs DannyS712 (talk) 20:03, 6 November 2020 (UTC)

If you know the particular articles they are interested in, Special:Recentchangeslinked on a subpage will do. --Izno (talk) 20:04, 6 November 2020 (UTC)

Thank you for all the suggestions, I will check those out! Mathglot (talk) 02:07, 7 November 2020 (UTC)

m:Community Wishlist Survey 2021 opens tomorrow. Whatamidoing (WMF) (talk) 21:21, 15 November 2020 (UTC)

How about making a separate "Wikipedia China Edition" that is censored to please the Great Firewall of China? (The normal version would be kept uncensored.)

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 am aware of WP:NOTCENSORED, and that's how it should stay for the normal en.wikipedia.org, zh.wikipedia.org, fr.wikipedia.org, etc. But how about making a separate en.wikipedia-cn.org, zh.wikipedia-cn.org, fr.wikipedia-cn.org etc. that, among other changes, mentions Taiwan as part of China and does not mention the 1989 Tiananmen protest, so it could be allowed in China? This way, editors that are temporarily on vacation in China that don't care about such "sensitive issues" can continue to edit normally (as you can't edit when connected to most commercial VPNs), and readers in China that don't care about such subjects could read non-controversial articles about science, culture, etc., as Wikipedia has better coverage on some niche subjects compared to Chinese wikis such as Baidu Baike. Félix An (talk) 03:58, 18 November 2020 (UTC)

This might be a discussion better for WP:VPI or WP:VPM since it doesn't seem to consider the why in any great detail, which is required for a good proposal (and in fact is something more of a question about our values, which you might indeed find at places such as NOTCENSORED, WP:5P, and many more).

From a practical point of view, this is a non-starter, since we do not have the people to maintain our 6 million articles, never mind kowtowing to whichever country/state doesn't like what we say. China isn't the only one pissed about something on any given day. :) --Izno (talk) 04:16, 18 November 2020 (UTC)

We would also need to make a Wikipedia Turkey Edition, a Wikipedia Arab Edition, a Wikipedia Armenia Edition, a Wikipedia Azerbaijan Edition, a Wikipedia American Conservative Edition.... We should not be in the business of writing PoV forks to appease emotionally-fragile authoritarians and nationalists. —A little blue Bori v^_^v ^{Takes a strong man to deny...} 04:23, 18 November 2020 (UTC)

For the record, anyone, including the governments of those countries, can make a mirror of Wikipedia and then censor it as they please. It is not our job to do so on their behalf. BD2412 T 04:56, 18 November 2020 (UTC)

Based on three replies above, the answer is no, or meh.... Enjoyer of World^💬 08:54, 18 November 2020 (UTC)

• This is a complete non-starter, both philosophically (what would it do to our credibility to let any part of our site to give knowingly false (or at least unbalanced) info?) and practically. This does call back a little to the time before we started using https, when governments could block individual pages rather than having to choose to block Wikipedia as a whole. The switch may have been the death knell for China, but it's probably helped for places like Turkey that would almost surely take advantage of selective censoring if they could but aren't willing to bear the political cost of banning outright. {{u|Sdkb}} ^talk 09:00, 18 November 2020 (UTC)
• There are no circumstances in which this would ever happen. Quite aside from the practical impossibility (are you intending to be the one checking all 61,764,188 pages to see if there's anything that might upset the Chinese, French, Saudi, Turkish, Iranian, Venezuelan, Pakistani or Russian governments? If not, who are you suggesting for the job?) the large donors that fund Wikipedia would immediately withdraw support. Commercial firms like Disney self-censor to pander to dictatorships because they make the cold calculation that there's more money to be made in China than will be lost in boycotts elsewhere. Our donors fund us because they trust us to at least attempt to be neutral, and if we're going to start deliberately lying will just take their money elsewhere. ‑ Iridescent 09:13, 18 November 2020 (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.

Redesigning the good article and featured article topicons

• 
  Current good article icon
• 
  Current featured content icon

This proposal seeks to establish consensus for a mandate to redesign the icons that appear in the upper right corner of good articles (GAs) and featured content (FC) pages to mark their status.

Background: The current symbols for GAs and FC have been used since those systems were introduced way back in Wikipedia's early days. They have significant problems. The featured content icon is too skeuomorphic, giving it an outdated look, and its excessive detail causes it to render poorly at small scale. The good article icon, meanwhile, has been adopted throughout much of the rest of Wikimedia (and in some places on Wikipedia) as the "support vote" icon, leading to conflicting usage. More concerning than either of their individual issues is the lack of any shared visual language between them (the GA icon uses the norro style, and the FC icon is not part of any larger style system). When compounded by their overall lack of prominence (a separate issue under discussion above), this has led to the unfortunate situation where many (perhaps most) non-editing readers could not tell you whether a star or a green badge is a higher distinction, greatly diminishing the impact of the work editors put into the GA/FC systems.

Proposed process: This proposal does not put forward any specific redesign ideas, but rather seeks to assess whether there is general consensus for a change. If a mandate is established, editors at the graphics lab (where a version of this proposal is currently on hold) will have the opportunity to create designs, which will then be !voted on in a process perhaps similar to the one MediaWiki is using to redesign their logo, with the eventual winner adopted. Design proposals will likely incorporate changes to related icons such as those for good article candidates or former featured articles.

Cheers, {{u|Sdkb}} ^talk 20:23, 24 October 2020 (UTC)

Notified: Wikipedia talk:Featured content, Wikipedia talk:Featured articles, Wikipedia talk:Good articles, Wikipedia talk:WikiProject Usability. {{u|Sdkb}} ^talk 20:23, 24 October 2020 (UTC)

Survey

Should we redesign the GA and FC topicons?

• Support as proposer. This is a feasible task, and would have clear and significant benefits for readers across tens of thousands of pages. {{u|Sdkb}} ^talk 20:23, 24 October 2020 (UTC)
• Support. Would be lovely to have the new icons in the mobile version then as well. Femke Nijsse (talk) 16:18, 25 October 2020 (UTC)
• Support I don't really think there's any reason against this here. A change would be worthwhile because I can see how the disctinction between the two for the average reader may be difficult – the green is brighter and likely stands out more. The support vote/good article confusion is also a good point – I didn't understand that when I first joined WP. Aza24 (talk) 03:38, 27 October 2020 (UTC)
• Oppose - per my reasoning in the general discussion thread below. Nosebagbear (talk) 12:22, 27 October 2020 (UTC)
• Support FA per nom. The current icon is way too detailed and doesn't render well at small sizes. I think both icons should use the Norro Style 1, for the sake of consistency. My suggestion for Featured would be 30px as it is consistent with the current blue color used for featured articles in our internal templates. (Gold is too similar to the C-Class yellow.) I would be okay with changing the + icon used for GA but I don't have any ideas on what should replace it. —pythoncoder (talk | contribs) 19:33, 27 October 2020 (UTC)
• Oppose no real reason for the proposal, icons are adequate to the extent that most readers notice them (I didn't until I got really into Wikipedia mid-2018; perhaps they should be abolished in favor of text as discussed below). What does need to be redesigned, and bad, is Question book-new.svg, which is painfully 2008. I might make a proposal myself to that effect. – John M Wolfson (talk • contribs) 01:59, 29 October 2020 (UTC)

@Sdkb: sorry to jump in on a mostly unrelated thread, but I find John M Wolfson's comment, that he didn't notice the FA/GA icons until becoming actively involved in Wikipedia, interesting. It relates to the point you raised above and the argument I made in my proposal there. Jr8825 • Talk 02:10, 29 October 2020 (UTC)

That they are not particularly noticeable is a good thing per arguments made above: these icons while of some use to editors, are misleading for readers. Paul August ☎ 11:57, 11 November 2020 (UTC)

• Support, provided that this is just proposing to solicit proposals and initiate a more fulsome discussion of changing the images. As Sdkb wrote elsewhere in this discussion, "it's a very small cognitive jump from 'this website has an outdated look' to 'this website has outdated content'". 207.161.86.162 (talk) 03:49, 29 October 2020 (UTC)
• Oppose: of our many, many outdated design features, I do not see these icons as one of them. The proposer says many (perhaps most) non-editing readers could not tell you whether a star or a green badge is a higher distinction. I'll go further: almost no readers have ever noticed a star or green badge on any article they have ever read. Those that do, great—readers should always be encouraged to peek behind the scenes, because our culture should be as open and welcoming as possible. But this is really a change that would be for us, and I think to us it's more significant to maintain tradition and to keep with the icons that we recognise on sight (in context) as GA and FA icons. — Bilorv (talk) 21:14, 30 October 2020 (UTC)

  Would it take more than six months for editors to begin recognizing the new icons on sight? 207.161.86.162 (talk) 05:27, 12 November 2020 (UTC)

• Oppose per Bilorv. The FA and GA logos do not seem at all outdated. I also agree that most readers do not usually even see the logos in the corner. P,TO 19104 (talk) (contribs) 22:26, 30 October 2020 (UTC)
• Support in principle, anyway. I specifically remember a similar proposal that was drafted at Wikipedia:Icon standardization. If we're going to redesign the logos that are used for articles, let's just overhaul the rest of the project outright and adopt a standard set of design guidelines across the project. OhKayeSierra (talk) 23:06, 8 November 2020 (UTC)
• Support I agree with the main thrust of the nominator, which is that the icons are inconsistent, difficult to see and also somewhat out of date. I see no problem with exploring if the icons could be improved. Also, I (personally) have always found the FA icon to be the least visually appealing of the icon set, which is weird because it is the best articles. --Tom (LT) (talk) 02:38, 16 November 2020 (UTC)
• Meh I don't really understand the logic of doing this as a two part RfC and am reluctant to support change based on the stated rational. However, I liked the protection icon redesign so maybe? Best, Barkeep49 (talk) 05:01, 17 November 2020 (UTC)
• Support Perhaps modify the GA symbol to a simple silver star and FC to a gold star? We could even have a third category, like the above-mentioned Danish Wikipedia's "promising" category, with a bronze star. I'm not sure what would populate such a category, however. Perhaps existing B-class articles, or articles currently undergoing GA review? If the former (or the latter, really) was implemented, we should change the article grading system, either to Stub→ Start→ D→ C→ Good→ Featured, F→ E→ D→ C→ B→ A, or Stub→ Start→ Developmental→ Promising→ Good→ Featured. (I'd prefer options 2, 1, and 3, in that order). Perhaps I'll start an RfC on this later. --SqueePs10 ^Talk_{My edits} 01:41, 21 November 2020 (UTC)

  Converting "stub" to "F-class" would probably get us a bunch of complaints at AfC. I do agree that it's weird that we have this basically-unused A-class, but that seems like a separate discussion. {{u|Sdkb}} ^talk 08:18, 22 November 2020 (UTC)

Design discussion

What would you like to see in new topicons if they are redesigned? The discussion in this section will be used as guidance for designers if the proposal is successful.

• General comment: Consider color blindness (esp. red-green): In data visualization circles, there is increasing awareness of how graphics should be crafted to allow color blind individuals to distinguish through shading, what normally sighted individuals distinguish directly through color perception. (One can test shading in Photoshop etc by removing saturation.) It's my understanding that red-green color blindness is a common type, though not the only type of color blindness. Some color scales are better than others: see Scientific American. —RCraig09 (talk) 22:53, 17 October 2020 (UTC)
• oppose as the flat look icons would be confusing to the + meaning to add something, or the * meaning to bookmark it. Graeme Bartlett (talk) 23:11, 30 October 2020 (UTC)

General discussion

• Waste of time proposal. Make some icons then we can talk about some icons. WP:BOLD. --Izno (talk) 21:40, 24 October 2020 (UTC)

  @Izno: I'm launching this based on feedback from the Graphics Lab, where editors asked for us to establish a mandate for new icons before they commit a bunch of time to designing them (graphics work is absolutely not quick and easy). The process is open to discussion, but dismissiveness is not constructive. {{u|Sdkb}} ^talk 00:58, 25 October 2020 (UTC)

  They can be just as BOLD. I'm not a fan of proposals which are just a lot of process, and this is one. If they think they can put together some good icons they should Just Do It. Our lock icon worker of yesteryear--that came to the village pump basically out of the blue. It's a collective waste of every user's time to respond to this RFC if we have nothing to discuss, and at the end of the day that's probably just as "absolutely not quick" for the hours the community will waste arguing about whether it's a good idea to change it. --Izno (talk) 01:31, 25 October 2020 (UTC)

• No icon at all Icons are not large enough for their meaning to be clear, so just use text. Currently an article has "From Wikipedia, the free encyclopedia" displayed below the title. This is redundant as "Wikipedia, the free encyclopedia" is also displayed at the top of the left sidebar. Re-use this space to display "Featured article (from 2019-04-01)" etc. — GhostInTheMachine ^{talk to me} 17:19, 25 October 2020 (UTC)
  • The icons aren't meaningful. Although the above suggested text only, I would support a Text first approach, or possibly text and a small icon. (Also this proposal seeking agreement to change before we know what those changes might be reminds me too much of real world politics and it worries me.) -- 109.76.130.104 (talk) 06:43, 26 October 2020 (UTC)
    • If people are concerned about more visual/text feedback on article quality, a proposal to turn on the Wikipedia:Metadata gadget for all users instead of the opt-in in Preferences: Gadgets might be the best strategy (I don't know if that impacts mobile, either, so that's another discussion.) Der Wohltemperierte Fuchs ^talk 14:09, 29 October 2020 (UTC)
    • You can think of it from a different perspective: before creating better icons, ideally there would be some agreement on what problems exist with the current ones. Now visual design is a tricky thing: sometimes some people need to see alternatives to realize what those problems may be. Nonetheless, trying to gather information first before jumping to solutions can be very useful. isaacl (talk) 16:28, 26 October 2020 (UTC)
  • I like this—I've honestly never noticed "From Wikipedia, the free encyclopedia" and that's a reason to get rid of it. In contrast, I think readers might notice text about an article being good or featured. I would only support this, however, in addition to the existing topicons. (Tiny point: use the date style that the article has as a template, or MDY in words if none). — Bilorv (talk) 21:14, 30 October 2020 (UTC)
• What's wrong with being outdated? By the time anything is implemented fashions will have changed and maybe skeuomorphic icons will be all the rage again. By following trends several years after they have happened we simply make ourselves look like dad dancers (which I was happy to be at my daughter's wedding). We should put ourselves above issues of trendiness. Phil Bridger (talk) 17:34, 25 October 2020 (UTC)

  @Phil Bridger: There are some underlying reasons for the shift from skeuomorphism to flat design, beyond just fashions. My understanding is that the main one is that, in the earlier days of the internet, people weren't as comfortable with online navigation, so it was necessary to make icons more lifelike to help signal their meaning as clearly as possible, but as people have gotten more used to the internet, the cleaner look of flat design has won out.

  You're right, though, that trends may shift again in the future. There will be nothing preventing us from changing the icons again, though, especially once we've broken out of the "this is the way it's always been and always will be" mindset. I think the main problem with looking outdated is that it's a very small cognitive jump from "this website has an outdated look" to "this website has outdated content". {{u|Sdkb}} ^talk 19:24, 25 October 2020 (UTC)

  The increasing number of people using small screens on their phones to browse the web also resulted in simplification of iconography, both for legibility and to make more compact use of space. This has led to simpler, flatter designs. isaacl (talk) 21:37, 25 October 2020 (UTC)

  I think the main problem with looking outdated is that it's a very small cognitive jump from "this website has an outdated look" to "this website has outdated content". That's an excellent way of putting it. 207.161.86.162 (talk) 03:46, 29 October 2020 (UTC)

• I prefer the increased complexity of the FA - I find it goes with the inherent detail of an FA nicely. I am personally against shifting to flat designs in many cases. While in some senses it is also being used for "support", I dispute that it is likely to be confusing. The only people who are ever likely to see it used in its "support" sense are active editors, who are not then likely to be confused about it being used for GA. Set against that, we have readers who have seen it on articles being confused if it changes significantly (which would be needed for the similarity issue to be avoided) Nosebagbear (talk) 22:16, 26 October 2020 (UTC)

  @Nosebagbear: Yeah, the potential confusion for readers used to an old symbol is certainly a reasonable concern; we wouldn't want to be changing the symbols every year, but just doing it once in two decades shouldn't be too disruptive. Also, it'll only be an issue insofar as readers are aware of the current meaning of the symbols. And as I've argued above, I think the best evidence we have currently indicates that the vast majority are not. For those who do want clarification, the tooltip should be sufficient. {{u|Sdkb}} ^talk 18:56, 27 October 2020 (UTC)

  The FA icon is not displayed at all on mobiles and tooltips are not displayed on my (all/most/some?) tablets — GhostInTheMachine ^{talk to me} 19:31, 27 October 2020 (UTC)

• Has there been any consideration for "icons" just being "GA" for good articles and "FA" for featured articles with some sort of stylisation? —Tenryuu 🐲 ( 💬 • 📝 ) 22:44, 28 October 2020 (UTC)

  @Tenryuu: That could certainly be a possibility, although without readers knowing what "good article" and "featured article" mean, it might not be all that helpful to them. {{u|Sdkb}} ^talk 16:07, 2 November 2020 (UTC)

  Sdkb, in my experience, icons like that usually link to another page that describe what they're for. I'm not seeing the logic behind how the current icons automatically inform readers that they're good or featured articles. —Tenryuu 🐲 ( 💬 • 📝 ) 16:45, 2 November 2020 (UTC)

  @Tenryuu: The current icons definitely don't do that, thus why I hope they'll be redesigned. Something like a silver star and a gold star, on the other hand, would at least give everyone a sense that the gold pages are best. Part of the issue is that "good article" and "featured article" aren't super descriptive names. Yes, if you read the page it eventually tells you that FA is the higher tier, but readers are very unlikely to read that far. {{u|Sdkb}} ^talk 20:00, 2 November 2020 (UTC)

  Sdkb, in that case it sounds like WP:FA needs to be reworked. WP:GA seems to be descriptive enough in saying that GAs are good, just not as good as FAs. —Tenryuu 🐲 ( 💬 • 📝 ) 20:23, 2 November 2020 (UTC)

• How about to also redesigning that "listen to this page" icon (see Bhutanese passport)? Hddty (talk) 06:02, 31 October 2020 (UTC)

  @Hddty: I would love to see it! That would probably be an easier change to make, and could be discussed at WP:WikiProject Spoken Wikipedia. {{u|Sdkb}} ^talk 16:07, 2 November 2020 (UTC)

• @Sdkb: where did you advertise it? I watch GA related pages and don't recall seeing it but maybe I missed it. If you didn't notify GA and FA feels like that needs to happen as there would be interested editors there. Best, Barkeep49 (talk) 04:54, 17 November 2020 (UTC)

  Barkeep49, please refer to the "notified" line at the bottom of the proposal. {{u|Sdkb}} ^talk 04:56, 17 November 2020 (UTC)

  Sorry about that. I even scanned that page but somehow missed it. Should have done a find... Best, Barkeep49 (talk) 04:59, 17 November 2020 (UTC)

Facilitate gauging article length

Could we please make the References section of Wikipedia articles collapsed [hidden] by default, it could be opened if one clicks on a reference [n] link. One could then gauge how long an article is by looking at the size of the scroll bar. A small scroll bar means that the article is long. For example: If the scroll bar's dark middle area [the part one can drag] is a third of the size of the scollbar, one would know that the content is three screens long.

Thank you very much for Wikipedia. — Preceding unsigned comment added by GeneThomas2 (talk • contribs) 07:09, 10 November 2020 (UTC)

We have this request somewhat routinely, usually for related reasons (probably often enough it should be listed at WP:PEREN). It has been rejected each time because we do not see "knowing how long the article is" as sufficient to override the accessibility concerns with either hiding the references or (more usually) putting an in-content scrollbar into the page for the references. --Izno (talk) 14:02, 10 November 2020 (UTC)

GeneThomas2, I brought this up most recently at Template talk:Reflist.

For most readers the references are adjunct to the content proper, so making them collapsible does not break the “accessibility concerns” about hiding content. GeneThomas2

It'd be really nice to have for big articles like COVID-19 pandemic, where the reference list currently takes up nearly half the scroll length of the page, making it seem longer than it actually is (which is discouraging to readers; the longer a page looks via the scrollbar, the less people are to decide to read it).

Vietnamese Wikipedia (and possibly others) has implemented it, albeit fairly clunkily. I'm hopeful that with some technical advancements, it'd be possible to do this without introducing accessibility concerns. {{u|Sdkb}} ^talk 22:52, 10 November 2020 (UTC)

Rather than try to use the scrollbar for this purpose, which is hard to see on mobile devices anyway, I think displaying a word count or sentence count would be more helpful. An implementation would probably have to rely on heuristics to exclude the references, and would likely only be able to estimate what constitutes a word or sentence, but could still provide a reasonable indication for many articles. isaacl (talk) 23:25, 10 November 2020 (UTC)

DYKcheck has an implementation. --Izno (talk) 02:43, 11 November 2020 (UTC)

Thanks for the pointer, which led me to Wikipedia:Prosesize. It is able to isolate autogenerated reference lists by searching for the corresponding HTML class used to label them. isaacl (talk) 23:01, 12 November 2020 (UTC)

I would support a collapsed References section. Verifiability is essential for quality control, but the references are not really part of the message to the main reader. HTML-only accessibility is essential for the main text, but Wikipedia should take advantage of the capabilities provided by CSS and JavaScript that gives it the edge over paper encyclopedias (I feel Wikipedia is still too paper-like). Johannes Schade (talk) 12:07, 20 November 2020 (UTC)

How about "not by default." This sounds like something a gadget or preferences setting should control, at least for logged-in users. Maybe, after such a preference has been in place for a year or two, we can revisit whether to collapse the references "by default" for non-logged-in readers. For what it's worth, on the mobile interface, I think all sections except the "top" one are collapsed by default. davidwr/(talk)/(contribs) 15:39, 20 November 2020 (UTC)

@Davidwr: I like the thought of having a gadget available; that sounds like a good way to test this out and chip away a bit at the inertia of tradition. {{u|Sdkb}} ^talk 08:37, 22 November 2020 (UTC)

Add new edit tag for missing signatures

Should a new tag be added for when a user replies in a discussion, but forgot to sign? JsfasdF252 (talk) 07:04, 22 November 2020 (UTC)

You mean {{unsigned}}? 207.161.86.162 (talk) 07:19, 22 November 2020 (UTC)

That's not a tag, which has a specific meaning on Wikipedia. To answer the original question, it would be virtually impossible to write a filter that could identify such posts, as the software has no way to tell whether you're actually adding a new comment or modifying an existing one. ‑ Iridescent 07:21, 22 November 2020 (UTC)

That's not a tag, which has a specific meaning on Wikipedia. I mean, it doesn't. It has several meanings. See, e.g., Wikipedia:File copyright tags, Wikipedia:Tagging pages for problems (WP:TAGGING), Wikipedia:Template index (which describes certain certain templates as "tags"), Wikipedia:Responsible tagging, Wikipedia:Tag bombing (just to name a few). 207.161.86.162 (talk) 07:26, 22 November 2020 (UTC)

What about edits that meet all the following criteria?

• Didn't use "~~~~"
• Occurred on a talk or Wikipedia page
• Not marked as minor
• Increased page size JsfasdF252 (talk) 07:28, 22 November 2020 (UTC)

Can you clarify the purpose for your proposed change? isaacl (talk) 07:32, 22 November 2020 (UTC)

Perhaps make it easier for editors to find and sign unsigned comments? JsfasdF252 (talk) 07:40, 22 November 2020 (UTC)

In my opinion, the editors most likely to sign unsigned comments are those participating in that discussion. Personally, I don't think some form of tagging (not sure what exactly you have in mind) is worth the effort. isaacl (talk) 07:48, 22 November 2020 (UTC)

A tool is being built which will preempt the need to hunt for unsigned pages. --Izno (talk) 14:27, 22 November 2020 (UTC)

I think we have this already, it's called SineBot. How will this tool be different? davidwr/(talk)/(contribs) 15:59, 22 November 2020 (UTC)

See RfC on changing DEADNAME on crediting individuals for previously released works

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Biography#RfC: updating MOS:DEADNAME for how to credit individuals on previously released works
This potentially would affect a significant number of articles.  — SMcCandlish ☏ ¢ 😼  02:22, 2 December 2020 (UTC)

Archiving webpages

Wikipedia articles are highly susceptible to weblink decay. High quality articles can be renndered worthless when a significant amount of references lead to nothing. Currently Wikipedia depends on the WayBack Machine to retrive webpages from deadlinks. But the internet archive doesn't have snapshots of many references used on the Wikipedia. Is it possible that the Wikipedia/Wikimedia archives pages linked in particularly high quality articles (Featured, Good and A-class)? Aditya^{(✉ • ⚒)} 12:52, 27 November 2020 (UTC)

Alternatively, can we do anything to encourage external sites to keep more comprehensive archives of references used in FAs etc.? Certes (talk) 12:58, 27 November 2020 (UTC)

Sadly, there is little hope of websites in general being encouraged to keep archives of their own content. One of the most depressing phrases ever is the joyous exclamation: "We have redesigned our website!". This generally means that the pages were moved around (so breaking links) and many pages will have gone (possibly forever). — GhostInTheMachine ^{talk to me} 20:39, 27 November 2020 (UTC)

Sorry; I was unclear. I was suggesting that we encourage archive.org or similar sites to keep archives of FAs' external links. Comments below suggest that they have already done that for links added recently. Perhaps someone (a bot?) should now check that all links in FAs are archived, and prompt archive.org or similar to store those which are not, moving on to GAs etc. if resources permit. Certes (talk) 00:22, 28 November 2020 (UTC)

There are over 20 archive providers who freely provide web archive services. It would be a tough sell for WMF to dedicate resources required to run one internally; and there are questions about storing mass amounts of copyrighted content on WMF servers. -- GreenC 14:19, 27 November 2020 (UTC)

(1) WMF encouraging websites to keep their own archive must be a joke. Any websites that closes down will never take that responsibility. That is an absurd view of the world.

(2) Maintaining acrvives of copyrighted material may not be as difficult a process. Archive.org has successfully done it, and there is no record of litigation against it.

(3) It may also be possible to strike a partnership with archive.org or some site else.

Whatever the way, WMF needs an archiving system to become sustainable. Otherwise all featured, good and A-class articles are bound to become junk. Aditya^{(✉ • ⚒)} 00:07, 28 November 2020 (UTC)

(1) I have no idea what you are talking about.

(2) Good luck with that idea.

(3) Already exists. -- GreenC 00:35, 28 November 2020 (UTC)

• I believe that any link that gets added to Wikipedia, if it's not already archived by the Internet Archive, is crawled and added to their collection. So while there may be some old links that have died, it shouldn't really be an issue in the future. {{u|Sdkb}} ^talk 00:17, 28 November 2020 (UTC)
• Perhaps having archived references should be a requirement for articles to either obtain or mantain their Good, A-class, and Featuread status, if it isn't already. El Millo (talk) 00:21, 28 November 2020 (UTC)

• Wikipedia is an encyclopedia not a search engine or repository of links. The meat of our articles is the content not the links. WP:V only requires citations for quotations and controversial facts and so, for an uncontroversial topic with no quotes, no citations are required. And citations might well be to offline sources such as books, which are quite acceptable. See the current FA, for example.

Andrew🐉(talk) 00:06, 3 December 2020 (UTC)

• I just read this and was curious. A brief search of PACER shows around 30 US cases involving Internet Archive (the entity responsible for archive.org), some of which list them as plaintiff, but a few of them are copyright-related lawsuits in which they are defendant. There are definitely legal considerations to hosting copyrighted content, and this would factor into such a decision.  A S U K I T E   14:29, 5 December 2020 (UTC)

Cosmetic Bot Day (CBD)

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

There is consensus for the relaxing of WP:COSMETICBOT so that bots may be approved, using the normal process, to allow cosmetic edits that would run only on designated cosmetic bot days (in addition to typical trials/testing done during the Bot Request process). These bots must still have appropriate consensus for their cosmetic tasks. Several editors, both those in favor, but especially those who opposed worried that the tasks would impose preferences rather than improvements.

At the moment there is consensus for a single cosmetic bot day as a trial when these bots may run as there was no consensus about a frequency among participants of this RfC. There was no consensus, largely to lack of discussion, about when such a cosmetic bot day trial should occur but to the extent it was discussed editors indicated a preference for days that experience fewer edits. In any event appropriate notification should be given to warn editors of the trial.

When approving bot(s) that may run on cosmetic bot days, the Bot Approvals Group should also take into consideration the preference expressed for bots/cosmetic bot day structures which will minimize watchlist disruption (for example Enterprisey suggested a theoretical way cosmetic edits would be aggregated before being implemented by a single bot).

Following this trial, subsequent discussion (and/or follow-up RfC) may establish consensus for further cosmetic bot days including a proposed frequency and any other supporting structure/limitations as the community may deem appropriate. — Preceding unsigned comment added by Barkeep49 (talk • contribs) 22:05, 7 December 2020 (UTC)

---

Caution: bots temporarily improving Wikipedia

• The proposal is a periodic (monthly) 1-day (24hr GMT) relaxing of WP:COSMETICBOT assuming there is otherwise consensus for the bot at WP:BRFA

Cosmetic edits are generally disallowed by bots because they continually light up watchlist for changes that are not substantive impeding work flow. This is good. However, as a result many changes that could easily be done by bot never get done, and the community is left to fix simple issues by hand, assuming they ever get done at all.

This proposal is to have 1 day a month or year etc.. that is exempt ie. "Cosmetic Bot Day". Any such bot would require approval though WP:BRFA as normal, bot ops can't do whatever you want, but the bot on that day would not be under Cosmetic regulation, assuming there is otherwise consensus for the bot task. It's a trade-off between allowing bots to fix some problems that are plainly cosmetic while not lighting up watchlists on a daily basis.

It is true WP:COSMETICBOT already says "Consensus can, as always, create exceptions for particular cosmetic edits", however in practice these "exceptions" rarely happen because the bots are running continuously thus the bar is set high. This proposal would allow a temporary relaxation of COSMETICBOT.

For example the period might be once a month (the first day). If there is concern about too many edits, it might be limited to 1 CBD request per month ie. only 1 bot can claim the CBD spot each month. There could be a simple list where bot owners can add their name and date and link to the BRFA discussion, it would need minimal overhead and be nearly self-regulating.

If the bot is doing questionable things (eg. moving the placement of every instance of |url= before |title=) this proposal does not give blanket or even tacit permission. The bot task must have consensus first. The proposal would free up editors time to focus on more substantive work.

-- GreenC 15:41, 25 October 2020 (UTC)

Could we have an example or two of the sorts of edits that would be done on this day? I think an annual day would be an easier sell, as far as disrupting watchlists goes, than a monthly one. {{u|Sdkb}} ^talk 16:06, 25 October 2020 (UTC)

Examples might be adjusting spacing of infobox parameters and their values (to make them line up in edit view); replacing template redirects with their canonical names; adjusting spacing within and above/below headers in a way that does not change the rendered view but standardizes them; or many of AWB's general fixes, like some of those listed in the FixSyntax section. Or cosmetic edits that some editors do regularly, including editors like me. Although it might be annoying one day per month, getting millions of articles looking more similar in edit mode may be helpful. – Jonesey95 (talk) 16:40, 25 October 2020 (UTC)

Another example would be users like NicoV and others might be able to clear out the entirety of WP:CWERRORS if we had enough bots working on it. Primefac (talk) 17:33, 25 October 2020 (UTC)

Thanks Primefac for the notification. I already have some tasks approved for cosmetic edits alongside other edits (T6, T8, T9, T11), maybe some of them could be approved to run if the CBD proposal was accepted. I'm sure there are also other tasks related to other WP:WCW errors that could be added (I never spent the time required for BRFA for other errors that would only be cosmetic edits). --NicoV ^{(Talk on frwiki)} 19:33, 25 October 2020 (UTC)

I would be in support of something like this. I think the idea of a cosmetic bot day of the month/half month would be the best. Year seems to far apart if this is actually needed. Week might be too often if the task is purely cosmetic.

I think that these tasks should only be allowed on this proposed day if the task has been approved by a BRFA for running on that day. This could be that the BRFA has to state that on the "cosmetic day" the bot will do X, Y and Z cosmetic changes. This will ensure that the bot will have explicit approval to run on that day in particular.

Perhaps limiting the number of cosmetic tasks that can be run on that day might be needed, but I wouldn't want a limit unless it is needed. I think a list of what tasks will run on each cosmetic day would be good, regardless of whether limits exist to ensure that it is all transparently logged and prevent any misunderstandings. Dreamy Jazz ^{talk to me | my contributions} 16:15, 25 October 2020 (UTC)

• Comment: This is an interesting idea. I agree with Dreamy Jazz that any such tasks would have to specifically be approved as "Cosmetic Day" tasks, and probably advertised more widely than the usual BRFAs. There may a significant group of editors who simply oppose a certain cosmetic task, like adjusting spacing of infobox parameters, and we need to hear from them before a bot makes 50,000 edits. Bot tasks of this type could go through a normal trial period of 100 or so edits, then an extended trial on Cosmetic Day of 1,000 edits to ensure that the community does not object, before being approved for mass edits on subsequent Cosmetic Days. – Jonesey95 (talk) 16:40, 25 October 2020 (UTC)
  • Following up on my own comment: It appears that some editors in this discussion are unfamiliar with the actual meaning of "cosmetic edit". It means an edit that does not change the rendered appearance of the page. It does not mean "useless edit" or "unnecessary edit". As a gnome, I perform many, many cosmetic edits that fix problems like this and like this. There is no change in the rendered page, but an error has been fixed. (If Linter used tracking categories instead of its less useful Special page tracking system, the edits would not be cosmetic, but that's an argument for a different page.) If a type of edit is truly "unnecessary" or "useless" by consensus of the community, the proposed task to do those edits should be denied at BRFA. Rejecting all cosmetic edits because some of them are viewed by the community as useless would be throwing out the baby with the bathwater. – Jonesey95 (talk) 04:20, 26 October 2020 (UTC)
    • Most of the tasks discussed in this very section are excellent examples of unnecessary edits, many of which should not be being done at all let alone by bot. It's clear therefore that the intent of (many of) those supporting this proposal is not limited to fixing errors so this is not a baby and bathwater situation. Thryduulf (talk) 21:16, 27 October 2020 (UTC)
• I always thought of something like that, although probably not as often as once a month (maybe three months/six months would be better) for infobox normalization (see User:Headbomb/sandbox), talk page general fixes, etc. I would certainly oppose moving url before titles in citation templates, especially since many of 'my' articles deliberately put URLs after titles. But the general idea of a cosmetic day has some merit. Not sure if I'm for the idea, but I'd consider it, with fairly heavy BAG and community oversight. If it passes, I would suggest the days with the lowest editor activity to minimize annoyance. Headbomb {t · c · p · b} 16:53, 25 October 2020 (UTC)
• Question: why? What benefit is there to the encyclopedia of making cosmetic changes? Jonesey95 mentions "getting millions of articles looking more similar in edit mode", but I don't see why that's helpful or desirable or necessary. What am I missing? Schazjmd (talk) 17:01, 25 October 2020 (UTC)

  One reason is for things like WP:WCW; formatting or stylistic issues that can cause tracking/category errors and/or output issues. Primefac (talk) 17:33, 25 October 2020 (UTC)

• Another reason is that for us with a "copy-edit, gnomish" bent, it is quicker and easier to edit when there is consistency in the edit-mode view of pages. This would also stop the undeclared hidden-space-wars (eg: white space additions/removals in infoboxes, line returns between headers and sub-headers, and other stuff). Regards, GenQuest ^{"Talk to Me"} 20:03, 25 October 2020 (UTC)

• WP:BOTDICT#Editor-friendly_wikitext also comes to mind. See my infobox example above. Headbomb {t · c · p · b} 19:41, 25 October 2020 (UTC)

• Oppose. If a task is cosmetic then there is no benefit to doing it on mass absent other changes to the page. If there is benefit to doing the task en mass independently of other edits then it isn't cosmetic and/or the specific task will gain consensus at BRFA in the normal manner. Thryduulf (talk) 18:45, 25 October 2020 (UTC)
• Support per the above. Would prefer a 'first day of every quarter' or 'every-other quarter' type system rather than monthly, though. even or odd months only would work too. Thanks. GenQuest ^{"Talk to Me"} 20:07, 25 October 2020 (UTC)
• Oppose It's a bad idea technically to concentrate such high-volume edits of a similar nature – likely to cause edit conflicts and performance issues. I've already noticed Wikipedia running slowly in recent weeks. As these edits are already agreed to be unnecessary, there's no good reason to do this. And having lots of unnecessary edits doesn't just affect watchlists. They also clutter the edit histories for articles, making them more difficult to trace and analyse. Andrew🐉(talk) 20:18, 25 October 2020 (UTC)

That's not quite true. There's some edits that would make things things a lot more editor-friendly, even if they are technically cosmetic. There's certainly a threshold, but there's a subset of them that would be useful. Edit conflicts and 'performance issues' are overblown as issues. Watchlist flooding could be minimized by choose days with lower editor activity, and edit history clutter can also be minimized by focusing on higher-value tasks, and by performing them only once per every few months. It's not anything that technically couldn't already be handled via normal bot approval though. Headbomb {t · c · p · b} 02:20, 26 October 2020 (UTC)

likely to cause edit conflicts and performance issues. I've already noticed Wikipedia running slowly in recent weeks. Doesn't Wikipedia:Don't worry about performance apply here? 207.161.86.162 (talk) 02:49, 29 October 2020 (UTC)

My concern is not hypothetical. This morning, for example, Wikipedia froze on me for a period of over a minute. It's not clear why but other apps were ok so the problem seemed to be at the Wikipedia end. And that's not the only sort of performance issue. Wikipedia is constantly growing in size and so this tends to cause technical limits to be hit. Some pages can't easily be deleted now because they have had too many edits. Some pages won't display properly because they have too many templates. DYK had to divide its operations in two for such reasons and AfD is regularly affected too. Blithe reassurances are unconvincing because it seems apparent that no sizing or testing has been done – the only estimate we seem to have of the impact is "gazillions". The planned process seems to be to turn bots loose for a day and find out the hard way. This is just asking for trouble.

And note that the effects are permanent; not just a transitional spike. By adding lots of unnecessary edits, the page histories will all be that much longer and harder to analyse, process and understand.

And the purported benefits seem marginal. For new editors, the future is the Visual Editor, which does not require this. And for scripting, you can't rely on a particular format because there will always be new pages which will not conform. The effort seems mainly to be busywork for its own sake – playing with bots as toys or to boost edit counts.

My !vote stands.

Andrew🐉(talk) 12:27, 29 October 2020 (UTC)

Andrew Davidson, the number of bot edits taking place has zero effect on the performance of the site. The MediaWiki software is designed with scalability in mind and is capable of handling a lot of more edits daily than the number that actually takes place. In extreme occasions where a botop loses control and drives in 1000s of edits in a few seconds, the database locks up in a read-only mode for a number of seconds during which no edits can be made, but even that does not impact readability of the site. Of course, Wikipedia may freeze and go offline occasionally, but high rate of edits is AFAIK never the reason for those issues. – SD0001 (talk) 09:31, 30 October 2020 (UTC)

@Andrew Davidson: Is this not a question for the developers? And if this is likely to result in performance issues (or is unlikely to result in performance issues but does so in the future), do you not think that they will intervene? 207.161.86.162 (talk) 08:48, 6 November 2020 (UTC)

It's usually easy enough to find out the answer to that question: Aaron Schulz, Krinkle, would your team like to propose any limits on this, if it were adopted? Whatamidoing (WMF) (talk) 21:14, 15 November 2020 (UTC)

• Oppose. The edits are at minimum unnecessary and sometimes undesirable (adjusting spacing, and so on) and cause watchlist problems and pointless discussion. SarahSV ^(talk) 02:41, 26 October 2020 (UTC)
• Support with restrictions, pretty decent idea. Headbomb's link above to WP:BOTDICT#Editor-friendly wikitext is very appropriate. Sometimes wikitext just looks awful and is difficult to edit, and I completely understand the irritation of not being able to clear out a tracking category. However, I think this event should occur very infrequently; twice a year is okay, but I would prefer once a year. Also, there should be an effort to fold all such edits together into at most one edit per article. Maybe there could be a queuing system on Toolforge where cosmetic bots could edit a temporary version of the article for an hour before it gets saved. Enterprisey (talk!) 07:25, 26 October 2020 (UTC)
• Support per Enterprisey. Interesting that the BAG here are more open to the idea than the non-BAG. I think having friendly wikitext is a good idea. The articles where it is a mess, it is very unfriendly. Just most don't too often see the articles where it is a mess. Once a month seems reasonable. No limit to number of cosmetic bots ideally - this only really works if we can get all the cosmetic workload done in a day. Ideally using maxlag to ensure the bots switch off when needed. Perhaps spreading it over an extra day, depending on number of cosmetic bots, will be required to accommodate both these things. ProcrastinatingReader (talk) 13:11, 26 October 2020 (UTC)
  • I would guess most technically-inclined editors (BAG or not, myself included) put little stock in the phrase "it blows up watchlists" and similar, which is not to say that it does not, but that this concern is problematic is not well-founded, or is of lesser value relative to making wikitext (usually) more-consistent. (I do not attempt to set up a strawman here, only explain the observation.) --Izno (talk) 14:58, 26 October 2020 (UTC)
    • There's always the "human edits only" on watchlists, too... ProcrastinatingReader (talk) 22:32, 26 October 2020 (UTC)
• Were this proposal ever to become reality (I'm not going to hold my breath) I think that it would be damned useful. Editors often complain about citation templates and how they interfere with reading the wikitext of an article. When cs1|2 templates are used inline, there isn't much that can be done to improve the wikitext reading experience. One can convert to list defined referencing but that is the sort of thing that requires local consensus. But, one thing that can be done and is cosmetic, is to remove empty parameters that serve no other purpose than to occupy space (no empty parameters in cs1|2 templates have meaning). I can imagine a Monkbot task that does nothing but remove empty and ignored parameters. cs1|2 is moving to standardize on hyphenated multiword parameter names so replacing the all-run-together forms of parameter names would be a nice adjunct to empty-parameter removal. I have prototypes of bot code that does these two things that I have employed in manual awb tasks to clear various cs1|2 error categories.

  Some here have objected to this proposal because of the quantity of edits. They may be correct that on the first CBD there will be a bazillion edits. I suspect that the quantity of CBD edits will not stay at that same first-CBD level on succeeding CBDs simply because there will be fewer things that need cosmetic fixes. If that is true then monthly seems to me to be about right.

  —Trappist the monk (talk) 14:46, 26 October 2020 (UTC)

  Since writing the above, I have been picking at a cosmetic bot task to do the things that I mentioned. And I kept picking at it until suddenly Wikipedia:Bots/Requests for approval#Monkbot 18. Comments welcome.

  —Trappist the monk (talk) 19:45, 14 November 2020 (UTC)

• Support. I highly support this proposal. As an editor who works on TV- and film-related infobox category cleanup, cleaning manually a category of 10k pages of unknown empty parameters is a nightmare, where a bot can easily do this. I understand editors who don't want to have a watchlist spammed, but I can not relate. I believe most cosmetic changes are useful and make editing easier for both regular editors and editors working behind the scenes with templates, modules, tools and bots. Just so I'll make it easier for whoever closes this, I support the 1 month, but if consensus decides on a different number, I'm good with that (preference for as frequent as possible). --Gonnym (talk) 15:01, 26 October 2020 (UTC)
• Support. I also believe that a lot of cosmetic edits are in fact useful, even if they do not change the appearance of the rendered article. And often useful in the long run, by improving consistency and removing unnecessary elements, but as the benefit is in the long run, some editors only see the drawbacks during the edit (watchlist mainly). Dedicated days for such edits will limit the annoyance for such editors, but allow to do the cleanup that is useful. I'm not sure the number of pages modified in one day will be so high: for my bot, I usually have a 10s delay minimum between 2 edits, so only 8640 edits on 24h. I think a day each month would be good: for big lists, it would still require several days to do the clean up. Maybe less after the big cleanups are done. --NicoV ^{(Talk on frwiki)} 17:37, 26 October 2020 (UTC)
  • Except it isn't 8640 edits per 24h, it's 8640 edits per bot per 24h (for those that use the same delay as you). Given the number of different tasks mentioned here, there is the potential for 10-20 edits per article to produce no benefit to the reader. Thryduulf (talk) 18:09, 26 October 2020 (UTC)

    Folding all cosmetic edits together (if technically feasible), as I proposed above, could result in one edit per article. Enterprisey (talk!) 07:24, 29 October 2020 (UTC)

• Very weak support Indeed, many of those edits are invisible for the reader but they do clean up strange things. My strong preference is to attach those tasks to already existing approved tasks. The down side a polluted watchlist? In principle is that a one off/yearly event and after 24 hours a lot of those things are already out of focus. The Banner talk 17:50, 26 October 2020 (UTC)
• If this does go ahead (and I still maintain my strong opposition to it) then there should be an absolute maximum of one cosmetic edit per article per day, regardless of how many issues there allegedly are or how many bots there are "fixing" them. This will limit the pointless disruption to the encyclopaedia. Thryduulf (talk) 18:09, 26 October 2020 (UTC)
  • Just to make it "official" - I oppose the above absurd proposal which will make it needlessly harder to cleanup. --Gonnym (talk) 18:24, 26 October 2020 (UTC)
    • Yeah, that doesn't make sense. One edit per bot per article per day, perhaps (but even that means stashing every task's code together into one. Anyone who writes bot tasks here knows that is not how bot tasks are written. They usually run independently. That would be completely unfriendly). But this limit being enforced for all bots is just more work to check and enforce programatically, and it massively diminishes the benefit of the proposal. Just turn off bot edits on your watchlist for a day if it bothers someone. ProcrastinatingReader (talk) 22:35, 26 October 2020 (UTC)
      • Turning off bot edits means you miss other edits. I've missed BLP violations because of cosmetic edits (this is from the period in which one particular editor was allowed to make cosmetic edits before ArbCom stepped in). SarahSV ^(talk) 21:28, 27 October 2020 (UTC)

        Whether you miss edits depends on your watchlist settings. Some of us (including me) use the settings that show only the most recent edit to a page. If that's a bot, then the whole page disappears from your watchlist. Others show each edit separately, so only the bot edits disappear (but then you have to look at every single edit to that page on a separate line, which can turn my 300-pages-per-week display into a 1,200-edits-per-week list). Whatamidoing (WMF) (talk) 16:03, 28 October 2020 (UTC)

        @Whatamidoing (WMF): phab:T11790 is the perennial issue. I think if that were resolved we'd see more agreeableness from a number of people who otherwise are opposed to cosmetic bots. --Izno (talk) 17:58, 28 October 2020 (UTC)

        We could put it back in the m:Community Wishlist, which should open in a few weeks, but it didn't vote very high last time, so I'm not sure that it would help. There's not going to be fixed number of "winners" this round, but if memory serves, it didn't even come close to winning in the past. Still, it should probably be on the list. Whatamidoing (WMF) (talk) 23:11, 28 October 2020 (UTC)

• I honestly think this proposal works on the problem from the wrong direction. Even though I agree that cosmetic bots should be allowed to run more freely, I also think making one day for all the insanity will indeed result in watchlists and recent changes being very difficult to follow for that day rather than a more leisurely rate of 1epm each or w/e. --Izno (talk) 19:22, 26 October 2020 (UTC)
• These should just be done through the regular approval process; COSMETICBOT does not forbid cosmetic bots. If we're going to implement a Purge, I would prefer it be annual instead of monthly. Enterprisey's suggestion of a database copy that gets edited and then updates pages once sounds like the best idea. — Wug·a·po·des​ 20:27, 26 October 2020 (UTC)
• One thing definitely worth doing would to rearrange all Infobox templates to one item per line. Same goes for columns in tables. Downsize43 (talk) 21:38, 26 October 2020 (UTC)
  • I very strongly oppose changing all tables to be one column per line. Sometimes that is best, other times it makes things much harder to read (especially when you have multiple narrow columns of similar width). In a couple of tables I've seen the organisation is the first column (e.g. name of a lake) is on one line, with the columns for area, depth, and perimeter length all on the second line, which works well for that use. Thryduulf (talk) 22:02, 26 October 2020 (UTC)
    • You have completely misunderstood my proposal for tables, which is “every field of a table on a separate line”. Downsize43 (talk) 22:26, 26 October 2020 (UTC)
      • Then you need to explain what you actually do mean as I have no idea - tables have only rows and columns and however you choose to map fields onto them one format for wikitext is not appropriate for all tables, regardless of what that format is. Thryduulf (talk) 23:44, 26 October 2020 (UTC)
        • I think Downsize43 means that each cell/field in wikitext is on its own line in the "edit source" view. Schazjmd (talk) 00:26, 27 October 2020 (UTC)
          • Thank God someone understands what I mean. I had no idea it would cause such confusion. Just try to imagine a table of 10 rows by 10 columns written as one text string with no carriage returns. I have encountered and “fixed” a few of them; others I have given a wide berth. Downsize43 (talk) 02:12, 27 October 2020 (UTC)
            • I agree that 10x10 on one line is bad, but I disagree that there is one format that is correct for all tables so this is not a task suitable for a bot because (a) there is no way of determining algorithmically whether a given table needs fixing, and (b) which format is best depends on multiple factors that it is not possible for a bot to easily determine. Thryduulf (talk) 13:28, 27 October 2020 (UTC)
• Support trial - I think this discussion is struggling to get a good idea on "just how much inconvenience" vs "genuine benefit". I'd like to suggest we run a one-off trial, say on the 2nd Jan (I think lots of stuff gets changed on 1st, and don't want to pile on top), but specific can be determined. I want to give 2 months spare time for the bot community to figure out exactly tolerable levels, limits, priorities, etc - they're only going to get one shot at proving it works. Give a few days for feedback, then start a new RfC. Thoughts? Nosebagbear (talk) 22:29, 26 October 2020 (UTC)

  I think we'd need the data to figure out the quietest day to do it on. At the same time, the first run should maybe be longer than 24 hours if we do this. Since cosmetic bots have usually been prohibited, the current backlog will be very high (depending on how many bots sign up to this). If we're going to cause "disruption" for a day, noting that cosmetic bots will run at lower editing rates and stop at maxlags, we might as well power through the list and get it over and done with than arbitrarily choose which articles get the fruits of bot cleanup. Then any subsequent months will barely be a few hours runtime. 8640 edits per day per bot per task (at a rate of 10/sec) is not a lot, and I imagine the editing backlog of all these cosmetic tasks is high.

  Also note some of these tasks will overlap with stuff human editors already do, and it will decrease cognitive load for other edits, so really this is a productivity boost all around. Let the bots do what they're good at, so the people can do what they are good at. ProcrastinatingReader (talk) 22:46, 26 October 2020 (UTC)

  Re:all these cosmetic tasks Let's slow down a bit here... First we have to identify what task would even be considered acceptable. It's not because |para1=value |para2=value |para3=value is more readable and line-breaks better in the edit window than |para1=value|para2=value|para3=value that a bot should do those conversions. An infobox standardizing bot might fly, but that also doesn't mean that an edit is warranted just because there's a slight deviation from the standard layout. Headbomb {t · c · p · b} 22:57, 26 October 2020 (UTC)

  Perhaps, but how about Special:Diff/984743249, for example? The before was a mess. Bots cleaning this up would seemingly be a pro, right? ProcrastinatingReader (talk) 23:37, 26 October 2020 (UTC)

  That one's a plus, but the thing is, what exactly makes it a plus? Can that be coded reliably? What are the limits applicability? Should other standardization be done alongside 'one parameter per line'? So all these questions make it tricky to generalize to a set of yes/no that applies accross the board for a cosmetic bot to be considered useful enough. Headbomb {t · c · p · b} 00:47, 27 October 2020 (UTC)

  Bots cleaning this up would seemingly be a pro, right? No, because the bot edit would make it harder for human editors to identify and correct the content error by hiding the edit in watchlists and preventing edits from being undone automatically as well as adding clutter to the watchlist. Thryduulf (talk) 23:44, 26 October 2020 (UTC)

• Support. The diff by ProcrastinatingReader shows it well, and there are cases much worse, have seen whole Infobox in one line. TerraCyprus (talk) 02:11, 27 October 2020 (UTC)
• Support The valuable changes this would bring about outweighs any cluttering of watchlists and edit-conflicts. As for watchlists, is there not a way to add the "human (not bot)" flag by default? This would remove any clutter caused by these or other bots. Sam-2727 (talk) 12:32, 27 October 2020 (UTC)
• Oppose. I see above proposals to e.g. change articles with tables, to get one "cell" per line in edit mode. Why? Some may prefer this, others like (at least for some tables) the way it is set up in "List of best-selling books", where each "block" of code in a table represents one row in the table, making (for me) for much easier "reading" of the code as a whole. If this proposal would get approved anyway, it should be restricted to cosmetic edits which actually solve an error, and keep truly cosmetic edits like reordering code simply because some people prefer look X or Y out of it. This day should never be used as an excuse to impose one stylistic preference over another (be it spaces in infoboxes or around headers, spaces or no spaces after asterixes, and so on). Fram (talk) 13:00, 27 October 2020 (UTC)

Every bot requires consensus at WP:BRFA ("Bot Request for Approval"). The proposal does not remove the need for consensus for individual bot tasks. GreenC 18:23, 29 October 2020 (UTC)

• Comment Perhaps to say the obvious, but I think we should think of a better acronym than CBD (see Cannabidiol). I can imagine no shortage of quirky clickbait articles poking fun at us for "loving CBD". Perhaps BSD "Bot Syntax Day" or BFD "Bot Formatting Day". CaptainEek ^{Edits Ho Cap'n!}⚓ 20:05, 27 October 2020 (UTC)
  • I think exactly this every time this section shows up on my watchlist - Astrophobe (talk) 23:08, 14 November 2020 (UTC)
• Support. It irks me to no end to have to work around inconsistent infobox formatting and (especially) ordering of parameters, which makes duplicates more likely as the original is harder to spot. SounderBruce 23:33, 27 October 2020 (UTC)
• I'd want to see an estimate of changes first — both for the first run, and then subsequent iterations — but I think it does have merit. Like Enterprisey, I think once a month is entirely too often. Twice a year seems reasonable. I also think it'd be better organized as a single bot/BrfA so it's easy to add/remove/adjust/track/etc. as needed. ~ Amory (u • t • c) 10:57, 28 October 2020 (UTC)
• Support, but less frequently (maybe twice a year?) and with a system that merges all edits into one that is saved on the page. I'm happy to help create that. – Majavah ^{talk · edits} 13:04, 28 October 2020 (UTC)
• Oppose. Wikipedia should be free to edit at any time and day. Restrictions on the type of edits should therefore never be scheduled. Either the community wants certain edits done or they don't. The problem this is solving is also a software problem -- with article histories, watchlists and recent changes. I understand the proposal, the current limitation, the reason for the policy and the arguments for this exception. But I don't believe this is in the spirit of Wikipedia. That said, if this was a single bot running once a month with one edit per article, I would be fine, but not a free-for-all cosmetic day. —  HELLKNOWZ   ▎TALK 15:08, 28 October 2020 (UTC)

The proposal is not a not a free-for-all cosmetic day. All bots requires consensus and approval per normal procedures at WP:BRFA. -- GreenC 18:15, 29 October 2020 (UTC)

• It's an interesting idea. There are some cosmetic edits I like; others people call "cosmetic" but which actually come down to individual user preference. It also seems like there's a presumption that perhaps there would be several cosmetic bots going on this day. Wouldn't it be better to concentrate all of them in a single bot and allow that bot to run, say, quarterly? Maybe that's the same proposal with a stipulation. I imagine something that could even utilize a survey of possible changes to see what there is consensus for and what not. Spitballing, mainly. — Rhododendrites ^talk \\ 15:51, 28 October 2020 (UTC)
• Comment It's an interesting idea to fix a myriad of trivial or irritating deprecated parameters or minor fixes across one 24 hour period, but would it not also be a perfect invitation to vandals to insert a vast amount of nonsense on that same day, knowing that Watchlist alerts would be swamped and mostly ineffective? I like the idea of somehow such edits being addressed off-wiki and replaced in one go. Or, alternatively, the Watchlists being optionally able to not report such minor mass-edits made in this way. And what would stop someone with access to AWB running some inappropriate changes across many articles which would then go unnoticed? Nick Moyes (talk) 17:40, 28 October 2020 (UTC)
  • Nick Moyes, on watchlist set options: "human (not bot)", "unseen changes" and untick "latest revision"? Regular AWB editors and vandals would thus show up as normal, I think? ProcrastinatingReader (talk) 18:40, 28 October 2020 (UTC)
• Support if the proposed edits have consensus - First, let us all step back and recognize one important truth: If there is something that can be done to improve the encyclopedia, it would be stupid of us to not do it because we don't want to light up our watchlists. I mean, come on, we've got minor flags and bot flags and technology that can allow us to improve the encyclopedia and also have useful watchlists at the same time. We can put people on the moon and robots on Mars, we can figure out how to properly filter out automated edits from a watchlist. Hell, we might even make a new flag for this, "cosmetic bot edit", so we can filter that out. But, we can do it, people, we can do it. That said, the question is whether we want these edits done or not. If they are desirable edits, then yes, I support doing them, really every day, but one day per month is better than zero. The real question is what the edits will be. If "cosmetic edit" is just another word for unnecessary edit, then this is dead in the water. But if there are improvements to the encyclopedia that we can make that we are not making (or that we are making by hand that could be done by bot), then let's start making them. Lev!vich 23:12, 28 October 2020 (UTC)
• Support mostly for fixes that have accessibility-improving side effects, such as infobox parameter spacing, as these fixes are helpful, frequently needed yet invisible or "cosmetic" on the resulting page output. ~ ToBeFree (talk) 23:58, 28 October 2020 (UTC)
• Support per above. Inconsistent/strange formatting is incredibly discouraging for newbie editors. The benefits greatly outweigh any alleged drawbacks imo. -FASTILY 00:20, 29 October 2020 (UTC)
  • Really? The drawbacks greatly outweigh any alleged advantages imo. Especially as almost all the proposed changes are "fixing" things that aren't broken by enforcing one personal style preference that makes things significantly worse in some situations. Thryduulf (talk) 03:26, 29 October 2020 (UTC)

  Nice straw man, but your rebuttal does little to address my initial concern of newbie discouragement. -FASTILY 07:15, 29 October 2020 (UTC)

  If you have any evidence that any specific formatting is discouraging newbies over and above the discouragement presented by any and all source editing, then feel free to propose a bot task that fixes those problems reliably and correctly without introducing any new problems. Unless and until you can do that then my point which addresses every nearly specific change proposed stands. The solution to the problems of cosmetic bots is not to ignore them for one day a month but to run bots which don't cause those problems. Thryduulf (talk) 11:17, 29 October 2020 (UTC)

  Per this comment, and the one below to the IP (which are sorta bludgeoning btw, esp since you're not addressing specific comments), I don't understand what points you're making which haven't been addressed. Your points seem to be these two: (a) it clogs up watchlists and (b) not all of these edits are supported by consensus. I've provided a solution to (a) multiple times, and for (b) the proposal already says "assuming there is otherwise consensus for the bot". i.e., the edit it is making should be supported by a PAG. Multiple cosmetic tasks are already approved, to run alongside other tasks. So the assumption that no tasks exist prohibited by WP:COSMETICBOT and having consensus to be improvements is not true. ProcrastinatingReader (talk) 11:30, 29 October 2020 (UTC)

  To avoid any appearance of bludgeoning I'll make this my last reply for a while, but while you have made suggestions for the watchlist issue, other people have pointed out that either they wont actually solve the issue or they will create other, bigger ones. Those points have not been addressed. Indeed the specific problems raised in opposition (by myself and others) have been ignored or hand-waved away, frequently based on ILIKEIT style comments. Thryduulf (talk) 11:50, 29 October 2020 (UTC)

  At a skim I cannot see the reply which addresses why my solution given to Nick Moyes above won't solve the issue? I don't give that solution with too much certainty btw, so there may well be an issue, but I'm not aware of one yet. ProcrastinatingReader (talk) 11:59, 29 October 2020 (UTC)

• Support Sure, why not? – John M Wolfson (talk • contribs) 02:03, 29 October 2020 (UTC)
  • You mean other than all the disadvantages described in this very thread? Thryduulf (talk) 03:26, 29 October 2020 (UTC)
• Support – Seems like a most sensible solution to the problems with allowing open season for cosmetic changes made by bots, given the existing technical limitations. 207.161.86.162 (talk) 02:58, 29 October 2020 (UTC)

  Allowing open season for cosmetic changes by bots is the solution to the problems with allowing open season for cosmetic changes made by bots? This doesn't seem to follow any logic at all. Thryduulf (talk) 03:26, 29 October 2020 (UTC)

  Why don't you go ahead and attempt a more charitable interpretation of my comment. 207.161.86.162 (talk) 03:38, 29 October 2020 (UTC)

  Because I literally cannot think of any interpretation of your comment that makes any sense. The status quo is that that bots which make cosmetic changes only are not allowed to run at any time, because this prevents all the problems with them. This proposal is to allow those bots to run at specific times (i.e. the times when the season will be open) without addressing any of the problems they cause. Thryduulf (talk) 11:17, 29 October 2020 (UTC)

  I trust you can try harder than that. 207.161.86.162 (talk) 18:21, 29 October 2020 (UTC)

• Support, sounds sensible. Renata (talk) 03:29, 29 October 2020 (UTC)
• If all bot edits scheduled for the given day ought to be combined into one per article (as I think they should be), we have at least two options: run a service on Toolforge to combine all the edits, or have the bot authors submit all code to be run on a single account, using another program to combine edits. Side benefit: we'd know earlier if any bots were making conflicting edits. Actually, we should check that none of the bots will conflict with each other anyway. Enterprisey (talk!) 07:32, 29 October 2020 (UTC)

  We would need to make something which can merge that Toolforge-edit into the main article, resolving edit conflicts. Because edit conflicts seem likely then, and that means this becomes moot for many articles. ProcrastinatingReader (talk) 10:17, 29 October 2020 (UTC)

  btw, seems like @Majavah expressed support above in creating something like this? It would certainly address the largest concern raised about this ('lots of edits'), if we could have a separate place where bots do their edits, which are merged into the article. Some kind of basic merging (like git) might address most conflicts, and optimistically I suppose a basic 'queue' for manual resolution may address the remaining ones. I figured this may be too much work compared to just a regular CBD, but if we get the manpower to create such a system that'd also be pretty neat. ProcrastinatingReader (talk) 13:57, 29 October 2020 (UTC)

• Sarcastic support. This will give me a chance to slip in those edits in the text of certain articles that the other editors who watch those articles don't like. They'll never notice amongst the flurry of cosmetic bot edits. Jc3s5h (talk) 12:47, 29 October 2020 (UTC)

It's the work of a minute to adjust your watchlist settings so bot-tagged edits are filtered out. – Teratix ₵ 13:51, 29 October 2020 (UTC)

• Tentative support, with the caveat that I don't have significant experience in bot editing on Wikipedia. It seems likely that there are certain categories of bot-supported edits, such as fixing editor-hostile markup, that would not meet the threshold of usefulness to merit a frequently-running task; however, if this bar was lowered by making the task an annual or biannual event, it would meet the threshold. Enterprisey's suggestion to combine all proposed changes into a single edit also seems like a reasonable idea to minimise watchlist disruption. – Teratix ₵ 13:51, 29 October 2020 (UTC)
• Comment A list of exactly what type of changes that would be done would be useful, along with the number of articles too. Lugnuts ^{Fire Walk with Me} 14:31, 29 October 2020 (UTC)

Bot proposals are made at WP:BRFA. This CBD idea is not a bot proposal. -- GreenC 18:10, 29 October 2020 (UTC)

• Oppose Many of the proposed tasks have caused edit wars when humans try to do them, and introducing periodic bot-edits to do exactly the same thing is only going to exacerbate that problem. Perhaps there are some cosmetic edits that would truly be beneficial, but unless we first build consensus that human editors should be doing it that way also, we're just going to be creating bot vs. human issues as people just revert the bot when it conflicts with their preferred format. If we do this at all, it should be done as a single edit per page with a single bot once per year (twice at most). CThomas³ (talk) 16:03, 29 October 2020 (UTC)

@Cthomas3: Every bot requires consensus at WP:BRFA ("Bot Request for Approval"). The proposal does not remove the need for consensus for individual bot tasks. -- GreenC 16:58, 29 October 2020 (UTC)

Just because a few editors at BRFA think something sounds like a good idea doesn't mean that every editor on every article agrees. If the bot changes someone's pet article in a way they don't like, they are just going to revert it at their first opportunity. Next month, the bot makes the same edit, and so on. Is our plan to allow a bunch of slow-motion bot vs. human edit wars? CThomas³ (talk) 20:47, 29 October 2020 (UTC)

BRFA in general has the same issue, and it seems to have gotten along fine. Enterprisey (talk!) 05:01, 30 October 2020 (UTC)

That's a good point, but I would suggest that several of the suggestions already presented here tend to be more of the 'editor preference' type and not necessarily an objective improvement (such as lining up infobox parameters, converting tables to one cell per line, and converting template redirects to their canonical equivalents). If we're saying that these types of edits would likely not be approved at BRFA then perhaps I am being overly cautious. CThomas³ (talk) 06:30, 30 October 2020 (UTC)

This proposal doesn't aim to loosen standards for consensus or create new 'good' cosmetic tasks. It's simply to relax WP:COSMETICBOT for a day, which is overriding exclusionary criteria (even when the edit otherwise would have consensus). In a similar manner to how WP:NOT is exclusionary criteria; even if an article would otherwise meet notability guidelines, its presence can be prohibited by an overriding policy. COSMETICBOT is that for cosmetic edits (with some exceptions, eg substitution bots). Things like a general 'converting tables to one cell per line' would (if they're even supported by a PAG in the first place) likely fail WP:CONTEXTBOT anyway. Others may genuinely not be an improvement (per Headbomb's posited questions above). Those, I suspect, would not be approved to operate. ProcrastinatingReader (talk) 13:04, 30 October 2020 (UTC)

• Strong support, at least as a one-time thing. I see things in wikitext all the time that should be fixed en masse. A bot just sweeping through all articles on a selected day and just doing the baseline AWB genfixes would be a boon. BD2412 T 17:19, 29 October 2020 (UTC)
• Oppose - The notion of disallowing such bots because they bother people on their watchlist has always seemed ridiculous to me. That aside, I would not be opposed to approving specific bots for limited runs but giving a carte blanche day ("assuming there is otherwise consensus for the bot" — how would this be determined?) for it would lead to potentially controversial alterations en masse. This is something I cannot support. — Godsy ^(TALK_CONT) 17:44, 29 October 2020 (UTC)
  • Every bot requires consensus at WP:BRFA ("Bot Request for Approval"). The proposal does not remove the need for consensus for individual bot tasks. -- GreenC 18:02, 29 October 2020 (UTC)
• Support but would prefer quarterly or less frequently. A notice somewhere (maybe WP:VPM or WP:VPT?) to remind us to check WP:BRFA in the weeks leading up would be much appreciated. Ajpolino (talk) 04:37, 30 October 2020 (UTC)
• Support Mostly per the arguments by others. However, I will note that while the original proposal of a cosmetic bot day will lead to a huge amount of bot edits in a short period – so it would make more sense to have cosmetic bot week or fortnight so the edits can be spread out a bit. – SD0001 (talk) 08:16, 30 October 2020 (UTC)
• Oppose - There are good reason why we prohibit cosmetic edits. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:11, 30 October 2020 (UTC)
• Oppose this is an interesting idea, but the Cosmetic Omni-Bot idea (having all the cosmetic changes with consensus done by one bot) is a better one. The problem with bot edits hiding vandalism (phab:T11790) can be solved by requiring that the page have no edits in the past 72 hours before a COSMETICBOT edit is allowed. power~enwiki (π, ν) 18:26, 30 October 2020 (UTC)
• I'm all for changes that make markup significantly more editor friendly; I don't think that should be classified as a cosmetic change. However, I strongly disagree with changes that make it less editor friendly. Changing {{ill}} to {{interlanguage link}} by bypassing template redirects (as suggested earlier in the discussion) is not a helpful change for editors because it unnecessarily crowds the markup. (t · c) buidhe 01:22, 31 October 2020 (UTC)
• Support only for a limited set of changes - For stuff that takes little-to-no thought to do, such as removing the useless word "template" from templates invocations, this would be helpful. However, I've seen situations where bots come in to do "cleanup", and then just have to get widely reverted by humans again. For instance, see this edit by FrescoBot from a few months back, which was then undone by Lieutcoluseng. Another example is that some template redirects are intentional. A lot of these types of linty errors are done for a set purpose by the original editor, and having a bot blindly plow through it is a bad idea. However, for situations where the use truly adds nothing, like WP:CWERRORS #1 or #6, this would be quite helpful. Hog Farm _Bacon 02:30, 1 November 2020 (UTC)
• Oppose: I see the drawbacks in flooding editors' watchlists (which will reduce our ability to stop vandalism and other unconstructive edits etc.) and clogging up the page history as outweighing the benefits of the small proportion of cosmetic edits (such as linting errors) which I do think are acceptable. This is what I think about once a year, let alone once a month. I certainly don't think standardisations like *text to * text is worthwhile at all. Even many gnomish human edits to make cosmetic changes, I have found in practice to be more unhelpful than helpful for these reasons. We have plenty of non-cosmetic gnomish tasks which are more obviously helpful. On the other hand, for any cosmetic changes which do have consensus as acceptable (such as those which some bots do alongside other tasks) could perhaps be incorporated into InternetArchiveBot, which is now running on a good number of pages that such a change would go a significant way towards achieving what CBD is attempting to achieve. — Bilorv (talk) 20:47, 1 November 2020 (UTC)

InternetArchiveBot will not be taking cosmetic edit requests :) The proposal for *text to * text is a strawman ie. easily rejected as a bad idea. But the existences of this bad cosemtic edit ideas does not preclude other better ideas. --GreenC 15:11, 7 November 2020 (UTC)

• Support I believe that BAG will do a good job at requiring an appropriate strength of consensus for these tasks to be approved and are aware that they are somewhat contentious. Most of the other concerns I've seen such as performance issues, watchlist flooding and page history fluff either have solutions or are even smaller than the issues fixed. One precaution I think we should take though: Place a watchlist notice explaining how to filter bot edits during the day. --Trialpears (talk) 22:56, 5 November 2020 (UTC)
• Support:

1. As long as the WP:BAG isn't overwhelmed. Enough lead-time should be give so that all bots are able to receive the regular amount of scrutiny & testing prior to CBD.
2. Perhaps a 1-time CBD, and then reevaluate via another VPP to see the effect & community response to making it a regular (monthly, yearly, etc.) thing.
3. Many of the Opposes above seem ignorant of the Watchlist option to exclude bot edits.

~ Tom.Reding (talk ⋅dgaf)  14:29, 7 November 2020 (UTC)

Almost all of those commenting about the option to exclude bot edits seem ignorant that the drawbacks to this option have been explained (and ignored) multiple times already. It also completely ignores all the other reasons this is a terrible idea. Thryduulf (talk) 16:34, 7 November 2020 (UTC)

@Thryduulf: not agreeing with certain cosmetic edits is not a legitimate reason to oppose. Regardless of the outcome of this VPP, WP:BAG/WP:MOS/the community/etc. will continue to decide if particular cosmetic edits, and the way in which they are programatically found & fixed, will make it into a BRFA.   ~ Tom.Reding (talk ⋅dgaf)  16:55, 8 November 2020 (UTC)

That addresses one more reason (given the reasons peopel give for supporting here I'm not confident they wont be passed at BRFA, but that's a separate issue) but ignore the rebuttal to the "hide bots" argument and the other reasons given. Thryduulf (talk) 17:32, 8 November 2020 (UTC)

• Support, with the proviso that the duration and frequency of this period be adjusted appropriately based on the experience of the first iteration(s). Cosmetic edits are useful and in many cases bots are fully capable of completing what would have been days of human-work in moments. This proposal only allows bots which have been determined by WP:BRFA to be useful. This proposal sensibly limits the downside and I see a net benefit to the encyclopaedia. --LukeSurl ^{t c} 10:07, 8 November 2020 (UTC)
• Support Logical idea so useful edits that currently effectively disallowed can be done on a large scale. Zoozaz1 talk 04:25, 10 November 2020 (UTC)
• Oppose, because too few people will have the power to reformat inboxes without the community as a whole having a say on how they should look. I'm sure numerous editors don't even those this is being proposed! • Sbmeirow • Talk • 05:32, 10 November 2020 (UTC)
  • Every bot requires consensus at WP:BRFA ("Bot Request for Approval"). The proposal does not remove the need for consensus for individual bot tasks. -- GreenC 15:37, 12 November 2020 (UTC)
• Support, the more standardized the code behind the scenes the better. One day on occasion will help clean things up. spryde | talk 14:52, 12 November 2020 (UTC)
• Support kind of monthly seems too often. Perhaps also should block anonymous edits during period. Maybe slice up by hours into parts bh first letter: first hour non-letter ... last hour XYZ. Maybe require bots to sign up: this month the BlueBot will run and do cosmetic changes? AManWithNoPlan (talk) 15:23, 12 November 2020 (UTC)
• Support as this actually makes human powered AWB/WPCleaner tasks faster because there are not cosmetic changes that also need to be made. Also, cosmetic may not be noticeable to readers, but editors will often easily notice cosmetic changes. Gsquaredxc (talk) 17:24, 12 November 2020 (UTC)
• Support I trust that the BAG will have enough sense to know if something is controversial or not, I also support something like this going monthly or maybe even bi-monthly. Yearly seems like it would be far too easy for issues to crop up and get ahead on them, especially given what I suspect is the current backlog. If we want a good place to start, the lists at Wikicheck. There are currently over 179k issues, the majority of which are minor formatting or things like interwikis in wrong places, duplicate references, references before punctuation etc. These are things that have been identified as fixing but have not been done. Other projects like updating old template fields and other minor general fixes could also be performed. The CS1/2 errors could become a lot more easily manageable for user intervention. These are tasks that for the most part are menial and would do a great job at cleaning up template redundancy and improving usability for people that edit. If there are certain changes or pages that are continually being touched by the bots that we don't want to be, an extra parameter could like No bot could be created surely for no cosmetic bot. For example, the spacing for infoboxes doesn't seem to be a popular choice, and I'm sure the BAG would reach out if they had concerns that some could cause issues. --Lightlowemon (talk) 12:02, 13 November 2020 (UTC)
• Oppose. Been mulling this over for a while and the devil's surely in the details. My main concern, mirroring others above, is watchlist and page history flooding. I'm not seeing where the marginal benefit overcomes that. I could possibly get behind rolling genfixes in which a bot, running existing cleanup work, can cleanup genfixes, whether it's limited to only every 30 days or whenever the bot runs. Please take pains to minimize impact on editors, especially those who occasionally edit and do not participate in these discussions. (not watching, please {{ping}}) czar 22:54, 14 November 2020 (UTC)
• Support I support a careful trial run, and trust that the issues addressed will be non controversial. I think it is a great idea that is likely to contribute to editor wellbeing, editor retention, article quality, maintainability, and help wikignoming-type editors save time and reduce some of our backlogs. Special care must be taken to ensure the edit summaries are appropriately marked. I like the idea of avoiding pages that have been edited in the last 7 days or so, in order to reduce the possibility of vandalism being undetected. --Tom (LT) (talk) 02:37, 16 November 2020 (UTC)
• Support a general fix-up bot. However, it should not be limited to specific days, but should run continuously. If it triggers hourly, then it should only examine articles where the last modification timestamp is between 7 days and 7 days+1 hour in the past. This gives humans some time to revert/update/fix errors and not add confusion during "live" editing. If it finds that an article needs fixes but was edited by itself in the preceding 7 days, then it should not re-edit that article but instead add it to a "possible edit disagreement" list. A second instance of the bot would slowly work backwards to fix errors from the past. That is the easy bit — it will be rather more troublesome to agree what the bot should be allowed to change — GhostInTheMachine ^{talk to me} 18:02, 16 November 2020 (UTC)
• Support There are a number of positive cosmetic changes that should be made but are blocked for watchlist reasons. Ideally start with a small number of bots (say, two or three) allowed on a single trial day, then ramp up to allowing any number of approved bots on a monthly-schedule. Gbear605 (talk) 20:36, 16 November 2020 (UTC)
• Support The current workaround is absurd: bundle substantial cosmetic changes with minor visible changes and apply via WP:AWB. Cosmetic bot day would let us be honest about cosmetic bots. — BillHPike (talk, contribs) 14:37, 18 November 2020 (UTC)
• Support per above. Cosmetic changes have value, and this proposal allows them to outweigh the negative effect of watchlist/history cluttering. Watchlist notices about such a day would be a helpful addition, as well as more careful reviews of reverted bot changes to avoid creating slow-motion edit wars. — Goszei (talk) 07:15, 23 November 2020 (UTC)
• Strong oppose. There is already at least one bot running citing this discussion, and it's amply demonstrating the problems with this proposal: flooding watchlists, "fixing" things that aren't broken, etc. See also Cthomas' comments explaining why the "but BRFA" response does not adequately address these concerns. Nikkimaria (talk) 01:42, 28 November 2020 (UTC)

  That bot actually is mostly fixing broken things not merely cosmetic (soon will be broken - nodash arguments are going away) and while it "cited" this RfC, this RfC is not the reason it was approved, nor is the bot operating under CBD which at the moment doesn't exist. -- GreenC 01:53, 28 November 2020 (UTC)

  Things like "nodash arguments are going away" are IMO part of the problem with this whole discussion. Why are they going away, and where was it decided that they should? If you're mostly active in content creation, mass edits like that come as a fait accompli without clear rationale. I'm concerned that if this proposal goes through, we're going to be seeing a whole lot more of that kind of thing overwhelming our watchlists, without clear benefit. Nikkimaria (talk) 02:15, 28 November 2020 (UTC)

  Maybe? If that happens we could shut CBD down. I doubt it would be a problem though. That rate is limited to one day (thus "CB Day"); for AWB that would be at most 25,000 edits in 24 hrs (7/minute) out of a pool of 6.7 million articles or .00373 articles touched (1/3 of 1 percent). It won't overwhelm watchlists, most watchlists won't see a single edit if evenly distributed. And the BAG ops can limit how many bots are approved, though I don't forsee many applying for it. As noted by Goszei above, "Cosmetic changes [can] have value". There is a balance between the freedom of the individual and the good of the community. CBD attempts to find a balance. -- GreenC 05:04, 28 November 2020 (UTC)

  I do not share your optimism. Nikkimaria (talk) 15:15, 28 November 2020 (UTC)

  Ironically, this bot running has actually helped convince me that allowing cosmetic bots is a good idea, and thus having a CBD is a good plan. :) Gbear605 (talk) 02:01, 28 November 2020 (UTC)

  That one bot would be User:Monkbot/task 18. In the bot's BRFA, I mentioned this discussion as the inspiration for task 18. I did not 'cite' this discussion as permission or authorization for the task.

  —Trappist the monk (talk) 02:18, 28 November 2020 (UTC)

• Support trial as a good compromise. —valereee (talk) 15:22, 28 November 2020 (UTC)
• Oppose. The image caption demonstrates precisely the problem here: "Caution: bots temporarily improving Wikipedia." But cosmetic edits don't improve Wikipedia; they do the reverse, they are worthless at best and generate drama / bad feelings / distraction at worst. There's no reason to ever allow them. It'd be like having some sort of The Purge-lite day where vandalism is allowed; such a proposal is obviously silly, as allowing vandalism for a day won't improve anything. SnowFire (talk) 16:51, 29 November 2020 (UTC)

  How should we deal with tasks such as Monkbot 18's CS1 changes above? (This isn't a rhetorical question, as I can see several credible approaches.) Certes (talk) 17:10, 29 November 2020 (UTC)

  That particular task is problematic because it includes very widespread changes that do not have a clear consensus behind them. It certainly indicates that BRFAs need more input from the general editorship before approval. Beyond that? As I said above, I think it demonstrates the sort of issues raised by this proposal. Nikkimaria (talk) 19:51, 29 November 2020 (UTC)

  If a task is truly technically necessary, then it can pass muster as a normal edit at the bot approval requests page. By definition, it is no longer a cosmetic edit then. Cosmetic edits are by definition the unhelpful ones, similar to how vandalism is by definition unhelpful as well. I'm fine with a discussion on if Monkbot 18's changes qualify as cosmetic or not; I'm not okay with saying "even if it's cosmetic, who cares, fire the torpedoes anyway." SnowFire (talk) 21:23, 29 November 2020 (UTC)

• Comment: perhaps these bots should have their own "cosmetic bot" tag that is default excluded from watchlists. A few days before Cosmetic Bot Day and for about a week after, you have a watchlist message that informs editors about Cosmetic Bot Day and that they can enable seeing those edits in the tags filter. That would at least solve the watchlist issue. VanIsaac_WS^cont 21:57, 29 November 2020 (UTC)
• Oppose I do not think this is a good idea. Since there was a rough consensus against this opinion at the now-overturned close, if this is closed with the same rough consensus, I support the proposals S Marshall proposed, all of which are common sense and would limit the disruption this proposal would cause. SportingFlyer T·C 16:17, 7 December 2020 (UTC)

Closure

In my opinion as a BAG member, this closure should be undone and the outcome of the RFC should be judged by the BAG. There's consensus for a general trial/exploration of having more cosmetic bots on Wikipedia, but the details of the trial have not been mandated by the community and should be left to the BAG. Cosmetic bots are already allowed on Wikipedia, provided they have community consensus and a BRFA. The above 'proposal/supervote' in the closure is simply untenable. There is zero special concerns with bot edits to vital articles or BLPs. Requiring only one single bot edit per article is also untenable, unworkable, unwarranted, and undesired. Part of the point of this trial is to figure out what happens if you give permission for cosmetic bots to edit on Wikipedia a bit more freely, perhaps on a monthly basis. That means seeing what happens with edit conflicts, if there are cosmetic edit wars, how much people get ticked off, and the like. We don't even know what level of interest there is amongst bot coders for coding cosmetic bots to begin with. Maybe there'll be two, maybe there'll be twenty. Headbomb {t · c · p · b} 13:11, 2 December 2020 (UTC)

• Agreed GenQuest ^"scribble" 14:37, 2 December 2020 (UTC)
• S Marshall, please strike the bit about vital articles and living people. Those article types were never brought up in the discussion, AFAICT, so there is no basis for such a prohibition. One could easily argue that vital articles (or good articles, or FA, or living people, or whatever) are the most important to have tidied up so that they are easier to work on and parse. For the record, I think that items 1 and 2 are reasonable based on the discussion. Item 4 is already well established, so it is moot. – Jonesey95 (talk) 20:23, 2 December 2020 (UTC)

• There's relevant discussion on my talk page.—S Marshall T/C 20:27, 2 December 2020 (UTC)

Yes, in which multiple editors asked you to undo the close and let BAG review this, or at the very least leave the details of any trial to the BAG. Which you've refused to do. Headbomb {t · c · p · b} 21:39, 2 December 2020 (UTC)

• I have opened a close review at Wikipedia:Administrators' noticeboard#Cosmetic bot day close review — Wug·a·po·des​ 22:00, 2 December 2020 (UTC)

• That discussion resulted in consensus to overturn the closure, which I have done. For the record, this was the now-removed closing statement. Sandstein 14:31, 6 December 2020 (UTC)

  I had been following along for much of the discussion with an eye to possibly closing. I will be reading again today with the intent of closing (it's always possible that after reading/beginning to write my close I will discover I am not an appropriate closer for some reason - if so I'll strike this and post a comment). Best, Barkeep49 (talk) 16:01, 7 December 2020 (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.

A bot to exclude vanished users from mass messages and/or bot talk page messages

I have filed a BRFA for a task which would if approved add {{nobots}} template and/or Category:Wikipedians who opt out of message delivery to user talk page's of vanished users. The bot will not create user talk pages for vanished users, so only vanished users with talk pages will be affected. This was discussed at Wikipedia talk:Requests for comment/Arbitration Committee Elections December 2020 § Mass message, where it was discussed that sending mass message notifications to vanished users was unneeded for the arbitration committee elections. The idea of using a bot to add the category and also possibly nobots was suggested. I think such a bot would be useful. Vanished users are exceedingly unlikely to be reading their talk page, as they have vanished. Although the messages are harmless, I think talk pages of vanished users should ideally remain unedited unless it is necessary, as it is the closest thing that we have to deleting an account and vanished users are unlikely to every read these messages. The bot task will only edit the page once, so if the bot is reverted, it will not reinstate the changes. For more information on how and what the bot would do, the BRFA is where I've listed specifics. This discussion is to give this some wider attention, so that consensus can be found for a particular way forward. The options that can be taken are:

1. Option 1: Have a bot task which adds {{nobots}} and exclude the talk page from mass messages
2. Option 2: Have a bot task which adds Category:Wikipedians who opt out of message delivery to prevent mass messages
3. Option 3: Have a bot task which adds {{nobots}}
4. Option 4: Have no bot task

If you have questions about the bot, please ping me when commenting here or comment at the BRFA. Dreamy Jazz ^{talk to me | my contributions} 18:42, 30 November 2020 (UTC) (modified Dreamy Jazz ^{talk to me | my contributions} 20:39, 7 December 2020 (UTC))

I would personally vote for Option 1, with a second choice of Option 2. I think that vanished users don't need these messages, so preventing them seems reasonable. Dreamy Jazz ^{talk to me | my contributions} 18:42, 30 November 2020 (UTC)

• Option 1. Per proposal. –MJL ‐Talk‐^☖ 19:58, 30 November 2020 (UTC)
• If someone has spent their time, or wants to spend their time, writing such a bot then I don't see any great objection, but why do so? Just as vanished users don't need to get these messages, they also don't need not to get them. Phil Bridger (talk) 20:40, 30 November 2020 (UTC)
• Made a small modification to the text to add a wikilink to the BRFA at the bottom of my comment so it's clear. Dreamy Jazz ^{talk to me | my contributions} 20:40, 7 December 2020 (UTC)
• Option 1 and 2, if they are not mutually exclusive (different persons/bots may be looking for one or the other). Maybe have {{nobots}} do that categorization automatically? Or is option 2 what is meant by "and exclude the talk page from mass messages" in option 1?  — SMcCandlish ☏ ¢ 😼  05:00, 8 December 2020 (UTC)

  SMcCandlish, I'll clarify. Option 1 is Option 2 and Option 3 together. nobots can do the categorisation by providing "MassMessage" in the "optout" parameter. If Option 1 has consensus, then the nobots template will provide the category + the page will be in the category. The nobots template being used to provide the category is so that less is added to the talk page. Dreamy Jazz ^{talk to me | my contributions} 11:34, 8 December 2020 (UTC)

• Option 4 I watch several talk pages of vanished users for deletion notifications and other queries (in particular from new editors who don't know any better). While I don't have specific numbers to share, I suspect this proposal could have the damaging side effect of facilitating deletions into the void. There may be reasons to add nobots to specific pages, but I think this needs to be evaluated on an individual, case-by-case basis. -FASTILY 03:57, 9 December 2020 (UTC)

Wikipedia for children

Good day I've been informed you can ask questions and give suggestions.

I would like Wikipedia to consider. Start a Wikipedia platform for children at the age of 14. Children are not taught common law or criminal law at schools. It would be important for a growing population to learn there rights, how can children be expected to know the law without it being taught. I believe it would be really good platform for everyone.

People could be members of the platform. A small subscription could be charged.

Let Wikipedia stand out above the rest. After all you are a educational platform. 🇬🇧

Kind regards Andre Hulse — Preceding unsigned comment added by 2a00:23c7:6011:2c01:1084:5d67:531:866b (talk) 18:01, 6 December 2020 (UTC)

Andre Hulse, It is not clear what you are actually requesting. · · · Peter Southwood ^(talk): 20:02, 6 December 2020 (UTC)

Try w:simple:Main Page. The general idea of a Wikipedia for kids is nothing new either: m:Kidswiki. — Alexis Jazz (talk or ping me) 21:03, 6 December 2020 (UTC)

There's also Vikidia, which is not a WMF project (though it is loosely associated with Wikimedia France). Vahurzpu (talk) 21:58, 6 December 2020 (UTC)

Kids actually can edit the English Wikipedia, there's no rule against it. --a gd fan (talk) 19:01, 9 December 2020 (UTC)

Proposal to enhance Template:Section sizes

There is a discussion about a proposal to improve Template:Section sizes going on at Template talk:Section sizes#Proposal for optional cumulative size column. Your feedback would be appreciated. Mathglot (talk) 08:27, 12 December 2020 (UTC)

Revenue plan: City governments subscribe to Wikipedia on behalf of residents

Ask readers of Wikipedia to sign a petition for their City to subscribe to Wikipedia. When sufficient signatures are gathered, present the petition to the City. A City subscription costs $10k/month? Or, $0.10/month per resident? — Preceding unsigned comment added by Keihatsu1 (talk • contribs)

Hi @Keihatsu1:, we are "owned" by a charitable organization, and want to give away the information on the project for free, to everyone. Any person or organization is welcome to make donations to us, but subscriptions are not necessary as we are free. — xaosflux ^Talk 05:30, 10 December 2020 (UTC)

Selling access to Wikipedia might reduce quality, by discouraging editors who prefer to donate time to improving a freely available resource rather than for one which someone else is collecting money. Certes (talk) 10:19, 10 December 2020 (UTC)

• The Foundation's financial situation is stable and there is no need to change how it gets funds. They are trying to build an endowment so that future donations are not as necessary. 331dot (talk) 10:38, 10 December 2020 (UTC)

  I'll note that it's donation time, and though we the editors may think the Foundation is in good financial shape, the tone of the appeals banners may give readers a different impression. Pelagic ( messages ) – (07:33 Mon 14, AEDT) 20:33, 13 December 2020 (UTC)

• An endowment is the best way to fund an organization like Wikipedia, since it has no strings to pull. I could see an argument that, since it is a public service, Wikipedia should be funded by governments worldwide the same way libraries are. That would create a giant opportunity for influence or censorship, though, so we would never go for it. {{u|Sdkb}} ^talk 19:31, 11 December 2020 (UTC)

Hide rollbacks from watch lists

Twice in the last oh couple months or so I have accidentally rolled back changes on my watch list due to mis-clicks. Both times I have tried to click on something fairly quickly, before all the scripts on the page have loaded. A similar thing with the late-loading scripts happened again today, but I just went to a separate article, and I almost just mis-clicked again, which is why I'm here in the first place. Is there currently a way to either hide the rollback on the watch page until you need to use it (by toggling it off/on), or to at least have a confirmation page come up before you commit a rollback from a watch page, and if not, would this be easy to implement? SportingFlyer T·C 23:12, 10 December 2020 (UTC)

Go to your preferences > Appearance; in the Advanced options, check Show a confirmation prompt when clicking on a rollback link. Enjoyer of World^(bother...) 23:37, 10 December 2020 (UTC)

Alternatively, there are instructions on how to remove the rollback button from your watchlist at Wikipedia:Customizing watchlists (check the section called "Remove or modify the [rollback] link"). Armadillopteryx 23:40, 10 December 2020 (UTC)

Fantastic. Thank you both for your help - I've sorted it! SportingFlyer T·C 01:15, 11 December 2020 (UTC)

• This problem is frequent enough that I wonder if we ought to start showing a confirmation dialogue before rollbacks by default. Are there editors who would be opposed to that?

The other major issue here is the jumps that occur because of how the page loads. The developers really need to find a fix for that, since it's incredibly annoying. {{u|Sdkb}} ^talk 19:33, 11 December 2020 (UTC)

If the jumps are due to images that load more slowly (and are likely pulled from a different server), one possible solution is to enclose the image in a box of the same size which will load first and occupy the page space, while the image loads whenever it loads, occupying the same size space and avoiding jumps. Mathglot (talk) 23:25, 12 December 2020 (UTC)

@Mathglot: I think it's often due to watchlist announcements or other banners. {{u|Sdkb}} ^talk 19:58, 13 December 2020 (UTC)

Same solution, unless I'm missing something. Mathglot (talk) 20:06, 13 December 2020 (UTC)

Since HTML 3.2 (January 1997), the <img /> element has provided the width= and height= attributes, which according to the HTML 5.2 spec allows the user agent to allocate space for the image before it is downloaded (the code example there is from our own main page of 18 June 2014). The MediaWiki software emits these attributes. --Redrose64 🌹 (talk) 21:52, 13 December 2020 (UTC)

Time to change fundamentals

First time here. Not sure if this is the right place to write this.

Wiki keeps asking for money. It is about time to monetize the site. It has been great all these years without ads but it is time for a change.

You are asking the wrong people for money. Ask the corps that are willing to pay and more importantly that have the means to pay.

Make the ads small and keep them at the top of the page or left hand side.

I examined your financials, with over $120M per year in operating budget and still cannot make ends meet? It is time someone in charge took a long hard look at what's really going on. Take a big step back and view it from a different perspective. Bring in some top financial tech consultants to help re-organize and restructure. It's time to cut costs, a lot of costs. I run a business and have had to make major changes twice over the last 20 years to save money and to survive.

It's doable in any sector and industry, especially tech. — Preceding unsigned comment added by JamesStape (talk • contribs) 22:35, 3 December 2020 (UTC)

Any company that wants to is free to mirror or fork Wikipedia and turn the fork into a commercial enterprise. If the WMF "went commercial," it's almost certain there would be a "hard fork" by a new non-profit and the major editors would abandon the WMF for the new organization. Or, to put it another way, "DO NOT WANT". davidwr/(talk)/(contribs) 00:25, 4 December 2020 (UTC)

Agreed. Wikipedia should not have ads. See: Wikipedia:Perennial proposals#Advertising Tony Tan · talk 09:41, 6 December 2020 (UTC)

Who said WMF can't make ends meet? My understanding is that they have a healthy financial buffer. RudolfRed (talk) 00:56, 4 December 2020 (UTC)

Well, with all the advertising the last few days to non-logged-in editors, I can see how one might get the impression that they were strapped for cash. davidwr/(talk)/(contribs) 01:37, 4 December 2020 (UTC)

They're not saying they are strapped for cash. They are saying they need the donations. Which they do, both to cover expenditure and to build the financial buffer even further. I think the long-term goal is to create an endowment. -- The Anome (talk) 01:41, 4 December 2020 (UTC)

Yes, that's the long-term goal. --Izno (talk) 01:57, 4 December 2020 (UTC)

Like the responsible boards at any soundly-run non-profit, the Wikimedia Foundation is trying to build up a solid endowment for the future. As we keep having to repeat every time this idea comes up, any effort to commercialize or otherwise degrade Wikipedia would be met with massive and effective resistance from the thousands of editors who make it work. We would down tools and walk away, pausing only to note the names of those who destroyed all our work in the name of a bogus "efficiency." --Orange Mike | Talk 02:50, 4 December 2020 (UTC)

I'm not sure a project like this could ever work (in today's time) as a commercial enterprise. Perhaps in the future when software - eg a more coherent GPT-3 - can generate this content automatically, but otherwise it's infeasible. There's minimal commercial interest in trying to create a neutral encyclopaedia that covers so many topics. Brittanica could not (and does not) come close to the sheer volume and breadth of content. Which means you can't hire enough writers, which means you need volunteers, and volunteers will (most likely) not spend their hours chugging away at a project for the sake of shareholder profit. These kinds of projects only work as mission-aligned projects, I think, rather than shareholder-aligned ones. The rebuttal to these thoughts is Baidu Baike, but a lazy defence would be that that's a different culture and its quality is perhaps varying. ProcrastinatingReader (talk) 08:01, 4 December 2020 (UTC)

This happens every year, the requests for donations mislead readers, we complain, WMF wave their hands and spout platitudes and do it again. Same old story.· · · Peter Southwood ^(talk): 19:56, 6 December 2020 (UTC)

At least the WMF has a title which clearly distinguishes it from Wikipedia. Certes (talk) 20:15, 6 December 2020 (UTC)

@Certes: The question is for how long. — Alexis Jazz (talk or ping me) 18:57, 7 December 2020 (UTC)

Indeed; hence my first userbox. When I first visited Wikipedia, I clicked Donate, naively expecting to give to Wikipedia. Instead it solicited money for something I didn't quite understand, so I decided to donate my time instead. I think it only fair that future donors be clear as to where any funds might go. Certes (talk) 19:18, 7 December 2020 (UTC)

Hi, James, thanks for your suggestion. There is a project underway to provide a premium access tier for the big consumers: please see meta:OKAPI.

Some other sites out there run MediaWiki software with advertising and do okay for themselves, e.g. Wikia. But I think in the free-encyclopedia niche, Wikipedia has become so dominant that it would be hard for any competitors to get a leg-up. (Unless W?F messes things so badly that there is a mass exodus.)

As to the questions about whether the Foundation is spending its money wisely, is running a lean and focused operation, or is pushing donation-appeal campaigns that reflect its standing and aim to become the world's "essential knowledge infrastructure", I'll leave those for another time. :)

— Pelagic ( messages ) – (09:54 Mon 14, AEDT) 22:54, 13 December 2020 (UTC)

Make links to disambiguation pages orange by default

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Should links to disambiguation pages be orange by default? --RexxS (talk) 16:33, 23 November 2020 (UTC)

In the Special:Preferences#mw-prefsection-gadgets 'Appearance' section, there is an option to Display links to disambiguation pages in orange. I've found this very useful, and at a recent virtual UK meetup, it was suggested that it ought to be made the default option. I do not believe that there is any technical obstacle to doing that.

Please indicate your support or opposition for the proposal. I've created a separate discussion section to avoid fragmentation of debate within the other sections. --RexxS (talk) 16:33, 23 November 2020 (UTC)

Notified: WikiProject Usability. {{u|Sdkb}} ^talk 17:27, 23 November 2020 (UTC)

Notified: WikiProject Disambiguation. — Rod ^talk 17:36, 23 November 2020 (UTC)

Notified: MediaWiki talk:Gadget-DisambiguationLinks.css. —⁠andrybak (talk) 18:47, 23 November 2020 (UTC)

Notified: Template:Centralized discussion. –MJL ‐Talk‐^☖ 17:45, 28 November 2020 (UTC)

Support (orange dab links)

• Support as proposer. --RexxS (talk) 16:33, 23 November 2020 (UTC)
• Qualified support. I can't support this as a general change, as I think it would confuse the hell out of readers for the least useful links to be the ones given increased prominence. If the proposal is just to make this change for logged-in editors it's not a bad idea. (In an ideal world, anyone trying to add a link to a dab page would trigger a "do you really want to do that?" alert when they press "Publish changes", but that would probably cause too much server load.) ‑ Iridescent 16:54, 23 November 2020 (UTC)
  (adding) If this does go live, it needs to be prominently written into policy that sometimes those links to dab pages are there deliberately and trying to "fix" them inappropriately is a fast-track to getting blocked for disruption; I can easily foresee people in good faith assuming that they're being highlighted because they're errors that need fixing, leading to the same kind of unpleasantness we see when people try in good faith to "fix" redirects inappropriately. ‑ Iridescent 17:00, 23 November 2020 (UTC)

  There are some non-editing readers who log in so they can set preferences of various sorts. If this is something that we want for editors but isn't good for readers, enabling it for those logged in isn't a good solution. {{u|Sdkb}} ^talk 17:24, 23 November 2020 (UTC)

  Sdkb, if such readers have created an account specifically to adjust preferences, surely they will be more than able to turn off the gadget if it bothers them? —⁠andrybak (talk) 18:31, 23 November 2020 (UTC)

  Can ≠ will. We're talking about very casual users who may have an account only so that they'll be greeted by name on mobile, who are very unlikely to spend the time digging through the maze of our preferences menu to make sure the defaults align perfectly with what they want. {{u|Sdkb}} ^talk 18:56, 23 November 2020 (UTC)

• Support this would be very useful as it may reduce the 500-800 links to dab pages which are created each day (helping those which try to patrol and fix these) and mean that readers are more likely to get to the relevant article when they click on an internal wikilink.— Rod ^talk 17:01, 23 November 2020 (UTC)
• First, thanks to RexxS, I didn't know that option existed, and now I have that option enabled. If this is a default option that can be turned off, and if it is for logged-in editors only, then unequivocal support. If it's intended to happen for casual readers too, and/or if it can't be turned off without javascript, then I think I still support, but much less enthusiastically. Right now we give maximum prominence to articles that don't even exist, so I'm not too worried about that. And those few editors who have an account but never edit shouldn't be so distracted that this would be a net bad thing, especially if it can be turned off. --Floquenbeam (talk) 17:45, 23 November 2020 (UTC)
• Qualified support only for logged in editors as per Iridescent. Incidentally, this is the way it is implemented on Russian Wikipedia—logged in users see pink background for dab links by default. Example: ru:Анна#См. также. —⁠andrybak (talk) 18:19, 23 November 2020 (UTC)
• Support — it's super effective.   ~ Tom.Reding (talk ⋅dgaf)  19:15, 23 November 2020 (UTC)
• Qualified support in principle for editors but not readers. There are a few details to iron out. Is "logged in" a good enough proxy for "editing, not just reading"? Don't forget redirects to dabs, and consider how to handle INTDABs to pages (and via redirects) called "X (disambiguation)". Certes (talk) 19:19, 23 November 2020 (UTC)
• Support as a default for registered editors. Things people link, obviously without checking, boggle my mind sometimes. BD2412 T 02:25, 24 November 2020 (UTC)
• Qualified support per Iri for logged-in eds. Is there some sort of "sic" template for deliberate links to disam pages, which I do sometimes? If not there should be. Johnbod (talk) 03:15, 24 November 2020 (UTC)

  Yes: intentional links to dab X go via an "X (disambiguation)" redirect: see WP:INTDAB. Certes (talk) 14:32, 24 November 2020 (UTC)

• Qualified support for preview mode, to get the attention of an editor added a link without checking where it goes. MB 04:36, 24 November 2020 (UTC)
• Support per nomination. Blue links are sprinkled throughout articles, but the occasionally found red links provide no useful click. Under this proposal, orange links, which would probably be less common than red links, may not be as useful as blue links, but still have the potential of helping users find the desired entry on the disambiguation page and do so not through commingling with the actual blue links, but by differentiating themselves from them. —Roman Spinner (talk • contribs) 01:03, 25 November 2020 (UTC)
• Support for Change. If this proposal succeeds I believe it was hasten the need for a redesign of the disambiguation block. I actually think that these should be special blocks that don't require leaving the page, but offer a full preview on non-touch device hovers. It will get people thinking about the disambiguation problems; why so many pages lack them, how main pages are chosen, etc. They should be treated more as features of navigating an ambiguous language, and offer tooling. If a color is the first attempt at that, okay. Hopefully the Visual Editor's link suggestion system would also display these in orange, avoiding unintended links. Louis Waweru  Talk  08:40, 1 December 2020 (UTC)
• Support for editors. It seems useful, and anyone that doesn't like it can easily turn it off. Thanks. Mike Peel (talk) 11:13, 6 December 2020 (UTC)
• Qualified support for logged-in editors, in an accessible color. The color should probably be changed to an accessible color in any event. Ditto for green redirects. Levivich ^harass/_hound 07:38, 8 December 2020 (UTC)
• Support for editors. I'm using it for several months now and it's awesome. Quickly tells me if i did something wrong in wikilinking. Regards, Jeromi Mikhael ^(marhata) 07:26, 11 December 2020 (UTC)
• Support for editors. CRS-20 (talk) 02:59, 15 December 2020 (UTC)

Oppose (orange dab links)

• Oppose per WP:READER. If everything is working as it should, disambiguation links should show up only on disambiguation pages and in places like hatnotes. Those places are already sufficiently marked, so they don't need a different color. Doing this because of the existence of inappropriate dab links in the middle of articles is harming readers for the sake of editors, which we should never do. {{u|Sdkb}} ^talk 17:24, 23 November 2020 (UTC)
• Oppose I was going to say I support this proposal, but Sdkb has a good point. Readers first. Maybe a better idea is to make dab links orange automatically when previewing unsubmitted revisions regardless of the setting. That way editors can see clearly when their revisions would inadvertently add dab links without unnecessarily making it hard on readers who happen to be logged in. Come to think of it, in revision previews, why not make dab links flash neon pink and issue an audible alert that says, "Oh, the humanity", or some such.Coastside (talk) 00:49, 24 November 2020 (UTC)
  • If we can turn off the audio for public libraries, this has possibilities ... davidwr/(talk)/(contribs) 00:52, 24 November 2020 (UTC)
• Oppose. As Iridescent points out above, this will make things worse for WP:READERS, and I'm not even convinced it'll help editors. Warning editors about linking to DAB pages seems like something the various editing clients should be doing, not imposing U/I changes on readers. See also angry fruit salad. -- RoySmith (talk) 18:23, 23 November 2020 (UTC)
• Oppose Making this default. Those who want the feature can turn it on already. RudolfRed (talk) 01:00, 24 November 2020 (UTC)
• opposed zero benefit for our readers but distraction. Someone should fix WP:READERS as it has zero info on what's best for readers...odd link to link to.--Moxy 🍁 01:07, 24 November 2020 (UTC)

  I agree that much of the essay is outdated, but the {{nutshell}} note is the part worth reading. -- RoySmith (talk) 02:03, 24 November 2020 (UTC)

• Oppose If readers/editors enable it, they know what the orange means. If it's default, they won't know why it's orange instead of blue like other links. Schazjmd (talk) 01:19, 24 November 2020 (UTC)
• Oppose - makes articles harder to read for no useful reason. Article prose should be rendered as simply as possible. Black text, or blue for text that links to more information, are all the colours readers need. There are already several tools available for editors to enable visibility for disambiguation links (and many other kinds of links: redirects, crosswiki links, pages nominated for deletion, circular links, on and on and on). Keep it simple for readers. Ivanvector (^Talk/_Edits) 01:44, 24 November 2020 (UTC)
• Fundamentally per Schazjmd. The idea that orange should signify a special unwanted link is a user experience fail. Also per Ivanvector. --Izno (talk) 18:06, 24 November 2020 (UTC)
• Oppose per Ivanvector. Paul August ☎ 01:23, 25 November 2020 (UTC)
• Oppose per Roy and Ivan. ProcrastinatingReader (talk) 10:40, 26 November 2020 (UTC)
• Oppose per sake of consistency. Surely most readers of Wikipedia know what a blue wikilink means, and making links to disambiguation links orange would only confuse readers. Vorbee (talk) 12:27, 26 November 2020 (UTC)
• Oppose shifting the experience of logged-in editors from readers by default. I use the orange DAB links, and I absolutely would have loved having them earlier. But the solution is to better document and guide newly-registered users to the preferences, not foist them on without notice. I would love to see something like a utility for enabling the dozen or so most used gadgets included in our welcome templates. But a newly-registered user shouldn't see a different site when they first set up their account without something first telling them about those changes. VanIsaac_WS^cont 13:49, 26 November 2020 (UTC)

  That would be an excellent improvement. You should consider proposing it today at the CommTech wishlist on meta. --Izno (talk) 15:53, 26 November 2020 (UTC)

  Agreed. I apparently missed this prior to suggesting something similar below; this is an even better option. CThomas³ (talk) 23:20, 1 December 2020 (UTC)

• Oppose Links should be blue and Wikipedia should not be messing with basic standards and expectations. Plus, dab pages should not be linked from articles. And elsewhere, they are clearly named. For editors, there are multiple ways and scripts to do this. —  HELLKNOWZ   ▎TALK 15:13, 26 November 2020 (UTC)

  Even if we exclude the "you may be looking for…" hatnotes, there are numerous legitimate reasons to intentionally link a dab page from an article. ("Crucifixion was a common topic of medieval European paintings".) There are a lot of valid arguments against this proposal, but "we should remove the links instead" isn't one of them. ‑ Iridescent 09:12, 1 December 2020 (UTC)

  WP:INTDAB lists reasons to intentionally link a dab page. Our convention is that such links go via the X (disambiguation) redirect, so we can disregard them when finding and fixing accidental links to dabs such as a compound of mercury. Certes (talk) 11:30, 1 December 2020 (UTC)

• We should not be using color to uniquely present information because it is reduces accessibility for colorblind users. Not everyone can distinguish orange and blue. It is also a jarring and intrusive change--not only is it pretty useless for readers, the few times dab links show up would probably result in confusion. Editors can color links however they like. Personally I use CSS to color stub links purple (between a blue and red link). — Wug·a·po·des​ 04:57, 28 November 2020 (UTC)
• Strong oppose in read mode makes it worse for our readers. If editors want this feature, they can easily turn it on. I personally don't want it in edit mode but don't feel strongly about it, if I can turn it off. (t · c) buidhe 17:51, 28 November 2020 (UTC)
• Oppose making it the default, but def. needs to be made more public, incase anyone whichs to switch it on. Lugnuts ^{Fire Walk with Me} 17:52, 28 November 2020 (UTC)
• Oppose after trying this option (which I had not heard of) for a few days, I agree that it doesn't help readers to have it on. power~enwiki (π, ν) 18:31, 28 November 2020 (UTC)
• Oppose. I was planning to support for logged-in users only, but Vanisaac and Wugapodes convinced me otherwise. KevinL (aka L235 · t · c) 01:08, 29 November 2020 (UTC)
• Oppose - Great for editors, bad for readers to have another learning curve. Also, might be confused with a redlink thereby keeping readers from content we have that may be helpful to them because they may think it does not exist etc. Active links should appear as they always have here and in the traditional color of the world wide web. I also oppose this as a default for registered accounts (i.e. it should be opt-in; something one can turn on once they have learned about it).— Godsy ^(TALK_CONT) 06:36, 29 November 2020 (UTC)
• Oppose. The reading experience must come first. Otoh, this is a potentially very useful gadget for editors, which I have just enabled; perhaps the dablink bot reports could inform editors of its existence? Espresso Addict (talk) 15:38, 29 November 2020 (UTC)
• Absolutely not, per all of the above. A worse experience as a reader, a hard break from every web standard, and would only help the minority of folks who wish to work on DAB pages. ~ Amory (u • t • c) 02:24, 30 November 2020 (UTC)
• Oppose simply not a good reader (or editor) experience. -FASTILY 01:18, 1 December 2020 (UTC)
• Oppose for readers as a change which will only cause confusion (blue links and red links are enough). Oppose for editors because I actually don't think editors should be warned before linking to DAB pages by default. It's just another barrier to casual editors who fix typos here and there or new editors who get started with IP edits ("what have I done this time... first this weird 'Citation Style 1' error and now the link isn't the right colour. Oh, I give up"). I like the DPL bot that gives you talk page messages and I support more long-term editors knowing about the preference (just enabled it myself!) so they can avoid this mistake. — Bilorv (talk) 01:26, 1 December 2020 (UTC)
• Oppose I already use a tool which shows dab links in yellow, not orange. I associate orange with the "you have new messages" prompt, which is a more standard feature of the interface. Andrew🐉(talk) 09:37, 1 December 2020 (UTC)
• Oppose Please don't make me guess if red is orange and orange is red. It's a good option and can be used by power editors, though I'd prefer the pink box, which is less obtrusive. SportingFlyer T·C 17:07, 1 December 2020 (UTC)
• Oppose Completely agree that we should not be confusing our readers by introducing what will appear to them as randomly colored links. Even for logged-in users, I would avoid making this the default. I happen to have this gadget enabled and I am a fan, but I did so purposefully and intentionally and therefore I know what the orange color means. Equally importantly, I also know how to turn it off if I ever decide I want to. If we don't already have one, I would suggest that a better option for new users would be a how-to guide for some of the more helpful UI customizations; perhaps we could even add a link to it on our standard welcome templates. Not only would this help them find this particular gadget, but it would also teach them that the interface is customizable in all sorts of ways. CThomas³ (talk) 23:14, 1 December 2020 (UTC)
• Not useful for readers. feminist (talk) | free Hong Kong 03:24, 2 December 2020 (UTC)
• Oppose. An option in preference is enough. It's a distraction for readers (including editors) who don't even want to click any link while reading. Enjoyer of World^{(bother me...)} 22:02, 2 December 2020 (UTC)
• Oppose What about people with colour blindness? The Banner talk 16:52, 3 December 2020 (UTC) I would prefer a non-obtrusive background to highlight the issue.

  User:Anomie/linkclassifier uses yellow backgrounds by default. That leaves foreground colours for other use, e.g. redirects appear in green. Certes (talk) 16:17, 6 December 2020 (UTC)

• Oppose Not useful for readers. If there's a problem, mark with . We already have bots that do that I believe. If not, then a bot should be made. Headbomb {t · c · p · b} 17:12, 3 December 2020 (UTC)
• Oppose Out of the question for readers, for whom this would be unhelpful and extremely confusing. Many casual editors would experience the same, so it should be simply kept as an option. — Goszei (talk) 10:51, 6 December 2020 (UTC)
• O. Good for advanced editing, bad for new account owners. Wouldn't be opposed to making it easier to turn on rather than having to dig thru preferences, but meh. Rgrds. --Bison X (talk) 08:13, 7 December 2020 (UTC)
• Oppose. Orange-linking does nothing useful for readers and is apt to confuse them. Regular editors who may have use of this distinguishing coloration for maintenance purposes already have this option available in their site preferences. Editors who insist on remaining anonymous IPs are already missing out on a lot of other more important functionality than this, and they can use user-side JS/CSS stuff to do the same thing if they really want it (e.g. with GreaseMonkey scripts).  — SMcCandlish ☏ ¢ 😼  03:47, 8 December 2020 (UTC)
• Oppose. First; the shade of the orange color is painfully bright. Second; say you want to open a link to another tab manually-- when you hold it the link turns to orange, exactly like the shade-- this may create confusion for some, maybe they may think their lap's bugging or something. Third; don't find blue disambiguation links to be a problem in distinguishing actual articles with non-article pages; after all, many sites have blue as the default for link colors-- if we have to, we must change redirect, category, essay, guideline, MoS, file, main page, and talk pages to orange or another distinguishing shade. GeraldWL (Pine wish!) 07:48, 11 December 2020 (UTC)
• Oppose I don't think it would be particularly helpful for readers. The colour is very striking and for a user logged in who doesn't edit often, such a thing would stand out for seemingly no reason. If such colouring is added there needs to be a way to explain what it means in a easy to understand way. Just enabling the colour will cause confusion. Dreamy Jazz ^{talk to me | my contributions} 13:19, 11 December 2020 (UTC)

Discussion (orange dab links)

• If we're talking about changing the color of some links, there are some I think it would be good to put in a different color. The main one that comes to mind is links from reader-facing spaces to non-reader facing spaces (e.g. WP-space). However, we don't currently categorize that distinction well enough to implement something of the sort. {{u|Sdkb}} ^talk 17:31, 23 November 2020 (UTC)

  Current implementation uses orange foreground color. For comparison, Russian Wikipedia uses a pale pink background for dab links and only in the article namespace. CSS can be seen at ru:MediaWiki:Gadget-disambiguationLinks.css. —⁠andrybak (talk) 18:40, 23 November 2020 (UTC)

  In my experience, the pale pink background doesn't even slow Russian editors down from making links to DAB pages, and may not even encourage correction by other editors. I've seen enough of them. Narky Blert (talk) 21:01, 1 December 2020 (UTC)

  Orange seems a good choice. It's part way to red, like an amber traffic light. Red means stop: don't bother clicking here unless you want to create an article. Orange means warning: this link may not lead where you hoped it would. Certes (talk) 01:29, 24 November 2020 (UTC)

• Does this proposal raise any accessibility issues for partially sighted readers? If someone can't tell blue from orange then they've lost nothing (all links still appear bluorange), but if they have difficulty distinguishing orange from a white background (or whatever a future skin uses) then we may be causing problems. Certes (talk) 01:16, 24 November 2020 (UTC)
• Note: User:Anomie/linkclassifier uses yellow backgrounds by default, with a lighter yellow background for WP:INTDABs. —pythoncoder (talk | contribs) 17:51, 24 November 2020 (UTC)

  I use linkclassifier because it also shows redirects in green, which I find useful for bypassing them in navboxes, identifying duplicate See alsos, etc. I hope that it will continue to work after any changes resulting from this proposal. Certes (talk) 13:04, 26 November 2020 (UTC)

• As a lot of people are objecting to the introduction of another colour to signify to editors that they are linking to a dab page, would it be possible to have an alert (or pop up not sure of correct term) on preview or publish, letting the editor know they are linking to the dab page - in a similar way to the pop up giving an alert when trying to use a source on the blacklist as a citation?— Rod ^talk 15:24, 26 November 2020 (UTC)

  That would be a better solution if possible. It may be a suitable topic for the Community Wishlist Survey 2021. It would probably be too complex for an edit filter, but you could ask. Certes (talk) 15:46, 26 November 2020 (UTC)

  This was proposed, and rejected, back in 2016. – Uanfala (talk) 20:17, 8 December 2020 (UTC)

  Yair rand mentioned a solution for reducing complexity: require the pages to end in (disambiguation). If this were the case the alert check would be a one-liner. Louis Waweru  Talk  09:36, 1 December 2020 (UTC)

  Not quite. The base name would then hold a redirect to the dab (rather than the dab itself), so we would still need to check for bad links to it. Certes (talk) 11:32, 1 December 2020 (UTC)

  I second this. If anyone creates a wishlist item, please link to it here! {{u|Sdkb}} ^talk 22:29, 27 November 2020 (UTC)

• See Community Wishlist Survey 2021/Editing/Warn when linking to disambiguation pages but I'm not sure I have written it properly & it has not attracted much attention.— Rod ^talk 11:41, 1 December 2020 (UTC)

Tracked in Phabricator
Task T268855

Items that attract attention at the proposal stage are generally the ones that are problematic in some way. They may be unnecessary because of a feature the proposer didn't know about or the idea needs to be better fleshed out. If your proposal doesn't attract any comments, it means you wrote it up clearly and there isn't an alternate solution to the issue. VanIsaac_WS^cont 12:46, 1 December 2020 (UTC)

• Another idea: Stop disambiguation pages from showing up first on the suggestions when adding a link in VisualEditor. If it's between "Foo" (a disambiguation page) and "Foo (bar)", the suggestions should put the actual content-carrying pages first. I feel like this would reduce the number of disambiguation links by a fair amount. --Yair rand (talk) 23:03, 26 November 2020 (UTC)

  It would be much simpler for editors AND readers if all disambiguation pages had (disambiguation) in the title. Schazjmd (talk) 23:06, 26 November 2020 (UTC)

  Yes and no. If we moved Mercury to Mercury (disambiguation), Mercury would redirect to Mercury (disambiguation) and still attract bad links from editors who assume the planet/element/deity is the primary topic. Certes (talk) 23:24, 26 November 2020 (UTC)

  This sounds good as well. I'm not sure how difficult it would be technically. {{u|Sdkb}} ^talk 23:58, 30 November 2020 (UTC)

  Just wanted to chime in that I see a need for more disambiguation links rather than less. Every eligible page should have one, IMO. Having the disambig suggestion at the top is nice for predictability, in that the user doesn't have to scan the first suggestion if it's likely to be a disambiguation. Content carrying pages aren't indicative of what the user wants to link to, and on content-starved word groups, the disambig page may be the overweight page. I think a need for change shows again here; if it is understood that disambiguation pages are special, and orange, there should be less user error. Having them end in (disambiguation) would help too, new tooling can easily double-check or confirm intention to link to a (disambiguation) page, something I guess is a rare action in substantive new content creation. Louis Waweru  Talk  09:31, 1 December 2020 (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.

Simplify links to redirects

This is an extremely minor suggestion for a bot.

Let's say there's a link: [[Page name|Text of link]]

The bot would do the following:

1. If the (Page name) redirects to (Another page name) then (Page name) is replaced with (Another page)
2. If the (Page name) redirects to (Text of link) then the code becomes: [[Text of link]]

Maybe not #1, because of, say, "apple" changing in: [[Apple|Apples]], but #2 seems good.  AltoStev ^Talk 00:02, 19 December 2020 (UTC)

I've had another idea where when moving a page it auto-changes all the links.
Also I forgot to include when [[Page Name 1]] redirects to [[Page Name 2]] although that's even more disastrous because it changes the text itself.  AltoStev ^Talk 00:08, 19 December 2020 (UTC)

Redirects are WP:NOTBROKEN and don't need fixing in this way. --Izno (talk) 00:29, 19 December 2020 (UTC)

• I think WP:GENFIX might already include #2; if not, feel free to propose it at the GENFIX talk. Agreed with Izno #1 is not needed. {{u|Sdkb}} ^talk 00:32, 19 December 2020 (UTC)