Wikipedia:Village pump (proposals)/Archive 199

Add links
Source: 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

RFC: split births & deaths from year articles

This discussion resulted in consensus to split, with some caveats.

The strongest consensus that developed in this discussion is that large year articles should have the births and deaths removed. Whether an article is "large" can be determined using the guidance at

WP:SUMMARYSTYLE
and it being preferable to have a tighter inclusion criteria than to just remove the births/deaths. Though the weight of consensus did not favor these arguments, they are reasonable starting points for future discussions.

I do not find any consensus for how to handle small articles. Some editors explicitly opposed removing the births/deaths based on SIZE/SPLIT or on concerns about creating stubs. No editor advocated explicitly for removal in such cases, but many pro-split rationales were written to apply to all year articles. I do not find any reason that the usual

WP:NOCONSENSUS
guidance shouldn't apply here, so the content should stay in short articles pending further discussion.

For yearly births and deaths that are removed, the next question is: where should the content go? For deaths, proposals ranged from outright deletion, to incorporation in monthly "Deaths in month year" articles (which currently exist only for 1980–present), to the creation of "Deaths in year" articles (which do not yet exist). Consensus did not develop for any particular proposal, though most participants do not favor total deletion. Births got short shrift on this question, so there's even less agreement on what to do with them. Wherever the content ends up, there is consensus to link to the ultimate location from the main year articles.

Some participants supported splitting off births/deaths but proposed that some still be included if they meet the inclusion criteria as events. There's enough support, little enough opposition, and enough common-sense-iness to this proposal that I find rough consensus in its favor. Finding the line between the death of Queen Elizabeth and the birth of Elizabeth Banks is another open question.

