Jump to content

Wikipedia:Village pump (proposals)/Archive 175

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

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

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

RfC: Interim use of successor in Infobox officeholder

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
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

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)
  • 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)
  • 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)
  • Don't wait. Even if any of the unlikely "events" to alter the successor mentioned did happen it would take but a moment or two to edit the article to reflect the new circumstances. It is instructive to note that this has not been a problem for wikiP articles in any of the dozens of elections that occurred before the 2020 one. MarnetteD|Talk 21:32, 2 December 2020 (UTC)
  • Add parameter (I don't care if it's |to_be_succeeded_by= or |successor_elect= or whatever). Second choice: Don't wait. We have no reason to suppress information. If something strange like a sudden coup d'etat happens, we can just change it again.  — SMcCandlish ☏ ¢ 😼  04:54, 8 December 2020 (UTC)
List both outgoing and incoming...better question is what to do with people like David Andahl.--Moxy 🍁 03:22, 15 December 2020 (UTC)
  • Create a new field for |successor_elect=, |to_be_succeeded_by= or |successor_designate= per SMcCandlish and Eccekevin. The biggest concern I have with the way it's currently set up is that |succeeded_by= is past tense and it's just awkward because it reads like, for instance, "succeeded by X, next month". Adding (elect) is a crude solution. I understand the concern with WP:CRYSTAL, but if the presumptive successor dies, that can simply be change that in the infobox. I believe it's more helpful for users' navigation to indicate the future holder of an office if it is almost certain they will assume office. NO MORE HEROES ⚘ TALK 05:20, 15 December 2020 (UTC)
  • Create a new field per several editors above. Seems sensible and non-controversial. davidwr/(talk)/(contribs) 🎄 15:06, 15 December 2020 (UTC)
  • Wait - Who defeated whom in an election and when they are scheduled to take office are things better handled in prose. Leave infoboxes for simple facts that don't need all the explanation and qualification. --Khajidha (talk) 16:21, 17 December 2020 (UTC)
  • Don't wait, give the reader the best information currently available. It's not CRYSTALBALL, it's correct information. This is a general RFC not about a specific election, but it's helpful to use examples, so let's use Trump/Biden. Who is the next President of the US? It's Biden. Go find a political scientist or any scholar and ask them, "Who is Trump's successor?" The answer won't be "I don't know" or "could be anyone" or "we'll have to wait and see", the answer you'll get, from 10 out of 10 scholars, is "Biden". Two months ago, it'd be "We'll see". It may be that next month, the successor changes, but that doesn't mean that as of right now, we don't have a successor or we don't know who it is. There is no reason to leave the information out (who is currently the successor) when that information is available, and particularly when the gap between elections and transitions is often months. If the information changes, we should just update the article. We shouldn't leave information out because it may, theoretically, change. (If we did that, we'd have a blank encyclopedia.) Don't create a new field per WP:CREEP. Just adding "(elect)" after the name works fine for the weeks/months in between the election and transition. The current practice works well as it is. Levivich harass/hound 00:13, 18 December 2020 (UTC)
  • wait If you say someone *was* succeeded by someone else *before* the succession takes effect, you are presenting false information. Lying to our readers is bad. - Nabla (talk) 02:50, 18 December 2020 (UTC)

Discussion: Interim use of successor

  • 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)
  • Comment - I hope that those of you who are pushing for exclusion, will be vigilant in implementing that solution. I.E - walk the walk. GoodDay (talk) 20:38, 2 December 2020 (UTC)
  • Comment - Given how some such removals have been reverted, trying to implement this policy might be more hassle than it's worth.73.110.217.186 (talk) 23:31, 3 December 2020 (UTC)
    Knowingly editing against consensus is grounds for sanction under WP:DE, and a sanction is possible at a single admin's discretion at articles under DS (i.e., many if not most articles in areas of politics). The goal of this RfC is to establish a consensus. The possibility of disruption is never a good reason not to seek community consensus. ―Mandruss ☎ 00:26, 4 December 2020 (UTC)
    It was more regarding the fact that people might be unaware of a change, given how it seemed to be commonplace beforehand, so they might not know that it's against consensus.73.110.217.186 (talk) 05:51, 7 December 2020 (UTC)
    That is true for any consensus, which doesn't mean it might be more hassle than it's worth. Awareness of a consensus can be increased by including a link to this RfC in the template doc as part of the description of the |successor= parameter. When that is not enough, there is nothing wrong with unknowingly editing against a consensus and getting corrected. Hassle avoidance is not a good strategy for building a good encyclopedia. ―Mandruss ☎ 00:28, 8 December 2020 (UTC)
  • Comment - What about succession boxes at the bottom of articles? I noticed that some articles who had the elect removed from their infoboxes still have it at the boxes in the bottom.73.110.217.186 (talk) 04:36, 8 December 2020 (UTC)
    [1] ―Mandruss ☎ 06:05, 8 December 2020 (UTC)
  • Comment - At least this topic isn't very frustrating. Unlike what's happening over at the Antony Blinken article. GRRR. GoodDay (talk) 22:58, 10 December 2020 (UTC)
    The issue seems to be inconsistently applied.73.110.217.186 (talk) 14:10, 13 December 2020 (UTC)
  • Comment (1) If indeed the practice is to 'omit' successors, then someone better remove elected successors from the infoboxes of every single member of Congress who is to be succeeded. (2) The "succeeded by" field 'always' includes the word "(elect)", which makes it clear that the person listed has not in fact taken office. It is not WP:CRYSTALBALL; it is saying that someone has been elected, and is slated to succeed the incumbent. The election has taken place in the past. The installation will take place in the future. The word "(elect)" makes it clear that only the first has happened. It's not CRYSTALBALL to say that. (3) It is altogether quite useful to have a successor linked. (4) Until the 2020 Presidential Election, and still with every non-Presidential position, the official-elect was listed without exception in US politics (as far as I know). Wikipedia is here to provide information, not engage in obscurantism for what are clearly politically-motivated reasons. D. Benjamin Miller (talk) 00:57, 15 December 2020 (UTC)
    @D. Benjamin Miller: obscurantism for what are clearly politically-motivated reasons – Per WP:AGF I suggest and request that you provide the required "clear evidence" or strike that. Per AGF, I should not be required to point out that many of the Waiters, including me, are staunch Trump opponents. Furthermore it's hard to miss the irony of a Trump opponent seeing clearly politically-motivated reasons for something absent evidence of same, and I also suggest and request that you spend a little time reflecting on that. ―Mandruss ☎ 03:11, 15 December 2020 (UTC)
    OK, I have stricken that. I stand by the argument that it is not WP:CRYSTALBALL. D. Benjamin Miller (talk) 03:14, 15 December 2020 (UTC)
  • Comment - @Ryanlewis 05: please comment here, rather then continue on an addition run. GoodDay (talk) 03:21, 15 December 2020 (UTC)
  • Comment - Been doing my best to uphold the idea that we exclude successors-to-be in the infoboxes of lame-duck officials. I hope nothing changes in other areas (Donald Trump's intro, for example), that may cause me to become lazy & thus no longer try to enforce the exclude preference. GoodDay (talk) 13:58, 17 December 2020 (UTC)

Compromise

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.

IP disruptions

Seeing as this RFC is heading towards the exclude option. I should point out that an IP has apparently been continuing to re-add in the elected successors-to-be, in the lameduck infoboxes. GoodDay (talk) 03:52, 7 December 2020 (UTC)

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

@ProcrastinatingReader: If you or anyone else want to move this back to Template talk:Infobox officeholder for archival, now's the time (assuming no closure challenge). My preference would be to establish firm rules for the placement of such things, somehow confronting and addressing the problem of low participation at template talk pages. ―Mandruss ☎ 05:25, 19 December 2020 (UTC)

New page

I think there should be a page on Operation Enduring Encyclopedia and it would be a little bit funny, but also have links to how to "enroll." Sorry if this has already been discussed before. TigerScientist Chat 23:57, 18 December 2020 (UTC)

TigerScientist, do you mean Wikipedia:Operation Enduring Encyclopedia? —⁠andrybak (talk) 08:51, 19 December 2020 (UTC)

Minus signs not rendering

The minus sign sometimes does not appear in equations. For example, the first minus sign in the following equations does not appear in a Chrome browser on my laptop computer:

Please see Talk:Modular arithmetic#Minus signs not rendering and Talk:Abel–Ruffini theorem#Poor rendering with Chrome is confusing.—Anita5192 (talk) 17:11, 20 December 2020 (UTC)

@Anita5192: This has been reported multiple times now on WP:VPT, which would have been the correct place to leave this comment. --Izno (talk) 18:11, 20 December 2020 (UTC)
I don't see it there anywhere.—Anita5192 (talk) 20:02, 20 December 2020 (UTC)

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)

