Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

Before commenting, note:

  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32

Being able to edit your edit summariesEdit

It seems that this was already proposed at the VP by Juliancolton back in 2008, but I would like to bring up this idea again, but in a new way. The previous proposal would allow anyone (or maybe just admins) to edit the last edit summary that would have been made. In this idea, what if only you could edit your own edit summary if it was the last edit that was made? I think there is also more of a need for something like this than in 2008 because when using tools like Twinkle and RedWarn its not uncommon to misclick and then put in an edit summary that does not adequately describe why the revert was made. Is there a need for this? Is this possible?

Previous discussion link:[1]

Best, P,TO 19104 (talk) (contribs) 15:33, 11 August 2020 (UTC).

@P,TO 19104: so this is a bit of a turtles all the way down situation. We really expect transparency and accountability for actions, and to maintain that we would need to keep a revision history for the edit summaries as well (so we could tell what they used to say) - and then when someone makes that edit, would we want to give them an option to describe why they are making it (a summary edit summary) - and then should that also be editable? This goes all the way back to phab:T12105 from 2007 - and is not something the English Wikipedia could just implement - it would require a software feature request to develop this in to the software first. — xaosflux Talk 15:45, 11 August 2020 (UTC)
@Xaosflux: Thank you for responding. Is there a way that we could record old edit summaries that were overwritten? Could we store the old edit summaries in some page or in a user's subpage? Could we store them somewhere off-wiki to insure they don't take up too much space? I think compared to 2007 and 2008, there is more of a need for something like this because when using anti-vandalism tools really fastly it is possible to input a misleading edit summary. P,TO 19104 (talk) (contribs) 15:51, 11 August 2020 (UTC)
I see. This would be something that would require a general Media-Wiki change. Noted. I guess I give up then on this request.   P,TO 19104 (talk) (contribs) 15:57, 11 August 2020 (UTC)
I often make typos and other errors in edit summaries, usually noticing a split second after saving the edit. When they are minor (i.e. they don't affect the meaning of what I am trying to say) I just let them go and, if anyone actually notices, don't care if they think I'm an idiot. Occasionally they are significant errors, in which case I make a dummy edit to the page, such as adding a blank line, and note the fact that my previous edit summary was in error. Phil Bridger (talk) 16:44, 11 August 2020 (UTC)
And, on the point of automated tools, you shouldn't be going so fast that you make mistakes regularly. If you are making lots of mistakes in edit summaries then you are probably making lots of more important mistakes, so slow down. You are not personally and solely responsible for defending Wikipedia against vandalism, spam, etc. Phil Bridger (talk) 17:00, 11 August 2020 (UTC)
On fiwiki there is a tag for "error in edit summary" that you can add to your own edits if you made a mistake in the summary. When adding a tag you can add a reason for tagging the edit which is shown on the tag management page. We could probably try a system like that here too.  Majavah talk · edits 19:34, 11 August 2020 (UTC)
We had originally specifically denied our editors the ability to change tags after the fact (c.f. phab:T97013) - but could enable this if we have support for it. — xaosflux Talk 21:39, 11 August 2020 (UTC)
The fiwiki tag is (or should be in my opinion) quite rarely used, and it's not really for the purpose of tagging your own mistakes (I generally try to hide my mistakes, not highlight them, but maybe that's just me). The purpose is for example to tag misleading edit summaries that can otherwise cause confusion. For example, when you start a voting page, there are certain steps that you should follow and you should also use informative edit summaries, so that the page history can be followed easily. If someone didn't follow the instructions and left a bad edit summary, usually another editor will use the tag to mark the shameful deed. It takes some effort to read the reason for the tag, so if there are a lot of tagged edit summaries, it will just cause editors to waste their time trying to find out why there are tags on them. -kyykaarme (talk) 08:30, 25 August 2020 (UTC)

I'd be against the general change, but the "error in edit summary tag" is at least a possibility. I still think it's not too big an actual issue to need resolving, but i wouldn't object if something like the above was wanted. Nosebagbear (talk) 12:11, 13 August 2020 (UTC)

  Agree with Nosebagbear. {{u|Sdkb}}talk 20:26, 15 August 2020 (UTC)
@Sdkb and Majavah: This may be pretty late, but could we go head with this proposal? I didn't see your replies. P,TO 19104 (talk) (contribs) 19:45, 24 August 2020 (UTC)
@P,TO 19104: this is the "idea lab" - so there are no time limits :D But also, we don't implement from here. Once your idea is fairly solid (You can articulate what it is you want to change, and why you want to change it) - you can list it at WP:VPR where the community can weigh in on it. If there is consensus, we can move forward - if not, status quo remains. So, based on what we've discussed so far: "Editing an edit summary" is pretty much a non-starter (even if the community wanted it). Allowing people to add (and therefor also remove or change) tags on edits is possible (by giving the a group access to (changetags)). Note, "software defined tags" (such as "mw-rollback") can't be removed (not even by admins) - but a new manual tag could be added (an edit may have multiple tags). — xaosflux Talk 19:56, 24 August 2020 (UTC)
@Xaosflux: Moving forward with the "manual tags" idea. Thanks! P,TO 19104 (talk) (contribs) 20:03, 24 August 2020 (UTC)
Another possibility to address the original request while maintaining the reasons for why we decided to not allow edit summaries to be edited would be to allow an editor to edit her/his edit summary only for a limited amount of time (perhaps 30 minutes, at most some hours) or until another edit to the article has been made by someone. Edited summaries should have a small tag indicating that they have been edited after the fact. This would allow editors to correct typos or improve wording if they are soon spotted and no other editor has "sealed" the history by applying his own changes to the article.
This is a scheme implemented in many forum softwares for contributions (rather than only edit summaries) and it works quite well.
Given that an (evil) editor could have (deliberately) provided a misleading edit summary right from the start, it cannot create more harm if s/he would change a good summary into a misleading one later on for as long as no other editor has been actually misled or noone has read the article in the new state. We can assume that a follow-up editor would have been misled if that editor based anything on the exiting state of the article (including the edit history) by editing the article herself/himself. Also, in the case that there will be no edits by other editors in a given timeframe, the very fact of an article to be live in a certain state can be seen as "sealing" its edit history, therefore, the time window for corrections should be closed automatically after some while. Keeping it open for a small amount of time, however, is acceptable because the original editor could have made her/her edit a couple of minutes or hours later as well.
--Matthiaspaul (talk) 09:15, 8 September 2020 (UTC)
I agree. right now, all edit summaries are permanent, as soon as you make them. there ought to be at least some time to revise them, if desired. --Sm8900 (talk) 14:27, 17 September 2020 (UTC)
Support appending by original editor with time-stamped changes - but not editing in any other way except by administrators. Also Support allowing administrators to hide edit summaries without revision-deleting the entire edit if the edit summary would qualify for hiding under existing revision-deletion rules had the edit itself been revision-deletable, e.g. a good edit with a BLP violation in the edit summary, or a web-link in the edit summary that links to a malware-infested web site. davidwr/(talk)/(contribs) 19:22, 17 September 2020 (UTC)
Comment - a work-around exists: I occasionally "append" to my recent edit summaries by doing a "practically null edit" where I add a space to the end of a line then put in the correct edit summary. The most common reason is that I fat-finger the "enter" key too soon, which saves the edit before I've finished typing the edit summary and I left something very important off. Sometimes I have to do it if I put something in the edit summary that is just wrong, like a mis-typed URL or wikilink. davidwr/(talk)/(contribs) 19:26, 17 September 2020 (UTC)

With regards to the WMF renaming controversy, why not rename Wikipedia?Edit