For such a well-attended RfC, there was strikingly little engagement between participants on the substantive questions at hand. I hope to see further discussion on the matters that did not reach consensus. Firefangledfeathers (talk / contribs) 03:35, 8 March 2023 (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.

Should the "births" and "deaths" sections of year articles (e.g.,

WP:SPLIT
into separate articles? RFC posted 18:27, 1 February 2023 (UTC)

Proposer's note: see recent discussion at Wikipedia talk:WikiProject Years#Births & Deaths sections. Levivich (talk) 18:27, 1 February 2023 (UTC)
That seems like the kind of editorializing other websites, like news sites, might excel at. Maybe if we had a better category system, we wouldn't need to maintain a list like this. --Golbez (talk) 22:48, 6 February 2023 (UTC)
  • Support as long as readers could easily navigate to "Deaths in year X" from "Year X". It is getting too long and too unwieldy. Ancient years where there are no long list of births and deaths should not be changed.✠ SunDawn ✠ (contact) 16:04, 4 February 2023 (UTC)
    I think that how [[[2022 in the United States]] handled it is the best way. We have a level 2 header with a hatnote. InvadingInvader (userpage, talk) 01:29, 6 February 2023 (UTC)
  • Oppose as it is clear that recent years are suffering from recentism, and need to be cleaned out. Graeme Bartlett (talk) 21:03, 4 February 2023 (UTC)
  • Partial Support, as it fixes the usability issue of having multiple long timelines per page (which makes it harder to use scroll bars to judge which point in the timeline you are looking at). Partial because articles like Deaths in February 2022 appear to include all notable deaths, so are very likely to already include the more selective subset of deaths from the main year articles, so in practice we are talking about deletion of those sections rather than splitting. I support that too, but I’m not sure this is laid out clearly enough in the proposal. Barnards.tar.gz (talk) 22:22, 4 February 2023 (UTC)
    Barnards.tar.gz: Just to clarify, situations like this would be the exception. There are preexisting standalone lists of deaths for 1990-2023, so it would be effectively be a deletion in those cases since the content already exists at the destination. But all the years before that don't have dedicated lists of deaths, and to my knowledge there aren't any preexisting standalone lists of births by year. Thebiguglyalien (talk) 22:50, 4 February 2023 (UTC)
  • Support per Useight. Good suggestion. This would also have the benefit of preventing some of the horrendously long and mind-numbing disputes recently seen. Happy days ~ LindsayHello 16:18, 5 February 2023 (UTC)
  • Support as it would drastically reduce the amount of content disputes, though I would prefer to see some mention of notable funerals under events, as well as hatnoting these. I would also not be a big fan of splitting these contents if it would end up creating mini stubs, but in general, especially for years 1900+, this is a good idea. InvadingInvader (userpage, talk) 01:25, 6 February 2023 (UTC)
  • Support The articles are moderated pretty well, but the pattern right now is every time someone disagrees it goes to RfC and it basically becomes a popularity contest with no regard for how the article has been managed. Since there's no consensus on a way forward it makes sense to just remove the deaths altogether. Nemov (talk) 16:52, 6 February 2023 (UTC)
  • Support. I agree that births & deaths are minor aspects of a yaer. The freed-up space could be used to turn the lists into prose, which would make these articles far better. DFlhb (talk) 18:13, 6 February 2023 (UTC)
  • Support, so there is no more discussion about who is "internationally" noteworthy enough to be included in the main year article which really comes down to editor opinion. Right now, people are arguing to include
    WP:DUEWEIGHT in sources (Josef's bio has two sentences, but he's included over someone like Ash Carter). If you list them all on their own page and remove them from the parent, that solves the problem. Of course, deaths like Shinzo Abe and Queen Elizabeth can still be included in the "events" section, as there is related news to that beside just their act of dying (e.g., the assassination; the new king). Why? I Ask (talk
    ) 02:19, 8 February 2023 (UTC)
  • Support Births and Deaths sections are the reason why recent years articles are cluttered. A split would be a good idea, as it would make most discussions regarding death of notable figures moot, and not just that, it would do away the possibility of another discussions regarding these - which always fills up the talk pages of year articles because of debates after debates about THESE deaths. MarioJump83 (talk) 09:01, 8 February 2023 (UTC)
    Not only that, but these sometimes ridiculous deaths discussions have been draining my mental health. I feel confident in assuming that some other people can relate. I'm glad that we've finally gotten rid of the old "International notability" standard in general, but deaths at this point are best if they face a Morgenthau Plan-like fate. InvadingInvader (userpage, talk) 21:28, 11 February 2023 (UTC)
  • Oppose. Neatly trimmed sections that contain births and deaths should be included, per
    summary style. That we have a hard time doing this might be part of the task, but merely splitting it out without providing some summary overview in the article seems contrary to that style. — Red-tailed hawk (nest)
    19:16, 8 February 2023 (UTC)
  • Support only for those that satisfy the conditions of
    WP:SPLIT. If the articles are way too long, then it's a good idea, but for e.g. earlier centuries, most of the year articles are short enough that the list of comparatively smaller births and deaths of people with articles is unobtrusive. Joseph2302 (talk
    ) 13:35, 9 February 2023 (UTC)
  • Support - Where the year article is over-long, and the birth/death is not a major historical event in itself (like, e.g., the birth of Jesus or the death of Stalin). If there is any dispute about where a birth/death should be included as a major event, typically I would expect an article about the birth/death as an event for it to qualify. FOARP (talk) 14:46, 9 February 2023 (UTC)
so you're saying that we should include a list of very significant events, births and deaths in the year articles, and have a separate set of articles of 'all deaths' in those years? This is already the case. JeffUK 12:50, 10 February 2023 (UTC)
  • Oppose - We already have articles listing all (notable) births and deaths in each year. This is supposed to be a curated list of very significant events in each year; If the problem is that the article is too long, we need an RFC to agree the inclusion criteria for Births and Deaths that would drastically raise the bar for inclusion. I think the same is true of 'Events' as well. JeffUK 12:50, 10 February 2023 (UTC)
    This is supposed to be a curated list of very significant events in each year. You're right, which is why a deaths and births sections is unneeded in the parent page. It's not a big event that Coolio died. Other deaths, such as Shinzo Abe or the Queen, are notable events themselves with their own pages. But that can be added to the events section as special mentions. There is not need for the random duplication of content across pages, and currently the inclusion criteria is vague and handled by only a small subset of editors. Why? I Ask (talk) 13:13, 10 February 2023 (UTC)
    My view comes from 'look at what other similar sources tend to include', and a 'year in review' type resource will often include a list of 'important' deaths which is separate from 'events'. There's a difference between a death with is significant (Joe Nobody killed by aliens) which is an 'Event', and the death of someone who is significant, but who's death was otherwise not (Rich old formerly important man dies at home). I think readers expect a listing of significant deaths in the year in some easy-to-consume format, without having to read through all the other events. Looking at the newly formatted 2001 article, I think having a section on 'Deaths' would fit perfectly. I like the idea I saw on one of these myriad discussions about having a guideline/soft limit of X deaths on the main article. JeffUK 19:23, 10 February 2023 (UTC)
    "My view comes from 'look at what other similar sources tend to include', and a 'year in review' type resource will often include a list of 'important' deaths which is separate from 'events'."
What "similar" sources do that? Most
WP:WEIGHT
has been advanced out of that project. If there was, I for one should be happy to consider it, as I think there's at least an argument for keeping a summary section in the main article. And yes, a soft limit might make sense there as well. But inclusion criteria has to somehow be rendered out of source-based/NPOV/WEIGHT processes. None of this !voting the opinions of our individual editors as to what we think is important, and then reverse-engineer policy-like language such as "international notability" to rationalize those idiosyncratic preferences after-the-fact nonsense that seems to have become quite common practice on some the years articles in recent years, from the look of the talk pages.
In the meantime, until such a RS-based standard and process is proposed and endorsed by the community at large, the current proposal is a reasonable middle ground solution that addresses the main concern that arises out of the WP:YEARS crowd--which is doubtlessly exaggerated but nevertheless a cognizable issue--that the years articles are too large, but balances that concern against broader, more central, and more critical content policies that the community expects other more localized standards to generally conform to. SnowRise let's rap 02:31, 11 February 2023 (UTC)
A deaths section on paper would look nice, but it's like premium gasoline for an engine which produces the lamest edit wars and most unnecessary discussions. I feel like I need ten extra cups of coffee whenever I'm entering Talk:2022 to argue in favor of or opposing deaths. It's become mentally draining for me, and the removal of the section is not only in the interest of the project for reducing these wars, but by extension also in my self interest. No one can agree on a criteria, and given the about of opposition to "International notability" as previously implemented, unless we remove deaths altogether, we're going to be stuck in a gridlock because it seems like no one is willing to concede disputes until an RFC closes or outside admin intervention occurs. InvadingInvader (userpage, talk) 21:24, 11 February 2023 (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.

Discussion at Wikipedia talk:WikiProject Templates § Standardization of image sizes in discussion templates

 You are invited to join the discussion at Wikipedia talk:WikiProject Templates § Standardization of image sizes in discussion templates. --Trialpears (talk) 04:48, 8 March 2023 (UTC)

OCLC/Worldcat links as URLs

I've noticed a large number of citations use links to Worldcat in the URL field. These should, I believe, be subsumed under the OCLC tag, which generates the exact same link. These are deceiving to users who will expect a link to the actual book or article, rather than a listing of libraries that hold that title. I would love to see these treated as CS1 errors so we could clean these up. There's been a brief discussion at Help talk:Citation Style 1/Archive 87#OCLC/Worldcat links as URLs. I suggest that CS1 (and other relevant citation styles) generate an error when the URL field contains a link to WorldCat, plus a maintenance category to track how many articles have this issue and to allow editors to easily correct them. Straughn (talk) 14:30, 8 March 2023 (UTC)

Request for comment about the lead sentences in articles about elections

There is a request for comment about whether boldface or links should be preferred in election article lead sentences. Surtsicna (talk) 09:41, 12 March 2023 (UTC)

Template:Reflist-message

Suggest having a template for generating a reference list only in a given message on a talk page. It could be called Template:Reflist-message. It would be like Template:Reflist-talk, which is for a whole talk section and appears at the end of the section, but would only apply to a given message. It would be useful when an excerpt from a Wikipedia article is copied to a talk page message for discussion. The reference list would be conveniently next to the rest of the excerpt and the references would be clearly displayed for any discussion of them in following messages. Bob K31416 (talk) 19:36, 11 March 2023 (UTC)

But what you're describing is the functionality of {{Reflist-talk}} exactly. This template doesn't have to be at the end of a section, it can be used anywhere, and it will display whatever refs have been used in the preceding text since the last instance of a ref list. – Uanfala (talk) 19:53, 11 March 2023 (UTC)
If there is a Reflist-talk already placed at the end of the section for a previous message, then Reflist-talk placed in a new message in that section will dysfunctionally display the references from the previous message. If there was a Reflist-message, it would properly display only references for the message that it is in. Also note that in the documentation for Template:Reflist-talk, it says to place the template at the end of the section. Bob K31416 (talk) 21:17, 11 March 2023 (UTC)
You could achieve that effect by leaving off the <ref>...</ref> tags and leaving the templated citation(s) where you want it/them in your comment. Whether that is desirable is another issue that I haven't really thought about. You probably would have to add some context to make clear it is/they are reference(s). Donald Albury 23:51, 11 March 2023 (UTC)
Yes, that's a work around. I've done that. I just thought that this would be a useful template for the community. Bob K31416 (talk) 02:00, 12 March 2023 (UTC)
Bob K31416, am I missing something here? Just put an instance of the template at the end of every message, and it will only display the refs in that message. – Uanfala (talk) 00:40, 12 March 2023 (UTC)
That would require altering another editor's message and getting their permission to do so.
Doesn't look like this is getting anywhere. Bob K31416 (talk) 02:00, 12 March 2023 (UTC)
Not necessarily. If you'd like your reflist to list only your own refs, then precede your message with a reflist template to mop up any dangling refs from the text before it, then at the end of your message add a reflist template, which will then only display the refs from your post. – Uanfala (talk) 14:22, 12 March 2023 (UTC)
Looking at your user page, I think you're intelligent enough to see the flaws in your own suggestions. Bob K31416 (talk) 15:07, 12 March 2023 (UTC)
What you are asking for is not possible with how the software works. People are trying to suggest how you might get close, it would be good not to insult them. Anomie⚔ 17:36, 12 March 2023 (UTC)
How is it not possible? Can you explain?
Actually, the question of whether it is not possible because of limitations of the software is a question that is open to any expert that may be viewing this thread and would be willing to offer their opinion with an explanation. Thanks. Bob K31416 (talk) 18:11, 12 March 2023 (UTC)
You seem to want it so that only <ref> tags in your comment are included in the output of the template, without including tags in the same group from earlier comments. The software accumulates refs as the wikitext is parsed and <references /> outputs all the accumulated references to that point, there is no way to tell it to only include references from a part of the preceding page and no way to tell it to begin a new "context" for the accumulation.
The best you might do would be to manually use a group= parameter on your <ref> and <references /> that is not used anywhere earlier on the talk page (at least without its own <references />). Note that automatic translation of <ref> to add a group would be complicated by needing to be hacky to get the unexpanded wikitext into the template parameter in the first place and further complicated by having to handle templates like {{efn}} and {{r}} and so on. Anomie⚔ 11:47, 13 March 2023 (UTC)
Thanks. I think this is an example of the workaround that you mentioned in your second paragraph:
Markup Renders as 
A cure for cancer was found,<ref group=.>ABC News</ref> although it will be very expensive.<ref group=.>CBS News</ref> 
{{reflist|group=.}}

A cure for cancer was found,[. 1] although it will be very expensive.[. 2]

  1. ^ ABC News
  2. ^ CBS News
Bob K31416 (talk) 13:35, 13 March 2023 (UTC)
@Bob K31416 That would require altering another editor's message and getting their permission to do so. Adding {{reflist-talk}} to other people's comments is specifically called out in the Talk page guidelines as an example of appropriate editing of other people's comments in the fix formatting errors section. 163.1.15.238 (talk) 15:26, 13 March 2023 (UTC)
(edit conflict)This proposal has a faint whiff of that old favorite, "ASISOAP" (a solution in search of a problem). It doesn't seem like a situation that comes up that often. If you find yourself participating in a discussion section that is so long and has so many references that it's confusing how [17] in the comment matches up with the footnote 17 at the end of the section, then maybe it's a good time to insert an === Arbitrary break === somewhere. Would that be a sufficient approach for you, Bob? — JohnFromPinckney (talk / edits) 11:55, 13 March 2023 (UTC)
Concur. Section breaks solve this rare problem. -- GreenC 16:05, 13 March 2023 (UTC)

Suppose an excerpt from a Wikipedia article is copied to a message on a talk page and the reference list for the excerpt is wanted to immediately follow the excerpt. Can a template be made of the form {{reflist-x | excerpt}} where the parameter "excerpt" is the markup excerpt from a Wikipedia article, and the result is the text of the excerpt and its reference list that immediately follows? Bob K31416 (talk) 05:26, 13 March 2023 (UTC)

No, not as I'm guessing you intend, for the same reason as above. Anomie⚔ 11:47, 13 March 2023 (UTC)

Change visual editor to produce "upright" parameters instead of "px" when an editor merely drags the image larger or smaller

When an editor simply clicks on an image in an article and drags it to a larger or smaller size, the underlying code uses "px" (specific pixel size) instead of "upright". This proposal is for the visual editor to generate "upright" instead.

The use of "px" causes the display of a specific size of image regardless of what device the user is viewing Wikipedia. This is inferior to using "upright" which is a relative size (relative to your device, so to speak). Thus, "upright" should usually be applied instead of "px".

My personal experience, and thus for proposing this is that, as a newer editor, I edited ~30 articles using the visual editor before I realized that this was happening. It seems like a straight-forward upgrade to the visual editor. By the way, I went back and modified those 30 edited articles using "upright". I have since noticed many articles with specific "px" instead of upright and manually fix those myself; so this seems to be a fairly widespread problem. Countercheck (talk) 21:54, 9 March 2023 (UTC)

In that respect VE is already out of step with
our policy. You might consider adding your experience to Phab:T64671 or Phab:T296869. CMD (talk
) 09:06, 10 March 2023 (UTC)
The last time I remember the Editing team talking about this was c. 2015, and another team was considering removing the |upright system entirely. Obviously, that didn't happen, but if you want to pursue this, it might be worth figuring out whether the |upright system is really the best solution. Whatamidoing (WMF) (talk) 21:28, 15 March 2023 (UTC)
See also Should we have a more intuitive word for resizing images than "upright"? and the resulting phab task phab:T327120. the wub "?!" 09:38, 16 March 2023 (UTC)
Thanks. I'll write a comment there. Countercheck (talk) 15:53, 16 March 2023 (UTC)

Opt-out from future global edit filters

A proposal to enable global abuse filters managed on the meta-wiki is being discussed. Should it pass, local projects would need to opt-out if they want to only continue to use their local edit filters. Links and local discussion are open for comment at our edit filter noticeboard. We can pre-opt-out if there is a local showing of support. Thank you, — xaosflux Talk 09:53, 18 March 2023 (UTC)

Science Photo Competition 2023 Russia targeting CentralNotice banner

On April 2, the «Science Photo Competition 2023» started, traditionally the photo marathon is being held jointly with the Nauka television channel, it will be interesting. We invite everyone who is interested in science and who is able to hold a camera in their hands. The rules of the contest are very simple, prizes have a place to be! Colleagues, to attract external participants, we proposed a banner of the competition through CentralNotice. JukoFF (talk) 14:48, 19 March 2023 (UTC)

Change Common.css to remove default background from galleries

I'm coming here from Help talk:Gallery tag. User:Redrose64 explains the technical details there.

In galleries, a checkered background is added. This is an eyesore when a background color is used to set off images that are partially transparent, as here:

  • Sun
    Sun
  • Psyche
    Psyche
  • Gonggong
    Gonggong
  • Charon
    Charon

This displays correctly on Commons and most Wikimedia sites, including English Wiktionary. (English Wikiversity, Spanish Wikipedia and Spanish Wikivoyage add a white background. I first noticed this on WP-es.) Wikt-vi, -sr and WP-vi, -ko, -id, -ms, -sr also show white backgrounds, but most I checked did not.

Is this necessary? Could we restore the Wikimedia default display, or failing that, provide a way for the gallery tag to access the background param?

This is not a problem outside of galleries, as can be seen at the bottom of the template {{Infobox zodiac}}. — kwami (talk) 22:27, 19 March 2023 (UTC)

If I understood the conversation at talk page, this behaviour is suppressed in pages in mainspace, portal space (both of which are reader-facing), and user space. I imagine the reason for having a checkered background is that most images won't have one, and so if you see it, it's an indication that the image probably has transparent areas. I think this can be helpful for use cases where the images are being shown as candidates for use in other locations. I can conceive, though, how there may be use cases where, say on a WikiProject page (that is, a page in Wikipedia space), it would be nice to not add in a background. Do you have an example in mind where it is desirable not to have a visual indicator of transparent areas? isaacl (talk) 22:43, 19 March 2023 (UTC)
Ah, I hadn't realized that. But on en main, user and portal space, the checkered background is replaced with a solid white background, which is even worse because, as you said, it's not evident that the image is partly transparent. I'm advocating having no default background, or at least allowing the default to be overridden with gallery style="background-color: xxx;", which will accomplish the same thing but allow customization. (E.g. at infobox zodiac, where the imgs are set off on a black background -- yes, I realize that's not a gallery tag.)
If you copy the gallery above and preview it on your Wiktionary user page, you'll see what I mean.
I do see the functionality of the checkered background on non-reader-facing locations, but I don't see the point of forcing a white background in reader-facing locations. That has no visible effect other than denying the editor the ability to customize the display.
It looks like WP-es, where I first noticed this, is the same as WP-en: checkered background on talk space, solid background on user space. Contrast WP-fr or wikt-en, where there is no background on either. It may be worth keeping our checkered background for non-reader-facing locations, but IMO not the solid white background on reader-facing locations. — kwami (talk) 22:54, 19 March 2023 (UTC)
Based on MediaWiki:Common.css#L-254, the link provided by Redrose64 in the talk page conversation, the background-image property is set to none, which would allow whatever is underneath to show through. However... looking at a preview with my brower's development tools, I believe the Vector 2022 skin is setting the property to a white background. Are you using Vector 2022, or another skin? isaacl (talk) 23:21, 19 March 2023 (UTC)
That wouldn't explain French Wikipedia, though, which is using Vector 2022... Perhaps it has some additional style rules defined. isaacl (talk) 23:24, 19 March 2023 (UTC)
Just the opposite: I'm using Monobook on WP-en, but Vector 2022 on WP-fr. — kwami (talk) 23:53, 19 March 2023 (UTC)
Changing WP-en to Vector 2022 and WP-fr to Monobook doesn't seem to have any effect on the gallery display. I ran through the available skins here, and in all of them, the gallery displays with white backgrounds on my user page. — kwami (talk) 23:57, 19 March 2023 (UTC)
My mistake; I missed that the general rule starting at MediaWiki:Common.css#L-263 sets the background colour to white and the background image to the checkered pattern, and then the rule starting at MediaWiki:Common.css#L-267 sets the background image to none for specific namespaces. The white background could be removed, though it would be a big task to try to figure out what effect it may have on articles using galleries, since editors may have relied on the white background. isaacl (talk) 00:29, 20 March 2023 (UTC)
Is that likely to be an issue? Articles by default have a white background, so I'd think the only time it would even be visible would be when an editor manually selects a colored background for the gallery tag. — kwami (talk) 00:43, 20 March 2023 (UTC)
That was my initial thought too (plus the image has to have transparent areas). Nonetheless, it ought to be checked, and the effects of different skins considered. isaacl (talk) 01:29, 20 March 2023 (UTC)
Agreed. And so far I haven't noticed this as a problem in articles. I've only seen it on user pages, when people collect images that they like. Still, it would be nice if WP-en looked as good as other wikis. — kwami (talk) 01:50, 20 March 2023 (UTC)

Make "Always give me the visual editor if possible" default for new editors

In this discussion, the community considers the question of with which editing interface new users should be presented. The initial question is framed as if it were a binary choice between two possible defaults, but as it turns out, it isn't as simple as that at all.

After some confusion, the community figures out that IP editors who click the "edit" button are presented with a Welcome to Wikipedia banner which offers them two buttons. One takes them to the Visual Editor, and the other takes them to the wikitext editor. The button that points to the wikitext editor appears to be highlighted (in that it's white on blue rather than blue on white) and it says "start editing". Clicking this button takes you to the wikitext editor. The other one is marked "visual editor" and not highlighted in the same way. The user's choice when this box appears is remembered by default and, unless they know about the "preferences" button, they can find it hard to reverse their choice. This can lead to situations where someone inadvertently chooses an interface that's inappropriate for their markup language literacy level and can't easily find how to reverse it.

In other words, there isn't a "default" at all: there's a choice. Basically, the community wants IP editors to be able to switch between interfaces more conveniently. The community is attracted to the old method of displaying both editing tabs on the same page.

This is as far as the discussion goes so it leaves a lot of detail unresolved. In my view there's consensus to make it clearer what that "Welcome to Wikipedia!" box is actually asking, and consensus to implement some kind of easy switch between editors. I say with less confidence that there's consensus to reverse phab:T102398 -- it is in fact a unanimous consensus, in that every editor who expresses a preference on this does want the reversal, but (a) my confidence is low because it's such a small number of editors who do express a preference, and (b) presenting IP editors with the old choice between "edit" and "edit source" is not very illuminating for them either.

Whatever we do, it must have the effect of making the choice between interfaces clearer for the user and easier to reverse.—S Marshall T/C 21:55, 4 April 2023 (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.

Yesterday I helped someone to start editing in Wikipedia. Creating an account is a breeze, but when he started editing he is presented with the text editor, instead of the Visual Editor. Text Editor is good and have its uses, but for newer editor it is better to present them with Visual Editor, as it is created to be user friendly and really show changes that you intended. Editing through Text Editor for newer editor may be off putting, as many may just want to do minor changes (maybe add a single line in a table, change the number of things, etc.) and "learning" the wiki markup may be too much for them.

I understand that changing it in Preferences is trivial for many of us, but for many new editors this can be quite hard. This can be changed easily by making "Always give me the visual editor if possible" default. ✠ SunDawn ✠ (contact) 03:03, 31 January 2023 (UTC)

  • Strong support, as in "this could be one of the most important changes Wikipedia makes" support. To a new user, the wikitext editor is terrifying and bloated. To an experienced user, it can still be bloated. I'm fairly competent with wikitext, but I still use the visual editor for most purposes simply because the wikitext editor is too much to wade through unless you're making a really technical edit. I genuinely think Wikipedia would have a much larger user base contributing if the visual editor was the default. Thebiguglyalien (talk) 03:56, 31 January 2023 (UTC)
  • According to Wikipedia:VisualEditor this is already the case. CMD (talk) 03:57, 31 January 2023 (UTC)
    For an IP editor, the default is the wikitext editor, but it gives a pop up asking if you want to switch to the visual editor, which I imagine is meaningless to most users. I suppose it's not quite the same thing as a new account (and SunDawn might want to look into it to see where the discrepancy is), but visual editor definitely needs to be more accessible. Thebiguglyalien (talk) 05:20, 31 January 2023 (UTC)
  • Strong oppose.
    The WMF has been persistently and attempting to force this, despite the fact that they have data showing that defaulting into VisualEditor is harmful. There of course are some people who prefer VE, but the objective data shows the overal impact is negative. The WMF has been resistant to collecting good data on this, but I can report what we do have. If you examine the graph at the right, you'll find that the Desktop Wikitext Editor has approximately DOUBLE the retention rate as Desktop Visual Editor, and that Mobile Wikitext also has about DOUBLE the retention rate as Mobile Visual Editor. That is a pretty staggering difference. From the published graph we cannot tell whether Visual Editor is causing half of editors to quit editing entirely, or whether users given VE-by-default merely abandon VE to use the Wikitext editor instead, or more likely some mix of both. Regardless, the data is extremely damning.

    Nearly 4 years ago they started work on a mobile-default test. They still have not released any results, however if you dig through the comments of various related tasks it is clear that the results were a disaster for VE. A VE-default on mobile was clearly driving away a significant percentage of edits, and possibly driving away editors. They have been working off-and-on repeatedly shifting the goalposts on that project, trying to get better results. Nearly 4 years, and they still haven't released actual data.

    Important final note: Never believe any claimed "Edit Completion Rate" data. The raw data for VE is so bad that the WMF concocted this specific term and defined it in such a way as to inflate the apparent success of VE. The "Edit Completion Rate" is defined such that every Wikitext-activation that does not result in a saved edit counts as a "failed edit", but a substantial portion of equivalent VE "failed edits" are simply discarded from the dataset and ignored. That artificially inflates the claimed "VE-success" percentage.

    When the VE project was first conceived the WMF internally hyped it as so insanely-awesome that pur biggest problem would be handling the overwhelming flood of new users. The WMF diverted an absolutely excessive percentage of all development time&dollars on this agenda (VE itself, Flow, replacing the translation-editor, attempting to eliminate our wikitext editor in favor of a wikitext mode inside VE, ongoing work to replace our wikitext engine, and various other work). People's paycheck was literally dependent on producing positive results. It resulted in an almost cult-like level of confirmation bias, internally cheerleading and wildly hyping anything that could remotely be interpreted as positive for VE while all unfavorable information and data vanishes down the Memory hole. Nearly 4 years researching VE-on-mobile and we still don't have any published results. I have asked the WMF to preform equivalent research getting solid data on the effect of a VE-default on desktop, but no-go. The retention graph I posted is the best we've got, and that's ambiguous whether VE actively drives new users away or whether it "merely" drives users to flee to Wikitext instead. Alsee (talk) 12:34, 31 January 2023 (UTC) (Some vote timestamps are out of order due to auto-resolved edit conflict.)

    I don't agree with your assessment of the data shown in the graph. The caption reads, emphasis added: This includes all logged-in users who made an edit at any time, on any wiki, between October 2017 and March 2018, regardless of the number of edits made before the study started. This graph does not show overall retention rates for new accounts. Edits in four editing environments were measured: the 2010 WikiEditor, VisualEditor's visual mode, the MobileFrontEnd wikitext editor, and the MobileFrontEnd visual editor. It excludes all edits using VisualEditor's 2017 wikitext mode, [...] All manual "Undo" actions are counted as "using" the 2010 WikiEditor. Users who used multiple editing environments are counted separately for each editing environment. Therefore, each user can appear up to four times in this graph. If a primary user of VisualEditor uses the undo button frequently, then they are counted as a "retained" user of the 2010 WikiEditor. 0xDeadbeef→∞ (talk to me) 12:44, 31 January 2023 (UTC)
    I agree that the available data isn't exactly the data we need. I said it's the best available data, and that it's pretty damning. The result was disastrous when they tried collecting data for VE-on-mobile. How about we agree that we shouldn't be making such a critical change like this unless-and-until we actually do collect data on what effect changing the desktop default has? I have requested the WMF collect this data, and they declined. I'm all for a formal community request that the WMF do a proper test on this. Alsee (talk) 12:55, 31 January 2023 (UTC)
    "How about we agree that we shouldn't be making such a critical change like this unless-and-until we actually do collect data" If the situation we're complaining about wasn't justified with data, why should a change to it require that justification? Is the current situation (that in effect, new editors get locked into VE or wikitext almost at random) even the result of a consensus? MartinPoulter (talk) 13:13, 31 January 2023 (UTC)
    I just realized - this isn't even a proposal to change the default editor. This is vastly worse. This is actually a proposal to move away from the "remember my last editor". People who actively choose to use the Wikitext editor would get screwed waiting for VE-to-load and then switch to wikitext on EVERY edit, unless/until the locate preference item to fix this. I likely would have quit editing before I discovered there was a way to fix it. Alsee (talk) 13:07, 31 January 2023 (UTC)
    The problem is not for prominent editors like you or me - but for newer editors. Experienced editors have the knowledge and the time to go to their own Preferences (which took less than a minute) but newer editor, in my opinion, will immediately be confused by the text editor and stopped contributing. They don't know that Wikipedia have a very user-friendly UI at VisualEditor. They will think that the only way to edit is through this confusing text editor. ✠ SunDawn ✠ (contact) 15:45, 31 January 2023 (UTC)
  • Support. I'm not sure why, but during a recent edit-a-thon at least one new logged-in editor was unable to use VisualEditor, and it us 5 minutes in Preferences to show both editing tabs. VE is easier for beginners.
    talk
    ) 12:18, 31 January 2023 (UTC)
  • Strong support. This is a solid way to make Wikipedia user-friendly and increase the pool of willing contributors. DFlhb (talk) 12:23, 31 January 2023 (UTC)
  • Strong support. Visual editor is the more friendly option for new editors, so we should enable it by default. 0xDeadbeef→∞ (talk to me) 12:34, 31 January 2023 (UTC)
  • Support Despite some long-term attempts to continue forcing wikitext on new editors, it is extremely clear that VE is the more welcoming and easy to understand editing environment. I use it more often than wikitext when editing articles, and have not once in recent years considered wikitext an improvement when trying to explain how to edit to a new editor. Sam Walton (talk) 12:47, 31 January 2023 (UTC)
  • Strong Support I also have been recently running training events for new editors and am having the same problem that it is very easy for them to get locked into the wikitext editor without realising that the visual editor is an option. Fixing that involves taking them to their preferences and is a speed-bump on the whole training process. That's with in-person training; it's exponentially harder to fix this when training remotely. It shouldn't be so hard for new users to access something which has been created to make the experience easier for them. MartinPoulter (talk) 13:04, 31 January 2023 (UTC)
  • Whoa. Why not give them VA as the editor on their first edit, but "Remember my last editor" as the default? Why force them back to VE even after they have switched to edit with wikitext? If they found the switch once, they will find it in the opposite direction as well if and when they want it.
    Fram (talk
    ) 13:34, 31 January 2023 (UTC)
    I do agree with this. It didn't break "last editor used" but it provided a good interface for new editors. ✠ SunDawn ✠ (contact) 15:55, 31 January 2023 (UTC)
  • Strong oppose: Alsee has articulated this much better than I could've, so there's that, but I'll add extra. Ever wondered why we teach young kids do addition/subtraction when we all have calculators today (smartphone ones included)? The problem with Visual editor is that it is not univerally compatible to all pages, try editing the tables at United States congressional delegations from New York, for example. To edit them, you need advanced knowledge of wikitext. And to gain that advanced knowledge, you need to gain basic knowledge first, which is gained by editing normal prose. And that isn't hard. My first Wikipedia edit was made when I was in 1st grade (≈6 year old) as an IP. I could understand the wikitext logic and implement it to write prose and construct wikilinks. Is the next generation going to be dumber? No one is taught wikitext syntax in schools or colleges, people learnt it as they edited Wikipedia and that has kept the site running smoothly for about two decades. When we default to VE, and people may start using it for basic editing, they fail to acquaint themselves with the wikitext logic, which will hurt them make complicated edits where visual editor fails. Even today, most complicated templates/modules are maintained by a few old guards who familiarised themselves with wikitext/lua, a level of familiarisation which the newer generation of editors has probably not achieved. No one here will be here forever, and newer editors should be encouraged to use wikitext, rather than be served with VE on a silver platter. I know this is a controversial opinion of mine and will probable lose at the end, but I genuinely consider it to be detrimental to the future of the project. —CX Zoom[he/him] (let's talk • {C•X}) 13:48, 31 January 2023 (UTC)
    The way I see it, if editors didn't understand wikitext, that is still fine by me - as long as they are able to edit constructively. In my case, my friend just want to add a single information. Forcing him to "learn" wikitext took time, as he will have to read about how to cite properly in wikitext, find the "location" he wanted to edit in the middle of the jumbled things he didn't understand, and so on. While if he got VE, he could just see it, use the cite button, let Wikipedia handle the citing, and he is finished. There are many other scenario. Someone stumbling into a typo on an article can fix it easily if he use VE, while if he see the complexity of text editor, he may be afraid that he broke something then he did nothing. In short, for most editors, I didn't think the knowledge of text editor is necessary. If they are interesting in doing more for Wikipedia, they will learn that text editor offered more, and learn. But if they just want to fix small mistakes and add small bits of information, that should be fine as well. ✠ SunDawn ✠ (contact) 15:54, 31 January 2023 (UTC)
    This sounds like an argument to import the cite button into the wikitext editor. CMD (talk) 17:54, 31 January 2023 (UTC)
  • Conditional Oppose if this is going to end up breaking the "remember my last editor" option - users should get a consistent experience. — xaosflux Talk 14:50, 31 January 2023 (UTC)
    Let's say we use Fram's input - keep the "remember last editor" while change the default editor for newer editor to VE, would you reconsider your position? My objective is not break the current "remember last editor", but to make VE default for newer editor. ✠ SunDawn ✠ (contact) 15:59, 31 January 2023 (UTC)
    @SunDawn: I marked that as conditional. I haven't created a brand-new account just to test this, but if I recall correctly the the current default is "Ask me what I want to use" with a big pop up box, isn't it? — xaosflux Talk 16:55, 31 January 2023 (UTC)
    Good question. Does anyone know the current default? I assumed it was wikitext. If it's a pop-up box then I'll change to oppose because a choice is better for editors who can handle wikitext and raises awareness of the "real" editor for newbies. Certes (talk) 17:24, 31 January 2023 (UTC)
    The current default for IPs appears to be the wikitext editor covered by a large "Welcome to Wikipedia" banner which has a "Switch to the visual editor" button and a "Start editing" button. If this is also the case for new editors, then Wikipedia:VisualEditor is wrong and this list is misleading or bugged. CMD (talk) 17:58, 31 January 2023 (UTC)
    That's what I recall seeing when making my first logged-in edit on other wikis. If it's also true for enwp, perhaps all we need do is reword the buttons to something more equal like "Edit using Visual Editor" and "Edit as wikitext". One of the buttons is highlighted by default; we may want that to be VE rather than Wikitext. Certes (talk) 18:35, 31 January 2023 (UTC)
    The way I recall it (when assisting someone new editing) is that they are immediately represented by text editor. The "edit" beside the heading is "edit source", and he is immediately taken to to the text editor. I didn't recall him given the option between VE and text editor. Of course, the sure way to know is to create another account to test it by ourselves. ✠ SunDawn ✠ (contact) 04:49, 1 February 2023 (UTC)
    Whether you see one tab or two, and if you see one, which one you see, depends on your prefs settings. Whatamidoing (WMF) (talk) 17:57, 2 February 2023 (UTC)
  • Conditional support, only if editors are prominently offered a simple and persistent way to opt out of VE. Certes (talk) 16:19, 31 January 2023 (UTC) It's complicated: see my comment above. Certes (talk) 18:38, 31 January 2023 (UTC)
  • Comment By adding an obscuring layer which is obscure itself, I suspect that visual editor does more harm than good for about 90% of editors. But it might be a good default for the 10% which is those who are just starting.North8000 (talk) 17:58, 31 January 2023 (UTC)
  • Strong oppose. Even on fast machines, the visual editor has a very perceptible lag. If you want to encourage people to continue editing, that is going to be a negative. --Trovatore (talk) 18:01, 31 January 2023 (UTC)
    @Trovatore I've not seen any "very perceptible lag" with VE recently on my machines - when do you experience it? Sam Walton (talk) 18:18, 31 January 2023 (UTC)
    To be fair, I'm probably thinking of "realtime preview". But it would be surprising if VE were less laggy than that. Is it? --Trovatore (talk) 18:23, 31 January 2023 (UTC)
    @Trovatore Realtime preview is a niche feature that new editors probably won't use, and it has to be laggy by design, as I understand it. Rendering wikitext into a preview takes time so it can't happen instantly. There needs to be some delay between the preview updates. VE itself, in terms of actually editing articles, is almost completely lag-free for me. Sam Walton (talk) 18:32, 31 January 2023 (UTC)
    OK, withdrawn. It looks like I misunderstood the proposal anyway. --Trovatore (talk) 19:57, 31 January 2023 (UTC)
  • Generally support - But this thread is already a bit confusing. It would help to revise the top part to state clearly what the current situation is and what specifically would change. VE is already the default for new users AFAIK, as it should be. As I understand it, this would address a specific issue: people switching to the wikicode editor and not understanding how to get back. If my understanding is correct, I definitely support it. Alternatively, we could replace the unclear toggle button that nobody ever thinks to click with a bright line that says "GET ME BACK TO VISUAL EDITING MODE" unless you disable that in prefs. My engagement with new users has largely been through edit-a-thons and university classes. When I started with those activities, wikicode was still the standard. VE existed, but wasn't very good yet, and I had everyone working in wikicode. It was fine, and I still use wikicode most of the time. At some point some years back, though, VE got good. Using VE during events/classes was -- and I don't like using this term -- a game-changer. It presented a learning curve that took time to get over, and people used to just run away from editing and/or never really got comfortable. Using VE means newbies can get right into editing and spent their learning time focused on things like wikipolicy, citations, style, etc. rather than syntax. Sure, we still talk about wikicode for talk pages, but with the reply tool, even that's less needed. In short, moving newbies away from wikicode has been an incredible boon for new user engagement in my experience, and now one of the most frequent questions I get is "I think I did something wrong; how do I get back to what we used before" when people accidentally find themselves in the wikicode editor. — Rhododendrites talk \\ 18:02, 31 January 2023 (UTC)
    Last I checked, when an IP makes their first edit, they are taken to the source editor and then get a dialog box asking if they want to switch to the visual editor. Has this changed? —pythoncoder (talk | contribs) 18:00, 1 February 2023 (UTC)
. Comment I would support a far clearer way of switching between the two. When I first started I found VE couldn't do what I was try to do, switch to wikicode and never looked back. However a couple of times I mistakenly switched back to VE, and had to spend 10 minutes trying to work out how to switch back. Hiding the option behind a very unclear toggle is bad UI design. Having a large "back to VE" would be a bad idea, as any IP editor using wikicode wouldn't be able to get rid of it using preferences. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:36, 31 January 2023 (UTC)
I'm slightly unsure about what's being discussed here. As far as I'm aware VE is the default, yet editors are supporting making it the default. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 16:52, 1 February 2023 (UTC)
  • Support making VisualEditor default. Now that it works well and reliably I tend to use it over source editing unless I'm adding an infobox template or something like that, an activity that new editors are unlikely to be doing. VisualEditor is much more accessible and is capable of performing most edits nowadays. There's quite a few tables across wikipedia that should be altered to make them easier to edit with VisualEditor.Garuda3 (talk) 22:27, 31 January 2023 (UTC)
  • Oppose When you start users on the VE as the default, they will basically never learn to edit the source in proper wikitext. I'd rather have users who come in and get familiar with wikimarkup from the get-go, and then once they get some experience, they can later decide to activate the VE. I'd rather not create a breed of new editors who don't know how to manually add a template or an infobox or troubleshoot a badly formatted table, or whatever. There's value in learning to work in the markup, and if we start people on the VE, we basically create an artificial barrier to advancement in Wikipedia to true competence, which is likely to be as, if not more, frustrating than learning to write in wikimarkup from the start. --Jayron32 16:31, 2 February 2023 (UTC)
  • Oppose until VE is significantly improved. You almost need to have a better understanding of wikitext for using VE than for SE if you want to avoid breaking links and removing semantic templates. Syntax highlighting should definitely be made default though, as without it reference and template bloat can get in the way of the content of the article. – small jars tc 10:47, 5 February 2023 (UTC)
  • Support. I don't believe that markup is inherently off-putting to 'ordinary users'. It wasn't ten years ago when BBCode was everywhere and it isn't now when Markdown is everywhere. But wikitext was never the cleanest markup language to begin with and now that the average article starts with a wall of templates and long embedded references, it clearly is off-putting. This isn't 2013: VisualEditor works fine, offers a kind of distraction-free writing interface that lets you focus on prose, makes it easier to add and format references, and if they find its limits new users can easily switch to source editing. It would be nice to have some hard (and up to date) data on how the switch might impact editor retention before making a permanent change, though. – Joe (talk) 16:38, 5 February 2023 (UTC)
    I sorta see your point, and I remember ten years ago BBCode was used on forums etc, but even those have some technical barrier. On sites used by 'very ordinary users' like Facebook, I think there were still WYSIWYG editors. I use Markdown on sites like GitHub but on 'normal sites' not geared at technically proficient people I don't recall using Markdown or any other language, it's usually either plaintext editors with no syntax support, or WYSIWYG editors. (with the caveat that my memory might be selectively omitting normal sites using BBCode/markdown!) ProcrastinatingReader (talk) 12:49, 6 February 2023 (UTC)
    on 'normal sites' not geared at technically proficient people I don't recall using Markdown or any other language – I don't share this experience. I thought the asterisks and underscores used in youtube comments where pretty well known. Discord also has rich text markup and escape codes. They even have little codes for creating emojis in comments on Scratch, a website used mainly by children. [1]. None of this is quite as complex as wikitext, but I don’t think that very ordinary users are yet so dependent on WYSIWYG that the difference is going to be deterring. small jars tc 18:58, 6 February 2023 (UTC)
    I suppose asterisks and underscores are well known, yes. I guess they're in WhatsApp also. Though IME most people do not use them, I think because they aren't aware how they work. I think Discord does target itself at a relatively technical audience, certainly more-so than Wikipedia. ProcrastinatingReader (talk) 11:57, 8 February 2023 (UTC)
  • Strong support - I didn't even realise VE isn't the default for unregistered users. It should be IMO; in 2023 the average user does not want to write wikitext/raw syntax, is not used to doing so (think the avg site a normal person uses), and even techy users who don't use WYSISYG editors tend to use markup languages that are much simpler than wikitext (e.g. Markdown). As for preferences, it'd be ideal if the choice persisted, and maybe that will happen (n.b. the persisting of fixed/full width opening the door on that), but even without that I think it's better to have VE as the default. Even I use VE to write articles, and not the wikitext editors, and I'd consider myself more technically proficient and used to wikitext than the average person. ProcrastinatingReader (talk) 12:49, 6 February 2023 (UTC)
    Can we make showing both editing tabs the default for new editors instead? I don't see any reason that this would harm people, and it would give a nice easy button to choose which editing mode you want to use. — Red-tailed hawk (nest) 00:08, 9 February 2023 (UTC)
    Going back to two edit tabs, one for each editor, is a very reasonable solution. Note that the WMF imposed the change to a single edit tab without consensus or consulting the community. Here's the MWF's announcement. They unilaterally declared that they are going to drop from two edit links to just one. Alsee (talk) 12:05, 10 February 2023 (UTC)
    Well... that's extremely silly of them, especially given that on many other Wikimedia wikis there are two tabs. — Red-tailed hawk (nest) 17:13, 15 February 2023 (UTC)
    Strange. I am editing id.wikipedia today and they have two edit tabs - one for VE and one for wikitext. ✠ SunDawn ✠ (contact) 03:59, 16 February 2023 (UTC)
    @Red-tailed hawk @SunDawn I can explain the mess of wikis with random edit tab configurations. I'll try to keep this shortish. The WMF manager who came up with the single edit tab idea has been pushing an agenda to force everyone into VE. I spotted the single-tab project when he first started work on it. He assured me he wouldn't try to impose a VE-default without asking the community first. He then deployed an effectively stealth VE default - not visible to the existing community. He failed to respond to messages and Notifications in multiple places - for weeks. I had to escalate the issue to the Executive Director, she had to summoned him to answer to me. He claimed it was a "bug" and, to the Executive-director's-face, he assured us he'd fix it. He again disappeared, silently didn't fix it, when pressed later he admitted the "bug" was his plan all along, and declared he would not fix it. ANI ruled it's not uncivil to say a manager "lies" when the charge is supported by evidence. Three wikis rebelled with EnWiki and another Wiki writing hacks to the sitewide javascript to override his code. We came one step short of a second superprotect incident. Instead he relented and those three wikis were changed. He then abandoned the project part way through his attempted global-deployment, leaving the global wikis with randomly differing configurations. Alsee (talk) 05:36, 16 February 2023 (UTC)
    So, if there was never consensus to implement it here, and the code exists for other wikis why not just open an RfC to ask the WMF to add the second tab here? This seems like a relatively simple configuration to enable, and I don't see the phab task getting rejected if an RfC were to close in favor of this—especially at this point in time. — Red-tailed hawk (nest) 05:40, 16 February 2023 (UTC)
    Even better idea that what is suggested here. Why not have the cake and eat it?? Piotr Konieczny aka Prokonsul Piotrus| reply here 15:29, 17 February 2023 (UTC)
  • Strong support - VisualEditor is much much easier to use for casual editing than doing it via wikitext (atleast on Wikipedia, on other projects it is a different discourse). Learning an arcane markup language should not be one of the side-quests to writing an encylopedia. -- Sohom Datta (talk) 00:30, 14 February 2023 (UTC)
  • Strong support with a but. Look, I run educational programs and each year I introduce dozens of newbies (students) to en wiki. And of course they ignore the choice prompt and half of them gets old code and they are unhappy/confused, and I have to manually help them with adjusting their preferences. This should've been the default years ago. However, I think that an even better choice is to give them "both edit tabs", so they can experiment with two modes. That's actually is what I try to get my students to have, interface wise. B/c let's face it, VE is good but editing anything template related is still a mess. (Tables suck in either version). --Piotr Konieczny aka Prokonsul Piotrus| reply here 04:15, 16 February 2023 (UTC)
  • Support There's a lot of bad history with the visual editor, but it has made a lot of strides and is definitely a lot friendlier for a non-technical editor. Galobtter (pingó mió) 08:00, 16 February 2023 (UTC)
  • Support I recently joined Wikipedia (late June) and tbh the visual editor is much better than the text editor. — Preceding unsigned comment added by Roads4117 (talk • contribs) 12:13, 26 February 2023 (UTC)
  • Support but still with the change option, oppose pure change - currently we appear to have wikitext as the default, with a big overlay asking which option people would like. I'd change that to Visual with the overlay. Options beat pure Visual, but this covers people who click out, not knowing which to go for. I don't see any reason this would involve it forgetting last selection, which obviously is more key, but the current system doesn't have any issues with it. Nosebagbear (talk) 23:10, 1 March 2023 (UTC)
  • Give both edit tabs as described in my comments above. This will allow users to decide which editing style that they would like to use, while harming nobody. It's the best of both worlds, and it seems more sensible than trying to address this issue by tweaking the default option. — Red-tailed hawk (nest) 19:43, 3 March 2023 (UTC)
  • Strong support joined Wikipedia in 2014 but immediately stopped because it was just frustrating to learn how to edit. Since visual editor was included I have found it easier to edit and then learn from while actually adding useful content and not to be bothered by formatting refs, tables, etc. It is just easier. I am sure if other new users new about this discussion you will have an avalanche of support. To be honest, it took me a while to understand if this was actually a matter of opinion and not a fact that Virtual editor is just excellent!
    FuzzyMagma (talk) 13:52, 6 March 2023 (UTC)
  • Oppose. While I agree that VE can be more easy to use for new editors, it still isn't ready to be dafault option for them. For example, when adding refs, VE automatically give them names, like ":0", ":1" and so on. And, unknown to new editors, this auto-generated names cause duplicate ref errors, harming verifiability of articles and forcing more experienced editors to clean them up. So, until this and other defiences of VE is fixed, much better option is to make default syntax highlightning, live preview and editing toolbar. a!rado🦈 (C✙T) 13:25, 7 March 2023 (UTC)
    • @Arado Ar 196: What is the context in which the references are duplicated? Do you mean when a reference is already in use with a name that VE doesn't recognize, so it generates a new one? Is the assumption that a new user, if they overcame the learning curve to using the source editor to begin with, would know how to search for and find named references rather than add a new one anyway? Or am I misunderstanding your point? — Rhododendrites talk \\ 16:02, 7 March 2023 (UTC)
      @Rhododendrites: I mean when two different refs have same name (like that:[1][1], same refs with unique names:[2][3]). My assumption is that a new user, learning to add refs with source editor, will also learn to either give them unique names or leave them unnamed. a!rado🦈 (C✙T) 05:14, 8 March 2023 (UTC)
      Source names would presumably help editors who want to edit the same page more than once. A basic source code functionality that sadly never made it to VE. Raised on Phab in 2013, 2015, and 2020, raised on the community wishlist in 2017, 2019, and now 2023. Hope springs eternal. CMD (talk) 05:56, 8 March 2023 (UTC)
      @Arado Ar 196, can you give me some diffs with this happening? The visual editor should never give an new ref the same name as an existing ref. Whatamidoing (WMF) (talk) 20:50, 15 March 2023 (UTC)
      @Whatamidoing (WMF): Yes, in simple conditions (two refs are added in one article), VE will give them different names. Problems start when added named refs are copypasted/transcluded to somewhere else. Look here:
      1. [2]Visual edit, adding new source (1 use, so no name)+re-using source from table (VE adds ref name ":0") - All clear, no errors
      2. [3]Useful table is copypasted to new template - ref still has name ":0"
      3. [4]Visual edit, ref added with content, most likely copied from somewhere, 'cause 1 use but has name - Error occurs, because ref from templated table has same ":0" name
      4. [5] a certain editor removes ref name from template - No more error (even in old revisions, 'cause transcluded template is fixed).
      Pretty easy to fix when you knew where problematic ref name is, but can easily get complicated with multiple transcluded sections, like here:[6][7][8]. And all this would be prevented if VE allowed giving refs unique name when re-using them. Because unique names (like "Merck" or "RadExpMerck" in example above) are much less likely to conflict with ref names in somewhere else. a!rado🦈 (C✙T) 06:57, 16 March 2023 (UTC)
      Thanks, @Arado Ar 196. Diff #3 is almost certainly a copy/paste problem, because the same editor added and re-used that ref three minutes earlier in a different article. If the <ref name=":0"> is directly in the article, the visual editor will renumber it (diff – this was ":0" when I pasted it, but ":3" when it saved). However, if the ref is transcluded from elsewhere (including in an infobox), it can't 'see' the existence of the ref, so the visual editor doesn't know that it needs to re-number it. Whatamidoing (WMF) (talk) 02:33, 17 March 2023 (UTC)
Sources

  1. ^ a b MiG-31 Foxhound. Harrassing Spy Planes for Dummies. Moscow: Mikoyan.{{cite book}}: CS1 maint: numeric names: authors list (link) Cite error: The named reference ":0" was defined multiple times with different content (see the help page).
  2. ^ MiG-31 Foxhound. Harrassing Spy Planes for Dummies. Moscow: Mikoyan.{{cite book}}: CS1 maint: numeric names: authors list (link)
  3. ^ Wiesel 2. "Breaking news: M8 undresses in public to show her Level 1 armour package". Daily Airdrop.{{cite news}}: CS1 maint: numeric names: authors list (link)
  • SupportI have hardly used the text editor and still find it difficult to use "proper" wiki markup which someone seems to argue has to be the one of the text editor. I edit in the visual editor and if anyone disagrees with my wiki markups or sourcing in the visual editor I am sorry and grateful for advice. I believe we could just accept that the vast majority of wikipedia users (editors and readers) aren't programmers and would likely more easily be retained as editors if the visual editor is the default.Paradise Chronicle (talk) 19:25, 19 March 2023 (UTC)
  • Support – the defects of VE are not pressing or bad enough to overrule the absolute intimidation and foreignity that the source editor will doubtlessly present to brand new editors. – Aza24 (talk) 04:42, 22 March 2023 (UTC)

VE default discussion

Ping Femke (alt) DFlhb 0xDeadbeef to consider the WMF's research on this question, that I posted above. You posted while I was writing and digging up the cited info. Alsee (talk) 12:44, 31 January 2023 (UTC)

The WMF research shows correlation, not causation.
Phil Bridger (talk
) 22:47, 31 January 2023 (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.

Request for comment on infobox for Rod Steiger

For those interested, there's currently a RFC asking should the biography of Rod Steiger include an infobox? Thanks! Nemov (talk) 03:45, 21 March 2023 (UTC)

I'm puzzled why this is even a contentious issue. It's like choosing to not use a template or an table. Zaathras (talk) 04:17, 21 March 2023 (UTC)
A quick glance of the revision history reveals evidence of disruptive edit warring by the usual suspects. It seems I'm no longer allowed to name names around here without someone trying to twist it into a personal attack, so I'll leave it at that. Once more progressing to a time-wasting RFC as a knee-jerk reaction further shows the lack of respect people have for
WP:NOTBUREAUCRACY. RadioKAOS / Talk to me, Billy / Transmissions
06:50, 21 March 2023 (UTC)
I'm genuinely curious what should be the next step should be if not a RfC? Those who believe that the infobox would be an improvement have been bold in adding it find that edit reverted immediately by an editor(s) steadfastly opposed to finding consensus in the matter. Like Zaathras I am baffled at the nature of the debate. I would love a better path forward, but this is the way. Nemov (talk) 12:46, 21 March 2023 (UTC)
Not sure why this needs additional attention beyond what the RfC brings. It's contentious because we have no clear rules about when/whether to use infoboxes, so all of the debates come down to personal opinions. "An infobox would be self-evidently good here because they help readers" vs. "infoboxes might be useful sometimes, but not here". It's all just personal preference, stated with various degrees of matter-of-factness. It's basically the same as
WP:CITEVAR, except there aren't a bunch of people going around to articles they've never edited saying "list-defined references are just obviously better, so let's use them here" against the wishes of the people who actually worked on the article. I get both sides of the infobox argument, except for that desire to impose it... It does seem like we're approaching the point where there might be consensus to just use them everywhere, though. — Rhododendrites talk
\\ 17:03, 21 March 2023 (UTC)
Given the community's growing acceptance of infoboxes as a normal part of the Wikipedia UI shouldn't some of the contentiousness be dropped on this topic? If most of the community believes that infoboxes are an improvement to the article why should it be a surprise that new editors are attempting to add infoboxes? Most of the recent RfC are from editors who didn't know anything about the ancient infobox wars. I was certainly blissfully unaware until I saw this popping up in RfCs. The idea that new editors are trying to "impose it" is a little unfair. What I don't understand is the continued opposition to infoboxes despite the fact it appears the community finds them helpful. Nemov (talk) 17:40, 21 March 2023 (UTC)
Given the community's growing acceptance of infoboxes. Anecdotally, it seems that it may be headed that way, but you'll need to actually establish consensus for a change to the rules to act on it. If a dozen people go to many articles to impose an infobox against the wishes of the people who wrote the article, it can certainly look like growing acceptance, or it could just be a smallish number of people on a mission, a smaller number of people objecting to said mission, and a vast majority who just don't care enough to comment. Some of that vast majority would come out for a broader RfC on infoboxes generally, and who knows where they'll land.
The idea that new editors are trying to "impose it" is a little unfair. It looks like you yourself have gone to a whole bunch of articles to try to add an infobox where the primary contributors did not want them. Why is "impose it" unfair? — Rhododendrites talk \\ 17:54, 21 March 2023 (UTC)
If you look at my edit history I have only created one RfC on adding an infobox. That would be this one since I found the article after watching On the Waterfront. I have been involved in several RfC discussions about infoboxes the past 5 months. That's mostly because I'm involved in most RfC discussions that past 5 months. I find the idea that I'm part of some nefarious mission to impose infoboxes an unfair characterization.
My general observation that in most of the infobox discussions the same group of editors almost are always involved in opposing them (which is their right). I can't really say the same about those attempting to add them. It's been a variety of different editors, some new, some old, some having nothing to do with old discussions. I'm reluctant to frame this as us vs. them because many of the editors who have supported the infobox haven't been involved in every discussion. Plus, the group that have opposed are full of great, well meaning, and productive editors. It's simply not in good faith to complain about editor's motivations.
So my question again falls back to a path forward and not trying to dredge up the past. If no path is outlined then we'll see the same pattern. Editors will stonewall the infobox, someone will create an RfC, the community will be alerted, and the infobox will be added. This seems to be like a waste of time for RfC watchers like myself. Nemov (talk) 18:08, 21 March 2023 (UTC)
nefarious mission - I don't think it's nefarious, to be clear. But apart from that I don't really have anything else to add. — Rhododendrites talk \\ 18:44, 21 March 2023 (UTC)
Seconding Rhododendrites point here. Any sort of easily modifiable and replicable idea gets spammed throughout Wikipedia pages. That doesn't indicate a broad community consensus, it indicates that easily made edits are made more often, because they are easy. The more visible the template, the more it happens. I suspect infoboxes would be one of those items that the community does support, but the broader argument doesn't hold. CMD (talk) 01:31, 23 March 2023 (UTC)
Rhododendrites' claims that there's a group of infobox warriors that "go to many articles to impose an infobox against the wishes of the people who wrote the article." That's not been my observation the past five months even if there are a few familiar faces. Also, the claim that I "have gone to a whole bunch of articles to try to add an infobox where the primary contributors did not want them is false. Rhododendrites has commented against inclusion on several infobox discussions but I wouldn't characterize their position as an anti-infobox warrior.
There doesn't seem to be much interest in finding a path forward which is fine. The system appears to be working.
WP:RFC says that RfCs can be brought here so more editors can comment. Inviting more editors to comment is a reasonable way to find consensus. Nemov (talk
) 02:51, 23 March 2023 (UTC)
Yes, keeping in mind the article has had millions of views since 2015 and only a couple of people ever had a problem with no infobox. There have been a number of different names turn up at IB discussions aside from the regulars, I don't know how many are sockpuppets of past ones or are actually genuine. Nemov may be innocent, but overall as with Kubrick it does suspiciously look like a coordinated effort to enforce boxes on promoted articles, taking advantage of the fact that several of the people who once defended against them no longer edit. The example given below is a perfect example of how they are not essential. ♦ Dr. Blofeld 11:52, 23 March 2023 (UTC)
Personal reflection: Someone added an infobox to an article I started, Rupert Frazer. I couldn't be arsed to oppose it, but it just seems unnecessary. Gråbergs Gråa Sång (talk) 09:59, 23 March 2023 (UTC)
That article is a good example of an article that doesn't need an infobox. Nemov (talk) 13:07, 23 March 2023 (UTC)
I disagree. It's a great example of an unnecessary infobox. It takes four lines to show on the right-hand side what we say in one line on the left. It adds only the current age, which I consider a "nice-to-have", but not worth the addition of the ugly little box on the right. — JohnFromPinckney (talk / edits) 14:47, 23 March 2023 (UTC)
I'm generally for infoboxes and believe their a benefit to the reader, but an infobox that has nothing more than the details of the first sentence is pointless. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:42, 23 March 2023 (UTC)
Removing it here make sense, though I think sometimes new editors find it challenging to figure out how to add an Infobox, and so base structure can make it easier for them to then add an image etc.. ~ 🦝 Shushugah (he/him • talk) 22:05, 23 March 2023 (UTC)

Vector Rollback - Closure Review II

A Close Review for the recent RFC on Rollbacking Vector 2022 is currently underway at AN. Soni (talk) 14:57, 28 March 2023 (UTC)

Move protection for
WP:DYK
articles?

In Wikipedia talk:Did you know/Archive 188#Move protection, there was agreement that DYK articles should be move-protected while they're on the front page (and in the queue leading up to that). I put forth a BRFA, at which it was suggested that I open a discussion here to get wider consensus on the need for such protection.

There were also some technical questions which came up at the BRFA, but for this discussion, let's just look at whether the basic concept of move-protection has consensus or not. -- RoySmith (talk) 18:11, 8 March 2023 (UTC)

Date diff area
8 Mar 2023 [9] ITN
22 Feb 2023 [10] DYK
22 Jan 2023 [11] OTD
3 Jan 2023 [12] ITN
28 Dec 2022 [13] DYK
27 Oct 2022 [14] OTD
13 Oct 2022 [15] ITN
7 Oct 2022 [16] ITN
8 Sep 2022 [17] OTD
17 Aug 2022 [18] ITN
21 Jul 2022 [19] DYK
13 Jul 2022 [20] DYK
28 Jun 2022 [21] OTD
28 Jun 2022 [22] ITN
27 Jun 2022 [23] ITN
30 May 2022 [24] OTD
13 May 2022 [25] ITN
14 Mar 2022 [26] OTD
8 Mar 2022 [27] POTD
24 Jan 2022 [28] DYK

Disambig icon as default thumbnail

Tracked in Phabricator
Task T332756
Related articles on Wikipedia mobile version 2023 screengrab screen capture; if my proposal were implemented the top image slot would now have show the disambiguation trident graphic

I propose that {by use of magic I don't personally understand} the disambiguation icon be set as a default thumbnail image for all disambiguation pages to improve navigation clarity for users.

Disambig gray icon, any color would do

jengod (talk) 19:49, 19 March 2023 (UTC)

Good idea, if possible. Traditionally we use red and blue but the colour isn't important. Certes (talk) 21:17, 19 March 2023 (UTC)
I believe that's a question for the Web team, so pinging @SGrabarczuk (WMF). The next step is probably filing a Phab: ticket for it. Whatamidoing (WMF) (talk) 02:36, 20 March 2023 (UTC)
Would this apply to search results and the search preview in v22 and menerva, as well as to releated articles? small jars tc 22:17, 20 March 2023 (UTC)
I don't know what v22 and merneva are but it would be great if this also registered in search results. jengod (talk) 01:41, 29 March 2023 (UTC)
Hey @Jengod. I'd like to ask what you mean by a "thumbnail" here. Are you suggesting that the disambig icon should be shown in search preview and search results? Could you repeat your proposal using a description/a list instead of the word thumbnail? SGrabarczuk (WMF) (talk) 13:55, 21 March 2023 (UTC)
I think this concerns the page image (mw:Extension:PageImages). Such icons are usually excluded from becoming page images, that could indeed be changed for disambiguation pages. XanonymusX (talk) 14:36, 21 March 2023 (UTC)
If this is possible, I would definitely support this. Looks better than the default grey page and I don't see any reason why it should be opposed. Adds a pop of colour to the previews and looks almost Underground-ish. Assuming that, of course, it can be done. Tim O'Doherty (talk) 23:05, 21 March 2023 (UTC)
Would support as well if technically possible. A good, solid idea. Aza24 (talk) 00:05, 22 March 2023 (UTC)
I've created a Phabricator ticket, but I'd like to encourage you to add comments focusing on the following:
  1. describe the actual underlying problem which you want to solve. Do not describe only a solution
  2. what exactly you would like to be able to do and where exactly
  3. why should this be implemented
This will help to prioritize the task, understand the scope, and check whether it's really done. Thanks! SGrabarczuk (WMF) (talk) 02:52, 22 March 2023 (UTC)
Sorry I'm late replying to this:
1. I'm a mobile-only user (and editor) and one of my wiki hobbies is keeping an eye on what's surfaced by those three "related articles" boxes that appear at the bottom of pages. When you're roaming the site that way, it becomes really obvious that every article is improved by a default image (must placed above the TOC on article page to appear) and a <40 characters short description. Very important guideposts. Anyway, disambiguation pages often show up as a visual dead zone with an off-putting minimum of information.
2 I would like the default page image for disambiguation pages (some of which are quite dense and informative in their own right cf Point (disambiguation)) to appear less like voids and more like wayfinding tools. My proposal is that the red-blue sideways disambiguation trident symbol Commons:File:Disambig.svg be the default image for all disambiguation pages that don't have an existing image (which they mostly shouldn't have but I bet there are exceptions).
3. This should be implemented to improve the user experience.
Cheers jengod (talk) 01:39, 29 March 2023 (UTC)
Thanks, I've copied your comments on Phabricator. This seems to have a fair amount of support!
talk
) 03:34, 29 March 2023 (UTC)
120px icon
mw:Extension:Disambiguator makes the magic word __DISAMBIG__ to mark disambiguation pages so MediaWiki can identify them. We add __DISAMBIG__ in {{Dmbox}} which is used by disambiguation templates. The page image displayed in searches and elsewhere is selected by mw:Extension:PageImages. We have both extensions so the suggestion can be implemented if PageImages automatically selects a certain image for marked disambiguation pages. I like it and suggest the image can be set by a wiki in a new MediaWiki message like MediaWiki:Disambig page image. I don't know how various other wikis handle disambiguation pages but I think the message should be blank by default, probably also in Wikimedia wikis. Here we could choose Disambig.svg for File:Disambig.svg.
mw:Extension:PageImages can currently only select an image which is in the lead and at least 120px. We could implement it locally without a change in the extension if we display a 120px icon on disambiguation pages but I don't like that. We could probably trick the extension by using code which technically places the image in the lead but hides it from viewers in practice. We would need an additional template on disambiguation pages because they often have sections, and existing disambiguation templates are placed at the end. It's also an ugly hack I dislike. The "hidden" image might be displayed in some circumstances or cause confusion when some features claim it's there but users cannot see it. A change in the extension would be much cleaner. I suggest we wait to see if the developers will implement it before we consider a local hack. PrimeHunter (talk) 03:34, 23 March 2023 (UTC)
Some disambiguation pages do currently have a page image taken from the lead, e.g. Macedonia and William and Mary. It usually only represents some of the entries. I'm fine with always replacing it with a disambiguation icon. PrimeHunter (talk) 03:47, 23 March 2023 (UTC)
I'd suggest only replacing it with a disambiguation icon when there is no existing image available.
talk
) 23:50, 23 March 2023 (UTC)
This feature already exists in VisualEditor. If you click the chain icon to add a link and write example then the option Example shows a disambiguation icon as page image. mw:Extension:Disambiguator#Features says: "If VisualEditor is enabled, shows whether a page is a disambiguation page or not in the link dialog". PrimeHunter (talk) 04:07, 23 March 2023 (UTC)

alt= text for images

Example diff Special:Diff/1145970784/1145978283

Why not have the alt text in the image page, it can then be copied by bot into citations. If editors want to change the alt text they can on a per-cite basis as normal. This at least creates a base alt text. -- GreenC 02:37, 22 March 2023 (UTC)

@GreenC, I understand that the immediate problem is that there is no place to store it. c:Help:Alternative text has links to the relevant prior discussions. Whatamidoing (WMF) (talk) 00:57, 23 March 2023 (UTC)
Moreover, if the image is on Commons, as most images used in the English Wikipedia are, then it would be presumptuous to store the alt text there. Images on Commons can be used in any Wikipedia, and there is no reason why one language should be privileged as the alt text for such an image. Donald Albury 01:33, 23 March 2023 (UTC)
Commons is multilingual. It's supposed to have all text content in each language. Alt-text would be no exception. – SD0001 (talk) 16:57, 25 March 2023 (UTC)
Well, there are currently 321 active language Wikipedias. That would be an awful lot of data to add, even if you had enough speakers of each language who were willing to add descriptions to the more than 91,000,000 media files on Commons. You are offered the chance to enter descriptions in more than one language when you upload a file, but even for the (admittedlt few) images I checked that are used on half-a-dozen or more different language WPs, I didn't see anything other than English descriptions. Donald Albury 18:31, 25 March 2023 (UTC)
It'd be less data than's already stored for the pictures (60 bytes in 321 languages is about 20 KB; a typical modern digital photo could be 100–1000 times that size). Wikipedia:Don't worry about performance (though if you're planning to add millions yourself, then let's maybe give Ops a heads-up first). Whatamidoing (WMF) (talk) 00:05, 29 March 2023 (UTC)
Oh, I'm not worried about the data storage space. I was thinking of the volunteer-hours involved in adding individualized alt-texts to millions of images. Donald Albury 00:40, 29 March 2023 (UTC)
Every image *needs* alt text. See
talk
) 03:36, 29 March 2023 (UTC)
As far as I know, WAID is right on the technical issue, and I agree with DA on the Commons presumptuousness issue. Even if we could bypass both those issues, an images alt text should be determined based on its use in the article. For example, there's an image of Elizabeth II in the infobox at Purple, and the same image is used at multiple articles about the monarchies of various countries. The alt text at Purple should mention that she is wearing a purple hat, while the others do not need that detail. Firefangledfeathers (talk / contribs) 01:41, 23 March 2023 (UTC)
Commons holds descriptions for each language, I do not think it would be difficult to hold a default alt-text for each language too. CMD (talk) 02:40, 23 March 2023 (UTC)
Exactly. If editors want to modify the default text, simply add |alt= to the citation as would be done anyway (when there is no default text). At least there is a default text starting point, which in many if not most cases would be sufficient, and save a lot of duplication of effort. It would also benefit increasing the number of citations with alt text. -- GreenC 00:07, 24 March 2023 (UTC)
Inside VisualEditor (visual editing or its wikitext mode), if basic alt text were stored on Commons, then it could be imported into the dialog and stored locally. Whatamidoing (WMF) (talk) 19:31, 24 March 2023 (UTC)
I agree with Firefangledfeathers, particularly about the context issue - alt text is there to give provide the context and encyclopedic relevance of the image that readers who can see it get from the image itself. That context and relevance depends on the reason why it is being used in the given article. At
Governor General of Papua New Guinea and most other articles it need only say who it is a picture of, although at List of state leaders by age her age in the photograph would probably also be relevant information. Thryduulf (talk
) 15:29, 23 March 2023 (UTC)
Xeno's proposal notes that context can be an issue; he suggests that default alt text would be able to be overridden for specific uses in pages.
talk
) 23:41, 23 March 2023 (UTC)
Without alt text stored on Commons, this is "Stamp Canada 4C".
I don't think we should presume that Commons doesn't want this for itself. Simple descriptions of Commons' images could be helpful for Commons. Otherwise, the alt text is the filename, which can be incomplete (how about "cancelled purple Canadian stamp showing Queen Elizabeth"?), misleading ("4C" isn't the same as "4¢"), or incomprehensible (automatically assigned numbers that say little or nothing about the contents, such as File:004 2022 04 15 Ei.jpg). Whatamidoing (WMF) (talk) 19:44, 24 March 2023 (UTC)
It's probably possible to implement this via structured data.
talk
) 23:38, 23 March 2023 (UTC)
Most images I've seen are only used in one (or just a handful of) articles. Is the added burden of needing to go on Commons to change alt-texts worth the benefit, for that presumably small number of images that are used in many articles? DFlhb (talk) 00:39, 24 March 2023 (UTC)
I challenge the notion that most images are only used once or twice - this is very clearly not the case.
talk
) 00:54, 24 March 2023 (UTC)
There are (as of a few minutes ago) 6,468,023 different images used in mainspace. 5,076,097 are used on just one article. 826,773 are used on two articles. 565,153 are used on three or more. This count includes flags, icons, and other decorative or navigational images included by wikitext, but not images used only via CSS. The most-used image is File:OOjs UI icon edit-ltr-progressive.svg at 1,473,481 uses. Anomie⚔ 11:38, 24 March 2023 (UTC)
My initial claim was incorrect, however, 826,773 images on two articles and 565,153 on 3+ is not insignificant. Even for images only used on two articles, a centralized default alt text stored on Commons would auto-update with changes, removing the burden for editors of alt text to also edit the text on more than one page.
As well, quoting
talk
) 01:29, 25 March 2023 (UTC)
What is very clearly the case is that most of the images on Commons (today "91,601,939 freely usable media files", ok not all images) are not used at all, and never will be. Johnbod (talk) 19:52, 24 March 2023 (UTC)
An ideal implementation is that writing alt= here would overwrite the commons alt-text with no need to exit your edit window. CMD (talk) 01:24, 25 March 2023 (UTC)
So.. I've always thought this was an interesting idea, but that any sort of implementation has too many restrictions to be of true use. Like stated before by ppl in this discussion:
  • alt are language specific so cannot be reused across languages.
  • sister projects are unlikely to provide them (they are busy enough trying to stay alive)
  • Commons has more images not in use, than in use
  • Neither Wikidata nor Commons are trusted by Wikipedians
  • It doesn't help writing initial alt descriptions, so only helps with multiple usages of of the same image.
  • Alt is context specific so even for images that are used multiple times, it's likely not always going to suffice
