Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
 Policy Technical Proposals Idea lab WMF Miscellaneous 

New proposals are discussed here. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174

Succession boxes for US Presidents[edit]

Following on from the discussion started here:

Talk:Donald Trump#What happened to the succession boxes?

How does the community feel about succession boxes and their inclusion in the articles about US Presidents specifically? The following three options were presented on the talk page above:

  1. The succession boxes should be included in all U.S. presidents' BLPs.
  2. The succession boxes should be omitted from all U.S. presidents' BLPs.
  3. One size does not fit all. Cross-article consistency is less important than flexibility. Decide on a case-by-case basis at article level.

06:39, 13 November 2020 (UTC)

  • 2 - The information therein is somewhat redundant with the Preceded by and Succeeded by fields of {{Infobox officeholder}}, while far less visible and accessible being at the bottom of the article. What little anecdotal evidence we have (from editors who used to be only readers) suggests that readers rarely or never use the succession boxes. At Donald Trump, the boxes were removed after brief discussion in December 2018, and the only arguments in opposition to that have been that U.S. presidents' BLPs must be consistent. No one has even attempted to make the case that the boxes actually benefit readers enough to justify the space required, and I feel that would be a very difficult case to make. Ok, so let's make U.S. presidents' BLPs consistent. ―Mandruss  09:26, 1 September 2020 (UTC)
  • 2 - succession boxes are such an outdated navigation tool on en.wiki. We have as Mandruss pointed above, the relevant fields in the infobox, but also navigation templates such as {{US Presidents}} which already show the entire list. Succession boxes just add clutter as they are much more larger and offer no additional value. --Gonnym (talk) 10:28, 1 September 2020 (UTC)
  • 1 or 2 - but this should include all the US presidential & vice presidential nominees bios. GoodDay (talk) 14:16, 1 September 2020 (UTC)
  • 2 seem pretty redundant/useless now. We show the same information in better ways in articles. Showing succession for the Nobel Peace Prize (ref Obama) is not helpful. Succession for major office posts is already shown in infobox. I support broader removal from all such articles. Also noting that cobaltcigs's mockup below is a significant improvement, and in any case the boxes should be updated to that if kept. ProcrastinatingReader (talk) 13:50, 6 September 2020 (UTC)
  • 2 I think succession boxes in general have had their day. The infobox is much more useful, because it puts the short summary of the individaul write at the top of the article. If an individaul has a lot of offices that wouldd make the infobox too long, it's always possible to put some of the offices in a collapsed format, as is done with the infobox for John A. Macdonald. --Mr Serjeant Buzfuz (talk) 17:32, 7 September 2020 (UTC)
  • 1 – Succession boxes remain useful for cases where the inclusion of an office in the infobox of a given article wouldn't meet MOS:INFOBOXPURPOSE. For example, in the Canadian context, it's not uncommon for there to be "secondary" ministerial titles that are typically held alongside a more significant portfolio, such as Minister responsible for La Francophonie. Despite being a significant office, it simply wouldn't be important enough to include in the infobox in most cases. 207.161.86.162 (talk) 05:38, 15 September 2020 (UTC)
  • 1 Not sure where you're getting "anecdotal evidence" from. I use them all the time for navigation. Perhaps among the most useful things on a page, particularly if a person has held multiple offices or secondary titles over their lifetime. The infobox at the top is not always the clearest nor complete, and sometimes troublesome to scroll all the way back up there if you're already at the bottom. Walrasiad (talk) 07:41, 17 September 2020 (UTC)
  • 1 I've found them very useful for navigating articles. PaleAqua (talk) 18:08, 5 October 2020 (UTC)
  • 1 MOS:INFOBOXPURPOSE is fundamentally at odds with relying on infoboxes to be a complete record of succession in offices. In the case of Trump, there's no real conflict; he's held one major political office, and it's the most relevant thing in his career, so it goes in the infobox. That's not the case for many political figures; in the UK, chronicling someone's ascent through a series of junior ministerial posts might require bloating the infobox to an enormous extent at the expense of highlighting what's most important. (Winston Churchill is an excellent example of why collapsible infoboxes don't solve this: it's impossible from the current arrangement to infer which offices besides PM were most salient to his career, probably Chancellor and Admiralty.) The more visible your navigation element, the more judicious you need to be about what you put in it; succession boxes have always been at the bottom of the article so that they can be more complete than infoboxes without getting in the way of a quick skim. If we're going to delete anything, it should be cruft like {{US Presidents}}. Salience is built into succession boxes: the actions, policies, and careers of an individual's predecessor and successor are necessarily of greater relevance than most or all of those further removed. (Or to put it more simply, it's logical to want to navigate from Obama to GW Bush or to Trump; there's no real case for wanting a "convenient" mechanism to jump from Obama to Tyler or Benjamin Harrison or Buchanan.) The idea that showing the "entire list" adds "more value" is the same fallacy you see in amateur GUI design, where jamming more buttons into the toolbar or more options onto the menu is uncritically regarded as an improvement. I do agree that there are some things crammed into succession boxes that don't fit the model of a single office more or less continuously occupied by different people—I would fully support removal of Nobel Prize succession, as ProcrastinatingReader suggests. Anecdotally, I've put a certain amount of time into installing succession boxes over the years because I *do* find them useful as a reader—this was something I wanted even as a kid reading paper encyclopedias! I find scanning through tiny, irregularly-laid-out text in big infoboxes less easy to navigate than dropping to the bottom of the article and consulting a succession box. Choess (talk) 14:45, 13 November 2020 (UTC)
  • 1 Succession boxes have a function. The information in the succession boxes should not be moved to the infobox, which serves a different purpose with minor overlap (MOS:INFOBOXPURPOSE). The formatting of the succession boxes might be improved. Johannes Schade (talk) 10:01, 14 November 2020 (UTC)
  • 2 Never seen the point of succession boxes, and they often duplicate footer templates that are more effective navigation tools (in this example, {{US Presidents}} which includes the dates of office for each president). Number 57 12:26, 21 November 2020 (UTC)
    Winston Churchill is a mobile view scrolling accessibility nightmare.... it has been used as an example of what not to do by thoses who oppose any infobox. --Moxy 🍁 14:47, 21 November 2020 (UTC)
    Regarding the issue of duplication, what about the case of offices that don't and shouldn't have navboxes (like "secondary" ministerial titles such as the Canadian Minister responsible for Official Languages, as I mentioned above)? 207.161.86.162 (talk) 01:51, 22 November 2020 (UTC)
  • 1 -- Succession boxes fulfil a useful function in facilitating navigation between successive holders of the same office. They appear near the end of an article, which should avoid them causing difficulty for mobile users. The mistake is having the same information repeated in infoboxes. The inclusion there of predecessor, successor, superior (monarch, government, etc.) seems unnecessary in a place intended to provide a brief outline: office held and dates should be enough there. Those who want more than then refer to the succession box. Peterkingiron (talk) 16:47, 22 November 2020 (UTC)

Flatten your succession boxes and/or abs[edit]

So I've suggested this before but here is my initial visual mock-up. What we know today as "succession boxes" should be flattened out to look roughly like this:

Ideally the template would also read each row's data (names, order, dates, annotations, whatever) by looking up {{PAGENAME}} on centralized lists (titled e.g. Module:Succession/President of the United States) and format the lookup results accordingly. So the calling syntax might be reduced to something like this (with various shorthand abbreviations allowed):

{{succession navbox|Illinois Senate|United States Senate|President of the United States}}

Unrecognized positions such as Community Organizer (Chicago) would be ignored and impossible for noobs to casually add. Such a system would greatly reduce screen waste, allow tighter control over accuracy, and protect against the random crap that existing succession boxes universally attract. I could probably create it within a few days, if there is interest. ―cobaltcigs 12:11, 1 September 2020 (UTC)