The WMF wants this name change. That much is clear. The rank and file volunteers of the Wikipedia project have little say in the matter. That much is clear. So instead of trying to do the hard or impossible (convincing WMF not to go through with something they're already decided on), why not solve this problem with a change we actually have the power to effect: let's rename Wikipedia instead. I don't have any immediately great suggestions for names; I'll leave that to smarter people than myself. Renaming wikipedia would:

  • prevent WMF from squatting on our legitimacy
  • draw attention to the issue (we'd get plenty of news coverage for "Wikipedia changes its name, here's why", much more than you'd ever see for "Wikimedia's holding charity changes their name to align its brand strategy")
  • draw attention to the Foundation itself (front-page news coverage talking about the foundation, even in a likely negatively light as above, would serve their goals of increased visibility)
  • probably not drastically impact our searchability. Google is very good at routing around name changes of this sort, so if (silly name for example) Kumquatpedia suddenly had the editor base and activity of Wikipedia, and wikipedia was permanently redirecting there with a 302, it wouldn't take long for us to be as popular as ever on google
  • Wikipedia kind of sucks as a name. It's not easily initialized (WP sort of works but is indistinct and inelegant; "double-yoo pee" or "dubya-pee", neither of which are appealing IMO) and both the wiki- prefix and the -pedia suffix are victims of Wikipedia's own success.
  • To the extent that it reduces traffic, that seems more likely to hurt the WMF than the wikipedia project. Wikipedia is a major source of fundraising for the WMF.

2600:1700:EFA0:2980:40C0:BAC7:107B:5DDF (talk) 19:55, 20 August 2020 (UTC)

This is not the place to discuss this. The English Wikipedia has no control over the name of the WMF. Consider taking this to a relevant discussion at Meta-Wiki. P,TO 19104 (talk) (contribs) 16:56, 21 August 2020 (UTC)

Strongly oppose renaming Wikipedia. Users of the world wide web are likely to be familiar with Wikipedia, especially since it has a high Google search, and renaming it would only result in confusion. Vorbee (talk) 21:39, 1 September 2020 (UTC)

I mean, isn't it up to the Foundation what to name the encyclopedia? For good or ill. At the top of each page where it says "Wikiedpia", can regular editors change that? Or the domain name, and so forth.
The whole internet uses the Wikipedia, so if we do change the name, we could have an internet-wide open vote. On second thought though, would probably come down to race between "Encyclopedia McEncyclopediaface" and "Hitler Did Nothing Wrong", so maybe not. Herostratus (talk) 19:11, 3 September 2020 (UTC)
Well, yes, this web site's name is controlled by its owner, the Foundation, so you are right. But apart from that one obvious and probably insurmountable problem, which I'm sure the original poster here was really aware of, this is a wonderful idea, which doesn't warrant a po-faced response of "strong oppose". OP, please keep thinking laterally. Phil Bridger (talk) 19:51, 3 September 2020 (UTC)

Po-faced response of strong oppose. Phil, I'm surprised at you, are you feeling ok? I'm undecided whether this is trolling or just one of the worst proposals of the year. We are not going to abandon one of the most widely-recognized brands in world history without far better reasons than those presented, even if we had the authority to do so. ―Mandruss  20:20, 3 September 2020 (UTC)

Definitely po-faced. And I'm feeling quite all right, thanks. Had a wonderful trip to Whipsnade Zoo today with my grandson. Phil Bridger (talk) 20:30, 3 September 2020 (UTC)
  • The proposer says Wikipedia kinds of sucks as a name. However, Wikipedia is a portmanteau of "Wiki" (the Hawaiian for "informal" or "quick") and "encyclopedia". Since "Wiki" means a website that any one can edit, calling this website "Wikipedia" makes it fairly self-explanatory what it is. As for the note about Wikipedia being difficult to initialise, I do not see what is wrong with calling it "WP".

It is true that "W" is the only letter in the Latin alphabet that has more than one syllable in its name, so it would take longer to say "WP" than other possible initials, but since people are more likely to type WP or write WP than say it, I do not see a problem. Vorbee (talk) 05:56, 4 September 2020 (UTC)

I oppose renaming "Wikipedia." the current name incorporates the ideas of "wiki" and "encyclopedia." we are the world's greatest wiki, and also the world's biggest and most comprehensive encyclopedia, ever. so I don't see any reason that we should not just stick with the name that we currently have. thanks!! --Sm8900 (talk)

Developing a naming convention for fictional elementsEdit

I had the idea of developing a unified naming convention for articles about fictional elements. The proposal, currently in the brainstorming phase, is at Wikipedia:Naming conventions (fictional elements). Please comment at the draft proposal's talk page. –LaundryPizza03 (d) 03:55, 22 August 2020 (UTC)

And here I thought this was going to be a naming convention for Unobtainium and Bolonium. --Ahecht (TALK
) 14:10, 4 September 2020 (UTC)
I did as well, I was: disappointed, deprived of an opportunity to rant about excessive naming rules; and deprived of multiple joke possibilities Nosebagbear (talk) 11:03, 8 September 2020 (UTC)

Sorting support/oppose votes in village pumpEdit

As a sort of meta-suggestion within the village pump, I think that support and oppose votes here should be sorted like they are at WP:RfA. The need for it is evidenced in long discussions like the current one on parenthetical citations. Instead of "arbitrary breaks," there should be subsections for support/oppose with numbering to be able to tell easily how many users are on each side. Tonystewart14 (talk) 00:46, 1 September 2020 (UTC)

Tonystewart14, it depends on the discussion. Some are big enough that that should definitely happen. But for smaller ones, it's better to have things a little looser, since if they're too formalized it creates unneeded headings and makes it harder to express ambivalence/other more nuanced views. We don't always know which discussions are going to become huge, but for those that likely are, I certainly support that sort of structure over arbitrary breaks. {{u|Sdkb}}talk 03:37, 1 September 2020 (UTC)
On that, we could have a Support section, an Oppose section and a third section where everything that isn't either of the two can be. El Millo (talk) 03:41, 1 September 2020 (UTC)
RFCs are still supposed to be discussions, and even RFAs are still supposed to be. These headers usually cause users to be more likely to vote rather than discuss. --Izno (talk) 05:26, 1 September 2020 (UTC)
  • One concern I have with this is that even for medium size, it's quite helpful to have comments within, along with threaded replies, rather than out in a Discussion section (or, worse yet, doubling each to put them in each). I also back Izno's concerns. Nosebagbear (talk) 18:43, 1 September 2020 (UTC)
  • Yeah, because the "votes" are bolded (and usually pretty short, altho sometimes not) its not that hard to count up even fairly long lists of commenters. Usually there's only like ten or so anyway max. The proposal would tend to divide people into "camps" even more than currently, a little bit, at least as mindset. Also, counting numbers of "votes" is not the main way to determine the outcome -- at least, its not supposed to be, and usually isn't, unless there's a true supermajority. In RfA there are really a lot of voters so its different. Also numbers matter there more. Herostratus (talk) 19:02, 3 September 2020 (UTC)
    I agree. We normally split the "votes" only when counting the votes matters and there are more responses than are likely to be convenient to count by hand, which happens in very few discussions. WhatamIdoing (talk) 21:10, 9 September 2020 (UTC)

Switch to flat icons?Edit

It has been my belief that Wikipedia looks a bit... dated. We still use skeuomorphic design in many areas of the encyclopedia from certain templates to default skins, and we still use a skin with a design that became dated in 2015.

Last time I proposed switching to flat design, I was told that my proposal was not ripe enough to be suited for an RfC. What I would like to do here is consider developing my proposal into something that may work in practice and that reflects the general consensus here.

It is good to note as well that we have switched from gradient padlocks to flat padlocks because of accessibility and contrast as well as aesthetics.

I already have an idea on what some icons could be replaced with, which can be viewed here. Because this is a major change, I think it would be good to get consensus first, which is why I am asking for input on how to develop this. I just want to develop this proposal further to see if we can make Wikipedia look more modern. Aasim 22:32, 4 September 2020 (UTC)

@Awesome Aasim: I'm still not seeing the full range of icons addressed in the draft proposal, and in order to be effective, the switch will need to be comprehensive (otherwise it'll just introduce another competing standard). I used the nutshell icon last time as an example — what do you propose to do for that at {{Nutshell}}, and for the many other icons still not included? {{u|Sdkb}}talk 19:52, 7 September 2020 (UTC)
And, as also stated in previous proposals, can you give any reason other than trendiness for this? I, for one, choose to edit Wikipedia in preference to other activities precisely because it does not bend to the latest fashion, but takes a long-term view of things. Phil Bridger (talk) 20:01, 7 September 2020 (UTC)
I feel 'flat' icons are, well, flat! The current icons are metaphorical—they link to, well, iconic, concepts. A red octagon is (in the US anyway) instantly recognized to mean "Stop"—the hand palm makes the sign universal. Any extra cues in an icon as to meaning is a plus. These cues are primary in designing a large set of icons. "Modern" is way down on the list. Icons in Wikipedia are part of a work environment. I value icons that require no more cogitation than necessary. Recognition at a glance is a good thing. Bland uniformity is not. Perhaps your proposal might gain more acceptance if the images were more distinct. — Neonorange (Phil) 22:12, 9 September 2020 (UTC)
It's actually not that bad of an idea... for example, the icons on the French Wikipedia are already flat! And, I really think that Wikipedia needs new icons, because some of them look really dated in this internet time. But, I wanna point out that in your icons, some of them (especially the warning icons) look like they were ripped straight from Windows 10. It's probably a good idea to change those. Arsonxists (talk) 17:55, 10 September 2020 (UTC)
Any change is going to cause confusion, except for the trash can (which conveys more skeuomorphic meaning than the status quo) to symbolize deletion. Most of others are either a lowercase "i" or an exclamation point "!" (which look almost the same in a sans-serif font) to very subtly indicate severity, in front of a circle, the color of which indicates who knows what. There's no point in having a dozen icons that all look alike. ―cobaltcigs 22:18, 16 September 2020 (UTC)

Killing catsEdit

The article Barack Obama is in 70 categories.


I'm talking about content categories here, not maintenance. I'd think a good rule of thumb here is that most articles should be in no more than about 2 or 3 categories, maybe 5 or 6 for really busy articles. From a brief look, biographies tend to be some of the worst offenders, but there are certainly others.

The category system might work well on a small, tightly-focused wiki, but it just doesn't scale to a general encyclopedia with millions of articles. Do we really need Category:1931 establishments in New York (state)? Does this actually serve the reader? (Hint: no).

I don't have any brilliant answers or ideas here, but I think at least some degree of recognition that there's a problem would be a first step. –Deacon Vorbis (carbon • videos) 14:44, 6 September 2020 (UTC)

Two thoughts. First is that 2-3 is insufficient for many subjects unless we get incredibly laser focused with subcategories. Is there a use to having people grouped by hometown? By job? By alma mater? By awards won? Because we're already up to probably, what, 15-20 just with those? I mean sure we could have a category for "Democratic Party United States senators from Illinois who are also non-fiction writers and Harvard Law School alumni" to get the number down... The relevant question (for me) for that particular example is why the vast majority of those categories aren't moved to the category "Barack Obama". There's probably some guideline I'm not aware of.
Second thought: how many readers have you talked to who actually use categories? I regularly bring up categories when teaching new users IRL and ask if anyone has ever used them. Maybe a couple out of hundreds that I've asked, and usually just because they were organizing an edit-a-thon or needed some information about Wikipedia articles for their job. And once they know about categories most people still don't use them, because for those purposes something like a Wikidata query is more comprehensive or a WikiProject table or a curated list is more accurate. The people who care about categories are Wikipedians, and some Wikipedians care an awful lot (see WP:4000). Personally, I'd be happy if we started long-term planning for replacement by Wikidata. There's plenty that Wikidata isn't good for, but straightforward tagging is one it's much more equipped to handle than MediaWiki. — Rhododendrites talk \\ 15:09, 6 September 2020 (UTC)
I would agree with this (in particular that categories is the 2000s tool which is way outdated), except for any Wikidata-related RfC is bound to attract several dozen users voting it down with the motivation that Wikidata is evil does not matter what is being discussed. In practical terms, I just do not know how to organize this.--Ymblanter (talk) 19:17, 6 September 2020 (UTC)
NO! Don't kill the cats! All joking aside, I think that very specific categories the no one is likely going to search for should be be eliminated, but I oppose killing of categories all together, considering that some categories like Category:Candidates for speedy deletion are vital to the maintenance of Wikipedia. Goose(Talk!) 20:42, 6 September 2020 (UTC)
I can see some categories rearranged in the tree as in Category:Democratic_Party_Presidents_of_the_United_States in the category of Category:Democratic_Party_(United_States)_presidential_nominees. That would bring done the categories for Barack Obama down to 69(not intended for inside jokes).Manabimasu (talk) 01:33, 7 September 2020 (UTC)
What problem is this intending to solve? The category system might work well on a small, tightly-focused wiki, but it just doesn't scale to a general encyclopedia with millions of articles.[citation needed] The category system does scale to millions of articles. Lists, navboxes etc generally don't scale, but categories do. Cats like Category:1931 establishments in New York (state) may not be useful for the general lay reader -- they aren't intended for lay readers. It is natural for libraries and other information sources to try and organise content in as many ways as reasonable, as this aids research. It's difficult for print encyclopedias but easy for an online encyclopedia. So I just don't see any "problem" here. – SD0001 (talk) 08:32, 9 September 2020 (UTC)
@SD0001: If categories aren't intended for the reader, then they should be hidden. We even have WP:CATDEFINING, but it doesn't seem to be followed in practice. People wouldn't be in 70 categories if it were.
Really, the problem that you're asking about is that categories tend to get split into subcats in arbitrary ways when they get too large. Even worse than the 1931 example is "Office buildings on the National Register of Historic Places in Manhattan" (pulling these from Empire State Building). There should be 3 categories –
  • office buildings,
  • things in Manhattan, and
  • things on the NRHP.
And if you care about the three-way intersection, then we should have a working way to get that. But we don't (and no, PetScan doesn't doesn't really even work). What if I had just wanted office buildings on the NRHP? or things in Manhattan on the NRHP? or office buildings in Manhattan? (Oh, but don't worry, it's also in "Skyscraper office buildings in Manhattan"). Then the category scheme is useless. Of course, doing things with properties like WikiData does is probably the way forward, but it would be a pretty major undertaking, and I'm not sure the collective will exists for that. So in the mean time, we have a broke, useless system. What do we do with it? –Deacon Vorbis (carbon • videos) 13:42, 9 September 2020 (UTC)
@Deacon Vorbis: What if I had just wanted office buildings on the NRHP? that's the subtree of Category:Office buildings on the National Register of Historic Places
or things in Manhattan on the NRHP? Category:Buildings and structures on the National Register of Historic Places in Manhattan,
or office buildings in Manhattan? Category:Office buildings in Manhattan.
The category you started with is a descendant of each of these categories.
doing things with properties like WikiData -- that's an alternative way of doing things which is already being done. wikidata:Q9188 has instance of = office building, location = "Midtown Manhatten", heritage designation = "place listed on the National Register of Historic Places". You can write a SPARQL query to get an intersection of one or more properties. If you're only interested in stuff that have WP articles, of course you can filter for that too.
TL;DR: Both the systems work. Please do some groundwork before making pompous claims like "we have a broke, useless system" demeaning the spectacular work done by volunteers over more than 15 years in organising all this together. – SD0001 (talk) 15:49, 9 September 2020 (UTC)
  • I find the whole category system extremely frustrating. As a computer scientist, I want to know what kind of relationship the cat graph represents. is-a? has-a? is-sorta-like? Beats me. I also want to be able to navigate the cat graph using standard tools, and to do that, I need to know what kind of graph it is. Intuitively, it's a tree, but it's actually not. It's not even a DAG. The profusion of intersecting cross-cutting cats ("Female alumni of Potrzebie University who edit wikipedia", "Women from Lower Slobbovia", "17th Century wikipedians") doesn't help. -- RoySmith (talk) 14:26, 9 September 2020 (UTC)
    It should be a DAG. If there are any cycles, I think it's reasonable to consider that an actual error. –Deacon Vorbis (carbon • videos) 14:36, 9 September 2020 (UTC)
    Deacon Vorbis, You would think so, but that doesn't seem to be the case. For example, in WP:CAT, there's a footnote that says, Mathematically speaking, this means that the system approximates a directed acyclic graph. From the point of view of somebody trying to navigate the graph programmatically, "approximates" is a synonym for "is not". Elsewhere, it says, Category chains formed by parent–child relationships should never form closed loops. Well, duh. It would be fine if there was some way to determine which edges represented parent-child (i.e. is-a) relationships, but there's doesn't appear to be.
    I once wanted to find all the music-related articles in wikipedia. I did the obvious thing; I started with Category:Music and tried to enumerate all the articles which were transitively a member of that category. Many days later, I gave it up as a lost cause. -- RoySmith (talk) 14:51, 9 September 2020 (UTC)
    @RoySmith: isn't this is an example of GIGO? Every article in the subtree of Category:Music is "music-related", however remote the connection may be. Maybe you had something else in mind than "music-related"? For exapmple, to get a list of all songs, the subtree of Category:Musical compositions can be used instead, which doesn't seem to contain anything apart from compositions.
    That being said, I've been in the trap myself and learnt the hard way that the tree isn't acyclic -- though I don't seem to recall where or why the cyclicity was occurring. – SD0001 (talk) 16:12, 9 September 2020 (UTC)
    SD0001, I don't have the details handy any more, but what was going on was the traversal never converged. Once I realized that there were cycles, I added code to discover when I was re-visiting a node and ignore it. But that wasn't good enough. There were enough bogus edges that you would head off into the weeds when you traversed them and start discovering cats that had nothing to do with music. Sure, some of those were just bad data, but when you start with the constraints on the cat graph being as weak as "directed", it's really hard to explore it in any useful way, and it's really hard to do any useful error checkng. Imagine if I made Category:Barak Obama a subcat of Category:Barbershop music because he sang in a Barbershop quartet. Now a traversal starting from Music would suddenly be discoving all sorts of weird stuff. That's the sort of thing that was going on. -- RoySmith (talk) 17:07, 9 September 2020 (UTC)
    Would be interesting to let tsort crank on it for a while and find cycles as a project to fix. I can't figure out how to count the pages in the Category: namespace to get a handle on the order of magnitude of that task. DMacks (talk) 18:21, 9 September 2020 (UTC)
    2003278 existing category pages, plus however many redlinks with at least one page categorized in them - I can only find 273, which seems low, so maybe my logic was off. 6863520 categorizations of Category pages, i.e. edges. —Cryptic 18:46, 9 September 2020 (UTC)
    DMacks, Spoiler: 2,047,712. -- RoySmith (talk) 18:54, 9 September 2020 (UTC)
    There are about 98K transclusions of {{Category redirect}}, which bots claim to fix. So that's 5% less CPU-catching-fire already. DMacks (talk) 19:04, 9 September 2020 (UTC)
    1,906,889 excluding all hard and soft redirects. But this doesn't include any red-linked cats with pages in them. – SD0001 (talk) 11:23, 11 September 2020 (UTC)
    Another more-manageable task is to clean out Special:UncategorizedCategories. It represents unreachable islands. DMacks (talk) 19:08, 9 September 2020 (UTC)
    One real problem with intersecting categories is inconsistent diffusion rules. For example, although a horror film released in 1977 belongs to Category:1977 horror films, it remains a direct member of Category:1977 films (see Template:All included) but not a direct member of Category:Horror films (see Template:Category diffuse). If one rule or the other were consistently applied to all categories, some demand for an oppositely generated view of each category (direct members plus or minus subcategory members, for whatever maintenance purpose) will always still exist. ―cobaltcigs 21:43, 13 September 2020 (UTC)
  • This guy's article is far from "busy" by any reasonable standard. He's perhaps best known for playing for 12 different professional basketball teams in 14 years, and is properly categorized as such. The above-proposed upper limit of "5 or 6" categories is totally unpracticable. Articles with that few categories tend to be permanent stubs (not that there's anything wrong with that). ―cobaltcigs 19:54, 13 September 2020 (UTC)
  • @DMacks and RoySmith: Getting a list of category cycles isn't the difficult part. I got a list of all parentcat—subcat connections from the database with just the page IDs (titles would of course make the output file unmanageably large) This doesn't seem to work on Quarry for some reason but worked fast enough (<15 mins) on the toolforge grid. Then I wrote an efficient C++ program to call out the cycles using depth-first search (runtime < 5 mins). It tells me there are 4106 cycles in all. Here are the first 5000 lines of output (cycles are shown with the page IDs only though). Now the tough part is what to do with this information? There are some cycles that contain just one page, eg. Category:Hidden categories contains itself! Some have just 2 pages: Category:Bill Gates contains Category:Gates family and Category:Gates family contains Category:Bill Gates, which seems to make sense! Then of course there are some massive cyclic chains that I don't know how to look into since the output contains just the IDs :( I guess I'll need to write some more code to make the output contain the category names so it's human-readable. – SD0001 (talk) 14:04, 15 September 2020 (UTC)
    SD0001, Cool, I'll take a closer look at that when I get a chance. Your Gates 2-cycle is endemic of one of the core problems: there's no rigid definition of what the edge relationships are. Neither of those are is-a relations, which would be fine, if the edges were labeled with what they represent. -- RoySmith (talk) 14:11, 15 September 2020 (UTC)
    It's easy: Bill Gates is a member of the Gates family, but the Gates family is not a member of Bill Gates. No need for a loop here. --Redrose64 🌹 (talk) 18:20, 15 September 2020 (UTC)
    Ah, I see converting the IDs to titles is easier done by the API rather through the database (500 IDs can be resolved in a single API call). The prettified output is hereSD0001 (talk) 20:22, 16 September 2020 (UTC)
I find categories to be highly valuable. highly. it is one of things that makes Wikipedia so valuable as a resource for research. for example, check out Category:Political charters, Category:Diplomatic conferences, Category:Clinton administration personnel,Category: Domestic implements, category: Firefighting in the United States. all of these bring together various articles and entries in a unique manner, to provide various correlations that many users might find helpful and informative. --Sm8900 (talk) 14:46, 17 September 2020 (UTC)
Sm8900, I'm not doubting you, but you could give some concrete examples of how you've used categories? I'm just trying to understand how they get used in real life, by real users. -- RoySmith (talk) 17:33, 17 September 2020 (UTC)

Different highlights in Diffs for wiki markup vs. contentEdit

I haven’t been able to find if this has already been proposed. In Diffs, it’d be great if the wiki markup, particularly the entire citations, were highlighted in a different color, than the regular content text (e.g., all newly added items are highlighted blue in diffs, but citations could be highlighted darker/lighter shade of blue than new content). This would make it easier to read the new content, vs the citations (which can be very long) and other intermingled markup.

Now where everything is the same color, users have to spend more time deciphering the diffs (e.g. content text, even single sentences, broken up by long citation markups). Or they spend additional time and effort by going to the main Article page, then search for the new content, to see it there, where it’s easier to read. In either case, considerably more time and effort is spent, and when we multiply this by all the Admins and Editors who check the diffs, it’s probably a lot of time lost. Any thoughts? Thhhommmasss (talk) 21:55, 6 September 2020 (UTC)

Try WP:WikEdDiff. --Izno (talk) 11:55, 7 September 2020 (UTC)
Thanks, looks interesting, I'll check it out Thhhommmasss (talk) 04:04, 9 September 2020 (UTC)

What should we do about experienced editors who habitually don't use edit summaries?Edit

I occasionally come across experienced editors who make generally positive contributions, but just do not use edit summaries. They generally have plenty of warnings on their talk page (I recently revamped {{Summary2}} to make it useful for using for experienced editors, since {{Summary}} is not), but since our rules don't formally require summaries, they are able to just ignore the warnings and carry on, wasting other editors' time. Is it time to change the rules somehow? If not, are there other approaches we could take to address this problem? {{u|Sdkb}}talk 19:45, 7 September 2020 (UTC)

I feel your pain. I think ANI is about the only way to go, where nothing will likely happen, especially if it's an experienced, productive editor. While we're at it, I'd also lump in the habit of just blindly copy/pasting the entire text of an edit into the summary box along with that. That's not only almost as useless, but also tends to make page histories a lot less navigable. But people will often just oppose anything that adds or strengthens anything resembling a rule, even if it would be useful, citing WP:CREEP, so I'm not expecting much, myself. –Deacon Vorbis (carbon • videos) 19:57, 7 September 2020 (UTC)
The prevailing community approach to such things (with which I disagree) appears to be:
  • Write guidelines describing best practices.
  • Ensure that editors are aware of the guidelines.
  • Carry on.
Generally speaking and with exceptions, individual freedom trumps the greater good at en-wiki. Custom signatures are another example, where the community consistently refuses to impose even minimal bright-line restrictions. ―Mandruss  20:04, 7 September 2020 (UTC)
The community might not but the foundation has. See Wikipedia:Village pump (WMF)#New requirements for user signatures. CambridgeBayWeather, Uqaqtuq (talk), Huliva 23:41, 7 September 2020 (UTC)
I see nothing there addressing the problem of distracting signatures that get in the way of discussion, a problem that could be greatly reduced by one or two bright-line restrictions. And even what's there applies only to new signatures, meaning the improvements will be realized only by gradual attrition that will take decades. I probably won't live that long, and I'm not that patient anyway. ―Mandruss  00:03, 8 September 2020 (UTC)
Whatamidoing is contacting everyone whose signature does not comply to resolve them. The current forecast is "probably months"—see Wikipedia:Village pump (proposals)/Archive 170 § Add basic HTML syntax-checking on user signature field changes for a few more details. There are about 900 more editors affected, and about 700 of them are easily fixed. isaacl (talk) 00:18, 8 September 2020 (UTC)
I can't remember when we last had a change to the rules about signatures, other than the WMF reform to them which has proved remarkably uncontentious for a WMF change. Though we did have this 2009 Request for signatureship. Perhaps now would be a good time to propose a change at Wikipedia_talk:Signatures. Can you be specific though as to what is allowed now but which you feel should no longer be allowed? ϢereSpielChequers 16:48, 18 September 2020 (UTC)
@Mandruss: I've enforced our custom-signature bright-line restrictions with block warnings before, specifically the prohibitions on signatures that disrupt the flow of text, that call templates, or that include images. — xaosflux Talk 00:14, 8 September 2020 (UTC)
  • 15 years ago, when I ran for admin, whether you used edit summaries or not was something that people worried about. I guess people are still worrying about it. What's next? Worrying about signatures? Oh, wait, yeah, I guess it is. The big issues of the day: edit summaries, signatures, and oxford commas. — Preceding unsigned comment added by RoySmith (talkcontribs) 00:32, 8 September 2020 (UTC)
  • How about asking nicely with a human message rather than a templated warning? Phil Bridger (talk) 15:55, 9 September 2020 (UTC)
    And when that's still ignored, then what? –Deacon Vorbis (carbon • videos) 17:48, 9 September 2020 (UTC)
    Then it depends on circumstances. If the editor is a net positive to the task of building this encyclopedia then we just put up with them not obeying some officious "rule". We are not here to provide nice neat edit summaries or to make our signatures look good, but to build an encyclopedia. Phil Bridger (talk) 17:57, 9 September 2020 (UTC)
    Edit summaries are useful tools when building an encyclopedia, and having them can hours and hours of work from the many editors that might have to review each edit to tell what it is. --Ahecht (TALK
    ) 19:33, 9 September 2020 (UTC)
    Yes, they can be, but in other circumstances they can be useless, as RoySmith explains below. That is why I used the phrases "it depends on circumstances" and "net positive". Phil Bridger (talk) 19:47, 9 September 2020 (UTC)
  • I really don't see a blank edit summary as a reasonable freedom. The user preference Preferences ↠ Editing ↠ Prompt me when entering a blank edit summary should be set as the default. Better still, remove the A blank edit summary is OK the second time around option. And do not mention Oxford commas. — GhostInTheMachine talk to me 19:02, 9 September 2020 (UTC)
    GhostInTheMachine, The problem with requiring the user to enter something is that it just encourages garbage. Often, there's nothing to say besides "fix", "more", "reply", or something equally useless. When there's something useful to say, I say it. It's like the web forms that require me to enter a phone number.
    If you insist on refusing to allow me to place my order without giving you a phone number, OK, fine, my phone number is 999-999-9999. -- RoySmith (talk) 19:24, 9 September 2020 (UTC)
    How did you know what phone number I entered today on a web form? Phil Bridger (talk) 19:27, 9 September 2020 (UTC)
    I know. I still think that the first You have entered a blank edit summary, please think about that warning should be the default. — GhostInTheMachine talk to me 19:45, 9 September 2020 (UTC)
    Maybe for logged in editors who have completed their first 100 edits. Otherwise the main thing you achieve is discouraging vandals from self identifying by leaving a blank edit summary. ϢereSpielChequers 16:25, 18 September 2020 (UTC)
  • If a Wikipedian does not type in an edit summary, the contribution will be marked in the article's history by the sub-heading of the article. This could be seen as an edit summary (for example, I am not going to type in an edit here but I will still have this edit marked up as "What should we do about experienced editors who habitually don't use edit summaries?") so I do not see a problem. Vorbee (talk) 06:20, 18 September 2020 (UTC)

Would a greater problem be whether or not a Wikipedian marks an edit a minor edit or not? There might be debate about what counts as a minor edit, but sometimes edits are obviously minor (e.g. inserting a missing letter into a typo) and if such an edit is not noted as minor, this will not show up in the article's history. Vorbee (talk) 06:27, 18 September 2020 (UTC)

  • When I'm training, or talking to someone who doesn't see the point of edit summaries, I usually explain that an edit summary is code for "I'm probably not a vandal". Of course there are some vandals and spammers who have cottoned on and use edit summaries, and some regulars who don't. But as long as keeping edit summaries as optional helps some spammers and vandals self identify as such, then I think that it is useful to keep it optional. However there are some people who don't opt in to an edit summary point until they run an RFA. or ask an experienced RFA nominator like myself for a nomination. So keeping edit summaries optional is an imperfect but useful tool for spotting bad edits. ϢereSpielChequers 16:18, 18 September 2020 (UTC)
    Since this discussion is veering in the direction of discussing mandatory edit summaries, I'll note that it's listed at Wikipedia:Perennial proposals#Automatically prompt for missing edit summary. It's certainly a valid discussion to have, but I'm more interested here in sticking to the more narrow question I initially posed about experienced non-vandal editors. {{u|Sdkb}}talk 04:40, 20 September 2020 (UTC)
Vorbee, edits incorrectly marked as minor are certainly a problem. I rewrote {{uw-minor}} a few months ago, and I use it whenever I come across an edit improperly marked as minor. It's usually from a beginner; I think it's (thankfully) not that common to intentionally mark a controversial edit as minor to try to avoid scrutiny. If you want, a parameter or separate template could be made to allow for a more strongly-worded alternative to uw-minor, which would be appropriate for instances in which someone is trying to evade scrutiny. {{u|Sdkb}}talk 04:44, 20 September 2020 (UTC)
  • I presume this idea is for mainspaces, not talk pages or user pages? ProcrastinatingReader (talk) 05:20, 20 September 2020 (UTC)

Script or bot to enforce rollbacks "in the spirit of WP:G5" for block-evading socksEdit

Inspired by this discussion (permalink) and the repeated block-evasion by this IP. See Wikipedia:Banning policy#Evasion and enforcement for policy supporting undoing edits of block-evading editors.

It would be very helpful if a bot or script attempted to revert all edits by newly-blocked socks made after a given date and time, then delivered a report of which pages were and were NOT completely reverted so they could be scrutinized manually.

Even if this were an "admin-use-only" tool, the reports it generated would still be useful to non-admins editors doing cleanup work.

Any thoughts pro or con before I ask for it on Wikipedia:Village pump (technical)? Anyone want to volunteer to code it up?

On thing to be careful of: Such a script would undo edits banned editors are allowed to do, such as when the revert would re-introduce a WP:BLP issue. This is why the person running the script should do some spot-checking first to have high confidence that nearly all or all of the edits would be reverted if done by hand. For the same reason, certain name-spaces such as discussion pages should probably be skipped over and logged as "not done" by the script. davidwr/(talk)/(contribs) 18:41, 10 September 2020 (UTC)

Davidwr, I've been working on some SPI tools ( One of the functions is something like that. Select a SPI case, click the "G5" button, and it runs some heuristics to guess what might be G5 eligible related to that case. It's pretty rough right now. I work on it in fits and starts when the mood strikes me. -- RoySmith (talk) 18:51, 10 September 2020 (UTC)
Of course, the argument against such a script would be that some of the block-evading person's changes might be good for the encyclopedia. But I would be in favor of a ban-revert script despite the argument. One of the problems would be finding and reverting the ban-evading-edits that have been followed by unrelated changes to the same article. Basically it would involve looking at all the ban-evading edits, not just the ones which are the most recent changes to an article. Binksternet (talk) 18:56, 10 September 2020 (UTC)
True. Ideally, you would look at all edits after a specified date-and-time to see if they were created by the blocked editor under one or more specified accounts or IP addresses, then revert those you could and log successes and failures. davidwr/(talk)/(contribs) 19:17, 10 September 2020 (UTC)
There is already a mass rollback script (User:Writ Keeper/Scripts/massRollback.js) which identifies all latest-revision contribs by a user and offers to revert them. Its use has been controversial in the past, but at least one attempt to create a script more powerful than that was soundly rejected by the community as an abuse of admin tools (as I recall, that script could also automatically revdel contributions). I don't remember now which script that was but I see I also have User:Writ Keeper/Scripts/massRevdel.js in my .js, but I'm not sure what it does. Ivanvector (Talk/Edits) 16:23, 18 September 2020 (UTC)

Proposal: Move references to bottom of article (like e.g. in German WP) have external links etc above the reflistEdit


I mostly write in German WP, where the reflist ist pretty much the last thing in the article. I find that more convenient for the readers. Esp if the reflist is long, the external links, which quite often are great … tend to get overlooked, because they follow a million lines of small print not meant for consumption. I would suggest changing the order to having the reflist follow the external links… :-)) --Satu Katja (talk) 09:59, 13 September 2020 (UTC)