So the majority of alt descriptions are likely to be written by each of the wikipedias.... Which means that like 95+ % of the the alt text is basically coming from the same place and the same people, Wikipedians, they would just have to move where they store/get them from.
Taking in all of these limitations and edge cases, made me think. What if someone were to make a bot that takes the alt of an image usage, which then copies it to the alt tag of other local uses of the thumbnail where no alt is provided ? Wouldn't that solve almost the exact same problem, without all the increased complexity of which the return on investment is very dubious ? If the results of such bot edits are uncontroversial, then it gives much more credence to this proposal. —TheDJ (talk • contribs) 09:52, 29 March 2023 (UTC)

Link to the Wikidata item in the language scrollbar

It would be helpful to add to the WP articles a direct wlink to the Wikidata item (with the related number).

You can add it to the language scrollbar that is present in the left side at the top of the WP articles (in the mobile view).

Before the last restyling of WP articles, the Wikidata item could be accessed from a direct link whose title in Italiano was "Modifica collegamenti".

The new version of the WP articles shall provider the same feature. Otherwise, without a direct link, the risk is that new or translate articles aren't connected to interwiki-Wikidata. 151.82.234.22 (talk) 21:02, 30 March 2023 (UTC)

quite happy to NOT have things connected Wikidata. Just saying. Blueboar (talk) 21:32, 30 March 2023 (UTC)
Virtually all language interlinks are served by Wikidata though. ~ 🦝 Shushugah (he/him • talk) 23:03, 30 March 2023 (UTC)
Yes, and that use is among the least controversial of its uses. * Pppery * it has begun... 23:05, 30 March 2023 (UTC)
Unfortunately, true. Blueboar (talk) 00:09, 31 March 2023 (UTC)
It is still there under the new "Tools" tab - the Tools section that used to be in the left margin is now under a tab. StarryGrandma (talk) 22:55, 30 March 2023 (UTC)
There is also a keybinding, which is ALT-Shift-G. Curbon7 (talk) 02:11, 31 March 2023 (UTC)

