Wikipedia

Wikipedia:Village pump (idea lab)/Archive 38

< Wikipedia:Village pump (idea lab)
Village pump (idea lab) archive  

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

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56

Some option to make articles easier to read

Hello! So I had an idea of an option in the settings that would make articles a bit easier to read. My reasoning behind this is people like me (I'm autistic) have a hard time reading some longer sections of articles. This is mainly due to having sort of a short attention span, making it hard to read long sections of articles in one sitting. I propose some way to break up article sections in a way that makes it easier to read. I'm not exactly sure how we would do this which is why I put this in idea lab. Some of the ideas I have are making the text slightly larger, making different parts of the article highlighted in different colors, or making the space between different parts of the article/section larger. Let me know what you guys think and if you guys have any other ideas as to how we would make larger articles easier to read. ― Blaze The WolfTalkBlaze Wolf#6545 16:40, 24 September 2021 (UTC)

I should probably specify that not everyone who has this issue is autistic. Dyslexia can also make reading articles an issue. ― Blaze The WolfTalkBlaze Wolf#6545 16:44, 24 September 2021 (UTC)
@Blaze The Wolf, have you tried "new" Vector? @AHollender (WMF) designed it to have a narrower width (on most people's font/screen-size combinations) because shorter lines are easier for many people to read. If you want to try it out, then go to Special:Preferences#mw-prefsection-rendering-skin and un-check the "Legacy vector" item.
Remember: It often takes people two weeks of regular use to get used to a change in the appearance of a website. A few things (e.g., the search bar and links to non-English Wikipedias) are in different places, and you'll have to re-train your habits. But if you stick with it through that adjustment period, you might find it easier to read articles. Whatamidoing (WMF) (talk) 17:06, 24 September 2021 (UTC)
At the same time, many of our articles do have over-long sections, which I'm sure puts a high % of readers off. Editors should get in the habit of breaking them up. It might be an idea if MOS:PARA actually specified a figure for a length that is likely to be too long - at the moment it just says cryptically "paragraphs that exceed a certain length become hard to read" - yes, but what length? Johnbod (talk) 17:15, 24 September 2021 (UTC)
 
I wonder how it would work to have some kind cursor which highlights one paragraph at a time (or perhaps one line, or a contiguous span of N lines). As you finish reading each paragraph, you could use the up or down arrow keys to move to the next paragraph. A nice side-effect of this could be that the software keeps track of the last paragraph you read and when you revisit the page, gets you back to the same place. That might make it easier to read a bit, go away, and come back to read some more. -- RoySmith (talk) 18:04, 24 September 2021 (UTC)
I highlight (select) text as I read all the time. I suspect many people do. It drives me nuts when a website overrides the selection behavior (Medium, Feedly, etc.). Nardog (talk) 05:28, 25 September 2021 (UTC)
@Nardog: That is a close second, in my list of egregious web-design offenses that should be capital crimes, behind setting the visited link color the same as the normal link color. That I absolutely loathe, and (to all site designers guilty of this crime:) if I visit your site a lot, I will add a userstyle to undo your bullshit, you bunch of heathen, poo-flinging webmonkeys! -- FeRDNYC (talk) 16:11, 27 September 2021 (UTC)
Infinite scroll isn't the first, FeRDNYC? For shame. IznoPublic (talk) 20:17, 29 September 2021 (UTC)
@Izno: Heh. I have nothing against infinite scroll per se — like too many things, it's neither inherently good nor bad, but its power can be difficult to wield correctly, and it's all too easily abused. Infinite scroll as a replacement for pagination is fine as long as (a) there's still a well-defined structure and ordering to the contents; (b) you can reach individual items directly, and (c) you can skip to a point within the infinite scroll, so you don't have to work down from all the way back at the start. (Granted, almost nobody does all of that correctly.)
Tumblr's archive pages for blogs are an example of "pretty good". They scroll "infinitely" into the past (until you hit the first post), and posts are grouped by month. You can start from the "top" (end/latest post) of any given month by selecting it from a dropdown menu, and the infinite scroll will work backwards from that point instead of from "now". You can also filter the contents of the list by things like post type or tag matches. It's mostly OK, really.
The sadly-more-typical "infinitely accumulating progression of barely-related content with no rhyme, reason, or (most importantly) navigation/control", though... well, I guess I figure that's more than a "bad web design" issue. Those sites are fundamentally engineered to convert users' wasted time into site revenue. -- FeRDNYC (talk) 22:52, 29 September 2021 (UTC)
@Nardog Yup, I do that too (selecting text to make it easier to read). Not as a regular thing, but it's an option I have in my toolkit when I'm faced with a website that's made just plain bad design decisions. There's lots of good human-factors research on how to make text easier to read. Font selection, line length and spacing, paragraph formatting, contrast, kerning, etc, etc. And then there's the legions of web designers who do things "because it looks good". -- RoySmith (talk) 20:42, 29 September 2021 (UTC)
@Whatamidoing (WMF): I've tried new Vector and I haven't really liked it. It seems really weird to all of the sudden have the article and sidebar be on the same "level". Overall it just feels weird to me and I haven't liked it so I've switched back to legacy Vector. Also, the narrower width isn't noticeable at all and to me it would just make sections seem longer. I do honestly wonder if it's because when I'm staring at black text on a computer screen, it all sort of starts to blur and black highlights form around the words and in between lines (which aren't really there, it's an illusion). I would honestly love for WIkipedia to have a dark mode but at the moment, Wikipedia's dark mode just feels like "high contrast" mode where the colors are reversed, therefore making a pseudo-dark mode. ― Blaze The WolfTalkBlaze Wolf#6545 18:31, 24 September 2021 (UTC)
For RoySmith's idea, what we need is an accessibility expert who is also a JavaScript expert. Like RexxS (talk · contribs). --Redrose64 🌹 (talk) 19:22, 24 September 2021 (UTC)
  • The Encyclopaedia Brittanica, in those far-off days when it was a paper encyclopaedia, used to be in two sections - the Micropeaida (Index and Ready Reference) and the Macropaedia (knowledge in depth). For example, when articles of famous people were in the Macropaedia, the Micropaedia would have a corresponding article for that person saying "Abstract of text biography." Would it help if all articles in Wikipedia were headed by an "Abstract" section, similar to the Micropedia articles in the Encyclopaedia Brttanica? YTKJ (talk) 21:38, 24 September 2021 (UTC)
That's what MOS:LEAD is supposed to be. Unfortunately, few articles are written that way RoySmith-Mobile (talk) 09:31, 25 September 2021 (UTC)
  • There was an article a bunch of years ago, I think it was posted at Engadget but even knowing that I can't seem to find it anymore, it's been around 10 years so hardly surprising. But in the context of some speculation about the future of human-computer interfaces, one of the advances suggested was that eye-tracking software could observe your progress through an article as you read it, and effectively "mark your place" on the page as you go. Get halfway through a long-form Sunday NY Times thinkpiece and have to run out the door to catch a train? Pull the article up on your mobile device once you're on board, and the browser scrolls right to the last word you read so you can pick up exactly where you left off.
I mean, we all know the most likely use of such technology is to force people to actually watch ads in their content, or other evil manipulations of that sort. But, still, there are some potentially beneficial aspects to that kind of thing, deep down there under all the obvious perversions of it. -- FeRDNYC (talk) 16:27, 27 September 2021 (UTC)

Alright so I haven't really seen many ideas about this. I understand that New Vector might help, however some users don't want to use New Vector, so any ideas that might work with both New and Legacy Vector? ― Blaze The WolfTalkBlaze Wolf#6545 19:07, 5 October 2021 (UTC)

Adding several namespace shortcuts

  Moved from WP:VPP

While contributing to English Wikipedia, I found that some namespace shortcuts are missing. For example:

  • H: pointing to Help:
    • HT: pointing to Help_talk:
  • T: pointing to Template:
    • TT: pointing to Template_talk:

if we add these shortcuts to English Wikipedia, this will makes links shorter and easier to access, esp. with shortcut services. Wiki Emoji | Emojiwiki Talk~~ 12:27, 5 October 2021 (UTC)

HT: and TT: are interwiki prefixes, so they can't be used. WT: isn't a namespace shortcut either, but there are many redirects substituting for that. See Special:PrefixIndex/H: and Special:PrefixIndex/T: for existing shortcuts. Making more shortcuts just means we'll have more strange cross-namespace redirects such as Wikipedia:Kill (the page should properly be called Project:Kill). —Kusma (talk) 12:38, 5 October 2021 (UTC)

Expand "what links here" for Draftspace articles to include "what links to" the topic if it were in mainspace

For example, I started Draft:Simpson's Rest and want to see relevant links at "what links here". Of course nothing, or hardly anything, links to "Draft:Simpson's Rest"; what I want to see is what links to "Simpson's Rest" (currently a redlink). Could "What links here" be modified to automatically provide those relevant results, for articles in Draftspace? This would be useful for article developers and AFC reviewers and other reviewers. --Doncram (talk) 17:07, 9 October 2021 (UTC)

You could simply go to the mainspace redlink and look at its "what links here" - Special:WhatLinksHere/Simpson's Rest. I just checked and it does work. Roger (Dodger67) (talk) 17:15, 9 October 2021 (UTC)
There is no "mainspace redlink" within a Draft article that can be clicked upon, unless one deliberately adds it as a temporary thing, just to facilitate performing that "what links here" search (by just two clicks). And it is confusing for AFC reviewers and others when they see you have put such a temporary thing into the article. Again, a one-click service would be helpful for draft article developers and reviewers. Note, a somewhat related recent change was the introduction of messaging to persons creating a new article, if there already exists a Draft article on the topic. E.g., clicking on redlink Simpson's Rest right now yields message "There is a draft for this article at Draft:Simpson's Rest." --Doncram (talk) 17:34, 9 October 2021 (UTC)
This is just one more thing that is wrong with the concept of draft space. The whole idea of a Wiki is that articles are edited in main space where people can see them, and deleted if it is found after proper examination (which seems to happen less and less at WP:AFD) that their subject fails policy or guidelines. Why can't we just acknowledge that the experiment of using draft space has failed, rather than add more and more bells and whistles to it? The only answer that I can see is that people are addicted to the fallacious concept that sunk costs should be taken into account. Phil Bridger (talk) 19:37, 9 October 2021 (UTC)
@Phil Bridger: I strongly disagree with your view of draftspace. I have over a thousand drafts there now, and at this point have completed and moved over a thousand previous drafts to mainspace. I use the space as I believe it is best used, as a place to gather sources while preparing an article (see, e.g., Draft:William Lawrence Foster). BD2412 T 20:51, 10 October 2021 (UTC)
Exactly. Sunk costs. You are probably the the only editor who makes such extensive use of draft space, rather than, as we are told it is not, treating it as as a backdoor route to deletion by non-admins, and you could do exactly the same in user space, as has happened ever since Wikipedia started. If you want to give an example of how draft space is any better then show me an article that shouldn't be in main space but where collaboration has happened. Phil Bridger (talk) 21:13, 10 October 2021 (UTC)
@Phil Bridger: Again, I have to disagree. Even if I can't put my finger on any one article on a moment's notice, of the drafts that have been moved to mainspace, at least a hundred involved substantial collaboration with other editors working on the draft as a draft to bring it up to mainspace quality. BD2412 T 17:57, 12 October 2021 (UTC)
Actually, I can put my finger on some. Jack Mizuha is an article where I started the draft and someone else picked it up and added substantial content to move it to mainspace. T'Challa (Marvel Cinematic Universe) was worked on by numerous MCU project participants in draft until there was consensus within the project that it was in shape for mainspace. Rivalry was a solid draft-space collaboration. BD2412 T 18:07, 12 October 2021 (UTC)
+1, I also use Draft space and have seen my starts picked up and have picked up others. As for the argument that "The whole idea of a Wiki is that articles are edited in main space where people can see them" - if we didn't have draft space editors would just be using user subpages, where content is less visible and less collaborative. A venue for working on articles which aren't ready for moving to mainspace yet is an entirely reasonable thing. Perhaps we could think about ways to make drafts more visible and collaborative, rather than removing them entirely? Sam Walton (talk) 21:44, 12 October 2021 (UTC)
One possible alternative to a literal "Draft:" draftspace would be to have a space for drafts in project space, and associate drafts with specific WikiProjects, provided that there is a relevant project for any given draft. BD2412 T 02:56, 13 October 2021 (UTC)
Would adding [[Special:Whatlinkshere/{{PAGENAME}}]] to somewhere in {{AfC submission}} solve/work around your problem? It automagically removes the "draft" and shows links to the same name in mainspace. —Kusma (talk) 22:23, 9 October 2021 (UTC)
{{AfC submission/tools}} already says [[Special:WhatLinksHere/{{SUBPAGENAME}}|⋈]]. It's linked on "⋈" after clicking "show" at "Reviewer tools" at Draft:Simpson's Rest. Few draft authors will problably find that. PrimeHunter (talk) 22:49, 9 October 2021 (UTC)
Unicode Character 'BOWTIE' (U+22C8). What a curious selection. --Redrose64 🌹 (talk) 08:07, 10 October 2021 (UTC)
Perhaps we could change it to "links" or something else that I wouldn't overlook and that would make sense also for screen readers? —Kusma (talk) 08:12, 10 October 2021 (UTC)

Replacement for Interlanguage link template

This is a proposal to deprecate {{interlanguage link}} and define a new type of disambiguation/redirect page that includes one or more links to the appropriate page on one or more other wikis.

The primary issue that I raise with the existing solution is that multiple articles may have links for the same article which exists on other wikis but not on enwiki. Whenever there is any change to the set of wikis that should be linked to (perhaps the article has become available in another language, or perhaps an English-language version has become available), then all the pages referencing that article need to be modified ... we even have a bot which automatically replaces the {{Ill}} with a direct link when an English-language version becomes available.

The proposed solution is a form of disambiguation or "manual redirect" page that has whatever name that would presumably be used on enwiki. The pre-existing discussion is at Template talk:Interlanguage link § Proposed alternative to Template:Ill. Fabrickator (talk) 18:47, 19 September 2021 (UTC)

Note that this can be used in a citation, a meaningful advantage over {{Ill}}. Fabrickator (talk) 19:13, 19 September 2021 (UTC)
I think you misunderstand how {{ill}} works when that red-linked article gets created here – no manual change is required, the red link will turn blue and interlanguage links should appear in the left side bar. A bot may come along and remove the template. As for citations: several components of a citation can already be linked via {{ill}}. Author links are of course possible in free-text citations, and can be hacked into citation templates as well. -- Michael Bednarek (talk) 02:49, 20 September 2021 (UTC)
Sorry, I "mis-spoke" about how the template handles the case when an enwiki version of the page becomes available.... as that's the single situation which is handled okay, more or less. Every other case is handled poorly, in that it's necessary to edit each page which references the affected article when there's any other change to availability of interlanguage versions of the article. Fabrickator (talk) 06:44, 20 September 2021 (UTC)
I would be happy to see the templates and their redlinks being replaced with links to articles that provide at least a basic stub level of content, and with sufficient referencing to show the subject is notable. However, this proposal would see approximately 110,000 redlinks being replaced with links of a different color, and the creation of many new pages to which these recolored links would go. They would be each contain a list of external links to other wikis, but be lacking the level of content or citations required in standard articles. The idea that redlinks are ugly as they are highly visible and a clear indication of something being wrong (i.e. missing content) is not a major concern to me compared to the actual lack of content, something which I feel the proposal does not fix, but attempts to mask by using placeholder pages. There are numerous issues with the usage of this template, from inconsistency in the naming of the redlink to the order, number and selection of language links used with it. It may be possible to make adjustments to the template or create tools that can help to sort some of this, however, these issues are mainly the result of editing rather than the template itself. Changes to the documentation could help inform editors of some potential issues and how to avoid or work around them. EdwardUK (talk) 04:53, 20 September 2021 (UTC)
EdwardUK wrote:

I would be happy to see the templates and their redlinks being replaced with links to articles that provide at least a basic stub level of content, and with sufficient referencing to show the subject is notable

It seems like you are trying to apply some sort of technical rule that would have the effect of complicating or otherwise deterring the implementation of a presumably useful feature. I'm a little perplexed at this approach, given what seems to be a general consensus that these interwiki redlinks are expected to encourage the creation of new articles. Anyway, notability applies to articles, and I think we can distnguish between a redirect page and an article. Fabrickator (talk) 09:45, 20 September 2021 (UTC)
The technical rule is simply meeting the standard expectations of any standard article without which the article is liable to be deleted or draftified. Here it seems the intention is to circumvent these requirements by classing these as a different type of main space page for topics where there is another language version and I would be very surprised if these pages were not challenged either as a concept or on an individual level. I would expect the issue of notability to apply on the basis that wikipedia is not an indiscriminate collection of information, so inclusion here should not be based solely on the content existing on other wikis.
I understand these pages could be seen as starting points which could be expanded into full articles, but it is not clear at what point they would make the transition and the standard rules would apply. This would be a particular problem where content creeps in and it goes from "this article is not available" to "there is no article about topic X…" followed by a brief description for the benefit of the disambiguation and then to further details being added. With the redlinks there is a clear dividing line over there being an article or not, the proposed pages would make this line unclear. EdwardUK (talk) 16:40, 20 September 2021 (UTC)
I am not sure what the source is of your contention that these redirect pages could be expanded into full articles, but of course there's nothing preventing existing disambiguation pages from being expanded in this manner, and there are certainly some cases where a disambiguation page actually describes a term when there is no appropriate article to link to. Just take a look at the red herring disambiguation page. Fabrickator (talk) 18:43, 20 September 2021 (UTC)

There are certainly examples of disambiguation pages that deviate from the guidelines and have content that should not be there, but these pages are never intended to become articles, only to list topics for which there are already related articles on the English language wiki. What the language link pages would need is something more like a disambiguation/hatnote so that users could know exactly which topic there is no article for without having to open any of the links (or translate the contents).

It may be possible to use templates or bots to assist in creating both the redirect and language link pages if the text was kept simple and generic. (If I am correct in thinking that the proposal would create two pages for each topic, a redirect/article page and a links page, one being a page where the article will eventually be but is initially blank except for a redirect to the second page, which has the language links) However, adding the language links may be more difficult, and based on the size of the task I do not know how complicated or time consuming it would be to add the individual disambiguation for each page, and as it has been noted, the template has numerous cases of name and language variations for a single topic, which could result in many errors and page duplications which would have to be corrected too.

Once an article has been created (replacing the redirect) it would orphan the language links page. If these link pages were kept there could be a build-up of these redundant pages, and if deleted there is the same issue as happens with the template, that if the article is deleted or removed the links to it would turn red but the redirect and language links would not be restored. (This is one of the reasons I would prefer to have citations from the start, so that the articles are more likely to be retained.) When it comes to the creation of the articles I can see two ways in which this is likely to happen, either overwriting the redirect page with a full article, or as a result of additions of text on the links page until an editor decides at some point that it should be moved to the article page. EdwardUK (talk) 07:38, 21 September 2021 (UTC)

We've got to start off with some common ground about our attitude towards interlanguage links. On the one hand, the fact that we can use interlanguage links greatly increases the number of distinct topics that are potentially available to enwiki users, notwithstanding the fact that these articles are not in English. On the other hand, some of these articles might not meet the standards of what would be considered acceptable as an article on enwiki, notwithstanding the fact that these articles aren't in English.
So supporting this notion that we might be concerned about this is that some of these other wikis might not have similar attitudes about reliable sources, NPOV, or certain other policies we consider to be fundamental, and thus, such links could be harmful to the reputation of enwiki. If this is a substantial concern, we might restrict links to certain wikis which we consider to have a "like-minded" attitude compared to enwiki.
Now let's take a more positive stance. Given that there are at least some non-English wikis that do have similar standards, we will still have disagreements, certainly as to notability, for instance. And I'll raise the question that has been brought up in a sideways sort of manner: Are we inviting some kind of trouble if we allow a link to an article that would not be considered notable on enwiki, but which is considered notable on one of these "like-minded" wikis? Phrasing the question another way, if the folks running the Russian-language wiki allow there to be an article for some obscure Russian philosopher (yet this article does not exist on enwiki because the philosopher is not notable in the English-speaking world), and enwiki has an article mentioning that obscure Russian philosopher, should it be okay to have an interlanguage link to the article on the Russian wiki? Answer me that, and I think that would help us to move forward. Fabrickator (talk) 09:40, 22 September 2021 (UTC)
Yes. -- Michael Bednarek (talk) 10:52, 22 September 2021 (UTC)
See H:FOREIGNLINK. - Donald Albury 16:26, 22 September 2021 (UTC)
@Donald Albury: The whole point of this discussion is actually the deficiencies of the existing solutions such as {{interlanguage link}}. Some of the discussion has been to the effect that a proposed solution would create "disambiguation" pages (using the appropriate English name of the article) which would offer one or more interlanguage links to choose from, but one of the objections has been that those might not meet the "notability" requirement on enwiki. We now have one person agreeing that this should not be considered to raise a notability issue. Fabrickator (talk) 21:55, 22 September 2021 (UTC)
One solution to all this, will be to wait until a good translator will arrive and will translate this "obscure philosopher" article with attributed reliable sources.--Filmomusico (talk) 22:01, 22 September 2021 (UTC)
Unless the content of a page is terrible (in which case I would not bother) then linking to it would be fine, but that is not the same as creating an English language page for it. On the English wiki the quality expectations are higher than they once were, so there are plenty of older sub-standard and non-notable articles, (some which could be deleted or draftified but have not, either because they have not been noticed, they have been ignored, or the issues have been tagged but not resolved), and the situation is the same in other languages including "like-minded" wikis. The German article de:Arthur Kaan for example, (this being found on Achilles, the first article listed on the "What links here" page for the template) is of a quality which would be okay to have or to link to, but not necessarily to create. If the article already existed in English I think it would be kept, it seems notable and has sources but it would be tagged for lacking inline citations, however, as a new article it may be seen as inadequate until these citations are added, which would be difficult to do as of the three sources on the German wiki, one is not online and a version of another (Thieme-Becker) is behind a registration/pay wall.
If the proposed pages were implemented, then when information on the links page is added, (specifically the introductory disambiguation), it would be necessary if this is drawn from the other language versions to ensure that it has the correct copyright attribution, and that it is accurate, which may be unclear if the other version lacks citations. If it was on the English wiki the editor would be taking on responsibility for the accuracy of the information/content, whereas using the template they only have to ensure the accuracy of the link(s). It would also be necessary when attempting to fully create this article in English to not just use a direct translation but also make additional improvements, without which it could be draftified or deleted, with the redirect and link pages being lost. Unless there is a better alternative, then for this proposal to succeed, there would need to be a way to counter any pages being removed, this would require the creation of another type of template added to the redirect page, which would be retained when it becomes the article page (unlike the removable template used for changing the color of incoming links). These would inform admin editors of the option to restore the redirect page, not just move or delete the article, and could link to any tools that may have to be created to provide a method for un-deleting the links page and adding to it any messages regarding removed versions or drafts of the article. After the first set of proposed pages have been created to replace the existing templates I do not think any more pages of this type would be made because the combination of pages and templates needed would be very off-putting to editors trying to add it, instead they would opt for ordinary redlinks and argue for the restoration of the template which is much easier to use. EdwardUK (talk) 23:39, 22 September 2021 (UTC)
Not to make too fine a point of it, but I do not propose having separate redirect and link pages. I don't know if it helps any, perhaps we should drop the term "redirect", it's just a disambiguation page that may have links to one or more pages, pages which happen to be on other wikis. If it's decided to replace this disambiguation page with an article, some consideration could be given to how we "transition" it back to the way it was if it's decided to delete the article. This is worthy of giving some thought to, but building up some complex set of conventions may be overkill. I see this as a way of increasing the use of wikilinks to non-English wikis, so that there's only one place where the interwiki links (for a given article) need to be recorded, instead of repeating them on each page containing the term to be wikilinked. Fabrickator (talk) 00:09, 23 September 2021 (UTC)
The reason why interwikis exist is so that one can translate an article from one language to another. On the other hand, the articles that we write are translated more (because we have more) then in other languages.--Filmomusico (talk) 02:55, 23 September 2021 (UTC)
The only place the language links need to be recorded is on wikidata, the problem is that this is easily accessible from an article, where it is displayed on the left sidebar, but not from a redlink, and although the template allows a link to wikidata to be added, many of the editors that use the template probably think that it may be more helpful to link directly to another language instead of having to go through wikidata. If there was just a link to a single page, tagged with a "this is not an article" type template, then it would not need to have a list of language links as users could access the wikidata item and find the list of language links there.
Suppose though, instead of this disambiguation page, we were to have a modified "Creating…" page. This would require an addition to be made to the standard blank "Creating…" page (reached from clicking a redlink) of a feature (maybe a sidebar tool option) allowing the editor to pre-associate that name with an existing wikidata item before the article has been created. This could be used to generate a modified "Creating…" page for which all the matching redlinks could display in another color, for example orange. Then when another editor sees it they would be aware that when they clicked on this orange link it would take them to the modified "Creating…" page (something like https://en.wikipedia.org/w/index.php?title=____&action=edit&orangelink=1) from which they could either access the wikidata item, or create the article. This would remove the need for the template (and the language links it displays), without the need for the creation of disambiguation pages or having to create the list of language links that goes on it. Some editors with technical knowledge may have to assess the practicalities/possibilities of this concept, and there may still be some uses of the template that are tricky to convert, but it would very be simple for editors to add new links. EdwardUK (talk) 03:16, 23 September 2021 (UTC)
In principle, this might be an optimum approach, i.e. a single source mapping "equivalent" articles across all different language wikis. As a practical solution, I would be really skeptical. This means that existing editors (and perhaps non-editors) need to somehow be interacting with Wikidata. I looked at the Wikidata docs, trying to access info using the QID, couldn't make out heads or tails. I guess there's great stuff in there that I'm missing out on. (I tried finding the stuff mentioned in the left sidebar, I couldn't find that either.) So I am a totally clueless editor it seems. This would seem to be a huge barrier, maybe I'm the only one with such a blind spot, but I doubt it. My prediction would be that if we go this route, then only a small group of particularly technical editors will participate, it will become a feature regular editors can't effectively contribute to, they'll see that interlanguage articles exist but have no way to contribute. The ability to contribute is obviously a big part of the appeal of being an editor, adding interlanguage links look like a meaningful way to contribute (just as many editors feel they are encouraged to improve articles by adding wikilinks), but this will be beyond them. I am highly skeptical that the barriers this seems to create would be overcome. Fabrickator (talk) 15:37, 23 September 2021 (UTC)

The level of interaction would be little different than it currently is with the existing template, or would be with the proposed disambiguation page. Here the requirement is also for the initial editor adding the links to visit the external pages in order to verify their links are accurate. On most articles the link to wikidata is found in the left sidebar near the bottom of the tools section. (unless using the mobile website, or there is no item, or other display settings have moved/removed it) Adding links to wikidata would be much like when adding other languages, after opening a page on the relevant language site/wikidata an editor could use the search bar at the top right to look for the name and confirm if there is already a page for their topic, with wikidata the QID would appear next to the page title, which the editor could copy without having to take any editing action within wikidata. Then on the standard/redlink "Creating…" page, using a feature (which is not currently there and would need to be created) the editor could type/paste in the QID just as they currently do when adding it to the template. Note that until the article has been created this link would only be one-way, so that it would link to wikidata, but wikidata would not link back to the non-existent English article. When subsequent editors click on the orangelink, the sidebar of this "Creating…" page would not only have a wikidata item, but also the other features generated as a result of this, notable the language list, and also the commons link. These could be accessed directly from that page without having to go via the wikidata site. It could also see more consistency in the naming of links if, when an editor tries to turn a redlink orange by adding the wikidata ID, a message appeared if that QID had already been linked to a different name, so that they could then go back and adjust their redlink as needed. EdwardUK (talk) 19:12, 23 September 2021 (UTC)

@EdwardUK: WP:Wikidata § New articles seems to claim that the capability to create links based on Wikidata is already present. I tried following their instructions with Evgenia Zabolotskaya, adding ru:Институт общей физики имени А. М. Прохорова РАН via Wikidata. But that only updates the Wikidata. There are instructions shown for semi-automated migration and manual migration, but they do not seem clear enough to follow. Can you tell whether these instructions should actually work if I were able to figure out how to follow them? Fabrickator (talk) 21:30, 23 September 2021 (UTC)

Arbitrary section break

Fabrickator: Your merge of Evgenia Zabolotskaya (D:Q67166568) and ru:Институт общей физики имени А. М. Прохорова РАН [A.M. Prokhorov General Physics Institute of RAS] (D:Q16655721) at Wikidata was ill advised. Those articles do not cover the same subject and the merge ought to be reverted. -- Michael Bednarek (talk) 02:15, 24 September 2021 (UTC)
The wikidata instructions seem hard to follow, I get lost near the start as soon as it says to locate "Item by title", rather than just using the "Search Wikidata" box at the top right, but after that it looks like it should work. I have only tried some of more basic things on wikidata, (correcting info and adding links rather than merging and migrating) though I think some of this might be suited to editors more experienced than me. Also these instructions are designed for working with links and pages that already exist. Because, initially there would be no article in English for them to create a link for, editors would not need to know how to do this or any other editing within wikidata. If editors are aware of other language articles that are missing from wikidata they can add them, but it is not required as all they would be doing at this stage is looking for the QID. Entering this into the English wikipedia using a tool/option on the article creation page would extract and display the information from wikidata, without the page itself being added to wikidata. Effectively it is a tool that can be used to show a preview of the links that would normally only appear after the article has been created. Only when the English article had been created would there be the need to add it as an entry on wikidata, and the fact that an editor has already identified its matching QID should make this more manageable. EdwardUK (talk) 02:31, 24 September 2021 (UTC)
@Michael Bednarek: @EdwardUK: I'm not sure I see eye-to-eye with regard to the need for the English-language article to already exist. I think of the QID as a concept, in this case I was trying to apply this to the concept of a specific institute of the Russian Academy of Sciences. The concept exists independent of the existence of an English-language article providing information about that concept. Wikidata is proffered as a specific mechanism that substitutes for {{Interlanguage link}}, it doesn't make sense that the English-language article must first exist. I'm guessing that somebody knows how to do this, or else knows that there's some piece that's missing and it can't really do this, but that person is neither you (EdwardUK) nor me. Michael, is there any chance you can set us straight on this? Fabrickator (talk) 03:10, 24 September 2021 (UTC)
I think of Q-numbers at Wikidata as ISBN numbers or barcodes (note the stylized barcode used as Wikidata's logo) which identify a well defined entity; see Help:Wikidata. The Wikipedia entries at Wikidata then provide links to exactly that subject in various language editions of Wikipedia. -- Michael Bednarek (talk) 03:27, 24 September 2021 (UTC)
If the article did not exist, then in theory it would be possible to create what would be a redlink for it on wikidata, yet trying to do so would result in an error because the list of languages on wikidata is intended to aid navigation, for this reason it would not be desirable to have redlinks here as is the case with them being discouraged in our internal navboxes. I think consensus would probably also be against adding a redlink outside of the English wiki as I have seen a past discussion opposing the linking of our draft versions to wikidata in case this was to suggest to other wikis that something here was sub-standard or deficient, and I think adding redlinks would be viewed in the same manner.
With regards to the language template I have just spotted something interesting on the Chinese language version. An example can be found here: zh: 巴克斯特公園 (Baxter Park), linking to Sir David Baxter. This link appears to be their version of the language template, but the redlink and language links have been replaced with a green link. When the link is hovered over it changes to red and displays a navigation popup which roughly translates as: "Entry X has not yet been created, and can be found on the corresponding page of English Wikipedia:X". EdwardUK (talk) 06:51, 24 September 2021 (UTC)
I came across some other Wikipedia (can't figure out which it was) that provides a solution. See the link labeled "General Physics Institute" on User:Fabrickator/Evgenia_Zabolotskaya. Fabrickator (talk) 19:53, 24 September 2021 (UTC)
Aha! This is already supported {{Interlanguage link}} using the WD (QID) parameter... but of something like 50,000 instances of {{Ill}}, only about 2,000 use this feature, quite rare. I would suggest that using {{Ill}} without QID ought to have been deprecated (or at least discouraged), but Wikipedia editors are no different from other people, they repeat what they see and what they are familiar with. So we continue to propagate a use of {{Ill}} that doesn't really do the job very well. Fabrickator (talk) 04:00, 25 September 2021 (UTC)
The option to use the template to provide a separate link to wikidata next to a redlink avoids the problem of WP:SURPRISE caused by using a piped link. With the template I think that linking to wikidata should be encouraged in certain situations, mainly as an alternative to adding too many language links. But even with a wikidata link I think editors would continue in wanting to select the best ones and have direct links to these languages too, as they think readers would find this more helpful than just the link to the list of languages, and when there are only one or two languages then linking directly to them and leaving out the wikidata link could be seen as reducing unwanted clutter.
The maximum number of language links was increased from 5 to 12 in 2017, when one editor requested it to enable linking to all the language pages for a particular topic even though at the time only about 3 of these were anything more than a stub. I cannot see a significant benefit in this, the links to stubs did not add anything helpful, one or two links to the good pages were all that was needed, and even if they had all been good that would still have been sufficient. If the issue were to be raised again on the talk page again the number may be reduced. There is a certain amount of reluctance/hostility among some editors towards wikidata, but if asked to consider whether with this template it is more helpful to have a) numerous links to stubs, b) a link to one (or two) good article(s) and wikidata, or c) just to wikidata, my thought is that many would opt for b). When those options are presented with arguments towards greater consistency and neater appearance, I think that it would be possible to gain consensus to adjust the template, or at least to establish clearer guidance on how to use the template to best effect. EdwardUK (talk) 18:31, 25 September 2021 (UTC)