The current order is preferred because references are more part of the article than external links are. --Izno (talk) 12:22, 13 September 2020 (UTC)
Izno, To be honest, I think there's merit to the suggestion, but from a practical point of view, it would require a huge (and error-prone) robo-editing job to go back and re-shuffle 6 million existing articles, which seems like a non-starter. -- RoySmith (talk) 13:24, 13 September 2020 (UTC)
Something something separation of content and presentation something something  Deacon Vorbis (carbon • videos) 14:36, 13 September 2020 (UTC)
True, re-shuffling 6 Mio articles is quite something, and that would have to be considered… But esp. in long articles (… and articles that cover major topics usually tend to be long) the reflist can be hunderds of refs. "WW II" has 414 refs, I never saw that there are "external links" underneath until I specifically scrolled down to counts the refs. My guess is that the majority of the readers will have the same experience… and that is quite a pity, they were put there for a purpose and it'd be great if they were seen… --Satu Katja (talk) 15:18, 13 September 2020 (UTC)
My experience of external links has been rather different. I have very rarely found any to be useful, and they are often lists of spam links or links to various social media sites owned by the article subject. And remember that references are also there to be seen. They are the most important part of any article because they are the only means by which content in the encyclopedia that anyone can edit can be seen to be reliable. Phil Bridger (talk) 15:47, 13 September 2020 (UTC)
So I think ideas like this stem from the wrong-headed view of "References" as some kind of edit war monument which no reader actually wants to see. References are part of the article, unlike the other articles listed in "See also", which in turn are more part of the website than any external links could be. That seems like a natural descending order of relevance, and was considered normal before the bury-the-refs movement. Disclaimer: However, if I were trying to promote my own external website(s) I would absolutely want my links to be floating somewhere above the first paragraph, and want the references section to be written in the smallest font possible, hidden in a scrolling collapsible box, perhaps even moved to a separate page and PGP-encrypted because fuck fact-checking anyway.cobaltcigs 15:55, 13 September 2020 (UTC)
Hi there, I am bit taken aback by the tonality of the replies, not by the fact that you disagree. I made a suggestion based on my experience in another WP, the German one, which is one of the largest WPs, and in which the order is the other way around: the reflist below the external links. There are obviously pros and cons for both concepts. I had heard at Wikimania in Stockholm 2019 that the English WP has become harsh and abrasive, and yes… feels true.--Satu Katja (talk) 18:36, 13 September 2020 (UTC)
I don't see anything harsh and abrasive here, but simply the fact that some editors agree with you and others disagree. If every proposal was greeted with unconditional support then we wouldn't have any discussions, but the first mover would simply always have agreement. Phil Bridger (talk) 19:59, 13 September 2020 (UTC)
I dunno, Phil. Saying that this idea would help the spammers does feel a bit harsh to me. WhatamIdoing (talk) 18:07, 16 September 2020 (UTC)
Sorry, but there's nothing harsh about it at all - it's simply people's experience of editing the English Wikipedia, which may be different from other language Wikipedias. If such a response is not to be allowed then there is no point in having any discussions. Phil Bridger (talk) 19:29, 16 September 2020 (UTC)
There's a distinction to consider between the importance of having references show up prominently when readers hover the cursor over the footnote, and having them show up prominently all together in a big chunk at/near the bottom of the page. The former is clearly very useful and important, the latter much more debatably so. {{u|Sdkb}}talk 04:07, 14 September 2020 (UTC)
Like others noted above that would be a big job moving everything around. Otherwise I kind of like the idea. I rarely browse the ref section by itself, I always go direct from the article. I do however browse the external link section since that can have some useful things. I would imagine most readers look at it that way as well. The important thing for the ref section is that it exists, not necessarily where it is on the page. Where as it can be nice to have the see also and external links more accessible. PackMecEng (talk) 20:18, 13 September 2020 (UTC)
Given that most readers aren't reading articles in their entirety from top to bottom, I actually think there is greater prominence having the external links at the end. Once people know the convention, then can jump to the bottom of the page to find the links. isaacl (talk) 16:18, 14 September 2020 (UTC)
I tend to agree with Isaacl. The very end of the page isn't necessarily the least prominent position. WhatamIdoing (talk) 18:07, 16 September 2020 (UTC)
Or use the table of contents, which is a list of wikilinks for a reason. ―Mandruss  19:56, 16 September 2020 (UTC)
As mentioned references are part of the article. Also there are often "bibliographies" "sources" etc. sections that come below a reference section. Do all of them get moved to the bottom or just the refs. I for one would not want to see the refs below a batch of ELs and categories as say at the Cary Grant article. IMO this is a solution in search of a problem and, thus, no change is needed. MarnetteD|Talk 20:16, 16 September 2020 (UTC)
  • Strongly opposed. In articles I see the EL section is typically very weak & stuffed with dead links, spam, or non-RS stuff. Also per Isaacl. Johnbod (talk) 14:55, 17 September 2020 (UTC)
  • Oppose This feels like a solution in search of a problem. I see no inherent benefit to one ordering over the other, and because of that, the proposal represents a large effort to be spent on zero net benefit. No need for it. --Jayron32 14:59, 17 September 2020 (UTC)