A draft of the logo described by wugapodes
  • Hi everyone! Samir here from the Foundation's brand studio. Wanted to bring to your attention that we have recently published some celebratory Wikipedia 20 symbols here. Hope they can be of inspiration to your brainstorming. Please let us know if you would like to collaborate on something. Thanks so much for starting this discussion. --Selsharbaty (WMF) (talk) 10:54, 10 December 2020 (UTC)
    • @Selsharbaty (WMF): Thanks for sharing these! I want to ask if someone could design an image of a cell phone in that art style? (update, I made a stand-in myself, but feel free to keep tweaking) I have an idea for a logo we can use which represents Wikipedia's place in the development of knowledge accessibility. To keep the visual proportions the same, I think we should replace the puzzle globe with a four-quadrant square (instead of 4 images linearly). The top left would be File:WP20Symbols Wikiversity.svg representing paper encyclopedias; top right would be File:WP20Symbols_MediaWiki.svg representing the CRT monitors common when Wikipedia debuted; bottom left would be File:WP20 symbol CellPhone.svg representing our contemporary, mostly-mobile readerbase; and bottom right would be File:WP20Symbols_puzzleglobe2.svg to maintain continuity through the branding. Below this quadriptych would be the "Wikipedia 20" text mark. I've included a rough mock-up here using {{Multiple image}}. Does this generally sound like a good design? We've got less than a month to get something set up so if you could pitch this to your team and get feedback on changes, I'd be happy to help advertise a proposed celebratory logo to the community. — Wug·a·po·des​ 23:04, 17 December 2020 (UTC)
  • ping discussion participants @Awesome Aasim, Vanisaac, Wehwalt, Vanisaac, Yair rand, and SMcCandlish: Following up on Selsharbaty (WMF)'s message I used the WMF brand team's designs to make a logo displayed here (link for convenience). Since you all seemed interested, I wanted to get your opinions on it and possible revisions. If it's on the right track, we should coordinate an up-or-down RFC advertised at CENT or through a watchlist notice, and if it's the wrong track we should try to further develop other ideas in the next few days. — Wug·a·po·des​ 00:17, 18 December 2020 (UTC)
    Looks great! Maybe the first image should be a 20, though. Because Wikipedia turns 20. Aasim (talk) 00:57, 18 December 2020 (UTC)
    I'm... not really a fan of the style, tbh. It seems vaguely thematically wrong. (The entire set of resources provided seems quite off; the brightly-colored high-contrast thick-line cartoon-effect artwork looks somewhat childish and not really scholarliness/collaborative-project-themed. I find the faces a bit creepy, but that's just my personal sense of aesthetics, I suppose. Also, several of them are for broken links ("Bapho", "Ghyama", "WKTK (slang)", "Chic@s") and the Wiktionary one incorrectly describes "knowledge" as a proper noun, which is quite an error. I'm also a bit confused as to why six of the images have Islamic religious iconography? (None from other religions afaict.)) Anyway, back to the logo: I don't suppose we could go with something more along the lines of the commons:Category:Wikipedia 10 or commons:Category:Wikipedia 15 imagery? I do like the "20 years of Wikipedia" line, though. --Yair rand (talk) 04:54, 18 December 2020 (UTC)
    It's all an evil plot hatched by us Muslims: first we take over the Wikipedia logo, then we take over the world! All your pedia are belong to us. M Imtiaz (talk · contribs) 12:35, 21 December 2020 (UTC)
    I'd also rather see something thematically related to our past anniversaries and dislike the use of the cartoons.--Wehwalt (talk) 06:53, 18 December 2020 (UTC)
    Something as simple as a 20 with the zero formed by the Wikipedia globe, perhaps within an outline, would be fine.--Wehwalt (talk) 17:17, 18 December 2020 (UTC)
  • I would prefer something subtle, based on current or historical logos but without the flashy color. Something like the bottom-right one, but in the traditional grey, with the "radiating lines" removed and something to indicate "twenty" or "20" around the edges. If you do want to do a "4-image" logo, maybe use some of the earlier Wikipedia logos, or use logos for the Foundation, Commons, WikiData, and other cross-language parts of the project. Bottom line: The less it looks like the current or historical logos, the less I like it. davidwr/(talk)/(contribs) 🎄 16:48, 18 December 2020 (UTC)
    I don't think I'll have much aesthetic input, as long as the messaging purpose is done well, and we take accessibility into account (black and red don't mix well, because red looks near-black to people with some kinds of color blindness). I'm not sure the "reading a book" thing has much to do with Wikipedia, though the desktop and mobile icons or whatever we might call them are on-point.  — SMcCandlish ☏ ¢ 😼  04:31, 19 December 2020 (UTC)
  • Thanks for the feedback. I've worked up three candidates based on the stated preferences and previous years.
  • Still in the WMF's planned visual style, but not so different as first iteration.
    Still in the WMF's planned visual style, but not so different as first iteration.
  • Our usual puzzle globe with the "20 years of Wikipedia" mark.
    Our usual puzzle globe with the "20 years of Wikipedia" mark.
  • A banner inspired by the Wikipedia 10 visuals.
    A banner inspired by the Wikipedia 10 visuals.

I'll wait a couple more days for additional feedback, and absent any major problems I hope to get an RfC started by the end of the week. — Wug·a·po·des​ 02:55, 22 December 2020 (UTC)

Add the stations at Template:Adjacent stations

Not a project-wide concern. Please propose at Template talk:Adjacent stations. (non-admin closure) {{u|Sdkb}} talk 03:33, 22 December 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.

Line 6, 8, 9, 17 and extension of 18 of Chengdu Metro have been opened, but the template don't update these stations, please update it.--Nrya (talk) 01:12, 21 December 2020 (UTC)

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

Cite username policy when signing up

When singing up on Wikipedia, you have to make a username, and unbeknownst to newcomers, there is a username policy that controls what kinds of names are allowed and vice versa. I've seen a ton of newcomers using prohibited types of names. A significant portion of them do not have a malicious intent; they think anyone can make a user account on Wikipedia, like accounts on YouTube, Instagram, etc. Then, an admin would message that they are subject to admin attention, scaring them. There are those who just ain't here to build, but there are those who, just as they are about to do good-faith edits, got blocked from editing for violating the policy, which they are unaware of. You could've told me!

To prevent these cases from happening again, I propose referencing the policy at the signup page, below or above the entering username bar. That way those willing to signup and are about to make a violating username can be aware. It could be small stuff like PLEASE READ OUR USERNAME POLICY TO SEE WHAT NAMES ARE NOT ALLOWED ... or big stuff, listing what names are not allowed in short, bulleted lists, like:

PLEASE DO NOT USE THESE TYPES OF NAMES:

  • Names that represent an organization
  • Names that are promotional
  • Names that imply multiple people using your account
  • Names that include a role or title within an organization
  • Offensive or explicit names
  • Confusing or long names
  • Names of people that has a Wikipedia article
  • Names intended to troll, vandalize, disrupt, advertise, or spam Wikipedia

GeraldWL 12:45, 9 December 2020 (UTC)

  • Are there really a significant number of good-faith editors being blocked on sight for username violations? Can you provide a specific, recent example of an editor immediately blocked for having, for example, a username "intended to troll, vandalise, disrupt, advertise or spam Wikipedia", who actually intended to be constructive? – Teratix ₵ 13:08, 9 December 2020 (UTC)
    WP:Usernames for administrator attention begins with a big scary pink box urging us only to report usernames guaranteed to cause an immediate apocalypse: Do not report a username merely because it “appears" promotional, etc. However, a significant number of good-faith editors create names such as "Foo people" or "WidgetCorp". As such names clearly infringe the username policy but we are explicitly warned not to report them, it might be better for everyone if new editors were encouraged to use a more appropriate name in the first place. Certes (talk) 13:19, 9 December 2020 (UTC)
    It may actually be preferable if "WidgetCorp" was not explicitly warned that organisations' names are prohibited as usernames, because, at least in my experience, the vast majority of accounts with corporate usernames like this are promotional SPAs with conflicts of interest. The username in this case acts as an obvious warning sign, inviting closer scrutiny of their editing. If an editor starts whitewashing Widget Corporation, they'll be spotted and reverted faster if their name is "WidgetCorp", because usernames like these are such an obvious red flag. Warning new editors against these sorts of representative names would reduce the effectiveness of this tactic. – Teratix ₵ 13:46, 9 December 2020 (UTC)
    Teratix, I frankly don't understand this part. Linking the username policy on the signup page and make it obvious for newcomers to see will reduce the likeliness of cases happening. It's like if you put a sign saying that there's construction ongoing and don't go near it, the likeliness of people entering the area is reduced. When you say that "The username in this case acts as an obvious warning sign," you're hinting that such usernames usually do bad-faith edits, which is a false claim. It sounds like we're purposefully not linking the policy in order to investigate bad-faith accounts, which I believe there can be various alternatives. It doesn't have to play trick on the users. It's like saying "We'll not tell anyone that we have a civility policy, see if anyone becomes uncivil." GeraldWL 03:12, 10 December 2020 (UTC)
    In my experience with accounts named after organisations, those with completely problem-free edits are overwhelmingly the exception rather than the rule. Nowhere did I say or imply that such usernames usually do bad-faith edits, merely that their edits tend to be problematic and deserve further scrutiny (one can edit in good faith but nevertheless make poor edits). It's like saying "We'll not tell anyone that we have a civility policy, see if anyone becomes uncivil." Would that be such a terrible idea? Surely anyone who needs to be explicitly directed to a civility policy before they begin interacting nicely with other editors is likely to be a net negative to the project? (I don't mean "outright conceal the existence of WP:CIVIL", just not explicitly informing new editors of what should be common sense – treating others with respect).
As others have noted, the username policy is linked from the sign-up page. – Teratix ₵ 11:13, 10 December 2020 (UTC)
Teratix, the policy is cited in the page, but not so obvious. The words "help me choose" sounds like a random name generator if you have no idea how to pseudonymize yourself. I believe there are many ways to tackle a bad-faith editor, or an editor whose edits are unconstructive, than not warning them of a policy they should've known in the first place. That's just my take, ofc. GeraldWL 11:32, 10 December 2020 (UTC)
Yes, I agree that the link's wording could be improved. – Teratix ₵ 11:34, 10 December 2020 (UTC)

So the create-account page has a link to the policy but it isn't clearly indicated. Maybe change Help me choose to What are the rules for names? ? (Hopefully other editors will have better ideas, that's the first one that came to my mind.) Schazjmd (talk) 18:11, 9 December 2020 (UTC)

