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.
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:SIZE and WP:SPLIT. There were strong arguments against removal, including needing to summarize the removed content (wherever it lands) per 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., 2022) be WP:SPLIT into separate articles? RFC posted 18:27, 1 February 2023 (UTC)
Support as proposer. The year articles are very long (e.g. 2022 is 206k, 2021 is 227k, 2020 is 360k, 2019 is 316k, 2018 is a comparatively lean 153k). The Births and Deaths sections take up half the pages or more by my eye. Moving them to sub-pages (e.g. Deaths in 2022) is the fastest and easiest way to cut year articles down by about half and finally comply with WP:SIZE, while still having a place to put the content. Note we already have List of deaths by year, Deaths in December 2022 and so forth. (If a death itself was a significant event and not just "old person dies", e.g., an assassination of a world leader, it would still be listed in the "events" sections.) Levivich (talk) 18:27, 1 February 2023 (UTC)
I support splitting them out from the main year articles. I don't really have a strong opinion about how the sub-articles are organized (e.g. by year or month). Levivich (talk) 18:39, 1 February 2023 (UTC)
Monthly articles are for all deaths of internationally notable people. Those on main year articles are only for those who have substantial international notability. Jim Michael 2 (talk) 18:42, 1 February 2023 (UTC)
International notability as it has been practiced on year articles is already being questioned as a criteria, as it has been both too arbitrary in what it means and is the subject for all these content disputes. InvadingInvader (userpage, talk) 07:17, 6 February 2023 (UTC)
Correct. As a frequent contributor to US Years articles, this has been hugely beneficial as we have had more time to add in events without having to be worried about article size due to these deaths. InvadingInvader (userpage, talk) 01:27, 6 February 2023 (UTC)
In my view it's not about how far back, it's about how large the page is. Any page that doesn't need to be WP:SPLIT because it already complies with WP:SIZE shouldn't be split. Levivich (talk) 18:49, 1 February 2023 (UTC)
Support. This has been my position for a while. Beyond size considerations, most births and deaths are not notable in their own right. Births and deaths are a WP:MINORASPECT of each given year, and they do not warrant such massive coverage in the year's article. The inclusion of births and deaths is a relic of before Wikipedia was standardized, and the year articles are late to catch up. Thebiguglyalien (talk) 18:50, 1 February 2023 (UTC)
Oppose we shouldn't be having discussions about major changes to layout & inclusion criteria of main year articles when their best editor is absent. Jim Michael 2 (talk) 19:20, 1 February 2023 (UTC)
We don't know, but the recent discussions about major aspects of main year articles on here & on Years are incomplete without her. Jim Michael 2 (talk) 19:34, 1 February 2023 (UTC)
Deb's input is valuable and I hope we have a chance to hear it, and I hope she's having fun while on wikibreak, but I can't imagine Deb ever suggesting we not have an RFC while she is on a wikibreak that's lasted three weeks and will continue for an unknown duration. Levivich (talk) 19:42, 1 February 2023 (UTC)
Of course I would not suggest that :-) I was away for 4 weeks but for obvious reasons I didn't give out that information on my user page. I am fairly neutral on this proposal, but I have to say I am not sure it will have much effect. Year articles should undoubtedly be shorter. I also don't object in principle to summaries. Unfortunately I can't see anyone willing to put in the work to ensure that the global picture is what we get, as opposed to duplication of what's in the article on the United States. I see some people (below) already suggesting that the articles should include everything that is "newsworthy", which may just mean relocating the problem. Deb (talk) 17:52, 7 February 2023 (UTC)
Welcome back! We've written several novels about year articles in your absence, apologies for all the reading to catch up on :-) Levivich (talk) 18:11, 7 February 2023 (UTC)
Splitting the long ones makes sense. Oppose making a general rule (if the list is short, keep everything together). —Kusma (talk) 19:37, 1 February 2023 (UTC)
If their birth or death is newsworthy, it should be included in the article. Otherwise, we're picking and choosing who gets to qualify, which is what we've already done by having articles on them in the first place. I propose removing all lists of births and deaths and relying on categories. Otherwise, what even are categories for? --Golbez (talk) 21:14, 1 February 2023 (UTC)
How do you define newsworthy? There's a much higher bar to be in main year articles than to have a WP article. Cats are for many things. Jim Michael 2 (talk) 21:38, 1 February 2023 (UTC)
Dying in office. New heir apparent born. First [x] born in [y]. Last person killed by [z]. That kind of thing. And you say there's a higher bar, I say there should be no bar. They should only be included in the year article if they were somehow significant to that year, right? So either their birth is notable, their death is notable, or their actions in life are notable. Everything else, that's (at risk of repeating myself) what we have categories for. --Golbez (talk) 22:38, 1 February 2023 (UTC)
You really don't think the assassination of Shinzo Abe wouldn't be mentioned? You seem to still think I'm arguing for a discrete "here are the important people who died" list. No, I'm saying, include them in the actual list of events, if their birth or death was actually notable. I'm pretty sure Abe's is. --Golbez (talk) 23:07, 1 February 2023 (UTC)
Their deaths, in themselves? Sure. Looks like Pele's funeral was a major event though, so that would probably be included. You do realize that all I'm suggesting is that, if people want to find out who died in 2022, they look at the category of people who died in 2022. That's all. There's no need to duplicate efforts in a year article, especially since then it just becomes a popularity contest of who gets included. --Golbez (talk) 23:58, 1 February 2023 (UTC)
That cat has multiple times more people in it. The deaths in main year articles are only of those that have substantial international notability. You're implying that thousands of editors have pointlessly made those lists on main year articles during the last two decades. Jim Michael 2 (talk) 00:31, 2 February 2023 (UTC)
Many people go to main year articles to see lists of the internationally notable people who died that year. Such lists are nowhere else on WP. Jim Michael 2 (talk) 11:50, 2 February 2023 (UTC)
Why? Why do they go to the list? I'm not being facetious. If they want to know who died in the year, that's what the category is for. If they want to know who famous died in the year, well, first of all, if they're on Wikipedia they've already passed notability. Secondly, they aren't going to find the famous people - they're going to find what a tiny subset of a subset of Wikipedia decided were the people worth mentioning. I know this isn't going to change, and I'm not about to right some great wrong with this argument. But I will defend it. --Golbez (talk) 16:19, 2 February 2023 (UTC)
Those cats include a huge number of people. The deaths lists in main year articles are those who have substantial international notability. The criteria have been discussed at length. Jim Michael 2 (talk) 18:09, 2 February 2023 (UTC)
Very weak support I think that this is an axe being asked to do a scalpel's job. Yes, if the article is too long per WP:ARTICLESIZE, than births and deaths make a good target for spinning out into their own articles. However, to say that we need to do so for all year articles is a bridge too far. I'd be okay with guidance that says "If a year article is too long, then it should be considered to split the birth and death sections as their own articles" however, this wouldn't be even necessary for most year articles. Picking a few random years 175 (not needed), 1211 (not needed), 1472 (not needed), 1811 (a bit of a longer article than the rest, but probably still not needed), 1877 (getting longer still. Probably not needed, but reaching the edge-case territory), 1922 (needed, being overwhelmed by births and deaths, and reaching the "probably a bit too long" area), 1988, (likely needed). Given that data, I'd be fine with setting a cutoff of 1900 or later, but even still, we should be careful about how we do this. The current proposal is far too broad. We need to tailor it to actually fix the problem at hand. --Jayron3212:08, 2 February 2023 (UTC)
Support, the WP:SIZE argument applicability gets tricky as this mixes prose and lists, but perhaps that is another argument for a WP:STANDALONE list. Most of the year articles are just lists of course, but they could be much more! Even without that step, I suspect any prose would develop from the events sections, not the births and deaths, so spinning off the undue elements makes sense. (As mentioned above but to clarify, births and deaths that would make the event section are of course fine in the main articles.) CMD (talk) 12:30, 2 February 2023 (UTC)
Comment If births & deaths are to be split off main year articles, for which years would this be done? Recent year articles have the most deaths in them, but far fewer births. Jim Michael 2 (talk) 12:35, 2 February 2023 (UTC)
It should only be a size issue. If the births section is not too big, don't split it. It's not that complicated. --Jayron3213:06, 2 February 2023 (UTC)
I'm not saying it doesn't, but there isn't an exact size at which we should split, so how many main year articles should the births be split off from? How many for the deaths? Jim Michael 2 (talk) 15:49, 2 February 2023 (UTC)
I'm not convinced that it's not. The way the discussion seems to be heading, we're in danger of creating two articles of unmanageable length in place of the existing ones, with the same debate over "international notability" having to continue. Deb (talk) 13:29, 9 February 2023 (UTC)
Support Split any article that is over 125K in size (but not with a hard and fast rule: aim for less than or ~100K final article size, if possible.) GenQuest"scribble"16:11, 2 February 2023 (UTC)
Support removal, this is what categories are for. No need to split. Just delete. If categories aren't up to the task, then we need to improve how categories work. (can't help but wonder if this is where my 20 year old Semantic Wikipedia proposal would have come in handy...)[citation needed] --Golbez (talk) 16:37, 2 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)
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 ~ LindsayHello16: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 Viktor Mazin or Josef Panáček due to winning gold in the Olympics despite a lack of potential 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. JeffUK12: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. JeffUK12: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. JeffUK19: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:RS that might publish a 'year in review' editorial would be WP:Secondary sources with functions and policies which allow for editorial discretion in making such a list. This project is a WP:tertiary source, an encyclopedia, meant to summarize the positions of primary and secondary sources, with neutrality policies that greater constrain our ability to pick favourites, so to speak, from among topics, on the basis of personal judgment of what is an "important" topic. There seems to be a problem understanding that point of policy and community consensus so far at WikiProject Years, and thus no suggestion (that I have seen presented anyway, from my indirect view of the project and the recent related VP and ANI discussions) that is based in 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 rap02: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)
Support. I actually think that the need to curtail content on these articles may be at least somewhat exaggerated, in the WP:NOTPAPER sense. But if the choice is going to be between 1) allowing users to run around applying thinly-veiled WP:OR criteria as to the "importance" of this or that person based on nothing nothing remotely tethered to WP:WEIGHT or, 2) simply sequestering the content into separate articles to reduce the perceived need to constantly be asserting policy non-compliant personal calls as an excuse to "prune" the article to personal taste of importance, and then rationalize it by page byte size, then I have to choose the latter. That's unlikely to stop the arguments based on subjective calls in the Years articles altogether, nor completely forestall debates in the death/birth offshoot articles, but it is a start. If the Year regulars come up with a WEIGHT-centered test for inclusion of a summary section in the main years articles that the community can get behind, we can then make that adjustment as well. For the meantime, a clear break moving all death/birth entries to a separate list seems like a workable system. SnowRise let's rap02:31, 11 February 2023 (UTC)
I personally doubt that such a measure can be agreed upon. When I try to propose criteria myself, I feel that too many people follow an "all or nothing" approach, either restricting ourselves to the old "international notability" standards or including everybody. Frequently, I remember seeing Jim Michael 2 before his TBAN and 4me689 make a lot of these arguments, like "by including Robbie Coltrane we must include Anne Heche" or "we must include Takeoff because we included Coolio". I also remember Scrubby making a lot of anti-Americentric arguments, but there came a point where it at least seemed his position was less anti-Americentric and more so exclude because they're American, which is worse. My attempts to persuade editors into a more consensus-based system not rooted in a standard have all but failed. I think that my support of the removal of deaths, as much as it is rooted in article size, is even more intended to prevent chronic and energy-draining debates. As dumb as the following sounds, it's come to the point where I felt I've been losing my Monday and Friday chess games partly because I used most or all of my brain energy to argue in favor of including Barbara Walters. InvadingInvader (userpage, talk) 21:18, 11 February 2023 (UTC)
Strong oppose - We'd need to be consistent with every single year to do this. It would be strange to have some years with sections for births and deaths and others not. In practice, this would create hundreds of new articles. Tim O'Doherty (talk) 17:58, 18 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.
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)
Like Izno mentioned in that other discussion, there was an RFC about this (I don't remember where either, I just remember participating in it). My memory of the RFC is that there is consensus to have a link under the title, even if that link duplicates another link like OCLC or DOI. Oppose making them errors, as they are not errors. We don't need to take the choice away from editors; let them add a dupe link if they want. The reason is that not everyone knows what an OCLC or a DOI is, but everyone knows to click the link under the title. Levivich (talk) 22:25, 8 March 2023 (UTC)
Yup, thank you, that's the RFC that concluded with "There is consensus against removing a parameter just because it is a duplicate. However, there is an agreement that sometimes removing duplicates can be appropriate. This decision should be made on an article by article basis, unless it is a copyright violation for which there is consensus to remove." WP:CCC but it needs a new WP:RFC. Levivich (talk) 03:20, 9 March 2023 (UTC)
Support – As pointed out, such a URL is a) an exact duplicate of the link provided by the parameter |oclc=; b) creates a wrong impression of a link to the actual work. IIRC, the DOI (and JSTOR) links are treated differently if they give free access. -- Michael Bednarek (talk) 00:34, 9 March 2023 (UTC)
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 Albury23:51, 11 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.
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)
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]
@Bob K31416That 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)
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)
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)
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)
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, — xaosfluxTalk09: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
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
Psyche
Gonggong
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?
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)
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 MarshallT/C21: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)
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. Femke (alt) (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)
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)
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)
Conditional Oppose if this is going to end up breaking the "remember my last editor" option - users should get a consistent experience. — xaosfluxTalk14: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? — xaosfluxTalk16: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)
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)
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)
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. — Rhododendritestalk \\ 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)
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. --Jayron3216: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 jarstc10: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 jarstc18: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)
@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)
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 here04: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 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!
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? — Rhododendritestalk \\ 16:02, 7 March 2023 (UTC)
@Rhododendrites: I mean when two different refs have same name (like that:[1][2], same refs with unique names:[3][4]). 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)
@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:
[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
[3]Useful table is copypasted to new template - ref still has name ":0"
[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
[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
^MiG-31 Foxhound. Harrassing Spy Planes for Dummies. Moscow: Mikoyan.{{cite book}}: 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)
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.
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)
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. — Rhododendritestalk \\ 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? — Rhododendritestalk \\ 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)
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. Blofeld11:52, 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)
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)
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)
I was opposed at WT:DYK, and I haven't really seen any good arguments for protection. Moves of DYK items are rare, and incorrect moves more so. Where is the problem that is being solved here? —Kusma (talk) 18:51, 8 March 2023 (UTC)
Oppose, pages are not protected pre-emptively, and no substantial argument to deviate from this principle has been presented. —Kusma (talk) 19:28, 8 March 2023 (UTC)
Support We have WP:MPNOREDIRECT and any move ends up at WP:ERRORS. That alone is reason enough to do this as there’s too much traffic at Errors. Most main page moves occur through WP:ITN, though. If we get this working smoothly for DYK, we can later discuss whether we want to broaden the scope to ITN. There’s hardly ever anything urgent about a move but if it is urgent, it can be done by an admin who can also resolve the redirect on the main page. Schwede6619:14, 8 March 2023 (UTC)
"An edit will need to be made to a protected page after the move" is an incredibly weak argument for default protection. Do you also want to protect all pages linked from the TFA blurb? —Kusma (talk) 19:25, 8 March 2023 (UTC)
Support as per the previous discussion: it interferes with history compilation in any number of fields and allows non-admins to screw with what's linked from the main page. I think that should require consensus. It would also be weird and arbitrary to move-protect TFAs and not DYKs, even though the bolded links of DYK on any given day roughly match the TFA views bump. I'll also point out that any kind of maintenance tag or merge or AfD nomination can't be added while an article is on the Main Page; if consensus isn't gained to pull the article off of DYK, the tag is removed and any nomination closed. We already have fairly extensive rules preventing good faith tagging of articles while they're on the Main Page; RMs and moves shouldn't be an exception. theleekycauldron (talk • contribs) (she/her) 20:02, 8 March 2023 (UTC)
Leeky, do you have a link to the rules about tag bombing articles on the main page? I got into a tussle in January with someone who tag bombed the TFA. (Over a template calling for revdel of an alleged copyvio in the history ie something not only not urgent, but did not need to be done at all.) Hawkeye7(discuss)00:33, 9 March 2023 (UTC)
WP:Did you know/Supplementary guidelines#F7 says F7 (article title): Make sure your article title conforms with Wikipedia:Manual of Style (titles). But I don't regard this as sufficient reason for a pull, especially given that the WP:RM process may not approve renaming. I don't regard tag bombing as a reason either. I 've had articles tag bombed. In one case, an editor felt entitled to tag bomb for notability even after an article was kept at AfD. Hawkeye7(discuss)23:17, 9 March 2023 (UTC)
Support We shouldn't allow vandals to attack the front page. No other reason why someone would want to move an article while it is on the front page. Hawkeye7(discuss)20:17, 8 March 2023 (UTC)
Do you have any evidence that most page moves of DYK pages are vandalism? I honestly can't recall the last time it happened. —Kusma (talk) 20:54, 8 March 2023 (UTC)
If a page needs to be disambiguated or similar, you just move it without going through WP:RM. See WP:NOTRM. As there are many cases where WP:BOLD moves are encouraged, it is usually unnecessary to invoke WP:IAR. —Kusma (talk) 23:23, 9 March 2023 (UTC)
I compared the number of entries in Special:Log/move vs the number of discussions in Wikipedia:Requested moves/Current discussions last week, and I think it's fair to say that >90% of page moves don't involve the RM process. DYK involves mostly new articles, which probably have a higher rate of appropriate/non-vandal page moves than average. But even then, it just doesn't seem to happen much. DYKs are only on the Main Page for a few hours. Can anyone name even three DYKs that were moved during the few hours the article was on the Main Page? I can't. WhatamIdoing (talk) 21:08, 15 March 2023 (UTC)
Support It is sensible to protect. A move can be requested at WP:ERRORS. Agree with Schwede66 that There’s hardly ever anything urgent about a move but if it is urgent, it can be done by an admin who can also resolve the redirect on the main pageBruxton (talk) 21:21, 8 March 2023 (UTC)
@Legoktm: What's a little confusing here is that as far as I can tell, this type of question has already been decided for TFA (see Wikipedia:Bots/Requests for approval/TFA Protector Bot 3. There's no particular difference between DYK and TFA (or, for that matter, ITN, etc). We should have a uniform policy for all main page content. The details might change for each section to accommodate the differences in process, but the basic policy should be the same. -- RoySmith(talk)01:52, 9 March 2023 (UTC)
@RoySmith: you mean TFA Prot Bot 1, which was for move protection? My recollection when I took on that task is that people had been manually move-protecting the TFA for years (and even automatically with some unapproved adminbots) and the bot was just automating what was the custom, not introducing a new practice. Legoktm (talk) 04:23, 9 March 2023 (UTC)
Cmnt: Has there been a huge problem with what this is trying to prevent? It seems to me, at this point, to just be policy-creep. GenQuest"scribble"02:17, 9 March 2023 (UTC)
oppose not even one case has been supplied of a problem move. Since the DYK articles are usually new, there is a much bigger chance that a rename to something better is in order. For a TFA, that has gone through a long careful process by several people, so we can be sure it is at the best name already. As long as a redirect is working, reporting at WP:ERRORS is unnecessary. Graeme Bartlett (talk) 02:44, 9 March 2023 (UTC)
@Schierbecker: speaking as someone who's helped maintain DYK's stats pages for over a year, you're right that barely any single DYK matches a TFA view-for-view. But that's only because DYK runs eight or even sixteen hooks a day, splitting attention; a much fairer comparison would be looking at how many views all DYKs get in a day, compared to TFA. They're in the same order of magnitude – DYK gets some 40-50k views a day, last I checked, which is comparable with lots of TFAs. theleekycauldron (talk • contribs) (she/her) 18:13, 9 March 2023 (UTC)
@Schierbecker: yes... pages on TFA. I mean, you pointed out that DYKs don't get enough views to justify protection, compared to TFA – I'm just pointing out that in the aggregate, the two are actually quite comparable in that respect. If it's not about page views, that fine, but saying that would directly contravene your initial !vote. theleekycauldron (talk • contribs) (she/her) 21:24, 9 March 2023 (UTC)
I don't think it makes sense to think about this in the aggregate. There are some 8 hooks refreshed every 12 hours. An inappropriate page move to a DYK entry will be caught before too many readers see it. Your comparison to the practice of protecting TFAs is not quite on the mark. There will almost never be a reason to unilaterally move a TFA. Schierbecker (talk) 21:42, 9 March 2023 (UTC)
How often do we fix redirects from the main page, and how often is that caused by a DYK? I've had a look through the history of Wikipedia:Main Page/Errors and searched for the term "redirect", going back to Jan 2022. Obviously, that method won't find all instances, but it gives an idea. Also note that it's not necessarily the target article that causes the redirect. There are unders and overs, I suppose. Schwede6605:10, 9 March 2023 (UTC)
Oppose. This is a solution in search of a problem. Policy is against pre-emptive protection and there's no evidence that page-move vandalism is a problem on DYK. Yes, we move-protect TFAs; I'm not entirely sure that's necessary (and note that the bot for that doesn't interfere with existing protection) but TFA is much higher profile than DYK and featured articles (and their titles) have been subject to much more scrutiny than DYKs which, by definition, are often new articles. I don't see anything to suggest that move-protecting DYKs by default is necessary or helpful. We haven't needed it thus far in all the years that DYK has existed and all the thousands of articles that have been through it, nor have we thought it necessary for ITN or OTD, so I don't see it being necessary now. HJ Mitchell | Penny for your thoughts?14:35, 9 March 2023 (UTC)
Support It's only for a few days for heaven's sake, and the correct thing to do is almost always to launch a WP:RM discussion, not just move the page on a whim. This has happened to a nom of mine (of course I immediately reverted, & the editor never came back) and happens not infrequently. I don't really understand the opposes. Johnbod (talk) 15:09, 9 March 2023 (UTC)
Oppose'. We do not preemptively protect. I think that bold moves can be a benefit to the project, particularly when titles are grossly out-of-line with relevant naming conventions, and merely being nominated for DYK does not warrant move protection as such. — Red-tailed hawk(nest)16:25, 9 March 2023 (UTC)
Bold moves can be a benefit (I do some myself), but usually they aren't - they are just new editors, those with a cranky set idea, or more experienced editors too lazy to follow procedure & start an RM (I revert far more than I do myself). Being on the main page naturally attracts far more of them. The DYK reviewing process results in most really bad misnaming issues being resolved before this would apply. Johnbod (talk) 16:54, 9 March 2023 (UTC)
Oppose. We should have less rules protecting DYK, not more (e.g. the "no tags on articles on the Main Page" rule, even though we have things like Wikipedia:Articles for deletion/Basilico's where an article is DYK'ed and AfD'ed on the same day, and ends up deleted). As said above, a solution in search of a problem. Fram (talk) 16:39, 9 March 2023 (UTC)
Support and would also support extending this to all articles on the main page. Highly visible content, and there will almost never be a significant benefit to moving it unilaterally during the 12/24 hours an article is on AFD, but there can be a detrimental effect. Given that only admins can add content to the main page, we shouldn't being allowing anyone to defacto edit the content once it's on the main page. Pre-emptive protection for something highly visible seems fine to me, as it is used elsewhere e.g. protecting images on the main page and all highly used templates are both done pre-emptively, so I don't agree with the argument that pre-emptive protection shouldn't also be done for DYK (and other main page content). Joseph2302 (talk) 17:21, 9 March 2023 (UTC)
Protection of Main Page images and of highly used templates is a response to frequent vandalism before we had these protections. (It was popular for a while to insert shock images via template vandalism). Moves of DYK items or other Main Page linked items are not a frequent type of vandalism, and so we do not move protect these pages. Note also that all pages are already protected from moves by non-autoconfirmed editors. —Kusma (talk) 23:28, 9 March 2023 (UTC)
Support for bold links. The Main Page is highly visible, and WP:MPNOREDIRECT does not allow redirects on the Main Page. Protecting bold-linked pages would prevent page-move vandalism; even though we don't typically preemptively protect articles, we already do so for TFAs. I don't agree that we should be allowing people to move bold-linked pages boldly, if you will, while they're on the Main Page. If a bold-linked page needs to be moved so urgently that someone can't wait 24 hours (until the article is off the Main Page), a user could always file a request at WP:RMTR#Administrator needed. – Epicgenius (talk) 18:04, 9 March 2023 (UTC)
Just because a page is linked from the Main Page shouldn't stop usual wiki rules form applying. On the contrary, pages linked from the Main Page should be as open to editing (including editing the page title) as reasonably possible. The approach of not protecting seems to be working so far, so I don't see why we should change it. As to WP:MPNOREDIRECT: this is not some law, it is just a rule we have to make certain types of vandalism less effective if the redirect is less watched than the target. Page moves don't change the number of watchers, so this isn't a particular strong argument when applied to redirects created by page moves. I guess one of the reasons we don't see a lot of vandalism of DYK items via page moves is that it is not really more effective than just vandalising the pages directly, and additionally requires an autoconfirmed account. —Kusma (talk) 23:41, 9 March 2023 (UTC)
@Kusma, I understand your point. However, I should specify that the reason I'm in favor of temporarily protecting these pages is not only because of page-move vandalism, but also because the resulting redirects can be hijacked. I realize that community consensus is trending against this proposal, anyway, but I think WP:MOVP can be interpreted as allowing current DYKs to be protected. The policy says that Highly visible pages that have no reason to be moved can be protected, and I think this may apply to DYKs currently on the main page, which typically receive thousands of views during their DYK appearances. – Epicgenius (talk) 23:36, 10 March 2023 (UTC)
Weak Oppose we should avoid having sysop-flagged bots unless there's a clear need to address. In the last discussion the only move identified was a positive one, and occurrence is so rare that the no MP redirects issue could easily be fixed manually through the errors process, and isn't that significant a concern to begin with. I don't feel too strongly on this as move-protection does not merit the same degree of concern that editing protection does, and the fact that moves aren't happening at all to any significant degree cuts both ways. I wish this had been brought here first prior to any work being put in, but there's nothing that can be done about that now. 74.73.224.126 (talk) 17:55, 10 March 2023 (UTC)
Oppose - the protection policy very clearly instructs not to protect pages except in response to disruptive editing. While we do sometimes make blanket exceptions (such as WP:HRT) it is (with good reason) a very high bar to demonstrate being a net positive over the potential for harm. Despite having been asked several times and having had ample time to respond, the supporters of this preemptive protection have not provided any evidence demonstrating that that is the case here. There's no pattern of disruptive page moves of articles listed at DYK, and even if there were there's little risk of widespread harm owing to how little time these links are visible on the main page, how many eyes are on them already, and how easily they can be corrected. It has also been pointed out at BRFA that automatically protecting these pages would replace any existing move protection set by an admin for good reason, and then it would expire back to no protection. That's a pretty significant risk of harm, particularly for GAs and BLPs. So in summary there are no good reasons to do this, and several good reasons not to. Ivanvector (Talk/Edits) 18:28, 10 March 2023 (UTC)
Oppose: nobody seems to have provided any evidence that there is a problem that this will solve. We shouldn't depart from the general policy of not protecting pre-emptively if we can't even demonstrate there's an issue to be solved. Caeciliusinhorto (talk) 19:20, 10 March 2023 (UTC)
Oppose per WP:NO-PREEMPT. The very first thing the main page says is "Welcome to Wikipedia, the free encyclopedia that anyone can edit.", and I take that last part seriously. We shouldn't pre-empt contributions for merely speculative reasons. Colin M (talk) 16:53, 20 March 2023 (UTC)
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.
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)
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)
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.
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)
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)
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. -- GreenC02:37, 22 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 Albury01: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 Albury18: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 Albury00:40, 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. -- GreenC00: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 Purple, the image of Elizabeth II needs only to say that it is a picture of an (elderly) woman wearing a purple hat and coat, at Windsor, Berkshire, 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)
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)
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)
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 Chidgk1 who posted this on Phabricator (dual-licensed CC-BY-SA and GPL): I sometimes add pics on a Wikipedia for which I am not a native speaker so it would be very hard for me to write alt text there. Conversely as a native English speaker if I write the alt text once then those with poor English can easily benefit later when they add the same pic to another article. EpicPupper (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)
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.
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). BD2412T23: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. BD2412T04: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 Fuchstalk20: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 here04:04, 18 February 2023 (UTC)
Having carefully studied all the arguments, I propose possible solutions to these issues:
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.
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.
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.
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)
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. Blofeld17: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.
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, Rosguilltalk17:54, 20 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 Albury13: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)
I think you are optimistic that that wouldn't have any impact on the individuals writing (including the risk that editors who might indeed have taken something to FA without it, decide to take it to a good level and then ask for the research grant - and not progressing if they don't receive it). Perhaps more significantly, it would give the WMF a means to push content they wanted to see more of - indirect Editor status, and the WMF has public, established, social and political positions that (for example) en-wiki has !voted and confirmed a neutrality on. Nosebagbear (talk) 23:06, 1 March 2023 (UTC)
Maybe. But when you consider that last year the Foundation found it had $1 million of funds left over, & the TPB decided that the best use for these moneys was to donate them to 4 non-profits that had a tangential connection to the goals of the Wikipedias, Wikisources, Commons, etc., I believe that the risk of editorial contamination by the Foundation is a risk worth taking. -- llywrch (talk) 05:54, 3 April 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)
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)
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)
Wikipedia:Requests for comment/Rollback of Vector 2022 was moved from this page due to its large volume of comments. It has now closed with no consensus to rollback the default skin on the English Wikipedia to Vector 2010, but noting a numerical majority in support of rolling back. Where do we go from here? For challenged edits, we don't allow bold changes to stand simply because there is no consensus to roll back – we restore the status quo ante unless there is consensus to change – but this change is not an edit. Is this a case of 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)
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)
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.
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. ToaNidhiki0523:45, 16 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. ToaNidhiki0500:11, 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)
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)
@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)
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 jarstc22:23, 18 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)
@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 jarstc16: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)
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. SilverserenC03:01, 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)
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:
The people closing the original RfC had a tough job, & no matter how they closed the discussion people would have been unhappy.
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.
"Any information" is overly broad for other namespaces. That being said, it's probably simpler for the target audience of new editors to avoid getting into the details. isaacl (talk) 16:39, 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. ~ ONUnicorn(Talk|Contribs)problem solving18: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.
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.
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)
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)
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 MothTalkContribs19: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. EpicPupper (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. Blofeld15: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. --Jayron3215: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. Blofeld15: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? --Jayron3216: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. Blofeld16:16, 29 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). -- GreenC16: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.
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 embassies that was supposed to provide some of the functionality you suggest, but it seems to be little-used by the English Wikipedia in either direction. 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. Blofeld19: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 today's list, for example, I see three discussions that were relisted after having received no other input than a single delete !vote; according to 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)
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:
Reduce the sheer quantity and thus the shortage of participants
Reduce the "production line" type nature of the task
Reduce the need for relisting
Make it not be the place when newbies (with angst and pain) learn what wp:notability is and that it isn't about notability
Reduce the "search the world for references" / guilt for not doing so part of the job
#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. -- GreenC20:00, 29 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... :/ — Rhododendritestalk \\ 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. Blofeld11: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. Blofeld11: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. :) — Rhododendritestalk \\ 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. -- GreenC14: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)
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...
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 this RfC close. The fact is, many AfDs are unrigorous or poorly attended, and if it's not 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. Blofeld07: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)
The atmosphere on AfD will always remain on the level described above because of the fundamental way AfD works. The stakes are high, since the AfD outcome is more or less permanent. The scope for disagreement is as high as possible, since participants are encouraged to explore the totality of existing sources rather than focus on the article itself, and there are also too many voting options to choose from. The status of BEFORE is controversial, and closers and relisters are seldom helpful since they don't usually quote any policies and guidelines. There is every incentive to disagree. Avilich (talk) 03:23, 2 April 2023 (UTC)
I don't think AfD is especially high-stakes. A no consensus or even a keep can be re-nominated after a few months, and a deleted article can be re-created if more sources are found. There may be a perception of AfD as a high-stakes game, but that's probably a result of the battleground mentality, rather than a cause of it. Sojourner in the earth (talk) 06:08, 2 April 2023 (UTC)
I think the stakes are high. Or, perhaps more precisely, if someone is invested in having a subject represented on Wikipedia, whether that subject seems important to others or not (Anyone else remember the huge fight over the title of Tree shaping, with various real-world experts appearing to endorse or oppose different options? Would anybody think that just the name of this article was worth that many hours? Imagine if we'd instead proposed not having an article about the subject they'd dedicated their lives to...), then the prospect of someone declaring their favorite subject to be unworthy of Wikipedia and deleting that article could very well seem like a big deal.
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. JeffUK09: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)
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)
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 Albury13: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?
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 MarshallT/C22: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)
I think it can depend, though. An article can be proposed for an AFD and an RM on entirely unrelated matters. The title an article is located under is really an orthogonal issue to whether or not Wikipedia should have an article in the first place. I mean, some times AFDs determine that an article should be moved to a new title, but that's a really rare outcome. Probably 90% of the outcomes are either keep/delete and probably 90% of the remaining discussions end up with merge/redirect discussion. Very few discussions consider a simple move. I think both discussions are fine to proceed together. --Jayron3216:34, 12 April 2023 (UTC)
The two discussions can definitely proceed together in parallel. If the RM discussion reaches consensus to move before the AfD discussion is closed, it can make sense to delay the actual move until AfD is complete, as it avoids confusion at AfD. I take S Marshall's point that there's a risk of abuse, but (1) AfD isn't a second opinion on the move debate; it doesn't over-rule the move, it just delays it a little, and (2) if someone habitually misuses AfD to pervert other discussions, they can be dragged off to ANI and thrown to the lions. The main thing is to ensure that both debates are kept informed, very briefly, of the existence and conclusion of the other. I.e. it would be appropriate for a closed RM to be notified at the matching AfD "If this article is kept, it has been agreed at .... that it will be moved to some other weird title". Elemimele (talk) 12:21, 13 April 2023 (UTC)
If it appears that the AFD was set up because someone wants to override an RM, that is abuse of process and should be grounds for a speedy close. Otherwise, copy all RM votes to the AFD with the needed changes to make it clear the votes only cover the rename question, and inform the voters of this change. Animal lover|666|14:02, 13 April 2023 (UTC)
I strongly oppose the latter idea of copying RM votes to AfD as RM, & AfD are two very separate processes. While AfD does occasionally result in "Move" conclusion, you wouldn't want "I think Turkey should be moved to Turkiye" statements within an AfD where the nominator says "Delete because it is non-notable per WP:NGEO". —CX Zoom[he/him](let's talk • {C•X})12:56, 14 April 2023 (UTC)
In the particular case we're thinking about, the RM was open before the AfD. The now-deleted RM page contained more than a dozen sources, none of which received any real analysis or even engagement from any of the participants at either the RM or the AfD, and I think that's a pity. It should not have happened this way.—S MarshallT/C15:41, 13 April 2023 (UTC)
I have thought a lot about this. I personally think that discussions that took place in a talk page provides a great deal of insight about the now-deleted article and its content. If I were one of the initial Wikipedians, I would have made sure that talk pages were archived somewhere while clearing up mainspace. —CX Zoom[he/him](let's talk • {C•X})13:01, 14 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.
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)
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. JeffUK10: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
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)
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! — xaosfluxTalk15: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)
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)
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)
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)
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)
Sun
Psyche
Gonggong
Charon.svg)
.svg)
.svg)
.svg)
but the colour isn't important. Certes (talk) 21:17, 19 March 2023 (UTC)
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)
Administrator note this is about message MediaWiki:Editpage-head-copy-warn. — xaosflux Talk 10:47, 28 March 2023 (UTC)