I like the present order of the ancillary sections at the end, because there is a logic to the order. "See also" points to material in Wikipedia; "References" points to material outside Wikipedia; "External links" points to unconnected material on the Internet outside Wikipedia; & "Further reading" points to material outside the Internet. (Okay, the last two is the order I put them in, but I've worked on less than a dozen articles that had both of those sections so which of the two should be at the end is a debatable matter.) -- llywrch (talk) 22:00, 17 September 2020 (UTC)

I'm always amazed by how different the articles you work on seem to be from those I work on, which generally have both. Nearly always this is FR then EL, as Wikipedia:Manual of Style/Layout implicitly suggests, but does not mandate. Johnbod (talk) 02:25, 18 September 2020 (UTC)

White text and templatesEdit

I decided to start development on a dark mode for the vector skin, which has white text on a black background. (The colors of links are also changed for legibility.) I noticed that various templates with a colored background make the text illegible. I was wondering if a module could be implemented to adjust the template's colors to match the user's default text color, or if the text in such templates should default to black. Alternatively, is there a way to work around this issue? To test the (pre-alpha state) dark mode yourself, go to Special:Mypage/vector.css and redirect the page to User:LaundryPizza03/nightvector.css. I'm sorry if this overlaps in scope with WP:VPT. –LaundryPizza03 (d) 08:51, 14 September 2020 (UTC)

LaundryPizza03, I think you're more likely to get a useful answer at Wikipedia:Village pump (technical). WhatamIdoing (talk) 18:08, 16 September 2020 (UTC)
I have used a similar gadget, which is green-on-black - I've experienced this issue quite frequently, especially with WP:IGLOO and user signatures. -- a lad insane (channel two) 21:44, 17 September 2020 (UTC)

More dates, including yearEdit

I just wanted to suggest that the information on Wikipedia would often be improved by dates added, including year, so one can get some context for reported events etc.. — Preceding unsigned comment added by (talkcontribs) 15:00, 14 September 2020 (UTC)

  • What? I don't know what your saying. Also, sign your posts, please. Arsonxists (talk) 20:03, 14 September 2020 (UTC)
  • Ideally, articles should already be providing all context, including dates and years, that is necessary to inform a reader's understanding of events. If you believe a particular article would benefit from the addition of dates, please feel free to be bold and add them yourself. – Teratix 01:05, 16 September 2020 (UTC)
  • The dates of events, including the year, very often are added. If one looks at the many biographical articles in Wikipedia, one can see that very often, they give the dates in which the person are born and died - not just the year the person was born and the year the person died, but the dates of the year the person was born and died. Some biographical articles, it is true, do not put in the year a person was born (I think this may be especially true for potted biographies of living people) but that may just be because the Wikipedian who started the article does not know the date a person was born. I would rather a Wikipedian omit a date than put in an inaccurate date. If a Wikipedian reads a biographical article and knows the date a person was born, s/he can improve the article by putting in the date. Vorbee (talk) 08:22, 18 September 2020 (UTC)
  • I have just been looking at the article on the Battle of Britain and see it does give the date of the battle, but quite a way down the article. Is what the proposer saying we should have dates nearer the start of articles? Vorbee (talk) 06:43, 20 September 2020 (UTC)

Have automatic "category-in-namespace" pagesEdit

It would be very helpful for maintenance and some other categories to have automatic "in namespace" sub-categories, such as "Category:Pages where template include size is exceeded/Article namespace" which would be the article pages in Category:Pages where template include size is exceeded, i.e. this list, except as a proper category instead of XML output.

I could then add this automatically generated sub-category to my watchlist instead of the main category. As it is, my watchlist gets the clutter of each move by a draft-, user-page, or other-page as it goes in or out of this category.

Also, editors who look at the categories directly would have an easy way to "filter out" the namespaces they didn't want.

If this were an automated part of Wikipedia, something like Category:base category/Article namespace, Category:base category/Talk namespace, etc. that would apply automatically to all categories, that would be even better. Of course, we'd have to rename any existing category that had a name-collision, but I would expect such collisions to be few. Since it would be an automatically-generated category, we would have to make a decision about the "content" (i.e. description page) of the category.

Alternative implementation: Provide a "in selected namespaces" filter on each category's page for people viewing the category pages directly, and a "in selected namespaces" filter for categories listed in watchlists. This likely would be more limited since it would be easier to code if the editor were forced to set a single namespace-filter that applied to all categories. In the original proposal, a user could watchlist Category:base category 1/Article namespace and Category:''base category 2''/Template namespace.

Thoughts? Who would find something like this useful? davidwr/(talk)/(contribs) 15:55, 14 September 2020 (UTC)

The second one can be done today in a gadget I would guess. It also has a phab ticket from 2013 (see also the child task). --Izno (talk) 17:15, 14 September 2020 (UTC)

Idea: Make the undo edit tool available to only Auto-Confirmed usersEdit

The edit tool can be used by vandals, to revert alot of edits on a page. It's kinda a big deal when a random wikipedian comes to the Nickelodeon article and reverts the page to the 2008 version (no that didn't happen). It might be a good idea to lock the undo button to people who are not Auto-Confirmed. It could also stop edit wars before they happen, if one of the person involved in the to-be edit war isn't Auto-Confirmed. Of course, I want your opinions, and see if this is a good idea. Thanks. Arsonxists (talk) 19:28, 14 September 2020 (UTC)