Schazjmd, I would make that slightly bigger-- make it more obvious for newcomers to see. That means no brackets, as having them makes it seem useless (or at least that's just how I feel). Of course, this approach won't solve it all, but at least it helps. IMO. GeraldWL 03:03, 10 December 2020 (UTC)
  • I wouldn't give it the tone of a "warning" (so not as phrased above, with all caps and bold), but I think welcoming guidance about the username policy would be helpful to people registering an account and would save them a potential headache. Some people may not realize the implications of choosing a username that has their company's name in it, or their own name (e.g. verification procedures), etc. Levivich harass/hound 03:37, 10 December 2020 (UTC)
    Levivich, agree. GeraldWL 03:39, 10 December 2020 (UTC)
  • I can understand why the "help me choose" phrase seems a bit cryptic. I think "username guidelines" or even just "guidelines" would be far clearer wordings. However, I am reluctant to include a huge amount of detail about what usernames are and are not acceptable, mainly because the bulk of such guidance would be irrelevant to good-faith users (will a helpful editor really need to be told not to select an offensive username?), but also because problematic usernames can act as a convenient signal that a users' contributions need closer examination. – Teratix ₵ 11:27, 10 December 2020 (UTC)
Support improving the wording. Both of these sound good: "Please check our username policy" (request/instruction) or "What are the rules for names?" (a question the user could relate to, and less formal). Pelagic ( messages ) – (07:56 Mon 14, AEDT) 20:56, 13 December 2020 (UTC)
  • Support the wording change per User:Pelagic above. GenQuest "scribble" 21:58, 21 December 2020 (UTC)
  • Strongly oppose. First, nobody is actually going to read it. I bet half the established editors around haven’t read the username policy either. I’ll openly say I only know some parts of it. Totally unreasonable to link that page and expect people actually read it. The more text and links you add, the less chance people will read or click on *any* of them. Second, if someone is here just to promote I’d rather they choose a promo name and make it real easy for us over at COIN. Username violations are fine, it makes their intentions much easier to spot. If they chose a less violating username, that doesn’t magically make their intentions more pure. ProcrastinatingReader (talk) 22:36, 21 December 2020 (UTC)
    ProcrastinatingReader, it is dangerous to assume nobody will read it. Nobody will seemingly read Wikipedia's Disclaimers, but is it safe to assume nobody actually does? We expect people to "comply with the rules" but don't hand them the rules in the first place. Usernames violations are not fine as they're breaking Wikipedia's rules, so that's why I'm bringing this proposal, because it is still a policy. If the username policy is just a tool for admins to jumpscare the offending usernames, then why is there even a username policy? GeraldWL 13:45, 22 December 2020 (UTC)
    It's fairly safe to assume this. We have ~50 policies, and god knows how many guidelines, plus the MOS, and then essays which de facto are accepted as guidelines. I have not read most, and I assume most editors haven't either, and even most admins who do not work in username policy enforcement (thought: I wonder how many admins would pass a general PAG quiz).
    This is why we give warnings to people. It's why we have username soft blocks. Common sense gets you very, very far in any collaborative or social environment. And common sense tells us certain usernames are inappropriate (as they would be anywhere).
    I hope a user signing up doesn't read the username policy. If they want to spend their time reading a long wall of text, there are more helpful policies to be reading. Or, rather, essays, on how they can write content better, or just writing content, or doing literally anything else. We should stop wasting people's time by expecting them to read our legislation books, especially when they likely weren't about to fall foul of them anyway. Just as we don't expect people to read the entire statute books or the state's rules on what names are acceptable on a birth certificate (this exists, in many jurisdictions). The registrar will tell you if there's a problem. ProcrastinatingReader (talk) 14:41, 22 December 2020 (UTC)
    ProcrastinatingReader, this doesn't erase the fact that citing the policy in a visible way may help attract some. I do not guarantee the solid effectiveness of this, but if this can help even a dozen of newcomers, why not? I can understand the opposition, that through experiences of being warned is the best way of developing WP IQ. But a lot of people just want to edit immediately. Then they have to deal with an admin noticeboard BS? I think that not warning them of such wow so important policy is a symbiotic mutualism: AGF newcomers can edit without the need to deal with woa-woa-woa admins, and admins can have time for other things than to care about a small thing as a username. GeraldWL 14:48, 22 December 2020 (UTC)
    The username requirements are not just bureaucracy. They give a good indication into the kind of editing an editor will be doing. If you spend some time at eg WP:COIN you'll see how helpful usernames are in that sense. An editor who is here solely to promote is saving us a lot of time by making their intentions very clear using their username. An editor with an egregiously offensive username is obviously not here to build an encyclopaedia. Making it more obvious that they should choose a normal name will just help them keep up their crap for longer, and waste more volunteer time in determining their purpose here. If we're blocking people for small technical violations, then something should change there. ProcrastinatingReader (talk) 15:00, 22 December 2020 (UTC)
    ProcrastinatingReader, I believe that this proposal would not disadvantage that tactic, which I believe is a smart one. Here's the logic: some majority editors may look at the policy and properly learn first before making an account. Offending paid editors or COI editors, however, may not give a shit and just make an account and do 10 edits in a sandbox just to get editing privileges. As you said, not all will look at that policy-- maybe the majority of that people are the offenders. I've lived my childhood with bullies-- trust me, ignorance does not pay attention to details. GeraldWL 15:15, 22 December 2020 (UTC)
    correction: *some genuine editors. GeraldWL 15:16, 22 December 2020 (UTC)
    Most editors do not sign up with the goal of becoming prolific editors. They sign up to edit a small typo or something. That's why I signed up. I can tell you now I would not have read the username policy, and still only know the principles. An editor with the goal of getting their promo published will have cared more for policy than I, because they actually have a motive. If someone made me decide between "read the policy and sign up" or "don't read the policy and you can't edit", I'd probably have chosen the latter, simply because I wouldn't care enough to spend my time reading 3000+ words to edit a typo. ProcrastinatingReader (talk) 15:19, 22 December 2020 (UTC)
    ProcrastinatingReader, "An editor with the goal of getting their promo published will have cared more for policy than I"-- well, you just... go and see the many paid editors on Wikipedia. They don't give a shit, my man. It's the I don't care, just leave me alone making articles about my very cool furry website ideology. As I state, this change will not be fully effective in preventing good-faith editors from being blocked, but this may help. GeraldWL 15:29, 22 December 2020 (UTC)
    Do you have some examples of accounts of good-faith editors who were blocked due to username policy violations? That'd be helpful to picture the issue here. ProcrastinatingReader (talk) 15:32, 22 December 2020 (UTC)
    ProcrastinatingReader, I cannot give specific examples of such users as I'm not prepared for such threads when I posted this proposal. However, from my witnessing of various unjustified blocks, I'm sure there are victims of such that have suspicious usernames as a cause. A lot of us make an account in good faith, so if an AGF editor is warned because of violating a policy they could've been given when singing up, isn't that disappointing? By the way, the username policy is already cited in the signup page-- it's just not given clearly (rn it says "help me choose which sounds like a random name generator). I'm just proposing for a clearer text, since the current text is not correct.
    To prove the no-harm-ness of this proposal: the policy's been there for long, and we can still track down offenders. Suppose paid editors are detailed in learning policies to mask their violations. That's simply not the case. GeraldWL 15:46, 22 December 2020 (UTC)
    The argument here is that the link is too obscure to be noticed by 'good-faith editors'. The same would apply to any other editor signing up, then, including paid editors. And any change would affect anyone registering, too. I simply hypothesise that the vast majority of good faith editors would not mistakingly fall foul of the username policy. Without specific examples to go by I cannot really judge that there's a real problem here, or that this is the best solution to fix it. But I am quite confident that such a change will disrupt anti-vandalism/COI efforts. I'll drop a link at COIN for additional thoughts, in case others active there see this differently than I. ProcrastinatingReader (talk) 15:55, 22 December 2020 (UTC)
    ProcrastinatingReader, if you think that nobody will spot it, then why do you think it will disrupt anti-vandalism efforts? The fact is that many confuse Wikipedia with social media: in social media, there are no rules on your usernames, so long as it is in their character threshold. In Wikipedia, no, policy creeps you throughout. I'll bow down in this sub-thread as we arguing here continuously won't give additional value, however any editors willing to express opinions may do so. GeraldWL 16:03, 22 December 2020 (UTC)


That Non-Published Text Inside The Text-Editing-Box Be A Different Colour (Such As Green)

When editing a Wikipedia page there can be a lot of extra text (such as reference information) that isn't going to published on the finished Wikipedia page, to make the editing of the publishable text easier, it would be helpful if the non-published text was shown on screen in a different colour (such as green).

This would help to distinguish the different sorts of text from each other.

As an example of how this might work, programs used to edit software code, (including HTML webpage code) often use different colours for different types of characters, and different sections of the code being edited.

Options could include :-

  • switching off the colour(s), to show monochrome, as is currently the case.
  • allowing each user to select which colour(s) they want each section of text to be, while they edit it.

Implementing this simple change might increase the productivity of editors, as they edit Wikipedia pages.

@WikiWikiWonderful: There already multiple options for syntax highlighting when editing wikitext. Under Preferences -> Gadgets you can enable syntax highlighter or wikEd. There is also CodeMirror but I'm not entirely sure how to enable it. And if you use VisualEditor, you won't see any non-rendered wikitext at all. – Joe (talk) 16:08, 15 December 2020 (UTC)
Joe Roe, CodeMirror is available by default for all users in the editing toolbar, as a marker icon (before Advanced). Or as "Syntax highlighting" in the 'hamburger' drop down menu if you are using the 2017 wikieditor. —TheDJ (talk • contribs) 21:25, 22 December 2020 (UTC)
This proposal is about highlighting the difference during the edit. It would make it easier to find your place and keep track of what you have done. It must not interfere with syntax highlighting, which serves a different purpose. · · · Peter Southwood (talk): 05:49, 18 December 2020 (UTC)

Overhaul of talk page editing

As a reader of Wikipedia rather than an editor (or at most a very occasional editor) something I always think is a major drawback of the whole project is the bizarre and confusing system of talk page "editing", which is basically the same as editing an article and in my experience utterly unsuited to a discussion scenario.

Surely a far better method would be one more akin to an online forum, where to begin a thread, or post on an existing thread, the user simply types in a dialogue box (or whatever the correct term is) and the whole experience, especially for the uninitiated, is far clearer and simpler (and safer - no chance of inadvertently editing or deleting previous comments).

I'm sure there must be thousands of people with knowledge of a subject or other potentially useful input, whose thoughts and observations would help to improve articles, who are put off making any remarks on talk pages due to the confusing and unusual way in which comments must be added.— Preceding unsigned comment added by 2a02:c7d:93e9:b500:b09e:6a2a:d36f:9f2c (talk • contribs)

Yes! I think you’re right here. This sounds somewhat like what Flow tried to (unsuccessfully) do. Unfortunately this is something in the domain of the Foundation. It would take too much time to expect a volunteer dev to code it, and even then it’d need to be signed off by some people in product, so really this has to be a funded project from them. I’m not really sure where the right place to raise this is, but maybe someone more familiar with the product structure of the WMF may know? Probably somewhere on meta wiki. ProcrastinatingReader (talk) 13:02, 22 December 2020 (UTC)
Several initiatives such as Flow have aimed to make talk pages more accessible, especially to novice editors. However, the current method has stuck, because it's familiar to everyone who knows how to edit an article. Of course, many potential contributors are experts in their field rather than in article editing. DiscussionTools and other gadgets can provide a friendlier interface to the existing format. Certes (talk) 13:09, 22 December 2020 (UTC)
I like DT but I’m not sure it helps people unfamiliar with our format. It makes replying easier/faster but talk pages are still a hard-to-navigate clutter. ProcrastinatingReader (talk)<
@2a02:c7d:93e9:b500:b09e:6a2a:d36f:9f2c:, one significant reason for the current format is it lets you do anything you could on an article page - trying to make a system that is both user-friendly as a normal chat set-up and still has all the functionality of the current one is extremely tough. There are some current work, now quite advanced, to make at least the general communication aspect much more user-friendly. It's still a bit buggy, and needs more functionality, but much improved on 3 months ago. We'll definitely see rollout here in 2021. Nosebagbear (talk) 17:06, 22 December 2020 (UTC)
I think our current talk page system works great overall. Full stop. (There are a few areas of improvement I would suggest, that I expect will eventually become available if we don't make a sea change to a new framework, that I am keeping mum on as beyond the scope and the grain of this thread). The fact it does not resemble other forum systems is in my view a plus. A slight barrier to entry, for a fully comprehensible system once you learn it—where learning it teaches a variety of minor skills that will be needed, in any event, in more complexity and abundance to edit articles (when I say that I am taking into consideration the visual editor, and discounting it as near useless for involved editing)—helps weed out those not sufficiently interested, knowledge-sharing-hungry, and smart enough to likely ever become great editors. At the same time, our system is just as easy to learn as forums with respect to a lot of older retired academics and professionals with all their accumulated expertise, who in my experience don't share much of a Venn diagram overlap with those who are coming here used to forums and seeing a different system than they are used to, and make up a lot of new users who are actually here to build an encyclopedia.

On that last issue (despite the change to the AfC "barrier") a huge percentage of our new articles for the past few years are undisclosed paid editing, copyright violating, advertisements. That problem is so unrecognized, massive in scale and dangerous to our long term efficacy, that it's hard for me to talk about without trembling in anger and frustration that it's not the near exclusive focus of regular editors and the foundation to address. It colors everything, and making talk page editing more forum-like would, I think, contribute to that problem as a side result.--Fuhghettaboutit (talk) 17:26, 22 December 2020 (UTC)

no Disagree @Fuhghettaboutit: with due respect, I could not possibly disagree more strongly with the idea that we intentionally ought to have technical barriers to entry to weed out newcomers. The editors who we lose by having those barriers are not mainly UPEs—they're mainly women, non-tech savvy people, and the other groups we most desperately need to address Wikipedia's systemic bias. I'm fully onboard with combatting the crud that clogs up AfC/NPP, which is indeed a huge problem, but we should tackle it in a targeted way, not by abandoning our commitment to be welcoming to newcomers, which would create mostly collateral damage. {{u|Sdkb}} talk 19:56, 22 December 2020 (UTC)
You add to my point, because the issue is not tech savviness. Our system is not harder to learn than others. The issue is learning a new way to post to those who are already used to another system. People who are not tech savvy are more likely to be unfamiliar with forum systems and so it's far more likely to be neutral as to them. Meanwhile, biting is about human treatment of newcomers with kindness and patience; it's about [lack of] hostility in human interaction. I wholly reject the idea that what I am talking about even interfaces with that concept—and have spend a great deal of my time here, over 15 years, trying to shepherd new users with friendly interaction. The rub though is in calibrating the systems so that, on balance, we maximize the likelihood of getting good new users, and tend to funnel away those who have no such potential.--Fuhghettaboutit (talk) 21:26, 22 December 2020 (UTC)
Fuhghettaboutit, in my opinion anyone who thinks talk pages 'work great', should also farm their own food and be denied entry to a supermarkt, farming your own food also works great, we should make everyone do that ! —TheDJ (talk • contribs) 21:34, 22 December 2020 (UTC)
Hey DJ. Sorry, but your analogy couldn't be more is inapt in my view. It is to something almost none of us do, that is well known to be naively thought easy when it's actually incredibly complex, finicky, labor intensive and super limiting. First, there is no stand in for the unknown quantity (our system versus a forum system are two completely known quantities by most of us). Therefore, having used both extensively, I directly come to my judgement call that there's little advantage of one over the other. Additionally, using talk pages here is something most of us do everyday (are doing right now); that we actually see most people figure out fairly easily; and it is something we had to figure out ourselves when we arrived here – for me, in 2005, when it was actually more difficult. I remember. It was easy. And yet I remain relatively tech naive, and was far moreso in 2005.--Fuhghettaboutit (talk) 22:05, 22 December 2020 (UTC)

Since the OP speaks as an IP reader and not editor, we could display the talk page in a more friendly format, for users not logged in. Editing would remain as normal. The page rendering would parse the talk page and turn it into a friendly non-Wikipedian format (which is the hard part). If this irritates IP editors they should sign up for an account there are a number of things not available to IP editors this could be another. -- GreenC 17:57, 22 December 2020 (UTC)

I agree with OP, we're basically using internet-equivalent of stone-age tools to communicate, and it hugely hampers the growth of our editing pool and of the projects overall. An overhaul is so long overdue. Flow was an attempt but they gave up after that. I agree it's in the WMF's domain, and when the WMF holds trustee elections, I plan on asking the trustee candidates some questions about how much money they're going to allocate to this sort of development as compared to how much money they allocated in FY 20-21. Levivich harass/hound 18:13, 22 December 2020 (UTC)

My sense is the lack of uptake of VisualEditor was a lesson that WMF can't force the community to change even after spending lots of time and money on a project. There would have to be user choose which they prefer. Which is why my proposal above to use one style for IP readers by default for display, and the classic style for everyone else by default, and in both cases the 'editing' of a page remains the classic wiki style. A hybrid to start. After time editors will naturally ask the editing be migrated to a new style as well. Step by step is the way for large complex political changes. -- GreenC 18:40, 22 December 2020 (UTC)
People adopt new technologies quickly if those new technologies are good. Just ask Apple. Levivich harass/hound 18:44, 22 December 2020 (UTC)
Maybe, but we are not Apple selling smartphones. Again look at VisualEditor which is the best analogue. VE is great technology. -- GreenC 18:47, 22 December 2020 (UTC)
VE is not great technology, it's a poor WYSIWYG editor by modern standards. Back to talk page editing, the technology for us to communicate over the internet (better than this editing-a-text-page nonsense method we're using now) already exists. WMF doesn't have to invent anything new. Editing Google docs simultaneously without edit conflicts has been around for years. Message boards have been around for decades. What's needed from the WMF is to adapt the best existing technologies for Wikipedia's use (which it should do with a strategic partner); the WMF doesn't need to re-invent the wheel here. I don't think the community is resistant to change so much as it's resistant to change for the worse. Levivich harass/hound 18:52, 22 December 2020 (UTC)
If you're comparing the editor with Google Docs, it didn't have a legacy format problem. Word did, but Microsoft had a lot more money and incentive to make it work, and even they replaced their old legacy format with an XML-based one.
The key issue with change is, as with so many things, English Wikipedia's consensus-like decision-making process. Generally, the community tries very hard to agree on something that most editors can live with. There is a significant number of vocal editors who like using the same syntax as editing articles on talk pages. (Some of them don't follow the usual indenting conventions for talk pages, but hey, as long as they don't mind when someone else fixes it, I guess I can't complain too much.) There's a reason why linear discussion board threads remain popular on the web: you just need to find where you last left off and catch up from there, rather than trying to chase down innumerable branches that have popped up. But many people like greater freedom to post wherever they want. We'll have to see if the discussion tools initiative improves matters. isaacl (talk) 19:42, 22 December 2020 (UTC)
The Talk pages project and mw:Talk pages project/New discussion are interesting, but they're mostly convenience factors for existing editors imo. Whilst these will help new contributors too, I am not sure they address the fundamental problems. They make it easier to technically reply to a comment, but they do not make it easier for someone new to jump into the mountain discussions we have around here. They don't make finding discussions easier, or searching through them, or organising them. Some of the issue I think is the format of discussions, both software and 'social'. Social format alone can make a massive difference: compare the format of ANI to the format of AE for resolving problems; one more often ends with conclusive outcomes.
That said, they've identified some of the right issues. See mw:Talk_pages_project/New_discussion#Background. Some of this falls upon us. For example: Junior Contributors find the workflow difficult to discover. Many talk pages contain large yellow infoboxes. they, "...are so prominent they distract people from most important actions on a talk page (start a new topic, reply, edit, etc)." The WMF can't force a change here without causing drama. Within the community, trying to remove the talk page crap is an uphill battle. Maybe the foundation can create a better area in the page to host this fluff, like a button in the toolbar, and some kind of "talk page banner priority system" (info, warn, etc). They got around this on mobile by taking the decision out of the community's hands and moving it all into "About this page". Some of the issues are from a community POV, eg signing edits is not the biggest barrier for the newbie (someone else can {{unsigned}})
I think some folks in the community working with some folks in the foundation, and some connection with external experts, could lead to a good outcome here. ProcrastinatingReader (talk) 20:08, 22 December 2020 (UTC)
It's a very solve-able problem. Which isn't to say that it's easy or quick or cheap, but it's doable. WMF faces some unique challenges. Legacy is one; scale and speed are probably bigger concerns. But there are database and network architects out there who are very knowledgable and good at tackling these sorts of problems. The best ones are in well-paid jobs in the private sector, many at those big companies I won't bother naming. We need a team of those people to spend a year or two coming up with a better UI for Wikipedia editors. They need to have discussions with the community to figure out user needs, but it needs to be experienced software architects asking the questions (not community liaisons), and overseeing the dev teams. The best devs need to talk to the end users directly. It can be done, it just takes spending real money in the right way. Levivich harass/hound 20:19, 22 December 2020 (UTC)
The key issues are not technical, in my opinion, but social. At present, I believe there are enough editors who think the WMF should leave the site mostly as is (other than investing in the features and tools of interest to them, natch) that it would be unappealing to invest in a prolonged engagement with the world-wide community when there is significant doubt that the result will be accepted. isaacl (talk) 21:13, 22 December 2020 (UTC)
There’s a vocal number of people who refuse to accept a change to their workflow, but I am not convinced the majority is stubborn or illogical. I suspect (or at least hope) that if what Levivich says happened and there was a good end result, those dissenting voices would be dwarfed by those which are excited to try something better. I’m hoping the poor precedent is a mixture of this set of people + those who just dislike the implementation, not the principle. ProcrastinatingReader (talk) 21:49, 22 December 2020 (UTC)
I think it's more of a tragedy of the commons: people are happy with methods that work well for them personally, even if it causes a burden on the collective community. The thing is, collaborative editors don't want to dwarf the voices of others; they really want to find a compromise that as many people as possible can go along with (a true consensus). It's not a lot of fun arguing against long-time, valued contributors, and so people move on to other things instead. isaacl (talk) 01:39, 23 December 2020 (UTC)
  • This is already happening. The IP has a very valid point, but many of the editors above seem to have missed the link to the Discussion Tools extension being built by the WMF that seeks to tackle this exact problem and will be rolled out in the coming year. It's a waste of energy to highlight the need for the WMF to address this problem when they are already doing so. {{u|Sdkb}} talk 20:03, 22 December 2020 (UTC)
  • This is one of those ares where the Wikipedia process has failed. Editing talk pages as if they were articles leads to an exacerbation of our systemic bias towards people with technical ability, who (speaking as someone who worked in technical areas of IT for several decades myself) have very little correlation with people who can create a decent encyclopedia. This seems to be a topic where most people who think about it recognise there to be a problem, but there's little agreement on what to do about it. Phil Bridger (talk) 20:53, 22 December 2020 (UTC)
  • Hey Iridescent, any thoughts on this one? I think I've seen you comment on interface before, though not talk pages in particular. ProcrastinatingReader (talk) 22:30, 22 December 2020 (UTC)

