Wikipedia:Village pump (proposals)/Archive 175

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

talk ) 00:14, 19 December 2020 (UTC)

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)
  • This is a general discussion, not specific to the one instance you are referring to. -bɜ:ʳkənhɪmez (User/say hi!) 23:14, 14 November 2020 (UTC)
• Wait until the successor has actually succeeded. While I respect that there is an "heir apparent" field in royalty infoboxes, that's a position in its own right which that person currently holds while the other person is the king/queen. An heir apparent is more similar to a vice president, chief of staff, or other position which is held simultaneously - not a successor where the transfer happens. Someone is not "succeeded by" another because of a vote, or a promise, or a claim, or a resignation... they're succeeded by someone when someone else takes the position they currently hold. Until there is another (obviously different) person in an office, they have not been succeeded, and many things can (and in history have) changed the course of what appeared to be an "obvious" succession. -bɜ:ʳkənhɪmez (User/say hi!) 23:14, 14 November 2020 (UTC)
• Do not wait. The entry can always be corrected after, if the presumptive successor does not take office. --Checco (talk) 05:40, 16 November 2020 (UTC)
• Wait per TFD and Springee. -- Guy Macon (talk) 19:01, 16 November 2020 (UTC)
• Wait: It's been our long-standing habit to wait (which has only changed in recent months, and without consensus). I find that EddieHugh is completely correct (like Berchanhimez), and PackMecEng speaks rightly: "update when the transition occurs", not before. (On another note, I also find the recent use of "Outgoing", redirecting to "Lame duck" for "status" of incumbents to be extremely troubling, but that can be discussed later.) — Javert2113 (Siarad.|¤) 01:15, 17 November 2020 (UTC)
• Wait, and add a |to_be_succeeded_by= field (that nobody will ever care enough about to use for anything other than the United States presidential election). jp×g 09:52, 20 November 2020 (UTC)
  • I think this is the best option. I'd call it |successor_elect= you only have to remove the |_elect= upon succession. Eccekevin (talk) 01:18, 21 November 2020 (UTC)
• Don't wait per below. Honestly can hardly believe this is a discussion that's happening. Therequiembellishere (talk) 00:57, 21 November 2020 (UTC)
• Wait and don't add anything. Also, this is
  WP:CRYSTAL; you don't even know if an elected successor will take office, until they do. Mathglot (talk
  ) 09:37, 21 November 2020 (UTC)
• Hidden form - See my compromise (below) in discussion section. GoodDay (talk) 17:21, 21 November 2020 (UTC)
• Wait and create a |successor_elect= field As proposed also by User:JPxG, see below for rationale and discussion.Eccekevin (talk) 21:05, 21 November 2020 (UTC)
• Wait until the successor actually takes office. In the case of the President of the US, succession is unknowable. Currently, Trump’s official successor is still the Vice President (Pence)... with the Speaker of the House (Pelosi) after that (and so on down the line of succession).

  This, of course, completely changes if Trump lives to January 20th, when Biden (or, if HE dies, Harris) assumes office.

  Yes, chances are extremely good that Trump’s actual successor in office will be Biden... but we won’t know until it happens. It COULD be Pence, or Pelosi, or Harris, or even an unknown person appointed into the succession (think of Gerald Ford). Shit happens, and it being 2020, I would not be shocked if it did. Blueboar (talk) 21:26, 23 November 2020 (UTC)

• Wait. Biden is almost certainly Trump's successor, but if he were to drop dead in the middle of his inauguration, before completing his oath for office, he isn't. No reliable source can guarantee that Biden is Trump's successor. 147.161.9.152 (talk) 15:35, 24 November 2020 (UTC)

  The RfC is not about Trump/Biden specifically, and it will not affect Trump/Biden alone, so I think it's misleading to talk about that one case. ―Mandruss ☎ 23:02, 24 November 2020 (UTC)

  It is an example... the same arguments can be made any time the Presidency is about to change hands (the one possible exception might be when a sitting Vice President runs for the presidency and is elected ... as he/she would be BOTH the designated successor through rules of succession AND the expected successor through election). Blueboar (talk) 01:51, 30 November 2020 (UTC)

  Even then, the VP could die before taking office. 147.161.14.234 (talk) 15:14, 30 November 2020 (UTC)