Considering that the existing boxes are collapsed, I don't think this is really relevant to this discussion (and it feels like a bit of a distracting hijack, to be honest). From what I've seen, the arguments against the boxes are not that they occupy too much screen real estate when temporarily expanded by a reader. There is no reason to believe that this would be more needed or used than the existing boxes. ―Mandruss  12:38, 1 September 2020 (UTC) (Strike after subsequent discussion.) ―Mandruss  13:35, 1 September 2020 (UTC)
Perhaps User:Gonnym would clarify Succession boxes just add clutter as they are much more larger in light of the fact that they are collapsed, but my reference to the space required was about other types of space: File size, post-expand include size, space in the edit window, and even the screen space required for the collapse bar. If the boxes are rarely used, even those relatively minor things are unjustified. Massive unnecessary clutter is usually a gradual accumulation of relatively minor things just like this – "hey, one more collapse bar won't hurt" – and we can only address them one at a time. ―Mandruss  13:03, 1 September 2020 (UTC)
A template shouldn't be huge even when expended if it doesn't need to. Compare the size of the succession section (Offices and distinctions) to Template:Barack Obama. Look at how much link data the navbox has compared to the succession one and yet the succession one is much larger and duplicates information presented elsewhere in the article, including right next to it with {{US Presidents}}. --Gonnym (talk) 13:17, 1 September 2020 (UTC)
@Gonnym: In that case, cobaltcigs's proposal would appear to address at least some of your concerns. Would you support it as a solution, then? ―Mandruss  13:23, 1 September 2020 (UTC)
No, not really. It is better than the current succession templates, but it's still not needed as it's still duplicating data right next to it. Using the above example, it's duplicating {{US Presidents}} and {{United States senators from Illinois}} with the 13th District seat seemingly not being important enough to warrant a navigation template. And again, all 3 are the first pieces of information right after his image in the infobox. --Gonnym (talk) 13:30, 1 September 2020 (UTC)
Fair enough - I am still learning the ropes here. ScottishNardualElf (talk) 22:25, 1 September 2020 (UTC)
@ScottishNardualElf: You might get more attention on this topic, if you make this discussion an RFC. GoodDay (talk) 15:33, 3 September 2020 (UTC)

So this proposal was actually intended as a compromise between the status quo and my (unpopular, I thought) personal opinion that totally getting rid of succession boxes would be better. Support for the latter seems higher than predicted, which is good. As long as we whack the {{portal bar}}s next. ―cobaltcigs 22:18, 10 September 2020 (UTC)

@Cobaltcigs: If you support option 2, feel free to indicate same in the preceding section, for clarity. ―Mandruss  15:14, 11 September 2020 (UTC)
  • I think the idea of flattenning the boxes is the best idea--and possibly not just for US presidents but in general. They're a rather primitive visual element, reminiscent of the earliest years of html. The basic information they give is useful--the prominence in the appearance of the article dadds nothing to that. DGG ( talk ) 00:55, 19 September 2020 (UTC)
  • Broadly support flattening but the sample doesn't work well without some kind of separator in a wide window (and particularly as the number of offices rises). If the middle column could be made relatively narrow, and the left and right columns were right and left aligned respectively it would keep things visually connected ~Hydronium~Hydroxide~(Talk)~ 02:28, 19 September 2020 (UTC)
I would like to see how, using such a list, you could handle the succession box for Grover Cleveland. 109.186.211.111 (talk) 01:13, 16 November 2020 (UTC)
Cleveland's political career is not especially complex, I assume it would go Sheriff of Erie County → Mayor of Buffalo → Governor of New York → President of the United States → President of the United States (Keeping his two terms as President separate.) Even for someone like Henry Clay, who bounced between the House and Senate with astonishing frequency, would be fairly simple, if not rather long.
  • No objection -- I approach this issue from the point of view of UK, where there are successions other than of offices held. Someone who had a long and varied career may indeed have a long succession box, but a shorter format would be acceptable, if this change can be made by some automatic means. However the issue is complicated by the existence of a "with" field, which applies to UK MPs before 1832 and to US senators (since each state elects 2).

Expansion of scope: succession boxes[edit]

This question should be expanded to include all the US presidential & vice presidential candidate bios. GoodDay (talk) 14:13, 1 September 2020 (UTC)

Sure, but why stop there? What about use of the same boxes in the BLPs for other U.S. officeholders? What about non-U.S. officeholders? If you're expanding scope at all, the only logical place to stop expanding would be to include all uses of the boxes anywhere in the encyclopedia. That's a far larger question, and before you know it you have a months-long discussion, very possibly all wasted time due to a no-consensus outcome. I say we can take this on in smaller pieces without undue harm to the encyclopedia, but any consensus here would be a factor in future discussions about other pieces. If we reach a consensus for option 1, there probably won't be any future discussions anyway. ―Mandruss  14:44, 1 September 2020 (UTC)
It wasn't my decision to delete the succession boxes at Donald Trump, thus putting that article out-of-sync with the others. GoodDay (talk) 15:38, 1 September 2020 (UTC)
That again??! You're right, it wasn't your decision. It was a local consensus not precluded by a community consensus, as explained to you more than once. The cross-article consistency factor was argued, and it was not enough to sway consensus toward keep. Please cease making me keep explaining to you how Wikipedia works, you have been around far too long for that. You are becoming disruptive. ―Mandruss  15:49, 1 September 2020 (UTC)
I'm not interested in getting into personal insults with you, so let's not go down that path. GoodDay (talk) 16:13, 1 September 2020 (UTC)
  • I think candidates and certainly spouses should not have succ-boxes. In any event, failed political candidates are generally NN, unless for other reasons. Presidential candidates usually hold some other office (or have done) so that this does not apply to them. Peterkingiron (talk) 16:47, 22 November 2020 (UTC)

Presidential & Vice Presidential candidate spouses[edit]

Note: Presidential candidate & Vice Presidential candidate spouses should be deleted from such bios. GoodDay (talk) 17:46, 14 November 2020 (UTC)

Update - I've deleted as many of them, as I could find. GoodDay (talk) 19:08, 23 November 2020 (UTC)

Redesigning the good article and featured article topicons[edit]

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[edit]

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 (talkcontribs) 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. Jr8825Talk 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 TalkMy 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[edit]

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[edit]

  • 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)