Why would we want to make talk pages different from other pages on the site? Assuming it did lead some people to comment, we would still be better off if they became editors rather than trying to interpret what they want us to do. If they do go on to edit, they will still need to learn how to do that. --Khajidha (talk) 23:30, 22 December 2020 (UTC)

With VE? Not really. ProcrastinatingReader (talk) 23:44, 22 December 2020 (UTC)
As someone else noted earlier, VE is near useless for anything beyond correcting typos.--Khajidha (talk) 00:09, 23 December 2020 (UTC)
Why do you think that? (or, what shortcomings make it useless for you?) When I write articles I tend to prefer using VE personally (though I do often need to switch to source, mainly to edit templates). ProcrastinatingReader (talk) 13:22, 23 December 2020 (UTC)
Template editing is one major problem. Heck, link editing is much simpler in source mode, as I can edit the link itself and its pipe all at once just as easily as I would edit any other word on the page.--Khajidha (talk) 14:35, 23 December 2020 (UTC)
The Foundation semi-recently celebrated reaching 50% of first edits being made with VE, and also noted that 35% of subsequent edits by those users are made with VE. To drop from 50% to 35%, a little math quickly establishes that VE either drives upwards of 30% to quit editing completely, or that users given VE rapidly find and flee to the Wikitext editor, or some combination. They didn't supply sufficient data to distinguish which.
They want to convert mobile to default to VE. They ran a randomized test were mobile users were given either VE or wikitext editor, 50%-50%. They never released the results. The comments on the Phab task made it clear that the results were extremely bad for VE. A substantial portion of people quit before VE could even finish loading. Every time the Foundation collects data on the real world impact of VE, the data shows giving users VE has a negative impact.
Returning to the Talk page subject, the Foundation's crusade to replace Talk pages with Flow chat-boards was grossly broken. They fought for six years trying to force the project forwards, ultimately terminating development and deployment. The MW:Talk pages consultation 2019 resulted in Global Community Consensus to build enhancements on top of existing talk pages. The new MW:Talk pages project is adding easy reply links to existing talk pages, and possibly other enhancements. Alsee (talk) 03:47, 25 December 2020 (UTC)
Visual Editor is so useful for citing scientific research papers that I wouldn't use Wikipedia without it, manually citing hundreds of scientific papers would be a massive pain otherwise. Hemiauchenia (talk) 23:00, 25 December 2020 (UTC)
@Hemiauchenia: I used to rely on the Cite button in VE in source mode for that exact reason (and still use it on occasion). That Cite button Citoid. I stopped using it when I found WP:Zotero. They do the same thing, but Zotero does it better:
  • What Citoid spits out for https://pubmed.ncbi.nlm.nih.gov/32202722/:
    {{Cite journal|last=Emanuel|first=Ezekiel J.|last2=Persad|first2=Govind|last3=Upshur|first3=Ross|last4=Thome|first4=Beatriz|last5=Parker|first5=Michael|last6=Glickman|first6=Aaron|last7=Zhang|first7=Cathy|last8=Boyle|first8=Connor|last9=Smith|first9=Maxwell|last10=Phillips|first10=James P.|date=05 21, 2020|title=Fair Allocation of Scarce Medical Resources in the Time of Covid-19|url=https://pubmed.ncbi.nlm.nih.gov/32202722/|journal=The New England Journal of Medicine|volume=382|issue=21|pages=2049–2055|doi=10.1056/NEJMsb2005114|issn=1533-4406|pmid=32202722}}
  • What Zotero spits out for https://pubmed.ncbi.nlm.nih.gov/32202722/:
    {{Cite journal| doi = 10.1056/NEJMsb2005114| issn = 1533-4406| volume = 382| issue = 21| pages = 2049–2055| last1 = Emanuel| first1 = Ezekiel J.| last2 = Persad| first2 = Govind| last3 = Upshur| first3 = Ross| last4 = Thome| first4 = Beatriz| last5 = Parker| first5 = Michael| last6 = Glickman| first6 = Aaron| last7 = Zhang| first7 = Cathy| last8 = Boyle| first8 = Connor| last9 = Smith| first9 = Maxwell| last10 = Phillips| first10 = James P.| title = Fair Allocation of Scarce Medical Resources in the Time of Covid-19| journal = The New England Journal of Medicine| date = 2020-05-21| pmid = 32202722}} Levivich harass/hound 04:41, 26 December 2020 (UTC)

Clearly mark talk pages for deceased, retired or indefinitely banned users

Formerly named “Clearly mark talk pages for deceased, retired or blocked users” – minnow Self-minnow

I feel sorry when I see users post questions to former users, and when I see the reams of automatic notices that clutter the talk pages of former users. (Example: User talk:Od Mishehu.) Both are a waste of time and resources. So I propose to add a template to any such user page that alerts both users and bots that the former user won't respond and very likely not read those automated notices anymore. In the event that a user still wants to see those automated notifications, there could be a parameter in the template to allow bots to continue posting notices. (By “user” in the previous sentence, I mean either the former user, IOW, the owner of the talk page, if they has the right to edit the page, or someone else who has a legitimate interest, such as a relative of a deceased user.) It may also make sense to stop archiving. ◅ Sebastian 10:41, 25 December 2020 (UTC)

  • Would {{Not around}} help with at least the marking part? Stopping archiving/automated messages might be more difficult, since there are all sorts of ways those happen. {{u|Sdkb}} talk 03:47, 26 December 2020 (UTC)
  • For bots, you can use {{nobots}} and Category:Wikipedians who opt out of message delivery. For users who are confirmed to be deceased, we have {{deceased}}; otherwise, if they just haven't edited for a long time, then we can use {{not around}} as Sdkb suggested. I am disinclined to add any kind of user page template just to say that a user is blocked because it would essentially be a badge of shame; see Wikipedia:Templates for discussion/Log/2019 April 17#Template:Blocked user for a recent example that got deleted because it was a net negative. In Od Mishehu's case, he already has {{sockpuppeteer}} on his user page, and anyone that clicks "edit" on a blocked user's talk page should already get a red banner above the edit window that explains that the user is blocked. Mz7 (talk) 04:06, 26 December 2020 (UTC)
    Oops, I meant indef banned, not (temporarily) blocked. trout Self-trout. For those, we already have {{Banned user}}. And the red banner is enough; it just didn't occur to me that people wouldn't read it. minnow Self-minnow ◅ Sebastian 12:32, 29 December 2020 (UTC)
  • @SebastianHelm: You can't stop archiving, once a page becomes too long MediaWiki can no longer handle it. The automated notices for deletion/discussion can be useful for talk page stalkers. — Alexis Jazz (talk or ping me) 11:55, 27 December 2020 (UTC)
    We should primarily improve the experience for the average user, and not pile up ballast just for a small group of users who might or might not find it somewhat useful. Page length: The best solution, then, would be to archive everything up to the message that announces the end of usership (that is, e.g. the announcement of death or of a ban, if it exists. Otherwise, archive everything on the page). That would avoid cases like Od Mishehu's talk page, where the one message that mattered was shoved to the archive by the weight of 10 moot automated messages. ◅ Sebastian 12:32, 29 December 2020 (UTC)
    @SebastianHelm: where the one message that mattered was shoved to the archive by the weight of 10 moot automated messages Content above the __TOC__ is never archived AFAIK. — Alexis Jazz 12:46, 29 December 2020 — continues after insertion below
    Sorry if that wasn't clear; I meant User talk:Od Mishehu/Archive17#June 2019. ◅ Sebastian 13:10, 29 December 2020 (UTC)
    Newsletters and announcements to vote on stuff are indeed useless, but for any user in good standing there is usually someone who is willing to comment when deletion of their stuff is proposed. — Alexis Jazz (talk or ping me) 12:46, 29 December 2020 (UTC)
    Good point; stuff that others may take over, such as prod notices, already account for about 50% of the text on average, so I now see the use for Wikipedia of your point that I thought was only useful for a small group. (I moved your message here to preserve context; hope that's OK with you.) ◅ Sebastian 13:10, 29 December 2020 (UTC)
    Maybe the best solution would be if we had disappearing messages (after a given time or after a given number of new sections is added). ◅ Sebastian 13:18, 29 December 2020 (UTC)

Thank you all for your answers. I now realize we already have templates for almost all cases; it's just that they often aren't used on user talk pages, but they can and have been used there, too. To summarize, we have:

The gist of my proposal therefore boils down to place those templates on user talk pages by default. Most of these already contain Category:Wikipedians who opt out of message delivery, so we already have a technical solution for my problem with the piling up of messages. The one exception is {{Banned user}}, so that should be discussed there. (Forgive me, though, for pointing to this extreme example of piled up messages.) But maybe that isn't just an on-off decision: At least for deceased users we might, per ad mortuos nil nisi bonum, only list positive messages such as the DYK messages at User talk:Halibutt. ◅ Sebastian 12:32, 29 December 2020 (UTC)

Wiki App Idea

Duplicate post — see Wikipedia:Village_pump_(idea_lab)#Wiki_App_Idea — GhostInTheMachine talk to me 22:12, 29 December 2020 (UTC)

X year in Association football

In my opinion it would be better inser the finalist and the score of each final of international club competitions and delete the column of defending champions Dr Salvus (talk) 18:09, 29 December 2020 (UTC)

@Dr Salvus: It's not fully clear what you are proposing. I would find a less generalized forum to make your suggestion, and articulate it more fully with links etc. {{u|Sdkb}} talk 21:12, 30 December 2020 (UTC)


I mean for example the article "2020 in association football" or "2021 in association football" etc.

Succession boxes for US Presidents

No consensus to omit succession boxes from US presidents' BLPs. Editors were evenly split, with seven !votes on each side. Editors in favor of omitting succession boxes made the argument that the boxes are redundant with parameters that exist in the infobox. Those in favor of including succession boxes argued either that they personally found them useful, or that they are particularly useful for listing the succession of secondary offices that may not be appropriate to include in the lead. A proposal to flatten the succession box format drew wide support, although it was not included as part of the advertised RfC. signed, Rosguill talk 22:06, 30 December 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.

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)
  • 1. Navigation features become confusing when they are not consistent across a set. Option 3 is kind of boneheaded; there is no US President for whom succession information is irrelevant (or even less relevant than for any others), so the "flexibility" argument simply makes no sense. I think someone just copied it wholesale from arguments about infoboxes, which are a very different kind of template.  — SMcCandlish ☏ ¢ 😼  03:54, 8 December 2020 (UTC)
  • 1 -- Such boxes seem somewhat more detailed than the ones at the top of the article.73.110.217.186 (talk) 04:39, 8 December 2020 (UTC)
  • 2 - The boxes are redundant with similar links in the infobox and in the footer of the navbox. We don't need the same thing in the article 3 times! Kaldari (talk) 15:09, 8 December 2020 (UTC)
  • 2 ProcrastinatingReader makes the most sense. Agree 100% with his sentiments. GenQuest "scribble" 14:24, 17 December 2020 (UTC)

Flatten your succession boxes and/or abs

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).
  • Agreed. The current boxes take up too much space, for no good reason. Thanks for the demo, cobaltcigs.  — SMcCandlish ☏ ¢ 😼  03:51, 8 December 2020 (UTC)
  • Comment - It may make sense to add a 4th column for those date ranges. It could be in the same place it is now. Just that having a column would align the dates nicely. –Novem Linguae (talk) 04:41, 8 December 2020 (UTC)
  • Good idea - If we're going to keep succession boxes, this is a much better format for them. Kaldari (talk) 15:14, 8 December 2020 (UTC)
  • Support - These boxes take up space and I like the alternative format. If there is a format we can adopt here and there, I'd do it. I see an analogous thing when big boxes are inserted with lists of formally important people, like this one. I squeeze those down when I can so they take less vertical space. Good thought, user:cobaltcigs. -- econterms (talk) 02:32, 13 December 2020 (UTC)
  • Support displaying similar information using less space. We could even move the preceded/succeeded by headers into the top band beside the "Offices of Joe Schmoe" title. Certes (talk) 12:57, 13 December 2020 (UTC)

Expansion of scope: succession boxes

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

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)

