Wikipedia:Village pump (proposals)/Archive 191

Moved to

Actually in America they are becoming more and more serious, and the only reasons are irresponsible news media and social media users and platforms, according to the

This is a classic

WP:NOTCENSORED situation. Wikipedia does not hide things that are upsetting or controversial as long as they are reliably sourced. It would lead to a form of gesture politics, because the information would be freely available elsewhere, eg television and newspaper headlines.--♦IanMacM♦ ^{(talk to me)}

17:03, 20 July 2022 (UTC)

While I, in principle, agree/understand where RekishiEJ is coming with this, Ianmacm is correct about

WP:NOTCENSORED. TheSandDoctor ^Talk

18:07, 20 July 2022 (UTC)

I am not sure that WP:NOTCENSORED is really the right policy to apply… no one is proposing that we delete the articles on these events. The question is whether we want to highlight these events on the main page. That’s more of a WP:DUE/UNDUE question. Blueboar (talk) 19:56, 20 July 2022 (UTC)

• @RekishiEJ: We need a discourse. WP:NOTCENSORED is not the end of the consideration, but only one thread in a massive conversation going in many directions. While I think NOTCENSORED is a guiding principle, we have related conversations such as how explicit Wikipedia should be in discussing suicide or other topics where research says that exposure to information encourages unwanted behavior. I support you or anyone else starting an essay, seeking prior conversation, and identifying other perspectives. We also have a Wikipedia article on the issue that could inform thought - Effects of violence in mass media. It has come up in the past as to whether terrorists are allowed to share images of crime that we republish in Wikipedia. I the discussion has hardly begun. Bluerasberry (talk) 20:05, 20 July 2022 (UTC)
  • @Bluerasberry: Another article significantly better inform thought about how mass shootings should be presented here - mass shooting contagion.--RekishiEJ (talk) 10:21, 21 July 2022 (UTC)

"The only reasons [that mass shootings are becoming more serious] are irresponsible news media and social media users and platforms" is flat-out wrong. Putting that aside, if someone is going to do a copycat shooting, it's generally because they have a community egging them on via platforms like Discord, Telegram, 8chan, etc. It is almost definitely not because they happened to see an article about shootings on Wikipedia and independently decided it was cool. (I sincerely hope to never be proven wrong about this.) Gnomingstuff (talk) 20:20, 24 July 2022 (UTC)

@Gnomingstuff: The statement which you think is wrong is taken from [4], which reflects the consensus of the American Psychological Association on mass shooting contagion.--RekishiEJ (talk) 12:50, 25 July 2022 (UTC) altered a little 12:51, 25 July 2022 (UTC) altered a little again 11:18, 26 July 2022 (UTC)

What the paper says is that media coverage "may ultimately be contributing to the perpetuation of [mass shootings]" and names three other contributing factors, which is quite a different statement than "the only reasons mass shootings are increasing are news media." It also doesn't recommend anything analogous to not putting these articles on the main page. Gnomingstuff (talk) 15:31, 25 July 2022 (UTC)

I think we shouldn't mention the name or race of the shooter on the front page similar to this] .Agree that WP is an unlikely source for mass shootings, but I don't see any reason why a shooter would not have edited WP. Wakelamp d[@-@]b (talk) 11:19, 26 July 2022 (UTC)

In fact, we know a good number of them did – among them

Elliot Rodger and Raymond Spencer. Most only made a few edits, but still -- that is more than most people do. Andreas JN466

16:56, 26 July 2022 (UTC)

I think that they should be treated as any other even of similar significance, including the main page. But to not follow the US media practice of reporting on covering each one ~50 times...each day for for 20 days afterwards and then 30 more times in following years for anniversaries etc.. This increases the issues, perceptions and problems described in the OP.North8000 (talk) 22:24, 20 July 2022 (UTC)

The news media decided that it would not show the videos of the planes hitting the towers over and over again in the September 11 attacks. Some of the material is disturbing and upsetting so caution is needed. What is needed is a way of addressing this without trying to hide things that are legitimate matters of news and encyclopedic coverage.--♦IanMacM♦ ^{(talk to me)} 09:40, 21 July 2022 (UTC)

The news media decided that it would not show the videos of the planes hitting the towers over and over again

You could not avoid those videos if you tried back in 2001. They were everywhere.

Anyway, that's a different discussion. IanMacM is correct that this is ultimately a

b

} 10:59, 21 July 2022 (UTC)

@North8000: "the US media practice of reporting on covering each one ~50 times...each day for for 20 days afterwards and then 30 more times in following years for anniversaries etc.."? You mean after a mass shooting receives national coverage in the U.S., it is reported by American news outlets from Day 1 to Day 20, and during this period it is repeated at most 49 times everyday (which seems impossible), and in the following years it is repeated 30 times each year? Sorry I don't understand what you mean very well.--RekishiEJ (talk) 08:36, 23 July 2022 (UTC)

@RekishiEJ, I believe North8000 means it's covered around 50 times (by various different news outlets) for 20 days, and then over the anniversaries etc. it is covered 30 more times (in total). If that's still implausible, it could also be exaggeration. ― Qwerfjkltalk 09:01, 23 July 2022 (UTC)