@EdwardUK: You wrote:

linking to wikidata should be encouraged in certain situations, mainly as an alternative to adding too many language links.

I consider it objectionable that, when you link using the QID, the Wikidata link doesn't appear if the enwiki article has come into existence (which is particularly problematic if the enwiki article is a stub). But the original concern I had, being the need to update the {{Ill}} template when the article becomes available in a new language, that's only resolved if the QID is specified. As for users being annoyed by being presented with a bunch of irrelevant choices, this problem is solvable by providing some sort of user-customizable language preferences... but WP editors can't be making the call about which interlanguage version is best (for how many reasons? ... even if the editor feels one language is preferable to another when linking from a specific article, that may change over time, it requires the ability to read the mind of the user, and it goes against the principle of having a single set of interlanguage article equivalences per source article).

Should I try to make this clear? We now have a way to record all the instances in which articles on "Prokhorov General Physics Institute" may be available in various languages. Assuming this article existed in several languages, and you would let the editor who's inserting the link in an article specify which language is best, based on the context in which it is linked? So now, the preferred link depends on the where it's linked from? Never mind that those articles change over time, and the best language to link to would also be subject to change, you're doing completely the opposite of what the QIDs do for us. The QID is suitably close to the right solution, and the only logical reason to avoid using it is a belief that nothing pertinent to the choice of link is ever going to change. Fabrickator (talk) 22:21, 25 September 2021 (UTC)

Here's an article where I resolved several links by QID. The one issue I had was where there was an existing article on enwiki for a different topic.... because that makes the Wikidata link disappear ... adding a qualifier solves the problem, also a couple of items had disambiguation pages in other languages, including a qualifier can reduce the risk of future collisions. All in all, this is a much better solution than using {{ill}} without a QID, IMO. Fabrickator (talk) 03:56, 26 September 2021 (UTC).
Something that would assist in creating versions of the template containing a wikidata link could be useful. There is a user script here: User:Cobaltcigs/IllWill, the description for which says it can be used with redlinks to search wikidata for the matching topic and then add the template with language links. (I have not installed it so am not entirely sure of how it works) It may already have an option for, or could be modified for, adding a wikidata link rather than languages. If not then it may be possible to create a similar user script that could be used for this. EdwardUK (talk) 03:47, 27 September 2021 (UTC)
My attention has been directed to WP:Wikidata § Appropriate usage in articles. I am not sure I fully grasp the rationale. The objection seems to focus on the reliability of Wikidata content, but (given my narrow view of WD as nothing more than a table of "equivalent" non-English language articles) this just strikes me as bizarre. This is how decisions are made here in WP-land, one more piece of evidence (IMO) giving credence to the hypothesis that WP is dysfunctional. Fabrickator (talk) 10:05, 27 September 2021 (UTC)
I was aware that opinion was generally against the use of wikidata and in particular the use of it to automatically add content to wikpedia articles (in case this content may be inaccurate), but the summary for the New RFC (June 2018) suggests no consensus over its use in the language template. Had the RFC banned this then the ability to use this parameter of the template should surely have been disabled and deprecated at that time, which did not happen, and since then another feature, the short= parameter has been added for use with the wikidata link. This would seem an illogical thing to add if the link itself had been prohibited. EdwardUK (talk) 15:44, 27 September 2021 (UTC)
One of the main objections to Wikidata was the fact that the Wikidata "reliable source" requirement might not be up to the standards of the enwiki reliable source requirements. In this instance, the QID is used to obtain a set of interlanguage links on other Wikipedia sites. The query as currently set up by {{interlanguage link}} uses an anchor to go to the Wipkipedia links section of the Wikidata page for that QID. It would be helpful if this could be chaned to display only the Wikipedia links, I presume that this is not too difficult to do. It might be desirable to have certain constraints on these links (e.g. disallow revision ids), but that concern is not a good reason to reject the concept... and to reject on this basis would result in a case of catch-22, nobody is going to fix this problem as long as such Wikilinks are disallowed.
With regard to the closure New RFC on linking to Wikidata (WP:Manual of Style), the statement :

As to the other proposed exception of linking to WD, by inline inter-language link, given that there is roughly a numerical tie and there's no clear-cut refutable argument(s) from either side, I am unable to see any consensus.

. But I think I am properly perplexed when this becomes:

Wikidata should not be linked to within the body of the article except in the manner of hidden comment(s) as to mentioning the Q-number.

It seems to me that you get to this depending on how the proposition is structured. For instance, if this had been interpreted as the following independent propositions:
* prohibit Wikidata links in hidden comments
* prohibit Wikidata links in interlanguage links
* prohibit Wikidata links in ordinary text
Then we'd have no consensus on the use of Wikidata links in interlanguage links, and given that the current state had been to allow them, these links would continue to be allowed. Fabrickator (talk) 01:17, 30 September 2021 (UTC)

@Fram: At User talk:Winged Blades of Godric § June 2018 RfC on Wikidata links, User:Fram responded to this, stating

No: there is consensus that Wikidata links are not allowed in text, and there is no consensus to make an exception for interlanguage links. Which means that the first rule also applies to the second case

.My response to Fram is "Thanks for providing the opportunity to elaborate on my point."

Of 31 votes cast, I interpreted 25 as having a statement that I could assign to one of 3 categories:

* 12 support the proposal (prohibit WD links in interlanguage links and ordinary text)
* 9 oppose the proposal (allow WD links in interlanguage links and ordinary text)
* 4 support the proposal with exception (allow WD links in interlanguage links, prohibit them in ordinary text)

So is this 16 to 9 in support of the proposal, while 13 to 12 (no consensus) to exempt the rule for interlanguage links? Or is it 16 to 9 to prohibit links in ordinary text, and 13 to 12 (no consensus) to allow them in interlanguage links (thus they would continue to be allowed). So with the identical facts, being presented two different ways yet reaching contradictory results, this demonstrates that the determination made in the closure of this RfC was arbitrary." Fabrickator (talk) 02:07, 3 October 2021 (UTC)

I see no cogent response to my claim that the interpretation of the vote was arbitrary. Is there a forum that would be more suitable for such an issue? Fabrickator (talk) 06:53, 13 October 2021 (UTC)

Create tracking template for Wikidata items in text

After reaching the conclusion that users do not want visible links for Wikidata items on Wikipedia articles in the Create template/link for things that have Wikidata items, but not articles discussion, I want to propose another solution.

I still think it's extremely important that Wikidata items that are tracked in articles in some way. There are so many items in Wikidata that do not have articles but describe something that is present in an article. Establishing a "link" between them is useful for tracking and notability purposes.

So instead of creating a visible link using something like Template:Interlanguage link, my proposed solution is to make a template called "Associated wikidata" that shows normal text for all users and the associated item ID is only present in the source code. This is better than the current suggestion of putting a comment like <!--Q108291790--> because it is actually computer readable, therefore creating an actual association.

Example:

{{Associated wikidata|item=Q108291790|text=Changer : Dear Eris}} will just show "Changer : Dear Eris" on the section that mentions it with no link.

Thoughts? Lectrician1 (talk) 14:11, 12 October 2021 (UTC)

  • What part of “we don’t want links to Wikidata” is not clear? Blueboar (talk) 14:26, 12 October 2021 (UTC)
    @Blueboar It seemed as if users did not want visible links, however were okay with comment "links" in the source code. All my template does is "standardize" the way that Wikidata is mentioned. It's really no different than adding comments.
    Are my reasons above for creating "digital" links not convincing? Lectrician1 (talk) 14:32, 12 October 2021 (UTC)
Not really. You explain that you think it is important to create digital links, but not why it is important to do so. I see no benefit to even hidden “digital” links Blueboar (talk) 14:45, 12 October 2021 (UTC)
@Blueboar I explain why above: "Establishing a "link" between them is useful for tracking and notability purposes."
To add, Wikidata in the future could establish a native tool that shows on the item page where an item is linked on Wikis.
Creating a tracking category for the template would be nice for statistics as well. We could see where items are linked across wikis and on what types of articles. Lectrician1 (talk) 15:31, 12 October 2021 (UTC)
Okay, so it might be useful for Wikidata. How is it useful for enwiki? Making our code more complicated to edit for the benefit of Wikidata seems like a poor tradeoff. Fram (talk) 15:50, 12 October 2021 (UTC)
@Fram Does it matter if it's "one-sided"? We're all part of one movement trying to document information. More linked data means better data for all of us in the end.
It could be useful to enwiki editors, say they found it when editing and they could contribute or use data from it. And it could be more useful if an actual link was displayed for at least logged-in users. But, EN Wikipedians seem to hate Wikidata and stay away from it at all costs, which in the end is hindering Wikidata from actually being of use any use on our wiki (which it can be of significant use if people were inspired enough to create tools for it), and leaving enwiki in the dust compared to, say the Catalan.
I don't see this simple template as an obstruction to editing. My template is of little complication compared to something like an infobox and will barely add any clutter. It's 2 simple parameters. Lectrician1 (talk) 17:34, 12 October 2021 (UTC)
As I disagree with most of your premises (e.g. "More linked data means better data for all of us in the end."), I disagree with your conclusions as well. I don't think it is advisable to use anything from a website that brings us the article "lost to fury" for nearly a day now, when the enwiki article linked to it has received more than 1 million views over the last 20 days. If even the most high profile pages can't be protected from such extremely obvious vandalism, then we have no business at all linking to it. If Wikidata wants to be useful, they need to improve dramatically (in vandalism protection, in sourcing, and so on). As they haven't done this in the past, what, 8 years, I doubt it will happen anytime soon. For crying out loud, their entry for West Africa was called "Mexico" for two whole weeks[1]. Fram (talk) 07:59, 13 October 2021 (UTC)
Absolutely right. Peter coxhead (talk) 09:59, 13 October 2021 (UTC)
@Fram @Peter coxhead
So you're concerned that people will see the item in the source text and then proceed to vandalize it?
I think that the chances of that are extremely low. People who are likely to vandalize a Wikipedia article are very unlikely to know or research what Wikidata, figure out how to get to the item, and then proceed to know how to vandalize it. That is a lot of steps required compared to just vandalizing the Wikipedia article instead. In this instance, Wikipedia is much more likely to get vandalized then Wikidata.
Therefore, I think the potential benefits of adding the template "link" outweigh the potential downside that the Wikidata item is vandalized.
Nothing on Wikipedia is impacted by the presence of this template. It is not used as a source or link. It's just a template as simple as something like Template:Use mdy dates. Lectrician1 (talk) 19:24, 13 October 2021 (UTC)
No, I think that you will be leading people to a site which is unreliable, poorly patrolled, and of little use. I see no benefit to enwiki at all. Fram (talk) 07:01, 14 October 2021 (UTC)
  • Wikidata is an unstable knowledge base in which any value may change at any time. We really shouldn’t be linking to it anywhere. --Malcolmxl5 (talk) 16:03, 12 October 2021 (UTC)
Wikidata is crowd-sourced just as Wikipedia is, and we don't allow the use of Wikipedia as a source because it is crowd-sourced. - Donald Albury 17:17, 12 October 2021 (UTC)
@Malcolmxl5 @Donald Albury It's NOT a link. Nor is it a source. It is simply a "correlation" stored in the source text for "existence" and tracking usage. Please see the example.
Malcomxl5, I'm not sure if you recognize the usage case here. Lectrician1 (talk) 17:39, 12 October 2021 (UTC)
@Lectrician1: but the use of such a template appears, to me at least, and I'm sure it will to other editors, to endorse links to Wikidata, which I agree entirely with Donald Albury is not and should not be allowed as a source. Peter coxhead (talk) 10:03, 13 October 2021 (UTC)
Lectrician, if it does not actually link to WD, then there is even LESS reason to clutter up the editing page with it. Still a no for me. Blueboar (talk) 11:26, 13 October 2021 (UTC)
I'm not sure I'll be able to convince you if you find this template "cluttering" when comparing it to the other average 50+ templates, references, and links on an average article that are much more cluttering. Lectrician1 (talk) 19:42, 13 October 2021 (UTC)
Those templates either have a clear purpose (adding a reference, indicating unsourced statements) or are out of the way (use dmy dates, shortdesc). Adding a template in the middle of the text which only benefit is that Wikidata might perhaps track some usage is, yes, cluttering. Fram (talk) 07:01, 14 October 2021 (UTC)
@Peter coxhead
If there's anything that endorses Wikidata on Wikipedia it's the "Wikidata link" on the sidebar...
This template is harmless compared to that.
I also struggle to understand how you see this as a "source" and "endorsement". It's just a relationship. When we add the link to a person or organization's official website to their article, are we "endorsing it"? That is also just a relationship.
And not even the official website link compares to this template. The website link actually appears on the article whereas this template just shows the normal text...
And gosh, we are linking to another Wikimedia project site. This link is part of the Wikimedia ecosystem! Why would we reject it? And if you're concerned about quality differences, who ever said that Wikipedia articles were of any better quality than any other Wikimedia Project...
As I stated above, this is harmless and will not cause vandalism or any other concern. Lectrician1 (talk) 19:40, 13 October 2021 (UTC)
The sidebar link appears once in each article where editors can find it helpful, or just as easily ignore it. The template could appear every time there is a Wikidata item that does not have its own article, and for the tracking data to have any meaning it would presumably need to be used extensively in order to create a full picture. The interlanguage template should be (but often is not) used sparingly to supplement certain redlinks, for the benefit of other editors, unlike the intention of this template which is to enable machine reading of the source code, but in doing so it would make it almost impossible for humans to edit it. Perhaps there could be a way of tracking this type of information using tools and templates placed somewhere within Wikidata rather than here. EdwardUK (talk) 21:48, 13 October 2021 (UTC)
I agree with EdwardUK re a one-off link in the sidebar, which can be ignored. Re who ever said that Wikipedia articles were of any better quality than any other Wikimedia Project – I say that some aspects, e.g. classification and taxonomy, are much better covered in the main language wikipedias (English, French, Spanish, German, ...) than in Wikispecies or Wikidata, which is a reflection of the number of editors working on them. Active collaboration by multiple editors in wikiprojects produce better quality articles. Peter coxhead (talk) 06:22, 14 October 2021 (UTC)
Wikidata is an unstable knowledge base in which any value may change at any time. Well, so is Wikipedia, and the Commons, which we use to link to or take images from all the time, although they may change without warning. There is also general consensus to accept that Wikidata should be used extensively as our central storage for interwikilinks (this is much better than the previous bot-maintained monstrosity of changing corresponding pages on every language edition every time a page is moved on any Wikipedia). We just don't trust Wikidata's other content, because we don't trust their editing processes, which seem less robust that Wikipedia's. In an ideal world, we should have a trustworthy repository of data that can be shared by different Wikimedia projects, but Wikidata is currently far better at collecting and collating unverified data than at verifying it. I do hope that changes, but that's where we're at. —Kusma (talk) 08:07, 14 October 2021 (UTC)
This is no different from the existing (and already allowed) solution of putting the Q number as a wikitext comment, except for the fact that it adds a template whose wikitext would be literally {{{text}}}. There's no point in creating a template that does so little, and comments are computer readable, in the sense that a computer is capable of parsing the wikitext to find them. * Pppery * it has begun... 03:03, 15 October 2021 (UTC)

WikiFiction

I would like to propose creating a multiauthor space for creative writing: WikiFiction (or WikiNovelist).

Wikinovelists should contribute with donations to be able to participate in multiauthor books and everyone should previously register in order to contribute. This process will hopefully keep bored haters/destroyers away from busy creators -or modern serial witch burners from potential intelligent life out there.

WikiFiction could be a way to get funds for this or other wikimedia projects.

This new platform could recycle the current Wikipedia platform, with the added registration requirement, perhaps with a valid cellphone. A maximum of authors per book should be set for a given time, to avoid some books getting too crowded and the content confusing and neverending changing.

There should be authors and editors, who could review the final book for coherence. All versions should be stored until the final version is agreed. Authors and editors could go by name or nick, but all should be registered with a way to prove identity.

Any profits from any WikiFiction book should ideally be offered to non-profit charity organisations, chosen by votation of main authors, with a percentage dedicated to maintain WikiFiction.

Part of the donations for wikinovelists could be saved in a fund, which will offer free passes for those who could not contribute otherwise. So a young Leonardo da Vinci from a remote village somewhere in this planet, could still contribute to a book with perhaps unique ideas, even if her income is zero.

Creative writing or imagination in general is urgently needed to find solutions for the future we are facing. Encyclopedias and history are giving us great (or terrible) ideas from the past. Some novels (a bit as science) can be a valuable means to predict or create the future.