• Don't wait. This discussion is honestly counterproductive and is wasting time. This has been the standard for years and for some reason someone has an issue with it? I don't know who this person is but this issue can always be corrected besides it's good to have this filled because when people are looking at the page and might wonder after seeing the election results "Where's the successor?". It also helps to be prepared as all that needs to happen come January it to remove the "elect" at the end of the name. Also @Eccekevin: you are engaging in what looks to be edit wars with other users regarding this RFC which is based on my understanding not final. You need to stop because other users are going to add them back and based on your words you are doing this based on a guideline which is currently in question in this very discussion which appears to be not final in any way shape or form. Until this RFC is resolved the articles should remain the same as they were prior to this discussion until a compromise can be reached. On election pages and the 117th Congress page we already list the successors as taking office during that Congress because that's just the way its been for years and nobody is questioning that for some odd reason but they are questioning this which baffles me. Again leave the articles the way they were until someone comes up with something. Also if a consensus was already reached someone let me know cuz I have not the closest idea what has been decided yet. Wollers14 (talk) 03:52, 25 November 2020 (UTC)

  for some reason someone has an issue with it? I don't know who this person is

  In this RfC, so far: Mandruss, The Four Deuces (TFD), Springee, EddieHugh, Coolcaesar, Enos733, PackMecEng, Berchanhimez, Guy Macon, Javert2113, JPxG, Mathglot, GoodDay, Eccekevin, Blueboar, 147.161.9.152.

  At the Trump article, although specific to that case alone (not counting users already mentioned): Tytrox, MelanieN, Ivanvector, Wugapodes, Jack Upland, Scjessey, Calidum.

  Now you know who "this person" is. Every one of them was aware of the precedent that you claim is a "standard". If you're asking who had the unmitigated gall to take this to the community to test whether there is in fact a community consensus for your "standard", that would be me. ―Mandruss ☎ 04:33, 25 November 2020 (UTC)

  Please come to the comments section. We can talk there. Wollers14 (talk) 05:59, 25 November 2020 (UTC)

• Wait. The current office holder may resign, die, or be incapacited before the scheduled end of their term in office, and the elected successor may die or be incapacited before being sworn in or otherwise assuming the office. Space4Time3Continuum2x (talk) 17:20, 26 November 2020 (UTC)
• Wait Per WP:CRYSTAL, outgoing members of Congress have resigned during the lame-duck period (between the election and the new Congress on 3 Jan), and, in at least
  one case I know of, the member-elect had died during said period; either situation would render the election-projected date of the successor's installment or even their identity incorrect. This discussion is counterproductive / waste of time is moot since this RfC was allowed to be run. CaradhrasAiguo (leave language
  ) 18:04, 26 November 2020 (UTC)
• Don't wait sure, the elected successor isn't guaranteed to take over, but that's what will happen in the vast, vast majority of cases, and I don't see a problem with adding it, possibly with an "(elect)" or "(presumptive)" suffix afterwards if necessary. In high profile cases such as POTUS there won't be any problem with getting people to remove the suffix when the successor takes office. Hut 8.5 18:24, 26 November 2020 (UTC)
• Don't wait. Putting successors elect seems to be a long standing practice and there doesn't seem to be an adequate reason to change it. Doing so would require a long term overhaul. — Preceding unsigned comment added by 73.110.217.186 (talk) 19:20, 26 November 2020 (UTC)
• Wait per
  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)

@

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)

  @

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

  @

  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)

• This is the type of issue I mentioned before. The confusion probably comes from the fact that a decision hasn't been officially made yet.73.110.217.186 (talk) 05:27, 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)

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)

Wikipedia:Operation Enduring Encyclopedia? —⁠andrybak (talk

) 08:51, 19 December 2020 (UTC)

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)

@

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)

• I'd like to add one puzzle piece to the right of the Ethiopic (at the top right). It would be barely visible, but symbolizes that over twenty years, we have added to the sum of human knowledge by bringing so much encyclopedic content to the world. VanIsaac_WS^cont 03:56, 30 November 2020 (UTC)
  • That's an interesting idea - is there a single character version of "20" in any language that could be used? This could require a veritable bolting through however, since to get it used, it has to jump through a bunch of hoops on the WMF's side. Not that I suppose lacking the trademark on it is a concern for a one-off. Nosebagbear (talk) 10:37, 30 November 2020 (UTC)
    • Hebrew does, כ.--Wehwalt (talk) 11:04, 30 November 2020 (UTC)
    • There are dozens of options for number characters, including
      Aryabhata numeration, Hebrew gematria, Greek numerals, Babylonian cuneiform numerals, etc. I would like to keep the tradition of using an approximation of "wi" like the Tocharian "wi/vi" with the fremdzeichen form of "w" - . VanIsaac_WS^cont
      12:47, 30 November 2020 (UTC)
      • It strikes me that a stylized XX to emphasize the top half, which could be made to resemble a W, might be good.--Wehwalt (talk) 13:59, 30 November 2020 (UTC)
      • Pulling from various articles and such... Armenian Ի, Arabic ك, Attic/Greek ΔΔ, Eastern Arabic numerals ٢٠, Egyptian 𓎆𓎆, Aegean 𐄑, Phoenician 𐤘, Mongolian ᠒᠐, Ethiopic ፳, Glagolitic Ⰻ, Gothic 𐌺, Burmese ၂၀, and Hebrew כ as mentioned above... Plus, there are some languages that use a single character for twenty the word, like 廿. I think there are enough individual symbols meaning twenty to cover the globe, if people like the sound of that. --Yair rand (talk) 09:30, 8 December 2020 (UTC)

    20

    二十

    XX

    0x14

    What else? Aasim (talk) 17:48, 30 November 2020 (UTC)