Donations for Wikipedia editors

Preface: I want to address administrators, bureaucrats, and other contributors to Wikipedia. I am not advertising anything in this message, it is just important for me to try to improve the project, to attract participants, to improve conditions for editors.

"Hello everyone. I would like to address all members of Wikipedia. It's good to see everyone in this project. I believe that each of you love Wikipedia and like to spend as much time in it as you want, because doing what you love can be endless. However, you would hardly refuse financial support, a kind of "tip" for working in your favorite project. I joined the project about 5 years ago myself, and over the years I have noticed several things: once successful and energetic participants leave Wikipedia: sometimes because of burnout and other reasons, but in most cases it is due to the need to plan their lives, and not everyone has the strength, resources, time, or desire to stay. Sometimes the desire is there, but the opportunity is simply not there. This is just the tip of the iceberg. I love people who are willing to help pro bono, but I want those people to get feedback. I think editors also want "tips."

I appeal to the Wikimedia Foundation and its staff: add the ability to donate financially to Wikipedia editors. Henry Ford used to pay employees for their vacations - and they worked much more efficiently. There's just one important point - donations need to be added in all language sections. Why can YouTube, Ticktock bloggers get donations from fans of their work and creativity, but not less talented Wikipedia contributors can't? All you need to do is add another button next to the "Thank you" button (the participant for the edit) - "Donate" to the participant for the edit. If you want to support me, speak up below, I've also created a Change.org petition that you can sign and help distribute (https://chng.it/CKYRQK4G). Love you all. Have a nice day.

P.S. - used the translator, sorry for any inconvenience. Алексей Старовойтов (talk) 21:43, 17 February 2023 (UTC)