I will contribute with a first novel first chapter idea as a test. It is aimed to be a multiauthor book that would focus on a paradigm change related to Climate, from looking at plastic or recycling as the big problem here, to admitting we human overpopulation are the real issue on this planet. The book will revolve around that.

This creative piece of work requires the input of scientists, modern philosophers, social anthropologists... And needs to start rolling asap...

Caro — Preceding unsigned comment added by 94.252.121.207 (talk) 13:45, 16 October 2021 (UTC)

Please see WP:MULTI and my reply at Wikipedia:Village pump (proposals)#WikiFiction. --Redrose64 🌹 (talk) 14:50, 16 October 2021 (UTC)

Mod Rank

What if there was a rank called Moderator? There would be a moderately protected page, meaning it can only be edited by moderators and above. It would give you more user rights then somebody extended confirmed, but less than somebody who's admin. Pikiwedia98461 (talk) 20:06, 26 October 2021 (UTC)

I don't think that's a good idea. The point of page protection is to stop disruption, not to privilege one class of editors over another. Vexations (talk) 20:52, 26 October 2021 (UTC)
@Pikiwedia98461: I don't see any need for it, do you have anywhere in mind where it would be useful? Looking at Special:ProtectedPages shows that basically every fully protected page in the article space are redirects that might need editing once a decade? Filtering by a minimum size of 700 bytes to remove all the redirects (because the "hide redirects" option doesn't hide soft redirects) shows that the only actual page in article space that is permanently fully protected is the main page [2]. 163.1.15.238 (talk) 09:41, 27 October 2021 (UTC)

Yeah, thinking back on that, it was a dumb idea. Pikiwedia98461 (talk) 16:59, 27 October 2021 (UTC)

Picturepedia

Reading long text sometimes may be annoying, especially when the subject is not of our main interest. But the text may become interesting if accompanied with images... and even better if it is a slideshow with short text. I personally like looking at articles via the pictures and I believe it may be an interesting idea if there is a way to present an article as a slideshow. It will be more appealing for people with less interest to go into the details. I suggest to create an image mode for the articles. The pictures in the article can have a longer alternative text in a way that if viewed via the Image viewer they tell a story. I made a try here to see what this can look like.There is nothing new. We have already the possibility to create such stories but it may require slight adaptation of the ImageViewer in order to display the text better - for example show the text near the image and the caption below. It may need also an alternative text for the images that is not visible in the article but only visible in the ImageViewer in order to avoid overcharging the text in the article. Finally, a "View this article as slideshow" button may be also nice.--Ikonact (talk) 18:28, 7 October 2021 (UTC)

The only issue I can see with this is articles that have little or no images on them. And even then the pictures don't always talk about everything in the article. ― Blaze The WolfTalkBlaze Wolf#6545 18:39, 7 October 2021 (UTC)
If there are articles with little or no images they will not have a slideshow. Not all of the articles need to have it. On the other hand, presenting with pictures gives the freedom to select images less related to the article. It is enough to have a nice picture that tells a story. And that's correct that pictures don't always talk about everything in the article. But that's the point - the slideshow will be a short version, a summary presented in pictures. --Ikonact (talk) 19:32, 7 October 2021 (UTC)
@UOzurumba (WMF), this discussion reminds me of the 'Stories' project. What do you think? Whatamidoing (WMF) (talk) 19:08, 8 October 2021 (UTC)
@Whatamidoing Yes, Ikonact's thoughts about visual stories is in line with the Wikistories pilot project. This is a validation if you ask me. So, @Ikonact and anyone interested in this, please follow up on the project here and then you can also look at the early design exploration presentation. Thanks Whatamidoing, for pinging me about this. :)
UOzurumba (WMF) (talk) 10:26, 13 October 2021 (UTC)
This sounds like something that should be more a Simple English Wikipedia project, less on en.wiki. Not that this is a bad idea, just maybe beyond our scope. --Masem (t) 19:17, 8 October 2021 (UTC)
I agree with Masem. This would work great on Simple, but here? Here text is the most efficient way of communicating messages to our readers. 🐔 Chicdat  Bawk to me! 10:07, 11 October 2021 (UTC)
Well, I disagree that this is for Simple English Wikipedia for two reasons. First, the idea is not to make a simple text but to present an article differently. This can be complex text too but with some visual support. It may allow readers that are not familiar with details to learn about a subject without digging in a bunch of paragraphs (one can refer to the subject "Some option to make articles easier to read" above). Second, this can be applicable to other Wikipedias, not only for English. --Ikonact (talk) 09:17, 12 October 2021 (UTC)
I'm not sure that this would necessarily be at any Wikipedia. It might be a separate project entirely. mw:Wikistories has more information (but doesn't specify whether it would be part of Wikipedia or a separate project). Whatamidoing (WMF) (talk) 02:22, 20 October 2021 (UTC)
BTW, if you click through to mw: Wikistories and put the page on your watchlist, you'll get a notification whenever anyone starts a new discussion on its talk page. I encourage interested editors to watch that page. Whatamidoing (WMF) (talk) 02:23, 20 October 2021 (UTC)
I love this idea!
I actually think this could work on all Wikipedias, Simple and EN. Captions can be both simple and complex English, so we shouldn't just limit it to Simple.
How we could implement this is maybe creating a system for different viewing modes of Wikipedia articles. For example, users could choose from the standard text, your slideshow version, or maybe others such as a "fact sheet" (list of bullet points), or anything else the community could come up with! Users could select the mode at the top of the article. Lectrician1 (talk) 14:28, 12 October 2021 (UTC)
That argument violates the WP:ILIKEIT policy. 🐔 Chicdat  Bawk to me! 10:40, 13 October 2021 (UTC)
Perhaps I'm just being dense and this is a joke but WP:ILIKEIT is not a policy (see the top of the page) and applies to deletion discussions, not discussions in general or VPI. 15 (talk) 23:18, 13 October 2021 (UTC)
You're right. 🐔 Chicdat  Bawk to me! 10:18, 14 October 2021 (UTC)

Import from Commons

