Jump to content

Wikipedia:Village pump (proposals)/Archive 191

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

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

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

Consultation on Search improvements

Hello everybody from the Structured Data Across Wikimedia team!

We are currently investigating a number of visual improvements to Special:Search, to enable users to better find the information they are looking for. This is part of a greater initiative that we are conducting, called “Search Improvements”, and we are interested in hearing your feedback.

What do we want to do?

As you will see, most of the proposed changes are graphical improvements to the current way Special:Search looks like. Our goal is to provide better context and better layout for casual readers who want to use the Wikipedia search page, as well as promote awareness for Wikipedia’s sister projects by rearranging the “sister projects” search section.

In particular, we want to:

By clicking on the blue links, you can see a mockup of the proposed changes. You can also see all mockups at a glance by visiting the Search Improvements project page on Mediawiki.org.

What are we asking you?

We want to hear from you about these proposed changes. None of these suggestions is currently set into stone, and before deploying them we want to hear your opinion about them.

More specifically, we would like to know:

  • What do you think about the approach that we outlined above?
  • Do you think that any of these changes can affect the contribution flow? If yes, how?
  • Do you think that these changes can improve the experience of new users or casual readers?

Your opinion is important to us, and we want to use it to inform these changes before we eventually deploy them, if there is feedback to do so from all communities.

How can you give feedback?

You can reply to this message here (please remember to ping User:Sannita (WMF) when you do) or on Mediawiki.org. We plan to keep this consultation going for around three weeks, from today until July 10, 2022.

We are also planning on hosting an office hour on June 28 at 15:00 UTC (link to the meeting), where you can ask questions and directly reply to the team about the proposed changes.

Hope to hear from you! -- Sannita (WMF) (talk) 10:42, 21 June 2022 (UTC)