Closure

We need an administrator to close this expired RFC. GoodDay (talk) 12:35, 19 December 2020 (UTC)

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

Allow linking to the "submitted" draft article available for review

To avoid a WP:TALKFORK, please hold discussion at Wikipedia talk:Manual of Style/Linking#Semi-protected edit request on 7 January 2021. (non-admin closure) {{u|Sdkb}} talk 19:18, 7 January 2021 (UTC)

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

Wikipedia policy and guidelines should be solution-oriented and future-proof the edits by being oriented towards "non-alpha" editors (IPs and occasional editors) who contribute the majority of the content, hence they are the core and most important editors/stakeholders. Whereas policies and guidelines are designed by the and for the alpha editors who love to argue, waste time in pedantic debates, nitpick on minor thing to turn mole into hills, big turn off for the "core contributors" (IPs and occasional editors) of the wikipedia, who gets disgusted and walk away.

Please amend the MOS:DRAFTNOLINK guideline in such a way that it must permit the linking of draft articles that have been submitted for the review. You can still impose restriction on linking the sandbox articles or the draft articles that have not been submitted for the review. You can read the benefits and arguments in favor of this proposed edit here and more detailed benefits and concerns here. I was redirected to MOS:LINKING here and to VPR, what a wild goose chase, down the people in time-wasting stuff. Please note that the similar concerns have been already documented by numerous other editors Wikipedia:Why Wikipedia is not so great, my proposed edit mitigates some of those concerns. To start with, just allow linking to the submitted drafts as requested here. I will not be monitoring this talkpage here, I have also stopped monitoring talkpages where I had submitted my proposals to edit MOS guidelines. I have already wasted too much time on this bureaucratic hurdle/issues. I leave it to the other members of the community here to tke this to some logical conclusion. Big thank you to you all for your patience to volunteer your time here to help others. 58.182.176.169 (talk) 15:43, 7 January 2021 (UTC)