On occasion, we lose Commons-hosted images that we could have hosted as fair use had there been a simpler way to import the file from Commons (similar to how we can export to Commons). On another talk page @Alexis Jazz said this is possible by creating an upload_by_url user right that a gadget would then use to preserve/import the file's edit history. This would require community consensus for a configuration change, so wanted to open for discussion. If you're wondering what we'd be looking to import, offhand: (1) Any file that would sufficiently meet WP:NFCC fair use criteria but happens to be uploaded to the wrong place, (2) Images that meet our free use criteria (US-based copyright) but not Commons' (US-based and country of origin's copyright), such as freedom of panorama violations. Related: T214280. czar 04:55, 4 October 2021 (UTC)

I think I'd want to know exactly how upload_by_url works. Jo-Jo Eumerus (talk) 07:35, 4 October 2021 (UTC)
@Czar: is the workflow for this, with examples, available somewhere? I did a very quick direct test (resulting in testwiki:File:Лежка_моржей_на_острове_Нортбрук-test.jpg) which did get the file over, but did not get the "file's edit history". — xaosflux Talk 10:36, 4 October 2021 (UTC)
@Xaosflux: What do you mean? — Alexis Jazz (talk or ping me) 11:11, 4 October 2021 (UTC)
@Alexis Jazz: testwiki:File:Лежка моржей на острове Нортбрук-test.jpg was an upload_by_url from commons:File:Лежка моржей на острове Нортбрук.jpg. The upload part, and not having to mess with downloading and re-uploading the file, itself seemed to go fine - but it did not do anything about preserving the attributions such as the original uploader information from commonswiki, or even mention the upload_by_url source in a log or in the file description. — xaosflux Talk 12:01, 4 October 2021 (UTC)
I think I confused Czar. I said It would perhaps be feasible to create a gadget if we granted users the upload_by_url right and added upload.wikimedia.org to the whitelist for that. I'm not saying it would be impossible otherwise, but it would be a whole lot less messy. Either way page/upload history wouldn't be preserved this way, only mw:Extension:FileImporter can do that. The either way here means that a gadget, whether it uses upload_by_url or not, will not preserve page/upload history like fileimporter does when exporting to Commons and this way refers to gadgets in general. It's just that a gadget with upload_by_url would be easier to create and less prone to errors. Such a gadget would (oversimplified):
  • Generate the link to the full image for use with upload_by_url
  • Obtain wikitext of the file page on Commons
  • (optional) obtain username of the original uploader
  • (optional) do some replacements for Commons-specific templates, remove DR templates, etc
  • (optional) do some replacements based on user input (I'm thinking a little form where you select PD-USonly, non-free logo, non-free biog-pic, etc)
  • (optional) check if the image is >0.1 megapixel and claimed as fair use, if so tag for non-free reduce
  • Upload file here with the updated wikitext
Hope this clears things up. Without upload_by_url the image would have to be downloaded to the computer of the user and uploaded to enwiki. That would be more complicated and more likely to fail so I'm not particularly interested in trying to walk that path. — Alexis Jazz (talk or ping me) 11:11, 4 October 2021 (UTC)
  • Without solving for how to ensure proper licensing and attribution components, working on how to change the download/upload workflow to link-for-upload doesn't seem extremely useful (nor is yet figuring out who should be allowed to do this, and how/if to manage such group). How prevalent is this situation, and is there someone that wants to work on building the mechanics for such a process? — xaosflux Talk 15:12, 4 October 2021 (UTC)
    @Xaosflux, I don't have the means to assess prevalence but one way could be to see which image-less articles have a talk page notice that a Commons image is (was) up for deletion. I know it's affected me perhaps a dozen times. I also know sometimes images are uploaded to Commons by accident. I imagine the technical work needed for the transfer is a major deterrent for preserving the image on ENWP. I was surprised there was no easy way to transfer images back to ENWP. czar 18:35, 9 October 2021 (UTC)
    @Xaosflux: Here's an example I just ran into: Wikipedia:Files for discussion/2021 October 11#File:SKY-Q-Logo.png. It happens. — Alexis Jazz (talk or ping me) 13:48, 12 October 2021 (UTC)
    @Alexis Jazz: what am I missing there? Wikipedia:Files_for_discussion/2021_October_11#File:SKY-Q-Logo.png doesn't seem to say anything about needing to rescue a file from commons, it is about a file that is already here. — xaosflux Talk 13:55, 12 October 2021 (UTC)
    @Xaosflux: The nominator says that File:SKY-Q-Logo.png should be deleted as File:Sky Q - Logo 2020.svg is a "free alternative" when in fact it's clearly eligible for copyright protection in the UK. Would be handy if we had a tool to import the thing here, no? — Alexis Jazz (talk or ping me) 14:22, 12 October 2021 (UTC)
    @Alexis Jazz: sorry if I'm completely misunderstanding you - but File:SKY-Q-Logo.png appears to already be a local file, commons:File:SKY-Q-Logo.png does not seem to exist. Can you further explain that if we had a commons-->enwiki import tool, what is the file that is on commons that would apply in this scenario? It doesn't appear that anyone on commonswiki is discussing deleting the second file you mentioned? — xaosflux Talk 14:28, 12 October 2021 (UTC)
    @Xaosflux: Exactly, the second file could be copied to enwiki. It easily exceeds c:COM:TOO UK, just because nobody has tagged it yet doesn't mean it is acceptable to use. It's not correctly licensed so we should create a local copy with the correct licensing. — Alexis Jazz (talk or ping me) 06:47, 13 October 2021 (UTC)
    Ah OK, so it this specific example it isn't something anyone has do worry about (yet) - but yes it seems fine, but getting over more then just the file contents is still important - think this sounds more like using filexporter in reverse than just using uploadbyurl, else everything else is going to get lost or still have to be dealt with by hand. — xaosflux Talk 09:58, 13 October 2021 (UTC)
    @Xaosflux: NOW it is something to worry about!   I think in most cases it would be no big loss to miss out on metadata. Keeping metadata (like uploader username) is more important for own work. For logos or fair use this is less of an issue. And even for own work (which may happen in case of FoP issues), there are still "own work" files being exported from enwiki to Commons using tools other than FileImporter, do we really have to be holier than the pope? — Alexis Jazz (talk or ping me) 12:43, 21 October 2021 (UTC)
    I'm not saying it is a hard blocker, just that if we bother to write a tool for this, might as well make it as useful as possible. — xaosflux Talk 13:20, 21 October 2021 (UTC)
    @Xaosflux: I get your point, but I'm not sure FileImporter could be adapted for this. FileImporter can't be accessed with the API afaik so everything becomes more complicated. — Alexis Jazz (talk or ping me) 16:59, 21 October 2021 (UTC)
We once had Wikipedia:Bots/Requests for approval/Commons fair use upload bot 2, but then its operator was globally banned in 2014, and no one restarted it. I believe Fae expressed interest in doing so at one point, but the plan fell through, and in any case, they have now been banned. * Pppery * it has begun... 18:04, 10 October 2021 (UTC)

Backups for Bot Operators

This is based on a report at WP:ANI. Bots that stop working for various reasons are a common problem. Bot operators who stop editing are a common situation, because editing Wikipedia is voluntary (and often stressful). Some tasks performed by bots are of a relatively high priority. Something would be done in the ideal world that we do not live in. It occurs to me that three of the subtasks are to identify the priorities of bot tasks, and to identify possible backup bot operators (based on programming language and other matters), and then to identify high-priority bots that do not have backup bot operators. Robert McClenon (talk) 18:18, 16 October 2021 (UTC)

One thing I think might be prudent is to (require/encourage/mention) having bots' userpages link to the codebase that they're running; usually, when software I've written stops working, it's because of some minor bug (or API deprecation, etc) that isn't particularly hard to fix. If everyone were able to take a look at the code (and debug it on their own machine, etc) it'd be a much simpler problem for absent operators to accept a pull request than to personally rewrite code which in all likelihood they haven't looked at in years. jp×g 01:17, 19 October 2021 (UTC)
Or require a simple startup procedure to be submitted as part of the BRFA. Enterprisey (talk!) 02:47, 19 October 2021 (UTC)
The problem is that we have some high-priority bots, such as SineBot, that are closed-source. Whether we should be approving BFRAs for closed-source bots is another matter. --Ahecht (TALK
PAGE) 20:58, 21 October 2021 (UTC)

Help on Foreign Wikipedias

There are frequently questions asked at various forums on the English Wikipedia about dealing with foreign Wikipedias, typically about block appeals. (Of course, the user may or may not be blocked. Questions about blocks from editors who are editing from their own account and are not blocked do happen. That is a detail.) They have also asked about blocks on Commons, or about problems on Meta. They are always told, of course, that each Wikipedia is a separate project. However, what I am suggesting is a global Help page giving information about seeking various sorts of help on other Wikipedias, and on Commons, and on Meta, and on Wiktionary, and so on. The page, possibly with subpages, should be one that we invite cross-wiki editors to maintain as a service to other cross-wiki editors. It should have a disclaimer that the information is the best that we have here but may not be accurate, and to go to the page on the foreign Wikipedia and ask further, and please come back and update the help here if it needs updating. Robert McClenon (talk) 18:18, 16 October 2021 (UTC)

Why would this be better than just telling people to go ask on the appropriate project? (Genuine question!) Calliopejen1 (talk) 19:44, 20 October 2021 (UTC)
User:Calliopejen1 - It is not always obvious on a given project where or how to ask for help. I recently encountered a page on Meta that I thought was a very bad attempt at humor that had no real purpose, and so should be deleted, but it was not obvious on Meta either how to ask for help or how to nominate a page for deletion. I did answer my own question, and the page was deleted. A less experienced user might have been baffled. How to look for help is different on different projects, and the differences can be confusing to a user, especially to a user who lacks experience with online systems. Some of the questions that we see about foreign Wikipedias, or about other projects (e.g., Commons, Wiktionary), seem to indicate that the user either has tried and failed to find help, or is exasperated and has stopped looking on the other system. Robert McClenon (talk) 17:00, 23 October 2021 (UTC)
I don't see anything wrong with maintaining a page that tells an editor how to do that. That would give people something to link to if editors ask here, which many people seem to do in the mistaken belief that the English Wikipedia has some sort of primacy over the other languages. Phil Bridger (talk) 19:57, 20 October 2021 (UTC)
An example of where this could be useful can be seen here. I see a few of these every month, and it would be good to be able to direct the editors to the correct place to ask for help on the other project. Phil Bridger (talk) 09:27, 24 October 2021 (UTC)

Random Article Feature

  Moved from WP:VPR

I really like the random article feature, but it can be improved. I would love to see a way to search for random articles within certain categories.

e.g. search for a random article in science, astronomy, literature, music, etc.

I'm not sure if all articles are categorized by default, but I'm sure a select group of people including myself would help categorize articles so a feature such as this could be implemented.

Thanks. Senor hams (talk) 18:25, 13 October 2021 (UTC)

  • @Senor hams: you can use Special:RandomInCategory to get a random article from a specified category (example: Special:RandomInCategory/Apples). — xaosflux Talk 18:43, 13 October 2021 (UTC)
    • @Senor hams: - I've moved this to Idea Lab, as it isn't really a ready to go proposal for VPR. — xaosflux Talk 18:46, 13 October 2021 (UTC)
      • It is difficult to randomly explore a wide theme using categories, because most of the related articles have been split into subcategories so fall outside the range of the search. For example, a random for "Yorkshire" would only result in one of 4 articles or its 33 subcategory pages, but not to one of the 20,000+ articles in those subcategories. To improve the RandominCategory it would be helpful to have the option to include all of the subcategory pages too. An alternative is to search using the larger Wikiproject related categories (e.g. "WikiProject Yorkshire articles") as these can give more possible outcomes, but annoyingly these are on the talk pages so link there rather than directly to articles. EdwardUK (talk) 20:58, 13 October 2021 (UTC)
  • This is a perennial proposal that would work well in theory but is so hard to actually put into practice. I'm not saying I wouldn't support this, but the subcategories, as EdwardUK pointed out, would make it nearly impossible. 🐔 Chicdat  Bawk to me! 10:15, 14 October 2021 (UTC)
    @Xaosflux, do you think it would be easy to set up a script that does Special:RandomInCategory based on WikiProject categories, but then redirects to the content space? Special:RandomInCategory/All WikiProject Medicine articles takes you to the talk page. Whatamidoing (WMF) (talk) 02:28, 20 October 2021 (UTC)
    @Whatamidoing (WMF): a script solution to it didn't immediately come to mind, but maybe? Strategy for that would probably depend on who the audience for it would be, and how it needs to be presented. — xaosflux Talk 12:34, 20 October 2021 (UTC)
  • @Senor hams: One clunky way to do it is using lesser known features of Special:Search. You can filter to articles in certain topics as determined by ORES machine learning with articletopic:TOPIC. And you can sort search results randomly by adding &sort=random to the URL. So this link will give a randomly sorted list of "television" articles. the wub "?!" 13:55, 20 October 2021 (UTC)
  • Is https://randomincategory.toolforge.org/apples "just" an external version of Special:RandomInCategory/Apples? — GhostInTheMachine talk to me 20:41, 20 October 2021 (UTC)
    • If you don't care how random the result is. The short short version is that Special:RandomInCategory isn't really random; it gives pages in the category in an ostensibly unpredictable fashion, but - especially in small categories - the pages aren't equally likely to be selected. The toolforge tool claims that it is really random, and I have no reason to doubt it. Also, it can filter for specific namespaces, or filter out files or subcategory pages.
      If you want a random article from within a category tree to a given depth, Petscan can do that (select "randomly" from Output > Sort). Harder to use, though. —Cryptic 21:47, 20 October 2021 (UTC)
      • @Ahecht:'s tool (randomincategory.toolforge) is nice, I wonder if they would be open to adding a parameter to support this use case? Ahecht, specifically that would be: request a page in a category, but when providing the result, strip the TALK prefix out? Perhaps a ?returnmain=true or the like parameter (understanding that this COULD return a redlink)? — xaosflux Talk 11:55, 21 October 2021 (UTC)
        @Cryptic @Xaosflux I discovered this lack of randomness when I was working AfC. It's really quite non-random. See T230700. -- RoySmith (talk) 12:31, 21 October 2021 (UTC)
        • @RoySmith: I suspect for most of the use case of this, true randomness isn't really that important? This is mostly to let readers browse around and discover new articles to read. — xaosflux Talk 13:19, 21 October 2021 (UTC)
          For the simplest use case of a idly browsing user (which, as I understand it, was the original use case for that feature), it's probably good enough. -- RoySmith (talk) 14:02, 21 October 2021 (UTC)
          I believe the pseudo-random mechanism is something like this: Pick a number between 0 and 1 (let's say that we picked 0.32), get the smallest and largest page ids for the pages in the category, and find the article whose id number is closest to 32% of the way through the range.
          The problem is that id numbers aren't random, so you're pretty much sorting by date of creation, and when the process (e.g., AFC) is rather date-dependent, then you end up with ids that look like this:
          1, 2500, 5609, 6233, 7239, 8305, 8359, 8904, 9134, 9234, 9345, 9456, 9519, 9714, and 10000
          and about 40% of the "random" pages will be one of the first two pages, because 40% of 10,000 is 4000, which is closer to the second page id number than to the third one. Whatamidoing (WMF) (talk) 19:50, 21 October 2021 (UTC)
    @GhostInTheMachine: Special:RandomInCategory picks articles by randomly choosing a timestamp and then finding the article added to the category closest to that timestamp. This means that a cluster of articles added around the same time are less likely to be chosen than an article added by itself. The impetus for creating the tool was when I noticed that accessing Special:RandomInCategory/Pending AfC submissions 25 times only returned about 15 unique pages out of the 1,350 pages in that category at the time (the rest were doubled or tripled). The toolforge tool literally lists out all the pages in the category and chooses one at random, and should be as "really random" as the PHP array_rand() function allows.
    @Xaosflux: I added a returntype= parameter that can take the values subject, article, or talk. The first two always return the associated article (if it exists), the last one returns the associated talk page (if it exists). For example, toolforge:randomincategory/All WikiProject Medicine articles?returntype=article works as expected, although with very large categories like that it will take a while to load the first time you use it (it caches categories for 10 minutes). It fetches the associated page using the API, so there is a bit of a performance hit compared to just stripping "talk:" from the title, but that way it will never return a redlink and it will works across all language wikis, not just those that use the "talk" prefix. --Ahecht (TALK
    PAGE    ) 20:39, 21 October 2021 (UTC)
    @Ahecht: thank you for the quick action! — xaosflux Talk 03:09, 22 October 2021 (UTC)
    @Whatamidoing (WMF): see above, this is off-wikiish, but is perhaps something we could integrate for curious readers somewhere perhaps? — xaosflux Talk 03:09, 22 October 2021 (UTC)
    In the sidebar? (I'm not sure non-editors really use it.) Special:Random takes you straight to a page, so that limits the opportunity for showing a message. Whatamidoing (WMF) (talk) 18:34, 26 October 2021 (UTC)

Preparation for IP masking

I read few weeks ago here and on meta wiki that IPs are going to be masked. Then some editors proposed that IP editing be banned but many opposed it. So banning will be controversial. But, are there some other ideas which can be implemented to counter vandalism? I am relatively new at wikipedia so I don't know what will that be exactly. I propose that now a userscript be made which mimics IP masking. Interested vandal fighters can add in there js file so as to get a feel on how it will look after update, so that community will get better idea about it and vandal fighters will be more prepared for actual masking. I have no idea how to make such script but just thought came in mind so shared it. -- Parnaval (talk) 11:27, 22 October 2021 (UTC)

@Parnaval: while an interesting preparation idea, I would think one of the bigger issues here is that it's not the regular vandal fighting workflow that is impaired by masking but the socking and range-hunting. A lot of that is done by cross-editor efforts (rather than one person handling everything themselves), so you'd have to make sure everyone was on it. Otherwise you'd be getting "can you block 5%£u343ur/64" and others would be "who is 5%£u343ur/64 - I'm seeing 4.343.121.12/64" etc Nosebagbear (talk) 16:06, 22 October 2021 (UTC)
@Nosebagbear: Then just aggressively add this to every editor who is rollbacker/admin/checkuser. And post a message to talkpage of everyone in these usergroups. And if this is not feasible, there should be something else which enwiki should do before masking goes live. Some sort of brainstorming needs to be done like one going on for RfA review. -- Parnaval (talk) 06:45, 23 October 2021 (UTC)
Parnaval, those of us who have been around a long time and have been instrumental in getting important policies brought into line with today's reality know that change on Wikipedia happens slowly. One medium sized Wikipedia has recently banned IP editing with resounding success, while the WMF is currently supporting a 6-month trial on another. That said, consensus can change, and sometimes dramatically so, hence banning IP editing might not be quite so controversial after all. These issues are discussed in depth on Meta. Kudpung กุดผึ้ง (talk) 05:59, 24 October 2021 (UTC)
Oh. . . OK. I was just suggesting that enwp community should do some trials themselves, so as to show some results to WMF on what worked here. -- Parnaval (talk) 12:49, 24 October 2021 (UTC)
Why are you even doing IP masking. I ask: why? I see no benefits and many disadvantages of hiding IP numbers from all but the privileged few. 🐔 Chicdat  Bawk to me! 12:11, 25 October 2021 (UTC)
@Chicdat: -- Well, we aren't doing it. The WMF is. We don't want it, but alas -- Rockstone[Send me a message!] 00:22, 28 October 2021 (UTC)

Truth seeking team

There's a lot of cloudy information in the news that can make its way onto Wikipedia. Perhaps someone is pronounced dead in absentia on CNN, but people in the real world see the man walking around and get clear tape and pictures of him. Maybe there are little white lies, unverified claims, and other such commodities on a page. Enter the "Truth Team."

Much like the Typo Team (who seek to find Typos and correct them), the Truth Team looks to find lies and false info in Wikipedia pages and correct them or even remove them. For instance, someone may say that "John Doe was assassinated at 3:30 AM" but in reality, John Doe was assassinated at 4:30 AM, as found by eyewitness testimony. If the exact time can't be found, say at "approximately 3:30 AM." Stuff like that.

It would clear up a lot of false evidence, unite Wikipedia users to find the truth and to make Wikipedia a better source of information in general. xdude (talk) 16:54, 29 October 2021 (UTC)

Listen, Xdude gamer, I made a little joke above, but I want you to know that I (and everyone else) recognize that you're trying to improve things. But if you read the links above you'll see that actually, trying to fix articles by direct evidence isn't a good idea. EEng 22:02, 29 October 2021 (UTC)

Ah, I see. Reading these articles, I realize the error. xdude (talk) 23:58, 29 October 2021 (UTC)

Spoken wikipedia on the main page

This is probably more likely to apply to Today's featured article, Today's featured list, Today's featured picture, and possibly Did you know than it is to apply to In the news and On this day, but I think there should be a way for people to volunteer to add a narration to the blurbs that appear on the main page. This probably wouldn't work for ITN and OTD, because those are dynamically updated lists, but it might work for DYK, because the entire list is updated at the same time, and it could really work for TFA, TFP, and TFL, which have thousand-word blurbs. Maybe it's just the icon, instead of the whole playback box, but I think there should be a way to add spoken tracks to the main page. They'd have to be reviewed, of course, but I think it could be done. theleekycauldron (talk • contribs) (they/them) 01:44, 29 October 2021 (UTC)

Is a spoken-word reading of material which, like a mayfly, lives only one day (or even less) really a good investment of editor time and effort? And think of the pronunciation disputes! EEng 18:31, 29 October 2021 (UTC)
For sure. I don't think it'd be a requirement for every appearance, but if someone wants to make a recording, there should be a way to display it—and we have MOS:VAR for pronunciation disputes. The main page is seen by millions of people every day—it does seem worth the investment if someone wants to make it. theleekycauldron (talk • contribs) (they/them) 18:32, 29 October 2021 (UTC)
MOS:VAR for pronunciation disputes – Entire vistas of deadline-driven main page battles to the death open before us! You'll be a bust in the Hall of Fame! [3] EEng 19:19, 29 October 2021 (UTC)
Where will you find readers who can pronounce all those foreign names? —Kusma (talk) 18:44, 29 October 2021 (UTC)
The IPA can help there, no? If not, it'll probably be weaker on that side, but again, we don't need to have one for every blurb. There should be the option, though. theleekycauldron (talk • contribs) (they/them) 18:46, 29 October 2021 (UTC)
Personally I find IPA an eh-NIG-muh (or eh-nig-MUH if you're over 35 or went to private school) [4]. EEng 19:23, 29 October 2021 (UTC)
I have a PhD in Linguistics and don't speak or read IPA. - Donald Albury 21:32, 29 October 2021 (UTC)
I speak fluent IPA … if I drink enough of them. Blueboar (talk) 22:21, 29 October 2021 (UTC)

@Theleekycauldron: it's a good idea, if the main page projects start with a few to test the waters, and see how it goes. It doesn't have to be an everyday thing, but selected by the individual projects. Let them decide on some trial runs. — Maile (talk) 23:52, 29 October 2021 (UTC)

Maybe we start with TFA, then—see how it goes. I'll ping some of the coordinators over there. theleekycauldron (talk • contribs) (they/them) 23:55, 29 October 2021 (UTC)
TFA would be an excellent place to start. They plan well in advance, and are probably the best project to determine how workable this idea is. — Maile (talk) 00:25, 30 October 2021 (UTC)
I agree, TFA would be a good place to start. They've one got the one moving part each day. —valereee (talk) 14:24, 30 October 2021 (UTC)
I consider this a great idea, especially for TFA and TFL. I doubt whether it would be easy enough to do this at DYK, as sometimes, we tweak a hook while it is on the main page. In rare conditions, the we swap a hook. It isn't as stable as TFA and TFL. I wonder, would we be able to change the recording simultaneously? – Kavyansh.Singh (talk) 17:17, 30 October 2021 (UTC)
No, at that point we'd have to pull the recording—you're right, DYK is pretty unstable. theleekycauldron (talk • contribs) (they/them) 17:20, 30 October 2021 (UTC)

Roud Folk Song Index and Child Ballads nr in the WP:LEAD of articles about songs

It's common [5] that a WP-article on a folk song (?) will mention something called a Roud Folk Song Index number in the WP:LEAD, sometimes also a Child Ballads number. See also List of folk songs by Roud number. Sometimes in the first sentence:

Sometimes a little further down:

IMO, this looks like strange WP-writing, like having "The imdb number is tt0068646" in the lead of The Godfather, and not "a summary of [the article's] most important contents". I'm guessing Roud and Child are more academic, though. A previous discussion Wikipedia:Village_pump_(policy)/Archive_156#Stop_putting_Roud_index_numbers_in_the_lead_of_folk_songs mentioned external links, infobox and wikidata (it can be added there apparently [6]) as alternatives to lead, but nothing really happened afaik.

So, is there some sort of consensus that having these in the lead should be dealt with somehow (how?), or is it ok to have them there? At the time of the previous discussion I edited Cotton-Eyed Joe like so [7], noone has changed it. Gråbergs Gråa Sång (talk) 20:08, 22 October 2021 (UTC)

I know they're an important identifier for those songs. It would be useful to have some standard method of incorporating them in those articles, so readers and researchers can rely on where to find them. Maybe as fields added to Template:Infobox song? Ah, I see that was generally the consensus in that discussion (minus the lead/lede/introduction tangent). But that would also imply an expectation that all of those types of articles include an infobox. It could be a standard section after the lead? Schazjmd (talk) 20:45, 22 October 2021 (UTC)
How about a "Folk Song Index" section above See also/References? Gråbergs Gråa Sång (talk) 21:11, 22 October 2021 (UTC)
I like that idea! (Properly sentence-cased, of course) Schazjmd (talk) 21:11, 22 October 2021 (UTC)
But of course. Gråbergs Gråa Sång (talk) 21:37, 22 October 2021 (UTC)
Roud numbers at least (not sure about the Childs nos.) are akin to the opus numbers (or other recognized cataloging numbers like BMV or Köchel numbers) we see in the lede -- usually the introductory phrase -- of most classical music articles, e.g. The Symphony No. 6 in B minor, Op. 74...; or The Requiem in D minor, K. 626... or Fugue in G minor, BWV 578.... They have recognized academic status as identifiers to unambiguously identify a particular work. They ought to be in the lede.
This is nothing like IMDB numbers, which are just the database numbers used by a particular vendor to navigate its database, and whose stability Wikipedia takes advantage of for linking. Roud numbers, like opus, BMV and Köchel numbers, are stable, academically recognized and not tied to a vendor who might arbitrarily change them in the future (as Turner Classic Movies did some time ago, breaking Wikipedia templating in the process). TJRC (talk) 23:44, 22 October 2021 (UTC)
Interesting. Opus numbers has been around longer though, and Bach-Werke-Verzeichnis/Köchel catalogue is more limited in scope, like opus numbers for one musician at a time. Roud seems more like a limited ISBN or ASIN, catching them all, or trying to. Gråbergs Gråa Sång (talk) 08:02, 23 October 2021 (UTC)
Identifying Roud and similar catalogue numbers is important, but the way they are presented in many WP articles is awkward and not encyclopedic. A while back, I remember several articles that were little more than "'Ballad X'" is Roud 12345" followed by lyrics that were italicized and formatted with a series of <br /> and : (rather than something like {{Poemquote}}), with a link to the Roud index as the sole ref. It reminded me of the mass creations of superstubs in the early days that seemed to ignore WP:NSONGS "Notability aside, a standalone article is appropriate only when there is enough material to warrant a reasonably detailed article; articles unlikely ever to grow beyond stubs should be merged to articles about an artist or album."
The catalogue number should be worked in to articles with some explanation or context; a reader who is only interested in one song may not know what a Roud number is or why it is significant. Also, Roud and other ID numbers can be added to Template:Infobox musical composition using the |catalogue= parameter. This template also has several other useful fields more applicable to traditional songs than Template:Infobox song, which is more geared towards commericial recordings. An example follows.
—Ojorojo (talk) 14:43, 23 October 2021 (UTC)
Maybe compare it to how the classification scheme for folk tales is done. My thought is that the Roud song index should be in the info box with a link to the official Roud site in the external links as there are 60,000 codes and we only have 3 or 400 hundred.
  • Aarne–Thompson–Uther Index is a global classification scheme for fairy tales and covers most of the globe. Introduced in 1900, with last update printed in 2004, it has 2100 codes, and has been used in 8000 ish academic papers. The wiki article Cinderella for instance has ATU of 510A "persecuted heroine" and this is mentioned in the lede and the infobox. The ATU wiki page is active this year, and the corresponding List of fairy tales is quite active and uses ATU, but only covers a very small number of the stories. A casual reader would be able to find similar stories and realises the connectedness of folk tales
  • Roud_Folk_Song_Index is a pre-WW2 folk English language (UK and US) song identification scheme, which references to variants and recordings.Introduced in 1900, with updates still occurring online, it has 60,000 possible indices and 250,000 references, and has been used in 1800ish academic papers. The Roud wiki page is not active the year, but the list has had a lot of work on this, but there are only 300 to 600 folk songs . A casual reader would find it of limited use - it's just an id. Copying SMeeds (talk) and AlexanderHovanec (talk)) who seem to be the people who have done lots of work and may be able to explain things better Wakelamp d[@-@]b (talk) 07:57, 1 November 2021 (UTC)
Extended content
"Tre pepparkaksgubbar"
Swedish folk song by Alice Tegnér
 
Sheet music cover (1920)
English"Three Gingerbread Men"
Other name"Vi komma, vi komma från Pepparkakeland"
CatalogueRoud 99
Genre
Written1900–1913: Sweden
Textby Astrid Forsell-Gullstrand
LanguageSwedish
Published1913: Sweden
Publisher
  • Bärina Hallonhätta och andra visor
  • Sjung med oss, Mamma! Vol. 6
RecordedGirls' choir, Solna, Sweden (1931)
Audio sample
Nils Lund version (1950)
{{Infobox musical composition
| name                = 
| type                = 
| composer            = 
| image               = 
| image_size          = 
| alt                 = 
| border              = 
| caption             = 
| translation         = 
| native_name         = 
| native_name_lang    = 
| other_name          = 
| catalogue           = 
| genre               = 
| written             = 
| text                = 
| language            = 
| composed            = 
| published           = 
| publisher           = 
| first_recording     = 
| misc                = 
}}

Subset parameters

  • |name= title of the composition, using the common name
  • |type= appears with the composer above an image, such as Folk song
  • |composer= composer of the piece
  • |image= a suitable free image
  • |image_size=
  • |border= set to yes for a border
  • |alt= an alternative description of the image for readers who don't see it
  • |caption= description of the image
  • |translation= title in English, if the common name is in different language
  • |native_name= native title, if the common name is English
  • |native_name_lang= language of the native title/common title not in English
  • |other_name= other name(s) the work may be known by
  • |catalogue= list the catalogue with a link, such as Roud 99
  • |genre= genre of the piece, such as Christmas music
  • |written= more general if "composed" can't be said or is not known
  • |text= text source, such as a poem or "by A. Smith"
  • |language= language of the text
  • |composed= time and location of composition if known
  • |published= date(s) and location(s) of publishing
  • |publisher= company (or companies) which published the piece
  • |first_recording= artist and date of the first recording
  • |misc= for the use of {{Audio sample}}
One of the problems with folk songs and ballads is that they often exist in many variant versions, no one of which is definitive. Even the titles may vary; or, conversely, two or more songs may have identical titles, but entirely different content. The purpose and great strength of the Child and Roud lists is that they bring together all variants under a single authoritative identifier, and perhaps save the student a lot of wasted time and effort in chasing "ghosts". So to my mind this is important information that should be included both in the lead, and in the infobox if there is one. On the other hand, it's a technical reference which won't immediately mean much to many general readers, so shouldn't be given undue prominence, or made the basis of the definition. Putting the reference in brackets after the title (e.g. Whiskey in the Jar), or briefly stating it at the end of either the lead paragraph or lead section (e.g. Ring a Ring o' Roses, Holmfirth Anthem), are all entirely acceptable ways of achieving what we want – getting core information out there, succinctly, without overcomplicating the issue. But making it the sole content of the definition (e.g. Robin Hood and the Bishop of Hereford, admittedly a stub) is bad practice, and to be deprecated. GrindtXX (talk) 13:13, 24 October 2021 (UTC)
It seems to me that Roud/Child nr is not "core information," that's stuff like year/country of origin, composer and what Donald Trump tweeted about it. If "Whiskey in the Jar" was a chemical element like lead, Roud is not atomic number, it's electron configuration. However, I think it would be helpful that included Roud numbers has a cite with link included, like.[1] Not necessary if this is under External links, of course. I'm not pushing infoboxes beacause I don't want to "force" an article to have an infobox just to have a place to put the Roud nr. Gråbergs Gråa Sång (talk) 08:41, 25 October 2021 (UTC)

References

  1. ^ "Whiskey in the Jar, Roud No 533". Roud Folk Song Index. Retrieved 25 October 2021.

Module code TOC

  Moved from WP:VPR

I could use a "Module code TOC" to navigate a module page. Module code can be too long to keep overview.

For example, Module:String does have a ../doc TOC, all fine. But in development stage, or in code-research situation, I'd want to go to line "function p._main". The /doc could have like "==code== ===_main===". -DePiep (talk) 20:34, 30 October 2021 (UTC)

@DePiep: are you proposing that we adopt a certain coding style (can you show an example of what it would look like when complete) - or is this a feature request for pages in the Scrubinto content model? — xaosflux Talk 11:25, 1 November 2021 (UTC)
I think it is a feature request. For example, Module:String has function name code function str._match(...).
The TOC I propose then could find this, and create a TOC line equivalent to (the known effect of)
===str._match===
Bottleneck IMO is the "find" part in this. I'm not sure this can be done by Lua module only.
-Piep (talk) 11:34, 1 November 2021 (UTC)
You are asking for anchors such as Module:String#L-140? Gonnym (talk) 11:49, 1 November 2021 (UTC)
@Gonnym: great! line number could be part of the solution indeed. Especially when code is stable. Then TOC to create manually.
More thoughts: 1. more automation; 2. read & show function name in the TOC; 3. adjust linenumber when code changes; 4. keep distinct from possible /documentation function name (=like when regular "===_match===" exists)'; 5. 'TOC-depth' options applied to public/local functions, top code section. -DePiep (talk) 13:27, 1 November 2021 (UTC)
I imagine something like the documentation generated by Javadoc for Java code. isaacl (talk) 21:55, 1 November 2021 (UTC)
@DePiep: moved here from VPR, since (a) not a ready to go proposal (b) doesn't seem like something we can directly do here? — xaosflux Talk 11:39, 1 November 2021 (UTC)

Idea: Explicitly add Notability as a GA Criterion

You might think that this is silly—isn’t every article required to be notable? While perWP:N, the answer is yes, in practice there are articles that have slipped through GA and FA that we’re later determined by the community to be non-notable.

The recent deletion of Lewis (baseball) shows that even featured articles can have issues with notability. However, FA nominations take up an enormous amount of editor time—both for the multitude of reviewers required and for the editors who prepare the article. As a result, when non-notable articles are promoted to FA, an enormous amount of time is wasted entirely.

Likewise, articles that are evaluated for GA demand editor time—both from an evaluator and from the editor(s) who prepare the article prior to its nomination—though not to the same extent as an FA. Obviously, we want to avoid wasted work, since editor time is our most valuable asset. But, by GA not having an explicit notability requirement, articles on dubious notability could make it through the entire process and even gain the green plus topic on without an affirmative check being done on the article’s notability. Our current system, therefore, is causing a decent amount of time waste when articles approach that level.

To create an explicit requirement that an article to affirmatively meet WP:N at the time of its nomination for GA would help to lighten this sort of wasted work. It would require authors to find in-depth sourcing of the articles before making nominations, potentially leading to improved article quality. And, since FA articles must pass all GA criteria, changes made to the GA criteria would carry over to FA—this would reduce the risk of having articles of dubious notability go through the entire FA process, succeed because it passes all explicit requirements, and then subsequently be deleted.

The downside to this sort of rule (as far as I can tell) is twofold: first, articles that are just barely notable but indeed pass WP:N (or possibly would earn a no consensus at AfD) are going to have a very hard time being appreciated as good articles if their content is good; second, it would leave it to individual editors (who vary significantly on the deletionism-inclusionism spectrum) to make a call on whether something is notable, whereas the AfD process is community-based and allows for consensus to form on notability. If we are to solve these problem by launching an AfD every time the GA reviewer were to not find an article clearly notable, this might result in more work overall (though it might help in trimming out cruft easier).

I’m wondering if anybody else has thoughts around an idea like this, or knows if this has been tried before. I’m thinking about a formal proposal, but I would prefer to do brainstorming to try to come up with something more concrete before a proposal gets made. — Mikehawk10 (talk) 06:42, 8 November 2021 (UTC)

  • I'm skeptical that this would actually have any effect in practice. It is quite rare for a GA topic to be found non-notable—even more so for FA—and in the few instances where it does happen, it's not because the GA reviewer did not check for the subject's notability, but because the GA reviewer had a different opinion about the subject's notability compared to the editor(s) that eventually came along to question it. Mz7 (talk) 06:54, 8 November 2021 (UTC)
  • I have similar thoughts to Mz7—any GA reviewer worth their salt is already checking (or possibly spot-checking) sources to make sure that the information in the article is reflected in its sourcing. If they somehow fail to notice along the way that the article is blatantly non-notable, that's a failure on the reviewer's part, not the criteria. theleekycauldron (talk • contribs) (they/them) 07:11, 8 November 2021 (UTC)
  • I echo the concerns of the two above editors. This is a very sporadic problem that doesn't appear very often. 🐔 Chicdat  Bawk to me! 11:43, 8 November 2021 (UTC)

What links here

  Moved from WP:VPR

I would like to propose that "what links here" feature to sort articles alphabetically. I think that would be more useful. Bada Kaji (talk • श्रीमान् गम्भीर) 19:41, 2 November 2021 (UTC)

So do I, though ideally by namespace then title. Meanwhile, you may be interested in User:GhostInTheMachine/SortWhatLinksHere. Certes (talk) 20:22, 2 November 2021 (UTC)
Bless you, Certes, for pointing me to this. I have been craving something like this (be it the OP's dream version or Ghost's slight-daly-while it sorts version). Thanks to GhostInTheMachine, too, of course. — JohnFromPinckney (talk / edits) 23:44, 2 November 2021 (UTC)
Yes, add this as a sorting option. Not the default, though. BD2412 T 20:25, 2 November 2021 (UTC)
It probably won't happen because the DB query would not be efficient. Anomie⚔ 23:00, 2 November 2021 (UTC)

Refining the rollback right

At present, the rollback user right is predominantly given by administrators to trusted editors (typically counter vandalism patrollers) and allows access to more complex and powerful tools, the most notable tools being rollback links (the namesake of the right), Huggle, and some features in RedWarn.

As time has progressed, the rollback feature and right has been used for more than just rollback links (i.e. a link that's clicked and immediately reverts an edit without summary) and as such the current rollback policy is outdated, confusing and conflicts with what many people use it for (i.e. through Huggle or other tools with edit summaries). Because of the lack of clarity, many times WP:ROLLBACKUSE has been brought up in discussions, even when it's usually not applicable to use of rollback with edit summaries (i.e. by using the rollback link).

We should clarify this - as such I think renaming the right on the English Wikipedia to "Tool Confirmed" or similar (thinking along the lines of auto-confirmed, extended-confirmed, tool confirmed, but I welcome proposals for any better name) that clearly describes what the role does, why the person has it and how they can be held accountable for their use.

The rollback link policy should then be merged into the wider reversion policy as no matter where, tool use without edit summaries should only be appropriate in certain situations and autoconfirmed users can replicate the use of rollback links by using a tool such as Twinkle or RedWarn. This means there won't be fragmentation between what essentially in both cases is just reverting an edit.

A sample of what my idea of a summary would look like:
Tool confirmed editors are editors approved by an administrator to have access to more powerful semi-automated tools. A tool confirmed user has access to features in tools such as X, Y and Z, also access to rollback links.

This could also supersede the AutoWikiBrowser request page, if technically possible.

We should also consider creating a tag named something along the lines of "Tool edit" that's required for all automated tools, userscripts etc on the English Wikipedia where appropriate and possible to increase accountability and other benefits such as analytics.

What do people think? ✨ Ed talk! ✨ 23:49, 24 October 2021 (UTC)

It makes sense to me. I requested Rollback because I'd heard intriguing stuff about Huggle, then had Rollback removed when I discovered that I didn't like using Huggle. I couldn't see any other use for having Rollback, because Twinkle provides rollback/vandalism links in both article history view and diff view, and enables rollback of multiple edits (sequential by a single editor) in one click. So the Rollback permission isn't really associated to rollback functionality. Schazjmd (talk) 00:07, 25 October 2021 (UTC)
I do not think of the rollback permission as mainly functional or technical—giving access to tools—rather as a matter of trust, in effect a licence to revert vandalism without an edit summary. IMO it doesn’t really matter how the revert is done, be it with a helper script, the rollback button, or simply null-editing an old version of the page (which last any user can do).—Odysseus1479 01:45, 25 October 2021 (UTC)
What does the rollback right grant, other than the "[rollback]" link? --Redrose64 🌹 (talk) 07:01, 25 October 2021 (UTC)
Permission to use Huggle, and nothing else. 🐔 Chicdat  Bawk to me! 10:22, 25 October 2021 (UTC)
That's incorrect. In fact the rollback right is required by quite a few tools for both technical and other reasons. "Tool confirmed" could also extend to providing trusted users with more powerful features and merge already complex permission systems together. ✨ Ed talk! ✨ 17:47, 25 October 2021 (UTC)
  • Literally the only thing that membership in the rollbackers group does is confer access to the rollback permission. The rollback permission allows an user to request a server-side reversion. None of these other scripts or clients are official and are subject to change on the whims of their maintainers, or in some cases by any user that wants to fork or recompile them. — xaosflux Talk 17:56, 25 October 2021 (UTC)
    Yes, that is technically what it does, but what I'm proposing is an expansion and restructuring of this policy, especially how a lot of people only apply for rollback for access to tools such as Huggle. ✨ Ed talk! ✨ 00:40, 28 October 2021 (UTC)
I agree that the current situation doesn't make as much sense as it should and that it should be improved. I specifically agree it's silly how we draw such a distinction between rollback and undo. Putting all of countervandalism behind a role might not be such a bad idea. Hear me out! Perhaps without the role, you could only improve existing edits by adding a citation, or rewording bad edits, but you wouldn't have an easy way in the software to undo them. Enterprisey (talk!) 08:30, 5 November 2021 (UTC)
Would this involve removing the “undo” button, which allows an easy way in software to undo edits? I imagine that doing so would have impacts beyond counter vandalism. — Mikehawk10 (talk) 15:39, 8 November 2021 (UTC)
@Mikehawk10: undo is all client-side, it really just helps populate your edit window and edit summary. — xaosflux Talk 15:57, 8 November 2021 (UTC)
While I'm in the mood for weird ideas, perhaps undo could be made available after you've added or edited X amount of text in articles, because indeed undo is useful for a lot of other edits. Enterprisey (talk!) 01:36, 9 November 2021 (UTC)

Disclaimer to posts on the confederacy and confederates

I am advocating that the below or something similar be added to EVERY page that is dedicated in anyway to the confederacy, anyone who fought for the confederacy, and for any groups the celebrate the confederacy. My ask for this is to simply present historically factual & accurate information. Over the last few years, the Jim Crow era statues to these treasonous people and the effort to continue to subjugate the African-American population have begun to be appropriately removed. Additionally, states have removed the confederate battle flag from the state flags in effort to stop celebrating a system as heinous what the confederacy was fighting for. It can easily be argued that because Wikipedia is often used by students as reference material and by people simply searching the internet for information that your pages without the header suggested below will do more harm and spread more misinformation than these statues ever would had they been left in place. And Wikipedia had a duty and moral obligation to present facts.

My suggestion for all confederate related pages is (all of this is true, factual and as neutral as is possible):

This man chose to serve and fight on the side of the Confederacy and against the democracy, the constitution of the United States during the American Civil War. The Confederacy was in direct violation of the US constitution thus by its nature serving to defend the confederacy was an act of treason against the United States of America.

The root cause of the confederacy was to maintain its economic system which was the enslavement of the African-American population. Only later did the southerners, including the Sons & Daughters of the confederacy propagate the mis truth of the lost cause, states’ rights, as the reason for the civil war. This is false. — Preceding unsigned comment added by Frank Conversation (talk • contribs) 02:09, 8 November 2021 (UTC)

Sidestepping the POV issue that is portraying the various institutions of the United States as indisputably good and beyond reproach, I'm just going to throw out there that the language is unencyclopedic and doesn't have a good place in most articles. theleekycauldron (talk • contribs) (they/them) 07:14, 8 November 2021 (UTC)
In general, mandating by policy that specific text be included in all articles that have some characteristic is not something we do. I understand the sentiment, though it might reasonably give undue weight to the status of some people as confederate soldiers, especially for those who became notable later in life for something else entirely. — Mikehawk10 (talk) 16:58, 8 November 2021 (UTC)
Why make confederate soldiers an exception to our general "no disclaimers" guideline? There have been many conflicts in world history in which one or both sides was just as, or even more, evil than the confederacy. We rely on the neutral point of view policy to take care of things. This idea smacks very much of American exceptionalism. Phil Bridger (talk) 18:26, 8 November 2021 (UTC)
Yeah. For nasty, horrible and evil, try Nazi human experimentation. I see no disclaimers there. --Redrose64 🌹 (talk) 19:37, 8 November 2021 (UTC)
All right, I think we've rained and snowed on this suggestion enough. I don't think this one's getting out of the lab. theleekycauldron (talk • contribs) (they/them) 20:48, 8 November 2021 (UTC)

I appreciate the thoughts and feedback. I in no way advocated that this type of disclaimer only be placed on Confederate pages; something similar should be placed on pages of Nazis, supporters/champions of other racist/violent/bigoted groups. So please argue that such a disclaimer be placed on those pages and I will support your efforts. These institutions/people must be appropriately identified as such. Leekycauldron your rain is acidic and frankly misplaced. — Preceding unsigned comment added by Frank Conversation (talk • contribs) 04:34, 9 November 2021 (UTC)

Again, I'm still going to push back on WP:NPOV grounds. We need to properly weigh reliable sources with different viewpoints in how we describe individuals. Would we want to put a giant disclaimer atop Pope Benedict XVI to say that he was in the Hitler Youth and therefore, by somebody's analysis, he was complicit in Nazi war crimes? I'd imagine not; that isn't how reliable sources describe him, though the Hitler Youth did indeed do some really terrible things. In general, the coverage of specific individuals, particularly for living people need more nuance than blanket statements posted in the articles of all people in X group. — Mikehawk10 (talk) 05:09, 9 November 2021 (UTC)
While I agree that those who performed, enabled or supported actions in the name of the Confederacy did "great wrongs", Wikipedia is not the place to right "great wrongs". We summarize what reliable sources have to say about subjects. We do not editorialize in Wikipedia. - Donald Albury 13:28, 9 November 2021 (UTC)

Gadget to automatically watch certain vandalism targets

The gadget would do something like this:

  1. Every hour or so, fetch a list of articles linked from the Main Page.
  2. If any page is not on your watchlist, or is watched for less than (say) 24 hours, add the page to your watchlist for (say) 36 hours.

Roughly speaking, Special:RelatedChanges/Main Page would be merged into your watchlist. Now if only a handful of people enable this gadget, it will hardly make a dent, but image if thousands of users install it!

And why stop at the MP? There's also Category:Recent deaths, Wikipedia:Requests for page protection/Increase, and probably other possibilities I'm not thinking of. To avoid cluttering the watchlist too much, semi-protected pages, or pages already watched by 500 active users could be excluded. Or maybe only watch a randomly selected 25 pages, instead of all of them.

You can see a simple proof-of-concept at User:Suffusion of Yellow/autowatch.js. There is no user interface; just install it and it will do its thing. If anyone likes this idea I'll continue to develop the script. Suffusion of Yellow (talk) 22:34, 8 November 2021 (UTC)

To be frank, I installed the program and i've still got the pages in my watchlist like weevils in my hair. this would have to be paired with watchlist categorization. theleekycauldron (talk • contribs) (they/them) 04:23, 10 November 2021 (UTC)
@Theleekycauldron: So, too many pages, then? Would it have been so irritating if only about 25 pages were watched? In any case, said weevils should have all died by now (36 hours). If not, something went very wrong. Suffusion of Yellow (talk) 18:40, 11 November 2021 (UTC)
the weevils have gone, thanks :) It's a bit too many pages for me, so if there were a way that it could be a separate, centralized watchlist, that'd be easier. theleekycauldron (talk • contribs) (they/them) 19:50, 11 November 2021 (UTC)
Well the idea is that people wouldn't have to click on a separate page. They can already click on Special:RelatedChanges/Main Page, or Special:RelatedChanges/Category:Recent deaths if they want. Suffusion of Yellow (talk) 20:30, 11 November 2021 (UTC)
@Theleekycauldron You mean something like Special:RecentChangesLinked/Main_Page? --Ahecht (TALK
PAGE) 20:40, 11 November 2021 (UTC)
Yeah, that's about what I'm looking for. I don't think we need much else/ theleekycauldron (talk • contribs) (they/them) 20:52, 11 November 2021 (UTC)

Add corporate Company/Charity ID to company info box. Cross check with registries

WAS AfD for companies - Add lookup of Company data via Wikipedia library? Companies are going to extreme lengths to falsify notability, size, and history.

Are there any stats on companies that pass NPP and/or AfC and are detected later? Better would be a random sample of companies

So, having a link to corporate registers might fix a few pathways - Fraudulent use of an old company's name that was notable - A new company or charity can find an existing Wikipedia article for an old company, create a company with the same or similar name, then update the page to show their current website page - A company can cease trading and there is no prompt. IF they had the Wikipedia page on file, we could get advised by the notices that are created by corporate registers - The size of the company can be manipulated - false charities in WP are particularly nasty, as they increase up the chance of scam sucess.


Before that - Would it help AfD, if Wikipedia Library arranged access to paywalled company data and this was accessible via their new search tool initially

The paywalled data would be things like

Wakelamp d[@-@]b (talk) 08:54, 12 November 2021 (UTC)

@Wakelamp: none of this would have any relevance to a company's notability. In terms of size, it's possible we might draw a staff number from one of these, though it's non-ideal, but our access to these wouldn't really give us any more reliable idea than what we have already. Nosebagbear (talk) 11:08, 13 November 2021 (UTC)
No change to what makes a company notable - The extra information] was to allow doubt to be cast on a apparently squeaky clean company, that had gamed wikipedia by using advertorials, or misled, or was reusing once notable company name. Wakelamp d[@-@]b (talk) 15:31, 13 November 2021 (UTC)

Spoken Wikipedia at WP:TFA, part 2

Now at VPR User:力 (powera, π, ν)

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.

Okay, after some discussion at WT:TFA, i want to iron out the text of my proposal concerning the narration of the blurbs at Today's Featured Article before the proposal goes to RfC. Pinging @Valereee and Maile66 as a part of the previous discussion.

Problem: The Main Page of English Wikipedia is regularly seen by 5.5 million people, of which a significant number are sight-impaired. While WikiProject Spoken Wikipedia exists to narrate existing articles, and has narrated hundreds of Featured Articles, users are currently not allowed to add recordings to sections of the Main Page. Not every section of the Main Page is easily narrated—Did you know, On this day, and In the news, for example, are too unpredictable to have immutable recordings attached to them. Today's Featured Article (TFA), however, consists of a single thousand-character blurb generally updated only once a day, ideal for a spoken recording.
Proposal: In every nomination template for TFA, there should be an optional "narration" parameter that allows the nominator, or any other interested editor, to add a spoken recording of the blurb that is to appear on the Main Page. A sample narration on a past iteration of the Main Page can be found here. No nomination will be required to contain a narration, but any recording that is attached to the nomination must be reviewed by an admin according to the guidelines laid out by WikiProject Spoken Wikipedia for technical quality, clarity, and accuracy before the recording can accompany the nomination to the Main Page. This proposal has the potential to help thousands in accessing the article Wikipedia's most proud of. This isn't limited to sight-impaired people, either; this proposal also accommodates those with reading disabilities, those too young to read, or those who just more easily digest information in auditory form.

Any constructive criticism of the proposal is invited! If someone knows how to make the language take itself less seriously, that'd also be welcome. theleekycauldron (talk • contribs) (they/them) 04:03, 10 November 2021 (UTC)

  • I like this idea a lot. My sole concern would be regarding the ability to fully vet the recording before the featured article would make it to the main page, though I do not believe that this would be too big of a logistical hassle to outweigh the benefits of including the spoken article for the sight-impaired or those who have limited literacy. This is something that's very thoughtful of you, Theleekycauldron. — Mikehawk10 (talk) 04:51, 10 November 2021 (UTC)
  • Support - I think the concept is very forward-thinking as we continue to build an encyclopedia accessible to everyone. This would accommodate not only the sight-impaired, but also anyone struggling with any reading disability, children too young to read, or any number of factors. — Maile (talk) 11:17, 10 November 2021 (UTC)
  • Since we're in VPI I won't do the bold !vote, but this seems reasonable unless a template-ite says there's a technical nuisance in doing it. Blurb lengths aren't very long, so compared to the effort in vetting an actual FAC, vetting the blurb (then or later) isn't significant. It's not akin to vetting a recording of the whole article. Nosebagbear (talk) 19:29, 10 November 2021 (UTC)
  • Like other MP content, would need to ensure that such media files are available under the CC BY-SA 3.0 License and/or CCO. They would also need upload protection applied (as this isn't inherited from cascading protection). — xaosflux Talk 19:34, 10 November 2021 (UTC)
  • From the sample at User:Theleekycauldron/TFA test, I don't like how much space the playback control is using here, also that specific layout is causing the border to be pushed out a bit. The first part is really up for discussion on how prominent/intrusive that control should be - the second needs some technical work. — xaosflux Talk 19:37, 10 November 2021 (UTC)
    @Xaosflux: I agree, that's been gnawing at me a bit, so work with me here—how would you make it smaller? I've shrunk it to 100px across, what other redesigns would you make? theleekycauldron (talk • contribs) (they/them) 21:18, 10 November 2021 (UTC)
    @Theleekycauldron: probably need a custom container for it instead of the default File: handler - that is likely what is interfering with the right side margins; as for sizing and styling - It could be good the way it is sized now, not sure though - that is something that needs some feedback perhaps. Maybe other following this can show some mock ups. — xaosflux Talk 00:04, 11 November 2021 (UTC)
    all right, all of that's noted—cart before the horse, though, let's try and get this proposal a bit closer to rock solid before the technical discussions theleekycauldron (talk • contribs) (they/them) 19:54, 11 November 2021 (UTC)
  • Great idea! Totally support. ~Gwennie🐈｟💬 📋｠ 00:13, 11 November 2021 (UTC)
  • Support We should let blind people be able to "see" the encyclopedia. 🐔 Chicdat  Bawk to me! 11:39, 11 November 2021 (UTC)
  • OK providing that it's technically feasible and that it works for blurbs that are more image than text; sometimes a TFA blurb needs to emphasize the image and show only little text. Jo-Jo Eumerus (talk) 16:25, 11 November 2021 (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.

Report :Do proposal discussion Editors match Active Editor Demographics

The Wikipedia:Wikipedianscommunity proposal consensus is only true consensus if it has involvement of all demographics in terms of years experience,and diversity. Not as a percentage, but least as a voice to explain different views. The Wikipedia foundation board is thinking of expanding to reflect diversity, but we don't know whether our consensus is being dominated by one group

A way of doing this would be to have reports that

  • Compare between proposal editors and Active Editors. the years of active editing, diversity, and editor type. (Diversity could be based on user page templates or Wikipedia:WikiProject_Accessibility membership).
  • Compare the voting percentage (Abstain, Support, Oppose) by years of active editing and editor type
  • Confirm whether a few voices dominate proposals. Consensus does not means the majority always wins, but you would expect that the majority would be in line with consensus most of the time

Why should we care? There is more editing to be done than has already been done; there are huge numbers of maintenance tags, article tags, open Talk topics especially non replied, various error reports, missing content, procedure readability improvements, missing or questionable references, missing or incorrect categories,mentors needed,stubs, low project membership, article quality etc,... Wakelamp d[@-@]b (talk) 07:47, 6 November 2021 (UTC)

Do you really mean if it does not have involvement? I believe you have the sense reversed in your lead sentence. — JohnFromPinckney (talk / edits) 09:23, 6 November 2021 (UTC)
Doh. Fixed Wakelamp d[@-@]b (talk) 11:13, 6 November 2021 (UTC)
I would be surprised if the average policy consensus was particularly representative of the community or of the readers, along any number of axes. The problem of backing that up with numbers is more thinking than I'd want to do on a Friday night, however. Enterprisey (talk!) 10:11, 6 November 2021 (UTC)
Agee.My Suspicions is that is wildly unrepresentative Wakelamp d[@-@]b (talk) 11:13, 6 November 2021 (UTC)
Just thinking about it, would it change anything.... probably not. I was interested to see if change was being blocked by WP:OWN editors Wakelamp d[@-@]b (talk) 14:34, 8 November 2021 (UTC)
Of course it's wildly unrepresentative, @Wakelamp. This is known. This isn't even hard to prove with purely public information. The median number of edits per registered account is either zero or one. Of the people who do make their first edit, most never edit again for months, if ever. Anyone who makes two edits has an above-average edit count. 95% (ninety-five percent!) of registered editors have never made 10 edits. 99.8% of registered editors haven't made it to 500 edits. Every person who has replied to you so far in this section is well beyond that level: we are all in the top 0.01% by edit count. We have made more edits than 99.99% of registered users.
My question for you is: Do you really want every discussion to be equally weighted by edit count, so that completely inexperienced people get the same say as people who know what they're talking about? Perhaps it would be appropriate for question that affect newcomers the same as they affect experienced editors (e.g., whether the default image size should be increased), but maybe other questions (e.g., whether a given source is suitable for a specific article) should prioritize experienced editors. Whatamidoing (WMF) (talk) 21:17, 15 November 2021 (UTC)
I agree 1 editor : 1 vote would not work with WIkipedia. There is too much experience needed. But my concern with this question was not about newish users (although the teahouse editors would make a good proxy), but about the current content creators, the crafters who work FA, etc. They may not do as many edits, but they create the content. So, I was trying to work out whether were represented, in some decisions For instance 1/ Allow IP editors. The consequences of that will be time and stress for NPP, CfD, (CfD already has a huge multi years backlog) And More NPP editors also create more tags, rather than fix tags (which affects wikignomes like me) 2/ Reference lists should not be defined in detail. Consequence of is that the Article Wizard can't ask them to fill in the references they will using before they spend 4 hours creating the article, then rage quit after AfD.3/ Clarity of procedures and guidelines - Does make it more difficult for those with less English skills, younger, or using voice readers to be editors? Does too much complexity encourage anger? Wakelamp d[@-@]b (talk) 13:45, 16 November 2021 (UTC)

Blockchain and Wikipedia

There is a lot happening in the blockchain world that is beyond crypto currencies. Non-fungible token (NFT) for example. Anytime you want to reward users towards a goal, or gameify a process to attract users, it might have an application. Is anyone working on, or proposed, or suggested, anything related to blockchain and Wikipedia? I'm not outright suggesting it be done, only want to learn more what is being done or discussed, if anything. -- GreenC 14:43, 6 November 2021 (UTC)

As someone dealing with ill-informed crypto boosterism creeping into my professional work, I really hope that I don't need to fight it on Wikipedia too. signed, Rosguill talk 15:16, 6 November 2021 (UTC)
I am not aware of any such proposals, and to be honest I hope none ever materialise. Blockchain has always looked to me to be mostly a solution in search of a problem. firefly ( t · c ) 15:24, 6 November 2021 (UTC)
Please no. I would certainly attract people, but not the people we need. Vexations (talk) 17:25, 6 November 2021 (UTC)
Time to start selling NFTs for each individual diff! --Masem (t) 17:46, 6 November 2021 (UTC)
Putting aside how silly the idea is in general, I wonder whether NFTs, to comply with CCYBASA 3.0 would inherently themselves be under that license Nosebagbear (talk) 16:58, 7 November 2021 (UTC)
Describing the idea as silly is harsh @Nosebagbear. @GreenC has just suggested an elephant sized tool for a mouse size problem.
@GreenC thank you for being on Wikipedia for 18 years, wakelamp said after looking at your user page. :-)
Blockchain raises high levels of horror in IT, because it provides security through high processing time on each transaction, and adds complexity to implementing what otherwise would be simple processes. This makes sense for some situations, but the desirability, monetary value, and importance of the an achievement badge does not justify it. NFTs are really for trading things or identifying things uniquely, but there is no standard, and it has the same issue as blockchains. To give you and indication of the differences, Openbadge.org is very small and very quick and uses a digital certificates similar to a website.
Gamification is worth discussing, because we have an issue retaining new Editors, an obsession with # of edits, and our ideals not matching our interactions. Also when I see a user page (your's excepted of course :-)) I always want to run screaming the word "Geocities" .
Here are two game systems assosciated with forum and the creation of contents https://boardgamegeek.com/wiki/page/BoardGameGeek_FAQ and https://whirlpool.net.au/wiki/wp_smileysystem . Wakelamp d[@-@]b (talk) 14:31, 8 November 2021 (UTC)
  • Wikipedia doesn't need a blockchain. A blockchain is used for distributed consensus. But Wikipedia has centralized consensus; everyone agrees on what part of the encyclopedia Special:PermaLink/1054013081 refers to. As far as NFTs, we have Barnstars, which are already on the "centralized blockchain". Sure, you can't sell barnstars for money, but you're not supposed to profit from your Wikipedia edits, remember? User:力 (powera, π, ν) 18:17, 8 November 2021 (UTC)
FWIW Everipedia uses blockchain. I've never used it but is an experiment in applying the tech to a wiki environment. -- GreenC 21:36, 8 November 2021 (UTC)
I have looked at their site- It seems to be about paying content creators with micro- payments [8] Wakelamp d[@-@]b (talk) 12:48, 15 November 2021 (UTC)
Eveipedia? That highly succesful experiment that e.g. lists Kamala Harris as Senator and Presidential candidate? I think we may consider Everipedia to be dead as a dodo. Even Joe Biden is still described as a candidate, and Donald Trump as the current president. Only blockchain and crypto articles still get updated, it seems. Fram (talk) 14:57, 16 November 2021 (UTC)
Everipedia do seem to be the parallel universe of Wikipedia. (even to the Other Founder having been the CIO)., But i think it is good that @GreenC brought them up. What would Sun Tzu advice? :-) .. What can we learn from them? Why didn't micro-payment work? Was their platform more attractive to some editors than Wikipedia? Wakelamp d[@-@]b (talk) 22:14, 18 November 2021 (UTC)

Talk and Article integration to reduce editing time

Topic was : Change TALK tab to show the # of non archived tasks The problem is TALK has no visibility on ARTICLE, TALK topic status is hard to know, and editing must be done on both ARTICLE and TALK. The Reader has no cues to article quality except maintenance template, and no incentive to look at TALK and become an EDITOR. An idea TALK Page

  • Topics to contain an additional shortcut status Template:Done, similar to subscribe.
  • the TALK Tab to shows the number of topics not DONE similar to inbox
  • Maintenance templates to create a linked TALK topics - changing to Done removes maintenance template. Changing status to undone ass its
  • Changing the first project importance and quality updates ARTICLE header

ARTICLE Page

  • Selecting ARTICLE Publish - List of topics shows to the left. Editor can select topic(s) and change status. Or open up topic and enter directly The Publish Summary is automatically added to the Topic at
  • Reverting a linked update on either reverts both

Topic was : Change TALK tab to show the # of non archived tasks Make the Talk Tab show the number of open non archived topics. So, similar to many systems for notifications, email, and messaging system Wakelamp d[@-@]b (talk) 16:00, 7 November 2021 (UTC)

On most talk pages, "archiving" isn't used, nor is there a "close" of topics. This could possibly be useful for pages on on projects that use Flow. — xaosflux Talk 16:07, 7 November 2021 (UTC)
@Xaosflux Flow is marked as historical. is EN going to use flow?
With archives, I was going to raise a separate idea, if this one had potential. That idea was going to be that Talk has an option to mark a topic as CLOSED, similar to archive/closed tag used on RFC, but also with an option to REOPEN.
These two ideas were to solve
  • An Editor on Article does not know there is anything on talk.
  • An Editor on Talk has to skim all Talk Topics
  • Maybe reduce the number of Talk Topics (especially from Newbies) that never get a reply
@Enterprisey I was after it for everyone Wakelamp d[@-@]b (talk) 13:42, 8 November 2021 (UTC)
Might be doable as a user script. WP:SCRIPTREQ to request. -- GreenC 17:12, 7 November 2021 (UTC)
You're in luck: User:Enterprisey/talk-tab-count Enterprisey (talk!) 21:11, 7 November 2021 (UTC)
Flow became mw:Structured Discussions - and enwiki isn't using it anywhere (for now) - some other projects do use it, notable mediawikiwiki. — xaosflux Talk 14:16, 8 November 2021 (UTC)
Do other editors Look at talk consistently? And what are the downsides of this idea? Wakelamp d[@-@]b (talk) 05:26, 12 November 2021 (UTC)
The chief downsides were given by xaosflux: we don't usually close or archive discussions, so it's impossible for a computer program to know if any single discussion needs a response. As a result, people would learn not to trust the number of topics displayed, because some of the topics could be obsolete.
If the idea is to get more people responding to talk pages, we could get a bot to comment on wikiproject talk pages with a random selection of talk page sections. But that would annoy people unless the links were all useful or interesting, so you'd need a human to do it anyway. That's a lot of work. Enterprisey (talk!) 09:17, 12 November 2021 (UTC)
The interesting or useful is really hard to detect. You can do keyword or weasel word searches, but how do you tell if they are interesting? Unless we allowed an editor to mark the topic as interesting.....hmmm.
We definitely shouldn't create extra work. I was looking through missing category history and a few other reports - we are indicating more work with tags and templates than we are getting rid off. (I was trying to work out a way of estimating the backlog).
I agree with you about archives..... Ok what about [[template:Done]] and squiggly brackets edit fully-protected ... answered=yes}} and Talk:Ninth generation of video game consoles. Wakelamp d[@-@]b (talk) 11:23, 12 November 2021 (UTC)
Flow is used on a few Wikipedias, plus MediaWiki.org. See mw:Talk:Sandbox if you'd like to try it out. The WMF has no current plans for developing it further. If anyone finds about $10M and a spare dev team lying about, please kindly contact me, and I will give you a list of bugs and missing features in Flow to fix first (I'll give you the list for free.  ;-)).
In terms of what to do, the Editing team is watching the ideas shared at mw:Talk pages project (and its multiple sub-pages). Different "stories" about how people think about talk pages are useful to them. For example, @Wakelamp seems to have a vision of a talk page that is a bit like a checklist of tasks to be accomplished. Other concepts are similar to spaces for decision-making, or a casual hangout spot. If you have a metaphor or concept (or a variant on a concept) that helps you describe what a talk page is for, then please post it at mw:Talk:Talk pages project. This kind of background or high-level information is more useful to the designer and product manager than you might guess. Whatamidoing (WMF) (talk) 21:33, 15 November 2021 (UTC)
It's good that the discussions are of use, and those metaphors are good, but I really really think WMF reach out to the different Talk user types . (BTW My vision is changing based on the discussions, and as I dig through the various areas, but it is based on the 4th Pillar "editors should treat each other with respect and civility" (with a bit of stretching))
  • Respect - Respect is not just listening to others you are in conversation with, it is also noticing that others have spoken. As a Wiki Gnome, my guess is 20 % of high importance talk topics are archived without reply, and nearly all topics on low importance articles never get a reply, or are even looked at. The stretch is that it it is also about being respectful of other's time - if something has been fixed, I don't need to know about it. If I must need to know about mark the topic as FAQ, In talk, refer to other's comments, and try to combine thoughts, not fragment them. All the article tags are a form of Talk - and most are a waste of time ; I can read an article and know it needs citations.
  • Difference - The casual hangout things a good idea, but it should be at a higher level. I know of know other forum that doesn't have a casual lounge,. Some Wikipedians would dislike it as wasting editing time, ,but they also don't understand that others are different. Who cares if someone spends all their time editing their user page ( as long as it is hidden from google and reader searches)? If it increases the chances that they might do 1 edit in main it's awesome, . If they don't it is our fault for not engaging them
  • Civility. This is declining I think, Many active editors have moved into tools, Many experienced editors, who were voices of moderation have got worn down and left,. New editors are not that attracted because of legalism and opaque rules. OVerall Wikipedia has an admin system for content and extremes,, but not a moderation system for medium bad behaviour. There are no consequences of being an ass. So I avoid long threads on Article Talk,
  • Wakelamp d[@-@]b (talk) 23:57, 18 November 2021 (UTC)