@Sannita (WMF): I wouldn't want us adding article thumbnails to search results until phab:T306246 is resolved. --Ahecht (TALK
PAGE) 14:18, 21 June 2022 (UTC)
@Sannita (WMF) Please consider implementing T146418. That was raised in reference to the Special:Contributions, but it applies equally to Special:Search (i.e. the Add namespaces pane). -- RoySmith (talk) 15:00, 21 June 2022 (UTC)
If you want to improve the search page it would be great if you can fix phab:T215117. 90.227.175.244 (talk) 18:05, 21 June 2022 (UTC)
Hi 90.227.175.244, I just received a confirmation from the dev team that they will start working on that fix. I cannot promise anything about when the bug will be fixed, but it will be fixed for sure in the coming weeks. Thanks for bringing it up! Sannita (WMF) (talk) 17:20, 29 June 2022 (UTC)
@Sannita (WMF): Like Ahecht, I'd like to not have thumbnails until phab:T306246 is resolved. Also, I'm not sure if collapsing the advanced search options is a good idea. Instead I think, moving the "sort by" option between the "blue Search button" and "Results 1 – 20 of 859" would be more intuitive for casual readers. All the other proposals look really nice to me. Best. —CX Zoom[he/him] (let's talk • {C•X}) 19:43, 21 June 2022 (UTC)
@Sannita (WMF): On second thought, casual readers would not care much about when a certain article was created or when it was last edited. Such sorting is useful on e-commerce sites but probably wouldn't be here. So sorting system is probably best placed where it already is. —CX Zoom[he/him] (let's talk • {C•X}) 13:45, 22 June 2022 (UTC)
I don't think that we want all of MediaWiki:Bad image list to be blocked from previews. There is certainly a high degree of overlap, but no reason to block images such as File:Dead rat blood.JPG, File:Encyclopedia Dramatica (logo).png, File:Flag of Hezbollah.svg, File:Osama bin Laden portrait.jpg or File:Swastika.png from previews, just because each of these images is likely to be abused. Animal lover |666| 14:05, 22 June 2022 (UTC)
@Animal lover 666 It's better than nothing. I'd rather have a few "meh" images not appear than unexpected graphic images showing up in benign search results (for example, a search for "Iran's Penal Code" shouldn't show a thumbnail for Anal sex, and a search for "Canadian Holstein cows" shouldn't show a thumbnail for Anogenital distance). --Ahecht (TALK
PAGE) 14:46, 22 June 2022 (UTC)
@Ahecht, @RoySmith, @CX Zoom, @Animal lover 666: thank you so much for your interventions and your feedback! I already reported your comments to the dev team.
Regarding T306246, someone is looking currently at the bug. I'll keep an eye on it too, just to be sure that it doesn't get in the way of our development. Regarding T146418, it doesn't apply to our current sprint, but we will take it into consideration for our next steps. I'll keep you posted about it.
Thanks again for your feedback, and if you have more, please keep it coming! :) Sannita (WMF) talk) 12:04, 23 June 2022 (UTC)
File:Dead rat blood.JPG (don't click if you just had lunch) isn't used in any article here so it won't be affected anyway. If we did have an article for "dead rat" that used it as the first image, I'd argue it shouldn't show up in search results. It wouldn't be appropriate to show to someone who's looking for Deadliest Catch. Wikipedia may be WP:NOTCENSORED, but that's about articles. If you look up shit, you should be served shit. But you wouldn't put "Dead rat blood" on the Main Page, would you? For Osama, I wonder if that image (still) needs to be on the bad image list. File:Flag of Hezbollah.svg is non-free so that's never a page image anyway. File:Swastika.png isn't used in any article, so no page image. Encyclopedia Dramatica is barely legible as a search thumbnail, and again, I wonder if it (still) needs to be on the bad image list. At any rate, it's not a huge loss. Search thumbnails/previews are no necessity, if anything, they are (@Sannita (WMF):) mostly bloat. Having a handful of images that aren't overly shocking excluded is not a big deal. Showing anal sex to kids looking for the home of Disneyland, Anaheim, California, is. — Alexis Jazz (talk or ping me) 14:27, 6 July 2022 (UTC)
Love all except for 3 and 7 Most of these improvements look fantastic and greatly needed. I would personally oppose removing the outlines for the sister project search, as it makes it less clear and accessible, but I would support changing the color/transparency of the outline and making it rounded. The new position for the new article message also seems a bit wonky, but changing the position in general is fantastic. Thanks for all of your work! 🐶 EpicPupper (he/him | talk) 16:59, 24 June 2022 (UTC)
Hi, Sannita (WMF)! My initial reaction before clicking through to all the details: for "Add an article thumbnail to search results", we need T91683 Allow editors control of the page image, which is #8 in this year's Community Wishlist. ⁓ Pelagic ( messages ) 11:10, 6 July 2022 (UTC)
Hello everyone! Our consultation period about Search improvements will end on July 10, but we already have some initial news that we want to share with you.
Based on your precious feedback that we collected across communities, we decided to take some more time to re-evaluate our proposal on namespace tags, and to tweak slightly article thumbnails in order to make it easier for users to hide them, if needed. We also decided not to proceed with collapsing the advanced search options.
All other improvements received a general positive feedback in the consultation so far, so our plan is to implement them starting from July 11.
There are still some days left for discussion, so you can still help us in refining our proposals. Thanks for your help so far! Sannita (WMF) (talk) 13:25, 6 July 2022 (UTC)
@Sannita (WMF), looks like I missed the initial window, but having reviewed the changes and the comments above, figured I'd share.
Overall, it looks pretty good, but I agree with others that the concerns about image selection should be resolved.
For namespace tags, many less-experienced editors struggle to understand what they mean, so ideally I'd like to see some sort of explanation of what "user talk" or "draft" means if anyone hovers over the tag on a result.
For other projects, it's important to understand that, although they share the most fundamental core open knowledge mission, beyond that many of them have very different purposes from Wikipedia, which could make some entries there not a very useful result. It's essential that content from outside of Wikipedia be clearly identified as such so that readers know when they're leaving the encyclopedia and going to something else. E.g. if they click a Wikivoyage link expecting it to be basically a Wikipedia article, they'll be surprised when they encounter a statement like "check out this excellent restaurant", which is fine under voy:BEFAIR but would never fly under WP:NEUTRAL.
Moving the “no article found” message to a better position sounds fine from your mockup, but it's definitely important to understand that this message is a key step in the creation of many new articles.
Cheers, {{u|Sdkb}} talk 21:45, 15 July 2022 (UTC)

plagiarism bot

Plagiarism bot: One of our scripters could create a bot that would run checks to see if a large portion of the text was copied from another Wikipedia article, and flag it. divisionsign speak of the devil 23:05, 12 July 2022 (UTC)

seems pretty useless, we already have earwig but this is a matter of attribution and not that big of a problem. PRAXIDICAE🌈 23:06, 12 July 2022 (UTC)
If it's "on-demand" like the side-bar citation bot, I don't see how this would be an improvement in lieu of Earwig. —VersaceSpace 🌃 23:24, 12 July 2022 (UTC)
There is a bot that will flag copyvio, at least in draft space. I forgot the name of the bot, but it flagged a draft I was working on when I included a quote in a cite. This is where I removed the quote based on the bot flagging. Unfortunately I can't remember the bot name, or find the flagging in any log. ScottishFinnishRadish (talk) 23:32, 12 July 2022 (UTC)
It's EranBot. Many of its reports involve unattributed copying within Wikipedia, and those can be fixed by whomever is dealing with the report at CopyPatrol. DanCherek (talk) 23:46, 12 July 2022 (UTC)
I would be concerned that such a bot could have chilling effects on use of quotations which are used correctly—it would probably be very hard for an algorithm to distinguish between proper and excessive direct quotations, and I don’t want editors to be derailed by false positives. Yitz (talk) 03:22, 17 July 2022 (UTC)

Rename AfD to VfD

Not a serious proposal. Primefac (talk) 07:14, 18 July 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.

VfD is much clearer, and used on every other wiki. There is no need for it to be different here. Also AfD sounds like a disease, while VfD is pure purity. – Ilovemydoodle (talk) 06:53, 18 July 2022 (UTC)

VfD implies it's a vote. It's not (or at least, it isn't supposed to be); it's a debate. That's why it was changed from VfD in the latter half of the 2000's. —Jéské Couriano v^_^v a little blue Bori 07:08, 18 July 2022 (UTC)

@Jéské Couriano: Then why is it called "VfD" on every other WMF-wiki? – Ilovemydoodle (talk) 07:17, 18 July 2022 (UTC)

@Ilovemydoodle: Because they opted to not change the name. What they do has no bearing on en.wp and likewise our decisions have no bearing on any other Wikipedia. —Jéské Couriano v^_^v a little blue Bori 07:24, 18 July 2022 (UTC)
@Jéské Couriano: Can this decision ever be reversed? – Ilovemydoodle (talk) 07:28, 18 July 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.

Adding geolocation to Wikipedia app to identify nearby items of interest/significance

Folks,

I enjoy Wikipedia and visit the site regularly. I also contribute to support the fine work you do.

When viewing today's featured article on the Midland Railway War Memorial, I had an idea for what I think would be a new feature for Wikipedia.

My idea would be to be to enable the Wikipedia app to geolocate the user and suggest articles in the vicinity of the user.  That way, when traveling, a person could use Wikipedia to inform them of nearby items of interest and significance.

I still kick myself for the time long ago when I was crossing Wyoming and missed Devils Tower, not knowing it was nearby.  

The Wikipedia app could allow users to sort by distance and by type (natural features, buildings, monuments, historical events, etc.).

That is my suggestion.

Roger 2600:4040:7FCD:C900:6977:6471:32DE:F1EB (talk) 03:32, 15 July 2022 (UTC)

Change the look of the authority control module

The {{authority control}} template is used on nearly 2 million pages, about 4% of all pages. Despite its widespread use, it has long been controversial, having been twice nominated for deletion, in 2010 and 2017. These were based on its uncertain value, its obscure contents, and possible duplication of its function by Wikidata. (I am unsure as to when an article warrants an {{authority control}} template.)

Due to its position in MOS:LAYOUT, it attracts complaints that it looks ugly. The root of the problem here is that it masquerades as a navigation bar but it is not one: Wikipedia:Navigation template states that Navigation templates do not provide external links to other websites. Which is what {{authority control}} does. This is why MOS:LAYOUT places it separate from the navbar templates, but that causes problems with the layout. My proposal is a simple one: to alter the template so it no longer masquerades as a navbar template. So it would look like our other external navigation aid, {{Taxonbar}}. This would resolve issues with its visual impact. Hawkeye7 (discuss) 20:49, 15 July 2022 (UTC)

Also note the prior RfC at Wikipedia:Village pump (proposals)/Archive 181#RfC: look of Authority Control. * Pppery * it has begun... 16:11, 16 July 2022 (UTC)
  • The only major visual difference between {{Authority control}} and {{Taxonbar}} is that the former is collapsible. Are you suggesting that function be removed? If so, I object. Removing a helpful function to create a visual distinction is not a good solution. – Scyrme (talk) 19:34, 16 July 2022 (UTC)

I appreciate your desire not to see it. Here's a mockup:

Despite not being collapsed, it is still smaller than the real thing. The entries are taken from a real article and, yes, some of the links don't go anywhere useful, some of the labels are deceptive, and the layout is inconsistent as well as horrible. That's just the way {{Authority control}} is. Hawkeye7 (discuss) 10:17, 17 July 2022 (UTC)

I have a question. If Wikidata already does the job that Authority control does, why not use the Wikidata template to auto-fill the authority control? —CX Zoom[he/him] (let's talk • {C•X}) 13:40, 17 July 2022 (UTC)
... we already do. * Pppery * it has begun... 13:43, 17 July 2022 (UTC)
Oh I see. The above example is manually filled though, so I thought we only manually fill it. —CX Zoom[he/him] (let's talk • {C•X}) 13:51, 17 July 2022 (UTC)
It's only smaller because you only included enough data to fill one line, and the links are unordered into sublists (as they are on eg. Henry VIII). – Scyrme (talk) 01:23, 18 July 2022 (UTC)
We do indeed need to radically change the appearance of this thing, but this doesn't achieve it. The single worst aspect of it at the moment is that it contains both wikilinks to our pages on the various sources and numbered (e.g., "[5]") weblinks; that's completely counter-intuitive – you click on VIAF, and instead of taking you there it takes you our article on it. This proposal doesn't address that (it even seems to make it worse), and if the taxonbar has the same problem it too should probably be redesigned. However, priority one for Authority control is to make it collapsed by default. Justlettersandnumbers (talk) 07:51, 18 July 2022 (UTC)
New layout is worse than what we have. In the example, what is "United States"? In the current layout, it is "national library: United States", which is clear (or certainly clearer), but in the new proposed layout it is just a country name without any explanation. And we do need a mockup for examples with 30+ links as well, to see what that would look like. Fram (talk) 08:00, 18 July 2022 (UTC)
@Hawkeye7, {{Medical resources}} is another similar template. I think we would benefit from having something similar for film review aggregators (like Rotten Tomatoes). We put the same handful of links at the end of all of those articles, so why not standardize and automate it? WhatamIdoing (talk) 19:48, 18 July 2022 (UTC)

Discussion at RfA/RfB

There is consensus against implementing both proposals. There is a consensus that the first proposal will make it more difficult for RfA to follow and is counter to the existing community consensus that RfA is not a vote. The consensus against the second proposal is less strong, but there is an overall consensus that it is not a necessary change. TonyBallioni (talk) 01:13, 14 July 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.

Following on from Wikipedia talk:Requests for adminship#All discussion in general discussion, this RfC concerns those parts of the Wikipedia:Requests for adminship (RfA) and Requests for bureaucratship (RfB) processes that are normally placed below the RfA/RfB toolbox in the Discussion section. There are two proposals to consider:

  1. Anyone wishing to respond to any Support/Oppose/Neutral (if kept) statement should do so in the General comments section or on the talk page
  2. The neutral section will be eliminated at Requests for Adminship/Bureaucrat (only have Support and Oppose sections)

Barkeep49 (talk) 19:22, 13 June 2022 (UTC)

Background and details

In the most recent RfC on the topic of balance between voting and discussion at RfA, the community consensus was ...the bulk of opinions seem to be for keeping the balance as is with a slight skew towards making it more vote-like. This RfC attempts to build-off of that consensus by concentrating discussion, including the comments that happen currently in the neutral section, in the "General comments" section and on the talk page thus making the support and neutral sections more vote-like. This RfC would not change current practice of people explaining their supports/opposes/neutrals, merely where replies to them would belong.

Comments specific to the candidate/RfX will go in the "General comments" section, while more general comments will go on the talk page. An example of how this would work can be found at this RfB where discussion about a particular oppose occurred in general comments while a broader discussion about hypotheticals was moved to the talk page. Topics would continue to be seperated with a dividing line in general comments and by headings on the talk page.

Poll (RFA/RFB discussion)

  • Support both Our current status quo is a bad one, where on topic discussion about the candidate gets shunted to the talk page because of concerns about the tenor of discourse, while not actually doing much for that discourse because people still feel attacked by replies. By moving the comments to a general section, hopefully there will be a bit more remove (even if there are pings) and regardless when multiple people have similar concerns the discussion will be in one place rather than spread out over multiple opposes, something this recent RfA would have benefitted from. It also provides a standard (Comments specific to the candidate/RfX will go in the "General comments" section, while more general comments will go on the talk page on deciding which comments should be moved to the talk page. While I use Lee's RfB as an example of where this has worked, I would suggest it has also worked at Wugs' RfB where there was limited discussion about opposes compared to a more robust discussion in general comments. The neutral section at its best feels like it duplicates things that belong in general comments, where they should be considered by crats when determining consensus and considered by the community without tipping the balance towards or against the candidate, and at worst is needless signaling (i.e. "I intend to vote later") and since we're considering changes to increase that discussion I have paired the questions. Best, Barkeep49 (talk) 19:22, 13 June 2022 (UTC)
  • Support both per the nom almost verbatim. We might not have been able to reform RfA, but small changes like this might helpfully go a ways towards making the atmosphere and process of RfX slightly less adversarial. --WaltCip-(talk) 19:34, 13 June 2022 (UTC)
  • Support both (I never understood the reason for having a no-vote neutral section at all.) Schazjmd (talk) 19:53, 13 June 2022 (UTC)
  • support 1 only neutral section is required. "I will vote later" comments were discussed at WT:RFA. What if one finds a candidate who is excellent in some areas, and has zero experience in some other areas, and what if that voter gets torn between oppose vs support? They dont want to support because of lack of experience, but dont want to oppose as candidate is good, has clue, and solid contributions. I think neutral is necessary. We dont protect a page/article because of one inexperienced editor. Same should apply here. Crats can handle that. Rest of the norms for general comments should be kept as they are. If comments go off topic/RfX, any crat/uninvolved editor can move it to talkpage. —usernamekiran (talk) 19:59, 13 June 2022 (UTC)
    Perhaps we need to advertise more widely that there is the option of abstaining from any RfA by simply not editing the page. —Kusma (talk) 21:18, 13 June 2022 (UTC)
    +1 valereee (talk) 16:32, 22 June 2022 (UTC)
  • Oppose option 1. RFA can be counterintuitive already, and not being able to reply to a statement immediately below it, the way you would on a talkpage would make that worse. I think it would also make the RFA experience worse for candidates. Currently if someone !votes with an easily rebutted rationale it can be pointed out in the next paragraph - having the statement "I've checked the deleted edits, and yes it was an attack page. There may well be a notable academic of the same name, but that was a valid deletion" in a completely different section rather than in the next paragraph is not going to make RFA a better place. ϢereSpielChequers 20:30, 13 June 2022 (UTC)
  • Oppose 1, Support 2. WereSpielChequers took the words right out of my mouth on option 1 -- demonstrably false claims in !votes need to be rebutted on the spot, not in a separate section down below. On option 2, I see absolutely no reason for someone who doesn't want to support, doesn't want to oppose, and doesn't want to leave a general comment to edit the page at all. !Voting at RFA is not mandatory, and no one's taking attendance. --Ahecht (TALK
    PAGE    ) 20:36, 13 June 2022 (UTC)
  • I support both proposals. Consolidating discussion about a given concern will reduce repetitiveness and improve efficiency: additional supporting or refuting evidence can be done in one thread, instead of having to repeat it across multiple threads. For convenience, I also support a slight modification to the first proposal, where pointers can be added in response to a support/oppose statement that would refer to the relevant discussion threads. I think the comments currently made in the neutral section can be posted within a general discussion section without loss of effectiveness, and so support this as well. isaacl (talk) 20:52, 13 June 2022 (UTC)
  • Support option 1 (we need to stop the way that discussions under a vote rationale tend to degenerate), but there should be a way to make factual corrections or perhaps a neutral "see discussion section for context". Also support merging "neutrals" into the general discussion. A lot of neutrals are either useless attention-seeking ("hey, I participated too!") or bring ammunition for the opposition that doesn't have to be sugarcoated as "neutral". —Kusma (talk) 21:14, 13 June 2022 (UTC)
    I thought about allowing such pointers and would have no objection to those being permitted under this proposal. Best, Barkeep49 (talk) 21:20, 13 June 2022 (UTC)
  • Support option 2, support 1 with changes I never understood why there is a neutral section and a general comment section. I generally support option 1, but with two caveats. First, self replies should alway be allowed. Second, I do agree there should be a way for an editor to signal there is discussion as Issacl mentions above. --Enos733 (talk) 21:45, 13 June 2022 (UTC)
  • Oppose 1 per WereSpielChequers, et al. Support 2 as the Neutral section has never served a useful purpose.  — SMcCandlish ☏ ¢ 😼  23:15, 13 June 2022 (UTC)
  • Oppose both The "most recent RfC" was a war of attrition that cannot reasonably be interpreted as justification for these proposals. As stated above, if someone makes an incorrect claim in their vote, the problem needs to be corrected where the claim is made—not hidden in a large discussion 50KB further down the page. What is the problem with neutral? That section allows mild observations or reservations without recording a vote—it's fine. Johnuniq (talk) 23:53, 13 June 2022 (UTC)
  • Strong oppose 2 Keep the neutrals. Maybe ill be back with an opinion on #1, but not yet. Happy Editing--IAmChaos 00:15, 14 June 2022 (UTC)
  • Oppose 2 - RfX is a discussion, and one can add to the discussion without specifically supporting or opposing the candidate, I think that removing this will either dissuade people from contributing to the discussion at all or trying to shoe-horn themselves in to support/oppose as well so they 'get counted'. And I really don't want to see *'''Weakest possible support because the neutral section is gone''' blah blah blah ~~~~. — xaosflux Talk 00:21, 14 June 2022 (UTC)
    The proposal you are opposing does not remove the option to participate in the discussion without supporting or opposing. —Kusma (talk) 05:31, 14 June 2022 (UTC)
    @Kusma I'm aware - but I think it may backfire because by not having a numbered entry, some people may not think they are "counted" like everyone else. — xaosflux Talk 15:32, 14 June 2022 (UTC)
    I don't think a person providing more clarity to crats on how their comments should be interpreted when deciding consensus is backfiring. Best, Barkeep49 (talk) 15:49, 14 June 2022 (UTC)
    @Barkeep49 I'm specifically talking about people who would have previously !voted "Neutral" who now would not be allowed to. Yes, they could just put general comments in the comments section, but I think some of them will feel they are not "counted" that way because everyone else gets an incrementing number with higher visibility towards the top of the page. — xaosflux Talk 00:08, 15 June 2022 (UTC)
    Given the number of statements in the support and oppose sections, I think the most prominent ones will be the first few, and the last few before an editor places their comment. Comments in the current "neutral" section have greater prominence only because there are a small number of them. It's unclear to me, though, that this prominence is inherently warranted: why should someone's comments get greater prominence just for appearing in one section versus another? Comments in the general discussion section also get greater prominence if there are only a few; they lose prominence as more comments are added, as they do in all the other sections. There isn't a good solution for that. isaacl (talk) 00:33, 15 June 2022 (UTC)
    Obviously we both know that this isn't how crats would read a discussion. But to the extent that it would be a fear among those who don't know better, I'm OK with it because it does send a signal about the intent of the person to the crats - that is there are mixed feelings that in the teeniest way tip towards oppose or tip towards support. As a believer in Wikipedia:Strong#What about "weak"? it seems like a legitimate way for the comments to get out there, while still having the same eventual effect on crats, as skilled diviners of consensus. Best, Barkeep49 (talk) 00:56, 15 June 2022 (UTC)
    Keeping the neutral section because the folks who just want to hear their voice will still just want to hear their voice...that's sad. I guess it's better than a section headed "Place silly irrelevant stuff here, please." valereee (talk) 16:40, 22 June 2022 (UTC)
  • neutral Neutral votes do not hurt, and may express some useful point, but also don't help build an outcome. Graeme Bartlett (talk) 11:29, 14 June 2022 (UTC)
  • Oppose both — I see really no benefit in building up new regulations like this one because of the WP:CREEP. I think we have to pay attention to a more serious problem here: many adminship proposals are turned down too early. They are rarely discussed. Wikipedia has many problems that are non-technical. Cheers AXONOV (talk) ⚑ 16:36, 14 June 2022 (UTC)
    And with oppose !votes like this, it's easy to see why. For some reason, it's impossible to get any meaningful changes pushed through in RFA or any other realm of Wikipedia because of a widespread impulse to avoid anything that might hint at "changing the rules", as evidenced in the failure of the RFA reform effort last year. One thing that can be guaranteed by standing pat is that nothing will get better. WaltCip-(talk) 16:42, 14 June 2022 (UTC)
  • Support 1 Oppose 2 As long as people can reply to themselves then I support the first part of this proposal. Dr vulpes (💬 • 📝) 23:45, 14 June 2022 (UTC)
  • Support both, and especially the second. If you are torn between support and oppose, you can leave a comment explaining your justification, and that might help others decide (or not). 🐶 EpicPupper (he/him | talk) 23:53, 14 June 2022 (UTC)
  • Support 1, oppose 2 – Best to avoid staggering discussions across multiple sections or pages. The neutral section also helps for consolidation and offers a voice in the "main" thread for those who aren't comfortable supporting or opposing. ComplexRational (talk) 00:06, 15 June 2022 (UTC)
  • Support 1, oppose 2 - I don't see enough justification to convince me neutral votes are harmful in some way and understand the value some editors see in stating their opinions through such a vote. Nonetheless, I think the first proposal is a good one. — Ixtal ( T / C ) ⁂ Join WP:FINANCE! 10:24, 15 June 2022 (UTC)
  • Oppose both — concurring with WereSpielChequers and Johnuniq, being able to directly comment on a user's vote is extremely important, not only for explaining why the vote might be inappropriate, but also highlighting the issue for the next or following participants hovering over that section; ultimately, greatly influencing the the way the next editor votes. The drive-by voters, of whom there are an abundance these days, might not bother to scroll all the way down to read various comments, many of which are more about the process than the candidate. Probably few participants take the time for a serious read of threads removed to the talk page unless it is about a juicy scandal.
Xaosflux's oppose of No.2 makes absolute sense.The 'neutral' section is also important because it is used and read by wavering voters. It is quite different from the quagmire of general chit-chat at the bottom of the page, and the neutrals could also be taken into consideration in a 'crat chat, or even by a single 'crat having a hard time reading a consensus in a close run RfA - it has happened but it would be suicide if I were to provide the diffs. (Sorry Barkeep49, I know you are hell bent on RfA reform - so was I for years, and still maintain that change is needed - but I think these 2 proposals are solutions looking for problems). Kudpung กุดผึ้ง (talk) 11:40, 15 June 2022 (UTC)
  • Oppose 1. Unless we disallow discussion entirely (I hope not), the only thing shunting replies to a different section or the talk page does is make it harder to follow. Support 2. Having a special section for people to explain why they're sitting on the fence is the most Wikipedia thing ever. There is no difference between a neutral vote and a comment. – Joe (talk) 11:54, 15 June 2022 (UTC)
  • Oppose 1. It would make it hard for the users to follow. Oppose 2: I agree with Xaosflux for the most part. --Baggaet (talk) 14:00, 15 June 2022 (UTC)
  • Oppose 1. The problem with RFA is not people responding inline, it's people responding uncivilly. This will not fix the problem and, per others above, will introduce others. Thryduulf (talk) 14:19, 15 June 2022 (UTC)
  • Support 1 Just a baby step towards what we need which is to organize a substantial, polite focused discussion (including participation by the nominee) in important areas of question. Mild oppose to #2 I was going to vote "neutral" on removing "neutral". :-) "Neutral" is a way to express actual sentiment and not remove participation by those who aren't in the other two choices. North8000 (talk) 14:37, 15 June 2022 (UTC)
  • Support both - I wanted to wait until my RfB was over before making any comments here. I feel like I'm in a unique position having been through two RfXs in two years. My general thoughts are that the neutral option is very similar to just not voting at all. I get that sometimes a user may want to spoil a ballot - but that information would be the same in general comments.
In my eyes, one of the bigger issues at RfA is badgering (or at least people being accused of it). Very few people strike their vote after having someone comment on it. Having the discussion over issues at a different place is helpful in my eyes. Having the discussion happen immediately after the !vote cast is quite combative, whilst a ping to a discussion thread would be a little bit more calm. I know I would feel like others were suggesting my comment was much less valid if I had a direct response than a ping to a discussion.
That being said, discussions that happen, but aren't actually about the user in question (such as at the RfB, where there was some valid concern about security risks for having additional users with higher rights/2FA) are helpful, but shouldn't fill up the RfA page. These should be more more swiftly to the talk, or better to WT:RfA. My rfA had a valid discussion about the state of WP:GAN, but it's not helpful in discussing the candidate. Lee Vilenski (talk • contribs) 17:09, 15 June 2022 (UTC)
  • Oppose 2: Neutral votes don't harm. No need to remove them. Someone might be great at one thing but not so much at the other. We may want to cast a neutral vote. Abstaining is not a solution, because someone else coming to the RfA may find the reasoning useful in deciding their vote. Maybe, of the points I raised, the "other thing" matters more to them. Because the candidate is not good at that "other thing", and my vote brought it to light, the voter now has a clearer picture and vote accordingly. That's what I do, keep reading every incoming vote (S/O/N) to ensure that I don't miss something. And ofcourse, when S/O ratio are in 'crat discretionary range, the crats may find something useful in the neutral section to base their final decision. Neutral on 1. —CX Zoom[he/him] (let's talk • {C•X}) 09:13, 16 June 2022 (UTC)
    As a 'crat that closes RfX's sometimes: I currently give more weight to a "Neutral, Leaning x" (though less weight than a "weak x" in the support/oppose sections) than just a comment in the general discussion area. The general discussion area is still relevant and important - especially if there are specific issues raised in the numbered section that get more resolved in expanded discussion. Most of this is only relevant in close-calls of course. — xaosflux Talk 10:00, 16 June 2022 (UTC)
  • Oppose 1 per WereSpielChequers. Really don't care about 2, but it seems like a pointless change just for change's sake. Boing! said Zebedee (talk) 15:00, 16 June 2022 (UTC)
  • Oppose 1 per WereSpielChequers; far better would be more active clerking or consistently removing to the talk page after two extra comments instead of it sometimes happening & sometimes not.. Oppose 2 because it's a solution looking for a problem, and because the Neutral section can be of use. Happy days ~ LindsayHello 13:15, 18 June 2022 (UTC)
  • Endorse 1, oppose 2. The first option prevents users from bludgeoning another for their opinions. However, I believe the neutral page has its own utility, and should be kept (at least for bureaucratic consideration when closing an RfX). Thanks, NotReallySoroka (talk) 06:48, 19 June 2022 (UTC)
  • Oppose 1 because of the occasional newbie RfA !vote that's like "XTools says that the candidate has 3,000 deleted edits, so they must have made 3,000 bad edits!" – for blatantly erroneous statements like these, I think it is important to keep the factual correction as close as possible. DanCherek (talk) 21:58, 19 June 2022 (UTC)
  • Oppose both. I opposed to 1 because, in some circumstances, replies asking for clarification should be immediately asked instead of being asked on the Talk page purely because of procedural reasons. I agreed that if the conversation becomes long it should be taken to the Talk page, but there are circumstances where it should not be taken to the Talk page. I opposed to 2 because Neutral votes are valid votes regardless. Being Neutral and unable to form up your decision is different from abstaining in the RfA process. People that voted Neutral have their opinion and reasoning as well - and this may sway the Support/Oppose voters, and should be kept in the procedure. ✠ SunDawn ✠ (contact) 11:22, 22 June 2022 (UTC)
  • Oppose both per WP:CREEP, WP:BROKE. I don't see these proposals as solving any problem, and they seem like they would needlessly stifle discussion. RfA has many problems, neither the neutral section nor the ability to reply to comments is one of them. ~Swarm~ {sting} 05:24, 23 June 2022 (UTC)
  • Oppose both because this makes RFA a vote, not a discussion. --Rschen7754 05:48, 23 June 2022 (UTC)
  • Oppose both. The proposals just seem to make contributing more awkward. Flexibility is good, as is not having to switch to the talk page but rather simply to scroll down. Jmchutchinson (talk) 10:34, 23 June 2022 (UTC)
  • Oppose both don't really see how this would help anything and option 1 especially is at odds with how similar discussions usually work. Hut 8.5 17:27, 23 June 2022 (UTC)
  • Oppose both but remove the General comments section. I think off-topic discussion or further discussion about a vote can be moved to the talk page, the procedure exist for that. Also neutral votes may count as an idea (because some user may both support and oppose at some point) Weakest possible support/oppose may make it harder for crats to close RfX. Thingofme (talk) 02:39, 24 June 2022 (UTC)
  • Support both, less drama --> more productive conversation --> improving Wikipedia faster. Also, neutral votes can be moved to general conversation stuff, and there will be less stress to the nominees. CactiStaccingCrane (talk) 05:28, 24 June 2022 (UTC)
  • Oppose both (firstly, I thought I'd answered, but it seems to not be here. Please ping if I've double !voted). Neutrals provide a single clear reason (or set of reasons) for that position in a way that general discussion does not. I would not include general discussion in the consideration of the outcome, and without that, neutrals would be ignored when they shouldn't always be. It's also useful for other participants. I also find some degree of immediate clarification helpful, and thus would oppose the other point. More aggressive clerking to move to Tp as required, however, would be fine. Nosebagbear (talk) 12:38, 24 June 2022 (UTC)
  • Oppose both. I oppose 1 because discussion should be centralized, and that proposal would disperse it. I also oppose 2 because RfX is not a vote. It's valuable to count the balance of opinion, which is why we use numbers in the first place … and mixed opinions form part of that balance of opinion and should be counted, which 2 would discourage. Moreover, 2 would move things closer to looking like a vote, which should generally be discouraged. {{Nihiltres |talk |edits}} 16:03, 24 June 2022 (UTC)
  • Oppose 1: this cannot be done so long as RfA is not a vote, but determined by assessing consensus, and so long as people can make false comments in the Support/Oppose sections. My issue with the toxicity of RfA is most commonly the content of Oppose !votes, and second-most commonly the content of replies to Oppose !votes. This change would likely fix the second-most common issue at the expense of exacerbating the first. Additionally, though hardly the best way to run things, the possibility of replies to your Oppose !vote inline creates a social stigma against making inflammatory and unverifiable claims. Support 2 because I have never seen a use for the Neutral section that could not be served by general discussion and the section generally adds to the word count of the RfA without particularly increasing the quality of discussion—the length of each RfA page adds to the pressure of running as a candidate. — Bilorv (talk) 17:17, 24 June 2022 (UTC)
  • Oppose both. While RfA is in reality about the closest thing we have to a "vote" system, with perhaps the exception of ArbCom elections, we shouldn't be making it more that way. Rationales for an editor's position should be open to discussion and challenge right there, not put off somewhere that people reading it later might not see. Similarly, an editor who has chosen to neither support nor oppose but has something to say should be able to do that, and a "Neutral" position is already a logical way of doing that. If discussions get excessively long, they can still be moved to the talk page, but with a pointer to that discussion right there with the vote so that interested parties will know that there is a discussion about the matter and can read it if they choose. Seraphimblade Talk to me 04:54, 25 June 2022 (UTC)
  • Oppose 1 per WereSpielChequers et al. I'm imagining trying to read my way through a long RfA and having to bounce up and down to figure out what people are responding to in the comments. No way is this interface up to that task. Indifferent leaning oppose 2 - Joe Roe is right, it's the most wikipedia thing ever—but is that really the heart of the RfA problems? It's mostly harmless and is appreciated by some. Retswerb (talk) 05:10, 25 June 2022 (UTC)
  • Oppose both. Solution in search of a problem. There are many issues with RfA, however these proposals wouldn't accomplish anything aside from introducing pointless complexity to the process. -FASTILY 06:50, 25 June 2022 (UTC)
  • Oppose 2 Forcing users to choose a side does a disservice to those who have mixed feelings about a candidate. Also, I trust the closing crats to properly interpret whether !votes in the neutral section should be weighed for or against promotion. Iffy★Chat -- 18:42, 25 June 2022 (UTC)
  • Oppose both - I was actually leaning towards supporting 1, because I've seen too many times people being uncivil in responses to opposers, but WereSpielChequers argued convincingly and ultimately the solution to uncivil behaviour is to make sure it is corrected directly. I don't really care whether people are neutral or not and I don't see how getting rid of the neutral section actually improves things. "Neutral" votes are typically just parking to see whether any momentum is going to get behind opposing the candidacy, or to share information and let others oppose, but these are not actually bad things. FOARP (talk) 13:56, 27 June 2022 (UTC)
  • Oppose 1, support 2 It's very difficult to follow a non-threaded discussion. Moving the replies to a particular support/oppose statement to a different section right out of the gate can be very confusing and, quite frankly, will be nigh impossible to enforce. If a reply thread gets out of hand , either collapse it or move it to the talk page and link to it. As far as eliminating the neutral section, it is my understanding that neutral statements aren't included in the final percentage calculation anyways, so the fear of not being "counted" is literally unfounded. As has been stated previously, no one except the nominee is required to participate in any RFA/RFB discussion. Many times I haven't felt strongly for or against a candidate, and I simply did not participate. Even if the neutral section is eliminated, an editor's comment is "counted" when they sign the comment and hit "Publish changes." — Jkudlick ⚓ (talk) 19:50, 27 June 2022 (UTC)
  • Oppose both. If I believed this would reduce drama and incivility and make for more productive discussions, I would support. But I just don't understand how it does that. – wbm1058 (talk) 02:38, 1 July 2022 (UTC)
  • Oppose both. I agree with the argument that splitting discussions makes them harder to follow and it also makes RfA seem more like a vote and less like a discussion. I also do not believe eliminating the neutral section will serve any purpose. Yes, there are people who think they should tell the world that they have not yet decided but those were never real neutral !votes. But many a discussion has seen well thought out comments in neutral where users were able to explain in detail and without it getting lost in the discussion section, why they were unable to support without opposing outright. Most parliaments allow members to abstain (which is distinct from simply not voting) for a reason. Neutrals are already not counted in the percentage but that does not make them worthless. Regards SoWhy 08:47, 1 July 2022 (UTC)
  • Oppose both. It would just complicate the process, and I do not understand how it would reduce incivility. CollectiveSolidarity (talk) 19:22, 6 July 2022 (UTC)
  • Support 1, Oppose 2 I do think the reply chains get out of hand sometimes and make votes hard to read and follow, so forcing conversation into a general discussion section seems reasonable. An alternative would be to hard cap the number of replies an editor can make, or how many replies can be in one thread (under one vote), but this would require more oversight to implement that proposal 1. However, on point 2, neutral votes have value beyond "general discussion" - each editor only gets one vote, whether that's support, oppose, or neutral. This places some extra weight on the rationale behind a neutral vote, beyond the weight of a comment that can get lost in the general discussion. Neutral votes also offer a place for editors with a potential COI to record what their vote would have been, such as the first example here [3]. Thus, I think neutral votes are valuable and should be kept. Toadspike (talk) 21:35, 6 July 2022 (UTC)
  • Oppose both I'd rather see discussions on Support/Neutral/Oppose than go to a huge clutter mess in General Comments. Also oppose 2, since some people may want to hold their vote. I don't leave neutral votes often but I believe it should be a choice that users can make.--Takipoint123 (talk) 16:29, 9 July 2022 (UTC)
  • Support 2 I have yet to see a useful neutral vote which wasn't either better off on the talk page or in the oppose column. Protonk (talk) 19:32, 10 July 2022 (UTC)
  • Fully Oppose both Option 1 and 2 - Like many other people have stated above, the proposed changes do not solve any real problem and instead they are just adding an unnecessary complexity to a simple process. Most of the times, the discussion under support/oppose votes is very reasonable & helpful and in case a discussion gets longer, it eventually moves to the general comments section or the talk page anyways, but that doesn't mean that it should be forced because that would be counterproductive to do so. It is always best to have discussion about things where they are instead of relocating it to some other place and that is the basic concept for any type of discussion on Wikipedia. Also, if the neutral section were to be removed, then people who wanted to voice their real and genuine opinions and concerns would be forced to do so in the general comments where their neutral !vote would just become another regular comment and would very easily get lost if there was a long discussion in the general comments section. There is a neutral vote when voting in the Arbcom election for a similar reason which is similar to abstaining, but the difference here is that Arbcom is an election process decided by vote percentage and RfA is a mixture and combination of both voting plus discussion where both are equally important. The neutral !votes are very important for bureaucrats to consider in RfA's/RfB's which are in the discretionary range and would therefore lose all their importance if they were placed as a general comment in the general comments section which is totally wrong and should not happen. I have myself !voted neutral on several RfA's in the past and I find it a very helpful and important place to voice my opinion/concern about the respective candidate. I had supported many important and useful changes in the Wikipedia:Requests for adminship/2021 review, but the changes proposed here will be unproductive as I have explained them and hence I fully oppose both of them. TheGeneralUser (talk) 14:07, 12 July 2022 (UTC)

General comments (RFA/RFB discussion)

  • Q: what does it mean by The neutral section will be eliminated at Requests for Adminship/Bureaucrat? It sounds like there would be only two sections: support, and oppose. Did I get it right? —usernamekiran (talk) 19:36, 13 June 2022 (UTC)
    OP has explained it in their support. duh me. —usernamekiran (talk) 19:38, 13 June 2022 (UTC)
    You shouldn't have to read my support to make sense of this so I've slightly modified the statement to add clarity. Best, Barkeep49 (talk) 20:01, 13 June 2022 (UTC)
  • Probably too late now, but might have been better to split this into 2 RFCs originally. It's hard to take the pulse of this and see what way this is trending without a very thorough read, due to the mixing of two questions. –Novem Linguae (talk) 01:48, 15 June 2022 (UTC)
  • This may just be my pet peeve, and its not as bad as it used to be, but I always thought "placeholder" neutral votes are self-important nonsense. "I haven't taken the time to actually form an opinion, and I just wanted that noted for the record" is just noise. If nothing else we should ban/remove those. Beeblebrox (talk) 19:35, 16 June 2022 (UTC)
    Maybe Wikipedia:Advice for RfA_voters#Voting 'Neutral' should be updated with such advice. I believe the last few RfAs that have had these "neutrals" were appropriately admonished. Rgrds. --Bison X (talk) 21:10, 16 June 2022 (UTC)
    For reference, an earlier discussion can be found at Wikipedia talk:Requests for adminship/Archive 252 § Placeholder neutrals, which resulted in this edit to the edit notice for all requests for adminship (though not for requests for bureaucratship, which don't have any edit notices). isaacl (talk) 21:43, 16 June 2022 (UTC)
    Huh, I totally missed that previous discussion. Interesting. I think just removing them is still the right move, but if we remove the neutral section altogether that will obviously be a moot point, so I guess we'll wait and see what happens here first. Beeblebrox (talk) 21:52, 19 June 2022 (UTC)
    The basic issue is that although there have been placeholder statements from newcomers (perhaps thinking that their participation had been solicited and thus they felt compelled to say something), they've also come from long-time editors, who would likely be displeased with having their comments removed. Thus the benefit-to-dissatisfaction ratio of enacting a new rule is fairly low, particularly considering the small number of such statements. (On the other hand, perhaps it happens so infrequently now that a rule could gain acceptance with only minor discontent? On the third hand, if it's out of fashion then it's a non-issue.) isaacl (talk) 16:26, 21 June 2022 (UTC)
  • Per WP:CREEP and WP:BROKE, this RfC is a solution looking for the wrong problem. It does not address the main issue of RfA which is its toxicity. Wherever the comments are made, RfA is, and will remain a process where traditionally all civility and common sense participation is allowed to be flouted with impunity, and on which comments and votes are beyond the pale. Plenty of research among both successful and reticent candidates has revealed that the environment itself is discouraging potential candidates of the right calibre from applying for adminship. Furthermore, these RfC at short intervals just fan the flames and increase the burgeoning tendency to start a full blown RfC to dot every I and cross every T. Fix the voters, for example through better clerking (by any established user) and set a threshold for user participation, and RfA will fix itself. Kudpung กุดผึ้ง (talk) 05:10, 5 July 2022 (UTC)
    What would you suggest to be a threshold for user participation? The idea itself is intriguing to me. CollectiveSolidarity (talk) 00:28, 13 July 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.

Upgrade opt-in Appearance gadget to show blocked users without talk page access

Moved to Wikipedia:User scripts/Requests § Upgrade opt-in Appearance gadget to show blocked users without talk page access

— Preceding unsigned comment added by EpicPupper (talk • contribs) 22:26, 21 July 2022 (UTC)

Clerk reform at RfA/RfB

FAILED
I'm closing this per WP:SNOW. No one seems to be on board with it, and that isn't likely to change any time soon.
For what it's worth, this closure is not in my capacity as an arbcom clerk but as a regular user.
Regards, (non-admin closure) –MJL ‐Talk‐☖ 17:35, 7 July 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.

This RfC attempts to gauge a consensus for a reform of clerking at RfAs/RfBs, which is proposed due to much discussion on that topic during a recent RfB. The general proposal is submitted below for evaluation, please share your thoughts. Szmenderowiecki (talk) 23:50, 20 June 2022 (UTC)

Proposal (Clerk reform at RfA/RfB)

  1. Clerking for RfAs and RfBs is delegated exclusively to the clerks serving at the Arbitration Committee who do not simultaneously have bureaucrat rights.
  2. Bureaucrats may !vote but may not clerk discussions. If they submit a !vote, they shall not be active during the determination of consensus for approval of the request for adminship/bureaucratship and may not participate in the bureaucrat discussion, if it is started.
  3. A clerk that has had substantial interaction with the candidate in question, or has nominated the candidate for RfA/RfB, must refrain from clerking it.
  4. The clerks must refrain from making comments in support or opposition of the candidate, and shall not modify or remove the comments based on whether the clerk agrees or disagrees with the opinion expressed there, but may only do so in case of violation of civility. They shall make explicit any intervention in the comments, along with the reasoning of intervention.
  5. Using their administrative tools (if they have access to them), the clerks may ban the editor from the RfA/RfB they are participating in case of persistent refusal to maintain decorum, but only for the duration of that RfA/RfB. A general ban from such discussions may only be enacted following a discussion at the administrator's noticeboard.
  6. Any sockpuppetry/meatpuppetry investigations, or those of canvassing, if started by a clerk or a bureaucrat in relation to an RfA/RfB, must be resolved as a first priority.
  7. The community will determine the venue of appeal or review of clerk's actions. (Formulated that way due to the current uncertainty over the existence of XRV and its scope)
  8. The Arbitration Committee may, if the rational usage of user resources so requires, appoint more clerks.

Rationale (Clerk reform at RfA/RfB)

In 2011, there was a proposal to introduce clerking as an ad hoc role for administrators and non-administrators in good standing alike, but it was not approved. The 2015 RfC established that bureaucrats may have the right to clerk discussions. In the answers submitted as part of the most recent RfB, however, Wugapodes, an (unsuccessful) candidate for a bureaucrat, said that bureaucrats are reluctant to clerk the discussions themselves, particularly since they may be perceived as non-neutral if they intervene. There has been some discussion during the RfB of the proposal of more active clerking as a way to reduce the stress and drama that often accompany the process, and there seemed to be some support to let it have a try, though not much certainty over the effectiveness of such a solution.

This proposal suggests a change from the bureaucrat-enforced decorum (which apparently does not work) to clerk-enforced decorum. Clerks are supposed to be experienced in dealing with incivility, which is often in ample supply at ArbCom, and the ways to respond to it. A drawback to this solution is that there are few clerks to begin with, and some bureaucrats are already arbiters. That said, let's try this proposal to see if people agree to make some sort of change, or even if it fails, we could see where the community in general stands on this issue. Szmenderowiecki (talk) 23:50, 20 June 2022 (UTC)

Feedback (Clerk reform at RfA/RfB)

(summoned by the bot) I applaud such efforts but 'Oppose This would be 8 new rules and procedures to solve 2 non-existent problems. The big problem at RFA isn't uncivil decorum, the problem and fix is more complex than that. And Wikipedia already has rules and processes regarding uncivil behavior. But thanks for such efforts. Sincerely, North8000 (talk) 12:02, 21 June 2022 (UTC)

If approval for sanctions is determined at the administrators' noticeboard, then I think any uninvolved administrator should be able to evaluate consensus (and, if deemed necessary, implement any suitable blocks). I don't think it's a good idea to prioritize sockpuppet investigations for an internal procedure versus those for mainspace edits. If necessary, an internal procedure can be put on hold or extended, without consequences to readers. Regarding the 2015 RfC, note the option of "any editor" received almost as much support as "bureaucrats", which is in practice what is done today. (On more minor editorial notes, the first sentence of point 2 is redundant with point 1, and point 8 is always generally the case.) isaacl (talk) 16:03, 21 June 2022 (UTC)

  • Feedback on components:
    1. I don't see any reason to forbid 'crats from clerking. I also don't like the idea of having arbcom be in charge of RfA's (as they are in charge of the arbcom clerks). I vote for arbcom members for dispute resolution skills, not for this.
    2. 'Crats already recuse when appropriate; this sets up a scenario that could prevent closure (as recusal isn't required if every active crat participated in an RFA it would be stuck - in practice this doesn't happen as the majority of 'crats do abstain from !voting.
    3. There are currently only 4 active clerks - who are also active throughout the project - some are already likely to have interacted with admin candidates.
    4. Volunteering to clerk arbcom cases should not disenfranchise someone from participating in RfA's.
    5. "Bans" don't require admin tools, and I don't think we should have any situation where a single editor can ban another one.
    6. CU's are volunteers - dictating the order of their work, or that they must volunteer to do something before they are allowed to volunteer to do other things is very anti-volunteer.
    7. Um, sure.
    8. Arbcom can already appoint as many clerks as they want.
    • So, I think there are many problems with this as proposed. I am fairly open to expanding the 'clerking' capacity of our 848 strong admin corps. — xaosflux Talk 12:59, 22 June 2022 (UTC)
  • Oppose. While some RFA/RFB discussions could be better, this amount of bureaucracy isn't going to resolve the issues and could lead to others. Thryduulf (talk) 11:56, 23 June 2022 (UTC)
  • I'd quite like to see some sort of "authorized" clerking system, but this seems like too much. What's needed are a few admins who are clear on what won't fly at RfX and what to do about it. Whoever clerks an RfX shouldn't !vote in it, but otherwise they really don't need any special qualifications. valereee (talk) 13:34, 24 June 2022 (UTC)
  • I'd also oppose - let's have Crats (those who don't (!)vote) clerk. In the same way that admin actions don't make someone INVOLVED for a future admin action, clerking would not logically disqualify from 'cratchats anyway. Nosebagbear (talk) 16:26, 24 June 2022 (UTC)
  • Oppose - I'm a longstanding proponent of clerking at RfA, to the extent that I myself wrote a proposal over a decade ago. So this definitely caught my attention. And then immediately lost it with the very first point. I find the proposal to be tone deaf towards the RfB that inspired it. The RfB mostly failed because the user was an active arbitrator, and a significant group came out in opposition to the existence of an overlap between the two roles, with many comments clarifying that it is nothing personal against the user. I certainly don't think the community wants a special class of people hand-picked by Arbcom to be policing RfA, when they don't want even the most uncontentious arbitrator policing RfA as a crat. In spite of this result, it did not fail because the community doesn't want crats to clerk RfA. Indeed, the community has repeatedly established that it supports the notion of crats clerking RfA, it is supported by a formal RfC, and based on the RfB, this hasn't changed. ~Swarm~ {sting} 05:36, 25 June 2022 (UTC)
  • Oppose: How does this solve anything is beyond me. I might be dumb but please don't tell me that sockstriking a sock's !vote at a RfA would get me blocked just because I'm not a ArbCom clerk. —CX Zoom[he/him] (let's talk • {C•X}) 20:43, 25 June 2022 (UTC)
  • Oppose - Preventing crats from clerking at RfB seems like a good idea, but the rest of the proposals seem to me like formalizing a lot of things that already happen, and work just fine at that. Not to be too libertarian, but I think setting rules beyond what is necessary is...not necessary. Toadspike (talk) 09:11, 7 July 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.

About mass shootings

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 American Psychological Association. However, the English Wikipedia community may be partially responsible as well, since mass shootings sometimes appear on the Main Page (for example, 2012 Aurora, Colorado shooting is included in the "On this day" section today), and there is evidence that giving a mass shooting massive attention can cause contagion. So I propose that such tragedies (excl. state violence, events accompanied with a military operation and more-than-three perpetrator ones) be excluded from the Main Page, except for "From today's featured article" and "Did you know ..." to mitigate the current mass shooting epidemic in America. RekishiEJ (talk) 16:47, 20 July 2022 (UTC) altered a bit 10:21, 21 July 2022 (UTC)

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)
"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 James von Brunn, John Patrick Bedell, Anders Breivik, Adam Lanza, 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 WP:NOTCENSORED issue. Americans will continue mass murdering themselves, and it will continue to be news. Much like bombings and other acts of terrorism, accidents, and other disasters will continue to occur, and continue to be news. Headbomb {t · c · p · 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:NOT#NEWS exists and 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 R2, 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)

Protecting important list articles indefinitely

I think it is important to protect important list articles from promotional edits such as List of news websites in India and Over-the-top media services in India. I believe these types article has an importance in search results that people search for it. Unfortunately, there is a high chance to get the article vandalized for promotional uses by others (business, agency) to list their assets in Wikipedia. IPs are also coming with the same after the vandal's block. So, I believe it would be important to make these types of article reliable and vandal free by protecting it with SemiP or ECP. Onmyway22 talk 07:18, 27 July 2022 (UTC)

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 improve

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 discussion), alphabetic order isn't always optimal, etc. You can get more feedback by posting at WT:APO and WT:WPDAB. Uanfala (talk) 13:13, 3 August 2022 (UTC)

Rolling out the edit wizard

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: *::::![image](https://user-images.githubusercontent.com/99730619/183674444-83719bff-cdc7-41bd-b8ce-806b9fff00bf.png) *::::Compare to how reply tool loads it below the input area: *::::![image](https://user-images.githubusercontent.com/99730619/183674832-8fb1b715-2790-4363-a3ce-c0188e3e86bd.png) *::::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 168 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)

Bots fixing double redirects should tag them with rcat

Original proposal: Suppose a double redirect A → B → C is straightened to A → C. If B is retargeted or expanded to an article later, A should be updated accordingly. We already have a mechanism for that, the template {{R avoided double redirect}}. However, the double-redirect-fixing bots currently fail to tag the straightened redirect (A) with the template. I thus propose to make it mandatory for the bots to apply the tag when straightening a double redirect. It has already been discussed at Wikipedia talk:Double redirects § The bots should operate with a delay. See also the modification of the proposal below. Petr Matas 05:40, 1 August 2022 (UTC). Updated: 23:46, 2 August 2022 (UTC)

It's really a bad task for a bot, and {{R avoided double redirect}} is rather pointless tagging in most cases. Many redirects are created as double redirects with the understand that a both will cleanup after them. What's gained by tagging those with {{R avoided double redirect}}? Headbomb {t · c · p · 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 Proceedings of the National Academy of Sciences of the United States of America. Because that is a mouthful, I create 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
P.N.A.S. → PNAS
PNAS USA → PNAS
Proc Natl Acad Sci → PNAS
Proc. Natl. Acad. Sci. → PNAS
Proc Natl Acad Sci USA → PNAS
Proc. Natl. Acad. Sci. U.S.A. → PNAS
Proceedings of the National Academy of Sciences → PNAS
And a bunch of others
Should those be tagged with {{R avoided double redirect}} once the bot cleans up after me? The answer here is clearly no. These are not distinct topics, these are the same topics. Headbomb {t · c · p · 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 becomes a disambiguation page, even though it is not tagged as a redirect with possibilities at present. Then all redirects that pointed to it before straightening should be retargeted back to 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 Proceedings of the National Academy of Sciences of the United States of America before PNAS got turned into a dab? What would be different? Exactly nothing, since no redirect is pointing to PNAS. Headbomb {t · c · p · 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. Headbomb {t · c · p · 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 {{R avoided double redirect}} imo. –MJL ‐Talk‐☖ 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 {{R avoided double redirect}}? Headbomb {t · c · p · 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 {{R from move}} then I don't think pages targeting it should be tagged {{R avoided double redirect}}. –MJL ‐Talk‐☖ 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 WP:PAGESWAP (which also means that ordinary editors couldn't at all), all because of Rcats. Heck, I'll stop even trying. Now, can anyone remind me for what purpose we invented the Rcat's for? Why should I care having a {{R from move}} when I can see from history that the page had been moved? Worse still, why should anyone care about {{R bot-avoided double redirect}} and the associated category? While Rcats might be marginally useful somewhere, most of the time they're just a big nuisance. No such user (talk) 12:40, 15 August 2022 (UTC)

20 years club?

The informal Wikipedia:Twenty Year Society is available. — xaosflux Talk 15:30, 15 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.

In about one month, I will pass the 20 year milestone-that is, it will be 20 years since I began contributing at Wikipedia. Now, with the "pedia" being around since c. 2000, I reckon there are very few Wikipedians who have reached that milestone, so I was wondering, is there any way that we can form a club or a group or a list or whatever, of Wikipedians who have been here 20+years and are still active?-Or, a club-list, etc of Wikipedians who have collaborated for 20 or more years? Thanks and God bless! Antonio Pediaphile Martin (si??) , 10:53, 10 August, 2022 (UTC)

User:AntonioMartin, yes there is at Wikipedia:Twenty Year Society. Welcome to the club! CactiStaccingCrane (talk) 12:44, 10 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.

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)
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,
  • 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. Headbomb {t · c · p · 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)

Many articles for years on Wikipedia, such as 786, contain the text "(link will display the full calendar)". This text is usually intended to explain articles displaying the corresponding calendar, such as Common year starting on Sunday. I propose that this text be removed from the 1.58K instances of this, as it is not appropriate in print and does not conform to usual Wikipedia standards. Per the Manual of Style, articles should be written in a manner that facilitates transmission in other forms such as print, spoken word, and via a screen reader. The question of whether these calendars are helpful and should be included via a template sidebar or navbar is appropriate for another discussion. In the event that this proposal passes, I intend to submit a bot request for approval for this task. Thank you for your consideration, 🐶 EpicPupper (he/him | talk) 21:17, 18 August 2022 (UTC)

Notified: Wikipedia talk:WikiProject Years#Discussion at Wikipedia:Village pump (proposals) § Removal of "link will display the full calendar" in year articles. 🐶 EpicPupper (he/him | 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)

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)
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 Pulse Nightclub Shooting and the Capitol insurrection are impactful events that should not be held in draft-space for two weeks. Conversely, this and this are really just violations of 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). (edit conflict) –MJL ‐Talk‐☖ 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 September 11 attacks or 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.

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 {{citation}} template) as it eliminates the silly distinction between web and newspapers for sources such as The Guardian or NYT which are both. And I like 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. Headbomb {t · c · p · 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 Template:infobox language to be able to include a language compass in articles (see Breton language), along the lines of |status= in Template:speciesbox. Currently, these are added using the |map= or |map2= parameters, which is limiting if a language needs more than one map, and most use {{small}}, not following 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, e • 🗣 • 🏲 15:28, 25 August 2022 (UTC)

References

  1. ^ Moseley, Christopher; Nicolas, Alexander, eds. (2010). Atlas of the World's Languages in Danger (PDF) (3rd ed.). Paris: UNESCO. 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? 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 WP:BOTPOL should be reviewed. Headbomb {t · c · p · 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)

@HarshaMadhyastha: once you have results, you can simply post a notice here (or maybe WP:VPM would be better), and at WP:BOTN and that should give you plenty of feedback. If you target specific types of articles like "mostly medical articles", you can also post notice on related Wikiprojects, like WikiProject Medicine. Headbomb {t · c · p · 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 Figure skating at the Olympic Games? —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:Dark mode (gadget) exists which provides this for logged-in users. It cannot work for logged-out users as Nardog mentions. Anything like this that works for logged-out users would have to be an extension and even then there are technical issues such as parser cache having to keep two copies of every page (light mode + dark mode). I suggest deactivating RfC tag - see 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.

Wikipedia talk:In the news has an 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 the administrators' incidents noticeboard (ANI). However, I believe that a specific section of the administrator intervention against vandalism (AIV) noticeboard should be used instead for requesting talk page access revocation. Per 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 @Tamzin and @Suffusion of Yellow, who had brainstormed this idea in the past and shared it with me. Thank you for your consideration! 🐶 EpicPupper (he/him | talk) 21:48, 18 August 2022 (UTC)

Notified: Wikipedia talk:Administrators' noticeboard, Wikipedia talk:Administrator intervention against vandalism, Wikipedia talk:Counter-Vandalism Unit. 🐶 EpicPupper (he/him | 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. 🐶 EpicPupper (he/him | 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. 🥒 EpicPickle (they/them | 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.--Ineffablebookkeeper (talk) ({{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)
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
old icon
new icon
How the new icon appears in Chrome on a 1920x1080 display in Windows 10


Recently, a new icon has been rolled out and implemented for external links. Should we use the longstanding icon or keep the new one? — Ⓜ️hawk10 (talk) 04:26, 29 July 2022 (UTC)

  • 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. — Ⓜ️hawk10 (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. — Ⓜ️hawk10 (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)
  • WP:BIKESHED If you prefer the 'old one' once the 'new one' is rolled out, you can always customize it in your on skin. Headbomb {t · c · p · 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. — Ⓜ️hawk10 (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)
  • WP:BIKESHED, no one should care, start writing articles or become a designer ffs —TheDJ (talk • contribs) 14:02, 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:BIKESHED, 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. – Berrely • T∕C 07:23, 15 August 2022 (UTC)
  • Note: A new icon has been proposed – Berrely • 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 Jason here. I also don't like setting the standard that we make our source code easier to change than MediaWiki:Common.css. There should be some sort of community review before highly visible changes go live.
FWIW, I say this as the person who got the PDF icon change rolling (despite not getting my preferred result). @Nosebagbear: From that perspective, I can say the pdf change took forever simply because the community didn't just want an improved icon (which my suggestion in comparison to the lousy gif) but a better icon (the one they ended up going with without the Adobe logo on it -_-). –MJL ‐Talk‐☖ 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)
@Whatamidoing (WMF): Thank you for clearing that up for folks. –MJL ‐Talk‐☖ 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 The Heat Is On (TV series) and ST47 for Eric van Viele) to archive them using the instructions at WP:HOAXLIST. Extraordinary Writ (talk) 05:15, 11 September 2022 (UTC)
Can't someone also just copy the archived page? --RockstoneSend 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)
@Casualdejekyll, the issue is that FACs tend to have a strict time limit - if a nomination doesn't get any comments, or if consensus isn't reached within several weeks, it's automatically archived. GA has no such time limit. To repeat what David Eppstein and other editors above said, good article nominations can languish for weeks or, in many cases, months and even years. It's also important to note that even FA doesn't have a strict one-nomination limit; many regulars stack two FACs at a time if they're co-nominating, and sometimes you can even find three FACs by the same user at the same time. Additionally, unlike at FAC, GA reviewers are not obligated to finish their reviews in a timely manner; 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)
  • Etriusus can you clear something up, especially in the intro paragraph and the header - what is wrong with someone producing lots of "GAs", which seem to be Wikipedia:Good Articles. Isn't creating Good Articles a GoodThing? Without digging through everything else, it seems that maybe your issue is with someone creating a lot of 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)
Nota bene* 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. SD0001, given that via SDZeroBot you have access to the number of successful GA nominations, would you be able to periodically generate a page that listed all the editors with an open nomination on WP:GAN, along with the number of promoted GAs each nominator had? Mike Christie (talk - contribs - library) 17:57, 20 September 2022 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_191&oldid=1113160911"