I don't think the "undo" is a huge concern, since edits that far back probably have "conflicting" intervening edits and can't be "undone." if you are worried about someone loading up an old page, then editing it and saving it, I'm not sure if it's feasible to prevent this. Perhaps more useful would be a tag for edits that affected more than one section which were made by a non-logged-in or non-autoconfirmed account. I haven't checked the tag list, perhaps that's already being done. davidwr/(talk)/(contribs) 19:50, 14 September 2020 (UTC)
Now that I think of it, yeah, that's not much of a concern. Might make a new idea for the more useful thing you mentioned. Arsonxists (talk) 20:00, 14 September 2020 (UTC)

Election Endorsement Notability StandardsEdit

In the 2020 Green Party of Canada leadership election, I noticed that there might be an issue of what constitutes a notable endorsement.

If I were to endorse any of the candidates, I would hope it doesn't make it onto that page, but there are some people who I really wouldn't describe as having any local importance or movement notability there. I think there may be room for an Endorsement Notability standard that applies to all elections, and propose the following:

An endorsement should be included if someone (a) has been affiliated with the party in an official capacity, (b) has held elected office in the country or voting zone, (c) is an organization that has existed since at least the start of the election cycle and has some relationship with the election issues, or (d) is a national or international name (like Rodger Waters or Greta Thumberg).