I was a little vague, but what I meant roughly speaking is that each larger scale mass shooting gets covered by national media on about (rough guess) 50 days. And as a rough example, daily coverage for each of the 20 days following the event and then on about an additional 30 different days spread amongst during the following years. (e.g. the 1 month anniversary, the 2 month anniversary, 3 month anniversary, 8th year anniversary, interviews about the event with survivors and friends / families of victims about upcoming anniversaries, coverage triggered by their actions in subsequent months and years etc. North8000 (talk) 12:47, 23 July 2022 (UTC)

In short, we should cover them when they are current news, but not amp up coverage (as the US media does) via anniversaries etc. North8000 (talk) 14:47, 24 July 2022 (UTC)

To clarify further, the "current news" coverage should be subject to the usual criteria, such as Masem described in the next post. North8000 (talk) 17:17, 26 July 2022 (UTC)

• I would say that we should be trying to recall that
  WP:NEVENT should be used to judge the long-term notability of such events. There are clearly some shootings that will remain notable like the Uvadle shooting, but we are often far too eager to rush to create an article about a mass shooting without waiting to see how much coverage it actually is going to have in the future. --Masem (t
  ) 15:00, 24 July 2022 (UTC)

  I would have thought it unlikely that a mass shooting would not get at least some longer-term coverage from regional media, though of course many won't in a national or even a state sense. Nosebagbear (talk) 17:25, 25 July 2022 (UTC)

  In the US, mass shootings happen, on average, more than once a day. These events are notable according to the same criteria we use for anything else, but as a practical matter we'd need to hire or appoint a full-time editor in residence just to keep up with the death toll associated with our... "freedom". MastCell ^Talk 17:30, 26 July 2022 (UTC)

There are different ways that they are defined for different purposes including ones where people were only wounded. I think that the OP was referring to those of the type with several deaths which make national news. North8000 (talk)

• The entire premise of this proposal is faulty. To say that "the only reasons are irresponsible news media and social media users and platforms, according to the American Psychological Association" is patently false and lacks citation. RekishiEJ is incorrect that this press release "reflects the consensus of the American Psychological Association on mass shooting contagion". Rather, it is a presented paper from the APA national conference, meaning it is not even a peer-reviewed published scholarly article and certainly not a position statement of any sort. Social contagion theory is a perfectly valid theory and likely has some significant R², but to suggest we stop writing any articles due to it is absurd. Most damning to this contagion idea, to me, is that this "contagion" near-universally affects only boys and young men for some unspecified reason. EvergreenFir (talk) 17:55, 26 July 2022 (UTC)
• Agree with user Masem above. I would also add that when these events are highlighted, for whatever reason, that the perpetrator's name should only appear once in the article or summary, and never in the headline. Regards, GenQuest ^"scribble" 18:59, 26 July 2022 (UTC)

I think it is important to protect important list articles from promotional edits such as

Remember that protection also protects against good edits, such as removing vandalism and spam.

Phil Bridger (talk

) 07:28, 27 July 2022 (UTC)

WP:PREEMPTIVE makes it clear that pages should not be pre-emptively protected; neither linked article has any recent disruption, so I do not see the need to protect at the moment. Curbon7 (talk

) 13:49, 28 July 2022 (UTC)

I can't see why list articles in general would needs special exceptions from Wikipedia:Protection_policy#Pre-emptive_protection; if a page is having a problem we should be able to deal with it already. — xaosflux ^Talk 13:50, 28 July 2022 (UTC)

The general rule is to apply the lowest level of protection, for the shortest period of time, required to prevent ongoing disruption. Apply indef protection of any level is a drastic step which shouldn't be taken without extensive evidence that it's needed and that previous efforts have failed. -- RoySmith (talk) 16:11, 28 July 2022 (UTC)

To whatever extent that people use those lists, any entry is promotional and will financially benefit whoever is listed. And being subjective with no inclusion criteria noted, what would make any particular addition be considered to be "promotional" any more than the others on the list? North8000 (talk) 16:20, 28 July 2022 (UTC)

We already have a What Links Here link on redlinked pages. I propose a link to Related Changes be added directly after it (with options set to list changes to pages linking to the page in question).

Rationale: It saves a few clicks or keystrokes, and it is useful to check the popularity of an article subject or the amount of editing activity on connected subjects, something that may indicate importance or demand of a new article. Utfor (talk) 17:43, 31 July 2022 (UTC)

DABs on very common names: how to improveI'm not a coder, but others are. There is a dilemma here: any DAB page on very common first names (such as Ben) or surnames (such as Müller (surname)) has the problem that it is NEVER complete. It can't be. Also, updating the details (such as death year when it occurs) is a Sisyphean task, which will also never catch up with events.

The second option would be to only use the template {{intitle|''search word''}} for displaying "All pages with titles containing search word". Besides the problem of bringing up hits other than pages about people with that name, the main problem there is that it leads to endless lists of hits, which are not organised alphabetically (can't figure out how they are organised), split into pages of 50, so totally non-user-friendly and almost useless.

We need a bot here, which would transform the template, so the result would still be

• an automatically created list, but one
• ordered alphabetically,
• displaying the "short description" next to the name and being
• as updated as the Wikidata file is,
• at best with the option of getting fixed manually (because there are more editors who know how to do that than such who know how to fix "short descriptions" and Wikidata files),
• ideally with a mechanism pinging interested editors when such manual changes happen, so that they can adopt the change, if they see fit, to the "short description" and Wikidata file.
• Adding headings for each letter of the alphabet, like at Müller (surname), is also helpful.
• The option of giving priority to manual fixes: if the name stems from, say, a biblical character or a few ancient saints, those should be set first, at the top, in their own sub-section, preferably in a chronological order, which should be stated in a short sentence (intro) under the sub-heading. That's the job of an experienced editor, not a bot, and the bot should not mess it up.

Repetitive work is typically best fit for bots, and this is a clear case of such work. Is anyone interested & able to create the mechanism? I guess there might be Wiki proposal pages better suited than this one. Who can point me to them? Thank you, Arminden (talk) 08:44, 25 July 2022 (UTC)

Automatically displaying the short description would indeed be a major improvement. SDs are specifically written with disambiguation of this type in mind, and many biographical SDs include birth and death dates which helps quickly readers focus on titles of interest. One slight correction: SDs aren't linked in any way with Wikidata (they used to be, but the link was removed a few years ago). Now, all SDs are stored locally here, and are written with solely with Wikipedia in mind. MichaelMaggs (talk) 10:29, 25 July 2022 (UTC)

@Arminden, I wonder whether a link to Special:AllPages/Ben would address some of your concerns for common first names. Whatamidoing (WMF) (talk) 21:02, 25 July 2022 (UTC)

Whatamidoing (WMF), thanks for the template. I knew of a similar one, {{intitle|Ben}} (leads to All pages with titles containing Ben). There is even one leading to [[Special:search/~"Ben"|All pages containing ''Ben'']] (leads to All pages containing Ben). The two can be both replaced by a single, much shorter one, {{srt}}. Anyway, they're all useful, but lacking details (short description and life years) and are not good for replacing the existing DAB page. Arminden (talk) 21:48, 25 July 2022 (UTC)

Not sure that DAB is supposed to be an index of every “Ben”. The point of a DAB page is to disambiguate topics that might have the same title.Blueboar (talk) 22:01, 25 July 2022 (UTC)

Having a list of all people named Bibi is a useful disambiguation tool; there are 33 people listed there, divided into nickname, first name and last name. Ben is probably the name of too many people to be useful even as a navigation aid, unless some reasonable split can be made (by a human, not a bot) and enforced. Animal lover |666| 18:38, 26 July 2022 (UTC)

{{Get short description}} might help (though it doesn't work perfectly). The birth and death dates could be obtained from Wikidata (via a bot or template). ― Qwerfjkltalk 06:36, 28 July 2022 (UTC)

Getting the name indexes to at least partly be kept up to date by bots would be an improvement on the current situation. Of course, there are all sorts of pitfalls when you get to the specificis: e.g. the short descriptions aren't always good for disambiguation (see this

WT:WPDAB. Uanfala (talk

) 13:13, 3 August 2022 (UTC)

For the past couple of months, Firefly, SD0001, and I have been advising a Google Summer of Code project by Ankit18gupta to create a new way for beginners to learn how to edit: the "edit wizard", a step-by-step form for making edits. You can try it on a random page at this link (click the "Edit Wizard" tab at the top). I'd like to see it go live on an arbitrary article to test it out and see how useful it is to people - perhaps one of the mid-ranking articles on WP:Popular pages, like maybe Britney Spears. The project is still at the prototype stage, but the bones are there and the instructions will definitely be greatly expanded before anything gets published - I just figured we could start the conversation now. So, let me know what you think. If we have consensus here, I'll pick an article (based on what gets said here) and also get consensus at its talk page, then implement it (which, if we can't figure out anything else, might have to be through MediaWiki:Common.js). Enterprisey (talk!) 13:32, 7 August 2022 (UTC)

Tried it at the link you gave, clicked it, got "give a source for your fact" with a field to enter a URL. Uh, what? Perhaps I just wanted to correct a typo, rewrite a sentence to get it to flow better, or remove an unsourced claim? The first screen I get is completely out of the blue and isnot how an "editing wizard" should start. Seems to be not ready for implementation. It doesn't get better further on, a very limited tool which ends up posting an edit request to the talk page apparently?[5] "Spot where to add the fact", which fact? All I did was give an url, a quote, and a translation: I didn't present any fact. This tool will create lots of confusion, many edit requests, and little actual benefit.

Fram (talk

) 09:51, 8 August 2022 (UTC)

The directions will be substantially improved. The intended workflow is (1) think of a statement (fact) to add to the article, (2) get a source, (3) get a quote from the source that supports your statement, (4) rephrase the quote in your own words so that it's suitable to be included in the article, (5) pick a location in the article for your new text to go. As for the other types of edits, some will be added to the wizard later; others, like fixing a typo, are trivial to do with the current editor and are thus not in scope. Enterprisey (talk!) 03:02, 9 August 2022 (UTC)

Fram's right – this thing seems to be worse than useless. Any such functionality should be integrated with the

Visual Editor which could use some better signposting. For example, I recently thought to try figuring out how to create a redirect with the Visual Editor as this is the sort of thing that causes me difficulty when training newcomers. I've long known how to do this with the wikitext editor but it's not obvious how to do this in the Visual Editor. I did manage to find out where the function was hidden but I still feel uncertain. As we're still digesting that interface, we don't need another completely new one, thanks. Andrew🐉(talk

) 10:11, 8 August 2022 (UTC)

As said below by others, the Visual Editor is not the right place for this because the point is to replace the editing interface with something less bewildering. The WMF Growth team is doing some nice work with putting such signposting and feedback in the editor: see T265163. Enterprisey (talk!) 03:04, 9 August 2022 (UTC)

• Support pilot I tried the tool. It works well. It communicates the point that when people edit Wikipedia they should start by preparing to cite sources. I support implementing this tool on a few articles with support of community members watching them, which could mean giving notice at a WikiProject or other public forum. I see the criticism in this discussion and I am not persuaded. The future of Wikipedia will include technological change and either the community will have input into it, or the community will not. This is a solid research and development project which produced a tool and concept worth testing and discussing. The proposed pilot is unlikely to be disruptive. I appreciate that the pilot is designed for community participation. If anyone wants to criticize research and development in general, then I encourage them to make a proposal for funding to meta:Grants:Start and request sponsorship to organize community review. There are tens of US$millions a year being spent on Wikimedia software development which produces wide changes and yet typically receive less attention or review than student projects like this one. This is a summer student project. Of course this should proceed, this pilot is small, has disclosure, and is a model for collaboration in the way the wiki community wants for all development. I appreciate protection and criticism but be aware of the scale of that big money; if this student pilot seems scary then the big picture is not in view. If there is a problem with this project, then say what would make the development process better, then escalate those ethical requirements up the chain to the paid development. Bluerasberry (talk) 14:35, 8 August 2022 (UTC)
  • Ignoring for now the discussion about the actual tool and whether it communicates well or badly, let me start by adressing the remainder of your post: what? "The future of Wikipedia will include technological change and either the community will have input into it, or the community will not." And? What is the relevance? Some new bit of technology is proposed, and the community gives input. How is that a reason to support (or oppose) this thing? "I appreciate that the pilot is designed for community participation." Yes, that's why I tested it, that's my participation. And then I gave my input on it, which supposedly is the benefit of this community-led project. Good. Still no idea why you ramble on about it as if all of this is important for the implementation or somehow negates the criticism. "Of course this should proceed, this pilot is small, has disclosure, and is a model for collaboration in the way the wiki community wants for all development." Yes, by all means, proceed, by looking at the criticism and coming back with an improved tool, not by brushing aside the criticism because this is a student project with collaboration. "If there is a problem with this project, then say what would make the development process better, then escalate those ethical requirements up the chain to the paid development." Now you've completely lost me; the "problem" with this project is the current end product, which isn't ready to be placed on articles. I have no idea what "ethical requirements" I should escalate to what "paid development", I am giving feedback on the current end result which is being proposed, and which needs serious improvements before putting it into alpha testing. I have no problems with the way this project is otherwise handled, no "ethical" qualms, no comments on any of that.
    Fram (talk
    ) 14:49, 8 August 2022 (UTC)

@

Fram: This is a routine pilot with a functional tool and limited scope. I wish that we had a guideline or rubric for making judgements at scale for allowing or denying such proposals. I disagree that this "needs serious improvements before putting it into alpha testing", but I wish that I could point to a published guide for determining this. Do you have any general ideas for how to determine when a tool is ready for alpha testing? I feel like we should have a standard process for making judgements by the 100s every year. I have the feeling that the main reason why this proposal is getting criticism is that it is being documented for community comment, and if this proposal were not disclosed as is more typical, then there would be no objection to the testing. I do not want the outreach and documentation itself to be the cause for the negative response. Bluerasberry (talk)

15:58, 8 August 2022 (UTC)

Except that it isn't a functional tool. What is the purpose of the pilot? To get actionable feedback. Look above, look below, you have plenty of actionable feedback already. I doubt that such pilots are being started "by the 100s every year", it's not as if we get new tabs at the main interface constantly. "the main reason why this proposal is getting criticism " is that the tool is at the moment not good at all, and will only confuse newbies or IPs, not help them. "if this proposal were not disclosed as is more typical, then there would be no objection to the testing." Duh, if no one knew this was being tested, no one would object. That's not the winning argument you believe it is. If people would find out that some editors are testing a poor tool on IPs or newbies without prior disclosure, then those editors could get into serious trouble. In this case on the other hand, there is no reason at all to get anyone into trouble, people should be thanked for trying something: but that doesn't mean that the result should be supported or even be considered ready for limited testing to unwary users. The testing that is being done here and now, by volunteers willing to test it, is a perfect first step. But accepting that those volunteers then tell you that it isn't yet ready for wider testing as proposed is also necessary (just like having to accept that people may even tell you "never" instead of "not yet").

Fram (talk

) 16:07, 8 August 2022 (UTC)

• Perhaps it might be helpful to rename this tool to the "Edit request wizard"? Since it seems to be about making edit requests, not direct edits to the article. Writ Keeper ⚇♔ 15:02, 8 August 2022 (UTC)

  While "edit request wizard" is a good description of the current state of the project, I envision an edit request as only one possible outcome for the workflow: perhaps the edit could be actually applied to the article for advanced editors, or the user's mentor could be pinged or other help sought in real-time. Enterprisey (talk!) 03:06, 9 August 2022 (UTC)

• Seems like this still has issues. Running in to dead-end workflows on this. Went to the page, put in a source, it did say "Source probably OK". No idea what the "Select the sentence" is suppose to do, there was no UI feedback on this. Do you try to insert the cursor somewhere? Do you highlight something? No idea there - but it did let me continue. Put in the "quote from your source", then just got a dead end of "The quote does not match..." and no way to continue from there - dead end stop at this point. Compare this to if I would have just used the wiki editor and the insert source, that works just fine. Sample reference used here was: {{cite journal |last1=Trimble |first1=Virginia |last2=Aschwanden |first2=Markus J. |last3=Hansen |first3=Carl J. |title=Astrophysics in 2005 |journal=Publications of the Astronomical Society of the Pacific |date=2006 |volume=118 |issue=845 |pages=947–1047 |doi=10.1086/506157 |url=https://www.jstor.org/stable/10.1086/506157 |issn=0004-6280}} — xaosflux ^Talk 15:09, 8 August 2022 (UTC)
  • Same happens with Google Books (with preview or with snippets both), you put in a straight quote from the book but it doesn't work. "The quote does not match. Please make sure the quote is copied/pasted exactly from the source".
    Fram (talk
    ) 15:21, 8 August 2022 (UTC)

    The tool is only relevant for web sources, as that is usually what beginners use mostly. It tries to load the URL (in the backend) to verify the quote. As of now, this only works for simpler websites that put the text in the HTML source, not sites like Google Books or JSTOR where the text may be embedded in images or iframes or other fancy elements, or loaded via JavaScript (although the last limitation is probably solvable). – SD0001 (talk) 16:39, 8 August 2022 (UTC)

    Maybe if the quote fails, it should continue anyway. Tell them it doesnt see it, or cant read it - continue anyway? And just note that with the output? — xaosflux ^Talk 16:44, 8 August 2022 (UTC)

    If we allowed continuing anyway, a user could submit arbitrary text as the quote. We're trying to minimize the amount of arbitrary text users can submit. The reasoning behind requiring exact quotes is if the website is OK and the quote comes from the website, the quote is probably fine to post. Regarding Google Books, I'm hoping for a technical solution, but we may have to just not check Google Books quotes (which hopefully people won't take advantage of). Enterprisey (talk!) 03:23, 9 August 2022 (UTC)

• Blocking issue this should be resolvable. The very last page of the dialog with the "Send edit request" button needs to display MediaWiki:wikimedia-copyrightwarning; and extra verbiage that this is a publish action as referenced in that message. Reason being is that this is introducing a new editor that would allow users to publish new works and they need to agree to the TOU and release their work under the appropriate license to do so. — xaosflux ^Talk 15:22, 8 August 2022 (UTC)

  Also, someone more in the know about toolforge - are there are differences in the privacy policy or access to private info there that unsuspecting editors need be aware of before they get connected to it for this tool? — xaosflux ^Talk 16:01, 8 August 2022 (UTC)

  Additional Easy-to-fix blocking issue: prior to publishing this to production users, especially anon users, the script needs to be moved out of userspace - prob best to gadgetize it as well and load via ?withgadget. — xaosflux ^Talk 16:03, 8 August 2022 (UTC)

  Yes, I had noticed that earlier, but was considering waiting on bringing it up until seeing whether this discussion ended with a consensus to proceed. But definitely seconded; this should not be rolled out while the main code is still in userspace. Writ Keeper ⚇♔ 16:06, 8 August 2022 (UTC)

  Roger that. It'll definitely be a gadget before any rollout. Bug filed for the copyright boilerplate. And I'm not sure on the toolforge privacy policy, but at least I don't think this is the first use of toolforge for a similar purpose. Enterprisey (talk!) 03:28, 9 August 2022 (UTC)

  @Enterprisey

  Github is being a pain, please add this to the ticket:

  *::::It could go right down here: *:::: *::::Compare to how reply tool loads it below the input area: *:::: *::::To get around the verbiage mismatch, perhaps the wizard can change the label from "Send Edit Request" to "Publish Edit Request" - that way you don't have to fork the copyright or add more text that "Send equals Publish" ? *::::

  — xaosflux ^Talk 14:35, 9 August 2022 (UTC)

  Yep, we'll use the reply tool's appearance as a guide. Enterprisey (talk!) 15:54, 9 August 2022 (UTC)

• I think the fundamental question will be how are the problems that arose from the article feedback tool going to be avoided? It produced comments with a very low signal-to-noise ratio, thus requiring a high number of editors to sift through effectively, which did not emerge. isaacl (talk) 16:22, 8 August 2022 (UTC)

  I thought a lot about the article feedback tool and its issues while designing this. Here, we're trying to restrict what users can post with this, using code, to the point where what they post isn't too useless. The URL is verified to be on

  RSP and the quote is verified to be from the URL. The actual text that goes on the article will be more difficult (i.e. impossible to do perfectly) but I'm hoping that making users get over the first two hurdles will help. Enterprisey (talk!

  ) 03:33, 9 August 2022 (UTC)

• Oppose As it now turns out that this is actually an edit request wizard, note that we have one already – see
  WP:ERW. I'm not sure whether anyone uses it but the focus should be on improving it rather than re-inventing another way of doing exactly the same thing. See also feature creep. Andrew🐉(talk
  ) 18:01, 8 August 2022 (UTC)

  The edit request wizard is really unintuitive and is implemented by giving instructions as part of the wikitext editing window – the worse possible newbie experience. It is not a serious contender with this JavaScript tool. Best, KevinL (aka L235 · t · c) 18:33, 8 August 2022 (UTC)

  This offering does not seem to be a serious contender either as no groundwork has been done. For example, there's a project

  WP:WPEDITREQ – "We cover anything related to edit requests on the English Language Wikipedia". But they don't seem to have been consulted about this proposal! And I don't suppose the WMF have been consulted either. My view is that something fundamental like this should be part of the MediaWiki interface so that it is fully integrated with logging, permissions and other architectural features. It would then get ongoing support and development rather than being a one-off summer intern project. Andrew🐉(talk

  ) 06:56, 9 August 2022 (UTC)

• I fully support prototyping this and give my thanks to @Enterprisey for his work on this. I agree with Xaosflux about the outstanding blocking issues prior to implementing this. Best, KevinL (aka L235 · t · c) 18:34, 8 August 2022 (UTC)

  I am facing a lot of problems at the "Quote from your source that supports your fact" stage, though, and anticipate that major bugs should be resolved before deploying even as a prototype. Best, KevinL (aka L235 · t · c) 18:37, 8 August 2022 (UTC)

  Yup, that'll have to be worked out. Thank you for the support. Enterprisey (talk!) 03:35, 9 August 2022 (UTC)

• When I tested this a couple weeks ago I also found it very promising but I'm not sure I'd say it's ready to use with actual new editors outside of testing (likely with developer monitoring). Beyond the blockers that have been noted, I think the edits that are produced are going to be hard - needlessly so - to action. That said I agree with L235 that the opportunity to guide editors through how to write a good edit, step by step, and which does some degree of checking (i.e. it's doing some look to see if the source is a reasonable source), is going to be a huge benefit and will be what distinguishes this (potentially) from the Article Feedback Tool. Best, Barkeep49 (talk) 20:22, 8 August 2022 (UTC)

  Yes, the current area of development work is making requests include wikitext and a full cite template like this. We could even write a gadget that could apply the edit in one click from the talk page (with some improvements to the "pick where your text goes" part of the form). And yeah, better instructions are at the top of my to-do list. Enterprisey (talk!) 03:38, 9 August 2022 (UTC)

I have some questions:

1. Is this for protected pages, or any page?
2. Will this use an edit request template, or just add a talk page message?
3. Who is going to patrol this? There are already plenty of request queues that don't get enough attention.

And some comments:

1. As Fram pointed out, there needs to be a way to make copy edits.
2. There needs to be some notes about consensus, npov and likely a huge number of other content pags.
3. The overwhelming majority of edit requests that aren't horribly malformed or vandalism contain blpvio, npov issues, and fringe issues. This is going to basically create another queue for people to clear trash from. The vast majority of constructive edit requests are copyedits, and this tool doesn't handle those.
4. Is the best we can do to attract new editors (who almost never come from those making edit requests) is ask other editors to make edits for them? The best solution to "it's hard for some people to learn to edit" is "just make the nerds do the actual editing?" Does that mean we've given up on visual editor? ScottishFinnishRadish (talk) 21:00, 8 August 2022 (UTC)

@ScottishFinnishRadish for your question 2, this is what the output currently produces: Special:PermaLink/1103158365#Edit_Request_made_by_Xaosflux_15:16,_8_August_2022_(UTC). I'd think these should probably be enqueued in a category somewhere too, likely under Category:Wikipedia edit requests where all the other ER's go. — xaosflux ^Talk 21:21, 8 August 2022 (UTC)

Regarding backlog, there are over 187 open edit requests requests that most users can handle, with a backlog to May 2022 as of now. — xaosflux ^Talk 21:25, 8 August 2022 (UTC)

The vast majority of users never look at those, however, which is how I have more than 10,000 handled requests. ScottishFinnishRadish (talk) 21:38, 8 August 2022 (UTC)

• Support prototyping - consider this backing for up to 3 articles to be selected for alpha testing, along the basis proposed by Enterprisey. The damage it can do is tiny (most of the issues I came across trying it out will just mean requests don't get made), and as a student summer project, it's not like it'll slip into general use without far more community discussion. There are indeed changes that should be made, and I'd have significant things I wanted to discuss before a broader rollout including it occurring at all. But none of that prevents alpha testing. Nosebagbear (talk) 01:58, 9 August 2022 (UTC)

  For more specific feedback, the "quote your source" bit needs to be WAY less pushy, especially with regard to google book snippets. Nosebagbear (talk) 01:59, 9 August 2022 (UTC)

• As you can see above, I oppose rolling this out to unsuspecting editors in its current state, I don't get why you would do this when there is so much to be improved first. But if it gets rolled out, then please don't start at a controversial BLP like Britney Spears, or better yet don't start at BLPs full stop.
  Fram (talk
  ) 07:38, 9 August 2022 (UTC)
• I think something more like User:NguoiDungKhongDinhDanh/FormattedEditRequest (maybe with VE?) would be nice. ― Qwerfjkltalk 13:21, 9 August 2022 (UTC)
• I just spent some time testing this tool. There are a number of problems with it and I'm afraid that this will confuse newbies more than it helps them. This needs a lot more work before going live, even as a pilot test. Some issues:
  • The form does not accept URLs in the format of "www.example.com". It has to be prefixed with http:// or https://. The error message simply says "This is not a valid URL" and does not explain why. I don't think it will be obvious to less tech-literate users (presumably the intended audience of this tool) what the issue is.
  • If you enter a Twitter, Facebook, etc. URL, the wizard states that it is an unreliable source and refuses to proceed. While these are indeed unreliable in most situations, there are plenty of valid uses per
    WP:ABOUTSELF
    . Outright banning these sources contradicts policy and is unnecessary considering that the wizard creates an edit request, so if the source is inappropriate the request will be declined anyway.
  • Paywalled sources cannot be used as the wizard will not be able to verify the quote. This prevents the use of most RS for medical/scientific articles and even many news sources.
  • Formatting issues can cause the wizard to say that the quote doesn't match. For instance I was unable to input the three lines starting with "Another approach utilized by some laboratories to obtain reliable results..." by copy-pasting from [6].
  • The instructions to copy-paste a quote and "rephrase the quote in your own words" seem to encourage close paraphrasing. Articles are properly written by reading and understanding a variety of sources, not cobbling together lightly rephrased quotes from individual sources.
  • As mentioned above the tool does not support fixing typos, copyediting, removing vandalism, etc. In my experience most new editors start out by making these sorts of minor edits rather than adding substantial content.
• I'd encourage those evaluating this proposal to look at their own newbie edits and see if they would have been able to make them using this tool. This was my first edit - it doesn't involve adding prose, so it wouldn't have been supported. This is my first edit that added referenced content. The wizard would have prevented me from adding this as it cites offline sources and Google Books. Rather than making things easier for new users, this tool seems to restrict their ability to edit for no good reason. The idea that newbies and IP editors should only cite non-paywalled webpages (but don't think of adding, e.g., an announcement about a new album sourced to a band's verified Twitter account) is misguided. Spicy (talk) 15:36, 9 August 2022 (UTC)
• Testing this on a few individual pages would present minimal possible downside. However I don't think we need to increase confusion and complexity with yet another way to edit. The current implementation is so restricted that any attempt will almost invariably fail. The ideas discussed for expanding functionality simultaneously retain serious limitation on what kinds of edits would be possible, while making things more complicated to sort through different specific-permitted edits, while trying to aggressively rejecting edits to avoid the article-feedback-tool problem, all while actively delaying or derailing a new user from learn how to become an actual editor. It makes the same error the WMF makes - we do NOT need are dead-end specialty tools trying to help new users do individual low level tasks under the supervision of experienced editors. The survival of the project is relies entirely on the cycle of new users into general-competence editors capable of supervising the next new users. Alsee (talk) 09:28, 15 August 2022 (UTC)

Original proposal: Suppose a

It's really a bad task for a bot, and {{

b

} 07:32, 1 August 2022 (UTC)

Support. I completely disagree with Headbomb - {{R avoided double redirect}} is for situations where the avoided double redirect could potentially become an article later or where that redirect is retargetted - when the avoided redirect changes the dependent redirect can be automatically updated to best serve readers. For example if "Foo (song)" is created as a redirect to "Foo (album)" that is itself a redirect to "Foo (band)" then tagging the first redirect as a {{R avoided double redirect}} will allow it to be automatically retargetted to "Foo (album)" when someone writes that article; it can also be retargetted automatically if "Foo (album)" is retargetted to the new article "Foo discography" without the author of the article needing to know the redirect exists - this is even more useful when the redirect is from a less obvious title than in this example. I can see lots of advantages of doing this by a bot and no downsides. Thryduulf (talk) 10:45, 1 August 2022 (UTC)

Thryduulf, I see the downsides. Let's say "Death of Foo" is a redirect to "Shooting of Foo" which is then moved to "Assassination of Foo", causing a double redirect at the first one, we would not want the bot to tag "Death of Foo" with {{R avoided double redirect}}, because the avoided double redirect doesn't really have the potential to become a standalone article without duplicating an existing article, and it would just bloat up the category with unwanted pages. —CX Zoom[he/him] ^{(let's talk • {C•X})} 11:43, 1 August 2022 (UTC)

It's never "mandatory" for a human editor to put that template on a page, so it shouldn't be for their bot-aided edit either. Fixing the double redirect alone is still better for readers, so if it comes down to fixing it or skipping it over this new proposed rule - I'm for the former. — xaosflux ^Talk 12:52, 1 August 2022 (UTC)

Here's a concrete example. There is the journal

PNAS → Proceedings of the National Academy of Sciences of the United States of America

, it's most common abbreviation. Now, because this isn't the only way to refer to PNAS, and because I am lazy, I also create

PNAS

PNAS

PNAS

PNAS

PNAS

PNAS

PNAS

And a bunch of others

Should those be tagged with {{

b

} 13:30, 1 August 2022 (UTC)

You can afford the laziness, because you know that currently it leaves no trace in the page structure, only in the history. But imagine that one day

PNAS. If their intended target is Proceedings of the National Academy of Sciences of the United States of America, it should have been specified right away instead of relying on straightening by bots. In other words, current toleration of a bad practice is not a good argument for insisting on its toleration forever. A good news is that possible adoption of the proposal will have no effect on such redirects straightened in the past. Petr Matas

23:26, 2 August 2022 (UTC)

Let's say they'd have all been pointed to

b

} 23:30, 2 August 2022 (UTC)

If they have been straightened and tagged, then after turning

PNAS into a dab they will appear in Category:Avoided double redirects to be updated. Petr Matas

23:40, 2 August 2022 (UTC)

Which they shouldn't, since they don't need any updating.

b

} 00:38, 3 August 2022 (UTC)

That is right, it is just a relict of one's laziness. Petr Matas 04:28, 4 August 2022 (UTC)

Oppose per

WP:CONTEXTBOT. The original premise here is not correct, a redirect chain A → B → C does not mean that B is the intended target for A or that the process of retargeting A results in an avoided double redirect. B could be a misspelling, an alternate capitalisation, an alternate disambiguation, a synonym etc. {{R avoided double redirect}} is for the situation "If B was an article A should point to it, but since B is a redirect A points to C instead". Any bot applying these tags would need to be making editorial judgements about what the intention of person who created redirect A was, and whether B has the potential to be a separate subject from C, which is not an appropriate task for a bot. 163.1.15.238 (talk

) 13:08, 1 August 2022 (UTC)

No comment on original proposal (Headbomb's comments give me pause). However, if I create Article X and Redirect A to it; then if Article X becomes Redirect x, we should see Redirect A should get tagged by a bot automatically as {{

☖

21:49, 2 August 2022 (UTC)

Let's say you create "Canadian Hockey in the 1920s". You then create a "1920s in Canadian Hockey" redirect as a likely alternative title, and "Canadian Hockey in the 1920's" and "1920's in Canadian Hockey" redirects as likely typos.

A move request occurs, and the page is moved to "History of Canadian Hockey (1920s)". What's to be gained by tagging

"1920s in Canadian Hockey"

"Canadian Hockey in the 1920's"

"1920's in Canadian Hockey"

as {{

b

} 00:43, 3 August 2022 (UTC)

That's not exactly the scenario I described (though I get why you are mentioning it). If Redirect x is tagged {{

☖

13:18, 3 August 2022 (UTC)

Modification of the proposal: The strongest opposition seems to come from the observation that a bot-straightened redirect is not the same as a redirect tagged manually with {{R avoided double redirect}}. Therefore I propose that the bots add a different tag when straightening a double redirect, for example {{Bot-straightened redirect|original target}}. Thus the original target of the redirect is not lost, changes in the original target can be tracked, and the category of manually-tagged redirects will not become cluttered. Petr Matas 23:26, 2 August 2022 (UTC)

I'm against the original proposal, but this one seems reasonable – it would help in tracking what had happened in cases like this (and potentially allow for bot-straightening of double redirects to be automatically undone if the "middle" redirect got edited into an article). --ais523 11:51, 6 August 2022 (UTC)

This makes sense to me. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:09, 7 August 2022 (UTC)

• Oppose any additional Rcat tagging. I'm a page mover and a seasoned RM closer, and I don't even remember when was the last time I could move a page without a
  No such user (talk
  ) 12:40, 15 August 2022 (UTC)

As a general principle, we should ask editors to fix their mistakes. Why don't we?

We have, or have had, systems in place that drop a user talk note where an editor adds a disambiguation link to an article, or leaves unbalanced brackets in an article.

Why don't we have something set up so that for every

WP:CHECKWIKI issue for which we scan (e.g., an editor putting a footnote in a header), we have a bot find the editor who made that edit and drop them a note informing them of the relevant rule and asking that they fix it? BD2412 T

15:44, 28 July 2022 (UTC)

In theory, I think this would be a great idea, but requires a bit of thought. We could certainly come up with a list of things that can be checked automatically (in the tradition of lint). We could then drop a (friendly and educational) note on the editor's page, alerting them to the issue and suggesting improvements. The problem is, as anybody who has worked with a linting system knows, the burden of sorting out false or trivial alerts can exceed the value of the system if you're not careful. -- RoySmith (talk) 16:07, 28 July 2022 (UTC)

In principle this is a nice idea, but out of interest what do you mean by "putting a footnote in a header"? Do you mean including references in the lead, as in (from today's OTD) Rædwald of East Anglia notes [1] and [2]? While this is in principle not correct, all lead facts should be mentioned and cited in the body, and would be something to bring up at GA or FA, we definitely shouldn't be discouraging this for each and every article of any quality. It is much better for a fact to be referenced only in the lead than not referenced at all... Cheers  — Amakuru (talk) 16:13, 28 July 2022 (UTC)

I think BD2412 meant something like == Awards<ref>{{cite web ... }}</ref> == in articles. DanCherek (talk) 16:16, 28 July 2022 (UTC)

Yes, per DanCherek, last I checked we have over 5,000 instances of a footnote in a section header, with many of these being in the ==References== header, and therefore not properly associated with specific article text. In every one of those cases, some editor first put that ref tag in the header, and a search of the article history should reveal which one, so they can be messaged and asked to fix the error. BD2412 T 19:01, 28 July 2022 (UTC)

To be clear, by the way, I am not just suggesting that we do this going forward, but that we do this retroactively with respect to currently-existing errors. BD2412 T 19:03, 28 July 2022 (UTC)

I've seen == Awards==<ref>{{cite web ... }}</ref> too, and I am fine if we have that notice, but I don't I know how many of these standard type mistake edits there are. Alanscottwalker (talk) 19:20, 28 July 2022 (UTC)

As a general principle experienced users should fix mistakes that are made by new editors. Why don't we?

Phil Bridger (talk

) 21:39, 28 July 2022 (UTC)

Oh, I do, sometimes, but I have other things to do, and don't want to spend all of my time fixing other editor's mistakers. And fixing one's own mistakes when they are pointed out is how we hopefully learn not to make the same mistakes again. - Donald Albury 22:51, 28 July 2022 (UTC)

@

Phil Bridger: let me ask you this. Do you remember all of your old mistakes? Some of the things we are fixing today were originally done years ago by editors who are still active, and now experienced. If, say, fourteen years ago, you did something erroneous in an article and it was still there, wouldn't you want a bot to drop you a note asking you to revisit it? BD2412 T

05:26, 29 July 2022 (UTC)

I just thought I would trial a problem solving approach to proposal evaluation.

Problem

• Quality - Editors creating work for others

Root Cause

• Process - The editing systems are not mistake proof.
• Training - Help is not context-sensitive, but in complex guidelines. Ignorantia juris non excusat (ignorance of the law is no excuse) approach
• User Experience - Overload of information. Action and Error message are complex and long.
• Policy -
  WP:5P4
  "Wikipedia's editors should treat each other with respect and civility" does not specify that editors should not waste other's time.
• Process Management - There is no overview of errors to fix
• People - Lack of editors to fix minor issues "I do, sometimes, but I have other things to do, and don't want to spend all of my time fixing other editor's mistakes. " @Donald Albury

Proposed solution

• Create an automated system to ask problem creator to fix.

Can we trial it at low cost?

• Yes - identify minor errors and manually send errors, and see responses both from a bot type editor name and from a normal editor name,

Risks

• Against Best practise -Blame_in_organizations
• Editor retention : Creator of error may respond negatively especially if many years old (See comment by @BD2412) justice delayed_is_justice_denied or maybe there needs to be a statute of limitations
• Editor Retention - Major reason for "Golden editors" is perceived negative interactions, especially on talk (there is WMF research somewhere that someone can find)
• Editor retention : Bot Human interactions can be problematic
• New Process Risk- Pushing error notifications to editors.
• User Experience - We are allowing a bot to send errors a few minutes later rather than tell the editor at the time
• Editor retention - Notifications are static. If the error is fixed, before the editor looks, then wasted effort.

Cost

• Labour - Increased effort of "ask to fix" vs "fix yourself" (Wikipedia Editor hours)
• Quality - High Failure rate - Using talk as an example (and figures based on a random sample I just did), only 5 to 10 % get a response within 5 years, or before being archived. FA are 50 &, stubs are zero
• Turnover/Retention - (see @BD2412

Benefit to Readers

• Would they notice if this is not fixed?

What do we need to monitor current state and success rate?

• Data - results from similar request processes. (notifications, messages, talk)
• Data - percentage of minor errors after receiving notification
• Data - percentage of active editors who stop being active within say 12 months of receiving notification, compared with editors who don't receive notification
• Definition of success -what percentage is success
• Policy - no process for evaluating proposal success Wakelamp d[@-@]b (talk) 08:30, 29 July 2022 (UTC)

• @Wakelamp: For the record, the "don't want to spend all of my time fixing other editor's mistakes" comment that you quote was Donald Albury, not me. BD2412 T 16:52, 29 July 2022 (UTC)

Doh! CorrectedWakelamp d[@-@]b (talk) 13:34, 30 July 2022 (UTC)

• I like this evaluation approach. But I am not sure I entirely agree with the problem statement. Or rather, I'm not sure I agree that it is a problem at all. Imperfect edits are how the wiki grows. Someone who makes a flawed edit is not "creating work for others"; they are building the project in the way it was meant to be built. But someone who demands that the contributor fix that flawed edit is, in fact, the one who is creating work for others -- and is also contributing to the dangerous perception that imperfect contributions are unacceptable. That this approach would even seem plausible is, I think, a sign of how unsustainably closed (and commensurately stressed and overburdened) the editor community has become, as the heightened barriers to entry leave a few core users to attempt to bear the entire weight of the project alone. -- Visviva (talk) 03:33, 4 August 2022 (UTC)

  @Visviva I agree that imperfect edits are crucial (and actually quite collaborative if people work well). Thank-you for sayimg you like the approach. if it was done as a one page per problem, the evaluation approach seeems to fit WP. There are gaps though in how it would work

  I agree that the problem could have been stated better, and I also was unhappy with the phrase "making work for others" The work I was thinking of was ::*:* Drive by tagging,

  • Reverting a whole change when part of it has merit
  • Causing disproportinate conflict for good faith edits,
  • All the various editor "sins".... Wakelamp d[@-@]b (talk) 09:35, 6 August 2022 (UTC)
    • @Alanscottwalker, @Visviva, @Wakelamp, Here is a list of high-priority checkwiki errors. Presumably, at least some of these, the more egregious, would be the ones tracked. These errors tend to be tricky to automatically fix, and also cause visual errors. ― Qwerfjkltalk 17:12, 6 August 2022 (UTC)

• The answer is very simple: This is a volunteer organization, and you cannot coerce anyone to do anything they don't feel like doing. If you tell a Wikipedia editor to do something, they can just not do it, and then what? If you see a mistake, feel free to fix it yourself, or not, no one can make you. --Jayron32 13:16, 3 August 2022 (UTC)

  Giving feedback about what can be done better would help editors learning how to improve their work, if they are willing to do so. I would describe this as training rather than coercion. MarioGom (talk) 21:46, 16 August 2022 (UTC)

• I recently opened phab:T315072 – which I think is a technically feasible solution to alert users of issues while they are in the editing window. – SD0001 (talk) 04:55, 13 August 2022 (UTC)

CS1 maintenance warnings

Suggestion: You need a bot to delete |url-status=dead on all pages with citations that have |archive-url= , the errors are no longer visible to correct.

Script warning: One or more {{cite web}} templates have maintenance messages; messages may be hidden (help).

.... 0mtwb9gd5wx (talk) 01:53, 15 August 2022 (UTC)

Maintenance warnings are not the result of errors as the triggering actions normally do not disrupt processing or presentation. The issue here (declaring a default value) affects editors only and is cosmetic. The documentation states that this parameter value is the implicit default when archive parameters are used, so the appearance of a related maintenance message should not be a surprise. Is it worth writing a script just to remove this? Perhaps. 68.173.78.83 (talk) 12:51, 16 August 2022 (UTC)

|url-status=dead should not be removed. This is an explicit flag that the url is dead and is quite valuable.

b

} 13:25, 18 August 2022 (UTC)

Bad new reply code

Suggestion: One can no longer use the thing that inserts —≈≠≤≥±←→§ #REDIRECT [[]] <blockquote></blockquote> <span class="plainlinks"></span> ⊉⊄∭∆⋈⊗ <math></math> {{math|}} {{sfrac||}} BOO! Bring it back .... 0mtwb9gd5wx (talk) 01:43, 15 August 2022 (UTC)

Are you complaining that the "reply" tool uses a different editor (which is more suitable to discussions)? You can just reply the old fashioned way using the "edit" link instead. —Kusma (talk) 13:58, 15 August 2022 (UTC)

The lack of a button to insert a redirect in a reply is good UX. We should celebrate that no MediaWiki developer decided to add it. MarioGom (talk) 21:39, 16 August 2022 (UTC)

A redirect wouldn't work in a [reply], because it'd be prefixed with at least one :. But still, it's a good point: much of what's in CharInsert is unnecessary or inappropriate for typical talk-page comments. Whatamidoing (WMF) (talk) 19:44, 18 August 2022 (UTC)

Removal of "link will display the full calendar" in year articles

Many articles for years on Wikipedia, such as

talk

) 21:17, 18 August 2022 (UTC)

Notified:

talk

) 21:22, 18 August 2022 (UTC)

• Remove, but only after we reach consensus on whether to provide a link which obviously leads to a calendar somewhere else such as a sidebar. Many readers will want to see a calendar for the year^{[citation needed]} but this isn't the best way to present it. Certes (talk) 22:52, 18 August 2022 (UTC)

• Replace but don't remove until then. I'd be happy to remove the in-text reference like that (agree it reads a bit awkwardly), but I think that whatever replaces it needs to be sorted out at the same time. It does seem these are reasonably well-used links - I checked a random month's clickstream data and Common year starting on Sunday is the second most popular outbound link from 786). Andrew Gray (talk) 23:07, 18 August 2022 (UTC)

Make a database for data validation when filling forms (Ex : First and last names can't take numbers)

You are getting paid to do this work. Wikipedia volunteers are not.--🌈WaltCip-(talk) 15:20, 21 August 2022 (UTC)

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

---

I work in IT. I am currently working in the government of Quebec. I'm designing tests to ensure the format of the fields in a form from a software are respected. Like, enter "abcd" in phone number should not be accepted. But I don't know all the rules. And apparently, NOBODY does!!! At least, there is no public database on the subject on the Internet. My team spent (the three of us each on our side) two hours (each) on looking on the Web (including Wikipedia) what are the rules. For example, I live in Quebec province. What are the rules for choosing a first name? Can they have digits or special characters in it? Of course not! But I couldn't find ANYWHERE where that is decided. IT ISN'T EVEN IN THE TEXT OF LAW!!!! :O :O :O

So, I believe you are getting where I want to go with this. I would like Wikipédia to host a public managed (like all your website) database where ALL the requirements all listed, based on countries or areas that have their own rules. Each person browsing the database could choose the desired countries, or all of them. Each rule would be identified by country in the search result. If some rules are common, group them together.

So here are a few examples of the fields : First name Last name Social insurance number Adress (and their various possible fields : civic number, type of street, name of street, city, ZIP code) Phone numbers Email Website Other coordinates or numbers (ex : Company number)

I mean, those are defined by governments. They exist. But, if people want to help create the database here in Wikipedia, some calls to the governments (made by the creators of contents) will have to be made, to know what is legally made.

So many people uses those, I can't believe this isn't existing already!! :O :O

Please, tell me this is possible! Alplo14 (talk) 16:46, 19 August 2022 (UTC)

• wtf? Dennis Brown - 2¢ 16:58, 19 August 2022 (UTC)

It may not be as common nowadays, but in my youth many companies would have phone numbers that were given as words. Often the numerical equivalent would not appear on their signs and media. --User:Khajidha (talk) (contributions) 18:08, 19 August 2022 (UTC)

What does any of this have to do with improving the encyclopedia? That's my point. Dennis Brown - 2¢ 18:19, 19 August 2022 (UTC)

Maybe posts here could be validated for relevance, perhaps based on keyword-pattern (exact phrase or proximity). 24.168.24.89 (talk) 18:27, 19 August 2022 (UTC)

• This would not fit even on Wikidata, and certainly not on Wikipedia. We are not a
  repository for indiscriminate information. 2601:647:5800:1A1F:40D5:8B1F:2BD2:8163 (talk
  ) 01:25, 20 August 2022 (UTC)
• Sorry, I'm not sure what you mean. Can you please be clearer? —CX Zoom[he/him] ^{(let's talk • {C•X})} 04:58, 20 August 2022 (UTC)
• Cryptic
  10:22, 20 August 2022 (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.

Moratorium on recent events

I'm not sure whether this should be proposed here or in policy. I wonder whether it would be helpful if we had a policy similar to one of these: Option 1: No article should be written about an event until the event is at least two weeks old, or perhaps better Option 2: Articles about recent events must remain in draft-space, and will not be reviewed, until the event is at least two weeks old. My reasoning is:

(1) We are an encyclopaedia, not a newspaper. We don't gain anything by being bang-up-to-date, but we lose by being biased, inaccurate, and ephemeral. The long-term meaning of an event is almost never clear in the first few weeks.

(2) We cannot get an overview of what sources think until there has been time for enough good sources to do some thinking.

(3) And we waste valuable AfC-effort, and time at AfD, trying to assess whether something is going to be notable, when if we just waited a week or two, we'd know.

My feeling is that people rush into writing articles about events, motivated either by a desire to get there first, or because they are overwhelmed with the importance of the event in the middle of which they've found themselves. Neither is a great starting point for a balanced, future-proof article. If we had to wait a couple of weeks, then by the time we started typing, we'd have better sources, our initial emotions would have settled, and we'd write an article that looks like someone thought about it. Elemimele (talk) 10:20, 6 August 2022 (UTC)

• On principle, I agree that this would be a useful approach that best serves the encyclopedic purpose of this project. Pragmatically, I expect a lot of opposition and doubt that this has a chance of gaining community consensus. Schazjmd (talk) 15:58, 6 August 2022 (UTC)
• We definitely need to tone down the recent events articles, though I'm uncertain about how it should be handled. There do exist times where recent events should be written about as fast as possible. Events like the
  WP:NOTNEWS. I think a better option would just be to raise the notability guideline for recent events to, maybe 20 pieces of coverage in reliable sources? We need some indication that a recent event will amount to more than just breaking news. —VersaceSpace 🌃
  16:24, 6 August 2022 (UTC)
• We definitely need to be better on how we rush to create articles on breaking events. There are some that should be created as soon as they have happened such as major earthquakes, commercial air crashes, and the like - we can write these articles based on primarily factual coverage and that we know these generally have long-term enduring coverage. But there's articles that should be held off until we either know they are truly significant events, or more importantly we can write impartially and neutrally about the event. --Masem (t) 16:30, 6 August 2022 (UTC)
  • I disagree with VersaceSpace and Masem that Wikipedia must document certain types of events immediately. That's the job of the news media. But short of the absolute moratorium proposed, the list of exceptions that editors would argue for would be so lengthy as to make the proposal useless. And what about immediate updates to existing articles to document new events? The OP's points #1 and #2 apply to those as well, but I doubt if there would be any community support to delay updates to articles to insure enduring significance or established perspective. Schazjmd (talk) 17:03, 6 August 2022 (UTC)
• This would never likely pass since there's no practical way to enforce it. Let's say we ban coverage of recent events? What happens if I write an article about a major Hurricane anyways? Are you going to AFD it? Okay, well that's an entire week of discussion at minimum. If it gets relisted, it might be two weeks. Then suddenly by the end of that the hurricane happened two weeks ago, so all of the points in favor of deletion just became moot. You would need to propose a new CSD criteria (which many admins would probably be reluctant to support given how many issues there would be with actually utilizing it). Misusing draftspace as suggested by the proposal just seems like a more complicated way to get around that (and would likely just lead to a lot of move wars). (
  ☖
  17:17, 6 August 2022 (UTC)
• No. Far more reasonable to delete after the fact if it turns out to be non-notable, rather than rules to prevent creation. --Golbez (talk) 18:59, 6 August 2022 (UTC)
• Wikipedia is by default a newspaper of record, with so many responsible newspapers having withdrawn behind paywalls, and what's left being so full of sensationalism and advertisements. I look to a reasonable Wikipedia article as the free online alternative. Dhtwiki (talk) 08:03, 7 August 2022 (UTC)

  I'm afraid while I have some sympathy, I disagree with this one fundamentally. Yes, there ought to be a free newspaper project, but this isn't it. The two big differences between a newspaper and us are (1) that newspapers check their facts, while we don't. (2) Newspapers are dated, and obviously valid only on the date of issue; our articles don't carry a date, and present themselves as The Truth. These are both quite subtle features that we as editors understand, but our readers do not. I really do think that if we're going to try to emulate a newspaper then we, like a newspaper, should display prominently the date on which an article was last updated, and probably even draw more attention to who did the updating, or at the very least, the source that was last used to update. Because we don't do this, there is a risk that we will launder a two-day-old opinion from a biased newspaper as though it were up-to-date consensus truth, where a reader who is genuinely looking at a two-day-old copy of the Daily Telegraph knows that they're reading out-of-date material with a right-wing bias. Sorry, I'm being a bit ferocious. But practically, I suppose we could start dating recent events; it's all there in the edit history, it's just that readers don't usually know about histories. Maybe draw more attention to the edit history of recent event articles?? I'm just thinking out loud... Elemimele (talk) 22:48, 8 August 2022 (UTC)

  Wikipedia checks the newspapers who are doing the checking, and with a late-breaking story of importance any errors are apt to be quickly contested. I don't think bias enters into getting facts straight on, say, whether a celebrity is dead, near death, broke, arrested, whatever, or how many lives an accident has claimed, which are the sorts of things I had in mind. Dhtwiki (talk) 05:25, 9 August 2022 (UTC)

  I'd disagree that we check the newspapers. We summarise them. We don't do any fact-checking at all, which means we are, functionally, no more than gossips: We repeat what we hear. I don't have a problem with that; I have a problem with us misrepresenting what we are. We shouldn't take something that the Guardian presents as current-events news and re-present it as an encyclopaedic statement of history; Wikipedia is a different context to the front page of a newspaper, and context is important to the believability of a story. We are lending undue weight. The arrest of a celebrity is an excellent example: a newspaper reports it because it happened, but doesn't say it's an important part of the person's life. When it goes in a Wikipedia article, we make a tacit statement that it's a notable feature of that person's life story. We're adding weight to the significance of the arrest before we know it's significant, and that goes beyond our sources. I totally agree that my proposition was the wrong way to solve the problem, but the problem still exists: we must stop kidding ourselves about the accuracy of our current events, and we need to find some way to indicate to our readers which articles have the mature view of history, and which are written with the raw emotion of something that happened yesterday. Writing in the style of an encyclopaedia doesn't make the content more reliable. I do think that better use of tags and templates is the right way forwards, not my daft 2-week moratorium. Elemimele (talk) 09:19, 9 August 2022 (UTC)

  WP:NOT#NEWS WP is not a newspaper, and those using it as one are using WP mistakenly. We can document current events that have a clear path to notability, or where the news are updates to existing articles, but we should not be rushing to create news article just because it is information being widely reported. We are looking for endurance of information, not a temporary burst of coverage. Masem (t

  ) 13:26, 9 August 2022 (UTC)

• No. This is one of the weirdest suggestions ever put forward. Are you seriously suggesting that Wikipedia should have waited two weeks before having an article about the
  Robb Elementary School shooting? People have come to expect that there will be Wikipedia articles about major events as soon as possible.--♦IanMacM♦ ^{(talk to me)}
  08:14, 7 August 2022 (UTC)
• It is an unfortunate reality that someone will create an article about every breaking news event,
  WP:RECENT notwithstanding. That horse has bolted. Selfstudier (talk
  ) 08:22, 7 August 2022 (UTC)
• This would be a rule that wouldn't bring a net positive to the project. Most of those we do ultimately delete as ephemeral do little damage in the meantime. The negative ones getting the "press" are far outweighed by the huge number of recent articles that we do cover, and cover well. Nosebagbear (talk) 13:19, 7 August 2022 (UTC)
• A more productive approach might be to place a big “ugly looking” tag on articles about recent events - something that could be removed after review and (probable) rewriting/summarization in a few months. This, of course, requires volunteers who are willing to DO that review and summarization. Blueboar (talk) 14:19, 7 August 2022 (UTC
• Another issue with the proposal is that many events don't involve a separate article. For example, I noticed that Anne Heche was the top read article and wondered what was up. It turned out that she'd just had a spectacular accident and so people are naturally rushing to read her article. If we had a moratorium on such breaking news then people might stop coming to Wikipedia for such information and so would look for another source instead. Why would this be good?

Blueboar should note that the Anne Heche article already has a {{current person}} template and templates like this are commonly used to tag breaking news.

Andrew🐉(talk) 07:56, 8 August 2022 (UTC)

Yes, these tags are a very good thing, and perhaps the entire proposal is unnecessary were they used more often. I only see them on pre-existing articles where the subject has just been plunged into current events because something specific happened. It'd be nice to see them used in a cautionary way on brand-new events. Is there a big ugly tag for brand new articles, basically saying '"This article refers to a very recent event, and may not yet reflect the considered view of history", as per Blueboar? Could its use be encouraged, if it exists? Maybe new page patrollers and AfC reviewers could add it when appropriate? Elemimele (talk) 22:48, 8 August 2022 (UTC)

• Nope, I can't see how a hard rule about this would always benefit our readers. A recent example, on July 25th the President of India changed after their election. How would it be better for readers going to that article to see it say that the president is Ram Nath Kovind until today? — xaosflux ^Talk 17:26, 8 August 2022 (UTC)

  Okay, would need limitation. I suppose the cases I'm thinking of are traffic accidents, building fires, natural disasters, etc., but the heart of the matter is the reporting of fact. I don't mind instant reporting of facts that are beyond doubt, and which fall into categories whose notability is beyond doubt; I am dubious about trivia and initial rumours and opinions that spread after a scary event. As a counter-example, I'd offer "had covid". We now have a phenomenal number of articles about famous people stating that they had covid, complete with sourcing. Who cares? Much of the world's population has had covid by now. It was hot news at the time, but in retrospect it's about as significant as saying they had chicken pox. It will probably be decades before all this lot has been weeded out. But I've talked myself into a hole, because a 2-week limit wouldn't have stopped the rash of "had covid" additions... I accept this proposition isn't going anywhere, and was the wrong approach; I'm more keen on clear tags. Elemimele (talk) 22:48, 8 August 2022 (UTC)

• Tentative oppose. I can see the proposer's reasoning, insofar as we are an encyclopaedia and not Wikinews. However, I have always thought that one of Wikipedia's strengths is that it must be the world's most up-to-date encyclopaedia, and this policy would make it fall short of this strength. YTKJ (talk) 19:12, 8 August 2022 (UTC)

  I see the strength in this argument. My concern is that by trying to be the most up-to-date, we also run the risk of being the least reliable; on very recent events, there is often a big trade-off between stable accuracy, and rapid response. Perhaps again this could be dealt with by a template; something to remind our readers that Wikipedia's reliability on very recent events is lower than on things that have been kicking around for longer. We, as editors, know that WP is not a reliable source. They, as readers, frequently treat it as such. We owe them honesty about our reliability. But yes, I do see your point... Elemimele (talk) 22:48, 8 August 2022 (UTC)

  @Elemimele We already have Template:Recent death and Template:Current, which tend to be added very rapidly to articles where those apply. If you would like to reword these templates or propose a new template, though, I would be willing to listen. Toadspike (talk) 00:22, 22 August 2022 (UTC)

• Just no. Schierbecker (talk) 05:36, 9 August 2022 (UTC)
• So how about better tagging of breaking-news articles so that it's clear they're merely summaries of yesterday's newspapers and not yet a mature historical view? Is there an appropriate template for a new article that is still on shaky foundations? Elemimele (talk) 09:19, 9 August 2022 (UTC)

  Yes, the breaking news template, which is already in use. --Golbez (talk) 13:11, 9 August 2022 (UTC)

  Pinging @Another Believer, who has a lot of experience with this type of article. Whatamidoing (WMF) (talk) 23:54, 10 August 2022 (UTC)

• Strong no/oppose here. We should absolutely be creating new articles appropriately. (Thanks for the ping immediately above.) ---Another Believer _(Talk) 23:58, 10 August 2022 (UTC)
• I see the good intentions behind the proposal, but oppose for three reasons: 1) there are too many exceptions to manage for cases where instant updates make sense; 2) this is a problem that typically resolves itself after a few weeks using existing procedures; 3) Applying Template:Current seems an adequate and proportionate warning during those initial few weeks. Barnards.tar.gz (talk) 13:51, 13 August 2022 (UTC)
• Oppose. I sympathize with the reasons behind the proposal, but as said by so many others there are just too many reasons that we can't, won't, or shouldn't do this. Alsee (talk) 09:37, 15 August 2022 (UTC)

  Same here from me on this, I appreciate the spirit of the proposal, but this isn't really something that has a neat solution (as far as I'm aware at least). Yitz (talk) 04:07, 18 August 2022 (UTC)

• Strong oppose. Wikipedia is widely regarded as the best source for breaking news events, and is usually far more reliable and complete than anything else out there. Concerns about poorly-written or incorrect breaking news articles are misinformed. Most of our "breaking news" articles are, in my experience, extremely well sourced, even if the writing style isn't always perfect until a few days in. When corrections are required, they happen extremely quickly. Making corrections makes us no worse than the best newspaper or scholarly source, and is not something to be ashamed of - in fact, we probably react faster than any other media. A point-by-point rebuttal would be excessive here, so in short I don't see the issue with breaking news articles, especially considering the unique benefits they provide to countless readers. Toadspike (talk) 00:17, 22 August 2022 (UTC)

RFC on having delineated sections in ANI discussions

The linked discussion is closed. — xaosflux ^Talk 18:16, 22 August 2022 (UTC)

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

---

See the proposal at Wikipedia talk:Administrators' noticeboard#RFC on having delineated sections in ANI_discussions. CactiStaccingCrane (talk) 14:54, 16 August 2022 (UTC)

Note: the proposal has been withdrawn as a

WP:SNOW in favor of the status quo.— Shibbolethink ^{(♔ ♕}

) 14:56, 18 August 2022 (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.

Notice: Election-related discussion on Pump(WMF)

See discusion at Wikipedia:Village pump (WMF)/Archive 4#WMF prohibits community from voting for candidates of our choice in Board seats election. Alsee (talk) 09:49, 12 August 2022 (UTC)

Withdrawn. There's potential concern regarding future elections, but most people appear willing to accept the process for this year. Alsee (talk) 09:29, 14 August 2022 (UTC)

I still have three concerns

1. Do they represent us The Board of Trustee's video mentions Wikipedia twice. "We are the good guys and the good gals" "If you want to get more involved the easiest thing you can do is to read wikipedia"
2. None of the skills listed include audit or accounting, or ethics, or governance. Instead "Ideal candidates align with the Wikimedia mission and are thoughtful, respectful, and community-oriented." The "Wikimedia vision Imagine a world in which every single human being can freely share in the sum of all knowledge. That’s our commitment."
3. Election transparency issues from last year Wakelamp d[@-@]b (talk) 13:50, 23 August 2022 (UTC)

Add citation style 2 to the visual editor

CS2 is arguably locally popular, but you can't add it easily in VE. According to this page you can do this, so I don't see why not. Aaron Liu (talk) 03:13, 9 August 2022 (UTC)

Indeed. I like CS2 (the {{

list-defined references too. So, I use the generate function in VE to create the citations and then toggle to the wikitext editor to reformat them into my preferred format. This is a hassle and so it would be good if this were to be a supported preference. Andrew🐉(talk

) 16:41, 9 August 2022 (UTC)

Cite → Manual → Basic → Insert any template you want. Whatamidoing (WMF) (talk) 00:01, 11 August 2022 (UTC)

Yes, that's a way to remain in the visual editor, but filling out the template is quite the hassle that simply generating, tweaking, and then switching the template to Template:Citation is much easier Aaron Liu (talk) 02:29, 11 August 2022 (UTC)

As you can see from the documentation you linked above, you could add {{citation}} to the list. However, the auto-filling citoid service probably wouldn't use it much (or at all) in practice. It doesn't have a concept of "style" or article-specific conventions. It only has a concept of "source type". All sources of a given type are put into the same template. If most editors want news sites like The Guardian or New York Times to use {{cite news}}, then it will fill out {{cite news}} for those websites in all articles, even if you wanted it to use {{citation}} for those sources in the article you're editing. Whatamidoing (WMF) (talk) 04:59, 13 August 2022 (UTC)

So that means that this proposal can do two things: 1. Add CS2 to the manual tab, which only saves 2 clicks, and is unable to take advantage of citoid. 2. add some switch to the insert button that will allow us to switch to cs2 or add the switch to preferences, which would require some scripts Aaron Liu (talk) 17:37, 13 August 2022 (UTC)

AIUI your (1) can be done here by any interface admin, but (2) requires developer support. It might be possible to do this with a gadget (e.g., to create a new button in the toolbar). Whatamidoing (WMF) (talk) 19:50, 15 August 2022 (UTC)

• More like add everything to VE - Visual editor is legitimately Wikipedia's most useful tool, and it should be fully functional. Not being able to use wiki-markup, edit references in VE when they're in a template or give them ref names is ridiculous. Doesn't Wikimedia make hundreds of millions per year? It should not be much of a task to find people to work on that. —VersaceSpace 🌃 02:43, 11 August 2022 (UTC)

  @VersaceSpace, what other kinds of wiki-markup do you want to use in the visual editor? "Rich editing" of templates is surprisingly difficult (think "a large team for a couple of years" difficult, but no worse than that). Ref names were available in 2013, and then removed. I don't remember why it was removed (only that it was there, and then it wasn't), but since it once existed, I assume that it would be manageable. It was proposed in the Community Wishlist in the past, but didn't get enough votes to win.

  What else do you miss? Whatamidoing (WMF) (talk) 04:53, 13 August 2022 (UTC)

  They may be referring to using wiki markup on tables in VE. Aaron Liu (talk) 17:33, 13 August 2022 (UTC)

  let me clarify, of course making every relevant template WYSIWYG-able would be a big task, but if that's reduced to just infoboxes and navboxes + 5 others, i assume that wouldn't require so much time. and by using wiki-markup i mean being able to type " '' " and get italics etc. —VersaceSpace 🌃 23:10, 14 August 2022 (UTC)

  VersaceSpace it's more complicated. I'll try to squeeze the history&problem down to just a few sentences. In ~2011 the Foundation published a plan to quote "deprecate wikitext". (Correction: The exact phrase to search for is "deprecate wiki syntax", which has the exact same meaning".) The WMF built Visual Editor to supersede wikitext on article pages, and later Flow was to supersede wikitext on talk pages. They built VE as an HTML editor. VE itself has no ability to edit wikitext. In order to get VE working on articles, and to support a transition from wikitext-based-articles to html-based-articles, they build Parsoid as a temporary hack. Parsoid translates wikitext into HTML, that HTML is handed to VE, then VE's HTML output is handed back to Parsoid to translate back into wikitext to be saved. VE in-itself is a fine piece of software that has had rather few bugs - if they had not tried to deploy it on a wiki. Almost every problem with VE is actually due to Parsoid. Anyway the point is that expanding VE's abilities the way you want is very difficult because (1) VE has no idea how to handle wikitext and (2) Parsoid runs into ugly problems when it hits a template during its round trip translation-process. Alsee (talk) 07:36, 15 August 2022 (UTC)

  The linked page does not actually contain the words "deprecate wikitext". It does provide a "brief description" of a project in the area of "Features that make it possible or easier to contribute content" in these words:

  "Technology to deprecate wiki syntax as the primary input method used to create content in Wikimedia projects, and to instead make it possible to compose complex pages using a rich-text editor which also intuitively represents templates, magic-words and other wiki-specific paradigms.

  It seems to me that deprecating wikitext code specifically and solely "as the primary input method used to create content" is rather different from broadly "deprecating it", with the implication that not just your first edits or the ones in which you're focused on creating content, but all of them forever and regardless of purpose, must be without wikitext, which is the way that that the one word seems to be misrepresented.

  Also: if someone doesn't want to learn wikitext, why shouldn't they be allowed to edit in the systems they prefer? As Alsee's been told at least a dozen times (probably that many times just by me), there is no plan to take wikitext away from the people who want to use it. There never has been – not even in 2011, when the quoted statement indicates a goal of deprecating wikitext syntax only as "the primary input method" (and even then, the visual editor was only meant to be the primary method for the specific task of creating content; wikitext would still be the primary method for all other types of manual editing). Despite the persistent FUD on this point, nobody has ever said that wikitext would be deprecated for all purposes. If you like wikitext, use it. If you don't like it, don't use it. If you like it for some purposes and not others, use the one you think best suited for the task at hand. You can even edit wikitext directly in VisualEditor; the mw:2017 wikitext editor is VisualEditor's built-in wikitext mode.

  @VersaceSpace, almost all wikitext syntax except italics and bold gets 'translated' into the correct code. Try, e.g., typing {| to start a table, <ref to start a citation, * to start a list, or {{ to start a template in the visual editor. The visual editor knows what all of those mean and will do the right thing for you. (The difficulty with '' is that sometimes people actually want to type those as part of the text, e.g., if you are of the generation that was taught to use two single quotation marks to fake a double quotation mark.) Whatamidoing (WMF) (talk) 20:24, 15 August 2022 (UTC)

  @Whatamidoing (WMF) I corrected the exact search quote from "wikitext" to "wiki syntax", which has the exact same meaning. I apologize to anyone who tried searching for it and had trouble.

  I continue to reject your claim that the plan was to allow us to continue using wikitext. You can't destroy our car, give us a broken bicycle with "car" scribbled on it in crayon, and claim we'd still have a car. That indicates either a lack of understanding of the word, or Public-Relations type wordgames.

  The WMF showed us exactly what the result is when they remove our wikitext engine and stop saving wikitext, they showed us exactly how a secondary mode wikitext-substitute works. It was so dysfunctional our top four communities all demanded the code be uninstalled and banished. English Wikipedia, Meta, Commons, and German Wikipedia all demanded it be uninstalled. It was so diseased that it would be actively harmful to subject any new user to it. Implying that such a system could or would be retained indefinitely is hardly reasonable or realistic. Such a system would and should die as swiftly as possible.

  The plan was, and still is, to kill off our wikitext engine. That active plan is now called "Parser migration project". The original plan was also to stop saving as wikitext. I am not aware of any current active plan on that part, however I am also unaware of any explicit WMF decision to reject or terminate that part of the plan either. Alsee (talk) 14:16, 16 August 2022 (UTC)

  As far as I know, the full wikitext engine is still here. Replacing it as a primary input method is like designing cities around cars (VE) instead of designing them for bicycles. We can still ride our uncrippled bicycles however we want, bicycles are generally better, but most people just use cars anyways. Internally, all pages are still stored as wikitext, and there isn't a very easy way to change that. How would you save pages if you don't save them using wikitext? using wikitext v2 electric bungaloo? using html? using markdown?

  Searching "parser migration project wiki" returns no relevant results. Aaron Liu (talk) 14:41, 16 August 2022 (UTC)

  @Aaron Liu the Foundation has been working on killing off our wikitext engine since 2011, with constant delays. Here is the Foundation's Phabricator task declaring an intent to have terminated use of the "core parser" (our wikitext engine), and instead use VE's Parsoid engine, in 2021. And as you can see work is continuing on that task this year. That task links to Parser Unification, synonymous with Parser migration. That states the long term goal to completely remove our current wikitext engine from the codebase, instead use VE's Parsoid engine.

  Internally, all pages are still stored as wikitext, and there isn't a very easy way to change that. They spent a fortune of money, building everything around a plan to do exactly that. If we review what I said about about how VE works, you can see how they made it easy. They built VE as an HTML editor with no ability to edit wikitext - because end goal was to switch everything over to HTML. In order to get a VisualHTML editor to work on the existing wiki, they had to build Parsoid to translate wikitext articles into a form of HTML. Then VE can edit that HTML. Then then Parsoid translates that HTML back into wikitext for saving. If you skip that last step each page would be saved as HTML instead of wikitext. At that point they would have to keep "wikitext" editing available in some form, at least for some time, because VE is still not able to do everything we need. They built Flow around that end plan - and that is exactly how Flow works. In Flow pages are stored as HTML. If you try to use wikitext in Flow, Parsoid converts the HTML into fictional-wikitext that it displays for editing. When you preview or save, it throws away the wikitext, Parsoid converts it back into HTML. I don't know how much experience you have with Flow, but the so-called "wikitext" support is horribly broken. And to repeat, I do not know of any currently active plan to switch to saving everything as HTML. However but I am also unaware of any WMF decision to reject or terminate that part of the plan. But if you make HTML-editing the primary interface, staff would have to be incompetent not to go forwards with that part of the original plan. Alsee (talk) 16:56, 17 August 2022 (UTC)

Parsoid is still a wikitext engine, it translates back and forth between HTML and wikitext. They aren't "killing off" our wikitext engine, they're replacing it with a newer one since having two tools that do the same thing isn't very optimal. There are a lot of other explanations for why they built VE as an HTML editor. From a software perspective, modularity is important, and seperating the modules can make them easier to maintain. AIUI Flow is only for discussions, things saved with Flow are still stored as wikitext., and you can think of flow as a gadget for discussions. Plus, there isn't anything very wrong with wikitext, why would they spend fortunes to replace it? Aaron Liu (talk) 17:52, 17 August 2022 (UTC)

There definitely is a plan to replace the old PHP parser, which turns wikitext into content that can be read in a web browser. But the plan is to replace the old PHP parser with the newer Parsoid parser, which also turns wikitext into content that can be read in a web browser. Wikitext itself isn't going away. There has never been a plan, or any part of any plan, "to switch to saving everything as HTML". Whatamidoing (WMF) (talk) 19:07, 18 August 2022 (UTC)

...unless maybe someone has mistaken current behavior for "saving everything as HTML"? Because right now, when you make an edit, the servers actually do write everything down in HTML. It's just that this is in addition to, rather than instead of, storing the edit in wikitext. If the servers didn't "save everything as HTML", you wouldn't be able to see the article with your new edit in it. After you click the big blue button, the wikitext gets recorded and parsed into HTML, and it's the HTML that gets sent back to your web browser so you can read the article you just edited. Whatamidoing (WMF) (talk) 19:11, 18 August 2022 (UTC)

@Whatamidoing (WMF) https://www.mediawiki.org/wiki/Parsoid/About In the longer term, using HTML as the storage format can eliminate conversion overhead when rendering pages, and can also enable more efficient updates after an edit that only affect part of the page. This was not merely written by written by a WMF employee, it was written by the employee who led development on the Parsoid project.[7] The page history shows the quote was written in 2013, and it was certainly part of the thinking when they designed the Visual-HTML system in 2011.

Then there's https://phabricator.wikimedia.org/T112999 Let MediaWiki operate entirely without wikitext Sep 2015 The long-term goal of the Parsoid team is for Parsoid to eventually disappear, replaced by HTML-only wikis and round-trip conversion tools to simpler "source" formats. That was written by a WMF employee working on the Parsoid project. Before you jump to quote the subsequent comment, I'll do so. It goes on to say Wikipedia projects will continue to rely on wikitext for a long time yet. However that merely acknowledges that it will take time to reach the Parsoid team's goal of fully eliminating Wikitext on our wikis. Alsee (talk) 23:26, 18 August 2022 (UTC)

Yes, people have speculated about doing that. VisualEditor itself was designed so that third-party sites could use it without installing MediaWiki or using wikitext. I believe that PLOS One was using VisualEditor in its non-MediaWiki-based mode for article submissions. That doesn't say anything about what the movement is doing.

The visionaries are probably correct that if Wikipedia still exists next century, that nobody will be using wikitext. But there is no plan to make it happen, and even if it happens some time, I have no good reason to believe that it will happen during my lifetime. Whatamidoing (WMF) (talk) 19:11, 24 August 2022 (UTC)

Heh, one correction: Flow does not store ithe text in wikitext but instead in fact in HTML. It leads to issues like phab:T209120 where the HTML input/output from Parsoid has changed. IznoPublic (talk) 21:33, 18 August 2022 (UTC)

Proposal: Remove WP:Contents from the sidebar

I don't think that this page serves much of a purpose. People will most likely search for the term rather go to the contents. Interstellarity (talk) 01:38, 12 August 2022 (UTC)

It's hurting no one, and those that stumble upon it have a great way to explore the Encyclopedia. Keep it.

b

} 02:14, 12 August 2022 (UTC)

Agreed. Lean is the best. If we choose not to delete it, we should integrate the page more at the main page. This seems to the a relic from the Wikipedia's olden days in 2001. CactiStaccingCrane (talk) 12:57, 13 August 2022 (UTC)

It's a possibility if you'd want to look into the research on the general usage of the sidebar (see this recent MW UI report, also being discussed in relation to whether to adopt a new skin, for example). You should also consider however that all summer at least there have been proposals at the main Village Pump (Vital Direct, VA Reform currently on the page) for reinvigorating the Vital Articles projects, which is basically what makes up the Contents pages (or is more or less the spirit of them). Consider adding your concerns to one of those threads or WikiProjects, since there seems to be momentum for a complete overhaul of how VA is done, and that could mean a completely different concept of a "Contents" page (if one exists at all). SamuelRiv (talk) 23:25, 16 August 2022 (UTC)

The RfC was clear that we want portals

Turning the question on its head, the coentents page seems to have a much lower usage than the other side bar pages, is it as simple as changing it to Explore Wiikipedia? (Posted a comment on Wikipedia_talk:Portal

{I am very hopeful about VA changes as well (even though it has actually been all summer :-))). Wakelamp d[@-@]b (talk) 00:39, 25 August 2022 (UTC)

Add language status to Template:language infobox

Hi, I'm an editor mainly focused on formatting citations. Since I'm interested in linguistics, most articles I edit are about this topic; this includes articles about languages.

UNESCO has published a list of endangered or soon-to-be-endangered languages called the Atlas of the World's Languages in Danger,^[1] classified into groups: from Vulnerable to Critically Endangered and Extinct, akin to IUCN Red List for species.

My proposal is as follows: Add the necessary code to

MOS:SMALLFONT. The example for Breton also includes Template:Cite UNESCO Atlas

as a reference.

Images for the different groups are: File:Lang Status 20-CR.png, File:Lang Status 40-SE.png, File:Lang Status 60-DE.png, File:Lang Status 80-VU.png, File:Lang Status 99-NI.png, and File:Lang Status 01-EX.png. I volunteer to upload SVG versions of these files.

I hope I made myself understood and proposed this correctly; please don't hesitate to ask any questions. Thanks for reading, cheers, ${\displaystyle swar}$e • 🗣 • 🏲 15:28, 25 August 2022 (UTC)

References

1. ISBN 978-92-3-104096-2. Archived
   from the original on 23 July 2022.

A few minutes after posting this proposal I found a very similar, if not equal, idea with an in-depth discussion over on Template talk:Infobox language. Are these discussions independent? I mean, should I delete this proposal? ${\displaystyle swar}$e • 🗣 • 🏲 15:37, 25 August 2022 (UTC)

We do try to keep discussions in one place. But, don't delete this, leave it as a pointer to the existing discussion. - Donald Albury 18:34, 25 August 2022 (UTC)

Request for comments on research study

Update: Based on the feedback received below, we have now created the page User:FABLEBot/New URLs for permanently dead external links, which lists a random sample of the URL replacements discovered by FABLE for links which have been marked permanently dead.

As was suggested below, I made a post about this at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(miscellaneous)#Request_for_feedback_on_research_project_for_fixing_dead_links. HarshaMadhyastha (talk) 13:59, 29 August 2022 (UTC)

We would greatly appreciate the community's input on that page to help us gauge the accuracy of FABLE's output. Your feedback will help us ascertain if the URL replacements discovered by FABLE are sufficiently accurate that we can request permissions for our bot to directly edit articles and patch dead links.

As part of a research project at the University of Michigan, we have been developing a new system for fixing broken links on the web. Given a broken link to a web page, our system, FABLE (which stands for Finding Aliases for Broken Links Efficiently), attempts to find the new URL at which that same page now exists on the web; please see the web page for the FABLE project (https://webresearch.eecs.umich.edu/fable/) for more details on how our system works.

To gauge the accuracy of the URL replacements identified by FABLE, we are hoping to conduct the following study. We have run FABLE on a subset of links that have been marked as permanently dead (Category:Articles with permanently dead external links). For each such link where FABLE has found the new URL for the permanently dead link, we plan to make a post on the Talk page of the corresponding article seeking feedback on whether the new URL identified by FABLE looks correct. We have developed a bot (User:FABLEBot) to make such posts, and an example of the posts it would make is on my Talk page (User talk:HarshaMadhyastha).

Before we file for approval for our bot, I am posting here to seek your comments and concerns about this study. Thank you! HarshaMadhyastha (talk) 15:02, 9 August 2022 (UTC)

Hi @HarshaMadhyastha. Thank you for thinking of Wikipedia for this project and for consulting the community before proceeding with this idea. I think the general direction of this project is good, but I am quite worried about the number of talk page messages such a bot will generate. Talk page messages are "expensive" in that they stay around as clutter for a long time (forever on many pages) and generally bots do not leave messages on article talk pages. There are a couple other designs that could work better. One is to have an off-wiki website interface on which authenticated users can approve or disapprove particular URL changes. Another is to create a single page on-wiki that lists all, or many, of the proposed link replacements all in one place, similar to Wikipedia:Database reports (e.g. Wikipedia:Database reports/Potential biographies of living people (1)), that users can work through in bulk. Let me know if we can further discuss these ideas. Best, KevinL (aka L235 · t · c) 15:46, 9 August 2022 (UTC)

Oh, I just remembered the example of "bot posting talk page messages" not going well. It was InternetArchiveBot (talk · contribs), which posted "External links modified" sections on talk pages and really irritated community members (example), and if I remember correctly got blocked for it.
Separately, one other thing that you probably shouldn't do is direct people to an off-wiki site just to provide feedback. (Off-wiki hosted sites that use OAuth to actually perform the change, such as [8], and hosted on Toolforge, are probably OK.) They can provide feedback on-wiki, perhaps in a templated or tabled form that's machine-readable. Hope that's OK with your study methodology. I don't think you'll get community support otherwise. Best, KevinL (aka L235 · t · c) 15:49, 9 August 2022 (UTC)

InternetArchiveBot stopped posting on talk pages after this 2018 discussion, with the main motivation being (if I recall correctly) that the error rate was low, and the action performed wasn't significant enough to be worth posting about. Uanfala (talk) 16:48, 9 August 2022 (UTC)

Thank you for the feedback User:L235! I certainly appreciate the concern regarding clutter on Talk pages. For now, our plan was to post on the Talk pages of at most 200 articles, as our goal at the moment is just to gauge the accuracy of our system's output. Do you think the community would support such a limited one-time study? One of our motivations for posting on Talk pages was that users who are watching the Talk page of an article are more likely to have the necessary context for the external links included in the article.

Alternatively, I really like your idea of creating a single page which lists all proposed link replacements. We are working on creating such a page on our project site, but we could instead create it on-wiki, if that would make it more palatable. Do you have any suggestions/thoughts on what such a page should look like? Would it suffice to have a table with columns for "Wiki article", "Dead link in article", and "Potential replacement URL for dead link"? What would be the best way to seek user feedback on which of the rows in the table are correct? HarshaMadhyastha (talk) 16:42, 9 August 2022 (UTC)

Hi @HarshaMadhyastha, one other concern about the talk page messages is that you aren't going to get many responses. If you do 200 pages, I'd be surprised if you got 20 people reviewing the link.

Re the page, two more columns you can add are: (1) the full citation (not just the link), for context, and (2) a column for users to mark whether the correction is good or not. Best, KevinL (aka L235 · t · c) 16:52, 9 August 2022 (UTC)

Hi @User:L235, A quick follow up question: if we were to create a page which shows a table of the URL replacements that we have discovered, any thoughts/recommendations on how we would draw the community's attention to this page? Thank you. HarshaMadhyastha (talk) 13:54, 10 August 2022 (UTC)

Why don't you do ths in the Test Wikipedia??

And is your experiement part of your Wikimedia grant for links the same thing? Wakelamp d[@-@]b (talk) 07:46, 23 August 2022 (UTC)

Some ideas that are probably better than talk page messages: Use a tool similar to https://oabot.toolforge.org, or just make edits to the article directly and trust page watchers to correct any incorrect matchings. * Pppery * _{it has begun...} 16:01, 9 August 2022 (UTC)

Thank you. We were concerned that having our bot directly edit articles would receive pushback, since some of the URL replacements we find are likely to be incorrect. So far, by our estimation, we get only 5% wrong, but that's still more than 0 :)

What safeguards would you recommend we put in place in order to get approval to directly edit articles? HarshaMadhyastha (talk) 16:46, 9 August 2022 (UTC)

That's really up to

the bot approvals group, who will likely approve the bot for a trial of some small number of edits, then evaluate the fixes for themselves and/or see if anyone complains, not me, but remember that even an incorrect repair does not cause much harm since the original dead URL is not very useful. * Pppery * _{it has begun...}

17:11, 9 August 2022 (UTC)

This sounds really useful! I don't see any major problems with talk page posts, and it may even be the preferable option during the pilot run. However, I agree that it may be better to eventually skip it. Maybe the bot can just update the url, add a custom tag (some variant of ^[verification needed]), and allow editors to either approve the edit by removing the tag or to reject it by reverting the bot's edit. There should be a way to catch those accepts and rejects automatically, right? A link for editor feedback can also be available within the tag (or its corresponding help page) and in the bot's edit summary. Uanfala (talk) 16:48, 9 August 2022 (UTC)

• support pilot The effect on Wikipedia is 200 talk page messages, which is acceptable. If this proceeds then I expect registration at meta:Research:Projects, publishing a plan to publish research findings in a way that the Wikimedia community can accept, and a commitment to responding to questions and comments after posting the messages. I was one of the people who complained about the similar Internet Archive project, but in that case, there were several hundred thousand talk page messages posted, and that high number was the project. 200 seems reasonable; if someone complains then a lower number could be negotiated but to me this seems fine. If you are able to give more to this project, then commit to more documentation or publishing a peer reviewed paper, as the Wikimedia community appreciates that. Thanks. Bluerasberry (talk) 16:53, 9 August 2022 (UTC)

Thank you all for the comments, suggestions, and feedback. Greatly appreciated! My students and I will discuss how best to proceed and circle back here soon.

We have been working for a couple of years now on improving FABLE's coverage, accuracy, and efficiency. Looking forward to apply our work to help tackle link rot on Wikipedia. HarshaMadhyastha (talk) 20:23, 9 August 2022 (UTC)

A few scenarios

1. If the goal is to simply evaluate the potential, instead of 200 messages, you could simply consolidate the suggested urls on a centralized page for review. This could be in the bot's own userspace and wouldn't need any big community input so long as it stays in userspace. See
   WP:BOTUSERSPACE
   for the relevant guidance.
2. If the goal is an actual bot, and the bad match rate is unknown, the OABot model would be a good one, where the bot is making a suggestion and a human approves. This would be a semi-automated tool and wouldn't need a
   WP:BRFA
   .
3. If the goal is an actual bot, and the bad match rate is low/acceptable, the bot could make its own edits. But there would still a need for an extensive trial and a
   WP:BRFA
   .

In all cases

b

} 11:53, 11 August 2022 (UTC)

Thank you for the input.

Currently, we are definitely leaning towards option 1. Our main concern is: how will those who are interested in providing feedback on the URL replacements we find learn about our page's existence? This is why we are thinking that, once we create our page that lists all the URL replacements that we have found so far, we would also post on the Talk pages of 200 of these articles (after getting bot approval, of course). These Talk page messages would point users back to our consolidated page, thereby helping raise awareness of its existence.

Any thoughts/suggestions? HarshaMadhyastha (talk) 18:03, 11 August 2022 (UTC)

@

b

} 02:13, 12 August 2022 (UTC)

Sounds good. Thank you very much for the pointers!

We are currently simply churning through all articles listed in Category:Articles with permanently dead external links in alphabetical order. HarshaMadhyastha (talk) 02:29, 12 August 2022 (UTC)

I'll mostly be agreeing with things said by others, but I'll rapidly run through a stream of points: Fixing deadlinks is a desirable project, cool. The community tends to be very cautious with mass bot edits, you'll get much easier acceptance if you either post the proposed changes to be handled by humans, or implement some sort of tool where people can accept/reject/pass. We've found mass talk-page bot posts to be a semi-permanent nuisance clutter - if you do make bot talk posts you should make them as lightweight as possible. (The last bot to post on talk left a rather sizeable blob of text, for significant visual clutter.) I think a minimal post would consists of (1) a short section title like "deadlink bot" (2) a statement "See [link] for project information or to provide feedback" (3) state that [link] has been changed to [link], and (4) "You may revert this edit if it appears incorrect" and bot-signature on the same line. I think that would be about half the size of your example post. When you need editors to review or do work on something you can post here on Village Pump to get volunteers - if that doesn't draw enough people you can request escalated advertising for the effort. Regarding posting on ~200 talk pages as a trial, while I would consider that acceptable I think you're really better off posting a list or making a tool as I suggested earlier. You'll get zero review or feedback from most articles. I think we're up to around 6 million articles, the majority are obscure deserted wilderness. For obscure articles it can be years before any editor takes note of a talk page post. Alsee (talk) 06:43, 15 August 2022 (UTC)

Thank you @Alsee. Given all of the earlier feedback, our current plan is to create a page which lists the URL replacements discovered by our system. So, that's inline with what you are suggesting.

I'm hoping that we'll be ready with a first version of our page soon, at which point I'll share it here to get feedback. 68.49.106.206 (talk) 12:30, 16 August 2022 (UTC)

Sorry, I forgot to login before posting my previous reply. Just confirming that it was indeed me! HarshaMadhyastha (talk) 12:32, 16 August 2022 (UTC)

In case you didn't notice, you can review these edits at User:FABLEBot/New URLs for permanently dead external links. — Qwerfjkltalk 20:31, 29 August 2022 (UTC)

Figure skating at the Olympics

I followed up on this at my talk page, this is premature for a community proposal right now, splits are already allowed if they follow the guideline mentioned below. — xaosflux ^Talk 21:46, 29 August 2022 (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.

---

Hello! Is it possible to add own article regarding Figure skating events from 1964 until 2002. I mean own articles about the different events e.g. Single skating, pairs and Ice dancing. The article should start with Figure skating at the 1964 Winter Olympics – Men's singles etc. It would be of great value that the articles are added Yours sincerely, Sondre 88.88.4.178 (talk) 15:28, 29 August 2022 (UTC)

Why 1964 and 2002 in particular? What's wrong with

Cryptic

15:57, 29 August 2022 (UTC)

88, this doesn't really require a central proposal. If I'm reading you correct, you'd like to split pages such as Figure skating at the 1964 Winter Olympics in to more articles. This is fine as an overall concept, however I don't think there is enough content on this topic to support stand-alone articles. See Wikipedia:Splitting for guidelines on this. One way to start would be to make a draft of one of your proposals (e.g. Draft:Men's singles figure skating at the 1964 Winter Olympics) and ask others to review it for you. — xaosflux ^Talk 16:00, 29 August 2022 (UTC)

Ok. I mean if it is possible to split the articles. I meant figure skating at the 1964 Winter Olympics – Men's singles etc. Or Figure skating at the 1992 Winter Olympics – Men's singles etc.

Yours sincerely, Sondre 88.88.4.178 (talk) 21:41, 29 August 2022 (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.

Proposal: Dark Mode Button

Nothing actionable has been proposed, developers interested in working on a mediawiki darkmode can follow up at wikitech. — xaosflux ^Talk 13:46, 30 August 2022 (UTC)

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

---

I propose that a button be placed on the basic interface that toggles between light mode and dark mode, available to all users, whether with an account or not, to easily and quickly toggle between light and dark as one needs. -- 64.229.88.43 (talk) 04:18, 22 August 2022 (UTC)

• WP:DARK. – The Grid (talk
  ) 12:46, 22 August 2022 (UTC)
• The way the dark mode gadget works is by modifying the user's preferences for enabled gadgets. It's impossible for unregistered users to use the dark mode without getting a flash of the bright page before going dark on every page load. Nardog (talk) 16:21, 22 August 2022 (UTC)
• WP:RFCBEFORE. – SD0001 (talk
  ) 16:42, 22 August 2022 (UTC)

As many websites can do this without need of logging in, the need for an extension to do this with Wikipedia doesn't appear to be the case. Perhaps, all users who are not logged in can access one button gadget, while those who are logged in get another. Adding an extension is non-trivial for many users of Wikipedia, if they use wikipedia from consoles that are not their own, such as public access consoles in public libraries. Saving the eyestrain for these users would be a plus for accessibility of Wikipedia -- 64.229.88.43 (talk) 22:05, 25 August 2022 (UTC)

To enable this here, it needs to be invented first, so this isn't an actionable proposal specific to the English Wikipedia. Feel free to head over to wikitech:Help:Getting Started to learn how to start. — xaosflux ^Talk 00:20, 26 August 2022 (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.

RFC

Wikipedia talk:In the news has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. BilledMammal (talk) 01:19, 1 September 2022 (UTC)

Requesting talk page access revocation via AIV instead of ANI

Historically, the revocation of talk page access (TPA) for blocked users has been handled via

blocking policy

, TPA should be revoked in cases of continued abuse of their user talk page, or when the user has engaged in serious threats, accusations or outing which needs to be prevented from reoccurring. This is exactly under the remit of AIV, which is described as a noticeboard for active, obvious, and persistent vandals and spammers. The administrators' incidents noticeboard (ANI) has long been known to cause drama and sometimes have increased resolution times compared to other noticeboards, so I believe that redirecting cases of TPA removal to a more concentrated location would help with ease of requesting.

For implementation,

• The format of AIV can be changed to the below:

  ==Reports==
  ===General===
  ====Bot-reported====
  ====User-reported====
  ===Talk page access===
  ====Bot-reported====
  ====User-reported====

• {{vandal}}, the template used to link to users at AIV, can have a new version created specifically for TPA revocation requests, with an additional link that filters contributions to that of a user's own talk page, in order to streamline the reporting flow.
• The AIV helper bot(s) will need to be updated to allow for the new layout, and to not automatically flag already-blocked users in the new section reported with the new template
• A new bot can be coded or requested that will automatically report when blocked users trigger several edit filters (on edits to their talk page)

Pinging @

talk

) 21:48, 18 August 2022 (UTC)

Notified:

talk

) 21:52, 18 August 2022 (UTC)

• AIV is the appropriate place. It has been for years, if it weren't for the bot. However, adding complication to the AIV layout is not a great idea, IMO. People already struggle enough with the layout, they trash it, ignore it, existing admins won't have the additional pages on their watchlist, and there's probably other problems. Another thing, the last time the AIV bot went MIA, it was also reported that the operator hadn't edited for seven months, before some kind of magic fairy made it work again some hours later. When it comes to bot developers and operators, just sayin'. Otherwise, sounds good to me. -- zzuuzz ^(talk) 22:31, 18 August 2022 (UTC)

  I wouldn't bother with the format change, just set up the bot to not remove the entry if the user is already blocked if there is a flat or template or something in the request. ScottishFinnishRadish (talk) 22:36, 18 August 2022 (UTC)

  I would be open to considering using only a parameter in the vandal template as a differentiator for TPA/regular requests if it reduces confusion.

  talk

  ) 23:01, 18 August 2022 (UTC)

• Support, as that's what the page is designed for. CactiStaccingCrane (talk) 11:01, 19 August 2022 (UTC)
• What problem does this solve? Most of the time that TPA is taken away, it wasn't reported anywhere, the blocking admin or other admin simply notices. Often, the reason that TPA has to be blocked is because the person was already blocked, at ANI. So User:Example gets blocked at ANI, the report is still active, he acts like a jerk, and you want to have to go through AIV to get access removed? That doesn't make sense. That is bureaucracy for the sake of bureaucracy. Right now, most people simple tell the admin that did the block to begin with if it isn't noticed, and s/he, or talk page stalker admin, will take care of it.
• Is there a problem with TPA not being removed fast enough? I mean, what exactly is the problem that this is supposed to solve? Can you please point to a few instances were someone opened up a new ANI report to get TPA removed and it caused this drama you speak of? Dennis Brown - 2¢ 17:05, 19 August 2022 (UTC)

  I personally don't see it as a drama thing, I see it as a routine thing. There's a fair amount of random talk page disruption that happens, e.g. this. A nice twinkle or redwarn quick-report is easier than tracking down an active admin or opening an ANI thread. ScottishFinnishRadish (talk) 17:14, 19 August 2022 (UTC)

  That's probably not the best example. Most of the time TPA is removed because of their actual words, not spamming a template. Spamming a template, find AIV, but if the issue is they were blocked and are just going berzerk, pinging any admin is fine, ANI is fine, etc. Most of the time that TPA needs to be removed, it is right after a block, and the blocking admin is already monitoring. Often other admins are as well, if it was due to an ANI report, so reporting isn't needed anyway. In fact, ANI reports asking for TPA to be removed are exceedingly rare. What is more common is someone commenting on an already open ANI case. What I don't want to see (and you WILL see if that rule went into effect) is someone reports TPA needing to be removed, at ANI, and some policy wonk tells them to report it to AIV instead, even if there is already an open case. And then they discuss it for a while..... That isn't really benefitting anyone. Realistically, it doesn't matter where it is being reported, and I don't see a need for a hard rule for any board. Any admin worth their salt can look and tell if they need TPA removed. Adding more rules, however, is a problem with

  WP:CREEP. It just isn't necessary. Short version: this seems like a solution looking for a problem. Dennis Brown - 2¢

  17:25, 19 August 2022 (UTC)

  I've had multiple times that I tried to report template spam, or whatever this (needs admin goggles) and this were to AIV before I even realized the bot just removes them. I'm more interested in having the ability to report things like that to AIV. Right now there's no quick and easy way to report unambiguous talk page vandalism by a blocked user. ScottishFinnishRadish (talk) 17:31, 19 August 2022 (UTC)

  If it is vandalism of any kind, you can report it to AIV now. AIV isn't limited to main space. I'm not getting the distinction. Again, it seems like new rules for the sake of rules. If the offense was talk page vandalism specifically, you currently can report it to AIV, or ANI, or AN, or any admin already. Dealer's choice. How would creating a new rules improve this? Dennis Brown - 2¢ 17:47, 19 August 2022 (UTC)

  Let me try and clarify a bit. If a user is blocked and vandalizes their talk page you cannot request action at AIV, a bot eats the report. For example. Or 10 hours later when I didn't realize the bot eats them, and the disruption was continuing. ScottishFinnishRadish (talk) 17:57, 19 August 2022 (UTC)

  Thank you, that was really confusing for some reason. Then the problem is technical, not policy based. Has anyone approached JamesR and explain the problem? He may have some ideas, he is an admin and the bot operator, so I'm assuming he has good clue. Again, I don't see a need for policy changes, just tweaking the bot. Lot of ways to do that, I'm not sure which would be best, but he would know. Dennis Brown - 2¢ 18:18, 19 August 2022 (UTC)

• Support Why report, say, serious defamation at a place intended for long and tedious discussions? ~~ lol1VNIO (I made a mistake? talk to me) 09:57, 21 August 2022 (UTC)
• Changing the layout of AIV to anything more complex than "bot-reported" and "user-reported", especially by creating two new sections dedicated to rare situations, isn't an improvement. The actual issue here isn't AIV's layout, the issue is that reporting an already-blocked user leads to the report being instantly removed automatically. We can do that manually instead; it doesn't happen too often. If the timestamp of a report is newer than the timestamp of the current block, don't automatically remove the report. A bot issue, not one with AIV. ~ ToBeFree (talk) 11:02, 21 August 2022 (UTC)

  The AIV helper bots do have other unfixed issues (in some situations they output broken edit summaries). I remember reporting that a while ago, so I don't know how quickly any feature request would be implemented. —Kusma (talk) 15:41, 2 September 2022 (UTC)

• Please don't change the layout; that might break other bots or scripts. Just fix the bot so that it ignores reports with a dummy template like {{revoke talk page access}} unless talk page access is already revoked. Suffusion of Yellow (talk) 19:01, 21 August 2022 (UTC)
• I've edited the proposal to exclude the section portion after feedback.
  talk
  ) 02:04, 26 August 2022 (UTC)

Should Template:cnote and Template:cref be deprecated in the same way Template:ref, Template:note, Template:ref label and Template:note label are?

I've come across an article (Cleveland Torso Murderer) using {{cnote}}, a template I've never encountered before, which seems to encode similarly, or at least behave the same as {{ref}}, {{note}}, {{ref label}} and {{note label}}.

I click on the ^{[little hyperlinked square brackets]} next to a piece of text (I'm on mobile) and nothing pops up; on inspection of the Notes section, the text for the note is encoded there. But on clicking the ^ hyperlink, it won't link to the place in the text where the note is – much like {{ref}} and {{note}}.

Should {{cnote}} and {{cref}} be deprecated? We have {{efn}} and {{refn}} for the same purposes, and they seem to work just fine; I can't think of a reason for {{cnote}} and {{cref}} to exist.

Sorry if this isn't the correct forum for this – none of the forum descriptions mention template discussions and I figured this would be the best place to ask.--

ping

}} me!) 12:53, 10 September 2022 (UTC)

Templates for discussion is probably the best place to propose depreciation. See also the previous discussion about these templates: Wikipedia:Templates for discussion/Log/2018 March 31#cnote templates. 192.76.8.74 (talk) 12:59, 10 September 2022 (UTC)

RfC: Should we use the longstanding external links icon or the new one?

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

There is consensus to keep the old icon, and a weaker consensus that the old icon isn't very good either. I think the real consensus here is that the community would prefer approving a new icon, or having input on the design, before implementation. ScottishFinnishRadish (talk) 22:27, 4 September 2022 (UTC)

---

Tracked in Phabricator
Task T261391

Recently, a new icon has been rolled out and implemented for external links. Should we use the longstanding icon or keep the new one? —

talk

) 04:26, 29 July 2022 (UTC)

Discussion: Should we use the longstanding external links icon or the new one?

• Use the longstanding icon. The old icon was functioning quite fine, no editors on EnWiki seemed to complain about it, though the Wikimedia foundation decided to make changes to the current Vector skin that has used the longstanding external links icon. The new icon, frankly, is too thin to properly render on my monitor and (per comments on phabricator) it appears to be this way on low-density screens more generally. While some may be ok using the new icon before it is fully finished, I personally am frankly disappointed that the way that this icon renders on low-density screens was not given due consideration before its implementation. The longstanding icon should be used until the glaring issues with how the new icon renders on different screens are resolved. —
  talk
  ) 04:26, 29 July 2022 (UTC)
• This is clearly premature. --Izno (talk) 04:37, 29 July 2022 (UTC)

  I disagree. If anything was premature, it was pushing the icon onto EnWiki without (a) local communication that this was going to happen and (b) testing to make sure that the icon would appear well on low-density screens. —

  talk

  ) 04:39, 29 July 2022 (UTC)

  I disagree, no one is asking you about the 300 changes per week being deployed and you should be glad, you don't have enough waking hours to read them. Be bold and revert is a much better strategy. —TheDJ (talk • contribs) 14:34, 29 July 2022 (UTC)

  Per TheDJ. In addition, the change itself has already been reverted in the source. See phab:T261391#8112692. Izno (talk) 15:24, 29 July 2022 (UTC)

  Hi @

  Mhawk10 and all,
  Volker E. here, I'm Design Lead at the Wikimedia Foundation Product Design team and this change implemented by myself is part of a multi-year user-interface standardization approach. In short the icon collection design and agreed upon by the Design team follows generalized guidelines

  
  

  First things first, as @Izno already shared, the proposed icon change has already been reverted by us. The rollout featured two problems that we haven't fully anticipated. This will not go into production as is. For completion, visit also the corresponding Phabricator task.

  Second, we have been working and implementing a unified icon set with various quality characteristics for several years now. Among the characteristics are reduction to the essential form and making the icons as universally recognizable as possible. Keep in mind, that given the small icon size, the lesser the details, the better they are recognized by the users. Other high visibility icons, which have changed during that time were 'search', 'user avatar', 'watchlist', 'edit' (pencil) or the 'language' icon. Also Wikipedia's mobile frontend/Minerva Neue skin features the proposed new icon for over a year already. Users switching from mobile to desktop should find the same icons for the same thing.

  Third, the current (old) icon features long-standing technical issues. It's not sizing up when users increase text zoom (a common accessibility feature in use) in their browser preferences and doesn't hold up to other quality characteristics above, like the most simple form.
  

  Therefore we're aiming at amending the icon patch once more and at reintroducing it with better targeting all the special cases undiscovered before. Also with more testing time upfront. It should then work well for lo-dpi and hi-dpi (“retina display”) environments and without technical issues that were caused by having it featured in a bigger font-size in running text and smaller one in References.

  – Regards, Volker E. (WMF) (talk) 13:40, 1 August 2022 (UTC)

• b
  } 04:44, 29 July 2022 (UTC)

  This isn't about just me, and I'm aware of how to do customizations. The issue is that affects readers who have low-density screens by making the rendering sloppy. —

  talk

  ) 05:19, 29 July 2022 (UTC)

  Bikeshedding is when you get caught up discussing the color of the bikeshed instead of the construction of the nuclear power plant. The point isn't that one should never care about the color of a bikeshed. After all, there may be all sorts of aesthetic, logistical, and environmental concerns absolutely worth raising about a bikeshed's color. It just shouldn't become the focus over more important things. So if Mhawk had started this RfC in the middle of a discussion about the external links guideline, then yeah, that'd be bikeshedding. But it's perfectly fine to start a discussion with the specific scope of deciding what the icon should be, just like it's fine for the nuclear power plant to put together a committee with the dedicated purpose of picking a color for the bikeshed. -- Tamzin^{[cetacean needed]} (she|they|xe) 06:41, 29 July 2022 (UTC)