Cosmetic Bot Day (CBD)[edit]

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.
I'm somewhat surprised to find that rough consensus exists for a trial of Cosmetic Bot Day. I'm not surprised at all to see that there are a number of very grave and serious concerns about the proposal. I think we need to respect those concerns and be as cautious and conservative as possible, which means placing some restrictions on the trial. There isn't a consensus about what those restrictions should be, but after reading editors' concerns here, I can think of some starting points. I propose that:
1) There should be one trial, consisting of one 24-hour period.
2) On the trial day, there should be a maximum of one (1) cosmetic bot edit per article. Our technical wizards will know how to do this, but to my untrained eye it seems as if it may be necessary to give each bot its own list of articles to work on, and to ensure there's no duplication between lists.
3) On the trial day, cosmetic bots may not edit Vital Articles or any article in Category:Living people.
4) There should be a way in which editors can inoculate other articles against cosmetic bots. Perhaps use an opt-out category?
5) The date of Cosmetic Bot Day and how to use the opt-out should both be widely publicized well in advance (at least a month), using something editors are unlikely to miss such as a watchlist notice.
After this trial, there should be a further RfC to consider the lessons we've learned. Whether a second Cosmetic Bot Day happens afterwards should be decided at that RfC.—S Marshall T/C 23:55, 29 November 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)
  • 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 (utc) 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 (talkcontribs) 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). CThomas3 (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? CThomas3 (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. CThomas3 (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 (TALKCONT) 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 (talkdgaf)  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 (talkdgaf)  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! • SbmeirowTalk • 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. VanIsaacWScont 21:57, 29 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.

Replace hyphen with en-dash in Wikipedia browser tab name – MediaWiki:Pagetitle[edit]

HTML tag <title> defines the text, which web browsers usually use to label tabs. The <title> tag on English Wikipedia is controlled through the page MediaWiki:Pagetitle (see mw:Manual:Interface/Pagetitle for details). English Wikipedia uses the default $1 - {{SITENAME}}, where $1 is replaced by the full page name, magic word {{SITENAME}} is substituted to "Wikipedia", and they are separated by a spaced hyphen. For example, this page has <title>Wikipedia:Village pump (proposals) - Wikipedia</title>. Different wikis use different separators. Examples:

MediaWiki:Pagetitle on different wikis
Wiki Separator Example of <title>
English Wikipedia hyphen Earth - Wikipedia
German Wikipedia en-dash Erde – Wikipedia
Spanish Wikipedia hyphen Tierra - Wikipedia
French Wikipedia em-dash Terre — Wikipédia
Russian Wikipedia em-dash Земля — Википедия
Chinese Wikipedia hyphen 地球 - 维基百科,自由的百科全书
Wikimedia Commons hyphen Earth - Wikimedia Commons
MediaWiki's own wiki hyphen Help:Editing pages - MediaWiki

I propose replacing the hyphen at English Wikipedia's MediaWiki:Pagetitle with an en-dash, which is a more appropriate separator—see MOS:ENDASH. —⁠andrybak (talk) 16:29, 3 November 2020 (UTC)

  • I don't think this is necessary, and keep in mind would only change for users with the English interface language set (everyone else will still get the system default). — xaosflux Talk 18:29, 3 November 2020 (UTC)
  • Support per MOS:ENDASH. This seems like a pretty simple grammar fix (albeit with a huge scale), so I'm not sure it needs a giant discussion here, but I'm also not sure where else the discussion would've been hosted, so I can see why you brought it here. To speak to Xaosflux's point, this shouldn't be something that only applies to English, so if we can figure out how to apply it to all languages, that'd be even better. {{u|Sdkb}}talk 22:56, 3 November 2020 (UTC)
    Shouldn't the punctuation on each project conform to its own language and MOS? The MOS on enwiki would certainly indicate that an en dash, not a hyphen, should be used here, but an em dash or hyphen may be correct in other languages. A centralized discussion on Meta would be a good place to confirm that each project's tab punctuation adheres to its own MOS. Armadillopteryx 00:46, 4 November 2020 (UTC)
  • Meh for en.wiki; they're all just horizontal lines. 99% of users have never noticed, and of that 1%, 96% won't care. None of our business for all other wikis. I assume I'm misunderstanding Sdkb's comment; you aren't suggesting that the result of a discussion here should affect all other wikis? --Floquenbeam (talk) 23:29, 3 November 2020 (UTC)
    @Floquenbeam: From what Xaosflux said above, it seems that a fix might only apply to the English Wikipedia with the English language interface set, not all language interfaces. We control all language interfaces on English Wikipedia. As for other Wikipedias, it might be nice to standardize among those, but that discussion would probably have to be held somewhere on Meta. {{u|Sdkb}}talk 23:35, 3 November 2020 (UTC)
    It's very likely you know more than me about this. But "We control all language interfaces on English Wikipedia" doesn't sound right at all. I think I must be missing a subtlety or distinction or term of art? Anyway, it isn't important that I understand. As long as you're not saying we should make changes for, say, es.wiki or Commons too - which it looks like you're not saying - then we're good. --Floquenbeam (talk) 23:42, 3 November 2020 (UTC)
    In Special:Preferences you can set your language. If unset or set to a language that doesn't have a locally created MediaWiki page, there is a default MediaWiki page used. Killiondude (talk) 00:19, 4 November 2020 (UTC)
    MediaWiki has a framework to support translations into different languages in its own user interface messages, as described by Killiondude, which is what Sdkb is describing regarding having control over all language interfaces on English Wikipedia. It has been long recommended for users not to change their preferences to another language, though, as a lot (most? all?) of customized messages have not been translated (and as I recall, even specifying a country-specific English variant, like en-uk, will cause a fallback to the default message, thereby losing the customization). isaacl (talk) 00:36, 4 November 2020 (UTC)
    @Killiondude and Isaacl: actually it seems that if a custom message is set but not translated, the custom message is used. At least in the sidebar - go to https://en.wikipedia.org/wiki/Earth?uselang=de (an en.wp page but with the interface language set to German). The second item in the "contribute"/"Mitmachen" section is the custom English "Learn to edit" in both English and German interfaces rather than the default "Introduction" / "Einführung". Thryduulf (talk) 01:41, 4 November 2020 (UTC)
    You can see what impact changing the interface language would have by appending ?uselang=xx (where xx is the language code you want to use) to the URL (or &uselang=xx if the URL already contains a ?). For example go to https://en.wikipedia.org/wiki/Earth?uselang=de to see an English Wikipedia article with the interface language in German. The article text remains in English, but all the tabs, sidebar links, etc. are in German. Thryduulf (talk) 01:41, 4 November 2020 (UTC)
    It took you all more effort than it was probably worth, but I finally understand. Thanks everyone for the patient explanations, sorry everyone for being technologically incompetent, and sorry User:Sdkb for momentarily implying you might have been saying something crazy. --Floquenbeam (talk) 16:26, 4 November 2020 (UTC)
    No worries at all! {{u|Sdkb}}talk 19:31, 4 November 2020 (UTC)
  • Support this change on enwiki (and other English-language projects) per MOS:ENDASH; projects in other languages should make sure the dash (or hyphen) used conforms to their own MOS. Armadillopteryx 00:46, 4 November 2020 (UTC)
  •  Comment: previous relevant discussion: Wikipedia:Village pump (proposals)/Archive 135 § Proposal: Amend page title element to remove "Wikipedia, the free encyclopedia". —⁠andrybak (talk) 01:08, 4 November 2020 (UTC)
Support, hyphens are not used for this purpose, WP:NDASH.  Nixinova T  C   02:23, 4 November 2020 (UTC)
  • Support. It's a tiny, tiny thing...but honestly, I would be happy to see it happen.—Neil Shah-Quinn (talk) 15:11, 6 November 2020 (UTC)
  • Support on enwiki per Armadillopteryx. 〈 Forbes72 | Talk 〉 16:28, 6 November 2020 (UTC)
  •  Comment: should an RFC be opened to gather more feedback? —⁠andrybak (talk) 16:01, 8 November 2020 (UTC)
  • Support – It shouldn't be a question that our interface should generally conform to the MOS absent any reason to the contrary. 207.161.86.162 (talk) 03:26, 9 November 2020 (UTC)
  • Tentative support, but I am wonder whether there is a technical reason that hyphens in page titles are so common, even for sites with strict style manuals. For example, both the New York Times and the BBC have hyphens in their page titles. Indeed, it looks like every site in my browser bookmarks that has equivalent punctuation has a hyphen (except that my university's Blackboard Learn site has both a hyphen and an en dash in the title, which looks quite ugly now that I have noticed it). Any thoughts about why that might be? blameless 21:01, 9 November 2020 (UTC)
    • Withdrawing my support per the below and continued investigation. It was said above that "hyphens are not used for this purpose"--I am certainly a descriptivist, and I would say that hyphens are used for this purpose for purely internet-based instances of language (such as browser tabs) that are entirely separate from prose content, for the sake of consistency and reliability across browsers and character sets. Neutral. blameless 19:26, 26 November 2020 (UTC)
  • Oppose or replace with pipe. Browser tabs have limited horizontal space, and the only effect of this proposal is to waste a bit more of it. Perhaps this is why it is so common to use a hyphen or a pipe rather than an en-dash or em-dash. ST47 (talk) 21:29, 9 November 2020 (UTC)
    ST47, I'd have thought that the pipe would take up less space than an endash. I've tested in Firefox and Chromium in Ubuntu. In Firefox the pipe takes up more space than endash (font Noto Sans 10pt). In Chromium both take up the same amount of space (I couldn't figure out which font is used). —⁠andrybak (talk) 23:06, 9 November 2020 (UTC)
  • My browser (Firefox on Debian) follows our page title (and every other page title) with " - Mozilla Firefox" so using a dash or pipe would make my browser title look weird. Is that enough to oppose? I don't know, but clearly hyphens are pretty standard separators in how browsers display page titles. Additionally, it's probably better that our page titles are ASCII-compliant, and this change would move us away from that. This could affect page downloads or distribution on offline hardware. My main concern is that we gain pretty much no benefit, but there might be hidden problems it introduces. Wug·a·po·des 23:55, 9 November 2020 (UTC)
  • Meh Not worth the trouble for all the reasons Wugapodes mentioned. Probably nothing will break, but the benefit is so small it's not worth doing. The hyphen-minus is also the standard window title element separator on every non-Apple platform. An en/em dash will take up more space, which is undesirable. Switching to pipes would change the visual style, and I'm not a fan of that idea either (the hyphen-minus is the most common <title> separator anyway. --AntiCompositeNumber (talk) 00:27, 10 November 2020 (UTC)
  • Oppose Browser has limited space. Also, the proposal text doesn't clearly say which Hyphen#In_computing is currently used. Hyphen-minus is ASCII. If it currently is ASCII, then stay with ASCII for less interference with third party systems. TerraCyprus (talk) 23:26, 10 November 2020 (UTC)
  • Meh (Is Meh a valid voting option?) The title is also used for bookmarks, and so the site suffix has some value there, but I generally edit the titles to make sense to me and normally remove the suffix. Most of the time the tab is too narrow to display all of the article title, so the "- Wikipedia" site suffix is lost anyway. Personally, I would delete the site suffix from the titles as the icon at the start is enough to identify the tab, but I do suspect that would be seen as a step too far — GhostInTheMachine talk to me 11:59, 14 November 2020 (UTC)
  • Meh because I'm not sure I'll ever encounter a Wikipedia debate that warrants "meh" as much as this one. I'm sympathetic to both sides, but would probably favor the character that can be entered with one tap of the keystroke and is easily identified by non-native English speakers who don't even know what an en- or em-dash is. On the other hand no one's really going to be typing this on their own. Also, what were French and Russian Wikipedias thinking when they instituted the em-dash? -- Fuzheado | Talk 20:46, 16 November 2020 (UTC)
  •  Comment: I have requested closure of this discussion at WP:ANRFC. —⁠andrybak (talk) 18:25, 23 November 2020 (UTC)

Facilitate gauging article length[edit]

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 (talkcontribs) 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)

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.)[edit]

Clearly viewed as a non-starter Nosebagbear (talk) 09:41, 18 November 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I 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 52,035,618 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.

Add new edit tag for missing signatures[edit]

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)

Make links to disambiguation pages orange by default[edit]

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. –MJLTalk 17:45, 28 November 2020 (UTC)

Support (orange dab links)[edit]

  • 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 (talkdgaf)  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 (talkcontribs) 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)

Oppose (orange dab links)[edit]

  • 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 ... Face-smile.svg 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. VanIsaacWScont 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)
  • 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 (TALKCONT) 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 (utc) 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)