As a Wikipedia editor, I don't want readers to swell my personal bank account. What I would love is for them to have a way to donate to Wikipedia – to have their money used to fund projects editors vote for, such as addressing the huge backlog of MediaWiki bugs and enhancement requests, rather than disappear into a general WMF fund which sponsors a Ruritanian equality workshop or creates another post for an ethical diversity advisor. Certes (talk) 21:56, 17 February 2023 (UTC)
I'm afraid I may have been misunderstood, so I'll correct myself a bit. I was not referring to replacing donations to the Foundation with donations to participants. It is necessary to have both. If any participant doesn't need the funds, they can redirect them to the Wikimedia Foundation. Алексей Старовойтов (talk) 22:14, 17 February 2023 (UTC)
What you are saying is that you want the Foundation to employ editors, paid for by donations. Even if that's a good idea, it would be a logistical nightmare to set up(which would also be costly) and likely there would be privacy issues. 331dot (talk) 22:30, 17 February 2023 (UTC)
Whatever the merits of the proposal or lack thereof, providing a micropayment system for users to contribute to individual editors would not necessarily constitute employing paid editors, but would simply create an incentive for editors to make more and higher quality edits. It’s not a bad idea. Not everyone can afford to donate their time pro bono, and even a slight deferment to offset the loss of time and effort may make enough of a difference to increase the number and diversity of editors, which I do see as a significant problem impacting the quality of the wiki and its perception in the broader community. Nathan McKnight -- Aelffin (talk) 09:09, 17 March 2023 (UTC)
I'd support having a system that provided some relevant material reward to highly productive editors (counting myself in that cohort). I would guess that many of us who provide value to the project could benefit from upgrades to the equipment we use to edit, and access to sources beyond those available through the Wikipedia Library. I personally have in the past purchased reference works useful to the improvement of specific sets of articles, and have worn out several computer mouses fixing large tranches of disambiguation links (I think New York alone took about 70,000 mouse clicks). BD2412 T 23:15, 17 February 2023 (UTC)
How would you define 'highly productive'? Judging by the number of high-edit-count contributors who have found themselves sanctioned or blocked/banned by the project in recent years, I'd have to suggest that a raw edit count would be a highly inappropriate metric, and I can't think of any alternative off the top of my head that wouldn't be inherently subjective. AndyTheGrump (talk) 23:28, 17 February 2023 (UTC)
Raw edit count isn't irrelevant though. I would also look at contribution to GAs/FAs (an area in which I am admittedly somewhat lacking), DYKs, creation and expansion of non-stub new articles. Certainly I would put the burden on anyone seeking support to show their work beyond merely "I have a high edit count", but we can set up smart enough measures of evidence. BD2412 T 04:55, 18 February 2023 (UTC)
Blocking results from bad edits, and someone with a million edits has probably made more bad choices than someone with a hundred. However, despite the occasional error, they've also added vastly more net value to Wikipedia. That's the important metric and, although it can be hard to measure, it seems strongly correlated with edit count. Certes (talk) 11:53, 18 February 2023 (UTC)
Given the number of editors blocked, banned, or sanctioned in the top end of
WP:EDITS, I think you could reasonably argue that edit count is a piss-poor metric of quality or value-added to Wikipedia. It's easy to generate thousands of edits doing basically nothing if you want. Der Wohltemperierte Fuchs talk
20:16, 27 March 2023 (UTC)
I'd like to echo a few things raised by other editors: 1) for obvious reasons, it might be wise if WMF was attempting to help LT contributors maintain appropriate equipment, connection, and data security, 2) purely to assist with our costs of volunteering, it would be useful for a wider array of library-like local sources like current newspapers be made available by Foundation allies, 3) the WMF might consider a wider program of grants and scholarships towards improving and encouraging the volunteer pool. My highest priority is the sustainability and survival of the program, and substantial foundation liquidity is essential to protect the mission. We also need to see Internet Archive well managed and liquid. I've raised my concerns below, but I believe opening this floodgate could be a pandora's box for Wikipedia. BusterD (talk) 17:04, 18 February 2023 (UTC)
Oppose. Money, even small amounts of money, attracts bad actors and system-gamers. No issue with individual editors putting donation links on their user pages though. Barnards.tar.gz (talk) 20:26, 21 February 2023 (UTC)
Oppose. Money paid to editor's would make Wikipedia violate its non profit status.
It also makes it impartial. (User: Godai Yūsaku)
We have a stop-gap half-measure, which are grants. Some of them are small. Pl wiki offers mini grants/reimbursements for stuff like buying a book or even a camera (for folks who upload photos). See meta:Grants for a start. Note that I personally think micro grants are good but I have serious concerns about abuse in large grants (TL;DR, I fear some larger grantees are inflating costs to profit while producing next to no benefit for us). But, to reiterate, I think small grants, refunding books, library access, etc. are a good thing to pursue. --Piotr Konieczny aka Prokonsul Piotrus| reply here 04:04, 18 February 2023 (UTC)
Having carefully studied all the arguments, I propose possible solutions to these issues:
  1. I mean to add the ability to donate to regular editors, but not to remove the ability to donate to the Foundation. In my opinion, donations to participants will not interfere with donations to the Foundation itself. That is, readers will have a choice: to send money to the Fund or any editor, whose contribution they like. An important point: I propose that it is not the Foundation that gives donations to participants, but the readers of the project (although I do not exclude the help of the Foundation, if necessary). If some of the participants do not want to receive donations - we need to add a function that allows to refuse donations. If anyone doesn't want donations and thinks the Foundation needs the money more, we need to add a feature that allows the editor to redirect the donations to the Foundation. If some participants have money, they will have the opportunity to spend it on technical means (equipment, literature, media subscriptions, etc.) and therefore the Foundation will no longer have to spend money on grants to participants, but concentrate its attention and finances on more global and important issues. If anyone is intimidated by large amounts of donations or by turning Wikipedia into a place where many people will want to make money or will want to use donations as a payment system, it is reasonable to put a limit on the maximum amount of donations that can be sent to the editor per payment, for example about $1-$10.
  2. If by confidentiality problem you mean payment data of participants, this problem is solvable too, for example on YouTube, when you sponsor authors, you don't see their payment data, a good example.
  3. How do I know which authors should be allowed to accept donations and which should not? After all, there are authors who are detrimental and not very competent. For example, you could make it so that authors can only receive donations if they have been on the project long enough (although this measure would not solve the problem). Or it would be a special page where editors could apply for permission to accept donations. Or the ability to accept donations would be assigned at the same time as flags (e.g. "Patroller", "Administrator", "Bureaucrat"). Since these flags are not just assigned, nor are they assigned to everyone they meet, this could solve the problem.
  4. As for grants, I've already made my point, if readers can donate to participants, then participants can cover equipment costs themselves, and the Foundation would not have to spend its own money on such programs, or at least it would at least reduce the Foundation's costs for these items. And besides, my proposed donations should, in my idea, increase the number of editors who can receive financial support, since the Foundation cannot satisfy absolutely all participants with grants. Алексей Старовойтов (talk) 07:11, 18 February 2023 (UTC)
    The suggestions above are a roadmap to Wikipedia's social irrelevance, but I'm glad somebody said it. BusterD (talk) 07:33, 18 February 2023 (UTC)
  • This is scary material for discussion. I'd be interested in links to previous discussions on this inevitable subject. In the hypothetical, a request for "donations" reminds me of the run of '89 (without insult all to disenfranchised First Nations people, of course, but with all of the unintended consequences). I can't be the only wikipedian who has a view of how the pedia might one day die. I'm going to take a liberty to describe my thoughts. The WMF seems to be applying pressure on editors to subscribe to a UCC as volunteers, not paid employees. As a sysop, I feel strongly I'm here by and for the community, not the foundation. From another view, many longtime regular contributors perform important work without which an online encyclopedia truly still in infancy might not survive, and many of those editors are senior human beings who could utilize the stipend. What is true is that none of us will last forever, some of us may be corrupted or co-opted (by money or pressure), and as Larry Lessig once said in a Wikimania keynote, text is becoming the new Latin. My grandchild is no longer taught to read my handwriting. It is an amazing time, and how the world's largest online experiment for getting along reacts to these forces will make for a social experiment worthy of Hari Seldon. The foundation wants to give admins, functionaries and twenty-year contributors a stipend, that's one thing. Creating a way to donate to individual editors may turn us all into paid editors, and transform Wikipedia into Twitter or Facebook, neither fully functional nor socially relevant. BusterD (talk) 07:31, 18 February 2023 (UTC)
    Adding a paypal me link for editors down the side of talk pages wouldn't be technically difficult if people were willing to give their email addresses and source for payment, but very few of our readers check the history of an article, and given the collaborative nature of the project singling out one editor for writing something can be difficult, particularly on core topics. I think you'd find next to nobody would send editors money individually and it would be a waste of time. ♦ Dr. Blofeld 17:25, 18 February 2023 (UTC)
    Considering the proliferation of UPE the last few years, I'm sure there are dozens of reputation protection and pr firms who'd love to legally pay editors for popular contributions. Am I the only person to see this? The "how" isn't relevant before the "if" or "why." BusterD (talk) 18:18, 18 February 2023 (UTC)
    No. you're not the only person to see that this is an incredibly bad idea. I can just imagine an editor saying in a discussion about what to include, "but five people paid me for this edit". No, just no.
    Phil Bridger (talk
    ) 18:41, 18 February 2023 (UTC)
    Yes, I just wanted to add the rebuttal of - this would encourage both functional paid editing "do editing in this area, where your odds of working on content that aids my business is higher" as well as irrevocably breaking our reputation for such. If the WMF wants to directly handle acquisition of sources and such, perhaps through the Wikimedia Library, that's always good.
    But tips? No thanks. Nosebagbear (talk) 09:48, 20 February 2023 (UTC)
  • I found a quarter once at a Wikipedia conference. My new pay grade. But I do wish the Foundation greatly funded full conferences, offered room and board to editors traveling to cover a topic (when one editor, okay, I'll name him, Another Believer, goes into a city he photographs and writes articles for most of the statues in that city - a wonderful use of travel time. I say fund a few trips for editors who have shown their proficiency on things like this). And, yes, full funding of events and participants in a gala VivaWikiVegas for a North American Conference, well-earned party and meet-up occasion using Foundation money saved during the covid years. The Foundation really should be funding more Wikipedia editors and projects, to the tune of 10-20 million a year for a few years. Randy Kryn (talk) 13:36, 20 February 2023 (UTC)
  • If editors could be paid for edits then some of them would abuse it. For example, delete a large part of an article with an alternative account and restore it while claiming credit. Or make an unattributed copy to another article. Or make edits you think are popular with somebody willing and able to pay, e.g. removing negative well-sourced material about a company. Imagine articles where it becomes known or just rumored that certain types of edits are likely to get paid. I think there would be too few donors who are both willing to pay and properly judge who actually deserves pay for improving Wikipedia. "What is the chance somebody will pay for this?" should not be a thought when you make an edit. PrimeHunter (talk) 16:54, 20 February 2023 (UTC)
  • Strong oppose as it's open to abuse. We already have Wikimedia editathons with prizes that just encourage users to make tons of poor quality edits rather than helping the encyclopedia (e.g. an annual spam as many poor quality pictures into article challenge). Don't see how paying people to do more edits would have an actual benefit to the encyclopedia, as it would change motivation of some editors from being useful to doing as much small junk things as they can to make money. Joseph2302 (talk) 17:01, 20 February 2023 (UTC)
  • I would support the WMF hiring people or otherwise subsidizing them to edit and/or mediate neutrally on contentious topics, subject to extensive oversight by the community itself. But I think that the model proposed here of donating directly to editors in a decentralized fashion is unlikely to work for the various reasons identified by other editors above. signed, Rosguill talk 17:54, 20 February 2023 (UTC)
    +1 Levivich (talk) 01:29, 21 February 2023 (UTC)
  • NO! This is an amazingly and stupendously bad idea. Just say no. Regards, GenQuest "scribble" 00:52, 22 February 2023 (UTC)
  • If so many people can come together and contribute to a shared goal, then is paid editing ever needed? I think not. As others have said, I believe it will lead to people joining for the money, rather than joining for what we are truly here for: to create a free encyclopedia. Anything that could detract from that ultimate goal is a bad idea. Schminnte (talk • contribs) 02:53, 22 February 2023 (UTC)
  • If people want to donate in support of the project, but don't want to donate to the Foundation, then donate to the Internet Archive or any other project that provides free access to reliable sources. I just "checked out" a book for an hour from the Internet Archive yesterday to use as a source in an article I'm working on. I also use the Wayback Machine a lot, and periodically contribute to the Internet Archive. - Donald Albury 13:34, 22 February 2023 (UTC)
  • Strong oppose Just no. Too easy to abuse. -Kj cheetham (talk) 23:34, 22 February 2023 (UTC)
  • Confession I've actually been soliciting donations to further my own editing. After all, obtaining sources costs money, an increasing amount of money since I started editing, & I figure I could get money in a way that did not influence the POV of what I wrote. (Examples: I've found that some of the books I need for Ethiopian & Classical History have set me back over $100, while most of the rest are at least $50 a volume. I've encountered more & more a charge for ILL materials, such as Duke University charging me $15 for me to borrow one of their books.) So far, opening accounts at
    Go Fund Me, & Buy Me a Coffee have netted me exactly $1 in total. To be good at raising money in these ways, one has to be good at self-promotion, & if I were good at self-promotion I'd probably have been writing & publishing books & making a living that way. Instead I write articles on Wikipedia.

    One proposal I have been promoting is for the Foundation to set up a process for awarding research moneys. (Yes, the Foundation offers grants, but nowhere is it explained if, when or how it will provide grants for research. At least no where that I've looked. Maybe that's changing.) Providing grants of $50 to $100, maybe $500, is not going to ruin the seriousness of any established editor, but it might be an incentive to keep an experienced editor from drifting away. In my case, receiving a modest grant -- say $100 to $250, which is not enough money for me to live on, unless I live in a developing country where the minimum wage is $2 a day -- would have provide an incentive to improve some of the articles I've worked on to GA or FA class. -- llywrch (talk

    ) 07:10, 24 February 2023 (UTC)

  • How about a home for wayward senior wikipedians? This is an avocation I will take with me to my last days (a thought lately inspired watching the impressive Doug Weller log in every day). We'd merely need to qualify the word "wayward". BusterD (talk) 18:18, 4 March 2023 (UTC)
  • I agree with the concerns above that this is open to abuse, but along the lines of User:BD2412's suggestion: instead of giving editors cash, why not use donations to fund access to sources for editors to use, along the lines of the Wikipedia Library? I can see from comments above that I'm not the only one who has spent my own money on sources to use for Wikipedia editing. If the Wikipedia Library could be expanded with paywalled news sources, more extensive access to academic journals, and ebooks (especially scholarly books), that would help me improve the quality of my contributions. Physical books might also be a possibility. —Mx. Granger (talk · contribs) 19:42, 10 March 2023 (UTC)
  • Oppose, As other users have stated, it shouldn't be included with Wikipedia itself, it should more be a private thing on something like GoFundMe. ~With regards, I followed The Username Policy (Message Me) (What I have done on Wikipedia) 03:49, 27 March 2023 (UTC)
  • How about a pool of funds for books/source access that anyone could chip into, or something like an Amazon wishlist. Some chapters offer small grants for that sort of thing (I know Wikimedia UK does; I don't know how receptive they would be scaling it up though). But the cost of source material can be one of the biggest barriers to writing quality content (my Amazon wishlist totals about £3,000 and it's almost all books for potential Wikipedia articles), so any subsidy could make a big difference. HJ Mitchell | Penny for your thoughts? 19:41, 27 March 2023 (UTC)
    Good idea, I have suggested something similar for content improvement in the past. ♦ Dr. Blofeld 20:13, 27 March 2023 (UTC)
  • A rough back-of-the-envelope guess is that the English Wikipedia is built from about $5 Billion in volunteer time. A payment for some tiny fraction of that would probably make a mess out of things and has the danger of being an insult. Sincerely, North8000 (talk) 21:34, 27 March 2023 (UTC)
  • Opposefor now. It's not well thought through. I do not believe in self promotion and I am more in favor of a wikipedia solution. There are several competitions that actually already award small amounts of money on wikipedia. I believe the photographic one from commons is one. And one can also apply for grants from wikipedia.Paradise Chronicle (talk) 23:14, 27 March 2023 (UTC)
    There is also the WP:The Core Contest currently looking for editors taking part in it.Paradise Chronicle (talk) 08:43, 2 April 2023 (UTC)

Vector 2022 RfC

WP:CONEXCEPT where we must simply accept a fait accompli? Is there any appetite for taking further action to emphasise the majority opinion and, if so, what form should that take? Certes (talk
) 11:14, 16 March 2023 (UTC)

Please don't do this. This battle has waged for long enough. There's nothing new to be said that hasn't already been said in the 2 month long RFC, which was expertly summarized by a pair of uninvolved editors in their excellent closing statement. The suggestion there was to spend the next 6 months working with the WMF to improve the product and reevaluate how things look at the end of the 6 months. I strongly agree with that recommendation. -- RoySmith (talk) 13:52, 16 March 2023 (UTC)
Biggest +1 ever. User:ScottishFinnishRadish put it nicely here. Snowmanonahoe (talk) 23:54, 16 March 2023 (UTC)
Yup. What a humongous time-sink. DFlhb (talk) 16:55, 17 March 2023 (UTC)
Yes, let's get back to what's really important. Is it
corn or maize? ScottishFinnishRadish (talk
) 17:02, 17 March 2023 (UTC)
Option 3: it's inedible garbage. DFlhb (talk) 17:14, 17 March 2023 (UTC)
You need to cook it first. Tim O'Doherty (talk) 17:03, 25 March 2023 (UTC)
The closers clearly explained that in this case, no consensus means no rollback. If anyone wishes to challenge the close, they can follow the procedure at
WP:CLOSECHALLENGE; but that means giving policy-based reasons why the close was not a reasonable interpretation of consensus. Sojourner in the earth (talk
) 17:06, 16 March 2023 (UTC)
In the spirit of moving on productively…
It’s clear there are many editors who have specific grievances with the new skin. Since there is no consensus for a wholesale rollback of the skin, I suggest that progress will involve more focused attention on the fix-forward of those specific grievances individually. It would be helpful to create a summary of the main issues raised, each with links to relevant bugs that have been filed on Phabricator, so that (a) there is visibility of progress towards fixes, (b) concerned editors can focus their efforts on getting their specific issue resolved, and (c) to document that the issues are already well known and don’t need to be raised again. Barnards.tar.gz (talk) 18:51, 16 March 2023 (UTC)
Quite a large number are grouped on Phab. Personally, I'm currently watching making TOC code work again, which appears to have good traction, and the putting user talkpage links back in the header, which appears to be abandoned. CMD (talk) 06:49, 17 March 2023 (UTC)
I think that close had significant flaws; it placed too much weight on the closers assessment of whether current and future changes addressed the concerns of the community and on the closers assessment of whether the conditions of the previous close had been met.
Both of these assessments are required to be made by the community, not by the closers, and by making those assessments I believe this close was a supervote.
The way forward from here is to overturn that close, whether voluntarily by
WP:AN. BilledMammal (talk
) 20:13, 16 March 2023 (UTC)
We should iniate a formal
WP:CLOSECHALLENGE without hesitation. This closure is about as far away from the truth as possible. This is unacceptable. Tvx
1 18:47, 17 March 2023 (UTC)
I am glad there was not a consensus to roll back. I think that those who dislike the new skin are more vocal than those who like the new skin better. And it felt like there was a lot of "piling on" happening in the discussions. I agree with @RoySmith above. David10244 (talk) 02:01, 21 March 2023 (UTC)

There's probably no use even trying. The result was pre-ordained from the start - the numbers could have been 2:1 or 3:1 - it wouldn't have mattered. And if by some chance the closers had followed what was clearly a fairly obvious consensus, there's no guarantee it would have been respected. Honestly at this point the best way to respond is for editors to vote with their wallets and stop giving the WMF money. In the meantime, I wholeheartedly support repeatedly starting new discussions until the WMF gets it in their head that maybe railroading the community isn't a great idea. They don't get brownie points for being marginally more responsive after forcing something the community clearly doesn't want. The suggestion of a new RfC in six months is equally laughable - as if that will actually happen or have any outcome other than the one pre-ordained to happen. This entire charade is exemplary of everything wrong with how Wikipedia is run. Toa Nidhiki05 23:45, 16 March 2023 (UTC)

@Toa Nidhiki05: are you implying that the closers are secretly working with the WMF or something like that? Snowmanonahoe (talk) 00:05, 17 March 2023 (UTC)
There was no scenario where the implementation would be overturned and the new skin would be anything other than default. Whether that was in a "no consensus" RfC closure with hundreds of votes that skewed 61-39 in favor of rollback, an RfC review that finds the initial close invalid, or the WMF simply refusing to comply. Change was never going to happen. Toa Nidhiki05 00:11, 17 March 2023 (UTC)