Sticky header

  Moved from WP:VPR

It would be very helpful if on mobile devices in portrait mode the website header, which includes the "Wikipedia" link and buttons for search, notifications, etc, had the CSS attribute "position: sticky;".

At the moment, on large pages users have to scroll right to the top of the page in order to search for another topic or access their watchlist or contributions. Most mobile devices in portrait mode have enough screen space to display such a small header permanently.

This is just an idea that I wanted to suggest. I don't spend much time editing Wikipedia these days and may not follow the discussion. If you'd like a response to any comments please ping me. Cheers. nagualdesign 13:45, 16 November 2021 (UTC)

I like this idea, and I"m not quite sure if my idea built off of this would be possible but, in order to not impede article space I think that the header should sort of "collapse" into the top of the screen as the user is scrolling and after they've sat there for a bit without scrolling, it would come back again. What do you think of this idea @Nagualdesign:? ― Blaze The WolfTalkBlaze Wolf#6545 14:32, 16 November 2021 (UTC)
What would be great, but I have no idea how to do it, is if the header moved just out of view when scrolling down and immediately came back in to view when scrolling upwards, like the top bar of the Chrome mobile browser. Position:sticky works fine though and is very simple to implement.[example] nagualdesign 15:47, 16 November 2021 (UTC)
  • Note: I moved this from VPR as this isn't a ready execute proposal - ping to prior participants: @Nagualdesign and Blaze The Wolf: — xaosflux Talk 14:35, 16 November 2021 (UTC)
    I don't seem to have been pinged but I watch the page so I did notice the move anyway ― Blaze The WolfTalkBlaze Wolf#6545 14:42, 16 November 2021 (UTC)
    Ping didn't work for me either. nagualdesign 15:47, 16 November 2021 (UTC)
  • Mobile devices should already be in mobile view (Example random article in mobile view). Are you referring to the <header class="header-container header-chrome"> element? — xaosflux Talk 14:44, 16 November 2021 (UTC)
    Of course mobile devices viewing en.m.wikipedia.org are in mobile view. Sorry, I'm not sure what your point is. As for your question, I can't give you a definitive answer as I cannot look at the source code using this phone, but by "website header" I'm referring to the grey navigation bar at the very top of the page, which shows (from left to right) a menu icon, the "Wikipedia" logo, a search icon, notification icon, and user icon. nagualdesign 15:47, 16 November 2021 (UTC)
    I just discovered that using the Chrome mobile browser you can view source code by prepending the URL with "view-source:". However, I could hardly make sense of most of it. In answer to your question I'd have to say I think so. nagualdesign 16:08, 16 November 2021 (UTC)
    @SGrabarczuk (WMF), I think Web is already working on this? WhatamIdoing (talk) 20:21, 17 November 2021 (UTC)
    That's true @WhatamIdoing although we're only building the sticky header for desktop. SGrabarczuk (WMF) (talk) 23:14, 17 November 2021 (UTC)