Discussion (orange dab links)[edit]

  • 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)
    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)
    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)
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. VanIsaacWScont 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)

RfC: Interim use of successor in Infobox officeholder[edit]

Moved from Template talk:Infobox officeholder § RfC: Interim use of successor – Moved after ten days, for more participation. ―Mandruss  17:52, 23 November 2020 (UTC)

This RfC is about the |successor= parameter of {{Infobox officeholder}}. When present, this field displays as Succeeded by in the infobox. When an incumbent loses re-election, should the parameter be filled in immediately or wait until the successor takes office? 17:52, 23 November 2020 (UTC)

BACKGROUND
  1. The template doc – Template:Infobox officeholder – currently says: "The infobox for an incumbent officeholder should not mention an elected or designated successor, or the end date of the term, until the transition actually takes place."
  2. There is apparently quite a bit of precedent for filling in the parameter immediately, adding "(elect)" following the successor's name. The "(elect)" is then removed when the transition takes place.
  3. The template doc guidance is oddly placed at the end of the doc's lead, rather than in the |successor= parameter description, so it would be easy to miss. It is unknown whether editors creating the precedents were aware of its existence, or whether such awareness would have affected their edits.
  4. In a recent discussion at Talk:Donald Trump, some of the disagreement centered around the interpretation of the phrase Succeeded by, some editors saying it's past tense and should be treated as such, others saying it can mean "to be succeeded by" when "(elect)" is shown. The discussion was auto-archived without closure, with a !vote count of 14–12 favoring immediate inclusion (which most editors would call "no consensus to include").
  5. The goal of this RfC is to establish a community consensus for site-wide consistency in these situations, one way or the other. ―Mandruss  13:32, 13 November 2020 (UTC)

Survey: Interim use of successor[edit]