If you don't like Vector 2022, switch it off and don't use it. Ritchie333 (talk) (cont) 13:21, 17 March 2023 (UTC)

Many of us have. I'm alright, Jack; I need never see Vector 2022 again. Unfortunately, most of our readers do not have that option. Certes (talk) 16:19, 17 March 2023 (UTC)

Maybe give it a few months to see if it made the ivory tower gets more responsive and make fixes and if not reopen it then ? North8000 (talk) 14:36, 17 March 2023 (UTC)

I'm sure the third RfC will have a different result than the first two. Toa Nidhiki05 14:40, 17 March 2023 (UTC)
In my view, the community expressed itself in favour of keeping V10 in both the RfCs, and in the second one the consensus was even stronger than in the first one. The WMF should simply withdraw V22 and rework it to address all concerns expressed by users, and then and only then resubmit it for community evaluation. Æo (talk) 16:28, 17 March 2023 (UTC)

It was always going to be a controversial close, but the fact is the RFC was whether we should rollback Vector 2022, and there isn't a clear consensus to do so. And so the closure seems correct, even if lumbering people by default with something with large issues is a bad idea. Joseph2302 (talk) 15:15, 17 March 2023 (UTC)

Agreed. The close could have gone either way; this seems like one reasonable interpretation. With any close close like this, extra effort should be made to address the concerns of those who wanted the other outcome. (In this case: accelerating responses to relevant phab tickets, like the ones CMD notes above.) – SJ + 17:43, 17 March 2023 (UTC)

I'd like to see it rolled back. I've seen a lot of complaints about it on other sites, you cannot see the links to other wikipedia pages section easily and it's a major pain in the butt as I have to be signed into all kinds of nations wikipedia websites.KatoKungLee (talk) 16:43, 17 March 2023 (UTC)

@KatoKungLee: do you mean the interlanguage links? – SJ + 17:43, 17 March 2023 (UTC)
@Sj: - I'm really not familiar with some of the lingo, but if you go to a page, you can click on another language's version of the page. With the new look, if you can do that, it's hidden or not easy to find.KatoKungLee (talk) 22:07, 20 March 2023 (UTC)

Well for me I solved all of the many problems by reverting to the previous one. But for the sake of others including those that don't know they can do that it would be good to make the old one the default. Whether the close was right or wrong, maybe it will make WMF into better listeners and they'll fix the new one. North8000 (talk) 19:07, 17 March 2023 (UTC)

Unfortunately, there's a loophole in our consensus system where the WMF has an unlimited and unrestricted veto power over every discussion on the project, for any reason or for no reason. So this could have been unanimous, and the WMF still could have just ignored the close, regardless of how disruptive its actions are. Thebiguglyalien (talk) 01:42, 18 March 2023 (UTC)

That doesn’t mean the blatantly incorrect close should be allowed to stand. Tvx1 17:09, 18 March 2023 (UTC)
So go ahead and challenge it? Unless someone actually goes through the
WP:CLOSECHALLENGE process nothing is going to happen. * Pppery * it has begun...
22:04, 18 March 2023 (UTC)

I'm just disappointed the change which consensus was found for (full width by default) hasn't been implemented after two days. It should be very little work if I understand correctly, and the devs had literal months to prepare for this very probably result. Instead all they've done is "begun to discuss and evaluate" and promised "proposals" within a week, as if there hasn't been enough talk already. small jars tc 22:23, 18 March 2023 (UTC)

Isabelle has said the WMF is not bound to do this and her close will not be impacted by whether or not they follow through on this. In other words: the only actual binding part of this RfC is keeping it as default. You should expect the WMF to ignore the second bit of the RFC, as not even Isabelle is willing to hold them to it. Toa Nidhiki05 00:04, 20 March 2023 (UTC)
You should stop spreading misinformation and attacking Isabelle for somehow not holding them to it(?) as if that's something they—or anyone!—could do. I'll be the umpteenth person pointing you to
WP:CONEXCEPT. WMF can ignore any or all of the close. None of it is binding. None of it CAN be binding. 2600:1700:87D3:3460:55F2:D3B6:7A49:FADD (talk
) 22:02, 20 March 2023 (UTC)
Also, please note that Isabelle uses they/them, not she/her. 2600:1700:87D3:3460:55F2:D3B6:7A49:FADD (talk) 22:15, 20 March 2023 (UTC)
@SmallJarsWithGreenLabels Very little in software development at the scale Wikimedia projects operate in can happen within two days. There are always edge cases, considerations, and options to evaluate, even when something seems clear-cut. Just be patient. Sam Walton (talk) 09:59, 20 March 2023 (UTC)
It's a matter of changing the default mode of a toggle button. If that takes more than 2 hours to complete, they must have some very baroque software architecture. small jars tc 16:18, 20 March 2023 (UTC)
Changing the button is the easy part. It's finding which file of the 10 trillion to edit, waiting 10 minutes for the code to compile and for the unit tests to run, having the code reviewed, blah blah blah... Snowmanonahoe (talk) 18:16, 20 March 2023 (UTC)

Is this close really not going to be challenged?? Surely such a gross misrepresentation of a discussion cannot be allowed to stand.Tvx1 07:07, 19 March 2023 (UTC)

You've been commenting the same thing multiple times across multiple threads. If you're unhappy with the close, then challenge it yourself. Simply repeating yourself over and over again isn't helpful. Aoi (青い) (talk) 07:35, 19 March 2023 (UTC)
It's a difficult choice. On the one hand, the closer had a very difficult and time-consuming job, and acted competently and in good faith. On the other, there is a significant majority opposed to the recent change, so it should be reversed. Of course, whether the organisation which we trusted with our funds, trademarks and domains will deign to listen is a different question. Certes (talk) 13:19, 19 March 2023 (UTC)
Challenging the closure does not necessarily imply disavowing Isabelle Belato's and Ingenuity's good faith. Æo (talk) 17:52, 19 March 2023 (UTC)
Just leave it, most opposes have no merit, just a grudge for change. I was highly skeptical as well at the start and I quickly switched back to vector 2010. But then after the main concern I had was addressed, and also saw that the WMF actually does address the concerns raised, I eventually moved to vector 2022 for good and now I also prefer it on other projects.Paradise Chronicle (talk) 21:43, 19 March 2023 (UTC)
I was one of those who supported the rollback and I assure you that my vote was not driven simply by a "grudge for change". Æo (talk) 21:58, 19 March 2023 (UTC)
(ec) It's more than reasonable to leave this be for the six months until this will be revisited. Criticism of the change happened with the last skin and will happen with the next one. Our input has been and will be solicited. I'm pretty much used to it now- try it, you might like it. If not, use the old one. 331dot (talk) 22:01, 19 March 2023 (UTC)
I and most of those who voted for a rollback to V10 are not driven by individualistic thinking; it is not a simple "personally, I don't like V22 and therefore I stick to V10". Most of us think that V22 is inferior to V10 in many respects and is detrimental to the encyclopedia and to the users' experience, and that V10 should remain the default skin for the general welfare of the encyclopedia and for all the other users. Æo (talk) 22:19, 19 March 2023 (UTC)
There was people who thought that for V10, and there will be people who think that for V30 or whatever its called. That's a recipe for changing nothing for all time. 331dot (talk) 22:57, 19 March 2023 (UTC)
I disagree, I would have supported the change if V22 had actually been better. But it is not. Æo (talk) 00:05, 20 March 2023 (UTC)
I expect almost all registered editors who supported the rollback have visited Special:Preferences and will soon almost forget that Vector 2022 ever existed. We're !voting on behalf of the silent majority of unregistered editors, who don't have that privilege. Certes (talk) 12:16, 20 March 2023 (UTC)
If most opposes had no merit, than why are they given so much weight in the close to the point of claiming a "no consensus". Tvx1 18:30, 20 March 2023 (UTC)
A related discussion can be found at VPI, discussing possible modifications to the default settings of Vector 2022. BilledMammal (talk) 02:45, 20 March 2023 (UTC)

The close result is funny though in the retrospect of the whole active canvassing of non-Wikipedians by the WMF specifically to support the change. The real consensus against the re-design is much more than 2-1 considering that. SilverserenC 03:01, 20 March 2023 (UTC)

Good luck getting the closers to reconsider even a fragment of their defective close. It’s not going to happen. Toa Nidhiki05 02:37, 21 March 2023 (UTC)

The close has been formally challenged.Tvx
1 19:04, 20 March 2023 (UTC)

I've boldly closed that review. Let the discussions on the closer's page finish, and then interested editors can collaborate to open a review if it is still deemed necessary. BilledMammal (talk) 20:59, 20 March 2023 (UTC)
What needs to be finished then?? They have made it abundantly clear they will change their stance and insisted themselves a formal review was the way. How much more time needs to be wasted??? Please undo your unilateral close and let the procedure run its course. Tvx1 23:56, 20 March 2023 (UTC)
Take a look at the discussion here. BilledMammal (talk) 00:05, 21 March 2023 (UTC)
You could open a close review of the close of the close review. (don't actually do this, please) ScottishFinnishRadish (talk) 00:07, 21 March 2023 (UTC)
Meanwhile, life goes on... --⛵ WaltClipper -(talk) 13:07, 22 March 2023 (UTC)
A second Close Review was opened today. Soni (talk) 14:57, 28 March 2023 (UTC)
In retrospective the whole Vector22 launch process seems flawed. Three RfCs in which three times the outcome was a majority opposing the launch which then was interpreted as a support for the launch even though the initial closer mentioned he opposed the view the issues mentioned in the first close were addressed. As for me it's a dangerous precedent for consensus.Paradise Chronicle (talk) 09:01, 2 April 2023 (UTC)
If the WMF can't address the concerns of the community they could also just cite
WP:CONEXCEPT which is also a policy. But then again, who still cares about polices? WP:MASSCREATE or WP:MEATBOT are two, that could be applied a bit more but there is fierce opposition by several admins editors.Paradise Chronicle (talk
) 09:13, 2 April 2023 (UTC)
Unfortunately, the WMF can do whatever it likes. However, it must understand that, for some of us at least, it is on a final written warning. The next time the WMF acts against community consensus, I will stop editing Wikipedia, and I would be very surprised if I were the only departure. Certes (talk) 11:32, 2 April 2023 (UTC)

Inasmuch as the second Close Review was closed a few days ago, I feel a couple of points should be made:

  1. The people closing the original RfC had a tough job, & no matter how they closed the discussion people would have been unhappy.
  2. If the community had more faith that the Foundation would honor our preferences in matters like this, I believe people would be more likely to accept a "No consensus" closure, or a closure they disagreed with. That is, they didn't feel as if (as one commentator wrote in the last Close Review wrote) they were yelling into the void. But as many have pointed out, no matter what the community wants, the Foundation can always tell us to go pound sand. (To use the more polite form of the response.)

Some may accuse me of taking another whack at the dead equine, but my second point needs to be made: as long as we feel we are powerless in decisions like this, volunteers will be unhappy & resentment will simmer below the surface, to emerge whenever we try to interact with the Foundation over important issues. There are too many similarities in the relationship between the volunteers & the Foundation to a marriage going bad. -- llywrch (talk) 06:38, 3 April 2023 (UTC)

Proposal to reword text above the source-editing window

Issue: Many new editors fail to cite reliable sources when adding encyclopedic content. Only guidance they have on this subject is a small text above the editing window when editing in source mode. Visual editor is slightly better with this, but it is burrowed within a button. This proposal will focus on the source editor.

Proposal: Currently, the text reads "Content that violates any copyrights will be deleted. Encyclopedic content must be verifiable through citations to reliable sources." My proposal is to reword the "Encyclopedic content must be verifiable through citations to reliable sources" into "Any information added must be supported by reliable sources".

Rationale: The current text is cryptic to new editors and uses words that has its meaning in a unconventional way. For example, the word "verifiable" may be confusing to new editors and is not approachable. My reworded text will improve the accessibility of the text to new editors.

talk
) 10:24, 28 March 2023 (UTC)

information Administrator note this is about message MediaWiki:Editpage-head-copy-warn. — xaosflux Talk 10:47, 28 March 2023 (UTC)
Linking
verifiable and perhaps citations if those words remains, although they are linked from the currently linked page (Help:Introduction to referencing with Wiki Markup/1.) Certes (talk
) 13:04, 28 March 2023 (UTC)

Cmnt: How about: "Any content added must be supported by, and include, reliable source(s)". GenQuest "scribble" 17:53, 28 March 2023 (UTC)

"and include reliable sources" makes it sound like the actual source should be included, rather than a citation to the source. That could inadvertently lead to copyvios as people attempt to "include" the source. ~
problem solving
18:12, 28 March 2023 (UTC)
Wording aside, there is no consensus at the moment that every edit must correspond to an appropriate citation within the text, whether it is a new one or an existing one covers the change. It should be possible to cite a source, but the community has so far given higher priority to someone adding relevant information over insisting that the author include a citation for that information. isaacl (talk) 21:27, 28 March 2023 (UTC)
  • Comment. Maybe I’ve just been here too long, but is the word verifiable really that confusing? I don’t think it has any special meaning here beyond its everyday meaning. I agree though that Encyclopedic content isn’t helpful to outsiders. The lay perception is probably that this website is an encyclopedia and that means everything found on it is encyclopedic.
    I suggest wikilinks be added to both terms, pointing to pages that explain them. Barnards.tar.gz (talk) 21:58, 28 March 2023 (UTC)
    Maybe the problem is that long-time editors have a different understanding of what it means for something to be verifiable.
    @
    Carpimaps, Wikipedia:Glossary#verifiable
    gives this definition:
    Something that people are "able" to "verify". Specifically within the meaning of the Wikipedia:Verifiability policy, it is information that someone (although not necessarily you) could, with enough effort and expense, determine has been published in a reliable source, even if no source is provided in the article. Contrast uncited.
    This proposal is to change the sentence Encyclopedic content must be verifiable through citations to reliable sources to Any information added must be supported by reliable sources". I wonder whether you are aware that of the significant difference between the two? The existing sentence says that all content must be something other people are "able" to verify but does not (technically) require sources to be cited; the second says that every sentence must be cited. The first is a long-standing policy; the second is an idea that some editors support, but that has not been accepted in previous discussions.
    Also, anyone who is interested in encouraging newcomers to add citations will probably want to watch Wikipedia:Edit check and mw:Edit check. There's a software project underway to encourage (but not require) citations. WhatamIdoing (talk) 00:21, 29 March 2023 (UTC)
    Personally, I think you're reading more into the text than is there. I don't feel that saying added information must be supported by reliable sources is asking for every sentence to be cited. It doesn't put any requirement on having a citation per sentence, or even that each specific edit must include a citation. It doesn't even require a citation; it's only asking that the information has support from reliable sources. I think the current sentence is more prone to being interpreted by new editors as requiring a citation than the original proposal (though I agree it does not actually require this). isaacl (talk) 02:14, 29 March 2023 (UTC)
    When you use the word must, you are not "asking"; you are "requiring". (I think you're familiar with the definition in https://www.rfc-editor.org/rfc/rfc2119 ?) It might not be one per sentence, because a single citation could support a whole paragraph, but it is a requirement. WhatamIdoing (talk) 19:25, 31 March 2023 (UTC)
    I apologize for using the word "asking" colloquially; I meant that the proposed change requires that the information has support from reliable sources. The proposed change doesn't use the word "citation", nor the word "sentence". Thus to me it doesn't "say[s] that every sentence must be cited". The current sentence does use the word "citation" (and the word "must"), which is why I think it's more prone to be interpreted as requiring a citation. isaacl (talk) 00:35, 1 April 2023 (UTC)
    I don't like the current sentence, either. It's true that everything must be verifiable; it is not true that everything must be verifiable through the exact method of citing a reliable source.
    I support re-writing the sentence. Perhaps something like "It must be possible for others to verify any information you add. Please add a citation to a reliable source" (or "This is easiest to do if you add citations to reliable sources"). WhatamIdoing (talk) 01:55, 1 April 2023 (UTC)
    Today, I'm thinking about making it longer: "It must be possible for others to verify that any information you add has previously been published in a reliable source. Please help the reviewers out by adding citations to any reliable sources you are aware of." WhatamIdoing (talk) 21:15, 3 April 2023 (UTC)
    I would say the definition of verifiable that you have cited is entirely the same as the common non-Wikipedia meaning of the word. Verifiable. Something that is able to be verified. Not necessarily something that has been verified. It’s not jargon. For this reason I don’t think there’s a strong case for changing the existing wording (but I do support adding wikilinks to provide an abundance of clarity). Barnards.tar.gz (talk) 06:21, 29 March 2023 (UTC)
    I think my biggest worry for this subject is what we're communicating to patrollers.
    Background: Although spelling it out doesn't make us look good, I think we're all pretty settled on what we really want:
    • Newbies should add sources to any new material introduced into an article.
    • But I can do anything I want, because as an experienced editor, I am "using good editorial judgment" and "have the trust of the community" and that's how we did things 'way back in the day.
    There is a minority that additionally wants:
    • Almost every sentence to have at least one inline citation. (Currently, the English Wikipedia cites about 50% of sentences; a few years ago, it was closer to 30%, and once upon a time, it was basically zero.)
    A problem: We write one message, but it's seen by lots and lots and lots of different people. The message we want to send to newbies is "If you add a fact to this article, you must cite it". We hope that by sending a very strong, clear, firm requirement for always citing content, then perhaps the newbies will sometimes do the right thing.
    Then a few of these newbies grow up and turn into RecentChanges patrollers. The message we want to send to patrollers is "Use your judgment. Not every little thing actually requires a citation, and if you personally know that the edit is correct, then you personally shouldn't be so uncollegial and destructive as to remove good information. Wikipedia is not a game of
    Mother, May I?
    , and a citation is not a way of asking permission to add undisputed, accurate, encyclopedic facts."
    It's difficult to write a sentence that is effective at getting people to add citations without accidentally teaching them that citations are an end goal. WhatamIdoing (talk) 19:39, 31 March 2023 (UTC)
    I don't think this one sentence is going to cause significant problems with recent changes patrolling. As you've pointed out before, people don't read instructions. I don't feel this one sentence above the edit box is going to play a greater role than the experience editors gain through reading articles and seeing for themselves how information is cited. isaacl (talk) 00:28, 1 April 2023 (UTC)
    Consider, e.g., Wikipedia:Unsourced information is not valuable. Editors aren't making this idea up out of thin air. They're getting signals from anywhere and everywhere that 100% citation is required. Unless we want to change the rules (and maybe some day we will do that), then we really need to be careful about what signals we're sending everywhere. WhatamIdoing (talk) 01:50, 1 April 2023 (UTC)
    I agree editors take their cue from their experiences, which in addition to reading articles includes discussions with other editors. I think trying to shift the nature of these discussions will reap more benefits with respect to recent change patrolling than wordsmithing the current sentence above the edit box. (I think changing the sentence may benefit new editors, for that very small percentage that does read it.) isaacl (talk) 18:10, 1 April 2023 (UTC)
  • We have two related but distinct problems: 1) new editors don’t include citations when they are required. 2) patrollers demand citations when they are not necessarily required. The question is whether we can formulate this in one sentence. Blueboar (talk) 20:50, 31 March 2023 (UTC)
    I think the proposed text is fine, especially with the addition of wikilinks. We could also wikilink "supported" to WP:V. JoelleJay (talk) 01:35, 1 April 2023 (UTC)
    If we think people don't know what "supported" means, then WP:Directly supports would be more pointful. I'd rather have something like "Please add citations when you add new information. This helps people who will check your contribution later". WhatamIdoing (talk) 01:46, 1 April 2023 (UTC)

Speech synthesis

Why don't you add the

W3C websites' specifications. 151.18.116.120 (talk
) 15:06, 5 April 2023 (UTC)

That's a noble thought, but would it be more helpful to improve standards compliance so that a standard screen reader works better with Wikipedia? Certes (talk) 14:46, 6 April 2023 (UTC)
As a screen reader user, I don't think it can possibly be much better ... Graham87 10:19, 7 April 2023 (UTC)