What do you think? TimeEngineer (talk) 12:55, 15 September 2020 (UTC)

As it happens, we have WP:ENDORSERFC. It looks like that was turned into a guideline at Wikipedia:Political endorsements (though I'm not sure there was actually a discussion promoting it to guideline status, it's based on the RfC, which has standing). — Rhododendrites talk \\ 16:15, 15 September 2020 (UTC)

Idea: The Deleted Namespace (or deletionspace)Edit

Recently, an article I was thinking about editing got deleted in the AfD process. The log is here: Wikipedia:Articles for deletion/Iron Golem (Minecraft). The article in question might pass WP:GNG after some time in development, most likely in the Draftspace. Unfortunately, I cannot easily edit this, or any other previous article, without either contacting an administrator or using a third party like Deletionpedia.
I propose a new namespace called the "Deletion Namespace" or "Deleted:". The namespace will archive deleted articles and allow them to be available after deletion. The page will function as a "morgue" of pages that have been archived but are still available for reference. They will not be editable, but instead you will be able to view source code and Wikitext. Version History will also be available to view. If you want to edit the article or revive it in order to improve it, there will be a button to do so (the normal Move button would be restricted, maybe?). This will convert the article to a draft, where it can be worked on in the Draft space until any problems that lead to the article getting deleted are resolved. Then it can be submitted in the AfC process, and potentially accepted into the Namespace. This allows articles to have a second chance at life without compromising the existence of the Articles for Deletion process.
It will essentially function like Deletionpedia, but would integrate into the namespaces for ease of use. Is this a reasonable idea? Any and all feedback is appreciated. Squid45 (talk) 20:47, 15 September 2020 (UTC)

  • Genius idea. I like it. Would be a really good porposal. Fixing a deleted article for all the other reasons mentioned in the AfD deletion would open new opportunities for pages to go "out-of-order" for a few days, then be in-order for a long time. It would also wipe Deletionpedia off the internet, which could open up alot of new editors on Wikipedia. Arsonxists (talk) 20:57, 15 September 2020 (UTC)
  • See Wikipedia:Perennial proposals#Deleted pages should be visible. davidwr/(talk)/(contribs) 21:00, 15 September 2020 (UTC)
  • This idea has a bevy of issues, but the main problem is that the whole point of deletion is to remove problematic content from public view that cannot be improved through normal editing. If an article were potentially salvageable, it would not have been deleted in the first place. If you think an article is potentially salvageable despite being deleted, what is so hard about asking an administrator to restore it to draftspace? – Teratix 00:59, 16 September 2020 (UTC)
    I find your excess of faith disturbing. On the contrary I suspect several salvageable articles are deleted every day (with the other 90% or so indeed being total shit). Browsing the deletion log to guess which titles might be worth requesting a copy of is not a reasonable strategy. The average admin would probably block you after the third unlucky guess. Separation of permissions might be the answer. ―cobaltcigs 23:04, 17 September 2020 (UTC)
    I was thinking more about articles that the salvaging editor has already seen or is otherwise familiar with (such as the scenario at AfD outlined in the original suggestion). I'm not suggesting randomly combing through deletion logs. (And in any case I'm highly skeptical the "average admin" will block editors just for making "unlucky guesses" about which content may be worth restoring). – Teratix 01:45, 18 September 2020 (UTC)