This subsection uses the bulleted format (the "initial list marker type" is asterisk). Please help maintain that format per MOS:LISTGAP.

  • Wait for the successor to take office. Lots of things can happen between elections and transitions that would cancel the successions. Examples are not hard to imagine. The field label is not Succeeded by unless something happens to change that between now and the transition. The incumbents' BLPs can and probably do refer to the election outcomes in prose, often in their leads, so it's not like we would be depriving readers of that information.
    The precedent carries little weight for me because:
    • The issue has not been thoroughly examined and thought through.
    • The Trump article's discussion suggests that there is little agreement on the question despite the precedent (currently 12–10 favoring inclusion).
  • Removing the fields for the officeholders who have recently lost re-election is a matter of perhaps one or two editor-hours at most, not a significant factor, and I have no problem with changing de facto conventions like this when they are suboptimal. Resistance to change can impede improvements to the encyclopedia.
    A minor point: Removing the "(elect)" after every transition is a little extra work.
    (I don't know how to eliminate the extra bullet before "Removing" without breaking LISTGAP integrity. If you do, please fix it. Thanks.)Mandruss  13:41, 13 November 2020 (UTC)
  • Wait See comments below. TFD (talk) 14:37, 13 November 2020 (UTC)
  • Wait It would seem odd to have a "successor to be" item which this would be. Also, while in most cases we can assume the person-elect will be the actual successor there are times that things don't happen that way. I don't see an issue with waiting until succession has actually happened. Springee (talk) 16:39, 13 November 2020 (UTC)
  • Wait This is another example of people rushing to get the latest information in, even before it's been confirmed. If we don't know who the successor is because the successor hasn't formally taken office, then the person has not yet been succeeded, so the parameter should be left blank. Putting in "(elect)" is to misunderstand what "succeeded by" means. There's no hurry! EddieHugh (talk) 17:01, 13 November 2020 (UTC)
  • Wait. For the reasons stated above by TFD, Springee, and EddieHugh. --Coolcaesar (talk) 17:14, 13 November 2020 (UTC)
  • Wait In the US, at least, there is a several month period between the election and inauguration. Adding successor prematurely can cause confusion for viewers. --Enos733 (talk) 17:25, 13 November 2020 (UTC)
  • Wait - It should update when the transition occurs. PackMecEng (talk) 17:32, 13 November 2020 (UTC)
  • Add on Dec 14th, after the Elector vote and the election is certified.Eccekevin (talk) 23:02, 14 November 2020 (UTC)
    • This is a general discussion, not specific to the one instance you are referring to. -bɜ:ʳkənhɪmez (User/say hi!) 23:14, 14 November 2020 (UTC)
  • Wait until the successor has actually succeeded. While I respect that there is an "heir apparent" field in royalty infoboxes, that's a position in its own right which that person currently holds while the other person is the king/queen. An heir apparent is more similar to a vice president, chief of staff, or other position which is held simultaneously - not a successor where the transfer happens. Someone is not "succeeded by" another because of a vote, or a promise, or a claim, or a resignation... they're succeeded by someone when someone else takes the position they currently hold. Until there is another (obviously different) person in an office, they have not been succeeded, and many things can (and in history have) changed the course of what appeared to be an "obvious" succession. -bɜ:ʳkənhɪmez (User/say hi!) 23:14, 14 November 2020 (UTC)
  • Do not wait. The entry can always be corrected after, if the presumptive successor does not take office. --Checco (talk) 05:40, 16 November 2020 (UTC)
  • Wait per TFD and Springee. -- Guy Macon (talk) 19:01, 16 November 2020 (UTC)
  • Wait: It's been our long-standing habit to wait (which has only changed in recent months, and without consensus). I find that EddieHugh is completely correct (like Berchanhimez), and PackMecEng speaks rightly: "update when the transition occurs", not before. (On another note, I also find the recent use of "Outgoing", redirecting to "Lame duck" for "status" of incumbents to be extremely troubling, but that can be discussed later.) Javert2113 (Siarad.|¤) 01:15, 17 November 2020 (UTC)
  • Wait, and add a |to_be_succeeded_by= field (that nobody will ever care enough about to use for anything other than the United States presidential election). jp×g 09:52, 20 November 2020 (UTC)
    • I think this is the best option. I'd call it |successor_elect= you only have to remove the |_elect= upon succession. Eccekevin (talk) 01:18, 21 November 2020 (UTC)
  • Don't wait per below. Honestly can hardly believe this is a discussion that's happening. Therequiembellishere (talk) 00:57, 21 November 2020 (UTC)
  • Wait and don't add anything. Also, this is WP:CRYSTAL; you don't even know if an elected successor will take office, until they do. Mathglot (talk) 09:37, 21 November 2020 (UTC)
  • Hidden form - See my compromise (below) in discussion section. GoodDay (talk) 17:21, 21 November 2020 (UTC)
  • Wait and create a |successor_elect= field As proposed also by User:JPxG, see below for rationale and discussion.Eccekevin (talk) 21:05, 21 November 2020 (UTC)
  • Wait until the successor actually takes office. In the case of the President of the US, succession is unknowable. Currently, Trump’s official successor is still the Vice President (Pence)... with the Speaker of the House (Pelosi) after that (and so on down the line of succession).
This, of course, completely changes if Trump lives to January 20th, when Biden (or, if HE dies, Harris) assumes office.
Yes, chances are extremely good that Trump’s actual successor in office will be Biden... but we won’t know until it happens. It COULD be Pence, or Pelosi, or Harris, or even an unknown person appointed into the succession (think of Gerald Ford). Shit happens, and it being 2020, I would not be shocked if it did. Blueboar (talk) 21:26, 23 November 2020 (UTC)
  • Wait. Biden is almost certainly Trump's successor, but if he were to drop dead in the middle of his inauguration, before completing his oath for office, he isn't. No reliable source can guarantee that Biden is Trump's successor. 147.161.9.152 (talk) 15:35, 24 November 2020 (UTC)
    The RfC is not about Trump/Biden specifically, and it will not affect Trump/Biden alone, so I think it's misleading to talk about that one case. ―Mandruss  23:02, 24 November 2020 (UTC)
It is an example... the same arguments can be made any time the Presidency is about to change hands (the one possible exception might be when a sitting Vice President runs for the presidency and is elected ... as he/she would be BOTH the designated successor through rules of succession AND the expected successor through election). Blueboar (talk) 01:51, 30 November 2020 (UTC)
Even then, the VP could die before taking office. 147.161.14.234 (talk) 15:14, 30 November 2020 (UTC)
  • Don't wait. This discussion is honestly counterproductive and is wasting time. This has been the standard for years and for some reason someone has an issue with it? I don't know who this person is but this issue can always be corrected besides it's good to have this filled because when people are looking at the page and might wonder after seeing the election results "Where's the successor?". It also helps to be prepared as all that needs to happen come January it to remove the "elect" at the end of the name. Also @Eccekevin: you are engaging in what looks to be edit wars with other users regarding this RFC which is based on my understanding not final. You need to stop because other users are going to add them back and based on your words you are doing this based on a guideline which is currently in question in this very discussion which appears to be not final in any way shape or form. Until this RFC is resolved the articles should remain the same as they were prior to this discussion until a compromise can be reached. On election pages and the 117th Congress page we already list the successors as taking office during that Congress because that's just the way its been for years and nobody is questioning that for some odd reason but they are questioning this which baffles me. Again leave the articles the way they were until someone comes up with something. Also if a consensus was already reached someone let me know cuz I have not the closest idea what has been decided yet. Wollers14 (talk) 03:52, 25 November 2020 (UTC)
    for some reason someone has an issue with it? I don't know who this person is
    In this RfC, so far: Mandruss, The Four Deuces (TFD), Springee, EddieHugh, Coolcaesar, Enos733, PackMecEng, Berchanhimez, Guy Macon, Javert2113, JPxG, Mathglot, GoodDay, Eccekevin, Blueboar, 147.161.9.152.
    At the Trump article, although specific to that case alone (not counting users already mentioned): Tytrox, MelanieN, Ivanvector, Wugapodes, Jack Upland, Scjessey, Calidum.
    Now you know who "this person" is. Every one of them was aware of the precedent that you claim is a "standard". If you're asking who had the unmitigated gall to take this to the community to test whether there is in fact a community consensus for your "standard", that would be me. ―Mandruss  04:33, 25 November 2020 (UTC)
    Please come to the comments section. We can talk there. Wollers14 (talk) 05:59, 25 November 2020 (UTC)
  • Wait. The current office holder may resign, die, or be incapacited before the scheduled end of their term in office, and the elected successor may die or be incapacited before being sworn in or otherwise assuming the office. Space4Time3Continuum2x (talk) 17:20, 26 November 2020 (UTC)
  • Wait Per WP:CRYSTAL, outgoing members of Congress have resigned during the lame-duck period (between the election and the new Congress on 3 Jan), and, in at least one case I know of, the member-elect had died during said period; either situation would render the election-projected date of the successor's installment or even their identity incorrect. This discussion is counterproductive / waste of time is moot since this RfC was allowed to be run. CaradhrasAiguo (leave language) 18:04, 26 November 2020 (UTC)
  • Don't wait sure, the elected successor isn't guaranteed to take over, but that's what will happen in the vast, vast majority of cases, and I don't see a problem with adding it, possibly with an "(elect)" or "(presumptive)" suffix afterwards if necessary. In high profile cases such as POTUS there won't be any problem with getting people to remove the suffix when the successor takes office. Hut 8.5 18:24, 26 November 2020 (UTC)
  • Don't wait. Putting successors elect seems to be a long standing practice and there doesn't seem to be an adequate reason to change it. Doing so would require a long term overhaul. — Preceding unsigned comment added by 73.110.217.186 (talk) 19:20, 26 November 2020 (UTC)
  • Wait per CRYSTAL and VERIFIABILITY. There is a presumptive winner of the presidency at this point, but the election for that office doesn't happen until the electors (states) vote. Then, you'll have a president-elect. As for local and state offices, [office]-elect is is fine by me. Constitutionally yours, GenQuest "scribble" 18:08, 28 November 2020 (UTC)
    @GenQuest: - This RfC is not about U.S. presidents specifically, but about all officeholders U.S. and otherwise. ―Mandruss  06:44, 29 November 2020 (UTC)
    Sorry, I missed what you said about local and state offices. In that case, your !vote looks more like a "Don't wait" with a proposed exception for U.S. presidents, that exception being only a "partial wait" that frankly I failed to anticipate when I framed this RfC. I'd question whether any benefit there would be worth the added complication. ―Mandruss  06:51, 29 November 2020 (UTC)
    Sorry for the confusion, But you're right: Wait on the presidency - Don't Wait for the use of "-elect" on other offices, if that is chosen to be the rule. Personally, the whole thing is navel-gazing to me, and I don't see that temporary changes to articles are worth the effort, except perhaps in talk page discussions. So, my true feelings are that waiting to make any changes to any of the articles right now is the right thing to do. GenQuest "scribble" 23:13, 29 November 2020 (UTC)
  • Don't wait. The Presidency has literally never changed hands during a lame duck period by the incumbent dying before his elected successor took office. The only instance of something even remotely close was when Lawton Chiles died in December 1994 after Jeb Bush was elected Governor of Florida, so the Lt. Gov. that lost to Bush got to be Governor for like 3 weeks. JoeM3120 (talk) 01:25, 30 November 2020 (UTC)
FWIW, Chiles died in 1998. PS - the closes the USA came to invoking Section 3 of the 20th amendment, was when prez-elect FDR was nearly assassinated 'bout a month before he took office :) GoodDay (talk) 01:30, 30 November 2020 (UTC)
As Mandruss notes above, this discussion is not limited to the POTUS, but all officeholders. CaradhrasAiguo (leave language) 20:35, 30 November 2020 (UTC)

Discussion: Interim use of successor[edit]

  • Comment It might imply that the official was no longer in office. There is also potential for confusion between someone's designated successor and their elected successor. For example, were Trump to leave office before his term expires, his vice president would be his immediate successor, not Joe Biden. And there is always potential that the elected successor will not take office. Horace Greeley, the 1872 Democratic candidate, died before the electoral college met. (He was though the losing candidate.) Queen Elizabeth, who assumed the throne of 16 sovereign nations and numerous dependent territories, Canadian provinces and Australian states, has had the same heir apparent for almost 70 years, but during that time dozens of her realms have become republics. Barbados has voted to become a republic, so it is unlikely that her (currently) legal successor, Prince Charles, will ever succeed her as King of Barbados. Other countries, such as Saudi Arabia and North Korea, often have a line of succession, but can and do change it before their leaders leave office. In some cases, between an election and the date an official is sworn in, a country may decide to replace a victorious party leader with someone else. There could be a coup for example. Then we have the case of Venezuela, where the U.S. and its allies recognizes Juan Guaido as having succeeded Nicolas Maduro. But Maduro may in time be succeeded by someone else. It seems that the only case where this has been an issue is with Donald Trump. If editors feel that strongly, maybe we could amend the rules so that Trump could be treated as a unique exception. TFD (talk) 14:37, 13 November 2020 (UTC)
  • Comment regardless of this survey ends, I think in the future there should be a 'Successor designate' or 'expected successor' parameter. This will remove any need for further debate and controversy which will inevitably happen all the time.Eccekevin (talk) 02:27, 14 November 2020 (UTC)
    I'll oppose any such proposal if I'm aware of it. But this is not the place or time for it. ―Mandruss  15:19, 14 November 2020 (UTC)
    Why? It makes a lot of sense that there would be an expected successor. Harley Rouda'a page for example now has Michelle Steel in the successor parameter (which should be removed given this talk page). But it makes sense that going forward there should be a successor designate after an election and during the lame-duck period.Eccekevin (talk) 23:00, 14 November 2020 (UTC)
    Regardless, you are off topic in this discussion. It's about a narrow question, not anything related to successors. Consensus is already often difficult to assess without allowing discussion to wander into whatever tangents editors wish to bring up. Make your separate proposals separately, please. ―Mandruss  23:30, 14 November 2020 (UTC)
  • For comparison, I notice that the infobox at Elizabeth II has an heir apparent listed. —Granger (talk · contribs) 15:05, 14 November 2020 (UTC)
    A similar parameter should be added for elected positions, like the president, members of Congress of the English parliament. Eccekevin (talk) 23:00, 14 November 2020 (UTC)
  • Comment I still don't see why/how this would be an issue because even if you go to that Senator-elect or Congressperson-elect's page, it won't show them in office until January 3, 2021, when they will assume office so I don't get how that causes confusion, there obviously can't be two officeholders at once for a single office. Snickers2686 (talk)
  • Comment If the consensus is for wait until inauguration. Will it also be applied to the US representatives, US senators, US governors, US lieutenant governors & of course, all other elected/appointive political offices of other countries? GoodDay (talk) 18:02, 18 November 2020 (UTC)
    Yes, I would assume so. PackMecEng (talk) 18:08, 18 November 2020 (UTC)
    Cool :) GoodDay (talk) 18:10, 18 November 2020 (UTC)
    I agree that it should be applied to all - even if smaller offices have been wrong for a long time, it's not a reason not to fix it now. I look at it like this: Smaller pages are less likely to get views - this was not (to what I can see) a big problem on the pages for Obama or Trump because when those changes were proposed, they were correctly shot down until the inauguration. Just because smaller pages don't have enough sensible comments to shut it down (thus forming a "local" consensus for inclusion) does not mean that they were ever right to do so. Unfortunately, what I've observed is that with the 2016 election results, there was a large desire to avoid "legitimizing" the presidency of Trump and the wins of some other elections - and it went both ways in 2018, and now is attempting to quickly "remove" Trump as soon as possible in Wikipedia voice. I realize I'm getting off topic of a direct reply here, but I am attempting to point out that the only way to avoid the insertion of political bias in any direction into Wikipedia is to stick to the bare facts - someone isn't succeeded until they're actually succeeded. Doesn't matter who it is, who is likely to succeed, who's elected succeessor, etc. It matters who does, and when they do. I am unsure if this will close in time to fix all the errors in infoboxes related to the 2020 US election - but this luckily will hopefully give editors the strong, large consensus to prohibit addition in future elections in the US and around the world - which will hopefully eliminate this non-partisan bias of "I don't like this person so let's delegitimize their officeholding on Wikipedia as soon as possible by kicking them out early". -bɜ:ʳkənhɪmez (User/say hi!) 04:59, 19 November 2020 (UTC)