Expansion to the "Did you mean" box

I suggest implementing the functionality of checking whether the page exists when backslashes before spaces (or just all backslashes) are removed into {{New page DYM}}, e.g. going to Main\ Page would create a suggestion that the reader may have meant Main Page similarly to how going to Georgia (country would create a link to Georgia (country). This may be better placed at the template talk page, but it doesn't seem like it would turn into a discussion there and I don't expect there to be an obvious consensus.

This error isn't entirely rare to happen due to a malformed external link: see the "Yanny\ or\ Laurel" redirect getting ~110 views when it was made with them dying off immediately. However, the cause of this error is fairly specific: this is only caused by Reddit (as far as I'm aware), where it's a persistent glitch in conversion between the old and new styles: the new style inserts backslashes when writing a link to escape the Markdown formatting while it needn't to do so. The new style corrects the link's target when clicking on it. The old style and by extension many third party clients don't, causing a malformed target of that sort. This is a known issue that has persisted for close to two years, is still being constantly reported to the developers, and so it's unlikely to be fixed any time soon.

Reddit is a fairly large website, and adjusting for this may prove useful to people redirected to Wikipedia from there. Adding this is just correcting for one other specific website's shortcomings, but I don't see another negative to it. This would still assist a sizable amount of people in reaching the intended target article, out of those who would otherwise just go back rather than remove each %5C from the URL. Randi Moth TalkContribs 19:44, 6 April 2023 (UTC)

Looks good to me. Backslashes are also used fairly often in general for escaping characters, so it's not an implausible mistake to make.
talk
) 02:28, 12 April 2023 (UTC)

Increasing AFD participation

A problem I've noticed very recently is that there is a worrying lack of participation in many AFDs. Which does make it hard to gain a clear consensus when you're relying on only a few votes. And a problem has crept in where articles have to keep being relisted because of lack of participation, bloating an already overworked process. Any ideas on what we can do to improve this problem and generate more interest? I would rather see it where articles are listed for AFD and the consensus clear by the end of the week. ♦ Dr. Blofeld 15:34, 29 March 2023 (UTC)

If you do figure out how to force unpaid volunteers at Wikipedia doing work in their spare time to do anything, then you'll have squared the circle no one has yet figured out. Wikipedia, as a volunteer organization where all of the work is done by anonymous, unpaid actors, has no means to coerce anyone to do anything they aren't in the mood to do. Increasing participation is only possible by increasing one's own participation; at no time can you expect any action you take to cause any other person to do anything at Wikipedia. --Jayron32 15:39, 29 March 2023 (UTC)
I don't disagree Jayron. But is there a way we can increase visibility of AFDs, without necessarily forcing anonymous, unpaid editors to do anything? ♦ Dr. Blofeld 15:55, 29 March 2023 (UTC)
I mean, I guess we could add a link to Wikipedia:Community portal. It will never get noticed, as there's already dozens upon dozens of links to tasks that need community input, but we can add it to the list I suppose. Won't help one bit. But at least we're doing something, right? --Jayron32 16:01, 29 March 2023 (UTC)
Depends on how much traffic that page gets, I agree it would be unlikely to see a marked improvement. I know I'd support some sort of alert system for my talk page where I could be alerted of articles daily, like a few AFDs at random, random articles needing improvement etc at the top. Articles needing translation etc. Not forcing editors to do anything but like a news flash board at the top or something where I'd be more likely to see articles and you can control in your preferences what sort of content is displayed.♦ Dr. Blofeld 16:16, 29 March 2023 (UTC)
Something similar to the Feedback request service? Random person no 362478479 (talk) 23:30, 30 March 2023 (UTC)
As to random articles needing improvement, the Newcomer tasks module of the Newcomer homepage offers that. You can choose topic categories and what kind of improvement tasks you're interested in. You can activate it under Preferences -> User profile -> Newcomer Editor Features. It shows up next to your user and talk pages as a separate page. Random person no 362478479 (talk) 23:49, 30 March 2023 (UTC)
Improving the atmosphere of AfD to be more collegial would help. It's the making sausage side of Wikipedia. "Laws, like sausages, cease to inspire respect in proportion as we know how they are made" (1869). -- GreenC 16:54, 29 March 2023 (UTC)
I am a very infrequent contributor to AfD. When I have a spare moment to fill, I usually just scan down the list and pick a couple that look like I might be able to form a sensible opinion on them. I find there are quite a lot where I take one look and think I’ve got no chance of determining notability - usually non-English/non-Western names and places. For all I know, they might be tremendously notable in some culture, but I feel unqualified to judge, so I just leave them alone.
Wikipedia:Articles for deletion/Oon Yung is an example.
So I wonder if there is any merit in finding a way to reach out to other wikipedias for help - in the example above, perhaps to the Korean Wikipedia. Could be as simple as finding a liaison from that Wikipedia to link to the Korea deletion sorting list in the right place. Barnards.tar.gz (talk) 17:23, 29 March 2023 (UTC)
There is the concept of
Phil Bridger (talk
) 18:26, 29 March 2023 (UTC)
Agree with GreenC in that the environment around AfD's is so toxic and so polarized that I don't blame anyone for not participating there. There needs to be some reform for how AfD's are done but any attempts to reform AfD seem to not be wanted. ♠JCW555 (talk)♠ 17:39, 29 March 2023 (UTC)
I've tried to make AfDs that I participate in a little less toxic by not preceding my comments with "Keep" or "Delete" unless I am absolutely certain of what should be done with the article. This has not caught on and even the instructions for participating in a discussion say that this choice should be made. Making people make a decision before they have even started discussing leads to a battleground where people think they are losing face by changing their minds.
Phil Bridger (talk
) 18:26, 29 March 2023 (UTC)
Good points, particularly JCW and Green. I'd be interested to see a poll on people's views of AFD to see how many people consider it toxic and if this is why they stay clear of it. If there are a significant number then come up with ways in which we can improve it. I do think it's problematic to rely on just two or three people at times to control the outcome of content in our encyclopedia and we need to improve the process somehow without forcing people to do anything. An idea would be a points/credit system for editors in which they can collect points for doing certain tasks on here each month that could include for reviewing AFDs and GAs/FAs etc and a book fund in which editors can save up points to eventually buy books they need for articles, though I imagine a number would object to such a system and I can think of some potential problems with gaming the system. You could certainly make a mechanism like that work though without forcing anybody to do anything.♦ Dr. Blofeld 19:07, 29 March 2023 (UTC)
I'd like to see fewer relists. The sheer volume of articles at AfD divides editor attention and contributes to the low participation, and unnecessary relists are a big factor in that. Looking at
WP:NOQUORUM, these could/should have been closed as soft delete. I think generally, the process guidelines should be firmer about discouraging relisting except in cases where discussion is ongoing, or where the closer thinks there are important points that haven't been addressed. Sojourner in the earth (talk
) 18:43, 29 March 2023 (UTC)
Agree with this too. There's already usually 40-60 AfD's per day, and adding to that list by relisting things over and over doesn't help. I know a rate limit of AfD's has been routinely shot down, but I feel like it's too intimidating for people to participate in AfD when there's so many of them each day. ♠JCW555 (talk)♠ 19:33, 29 March 2023 (UTC)
On the whole, I'm more concerned by the quality rather than the quantity of "votes". A rather large number are pretty new editors who normally seem to vote delete, spouting a bunch of policy links, often with no relevance at all. Johnbod (talk) 19:17, 29 March 2023 (UTC)
Interesting. Is this a new kind of vandalism. -- GreenC 19:54, 29 March 2023 (UTC)
Agreed, I've noticed the same thing John. ♦ Dr. Blofeld 11:47, 30 March 2023 (UTC)

Volunteers work where it is enjoyable for them or at least not too painful. Wikipedia is a nasty and viscous environment, and AFD is one of the roughest neighborhoods within IT so efforts in both of those would help. Also the sheer quantity of AFD's makes it rougher at many levels. Aside from the obvious ones, when I work there I feel like a production line worker which for me at least isn't fun. Also doing the job thoroughly is difficult because participants are "supposed" to be searching the world find GNG sources or "prove a negative" that they don't exist. For me doing that isn't fun, nor is feeling guilty for not doing that. There is one fix which would fix this and about 5 other big problems. That is to establish is as a norm that step 1 to starting an article is to find GNG type sources to build it from. At AFD alone this would help in these ways:

  1. Reduce the sheer quantity and thus the shortage of participants
  2. Reduce the "production line" type nature of the task
  3. Reduce the need for relisting
  4. Make it not be the place when newbies (with angst and pain) learn what wp:notability is and that it isn't about notability
  5. Reduce the "search the world for references" / guilt for not doing so part of the job
  6. #5 would make it so more people can competently do it

And that's without even getting into on how it would help at AFC, NPP, draftification areas, the nasty environment for newbies and other areas. North8000 (talk) 19:38, 29 March 2023 (UTC)

North8000 you have done a lot of 'production line' work at AfD over the years your insights are valuable. I think you are right starting with good ingredients (GNG sources) can solve a lot of problems with bad cooks. -- GreenC 20:00, 29 March 2023 (UTC)
Isn't this already being done through AfC? I'm not sure what exactly you're suggesting. DFlhb (talk) 21:47, 31 March 2023 (UTC)

AfD has long suffered for participation, but it's a tough one to promote because it requires a good amount of knowledge and experience to contribute to effectively. It's not the sort of thing we can just gamify or marshal newbies to help out with because we don't want uninformed or lazy !votes (and it's already a frequently contentious space). Maybe a way around all that is to emphasize the articles themselves, e.g. a contest to look through AfDs and find an article to improve. Maybe get something like that added to the WikiCup? Most efforts to redirect volunteer time aren't successful, though, and this isn't an area where you're going to find many people who find AfD "fun" who haven't found it already... :/ — Rhododendrites talk \\ 20:13, 29 March 2023 (UTC)

Yes, I think if you were to gamify it or even with a contest, there would have to be a quality requirement to show that you've taken time to carefully review the articles. But then that would mean that a judge would need to go through the edits of each person and review them, which is time we don't really have or want to spend. ♦ Dr. Blofeld 11:53, 30 March 2023 (UTC)
I think further incentivizing "improving AfD'd articles" would only encourage the attitude that deletion==negative, which is one of the contributing factors to toxicity in that space (it's not pleasant being accused of "destroying the encyclopedia" just because you !voted to delete a page where the only sources anyone has found are trivial). We already have editors who refbomb/expand AfD'd articles with unencyclopedic content (sometimes specifically opening a DYK concurrent with the AfD!), adding more of that approach just makes it even harder for editors to actually comprehensively evaluate the quality of sources. Just a couple weeks ago I had to review every single one of 50+ references added to an article (on top of my own BEFORE) since many editors demand delete !voters provide an individual exclusion rationale for each citation. JoelleJay (talk) 21:59, 29 March 2023 (UTC)
Yes I think you could be right on that. It's interesting to me seeing how many editors are talking about AFD being a toxic environment. ♦ Dr. Blofeld 11:46, 30 March 2023 (UTC)
I wonder how many of those editors are talking purely about sports AfDs. I find AfD quite pleasant and collegial, and I suspect that's largely because I'm not at all interested in sports, politics or weather. Sojourner in the earth (talk) 18:16, 30 March 2023 (UTC)
Broadly, I'll disagree that encouraging people to actively improve articles that are at AfD can be a bad thing. If something can be improved and saved, in most cases it shouldn't have been nominated, after all. Assuming that encouraging people to improve articles means they'll do so incompetently is more pessimistic than I think is warranted. There's no getting around the fact that anyone who wants to keep an article isn't going to like it when people want to delete it. I've gotten plenty of the ~"you're destroying Wikipedia" comments, too, but the feelings are built into the process, and even the words we use (delete, remove, omit vs. include, improve, preserve). At the end of the day, though, the community tends to err on the side of improving content (which isn't to say simply keeping it), so if there's going to be an intervention IMO that's probably it. Doesn't mean it's an excellent idea, though. :) — Rhododendrites talk \\ 14:14, 30 March 2023 (UTC)

I think to improve participation at AfD you need to improve the environment at AfD. One proposal that has been discussed on my talk page is to prevent ref-bombing and require arguments to address the reasons for keeping or deleting; the initial draft was:

For the closer to be permitted to consider a keep !vote that argues a topic meets GNG, the !vote must either contain two sources that the editor believes meets the GNG criteria, or it must refer to a !vote that contains two sources. !Votes that contain more than two sources will be considered refbombing and may not be considered.

For the closer to be permitted to consider a delete !vote that argues a topic does not meet GNG, the !vote must either argue why previous presented sources do not meet GNG, or refer to a !vote that presents such an argument.

Some wordsmithing is still required but I believe this would be a positive, though incomplete, step to improving the environment and encouraging participating, as well as making it easier for the closer to determine consensus. BilledMammal (talk) 22:31, 29 March 2023 (UTC)

I might agree with you if the delete side would accept notability based on only 2 sources, but that is a problem as all they need to do is reject one source and it is pretty easy to come up reasons for any given source. Then when they reject it, a third source is provided, you become a "ref bomber", a problem editor! Such a 2-source rule would heavily favor deletion. -- GreenC 14:17, 2 April 2023 (UTC)
It's pretty easy to come up with a reason, but its much harder to come up with a good reason if the source is genuinely significant, independent, and secondary - and reasons that aren't good typically don't convince other !voters or the closer. I can't see this favoring either side, but I can see it favoring making AfD an easier location to edit. BilledMammal (talk) 18:09, 6 April 2023 (UTC)

It's my sense that AfD participation in sports articles is low because sports-focused editors lack understanding of our GNG policies. For years, participants were able to lean on a SNG that was easy to understand and apply. That's no longer the case, and I don't think enough editors have the experience necessary to apply the GNG (not to mention that it requires more effort than applying the SNG). One step that I think will help is an effort to explain specific GNG policies and provide examples of how they typically apply to sports articles at the NSPORT Talk page. I sense that editors are often talking past one another in AfDs rather than having actual disagreements over the available sources. Jogurney (talk) 12:53, 30 March 2023 (UTC)

Applying the general notability guideline at the sports notability talk page has been discussed for many, many years, as the sports-specific guidelines have always deferred to it (and this has been reaffirmed over and over again in RfCs, including the latest one). Thus personally I'm not too optimistic that further discussion will result in a significant change (though it may not hurt). Editors who continue to use routine or promotional coverage as indications of meeting Wikipedia's standards for having an article generally have never read the discussions at the sports notability talk page, or have disagreed with them, typically preferring an achievement-based standard. (Part of the issue is that a lot of sports journalism is driven by promotional needs based on reader demand, thus the suitability of a lot of sports articles has to be carefully evaluated.) isaacl (talk) 16:12, 30 March 2023 (UTC)
Sorry, I didn't mean to imply that these discussions haven't occurred at the NSPORTS Talk page; they obviously have. Perhaps the better thing is to direct sports article AfD participants to review those discussions. While we can't mandate this, I do think most AfD participants want to do the right thing, but they are "flying blind." Jogurney (talk) 16:56, 30 March 2023 (UTC)
I don't follow article deletion discussions, but in the ones I've seen related to sports figures, I don't get the sense that opposers are flying blind. I feel they disagree with the consensus view on the standard for having an article for sports figures, and per Wikipedia's tradition that guidance is established from the results of discussions over specific examples, rather than being prescribed by abstract discussion, they continue to make arguments based on their perspective. Many closers of deletion discussions have hewed to this tradition, and thus have determined consensus based on the specific comments within a given deletion discussion. I understand why this tradition has arisen during Wikipedia's history and how it allows for consensus views to be re-evaluated from the grassroots. It does, though, require a lot of time investment to constantly re-establish consensus, and that's an increasingly difficult demand to make upon the community. isaacl (talk) 17:47, 30 March 2023 (UTC)
Editors who continue to use routine or promotional coverage as indications of meeting Wikipedia's standards for having an article generally have never read the discussions at the sports notability talk page, or have disagreed with them, typically preferring an achievement-based standard. This is exactly what is happening in sports AfDs, and one of the reasons is because "routine" and "promotional" are not directly explained in our guidelines, and thus editors reject them as being invalid source exclusion reasons. Is a fawning, highly-positive coach hiring announcement in the local small-town newspaper automatic SIGCOV simply because some biographical details can be extracted from it? Does it matter if that paper regularly publishes pieces of identical length and depth for wide swathes of the town's residents? Are items of purely local interest always eligible to count towards GNG? Such questions can't even be considered in AfDs because there is technically no guidance explicitly asking editors to treat those types of sources any differently than those run in national news. JoelleJay (talk) 00:08, 31 March 2023 (UTC)
WP:AUD only apply to subjects that fall under Wikipedia:Notability (organizations and companies), and even then, AUD says that local newspapers do count towards notability – just that an article about a business can't be justified if the every single source ever published about the business is a local newspaper. WhatamIdoing (talk
) 20:52, 31 March 2023 (UTC)
This comment is impressively 100% strawman and also strikingly incorrect. JoelleJay (talk) 01:11, 1 April 2023 (UTC)

There's three things that I think play a role in this:

1) The post-Lugnuts notability rule changes were poorly thought out and created a lot of extra work on the website. Unfortunately, the same people who voted in a lot of those rules don't have interest in doing the daily AfD debate scut work which comes along with it. This site may see itself as a notability encyclopedia, but the average person thinks this is a google search where nearly everything ever should be posted on here. That's not going to ever change.

2) This site is extremely unfriendly and aggressive to newcomers. There's lots of people who come onto the site, try to write an article then either have it deleted and/or end up getting into a fight with the person who nominated it and get in trouble over it. I've seen a lot of people who could have contributed be run off here in quick fashion.

3) AfD discussions are also just a generally nasty place. People nominate things without doing any research into them, people seek out articles for deletion and take pleasure in getting them deleted, people stalk people from AfD discussions and there's just a lot of wikilawyering that isn't fun to deal with.KatoKungLee (talk) 16:30, 30 March 2023 (UTC)