• I really like this idea. What can we do to make this happen? It's about a month away. Tony Tan · talk 09:36, 6 December 2020 (UTC)
• Sounds good to me, too. As for what to do to make it happen, people with graphics skills should probably propose their designs and let us see them. Quickly.  — SMcCandlish ☏ ¢ 😼  04:55, 8 December 2020 (UTC)

• 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)
  • @
    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)
  • You can see how it would look under monobook and vector at File:WP20 Proposed Logo Monobook.png and File:WP20 Proposed Logo Vector.png — Wug·a·po·des​ 00:42, 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.
• 
  Our usual puzzle globe with the "20 years of Wikipedia" mark.
• 
  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)

When singing up on Wikipedia, you have to make a username, and unbeknownst to newcomers, there is

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)

• It's a sensible and user-friendly approach to tell new editors the rules about user names before they create one. Warning templates after the fact, or even gently-worded manual warnings, can have a chilling effect on someone brand new to the community. My preference would be for a link to the policy because (1) the summary list would make the create-account screen ridiculously long on mobile and (2) it introduces the new editor to the idea that Wikipedia has policies, plus on that page they'll see the box of other conduct policies. Schazjmd (talk) 15:50, 9 December 2020 (UTC)
  • "My preference would be for a link to the policy" The sign-up page already links to the policy. Do you mean changing/adding wording to that? —  HELLKNOWZ   ▎TALK 16:03, 9 December 2020 (UTC)
    • This. The signup page says (
      help me choose) linked to this policy right on the box where you type in the name you want. — xaosflux ^Talk
      16:52, 9 December 2020 (UTC)
    • That page also has this banner at the top of it: MediaWiki:Signupstart, which could be expanded some if helpful. — xaosflux ^Talk 16:53, 9 December 2020 (UTC)
      • Wow, I did not expect the policy page to come up from that! I didn't click it when I checked out the page because I thought "help me choose" would assign a random name (based on my experiences with other websites). Yeah, we could
        use clearer wording there. Schazjmd (talk)
        17:17, 9 December 2020 (UTC)
        • @Schazjmd: the "help me choose" label is from MediaWiki:wikimedia-createacct-helpusername - we can make it something else short if you have some good ideas for improvement. — xaosflux ^Talk 17:27, 9 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)

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.

@

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)

• With regard to making reference information less cluttery within wikitext, see meta:Community Wishlist Survey 2021/Citations/Tool for separating the references from the body text. {{u|Sdkb}} ^talk 18:11, 15 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)

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)

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)

@

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)

Formerly named “Clearly mark talk pages for deceased, retired or blocked users” –  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 {{
  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.  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.  Self-minnow ◅ Sebastian 12:32, 29 December 2020 (UTC)

• @
  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:

• {{
  deceased
  }}
• {{retired}}
• {{Banned user}}
• {{not around}}

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)

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

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: 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 navbox|Illinois Senate|United States Senate|President of the United States}}

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)

@

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?

talk!

) 23:06, 8 January 2021 (UTC)

@

WP:FULL protection, which already exists. WhatamIdoing (talk

) 23:26, 8 January 2021 (UTC)

A discussion has been started at

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)

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

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)

• (edit conflict) It is only intended to be for a short while. The logo itself is an easily changed option ($wgLogo in LocalSettings.php). The link from the logo is built in to the page structure so rerouting it would involve a code change. — GhostInTheMachine ^{talk to me} 13:13, 15 January 2021 (UTC)
• Well, the Wikipedia way would be at least to hyperlink "20 years", no idea if that is possible. Alanscottwalker (talk) 14:23, 15 January 2021 (UTC)

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)