It makes no sense that for the infinitesimally small number of contested races among the thousands of transitions that happen every year, we should hold back every single other member-elect and appointee-designate that are not in dispute in any way. If people want to have very specific discussions about particular disputed changes (Trump to Biden, Cordray to Mulvaney/English, etc), then those isolated incidents can be sorted out in talk. To try and say we can't say Majorie Greene will succeed Tom Graves after she's officially been elected in the general and was unopposed in a deep Republican seat is asinine. We do not need a burdensome standard over every other noncontroversial article just because people want to avoid discussion on the handful of pages where there is an issue (and those discussions are going to happen on contentious pages regardless, solving even less).
Arguments saying CRYSTAL beg all belief. It is not divining a possible outcome of an election, it is a definitive fact that someone has been elected after a general election and is to take office on a set start date. If, instead, someone were to say Marjorie Greene's primary win was tantamount to election and put her as Graves' successor then, that would have violated CRYSTAL and been wrong. If on the outside actuarial chance the transition does not go as intended and someone dies or declines to take office, then we adjust to the facts changing in the moment like we do all the time in every single other article. Regis Philbin was alive and his article used the present tense and when he died we changed to past tense. It's really the same thing. "The facts stated X on one day and they have changed to say something else that we will now reflect." Again, this presumption of caution just in case for an absolutely minuscule number of cases where a transition doesn't occur as planned (at most maybe a couple dozen times a year, and of those the number that are high profile can probably be counted on one hand) while, again, thousands more offices change hands uncontroversially every year is totally ridiculous. It is a much greater burden to have to create all of these changes and police each page in the meantime, rather than just remove "elect" or "designate" when the time comes to do so.
Finally, the whole idea of these RFCs vastly changing policy for thousands of articles that editors interact with based on a very narrow band of, what, slightly over ten people has been a deeply flawed system from the start. Most editors do not see an RFC pop up, even less so among those who consistently edit on a particular topic but don't spend their time scrolling through RFC/A every day to see if a tiny band of folks are going to shift the way they edit, sometimes in very big ways. I don't have an ideal way to fix this, maybe an alert pops up at the top of the edit screen saying an RFC is in progress regarding that page so folks can pop over there to see if it relates to them, but even then that wouldn't cover these types of discussions where a template used by hundreds of editors is being decided in a discussion tucked away, and they won't have a chance to weigh in because they edit pages that utilize the template because hardly anyone edits a template page itself. Or people start an RFC on a particular kind of dispute on one page and then apply that standard they came up with there across a much wider range of pages that editors of those pages had zero clue a discussion impacting them had occurred. I just think the levels of awareness and lack of disinterested canvassing to get other perspectives constantly undermines the RFC process and the outreach (or lack of) used for 95% of them wouldn't in any way be considered adequate to change policy at any real life publishing house or company, or some kind of official government public comment period that it seeks to emulate. I just think these flaws should be kept in mind before folks go about imperiously pointing at RFC conclusions where five people participated as ironclad policy and demanding consistency from editors who edit differently and had zero clue a discussion was happening. This is an issue I have with the process as a whole, but also how those grievances relate in particular to this discussion on this template used on thousands of pages being impacted without 99% of editors who edit them knowing about it. Therequiembellishere (talk) 15:52, 21 November 2020 (UTC)
  • Comment - Wow, I wonder if this RfC could possibly be relevant to some current political event. Jeez... we really are running out of stuff to argue about here, huh? jp×g 09:50, 20 November 2020 (UTC)
    Of course it's relevant to some current political event. Issues like this don't arise out of the blue, they generally originate in article talk. As stated in the opening statement, the goal is site-wide consistency in a usage convention that has been thoroughly examined and thought through – something that does not currently exist. That is a worthy goal. That Donald Trump et al, like any other articles, will comply with any consensus here is a natural side effect, but not the impetus for the RfC. ―Mandruss  17:01, 20 November 2020 (UTC)
  • Strong oppose Agree with Snickers2686 (talk · contribs) above. Firstly, if Eccekevin (talk · contribs) could stop going around as if an RFC is progress is somehow a strict policy to be adhered to when it's clearly not settled, that would be a good start. Dozens of editors are doing the same thing we've down every transition for global politician's at least since I joined in 2007 (the notion mentioned above that this is recent trend from the past few months is honestly just so ridiculous), and pretending they're suddenly doing something wrong rather than just invite them to participate in the discussion just because it's the opposite of what Eccekevin is arguing has been frustrating. This is frankly one of the most ridiculous things I've read and fits into this weird obsession to cater to the absolutely lowest common denominator of possible reader misunderstanding. Readers are not stupid. They know what the words "elect" and "designate" mean, especially without an end date listed and with the word "Incumbent" emblazoned on the box. If an excited editor doesn't hide the end date that is beyond the present date, a reader will understand that it is in the future and they are still in office. Indeed, having something listed in each field has been key in preventing such mistakes when less informed/newer editors try to say the incoming person has taken office when they fill in a blank field; then we have to waste much more time reverting these changes. We've done this for so long, it's become expected of readers looking to see who will succeed X politician to check the incumbent's page and see who is listed. This is really just bending over backwards to fix something that is not broken. Is there truly a wellspring of confused readers who can't figure this out that we need to hold off on every known transition immediately post and election or resignation for thousands of pages? No. There really isn't. If tense is such an incredible issue here (since they imply past tense with "preceded/succeed by"), then just change the filed to read neutrally as "predecessor/successor" like they read in code. But a wholesale policy on leaving the field's blank, even when hidden, is just lessening information that readers are more likely to be searching for than be confused by. It's unencyclopedic. It's a waste of time. It's unnecessary. Therequiembellishere (talk) 00:48, 21 November 2020 (UTC)
    • Therequiembellishere (talk · contribs) My edits are not based on the RfC, but on the current policy. If you look at the page, it states that the current policy is: "The infobox for an incumbent officeholder should not mention an elected or designated successor, or the end date of the term, until the transition actually takes place.". This RfC might change it, but as it stands the policy is to keep it blank. Whether the infobox policy was violated in the past is meaningless. Eccekevin (talk) 01:14, 21 November 2020 (UTC)