The word wikilawyering is key. It's a courtroom that favors people who have an advanced degree in the Wiki municipal codes and disadvantages people who are like "wait I thought you said this was an encyclopedia anyone can edit?" I go there when I want to be mad and sad. The very pleasant Grasshopper Pueblo article came out of the process tho, so there's that. The vibes at AfD are just bad, man. Not sure how to change that. jengod (talk) 21:31, 30 March 2023 (UTC)
I like many of North8000 suggestions. And I have also another one to add I believe I have not seen. To nominate an article for deletion, you must have voted in three AfDs before. Similar like DYK and the DYK review.Paradise Chronicle (talk) 21:53, 30 March 2023 (UTC)
@Dr. Blofeld, I wonder how many participants you think would be a good idea for the typical AFD? It's easy to say "more, more, more", but if there's a number that's likely to produce the right result, then we don't want to waste time and effort on making the dogpile. I ask this because if the median is two, and you think it should be four, and we somehow manage to reach four, I don't want someone to be posting then that four isn't enough, and we really need an average of seven...
We already advertise AFDs through the article itself, plus other mechanisms, e.g., Wikipedia:WikiProject Deletion sorting/Medicine and Wikipedia:WikiProject Medicine/Article alerts#AfD. A "push" option modeled after Wikipedia:Feedback request service is possible, and there are other options, such as encouraging newer editors to participate, transcluding the DELSORT lists onto WikiProject talk pagesor having a bot invite people/WikiProjects for AFDs at risk of being re-listed. WhatamIdoing (talk) 21:02, 31 March 2023 (UTC)
Yes, at least four or five people! ♦ Dr. Blofeld 07:14, 1 April 2023 (UTC)
Most AfDs are pretty open-and-shut, I don't think four or five opinions are necessary. If I see that two editors I trust have posted well-reasoned delete !votes, I'm not going to waste my time double-checking their work, because I know I'm unlikely to find anything they missed. It's possible to "participate" in an AfD simply by contributing to the silent consensus. The last seven daily logs recieved 300–400 pageviews each; it's probable that each nomination gets read by many people who just see no reason to comment. Sojourner in the earth (talk) 06:23, 2 April 2023 (UTC)
People nominate things without doing any research into them I've seen that happen. Couldn't we make the threshold for nominations more stringent, somehow? Then we wouldn't need to increase participation.
We could also consider loosening the inclusion criteria, to address your first point (I'd support that; there's nothing wrong with having permastubs, and that would remove all the "but it's just passing coverage", "but it fails
WP:10YT
" type arguments).
I think a lot of people support stringent notability requirements as a way to preserve Wikipedia's verifiability, but that seems pretty dysfunctional, since ultimately those are two separate things. It's far-out, but we could maybe consider reframing our notability requirements in terms of avoidance of real-world harm. Article is a hoax? Delete. It's a non-notable BLP with only polemical sources? Delete. Article about a defunct magazine, with SIGCOV in one lone reliable source? Hurts no one, keep. Our stringency on notability may be the biggest cause of our
WP:SYSTEMICBIAS. DFlhb (talk
) 22:06, 31 March 2023 (UTC)
What you're describing are fandom wikis.
Our stringency on notability may be the biggest cause of our
WP:SYSTEMICBIAS. Absolutely not. The coverage in RS of "western" topics throughout history is orders of magnitude greater than that of "non-western" topics, end of story. The more we loosen notability, the closer we get toward being an exact replica of every item that has ever been preserved in a reliable source, and that can only increase WP's "systemic bias" because the ratio of publications produced in the Anglosphere versus anywhere else rises the more trivial the content is. JoelleJay (talk
) 00:42, 1 April 2023 (UTC)
I think we do need more articles about periodicals (academic journals, newspapers, magazines), and I think we need them for both English-language publications and non-English ones. It seems to be really difficult to find independent sources, and even if you do, there's a chance that someone will show up claiming that everything is
WP:PROMOTIONAL, especially if the independent source says something positive, like "biggest daily newspaper in this country" or "impact factor of 1.1 in 2022" (which are both acceptable under WP:PROMOTIONAL) instead of scandal mongering (which is explicitly prohibited in WP:PROMOTIONAL). WhatamIdoing (talk
) 01:37, 1 April 2023 (UTC)
I was referring to the wise Wugapodes' words, as quoted in
FUTON, it goes poof. Many editors only run a quick Google search, which… only gives them results in the language their Google Account is set to, English. It literally won't return any other language (how many AfD regulars have thought of that?). Many editors only check Google Books… which has tons of unreliable English books, and lacks tons of reliable foreign books. DFlhb (talk
) 01:44, 1 April 2023 (UTC)
Wugapodes' opinion was not supported by consensus in that RfC and was at odds with how sportsperson articles were and are handled. Any increase in coverage of minority populations that loosening notability criteria would afford would be vastly, vastly outweighed by the proportionally larger increase in trivial coverage of western topics, because a) in practical terms, the latter is what western editors of a western Anglophone encyclopedia are interested in; and b) by definition, marginalized topics are marginal, they have less representation in absolute terms so even if we achieved 100% coverage of them they would still be dwarfed by the non-marginal topics. JoelleJay (talk) 04:22, 1 April 2023 (UTC)
Fair, I'm dropping it. My attempts at throwing out "pie in the sky food-for-thought" and hoping other users pick out and refine "the good parts" aren't quite productive anyway; I'll focus on more concrete and practical proposals from now on. DFlhb (talk) 07:00, 1 April 2023 (UTC)
I do agree that there are a lot of noms who don't do much of a BEFORE. On the other hand, there are a lot more article creators who don't do much of a BEFORE either. JoelleJay (talk) 15:28, 1 April 2023 (UTC)
And pretty much every AfD regular is familiar with Google's language settings, which is why searches in the native language are strongly encouraged. JoelleJay (talk) 04:27, 1 April 2023 (UTC)
Yes DF, people nominating articles without putting any research into them is a big problem. The nominators are most often wrong and take stubs at face value. ♦ Dr. Blofeld 07:20, 1 April 2023 (UTC)
I would disagree on making AfD noms require more
WP:BEFORE. While many afd's are not thought out, there are also those where the nom is not sure and wants to see what the other participants think. This also means that any noms would need a fully formed Delete argument, adding to the polarization that has been pointed out. Sungodtemple (talk • contribs
) 01:18, 2 April 2023 (UTC)
If you're not sure that the article should be deleted, then why would you actually try to get the article deleted? If you just want to know what other people think, then use a talk page. WhatamIdoing (talk) 21:28, 3 April 2023 (UTC)
I intended to bring up the
WP:BEFORE issue as well. A lot of nominations are directed at subjects where it's really easy to find sources with a simple search. This particularly affects subjects outside of the Anglosphere, where searching in the subject's native language brings up countless sources (something that nominators often don't check). This is especially a problem with "prolific" AfD nominators that clog the backlog by making frequent nominations that don't seem to have undergone any sort of before search. At what point does it become disruptive to frequently nominate articles for deletion when sources can be found? Thebiguglyalien (talk
) 01:55, 2 April 2023 (UTC)
You don't have to look far for WP:BATTLEGROUND. Sungodtemple (talk • contribs) 13:59, 2 April 2023 (UTC)
I agree BEFORE needs more teeth and serial abusers called out and sanctioned. Too often AfD is used for cleanup. -- GreenC 14:22, 2 April 2023 (UTC)
The hostility issue isn't going to be solved unless
WP:CIVIL gets enforced. I have my doubts about whether that's going to happen anytime soon. Thebiguglyalien (talk
) 02:01, 2 April 2023 (UTC)
Considering that the bar for AfD discourse has been as far down the gutter as calling editors "certain species of animals that mark their territories with bodily fluids", with nobody stopping to consider that perhaps it is more than a little degrading to compare human beings to urinating animals, I have to agree with this. Gnomingstuff (talk) 15:51, 10 April 2023 (UTC)

I need only be pinged, to be aware of an AFD. Once my input is given? I can't be pushed to change it. GoodDay (talk) 02:03, 2 April 2023 (UTC)

  • I would challenge that "articles have to keep being relisted because of lack of participation" They don't actually '*have*' to be relisted. We could simply not relist them , if no-one cares enough about deleting the article for there to be adequate participation, we could just let it stay. Hosting articles is pretty cheap, and if only the nominator wants something deleted, maybe that's a good enough indication that there is no consensus for deletion. JeffUK 09:05, 5 April 2023 (UTC)
    The exact same argument can be made for deleting such articles. If no one cares enough to defend the topic, perhaps it isn't noteworthy enough to keep around. JoelleJay (talk) 20:15, 5 April 2023 (UTC)
    I'd agree with JoelleJay here. If it's notable enough to get deleted, that's its notability. Perform a WP:BEFORE and usually one can find some sources on the subject. If not, lets better someone with some more interest create one and also leave the notifications (like AfD or WLs to and from the article etc.) to the creating editor.Paradise Chronicle (talk) 20:26, 5 April 2023 (UTC)
    This is actually the current guidance on what to do for a delete nomination with no opposes - see
    WP:SOFTDELETE Galobtter (pingó mió
    ) 22:34, 5 April 2023 (UTC)
    Looks like we already have a solution to ‘lack of participation’ then! JeffUK 14:54, 6 April 2023 (UTC)
    AfD participation isn't a measure of "who cares enough" -- whether about deleting an article, or about keeping it -- but a measure of how many people either frequent AfD regularly or become aware of the existence of an AfD on Wikipedia in a one-to-two-week time span and have the spare time in that one to two weeks to do unpaid volunteer work. Gnomingstuff (talk) 16:23, 10 April 2023 (UTC)

One thing that would help many big problem areas is to gracefully teach aspiring article creators that the normal step 1 of creating an article is finding 2 GNG references (guidance on the norm, not a rule). And in order to do that we need a new category of highly vetted and organized Core information pages. Like 25 or 50 maximum. Expecting that we're going to guide newbies (or anybody) only by "rules" (policies and guidelines) or saying "here's thousands of essays, take your pick" is not a way to provide guidance. North8000 (talk) 15:01, 5 April 2023 (UTC)

  • I'm writing as someone who's already staged a massive hissy-fit walk-out from AfD, but now slunk back in. Yes, the atmosphere can be toxic. My personal approach to deal with this is largely to avoid ever going back to a debate on which I've commented. It is too easy to be drawn into a fight. I'd recommend others to do the same. Maybe we need a survival guide for being an AfD contributor. But I also think the worst debates are those that get bludgeoned or derailed by massive ref-bombing and essay-writing. I wonder whether setting a response limit would help? Maybe a maximum of 2 responses per contributor, including the nominator? Each response not to exceed X words and Y sources? If the nomination holds water, it shouldn't be necessary to defend it against every !keep vote, and if a !keep vote is good, it shouldn't be necessary to defend it against everyone who disagrees.
  • It is difficult to get the balancing act between giving people the freedom to express honestly-held views without repercussion, but also putting people under an obligation to do the job properly: not just nominate things because they don't like them without bothering to look for sources, not just defend un-sourceable non-notable things because we like them (as I once did with the famous and not-particularly lamented article on
    Anti-urination devices in Norwich
    ).
  • Minor point, it's a fundamentally bad idea that AfC contributors are assessed on their AfD statistics. This encourages those who aspire to AfC to restrict themselves to !voting in large numbers of very obvious AfDs rather than assessing the difficult cases. Anyone with really good AfD statistics is probably not contributing usefully to AfD. Elemimele (talk) 12:41, 13 April 2023 (UTC)
@North8000, agreed. XAM2175 (T) 14:25, 13 April 2023 (UTC)

AfD and RM

If an article gets nominated for both, should one of the nominations be speedily closed? If so, which one should be the best to close? Wikiexplorationandhelping (talk) 04:20, 9 April 2023 (UTC)

Personally if I see both, I'd hold off dealing with the RM until the AfD is resolved. -Kj cheetham (talk) 11:45, 9 April 2023 (UTC)
Since many editors consider moving an article while it is at AfD to be disruptive, I would add a comment to the RM discussion about the AfD, and suggest it be paused until the AfD is resolved. Donald Albury 13:33, 9 April 2023 (UTC)
Hmm, good points. I closed an RM for an article that was in an AfD process a while ago (the RM close was deleted along with the article. However, the AfD for the article, remains). After notifying a participant who goes by the name of S Marshall, he says that he does not agree with what I had done. He says that AfD isn't more important or superior to other community processes. If we started closing RMs because an AfD has begun, then we're creating an incentive for the losing side to open an AfD as a spoiling tactic. I think that he also has a fair point here, I wonder what he thinks about this?
(The ping is intended to gather consensus on this matter). Wikiexplorationandhelping (talk) 21:49, 9 April 2023 (UTC)
AfD takes precedence. If the page ends up deleted, then there's no page to be moved. GoodDay (talk) 17:05, 9 April 2023 (UTC)
I would say that the correct thing is to leave a comment at the AFD, noting the existence of the RM… and a comment at the RM noting the existence of the AFD. Then let the community work it out. We are usually pretty good at that. Blueboar (talk) 21:58, 9 April 2023 (UTC)
If we decide that AfD can overrule RM, then people who don't like the way an RM is going will have an incentive to open an AfD while the RM is still in progress. I feel that that incentive is best avoided.—S Marshall T/C 22:20, 9 April 2023 (UTC)
I agree. Moreover, Wikipedia is a work in progress site. We don't stop people from editing (improving) an article when it is at AfD. We should not stop people from renaming (improvements via consensus) the article either. All you need to do is notify people on both pages that a discussion is going on on the other side. If the RM results in "not moved" or "no consensus", nothing changes. If it results in "moved", just notify the AfD page in a visually distinctive manner that the said article is moved during AfD process and that should suffice, as I had done in the past with no issues occurring. —CX Zoom[he/him] (let's talk • {C•X}) 10:35, 10 April 2023 (UTC)
I don't know why, but after all these years, I still maintain a certain naïvité about how we have discussions where we cooperatively figure out what's best for the encyclopedia and there's no winning or losing side. Perhaps I'm just out of touch with the modern world? In any case, it's not useful to have multiple discussions about the same thing at the same time, so I'd say whichever one started first should be allowed to finish. Also, it's sometimes a legitimate outcome of an AfD to rename an article, so that one discussion could cover both. If there's an ongoing RM discussion and somebody opens an AfD as an end run around the move,
WP:TROUT is probably the right process to sort it out. -- RoySmith (talk)
22:38, 9 April 2023 (UTC)

Sunnam Village

Sunnam is a Village in Pooh Tehsil in Kinnaur District of Himachal Pradesh State, India. It is located 36 KM towards North from District head quarters Reckong Peo. 10 KM from Pooh. 167 KM from State capital Shimla

Sunnam Pin code is 172110 and postal head office is Speelo .

Ropa ( 6 KM ) , Kanam ( 11 KM ) , Hango ( 11 KM ) , Namgia ( 12 KM ) , Pooh ( 13 KM ) are the nearby Villages to Sunnam. Sunnam is surrounded by Reckong Peo Tehsil towards South , Kalpa Tehsil towards South , Nichar Tehsil towards west , Chauhara Tehsil towards west .

Shimla , Mandi , Mussoorie , Sundarnagar are the near by Cities to Sunnam.


103.155.72.118 (talk) 11:58, 15 April 2023 (UTC)

If you are trying to write an article; put your text here: Draft:Sunnam Village and then also explain where the information came from, ie sources. Graeme Bartlett (talk) 12:02, 15 April 2023 (UTC)

Connecting sections to wikidata

I think if we connected sections to wikidata it would be pretty helpful in solving issues like the Bonnie and Clyde problem. It would make a lot of things generally more easy. Immanuelle ❤️💚💙 (talk to the cutest Wikipedian) 04:59, 6 April 2023 (UTC)

I don't know if connecting it to sections would work (as sections can change without warning), but some way to designate that "topic X exists as a section within article Y" would be really useful. Thebiguglyalien (talk) 05:17, 6 April 2023 (UTC)
We can now connect a redirect to wikidata, even if it is a redirect to a section. Debatably, this is even better than connecting a section, as the connection moves automatically if the redirect is upgraded to an article on the subtopic. (The mechanics of connecting the redirect are non-obvious; you have to click the icon (light bulb? rosette?) to the right of the title and select "Intentional sitelink to redirect" from the dropdown to make Publish clickable.) Certes (talk) 14:33, 6 April 2023 (UTC)
That is a great approach! Newystats (talk) 13:17, 15 April 2023 (UTC)
  • The less we point to Wikidata the better. Blueboar (talk) 15:35, 6 April 2023 (UTC)
    This isn't really "pointing to" Wikidata, except that the Tools menu in the left sidebar may gain a discreet "Wikidata item" link, and even that only appears if someone views the redirect page with &redirect=no. No one is proposing to display Wikidata values within a Wikipedia article here. Certes (talk) 17:23, 6 April 2023 (UTC)
The 'Bonnie and Clyde' problem has been solved, but this would help more in events, where e.g. a perpetrator has a section in an event, rather than their own article. JeffUK 10:50, 7 April 2023 (UTC)

Definition of Wikipedia editor

Comments would be appreciated at Template talk:Registered editors by edit count#Misleading. The discussion is about the definition of editor on Wikipedia. Are editors only those who have made one or more actual edits while logged in with a username, or do people who have a username but have never edited also called "editors". It makes a difference within the charts and tables included within the discussions. Thanks. Randy Kryn (talk) 15:49, 14 April 2023 (UTC)

If people have logged in with a username, and so have set up a user page, would not doing this constitute one edit of Wikipedia? YTKJ (talk) 21:12, 16 April 2023 (UTC)
Logging in does not create a user page. (Also, please go the link in Randy Kryn's comment, to the location where the topic is under discussion. This thread was just a notification for interested editors.) Schazjmd (talk) 21:16, 16 April 2023 (UTC)

When viewing contributions from IPv6 address show a link to the /64 range contributions

Since IPv6 often change so that a /64 range usually means a single user it would be helpful to have link to the /64 range when viewing the contributions of a single IPv6 address. For example Special:Contributions/2001:14BA:3F9:3B00:29F6:AD90:58AE:5715 would have a link to Special:Contributions/2001:14BA:3F9:3B00:0:0:0:0/64. MKFI (talk) 11:20, 14 April 2023 (UTC)

@MKFI I added it to the footer, how's that? — xaosflux Talk 12:44, 14 April 2023 (UTC)
Not good, because the last four groups need to be all zeros (or ::) or you won't get all IPs in the range. I already made a mockup a couple years ago, maybe you can deploy it. Nardog (talk) 12:50, 14 April 2023 (UTC)
I'm not sure you have that right. You can append /64 to any single IPv6 used on Wikipedia. It's even a preferred method in some cases. One problem this change does raise is that it adds /64 on to every IPv6 range. If you're looking at a /32 it becomes ../32/64. I believe your solution probably fixes that. -- zzuuzz (talk) 13:11, 14 April 2023 (UTC)
@Nardog that shouldn't be needed anymore, notice the output at Special:Contributions/2001:14BA:3F9:3B00:29F6:AD90:58AE:5715/64. — xaosflux Talk 15:30, 14 April 2023 (UTC)
Something between the 2 would probably be optimal (just add /64, but only if it doesn't have a / already)? Feel free to drop an edit request at Template talk:Anontools with suggested improvements of course! — xaosflux Talk 15:32, 14 April 2023 (UTC)
Why would you keep the last four groups? Even if what Zzuuzz says is right, each IP would have a different URL to what is essentially the same page, which is not good. Nardog (talk) 15:39, 14 April 2023 (UTC)
Essentially the same page, but not the same. If you look at the /64 link at the page for the single address, it doesn't take you to 2001:14BA:3F9:3B00::/64 (although it very much looks like it). It actually retains the single IP address in the contributions field and the address bar. This fits into my workflow a lot and can be useful in various situations. For example, narrowing the range, or blocking a single IP. I'm kinda with what RoySmith is saying, but don't particularly mind either link as long as it's not broken. Given a choice I'd prefer to retain the detail, especially since it does no harm. -- zzuuzz (talk) 16:01, 14 April 2023 (UTC)
I meant replacing it. Something is clearly needed if a /64 page has a link to /64. Nardog (talk) 15:37, 14 April 2023 (UTC)
It is true that v6 addresses are often allocated in /64 chunks, but that's not always the case. It's very much not the case in some parts of the world. And even in parts of the world where it's common practice, different wireless companies do it, or don't do it, or even do it on parts of their network and not others. It's not something we want to embed too deeply. -- RoySmith (talk) 15:45, 14 April 2023 (UTC)
@Xaosflux: Please revert the change. It's clear there isn't consensus how or whether it should be done. Nardog (talk) 16:15, 14 April 2023 (UTC)
We'll assume that's going to be the default action, but can we just save a few CPU cycles and see if we can agree a change first? I don't think it's going to be complicated (unless RoySmith is actually objecting). -- zzuuzz (talk) 16:23, 14 April 2023 (UTC)
Not with your route. I hate it when links to what is essentially the same page have different URLs and thus clog up my browser history or fail to turn purple. Nardog (talk) 16:29, 14 April 2023 (UTC)
I don't know how strongly I'm objecting, but yeah, I think that would not be ideal because it would give a false impression of the importance of the /64 boundary. For people who understand CIDR addressing, it's easy enough to append /nn to the existing form field or url, so I don't see this would buy us anything. This seems like user script territory, not something to be embedded in the interface. -- RoySmith (talk) 18:15, 14 April 2023 (UTC)
Of course per
WP:BRD, now at step 3 if anyone comes up with a consensus. — xaosflux Talk
16:40, 14 April 2023 (UTC)
FWIW mediawiki already knows if it is on a range or single ip (e.g. Mediawiki:sp-contributions-footer-anon-range vs Mediawiki:sp-contributions-footer-anon - it is just that we are loading the same pile of templates on both of them right now. — xaosflux Talk 18:41, 14 April 2023 (UTC)
I don't have anything to contribute directly to this question, but I want to remind you that m:IP masking will be happening during the next year, and this will have some effects on what is/isn't visible. Most high-volume editors will be able to get the IP address in the future, but I'm not sure whether ordinary editors will be able to find other accounts that are using the same IP addresses. Whatamidoing (WMF) (talk) 19:23, 17 April 2023 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_199&oldid=1151928162"