You can link to the article without the Draft: prefix. Once the draft is accepted, the red link will become blue. Allowing links to the draft space from the main space would aggravate our problem with spammers and undisclosed paid editors. MarioGom (talk) 18:22, 7 January 2021 (UTC)
Further discussion should happen at the linked-to discussion, Wikipedia talk:Manual of Style/Layout § Semi-protected edit request on 7 January 2021. davidwr/(talk)/(contribs) 18:35, 7 January 2021 (UTC)
Do you mean Wikipedia talk:Manual of Style/Linking#Semi-protected edit request on 7 January 2021? —  HELLKNOWZ   ▎TALK 18:47, 7 January 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Bring back Superprotect protection

I believe this would help the wiki a lot. It wasn't completely useless. I feel like all pages with Wikipedia:(Article Name) need it to prevent vandalism. Of course not pages that contain user-generated content such as the Village Pump section.

This is really just a suggestion. SoyokoAnis (talk) 04:01, 8 January 2021 (UTC)

Unless you are implying administrators are vandals (which is clearly not the case), then superprotect is irrelevant here. * Pppery * it has begun... 04:03, 8 January 2021 (UTC)
Superprotection was a WMF-implemented feature that allowed staff to prevent even administrators from editing certain pages. Are you sure this is the feature you are referring to? – Teratix ₵ 10:21, 8 January 2021 (UTC)
Oh, no. Administrators aren't vandals I just feel like those pages shouldn't be edited by anyone except Wikimedia Staff. Yes, that is the feature I was referring to. SoyokoAnis User Page 22:12, 8 January 2021 (UTC)
Why? This is a wiki, after all. * Pppery * it has begun... 22:17, 8 January 2021 (UTC)
@SoyokoAnis: The Foundation pretty much leaves it to the "local Wiki editors" for things that don't involve multiple projects or things external to the project, like legal issues. What you are asking would represent a huge philosophical shift. The only time I can see it being used would be for OFFICE actions and possibly for policies with legal implications, but it's not needed there because we can trust administrators to not do anything that goes against an OFFICE edict. Besides, the WMF has enough work to do, they don't need to be wasting time monitoring {{protected edit}} requests on local Wikis. Oh, I can think of one place where this would come in handy: If a court ordered the foundation to prevent administrators from editing a page. But I don't see that happening. davidwr/(talk)/(contribs) 22:19, 8 January 2021 (UTC)
Given that it's not the WMF's job to participate in content disputes unless there are legal reasons to do so, can you show an example where superprotect could have been useful if it was available? Majavah (talk!) 23:06, 8 January 2021 (UTC)
@SoyokoAnis, I think you are looking for WP:FULL protection, which already exists. WhatamIdoing (talk) 23:26, 8 January 2021 (UTC)