FWIW, when did the template change? For years, I've been adding in the elected/designated individuals before they took office & nobody ever objected. GoodDay (talk) 16:11, 21 November 2020 (UTC)
Agreed for at least a decade. And to be clear, GoodDay (talk · contribs) and I have agreed on very little during that time. Therequiembellishere (talk) 16:40, 21 November 2020 (UTC)
Considering this RFC & the infobox discussion taking place (see below), I'm in agreement with @Therequiembellishere:, that some kinda direct notification to interested editors, should be implemented. Too many times, a small group of editors have caused big changes, because most interested editors were unaware of such RFCs & other important discussions. GoodDay (talk) 16:47, 21 November 2020 (UTC)
@GoodDay: The RfC is obviously listed in the RfC listings of two RfC categories. I advertised the RfC at WP:VPP, WP:VPR, and WT:WikiProject Politics. You or anybody else is welcome to advertise it in other appropriate talk spaces. Per WP:CANVASS, you are NOT allowed to notify specific "interested" editors based on their known or likely positions on this issue. Don't do it. Don't even talk about doing it. ―Mandruss  16:58, 21 November 2020 (UTC)
To clarify, when I said "disinterested canvassing," I meant an impartial and blanket notification to users who frequently interact with the box. In that sense, we are looking for people who with an "interest" but not for those with a particular position in mind. If that makes sense. Therequiembellishere (talk) 17:49, 21 November 2020 (UTC)
Also noting that I'm fully aware this is much harder for a template RFC than one regarding a specific page. But I really believe that of the already tiny bubble of engaged editors, it is even tinier for those who look at pages like WikiProject Politics. Most people just edit, and those are the people I'd like to see some mechanism for making more aware. Therequiembellishere (talk) 17:52, 21 November 2020 (UTC)
I would dispute the notion that editors who have been extensively involved in editing |successor= fields are somehow more qualified than the average editor to weigh in on the subject. Between this RfC and the Trump article, there are several dozen editors already involved, and the RfC will likely run for another 20 days (or so). Furthermore I have always felt that, if an editor can't be bothered to watch for discussions of interest to them (like watching the page Wikipedia:Requests for comment/Politics, government, and law), they pretty much forfeit the right to complain about the results. I apply that principle to myself, and I have enough respect for the editing community to trust that they can reach acceptable decisions on most issues without my involvement. ―Mandruss  18:29, 21 November 2020 (UTC)
I don't think they're more qualified, I'm saying there should be some way to involve them. Of course Wikipedia isn't (and really shouldn't be) anyone's central purpose in life, but it feels as if we punish those casual editors who are consistent but don't have the time/know how to delve into the depths they aren't aware are happening. It keeps Wikipedia unfriendly and less "a free encyclopedia anyone can edit" and more a series of tiny fiefdoms of people wasting their Saturdays lol. I just think it's mistaken to say people "forfeit the right to complain" when they just don't know it's happening because of the byzantine processes here. Therequiembellishere (talk) 18:40, 21 November 2020 (UTC)
There is some way to involve them, and it has already been done. There is no other way to involve them without violating CANVASS. It's up to them to see the very public notifications. ―Mandruss  18:48, 21 November 2020 (UTC)
Which is why I've asked for there to be a mechanism, not just for this but all RFCs. The notion that Wikipedia:Requests for comment/Politics, government, and law is "very public" is just not true. As we can see by the scant and slanted (in effect, I don't think maliciously) attention we have on this page as compared to the discussion you've just alerted me to on Talk:Donald Trump (a page I specifically avoid because of the number of arguments that occur there), which has a much more lively discussion with a greater split of opinion. I think it's correct there should be a lot of people trying to solve an issue for that specific page. I do not think it's correct to come up with a blanket policies for the thousands of other pages that don't have any issue because of it, and especially not with the paltry engagement we've seen here. If this RFC is the controlling discussion that will affect every other infobox and transition ever, it's inadequate. Let's have the Trump dispute be sorted out on it's own and remove the provision that says it's not allowed, especially when it's not been used in practice over the (shamefully) 15 years I've edited here. As GoodDay raised above, its not clear to me when this got added or if it's ever been the practice. I disagree with it strenuously for all the reasons I've stated above regardless. Therequiembellishere (talk) 19:05, 21 November 2020 (UTC)
Perhaps inadequate, and perhaps it should have been given even more visibility by doing it at VPR (although it makes no "proposal" besides the "proposal" to examine the issue thoroughly and form a binding community consensus). Widespread editor practice means little to me without such thorough examination, and I don't deem things to be "Good" merely because they are widespread or traditional. Lots of participation in these things arises from editors watching the page histories of pages like that, not their tables of content (and the discussion notices won't stay for 30+ days like an RfC would). But this is the way many editors insist is the correct way, and it's the way I opted to go this time. If you want to go to the trouble of moving this RfC to a Village Pump page, I won't object provided you leave the existing level-2 heading and use the {{Moved discussion to}} and {{Moved discussion from}} templates. ―Mandruss  19:32, 21 November 2020 (UTC)
In any case, while I do think this is an issue that affects all RFCs (and therefore this specific one), I have three other paragraphs on why I think this RFC is wrong that I'd also appreciate some engagement in. Therequiembellishere (talk) 18:42, 21 November 2020 (UTC)
Since I've bounced around in this discussion, they are referring to my thoughts in the wall of text above with more of my arguments beyond those listed in the para, including questions over the RFC process as a whole. Therequiembellishere (talk) 16:53, 21 November 2020 (UTC)
Surely you can understand why this is not the place to discuss the RfC process as a whole? I give you that much credit and more. ―Mandruss  20:02, 21 November 2020 (UTC)
Yeah, I've emphasized that over and over again, so. Therequiembellishere (talk) 20:42, 21 November 2020 (UTC)

Comment for Mandruss. Listen man I never meant any disrespect in my previous post. But if this issue is limited to Donald Trump's page than I don't really care about this issue. But Eccekevin (talk · contribs) is going around and removing the successors for Members of the House and other politicians. Even though they are listed as having won their races AND are listed as members of the 117th Congress on its own page. So this is confusing and in my opinion unnecessary as they are already listed in the Congress page. I don't know why this user is going around when the RFC seems not to be final and removing them but since people are confused about this I want to know. Wollers14 (talk) 06:22, 25 November 2020 (UTC)