Proposal: Per-user/IP "pending changes protection" for low-competence editorsEdit

Proposal: Per-user/IP "pending changes protection" for editors demonstrating persistent low competence as a final step before blocking or in ideal cases, as an alternative to it.

Currently, you can block an editor from up to 10 pages or from a namespace, for example, you can prevent an editor from editing articles while still allowing him to edit other pages (see Wikipedia:Blocking policy#Setting block options, "Block editing partial").

What you cannot do is make all edits by a given editor automatically become "pending changes" even on pages that do not have this protection.

I recommend this as an intermediate step for users and stable-IP editors who are on the "slow march" to being blocked due to competence-issues. It would also be useful as an alternative to or final action before imposing school-blocks, which are sometimes places on an IP address or range for the duration of the school year.

This would also be useful for established editors with a conflict of interest who have demonstrated they can edit responsibly. Currently, such editors have to make an edit request on the article's talk page. This mechanism would allow responsible-COI editors to ask permission to edit conflicted pages directly, knowing they would be reviewed before being seen by non-logged-in editors.

This proposal would require a code change so I wanted to do a straw poll and get preliminary feedback here before taking it to a wider forum. Because it will need some preliminary discussion at WT:Protection policy, a full RFC, and a code change, I don't anticipate this going live before 2022.

Thoughts? davidwr/(talk)/(contribs) 16:02, 16 September 2020 (UTC)

This seems like a good idea. It would give pending change reviewers alot more power among wikipedia. Editors that (for some reason) turned on Wikipedia and started vandalising it could be foiled with the blocks. Arsonxists (talk) 17:21, 16 September 2020 (UTC)
My concern is that it would only take a few reasonably active editors (or even slightly more somewhat active editors) to overwhelm PCR. The system is very clunky, and an absolutely nightmare when you get more than one edit to a page (if some, but not all, are non-productive edits). I've long seen there to be more potential utility for PC, but it's fiddliness detracts from that. Nosebagbear (talk) 09:30, 17 September 2020 (UTC)
I don't see this as being a major issue if it were per-user-per-page. In most cases, a "still learning...slowly gaining competence" editor would be subject to "user-based" pending changes on only the few pages he's been editing disruptively, which would probably NOT include discussion pages. If they didn't "get a clue quickly" they would find themselves blocked from editing those pages. If they did "get a clue" the per-user pending-change restrictions would be removed. davidwr/(talk)/(contribs) 19:45, 17 September 2020 (UTC)

Alexa RankingsEdit

This is a query for ideas. What to do about Alexa Rankings in infoboxes (example WebCite).

  1. Enwiki has about 7,000 instances of {{infobox website}}
  2. The Alexa numbers change monthly. In a sane world it would be retrieved via automated means but..
  3. The ranking data is proprietary (Amazon) and there is a fee to access it via API ($0.01 per site) and you get the top X number of results ie. can't specify which website to get results for. Thus if you want ranking data for a particular website in the top 1 million it is very costly.
  4. The data can be web scraped.. but when done on a regular basis and loaded into Wikipedia it would almost certainly violate a copyright or terms of use rule, if not an outright IP block.
  5. The data can be manually added to Wikipedia.. but this is done sporadically see the WebCite example (2 years old as of this post), I have seen some over 5 years out of date.

As such, we have no legal way to automate the stats updates that isn't very costly, and manual updates are sporadic. As a result the Alexa numbers quickly become outdated and perhaps worse than nothing if misleading. Relying on the community to manually update over 7,000 infoboxes with proprietary data on a regular basis is a Sisyphean job. At the same time, there is a desire for this sort of thing from the community. What to do (if anything)? -- GreenC 01:40, 17 September 2020 (UTC)

I have previously argued that this data should be removed, much for the reasoning above. (I don't know where or if this was even onwiki.) --Izno (talk) 01:52, 17 September 2020 (UTC)
Previous discussion. --Izno (talk) 01:55, 17 September 2020 (UTC)
@Izno: Excellent forgot about that discussion. Good. It looks like consensus was trending to delete Alexa, but there was no RfC "Should we remove Alexa from infoboxes" to make it official. There was some support to have a template for the top 1000 sites, but that would again run into the problems mentioned above of data being outdated and copyright/TOU. Still it might link to Alexa and any other ranking sites without displaying a rank #, users click through. Do you think a VP RfC along those lines has some chance of consensus? -- GreenC 02:56, 17 September 2020 (UTC)
I think there is a fair shot of removal with an RFC at VPPRO or maybe even the temppate in question. --Izno (talk) 14:14, 17 September 2020 (UTC)
Its a good idea to move the idea to the proposals about deleting the Alexa Rank. Pretty sure RFC consensus will be supporting with it. Arsonxists (talk) 17:46, 17 September 2020 (UTC)
@Izno and Arsonxists: would you mind looking at an RfC proposal at User:GreenC/sandbox for any changes or comments? Found new API information that allows 1,000 free queries a month which opens an additional pathway. -- GreenC 18:21, 17 September 2020 (UTC)
@GreenC: I made some edits that I think go a slightly better direction. --Izno (talk) 19:36, 17 September 2020 (UTC)
Added the summary of problems and the number of domains needing tracking. -- GreenC 20:49, 17 September 2020 (UTC)
@GreenC: I think that the RfC is pretty satasfactory and should be released. Arsonxists (talk) 21:18, 17 September 2020 (UTC)
Alexa rankings get changed every single day, but not updated here. The more obscure a website is, the less it gets updated. And because it gets a very small websitebase, the ones in position next to them only need very small amounts added or removed from their userbase to get their rank changed. Meaning that: 1) On small website's articles, their Alexa rating is rarely ever correct.2) The rating on the article can be KILOMETERS AWAY from what the actual rating is.3) And the rating only gets updated very rarely. Meaning that it's an effect where the rank changes alot, but no one is there to change it. In conclusion: Yeah, it's a good idea to erase Alexa rankings entirely. Arsonxists (talk) 16:59, 17 September 2020 (UTC)

Update New RfC now open at Wikipedia:Village_pump_(proposals)#RfC:_Alexa_Rankings_in_Infoboxes. -- GreenC 17:21, 18 September 2020 (UTC)

idea for new editing approach: "consolidationism"Edit

I would like to think about laying out a new approach to editing in general, to be combined with the term "inclusionist." my working name for this "consolidationist," but right now that is just a suggested label. I am open to ideas on what to call this.

my idea for this approach is this; one core ideal of encyclopedic work should be greater topical overviews that are specifically designed to address and to weave together various historical topics, that already have their own entry, but which deserve some place within a larger overview for broader topics, eras, regions, historical movements, etc. right now, I am focusing on history as a topical field; we can apply this to other fields.

Two basic components for this idea, just as a start.

1) Firstly, one aspect of this is that every individual war or conflict, and other similar major historical events, should appear somewhere in a wider history of the era when that war occurred. so for example, clearly World War I already figures heavily in any overview of the era that it occurred. however, the Balkan Wars of 1911-1912 were of great importance as well, especially as a prelude to World War I and the other European conflicts. so that is just one example.
again, in general. as one core idea, we should seek to make overviews of historical eras into genuine topical overviews , and try encompass all of the smaller conflicts, events, that combined to shape that era. but again, the focus would be on building such overviews from "the ground up;" namely first would come the article on the specific conflict, event, trend, etc. itself., and then the originator would seek to add it to the broader entry for that era.
2) Secondly, on a different but related note, Wikipedia should seek to continually update its chronicle of current history, going forward. we already are a great exhaustive resource on past history. we should seek to do so on a broad scale for contemporary history as well. we already are great at generating individual articles for current events, as they occur; my point is that I would like to see some more attention to also generating and maintaining a broad historical overview for the current era, and updating it as events occur.
we already have 2020s in political history, for this purpose. I would like to suggest that we continue to make this a priority; that we focus on continuing to keep this series of decade overviews going. also, "consolidationism" would look into how to effectively adhere to WP:Notability, and to document current events, without falling into the trap of WP:Recentism. for example, several years ago, the US congress changed the Speaker of the House. No one thought to add that event to any of the overviews for that era, so I added it. obviously, we can't document everything; however, there should be some kind of standard of WP:Notability to work with here.