Blocking Request for User:IN

Incorrect venue. Please see WP:ANI or similar. (non-admin closure) {{u|Sdkb}} talk 09:29, 10 January 2021 (UTC)

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

Hey admins, User:IN is continuously doing useless edits, against WP:NOTHERE policy. I think a blocking request is needed. He/She was doing the same thing like this in Chinese Wikipedia and is in blocking status now. -- BrandNew Jim Zhang (talk) 14:44, 8 January 2021 (UTC)

Examples? --Golbez (talk) 15:55, 8 January 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This is alarming.

WP:SNOW not happening — Preceding unsigned comment added by RoySmith (talk • contribs) 02:29, 12 January 2021 (UTC)

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

See these:

I think WP should do a blackout, and also lock up the site (disable access to upload, download, and to view content pages, but not deleting them) unil this is protested. The notice and staydown regime pretty much tells sites to “police harder” which is impossible at scale else they'll be sued. — Preceding unsigned comment added by Joeleoj123 (talk • contribs) 23:00, 22 December 2020 (UTC)

But see Stop Online Piracy Act#Wikipedia blackout. Tony Tan · talk 08:32, 27 December 2020 (UTC)
  • Oppose. Wikipedia should act if and only if three conditions are met: a) that it materially affects Wikipedia now or in the predictable future, b) that it is politically feasible to stop, and c) that Wikipedia's action might be influential on the result. My understanding is that neither (b) nor (c) apply because it's part of an omnibus spending bill that's already passed Congress, and although I am ignorant enough of the specifics enough to be agnostic about (a), I'm not certain it applies either. I don't like the result here, but I don't think this is one of the few cases where Wikipedia should intervene. {{Nihiltres |talk |edits}} 00:48, 23 December 2020 (UTC)
Joeleoj123, this is a fait accompli. Dont see the point in blacking out. If it becomes a problem we can move the encyclopedia. —TheDJ (talk • contribs) 11:36, 23 December 2020 (UTC)
@Nihiltres and TheDJ: You seem to be confusing the CASE Act and felony streaming bill (both of which indeed look like faits accomplis at this point) with Senator Tillis' proposed Digital Copyright Act. The latter looks much more far-reaching (involving major changes to the DMCA, which Wikipedia and Commons rely on heavily) and is still very much up for discussion, as the EFF post linked above stresses ("This proposal is far worse than SOPA/PIPA, so our coalition will have to be stronger and more united than ever before"). Regards, HaeB (talk) 13:52, 27 December 2020 (UTC)