This issue is NOT limited to Donald Trump's page, it merely originated there. Please read the RfC introduction, I think it's clear enough on that point.
We are currently omitting the field at the Trump article because a high-participation discussion there failed to reach a consensus to include it (default is usually omit, especially for strongly disputed content).
In my opinion, Eccekevin is free to make BOLD edits that do not violate existing consensuses, subject to challenge by reversion. You are free to challenge their edits by reversion, and both of you are free to start discussions at article talk pages. But that is a lot of work that could be avoided if Eccekevin would just wait for the outcome of this RfC (assuming there is a consensus here). I would not do what they are doing, but it is within their rights. ―Mandruss  06:43, 25 November 2020 (UTC)
Past practices have been to include the successors-to-be in nearly all related bio articles. But it's been pointed out to me, that it was done 'against' the current related infobox guideline. Also, the exclude practice was implement 4 years ago at Barack Obama & Joe Biden (which I initially forgot). Most important is that we have consistency across all such articles. It's now quite obvious, a consensus has formed to exclude successors-to-be, period. GoodDay (talk) 16:05, 25 November 2020 (UTC)
Problem with this "obvious consnsus" is the successors-to-be are already listed at least the congressional ones as members of the 117th Congress. If the guideline was not followed correctly than the author of said guideline may need to revise it due to it being circumnavigated by using the (elect), (designate) etc. The guideline is out of date and a additional consensus may be needed to revise it if that is possible. I'm not sure what the process for revising a guideline is but that might be what we need to do if that is possible. Wollers14 (talk) 19:54, 25 November 2020 (UTC)
Look, we get it. A consensus to "Wait" in this RfC will create situations that seem inconsistent. To address all of it would have been far too much to take on in a single RfC. If the consensus here is "Wait", it will be because the community doesn't think Wikipedia should show successors as such prior to succession (except in article prose), so it would follow that the inconsistencies should be resolved by changing the rest of the precedent. The only question is whether that can be done on the basis of this RfC consensus or whether more discussions are necessary to make that happen. I regret that nobody has raised the issue at community level until now, resulting in a lot of work to change direction, but I don't lose sleep or bite my fingernails over the temporary inconsistencies. The easiest path is not always the best path, and Wikipedia is a work in progress. ―Mandruss  20:35, 25 November 2020 (UTC)
  • Not really sure why this was moved to VPR. It's a localised template issue, we seemingly routinely deal with these on template talk, even if major ones, and this isn't a major one relatively. Could just advertise via the RFC process (already done it seems) and add a section here with a link if necessary. It's now a bit misleading, since this won't be archived on the template talk where the discussion started and most of it happened anymore... ProcrastinatingReader (talk) 10:37, 26 November 2020 (UTC)
    @ProcrastinatingReader: I'm not really sure how you could be not really sure why this was moved to VPR, considering that that question is answered following the move templates at the very top of both of the "from" and "to" sections, where it's quite hard to miss. But here's a longer answer.
    I judged that where the RfC would be archived was less important than getting high participation, since the RfC has the potential to reverse what some consider a de facto consensus, with probable ripple effects (see above discussion). After ten days, we were not getting that high participation, despite the RfC listings and discussion notices in three separate talk spaces, and there was no reason to believe that would improve. Further, one or two people were talking about a need to notify "interested" editors in ways that I felt would violate WP:CANVASS, and this was a way to possibly make the RfC visible to at least some of those "interested" editors (I am not interested in gaming the system to keep out voices that I disagree with).
    But hey, if you want to move this back after closure so it will be archived in the "correct" place, no objection from me. ―Mandruss  17:13, 26 November 2020 (UTC)
  • A note to whoever closes this, I have yet to see a "don't wait" vote that explains how this does not violate WP:CRYSTAL and WP:V. Nobody says Biden has succeeded Trump yet - because he hasn't. They also are, more often than not, shying away from calling him Trump's successor - instead calling him president-elect - because he's not yet Trump's successor. This means that adding it, even with (elect) or (incoming) or similar is a violation of CRYSTAL and V, which seems to be conveniently ignored by everyone who just wants to be able to make these changes because they like it better that way. -bɜ:ʳkənhɪmez (User/say hi!) 21:51, 26 November 2020 (UTC) edited -bɜ:ʳkənhɪmez (User/say hi!) 05:33, 27 November 2020 (UTC)
    @Berchanhimez: I don't think it's proper for an editor to try to guide the closer's thinking beyond the arguments presented in their !vote, and I think any closer who needs that kind of "help" probably shouldn't be doing closures. If you can do that, opposing editors are certainly allowed to counter it, and back and forth, and then we have editors involved in the business of assessing their own consensus, which should be outside our purview, precisely because we can't be expected to be objective about that, which is why we have uninvolved closers in the first place. And I say this as a fellow Waiter. ―Mandruss  01:16, 27 November 2020 (UTC)
    While I said this as a note to the closer, it was more a message to those who've been voting not wait to consider replying to the policies. I put "note to whoever closes this" as I personally feel that closers shouldn't have to do all the work on their own - if a subset of votes is not policy based, it may help someone to see that clearly stated somewhere. Regardless, I'll refrain from that language in the future, and have struck the first part to just leave the comment itself. -bɜ:ʳkənhɪmez (User/say hi!) 05:33, 27 November 2020 (UTC)
    It's eminently verifiable that Biden is the president-elect, which is what the Don't Waiters want the field to say, so this is not a V issue as you claim. Similarly, it can also be asserted that it is not CRYSTAL to say that Biden is the president-elect, since he is indisputably the president-elect NOW, not in the future. So it isn't objectively a CRYSTAL issue, either. In my view, there is precious little policy on either side of this issue; it's pretty much pure "editorial judgment". (I've said elsewhere that it's misleading to talk about the Trump-Biden case in this RfC. Please feel free to substitute "the successor-elect" for "Biden", as that's what I meant. Biden is a convenient communication device.)Mandruss  05:49, 27 November 2020 (UTC)
    • Aren't "elect" and successor synonymous in this case? If reliable sources are calling Biden the President-elect, they basically saying that he is the expected successor.73.110.217.186 (talk) 05:40, 27 November 2020 (UTC)
      • Expected successor is not successor, and that is exactly the point I was making. -bɜ:ʳkənhɪmez (User/say hi!) 05:33, 27 November 2020 (UTC)
        • If they're suffixed with -elect, then it's saying that they're not yet the successor, but that they will be following the expiration of the term, since they won the most recent election. For what it's worth, the succession boxes at the bottom seem to have the -elect's listed. 73.110.217.186 (talk) 05:40, 27 November 2020 (UTC)
  • Comment - Call it growing pains, but activity at T.J. Cox, is an example of how difficulty it might be, implementing the exclusion consensus. GoodDay (talk) 21:42, 27 November 2020 (UTC)

Compromise[edit]

Withdrawn. ―Mandruss  18:40, 25 November 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Recommend we have the successor-to-be included in the infobox of the lameduck official, in hidden form. I've done this at Donald Trump & Mike Pence & so far, nobody seems to object. It's the same as having the 'departure date' in hidden form. GoodDay (talk) 17:19, 21 November 2020 (UTC)

I didn't see the point of that edit – no editors of that article need to be reminded who is projected to succeed Trump – but I didn't object because it's hidden and harmless. I'll be very surprised if any opponents of waiting would see that as an acceptable "compromise", because their arguments (and the entire debate) are centered around what readers can see. ―Mandruss  17:32, 21 November 2020 (UTC)
Let it grow on you & you'll see the wisdom behind it. GoodDay (talk) 17:34, 21 November 2020 (UTC)
There's no point in that. Why have it if it is not visible? It's just going to cause more confusion and edit warring. I advocate a separate successor_elect parameter (see below).Eccekevin (talk) 21:02, 21 November 2020 (UTC)
If visible in the editing window only, that would give an editor pause, if seeking to add individual. GoodDay (talk) 21:03, 21 November 2020 (UTC)
Yeah but in the endresult would be the same as to not include it at all, since it is not visible. So it's not really a compromise, it's just wait. If your goal is to make the editor pause, just add < !--- do not add before succession occurs---> instead.Eccekevin (talk) 21:11, 21 November 2020 (UTC)
But such an editor would be content to see that the elected individual is in the infobox, though hidden. This would remove 'any' suggestion of political bias. GoodDay (talk) 21:20, 21 November 2020 (UTC)
No it would not. What matters is what readers see, not what editors see. How long should I wait to see the wisdom behind it? ―Mandruss  21:30, 21 November 2020 (UTC)
If yas wanna learn the hard way? then go ahead. It's no stress for me. GoodDay (talk) 21:37, 21 November 2020 (UTC)
Okie dokie. Thank you. ―Mandruss  21:40, 21 November 2020 (UTC)

My proposal hasn't gotten any support. May as well close this sub-section. GoodDay (talk) 16:06, 25 November 2020 (UTC)

Done, thanks. ―Mandruss  18:40, 25 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.

Archiving webpages[edit]

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)

[edit]

Wikipedia turns 20 on 15 January 2021. Should we have a 20th anniversary logo for that day? This is a bit time sensitive as we can really only celebrate it once on 15 January 2021. Aasim (talk) 03:38, 30 November 2020 (UTC)

  • I'd like to add one puzzle piece to the right of the Ethiopic (at the top right). It would be barely visible, but symbolizes that over twenty years, we have added to the sum of human knowledge by bringing so much encyclopedic content to the world. VanIsaacWScont 03:56, 30 November 2020 (UTC)
    • That's an interesting idea - is there a single character version of "20" in any language that could be used? This could require a veritable bolting through however, since to get it used, it has to jump through a bunch of hoops on the WMF's side. Not that I suppose lacking the trademark on it is a concern for a one-off. Nosebagbear (talk) 10:37, 30 November 2020 (UTC)
      20
      二十
      XX
      0x14
      What else? Aasim (talk) 17:48, 30 November 2020 (UTC)

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

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)

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. –MJLTalk 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)