this is just an idea right now, so this page is the best place for it. I am not planning to move this ahead to a formal proposal right now. anything I do in the future will be shaped by whatever input I get. this doesn't need to be a formal proposal anyway; it can simply evolve, as people express ideas, interest, input, etc. etc.

ok, so what do folks here think of it? I assume the idea itself sounds rather innocuous, but feel free to call out any and all details on how we might put this into practice. whether you totally agree, or disagree, or find this interesting, or find it a little superfluous, your feedback is welcome. I appreciate it. thanks!! --Sm8900 (talk) 14:22, 17 September 2020 (UTC)

section break 1, consolidationism discussionEdit

You should review WP:SYNTH. Writing on topics that have occurred in the past few decades at a high-level is not really possible because the experts in history have not written the texts we would need to summarize the high-level. (I've even seen 50 years thrown around as the number before historians have sorted out who won and who lost in topics other than the discrete end of a war.) That would leave us writing synthetic commentary. Which is not allowed. --Izno (talk) 15:57, 17 September 2020 (UTC)
Ok, I partly agree with you, and I partly disagree. if that were fully the case, then it would not be possible to write an overview of any current eras, topics or events,would it? and yet.... isn't Wikipedia chock full of entries on items and events that are happening now? yes, you could say that the ultimate notability of these events is not fully known or understood yet, but that only highlights my own position on this. we cannot know the future notability of events taking place now, and yet, there are those entries.
yes, I fully understand that you are saying something different, i.e., that no one can yet know how specific events or topics would fit into larger overview articles. but with respect, I disagree with that as well. we already have widely used overviews for the current era right now, as well. they just are not necessarily explicitly labeled that way. so the best examples of such current era overviews would be articles such as Presidency of Donald Trump, premiership of Boris Johnson, 2020 United States presidential election, etc etc...
in other words, articles that describe current political figures, are often actively updated when those figures do something current that is noteworthy. there is no controversy over that practice imho, and there is widespread acceptance, of the fact that these articles are edited to reflect current events that are happening now. --Sm8900 (talk) 03:51, 18 September 2020 (UTC)

More concrete procedures of verification for new editors.Edit

I had been spent long time here and noticed that so many new editors has been blocked as a sockpuppet or glitch in there Ip address that matches some other accused or for having same opinions and ideas about particular subject matters. What if there should be more concrete process for verification for new editors. So that they can't face unnecessary blocking without explaining themselves for once. In most case scenarios People go through lots of assumptions and presumptions here which sometimes not be the truth.

Suggested ideas.

  • 1. Photo verification
  • 2. Providing a separate name and I'd for new editors for verification when they login 1st time.
  • 3. Conducting surveys every month to ensure their interest and what they think about Wikipedia. [Example like YouTube, Twitter and Instagram].

Redcap78 (talk) 04:13, 18 September 2020 (UTC)

No. Just no... I don't think Wikipedia should be getting stuff like this. It would hurt PR, and we would also lose our <13 editors. Arsonxists (talk) 15:06, 18 September 2020 (UTC)
No. This will just cause more people to either leave or edit as IPs. Judge accounts by their actions and edits. If someone is a vandal or sockpuppet that will be determined in time. RudolfRed (talk) 00:02, 19 September 2020 (UTC)
I'm thinking of wrapping this up in a {{archive top}}/{{archive bottom}} because proposals 1 & 2 would go against wmf:Privacy policy. Regarding proposal 3: some of us - even admins - have accounts on YouTube etc. which we would prefer not to make public. --Redrose64 🌹 (talk) 09:35, 19 September 2020 (UTC)