The proposal to charge felony for copyright infringement doesn't apply to us. However, the section 230 reform does affect us. The Wikimedia Foundation has already taken measures about it, and I would support a blackout on it. --NaBUru38 (talk) 12:22, 29 December 2020 (UTC)

  • Wikipedia is not a platform for political advocacy. ~ ToBeFree (talk) 23:52, 30 December 2020 (UTC)
  • Oppose until someone can show us that the final text is an existential threat to Wikimedia projects. --MarioGom (talk) 14:11, 4 January 2021 (UTC)
  • Oppose, obviously. "disable access to upload, download, and to view content pages" -- literally the opposite of Wikipedia's purpose. —  HELLKNOWZ   ▎TALK 14:17, 4 January 2021 (UTC)
  • Oppose per Nihiltres. I would support adding Wikipedia should act if and only if three conditions are met: a) that it materially affects Wikipedia now or in the predictable future, b) that it is politically feasible to stop, and c) that Wikipedia's action might be influential on the result. to a guideline or essay somewhere. — Wug·a·po·des​ 22:24, 4 January 2021 (UTC)
  • no...nO...NO...NO! and, once again, NO! GenQuest "scribble" 20:57, 7 January 2021 (UTC)
  • Oppose. Did we mention NO? Wikipedia is apolitical and should never be used as a platform for political advocacy regardless of issue. I would apply this even to "existential threats" – if the project's continued success is so tenuous that it rests on messages delivered via its encyclopedia, it's probably not worth saving. I strongly doubt that it is. Leave the politics to the WMF. ―Mandruss ☎ 21:30, 7 January 2021 (UTC)
  • Oppose. The situation around SOPA (which was an existential threat to Wikipedia) should be the bare minimum for a blackout. As much as it might seem tempting to join the latest outrage about misbegotten-Internet-law du jour, politicising Wikipedia so blatantly would sacrifice what goodwill we have unless it is literally a matter of "We can't function if this passes". As noted above, the more troubling parts are still up for discussion in any case, so discussion of any sort of blackout is premature at this point. Legislatures not debating a crisis move at the speed of smell. —A little blue Bori v^_^v Takes a strong man to deny... 22:01, 7 January 2021 (UTC)
  • Oppose per my essay at Wikipedia:Avoid political banners. Mz7 (talk) 07:04, 10 January 2021 (UTC)
  • Moral support - I too agree with those who've said that they aren't sure that this would impact Wikipedia or any WikiMedia projects. I also think that this should be considered at Meta for a larger audience than just English Wikipedia - ex: other languages, and other projects. That being said, iff a WMF lawyer expresses concern that this could negatively impact WMF projects, I think it should be considered and implemented. The WMF's goal/vision/projects areinherently political - they are for "free" knowledge and content. This inherently delves into copyright/patent/etc laws, which is inherently political. Thus, by definition, Wikipedia already is political - so any argument that "keep wikipedia apolitical" is inherently nonsense. Regards -bɜ:ʳkənhɪmez (User/say hi!) 02:10, 12 January 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

PROD consensus

Clear SNOW consensus that (standard) PROD can remain single-objection removed, with AfD handling consensus cases Nosebagbear (talk) 13:01, 12 January 2021 (UTC)

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

In the PROD process once a single person objects with a valid reason, it's a keep. The proposal is that it must be a consensus of this. Instead of removing all templates, they place a keep template with a reason. An admin evaluates the reason and removes endorsed templates. If there are a "negative" amount of endorsed templates for a whole hour, it's a keep. If this never happens for the whole week, it's a delete. — Preceding unsigned comment added by Nononsense101 (talk • contribs) 17:54, 10 January 2021 (UTC)

This is what AfD is for. The point of PROD is to action uncontroversial deletions without discussion. * Pppery * it has begun... 18:03, 10 January 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

BLP categories

A discussion has been started at Wikipedia talk:Biographies of living persons about potential additions to the BLP policy on categories. Please join the discussion there. Thank you. —Sangdeboeuf (talk) 23:45, 14 January 2021 (UTC)

Template:Class/icon Update

See also: Template talk:Class/icon § Edit Request - Update Icons.

There was first a discussion on the template talk page where it was made clear that due to the number of transclusions and the protection required on each icon, that this should be brought here.

Some of the icons displayed by this template are not using the "round icon" design or are not using a specific icon at all (such as draft). I am proposing that the following icons be updated to conform with the majority. Some of these icons are also used by xTools but not by this template creating an unneeded disconnect for page classes.

  • SL-Class Article: ->
  • Non-Article Page: ->
  • Draft Page: ->
  • Category: ->
  • Media File Page: ->
  • Portal Page: ->
  • Project Page: ->

Terasail[✉] 19:35, 31 December 2020 (UTC)

  • Sounds fine. The new icons look better to me, and bring this in line with the symbols I've seen used elsewhere. I'm not sure this needs a Village pump discussion—it's a nice bit of tidying, but it's largely not reader-facing. If we're doing work in this area, I'd like to see us focus on carrying through with the GA/FA topicon redesign, which has acquired a mandate but is now sitting at the graphics lab waiting for proposals to be submitted and an organizer to coordinate the process. {{u|Sdkb}} talk 23:58, 31 December 2020 (UTC)
  • Looks good to me. --MarioGom (talk) 14:08, 4 January 2021 (UTC)
  • Support. Looks like improvement, can't majorly fault any of the changes. I am a bit concerned about the minus in the non-article page icon compared to say . —  HELLKNOWZ   ▎TALK 14:22, 4 January 2021 (UTC)
  • Support. The replacement symbols indicate the information more clearly and have a more unified meaning. I agree with Hellknowz about the minus symbol for NA page, perhaps a centred dot, question or having nothing inside the border would be better? --Xurizuri (talk) 12:18, 12 January 2021 (UTC)
Strong support with the exception of the start-class one, which i very weakly oppose. JJP...MASTER![talk to] JJP... master? 17:06, 13 January 2021 (UTC)
  • Support per above. ~ HAL333 22:17, 13 January 2021 (UTC)
  • Support all seem to be improvements, though I also weakly oppose the start class one as well – I would think the orange is good for attracting attention to an article in need of expansion. Also, the icons are so small that in the proposed start class one, the incomplete bullet list idea is virtually unseeable. Aza24 (talk) 09:24, 16 January 2021 (UTC)

New logo - link?

The interesting new logo that's appeared for the 20th anniversary in the top left hand corner. Why does it just link to Main page, instead of to Wikipedia:20th anniversary or [2]? --Dweller (talk) Become old fashioned! 12:50, 15 January 2021 (UTC)

I think for a day this is a good idea, but our Wikipedia:20th anniversary needs some polishing possibly and the link going to the metawiki page may be a bit confusing. Noting, though, that since it's now the 15th we'd have to get consensus pretty quick to implement this? How do we change the logo link, anyway? If it naturally requires a software patch I don't think we have any more backport windows till Tuesday -- possibly we can get it done sooner per this if there's consensus and a wiling sysadmin? There's also the JavaScript route. ProcrastinatingReader (talk) 12:56, 15 January 2021 (UTC)
Side note: Isn't Java now deprecated? GenQuest "scribble" 19:11, 16 January 2021 (UTC)
Java != JavaScript. And, Java is certainly not deprecated, though its use as a web applet language has diminished for various reasons. You may be thinking of Flash, which is effectively dead as of this month. --Izno (talk) 19:33, 16 January 2021 (UTC)
Yes, that was it. Thanks. GenQuest "scribble" 19:43, 16 January 2021 (UTC)

Reform Category:Common vulnerabilities and exposures into rcat template

This category consists entirely of redirects at the moment. I think it would be more appropriate to rename the category to something like Category:Redirects from CVE IDs, and create a rcat template, {{R from CVE}}, that uses it. Given the relatively small number of pages included in the category, this shouldnt be too big of a task. --C o r t e x 💬talk 02:43, 1 January 2021 (UTC)

@Cortex128:  Done –MJL ‐Talk‐☖ 01:53, 17 January 2021 (UTC)

Rename Trecento/Quattrocento/Cinquecento/Seicento/Settecento categories

MOVED TO WT:CATP
OP has posted instead at WT:WikiProject Categories § Rename Trecento/Quattrocento/Cinquecento/Seicento/Settecento categories. YorkshireLad  ✿  (talk) 15:27, 18 January 2021 (UTC)
...discussion of which is now at Wikipedia:Categories for discussion/Log/2021 January 18#Category:Trecento composers_etc.

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

The following categories should, in my opinion, be replaced with their plain English equivalents:

The English titles are way more informative. Someone who doesn't know the Italian art of this period won't have to guess what Seicento means. It's worth noting that not even the Italian Wikipedia uses this rather cryptic convention: it:Categoria:Compositori italiani —capmo (talk) 14:01, 18 January 2021 (UTC)

Capmo, I'm inclined to agree, but I think you want to post this at WP:CFD: the "D" is for "Discussion", not just "Deletion".  :-) YorkshireLad  ✿  (talk) 14:22, 18 January 2021 (UTC)
Oh, thanks YorkshireLad! I was looking for that exact page, but couldn't find a link to it anywhere on the Community portal or the Village pump. Should I delete this topic from here and create another there? —capmo (talk) 14:51, 18 January 2021 (UTC)
On a second thought, WP:CFD doesn't seem to be the best place for longer discussions. I created a new entry at WP:CATP instead. —capmo (talk) 15:11, 18 January 2021 (UTC)
Capmo, Fair.  :-) YorkshireLad  ✿  (talk) 15:24, 18 January 2021 (UTC) I'll mark this as closed. YorkshireLad  ✿  (talk) 15:24, 18 January 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Before deleting articles make a consensus

Explained below. — xaosflux Talk 19:50, 20 January 2021 (UTC)

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

This is for administrator deleted articles(speedy deletions) not AFD. That way people can discuss deleted articles before they can be deleted. That way hours of work doesn't get ruined.

I know it says somewhere that it doesn't matter how much time or effort it took to make articles but this would really be helpful for some. SoyokoAnis 03:50, 19 January 2021 (UTC)

That's why it's called speedy deletion. You can discuss it afterwards on the admin's talk page or at WP:DRV. Also, no work is lost because any content can be restored (you can ask any admin for a copy, or the page can be restored either as an article or draft at DRV). – Finnusertop (talk ⋅ contribs) 05:23, 19 January 2021 (UTC)
@Finnusertop:, okay! I didn't fully understand it. Thanks! SoyokoAnis 21:58, 19 January 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_175&oldid=1142560808"