This Village Pump is for developing ideas, not for consensus polling. Rather than merely stating support or opposition to an idea, try to be creative and positive. If possible, suggest a better variation of the idea, or a better solution to the problem identified. Before posting an idea here, please read What Wikipedia is not to understand regular suggestions that will not be actioned12.249.218.202 (talk) 13:24, 19 November 2021 (UTC)

  • From what I can see so far, this would require a back-end change first (if you have a working personal CSS for this already - please point to the page that is successfully working) - as we certainly won't use a javascript hack for this (that is something that could be done as a personal userscript though). To request this be made available back-end, please file a feature request - you can model it off of phab:T283505 or one of its subtasks. — xaosflux Talk 14:24, 19 November 2021 (UTC)

Another page of users with most edits

Would it be possible to have another page of users with the most edits? WaterflameIsAwesome (talk) 04:04, 20 November 2021 (UTC)

Do you mean in addition to Wikipedia:List of Wikipedians by number of edits? — Mikehawk10 (talk) 04:59, 20 November 2021 (UTC)
Sure. The lists are user-generated by third-party tools and not official. Nothing prevents other users from creating their own list. The only question is "primary topic". Which list gets called "List of Wikipedians by number of edits". One option is make it a dab page. It depends if both lists are equally as good but have different features. It might require a vote to see. -- GreenC 05:53, 20 November 2021 (UTC)

Representation : Wikipedia Foundation Election Statistics

Do we need a better breakdown of the election statistics for the next WMF election? The 2021 election was very close (12 votes decided the 4th seat, and 212 separating first preferences for the 1st and 4th). Election irregularities didn't occur, but there was such a small turnout (6,873 votes) I must also explain that I am from Australia where election manipulation and irregularities (especially with STVs) are an artform, as we are "entirely peopled from criminals" to the point where thePublic Broadcasters election analyst is a national hero.

Irregularities I think could occur in a few areas 1/ Non-Editors (such as Foundation staff, external developers etc) can vote and could sway and there no is visibility of how many or for which candidate they voted. 2/ Audit. Statistics on irregular votes are not advised (votes are checked in the one week between the vote being complete and the announcement) and voters do not get confirmation of their vote. 3/ Group voting: Votes by Language edition or editor type were not advised for each candidate 4/ STV manipulation. STV voting only changed the vote for 4th place, But there are issues if

  • Electors don't know enough candidates. The record in Australia is 110 candidates for 6 positions. And in our case this is made worse as there is no visibility of candidates for re-election performance.
  • No criteria for a significant number of supporters to nominate a candidate.
  • Low voter turnout. STV has not changed turnout, but voter confusion from some countries was reported as STV was unknown
  • Candidates representing only 1 group

Overall, the issue is not misuse of cash or power, but the board being dis-functional or missing the skills the board asked for and identified was missing in . I raised similar issues on the election board. with JKoerner (WMF), but I have had more time to think now :-) I originally placed this one on the WMF page Wakelamp d[@-@]b (talk) 10:13, 4 November 2021 (UTC) Wakelamp d[@-@]b (talk) 00:39, 20 November 2021 (UTC)