• Use the longstanding icon, per
  MOS:RESOL and Mhawk's comments. BilledMammal (talk
  ) 05:56, 29 July 2022 (UTC)
• Use the longstanding icon per the visibility concerns Mhawk raises. A new icon that doesn't render right is about as useful as installing chandeliers in a condemned house. —Jéské Couriano v^_^v ^{a little blue Bori} 06:27, 29 July 2022 (UTC)
• Looks like the change was undone last night – I assume we will see the old icon again on Thursday — GhostInTheMachine ^{talk to me} 09:07, 29 July 2022 (UTC)
• Comment: I like the new icon but to me on my mobile screen using desktop site, it appears as four disconnected straight lines which is rather awkward to see. The old one at least worked fine. —CX Zoom[he/him] ^{(let's talk • {C•X})} 09:44, 29 July 2022 (UTC)

  I'm on regular desktop and I see the same: four disconnected lines as the box. Also at high zoom it becomes clear the the diagonal arrow looks terrible and it's got obvious issues. So the "new image" shown for this RfC doesn't match the actual image being used for the external links. Jason Quinn (talk) 16:27, 29 July 2022 (UTC)

• Given that the change has been reverted for now this RfC should be closed. Sam Walton (talk) 11:19, 29 July 2022 (UTC)
• The old icon looks like ass. I mean, I kind of grew attached to it over the years, but let's be honest, it was very much a product of its time. It doesn't make sense. Look at it for a minute. There is this big, open arrow, and a random diagonal line in the middle of the icon, that's a completely different color. Maybe there are some problems with the new one (it looks fine on my desktop computer but it seems like some people were having issues) -- but come on, there's a lot of room for improvement. jp×g 11:53, 29 July 2022 (UTC)
• What do you mean "has been rolled out and implemented"? I still see the "old icon" on EL's. — xaosflux ^Talk 13:31, 29 July 2022 (UTC)
  • I’m still seeing the new icon on desktop while logged out and logged in. What skin are you using? —
    talk
    ) 14:10, 29 July 2022 (UTC)

    Looks like this is skin-specific; only seeing the 'new' one in (minerva, vector, vector-2022). FWIW, I don't really care one way or the other there. — xaosflux ^Talk 14:37, 29 July 2022 (UTC)

• WP:BIKESHED, no one should care, start writing articles or become a designer ffs —TheDJ (talk • contribs
  ) 14:02, 29 July 2022 (UTC)
  • Seconded! Another waste of time survey to distract people from meaningful discussions and content creation. Aza24 (talk) 20:51, 29 July 2022 (UTC)

  It is good that people care about the site's design and point out problems with updates. Your dismissive attitude is not helpful. —Kusma (talk) 12:13, 30 July 2022 (UTC)

• While I don't like the old icon much and will not shed a tear when it gets replaced by something better, the new icon sort of breaks when I decrease my font size. (Just tested on zhwiki, which has the new xlink icon but the old PDF icon). I am hoping we'll see a third icon that is better than both soon. —Kusma (talk) 16:00, 29 July 2022 (UTC)
• The old icon should be used until resolution issues are fixed. That said, the new one if it renders correctly is much clearer than the old icon. —Danre98^{(talk^contribs)} 16:44, 29 July 2022 (UTC)
• Reconsider when they want to re-add, if we care I'm not quite on the "let the devs do and only revert if needed" side as suggested as pure default, but I don't think this would have been the drastic change that heralded the (formal) dev takeover without prior notice. It's been rightly reverted. Presumably it'll only be re-added when they're fairly confident that it'll serve all the usecases of the current one - i.e. when it's down to being a stylistic choice. As both are perfectly understandable I pray we can skip the pdf slog as I really couldn't care less at that point. Please consider this !vote as a akin to a procedural close !vote, if it matters. Nosebagbear (talk) 21:08, 29 July 2022 (UTC)
• Comment. What articulatable problem does this icon change solve? Not super clear from the phab thread. In my opinion, the icon's reduction in density is a bit jarring. –Novem Linguae (talk) 03:10, 30 July 2022 (UTC)
• Make the new icon thicker, per others. The new icon is inherently better as it is more modern, easier to see, etc. People who are wanting the old icon back can copy a CSS code from somewhere. A rocky implementation should not kill a good idea. CactiStaccingCrane (talk) 13:16, 30 July 2022 (UTC)
• WP:BRD Andrevan@
  21:32, 30 July 2022 (UTC)
• New logo no issues with the new logo, I think there's some response bias in terms of people actually liking the new logo but not commenting here. This isn't a big deal IMO. Use the new one. Therapyisgood (talk) 01:53, 31 July 2022 (UTC)

  The problem is not that proposal logo is bad. Infact, I like the modern feel of it. The problem is that what has been proposed, isn't the one being seen by many, if not all, of us. User experience should be the driving force behind change, not making changes for the sake of making changes when there's lots of rather urgent technical issues needing resolve. —CX Zoom[he/him] ^{(let's talk • {C•X})} 06:41, 31 July 2022 (UTC)

  This is a terrible, terrible argument. It would be akin to "We should solve all the problems on Earth before exploring space", i.e. we should never explore space because there will always be urgent problems needing to solve. CactiStaccingCrane (talk) 13:27, 13 August 2022 (UTC)

  For what it's worth, I prefer the new icon. ― Qwerfjkltalk 18:02, 31 July 2022 (UTC)

• Oppose any local solution. Just use whatever MediaWiki and Vector developers decide to use. If you want to push a certain option, do it on Phabricator or Meta, not here. Nardog (talk) 02:01, 31 July 2022 (UTC)
• Use the longstanding icon. In Chrome a 1920x1080 monitor in Windows 10, the new icon looks disjoined and lopsided. --Ahecht (TALK
  PAGE) 18:10, 31 July 2022 (UTC)

link text ← At least for me, this example is missing the line on the right side, which is even worse. --Ahecht (TALK
PAGE) 13:35, 1 August 2022 (UTC)

Patch author here. The (second) implementation has featured a technical issue with the icon canvas, hence the lost side lines. We've reverted the patch, but will provide an updated one which aims to work in your case. Please see also my message to the original thread. – Volker E. (WMF) (talk) 15:01, 1 August 2022 (UTC)

• Old one - 2560x1440 resolution and the border lines are incredibly thin, almost looking missrendered. Anarchyte (talk) 08:15, 1 August 2022 (UTC)
• New one I'd never considered we could change it, but now that I know we can, I agree that the old one looks not great. CaptainEek ^{Edits Ho Cap'n!}⚓ 03:28, 2 August 2022 (UTC)
• Old one or neutral if it ain't broke, don't fix it. But I'm not terribly fussed if we change it. New icon is not terrible, to be honest. Oaktree b (talk) 22:57, 2 August 2022 (UTC)
  • @Oaktree b, note the comment above, the current (old) icon features long-standing technical issues. It's not sizing up when users increase text zoom (a common accessibility feature in use) in their browser preferences and doesn't hold up to other quality characteristics above, like the most simple form.  ― Qwerfjkltalk 17:24, 3 August 2022 (UTC)

    OH, I'm ok with the migration to the new icon in that case. Oaktree b (talk) 18:10, 3 August 2022 (UTC)

• I was using a low-DPI screen the other day and the new icon looked like crap. I also saw the four disconnected lines, and the arrow looked quite ugly. If there’s an updated version of the new icon that fixes these problems, I’d love to see it, but until then, keep the status quo. Also, please fix the viewport for desktop view on mobile. —pythoncoder (talk | contribs) 00:13, 3 August 2022 (UTC)
• Longstanding one The new one's lines are too thin and pixelated for Vector legacy (2010) on Brave browser running on a 1920x1080 monitor. The old one's big and outlined arrow, which makes it easily recognize, definitely makes up for the smaller box in my opinion. ~~ lol1VNIO (I made a mistake? talk to me • contribs) 10:08, 5 August 2022 (UTC)
• Longstanding one, or at least make it optional; I personally stand against the simplification of logos, IMO they usually look like crap. Iazyges Consermonor Opus meum 15:10, 5 August 2022 (UTC)
• Make the new icon thicker The old icon is unnecessarily complex and does not scale, and the new icon matches the commonly seen "external link" or "opens in new window" icons found in applications or on other websites. The only issue I see is that the stroke weight needs to be thicker to be visible at small sizes. {{u|Bowler the Carmine}} (he/him | talk) 21:27, 9 August 2022 (UTC)
• I was not going to comment when I first saw this, but reading the comments above, perhaps that would mean I'm in silent agreement with the change, so here I am, butting in to say I don't ;) I use a low DPI setting on my screen and very much prefer the old icon. The new icon still looks blurry and hard on the eyes at 12px, and I don't see how getting rid of colours is an improvement either. Why not simply make the old icon scalable? Daß Wölf 18:58, 12 August 2022 (UTC)
• Request – Can we get a mockup of what the new icon would look line in context? Graham (talk) 05:55, 14 August 2022 (UTC)
• Support new icon, but not this one. The old one looks terrible and has not aged well at all, but the new one is not thick enough and doesn't display well at low resolutions. –
  ^T∕_C
  07:23, 15 August 2022 (UTC)
• Note: A new icon has been proposed –
  ^T∕_C
  07:28, 15 August 2022 (UTC)

  It looks great! However, because of the storm of comment when the icon was changed, I think it is much harder for the community to accept the new icon. It's another instance of the

  bike-shed effect. CactiStaccingCrane (talk

  ) 09:47, 15 August 2022 (UTC)

• Use MediaWiki's default, whatever it looks like. This isn't a wiki-specific decision to make. ~ ToBeFree (talk) 10:49, 21 August 2022 (UTC)
• Support new icon, provided the change is made globally. The current one looks outdated and this really shouldn't be a decision made wiki-by-wiki. Graham (talk) 05:55, 1 September 2022 (UTC)

Communication issue

@Volker E. (WMF), AHollender (WMF), and Jon (WMF): Completely separate from the issue of whether or not the new design is an improvement (which I still need to investigate more before forming an opinion), I think we need to take a bit of space here to diagnose what went wrong with communication between the WMF and the community. This is a major design change (far more impactful than the PDF icon change for which there was a CENT-listed RfC) that should have been presented to the community rather than rolled out unilaterally. Why didn't that happen? {{u|Sdkb}} ^talk 14:37, 29 July 2022 (UTC)

Because the PDF change took 3 months ? —TheDJ (talk • contribs) 14:43, 29 July 2022 (UTC)

The WMF had nothing to do with the pdf change; the icon is a local thing used by MediaWiki:Common.css circa row 92. In addition, per TheDJ above, there are several changes each week and I don't think enwiki needs consulted about every single one. Devs being bold and others reverting if necessary (as someone has) works just fine. —Danre98^{(talk^contribs)} 16:48, 29 July 2022 (UTC)

I really have to question it as a "major design change". No, New Vector is obviously such, but the external link tag is not. The pdf change took forever because so many proposed changes were un-understandable. Nosebagbear (talk) 21:10, 29 July 2022 (UTC)

The external links icon is not a "major design change" but it is extremely visible. Many of the key Wikipedians are some of the most thoughtful, helpful, and capable people on the planet. Maybe it's just me but I think common sense suggests to consult them before making any highly visible global change. Jason Quinn (talk) 02:30, 30 July 2022 (UTC)

It makes no economic sense however. —TheDJ (talk • contribs) 08:59, 30 July 2022 (UTC)

And yet, I didn't notice it until I saw this discussion. - Donald Albury 16:19, 30 July 2022 (UTC)

I would agree with

☖

18:41, 30 July 2022 (UTC)

"There should be some sort of community review before highly visible changes go live." There is, you can register on gerrit.wikimedia.org and review to your hearts content. You can read all the many dozens of MediaWiki.org pages that summarise some of the changes and you can participate in any Phabricator ticket that has the "design" tag (currently about 1100 open tickets all mostly about 'visible' things). —TheDJ (talk • contribs) 09:06, 2 August 2022 (UTC)

Please review mw:Bug management/Phabricator etiquette before posting comments on Phab tickets (it's not difficult, but it's not a Wikipedia talk page). Also, voting-type behaviors are banned; this is not the place to discuss who supports/opposes something (although links to external discussions are usually welcome). Whatamidoing (WMF) (talk) 20:08, 2 August 2022 (UTC)

@

☖

21:38, 2 August 2022 (UTC)

Not every change needs an RfC, but every change that alters how we view or interact with the website should be presented to the community; if there are reasonable objections, we can then open a broader discussion and if necessary an RfC. BilledMammal (talk) 00:11, 30 July 2022 (UTC)

“If they have to change something, they should change broccoli” … Harrumph! Blueboar (talk) 22:02, 2 August 2022 (UTC)

Blueboar, We love to diss the WMF, but we should also look at how suck we are. We imposed a double standard. CactiStaccingCrane (talk) 13:15, 13 August 2022 (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.

Implementing consensus

It appears that a new icon has been implemented but based on the consensus above the WMF should have discussed with us before doing this. Given they have not, I feel the most appropriate action is to reverse the implementation, but it is not clear how we do this. BilledMammal (talk) 00:25, 10 September 2022 (UTC)

I'm not sure if a consensus of 'the community would prefer approving a new icon, or having input on the design, before implementation' was appropriate to draw from the discussion. Most participants did not address that and most discussion wasn't focused around it. Perhaps it is true that the community generally agrees with that statement, but I'd prefer to see (wider) focused discussion on that question before deciding that there is consensus for it. —Danre98^{(talk^contribs)} 03:06, 11 September 2022 (UTC)

I opposed above, but looks like the issues are now gone (at least on my devices). So I support the change, it is consistent with the constantly modernising UI not just on WP but literally everywhere. *If* someone is still facing the problems outlined above, I would say revert back to old icon, one that works. I hope nobody faces them. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:52, 11 September 2022 (UTC)

Request for Hoax Archival

Former Hoax Articles "The Heat Is On (TV series)" and "Eric van Viele" are not archived as subpages of

WP:HOAXLIST despite being the longest lasting hoaxes at the time of their deletion. Atavoidturk (talk

) 20:02, 10 September 2022 (UTC)

This isn't something that needs a VPR discussion—if you think it's necessary, feel free to ask the deleting admins (Liz for

WP:HOAXLIST. Extraordinary Writ (talk

) 05:15, 11 September 2022 (UTC)

Can't someone also just copy the archived page? --Rockstone^{Send me a message!} 08:46, 20 September 2022 (UTC)

Limit to max GA proposals per user.

Note to those not familiar with this, from clarifications below: This discussion is about if the number of articles someone can nominate to be classified as a Good Article should be throttled. — xaosflux ^Talk 16:00, 9 September 2022 (UTC)

Per a very long ANI discussion, there was an issue of a user who was pumping out subprime GAs, at a near blinding rate. This came with an issue of many of these pages being rush jobs with very serious copy-vio issues (worst case we're going to have to stubify 200+ GAs, though it is unlikely). This issue drastically came to affront when said user began using the claim they had 60 GAs over 60 days (And used their total GA count) as a defense, ironically raising concerns over how this event likely deprived far more deserving nominations of a speedy review and was a massive drag on the GA backlog.

It was proposed on ANI that there may be a need for a max number of GA nominations one can put out at a given time. This would both help alleviate the GA nom backlog and prevent low quality articles from being 'pumped out'. I am proposing that there needs to be a hard cap of 25 GA noms that can be put out by any one person at a given time, in order to ensure quality of articles. Etriusus (Talk) 18:03, 8 September 2022 (UTC)

Do we have any evidence of this being a recurring or widespread issue? If it's just one editor a topic ban or personal restriction would be a better way of dealing with this. Adding sitewide limits for everyone seems like unnecessary rule creep unless there is actually an issue that needs to be addressed. 192.76.8.74 (talk) 18:31, 8 September 2022 (UTC)

Its preventative measure.

WP:CCI is now going to have to contend with 200+ Good articles and its unclear how far this issue will go. Even if it's one user, the fact this process was abused so heavily warrants some kind of policy change to keep it from happening again. While I agree that 25 is a rather arbitrary number, we do need some kind of cap simply because at some point, it becomes impossible to ensure quality if you're nominating 50 articles simultaneously. Etriusus (Talk

) 18:39, 8 September 2022 (UTC)

I think the problem is that Doug's GA reviewers didn't check the sources and did not look for copyvio (other than running Earwig). If we improve the quality of reviews, the quantity of nominations per user will not matter (and for users with a history of poor nominations, we should ban that user from nominating quickly rather than change the process for everyone). Steps in this direction are already on the way (the most recent GA backlog drive did explicitly ask for source checks) and will do more for quality than arbitrary limits. —Kusma (talk) 19:42, 8 September 2022 (UTC)

I don't disagree with that point. Perhaps a separate discussion for having a formal rule for spot checks during GA reviews is needed? Etriusus (Talk) 19:45, 8 September 2022 (UTC)

Firstly, if there is no evidence of a widespread problem that this limit would actually address then the addition is only going to harm contributions from good editors. Secondly, if a rule is going to apply to basically nobody then there is no point in it existing - it is just pointless policy clutter adding to the already huge amount of policy on this site.

WP:IAR allows us to act in accordance with common sense in response to unexpected events or weird edge cases, policy doesn't need to cover every possible piece of disruptive behaviour. 192.76.8.74 (talk

) 12:50, 10 September 2022 (UTC)

How would fewer nominations by Epicgenius lead to more quality? —Kusma (talk) 18:33, 8 September 2022 (UTC)

Epicgenius has only 16 noms at the moment. I have no doubt in the quality of his work. I am shooting for a number such that Epicgenius, Chriswick Chap, and similarly prolific nominators can be relatively unaffected but prevent such abuses as 50-60 simultaneous nominations. If you think the upper number needs to be workshopped, what do you propose? Etriusus (Talk) 18:45, 8 September 2022 (UTC)

I've just looked at a few random points in the history of Wikipedia:Good article nominations/Report, and the only people I've seen with more than 25 nominations were Epicgenius and Chiswick Chap. Doug Coldwell indeed often had more than 20 open nominations, but so did Lee Vilenski. —Kusma (talk) 19:30, 8 September 2022 (UTC)

At the height of Doug's activity, he was hitting over 30 GA nominations at a time (Fall 2020 & Spring 2021). He did have at least [9] instance of 50 simultaneous noms. Etriusus (Talk) 19:42, 8 September 2022 (UTC)

Good to know, thanks for finding that revision. I still think that instead of outlawing large numbers of simultaneous noms, we should perhaps look at the report and see "50 nominations" as a warning sign that somebody could be cutting corners while mass producing. I'd rather try to work on finding the bad eggs than annoy the good ones. —Kusma (talk) 20:52, 8 September 2022 (UTC)

I would support 1 GA nom per person at a time, to match with FA. casualdejekyll 18:47, 8 September 2022 (UTC)

I would absolutely oppose that. The beauty of GA nominations is that you can nominate your GA when it is ready, not when your previous GA has been reviewed, so you can work at your own pace (sometimes I nominate five articles in two weeks, sometimes two articles in five years). FA has limits (one nomination per user as well as unreviewed nominations timing out) because they keep all reviews on one page so people can read everything easily. GA (which has been deliberately designed to be an easier process) does not need these limits. —Kusma (talk) 19:39, 8 September 2022 (UTC)

I would also strongly oppose this. The problem is that GA nominations can languish for months before getting a review. In specialized topics with few active GA nominators and reviewers (such as the one I focus on, mathematics, one of the top-level GA classifications), this problem is especially acute; such a limit would imply that those topics are limited to single-digit numbers of new GAs in a year, and that for the vast majority of time I would be unable to work on GAs at all (having no new nomination slots available to prepare articles for and no on-topic nominations to review). If limits are imposed, they should be on the rate of new nominations, not on the number of outstanding nominations. For instance, I've been limiting my nominations to approximately one per week (which is not a significant limitation because it usually takes that much of my editing time to get an article polished enough for a GA nomination). —David Eppstein (talk) 20:00, 8 September 2022 (UTC)

I'd like a limit, but 1 GA per person is hilariously low. With the current backlog, that would limit your average article creator to less than 10 GAs per year. Trainsandotherthings (talk) 21:19, 8 September 2022 (UTC)

@

WP:GANR has plenty of examples of months-long reviews that have just been abandoned by their reviewers. A one-GAN cap is not feasible for that reason.

If you think a limit would increase GA quality, I would be fine with a limit within a certain time period, e.g. 1 GAN per week, or a higher hard limit, e.g. 10 simultaneous GANs. There is no reason anyone would ever need to nominate 30 articles for GA all at once. However, there's also no evidence that, aside from this specific case, other prolific nominators have similar issues with their nominations. Consistently subpar nominations can be handled with topic bans as necessary. – Epicgenius (talk

) 22:51, 8 September 2022 (UTC)

• That isn't the problem. This is ONE user, not a systemic problem. If someone is cranking out bad product, you topic ban them from doing it. You don't create yet MORE
  WP:CREEP for the hundreds of thousands of other editors, and admin, to deal with. We don't need a new policy every time someone screws up, we just need to sanction them for disruptive editing. Dennis Brown - 2¢
  20:55, 8 September 2022 (UTC)

  I agree. This was a problem with one person. The problem wasn't that they were making too many submissions. The problem is that they were making low-quality submissions and gaming the system. Address the problem directly.

  My first introduction to Doug Coldwell was about 1.5 years ago when a submission of his was one of my very earliest GA reviews. Even at that stage, it was clear to me something was wrong. Here's a quote from an off-wiki correspondence I had with a more experienced reviewer whose opinion I sought out: I see that the author has been an exceptionally prolific GA author. The problem is, I don't think the writing is very good. I get the impression that they're just going for volume, and relying on their reviewers to do all the hard work of turning it into high-quality prose. I would expect that somebody who has written 100+ GA articles would write better than this.

  If I could figure that out as a newbie, surely it wasn't a mystery to the GA regulars. If there's no better process, go to ANI and get a topic ban enacted. -- RoySmith (talk) 21:18, 8 September 2022 (UTC)

• Oppose - the (rare) cases of abuses of the system are better addressed on a user-by-user basis, rather than throttling everyone. Hog Farm _Talk 21:13, 8 September 2022 (UTC)
• Seeing this isn't going to go anywhere, I'll retract the proposal. Etriusus (Talk) 21:15, 8 September 2022 (UTC)

  It might be interesting for it to be mentioned when the ARBCOM led AfD discussion starts. Gusfriend (talk) 06:35, 9 September 2022 (UTC)

  No matter the best of intentions this amounts to

  advocacy and a slippery slope

  . Articles like

  Cigarette would certainly be a candidate for a cancer warning, a parental warning for Nudity, and the list goes on... -- Otr500 (talk) 06:20, 15 September 2022 (UTC)

  @Otr500 I think you replied to the wrong thread… Madeline (part of me) 08:05, 16 September 2022 (UTC)

• My bad, thanks, -- Otr500 (talk) 10:28, 17 September 2022 (UTC)

If the GA process can't handle the incoming rate of nominations, then it may be necessary to address the problem by throttling the queue. What does the community of GA reviewers think: can they handle the queue, and what changes would they suggest to help? isaacl (talk) 03:15, 9 September 2022 (UTC)

From what I've observed, every so often (about every 6-9 months), a GA review drive has to be arranged due to the constantly growing backlog of unreviewed GANs. On the other hand, users with 3 or more nominations (currently listed at Wikipedia:Good article nominations/Report#Nominators with multiple nominations) only comprise a little less than half of the current backlog - 245 of 510 nominations, to be precise. The top 5 users, with 10 or more nominations, only have a combined 78 nominations right now. This leads me to think that throttling the queue will have a limited effect on the GA backlog, if it does impact the backlog at all. Furthermore, editors with multiple nominations will likely still nominate their articles later, so you're only delaying the backlog, rather than actually reducing it. – Epicgenius (talk) 13:31, 9 September 2022 (UTC)

Delaying the backlog is beneficial: it reduces the daily amount of work for reviewers, and it distributes the queue delay across the submitters, instead of consolidating it into one bottleneck that affects everyone. isaacl (talk) 15:25, 9 September 2022 (UTC)

Because articles can sit in the queue for months, the work is already distributed. Introducing artificial throttles in the nomination process will not spread out the same work more evenly, because it is already spread out. It will not significantly reduce the total work, because as we have already seen from numbers above, most nominations do not come from nominators with many nominations. The only likely effect will be to push away prolific contributors to the GA process. Except in the rare cases where someone is both prolific and problematic, it is hard to understand why this would be beneficial. —David Eppstein (talk) 21:50, 9 September 2022 (UTC)

I agree if the vast majority of submitters are already self-limiting themselves to just one article in the queue, then there would be little impact to having a formal limit. It comes back to my original question: is the regular processing rate of the queue able to sustainably handle the regular input rate? Are there any changes that can help maintain a sustainable throughput? Are there any feedback mechanisms that can be used? isaacl (talk) 00:22, 10 September 2022 (UTC)

The input rate is mostly controlled by a large number of low-volume submitters. Throttling high-volume contributors will not affect that. Sustainability is mostly controlled by the willingness of volunteers to review submissions, the large commitment of time that it takes to do a proper review, and the unwillingness of the GA community to sacrifice the quality of the reviews by forcing inexperienced reviewers to review more through a QPQ requirement. Throttling high-volume contributors will also not affect that. —David Eppstein (talk) 01:00, 10 September 2022 (UTC)

Yes, I agreed with you. Is there anything that can be done to balance the available volunteer resources with the large number of submitters? isaacl (talk) 01:12, 10 September 2022 (UTC)

• GAN's? — xaosflux ^Talk
  13:50, 9 September 2022 (UTC)

  Xaosflux, my issue more so has to do with the fact that eventually, if one has so many GA noms open at once, it become impossible to ensure quality. Doug broke 50 GAs at one time back in 2020 and we are currently cleaning up one giant mess at ANI. Epicgenius mentioned limiting users by the rate at which they can nominate articles (e.g. 1 nom per week or something similar) which I am also open to. I am not criticising those who have large numbers of Good articles, I'm criticizing the practice of 'quantity over quality". Helping the backlog is a side effect, no the intended goal.

  Ultimately, this issue has elucidated a serious problem in GA review, seeing that potentially 200 subpar GANs got pushed through (JPxG made an excellent analogy for this at ANI). I'm trying to find a solution, not necessarily the solution. By all means, if you have a better proposal I'm all ears. Etrius ( Us) 15:46, 9 September 2022 (UTC)

  @Etriusus thanks, I was just clarifying that the problem being discussed was not about many "Good Articles", but about many "Good Article Nominations", correct? (In the lead you framed the problem to be about ...a user who was pumping out subprime GAs...). (Or is this about a Good Article reviewer promoting what shouldn't be a Good Article to that status? Any of us not familiar with the details are bound to get a bit lost in this proposal right now) — xaosflux ^Talk 15:55, 9 September 2022 (UTC)

  You are correct, thanks for the clarification. Etrius ( Us) 15:57, 9 September 2022 (UTC)

  Thank you, I put a top note. — xaosflux ^Talk 16:01, 9 September 2022 (UTC) about that. — xaosflux ^Talk 16:01, 9 September 2022 (UTC)

* Overuse of RFCs doesn't help. It is rare for a single article, or a single editor, to have more than one or two productive RFCs open at a time. Before starting a lot of RFCs, please check in on the RFC talk page for advice.

The RFC process had some similar problems with this a while back, with one or two editors opening ~10 RFCs at a time. After a year or so, we eventually settled on telling people what's normal, rather than setting a hard limit. The result was the box I've copied over here. I've not seen any similar problems since then.

Looking at the numbers from Epicgenius above, it should be possible to tell noms what a reasonably normal number of open noms is with a fairly high degree of certainty. Editors at WT:GAN can figure out what they want to advise the higher-volume noms to do. (Maybe ask on the talk page? Maybe review a few yourself? – whatever you think would help).

The advantage is that you're not creating a rule that can be broken. You're just alerting people to the difference between normal (e.g., it's okay to have more than one nom open) and potentially problematic noms. WhatamIdoing (talk) 19:28, 14 September 2022 (UTC)

I like this idea for both RFC and GA.Gusfriend (talk) 04:11, 17 September 2022 (UTC)

• Is the problem really that we are getting too many nominations… or is it that we don’t have enough reviewers to work through the backlog? If the latter, how can we attract more editors to volunteer? Blueboar (talk) 11:51, 17 September 2022 (UTC)

  Blueboar, as someone who's dipped in and out of the GA process for many years, I think that we sometimes lack reviewers, we often lack reviewers who are competent in specific subject areas, and that amount of work expected, if you judge by what you see in GA review pages rather than the actual criteria, has grown over the years and may have reached the point that it would-be reviewers might give up before they even try it out. Take a look at some of my first GA reviews, such as Talk:Hyacinthoides non-scripta/GA1 or the quick-fail at Talk:Algeria/GA1. It doesn't have to be a long slog with a bunch of nitpicky comments about non-required things like consistent citation formatting. Sometimes reviewing an article can take an hour or two instead of a week or two. WhatamIdoing (talk) 17:56, 19 September 2022 (UTC)

  Could it be both? That having too many nominations is discouraging reviewers? I can only speak for myself, but I'll share this anecdote: a few years ago I did DYK reviews. I stopped doing them when I noticed that an overwhelming majority of the backlog was just the same few editors who were nominating over 100 DYKs; I would say they were "churning" DYKs, despite QPQ, etc., I personally didn't want to be the "personal editor" for a small handful of people who were taking up most of the queue. I also got sick of sorting through the queue to figure out who nominated what and who was new, etc. So I just stopped. Same reason I almost never do a GA review. I have no idea if anyone else shares my feelings on this. Levivich (talk) 14:48, 20 September 2022 (UTC)

  @Levivich I totally agree. I only have a handful of GA submissions (and a similar handful of reviews). It takes a lot to get me riled up, but something that really pisses me off is when I put in a lot of effort doing a review and then discover that the author/submitter isn't putting in the same amount of effort to work on the issues I found. -- RoySmith (talk) 14:55, 20 September 2022 (UTC)

  Imagine a scatter graph with the horizontal axis "volume of submissions" and the vertical axis "quality of submissions". Someone like Epicgenius is at top right, with high-quality submissions and lots of them. Doug Coldwell, who seems to have stopped editing for now, was somewhere in the bottom right -- lots of submissions, poor quality. That's the troublesome corner. Perhaps limits, if we have them, should only apply to users who've been identified as being in that corner -- or the other way round; to have the limits not apply there needs to be a consensus that your work is good enough? Don't quite see how that could be made to work, but Levivich's and Roy's comments are concerning since if that corner drives reviewers away, it's a serious problem. Mike Christie (talk - contribs - library) 15:50, 20 September 2022 (UTC)

  I think if anything, the solution is to have a cap but a very high cap, one that 90% of editors would never come close to. (I couldn't guess as to an actual number.) Then have a process where an editor could apply for permission to be exempt from the cap, and that involves some review of their prior work to ensure it's up to snuff. Similar to autopatrolled. IIRC, such caps have been proposed in the past, including one at DYK this year, but haven't gained consensus. Levivich (talk) 16:03, 20 September 2022 (UTC)

  This is the current list of editors with more than one nomination. Mike Christie (talk - contribs - library) 16:20, 20 September 2022 (UTC)

  Thanks for that Mike, interesting. It looks like there are:

  • 5 editors with 10+ open noms
  • 16 editors with 5-9 open noms
  • 21 editors with 3-4 open noms
  • and something like 300-400 editors with 1 or 2 open noms?

  Am I reading that right? Levivich (talk) 16:30, 20 September 2022 (UTC)

  You're reading it correctly, but the last number isn't quite right, I think. I make it 227 nominations total by editors with 3 or more noms, which means about 270 nominations by editors with 1 or 2 noms. If, say, forty editors have two nominations, then there are about 190 editors with a single nomination. Mike Christie (talk - contribs - library) 16:50, 20 September 2022 (UTC)

  I wonder what would happen if there was a queue just of GA/DYK noms by first-time nominators. Levivich (talk) 17:28, 20 September 2022 (UTC)

  Interesting idea.

  WP:GAN, along with the number of promoted GAs each nominator had? Mike Christie (talk - contribs - library

  ) 17:57, 20 September 2022 (UTC)