No, we don't need the Ninja Turtles to audit the WMF election, and we don't need baseless fear, uncertainty, and doubt about the results. User:力 (powera, π, ν) 23:28, 20 November 2021 (UTC)
WP is not a democracy, but suggesting that "a better breakdown of the election statistics for the next WMF election" is FUD is too far; FUD grows when there is lack of transparency.
I wrote that "Election irregularities didn't occur". To be 100 % clear excellent candidates ( @rosiestep @Victoria @pundit and lorentzus ) were elected fairly.
BUT
Nonprofits have particular risks
- unwilling to admit corruption due to donation fears,
- boards not having the necessary skills especially to do with finance and detection of corruptions,
- Staff capture (the organization being run for the management's benefit or pleasure) especially in the creation of profit-making linked companies, and
- Volunteer disaffection.
So, any easy ability for management to manipulate governance must be blocked. (The Ninja Turtles would also make poor auditors) Wakelamp d[@-@]b (talk) 00:47, 21 November 2021 (UTC)

Prevent basic errors getting into articles

OP blocked as WP:LTA/BKFIP. Suffusion of Yellow (talk) 20:09, 22 November 2021 (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.

Wikipedia is based on the idea that it doesn't matter how poor your edit is; someone will fix it. In general, obvious vandalism is indeed fixed quite quickly. But edits that are well-intended but poor persist for years. Some of the most glaring issues that I frequently see include:

  1. First sentences which are a pointless restatement of the article title
  2. Bold text that does not correspond to the article title
  3. Use of contractions and ampersands
  4. Incorrectly capitalised section headings
  5. Links within section headings
  6. Links within bold-face reiterations of the article title
  7. Misuse of /

There are of course many others. But it would be trivial to prevent or inhibit any of these basic errors from ever getting into articles. A simple edit filter could apply simple quality checks, and warn the user if their edit fails them.

I can think of any number of advantages to basic quality control, and not a single disadvantage. Interested to know what other people think. 51.6.138.90 (talk) 10:19, 22 November 2021 (UTC)

The style guide Wikipedia:Manual_of_Style has discussions on MOS:AMP MOS:&, and Use of contractions and ampersands. They also give many exceptions such as AT&T and quotes containing contractions, Exceptions are what makes programming complicated. The disadvantage is that if you disallow such changes then an editor may not finish their edit, or worse quit Wikipedia Wakelamp d[@-@]b (talk) 12:25, 22 November 2021 (UTC)
I'm not suggesting disallowing anything. Rather, if one makes an edit that contains, for example, isn't, and the text is not within quotation marks. you would simply be warned that contractions should not be used, with a link given to the relevant part of the MOS. If there is some valid reason to use the contraction, you would just click save anyway. I can't remember how but I've certainly encountered edit filters with that behaviour before, where you can save the edit after a warning. 51.6.138.90 (talk) 13:05, 22 November 2021 (UTC)
I think it would result in user experience issues. It certainly makes me mildly annoyed every time I trip an edit filter. Kleinpecan (talk) 13:20, 22 November 2021 (UTC)
I would anticipate the user experience, if the filter were tripped, to be something like the following:
  1. user who did not read the manual of style makes an edit including text like "It should be noted"
  2. user is prevented from saving the edit immediately, with the reason displayed including a link to the MOS
  3. user revises their edit, and is less likely to make a similar mistake in the future
How would you see it playing out? 51.6.138.90 (talk) 13:43, 22 November 2021 (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.

Google Doodle advance notice

Whenever there's a Google Doodle honoring a person, it always drives a ton of traffic to their article. Sometimes we luck out and it's an FA, other times it's only start-class. Idk if Google would be willing to give us advance notice or who to ping at the WMF to get in touch with Google to ask, but it'd help to have some time to prepare the article. {{u|Sdkb}} talk 18:13, 8 November 2021 (UTC)

How much traffic are we talking? theleekycauldron (talk • contribs) (they/them) 18:17, 8 November 2021 (UTC)
@Theleekycauldron As a recent example, Charles K. Kao went from <400 page views per day to over 400,000 pageviews when featured in a Google Doodle earlier this week: pageviews. --Ahecht (TALK
PAGE) 18:31, 8 November 2021 (UTC)
Google states that the doodles are "surprising". Probably, they want to keep them a secret. Bada Kaji (talk • श्रीमान् गम्भीर) 18:45, 8 November 2021 (UTC)
Do New Zealand etc. get it early (when it's a global one)? If so they can alert the rest of the world. Nardog (talk) 19:21, 8 November 2021 (UTC)
holy crap. Yeah, we should figure out if there's a way we can get some advance notice. theleekycauldron (talk • contribs) (they/them) 19:00, 8 November 2021 (UTC)
Historical task force: Wikipedia:Articles for improvement/Google Doodle task force. {{u|Sdkb}} talk 19:12, 8 November 2021 (UTC)
Sdkb  How often would this occour per years? DO you know the rough split by quality for the last yeat?
Looking at the root cause, Maybe we should ask Google to prioritize high quality Article? Of if thy still want a low quality item arrange for them to contact an editor group offline?
Nardog  I am fascinated to know as well. I have asked the Kiribati Islands and Google Doodle on Quora Wakelamp d[@-@]b (talk) 03:38, 23 November 2021 (UTC)
Redoing ping of Sdkb and Nardog. Also @Wakelamp:, in your edit that added these pings, you used closing parentheses instead of braces. This caused an unclosed template which meant that all the section links after this one stopped working. I've gone and fixed it. Graham87 11:38, 23 November 2021 (UTC)

Bot collation of questions on low-watched talk pages

In the discussion at WT:CSD#File talk pages which consist only of boilerplates, wikiproject tags, and/or text which has been copied to Commons Jo-Jo Eumerus commented that File talk page discussions are pretty common but they usually don't get an answer. to which Redrose64 replied Mainly because they only have one watcher - the person who created the discussion. This got me wondering about the feasibility of (probably) a bot that looked for new posts to pages with fewer than N (actively engaged?) watchers and produced a list (or lists?) of such pages so that editors know that the posts exist and can go and respond if required. I don't know what a sensible value of N would be.

To avoid false positives the bot should ignore posts that consist of solely adding things like WikiProject tags, old deletion discussion notices, {{Talk page header}}, {{Talk page of redirect}} and probably others (as well as redirects to these templates) - I guess experience will show others as well, so the list should be easily configurable. Maybe also excluding things like {{help me}} which already generate notifications elsewhere - indeed maybe we would want to restrict it to certain namespaces only (Talk: and File talk: definitely; maybe Wikipedia talk:, Help talk:, Template talk: and Category talk: ?).

Some of what it will find will possibly be spam or junk, but then we can just remove this sooner than we otherwise would. It would expose that these pages have few watchers, but this bot will effectively make them more watched than average negating any benefit to knowing that. Thryduulf (talk) 17:03, 20 November 2021 (UTC)

I think this is a really good idea! CapitalSasha ~ talk 17:06, 20 November 2021 (UTC)
The big issue is file talk posts on enwiki that are about Commons files - usually they can't be actioned here. A differentiated solution may be needed for those discussion page posts that are about Commons files, because they need to be actioned on Commons if anywhere. Perhaps we could ask the Commons folks if they are interested in a dedicated collation of all enwiki file talk page posts that concern Commons files? Jo-Jo Eumerus (talk) 17:16, 20 November 2021 (UTC)
Some will be able to be dealt with here, and some by editors here making edits at Commons, but even though some will require action from Commons admins I don't think that means a list here would be without value. I can certainly see the benefit of putting such comments on a separate list to comments about locally hosted files though. Thryduulf (talk) 17:37, 20 November 2021 (UTC)
I like this idea. Another benefit could be that people post in the appropriate place, not posting where "there's more traffic" (but not necessarily more—or any—interest). That leaves discussions where they are relevant, and potentially, where others in the future will see them. — JohnFromPinckney (talk / edits) 20:43, 21 November 2021 (UTC)
@Thryduulf, I wonder what you think of phab:T295392. That would let you get a list of the discussions on pages you are interested in. Whatamidoing (WMF) (talk) 20:24, 22 November 2021 (UTC)
@Whatamidoing (WMF) while that's interesting and likely very useful, it's not the same as what I have in mind here. That seems to be:
  • Tell me when there are new discussions related to this list of things that I am interesting in
Whereas this is
  • Tell me when there are new discussions on pages that not very many people are actively watching
The latter will include pages that nobody has expressed an interest in (files and redirects will often only have a single watcher - the creator/uploader, who may not have edited Wikipedia for years), no WikiProjects have indicated belongs to their topic area, are too new for most people to know exist, etc. Thryduulf (talk) 20:58, 22 November 2021 (UTC)
What is the size of the issue? Are there any way to get the size of the problem? (Maybe by first project they belong to, Article importance and whether it is a new user (< x edits say)??
What do people think are the root causes for Editors creating discussions on no-watched/Low importance pages?
{{Thryduulf}} You mentioned interests - The biggest interest groups are projects. Would an addition to the new project dashboard showed the number of outstanding unwatched discussions encourage them being answered?
{{Jo-Jo Eumerus}} Can you explain about why the Comments can't be actioned here? I don't know anything about commons, Wakelamp d[@-@]b (talk) 02:37, 23 November 2021 (UTC)
Forget about "Commons", this is an issue that can arise on any little-watched talk page in any namespace. Second, a talk page question can be asked by any editor who ends up on a particular talk page, ranging from a genuinely curious reader who seeks clarification of something on the page or suggests a change to a WP:POINTy troll leaving an inappropriate remark. Sometimes articles on relatively obscure topics are created by editors who do little else in the encyclopedia and leave before a comment is added there. It's a good general cleanup project to address. BD2412 T 02:46, 23 November 2021 (UTC)
@Thryduulf I think your suggested report is of crucial important for Editor retainment because it makes them feel listened to, not isolated, and their needs are being met. In general, I am against many reports that are not run JIT on Articles. Many reports are unvisited except by search engines, have no or few using them (stubs, categories), are sometimes have completeness issues (Category-Article lists), but in this case a report is needed.
Some other things you may wish to consider to minimize the amount of Talks to review -
  • Prioritize new or returning editors
  • Exclude Topics that are in action or marked as done (There are done and in progress templates and it could work like the topic subscribe)
  • Excluding Topics that need no action (So we still need a done flag)
  • Can we get the discussion editor to make a choice? I believe strongly that editors should have the same information. Why not tell them there are no active watcher? And why not and remove inactive editors from article watch lists"
  • BOT created Topics - You would need to exclude, but do we need them at all?
  • I love the idea of identifying interests, but how??
  • Automation - Because of the size, maybe we need a tool with canned responses, a way of viewing a all the discussions and marking them done from Publish?
  • Responsibility - Many monthly reports seem to have gigantic backlogs (categories missing, stubs ..) How do we ensure that it is actioned? Wakelamp d[@-@]b (talk) 03:12, 23 November 2021 (UTC)
  • Sounds like a good idea to me. Enterprisey (talk!) 03:20, 23 November 2021 (UTC)
    @Wakelamp Responding to your comments in both messages:
    • If a page has WikiProject tags then it makes sense to flag the discussion to those projects (maybe as part of article alerts?) but not every page has them (e.g. random article took me to St. Louis School of Fine Arts where I have just created the talk page with project banners). So "interests" is not really relevant for this idea, my mention of them was distinguishing this project from the one @Whatamidoing (WMF) mentioned (where they are relevant).
    • I don't know how prioritisation would work, but if it can be done it might be useful. We shouldn't exclude established users though, as I know that I have posted comments on low-watched talk pages of articles I have come across but lack the subject knowledge to fix.
    • I'm anticipating this bot waits a while (a few hours? a day?) before flagging comments in this way, and so it would likely make sense to exclude any that have responses (by registered editors?) as that would suggest the issue is being/has been dealt with. Similarly if the comment has been removed, it shouldn't be reported here (regardless of why it was removed).
    • If the list is long (I honestly have no idea how long it will be) then some way of highlighting when someone has looked at a comment to avoid duplicating effort would be good. Maybe just remove an entry from the list when you've dealt with it? Dealing with it could just be flagging the problem somewhere someone who knows what to do should see it. For example I wouldn't have a clue how to verify whether a comment saying that $article misinterprets South African law is correct or not, but I could flag it to the South African and Law Wikiprojects.
    • Posts by bots should not be reported here, but a comment followed by an edit by Signbot should be reported.
    • I don't know the size of the problem, so I can't say anything about what level of automation is worthwhile, nor what form it should take. I think this is something that might be best developed with experience after we get a feel for how it works in practice.
    • Getting things actioned is a realistic concern. I don't know how to ensure that, but if it doesn't happen we aren't actually any worse off than we are now.
    • Letting people know that a page has few followers is a double-edged sword. We don't do it now because it would make the page a magnet for vandalism, and if we aren't reporting things instantly that would still be a potential issue. Maybe just an edit notice for talk namespaces that note not all pages have active watchers? Thryduulf (talk) 13:18, 23 November 2021 (UTC)
    For the last bullet, the "Page information" feature's "Number of page watchers" entry shows "Fewer than 30 watchers" for non-admins. This was a deliberate decision not to show the exact figure, and has been discussed at both Help talk:Watchlist and at WP:VPT. Re the last sentence, we already have Template:Editnotices/Namespace/File talk, Template:Editnotices/Namespace/Category talk and several other similar notices. --Redrose64 🌹 (talk) 15:00, 23 November 2021 (UTC)

Quality control

WP:DENY.
The following discussion has been closed. Please do not modify it.

Please correct me if I am wrong; I believe there is no mechanism on Wikipedia to prevent bad edits from being made. I also believe that there are no mechanisms in place to effectively deal with bad edits once they have been made. By this, I mean edits which might be well-meant, but are of poor quality. I ask this because I observe that poor quality content and serious errors can be found in almost any article you might care to look at, and if ever I investigate the article history, I usually find that the poor quality material has been in the article for many years. DSMN-IHSAGT (talk) 14:50, 6 December 2021 (UTC)

DSMN-IHSAGT, WP:Sofixit. - Cabayi (talk) 14:53, 6 December 2021 (UTC)
In what way do you think that answers my question? DSMN-IHSAGT (talk) 14:57, 6 December 2021 (UTC)
You didn't ask a question DSMN-IHSAGT you made a declarative statement. Yes, that situation exists on numerous articles here at the 'pedia. Please be aware that there are edit filters that erase some bad edits. For the rest it is the nature of a website that anyone can edit that there will be problems that need fixing. Please feel free to improve articles as you see fit. MarnetteD|Talk 15:05, 6 December 2021 (UTC)
OK then, to be clear, my question is: is there really no effective mechanism to prevent bad edits from being made, or from dealing with them once they have been made? DSMN-IHSAGT (talk) 15:34, 6 December 2021 (UTC)
What 'mechanism' would you propose? AndyTheGrump (talk) 15:37, 6 December 2021 (UTC)
I can think of plenty. I just want to be sure that my interpretation is correct; that there is no mechanism in place to prevent bad edits from being made, or to deal with them once they have been made. A specific example: 14 years ago, an anonymous editor added a lot of text to Neuchâtel that was not encyclopaedic in content or tone (see Special:Contributions/132.156.198.16). Today, I found that much of that poor content was still in place. I observe that a majority of articles contain significant quality deficiencies, so I see two possibilities: a) there are mechanisms in place to deal with poor quality, but the rate at which poor material is added exceeds the rate at which it is dealt with; or b) there are no mechanisms in place. If the former, don't they need improving? If the latter, don't they need to be put in place? DSMN-IHSAGT (talk) 15:47, 6 December 2021 (UTC)
There are lots of processes and mechanisms in place to deal with "bad" edits - depending on the definition of bad. You can learn more about these at Wikipedia:Recent changes patrol. — xaosflux Talk 15:50, 6 December 2021 (UTC)
OK, well, then it seems to me that these mechanisms are just not up to the task of ensuring that edits are predominantly good, or are dealt with rapidly if they are bad. Shouldn't they be improved?DSMN-IHSAGT (talk) 16:58, 6 December 2021 (UTC)
It is true that many edits deteriorate the contents of Wikipedia, but the model of letting anyone edit, including making less than optimal edits (at least until an editor demonstrates that their edits have a serious detrimental effect on the encyclopedia) is what has brought Wikipedia to its present state. We must be careful that any method of preventing "bad" edits does not end up killing Wikipedia. - Donald Albury 16:41, 6 December 2021 (UTC)
I agree with you that the model brought Wikipedia to its present state. But that state is that most articles have serious deficiencies. How would a method of preventing bad edits ever kill Wikipedia? DSMN-IHSAGT (talk) 16:58, 6 December 2021 (UTC)
  • Because good edits will also be prevented. If it was easy for software to determine whether an edit was good or bad, then it would be easy to have the software write Wikipedia articles.
  • Because humans, including Wikipedia editors, learn from making mistakes. If you prevent all bad edits, you prevent many useful forms of learning.
WhatamIdoing (talk) 20:35, 6 December 2021 (UTC)
I can easily imagine simple mechanisms that would prevent certain types of bad edit from being made, and that could not possibly prevent any good edit from being made. I disagree entirely with your premise that "determining whether an edit is good or bad" is a problem of equivalent complexity to "writing an encyclopaedia article". And part of my point is precisely that there is no mechanism for anyone to learn from their mistakes. Some simple QC checks which warn the user about common errors would provide precisely that. Preventing bad edits provides a useful form of learning. I've commented similarly below. DSMN-IHSAGT (talk) 21:44, 6 December 2021 (UTC)
  • There are many "mechanisms" to prevent poor quality edits being made, but none work perfectly, and once in place for a while, poor edits often remain for a long time. As an example, a rather high proportion of your own c. 40 edits (all in the last 2 days) have already been reverted - so the system does work, fairly well! Johnbod (talk) 17:03, 6 December 2021 (UTC)
I like your use of passive voice to describe your own actions. You provide another excellent example. You made a series of edits a month ago, in which you started with a pointless restatement of the article's title (do not introduce the list as "This is a list of X"...), misspelled "officially", wrote "This is the case in Ireland also" instead of the idiomatic "This is also the case in Ireland", used relative time references twice, and falsely claimed that the government of Ukraine is seeking "to make the rest of the world say Kyiv". There were no checks in place to stop you doing this, and your errors remained in place for a month until I fixed them. Why on Earth would you have just put them all right back? Did you not understand that they were errors? Did you simply resent someone else fixing your errors? Either way, it illustrates the issue extremely well. Had there been even so much as a spell-check in place to warn you that you'd made a mistake, it would have been a positive for the encyclopaedia. DSMN-IHSAGT (talk) 17:30, 6 December 2021 (UTC)
No, apart from the one-letter typo, which I corrected, I do not think they were "errors", which is why I reverted. It is remarkable how high a proportion of your edits were problematic. Given the very bad-tempered tone of your edits here and your edit summaries, and your fluent command of in-house jargon, one is bound to suspect this is not your first rodeo. Johnbod (talk) 17:42, 6 December 2021 (UTC)
It is remarkable how many of my edits, which corrected grammar, spelling, factual and style errors, you have a problem with. Nobody else has reverted any of my edits. And why would they? You seem to me to exemplify many problems with Wikipedia; you contributed extremely poor content and not only was there nothing to prevent you from doing so, there is nothing now to prevent you from aggressively restoring your errors. And you even argue that they are not errors! I linked to the easy-to-find (and also common sense) guidelines that I was following. Do you not understand them, or are you consciously flouting them? DSMN-IHSAGT (talk) 18:01, 6 December 2021 (UTC)
No longer true - see Canal - your change there was reverted within 2 minutes. Johnbod (talk) 18:37, 6 December 2021 (UTC)
And my, you must have been giddy with excitement when you saw that. I had inadvertently introduced an ugly repetition; someone reverted that. Fair enough. Ideally, they would not have simply restored the problem that I'd fixed but instead improved the article still further. But I then did that. Unlike you, I am capable of understanding that I made a mistake, and would not dream of reacting as inappropriately as you have done to being corrected. DSMN-IHSAGT (talk) 18:58, 6 December 2021 (UTC)
  • Discussion on article talk pages is important for quality control, as well as other things. Try it. Phil Bridger (talk) 18:05, 6 December 2021 (UTC)
To take the example I highlighted above at Neuchâtel, the poor text was never discussed when added in 2007 or at any time since. So I would argue that talk pages are not an effective mechanism for quality control. DSMN-IHSAGT (talk) 18:09, 6 December 2021 (UTC)
They are if you follow WP:BRD and discuss reverts rather than get offended by them. Why haven't you started a discussion at Talk:Neuchâtel? What makes you think that you have any less of an obligation to do so than any other volunteer editor? A project like Wikipedia can't get anywhere if people refuse to use the mechanisms that we have. Phil Bridger (talk) 18:14, 6 December 2021 (UTC)
The user who is reverting my edits at Neuchâtel is doing so because they felt offended by my correction of their errors at another set of articles. I don't believe they are acting in good faith so I don't see any particular benefit to discussing anything with them there. DSMN-IHSAGT (talk) 18:18, 6 December 2021 (UTC)
I would have reverted some of your edits there (example – this word means different things in different English variants, so explaining it helps readers). WhatamIdoing (talk) 20:41, 6 December 2021 (UTC)
MOS:ENGVAR says use one English variant consistently within an article. It doesn't say provide synonyms for any word where usage might differ. DSMN-IHSAGT (talk) 21:51, 6 December 2021 (UTC)
This discussion is rapidly turning into nothing but editors griping at one another over disagreement of each others' edits. That's not what this forum is for, and those of us who monitor it for constructive discussions are having our time wasted.
Please limit your discussions here to the topic of general issues and suggestions for improvements of Wikipedia. TJRC (talk) 19:33, 6 December 2021 (UTC)

Quality control mechanism

WP:DENY.
The following discussion has been closed. Please do not modify it.

There are many, many common sense guidelines which it would be easy to automatically check that edits comply with. A simple set of regexes applied to the diff of an edit could check, for example, that section headings were correctly capitalised, acronyms defined, list articles did not start with "This is a list", etc, etc. People take it very personally if you tell them they have made a mistake (see above) but it is exceedingly common for mistakes to persist in articles for years. So automated warning is really essential, I think, to prevent mistakes from being made. A simple warning that your edit might not comply with some guidelines - what downside could there be to that? DSMN-IHSAGT (talk) 18:18, 6 December 2021 (UTC)

Alphabetically, or in order of likelihood?
Seriously, this is partly done with the Special:AbuseFilter, user scripts, and anti-vandalism bots, but processing speed (you would have to check thousands and thousands of rules) and the damage caused by both false positives and false negatives are significant barriers. As a thought exercise, imagine what rules you would need to write to evaluate just the single article Profanity. Write it in regex, or write it in plain English, but write it down, and see how many rules it takes you just to reject edits that add words related excrement, except when it's potentially encyclopedic content (e.g., Poop humor, Fart joke, Toilet humour, Scatology, etc). WhatamIdoing (talk) 20:52, 6 December 2021 (UTC)
You're talking about vandalism I think. I'm talking about quality control checks, and specifically ones that would be simple to implement. Like, checking that section headings are correctly capitalised. My thought experiment is as follows:
  • case 1, no QC mechanism. User writes ==Section Heading== and hits save. Article now uses incorrect style. Likely outcome: nobody says anything to them, and the incorrect style will remain in place for a long time. Possible outcome if someone does say something to them: user gets offended.
  • case 2, QC mechanism in place: User writes ==Section Heading== and hits save. But instead of the save going through, they see a warning saying something like "section headings should be in sentence case, not title case. See Wikipedia:Manual_of_Style#Article_titles,_sections,_and_headings. Please either fix this, or just press 'save' if the guideline does not apply (eg a person's name is in the heading)." Likely outcome: user fixes the capitalisation before saving. Also likely outcome: the user, now being aware of the guideline, will correctly capitalise headings in the future.
What would the downside be? DSMN-IHSAGT (talk) 21:39, 6 December 2021 (UTC)
That might deal with a few trivial errors, but we have a much bigger problem with editors who are so convinced that they are right that they don't need to follow normal consensus-building practices, such as using article talk pages. Dealing with such editors would help us much more with quality. Phil Bridger (talk) 21:53, 6 December 2021 (UTC)
Content disputes affect a minority of articles; simple and easily avoidable errors, a majority. Are you saying that simple and easily avoidable errors are not worth worrying about? See Broken windows theory. DSMN-IHSAGT (talk) 22:20, 6 December 2021 (UTC)
I think many of the things you cite as examples are both extremely minor errors (and indeed, are actually stylistic variations that are "wrong" only by Wikipedia MOS standards) and subject to false positives. Either of those characteristics indicate things that ought not to be baked into the underlying configuration; where both both are true, that's especially so. They might be good candidates for bots, which can be both shut off in case of excessive false positives and can be expressly warded off with things like {{not a typo}}, {{text}} or the like. TJRC (talk) 23:06, 6 December 2021 (UTC)
Which things that I've cited do you regard as too minor to care about, and which do you think could not be checked without giving false positives? I think that fixing a simple error later with a bot has exactly the same advantages and disadvantages as raising a warning before the error can be saved, except that the person making the error would not be made aware of it. DSMN-IHSAGT (talk) 23:17, 6 December 2021 (UTC)
Capitalization of section headings is an example. Sometimes, title case is correct. And the reader gets the same value from the article whether section heads use title or sentence case. Schazjmd (talk) 23:20, 6 December 2021 (UTC)
In the process I outlined above, I noted that specific possibility. If title case were correct, the user could simply ignore the warning and save anyway. I don't think the reader does get the same value from a badly-presented article as they do from a well-presented one; that's really the whole reason that any publication has a manual of style, isn't it? DSMN-IHSAGT (talk) 23:28, 6 December 2021 (UTC)
Just so we're clear, I haven't said anything is "too minor to care about". I've said the things you point out are too minor to be automatically attempted to be "corrected" by error-prone technology which is as likely to make things worse than better.
Are you actually here for a serious discussion or are you just interested in having a fight, being inflammatory and burning straw men? TJRC (talk) 23:23, 6 December 2021 (UTC)
Sure, yeah, it could have potential. See Wikipedia talk:Making editing easier 2021#Text reactions. People worry about false positives but I suspect the correct balance to be drawn is not all the way on the side of "don't show hints if there's a chance they'll be wrong". Enterprisey (talk!) 00:05, 7 December 2021 (UTC)
Doing it even as editors type is something I'd never thought of. Sounds very interesting, I'll read and comment there. DSMN-IHSAGT (talk) 12:22, 7 December 2021 (UTC)
Nobody has mentioned ClueBot NG (talk · contribs) - example edit. --Redrose64 🌹 (talk) 09:30, 7 December 2021 (UTC)
I can see that anti-vandalism mechanisms work generally well because I rarely see articles that contain obvious vandalism. But I'm talking about errors, mistakes made by well-meaning editors. I see those in the vast majority of articles, so whatever mechanisms exist to deal with them, don't work. DSMN-IHSAGT (talk) 12:21, 7 December 2021 (UTC)

Are we too focused on number of edits?

I can't find any proposal to add another measure that recognizes the people who create lots of non-reverted content, or for the people that fix up issues, or people who do AfD /AfC, or discuss on talk, etc.

"What gets measured gets done." may have been said by W. Edwards Deming who would have made a very good editor, Wakelamp d[@-@]b (talk) 12:59, 15 November 2021 (UTC)

Wakelamp d[@-@]b (talk) 12:59, 15 November 2021 (UTC)

Wakelamp, This has been a topic of numerous academic studies. Some have proposed various better measures, but they did not get much traction. In the end, most of these require database analysis that is either difficult or simply nobody bothered with implementing them, so we are still stuck with a simple edit count. Piotr Konieczny aka Prokonsul Piotrus| reply here 11:23, 22 November 2021 (UTC)
The database analysis issue might not be that bad - we already access every single record in the user file and every single record in the edit history. If we can use fields on those files it might be easier. . My thoughts were number of edits would be split into tool/non tool and the same for number of characters
  • Ok - Number of characters
  • ??? - Tool Assisted
  • OK - BOT edit
  • Ok - Roll back / reverts
  • ??? tags removed - tags added  ???Good faith New Editor genuine Interactions -
  • ?? - Roll back / reverts
  • ?? - Number of AfD or speedy template
  • ?? - Number who have not edited since you AfD/Roll Back/Revert Wakelamp d[@-@]b (talk) 15:57, 22 November 2021 (UTC)
Registered editors by edit count (all registered accounts)
If you have made... you are about 1 in then you rank in the... or the... That's more than...
1 edit 3 top 30% of all users top 14,100,000 of all users 70% of all users
2 edits 5 top 20% of all users top 9,400,000 of all users 80% of all users
5 edits 10 top 10% of all users top 4,700,000 of all users 90% of all users
10 edits 20 top 5% of all users
(the autoconfirmed) 		top 2,360,000 of all users 95% of all users
100 edits 100 top 1% of all users top 473,000 of all users 99% of all users
500 edits 400 top 0.25% of all users
(the extended confirmed) 		top 118,000 of all users 99.75% of all users
1,000 edits 1,000 top 0.1% of all users top 47,000 of all users 99.9% of all users
10,000 edits 4,000 top 0.025% of all users top 11,800 of all users 99.975% of all users
25,000 edits 10,000 top 0.01% of all users top 4,700 of all users 99.99% of all users
50,000 edits 20,000 top 0.005% of all users top 2,300 of all users 99.995% of all users
100,000 edits 50,000 top 0.002% of all users top 900 of all users 99.998% of all users
250,000 edits 200,000 top 0.0005% of all users top 200 of all users 99.9995% of all users
500,000 edits 1,000,000 top 0.0001% of all users top 50 of all users 99.9999% of all users
1,000,000 edits 3,300,000 top 0.000031% of contributors top 13 of all contributors 99.99997% of all contributors
For the purposes of this table, a "user" is a person who has a registered account on the English Wikipedia.
Registered editors by edit count (only successful contributors)
If you have made... you are about 1 in then you rank in the... or the... That's more than...
1 edit 1 – one of 14,100,000 contributors –
2 edits 1-2 top 65% of contributors top 9,200,000 of all contributors 35% of all contributors
5 edits 3 top 30% of contributors top 4,200,000 of all contributors 70% of all contributors
10 edits 5 top 20% of contributors
(the autoconfirmed) 		top 2,839,000 of all contributors 80% of all contributors
100 edits 40 top 2.5% of contributors top 354,000 of all contributors 97.5% of all contributors
500 edits 133 top 0.75% of contributors
(the extended confirmed) 		top 106,000 of all contributors 99.25% of all contributors
1,000 edits 200 top 0.5% of contributors top 70,000 of all contributors 99.5% of all contributors
10,000 edits 1,000 top 0.1% of contributors top 14,100 of all contributors 99.9% of all contributors
25,000 edits 3,333 top 0.03% of contributors top 4,200 of all contributors 99.97% of all contributors
50,000 edits 6,666 top 0.015% of contributors top 2,100 of all contributors 99.985% of all contributors
100,000 edits 14,000 top 0.007% of contributors top 900 of all contributors 99.993% of all contributors
250,000 edits 66,666 top 0.0015% of contributors top 200 of all contributors 99.9985% of all contributors
500,000 edits 250,000 top 0.0004% of contributors top 50 of all contributors 99.9996% of all contributors
For the purposes of this table, a "contributor" is an account with at least one published edit on the English Wikipedia.
Of course we should have a measure which is more meaningful than number of edits... but it's hard to imagine an automated measure that could not easily be gamed. Encouraging pointless edits (as we currently do) is certainly counter-productive. Fabrickator (talk) 13:40, 15 November 2021 (UTC)
See WP:EDITCOUNT.--♦IanMacM♦ (talk to me) 13:43, 15 November 2021 (UTC)
Wakelamp, I made this table for you. WhatamIdoing (talk) 17:32, 16 November 2021 (UTC)
@WhatamIdoing: Just curious, are those edit counts global or just for enwiki? 192.76.8.91 (talk) 03:33, 17 November 2021 (UTC)
Thank-you for the table. I think it does gives a good indication of experience up to a point, but do you think it encourages peoples to use automated tools? And to encourages people to move from content creation to tool use? And maybe the word top is not the best? And it also has the disadvantage that it makes it impossible for Junior editors to catch up.
There are a number of statistics already in place and measured
X tools gives you 1/ edits in main, talk, wiki 2/ manual or bot/tool assisted 3/ % of edits classified as small, medium, large. 4/ You can also see that in the last 30 days there have only been 100 active admins
http://en.wikichecker.com/
I just found a research project that also measured whether words that you added stayed roughly in the same place versus the the current version. It also measured the number of hours worked. It's a few years old, but the charts are great but it makes the following points
  1. Registered editors in English Wikipedia are not getting less productive despite a dramatic reduction in the active population of editors. {BUT it also discusses that this is due to tool use}
  2. Anonymous editors contribute substantially to overall productivity; however, their proportion of overall contribution has been steadily declining since the beginning of 2006.
Wakelamp d[@-@]b (talk) 11:18, 17 November 2021 (UTC)
I think that focusing on any metric can encourage people to "win" by that metric. Having multiple metrics can balance these effects.
OTOH, I think that if more of the people on this page knew that we were (almost) all in the 99.9th percentile, we might be less inclined to think that we were "typical" editors and that what works for us is what works for all editors. WhatamIdoing (talk) 23:02, 17 November 2021 (UTC)
These numbers are enwiki only. WhatamIdoing (talk) 19:19, 17 November 2021 (UTC)
@WhatamIdoing: Won't the results be rather skewed then by potentially millions of editors who signed up to edit other languages and other projects, who had accounts created here automatically by central auth without the user asking for one (or even necessarily wanting one)? 192.76.8.95 (talk) 10:28, 18 November 2021 (UTC)
Yes. It also includes people who tried to edit but couldn't figure out our software. WhatamIdoing (talk) 17:24, 18 November 2021 (UTC)
...and users who just created an account to set up their display preferences or keep a watchlist. Cabayi (talk) 14:33, 20 November 2021 (UTC)
I have created a table just as a discussion piece for some major areas, and how I think their work relates to the number of edits. I have added in experience level and automation, to show my understanding that experienced editors use the automated tools more for instance (NPP Editor requirements). Part of this was inspired by reading the very interesting essay User:Cullen328/Smartphone_editing by User:Cullen328. It made me understand the work that dedicated "artisanal" editors do. He uses no tools, but has done 80 K edits; so I created a separate row for editors like him. :-) Wakelamp d[@-@]b (talk) 11:34, 17 November 2021 (UTC)
Article Stage Work Edit? Edits/Hour Experienced
or
Junior 		Stress Cause Part of a team Visible measure Backlog
New Articles Content Manual 1 o 2 Both Inexperience and Rejection
Article Wizard does not have the same checks as NPP
Large amount of time to create first article 		No Deleted Articles No
Redirects links Scripts Immense Exp None No ???? No
AfC Content
Support 		Manual Few Exp New User Aggression from not understanding process
High Backlog
Lack of Resources 		Yes See discussion on AfC page Medium
Support , Help , Teahouse Support Manual Few Exp Agression Yes Thanks No
NPP /Page curator/ Copyrights Defence Tools Large Exp Low - high sense of satisfaction Yes NPP measures No
AfD, images, copyright Defence Manual Few Exp Aggression - especially based on country etc
Scammers
Systematic issues
Fraud 		Yes Backlog
???? 		????
CfD Judge Manual Few Exp Very low resources
Highest Backlog
650 K + categories- nearly all not accessed
Over-classifiers
No category approval process
Very easy to create new categories on the fly
No process to ensure category-article process 		Yes Age of categories Increasing and Huge
Stub, Maintenance tags,templates Error ID Tools Large Exp None Yes ????

 ????
Small fixes Error Fix
Small Content 		Some tools Few IP
Junior
Gnomes 		Insufficient Resources
Errors are mostly obvious - so why tag, as more work
Sense of satisfaction varies

Low automation / multi screen process

Talk is a waste of time on low importance 		Many projects
are dead 		No measures of tags removed
No automatic rating change
(for low importance) 		Very large and increasing
- increase in various errors
- movements in quality ratings
- templates are in place for years
Animators, Artists Images Manual None ?? ??? ???? ???
Talk Content Manua
 Low Exp Conflict seeking, Ad Hom, OWN,,
Admin shortage
What is important ?
What has already been fixed, but no one closed the talk?
Poor user of talk (splitting threads, no consensus building) 		No None Decades
Content Creators Content Manual Lower Junior Overcategorisers
Lack of resources 		Tech Areas Yes
Other Areas vary 		Self Direected
Decades
Quality Ugr Content Manual 1 o 2 Both Either high interest areas
or
Artisanal solo editors working through their interest areas 		Tech areas - yes
other areas vary

 lone Centuries
Featured Article Contents Manual 1 o2 Exp Resourced
Artisanal

 Yes Featured Articles No
Projects Content
Improvement 		Manual
But
Some tools 		??? Exp Many dead.
No recruitment prompts
Unclear purpose sometimes
Community is criticised by some
Some work well, but they need a clear purpose 		Varies ???? ????
Proposals Proposals Manual Low Exp ???? ???? Qualitative measures only ????
Policies and Procedures Talk Manual Low EXP Conflict
Resistance versus Reform
 ???? No measure of effectiveness
No readability
Extra work is not of concern 		????
Bot writers Tech Manual Low Exp Maintaining data used by scripts
Unclear procedures
Distrust by some editors of IT and Wikimedia 		???? ???? ????
Admin Prosecutor
Investigator
Judge 		Tools

Manual 		Low

High 		Exp Aggression
Resources
Stress 		???? ???? ????
Wakelamp d[@-@]b (talk) 11:34, 17 November 2021 (UTC)
@Wakelamp, I think that if you are trying to find metrics, then you should look at the edits by Alexbrn. He spends a lot of time removing bad content. His average edit "contribution size" is a negative number. WhatamIdoing (talk) 20:20, 17 November 2021 (UTC)
It's true I do. I'd be fascinated to know what my net article-space byte change number was! Alexbrn (talk) 20:34, 17 November 2021 (UTC)
@Alexbrn I would be fascinated too - I had not realised that the Ecclesiastian Editor("a time to tear down and a time to build") editor existed (There is also a Scottish word meaning Terse, but I can't remember it) In the opposite case, at the extreme , a metric that praised words, could lead to verbosity, or readability issues. Or on Terseness could lead to single word Laconic ("If") articles. ~~~ Wakelamp d[@-@]b (talk) 22:18, 17 November 2021 (UTC)
@WhatamIdoing I think you misunderstand my intent. I am not after metrics for their own sake. I have a few concerns
  • That a focus a single metric, (and the proliferation of tool use that has happened over the last 5ish year), has distorted editor behaviour, and
  • That large number of tag edits is not increasing the quality of wikipedia especially on low importance items,
  • That all Editor types (that have the same Goals as WIkipedia - so most Edit Wars should not be a thing), should be able to visibly see the value of their contribution to Wikipedia.
  • So, if metrics should be line with Goals, what are the most important measurable current, and long terms goals of Wikipedia? Wakelamp d[@-@]b (talk) 22:37, 17 November 2021 (UTC)
I'm not sure that most active editors are all that motivated by edit counts. Probably a few people are, at least for brief periods of time, but I'd guess that most people make edits out of a belief that their edits help Wikipedia. I might disagree that some of these edits are actually helpful (see, e.g., people who add Template:Uncat to articles, even though you could just use the automatic Special:UncategorizedPages if you wanted to find pages that needed categorization...), but I don't think people add those tags because it's a quick way to increase their edit counts. WhatamIdoing (talk) 04:08, 18 November 2021 (UTC)
Is there a current report on OAUTH /Bot/Tool assisted edits.. I saw a chart somewhere showing that I think 6000 users were using tools create half the edits NPP has a metric, but I am not sure what it measures
Wikipedia:New pages patrol/Backlog drives/November 2021 Wakelamp d[@-@]b (talk) 14:56, 19 November 2021 (UTC)
"most active editors are all that motivated by edit counts". Primary motivation varies as per the table, but there are lots of studies about people's behaviors changes based on how they are measured.. A few thought experiments
  • A proposal is put forward that the number of edits is done is hidden for all users
  • A proposal is put forward that the number of edits is no longer added to once it reaches a 1000
  • A proposal is put forward that no data will be made available that ranks users by number of edits

Wakelamp d[@-@]b (talk) 14:45, 19 November 2021 (UTC)

There is qualitative and quantitative, computers are great the second and terrible at the former. Meanwhile humans prefer qualitative and find quantitative to be a bad way to measure human performance. This is not unique to Wikipedia! Think of algos that rate people or schools. See Weapons of Math Destruction -- GreenC 21:00, 17 November 2021 (UTC)

That book looks excellent and I have now added it to my reading list. In the Other World, i have watched managers game metrics to achieve their bonus, at the expense of increasing costs/work/stress for others, and reducing the organisation overall. I found this immoral and abhorrent Based on your reading and experience, do you think that computers can measure qualitative issues that aren't about human performance (for instance Article Quality for low importance items, readability) and human performance that is not high stake (Well done on your third month of being an Artisanal editor OR achieving your personal goal OR you may be working too many hours OR are involved in many conflicts -Wikipedia can wait. ~~~ Wakelamp d[@-@]b (talk) 22:59, 17 November 2021 (UTC)
With Google resources :) Hard to say maybe it's a matter of building blocks not today but with semantic web data in place things more possible in the future. -- GreenC GreenC 05:27, 18 November 2021 (UTC)
I think we need at least a split between bot/tool, and manual edits. There has been a massive migration to tools. And tools don't create content Wakelamp d[@-@]b (talk) 09:00, 18 November 2021 (UTC)

Honestly I feel like 1 edit should not be top 50%. This means that with just a simple edit, you're already on of the 50% people with the most edits? ???????????????? I think there should be more, like 15 edits or 25 edits, something like that, to make it look serious. Because that doesn't make much sense to me. WaterflameIsAwesome (talk) 02:34, 18 November 2021 (UTC)

"Top 50%" is a generous rounding on my part. 71.3% of registered editors have never made an edit here. The next 10.4% have made one edit, but only one. The next 4.9% have made exactly two edits. If you have managed to make five edits here, then you are in the top 10% of contributors to the English Wikipedia (by number of edits). WhatamIdoing (talk) 04:04, 18 November 2021 (UTC)
71.3 % is rather large ..... anywhere else I would say it was a bot farm..... Do we know the distribution of account creation??? This doesn't include IP editors does it?? Wakelamp d[@-@]b (talk) 06:32, 18 November 2021 (UTC)
It does not include IP editors. It includes people who didn't know that accounts are unnecessary, people who edit other Wikipedias, and people who tried to edit but couldn't figure out how. WhatamIdoing (talk) 17:25, 18 November 2021 (UTC)
@WhatamIdoing "people who tried to edit but couldn't figure out how." That's just depressing. I am analyzing all the New Article pathways, at the moment and I didn't have that one :-(. (Although I did have stuff about not understanding procedures), Can wiki detect new users who start an article and give up, or are user pathways tracked? It would be interesting to know if that improves with Visual.
@WaterflameIsAwesome The only way to do that is to get more editors to edit. :
Wakelamp d[@-@]b (talk) 00:30, 20 November 2021 (UTC)
The devs can detect failed edit attempts, at least inside a Javascript-based editing environment. A "failed" attempt may be a good thing; it includes opening a page for the purpose of copying the wikitext, or opening the editing window and deciding that your planned edit (or comment) is a bad idea before you save it.
I suspect that this is in the category of sensitive data that is only kept for 90 days. The log item about the failed edit attempt probably (but someone would have to check) associates an IP address (or account id#) with the edit attempt. Once you know the editor, it should be possible to check Special:Contributions t see whether anyone using that IP had recently made a successful edit. I expect that this would be very painful to do manually, so you'd need someone with suitable privileges and automation skills to do it for you. WhatamIdoing (talk) 04:58, 20 November 2021 (UTC)
Seems like the first step in establishing percentages should be to cut off the long tail. "Editors" (people who register an account) who have never made an edit shouldn't be included in the computations. Schazjmd (talk) 15:25, 18 November 2021 (UTC)
@Schazjmd, in round numbers, that would give us:
  • 30% have made one edit
  • 15% have made two edits
  • 10% have made three edits (this is the median editor, 45th to 55th percentile)
and you would be number #2622 out of 12.2 million ever-successfully-edited-here editors, rather than #2622 out of 42.5 million registered editors. WhatamIdoing (talk) 17:33, 18 November 2021 (UTC)
  • Edit count is obviously a poor metric because it doesn't measure productivity – an edit can be good, bad or indifferent. And they are a form of cost or input, rather than being a measure of value-added output and achievement.
For an example of a better metric, consider the number of citations added which would be a better measure of quality content. Editors boost their edit count by gaming, griefing, gnoming, gossiping and grinding but these activities don't tend to result in quality content with citations. So, counting citations added might be a better proxy for measuring useful work.
For example, see performance indicator and note that it is banner tagged as needing more citations. The person who added that tag boosted their edit count but didn't add any citations.
Andrew🐉(talk) 14:27, 18 November 2021 (UTC)
How do we count citations? Citations may range over unformated urls or names of books, <ref>...</ref>, or {{sfn*}}, inline or at the bottom of the article. Some may need work to make them appear correctly, but shouldn't an ill-formed attempt to provide a citation count? I like the idea, but I do not want to be the one trying to build a bot to count citations. - Donald Albury 20:39, 18 November 2021 (UTC)
Apparently ORES data quality model counts ref tags, example use in educational dashboard here: https://outreachdashboard.wmflabs.org/courses/The_University_of_Hong_Kong/EASC4407_-_Regional_Geology_Fall_2021_(Fall_2021)/students/overview . Graeme Bartlett (talk) 23:18, 18 November 2021 (UTC)
Neat! I don't see how to access the counter. I am curious to see what it shows for my own edits. The note says it counts ref tags. I wonder if it also counts SFN* templates (which I use as often as I can, these days). I guess improperly formatted citations would have to be fixed before they were counted. - Donald Albury 23:46, 18 November 2021 (UTC)
  • ORES is a machine-intelligence mechanism which has to be trained with examples of good and bad edits. This has been done for particular Wikis in particular languages and the details depend on the way that the sample data corpus is labelled as good, bad or whatever. This is a good way of building a metric because, if you have a simple rule like counting edits or citations, then people will then abuse and game it per the cobra effect, Campbell's law, Goodhart's law, Parkinson's law, &c. Ultimately, we ought to be able to run articles through such a tool and decide whether they are good or not. And then attribute this goodness to the editors who wrote it, in proportion to their contributions to the final form. And the final stage will be when the machine intelligence can also write the articles and so cut out the middle men. This is coming too... "A robot wrote this entire article. Are you scared yet, human?" Andrew🐉(talk) 09:49, 19 November 2021 (UTC)
Here's my personal opinion:
1 edit: Top 90%
5 edits: Top 80%
10 edits: Top 75%
50 edits: Top 60%
100 edits: Top 55%
500 edits: Top 50%
1,000 edits: Top 35%
10,000 edits: Top 25%
100,000 edits: Top 15%
500,000 edits: Top 10%
750,000 edits: Top 5%
1,000,000 edits: Top 1% (13 people have 1,000,000 edits)
Obviously, the list would change depending on how many users reach a certain point, how many users DON'T reach a certain point, and how many registered users there are on Wikipedia in general.
I added 1,000,000 edits because of the fact that multiple people have passed it, and it's over 10. However, this is how the list would go on (:O):
10,000,000 edits: Top 0.1%
100,000,000 edits: Top 0.01%
1,000,000,000 edits: Top 0.001%
10,000,000,000 edits: Top 0.0001%
50,000,000,000 edits: Top 0.00001%
100,000,000,000 edits: Top 0.000001%
1,000,000,000,000 edits: Top 0.0000001%
I went all the way to 1 Trillion edits :O
I know this is a far-fetched opinion but please respect it lol
WaterflameIsAwesome (talk) 01:05, 20 November 2021 (UTC)
Number of edits as a measure
As per previous comments, tools make doing a reverts a single click, gives a strong sense of community, and there leader boards showing the number of reverts
BUT there are
Consequences of Reverts using tools - good faith newcomers edit less, are more hesitant for up to a month and leave WP faster., editors active after 2 years has decreased *was 40 now 12%).
  • A 2011 WMF by @EpochFail showed that sometimes what is reverted as vandalism, could be good faith newcomers, These good faith newcomers are far,far. more likely to have their first edit rejected, than the more experienced tool using editors were then they started editing
  • The WMF paper found that reverting tools are increasingly and far more likely to revert the work of good-faith newcomers. (s there a quality check on false positives??)
  • The WMF paper found these automated first edit reverts predict the observed decline in New Editor Retention - nearly 40% of new editors remained active for a year pre-2005, that number dropped to only 12-15% post-2007[
  • The WMF paper found that Tool users often do not engage in best practice for discussing reverts or in their interactions .[Maybe a way of reducing this is to have canned comments)
  • The WMF paper found that new users are being pushed out of policy articulation. Policies and guidelines are opaque and calcified, but Essays are being created to fix gaps. .
  • Two papers by the same author showed an 80 % reduction of edits by new editors who have been reverted compared to new editors that weren't. It wasn't the difference between Vandals and good faith; Both groups had an equal chance of being reverted in the next 5 weeks.
  • The same paper also mentions difficulty in "understanding the vast history of prior contributions, decisions, policies, and standards that the community has evolved over time.
  • Another paper mentions that a study on a 1000 University students found that editors who had an edit "unfairly" reverted where more likely to vandalize or feel personal animosity towards that edit. This seems at odds with the WMF paper, but this was a qualitative survey
  • This 2020 paper discusses these issues The following editors and others were recruited for a research project , were mentioned in the paper and may like to comment @Epochfail @jrmorgan, @Krinkle, @Chicocvenancio, @Rosiestep (Sorry, my second link to you today) , @Barkeep49 , @Nick Moyes @Timtempleton @SkyGazer 512 and @Ohanwe Emmanuel .I.. There are a large number of recommendations, but I would like to point to

"Users should be  incentivized  by  algorithmic  systems  to  behave  in  ways that create enduring value for the community."

  • The same issue of keeping new and different editors is brought up, along with a suggestion to explain that it is the AI making that decision. I am not sure whether that is best. Maybe a scheduled edit for far longer than 5 minutes for marginal cases (to make them feel like it took time to a review), and the editor ability to choose a canned comment and a link to teahouse might be better; The paper also makes the assumption that experienced editors are best at managing conflict, But the article points out that conflict is a major reason that prolific editors leave.

"Wikipedia  has  become  like  an  ecosystem,  in  which  certain  kinds  of  people are  quite  well-adapted.  However,  “that  limits  the  diversity of  the  contributors.  So  the  ecosystem  needs  to  change  in  order  to  be  more  welcoming  to  certain  kinds  of  people.” 

“Identifying  stable  edit could  feed  back  into  a  model  that  provides  points  in  some  way that  does  encourage  good  behavior.”  @krinkle

  • this paper extends it to show even experienced prolific editors finding negative communication about a revert as a major reason they leave. The authors intend to expand this metric to all Wikipedia
  • Lastly, we should consider changing the publish function to run parts of ORES, so that the Editor can make the decisions to fix. Yes, Vandals will work out work arounds, but we can stop that Editor or Anon having access to the tool if they abuse it. Currently they can do the same thing. but it takes 5 minutes for NPP to give them an answer [User:Wakelamp|Wakelamp d[@-@]b]] (talk) 12:51, 21 November 2021 (UTC)
  • Yes, many people are too focussed on number of edits, but the solution is not to look for another flawed metric to replace it. We should simply get on with doing the work, rather than evaluating people. Phil Bridger (talk) 12:55, 29 November 2021 (UTC)

People are too focused on metrics

Don't get me wrong, it's nice to have metrics (# of edits, # of articles created, # of redirects created, # of GAs, # of FAs, # of DYKs, # of successful AFD nominations, # of files uploaded, etc...), especially if you like numbers. But numbers are just that, numbers. The goal isn't to create the encyclopedia whose contributors' productivity can be measured, but to create the best possible encyclopedia out there, freely available to all of humanity. That I'm 79th in 12 million, or 79th in 44 million in number of edits is really besides the point. Or if we suddenly excluded semi-automated edits from the count, and I dropped to 148th in 12 million in the rankings, the value of my contributions wouldn't suddenly be half of what it used to be. My goal isn't to climb the ranks, my goal is to make Wikipedia better.

What's worth more? 3 FAs or 4 file uploaded to commons? What if it's an FA on a topic no one cares about? What if the image is a simple arrow?

Numbers describe quantities well, not so much subjective value. Headbomb {t · c · p · b} 19:53, 29 November 2021 (UTC)

For me, WP is not just content and structure, but is also an equal WP community of readers and editors. NPOV and 'best possible encyclopedia" need an active renewing community. Productivity is not that important (although wasting other editors time and energy is), but the current measures (Edit measures, number of articles deleted, reverts..) can lead to be behaviour that causes editors to leave. A few more measures won't fix this, but it would be fairer to editors that create content. Let them decide the relative worth ("What's worth more? 3 FAs or 4 files..").
  1. Thinking about it, if we just had visibility of monthly figures on the rollovers it could be good
  2. "The goal isn't ... contributors' productivity"" AND "But numbers are just that, numbers." I agree. IF we want " the best possible encyclopedia", then we need to concentrate on creation, respecting each other's time, and on editor's staying. IF an action causes a good faith editor to leave, then a one-minute decision has lost hundreds of hours of improvement. Creating thousands of citation missing on articles, disrespects another editor's time and ability; There are undoubtedly a few editors whose behavior is not extreme, but who cause a lot of people to leave by being the second last straw
  3. Lastly, "Numbers describe quantities well, not so much subjective value." Subjective value can also cause issue - I get frustrated reading RfCs /reputable sources, because there are no numbers, no references to readers/new editors, and just anecdote. Wakelamp d[@-@]b (talk) 11:17, 30 November 2021 (UTC)

Merging flag template system with the ISO 3166 system

I was looking for a template similar to {{Country name}} that would take a country code and output a wikilink, such as {{Country name|USA}} → United States, but I sure can't find one. I could simply put Country name in [[ ]] like I did just now, but that doesn't account for the two Georgias, among other disambiguates. I kept finding myself looking through the guts of the WP:WikiProject Flag Template system and the Module:ISO 3166 system and I wondered why they weren't operating off of the same internal data. I feel like Template:Country data United States and Module:ISO 3166/data/US should be using the same code base. –Fredddie™ 00:02, 29 November 2021 (UTC)

{{flagg|xx|{{Country name|GEO}}}} → Georgia is one solution. Agree there should be a {{Country link}} template, and unified database if possible. Sod25 (talk) 12:33, 30 November 2021 (UTC)
It's a good start but {{flagg|xx|{{Country name|USA|GA}}}}Georgia is the wrong Georgia. –Fredddie™ 01:24, 1 December 2021 (UTC)
Same with {{flagg|xx|{{Country name|USA-GA}}}}Georgia –Fredddie™ 01:50, 1 December 2021 (UTC)
@Fredddie: The way to do it correctly is {{flag|Georgia (U.S. state)|name=Georgia}} which produces   Georgia. ― Blaze The WolfTalkBlaze Wolf#6545 14:30, 2 December 2021 (UTC)
Also, |name=Georgia is optional, however without it the name displays as "Georgia (U.S. state)" instead of just "Georgia". I found the code for it at Georgia (U.S. state)#External Links. ― Blaze The WolfTalkBlaze Wolf#6545 14:33, 2 December 2021 (UTC)
However I do agree that, in situations like this, being able to use something like that would be helpful. ― Blaze The WolfTalkBlaze Wolf#6545 14:43, 2 December 2021 (UTC)
Yeah I'm trying to do it with location codes so inputting "Georgia (state)" is not really tenable. –Fredddie™ 02:52, 3 December 2021 (UTC)

Getting more freely licensed media by allowing fair use images of living persons

So hear me out: many living people have no image on their Wikipedia article, and the subjects in question generally just don't care. They only start caring once they do have a picture and they don't like it.

I've seen this on multiple occasions as I've uploaded many crops from group photos (where flaws that weren't too noticeable in the full picture become more apparent) and screenshots from freely licensed videos (some people literally never close their mouth while keeping their eyes open when they're in frame) and added them to articles. Nobody cared for years, but after I've added a less than perfect picture (because that's the best we got), the subject wakes up.

An example of this that I remember is Jaap Smit. His article was created in 2011 on nlwiki. On 27 June 2018 I added a photo, File:Jaap Smit CNV 2012.jpg. That's a crop and his glasses magnifying his left eye combined with the angle make the photo not the most flattering there could be. (but the only freely licensed media we had) On 20 August 2018 the photo was replaced by Rob van de Webredactie provincie Zuid-Holland (Rob from the web editorial staff South Holland) who was instructed by Smit himself (talk page: "Het is de wens van de heer Smit om zijn foto te (laten) wijzigen.", translation: "It is the wish of Mr. Smit to have his photo changed") This eventually resulted in a CC BY 4.0 license being added to https://www.zuid-holland.nl/overons/bestuur-zh/gedeputeerde-staten/cdk-jaap-smit/beelden-publicatie/ and we now use File:Jaap Smit 2 (cropped).jpg.

So if we allowed fair use media for living persons but somehow made sure the media isn't overly flattering (the 0.1 megapixel restriction for fair use in general clearly isn't enough for that), we just might get more free media. This is pretty much a brain fart, but it may be worth brainstorming on how to exploit people's vanity. — Alexis Jazz (talk or ping me) 10:35, 28 November 2021 (UTC)

@Buidhe, Nikkimaria, and Elcobbola: I doubt this is doable, but they know better than I do. SandyGeorgia (Talk) 15:08, 28 November 2021 (UTC)
Even without fair use we could perhaps do more. For example, we could have the infobox automatically insert a generic silhouette when there's no image that links to instructions on how to license a photo properly. Probably not as effective, but indicates more clearly that something is missing. — Alexis Jazz (talk or ping me) 15:21, 28 November 2021 (UTC)
We used to do that, but the practice was deprecated after a community discussion. See WP:UPPI and Wikipedia:Centralized discussion/Image placeholders for the background. Nikkimaria (talk) 15:27, 28 November 2021 (UTC)
We could re-introduce them so we don't have to rely on the French Wikipedia (or other Wikipedias that are more pro free content than we are) for asking for free images. The discussion linked by Nikkimaria isn't exactly clear, and there might well be consensus to bring back begging-for-image placeholders for some classes of people (politicians, actors, sports personalities) where this might result in a free image being donated. Of course not every biography needs a picture, just like not every article needs an infobox. Do we have any data on how effective the placeholders were in soliciting free images? —Kusma (talk) 10:53, 2 December 2021 (UTC)
I admit I am a little uneasy at manipulating people in this manner. It feels a little bit like extortion - give us a free image or this unflattering one will remain up instead. Jo-Jo Eumerus (talk) 15:33, 28 November 2021 (UTC)
I don't know that it will necessary work like that—we essentially have that in place at present, free images are often taken from poor angles, at seated events or behind microphones, that sort of thing, so donating an image to improve the aesthetics of an article is already a possibility. That said, I'm leery of this for the simple fact that it will undoubtedly lead to tens of thousands of non-free images being plucked from the internet and added to articles which don't need them, and I don't believe that's something to encourage, especially as the knock-on effect will be "well, we have an image, no need to try to obtain a free one now", and the search for/creation of freely-available images will be curtailed. ᵹʀᴀᴘᴘʟᴇ ꭗ 15:47, 28 November 2021 (UTC)
It certainly does work that way, especially when they find that news sources often use our images. I get a lot of complaints about unflattering images, and know of many cases where the athletes were sufficiently aggrieved to upload a better image. Most would prefer that we use a flattering PR image. Hawkeye7 (discuss) 19:26, 29 November 2021 (UTC)
But that's the point I was making--it already works that way, it wouldn't be a byproduct of a change to fair use, it just is how it is now. ᵹʀᴀᴘᴘʟᴇ ꭗ 19:41, 29 November 2021 (UTC)
I just read about Personality_rights. It looks like celebrities have more rights depending on the country Wakelamp d[@-@]b (talk) 07:06, 2 December 2021 (UTC)
I question the idea that adding pictures is always of encyclopedic value. Let's take a subject like Hans-Lukas Kieser, who currently has no photo. Kieser is a historian known for his writings, not what he looks like. Even leaving aside the copyright issues, what benefit to the reader is advanced by letting them know he looks like this? Sure, if there was a free image I would have no objection to adding it but I'm skeptical that it does much to raise the value of the Wikipedia article. (t · c) buidhe 21:34, 28 November 2021 (UTC)
Humans use facial recognition as a primary tool for recognizing other humans. So anyone hoping to recognize the person (perhaps to meet them a conference, or to identify them when seeing them in a documentary or on television if there is no graphic indicating their name, ...) would benefit a photo of their face. CapitalSasha ~ talk 22:39, 28 November 2021 (UTC)
That may well be the case but Wikipedia is not LinkedIn, we're here to educate and not to network—if there is an informative need for a nonfree image that's one thing (perhaps a snippet of music that is being discussed, or a piece of visual art that cannot be conveyed in words alone) but in the case of a living individual we might actually be better served using free files that illustrate their work or the context around their lives than by a simple non-free portrait. In Buidhe's example, for instance, Kieser is an historian of the late Ottoman Empire and his bibliography lists several works on genocide; perhaps a contextual illustration like File:Assyrian_population_1914.svg conveys more about the subject than claiming "fair use" on a picture of him alone could. I'm also a fan of illustrating articles with quotes where possible as well; has this writer said something succinct which conveys who they are or what their work means which could fill a quote box instead of an image? ᵹʀᴀᴘᴘʟᴇ ꭗ 22:54, 28 November 2021 (UTC)
I am inclined to wrap this thread in {{archive top}}/{{archive bottom}}, in order that no more time should be wasted. Please see my closing summary at Wikipedia:Village pump (proposals)/Archive 170#Allow fair use non-freely licensed photos of politicians. If we can't allow it for politicians, we can't allow it for anybody else who is still alive. --Redrose64 🌹 (talk) 23:12, 28 November 2021 (UTC)
Redrose64, this is VP idea lab, not VP proposals. Your proposal has the goal of just allowing more fair use because you've given up on a high quality free alternative. This thread is about the idea of exploiting people's vanity to get more freely licensed content. I grant you that actually doing this with fair use content would require a change to foundation:Resolution:Licensing policy, but if the community would feel that it's worth it such a change wouldn't be impossible. It's unlikely to happen in the form I described (never say never, but, unlikely), but perhaps there's another way to achieve something similar. — Alexis Jazz (talk or ping me) 14:20, 29 November 2021 (UTC)
As a BLPN regular I'd very strongly oppose this. I know the headers tells me to be creative and positive but sorry I can't be. This proposal needs to be killed with fire. I was thinking the title made no sense, how would relaxing NFCC result in more free media? Then I read carefully and realised the proposal is effectively to punish living persons by using images they might not like to force them to release a freely licenced image. Although there's no suggestion of intentionally choosing unflattering images, the fact remains this is what is being proposed. Sorry but this is completely unacceptable and should never ever be acceptable on Wikipedia. Yes because of our free image requirements sometimes the images we chose is something the subject doesn't like and sometimes a subject may release a free image because of it. But there's a difference here in that we aren't choosing such images because we know the subjects may not like them. In fact one of the things we struggle with is how bad is too bad i.e. when is a free image so bad that we shouldn't use if even if it's the only image we have especially when a subject complains. I'd also note that in so much as other sources using our images which causes additional concern among subjects, it's likely one reason they do is because they're free. So even this part of what currently happens will probably be different when the images aren't free. Nil Einne (talk) 13:17, 1 December 2021 (UTC)
Nil Einne, this isn't a proposal (yet), it would be better hashed out if it was. As you've also noticed, unflattering images sometimes result in free images. Reading the comments here and thinking some more about this, we could perhaps research this effect: we select 100 people (actually 200 so we'd have a control group) from any English-speaking country who are alive, have no photo on their non-stub article and (to alleviate buidhe's concerns) have made a public appearance in the past 2 months. We select a non-free photo for them using the same criteria we use to select a non-free photo for people who passed away. (so we wouldn't select unflattering photos to start with) We make all 100 photos less attractive in some to-be-determined but consistent way. Maybe add some overlay, scale them down (0.01 megapixel?), blur, pixelize, black-and-white, contrast, brightness, newsprint filter, noise or some combination. We put them up for a year (will need to obtain an exemption from the foundation) and afterwards we see if this group has more free media than the control group. It's a fairly best-case scenario as it would require subjects from English-speaking countries (as this is English Wikipedia) with non-stub articles who make public appearances, but the goal would be to determine how strong the effect is. If it would turn out to be barely measurable it clearly wouldn't be worth pursuing this any further. If the effect is stronger than expected, there's perhaps some possible balance where the benefits outweigh the cons. Again, idea lab, no actual proposal at this point. — Alexis Jazz (talk or ping me) 17:37, 1 December 2021 (UTC)
I disagree with the original premise: I don't feel it is desirable to try to exploit people's vanity. Using a lower resolution fair-use image is of course already a standard practice, but I don't agree with deliberately degrading photo quality in a way to make them less attractive. This runs counter to the goal of presenting the best quality information available on a subject in a neutral manner. isaacl (talk) 21:28, 1 December 2021 (UTC)
I can already see the headlines; "Wikipedia badgers celebrities for better photos." - Donald Albury 00:06, 2 December 2021 (UTC)
Oppose forcing pictures into articles. Wikipedia is not a yearbook and does not need a pic in every article. Readers who want to see what a person looks like can easily google them and be lead to scads of pics - some authentic and some photo-shopped. MarnetteD|Talk 00:28, 2 December 2021 (UTC)
@Redrose64 I think the conversation is worth continuing, if we ask is there another way for the BLP to give us the image, but without our requesting it or lowering the photo quality.
  1. does the Open Social login or Open id store a photo?
  2. Do we need a better photo required list, that we share?
  3. Is there a way for a BLP to upload an image to Commons as CC? Maybe holding a WP sign :-) The current process means that someone has to have a celebrities email Wikipedia:A_picture_of_you
  4. Do the Article authority control link to somewhere with an image? I know the open scholar id (or whatever is) does and that does have an image
  5. [[User:Isaacl|isaacl] Nil Einne Vanity is a good point, except {{[[9]]}} mages? And I agree with {{Alexis Jazz}} point that there is no point in not choosing a better photo.
and
Photos are encyclopaedic by precedent (Britannica),by readers like of them, and by need (they help comprehension for ESL speakers, children, and those with dementia. (As long as we provide other option
Anyway This may all become moot in a few years (with verified ids and pictures) Wakelamp d[@-@]b (talk) 03:44, 2 December 2021 (UTC)
I'm uncomfortable with fair use images in an otherwise freely reusable Encyclopaedia. I'm not convinced that putting up low quality images will bring forth more good quality images under open licences than we already get by requiring images of living people be freely licensed. I see a huge problem in such a change because of people who have previously released openly licensed images now wanting to move to a "fair use" model. But most of all I agree with those above that we should not be putting unflattering images in biographies. ϢereSpielChequers 07:22, 2 December 2021 (UTC)
If our intent is not purely educational in picking the images, then our fair use claim seems to weaken; fair use accounts for the purpose and character of the use. I'm somewhat skeptical that coercing people to agree to license copyrighted content under a free license by using a bad non-free image of them would survive a serious challenge—especially if we are digitally altering them towards the end of portraying their appearance in a negative light as in the case of the floated A-B testing idea. I'd imagine WMF legal would need to give a (conditional) sign-off before this goes to a proposal, if nothing else. I'm not necessarily opposed to using fair-use images of living individuals who it is going to be extremely difficult to get a free picture of (for example, people in solitary confinement or those in prison for the rest of their life) or for people for whom it is unclear as to whether or not they are alive (verifiable missing people). Maybe something more narrowly tailored could get a consensus, but I don't think that something so broad is going to receive sufficient support for adoption. — Mhawk10 (talk) 07:34, 2 December 2021 (UTC)
I think we all need to remember that most people are not nearly as obsessed with Wikipedia as we regular editors are, so most of the images suggested to be included would not be replaced with better freely-licenced ones. I cannot support any idea that makes the quality of BLPs depend on their subjects' willingness to spend any time (even just a few minutes) thinking about Wikipedia. Phil Bridger (talk) 09:29, 2 December 2021 (UTC)
This may be the single worst idea I've ever heard on Wikipedia, and there are some real contenders for that. You're proposing we worsen people's public images because it might 5D-chess get them to freely license an image? I'm not opposing from the "actually, what if we just got rid of fair use images at all" perspective, which I disagree with. I'm opposing from the basic human dignity perspective. Frankly, someone who comes up with this idea shouldn't be editing BLPs. Vaticidalprophet 17:42, 8 December 2021 (UTC)

Wikinews category localization

Wikinews looks to be in terminal decline, at least in English. But a big improvement would requiring articles be categorized by relevant location. Right now it's just organized by Country or category and alphabetically. This is fine for national or international stories, but it's not easy to find articles for a specific place or region. Adding required article categories for country, state/Provence/prefecture/etc, county, city or town creates a lot of value especially with declines in local reporting. — Preceding unsigned comment added by Chiffre01 (talk) 20:50, 7 December 2021 (UTC) (talk • contribs) 20:09, 7 December 2021 (UTC)

  • Have I misunderstood something, or might these comments have been better placed here? YTKJ (talk) 19:57, 8 December 2021 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_38&oldid=1110556175"