Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)


Village pump sections

Edit-find-replace.svg
Policy
watch
To discuss existing and proposed policies

Preferences-system.svg
Technical
watch
To discuss technical issues. For wiki software bug reports, use Phabricator

Dialog-information on.svg
Proposals
watch
To discuss new proposals that are not policy-related. See also: perennial proposals.

Tools-hammer.svg
Idea lab
watch
To discuss ideas before proposing them to the community and attempt to find solutions to issues

Help-browser.svg
Miscellaneous
watch
To post messages that do not fit into any other category

View all village pump sections at once

Hyperlink-internet-search.svg
Other help and discussion locations
I want... Where to go
...help using or editing Wikipedia Help desk
...to find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review
...help resolving a specific article edit dispute Requests for comment
...to comment on a specific article Article's talk page
...to view other Wikimedia projects Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography Citing Wikipedia
...to report sites that copy Wikipedia content Mirrors and forks
...to ask questions or make comments Questions


Contents

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

WP:PROTECT and Fascism

There is strong consensus for indefinite semi-protection of Talk:Fascism. I'd recommend that we consider adding a notice to the top of the talk page and/or the edit notice for the talk page to explain to non-autoconfirmed users why they are no longer allowed to edit that page, and possibly give some suggestions for alternatives. ‑Scottywong| [gossip] || 17:36, 8 October 2019 (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.

We've had an ongoing problem at Fascism regarding repetitive and disruptive edit requests, WP:NOTFORUM issues, and vandalism from throw-away WP:SPA accounts. The article talk-page was semi-protected by Acroterion for some time, but this eventually expired and immediately upon the lift of the semi-protect we began experiencing problems again. This led to this discussion about longer-term talk page protection. While I still believe this may end up at Arbcom before the ongoing disruption of the page will be quelled, the one person in the conversation who opposed permanent semi-protection of article talk suggested that, while they didn't believe local consensus at article talk would be sufficient for such an unprecedented move, bringing the topic here might provide some support. The problems with disruptive SPAs at Talk:Fascism is ongoing even as recent as today [1], [2], [3] and this has been going on for months except for the period in which the talk page was under semi-protect. Pinging the editors who were involved in the discussion at article talk:

@Acroterion: @Ritchie92: @Slatersteven: @The Four Deuces: @Aquillion: @K.e.coffman: @Beyond My Ken: @Red Rock Canyon: @Snow Rise:

The truth is that we can't just do nothing so hopefully this forum can provide us with something resembling a long-term tool for preventing disruptive talk page activity in this fraught area. Simonm223 (talk) 13:46, 26 September 2019 (UTC)

I wonder if it might be best to somewhat permanently semiprotect the Fascism article (probably doesn't need permanent, I'd suggest only ten years), but also create a couple sub-talk pages. Basically, "if you are here to tell us that Fascism is actually a left-wing thing, go here; all other suggestions go here." Someguy1221 (talk) 13:50, 26 September 2019 (UTC)
Semi-protect does seem to be the only answer.Slatersteven (talk) 13:52, 26 September 2019 (UTC)
(edit conflict)Troll pits were commonly used by early internet forums. They... didn't work. Simonm223 (talk) 13:53, 26 September 2019 (UTC)
While I am usually loath to protect talk-pages for longer periods of time, in this special case I would not oppose permanent semi-protection. But, and here I'll throw my hat in the ring with an idea I have been mulling over for some time now without ever getting around to it: enable pending-changes protection for talk-pages (I do not even know if this is technically feasible, though), as this might prove also useful for other talk-pages I have known.Edits not going live is a great deterrent. Lectonar (talk) 13:58, 26 September 2019 (UTC)
Permanent semi-protection is the only really reasonable and rational response. These right-to-left requests all come from IPs or brand new accounts, usually as their first and only edit. We're not losing anything by screening them. Beyond My Ken (talk) 14:02, 26 September 2019 (UTC)
I agree with permanent semi-protection. This is a fairly frequent topic on fringe websites and so attracts a steady stream of unregistered editors to the talk page. TFD (talk) 14:06, 26 September 2019 (UTC)
I disagree. They are taking issue with the content of the article, it is our long custom that talk pages be open. I don't see that they are being disruptive, they are just disagreeing. People who edit for the first time are often called "readers". I would not make talk pages into walled gardens.--Wehwalt (talk) 14:16, 26 September 2019 (UTC)
I dunno, took a gander. I think half of them are just disagreeing. The other half are ranting about propaganda or complaining that the article hurt their fee fees. All of them are useless. Someguy1221 (talk) 14:38, 26 September 2019 (UTC)
  • It might help to take all of the discussions about the right/left nature of fascism, and copy them into a single dedicated archive page. Then, at the top of the current article talk page, pin a permanent link to that archive (make it prominent). Include a note explaining that this is a frequently discussed issue, and asking editors to review the archive before starting a new discussion on the topic (to avoid everyone having to repeat an argument that has been held many times over the years).
If the trolls see that all their concerns and questions have been addressed and answered many times before, they might hesitate to raise them again.
At a minimum, this will give us one single place to point to when some troll DOES show up to repeat the same arguments we have rebutted so many times before. We can simply respond with... “See the discussions in the special archive linked above. Unless you can bring something new to the discussion, it is pointless to respond to your concerns. They have already been discussed multiple times and a firm consensus has formed”. Blueboar (talk) 15:12, 26 September 2019 (UTC)
We have this at the top of the page and it has dissuaded nobody:

Simonm223 (talk) 15:19, 26 September 2019 (UTC)

This is my issue, we have a big warning yet still hve to fend of the claim time and time again. Personally I have no issue with this, it does take much effort to type "No". But some disagree, and there is no question it is bloody tiresome. So if it will make most of our time here easier, lets protect it.Slatersteven (talk) 14:43, 27 September 2019 (UTC)
  • WP:RBI is made for just this sort of situation. Any time a new account shows up on that page to whine about fascism being left-wing, revert them, per RBI, WP:NOTFORUM, and the edit notice. If you have the rights, block them per WP:NOTHERE. Talk pages are not forums for "debating" demonstrably counterfactual political grievances, but they should otherwise be open. Ivanvector (Talk/Edits) 15:35, 26 September 2019 (UTC)
While I see what Simon and others are saying, I think it's important for reader concerns to be brought on the talk page, where the regular editors of the articles will see it, rather than a sub page which may not be well-monitored. I seem to recall a previous instance where such a page was instituted and it didn't go well, but I've been here 14 years and my memory is not perfect. I do recall several times when I was not minded to support a change to an article based on one comment, but the fact that several editors came along suggesting more or less the same thing convinced me. I suggest you come up with more stock answers and employ patience and an open mind. I'm also concerned about the effect on other controversial articles.--Wehwalt (talk) 17:36, 26 September 2019 (UTC)
Is there a notification on the article talk page? I see a number of editors have been pinged above but I don't see any notice there, and a number of active editors haven't been pinged, such as Rjensen. Also, it looks like this was discussed on the article talk page and no consensus was reached.--Wehwalt (talk) 17:40, 26 September 2019 (UTC)
Apologies, I tried to ping everyone who participated in the previous conversation. I'll put a note on the talk page now. Simonm223 (talk) 15:00, 27 September 2019 (UTC)
  • Support indef semi-protection; it makes sense at this point. --K.e.coffman (talk) 00:27, 27 September 2019 (UTC)
  • I tend to agree with Ivanvector. RBI seems to be the best policy to deal with this. I'm happy to add this page to my watchlist and lend a hand if that is the outcome of this discussion. Peacemaker67 (click to talk to me) 00:41, 27 September 2019 (UTC)
  • Support permanent semi-protection, for all the reasons listed above. --Enos733 (talk) 04:05, 27 September 2019 (UTC)
  • Support permanent semi-protection, for all the reasons listed above. Rjensen (talk) 04:19, 27 September 2019 (UTC)
  • I think RBI is the better route; it will be hard to sell me on protecting an article talk page. It's probably already pretty high profile, but ask at WP:AN if you need more eyes and block buttons. Wug·a·po·des​ 04:22, 27 September 2019 (UTC)
  • comment It takes me about 20 seconds to respond “no” to these requests and change the response to “yes” in the template. I get great satisfaction refusing these requests, but it would be nicer if we didn’t get them in the first place. Roxy, the dog. wooF 15:31, 27 September 2019 (UTC)
  • With regard to RBI, while I appreciate the place it's coming from, I'm concerned. Wikipedia hasn't exactly been aggressive with blocking far-right POV accounts unless they actually start openly saying explicitly racist things, and a lot of admins avoid the extreme politics article set as a den of vipers they'd rather nothing to do with. Past experience has shown me that users can openly display the swastika on their user pages and face no consequence as long as they lampshade it sufficiently. So while I understand the argument for RBI in this case, I'm concerned that what we'll end up with is what we already see on the antifascism articles: R-R-R-RSN-R-3RR-ANI-R-R-R-I. Simonm223 (talk) 16:11, 27 September 2019 (UTC)
I think if you care enough about the article to watchlist it, edit it, and participate in discussions about it, part of that responsibility is having to listen to the views of the public on the talk page, and not shunt them off to a page you need not watchlist. That's part of the job. The answer to too many people complaining to customer service is not to cease to monitor the mailbox.--Wehwalt (talk) 16:26, 27 September 2019 (UTC)
No, it isn't. It's not part of any Wikipedia editor's "job" or "responsibility" to entertain trolls. The left-wing-fascism trolls aren't here to be informed or to participate in an academic debate, nor to contribute constructively to Wikipedia, they're here for the sole purpose of making Wikipedia agree with their factually incorrect opinion that fascism is a left-wing ideology, and to waste the time of anyone who disagrees. They are the definition of not here to build an encyclopedia. The only appropriate response is to shut it down: remove their comments without replying (not put them on some other page), and block them if they persist. Any other response is a disservice to building an encyclopedia. Ivanvector (Talk/Edits) 16:45, 27 September 2019 (UTC)
  • Support indefinite semi-protection of article, WP:RBI without engaging in debate should be used on the talk page, with limited use of short-term semi-protection (a few hours to a few days) as needed to deal with any rapidly evolving disruption. --Jayron32 16:49, 27 September 2019 (UTC)
  • Indefinite (semi)protection is not appropriate for a subject which obviously depends on time-sensitive events like the current political climate in this or that country. Make it 5 years, if 1 year was not enough. Nemo 08:11, 28 September 2019 (UTC)
  • Support ~10 year semi-protect of Talk. Using RBI may counter productively inflame some people into Long Term Abuse. I prefer to avoid permanent protection... it's easy enough to renew protection if needed, but perma-protection can just disappear into the system. Alsee (talk) 09:44, 28 September 2019 (UTC)
  • Support multi-year semi-protect of Talk. I don't see RBI working because the community would not accept blocking a new editor simply for posting their misguided views. Johnuniq (talk) 10:04, 28 September 2019 (UTC)
  • Support indef semi-protection of talk, regretfully. I'm not at all happy that it's come to this (I'm someone who's tried to talk to some of these people on occasion), but I don't see any other way forwards. Large numbers of off-site activists continuously push a vision of the topic that is plainly and utterly inconsistent with mainstream scholarship or reliable sources; nothing we do on our end seems likely to change this or to stem the tide of people demanding that our article reflect what some talking head on YouTube told them. While we can revert or dismiss these repetitive requests, they come in such volume that it makes it hard to get anything else done on the talk page (especially since well-meaning users - ahem - often end up replying to them without realizing they're wasting their time, complicating handling them further.) There are lots of other things that need to be discussed on that page - we can't continuously humor people who want to use it as a forum to debate basic pol-sci 101 questions. Indef is best because let's be real, this isn't going to change unless there's some sort of massive shift to the informational ecosystem these people are coming from, and there's no reason to think that will happen in just X years or whenever. Also, to those who think this is just some passing phase in US political culture that will end in a few years, I suggest going back and reading the earliest talk page archives on the subject - it has been a consistent refrain for as long as the talk page has existed. Talking heads in the US have been peddling this for decades, and this page has attracted complaints from people who follow them for as long as it has existed. Literally the second edit ever made on the article itself - in 2001! - was someone adding the argument that Communism is actually Fascism. --Aquillion (talk) 20:51, 28 September 2019 (UTC)
  • Support Indef semi-protection. Carrite (talk) 17:26, 29 September 2019 (UTC)
  • Support semi-protection of the article and talk page, any length up to indef. (And then taking down that silly red warning.) Semi-protect is not really a high bar: it's not too much to ask that someone create an account and edit elsewhere for a few days before editing or participating in discussions about one of the most controversial articles on Wikipedia. Anyway, when an article is as "touchy" as Fascism, it requires a real understanding of the nuance of our policies to be able to contribute meaningfully, as well as having taken the time to read the long history of prior discussion. The upside of instituting the very low bar of a few days' experience is that we save a lot of editors' time and nerves by significantly reducing the amount of disruption they have to deal with on a daily basis. It's a trade well worth making. Levivich 02:31, 1 October 2019 (UTC)
  • Comment I think indefinitely semiing that talk page will achieve absolutely nothing except moving all those stupid meatpuppet comments to the Help Desk, the Humanities refdesk, Talk:Main Page or another wrong forum. What's the difference? Either way they can be reverted and ignored. – filelakeshoe (t / c) 🐱 08:53, 1 October 2019 (UTC)
  • Support indef semi-protection of talk page. In the worst case there are several other wrong fora so such inanity would be dispersed across them rather than be a massive time sink for other topics in discussion. – John M Wolfson (talkcontribs) 21:40, 3 October 2019 (UTC)
  • Oppose any form of protection of the talk page. The solution is to revert the edit, leave a boilerplate "Fascism is a right-wing ideology because ..." message on the person's talk page and move on. It'll take 20 seconds a pop once you've written a boilerplate message for it. Just a note that while "fascism is a left-wing ideology" is a deliberate attempt at spreading misinformation by the alt-right, the very point of spreading misinformation is that some people who repeat this lie are not themselves alt-right, just misinformed; hence some of them are people who could contribute constructively to the site in some way, and so WP:BITE and shutting down entry points into editing is still something we must be careful of here. — Bilorv (talk) 21:02, 4 October 2019 (UTC)
  • Support near-indefinite semi-protection. I'm sympathetic to the RBI approach: but by their nature (it beng apparent from the big red box at the top of the talk page) these are no more than trolling edits. These IPs and throwaways know what racism, leftism and rightism are—they just want us to say something else per their agenda. They don't care how many editor-hours it takes to get their way (water dripping on stone), just that they do. From our point of view, those are editor hours that can be usefully spent "building the encyclopedia", as we call it, rather than getting distracted by putting unnecessary pages on watchlists (pace Peacemaker, although the offer is respected) or getting RSI from continual rollbacking. No; the only satisfactory solution is to close the time and energy sink(s) that these edits force us to attend our on-wiki time to. ——SerialNumber54129 16:25, 5 October 2019 (UTC)
  • Support Seems like the best response to the problem. My experience on 0.999... is that such people are stupid, not just ill-served by a poor quality education system, and are unlikely to go on to contribute constructively on the topic. Hawkeye7 (discuss) 20:33, 6 October 2019 (UTC)
  • Support semi. My ideal would really be a warning template for issues like this and other cases where some users take a stance that is WP:CIR levels of wrong (e.g. antivaxxers, flat earthers, InfoWars fans...) saying "here's the sources, if you still want to say (stupid thing), we will block you;" along with a relevant block template explaining WP:FREESPEECH, WP:GEVAL and other common objections by fringe advocates. Like, I don't mean any iffy cases where any view could have zealots (e.g. Arab-Israeli conflict), I mean a both ArbCom and community consensus approved list for undeniably wrong topics only advocated by lunatic charlatans. Hell, I wouldn't even want a broad "pseudomedicine" category, but specific values in the template for water fluoridation conspiracies, crystal healing, and antivaxxers. This will help them understand that we are biased toward reality and if that bias appears liberal (or whatever), that's their problem. Ian.thomson (talk) 21:53, 7 October 2019 (UTC)
  • Support semi. Some of the latest stuff is complete lunacy (i.e. "So is Wikipedia actually allowing people to make false assertions even after being shown it’s false? I agree, it appears this was written by some far-left liberal hoping to use Wikipedia to falsely create a new definition, without any citation, to include “right wing”."). I can just about AGF with some people confusing socialism and National Socialism, but even most of them are simply trolling. Black Kite (talk) 22:32, 7 October 2019 (UTC)
  • WP:RBI I believe that Ivanvector is correct Talk pages are not forums for "debating" demonstrably counterfactual political grievances, but they should otherwise be open. Lightburst (talk) 14:35, 8 October 2019 (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.

Has policy changed re: inline use of sister project linking?

I've recently seen more inline linking in article text to articles in other language projects, where it supposedly even is OK to use that method for sourcing. Having always thought that we need to source articles speciically, not in an indirect manner like that, I'd like to know if there has been a policy change since I first logged in 10 years ago. Anyone know? --SergeWoodzing (talk) 17:00, 6 October 2019 (UTC)

To my knowledge, all Wikipedias (including our own) are unreliable sources per WP:UGC. They may (and should) cite reliable sources for their assertions, but those sources need to be cited again here. Putting a link to the other Wikipedia article in the citation (like this: [1]) is not enough. DaßWölf 19:28, 6 October 2019 (UTC)
@SergeWoodzing: We should not reference to any open wiki, and do not consider ourselves a reliable source. If the article on, say, de.wikipedia has a sentence that has a reference there, then you don't link to the german article, you use the reference from there. --Dirk Beetstra T C 07:17, 7 October 2019 (UTC)
Agree with those two. Of course, not all editors know this, but hopefully they won't explode when you tell them. Gråbergs Gråa Sång (talk) 07:51, 7 October 2019 (UTC)
It's quite important to distinguish between citing other wikis (which is not acceptable) and linking to articles in foreign language wikis where an English language article does not yet exist. For instance "with musicologist Cornelia Schröder-Auerbach [de] and violist and composer Hanning Schröder [de], in 1930 he founded the Harlan Trio" is acceptable but the example given by Daß Wölf is not. Martin of Sheffield (talk) 09:05, 7 October 2019 (UTC)
Martin of Sheffield, note that I there accept the use if the ill template, not de:Hanning Schröder (which appears as a bluelink). —Dirk Beetstra T C 09:13, 7 October 2019 (UTC)

Reflist - Has policy changed re: inline use of sister project linking?

References

  1. ^ de:Hauptseite. German Wikipedia. Retrieved 6 October 2019.
@SergeWoodzing:, it would be much easier to answer this question if you could give a concrete example where a link to another language Wikipedia has been considered acceptable as a source. Phil Bridger (talk) 08:20, 8 October 2019 (UTC)
Thank you! After receiving highly appreciated opinions here, I made this change yesterday to the latest one of several during the past months. There is an older example with four svWP links toward the end of the first § here. I have not made any changes there yet. --SergeWoodzing (talk) 17:29, 8 October 2019 (UTC)
In neither of those cases is/was the interwiki link being used as a reference here. Phil Bridger (talk) 17:42, 8 October 2019 (UTC)
You are right. Part of my question, however, regardless of references, is whether or not we are now OK to use interwiki inline citations linking like those that, when subjects do not have articles on enWP. I haven't thought we are supposed to do that. Perhaps Google translate has improved to a degree which makes it more feasible to do that nowadays? --SergeWoodzing (talk) 18:21, 8 October 2019 (UTC)
Depends on language, Svante Thunberg g-translated seems rather helpful/understandable to me (I like the The Archipelago Doctor translation). Gråbergs Gråa Sång (talk) 19:07, 8 October 2019 (UTC)
Once again, these are links, not citations. Phil Bridger (talk) 19:12, 8 October 2019 (UTC)
Phil Bridger: sorry i misstyped last time above. Fixed now. Are you - or is anyone else - willing to address the question as it does not pertain only to citations?

Does anyone know if it now has become acceptable to add inline links to subjects where there are articles in sister-language projects but none here as yet?--SergeWoodzing (talk) 19:34, 8 October 2019 (UTC)

As far as I am aware that practice has always been regarded as acceptable. The ill template has been around since 2013, but my memory goes back further than that. Can you provide any evidence that this was ever considered unacceptable? It seems obvious to me that this is good practice, because any individual language Wikipedia will inevitably be subject to a bias towards articles that can be sourced in that language. Phil Bridger (talk) 19:52, 8 October 2019 (UTC)
  • My understanding has always been that we should NOT include inline links to articles in other projects (such as other language WPs). This is primarily due to the fact that other projects and language WPs have different core policy rules than we here at enWP do (ie they don’t follow our rules on Verification, NPOV, NOR, Notability, etc.) Blueboar (talk) 20:07, 8 October 2019 (UTC)
  • Whenever a title is suitable for a red link it is also suitable for an interwiki link. Why on Earth not? Let's not assume that the English Wikipedia is the be all and end all, and that it is anywhere near complete, particularly when it comes to topics whose sources are not in English. Phil Bridger (talk) 21:09, 8 October 2019 (UTC)
Help:Interlanguage_links#Inline_links may have something helpful, my reading is that using them (like Cornelia Schröder-Auerbach [de]) is a case-by-case consensus thing. Gråbergs Gråa Sång (talk) 20:55, 8 October 2019 (UTC)

Thank you all, but my question is not (not) about red links, where I understand, it's about blue links that go directly to articles on other language Wikis. Acceptable? --SergeWoodzing (talk) 15:11, 9 October 2019 (UTC)

  • Well.... in general, other wikipedia's shouldn't be considered a "reliable source" to be used in a reference, regardless of how the linking mechanics are performed. — xaosflux Talk 15:28, 9 October 2019 (UTC)
Ah, you mean like in "Ulf Brunnberg, Kisa Magnusson, Bill Öhrström and Bruno Wintzell". IMO bad idea and potentially annoying for readers. In general, a "normal-looking" wikilink should not take you outside en-WP. The ill-template is preferable. Gråbergs Gråa Sång (talk) 15:38, 9 October 2019 (UTC)
I agree. The {{ill}} template, which I was unaware of before this discussion, gives the best of both worlds: a local red link and a live link to another language Wikipedia with further information. Phil Bridger (talk) 16:30, 9 October 2019 (UTC)
Thank you again! I too agree. And I've learned something new, now again, despite being an old dog. --SergeWoodzing (talk) 17:46, 9 October 2019 (UTC)
SergeWoodzing, the answer is in WP:SISTER. "Normal-looking" inline links to other language editions of Wikipedia are not absolutely banned, but they are discouraged. However, regular links to Wikisource (e.g., you're talking about a non-notable document that Wikisource happens to have a copy of) and Wiktionary (e.g., words that may be unfamiliar to some readers) are accepted. WhatamIdoing (talk) 18:09, 11 October 2019 (UTC)

Why only GPL, why not MIT (edited)

A developer want to give his code to Wikimedia Foundation, so that they can use it in there project (which is actually needed).the code is actually "javascript" & Licenced under MIT licence because a small portion of the code was already licensed under MIT licence .now my questions are.

  1. MIT license says it is compatabe with GPL . so why can't foundation use this code even when the developer is ready to give a written acknowledgement ?
  2. If the 1st isn't possible, then can he license his code in dual license (MIT+GPL) ? then give the code under GPL license ?
  3. If 1st & 2nd isn't possible , then.can he make a portion of the code licensed under GPL ,so that he can give his code to the foundation ?

Thanks in advance .--md masum (talk) 18:23, 8 October 2019 (UTC)

The MIT licence (well, any of the well-known different versions) is compatible with the GPL, so code under the MIT license can be incorporated into GPL projects with no problems. I see no legal reason why the WMF would be unable to use it. --Stephan Schulz (talk) 19:48, 8 October 2019 (UTC)
However, Wikipedia uses the GNU Free Documentation License (GFDL), not the GPL, does it not? (Wikipedia:Copyrights). Regards SoWhy 20:02, 8 October 2019 (UTC)
GFDL is for text contributions. This is not code (well, executable), so does not need the "as is" warranty that GPL/MIT has. GPL is fine since the only restriction is that code is provided as-is, so MIT should be fine too since it has the same non-restrictions on use and only the as-is disclaimer. --Masem (t) 20:44, 8 October 2019 (UTC)
The MediaWiki software is licensed under GPLv2. isaacl (talk) 17:17, 9 October 2019 (UTC)
Just a curiosity question ,@Stephan Schulz: , @SoWhy: , @Masem: . there are many open license projects (GPL & MIT) in github . why the Wikimedia Tech team can't use these code to make a ton of cool features .what's the legal issue ?many many thanks in advance--md masum (talk) 06:24, 9 October 2019 (UTC)
Coordinating licenses is only one problem. Building working software systems is hard on a technical level - and the more "cool features" are added without a consistent architecture, the more technical debt is incurred. Most industrial software project fail (either officially, or by massively overrunning budgets while underdelivering on features). This is expensive, and the WMF should be careful not to overcommit. --Stephan Schulz (talk) 09:43, 9 October 2019 (UTC)
I agree. I worked for a few decades in IT and saw many projects fail (usually unoffically because nobody wanted to take the blame) because all of the stakeholders wanted their pet features to be included and nobody had the authority to say "no" to them. Phil Bridger (talk) 16:35, 9 October 2019 (UTC)

Wikipedia:Attempting to overturn recent consensus

I was looking for a project page that stands for the proposition that an editor should not attempt to revisit a topic for which a discussion was just closed by starting a new discussion on the same topic. Since WP:TOOSOON is taken by a page on people seeking admin rights before they are ready, I decided to expand and repurpose my prior essay on moratoriums into Wikipedia:Attempting to overturn recent consensus. Let me know if I've missed anything. Cheers! bd2412 T 21:04, 8 October 2019 (UTC)

This appears to be a new proposal that would require consensus to implement. If this is the page where the consensus is supposed to be achieved, I support the proposal as it appears to be in good working order, although it should not apply when any new request is substantially different from previous ones. – John M Wolfson (talkcontribs) 21:34, 10 October 2019 (UTC)
It might be worth adding some language to that effect, and delineating factors that make a new request substantially different from previous ones. bd2412 T 21:42, 10 October 2019 (UTC)
BD2412, I think it is nice expansion from WP:Moratoria.
It is a mix of sort-of existing and recognized best practice, to wait before trying the same thing again, and is gently pushing the concept further. It crosses the unclear line between essay and proposal. It is very similar to WP:RENOM, which is primarily for seeking deletion after an AfD "keep" decision.
It lacks comment on relitigating a discussion that was closed as "no consensus". These cases tend to be worst cases of beating dead horses until the community gets more than annoyed. --SmokeyJoe (talk) 23:07, 10 October 2019 (UTC)
I agree. Somewhere in Wikipedia we need to provide some guidance on when it is not okay to try to hastily relitigate something where strong feelings have not yet settled, and this is a start. bd2412 T 14:31, 11 October 2019 (UTC)
Any protection against reopening a topic needs to be dependent on the original discussion having been notified to any relevant/interested projects, and on it having been held in the right place. Cabayi (talk) 14:39, 11 October 2019 (UTC)
I agree with this idea. Perhaps come up with some redirects to point to this essay with some shorter titles, so that people can find this more easily. Sm8900 (talk) 14:47, 11 October 2019 (UTC)
Good idea, if it is workable. Earlier this year we had a suggestion that "chairman" be changed into furniture or some neologism. The proposal failed to achieve consensus. Within hours of being closed it was reopened, with the same result. Immediately after that it was reopened for a third time. When you see behaviour like this it is pretty pointless taking part in an RfC. Martin of Sheffield (talk) 15:11, 11 October 2019 (UTC)
@Cabayi: I agree, but do you have wording in mind for this? For now I am just copying what you wrote. bd2412 T 17:39, 11 October 2019 (UTC)
BD2412, the gloss you added to my text fills out the balancing points. I'm happy. Thanks, Cabayi (talk) 09:10, 12 October 2019 (UTC)
Just for the record, WP:TOOSOON is about notability and WP:NOTNOW is about RfA. (We really need to fix this, but I don’t know how.) —pythoncoder (talk | contribs) 22:39, 11 October 2019 (UTC)
Well I knew it was one of them. Still, no policy page (or any guidance) one when it is too soon to start a new discussion of a previously settled issue. bd2412 T 23:17, 11 October 2019 (UTC)
  • I think this needs to be taken on a case by case basis. I was recently involved in a case where I requested for a "consensus" to be overturned. Long story short the proposal gained "consensus", but it was big change that affected a lot of projects, and was against other Wikipedia policies. The original submitters suggested that they advertised this widely, but for a such a big change I successfully argued to re-open it on the basis that it needed to have much more input to even argue there was consensus. After many months the whole debate was closed as no consensus, because in reality there was no consensus. So I have strong feelings about consensus, and perhaps the outcomes should have votes for/against/abstain in summaries. Consensus should be able to be overturned if there is consensus that it should be. However there needs to be balance of being able to overturn inappropriate change, against repeatedly bringing the same proposal to a table. I think a sensible way of doing this is that if recurrent RfC on the same topic are proposed, then it should be escalated to admin/multiple admin/governing board at some level. It really just needs everyone to play honestly. Master Of Ninja (talk) 09:19, 12 October 2019 (UTC)

American or British spelling? Neither.

This discussion was more a request for comment generally on issues related to WP:ENGVAR rather than a firm proposal. There is no consensus. The proposer Getsnoopy is going to use the results of this discussion to write a proposal on his proposed changes (see below, but in summary to propose to standard all English variants to Oxford spelling). I will leave the proposer to make the decision on best forum to post, however Wikipedia:Village pump (proposals) could be an option. I note the concerns below of multiple initiated discussions: it is better having one centralised discussion and crossposting a link to this to other relevant boards, although please check the WP rules on crossposting before doing this. Further once the proposal has been posted it may be worthwhile to inform editors participating in this discussion, and to make reference that this discussion (and related discussions on other boards) has been previously completed. - Master Of Ninja (talk) 08:27, 22 October 2019 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I don't understand why this has historically been made a bigger issue than it should be. Clearly, picking one or the other inevitably brings up defensiveness, so why not pick a 3rd neutral option? Retain MOS:TIES, but in the case that an article doesn't have any real ties (e.g., science), use Oxford spelling. It's the most etymologically accurate, most neutral, most international version of English used by almost every international organization. In terms of vocabulary, keep the current policy where you follow the standard that's already been established in the article, and/or maintain MOS:COMMONALITY. Having a "retain the variant of English used by the OP (original poster)" policy creates a silly first-mover advantage for article creators in some sort of race to create a bunch of article stubs tagged with their favourite variant of English and effectively tie the hands of all subsequent contributors. And supporting multiple variants of spelling is absolutely asinine in my opinion. If 193 countries around the world and basically every international organization can agree on a common standard, why can't Wikipedia? Getsnoopy (talk) 18:22, 9 October 2019 (UTC)

  • Because we reached a consensus to allow more flexibility. Blueboar (talk) 18:27, 9 October 2019 (UTC)
  • The standard is to use the most appropriate variant for the article in question. See WP:COFAQ#ENGLISH and MOS:ENGVAR. I feel as long as the English is readable and understandable these slight variances shouldn't be a problem. However every now and again someone wants to push their own view of what is correct English onto the whole of Wikipedia, which then generates pushback, and leads to extended debates rather than improving Wikipedia. Trying to standardise things will never generate consensus - see the whole debacle the lasted months over trying to spell organisation/organization. I think the OP also is incorrect in stating that other organisations have agreed on a standard: in reality if you want to do work you can have to be pragmatic and accept slight variants in English. And these are variants in that apart from slight spelling differences there is complete mutual comprehensibility. We should not worry too much over this. - Master Of Ninja (talk) 08:53, 10 October 2019 (UTC)
    • @Master Of Ninja: The UN (and therefore all countries that interact through that body) uses Oxford spelling exclusively, as does the IMF, ISO, IEC, BIPM, etc. I've never considered "it's not a big deal" to be a good argument, if at all. The same could be said about many things in WP:MOS because one could say, "At the end of the day, what matters is the message getting across. Grammar, spelling, style, formatting, etc. are all secondary." The point of standards is to make communication efficient and frictionless. Insofar as that is possible, we should strive for it. Getsnoopy (talk) 20:52, 10 October 2019 (UTC)
      • @Getsnoopy: The standard is English and most people can get around the common variants of spellings. What is your actual proposal here? The way you've formatted the original post is a general complaint about a contentious subject that is already explained in MOS:ENGVAR. Is it the Oxford spellings you want to standardise around? If so say so. I'm not sure further discussion without a proposal is a good use of time. If you really want to change a policy I would go and build consensus for a view, and then form a proper argument and subject it a RFC (not sure which board is most appropriate). I wish you luck with this as it requires a lot of energy, which is IMHO better spent just making and editing good articles. Another option is to get involved with some of the technical side of Wikipedia - there was a suggestion of porting over something that is used in another language Wikipedia (?variants of Chinese) that automatically translates the spelling based on your dialect. Master Of Ninja (talk) 09:07, 12 October 2019 (UTC)
        • @Master Of Ninja: Yes, that's what I'm proposing. I said that in no unclear terms: "Clearly, picking one or the other inevitably brings up defensiveness, so why not pick a 3rd neutral option? Retain MOS:TIES, but in the case that an article doesn't have any real ties (e.g., science), use Oxford spelling." As for improving WP, while I agree with you that there are many ways of improving WP, I think this is one of the ways to do that as well. Getsnoopy (talk) 20:00, 12 October 2019 (UTC)
          • @Getsnoopy: Your original post then needs to be clearer that this is what you are proposing. I feel that the current consensus is actually the most pragmatic and inclusive for editors, however don't listen to a naysayer like me and if you want to propose it, propose it. I would however start a new thread and *explicitly* state that this is your proposal, rather than write it what looks like a complaint that has been discussed many times over the years. Like I say village pump may not be the best place to discuss this but I'll leave that up to you to decide; not the best place as if you want to effect change you really, *really* need to engage stakeholders and come up with a consensus or more like supermajority of editors/admins in charge to make a common style standard. I would start your proposal as e.g. "Proposal to make English style as Oxford English", state what your proposal and define Oxford English, and then state your reasons why you want this to be done, and to make it balanced benefits and drawbacks. I would start as a request for comment before potentially pushing it to a vote. Again good luck with this. Master Of Ninja (talk) 08:55, 13 October 2019 (UTC)
            • @Master Of Ninja: I'll be sure to do that; I guess as this discussion has been progressing, I changed my proposal to the one at the bottom of this section if you want to take a look. Which venues do you suggest I make this proposal in? And which stakeholders do you suggest I engage to make progress on this? Getsnoopy (talk) 21:52, 13 October 2019 (UTC)
              • @Getsnoopy: I'm not sure where your proposal is, but then again there's so much in the thread now I've lost where everything is. Anyway you can get a flavour of why people are in favour of WP:ENGVAR here. I'm not sure which forum is best to propose something like this in - have a look at the MOS pages and the general Village pump pages to see where it best fits in. It may need crossposting, but again don't know the rules on this as I tend to focus on editing rather than stay on WP politics - the only reason I have this page on my watchlist was that someone some time ago tried to push through a proposal in (my perception) a fairly underhanded way. There will be a lot of stakeholders with different views so can't really list them all, but they will be under the umbrella of wikipedia editors. Master Of Ninja (talk) 06:17, 14 October 2019 (UTC)
  • I would love Wikipedia to agree on a standard, whatever standard that might be, but we have enough editors who are not willing to agree on a standard to make that impossible. An example of how we can not agree on a standard in one tiny area, let alone for the whole of Wikipedia, can be found at Wikipedia:Village pump (policy)/Archive 153#RFC: spelling of "organisation"/"organization" in descriptive category names. We Brits are perfectly capable of reading American books written in English, just as Americans can read sources written in Indian English, with no problem, so this should not be an issue. The only problem I remember ever having had in this area is with pronunciation rather than spelling, when, when I was following an online course in architecture, the instructor kept talking about "nitches". It took me a bit of time before I realised that she was talking about niches, which I would pronounce very differently. Phil Bridger (talk) 18:35, 9 October 2019 (UTC)
    • I totally agree. I have seen some of the most absurd and wasteful edits over the diff twixt AmerEnglish and BritEnglish, AusEnglish and the idea of CanaEnglish or JamaEnglish or any other country where English is the primary language such as Liberia, boggles the mind.
    • @Phil Bridger: But that's exactly the crux of my point: I wouldn't be OK with any standard, since I, for example, don't agree with American spelling even though I'm American. And again, this is not to say that the other aspects of a dialect should be standardized as well (vocabulary, etc.); I'm merely talking about spelling. So I'd be fine with people using "elevator" vs. "lift" or "trash can" vs. "rubbish bin" as long as we spell them the same way. And I think the reason people haven't been willing to agree is that the options presented have always been one particular national variant at the expense of another. As far as I can tell (and search for), I haven't seen Oxford spelling being proposed as a standard. Getsnoopy (talk) 02:14, 10 October 2019 (UTC)
  • To me I don't care if it is spelled color or colour, neighbor or neigbour, labor or labour, my only peeve is with colloquialisms that are not known or used outside of a region (Angle land and Mericke have plenty), Oldperson (talk) 20:44, 9 October 2019 (UTC)
    • This edit was reverted because it wasn't believed to be policy. I was told to take it to "the talk page".What talk page? The comment was agreement. This editor doesn't see what a big deal it is if an edit is made in AmerEnglish or BritEnglish.Oldperson (talk) 01:25, 10 October 2019 (UTC)
  • Oppose per above. This is a long-contentious area of Wikipedia, and there's no likelihood or reason for the consensus to change. – John M Wolfson (talkcontribs) 01:44, 10 October 2019 (UTC)
    • @John M Wolfson: Well the point is about whether it's a reasonable proposal, not what its likelihood of success is. If everybody thinks it is reasonable and should change, then obviously, the likelihood of its success is 100% regardless of old consensus. Getsnoopy (talk) 02:14, 10 October 2019 (UTC)
  • Oh boy, an evergreen discussion. But MOS:ENGVAR is pretty clear, and to me at least it doesn't make sense to not use Australian English on some very Australian articles. SportingFlyer T·C 11:11, 10 October 2019 (UTC)
    • @SportingFlyer: I actually don't think this specific discussion has been had. In the past, most people have proposed using one national variety wholesale, which is not what I'm proposing. And you'd still be able to use Australian English in terms of vocabulary, grammar, etc., just not spelling. Besides, Oxford spelling is quite similar to that of Australian spelling. And all of this notwithstanding, I'm only proposing Oxford spelling for generic articles; MOS:TIES would still be retained for all articles with strong national ties. Getsnoopy (talk) 20:34, 10 October 2019 (UTC)
  • The idea of "Oxford spelling" as some kind of compromise between various competing spelling standards might be tempting in theory, but in fact you're basically suggesting that we write a significant number of articles in an form of spelling that essentially no editors or readers use in their daily lives. Oxford spelling is no less arbitrary than any particular national variety of English, and it has the disadvantage of being unfamiliar to everyone, aside from UN bureaucrats and British academic journal editors, I guess. Even the least-common English regional spelling variety is at least accepted as normal by those native to that region. Red Rock Canyon (talk) 23:35, 10 October 2019 (UTC)
    • ?? Loads of Brits, including me, use Oxford spelling all the time. I think you're under a misapphension there. But there is a lot more to ENVAR than the limited number of issues Oxford spelling would settle. No need to to heckle, Getsnoopy. Johnbod (talk) 23:41, 10 October 2019 (UTC)
    • Loads of Brits reading something using Oxford spelling would just think it is American. MilborneOne (talk) 14:36, 11 October 2019 (UTC)
      • There's no perfect answer, and the system we have is probably the least-bad one. I'm not in favor of "You must always do it this way" type prescriptions when avoidable. It's alienating. The current system gives some leeway to article creator, which is fine. Don't muzzle the ox that treads out the corn.

        Also, I mean if you wanted to lock down one single standard, I suppose the best would probably be American English rather than Oxford spelling or anything else. Reason being -- I looked this up, and was actually quite surprised -- about 2/3 of native English speakers are Americans. England and Canada and South Africa and Australia &c. taken together are large, but America is very large. I'm not recommending this, tho. Herostratus (talk) 18:38, 11 October 2019 (UTC)
        • @Herostratus: There are many rules in WP:MOS which outline how one "must always do it this way", and yet there are no complaints there even though a lot of those rules vary among countries, dialects, and even publishers. As for American English, the US's English-speaking population is only about 25% of all English speakers in the world, and the remaining 75% speaks some variant of British/Commonwealth English. Wikipedia is not only for "native English speakers", so using native English speaker statistics serve as a weak argument. The fact that WP hasn't been able to settle on American English as the standard for everything is no coincidence considering those facts. Getsnoopy (talk) 04:12, 12 October 2019 (UTC)
          • Actually, there are plenty of complaints, but the MoS regulars (I sort of speak as one, I guess, though a bit malvolentieri) are organized and manage to shut them down. Trying to impose British spelling on American editors, as a site-wide preference, would be a whole different ball of wax. They won't put up with it. I won't put up with it. And while non-native speakers are absolutely welcome here as both readers and contributors, it seems to me they're less likely to have fixed views on variety. In any case consistency is massively overrated, in general. --Trovatore (talk) 04:46, 12 October 2019 (UTC)
            • Seconded. There are complaints. Consistency is overrated. Consistency is good for editors (readers probably don't much care) for the sake of not having endless arguments over some things. And yes, if I am creating an article about something that is not country specific, I am not going to write "colour". Phhht. That's right out. (If the article's already started, that's different, for the sake of comity I'll go along with the article creator -- just as she will go along with me.) Yes the point about Indians (they use British English, and a lot Indians speak English very well and it is both common and official in India) is important, but so is the point about 2/3 of native speakers being American. They both matter. That's one reason why the system we have now is probably OK. Herostratus (talk) 15:33, 12 October 2019 (UTC)
          • @Trovatore and Herostratus: How exactly is that a "whole different ball of wax"? "They won't put up with it. I won't put up with it" isn't a valid reason for how that's any different than any of the other standards. Also, I find it ironic that as a "MoS regular", you're claiming that consistency is overrated. Imposing British spelling is exactly what I'm against as well, which is why the title of the section is "American or British spelling? Neither"; I'm proposing a neutral option which is Oxford spelling. The Oxford English Dictionary specifies "color" as a co-headword with "colour"; it actually does that for all the -our/-or suffix words, so no one would have to spell it only as "colour" and such. Getsnoopy (talk) 20:00, 12 October 2019 (UTC)
            • Consistency is overrated. That's my opinion, whether you find it "ironic" or not. You are in fact proposing imposing British spelling, albeit a particular subtype of British spelling that conservatively retains one feature American spelling has also retained. You have not made the case that such a change is necessary; its downside in terms of the bad feeling it will engender is obvious. --Trovatore (talk) 20:20, 12 October 2019 (UTC)
              • @Trovatore: Given that all editors have already accepted the existence of MOS, I don't really see that adding to that set of standards will "engender" a "bad feeling". Getsnoopy (talk) 21:52, 13 October 2019 (UTC)
                • We aren't talking about en dashes versus hyphens here. This proposal is essentially a proposal to deprecate American spelling, with the sole exception of -ize endings. If you don't understand how that could engender bad feeling, then I don't know what to tell you. --Trovatore (talk) 23:48, 13 October 2019 (UTC)
                  • @Trovatore: No, it isn't. Oxford spelling allows for -our/-or suffixes co-equally (as I've already mentioned), as well as preferring the -ize suffixes. But that's besides the point; the proposal is about choosing a neutral variant of English for what are essentially neutral articles (international articles with no strong ties to any particular variant). It seems like you're quite biased/defensive about maintaining American spelling rather than rationally understanding what the proposal is actually calling for. And I've in fact tweaked my proposal to make it the least disruptive; please read the bottom of this section. Getsnoopy (talk) 07:07, 14 October 2019 (UTC)
  • User:Getsnoopy, can you give a few examples of article creators who are "in some sort of race to create a bunch of article stubs tagged with their favourite variant of English"? WhatamIdoing (talk) 18:22, 11 October 2019 (UTC)
    • @WhatamIdoing: Yes, here are a few: Coupé, International Date Line, and Carbon fiber reinforced polymer. If you look at the early histories of those articles, you'll see that they've been tagged with a certain variant of English early on (the latter one hasn't been explicitly tagged, but the edits all veer in the direction of supporting American English, for example). Getsnoopy (talk) 04:12, 12 October 2019 (UTC)
      • These all go back to 2003 or 2002 in the last case. You say: "the latter one hasn't been explicitly tagged, but the edits all veer in the direction of supporting American English, for example". Well, double doh! Maybe it was written by American editors. Enough of this. Johnbod (talk) 17:21, 12 October 2019 (UTC)
        • @Johnbod: How is what year they were created in relevant? Also, did you read what the question was about? I was pointing out examples where in the "stub" stage of an article, the article was explicitly tagged with one variant of English which is usually unnecessary at that stage of an article. The fact that that has been done would indicate that some article creators are trying to impose their favourite variant of English. The latter example was originally titled "Carbon fibre", and there were some editors who changed it to "fiber" arbitrarily (hence the point about not being explicitly tagged with {{Use American English}}, but setting the stage for that in the future). Getsnoopy (talk) 20:00, 12 October 2019 (UTC)
          • Whatamidoing's question was stated in the present tense, and you gave examples from the early days of Wikipedia. That does not seem to be particularly convincing as an argument that this is a widespread current problem. Admittedly there's no way you can establish that with "a few examples"; en.wiki has almost 6M articles, so even if you can find three or four current cases, it doesn't prove much. I imagine this does happen to some extent, but you have a very heavy burden of proof to show that it happens enough to justify your incredibly disruptive proposal. (To clarify, I don't mean that making the proposal is incredibly disruptive; it's only a little disruptive, as probably not that many people are paying attention. But it would be incredibly disruptive if implemented.) --Trovatore (talk) 23:03, 12 October 2019 (UTC)
            • I don't agree that the proposal would be disruptive if the assumption is that people are aware of the differences and that they can navigate them with ease. See my proposal at the bottom of this section for how to make this proposal the least disruptive. Getsnoopy (talk) 21:52, 13 October 2019 (UTC)
  • With the current policy a large proportion of editors get to write in "their" variant of english, and where people write in articles that are obviously in another version of english there is a good chance that they know or are aware of the difference. If we changed to one standard form of spelling then a whole swathe of editors would find themselves being ticked off by pedants for not conforming to MOS. That makes this proposal one that is likely to lose us far more editors than it gains us, and with the community divided as to whether editor retention or civility is our biggest problem, standardising on one form of spelling is going to make things worse, whichever of those two you consider our biggest current problem. Remember our editors are unpaid volunteers, we don't require them to learn MOS before making their first edit, and nor should we. ϢereSpielChequers 00:01, 13 October 2019 (UTC)
    • Yah. Generally speaking, editor relations work better on a peer-to-peer model rather than a cop-to-perp model. When possible (it's not always possible), it's better to be like "let's talk about this and work it out" rather than "I'm reporting you to ANI". If there's some kind of "rule" made that, when creating a non-location-specific article, I have to write "computer programme"... well, I'm not going to do that, so then when I don't, I guess I'll get in "trouble", and how is that helpful to what we're trying to do here. Herostratus (talk) 02:43, 13 October 2019 (UTC)
    • @WereSpielChequers and Herostratus: Hmm...those are good points. I guess the point of my proposal is not to catch violators of this proposed rule "red handed" and reprimand them in some way. We already have many articles which are in violation of MoS, and there are many editors who go in and edit those articles to make them compliant over time. I'm imagining a similar mechanism with this. So how about this: currently, editors are forbidden from changing the English variant of an article if it's already been established; we should change the rules so that if an editor wants to change the variant to Oxford spelling for a non-strong-ties article, it should be allowed. That way, editors who want to get going initially will not be burdened/dissuaded by onerous rules, but editors who favour consistency have the freedom to make the articles compliant. Getsnoopy (talk) 21:52, 13 October 2019 (UTC)
      • No. The purpose of WP:ENGVAR is to avoid the ill feelings and wasted time that results from people with nothing better to do who go around looking for articles to tweak according to their favorite rule. This is a good WP:BIKESHED issue which people are happy to discuss at length, but the take-home message is that there will not be a change to ENGVAR. Johnuniq (talk) 02:43, 14 October 2019 (UTC)
        • @Johnuniq: I don't understand what ill feelings could arise from changing a neutral article to what is arguably the most neutral English variant; strong ties articles will remain, and so will neutral articles where there's no motivation to change it. If editors want to optionally change neutral articles to Oxford spelling, they can. People who've been following MOS:RETAIN will continue to follow it thereafter. As for wasted time, it's an editor's choice; if you don't want to expend the energy to change articles, that's totally fine, but why would you prevent others who are motivated to improve the consistency of WP from doing so? Getsnoopy (talk) 07:07, 14 October 2019 (UTC)
          • What makes an English variant neutral? Or not-neutral? Gråbergs Gråa Sång (talk) 08:38, 14 October 2019 (UTC)
            • @Gråbergs Gråa Sång: Any English variant specific to a particular region is by default non-neutral; Oxford spelling (despite what the name suggests) is not really used very much in England (as compared to "standard British" spelling). It's also in terms of spelling features: Oxford spelling prefers -our suffixes, but -ize suffixes, but also -lyse suffixes. Since it has a mix of features from all the major English variants, it's the most neutral, which is why practically every international organization in the world (including the UN) has adopted it. Getsnoopy (talk) 16:03, 14 October 2019 (UTC)
          • How many articles have you created? Believe me, if someone spends a month writing an article after purchasing and studying reference books, it is likely that ill feelings will result from a passerby with no interest in the topic who changes the style because rules. The wasted time comes from arguing about the style changes. Johnuniq (talk) 09:36, 14 October 2019 (UTC)
          • @Getsnoopy: Wikipedians invest a lot of time and effort writing articles. If you change their work into a different spelling than the one they know and use, the expectation is that subsequent edits to that article have to be in the new spelling. Not everyone knows or uses oxford spelling, so such a move will cause ill feelings among editors who are no longer able to maintain articles that they have voluntarily put a lot of time into. This would cause ill feelings, a level of ill feelings that is guaranteed to prevent such a decision getting consensus. If it were implemented it would lose us editors. I left another site in recent years when they decided to standardise on US spelling, I would leave this site if it decided to standardise on a version of English other than the one I use. Alternatively you could end the rule about article consistency, but that would give you a situation where some articles were inconsistent as to spelling within an article. I don't see this site having consensus to go to a system where half of an article might be in one spelling system, and the other newer half in the system preferred by the person who originally wrote the first half. ϢereSpielChequers 09:47, 14 October 2019 (UTC)
            • @WereSpielChequers and Johnuniq: I see, I can understand that. But the problem already exists for strong-ties articles. If I'm an editor using American spelling who spends a month researching and creating an article about an article on a New Zealand topic, for example, then some passerby with no interest in the topic can come in and change the style to New Zealand spelling under current rules. Wouldn't that engender "ill feelings" for the creating editor? Similarly, if a creating editor created an article, and another editor saw that it had some places where there were style errors (no spaces between quantities and their units in measurements, for example), so they went in and edited it, are you saying the the creating editor would "feel bad" about this? It's not a personal attack; we're all trying to improve WP together. And unless we have editors who solely create articles, they will have edited other people's articles as well (which presumably will use spelling other than their own). I don't know that having to use a spelling that they don't use in their daily life "locks them out" of being able to contribute at all; and if it does, then they're not far away from Googling the differences between the two (which they presumably would've done already if they're editing articles other than their own). Being "locked out" of an article and refusing to learn spelling differences (and maybe subsequently quitting an entire platform) seems quite dramatic, and I doubt they'd be able to get far as an editor seeing as they most likely would have encountered a situation where their spelling of choice wasn't used in an article, so they'd be bound by MOS:RETAIN. Getsnoopy (talk) 19:41, 14 October 2019 (UTC)
          • Yeah, and re "We already have many articles which are in violation of MoS, and there are many editors who go in and edit those articles to make them compliant"... well in some of those cases it is the MOS that is wrong not the article. Because whatever people do, that that is the standard -- the de facto standard, and we are not a rulebound entity that favors de jure over de facto.

            There are actually a number of rules that are mostly ignored. Somewhere in the MOS, for instance, there is a prescription against using place of birth/death in the vital-statistics line after a bio name: "John Howard Smith (April 9, 1814, Lincoln, Nebraska – August 13, 1889, New York City)" is not allowed. It's not allowed because somebody came in and added that, and while several people grumbled, nobody WP:BRD'd it (unfortunately). "Birth and death places, if known, should be mentioned in the body of the article, and can appear in the lead if relevant to notability, but not in the opening brackets alongside the birth and death dates." Well that's not just micromanaging pettifoggery, it's anti-function since in short bios (one or two paragraphs) it makes sense to out vital locations in the opening parenthesis, rather than awkwardly shoehorning them into the article text. Again, in this case it was just one person's preference.

            Anyway, do I follow that rule? No, of course not, not when it makes the article worse. What do you take me for? I'm here to write articles (and stuff), not shuffle papers. Herostratus (talk) 16:27, 14 October 2019 (UTC)

            • @Herostratus: Isn't that more of an issue of WP:BRD not being followed properly than it is of MoS being incorrect? I mean if MoS is "incorrect", then it would be changed, and if not, then the article text would be changed. Why have a MoS at all if it wouldn't be followed? Getsnoopy (talk) 19:41, 14 October 2019 (UTC)
              • @Getsnoopy:"if MoS is 'incorrect', then it would be changed"... only in theory. The way it works here actually, it is very hard to change anything. To change the MOS requires basically a supermajority, which is hard to get. I'm sure if I wanted to change or get rid of ""Birth and death places, if known, should [not] be mentioned... in the opening brackets alongside the birth and death dates", I could get let's say 9-6 in favor, so no change. Many people are of the mind "I, personally, don't do this or like to see it, so it should be forbidden" rather than "I, personally, don't do this or like to see it, but that's just my personal aesthetic, and it's not a big deal, so let other editors do it if that's their preference". Because: people. That's how a lot of people roll. It's mediocre IMO, but it is what it is. Consequently we are encrusted with a number of rules, not MOS particularly, which are non-useful and not followed. Herostratus (talk) 07:17, 15 October 2019 (UTC)
              • Because we keep hoping, against all odds, that Wikipedia articles will be written by people who not only know something about the subject matter, but also people who care more about producing a educational article for a reader who actually wants to learn something, than (e.g.,) producing an article that complies with All Teh Rulez.
                And Trovatore was absolutely correct: I wrote that question in the present tense on purpose. I want to see evidence that there is a current-meaning-this-very-month race to create articles just to be able to declare that this or that subject must henceforth be handled in someone's favorite form of English. I very strongly doubt that this is happening, and if it is, I want to hand out Wikipedia:Barnstars to everyone involved. WhatamIdoing (talk) 23:05, 14 October 2019 (UTC)
                • @WhatamIdoing: Oh I didn't mean that there is a race to create articles; that would be great (at least from that particular perspective). I meant that for articles stubs (which, tautologically, have already been written) that haven't quite "formed" their own English variant (bottom-up) or haven't been tagged explicitly with an English variant template (top-down), there's an incentive for editors to go in and add in their favourite English variant template to the article to essentially "lock in" future editors. Insofar as showing that that's happening, I was pointing out those examples. As for whether that's happening currently, I'd have to run a query on the database to be able to tell you, but I wouldn't say it's zero. Getsnoopy (talk) 00:14, 16 October 2019 (UTC)
                  • WP:RETAIN says "When an English variety's consistent usage has been established in an article, maintain it in the absence of consensus to the contrary." A stub doesn't have "consistent usage of a variety", and nothing is "established"; it's mostly a placeholder. It's a misuse of the templates to apply them to stubs.
                    Of course that doesn't mean it never happens. I don't ever recall seeing it happen, but WP is big. But you haven't shown any evidence that it's a current problem at all, and even if it is, the obvious course of action is to address that misuse, not to propose a nuclear change to the treatment of English varieties in the whole encyclopedia. --Trovatore (talk) 02:47, 16 October 2019 (UTC)
                    • @Trovatore: I guess I was using the term "stub" loosely. Yes, if the content is merely a paragraph or so, it would be misuse of the policy. But if the content is long enough, it wouldn't be misuse but would still "fall through the cracks". For example, if an article has been fleshed out to enough length to not qualify as a proper "stub", but only has enough content where it can be determined to be any English, it could be tagged as any variant. But let's say there's enough content to determine that it's some sort of Commonwealth English, but it gets tagged as Canadian English, then it would have to follow down that path for the rest of the life of that article when maybe it was being actually written in British English, for example. Regardless, the point isn't that that's the whole reason I'm proposing this change. The primary reason is consistency; the secondary reason is to ward off any potential "misuse" as you're describing it. And again, it is the farthest from a nuclear change. It's opt-in. If it were to be implemented today, nothing would happen; no one would be in violation of any rule. Only if editors want to make articles consistent would this apply, and it would happen quite slowly. Getsnoopy (talk) 20:02, 17 October 2019 (UTC)
                  • I'd love to see proof that editors are so in love with their national variety of English that they're willing to expand lots of articles for the purpose of "locking in" future editors (at least until the same future editors have a quick chat on the talk page and decide to change it). I don't find the claim particularly credible, but I'd be happy if a love of spelling were actually some editor's primary motivation for building the encyclopedia. WhatamIdoing (talk) 17:10, 16 October 2019 (UTC)
                    • @WhatamIdoing: But that's exactly my point: one needn't expand an article. An editor can just go in an tag an article with a certain variant of English while it's in the "stub" stage, and that's it. The article would have to follow that path of English spelling for the rest of the life of the article. Getsnoopy (talk) 20:02, 17 October 2019 (UTC)
                      • That's not true. Tagging the article "documents" the established standard (or, more precisely, someone's best guess at the established standard). If you wrongly tag an article, then it can simply be removed. And none of this "for the rest of the life of the article" because the relevant rules say that the style can be changed at any time, just be having a quick chat on the talk page. I really begin to think that you don't understand anything about the rule that you're hoping to replace. English varieties are NOT PERMANENT, the template is documentation, not decision, and nobody's doing this anyway. WhatamIdoing (talk) 22:25, 17 October 2019 (UTC)
                        • @WhatamIdoing: No, I understand it just fine. On the contrary, I'm beginning to think you're not understanding my point at all. Yes, the tag documents rather than dictates...in theory. But almost every editor just looks for a tag before editing an article, and proceeds to edit it compliant with said tag. Unless you're telling me every editor reads every article in full, parses it, and comes to a conclusion about which variant it's written in independent of the tag at the top, the tag has power. So when an article is in a stage when it doesn't quite have a specific variant, but has enough length to be considered one of any of the variants, an editor can tag it with a specific variant and send its future editors down that path. I agree that it's not truly "for the rest of the life of the article", but it effectively is, since MOS:RETAIN lists MOS:TIES and "reduced ambiguity" (ironically itself ambiguous) as the only valid reasons to change it. So a "quick chat" on the talk page wouldn't mean much, unless you're saying that the discussion on the talk page trumps the reasons listed in MOS:RETAIN. Getsnoopy (talk) 23:42, 17 October 2019 (UTC)
                          • What's your evidence that "almost every editor" looks at those tags? I'd guess that a majority of editors honestly have no idea what {{EngvarB}} means. Also, they're not used in ~90% of pages anyway. WhatamIdoing (talk) 01:07, 18 October 2019 (UTC)
                            • @WhatamIdoing: Isn't that the expectation? I'm giving people the benefit of the doubt. Getsnoopy (talk) 17:51, 20 October 2019 (UTC)
          • I was recently involved with a copy edit process where the ce initially decided that Britain wouldn't do (needed to be UK and so on) and as well changed EngvarB to Oxford spelling. After I queried the Brit thing, the ce thought that maybe it ought not to have been changed after all and that it could be switched back, haven't decided yet what to do about the Oxford spelling bit because article has "ise"s and "ize"'s both. Not complaining just mention it as indicative. Selfstudier (talk) 17:00, 14 October 2019 (UTC)
  • I wonder if a sizable chunk of the friction over which dialect of English we should standardize on might be avoided if in those cases where someone wants to rewrite an article into another dialect that editor simply asked first. Post the question on the Talk page, wait a month, & if no one objects go ahead & do the rewrite. (Personally, due to my eclectic reading interests, I conclude I write in a mangle of English dialects, so I wouldn't be surprised were I asked if I minded if my article were re-written in American English.) -- llywrch (talk) 20:25, 16 October 2019 (UTC)
    • @Llywrch: Hmm...that is a good point. More of an organic approach, eh? Although one problem I see with this is that MOS:RETAIN says "maintain it in the absence of consensus to the contrary", which I would take to mean that if no one responded to your request, it doesn't count as consensus. Getsnoopy (talk) 20:02, 17 October 2019 (UTC)
      • llywrch, as the guideline has said for several years now, you don't even have to wait for a whole month. Ordinary, everyday, garden-variety consensus from a quick chat on the talk page is all you need to change the variety. WhatamIdoing (talk) 22:25, 17 October 2019 (UTC)
        • Based on how little traffic most talk pages get, unless there is evidence to the contrary I think waiting a month is a good rule of thumb. If one can't be bothered to respond after a month, then it's safe to assume that no one cares much. On the other hand, if an editor can't remember she/he asked about changing the dialect of English for an article after a month, & maybe forgets to go back to that article, then it's safe to assume this isn't an important issue, & maybe should not be done. In any case, asking then waiting to make a change like that -- which is not critical to some of us, but is to others -- this shows a bit of civility, a modicum of respect. Which is not often enough shown enough around here. (And really, do we need a guideline to dictate showing a modicum of respect to each other?) -- llywrch (talk) 22:50, 17 October 2019 (UTC)
          • Based upon Category:Wikipedia behavioral guidelines and Category:Wikipedia conduct policies, we apparently think that we need 12 policies and 20 guidelines to dictate that modicum of respect. ;-) WhatamIdoing (talk) 01:17, 18 October 2019 (UTC)
            • Generally, if someone wants to massively expand an article I might agree to that, but otherwise would be likely to object to any change on principle - the principle being "let sleeping dogs lie". I'm far from being the only editor to feel this way (a decent claim of a "strong connection" would be different). Johnbod (talk) 04:39, 19 October 2019 (UTC)

───────────────────────── Please be aware that Getsnoopy started a similar thread at Template talk:Convert#Spelling and WP:COMMONALITY with no mention of this thread. Looking through his contribution history, I see that he has started similar discussions on multiple pages/templates without referring to any of the others. I find this divide and conquer approach highly suspicious.  Stepho  talk  02:26, 19 October 2019 (UTC)

  • Thanks - but it's more "divide and flop". Time to close this discussion. Johnbod (talk) 04:39, 19 October 2019 (UTC)
  • @Stepho-wrs: How is that relevant? They're completely separate issues. And suspicious of what, exactly? Getsnoopy (talk) 17:43, 20 October 2019 (UTC)
    • Because everything to do with regional differences of spelling is in WP:ENGVAR and hence {{convert}} and many other templates are subservient to ENGVAR. If I was trying to game the system then I would try to convince some major templates to go my way, then use their results to influence the main policy discussion by saying "hey, we're already doing it my way in practice, we may as well make it policy". I would also keep the template discussions strictly separate from each other, not advertising about any other discussions ( hoping that other editors won't see any relevant points in the other discussions) and claiming that there is no relationship between spelling in one template and spelling in another. That way, I could lose the argument in many of them but hopefully win in one of them and claim that one as the path to policy victory. I would also avoid at all costs talking at WT:ENGVAR and WT:SPELLING where knowledgeable editors hang out. So far, you are doing 10 out of 10 on such a plan.  Stepho  talk  18:58, 20 October 2019 (UTC)
      • @Stepho-wrs: While I'm flattered, you're giving me way too much credit than I deserve; you clearly need to get acquainted with Hanlon's razor. This is my first foray into anything related to WP policy, so I looked around and saw that something like an ENGVAR discussion is "evergreen" and bound to get outright rejected, so rather than launching into a proposal, I read that the issue should first be brought up in Village pump (here). And so I did. This issue (proposing allowing articles to be changed to Oxford spelling as an exception to MOS:RETAIN), in my mind, is completely separate from the issue of correctness and commonality that's associated with the SI units. So I proposed that idea on the {{convert}}. If you look at my conversation above with @Master Of Ninja, I was trying to suss out the venues in which to bring up this issue, and he didn't quite know where it was best. Little did I know that I was meant to cross-post or somehow declare all my ongoing proposals throughout WP. I was hoping for this conversation to shake out and consider all the ideas before posting it somewhere as an actual proposal. Your guess of some grand conspiracy, while valiant, is just not true. Getsnoopy (talk) 07:55, 21 October 2019 (UTC)
        • No problem, I can accept ignore instead of malice :)
ENGVAR would have been the proper place because it is the central policy over regional variations in spelling - which is exactly your topic. However, this talk page is also a reasonable place - as long as a notice was left at ENGVAR to say so. Templates such as {{convert}} simply follow ENGVAR, therefore discussions on such templates must wait for the discussion on ENGVAR (or here) to finish before they implement the result.  Stepho  talk  22:24, 21 October 2019 (UTC)

What about Canadian spelling, which is a compromise between Oxford and Webster's? TFD (talk) 19:43, 20 October 2019 (UTC)

  • @The Four Deuces: But Oxford is already a compromise between Webster's and Chamber's (for example). It allows -our and -or suffixes co-equally (though it prefers the former), allows -re and -er suffixes co-equally where it's etymologically accurate (though it prefers the former), prescribes -ize endings where they make sense, prescribes -yse endings, etc. It's the best of all worlds. This is why almost every international organization uses it. Getsnoopy (talk) 07:55, 21 October 2019 (UTC)
    • Even if organisations that employ full time staff and which can afford to train new staff into a corporate standard do this; It isn't a viable route for a volunteer based project that needs to minimise barriers to new volunteers. ϢereSpielChequers 08:07, 21 October 2019 (UTC)
    • @WereSpielChequers: Agreed, which is why I addressed this point up above. I think we've come full circle at this point. Getsnoopy (talk) 04:21, 22 October 2019 (UTC)
  • Is there any move forward either with a firm proposal or closing the thread? I think as has been stated WP:ENGVAR exists for a reason. If a proposal can be written, supported with statements, and then voted on, it would allow things to move on without what seems like endless debate. Master Of Ninja (talk) 09:05, 21 October 2019 (UTC)
    • @Master Of Ninja: Yes, I think we can close this discussion now. I have everything I need to write an actual proposal, which I'll be doing on the talk page of WP:ENGVAR. Getsnoopy (talk) 04:21, 22 October 2019 (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.

An alternative to consensus

It's been about a week and no *ahem* consensus is emerging towards anything that can be actionable. No prejudice against another discussion once something concrete is proposed. – John M Wolfson (talkcontribs) 05:11, 18 October 2019 (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.

An alternative to consensus. Apparently the idea of consensus is taken for granted on WP. Not surprising since the vast majorityof editors and admins come from an academic environment and are accustomed to peer review. (When it comes to peer review I can't help but think of the treatment of the father of plate tectonics aka continental drift, (Alfred Wegener) received at the hands of his peers, Let me commence my dissertation with my opinion about consensus. I realize that WP has been "put together" and the rules written by academicians whose forte is peer review and consensus. That may work well in an area where the subject matter is narrowly defined (e.g. endocrinology), but doesn't work at all in an area open to the general public. The problem with consensus in this environment is that it is too easily weighted by proponents or opponents of a particular subject. As shofly pie attacts flies, so does a pile of dung. People will gravitate towards an article in which they have a particular interest and as a consequence will,if endowed by power, exert control over content in that article. Thus when an editor shows up and posts something that is threatening to the beliefs of the controlling consensus, even though it is well researched and sourced, it tends to be reverted with the most specious of charges, and reversion of the revert leads to edit warring and of course the edit war is bound to be won by the editor who has the longest history on WP and has a long standing relationship with other editors, especially those of a like mind. Not to mention the whole affair is disruptive and leads to anger and bad publicity,which apparently is reflected elsewhere on the internet, such as phorae and blogs,and apparently some erstwhile editors have had their (user) name dragged through the mud on the internet.

Point being is that consensus is not the way to run a multi faceted project. A scientist does not submit an article on endocrinology to a group of psychiatrists, much less a conglomeration of plumbers, cops and beauticians. Also editors should start giving more thought to their edit summaries when they revert.Oldperson (talk) 23:38, 11 October 2019 (UTC)

You're not actually suggesting anything, just complaining in a roundabout way about "losing" something. Ian.thomson (talk) 23:43, 11 October 2019 (UTC)
  • So what's your idea of an alternative? You need consensus to try and ascertain the correct truth. However articles can have sections to account for multiple viewpoints. We have consensus because we really don't have a better way at the moment. Master Of Ninja (talk) 09:11, 12 October 2019 (UTC)
  • Peer review is based on consensus? Please tell that to Reviewer 2.how is that a redlink? – Joe (talk) 09:21, 12 October 2019 (UTC)
  • I think Oldperson has a point, since in practice Consensus is often invoked to trump basic policies like V and NPOV. The Consensus rule assumes that everyone is equally committed to the core policies and will come to a reasonable agreement on what those policies require. But, especially in dispute-prone areas of the project, that is often not how it works at all. That said, I don't see any way to fix this problem. Zerotalk 09:42, 12 October 2019 (UTC)
    Granted, but like all coins that coin has a flip side. If I cite V or NPOV incorrectly and refuse to back down, what is the mechanism for overriding me? Oh yeah...consensus, uninvolved close, and close review, as necessary. ―Mandruss  20:39, 12 October 2019 (UTC)
  • Would it be possible for a revert popup where reverter picks relevant policies being relied on or am I asking for too much there?Selfstudier (talk) 10:38, 12 October 2019 (UTC)


@Oldperson: If I get the drift of your complaint (and it's entirely possible that I don't), it sounds as though you might have found Citizendium more congenial than Wikipedia. But Citizendium is essentially a dead project, whereas Wikipedia is a daily fact of life. Granted, there could be other explanations (network effects and so on), but from the data we have, peer review doesn't seem to have shown itself an effective way to build an online encyclopedia. --Trovatore (talk) 23:39, 12 October 2019 (UTC)
@Trovatore:Thanks, and thanks for the link to Citizendum. Actually mine was not a complaint,but an observation. The biggest problem I have with consensus is that the only people who are attracted to an article are folk who have an emotional, religious, professional, political interest in the subject, and thus consensus weighs in in favor of those who have the most interested editors. Even something as inane (to an uninvolved westerner) as say an African or Indian or Chinese ethnic group, all it takes is one innocent well meaning edit to awaken the hives. But I understand when it is the only tool in the toolbox.Oldperson (talk) 00:20, 13 October 2019 (UTC)
Wellll... yes this can happen. One point is that local consensus can't (or isn't supposed to) override consensus of the larger community. For instance, a group of editors involved in an article can't just decide to ignore WP:RS or WP:NPOV for the purposes of that article. Or any rule which is generally followed by the community at large. For situations like this, WP:RFC can be your friend.
Maybe it's just me, but my experience is that, usually, when a person is significantly outnumbered in a talk discussion, it just means that they're wrong, or at least "wrong" in the sense that other people just honestly don't agree with them, and don't find their arguments convincing. It's happened to me many times certainly: I feel really strongly that I'm right, but the other editors in the discussion are against me 9-2. Drive you nuts, but I'm (almost always) not being tag-teamed or brigaded; people just plain don't agree with me. That's life on the Wikipedia. Herostratus (talk) 02:57, 13 October 2019 (UTC)
A group of editors involved in an article certainly can decide that an editor's citation of RS, NPOV, or any other policy, is without merit or outweighed by other policy arguments. It's easy as hell to raise the NPOV flag in error, either because one doesn't understand NPOV or because they don't agree with it. I know of more than one experienced editor who repeatedly makes false-balance arguments and hangs the NPOV label on them, despite being corrected on that again and again.
The body of our policy is sufficiently rich, vague, nuanced, watered-down, and self-contradictory, that a knowledgeable editor can present a policy argument for A or !A in most situations. And there are not enough highly competent editors willing to spend their time on the difficult, thankless, and often stressful job of uninvolved closes; in most cases we have to assume that a majority of those present won't be wrong on policy. ―Mandruss  03:37, 13 October 2019 (UTC)
BUT....consensus does not overrule NPOV policy: This policy is non-negotiable, and the principles upon which it is based cannot be superseded by other policies or guidelines, nor by editor consensus. Seriously. Atsme Talk 📧 20:04, 17 October 2019 (UTC)
"Consensus does not overrule NPOV policy" is not really a meaningful statement, because the policy can't enforce or apply itself. It takes a consensus of editors to do that, to interpret the policy and decide its consequences for a particular content question. postdlf (talk) 20:18, 17 October 2019 (UTC)
And then again, sometimes the local majority are wrong on policy. It is the system we have, and with all its faults it works a lot of the time. If there is a better way (including in efficiency of time spent), for a largely unidentified/pseudonymous-user crowdsourced project, I would like to know some details. · · · Peter Southwood (talk): 08:28, 15 October 2019 (UTC)
Peter Southwood - There are solutions and politically viable ones. Solutions include:
  1. Take policy out of the hands of the common (wo)man, as that noble experiment has clearly failed. Institute a policy board of highly qualified editors. Their mandate would be to:
    1. Make the body of our policy greatly less rich, vague, nuanced, watered-down, and self-contradictory. Applying it correctly, and recognizing incorrect application of it by others, wouldn't require an IQ north of 110 and three years of heavy editing experience. There would be considerably less disagreement, and we would be less vulnerable to POV pushing via policy abuse.
    2. Prevent a recurrence of the uncontrolled creep that got us to this point.
  2. An army of highly qualified closers.
Politically viable solutions include:
  1. None. ―Mandruss  20:50, 16 October 2019 (UTC)
I doubt that the listed solutions are reasonably practicable, aside from any political objections. I don't think that we can get there from here. Cheers, · · · Peter Southwood (talk): 05:59, 17 October 2019 (UTC)
Consensus has its shortcomings, but I think that some editors here are taking an overly pessimistic view of it. The sheer scope of Wikipedia means that a one-size-fits-all set of rules is going to be impossible to uphold and will definitely get in the way of things in the long run. Also, the fact that most discussions have valid policy-based rationale for A and !A is at least partly because experienced editors (usually) know better than to waste their time arguing A if guidelines and policy say B. signed, Rosguill talk 06:14, 17 October 2019 (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.

Require registration

I believe that at this time and age, Wikipedia should require that all those who wish to edit or add to our project should be registered users. It is easy for an unregistered user to vandalize an article which many of us have gone through a lot of trouble to write, then immediately make a copy as if that is what was truly written, thereby dis-crediting our project and adding to the reality that ours is an unreliable encyclopedia. The fact is that the majority of the vandalism is caused by un-registered users who have nothing better to do with their lives. If Wikipedia wants to keep it's good and honest contributors who love to share their knowledge with the world in general and wants to gain some sense of being a reliable encyclopedia, then it must do something to protect it's contributors and the articles which they have written from the constant vandalism going on, otherwise what's the use of staying here? Tony the Marine (talk) 05:50, 14 October 2019 (UTC)
  • Um, is this a proposal? Jo-Jo Eumerus (talk, contributions) 08:11, 14 October 2019 (UTC)
  • I feel that this is where we're eventually heading. I'm personally neutral on it, although the WMF might block it if passed like they did here and some other times. – John M Wolfson (talkcontribs) 17:52, 14 October 2019 (UTC)
  • Given m:IP Editing: Privacy Enhancement and Abuse Mitigation things might have changed substantially enough to allow another discussion. I support. --Rschen7754 18:16, 14 October 2019 (UTC)
  • Support - It's time to face reality.--WaltCip (talk) 20:18, 14 October 2019 (UTC)
  • Support. Not requiring registered accounts allows people to more easily make pests of themselves. Having said that, I will note that there are other facets to this discussion. One such facet I will call the problem of "regulars". You know—the good ol' boys club. It's one thing to be collegial, it is another thing to be cliquish. Many people vote together. I'm not entirely immune to that. Unregistered accounts do this less. They are not only free of a personal identity but they are less likely to form alliances. No, I have no proof for this. Bus stop (talk) 20:49, 14 October 2019 (UTC)
    Many editors tend to think the same way. That doesn't mean they "vote together", and they would still think the same way if they were unregistered. It would be harder to imagine that they were "voting together", however, since it's harder to remember IP addresses (and IP addresses often change with some frequency anyway). ―Mandruss  04:13, 15 October 2019 (UTC)
    It is definitely much harder to remember IP addresses. And IP addresses change. Ultimately I'm opposed to unregistered accounts. I found myself arguing with someone with an IP address, and an IP address that kept changing just in the span of that argument. That's when I decided that I oppose unregistered accounts. But at other times it has occurred to me that unregistered accounts are like fresh air. They tend to have less history and consequently their perspectives have the potential of being new and unencumbered. Bus stop (talk) 04:43, 15 October 2019 (UTC)
  • I'll give a moral support with mixed feelings because I see many very useful IP edits and lots of us, including me, started editing as IPs and might not have started if registration had been required. What is tipping me to support is the fact that I monitor some error-tracking categories and I usually see 20 or 30 articles per week where an IP with very few other edits has made arbitrary changes to birth dates, or other dates. I only see articles where the IP has accidentally broken the date (recent example) so there are many more changes. Recent changes that trigger the possible birth date change tag are listed here. Johnuniq (talk) 21:11, 14 October 2019 (UTC)
  • Strong support. I won't bother composing the strong case for this. It has already been written numerous times (and probably others could provide one or more links to it). The main question is whether WMF cares about a community consensus on this issue. Userbox. ―Mandruss  21:26, 14 October 2019 (UTC)
  • Strong oppose. Yeah, the proposal linked by Rschen7754 is nonsense but it's not clear to me how forcing registration would solve the issue. More importantly though the support case here is just as evidence-free as all other proposals to restrict editing to registered accounts made so far; besides, so as long as we are attached to Wikimedia we are supposed to Founding principles which do not permit a total ban on IP editing. Jo-Jo Eumerus (talk, contributions) 21:38, 14 October 2019 (UTC)
    These principles may evolve or be refined over time... - It appears that whoever wrote that was wise enough to allow that things might change in ways that justified revision to the founding principles. ―Mandruss  21:44, 14 October 2019 (UTC)
    Maybe, but this wouldn't be the right place to ask. More substantively, given that "leave an open door and deal with problems as they come" philosophy is what allowed Wikipedia to achieve its current status, this does not seem to be a good part to change. Jo-Jo Eumerus (talk, contributions) 21:55, 14 October 2019 (UTC)
    @Jo-Jo Eumerus: Maybe, but this wouldn't be the right place to ask. So you're saying that this is wrong venue and no consensus here can stand even a chance of getting that item removed from the founding principles? Then why haven't you moved to close on procedural grounds? ―Mandruss  22:02, 14 October 2019 (UTC)
    My concern is not mainly the procedural one and arguing procedural points tends to drive discussions off-course. Jo-Jo Eumerus (talk, contributions) 07:14, 15 October 2019 (UTC)
  • Oppose, but would support if this ever came to fruition. -- Rockstonetalk to me! 21:48, 14 October 2019 (UTC)

*Support - This worked back in 2003 when the internet was barely ever used and vandalism wasn't a thing ..... It really is about time the project was made in to a mandatory-registration site. –Davey2010Talk 22:05, 14 October 2019 (UTC)

  • Even more significant, that was when we had just started building the encyclopedia and needed an enormous work force to do it. Sixteen years and 5 million articles later, we can do fairly well without the editors who decline to create a completely anonymous account simply because they have an aversion to registration of any kind (or, dare I say it, because they want to avoid the accountability that comes with a persistent and stable identity). ―Mandruss  22:17, 14 October 2019 (UTC)
    How exactly is a completely anonymous account related to a persistent and stable identity? Looking through my last 100 blocks I see there are more throwaway sockpuppet accounts than IP addresses. Registration is overrated. Just ask the Twitter Bots. -- zzuuzz (talk) 22:44, 14 October 2019 (UTC)
    I think there is a difference in character between the individual who doesn't want accountability and avoids it in a manner fully legitimized by the site, and the individual who is prepared to sock to avoid it. RegReq won't suddenly transform a large number of the former into the latter, in my view. ―Mandruss  23:13, 14 October 2019 (UTC)
    2003 when the internet was barely ever used and vandalism wasn't a thing You and I have very different memories of 2003. ~ Amory (utc) 01:49, 15 October 2019 (UTC)
    • Amorymeltzer - I don't think I started using the internet at home not until something like 2004-2005 so I assumed everyone else was the same lol, Certainly didn't the internet in '03 and certainly didn't know EN existed lol. –Davey2010Talk 14:02, 15 October 2019 (UTC)
  • Oppose as per zzuuzz - Admittedly I have mixed feelings on it however it is indeed true socking is an issue here although not all socks are vandals, Mandatory registration wouldn't stop the vandalism and so in that respect maybe something needs to be done about both not just one or the other ..... or maybe I'm over-thinking this!. –Davey2010Talk 14:09, 15 October 2019 (UTC)
  • Comment/Question about logistics - As said above I'm neutral to this whole thing (but would support if that whole IP-masking shenanigans comes true, though thankfully it doesn't seem to have much traction), but if this does pass and the WMF doesn't block it, would the "Edit" tab for any given article redirect any non-logged in user to Special:CreateAccount with an editnotice about mandatory registration? Would this depend on the level of page protection? Thinking about it some more this would have the positive side effect of reminding users when they are logged out and forget to log (back) in, although that in of itself is not a reason to adopt this proposal. – John M Wolfson (talkcontribs) 22:20, 14 October 2019 (UTC)
  • Oppose. requiring an account to edit. "You can edit now" is a founding principle and the key mechaism for turning readers into editors. However, some of the problems would be ameliorated by auto-welcoming, whether on the first, fourth or tenth edit. Also, to assist registration, given the difficulty of finding a good username, a pronounceable username should be suggested.
Weak oppose unless a way is found to make “edit right now” remain true. Maybe some kind of auto-registration. —SmokeyJoe (talk) 08:47, 15 October 2019 (UTC)
Support requiring an account to create new pages, and requiring an email address to authenticate. Throwaway alternative accounts performing subtle vandalism and promotinal content creation are a far more serious threat to Wikipedia than silly kids making silly test edits. The need for an email address is a small measure to curb mass alt. account creations. A mobile telephone for authentication may be a good idea. Without revealing private information, account creators should be auto prompted to explain multiple accounts linked to the same IP, email address, or telephone number, not for actual scrutny, but to apply discouragement for creating many unlinked account. For people with accessiblity or access problems, there is Wikipedia:Request an account, although that process's 6 month backlog soounds pretty bad. It does however have good suggestions for overcoming most problem.
IPs can still get help to create an article, via Wikipedia:Requested articles, for example. --SmokeyJoe (talk) 22:51, 14 October 2019 (UTC)
    • Stirring stuff, but who is monitoring the many IPs who delight in making arbitrary changes to numbers and dates (see my comment at 21:11, 14 October 2019)? Inserted junk can be handled months after the event because it's easily recognized but I suspect that articles are being eroded in a way that will not realistically be cleaned up. You are right that anyone can edit was a founding principle, but its time has passed. Johnuniq (talk) 23:09, 14 October 2019 (UTC)
      • I don't disagree with your "moral support" for requiring registration for editing. If that were to happen, I think registration should be made much easier. If IP vandalism is both serious and takes months to repair, that would mean that the active editor count per article has fallen below a threshold, and it marks the senescence of Wikipedia as we new it. I suspect that this is the case. I think the answer is to decease the ease with which new people can create new pages, but to not decrease the ease with which readers can fix things immediately. --SmokeyJoe (talk) 00:29, 15 October 2019 (UTC)
If the active editor count per article has fallen and Wikipedia is truly past its peak in terms of membership, then you can't assume that the ease in which IP vandalism occurs wasn't a contributing factor. I spend more time repairing than I do contributing (way more), and it's discouraging. It wasn't always like that, especially early on after I first joined. It just so happens that the editors who used to watch the articles I'm interested in and fight vandalism are no longer around; they've given up and left. So I've found myself assuming that role more and more over time. Allowing IP drive-by disruption to remain uninhibited could actually encourage the downward trend, if in fact we're in the middle of one. Just shedding some light here that the trend may actually be the result of the problem (i.e. increasing IP vandalism) as opposed to being a reason we cite in favor of allowing it to continue. --GoneIn60 (talk) 03:46, 15 October 2019 (UTC)
  • Strong oppose: I had a lot more typed up, but I'll be concise: I don't believe we ought to betray our principles so rashly. I don't like IP spam and all that stuff either, but this is not the way to do it (and neither is the WMF's debacle-in-the-making). I don't have any alternatives, but I do know that this isn't the way. (As an addendum, should the WMF proposal go through, I may reconsider this vote). Javert2113 (Siarad.|¤) 23:59, 14 October 2019 (UTC)
  • Strong mixed feelings. I can see the thinking here, and have often thought the same. I also know that there are IP addys out there still contributing good material to the project. (also that Jimbo prefers IPs be allowed to edit - or at least he used to, but Larry Sanger preferred registration, .. but see how poorly that worked). I'll think on this, and if I end up feeling more strongly one way than the other, I'll revisit ..... maybe. — Ched (talk) 01:11, 15 October 2019 (UTC)
    there are IP addys out there still contributing good material to the project. Absolutely, but we should not assume that we will lose them if we require registration. It's quite possible that their position is "I don't want to register if I don't have to." And, remember, they are likely just as addicted as we are. ―Mandruss  01:21, 15 October 2019 (UTC)
And here [4] is an edit by an IP that is totally unproductive. Only too common in my experience. Xxanthippe (talk) 01:36, 15 October 2019 (UTC).
  • Just like we shouldn't assume they'll stay, trying to guess their position is laughable. Addicted? You probably aren't familiar with my editing history. — Ched (talk) 17:13, 15 October 2019 (UTC)
I'm not sure what that is supposed to show; that an IP was unproductive? I can find registered users who cause more trouble than that. — Ched (talk) 17:13, 15 October 2019 (UTC)
  • Support – (1) Registration doesn't stop anybody from using any other website. (2) Editing an article really isn't something you do in five second on a whim. If you do that, you usually screw it up. It kind of requires a commitment to be a productive editor. You have to at least review the article history and talk page before making any but the most trivial edits. The work that goes into editing is so much harder than registering an account, I just can't imagine how the latter would stop anyone from the former. (3) IP editors have a hard time integrating into the community, in no small part because it's impossible to remember which IP is who. On a collaborative project, that is a real barrier to success and productivity–can't work with someone if you don't remember their name because it's a string of numbers. (4) We sink a lot of time in dealing with IP vandalism. This will reduce that, freeing up editor time. (5) Email registration is probably a good idea, too, to prevent mass account creations. Levivich 02:59, 15 October 2019 (UTC)
    Some good points, and add the difficulty of communicating with an editor who can't receive pings and whose user talk page is often a short-term affair. By the time I get to their talk page, it's no longer their talk page. This, in an environment where editor communication is crucial. I once spent a good six total hours of my time over a number of days trying to chase one of these guys down, and finally gave up in frustration. It's absolutely crazy that we some of us find ways to justify things like that. ―Mandruss  03:13, 15 October 2019 (UTC)
    And what makes you think a freshly-registered user will want to stay, or even communicate? We get reports of uncommunicative users all the time at AN/I, and it can't be attributed to a language barrier. Not to mention seeing your first edit reverted out of hand shortly after it is made is a good enough reason to never want to log in again. —v^_^v Make your position clear! 23:59, 15 October 2019 (UTC)
  • Oppose An evergreen proposal, and not one I think that will improve the project. There's lots of good IP editors - the vast majority, in fact. SportingFlyer T·C 03:20, 15 October 2019 (UTC)
  • Oppose there are countless areas of the encyclopedia where this would have an overwhelmingly negative impact. Sports probably stand out as the biggest (score), but also copy editing, general fixes, and overall maintenance. There's also the huge recruitment aspect: most people who become active editors first edited as an IP. Get rid of that, you get rid of the gateway to editing as a whole, and we actually start losing numbers. TonyBallioni (talk) 03:23, 15 October 2019 (UTC)
    most people who become active editors first edited as an IP. Please show evidence that they wouldn't have registered immediately if that had been required.
    Ok, I'm weary of debunking obvious reasoning errors, so I'll cease bludgeoning this discussion. Good luck all. ―Mandruss  03:28, 15 October 2019 (UTC)
    OTOH there is no evidence that IP vandals wouldn't register immediately if that was what was required. Galobtter (pingó mió) 03:31, 15 October 2019 (UTC)
    Has someone cited vandalism reduction in a Support argument? I haven't. ―Mandruss  03:34, 15 October 2019 (UTC)
  • I don't know what the impact would be on editor recruitment (probably negative) but TBH I could very well see this make it harder to fight vandalism. Vandals can easily create an account, and it would be certainly much harder to do {{schoolblock}}s (and school vandals represent a fairly large portion of all vandalism) when only CU's can track IP edits. Galobtter (pingó mió) 03:31, 15 October 2019 (UTC)
  • Comment – I share similar concerns with other editors that required registration for all editing activity may not be the best solution for a host of reasons. However, there's a lot of middle ground between outright registration and open IP editing, and I suspect technical limitations have prevented good proposals from ever coming to fruition. Examples of alternative proposals (technical limitations aside):
    • Allow IP editing to continue as it does today, except on articles that have reached GA or FA status. Gives active editors incentive to stick around and promote articles.
    • Don't require registration for the first several articles (say 5) from any given IP. This allows immediate contribution, but discourages disruptive editing in one pass across dozens of articles. The number can reset every 30 days or some other specified timeout period.
    • Require random email verification from IPs. This means for the most part, they still have the ability to edit at will. However, on occasion (every 5-10 edits for example), it will prompt them to verify an email address. This will encourage them to register over time, especially if making good edits. IPs flagged as disruptive will have to constantly register new email addresses to continue their disruption. This happens transparently in the background without admin/human intervention.
    • IPs can create new articles and actively contribute to articles that are fairly new (say less than 2 years in age). This allows the rapid formation of new content, but discourages vandalism years later after an article has undergone significant changes.
    • Some combination of the above
Again, there are undoubtedly some technical limitations (unknown to me) which would prevent proposals like this from ever seeing the light of day, but I suspect the only possible compromise depends on an alternative solution that doesn't beat a tack with a sledgehammer. --GoneIn60 (talk) 04:30, 15 October 2019 (UTC)
  • I wrote this almost twelve years ago, and about 90% of it's still relevant to this discussion. —Cryptic 05:41, 15 October 2019 (UTC)
  • Insufficient data to make a rational statistics based decision. As far as I know, there is no convincing evidence that the current positive effects of IP editing exceed the negative effects or vice versa, and I see no easy way of measuring it. Those who struggle against the damage are likely to focus on the negative effects, those who don't are less likely to do so. I for one do not consider it a worthwhile use of my time and skills to concentrate on policing bad actors, but I also yearn for more collaboration and constructive input from a wider range of contributors with some clue and competence. I do not think that the status quo is tenable over the long term. An interesting experiment would be for WMF to clone Wikipedia, and make one clone for only registered editors, and the other for status quo. See which one thrives and which fails. They could be re-merged later after the effects are known. I know which one I would edit and use, but I don't know if it would be the one to thrive or fail. Editors would tend to migrate to whichever version they found most satisfying to work on. · · · Peter Southwood (talk): 07:11, 15 October 2019 (UTC)
    • PS: In the topics that I edit most, my impression is that very little value is added by IP editors, but not very much harm is done either, and what harm there is is mostly fixed quite quickly, by registered editors. My assessment of net value of IP edits in these topics is negative. This trend may vary enormously, I just don't know. IP requests and comments on talk pages appear to be more often of some value, possibly because the IP editor that engages in dialogue is more clueful and serious than one who does not. · · · Peter Southwood (talk): 07:30, 15 October 2019 (UTC)
      • PPS: I would Support a trial of obligatory registration, either for the whole Wikipedia, or for parts thereof, where the parts could be opt-in by WikiProject, opt-out by WikiProject, or randomly selected. Run on a similar basis to WP:ACTRIAL. · · · Peter Southwood (talk): 07:37, 15 October 2019 (UTC)
  • Oppose pending IP Masking result - I would probably agree with this if IP masking was bought in with high-level limitations on sight. It definitely looks like it's coming, but NKohli does seem willing to engage, so actual implementation is a bit up in the air. In any case, I don't see a need to jump the gun. IPs are a net positive once you've factored in the ability to create registered accounts so easily. After that discussion, this will need a properly thought out RfC. Nosebagbear (talk) 08:49, 15 October 2019 (UTC)
  • Support. I initially wanted to oppose based on the fact that on-the-spot editing is a founding principle (as at least one other editor stated). But with the growing number of visitors, and diminishing number of dedicated patrollers (at least per article), open IP editing poses a quality risk to the project. Considering accounts can also be instantly created, even without email verification, or having an email address altogether, making registration mandatory is still quite open in honest opinion. As Pbsouthwood stated, a trial would be a good first step. Rehman 09:01, 15 October 2019 (UTC)
  • Nag Encourage registration with something like "edits will be restricted as to number/size/scope until registered".Selfstudier (talk) 09:05, 15 October 2019 (UTC)
  • Support - absolutely. GoodDay (talk) 09:11, 15 October 2019 (UTC)
  • If we're really going to be talking about this, then I do indeed oppose it. There's been no evidence proffered to justify such a completely radical proposal, nor any evidence supporting the claims made in the proposal. Vandalism is a fact, and requiring accounts might limit it a bit, doing so won't remove the issue. Especially when a news story breaks, anonymous editors are the lifeblood of content creation; TonyB points out other areas of advantage. As enWiki has grown, we have relatively fewer active editors, and we do not need to encourage but rather than reverse that trend. This would certainly be tossing the baby with the bathwater. ~ Amory (utc) 09:56, 15 October 2019 (UTC)
  • Suggestion. It does not have to be all or nothing. A partial trial of non-IP editing could be introduced by allowing semi-confirmed (or whatever) users to apply WP:Semiprotection to articles that they judged needed it without having to go through the rigmarole of applying to administrators. The semi-protection could be removed by administrators on application as it is now. It could then be assessed if the trial improved or degraded the editing of affected articles. Xxanthippe (talk) 10:13, 15 October 2019 (UTC).
  • Right for the wrong reasons I disagree with OP's rationale (assigning the majority of vandalism to IPs, equating vandalism with discrediting an article), but I agree with the proposal. Registration is quick and easy, and if we make it mandatory and someone can't or won't take the five minutes to make an account, I have to wonder how they survive the rest of the Internet where registration is already required. creffpublic a creffett franchise (talk to the boss) 12:52, 15 October 2019 (UTC)
  • More thoughts on logistics If we are going to have a trial of this on only part of Wikipedia (say, FAs and GAs), we'll need a new form of protection that's not outright semi-protection (which restricts editing to autoconfirmed users). Also, concerns of vandals creating accounts, while valid, can be partially assuaged by (still?) allowing administrators to have a sort of account-creation autoblock; this would not to the best of my knowledge require the knowledge of the specific IP address entailed and thereby CU, although it might significantly increase unblock request backlogs. – John M Wolfson (talkcontribs) 14:04, 15 October 2019 (UTC)
  • It's complicated. I would absolutely support this if IP Masking is shoved down our throats. As it is, requiring accounts might make it harder for non-checkusers to identify peristent vandalism, as it's easier in many ways to create sock accounts than to change your IP address (especially if you want to change your IP to avoid a rangeblock). While I might support only allowing IP editors to edit in a "Pending Changes" mode, I wouldn't support an outright stop to IP contributions at this time. --Ahecht (TALK
    PAGE
    ) 14:43, 15 October 2019 (UTC)
  • Support. Yes, it's perennial, but I've always supported it. Most vandalism I see is from IP editors, and, to be brutally honest, the majority of edits I see from IP editors are either outright vandalism or so poor as to be worthless. Both require immediate reversion. -- Necrothesp (talk) 14:51, 15 October 2019 (UTC)
  • Actually I see loads of minor or sometimes valuable corrections or adjustments, & would not want to lose the ability of drive-by people to do this. Only ready to support limiting ips to a set number of edits - say 20, perhaps per year. I might also support maximum numbers of characters added or removed. Of course this would only hamper some ips and not others. I'm happy not to go on tolerating ips who edit very heavily over a long period - most are no doubt returning banned users or sock-puppets. Johnbod (talk) 15:11, 15 October 2019 (UTC)
  • No thanks. There is less of a case for this than there used to be as the edit filters revert much vandalism without needing human involvement. We still need IP editing as an entry point into editing, and i doubt that anyone disputes that. The real question is whether the registration process would lose us more goodfaith editors than badfaith ones. I'm in the camp that considers that vandals mostly do the minimum necessary to do their vandalism, so allowing IP editing, like allowing blank edit summaries, makes vandals easier to spot, but not more numerous. If that theory is correct, then mandatory registration would lose us more new good editors than bad as well as making vandals a tiny bit harder to spot. It would be interesting to see some academic research on these very different views of the benefits of compulsory registration, but Citizendium and WikiTribune are enough evidence for me. Of course we could go the whole hog and require registration via facebook et al. That likely would deter many vandals, but it isn't exactly compatible with our open source ethos. ϢereSpielChequers 15:29, 15 October 2019 (UTC)
  • Oppose Largely per WereSpielChequers and Davey2010. I am not sure it would have the intended effect and there is certainly a chance of doing more harm than good. Many good users started life here as IP editors and the fact that many IP edits are not that great only means they need help and guidance. PackMecEng (talk) 15:42, 15 October 2019 (UTC)
  • One part of me wants to ban IP editing, but it's really kind of pointless. Making an account is free and easy, and we don't limit how many accounts a user can (as opposed to, may) have. So people just make throw-away accounts and that's really no different than editing as an IP. Yes, we say you can't be a sock, but we do very little to prevent it. So which would you rather have; anonymous vandals using IPs, or anonymous vandals using throw-away accounts? -- RoySmith (talk) 15:52, 15 October 2019 (UTC)
  • Neutral. Based on my observations over the years, I have the feeling this won't help with the problem of vandalism, just change it. But it will force the WMF to consider which should be given priority: keeping Wikipedia open to anyone to edit (over the quality of content), or improving the content of Wikipedia (over allowing everyone to edit it). -- llywrch (talk) 16:20, 15 October 2019 (UTC)
  • Oppose, this would not substantively help with vandalism and would only provide another access barrier to editing. Basically in agreement with WereSpielChequers's comment/observations above. postdlf (talk) 16:27, 15 October 2019 (UTC)
Although I'm not in support of outright registration, I think it's naive to assume making it harder to vandalize wouldn't have a noticeable impact. Would it solve the problem and stop everyone? Of course not. Would it curb the behavior for some over time, given the increased effort and nuisance it would create for them? It's a reasonable possibility. Right now, they just have to change IPs or IP ranges. Imagine the nuisance of having to create a new account and verify email every single time on top of that. --GoneIn60 (talk) 17:18, 15 October 2019 (UTC)
  • Strong oppose There are probably a limited number of times where the weight of anonymous IP editors overwhelmed all admin capabilities and reasonable protection routes. The day to day IP stuff that causes problems is out-balanced by the number of IP that actually make useful contributions. --Masem (t) 17:23, 15 October 2019 (UTC)
  • Support in principle, as IP editing has several practical drawbacks. But the lack of actual and meaningful data about this aspect is a valid concern. A trial (either for a strictly limited time or in a limited area of articles) could help to gather more substantial evidence and analyze possible effects on the community. GermanJoe (talk) 17:29, 15 October 2019 (UTC)
  • Oppose I don't think I can add much to a discussion that has already been had many times over the years. I believe WP:HUMAN and WP:WNCAA already cover a lot of my thoughts on this matter, there's even an association of us that remain unregistered on principle, see here. Many editors are not attracted to the social side of Wikipedia which account creation invariably snares them deeper into they just want to go about their business and be left alone. In addition, this will prevent many useful and constructive editors from participating, remember 80%+ of IP edits are constructive. Far from being a horde of spammers, vandals, and trolls new and anonymous users built most of Wikipedia's content, see here. I've done WP:RCP, the problems caused by WP:VOAs are equivalent to those caused by IPs and when subtle often take longer to get noticed. Finally, compare Wikipedia to Citizendium and tell me if that's really the direction we want to go in. I have my issues WMFs idea as well, but this is not the solution. 71.62.176.24 (talk) 18:22, 15 October 2019 (UTC)
        • I absolutely don't support long-term frequent ip editing. There's no way having an account "snares people deeper into the social side of Wikipedia" if they don't want it to - this is just nonsense. Thousands of registered users just ignore any messages - User talk:DilletantiAnonymous is a shining example for you, with 246K bytes, not one by him. As an ip you are exposing a remarkable amount of personal information to anyone on the internet who cares to check it. Numbers are hard to remember for other editors & registered editors will rightly remain suspicious of those who choose not to register. Some may be harmless, but very many are not. Johnbod (talk) 04:17, 17 October 2019 (UTC)
    • Oppose, as per above, and other's arguments. (Consider my opinion changed) --MoonyTheDwarf (Braden N.) (talk) 18:53, 15 October 2019 (UTC)
  • Oppose. Equating IPs with vandals is insulting, considering that the vandal edits from IPs are a minority of all IP edits made. This is also not a fight we should be having right now in the first place considering Framgate. Also, requiring registration would more like than not discourage actual good-faith editors while doing nothing whatsoever to thwart vandalism, especially since we already get a lot of accounts that register just to vandalise/have a laugh at our expense, and that is before autocon/EC-buster socks. —v^_^v Make your position clear! 21:06, 15 October 2019 (UTC)
  • Oppose. A large number of our good edits are from IPs. I have a large watchlist, and... I dunno, easily 10% of the good edits are from IPs. So for a start you're throwing those away right off, most of them.
Then, you have that X% of registered editors first dip their toes in as IPs. What X% is I don't know? 50%? More? Less? Whatever it is, you're throwing some of those future editors away. Registering an account takes a certain amount of emotional commitment to editing, a commitment we would be asking for in advance of a sample of the experience. (It does, and arguments of "no it doesn't" or "it didn't for me" doesn't change that: it does.) I never register at websites for features I don't either plan to use a lot, or have come to use a lot, even tho I have a throwaway email account. I just don't. Lot of people don't, probably.
As to the proximate reason for this proposal, "It is easy for an unregistered user to vandalize an article which many of us have gone through a lot of trouble to write, then immediately make a copy as if that is what was truly written"... is that an actual real problem? I have not heard this. Also, if someone is trying to be be like "See, even this Wikipedia articles says that Trump is a space alien", the fact that she's pointing to a copy on her own web site kind of takes away most of the value there. Plus if you're committed to this level of trollery, I image you'll just register an account.
Project is not broken AFAK. If IP vandalism is spiking, I haven't seen evidence on my watchlist. If something is not broken, trying to fix it might break it. Herostratus (talk) 21:33, 15 October 2019 (UTC)
  • Vandalism is easily dealt with and might even be a positive because it gives people something to do as reverting vandalism is useful and easy. What is becoming untenable is the large number of arbitrary changes to numbers and dates and other factoids. Unfortunately that's anecdotal with no hard information available. However, see the example I posted above, and see these and these edits (reported at ANI). There is no way to evaluate arbitrary changes by a shifting IP other than to spend a couple of hours investigating the sources for each number. Johnuniq (talk) 23:03, 15 October 2019 (UTC)
  • Edits by a registered user can be evaluated. If someone registers and does nothing but make arbitrary number/date changes, they are automatically suspect. I would politely ask them on their talk page what the reasons for the changes were. If no response and the changes continue, the editor will end up indeffed and their changes rolled back without fuss. It is much harder doing that with an IP as they usually ignore their talk pages due to disinterest, or shifting IP. IPs are also used to templated waffle on their talk and I suspect that many of them ignore it for that reason. An IP cannot be indeffed, and getting even a month-long block on an IP is not easy due to Wikipedia's folklore from the early days about AGF: a new and brilliant editor might want to use that IP tomorrow. Johnuniq (talk) 02:27, 16 October 2019 (UTC)
  • To your point, nothing would. However, requiring new registration coupled with email verification would discourage a lot of them from staying active over time. Being disruptive becomes a product of diminishing returns; the effort required begins to outweigh the satisfaction. The proposal here isn't the right way to do it though. We need an automated system in place or a tool for non-admins that allows more pressure to be applied to offending IPs, while at the same time preserving unhindered access for the vast majority of other IPs. There are better options we're not discussing. --GoneIn60 (talk) 02:35, 16 October 2019 (UTC)
  • "what would stop a registered user from doing exactly the same" There is a psychological element. An identity is something to protect. We care about our reputations. Simply making someone create a user-name causes them to think about what user-name to choose. Right there, in the making up of a user-name, one is becoming responsible for something. Many of us have the experience of regretting our choice of user-name or at least considering preferable alternatives. Bus stop (talk) 04:34, 16 October 2019 (UTC)
  • Yet we get users who register an account just to commit vandalism all the time. "Protecting" an identity is meaningless if the identity is throwaway in the first place. —v^_^v Make your position clear! 20:49, 16 October 2019 (UTC)
  • Vandalism is easily dealt with and might even be a positive because it gives people something to do as reverting vandalism is useful and easy. Please read the rest of my comment where I replied to you above because it contains substantive points that you have not acknowledged let alone responded to. Johnuniq (talk) 23:18, 16 October 2019 (UTC)
  • might even be a positive because it gives people something to do as reverting vandalism is useful and easy. - PRICELESS! ―Mandruss  23:34, 16 October 2019 (UTC)
  • Reverting obvious vandalism is easy. Reverting subtle vandalism is not - it is quite possible that a lot of it remains unreverted, particularly if done by registered editors. Reverting vandalism and investigating possible vandalism are not particularly productive uses of time in comparison with actually building an encyclopedia. Reverting vandalism may have the theoretical upside of drawing one's attention to other aspects of an article that could use a bit of improvement, but only if they result in that improvement actually happening. Vandalism is a huge timesink, but it kind of goes with the territory. It is part of the natural environment of an open Wiki, a form of parasitism. We adapt or die. Look at filters, they are an adaptation that has served us well. What would happen if they had not been developed? We need better defenses. Sometimes we get them. · · · Peter Southwood (talk): 06:37, 17 October 2019 (UTC)
  • Oppose. Most of us started out making an edit or two before registering, and most of us would find it easy to create a new account if we wanted to foment mischief. It's ultimately none of my business why someone would want to reveal their location and in many cases more by not cloaking themselves in a user name, and banning it would be one more barrier to joining the editing community, one more discouragement, when we want to draw people in and always will (no, the encyclopedia is not "nearly finished", and yes, we need fresh eyes and hands if only to replace those we inevitably lose every year, if not to provide fresh perspectives and new skills) and requiring registration will do nothing to hinder vandalism. If anything it will make some kinds of vandals, such as schoolkids, harder to detect. Yngvadottir (talk) 05:12, 16 October 2019 (UTC)
  • Oppose Despite Mandruss's unsupported assertion that there is "a community consensus on this issue.", there is not. For example, in the current discussion my vote will make this a 12-15 in favor of the opposition, not counting split votes or nuanced answers or the like. I don't see how that represents a "consensus" to require registration. Nor am I aware of any of the past discussions on this exact issue which had such a consensus. Normal operation of Wikipedia should have zero barrier to entry, even creating a free account presents an unneeded and burdensome barrier to entry which will ultimately drive away good-faith users more than it would drive away bad-faith vandals. --Jayron32 15:51, 16 October 2019 (UTC)
    @Jayron32: Would have appreciated a ping. I've given up on this discussion as hopeless, so haven't been following it, and only happened to notice your comment by freak accident.
    The lack of consensus you correctly refer to did not exist at the time of my early comment, so I think "unsupported assertion" is more than a bit inappropriate. I didn't say there was a consensus, I allowed that there was a potential for one at that time. ―Mandruss  22:25, 16 October 2019 (UTC)
  • Just noting that I would support if this proposal had a chance of passing. Regardless of whether most IP edits are constructive, it's still a fact that the vast majority of vandalism comes from IPs, as seen by this graph if we are to trust it. They also add to the unconstructive pile we already have to deal with regarding registered editors. It's not offensive to acknowledge facts. Been here since 2007, and I've seen, especially when patrolling with WP:STiki or WP:Huggle, that most of the vandalism comes from IPs. Requiring registration would cut down both on vandalism and socking. And Wikipedia requiring registration isn't the same as what happened to Citizendium. Citizendium wanted more than just registration. And other sites that have tried to be like Wikipedia aren't as successful anyway. Wikipedia was first and had already attained a level of popularity that Citizendium had to compete with. Flyer22 Reborn (talk) 00:58, 17 October 2019 (UTC) Updated post. Flyer22 Reborn (talk) 01:07, 17 October 2019 (UTC)
    • That graph is based on 248 edits that happened 12 years ago. Even if it happened to be a representative sample, back then, I think things might have changed in the meantime. WhatamIdoing (talk) 19:51, 21 October 2019 (UTC)
  • Facts not in evidence. IPs are WP's main problem? We'd be better off without them, because they do so much more harm than good, even considering many contributing editors started as IPs? Exactly what problem is this drastic change supposed to solve, and how is this the only way to solve it? This change is supposed to have no negative consequences whatsoever, and we know this how? Well, I think WP's main problem is editors that joined after 2010; we should get rid of all of them. This new proposal of mine is as rational and justified as the one proposed here. --A D Monroe III(talk) 01:25, 17 October 2019 (UTC)
    Please help us with gathering the required evidence. What is the methodology for determining how many IP editors would register if it were required? Once we have that, how do we compensate for IP editors who are less than forthcoming in their responses – those who say they wouldn't because they don't want to, but actually would if it came to that? Do we pretend those editors don't exist in significant numbers? And so on. Explain these things to me and I'll get right on it.
    There is such a thing as unreasonable burden of proof. Akin to moving the goalposts, it's placing them a mile away from the kicker from the outset. ―Mandruss  02:09, 17 October 2019 (UTC)
    You've made the assertion that IP edits are a problem that needs fixing, and that Wikipedia is better off if we just got rid of them. It isn't really incumbent upon others to provide evidence that you're wrong. Null hypothesis requires that the burden is always on the person making the positive assertion to provide evidence to support it. Demanding that every assertion one makes must be accepted as true without proof otherwise is strange. Asking for simple evidence that requiring registration is necessary is not an unreasonable standard. You've (in the collective) asserted Wikipedia needs to do this. Why? --Jayron32 12:41, 17 October 2019 (UTC)
    Inertia lives in demands that proponents of change prove the unprovable. It makes it virtually impossible to respond to change, in this case that change being 18 years and 5 million articles. If you dispute my assertion that proponents' arguments are unprovable, I've asked for some explanation of how to prove them – an eminently fair request – and I have not seen that. As I said, unreasonable burden of proof. Absent debate judges, you and others making that unreasonable demand will prevail here, being enough to prevent a consensus for change, but I'm not going away without calling you out for unfair argument. ―Mandruss  06:13, 18 October 2019 (UTC)
    You've not even established that we need anything to change. You've said we do, without providing any evidence that we do. And then said that anyone who asks for a reason why is making unreasonable demands. I still don't see why you can just demand a major change to the way Wikipedia operates, and provide no evidence why we need to. --Jayron32 14:10, 21 October 2019 (UTC)
    We have provided reasoning why we need to – reasoning based in knowledge of the world, human nature, logic, etc. That's the best we can be expected to do. I've no beef with countering reasoning – that's what fair discussion is – but I don't like my arguments rejected out of hand because they lack proof of the unprovable. ―Mandruss  22:43, 21 October 2019 (UTC)
Here's an idea. Why not have software supply would-be unregistered users with accounts, including computer-generated user-names? In other words—you would have no choice. If you want to abandon that assigned account, you are free to do so. But there should be some type of a small penalty to disincentivize abandoning assigned accounts, such as a 24 or 48 hour waiting time to get a new assigned account at that IP address. The advantage to this is that the computer-generated user-names would be much more memorable than the string of numbers of an IP address. Bus stop (talk) 00:36, 18 October 2019 (UTC)
  • Oppose per every other time this has been proposed. Sam Walton (talk) 08:19, 17 October 2019 (UTC)
  • Strong oppose as requesting my account took a few weeks, and people who just want to fix on typo or similar, aren't going to go through the hassle of requesting. this will only gate-keep the editing of Wikipedia, which goes completely contrary to the goals of Wikipedia. ArkayusMako (talk) 12:09, 17 October 2019 (UTC)
I'm not arguing one way or the other for the "registration", just responding to the above. @ArkayusMako:, I have no idea why it would take a couple weeks, it's usually pretty instantaneous. Glitch on our side, your ISP, some point in between? IDK. But sorry about that.— Ched (talk) 12:30, 17 October 2019 (UTC)
  • Strong oppose - I have seen many useful edits by IP users. Especially small fixes and updates. I did a few of those myself before creating an account. And if I ever stop using a registered account, then I will continue to make some of those edits as an IP user as well. I also see many good reasons why people would want to avoid being part of the Wikipedia community. It is rather toxic at times. --Hecato (talk) 14:38, 17 October 2019 (UTC)
  • Oppose – Fighting vandalism is a huge time sink here, but it won't necessarily be stopped by registration, which may leave us with the inveterate, belligerent vandals, while keeping useful editors out. I'm seeing a lot of helpful edits from IPs on my watchlist, and my sense is that vandalism has gone down since I became active in 2013. Dhtwiki (talk) 19:39, 17 October 2019 (UTC)
  • Strong support - IP vandals are a major time sink, they chip away at the credibility of the pedia, and I see no feasible way the good aspects of not registering possibly outweigh the bad. Atsme Talk 📧 20:13, 17 October 2019 (UTC)
  • Support - I have always thought that allowing unregistered editors to edit in article space was an original mistake, but because it was an original mistake, it might not be corrected. Now that WMF is prepared to go to bizarre lengths to protect unregistered editors from themselves, in a way that will probably interfere with the prevention of vandalism, we should recognize that the easier way to protect unregistered editors from giving away their IP addresses is to require that they register pseudonymously (or with names), and we have always had pseudonymous registration. Perhaps the WMF has considered the risk that unregistered editors are facing with regard to privacy and not the counter-balancing consideration of the integrity of the encyclopedia. If the WMF really really wants to allow unregistered editors with masking, it could restrict their editing to talk pages, but that would sort of be the worst of both worlds. Just tell them to register. Robert McClenon (talk) 16:59, 20 October 2019 (UTC)
  • Strong oppose because IP editing is a core principle of Wikipedia and must continue to be. Also, in my experience, the IP vandals I have dealt with are usually very minor nuances, whereas the vandals who take the time to actually register are the ones who waste a significant amount of our time, and this proposal will do nothing to solve that issue. --Secundus Zephyrus (talk) 15:33, 23 October 2019 (UTC)

Require pending changes protection

it is clear that this proposal stands no chance of being enacted, as it runs counter to the fundamental mission of Wikipedia at the most basic level. Universal or broad-based forms of protection are basically always shot down per WP:PEREN, while this variation is novel, the litmus test for potential success as a proposal should be is the protection applied to individual articles on a case-by-case basis. As soon as protection in any form applies to "all articles", it isn't going to happen. Leaving this open any longer isn't likely to result in a change in this attitude across Wikipedia, as should be clear from the pile-on opposes that have rapidly come up. --Jayron32 15:43, 16 October 2019 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should there be a new non-flagged pending changes protection for all pages? QuackGuru (talk) 21:02, 15 October 2019 (UTC)

A non-flagged pending changes protection means any editor with more than 500 edits can approve an edit. This is a good compromise. QuackGuru (talk) 21:47, 15 October 2019 (UTC)

I recommend WP:PCPP for all pages. Only approved edits will pass, while still allowing IPs and new accounts to edit pages. People are spending hours each day reverting vandals. This change will cut back on vandalism while freeing up more time to improve articles and pages. QuackGuru (talk) 21:02, 15 October 2019 (UTC)
  • Support as proposer. See the edit history of this article. Pending changes protection is working like a well-oiled machine. QuackGuru (talk) 21:11, 15 October 2019 (UTC)
  • No. If you want this and the consequential eternal backlogs that come with it, learn German.v^_^v Make your position clear! 21:19, 15 October 2019 (UTC)
  • Support as worth a try. Xxanthippe (talk) 21:26, 15 October 2019 (UTC).
    • I feel I need to point out that what is being proposed here is FlaggedRevisions being deployed here on en.wp. Pending Changes is a very deliberately neutered version of it that we only got because we as a community objected to it. —v^_^v Make your position clear! 21:29, 15 October 2019 (UTC)
      • I have updated the proposal for a new non-flagged pending changes protection. A non-flagged pending changes protection means any editor with more than 500 edits can approve an edit. QuackGuru (talk) 21:36, 15 October 2019 (UTC)
        • Which is an idiotic idea that even most pro-PC/FR users rejected when we were debating PC/FR. Edit count is not an accurate predictor of whether someone knows how to review (which is also why most automatic-reviewer-status proposals have failed). —v^_^v Make your position clear! 21:42, 15 October 2019 (UTC)
          • Do you have a better idea? QuackGuru (talk) 21:47, 15 October 2019 (UTC)
            • Yeah. Jettisoning Pending Changes entirely. I have made my position on PC/FR very clear (if this is news to you, you have not been] paying attention), and am dead serious about anyone interested about seeing how it works on a project-wide scale learning German and contributing to de.wp. Oh, and PC is contraindicated on pages that see high volumes of edits because it causes massive backlogs. —v^_^v Make your position clear! 22:01, 15 October 2019 (UTC)
              • Non-flagged pending revisions would have much less backlog because anyone with over 500 edits can check it. QuackGuru (talk) 22:44, 15 October 2019 (UTC)
                • Edit count is not and never will be a substitute for what is actually required to be a CRASH member that doesn't suck at their job. In all previous discussions all edit-count-based automatic reviewer proposals have failed. —v^_^v Make your position clear! 23:20, 15 October 2019 (UTC)
                • Currently, everyone with over 500 edits can patrol all of the non-protected articles and revert vandalism. What would change by putting them all under protection while allowing editors with 500+ edits to review them? isaacl (talk) 23:28, 15 October 2019 (UTC)
                  • The proposal is not about changing what is the requirement for WP:Reviewers. I'm trying to think of a way to make it easier for a new process for non-flagged pending changes. QuackGuru (talk) 23:33, 15 October 2019 (UTC)
                    • There isn't going to be one because there is consensus against basing the reviewer right or anything equivalent in power solely on edit count. You're trying to circle a square by allowing non-reviewers to review articles, which isn't even technically possible at present AFAIK. —v^_^v Make your position clear! 23:38, 15 October 2019 (UTC)
                  • What would change by putting them all under protection? The edits would not be visible to the general public until checked. QuackGuru (talk) 23:33, 15 October 2019 (UTC)
                    • What would change is the backlog would get even more unmanageable. Even if we stick with just EC users (47,637, deliberately not counting myself) and just mainspace (5,951,561) the ratio is 1 editor for every 124.9 articles. For reference, when I crunched the numbers of active reviewers to BLPs - much smaller numbers, both, and done years ago during the PC "fuck you got mines", the ratio I got was approximately half that (1:65). —v^_^v Make your position clear! 23:39, 15 October 2019 (UTC)
                    • You said that backlogs would be reduced since anyone with over 500 edits could review the pending changes. But why would these editors be more willing to review potential vandalism changes than they are now? They have the full ability to do so now, and since the content is live there is a greater urgency to perform reviews. What would entice them to engage in this endless, thankless task? isaacl (talk) 23:43, 15 October 2019 (UTC)
                      • There is an unseen backlog of edits from the countless edits that never get checked. That is the real backlog. If the backlog is unmanageable then the vandalism is currently unmanageable because there are too many edits that go unchecked. QuackGuru (talk) 13:15, 16 October 2019 (UTC)
  • Oppose Pending changes is very useful in certain limited situations. BLPs come to mind as particularly suited to PC protection. However, the backlog that would result from turning it on for all pages would be insane. There would be no way for the editing community to keep up with that. If you think the "hours each day" spent reverting vandals is wasted, the hours each day reviewing and approving or reverting every single edit by non-autoconfirmed users that would result from having PC on by default would be at least 10 times the current amount of time reverting vandals. ~ ONUnicorn(Talk|Contribs)problem solving 22:07, 15 October 2019 (UTC)
  • Oppose ONUnicorn hits the nail on the head. This is also rife with the antipathy to anonymous editors. I know some people don't believe this but IPs do make good edits - I see dozens every day. This would mean those good edits would be held in limbo until they are checked. Add to this the fact that there are dozens - 100s - 1000s of articles that are not on any active editors watchlists and there would quickly be countless edits that never get looked at. MarnetteD|Talk 22:26, 15 October 2019 (UTC)
  • Oppose: Not the right time for this, if ever: wholly inefficient for current editors; and how would we accrete new editors? (What, wait for their edits to go through, even if an IP focuses solely, on, say, United States diplomats of the 20th century? Now, that's one of my fields, but even I have to be away from the computer at times...) Like MarnetteD, as well, I can't help but see this as tinged with distaste toward anonymous editors. Javert2113 (Siarad.|¤) 23:32, 15 October 2019 (UTC)
  • Oppose. Pending changes works well for pages where there are a few people paying special attention. Not so good elsewhere. · · · Peter Southwood (talk): 05:57, 16 October 2019 (UTC)
  • Oppose This goes squarely against the five Pillars, namely Wikipedia is free content that anyone can use, edit, and distribute. If the community would really want all articles to be protected in some form, the community would have formed consensus to just do that a long time ago. Lectonar (talk) 13:44, 16 October 2019 (UTC)
    Also: a lot of vandalism by IPs and regular users is reverted by IPs; no need to cut them off by showing some kind of mistrust which is unearned. And a lot of valuable content is also created by IPs. Lectonar (talk) 13:47, 16 October 2019 (UTC)
  • Oppose Same as with other, prefer a registration "nag".Selfstudier (talk) 14:55, 16 October 2019 (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.

CC-BY attribution for every contributor

Given the Creative Commons Attribution-ShareAlike 3.0 Unported License that is applied to contributors—contributed content.

How is the "CC BY" (a component of cc-by-sa) attribution effectively "shown/presented" for every contributor:

  • Does it have to be in the article content as a non-displayable remark? —apparently not.
  • Does the article contribution history effectively function as "CC BY" attribution to each individual contributor? —where is the policy/opinion-essay that presents how this is compliant with Creative Commons Attribution requirements. --2db (talk) 16:21, 16 October 2019 (UTC)
An article history is considered the history of contributor contributions for CC-SA. It is why it is important that page moves are done properly and not through copy-and-paste, that merged content should be identified by the oldid/diff where it originated from, and history merges used when merges occur followed by deletions so the contributions are kept. External to WP, it thus is sufficient to simply link to the WP page the CC-SA content was pulled from as the edit history can be found there. See WP:REUSE for the instructions to reusers of WP content. --Masem (t) 16:30, 16 October 2019 (UTC)
  • Only caveat here is that this applies to textual content on Wikipedia, and may not extend to media uploaded under a different but compatible free license under different terms. GMGtalk 16:34, 16 October 2019 (UTC)

─────────────────────────

  • An article history is considered the history of contributor contributions for CC-SA.

Ok, this implies that "article history" also meets the "CC BY" (a component of every CC–License) as attribution of the contributors—contributed content.

As I understand, every contributor "owns" each "original-work" textual contribution. However when the owner/contributor publishes said textual content on WP, the owner is agreeing to apply the unrevocable CC license mandated by WP. Now WP still has a requirement to give "CC BY" attribution to the contributor—which is met by the "article history" mechanism.

I concur that the "article history" mechanism, meets the "CC BY" content attribution requirement—as proper attribution to the contributor, however that is my opinion. Has any policy/essay been published on why this is correct? --2db (talk) 17:44, 16 October 2019 (UTC)

I mean, I don't know that there's ever been a court case challenging this form of attribution under the license. That's the only real form of precedent setting publication on the matter. GMGtalk 18:53, 16 October 2019 (UTC)
It is part of the Wikimedia Foundation's terms of use that we agree to when we edit. We agree to be attributed in this way. See m:Terms of Use. StarryGrandma (talk) 19:05, 16 October 2019 (UTC)

───────────────────────── What is the status of a contributors—contributed content that has deleted from the article. Does the unrevocable CC license mandated by WP per the original terms for publication by the contributor become null and void after x amount of time? --2db (talk) 03:50, 20 October 2019 (UTC)

@2db: basically, it doesn't change things: that the Wikimedia Foundation, though its volunteers, has chosen to stop publishing a contribution has no bearing on the copyright release that was made by the original contributor. You can release any copyrightable work you produce under CC or any other license you want - we just only accept for publishing works that are under that license. The Creative Commons license, and the GFDL are not licenses to, or licenses of Wikipedia. — xaosflux Talk 04:04, 20 October 2019 (UTC)
Copyright doesn't last for ever, more like life plus 70 years. But as some of our contributors are rather young, this could lead to some interesting discussions about Copyright in the next century. If it is Life plus seventy, and one assumes human life expectancy sticks at 115 being a safely high number, then by 2180 you should be safe to assume that early versions of Wikipedia are out of copyright. However, I'm not sure if the rules are different for collective works, afterall we were able to include work from the 1911 Britannica after less than a hundred years. ϢereSpielChequers 21:43, 22 October 2019 (UTC)

RfC on additional page mover permissions

Howdy,

There is a current request for comment at Wikipedia talk:Page mover (discussion link) regarding whether page movers should be permitted to move pages which are full-protected. As this would require a change of policy, I'm cross-posting here. Sceptre (talk) 18:08, 16 October 2019 (UTC)


Require a captcha for every IP edit in reader-oriented spaces

Look, if you really want to encourage IPs to register an account without requiring them to do so, and you don't want regular editors to face the backlog from making all IP edits pending changes, just require IPs to enter a captcha for each and every individual edit made in mainspace, template space, category space, image space, and portal space. Incidentally, this will help prevent editors with accounts from accidentally making edits while logged out, since they will get the same notice that a captcha is needed before they can save. IP editors who are serious about improving the encyclopedia will likely trudge through some captchas to make their changes (and perhaps will use fewer edits, since I have seen IPs go through a string of 20 edits to fix up an article, when they could have used the preview function and avoided all that). IP editors who merely want to comment in talk page discussions will be unaffected. bd2412 T 19:14, 16 October 2019 (UTC)

*lol* Irritate the hell out of them before they do it to us - or auto-gen an ad they have to watch before they can make any changes. Love it! Atsme Talk 📧 20:33, 17 October 2019 (UTC)
@Tony the Marine and QuackGuru: Does this satisfy your concerns? bd2412 T 19:16, 16 October 2019 (UTC)
@BD2412: long-standing issues such as phab:T6845 should probably be solved first... — xaosflux Talk 19:24, 16 October 2019 (UTC)
I proposed a captcha because it is a minor annoyance that would nudge people towards registering and make IP vandalism more time consuming for the IP. We could just as easily use a popup on each edit requiring the IP editor to confirm that they wish to continue even though their IP address will be recorded, or the like. bd2412 T 19:34, 16 October 2019 (UTC)
I know we're not really voting (or maybe we are?) but support. Anyone can edit and this does not prevent it, but as has been repeatedly pointed out over a very long time, registering an account is more anonymous than editing with your IP address attached to every edit. Whatever technical issues there are solved first, of course. Ivanvector (Talk/Edits) 19:37, 16 October 2019 (UTC)
This definitely helps. There are some IPs that never register but have made hundreds of edits. It should be capped off at about 100 edits (not including talk pages) to require a captcha for IPs and new accounts. QuackGuru (talk) 19:50, 16 October 2019 (UTC)
  • Oppose as counterproductive and yet more "Fuck Tha IPs" bullshit. Why would you demand a CAPTCHA to revert vandalism? That's something that IPs can and will do, and throwing this sort of barrier up is going to discourage that. —v^_^v Make your position clear! 20:52, 16 October 2019 (UTC)
    • All new edits by IPs and new accounts would require a captcha for at least the first 100 edits. Talk page discussions would not require a captcha. QuackGuru (talk) 20:59, 16 October 2019 (UTC)
      • There's no way to meaningfully tell a new edit from a revert for IPs that don't know how to use page histories. —v^_^v Make your position clear! 21:04, 16 October 2019 (UTC)
        • A new edit or a revert for IPs and new accounts would still require a captcha under the proposal. QuackGuru (talk) 21:37, 16 October 2019 (UTC)
          • 100 captchas? I would have sworn off Wikipedia before I was a 1/5th of the way through - and that's not counting that our captchas are terrible Nosebagbear (talk) 21:45, 16 October 2019 (UTC)
          • Is your actual plan to flip off IPs and softban them from Wikipedia, QuackGuru? Because that is the only way I can still presume good faith and reconcile your proposals. Also, what Nosebagbear says above. —v^_^v Make your position clear! 21:55, 16 October 2019 (UTC)
    • I think a registration nag/limitations till registered is sufficient.Don't like captchas.Selfstudier (talk) 22:42, 16 October 2019 (UTC)
  • Oppose: I despise captchas, too. (They don't like me; and don't get me started on their image-based replacements: even worse.) I wouldn't dream of inflicting them on others. This is a proposal that, if implemented, would do immeasurable harm to IP editors and to Wikipedia's image as a whole. Javert2113 (Siarad.|¤) 23:16, 16 October 2019 (UTC)
And I forgot to mention this: I believe this proposal, if implemented, would fall afoul of the nondiscrimination resolution at WP:ACCESSIBILITY. Javert2113 (Siarad.|¤) 23:22, 16 October 2019 (UTC)
I do not think captcha is the answer. When I first wrote my comment I was expressing my personal opinion which I titled "I Believe", I had no intentions of creating a "support" or "oppose" issue, however the title was changed to "Require Registration" by someone else. I know there are a lot of un-registered users who are good at what they do and mean well. Most of these end up being registered users who have made great contributions to our project. However, many users agree with me that the majority of the vandalism made to our great articles are made by non-registered users who have bad-faith editing on their minds. My personal believe is that they and everyone else for that matter should be held accountable for their contributions, whether these are positive or negative. I have known many great contributors to this project who gave up because of all the negative editing going on. That is why I believe that Wikipedia has to or should implement some rules or policy to protect those of us who love this project and wish for it to reach high standards of reliability. That is all I have to say in regard to my personal believes and this subject. Tony the Marine (talk) 23:50, 16 October 2019 (UTC)

Little late to the show (I had to figure out which pictures showed a crosswalk partially obstructed by a traffic light manufactured by Consolidated Lighting between 1937-1962), but: it is true that "the majority of the vandalism made to our great articles are made by non-registered users". Not only that, but the majority of the vandalism made to our lousy articles are also made by non-registered users. That matters, but it matters a whole lot less than this: the net effect of edits by not-registered users is positive. I base this on watching a 2,000-article watchlist for ten years. The net effect of edits by not-registered users is less positive than the net effect of edits by registered users, this is true. But so? It's still a positive. IP's vandalize, but they more often fix spelling, improve grammar, add good material, correct facts, add refs, and so forth. Herostratus (talk) 03:32, 17 October 2019 (UTC)

  • Not captcha but some minor friction/login-reminder on most or all IP edits seems like a good idea.  Just an extra OK click to say I'd really rather not log in or make an account should be enough.  I logged out for this edit just to see what I would get. I got a welcome/start editing dialog; is that always there, or just on first edit from an IP address?  98.210.161.131 (talk) 04:07, 17 October 2019 (UTC)
    • Probably just from the first edit. The last time I accidentally logged out and made an edit, I was surprised to see the edit coming from my IP address. I frankly would have preferred some kind of head's up. Yes, some minor friction. bd2412 T 04:12, 17 October 2019 (UTC)
      • I got it again. Maybe because in a private window there's no cookie to say I've seen it already? 98.210.161.131 (talk) 04:15, 17 October 2019 (UTC)
        • Yup, no such notice on second edit in same private window. 98.210.161.131 (talk) 04:16, 17 October 2019 (UTC)
  • Oppose any barrier to entry for good-faith edits. --Jayron32 14:41, 17 October 2019 (UTC)
  • Oppose From my experience, exceedingly slow. Captcha should only be used to prevent vandal bots, spam bots, ad bots, and other non-human vandals and advertisers, not humans. Plus Captcha might not work in some areas, and on some networks I have found that it doesn't work at all. From AnUnnamedUser (open talk page) 23:22, 17 October 2019 (UTC)
  • Captchas are used to filter out non-human agents. There doesn't appear to be any spate of malicious anonymous bots, so the proposal seems to be only about erecting obstacles in the way of IPs. Maybe this could entice a small number of them to register an account, but it's sure to annoy the hell out of many others and deter them from editing altogether. – Uanfala (talk) 13:02, 20 October 2019 (UTC)
  • I agree with 98.210.161.131 ("Not captcha, but some minor friction/login-reminder on most or all IP edits seems like a good idea.") I don't have anything specific to propose at this time. So, I oppose this exact proposal but support a later attempt to get us somewhere. While we do not want to discourage good-faith contributions, we do need to encourage account-creation, and discourage bad-faith (or even "grey-faith" – boneheaded, test/experiment, or just plain clueless) edits, most especially bad-faith ones done in rapid-fire succession. It's been a problem for 18 years and is not abating, so steps need to be taken, and have needed to be taken for a very long time. It's shameful how much constructive volunteer time is wasted cleaning up after bad IP edits. I'm extremely skeptical that the amount of good content contributed per day by IPs exceeds the amount of mess everyone else has to clean up. Maybe it did in the 2000s, but likely not today.  — AReaderOutThatawayt/c 05:39, 22 October 2019 (UTC)

Request for comment

Please see Wikipedia:Requests for comment/2019 community sentiment on binding desysop procedure. GMGtalk 01:03, 18 October 2019 (UTC)

Multiple users logged in on same account

Does anyone know if there is any rule against more than one person being given & using the password of a user account? Can't find anything on that. --SergeWoodzing (talk) 20:30, 19 October 2019 (UTC)

@SergeWoodzing: That's not usually allowed, see WP:NOSHARING. -- John of Reading (talk) 20:40, 19 October 2019 (UTC)
Thank you - that's what I was trying to find. --SergeWoodzing (talk) 20:41, 19 October 2019 (UTC)

It's good to know there's a restriction, Portuguese Wikipedia even had a shared sysop account at some point, I just assumed it was allowed and a study group I direct considered doing it for organisational purposes (and to avoid meatpuppetry accusations). We never did it anyway. Leefeniaures audiendi audiat 21:36, 19 October 2019 (UTC)

Technical

statelocallocal

Proposals

Proposal to delete Portal space

A proposal to delete the Portal: namespace. 21:00, 22 September 2019 (UTC)

Following the community discussion on portals which ended in May 2018 with "a strong consensus against deleting or even deprecating portals at this time", there was initially a surge in new portals resulting from mass creation using new automated tools. This wave of enthusiasm which saw a huge expansion of several hundred semi-automated portals was then countered by mass deletion, for example here and here. Having more or less restored the status quo, however, portals continue to be deleted at a rate - currently about 100 per month - that means within a year they will cease to exist or there will be so few that it will be pointless maintaining portal space. I personally am very much in favour of quality portals with several purposes: as navigation aids, as a showcase for broad topics, as an instant overview of a topic and as a tool for project editors to expand and improve coverage. However, it is now clear that the community is either unable or unwilling to defend its consensus - partly because there is a small band of determined editors working their way through all the portals, whereas each portal is usually only defended by one or two editors working on that topic. So it would save all involved editors a lot of time if we just agreed to scrap portals and portal space rather than continue the present process with those editors who see no value in portals having to put them one-by-one for deletion while those in favour of keeping them continue to waste time trying to defend them. Bermicourt (talk) 20:35, 19 September 2019 (UTC)

  • (Added the RfC template above, as this is a major proposal that deserves greater community attention) North America1000 06:46, 22 September 2019 (UTC)
  • Comment I think 3 portals (which are not really portals in the sense of being subject-area specific) should be exempt from this discussion: Portal:Contents, Portal:Current events and Portal:Featured content. There is no consensus whatsoever to delete them, and whether the portalspace remains with only these three, or they are moved elsewhere, this discussion should be limited to what happens to the subject-area portals. UnitedStatesian (talk) 20:50, 19 September 2019 (UTC)
  • Rate of deletion doesn't imply continuation to extermination. Hyperbolick (talk) 21:05, 19 September 2019 (UTC)
  • Actually, @UnitedStatesian, it doesn't, because portals are not a living species. They have a minimum viable population of one.
If and when portals do become biological entities and start reproducing each other, then you will be right. But I think we probably have a little time to go before Portal:Latvia runs off to make babies with Portal:East Timor. --BrownHairedGirl (talk) • (contribs) 20:59, 20 September 2019 (UTC)
Most of the commentary seems poorly informed. Wikipedia:Portal was created in February 2005 to manage "Wikiportals", and complaints have gone on ever since, not from people who want to improve the functionality of the content browsing schemes, but people who don't even want to use them and therefore, as humans do, simply imagine they can serve no purpose. Portals on the main page are getting something like 8,000 hits a day. This is being lauded as not enough because of the millions of hits the main page gets every day. The truth is, you hit the main page every time you come here to search for something in particular without reading anything. If you came here to find topics without a specific search term, you'd often look at the news, Did You Know, On This Day etc. If a DYK entry gets more than five thousand hits, not much more than half what some of the portals are getting, it goes down in a hall of fame forever. Imagine that. Don't be shocked, surprising results are standard fare when it comes to things involving human activity and numbers in the millions. No you can't delete the portal namespace without replacing it. It is one of the oldest parts of the content browsing system. What we need is, not to kick it with a big boot, but to nudge ourselves, and figure portals out because the only time they get some decent brainstorming input is when people are trying en masse to delete them because they don't understand. People have been paranoid about portals almost since they started, and some of that paranoia is fair, some of the recent portals have been nonsense, but so is a lot of Wikipedia sometimes and it just needs relatively minor edits and ideas to come out shining lovely, functional, and the best thing on the internet for what it is. Make portals the best thing on the internet for what they are, a content browsing system, and stop all this crazy driving towards deleting everything we don't use ourselves. There is an unspoken law of evolution: Almost everything is quirky in its own way. We don't truly understand that in a conceivable way, but imagine a world where we didn't try to embrace and emulate that quirkiness. What has happened here is that the portal team have tried to make portals really quirky really fast and had some failures which appear to be on a grand scale, but this is a practically invisible grand scale. It needs cleaned up, but it doesn't need deleted without fixing it. A content browsing system is a standard part of an encyclopaedia. Stop all this waffling on about putting an end to our content browsing systems and instead, use those brains to improve it. That's what we're crying out for, not this. ~ R.T.G 12:30, 16 October 2019 (UTC)
  • Comment To add some context to this. Around 100 Portals get deleted every month. Currently there are 42 Portals listed at the Miscellany for deletion page. If you take some time and take a closer look then you will notice the same 2 or 3 users consistently vote delete on all of these. Basically unopposed. The archives of the previous months will show the same picture. There is a pretty small-scale consensus going on of users who decided to delete most of the portal space. When I asked one of those users what their endgame is, they told me they wanted to delete at least 93.8% of the portal space, or 848 portals of the 904 remaining ones in July 2019, which they picked based on pageview numbers. So I can see why there is a demand for a wider scale consensus. If that is what the community wants, then so be it. But this should not be decided by poorly attended mass-MfDs. --Hecato (talk) 21:51, 19 September 2019 (UTC)
    • Low-hanging fruit, no? Hyperbolick (talk) 22:01, 19 September 2019 (UTC)
      • Most of the tree, I'd say. --Hecato (talk) 22:10, 19 September 2019 (UTC)
        • To some degree the low attendance of MfDs is a pretty potent indicator that there's not a lot of broad interest in keeping those portals around, let alone maintaining them for usefulness. Wikipedia's allowed to—and should!—try things, make mistakes, and be willing to say something was a failure; at least from the metric of user usefulness, most portals seem to fit that criteria. Der Wohltemperierte Fuchs talk 17:02, 20 September 2019 (UTC)
          • I believe there had been changes which caused portal usage to decline: Another user collected data on portal usage between 2015 and 2018, and I believe it halved. An influence may have been the mobile phone interface in use now. WhisperToMe (talk) 07:09, 24 September 2019 (UTC)
    The 2018 RfC stated that there were 1500 portals, which sounds about right. 660 portals survive today. Recent deletion counts by month: June 244, July 289, August 205, September (up to 19th) 189. Certes (talk) 23:43, 19 September 2019 (UTC)
  • It is shamefully disruptive that Hecato chooses yet again to misrepresent my comments.
I well remember that conversation with Hecato, tho unfortunately I can't locate it now. What I actually wrote was I believe the point of viability for portals to be somewhere around 100 pageviews per day. Hecato translated that into (I think 6.2%) of all portals, to which I promptly replied that I was setting a quality threshold not a number-of-portals target. Yet here Hecato has chosen here to cite a whole set of numbers which I never claimed and explicitly did not endorse.
Hecato has chosen to repeatedly misrepresent me. I cannot know for certain whether Hecato acts out of stupidity or malice or dishonesty, but it has been a recurring part of Hecato's conduct since only a few days after they joined wp a few months ago, and it's highly disruptive.
It's also tedious to have to assert yet again that the process of removing abandoned junk portals is housekeeping conducted without an end goal; it will stop when we cease to find abandoned junk portals. It's horribly time-consuming, and I wish it had finished long ago. I have my own views on the long-term future of portals, and have never sought to hide them, but I !vote in MFD on stated quality grounds I do not and never will try to use MFD to reach some quota of portals. That too I have set that out many times in discussions of which Hecato has been a part, and its repetition by Hecato is again a product of some sort of stupidity or malice or dishonesty. --BrownHairedGirl (talk) • (contribs) 08:28, 20 September 2019 (UTC)
Are these your own statistics or not? Did you not explain the implications of your plan in that very discussion? --Hecato (talk) 09:20, 20 September 2019 (UTC)
@Hecato, can you actually read English? I listed there four different options as potential proposals. You have cherrypicked one of the 4 options, and falsely asserted that it was my goal. In fact, I didn't set any of them as my goal; I opened a discussion about them, and when none of the ideas got support, I didn't pursue it.
You have a persistent and destructive habit on leaping on fragments of text, misunderstanding them, conflating them with something else, and then misrepresenting them to use as a weapon. This is not collegial conduct. --BrownHairedGirl (talk) • (contribs) 17:37, 20 September 2019 (UTC)
Hecato is right. There is a small band of determined editors who have adopted the tactic of destroying portals in detail because, individually, there will only be one or two project editors who are alerted to the MfD but that is rarely enough to overturn deletion. It's a clever tactic which has proven highly successful, but flies in the face of the community consensus not to delete or deprecate portals. That's uncollegial. Bermicourt (talk) 07:28, 21 September 2019 (UTC)
  • You confirmed above that you wanted to delete at least all portals with less than 100 daily pageviews. And you yourself created a comprehensive analyses of all the consequences that entails (deletion of 93.8%, 848 out of 904 portals in July 2019) as linked above. I assume you did not suffer under amnesia at any point in the last few months. --Hecato (talk) 11:39, 21 September 2019 (UTC)
To everyone: please, let's avoid the personal commentary. And there's no need to reply to this post, particularly to go over what others are doing now and in the past. Rest assured, I am aware. isaacl (talk) 16:19, 21 September 2019 (UTC)
  • @Hecato:. Stop switching the target. Your post above is about something which you claim you were told in July, and it's a fabrication.
You claimed above above that I told you in July they wanted to delete at least 93.8% of the portal space, or 848 portals of the 904 remaining ones in July 2019, which they picked based on pageview numbers. That is a lie, because I told you no such thing. The link you posted does not support the claim you made, and you weren't even part of that conversation ... so the idea that I told any part of that to you is another lie.
It's long past time for you to stop telling lies, and to stop doubling down on them when caught out. Wikipedia is a collaborative project, and your alt-fact propaganda tactics of doubling down on lies have no place here. --BrownHairedGirl (talk) • (contribs) 16:59, 21 September 2019 (UTC)
So it's true, but you did not tell me about it? --Hecato (talk) 10:04, 22 September 2019 (UTC)

Support - but leave Portal:Contents alone. Mark Schierbecker (talk) 23:48, 19 September 2019 (UTC)

  • Support - if nothing else maybe it will cut down on the bickering that is spreading throughout the project. — Ched (talk) 00:58, 14 October 2019 (UTC)
    That's an interesting proposal. Amputating the affected limb would be a practical solution to the problem. On the other hand, do we want to establish a precedent that anyone can get part of Wikipedia removed by bludgeoning a sufficiently long tirade of indignation and insult? Certes (talk) 08:23, 14 October 2019 (UTC)
  • The tail end of the ~2000 portals was easy to criticize. The tail end should be all deleted (or archived with prejudice), and that has been happening, with speed and momentum.
Even if 99% should be deleted, or deprecated and archived, it is a long way from agreeing that the top portals should go.
Consider them:

Top Portals.

#1 Main Page: Already in mainspace.
#2 Wikipedia:Community portal: Already in projectspace, and is a Portal To the Community, not for browsing articles.
#3 Portal:Contents redirects --> Portal:Contents/Portals: An unloved neglected start quality page. Look at https://xtools.wmflabs.org/articleinfo/en.wikipedia.org/Portal:Contents/Portals#Year counts
Collectively unloved neglected good idea. —SmokeyJoe (talk) 06:00, 21 September 2019 (UTC)

Main Page linked portals (alphabetical):

M#1 Portal:Arts
M#2 Portal:Biography
M#3 Portal:Geography
M#4 Portal:History
M#5 Portal:Mathematics
M#6 Portal:Science
M#7 Portal:Society
M#8 Portal:Technology
These eight mainpage-linked portals were chosen to be linked from the top of the mainpage for a good reason: They represent the broad subject areas of all articles. They appear intended to provide for top end browsing of the encyclopedia. I think they should be kept for that purpose, although they are currently not serving that purpose well.

I propose:

  1. Keep the Main page in mainspace.
  2. Keep #2 as not an article portal, is already in the right namespace, and its title is OK.
  3. Archive #3. A good idea, but never developed. It should be re-deployed only following a redevelopment of the main page linked portals M#1-8
  4. M#1-8. Move to mainspace, wind back linking to projectspace, only have projectspace linking in side frames. Possibly, these mainpagelinked portals could be merged to their parent articles. Possibly they could be moved to Arts (portal), for example. Whatever, a redevelopment is required. I think that they need to: (1) provide for comprehensive browsing to all articles; (2) match many of the principles of the category system.
Outlines
WP:Outlines are another attempt at facilitating comprehensive browsing, part-developed by much the same set of editors as for portals. They need to be in the conversation as well, whether merged into mainspace portals, or deleted.
--SmokeyJoe (talk) 00:20, 20 September 2019 (UTC)
@SmokeyJoe: I think your #3 above is not correct. Portal:Contents is its own page, not a redirect. It has many subpages/transclusions, but it does stand on its own. Its subpage Portal:Contents/Portals should be a M#9 in your list above, since that is what is the ninth portal link at the top of the main page. UnitedStatesian (talk) 03:38, 20 September 2019 (UTC)
Yes. It looks like I got that wrong. In any case, Portal:Contents and it’s subpages are a good idea, but are thoroughly neglected, undeveloped. I don’t think Portal:Contents belongs in the set of eight broad subject area portals M#1-8. —SmokeyJoe (talk) 05:57, 21 September 2019 (UTC)
Just to comment on some of the above, I would not be particularly opposed to relocation of portals on the more important topics to another mainspace, possibly project space, or article space if artfully done. bd2412 T 02:44, 22 September 2019 (UTC)
Outline are used in FA and GA articles alot to curb "See also" spam. I would not say outlines have the same problem as portals because there is not content in most.--Moxy 🍁 00:14, 23 September 2019 (UTC)

Section break 1

  • Oppose Users above may not have used portals, but I seek them out as a vital resource - the upper-level ones, admittedly. They function well where Overviews are lacking, and are a useful hub for those editors who have a primary focus on that topic. In theory, there is good reason to have a portal for every WikiProject, but I would say that could get too excessive where there are projects based for more niche things that exist because of a lot of interest. Kingsif (talk) 01:31, 20 September 2019 (UTC)
User:Kingsif. You appear to saying things that resonate with what I have been thinking.
(a) Upper level portals have value, or at least, a reader expects them to have value an sometimes tries to use them
(b) "Overviews are lacking". Broadly stated, absolutely. Article ledes provide good article overviews, but at a higher level they are lacking. Portals I thought were an attempt, but they fail, and WP:Outlines were kind of a skeleton of an idea in that direction but no more.
(c) I have sugested many times, but gaining zero traction from anoyone else, that many of the fair portals, maybe ~100 below the top portals, would be better suited in projectspace, within their WikiProject, becuase currently they seem mostly driven by editors to motivate other editors to do editing.
Can you comment on any of my ideas. I would like to see reform and redevelopment with better defined purposes, I think Portals suffer from a lack of stated objective, and I am not sure that NameSpace deletion is the road to get there. --SmokeyJoe (talk) 01:56, 20 September 2019 (UTC)
Absolutely, I think we have generally the same ideas. I am not opposed to reform, some portals do seem dead or linked to very closed topics, and some are already so well integrated into projects that they may as well be in there - but these should be much wider discussions, it's a small group of editors who have cleared out the unmaintained portals rather than try to improve them, with WP:Portal discussions... something else. The discussion should at least be expanded to have more options than "delete all" or "do nothing", I feel, and some of your suggestions help in that direction. Kingsif (talk) 02:09, 20 September 2019 (UTC)
  • Support something like this. I would prefer to keep some portals, maybe just the top three as suggested by UnitedStatesian, maybe also keep the 8 portals linked from the mainpage, and maybe even keep about 50–100 portals (roughly corresponding to WP:Vital articles/Level/2.
I have been one of the main drivers of portal deletion over the last six months, and I have repeatedly been astonished to find how many really bad portals there are. Ever time I thought we were nearing the end of deleting the junk, dozens more would be found. I don't know how many more portals there are which clearly fail POG, but beyond them there are hundreds more like Portal:Ireland: not broken, not on a too narrow topic, maybe lightly maintained ... but still not v helpful. So they languish with poor readership and poor design and no editor willing to devote much time to them.
The pageview stats for all portals are grim. Only 53 out of 639 exceed 100 pageviews per day, and only 18 exceed 200 views/day. Only the portals linked from the mainpage exceed 1000 per day, and even their numbers are grim, because the mainpage averages about 16 million hits per day.
It's very clear that portals as a whole have failed. After 14 years, they simply have not attracted enough readers to justify all the overheads of maintaining the portals, and maintaining over 7 million links to portals. This is unsurprising, because maintaining portals is a lot of work, which few editors want to do ... and because the design of most portals varies between dire, abysmal, atrocious, and disgraceful. Most of them are variants of extreme usability failure, making it slow and hard to get access to a risibly limited and poorly-chosen subset of a topic area's content.
After 14 years, the dwindling crew of portal fans have no remotely credible ideas of how to make portals work. Instead they moan about deletion, and try to wikilawyer their way against the deletion of even abandoned junk with almost no readers.
Portal:Contents has clear value as a rough higher-level sitemap. But the rest of them suffer from the same problem as the dominant 1990s web-portals: their niche held in the absence of better alternatives, but they were killed by the new technologies of powerful search (Google) and massive cross-linking (thanks to content management systems). Wikipedia has both of those, and is especially good at cross-linking. So the demand for portals is low, and the supply-side is starved: few active editors, v limited software, and a small editor base without any of the exceptional talent needed to make a breakthrough.
So I'm not picky about this. Some big cutback would be a huge improvement, and I;ll go with whatever we can get. --BrownHairedGirl (talk) • (contribs) 07:45, 20 September 2019 (UTC)
  • Oppose the total deletion of Portal namespace. There are three portals with millions of yearly viewers (Portal:Current events, Portal:Contents and Portal:Featured content), and fourteen portals with over 100,000 yearly views. I think anything over 10,000 is significant enough to keep 'not automatically delete', which includes around 240 of the current 640 portals. So total annihilation is premature. That said, there are many remaining portals that appear unattended to in any fashion. Mr rnddude (talk) 08:14, 20 September 2019 (UTC)
@Mr rnddude: 10,000 views per year sounds a lot, but it is only ~27 views per day. (It's easy to forget the scale of Wikipedia; the main page got 5.87 billion pageviews in the last year). But sadly the rot extends way beyond the 27/day mark. The community's ability/willingness to sustain portals which don't fail POG's very basic minimum requirements is low, and there many portals with much higher pageviews than that which are in v poor shape. (Recent notable examples include MFD:P:Education, MFD:P:Asia, MFD:P:Olympic Games) I view those as worse than the almost-unviewed junk, because so many more readers are having their time wasted. --BrownHairedGirl (talk) • (contribs) 08:56, 20 September 2019 (UTC)
BrownHairedGirl - Considered broadly, 27 views per day is not insignificant. Assuming article views are evenly distributed across en.wiki's 5.9 million articles, and that there are 5.87 billion views* a year, then on average each article is receiving 5,870,000,000 / 5,900,000 = 995 views per year, or 995 / 365 = 2.72 views per day. That's 1/10th of what any of those 240 portals are receiving. Of course, in reality, some articles are receiving thousands of views per day, and some are visited once in a blue moon. Moreover, not every main page view translates to an article space view, and any single main page view can result in 100 different article views (via bluelinks for example) so this quick math is less than perfect. I understand that some/many portals that meet this threshold are in very poor condition/abandoned. My 10,000 page views per year is a bar for "don't automatically delete", not for "automatically keep".
*I'm assuming that each article view takes place from the main page search bar, though this is not the case. Mr rnddude (talk) 10:08, 20 September 2019 (UTC)
@Mr rnddude: its not only not the case ... it's so far from the case that it makes your calculation irrelevant.
The comparison with the whole set of articles is also misplaced. Portals are supposed to be "enhanced main pages" for a whole topic area, so the correct comparator is the head article for the topic. In nearly all cases that I have examined, the head article gets between 100 and 2,000 times more views that the portal. --BrownHairedGirl (talk) • (contribs) 17:06, 21 September 2019 (UTC)
  • Oppose. Most of the 1500 portals which existed last year have now been deleted. A mass creation which added portals with narrow scope was swiftly undone. Although I disagreed with some deletions, they were selected carefully, leaving the better portals in place. We have also developed tools. Templates can now transclude excerpts from the current version of an article rather than creating a fork which becomes outdated. The consequent reduction in text allows an entire portal to fit on one or a few pages rather than sprawling over dozens of forgotten subpages. These changes leave the namespace in far better shape than it was when the previous RfC found consensus to keep it. Whilst WP:ENDPORTALS did not exempt every single portal from deletion, the clear implication was that the namespace should remain of significant size. The reduction to 660, with 30 more currently at MfD, is already a major compromise; keeping only three, eight or even 100 of the 1500 portals would be not in the spirit of last year's agreement.
    Page view counts say more about the visibility of portals than their quality. A wonderful portal will get as few first-time visitors as a dire one. Articles are suggested in the search box and those on subjects broad enough to merit a portal will have hundreds if not thousands of incoming wikilinks. Portals are excluded from search results and, except for the few featured on the main page, tend to have fewer incoming links. Certes (talk) 08:43, 20 September 2019 (UTC)
Certes is engaged in some rewriting of history.
When speedy deletion of the portalspam was considered, it was Certes who memorably described that process as a war on portals.
Also, Certes description of ENDPORTALS misrepresents the discussion (yet again). ENDPORTALS was a binary proposal to delete all portals, or have no mass deletion. No compromise was on the table. The result was a rejection of the proposal to delete all portals, and there was no implication either way of the resulting size of the set. (That's why TTH and his fellow-spammers interpreted the RFC as a license to spam away).
Additionally, so much has happened in portalspace since ENDPORTALS closed 18 months ago, that is likely that consensus has changed. Six months of detailed, one-by-one MFD analysis of the dire state of most portals has been an eyeopener for many. It's time for a new multi-option RFC to establish where consensus actually stands, and not try reading the entrails of an RFC which is now effectively ancient history. --BrownHairedGirl (talk) • (contribs) 09:10, 20 September 2019 (UTC)
I agree that ENDPORTALS was a binary proposal to delete all portals, or have no mass deletion. No compromise was on the table. The result was a rejection of the proposal to delete all portals. And yet a mass deletion of over 800 existing portals (plus the new ones) has taken place and another mass deletion is proposed now. Consensus can change, and this discussion may reach a different conclusion, but my comments above represent the previous discussion fairly. Certes (talk) 09:33, 20 September 2019 (UTC)
Certes - regarding your statement that "Portals ... have few incoming links". Can you clarify (or strike) that? I've just looked at Portal:Lincolnshire and it's got inlinks from thousands of pages. DexDor (talk) 11:45, 20 September 2019 (UTC)
Yes, that portal is exceptionally well linked, with nearly half as many incoming wikilinks as its article. Other portals have far fewer links: Lancashire's link ratio, for example, is 1:25. Also, although not the case for Lincolnshire, links to portals are often hidden within a collapsed template. I've modified my comment. Certes (talk) 12:58, 20 September 2019 (UTC)
I disagree, there is no evidence of the links/pageviews relationship, for example P:NUDE is linked in only 60 articles and is among the 50 most viewed portals.Guilherme Burn (talk) 13:30, 20 September 2019 (UTC)
@Guilherme Burn is correct. In the last few months, I have cleaned up the backlinks to all the deleted portals (those created through portals templates are listed in Category:Portal templates with redlinked portals plus subcats), and I have found no correlation between portal views and number of backlinks. There have been portals with abysmally low views but several thousand links from articles; others with much higher views but only a few dozen links.
Note that link counting needs a lot of caution. I assume that links have different value according to which namespace they are in, and how prominently they are displayed. For example, a category page has much lower views than an article; but OTOH the categ displays the link prominently on the top right of the page, whereas the article may display it within a collapsed navbox.
Through my work developing {{yearInCountryPortalBox}}, I created literally hundreds of thousands of links to Portal:Years, country portals and decade portals. Yet Portal:Years languished with trivial pageviews until it was deleted, and so do many country portals.
So if editors want to drive up portal readership, there will need to be some research. There has been far too much assertion of assumptions as if they are proven, whereas the data doesn't support the assumed correlations. BrownHairedGirl (talk) • (contribs) --17:21, 20 September 2019 (UTC)
It is also inaccurate for you describe WP:ENDPORTALS as an "agreement;" in fact the closer specifically wrote "no consensus." And then what happened? Yes, some tools were developed (thank you for that), but instead of being used to improve what we had, the tools were then used to take portal space in a wildly different direction, contrary to community consensus. And the result was a disaster. And the tools development stopped, in a very incomplete state; many create Lua errors, require advanced knowledge of Lua code, and work only in limited circumstances (I'll spare describing the result in Portal:Beavers). So the fever dream of a fully automated portalspace, which was pitched during WP:ENDPORTALS, is so far off in the future that we are effectively back where we were. UnitedStatesian (talk) 13:01, 20 September 2019 (UTC)
The close reads: There exists a strong consensus against deleting or even deprecating portals at this time. Certes (talk) 13:05, 20 September 2019 (UTC)
My bad, that part struck. UnitedStatesian (talk) 13:22, 20 September 2019 (UTC)
Three out of 660 portals currently show Lua errors. This is because the pages are too complex. A technical solution is actively being developed but requires a bot which is awaiting approval. All portals also run through the linter tool with no warnings. There have been other errors in the past, but their absence shows that the tools are being actively developed despite the constant discouragement. Certes (talk) 13:59, 20 September 2019 (UTC)
But that development is happening in the dark, which is the same problem as before. Where are the notifications of what is going on, to Wikipedia:Wikiproject Portals or the portal maintainers who are putting in effort? Or is the plan just to dump these into the portalspace with no warning, again? UnitedStatesian (talk) 14:13, 20 September 2019 (UTC)
There are a couple of enhancement announcements from last week here and here. Discussions usually take place on that page too, though those particular releases implement features requested on my own talk page. Lua errors from pages being too complex are discussed here but a solution has not yet been announced as it will not work without the nascent bot. Certes (talk) 14:55, 20 September 2019 (UTC)
@Certes:I agree that wonderful tools were created, I am a fan of the single-page layout, but their use has been reverted on a number of occasions in a dictatorial manner, has not reached the portals with many pageviews and new created portals continue to use the flawed example of the subpages forks. What is your opinion about this?Guilherme Burn (talk) 13:18, 20 September 2019 (UTC)
Even some editors who nominate portals for deletion agree that properly used excerpt templates are an improvement on stale forks, though some have complained that (per WP:LEADCITE and established practice on the Main Page) they omit references etc. Reversions have generally been justified as the portal being redundant because the list of articles displayed in one of its sections matches an existing category or template. In many cases our improvements only served to attract attention to the portal, which was subsequently deleted on the grounds that the version which we had replaced was of low quality and outdated. There is plenty of scope for deploying the tools in established portals without spoiling their character, but I cannot sensibly encourage anyone to invest their time in such work until the portals' future is clearer. Certes (talk) 13:50, 20 September 2019 (UTC)
@Certes: I am not aware of any case of the use of excerpt templates being reverted because the list of articles displayed in one of its sections matches an existing category or template. (There may have been a few where the whole portal was a cat/navbox clone, but I don't recall any). Please identify the portals you are talking about, because the creation of portals in the way you describe is a sneaky trick which should be stopped.
I am aware of about a dozen portals being deleted by consensus because they were new creations which used the embedded list technique to simply copy a category or a navbox, since I nominated most of them for MFD. Examples include MFD:Portal:Drawing, MFD:Portal:Volume, MFD:Portal:Electricity, MFD:Portal:Julius Caesar, MFD:Portal:Habitats, and MFD:Portal:Shipwrecks.
I really really hope that Certs clears this up, because after so many MFDs, it is very very very clear that the community has consistently and overwhelmingly rejected the creation of portals which simply clone the content set of another navigational device and present it in the bloated form of a portal, because that redundancy adds no value for readers. It appears to me that Certes's post above is a rejection of that consensus, so I hope that Certes will lose no time in clarifying that they are not seeking to subvert or evade the consensus that a portal cloned from a category or navbox is redundant. --BrownHairedGirl (talk) • (contribs) 17:30, 21 September 2019 (UTC)
Many examples have since been deleted. One still in place is Portal:Culture, which you reverted with the summary Restore last curated version, reverting conversion to automated redundant navbox-fork (TW). I see that you have replied to my comment at its MfD with the summary Certes making stuff up, so perhaps we will have to agree to differ on this point. Certes (talk) 00:38, 22 September 2019 (UTC)
@Certes: it should be crystal-clear from that edit summary that that portal was reverted because it had been converted to an automated navbox clone. As you are very well aware, the community overwhelmingly rejected the automated navbox clones. I did any such reversions; but any many more were done by other editors, including NA1K and UnitedStatesian.
It is very sad to see that Certes apparently rejects that consensus. --BrownHairedGirl (talk) • (contribs) 21:36, 4 October 2019 (UTC)
  • Oppose deletion of portal space, working for active portals Germany and Opera. --Gerda Arendt (talk) 17:15, 21 September 2019 (UTC)
    • Those, Gerda Arendt, are third tier portals, in the top 10-100, that I consider of unclear merit. What do these portals do for readers? Either of them, for any reader? Any evidence or anecdote? —SmokeyJoe (talk) 13:22, 23 September 2019 (UTC)
      • What I know is that both a Featured portals, well maintained, and with significant pageview numbers. Different offers mean different things to different readers. Individual "evidence" or "anecdote" wouldn't mean much to me. --Gerda Arendt (talk) 13:36, 23 September 2019 (UTC)
        • I don’t think “featured portal” means anything, not with “portal” itself being undefined. I put it to you that both are inferior to the parent articles by every measure, and they they are just playthings of editors. As playthings of editors, they belong in their WikiProjects, not tricking readers who think portals are for navigating. —SmokeyJoe (talk) 13:58, 23 September 2019 (UTC)
  • Oppose deletion of portal space. In a way, this is a solution looking for a problem. The whole issue over portals just creates work - even just discussing it - which could better be used for improving and policing the quality of mainspace articles , combating vandalism, and deleting inappropriate articles. Existing portals do not do any harm, neither is it a case of server capacity. Time to put this whole business to bed. Kudpung กุดผึ้ง (talk) 03:16, 25 September 2019 (UTC)

Section break 2

  • Support (deletion of portal namespace after moving a few pages to other namespaces). The costs of portals (luring some readers to poor pages, editor time spent creating/updating/discussing them, extra complexity added to Wp etc) outweighs any benefit they provide - of the OP's 4 points about the purpose of a portal the first 3 are what the corresponding article does (generally better than a portal) and the 4th is what the corresponding wikiproject should do. DexDor (talk) 11:57, 20 September 2019 (UTC)
  • Support - I like portals, but let's go to some points that demonstrate the death of the portals.
#1 Wikiprojects have abandoned the portals, several portals of active wikiprojects have been deleted without any objection from wikiprojects, while other portals are abandoned even with active wikiprojects.
#2 There is no relationship between pageviews and the quality of portals, or pageviews and the amount of backlinks to portals.
#3 In over a decade of namespace no solid guideline has been created, no logical organization, and not even portals have been correctly categorized.Guilherme Burn (talk) 12:03, 20 September 2019 (UTC)
  • Strong Oppose: There is no other suitable namespace for well-maintained portals such as Portal:Opera. Perhaps they just need rebranding. Adam Cuerden (talk)Has about 6.9% of all FPs 13:24, 20 September 2019 (UTC)
    Adam Cuerden, well, back before 2005, all portals were subpages of Wikipedia:Wikiportal, see User:Portal namespace initialisation script and its contributions. —Kusma (t·c) 14:11, 20 September 2019 (UTC)
    • @Kusma: I doubt that a deletion of the namespace would do a very good job at keeping what is, after all, at the least an important part of Wikipedia's history. Even if we shut down the creation of new portals, deleting years of hard work seems arbitrary, unnecessary, and rude. Adam Cuerden (talk)Has about 6.9% of all FPs 17:38, 20 September 2019 (UTC)
      Adam Cuerden, indeed. Portals do very little harm (even if they have little use), and deleting them is a great way to show editors that their hard work is not appreciated. So I don't understand why it is so popular. —Kusma (t·c) 19:34, 20 September 2019 (UTC)
Deletion of abandoned junk portals is popular because most editors can see luring readers to sets of abandoned, outdated, unscrutinised content forks surrounded by fake or stale DYKs plus stale news labelled as if it was current is a waste of the time of our readers, and a blot on Wikipedia's hard-won reputation. --BrownHairedGirl (talk) • (contribs) 20:37, 20 September 2019 (UTC)
  • Oppose There are very valid and good reasons to use Portals for broad topics, but from this mass creation incident, which created portals on a number of very narrow topics, we really need to have a process to approve the creation of new portals in the future, so that only those deemed sufficiently broad and appropriate are in play. --Masem (t) 13:40, 20 September 2019 (UTC)
    Masem, currently the question is more how to keep and improve portals on broad topics... Portal:Culture is at MFD right now (obviously a super broad topic), and from past experience I can tell you that fixing issues with portals during MFD is frowned upon (some people have been accused of "bad faith drive-by updating" or similar), so I won't touch it for my own sanity. We don't just need rules that justify deletion or harm creation, we also need some rules against deletion. —Kusma (t·c) 14:09, 20 September 2019 (UTC)
  • Strong Oppose - Not this again.... not all portals are in the same boat here, doing this would go around consensus on AfDs that were kept. - Knowledgekid87 (talk) 13:41, 20 September 2019 (UTC)
  • Oppose as written (and note that Bermicourt who originated this section is the creator of many portal, and many of those were deleted, and may be voicing their understandable frustration with the whole process here). There are numerous problems with portal space, the main is that there is no agreement what it is for and what any particular portal should do. In the past, this has meant that many portals got created, and having portals about major topics (like every country on Earth) was considered normal. In the last year, the old style guideline page WP:POG has been re-interpreted as a policy page that explains what portals should be like, and a particular interpretation of that page (I understand it as "portals must be about a wide topic including quality articles, must be maintained regularly, and have a nontrivial amount of pageviews") has become a popular deletion reason. Well, the only portals that get a significant amount of pageviews are those linked from the Main Page, so if pageviews are deemed important, all portals are doomed, even the well-maintained ones. In the current atmosphere, maintaining portals isn't a lot of fun, as you never know whether your portal will be nominated for deletion based on low page views soon, so people are stopping to do it, a self-reinforcing vicious circle very much against the spirit of Wikipedia to fix problems instead of deleting everything that is not perfect. In any case, if there is consensus that portals shouldn't be shown to readers, simply removing all portal links from mainspace would do the trick, and would allow the maintained portals to continue existing as tools and showcases for editors, linked only from talk pages and Wikipedia space. There is little need to delete old meta pages, even if they are useless, unless they are actively harmful, and I think the dangers of portal space have been rather exaggerated. In any case, anyone who opposes the deletion of all portals at once should show up at MfD every now and then to avoid deletion of all portals one by one. —Kusma (t·c) 13:44, 20 September 2019 (UTC)
  • @Kusma: any editor is welcome to participate in any XFD. But you are blatantly AGFing that the deletion of abandoned junk portals has an ulterior motive, and I hope you will retract that. You seem to be trying to votestack by recruiting editors with a particular POV, which is highly disruptive conduct. I hope that you will amend your comment to remind editors that !votes should weigh policy and guideline against the evidence of the nature of the portal under discussion. --BrownHairedGirl (talk) • (contribs) 17:44, 20 September 2019 (UTC)
    BrownHairedGirl, you'll have to help me out and explain to me which ulterior motive I am ascribing and to whom so I know which statement you would like me to retract. As for policy-based voting in portal MfDs, well, in my view, we simply do not have any robust policies that are specifically about portals, which is part of the reason the whole process is so frustrating. You may disagree with that, just like I disagree with your description of my comment as being "highly disruptive conduct", which is a completely unnecessary personal attack. —Kusma (t·c) 19:43, 20 September 2019 (UTC)
  • @Kusma:, I'm pretty sure that you know the answer to all those questions. As to guidelines, we have WP:POG, which has been accepted as the framework for about 800 MFDs now. I am surprised that you missed that.
WP:VOTESTACKING is highly disruptive conduct. Do I need to explain why? If you don't like being criticised for it, then don't do it.
The ulterior motive you are ascribing is to editors who nominate quality portals at MFD. You are presupposing that their aim is to use MFD to one-by-one delete all portals, rather than the stated reason of poor quality of individual portals.
I have no objection to any deleted portal being moved to WP:REFUNDed to project space, and I have never seen any objection to it. I think that in nearly every case a set of a dozen decade-old content forks is thoroughly useless to editors .. but if someone wants to memorialise them, I don't see it doing any harm so long as they stay firmly in project space. Most of them contain woefully outdated text, which is not checked for errors, and it does harm readers and Wikipedia to continue to lure readers to such junk. --BrownHairedGirl (talk) • (contribs) 20:32, 20 September 2019 (UTC)
BrownHairedGirl, I honestly didn't know the answers to my questions, which is why I asked them. I am not convinced that portal MFDs are truly only about the lack of quality in outdated portals, as I have seen attempts to fix the quality issues during MFDs being dismissed and the portal ending up deleted anyway. My suggestion to come to MFD every now and then is as visible to portal lovers as it is to portal haters, which I also invite to come to MFD so consensus can become clearer. WP:POG was not written to be a guideline about which portals to keep and which to delete, but as a guide how to write a portal (originally as a Manual of Style page for portals). I agree that a rough consensus has emerged at MFD that is that portals need to be about a broad subject, be maintained (but what exactly that means isn't clear), and should have some readers. But I disagree that this is what any written guidelines say, and have tried to update the guidelines to reflect the MFD results. On the whole, portals are probably not worth the amount of debate that we have about them, and I wouldn't be terribly sad if we end up merging them all with a relevant wikiproject, as long as we can keep on linking to them from the talk page banners, if that finally results in peace on this front. —Kusma (t·c) 21:15, 20 September 2019 (UTC)
  • Comment - This is going to need its own page again if we are discussing the matter again as it will impact the whole community. - Knowledgekid87 (talk) 14:13, 20 September 2019 (UTC)
Don’t overstate the situation - the reality is that the vast majority of editors do not give a flying flamingo about portals, one way or the other. Indeed most editors probably don’t even know what a portal is. Whether we keep some or delete them all, the decision will impact a very small part of the community. Blueboar (talk) 15:02, 20 September 2019 (UTC)
This isn't true per the long and lengthy discussion we had last time. This needs to be advertised as a major thing as portals are linked on hundreds of thousands of pages. - Knowledgekid87 (talk) 15:15, 20 September 2019 (UTC)
I agree with Knowledgekid, and if it may result in the removal of a namespace or 90% of its pages then we should really advertise it more widely. Certes (talk) 15:05, 20 September 2019 (UTC)
  • Oppose total deletion; we should keep some small number of portals for our broadest and most vital topics. bd2412 T 14:47, 20 September 2019 (UTC)
  • Oppose. Portals provide a place to collate articles, topics,and items of concern that might be highly useful to whatever subset of editors might be useful for editing that topic. For editors interested in a a specific country or locality, we have portals like Relief Map of Caribbean.png Caribbean portal, Flag of Italy.svg Italy portal, Flag of Tuvalu.svg Tuvalu portal, Flag of the United States.svg United States portal, PrefSymbol-Tokyo.svg Tokyo portal. for editors interested in highly relevant topics in, e.g., the natural world, we have portals like Earth Day Flag.png Ecology portal, Aegopodium podagraria1 ies.jpg Environment portal, Issoria lathonia.jpg Biology portal, Drinking water.jpg Water portal, etc. do we need to get rid of them? really? how are they any less helpful than the WikiProjects for those topics? I actually find Portals much more helpful than Wikiprojects, as a centralized place for viewing current articles, topics etc, relating to a particular topic. --Sm8900 (talk) 16:42, 20 September 2019 (UTC)
    • Wikiprojects and Portals are two very different things; the former is editor-facing, designed to aid collaboration and organization; the latter is (ostensibly) a reader-facing system. The problem is that few internet users use portals in general (we are very much in a post-Google world) and the question becomes one of how much they are "worth" versus how much they "cost". Der Wohltemperierte Fuchs talk 17:15, 20 September 2019 (UTC)
  • Oppose. Deleting portals is not improving the wiki. Benjamin (talk) 17:21, 20 September 2019 (UTC)
  • Oppose complete deletion of portals. I would be prepared to support getting rid of most of the ones we have currently, but I think we should keep some:
  • Very high level topics, such as the portals linked on the main page and some others.
  • Portals which don't correspond to articles, such as Portal:Contents, Portal:Featured content, Portal:Current events.
  • I think there is also a role for portals as showcases for collections of very high quality content, e.g. Portal:Battleships. We don't have anything else which shows them off in quite the same way.
The average portal though is little used and doesn't serve a useful purpose. People simply don't look at them. Hut 8.5 18:04, 20 September 2019 (UTC)
  • Question - What is the difference between categorization and portals? What do portals do that isn’t done by cats? Blueboar (talk) 19:53, 20 September 2019 (UTC)
    • @Blueboar: A good portal links to a curated set of high-quality articles and images around a topic, putting them in context and previewing them. They're pften based around Wikipedia's main page, with TFA, PotD, and other sections as are relevant to the topic, letting readers find high-quality content, as the main page does, but more specialised. Adam Cuerden (talk)Has about 6.9% of all FPs 20:23, 20 September 2019 (UTC)
Re "links to a curated set of high-quality articles ... around a topic" - the vast majority of portals have come nowhere near that aspiration. The reality is usually that the portal creator (without any discussion or explanation) picks a few articles (sometimes just one article, sometimes low quality articles, sometimes off-topic articles) and then no-one else ever expands/updates/corrects the set (except, in some cases when an article is deleted). "putting them in context and previewing them" is hardly an accurate description either. DexDor (talk) 21:07, 20 September 2019 (UTC)
DexDor, let us just assume Adam Cuerden is talking about Portal:Opera, which is one of the best portals we have, and about one of the topics most suitable for being shown in portal style, a really impressive work. —Kusma (t·c) 21:23, 20 September 2019 (UTC)
@DexDor and Kusma: As someone who has made and helped to make portals before, in the period they were being made, that was always the goal. I'd imagine most of the former featured portals (if they hadn't gotten overwritten in the bot creation of portals - the overwriting of formerly good portals with automatically created ones has definitely pulled down the quality) had that goal. Portal:Opera is an excellent example of what Featured portals, and thus all portals, tried to be. Adam Cuerden (talk)Has about 6.9% of all FPs 00:02, 21 September 2019 (UTC)
So I've had a look at Portal:Opera and still don't see how claims like "putting [articles] in context" can be supported.  That portal shows a list of "Stubs needing expansion" that has not been updated for over 10 years; either editors are not expanding those stubs or not updating the list. Now, I wouldn't argue that that means that Portal:Opera (in isolation) should be deleted, but it does demonstrate how even "good" portals are more about show than about actually being used. DexDor (talk) 06:08, 21 September 2019 (UTC)
Oops. Struck per comment below. DexDor (talk) 16:15, 21 September 2019 (UTC)
DexDor, the list of "Stubs needing expansion" on Portal:Opera does not require updating. The links are to categories which are updated immediately when a stub tag is added or removed from an article. They do not link to manually compiled lists. In fact, none of the tasks listed in "Things you can do" require manual maintenance. The only manual maintenance we do is adding new FAs, FPs, GAs, and DYKs when they reach that status. Voceditenore (talk) 14:53, 21 September 2019 (UTC)
I also took a look at Portal:Opera, and I also strongly disagree with Adam Cuerden. It's not broken and not full of redlinks, and has a few more articles than most of the bad portals, but that's about it.
As to it being an excellent example of what Featured portals, and thus all portals, tried to be ... heaven help us.
Take a look at WP:Featured portal candidates/Portal:Opera. That's a round of morale boosting in a pub chat, not assessment. There is no structured checking of listed points of evaluation, no measurable criteria, nothing. Just some discussion of the length of excerpts, and lots of air-kissing like "great and lovely portal" and "well built and beautiful portal".
As to "putting [articles] in context", that's nonsense. It just shows lead excerpts one at time, with no indication of why they were chosen, and not even a visible list of other titles. The purge-page-for-new-random-selection thing is such an extreme usability fail that it would laughable if it wasn't for the fact that some editors think this is an acceptable way of presenting a list. Sure, that's the std structure portal, but bluntly, it's a completely crap structure which has persisted only because portals were long ago abandoned by most editors, becoming the playground of a small set of editors who adopted uncritical groupthink, and who resent outsiders who try to inject some reality.
So it's wholly unsurprising that the portal got only 24 daily pageviews in the first half of 2019, while the head article averaged 1,438. Reader's don't waste their time on pages like that, which in practice exist only as hobby pages for a few editors. The head article does a vastly better job of navigation and showcasing.
As to the overwriting of formerly good portals with automatically created ones, the last such automation of a pre-existing portal was reverted in May. Many editors were involved, and I personally used a set of tools to identify and eliminate every last such automation. On reversion, it was clear why they had been automated: most of them were abandoned junk, and huge numbers were subsequently deleted. --BrownHairedGirl (talk) • (contribs) 15:33, 21 September 2019 (UTC)
Just a note about a couple of assertions made above:
1. Concerning the Featured Portal candidate process, i.e. There is no structured checking of listed points of evaluation, no measurable criteria, nothing. The participants in the Portal:Opera discussion were measuring the portal against Wikipedia:Featured portal criteria. If they found any aspect which did not match those criteria, they mentioned it in the discussion. If not, they did not. I suppose they could have explicitly added "Meets all the Featured portal criteria", but that was implicit in the discussion
2. Concerning Portal:Opera having not even a visible list of other titles. At the bottom of each section on the left-hand side is a link More X which takes the reader to the complete list of articles, pictures, sounds, etc. in that section. For example, More featured pictures takes you to the complete list of pictures included in the portal which states at the top the criteria for inclusion. More selected articles takes the reader to the complete list of selected articles, which again states the criteria for selection at the top.
Voceditenore (talk) 06:00, 22 September 2019 (UTC)
There's a good point about what would attract a reader to visit a portal. The quality of one isolated portal isn't a draw for an initial visit, because the reader doesn't know its quality beforehand (although it will influence revisits). The collective quality of portals, however, will affect whether or not readers will choose to follow a link to a portal, since they will extrapolate from their past experiences with other portals. Wikipedia would be a lot less successful, for instance, if nearly all of its articles were stubs. So although there is no deadline to improve any page, there is a practical consideration in trying to establish a baseline median level of quality that is sufficiently high to attract readers to visit other portals. isaacl (talk) 16:29, 21 September 2019 (UTC)
P.S. Blueboar might like to also consider pages such as Index of United States-related articles which are more of a fork of categorization (and, incidentally, were often created by the same editors who created portals). DexDor (talk) 21:15, 20 September 2019 (UTC)


Section break 3

  • Oppose. Portals are the best venue for active WikiProjects to display their work as a project. My experience with Portal:Opera with WP:WikiProject Opera is that it is a space that builds camaraderie, community, inspiration, and motivation (especially in generating better and more content) within our particular group. The encyclopedia benefits from portals, and I can see no value in deleting them.4meter4 (talk) 21:27, 20 September 2019 (UTC)
    • Where the purpose is for displaying WikiProject work, they should be located as a WikiProject subpage. —SmokeyJoe (talk) 06:29, 21 September 2019 (UTC)
      • @SmokeyJoe:, with respect, I disagree with suggestion above. there is no logic to taking something that is considered valid in its own right, and then moving it to a valid namespace that is less visible, simply because one considers it less important. Sm8900 (talk) 13:11, 23 September 2019 (UTC)
        • Sm8900, Portals currently have no validity. They fail their ostensible purpose as a navigation aid. You may consider them as useful for browsing, but browsing is not navigation. Portals do not serve readers, either in theory of service, or facts of pageviews. So, are they worthless? No, they are negative, because for the few readers sucked in, they are presented with unsourced NPOV violating presentations of what editors think is important. To the extent that portals showcase WikiProject work, plausible but dubious as both are mostly inactive, they belong in not reader facing projectspace pages. —SmokeyJoe (talk) 13:19, 23 September 2019 (UTC)
  • Support deleting portal space which actually isn't the same thing as deleting all portals. It doesn't need a separate namespace. I support deleting almost all portals, too, along the lines of SmokeyJoe's proposal above. Levivich 01:18, 21 September 2019 (UTC)
  • Support Over 850 portals (over 50% of the pre-TTH spam portals) have already been deleted for being abandoned failures of WP:POG. My experience at hundreds of portal MfD's that closed as delete is that nearly all portals are abandoned relics of past editors' momentary enthusiasm, and that there is 15 years of hard evidence that by any sane metric, the Portals Project has been a complete disaster. Very few portals have even a single maintainer (and POG requires multiple maintainers), let alone large numbers of readers, at least 20 articles, or WikiProject involvement. Why force editors to waste their time going through the rest one by one when it's clear as day that portals are a failed solution in search of a problem?
Head articles, with vastly higher readership and quality then their associated portals, and their very common rich and versatile navboxes are all we need on Wikipedia. It's time to end this farce, and the disgrace that a brilliant editor like @BrownHairedGirl has spent over a thousand hours cleaning up the sewage in Portal space only to realize that there is no bottom to the barrel. This is just what Portal space is. I don't oppose the top 10 portals being moved elsewhere, but the rest of Portal space should be deleted. Newshunter12 (talk) 21:03, 21 September 2019 (UTC)
Newshunter12, Why force editors to waste their time going through the rest one by one when it's clear as day that portals are a failed solution in search of a problem? First of all, most of the remaining portals are a lot better than those that have already been deleted, so we could also just keep all of the rest and not do any further MFDs, and we certainly shouldn't use the fact that worse pages exist to delete something like Portal:Opera.
If anybody forces you to go through the list of portals one by one, they should be told off. Participating in portal MFDs is a volunteer activity, just like maintaining portals is. I also would like to remind you that WP:IWORKEDSOHARD is not only not a valid reason to keep articles, it is also not a valid reason to delete entire namespaces.
Portals duplicate some functions of some other navigational aids, and duplicate some functions of WikiProjects. Their viewership is fairly low, just like the number of pageviews of many other navigational pages (outlines, categories) or of Wikiprojects is low. That is not necessarily a problem, as long as the viewers that are there get something good.
And there is one other aspect: It is a disgrace how brilliant editors like, say, User:Juliancolton are treated with disrespect just because they have created a portal in the past and no longer update it. —Kusma (t·c) 13:02, 22 September 2019 (UTC)
@Kusma Your statement doesn't reflect reality. Over 850 junk portals failing WP:POG have already been deleted and there is no end in sight to the number of junk portals that remain because portal space is and has always been a complete disaster. No, I am not required to clean up this enormous mess created by editors like Juliancolton (who you should not have canvassed, by the way), who heedlessly created and dumped portals in defiance of WP:POG's clear lead since 2006: "Do not expect other editors to maintain a portal you create". The editor in question then refused to accept personal reasonability for their own reckless actions and deserved any criticism they got.
Portal:Opera isn't complete crud, but as described by @BrownHairedGirl above, it's terribly structured and has low page views. At best, it's a not yet abandoned hobby page and a time suck for readers lured there who would be much better served by the head article, not some glorious contribution to the encyclopedia that merits keeping all junk portals so this one can have pals. Given the stark facts about Portal space, it's not unreasonable to mention that no more of the clean-up-crews time should be wasted to please the whims of a few portal fans who don't care about reality. I'll say it again: There is 15 years of hard evidence that Portal space is a complete disaster by any sane metric, and is a failed solution in search of a problem. Newshunter12 (talk) 21:09, 22 September 2019 (UTC)
  • Strong Oppose The original proposal starts from a somewhat holier-than-thou perspective that the existence of portals is objectionable and that they must be eradicated because "editors who see no value in portals" have to keep putting them up for deletion. What one person finds useless, others may find highly useful and a wholesale deletion for the convenience of a few who find them troubling seems unwarranted. The enthusiastic drive for an automated process of portal creation some months back certainly led to creation of a crop of portals that were of narrow interest and of, possibly, minor value; however, that does not invalidate a portal's value as a jumping-off point for users interested in a topic to find other articles in the same subject area. A good portal, such as Portal:Opera or Portal:London transport, gives a curated collection of information that is not otherwise easily accessed. Suggestions that a portal's daily pageviews is an indication of their value is risible; to assume that something that is little read is of no value is flawed. On that basis, substantial parts of Wikipedia could be deleted including large numbers of featured and good articles. Should we then start deleting obscure featured articles such as Wage reform in the Soviet Union, 1956–1962 (37 page views per day), 1860 Boden Professor of Sanskrit election (18 page views per day) or The Boat Race 1993 (12 page views per day).--DavidCane (talk) 14:38, 22 September 2019 (UTC)
  • Oppose. My views on this have not changed since the 2018 RFC that proposed the exact same thing, so I will simply rework what I said there for the purposes of this RFC: Oppose wholesale removal entire portal system and favor (continued) case-by-case review. If a particular portal sucks, improve it or get rid of it, using existing procedures (including proper notice on the portal's talk page). If a portal is well constructed, leave it alone (or improve it further, like anything else). As with the 2018 RFC, most portals seem not to have been notified of their impending demise until 2 days into this discussion. Full disclosure: I have worked on Portal:Mathematics content quite a bit in the past, and continue to monitor it today, which is how I came to find out about this RFC today (thanks to Voceditenore). - dcljr (talk) 00:29, 23 September 2019 (UTC)
I was pretty astounded that such a wide-ranging proposal to delete an entire project space and its contents was not even alerted to the principal stake-holders by the proposer:
1. Wikipedians at large (no RfC notice—it was added 3 days later by another editor, was subsequently removed by a different editor with the rationale remove RFC tag. per WP:RFC, and RF should be opens with "a brief, neutral statement of or question about the issue". This one open with a partisan diatribe. It has subsequently been re-added by yet another editor on the basis that it begins with a neutral statement and time stamp. All of which begs the question: If this is not an official RfC, what is the purpose or force of this discussion?)
2. WikiProject Portals (added the next day by another editor)
3. Affected portals (Yesterday, I notified the talk pages of most Portals with a designated maintainer)
4. Associated WikiProjects (Today, I notified the active WikiProjects who had bannered the above portals. If there were multiple projects, I notified only the most relevant one.)
I found out about this discussion only via an early notice at WikiProject Opera by one of our members. Most editors who concentrate on content do not keep pages like the Village Pump on watch. Plus, there are so many edits to this page for multiple proposals, that this proposal is easy to miss. Voceditenore (talk) 10:46, 23 September 2019 (UTC)
  • Support namespace decrepitation deprecation for the 3rd time in 3 years (move content portals to main namespace) Do not support deletion at the deletion board by a few editor's (have been vocal about this fact but to no avail). Also would be best if the portal project - if any left after this talk - is not dominated by those in favor of deletion as this has proven detrimental to any moment forward on anything related to portal improvements, guideline improvements. etc.--Moxy 🍁 00:39, 23 September 2019 (UTC)
Moxy, did you mean deprecation? Voceditenore (talk) 10:51, 23 September 2019 (UTC)</nowiki>
Yes thank you--Moxy 🍁 11:30, 23 September 2019 (UTC)
One could make the argument that decrepitation of the Portal namespace has been ongoing for years... rdfox 76 (talk) 13:32, 23 September 2019 (UTC)

Section break 4

  • Strong Oppose because of logical fallacy (faulty generalization) in the justification. The nominator said portals continue to be deleted at a rate - currently about 100 per month - that means within a year they will cease to exist or there will be so few that it will be pointless maintaining portal space. Citing numbers is cute and sounds convincing, but the proposal made a cruical, yet erroneous assumption that all existing portals are of identical quality or that all are failing an existing criteria such that none of them will survive a trip to XfD. The assumption, according to this nom, justifies a nuclear option on all portals other than the "big 3" (Portal:Contents, Portal:Current events and Portal:Featured content). It is quite clear from many examples raised above (Portal:United States, Portal:Opera amongst others) that many portals are not in the same group as the now-deleted mass-created portals. Furthermore, it assumes a linear rate of deletion with complete disregard on the quality of the "surviving" portals until none is left. Proposal doesn't consider the diminishing returns of poor-quality portals being listed on XfDs, which will eventually leave high-quality portals remaining. OhanaUnitedTalk page 00:51, 23 September 2019 (UTC)
@OhanaUnited Please see my vote just a little ways up. There is 15 years of hard evidence that the Portals Project has been a complete disaster by any sane metric. Over 850 pre-TTH spam portals (so over 50% of portals, not counting the spam) have already been deleted one by one in the past six months for being abandoned (often for a decade or more) failures of WP:POG. This RfC was started by a portal fan, so they didn't create the best starting rational, but please see past that to the bigger picture. That a few portals like Portal:Opera still have fans is inconsequential. That hobby-portal, with a terribly inefficient page structure and low number of views, could be moved to project space with virtually no changes, so it should not be used as an excuse to keep all portals. As a group, portal viewing rates have been going down sharply for years (perhaps @BrownHairedGirl could give us some hard data on that). All the hard data points to Portals being a disaster on Wikipedia from the start, so please reconsider your vote and help end this problem and enormous time suck once and for all. Newshunter12 (talk) 04:28, 23 September 2019 (UTC)
@OhanaUnited: There is no logical fallacy, because the pageview statistics are being used at MfD, and NO subject-area portal meets the pageview requirements that are being imposed in the MfD discussions. Even quality portals such as Portal:Antarctica were deleted on the pageview basis, and Portal:United States and Portal:Opera will surely follow. Unless of course editors who believe otherwise could bring themselves to contribute to the MfD discussions. But so far, nothing. UnitedStatesian (talk) 04:39, 23 September 2019 (UTC)
@OhanaUnited @UnitedStatesian That's not true and you know it, UnitedStatesian. As Wikipedia:Miscellany for deletion/Portal:Antarctica clearly shows, that portal had been abandoned for over a decade and was in abysmal shape until nearly a week into the MfD, in under 40 minutes you slapped together some automated add-ons and put them in the portal, claiming all is well now. The closer rightly ignored your disruption and games. Please stop trying deceive editors with know falsehoods, and while we're on that topic, please stop trying to stack votes at MfD. Newshunter12 (talk) 04:57, 23 September 2019 (UTC)
@Newshunter12: You have missed my point, which is that no MfD so far has found a subject-area portal that meets the pageview requirements of WP:POG, as that requirement is currently being interpreted at MfD. I am confident you will be unable here to give an example of any such currently existing portal that meets the requirement. And I never wrote "all was well" with Portal:Antarctica; of course that portal would need further ongoing maintenance. I was only curious why the !delete voters and the closing admin. seem never to have read WP:ATD. UnitedStatesian (talk) 05:10, 23 September 2019 (UTC)
@UnitedStatesian I clearly didn't imply "all is well" was a direct quote and portals need ongoing maintenance, which that portal lacked for over a decade, not one-off updates at MfD. No, off the top of my head, I don't have a portal in mind because all of the hundreds I have examined at MfD have been generally all around crud, even top 45 in views portals like Portal:Death. However well intentioned, portals are a failed enterprise on Wikipedia (and on the web, writ large), and should be done away with. That Portal space has failed for 15 years is not the fault of the present informal clean-up crew, and if editors like you could finally let go of portals, it would make Wikipeida a better place and save us all a considerable amount of time. Readers read articles, not portals. Newshunter12 (talk) 05:43, 23 September 2019 (UTC)
But unfortunately it is not just me that needs to let go (if it were I would do so in an instant). This RfC so far makes clear we will be stuck with portals for a while longer, maybe forever (though I find one of many ironies that so many editors who here oppose deletion of the portalspace - not all, of course, but many - apparently do not want to make any contributions to it: that's Wikipedia for you). As long as that is the case, the portalspace should be the best it can possibly be, which is why I continue to make edits (a LOT of edits) to some of the portals that remain. It's also why I have nominated a LOT of the narrow-subject portals for deletion, and will continue to do so. Neither of these efforts are a waste of my time. Let's say I agree with you, that portals "should be done away with" (note: I have not yet opposed this proposal). What should I then do, given that the community clearly feels differently? Is it a waste of time for someone to continue pursuing an all-portal deletion effort if that end state has been rejected by community consensus? UnitedStatesian (talk) 06:21, 23 September 2019 (UTC)
@UnitedStatesian Interesting points. I agree that it is a great irony that so many oppose voters don't contribute to Portal space writ large. The sad reality is that unless this RfC eliminates Portal space, the one by one cleanup effort will continue. We've clashed at times, but you seem like an over-all reasonable, rational person. All the hard data shows portals have failed, and observation shows that those who want to keep portals both don't understand that failure and don't care enough to maintain portals writ large. I honestly think that a one by one evaluation of all remaining portals will show that very few portals meet reasonable maintenance, readership, WikiProject/editor involvement, efficient page design and broadness expectations.
Portals are not unlike how the Articles of Confederation were in the U.S. It didn't work and there was no system to replace it, so they just drafted the Constitution anyway. Our RfC system for dealing with this issue hasn't been working, but deleting junk portals one by one is. The vast majority of portals were abandoned years ago or have almost no views, and portals have a small and declining viewership. I think it would be wiser if you stopped trying to maintain portals and just focused on the cleanup effort, which is where long-term on the ground reality is. Once portal space is in all likelihood down to only a small number of pages, it won't be able to hide from its fate anymore.
It's not so much that I feel that I have been wasting my time, but that this by-the-book one at a time is so tedious for all of us when no one besides MfD regulars (you, me, etc) truly cares (through actions) about Portal space at large. Interest in even a single portal is rare, and you alone are carrying a huge amount of water in a desert of portal-abandonment. Why not just help vacuum that sand up and see what's really left at the end when you're not holding it together? After all, if portal space ultimately = your work and 20-30 other active pages of reasonable quality and above 20 views per day, why keep polishing the whole room? Newshunter12 (talk) 08:22, 23 September 2019 (UTC)
WP:VOLUNTARY you are not being compelled to work on portals. All the best: Rich Farmbrough, 20:18, 18 October 2019 (UTC).
  • Strong Oppose: Portals are useful tools for browsing wikipedia focusing on broad topics of interest. The entire proposition of deleting portals to save editor’s time (as appears to be the main contention of the original proposer) is misguided. If saving editor time is the priority that would imply we should consider deleting the entire Wikipedia. The advocates against portal are repeatedly failing to appreciate that there are significant number of users who use Portals, care about them and are ready to work on improving them. Instead of deleting Portal namspace, the community may decide on a criteria for establishing required minimum importance/ breadth of a topic area for creating / keeping a portal and a certain quality benchmark before reaching which portals can be mandated to flag a “Draft” status. But getting rid of the portals altogether would be counterproductive and a serios blow to the appeal of Wikipedia.
Also the advocates against portals are frequently sighting poor page view count as a justification for deleting portals or atleast for proving that they are useless. The spirit of wikipedia is against the valuation of any item based on view count. If we go by that route, we will definitely bring in bias towards "popular" topics and items. A specialized portal may be useful to a handful of readers who come to wikipedia to explore within a specific topic area and these group of readers would often produce editors who are willing and able to contribute in that specialized area. Thus Portals can play a significant role in attracting readers and nurturing potential contributors in focused subject areas. Although limited in number such readers and contributors are valuable for wikipedia. [N.B: I posted a similar comment earlier apparently on a wrong thread which now seems to have been closed.] Arman (Talk) 06:50, 23 September 2019 (UTC)
  • Mild dislike - I believe there may be some value in some of the portals, even though I barely ever use or maintain any of them. There seems to be an organised process under way to remove the least-value portals at a rate where this proposal might be worth revisiting in 6-9 months. As an Australian editor, I'd support removing all of the Australian state/city portals, but maybe we can make the top-level Australia one worth soemthing. If we try and fail, then this proposal might be worth revisiting. --Scott Davis Talk 12:44, 23 September 2019 (UTC)
  • Oppose While the overwelming majority of portals are basically useless there are a few that offer some value. Deleting the whole namespace is the wrong way of handling it. --Trialpears (talk) 13:38, 23 September 2019 (UTC)
  • Support - delete Portals. I do not find them useful, when compared to the Navbars and even to the Categories. Rowan Forest (talk) 15:02, 23 September 2019 (UTC)
  • Oppose Since WP:NOTPAPER it's better to just keep them. --Janke | Talk 19:50, 23 September 2019 (UTC)
  • Oppose they carry a piece of Wikipedias history, they should just be marked as historical and retained. Portals were seen as a way to bring people into specific areas of Wikipedia, some worked and still continue to do so, others didn't. As a concept it was something the community tried, it's potential to further develop as a concept is there especially as more topic specific affiliates are being created. There is no reason to delete our history
  • Support: I find portals generally redundant and not very useful, plus the support for their creation and maintenance is too low to merit existence anymore. Concentrating editor content efforts into article space benefits Wikipedia as a whole. One good article is better than an okay article and a mediocre portal on the same topic. Some way of archival may be preferable to an outright deletion that loses the history. — MarkH21 (talk) 11:23, 24 September 2019 (UTC)
  • Support superseding portal namespace, but oppose deleting every single portal. On the one hand, some portals, such as Portal:Current events would work better under a subpage of Wikipedia:WikiProject Current events since it's among the most-viewed portals. On the other hand, though, I honestly don't see how portals really benefit anyone. They may have been interesting in 1995, but today the power of logistic-based search engines significantly undercuts their purpose. I also don't understand what historical purpose they would provide, if at all. ToThAc (talk) 22:29, 24 September 2019 (UTC)
  • This proposal is not clear. "Deleting the namespace" would just mean that all pages, existing or deleted, are moved to another namespace. Because of how MediaWiki works, you'd need to decide a new prefix to which to move all the pages (Wikipedia:Contents/?), otherwise they'll end up in main namespace. The effect of an unclear alarmist proposal is only that we waste a lot of time discussing something which won't happen, while possibly disrupting the ordinate work happening on portals. Nemo 05:32, 26 September 2019 (UTC)
  • Comment An RfC has just closed with a clear consensus that the "Portal guidelines" are not, in fact, official guidelines. The "guidelines" have been cited in 878 Portal MfDs (including one which deleted 1390 portals). This clarification finally removes the cornerstone of the argument for removing portals and their namespace. Certes (talk) 09:30, 26 September 2019 (UTC)
    • Nonsense. The page was a proposed guideline that never gained consensus, and therefore is a {{failed}} guideline. It is sneakily mistagged, a fake guideline, providing a fake foundation of the following uncontrolled creation of ill-considered portals. The many MfDs poked ridicule at the worst of the portals by pointing out that they didn’t even meet the very loose guidance of the fake guideline. To move forward from here, we need an agreement in the purpose of a portal. —SmokeyJoe (talk) 10:56, 26 September 2019 (UTC)
  • Comment - At a time when discussing the abandonment of portals, we should also discuss whether their privileged position on the main page is deserved, see Talk:Main Page#General discussion.Guilherme Burn (talk) 13:39, 26 September 2019 (UTC)
  • I'd keep the most important ones like the main page and current events. Possibly a solution would be to restrict the ability to create them to new page reviewers (meaning they can be created through AFC) and template editors but given it appears many have been created by experienced users this would probably cause more problems than it would solve. I think the point is though that they shouldn't be mass created (unlike articles) and things like WP:RUBBISH, WP:NEGLECT and WP:OUTDATED don't apply as much with portals. Crouch, Swale (talk) 14:08, 26 September 2019 (UTC)
  • Mostly support deletion, keep a few exceptions; keep the 3 exceptions mentioned by others (e.g. Featured Content) + the 8 broad topic portals linked on the main page. Note that this proposal is offered by a fan of Portals and seems to be some sort of rallying cry to confirm that the community still likes Portals? But that's not the same as liking abandoned, unused portals with 20 views a month. So even if this proposal "fails" (as nominator intends), that's hardly a sign that recent Portal MFDs were "wrong." It is probably mostly harmless if a few subject-specific portals are maintained as hobby projects, but all the other portals are an insidious honey trap - they offer some "work" for volunteers to do that seems cool, but is actually of almost no relevance whatsoever, because the sad truth is that readers hardly ever visit Portals. A little-used encyclopedia article is fine; a little-used meta navigational aid, however, is useless. SnowFire (talk) 17:05, 26 September 2019 (UTC)
  • Oppose: some portals are worth keeping and these should be continued to be housed in the Portal namespace. This seems like just a second RfC on whether to delete all portals, which we've already got consensus against doing, and I don't see that changing. A more useful RfC might be to speedily delete, say, all portals with <100 pageviews per month, but I doubt that would get consensus, and quite frankly though it's not a great situation, I don't see anything better than the status quo of slowly MfDing off the portals which are not useful. — Bilorv (talk) 22:22, 26 September 2019 (UTC)
  • Support - Portals are not useful. Delete them. Kaldari (talk) 18:59, 27 September 2019 (UTC)
  • Support with a few exceptions as detailed a few sections up. I know some people are very passionate about this, but the fact is most portals simply aren't maintained in a way that is actually useful to the reader, the people that all this is supposed to be for. That so many of them have been successfully deleted in recent months is in fact relevant as it goes right to this point. Beeblebrox (talk) 04:29, 28 September 2019 (UTC)
  • oppose I think they have a lot of potential and some are quite good. I'd rather see them raised in stature than deleted. Hobit (talk) 17:27, 29 September 2019 (UTC)
  • Oppose some users, perhaps many or even most users, do not find portals useful. But we are not in the habit of deleting content simply because most people don't use it. Now that we are satisfactorily dealing with the portal spam issues, it seems like it is time for those who are heavily interested to invest their energies in improving the current contents of portalspace. Lepricavark (talk) 04:30, 30 September 2019 (UTC)
  • Support per Beeblebrox. Organize the organized organization to organize ... ENOUGH — Ched (talk) 12:00, 30 September 2019 (UTC)
  • Oppose full deletion, support deprecation and thinning, basically on the lines of BrownHairedGirl; we should definitely keep the eight broad topics, the current events portal, and there are some portal concepts that, with decent curation and active WikiProjects, might be worth saving (like, maybe, Portal:Music, Portal:Military history, Portal:Sports), but a lot of the portals we currently have are are too specific and their lack of readership or curation shows. Sceptre (talk) 14:21, 30 September 2019 (UTC)
  • Support deleting all non-major portals and deprecation of the Portal: namespace - at this point the Portal: namespace is a sinking ship (Rschen7754 points out the downward spiral perfectly). We should scrap the Portal: namespace and move all the portal pages worth keeping to the Special: space - moving those portals there seems to make the most sense to me. I opposed its deletion about a year ago - but I now see the problem has only gotten worse. Kirbanzo (userpage - talk - contribs) 14:42, 30 September 2019 (UTC)
    "Special" is a virtual namespace: it is used as a common prefix for pages that are created on demand. isaacl (talk) 16:47, 1 October 2019 (UTC)
  • Comment: Can an admin or other users go around tagging portals, like last time? Kirbanzo (userpage - talk - contribs) 14:42, 30 September 2019 (UTC)
    • No, please. We don't need yet another circus like last time. There is no need to advertise a vague proposal which may or may not affect the individual page. (See my comment "This proposal is not clear" above.) Nemo 11:23, 2 October 2019 (UTC)
      As you say above, we need to be clear about what would happen to portals if the namespace were removed. If any variant of the proposal would result in bulk deletion then we need to advertise it on all portals. If the intention is to unlink them all then we should probably notify interested editors too. If it's just a technical change to store portals elsewhere and retain the links, that's less disruptive, but I don't see its advantages. Certes (talk) 12:32, 2 October 2019 (UTC)
  • Strong Oppose Portals are inherently useful in looking into a topic, in ways that categories or navboxes might technically not cover, and are the most reader-friendly way of looking into a topic, far better than categories, books, navboxes, or anything similar. Low readership is due to difficulties accessing on mobile view and the Wikipedia app, the fact that portals are so low down in the article, and poor use among articles - readers are not as familiar with this tool as they should be, and it's just decreasing as important portal subjects are being deleted. ɱ (talk) 00:04, 3 October 2019 (UTC)
  • Oppose the deletion of portal space (again). I believe that portals still serve a useful function on Wikipedia, and should be retained. Tools and processes for managing the namespace continue to be developed, and once the deletions have run their course (and we can agree on proper guidelines), work can resume on improving and fixing the namespace. — AfroThundr (u · t · c) 04:08, 3 October 2019 (UTC)
  • Oppose in general and particularly as written. Portals were never meant to be simply navigation tools. They were and are principally meant, like the Main Page, to showcase the best that Wikipedia has to offer in that subject via the "Selected article", "Selected biography" "Featured picture" sections (all of which should contain only items of FP, FA, or GA status). They are also meant to pique the reader's interest into some of the lesser-known byways of the subject via the "Selected anniversaries" and "Did you know?" sections, and a properly contextualised "Featured picture" section. However, the well-constructed ones (ones that achieved Featured Portal status under the now-discontinued system) have as key components a section with links to the principal topics of the portal's subject and a well-constructed category tree which makes browsing the subject's categories much more efficient. Are there many abandoned and very poor quality portals? Without a doubt. They probably should be taken to MfD. Having said that, there are hundreds of articles which haven't been touched by a human hand for nearly ten years, many of them tagged for no references or worse, yet there seems to be no push to eliminate them. And as for the number of page views argument, so what? I specialise in 18th- and 19th-century opera subjects, e.g. Margherita Zenoni, Giovanni Emanuele Bidera, Don Checco, etc.. They get at most 1 or 2 views a day (most of which are people simply adding categories, etc. or possibly me). But, if only one person finds those articles useful, I'm happy. If only one person finds Portal:Opera useful and/or it helps pique their interest in the subject, I'm happy. I think it would be a very poor outcome and a loss for our readership to eliminate portals across the board regardless of their quality, or to make them virtually inaccessible to readers by removing links to them from articles. Voceditenore (talk) 09:37, 3 October 2019 (UTC)
  • Oppose The first time it's funny, the next time its not. No, you can not just unilaterally delete the Portalspace with the justification of "at the rate they're going there won't be any to delete soon". Did I read any further than that sentence? Yes. Did I find any betetr reason to mass nuke? Nah. Thanks,L3X1 ◊distænt write◊ 16:22, 3 October 2019 (UTC)
  • Oppose. This is a "throw out the baby with the bathwater" idea, as others have spelled out in detail that I need not repeat.  — AReaderOutThatawayt/c 04:22, 7 October 2019 (UTC)
  • Oppose – For several reasons delineated herein, and also per the well-reasoned commentary by DGG within the thread below titled "Thoughts on the value of portals". North America1000 05:53, 7 October 2019 (UTC)
  • Support While I feel sorry for those who have in good faith attempted to build an maintain them, the fact is portals just don't have the readership and use to justify the timesink they've become for everyone across Wikipedia. And Wikipedia only needs on front page. oknazevad (talk) 18:16, 7 October 2019 (UTC)
  • Support. Move two dozen of the most general (Space, Nature, History, etc., but not individual countries), high-quality, well-maintained portals from Portal:Topic to Wikipedia:Topic_page and link all of them (not just nine) from the main page. These "topic pages" must be re-worked to be as densely packed with information and regularly updated as the main page. Delete the rest and the namespace itself. Less is more. — UnladenSwallow (talk) 01:45, 8 October 2019 (UTC)
  • Oppose per DGG below, and many other opposing editors. I am fairly new to editing, and I am still discovering many aspects of Wikipedia (including all the many forums where decisions are made). There are many ways that content within the mainspace of Wikipedia can be found (categories, lists, projects, portals, links between pages, etc), and there are many articles which do not make full use of all those ways. Rather than getting rid of means of navigating content, I think it would be much better to work towards improving the linking of content. Different navigational methods work for different people, or bring up different possibilities. Adding portals to more articles would surely make portals more useful (or do they just work one way?) and if articles which go through DYK, ITN, OTD, FA on the main page etc have portals added to them, surely they can be automatically added to the equivalent sections on portals, keeping those sections refreshed. RebeccaGreen (talk) 15:49, 8 October 2019 (UTC)
  • Oppose per Rebecca Green and I forget who said this above but basically this is a proposal and solution in search of creating problems. To begin with, the number a pages we are talking about even before the cull is minuscule in the scheme of the pedia, so any argument they cause any detriment, at all, is wholly overblown, and those who do not want to spend time on portals do not have to. But to RebbecaGreen's point, it is well established that people have different learning modalities and different reading styles (do research and learning differently - this is one reason why textbooks present information in prose, lists, boxes, etc., etc., etc., and not just in one way, in multiple ways) Alanscottwalker (talk) 16:02, 8 October 2019 (UTC)
  • Support. Delete all but the ones mentioned by UnitedStatesian. They are useless waste of time, nobody reads them, just few portal-fans edit and maintain them for themselves. I am sorry, but we should take their toys away, and make them do something actually useful. And if anybody leaves Wikipedia because we take away the portals and they never did anything else, sorry, but this no loss. Wikipedia is not a playground for creating pages with no encyclopedic use... ok, seriously, you can maintain them in your userspace, what's the difference? --Piotr Konieczny aka Prokonsul Piotrus| reply here 07:33, 10 October 2019 (UTC)
  • Support Except that it sounds like we should keep the top 3 (or 10 max). Anything that can be mass-created by automated tools is going to be nothing but trouble and full of crap anyway. North8000 (talk) 12:13, 15 October 2019 (UTC)
  • Support - I don't think I've ever been involved in a portal deletion discussion, but I did read some of them and check the related portals. It does seem that this design did not take and for 2019 is very outdated. I'm not against a better design in the future, but for that to happen, a design discussion should be held first and not a patch-work of fixes to try and save some unread portals. --Gonnym (talk) 12:22, 15 October 2019 (UTC)
  • Oppose The idea that pages should or could be deleted en masse if they are maintained by a small number of editors or have a low readership would be quite corrosive to the general working of Wikipedia, which has a long tail of such articles. Consider: the same argument could be used to delete our featured articles because they are typically the work of one or two editors and often the topic is a niche one which usually has few readers. And notice that even our supply of featured articles is drying up as they are not now being written at an adequate pace. We have too many carping critics and not enough contributors. We must promote collaboration and cooperation not cavilling and censorship. Andrew D. (talk) 23:33, 15 October 2019 (UTC)
  • Oppose We needed to go through and delete mass-created portals on topics too narrow to maintain a portal, and that's happened. There were simply too many poorly-created portals. After learning about them, I've found good portals to be exceptionally useful navigational devices and highlighting the best articles of particular WikiProjects. The "useless" support votes frustrate me. A good portal adds value, and we're making improvements on how to keep these maintained without needing a lot of oversight. These shouldn't be deprecated. What we absolutely need are good guidelines going forward, though. SportingFlyer T·C 13:22, 16 October 2019 (UTC)
  • Oppose I am not terribly enamoured of portals (or navboxes, and I even question categories sometimes) but they are potentially useful apparatus, and if they help access content for even a few readers it is ludicrous to delete them. Probably we should be constantly finding better ways to make and maintain them. All the best: Rich Farmbrough, 20:16, 18 October 2019 (UTC).

Intermediate proposal: de-link from article space

Articles with the {{Portal}} template, or perhaps the {{Portal bar}} or {{Portal-inline}} or {{Pbox}}, or in rare cases {{PBIE}} (optimized for portaling with Internet Explorer, in Ireland) tend to link to portals of very dubious relevance, which can't be excused no matter how well-maintained they might be.

Portals have been called the poor man's main page. Indeed, the navigational value of these linking to one from an article is rarely much better than linking back to the actual Main Page (which… I'm amazed to say doesn't happen much) and the self-referentiality is only slightly less than linking directly to the page for whichever WikiProject voted 4–1 to give themselves jurisdiction over the matter. Or indeed, the user page(s) of whoever decided that a former gift shop should link to every decade that the store itself existed (and for which a portal page still exists), that a list of animals is considered Portal:Biography, and that a drive-by shooting falls under the vast umbrella of Portal:War.

I suspect some of these dumb/vague/irrelevant portal links I've found are the result of "upmerging" the incoming links when a more specific portal is deleted. This is probably based on the flawed assumption that every article needs to link to some portal page, and that we should struggle to find the closest match. But I'm here to suggest none of them do. Even if we do let higher-functioning portals continue to exist for a while longer, cataloging the best and worst articles related to… whatever, we should start by retiring the templates above, which are useless clutter more often than not. ―cobaltcigs 23:17, 22 September 2019 (UTC)

  • Interesting. Definitely ought to strike links to bad portals/meaningless connections. Don't know I'd go all-out delete, but a good conversation-starter. Hyperbolick (talk) 23:21, 22 September 2019 (UTC)
  • Oppose complete delinking: baby, bathwater, all that. I fixed your exemplars, and the remaining problematic ones should be fixed via maintenance also. UnitedStatesian (talk) 16:52, 23 September 2019 (UTC)
  • I'd suggest an adjustment/refinement of cobaltcigs's proposal - delink portals from article space and category space (which would include removing from many templates) except retain links from Foobar (article) and (possibly) Category:Foobar to Portal:Foobar. That would remove irrelevant links and reduce watchlist noise (many edits to category pages are tinkering with portal links). DexDor (talk) 11:56, 24 September 2019 (UTC)
    Most of the watchlist noise is temporary, from portals leaving categories and being unlinked on deletion. The proposal would extend that noise to all portals. Certes (talk) 11:00, 25 September 2019 (UTC)
In the longer term it would decrease noise as most articles and categories would then never have portal tags on them. DexDor (talk) 18:58, 25 September 2019 (UTC)
  • Oppose - Not helpful in creating interest. - Knowledgekid87 (talk) 17:42, 24 September 2019 (UTC)
  • Support. If we don't have to see this cruft obscuring the actual content of our articles, it becomes much less important to prevent the cruft-enthusiasts from expanding their collections of cruft. —David Eppstein (talk) 21:11, 24 September 2019 (UTC)
  • Oppose - Not helpful in creating interest and will lower page views unnecessarily. North America1000 21:18, 24 September 2019 (UTC)
  • Oppose delinking. In a way, this is a solution looking for a problem. The whole issue over portals just creates work - even just discussing it - which could better be used for improving and policing the quality of mainspace articles , combating vandalism, and deleting inappropriate articles. Existing portals do not do any harm, neither is it a case of server capacity. Time to put this whole business to bed. Kudpung กุดผึ้ง (talk) 03:18, 25 September 2019 (UTC)
  • Oppose - Agree that links to poorly-thoughtout out portals are not helpful, but as long as we vet the creation of portal to make sure they are appropriately broad, these are extremely helpful to serve as broader topic outline pages. --Masem (t) 03:23, 25 September 2019 (UTC)
  • Partial support. I would suggest that we catalog which portals are in the best shape and which are in the worst shape, and unlink the worst, since there is no point in taking people to garbage. bd2412 T 04:05, 25 September 2019 (UTC)
    A list of portals in good shape would have other benefits for readers. It would also allow editors to resume improving a subset of portals in the knowledge that our work is not about to be deleted. Certes (talk) 11:00, 25 September 2019 (UTC)
"resume improving"?! Many/most portals weren't being maintained (i.e. corrected/updated) let alone improved - whilst more and more low quality portals were being created. For example, one portal said "How is called the Biotechnology branch applied to industrial processes?" for 12 years and referred to a file that had been deleted for 8 years. DexDor (talk) 11:45, 25 September 2019 (UTC)
The MfDs are already culling the list of portals, and I doubt any completely new community process would be more efficient or effective, assuming a consensus could even be developed on what to do/how to do it. --RL0919 (talk) 19:28, 25 September 2019 (UTC)
  • Oppose I can't see how this is helpful. A single navigation link near the bottom hardly "obscure[s] the actual content of articles", as David seems to think, and for those who want to navigate between articles by Portal, let them. Adam Cuerden (talk)Has about 7% of all FPs 11:04, 26 September 2019 (UTC)
  • Comment. Portals are practically de-linked from article space!!! According to the useless, out-of-date WP:POG which has barely changed in 12 years, portals are meant to "attract large numbers of interested readers" (why? they're not articles) yet the only mainspace link that portals "should" have is one from the main topic. One link!!! How did they ever think they would attract lots of readers? The fundamental problem is that POG implies and most editors believe that portals are there to entertain readers yet POG has set up a system that guarantees failure. On the other hand portals have the potential to be very useful navigation aids if, like categories, they are well-linked, and very useful project tools that show coverage and identify where articles need to be created and improved. They can be a showcase, yes, but is frankly a cosmetic add-on. Bermicourt (talk) 08:42, 29 September 2019 (UTC)
    The guidance says To optimise access to portals, each portal should have the following links leading to them:. It doesn't say that these should be the only mainspace links, and I don't believe others have interpreted the guidance in that manner. isaacl (talk) 01:24, 30 September 2019 (UTC)
  • Oppose doesn't make sense to me. Either have the portals and link to them in article space or don't have them at all. They're far less useful if our readers can't find them. Lepricavark (talk) 04:26, 30 September 2019 (UTC)
  • Support deletion of portals with the exception of some 50-100 exceptionally broad and vital topics. It is customary for all major websites to do away with parts of their websites that aren't popular with readers, and are therefore unnecessarily hogging maintenance costs. SD0001 (talk) 17:43, 5 October 2019 (UTC)
  • Oppose. This is a silly WP:SPITE proposal that amounts to "hide from all users a feature I'm not personally fond of, even though others like and use it".  — AReaderOutThatawayt/c 04:26, 7 October 2019 (UTC)
  • Oppose per characterisation of editors requesting deletion as a "small band of determined editors". I'm willing to reconsider if it turns out that's not accurate, but I do not see the value of this approach to ending a contentious debate (or series of debates). Airbornemihir (talk) 04:08, 9 October 2019 (UTC)
  • Support. Too many links to obscure tools obscure useful links to stuff like Commons or Wikivoyage or such. We need to prune links to failed ideas like portals that nobody has any use for. --Piotr Konieczny aka Prokonsul Piotrus| reply here 07:35, 10 October 2019 (UTC)
  • Oppose Each case should be judged on its merits. Grand schemes, one-size-fits-all policies and dramatic gestures are not appropriate now that Wikipedia is so large and complex. Andrew D. (talk) 23:39, 15 October 2019 (UTC)

Significance of mobile Wikipedia to portals

  • Comment - Do we have overall portal usage stats between say 2008 and now? I wonder if the adoption of viewing Wikipedia on a mobile phone makes/made portals less visible? WhisperToMe (talk) 12:02, 23 September 2019 (UTC)
WhisperToMe, I picked 3 Featured Portals at random and did some checking, albeit with a caveat. The mobile version appears to have been released in the Spring of 2014 [5]. The page stats tool was only implemented in July 2015. So I compared each of the three portals for the periods July–December 2015 and July–December 2018.
Portal:Medicine: July–December 2015 – 33,301 page views; July–December 2018 – 18,718 page views
Portal:American Civil War: July–December 2015 – 14,355 page views; July–December 2018 – 9,834 page views
Portal:Horses: July–December 2015 – 3,509 page views; July–December 2018 – 2,410 page views
The introduction of the mobile version and the increasing use of smart phones may have been a factor in the declines noted above. For example, Medicine, the parent article of Portal:Medicine, doesn't display the portal bar at the foot of the page in its mobile version. Nor does it display the footer Navigation box which also links to the portal. Another point is that the article Medicine for the month of September 2019 had 15,072 page views via desk top vs. 23,029 page views via mobile (a significant majority). I imagine the proportions for the articles Horse and American Civil War are similar.
As for the portals themselves on mobile, the quality of the experience can vary. Portal:Horse on mobile is good. Portal:Medicine not so good. The mobile version couldn't cope with a section presenting images as a transcluded random slideshow. Voceditenore (talk) 15:59, 23 September 2019 (UTC)
Thank you so much for the comparisons! It's telling to see the portal views being halved like that, only from 2015. I wonder if people in favor of keeping portals have considered discussing things with the developers of the mobile version of Wikipedia? WhisperToMe (talk) 22:26, 23 September 2019 (UTC)
  • While I'm leaning towards deprecation (not necessarily deletion) of portals, I'm wondering that instead of yet another end portals RfC, if instead there could be an RfC to reform the Portals process first. Like, perhaps more stringent standards for Portals, or a more thorough implementation of the Portal creation/maintenance guidelines? From what I can tell, while many are opposed to deprecating portal space as a whole, editors seem to be open to the idea of some kind of compromise: i.e. keep some but not all portals. On the other hand, in some cases that I've seen in the past (particularly around the time WP:ENDPORTALS took place), even when portals were kept, many ended up going back into inactivity. Perhaps, instead of this RfC, there should have been some systematic drive to reform the portals process, make them more active, while taking into account the concerns raised before regarding the "portal spam" and the apparently inadequately implemented automation? Then if that failed, only then would it have been the time to have ENDPORTALS 2.0? Narutolovehinata5 tccsdnew 14:59, 23 September 2019 (UTC)
Mentioned during many deletion talks was the fact that {{Portal-inline}} is visible in mobile view.....we were hoping that during cleanup (portal replacement after deletion) that the inline version would be used...but there seems no interest by those involved to help make portals visible for all.--Moxy 🍁 11:26, 25 September 2019 (UTC)

Alt-Proposal 1 to total deletion of Portal space

Proposal withdrawn by proposer - Knowledgekid87 (talk) 17:34, 22 September 2019 (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.

Pinging all editors who have participated in this discussion so far: @Bermicourt @UnitedStatesian @Hyperbolick @BrownHairedGirl @Hecato @David Fuchs @Certes @cobaltcigs @CodeLyoko @Mark Schierbecker @SmokeyJoe @Kingsif @Mr rnddude @DexDor @Guilherme Burn @Adam Cuerden @Kusma @Masem @Knowledgekid87 @Blueboar @BD2412 @Sm8900 @Benjamin @Hut 8.5 @4meter4

Since there seems to be overwhelming agreement among editors that the vast majority of existing portals are useless, I'm proposing a clearer deletion cut off to move the discussion along. My proposal is this: All currently existing portals be deleted, except for the top 75 portals in views from January 1 to September 1 2019. This will eliminate the vast majority of the abandoned/unused portals in existence today, and give the highest viewed portals the chance for individual evaluations or new maintenance plans to be crafted, as has already been happening at MfD for many months. Any of the deleted portals, such as Portal:Opera, may be moved to project space upon request (or before deletion) for use by editors, but with the understanding that they may not be returned to portal space. This is not meant to be a complete re-hash of the above discussion, but to advance that discussion to the next stage, so please try to keep brevity in mind when replying either way, so that it is easier to ascertain baseline support. I obviously Support this proposal per my reasoning at over 200 portal MfD's. Newshunter12 (talk) 22:54, 20 September 2019 (UTC)

Struck this side proposal of mine since it's clear the community doesn't want it and it's serving only as a distraction to the above discussion. I removed the RfC tag as this was never meant to be an RfC of its own, just a next-step continuation of the above discussion. Newshunter12 (talk) 09:06, 22 September 2019 (UTC)
  • I'd learn toward keeping more, rather than fewer, and would prefer moving to project space over deletion. Benjamin (talk) 22:56, 20 September 2019 (UTC)
    • Agree with moving over. In fact, would undelete all recently deleted portals with history (ie more than one editor doing real work on it) and move those to some space for historical preservation. Hyperbolick (talk) 23:05, 20 September 2019 (UTC)
      • @Hyperbolick Your getting into contentious new ideas here and above. Please stay focused on the proposal I put forward and strike your new proposals. @Benjamin Six months of MfD and over 850 deleted abandoned/low view portals with no end in sight speaks to how few topics can sustain a quality portal. Newshunter12 (talk) 23:32, 20 September 2019 (UTC)
        • Count my counterproposal as an oppose like those below, then, as I wouldn’t delete important portals over pageviews. Hyperbolick (talk) 23:46, 20 September 2019 (UTC)
          • Sigh. @Hyperbolick, you are presently voting twice now in this section (keep! and oppose!). Please strike one, as you only get one vote. Portals with low page views are overwhelmingly abandoned crud by a huge margin, as six months of MfD has shown. Newshunter12 (talk) 00:03, 21 September 2019 (UTC)
  • Oppose. Just because a portal isn't viewed frequently, doesn't mean the portal itself isn't maintained well or isn't active. Portal:Opera is a perfect example of this. I am not in favor of a mass deletion which throws out babies with the bathwater. Deletions should be remain an individual process of consideration.4meter4 (talk) 23:36, 20 September 2019 (UTC)
@4meter4 Portals with any maintainers in years are few and far between, as six months of MfD has shown. Newshunter12 (talk) 00:03, 21 September 2019 (UTC)
If cut to the important ones (by true significance, not arbitrary views) those who do portals will gravitate to what remains. And merge all the lesser subjects up, in the process. Hyperbolick (talk) 00:58, 21 September 2019 (UTC)
I doubt that assumption is accurate. In my experience, editors contribute usually in a few areas of interest, and gravitate to those portals associated with their interests. I spend most of my time writing on operas and opera singers because that's my interest and I spend most of my time working in two wikiprojects related to that topic. If the opera portal goes, even though it is highly active, I will not get involved with another portal because I am only interested in contributing in that one area. As for MFD, keep at it one portal at a time. There's no need for expediency. Be respectful of good work and editor's contributions by taking time to evaluate them individually. If the work is overwhelming maybe you need a wikibreak.4meter4 (talk) 01:11, 21 September 2019 (UTC)
  • Oppose. I see no such overwhelming agreement, nor support for deleting an arbitrary quota of 95% of portals. Certes (talk) 23:41, 20 September 2019 (UTC)
@Certes You're apparently incapable of basic math. This would eliminate less than 90% of existing portals and six months of MfD and 850 deleted portals (over 50% of the pre-TTH portals) speaks to how few portals actually have any merit. Newshunter12 (talk) 00:03, 21 September 2019 (UTC)
Thank you for the arithmetic lesson. I was referring to the 1500 portals which existed at the start of the cull. Certes (talk) 00:16, 21 September 2019 (UTC)
  • Oppose No, consensus seemed to be shifting to "let's not make any arbitrary deletions". In fact, I think many agree that this suggestion to even consider throwing out an entire namespace that has a very active project and useful pages that are well-maintained is a bad idea and spearheaded by users who don't particularly contribute to those upkeep efforts. Kingsif (talk) 23:45, 20 September 2019 (UTC)
@Kingsif Over 850 portals (over 50% of the pre-TTH portals) have already been deleted for being complete crud. Why force editors to waste their time going through the rest one by one? Newshunter12 (talk) 00:03, 21 September 2019 (UTC)
The suggestion, pick an arbitrary number or the entire space to delete, based entirely on quality then views, could effectively be compared to "let's delete a random selection of stubs" (or all stubs). Sound like a good idea? No, we can go through them if we must but if you find that too tedious, I think keep all is a better option than delete all. Kingsif (talk) 03:40, 22 September 2019 (UTC)
  • Strong oppose This WP:TNT-like approach to clean out Portal space makes no sense and is not how we do things on WP. Each portal must be evaluated case-by-case. --Masem (t) 01:20, 21 September 2019 (UTC)
  • Support – page views probably aren't the best way to draw the line, but I support it nonetheless, as we'll end up in the same place anyhow. I also support Hyperbolick's counterproposal above. Again, Vital 100 is probably not the best place to draw the line, but still better than what we have now. No matter what we do, we're going to end up at the same place: about 10 portals, the community portal and the main page ones. Whether we get there en masse or one-by-one, whether we draw lines using pageviews or Vital Topics, the method will only affect how much of our time we take up on the journey; the destination is the same. Levivich 01:24, 21 September 2019 (UTC)
  • Oppose page views aren't a good metric to use by themselves and we should be considering these on a case-by-case basis rather than using an arbitrary cutoff. I would suggest a good next step would be to draw up some proposals for criteria we can use to determine whether a topic should have a portal or not, since it doesn't look like getting rid of all of them is going to pass. Hut 8.5 10:06, 21 September 2019 (UTC)
  • Strong Oppose Why on earth would we base it on views, and not quality? And, even if we accepted that (which we shouldn't), why have a pre-determined, arbitrary number of portals, with the other thousands of portals deleted without the possibility of appeal, and likely without any people maintaining them ever being aware of this discussion? And why 75 portals to survive? We don't even know how many page views the 75th highest portal has, nor the 20th, nor the 76th, nor the 120th, nor the 1000th because the proposal is entirely arbitrary and not based on any relevant counts or research. This is an appalling idea, and doesn't feel like a well-thought out proposal to improve the encyclopedia, it only seems to work if the logic is "Let's delete all as many as possible of the portals," because why else have an arbitrary cutoff for the number allowed to survive? We do have a problem evaluating portals: The mass portal creation of a while back also involved editing over what used to be featured portals, and there's enough pieces to portals that it can be very hard to properly revert everything, since you may need to revert dozens or hundreds of pages to get everything to how it was, instead of having bot-generated content for at least some of it. Adam Cuerden (talk)Has about 6.9% of all FPs 11:34, 21 September 2019 (UTC)
  • Strong Oppose as per User:Adam Cuerden. Quality and utility should be what we base our judgements on. Not pageviews. We are not some kind of clickbait website. Pageviews on their own do not demonstrate anything, besides maybe poor linking. Link something on the frontpage and it will have tens of thousands of clicks, even if it is empty page with no utility whatsoever. Similarly the best portal in the world will not get any clicks if readers are not aware that it exists. --Hecato (talk) 11:50, 21 September 2019 (UTC)
    How does one measure "utility", if not by page views? Levivich 17:00, 21 September 2019 (UTC)
    Pageviews are not used at all in assessing WP:VITAL. Would guess, has some thought to utility of having such articles. Hyperbolick (talk) 21:34, 21 September 2019 (UTC)
  • @Levivich: I like User:Hyperbolick's answer. To add to that: Let's (for the sake of the argument) agree the purpose of portals is (1) to introduce users to the most important topics in a topic area, plus (2) showcase high quality content, plus (3) advertise WikiProjects and other related Wikimedia. The utility of a portal is then defined as its ability to fulfill these purposes. And if we need to quantify utility, then we get a consensus.
How do we decide which articles should be picked in (1)? Initially bold editor discretion and when people disagree, educated consensus. For an editor with an interest in a topic it should not be too hard to select the most important articles for a topic area, but WikiProjects also offer importance ratings of articles in their scope. Both utility and how well content is presented can then be part of a quality assessment.
I think the strong dislike for portals from parts of the community is due to many portals being poorly implemented when it comes to point (1) and a general lack of quality in presentation. Points (2) and (3) are nice and all, but if I go to a portal about biology as a regular reader, then I want to get a quick interactive and visually attractive introduction to the most important articles in the topic area of biology, not look at a bunch of A-class articles about obscure microbes, even if they are really well written. --Hecato (talk) 12:05, 22 September 2019 (UTC)
I think all of (1) (2) & (3) are desirable, but they do not mix well. For (1), the parent article does the job best. For (2), a WP:Category intersection of Category:Wikipedia featured articles and your desired topic category tree would be wonderful, but nothing currently serves well. For (3), one should enter through the Community Portal. Cross namespace linking out of mainspace is discouraged for good reason. —SmokeyJoe (talk) 12:34, 22 September 2019 (UTC)
@Hecato: Thank you. Hyperbolick (talk) 14:11, 22 September 2019 (UTC)
  • strong oppose. Lack of page views is not a reason to discard portals. Sm8900 (talk) 03:58, 22 September 2019 (UTC)
  • Strong Oppose: Portals are useful tools for navigation on broad topics of interest. The entire proposition of deleting portals to save editor’s time is misguided. If saving editor time is the priority that would imply we should consider deleting the entire Wikipedia. The advocates against portal are repeatedly failing to appreciate that there are significant number of users who use Portals, care about them and are ready to work on improving them. There can be a criteria for establishing notability / importance of a topic area for creating / keeping a portal and a certain quality benchmark before reaching which portals can be mandated to flag a “Draft” status. But getting rid of the portals altogether would be counterproductive and a serios blow to the appeal of Wikipedia. Arman (Talk) 10:35, 22 September 2019 (UTC)
Useful? How? How is a portal useful for navigation? They seem to feature a pseudo-random selection of articles liked by the portal creator, no attempts at enabling comprehensive navigation, and include a lot of cross namespace linking.
You miss most of the rationale, it is little about saving editors time, and more about removing a reader disservice.
Virtually no one uses portals. Looking at pageviews, from mainpage to mainpage linked portals, and secondary linked portals, it is like a thousand-fold attrition each time. Pageviews in the single digits are probably web crawlers and Wikipedia bots.
Your notion of “notability” and portals shows a poor understand of both notability and portals. Notability has nothing to do with a portal. Notability is for articles. —SmokeyJoe (talk) 11:00, 22 September 2019 (UTC)
Useful for navigation: in the same way the main page is useful for navigation. The characterization that you make can apply to main page as well.
Rationale: Please refer to the last line of Bermicourt's opening of this debate: "So it would save all involved editors a lot of time if we just agreed to scrap portals and portal space rather than continue the present process with those editors who see no value in portals having to put them one-by-one for deletion while those in favour of keeping them continue to waste time trying to defend them."
Page-view count is not a criteria to keep pages/material on wikipedia, nor is it a measure of usefulness. If it were, it would import bias. Only popular topics would remain. Portals are useful to editors who focus on specific subject areas - they may be few in number but their enthusiasm and contributions are immensely valuable for wikipedia.
I used the term "Notability / importance" to imply a measure parallel to notability measure of articles. Portals should meet a high threshold of notability / importance / breadth than articles and hence community can decide on such a criteria which I would support. Also, I would refrain from challanging other users "understanding" because it may be against WP:Civility. Arman (Talk) 11:25, 22 September 2019 (UTC)
You don’t go to the main page for navigation. It may be ok for browsing, but browsing is wandering, not navigation. The portals replicated the main page style of pseudo random interesting links, enticements to wander, not navigate. I think the fundamental flaw is that portals were supposed to be for navigation purposes, but they don’t meet that purpose.
Yeah, Bermicourt's rationale is not the one I would have used.
Portals are useful to editors who focus on specific subject areas. YES! That’s why they should be moved into their associated WikiProjects, they are for interested editors, not readers. —SmokeyJoe (talk) 11:35, 22 September 2019 (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.

Ethical Question - Should portals continue to be created or deleted while the community debates their future?

I only raise this because, while the community debates the purpose and future of portals, individual portals continue to be put up for deletion at a rate that may render the outcome of the discussion pointless. I'm not an expert on Wikipedia protocol, but my understanding was that, if we are actively discussing an issue, especially one that is clearly contentious, it is a fundamental breach of conduct to continue 'fighting the battle' for one side or the other. The focus must surely be on resolving the issue first. Bermicourt (talk) 17:26, 23 September 2019 (UTC)

  • Seems engaging in either process wastes resources. Going through individual deletion discussions itself suggests question is individualized, and some should/will be kept. Creating more seems equally ill-timed. Hyperbolick (talk) 17:32, 23 September 2019 (UTC)
  • If I'm being totally honest, I'm not sure I understand why so many people care about portals at all, and are committing any time whatsoever to having them deleted. Since much of the central argument seems to be that they are useless things that no one ever uses, seems six-of-one half-dozen-of-another whether we delete them or just let them sit around collecting dust. GMGtalk 17:46, 23 September 2019 (UTC)
    • You speak plenty of sense there. I think this is only the second time I've made any comment in the portal wars that have been going on for far too long, and the first time I got in reply to a comment (that maybe people were getting too worked up about the issue) the tired cliché from one of the zealots that my comment said more about me than about portals. Why can't people just get on with building this encyclopedia rather than arguing about how many angels can dance on the head of a pin? Phil Bridger (talk) 18:39, 23 September 2019 (UTC)
      • I think that the amount of effort to delete does not balance with the claimed lack of relevance, and that this ongoing squabble does far more harm than good. If Portals are really irrelevant, there is no need to delete them, because no-one is looking at them. If a significant number of people use them they should be improved when necessary. · · · Peter Southwood (talk): 18:56, 23 September 2019 (UTC)
        • The root problem IMO is that portal usage declined as people went to mobile phones, and that portals are not visible enough and are not easy enough for ordinary people to edit. Why get the mobile app to display portals and find a process to make it easy for an inexperienced user to edit a portal? Also when I raised a possibility of replacing direct quotations of articles in portals with transclusion, I felt that the portal deletion advocacy seemed uninterested in solving the issue that caused problems with lesser maintained portals (articles going out of date) and there was a strong preference for deletion instead. WhisperToMe (talk) 05:51, 24 September 2019 (UTC)
          • No, the root problem is that portal usage has never been high because WP:POG was badly written and inadvertently set it up that way. According to the portal guidelines (now downgraded to information), there "should" only be one link from mainspace. How was that ever going to meet the [questionable] goal of "attracting large numbers of readers", especially as portals don't appear in topic searches either? The real value of portals lies in their potential as navigation aids (but they need to be linked as categories are) and their value as project tools to enable coverage and quality to be improved.Bermicourt (talk) 12:11, 29 September 2019 (UTC)
          • I agree. I think that portals remain highly relevant and valid. they signify our commitment to treating certain subject areas as important. even if they are not updated, every portal has some compilation of useful articles around a core theme. Sm8900 (talk) 13:04, 24 September 2019 (UTC)
            • On the contrary, @Sm8900. Portals signify nothing other than the desire of some editors to create Rube Goldberg machines where they don't apply the core editorial techniques of using secondary sources to build content. They are basically just very poor quality mixtapes, which are fun to create but of little or no wider value, as demonstrated by their abysmal viewing fugures. -BrownHairedGirl (talk) • (contribs) 02:26, 10 October 2019 (UTC)
              • On the contrary, @BrownHairedGirl, clearly portals do have some valid function or else dozens of editors would not have worked on them to create them. I agree that some do get more consistent attention than others. --Sm8900 (talk) 13:22, 10 October 2019 (UTC)
                • Thank you, thank you, thank you, @Sm8900 ... for so clearly articulating the core problem with portals, even tho that was not your intention. They have huge value for the small crew of editors who create them (and in most cases then neglect them), but very little value for the readers for whom we build Wikipedia.
                  That's why in portal deletion discussions at MFD, the opposition to deletion comes almost exclusively from the same small crew of portal creators. Hardly anyone who isn't part of that portal-creation-and-fettling process defends the abandoned junk whose demise so troubles its creators.
                  Even portals with huge numbers of incoming links receive trivial pageviews, and those pageview numbers are themselves massively inflated by the requirement to purge a page to view a new selection. For example, the recently-deleted Portal:Anglicanism had over 10,000 links from articles, but managed only 32 views per day, versus 1,806 views/day for the head article. Even the 8 portals listed in prime place on the main page get only about 1/10,000th of the views of the main page (i.e. 0.01%).
                  The solution to this is obvious and simple: move all the portals to project space and remove links to them from article and category space. Then the few dozen editors who like making them and fettling them can continue to do so, while readers stop being lured to useless pages, and other editors can avoid the clutter of links to portals, etc. Win-win! --BrownHairedGirl (talk) • (contribs) 13:52, 10 October 2019 (UTC)
  • Good question. Very few portals have been created in the last six months, whilst those deleting portals plan to, in their own words, continue the salami-slicing until the portal fans stop whining. I would be interested to read neutral editors' comments on this matter. Certes (talk) 19:48, 23 September 2019‎
    • It's pity that Certes yet again misrepresents the facts. That was a comment made by one editor, which Certes falsely attributes to all editors who have been engaged in the deletion of portals.
      This sort of deception is just further evidence that many of the most passionate and vocal advocates of portals lack the good judgement required to sustain portals. --BrownHairedGirl (talk) • (contribs) 13:58, 10 October 2019 (UTC)
      • I claim that one editor inserted that text on one occasion, because that's how diffs work. However, the forecast I quoted does seem accurate so far. I hope that you can correct me by reassuring the community that the MfDs will stop at some point, rather than systematically working through the entire namespace. Certes (talk) 15:04, 10 October 2019 (UTC)
        • Certes made it clear that he was quoting one editor, who was representative of the whole. in disputing him, you have now claimed that the most devoted portal fans as a group "lack the good judgement required to sustain portals." it's curious how many responses of yours to certes often proves certes' general point about the overall opinions of portal opponents. Sm8900 (talk) 15:16, 10 October 2019 (UTC)
  • Certes, please do try to be honest for a change.
    You prefixed the quote with the words "those deleting portals plan to, in their own words", which clearly attributes that intention to a group of editors rather than to the one editor who wrote it. That is a dishonest misuse of a quote, and your decision only only minutes later to deny that it's what you did is as absurd as it is deceitful.
As I have said many times before in response to you and to others, I can assure you neither that MFDs will stop or that they will continue, because:
  1. I don't speak for any other editor. I make my own decisions on whether to MFD a given portal, after lengthy assessment. Other editors make their own assessment on whatever basis they see fit. There is no cabal.
  2. I will absolutely definitely not assure you or anyone else either that I will continue to bring portals to MFD, or that I will stop doing so.
    I assess each portal on its merits. I will continue to bring to MFD any portals I find which on assessment fall below what I believe acceptable standards ... and I will continue not to bring to MFD the portals I examine which aren't clear fails. Sadly, after 6 months of MFDs, Certes still seems unable or unwilling to grasp the concept of assessing portals one by one and deciding in their merits.
Certes has been consistently clear for over 7 months now that Certes vigorously opposes any deletion. Memorably, Certes made by far the biggest effort to poison the community atmosphere around TTH's portalspam, including denouncing those seeking its cleanup as waging a "war on portals". Sadly, even now, Certes is still in a foxhole, demanding that editors stop individually assessing portals ... while at the start of the year, Certes was equally adamant in opposing mass deletions. The reality remains that Certes's suatine dposition is that Certes just wants to keep as many portals as possible, regardless of their quality or their utility to readers.
And to @Sm8900, I repeat that the most devoted portal fans as a group "lack the good judgement required to sustain portals". If you would like me to expand on my reasons for saying that, then I would be willing in principle to start a new section and do so ... so long as you agree that my evidence of sustained poor judgement will not be labelled as a personal attack (see WP:NPA). --BrownHairedGirl (talk) • (contribs) 16:07, 10 October 2019 (UTC)
@BrownHairedGirl, to respond point by point:
  1. If Certes used that quote to typify the whole, then Certes probably had clear reasons for doing so. did any anti-portal editors express any disagreement with that quote? If not, then there is no point to making such a gigantic issue over it. it was part of an existing discussion, I assume, where one of the active participants made that comment as part of a broader topic.
  2. I appreciate your clear offer and courteous inquiry. Please do not start any such section; in my opinion, any such effort to highlight individuals' comments as showing poor judgment, rather than simply expressing an alternate opinion with which one disagrees, would possibly border on being unnecessarily personal in nature.
I appreciate your replies, here in this colloquy. thanks. --Sm8900 (talk) 16:13, 10 October 2019 (UTC)
@Sm8900, in this case, these are not just matters of opinion. These are matters of judgement and of fact, in which the editors concerned have repeatedly been found wanting. The editors concerned combine a long-term pattern of low skill, poor judgement and stubborn determination ... and that sustained combination is what has led which has led to the long-term decline of portal-space to the point where over 60% of all portals have been deleted against the opposition of that crew of portal fans.
As your first point, you are managing the difficult task of being at least as absurd as Certes. You write no point to making such a gigantic issue over it, but it wasn't me who chose to do that; it was Certes, who chose to hang that quote around the beck of a whole set of editors who neither wrote it nor commented on it.
To your question "did any anti-portal editors express any disagreement with that quote?" ... I reply with as much WP:CIVILity as I can muster, eff off back to Lubyanka or the Spanish Inquisition or wherever you got that evil mindset from".
Seriously, just eff off to whatever torture culture taught you that tactic. That attempt to hang one person's words around the neck of another just because they didn't explicitly disown them is a classic tactic of totalitarians, and it has no part in any remotely civil discussion anywhere. Lots of editors express their views in various discussions, and other may express a view on what has been written, or may not. But your attempt to claim that silence=assent belongs to Beria or Torquemada, not to colleagues discussing how to build an encyclopedia.
As you can see on from that section, which is still visible on my talk page, I simply didn't reply to @Robert McClenon's post. There were some things I agreed with, some I disagreed with, and some which were more nuanced, and I didn't have time to give the nuanced reply it needed.
You and Certes both need to clean up your acts. --BrownHairedGirl (talk) • (contribs) 16:42, 10 October 2019 (UTC)
@BrownHairedGirl, well, I think your reply to that is a bit disproportionate, but I have heard your concerns, I respect them, and I will acknowledge them. I appreciate your replies here. thanks. Sm8900 (talk) 16:57, 10 October 2019 (UTC)

There is the issue that no real attempt was made to advertise this discussion. How would people be aware of it unless they stumbled on it? If we're meant to block things on the back of this, it should've been widely advertised a week ago. Adam Cuerden (talk)Has about 6.9% of all FPs 18:51, 23 September 2019 (UTC)

Please don't interrupt; the grownups are talking. --Floquenbeam (talk) 17:32, 15 October 2019 (UTC)
The following discussion has been closed. Please do not modify it.
@Transhumanist:, so it must be about 15 years since people have been fighting with you to delete the portal namespace, Transhumanist. Has there ever been a proposal to open a dedicated site, such as prefix port.wikipedia or similar? From there you could mount a revenge campaign, maybe over the next 20 or 30 years, and delete user space? User pages are used but no single one gets more than a couple thousand hits occasionally. There's plenty of content in userspace but it's undefined, unmanaged, unchecked for relevance. People are supposed to keep control of their own defined userspace but often they simply delete enquiries and there are no strict rules to ensure userspace content is relevant to the given subject. I don't know. Let's have a campaign to delete most of userspace and just keep the important ones, you know, Jimbo Wales, WMF Katherine, um. Well there isn't really many or any really important ones is there? Can you think of any? Nobody looks at Larry Sangers userspace. Except maybe Jimbo but he doesn't count. He's just trying to drum up support for his own userspace. Let's have a vote somewhere and get an RFC going. This rampant userpsace must be stopped from clogging up all the servers. And how does it look, just letting people chitty chat and edit whatever, damn the hell way all they want. No that's it now, I'm furious about this. How dare they!! They'll turn away all our best customers and Google will take the lot. Bill Gates is just waiting for a new opportunity to break back into the internet, isn't he? Let's make wikiproject userpsace come here and show us exactly what they are trying to do, what their rationale is, and when they are going to stop! ~ R.T.G 07:06, 15 October 2019 (UTC)

subsection

If a group excludes portals individually within the rules I see no problem. The problem is the discussion about the future of portals that leads nowhere. No new proposals are raised, just an effort to keep portals abandoned and poorly viewed.Guilherme Burn (talk) 16:42, 24 September 2019 (UTC)
What are your thoughts about making portals more visible on mobile phones and more easily editable by lay people? I noticed that portal views halved as people got on the mobile app more. WhisperToMe (talk) 02:10, 25 September 2019 (UTC)
@WhisperToMe:I would like very much. But there is strong resistance to changing the obsolete sub-page model.Guilherme Burn (talk) 13:49, 26 September 2019 (UTC)
Based on what I can see....the above discussion has no consensus to get rid of portals. I think new ones can be created if the rules governing them are fixed. - Knowledgekid87 (talk) 17:38, 24 September 2019 (UTC)
  • Portals are like another door into Wikipedia. Let's see, what's another name for "door"? :-) Sm8900 (talk) 01:09, 25 September 2019 (UTC)
  • In a way, this is a solution looking for a problem. The whole issue over portals just creates work which could better be used for improving and policing the quality of mainspace articles , combating vandalism, and deleting inappropriate articles. Existing portals do not do any harm, neither is it a case of server capacity. Time to put this whole business to bed. Kudpung กุดผึ้ง (talk) 03:05, 25 September 2019 (UTC)
agreed @Kudpung:. Sm8900 (talk) 13:19, 25 September 2019 (UTC)
agreed here as well, there is clearly no consensus for the end to the portal system. The MfDs can be done on a case by case basis. - Knowledgekid87 (talk) 13:56, 25 September 2019 (UTC)
  • Unless there is a reason portals are helpful to readers, they should not be linked from article-space (including from templates). No such reason, which has not been discredited, has been stated. I have no objection to portals remaining, provided that readers will not be directed to them accidentally. — Arthur Rubin (talk) 00:55, 16 October 2019 (UTC)
Wikilinks to portals are clearly marked as such. There is a case (which I oppose) for unlinking but I don't think accidental visits are an issue. Certes (talk) 07:49, 16 October 2019 (UTC)

Thoughts on the value of portals

Portals are another way to deliver content, to compile links and articles, to provide a collection of articles around a central theme, to point editors towards central concepts of that area, and to generally promote editing of that topical area. they may not get a lot of editor traffic, but then neither do many Wikipedia essays, many wikiprojects, or indeed many articles on certain topics. is that a reason to get rid of any of those things? Sm8900 (talk) 13:15, 25 September 2019 (UTC)

As reader material, they fail core content policies. Without explicit sourcing, it is very hard to keep them NPOV compliant. They also present a very poor example of content, being unsourced. They don’t help deliver content better than their parent article, and they fail to provide good navigation, instead tending to showcase editor’s POV via articles that reflect what editors have been interested in developing. —SmokeyJoe (talk) 13:25, 25 September 2019 (UTC)
Do we need yet another discussion on this topic? Phil Bridger (talk) 13:28, 25 September 2019 (UTC)
I combined them together as other unrelated discussions should be allowed to continue unabated. - Knowledgekid87 (talk) 13:32, 25 September 2019 (UTC)
@Knowledgekid87: thanks, that's fine. @SmokeyJoe: well, I guess I disagree with that. I agree that yes, I suppose these points have been covered elsewhere in existing discussions here. thanks. Sm8900 (talk) 13:35, 25 September 2019 (UTC)
@SmokeyJoe: There are many legitimate concerns about portals, individually and collectively, but this seems like a very dubious line of criticism. By this reasoning, the Main page has all the same flaws. I wonder what would be the response to an RfC about how the main page "fails core content policies". --RL0919 (talk) 13:47, 25 September 2019 (UTC)
The Main page doesn’t pretend to offer comprehensive navigation to a whole subject area. Subject portals do so pretend, and then don’t. —SmokeyJoe (talk) 14:03, 25 September 2019 (UTC)
with respect, if that's your objection, there's not one portal that could meet that standard. the whole point of portals is to be a portal into a subject area, not to "offer comprehensive navigation." there's no way for any single portal to do that, as far as I know. Sm8900 (talk) 14:07, 25 September 2019 (UTC)
Portals could, I believe, meet this standard. They could merge their concept with that if WP:Outlines, and give up pushing selected articles, and wind back linking to WikiProject pages. —SmokeyJoe (talk) 22:36, 25 September 2019 (UTC)
I believe readers are not expecting portals to offer comprehensive navigation: their very name suggests a starting point for investigation. Additionally, readers are familiar with the content-under-construction ethos in Wikipedia, through their experience in browsing pages of varying quality. isaacl (talk) 16:13, 25 September 2019 (UTC)
Ok. You think portals offer a starting point for “investigation”. Tell me more. I don’t see any merit to that notion. —SmokeyJoe (talk) 22:39, 25 September 2019 (UTC)
I agree with you, @Sm8900: in theory, 100%. The problem is what is actually happening in practice. Work with me to imagine for a moment the extreme case, a portalspace that only has Portal:Catholicism, Portal:Opera, Portal:Trains and Portal:H. P. Lovecraft. Does that make any sense? I certainly don't think so. And yet that is the direction we are heading: those are four subject-area portals that get a lot of consistent editor attention, sufficient in my opinion, at lest for the time being (set aside discussion whether they are all broad subjects). The other portals, for the most part, do not; even the eight currently linked from the Main Page; I don't really care that subject-area portals are ignored by readers; my issue is they are almost universally ignored by editors, and hey, that's ok (Wikipedia evolves) as long as we don't pretend otherwise. I'll turn the question around to you: What do you think of a portalspace where the coverage is as spotty as it is today, let alone where it is heading with ~200 more portals still being culled per month at MfD? I encourage more editors to actually look at the state of the space, maybe try editing a portal or two, and then opine objectively based on that experience. UnitedStatesian (talk) 14:48, 25 September 2019 (UTC)
To take a parallel example, I haven't seen anyone compare navigation boxes across different topic areas and worry about a lack of similarity in how they cover their corresponding topics. It's not an issue because the people who are interested in the areas make decisions based on their domain knowledge on the best ones to create and maintain. If editors interested in opera decide that maintaining a portal offers a helpful entry point to the topic, why should the absence of other portals keep them from deciding how they want to spend their volunteer time? On the other hand, if none of the editors interested in a topic area want to maintain a corresponding portal, then why should other editors declare a portal ought to exist? isaacl (talk) 16:23, 25 September 2019 (UTC)
Navigation boxes, usually called navigation templates, work. I think everyone can see how they work, and can experience them working. Portals, in contrast, don’t “work”. They appear to be hobby activities for very few editors, and they offer a negative experience for readers. They mostly fail NPOV, they don’t serve as starting points for navigation, they are heavy handed clumsy editor recruitment pages. If they are not doing damage, it’s because humans don’t read them. I strongly suspect that for most portals, all the page hits are web crawlers, Wikipedia bots, and Wikipedia editors. —SmokeyJoe (talk) 22:45, 25 September 2019 (UTC)
If you mean that currently existing portals don't work, well, most of them aren't a current collaboration amongst editors interested in the corresponding topic area (if they ever were). The only way for a portal to work is for those editors to decide where a portal may be beneficial, define its scope, plan its content, write it, and maintain it. Personally, I'm not too interested in creating portals or list articles, or populating categories, but I'm not going to tell others not to spend their time on activities that they have determined to be useful, provided it imposes no burden on me. isaacl (talk) 03:33, 26 September 2019 (UTC)
I think Wikipedia should have a browsing functionality, structurally organised by subject area. That's what Portals should be doing, but they don't, not even the top portals. The category systems serves, but is ugly. The sheer number of bad portals was so much inertia that I thought renovation of the portal structure would be impossible. With deletion of the worst, I have more hope. See Portal_talk:Law#Proposed_portal_merger, where I dare to hope to find traction. --SmokeyJoe (talk) 03:43, 26 September 2019 (UTC)
@SmokeyJoe: "Wikipedia should have a browsing functionality, structurally organised by subject area". We have that already. It's called categories.
Per WP:CAT, "The central goal of the category system is to provide navigational links to Wikipedia pages in a hierarchy of categories which readers, knowing essential—defining—characteristics of a topic, can browse and quickly find sets of pages on topics that are defined by those characteristics.".
Wikipedia's poor software make categories unnecessarily hard to use, but trying to make portals into Categories 2.0 is doomed to fail. ---BrownHairedGirl (talk) • (contribs)
I agree on this: a good portal serves as a tool and bridge between the readers interested in an area, and editors. They exist beyond mainspace because they pull back the curtain on how WP is edited, just enough, but this helps with navigation within a large topic area, and where readers who are interested in editing can go help. This is not a function of a Wikiproject page, as there the focus is specifically on editing topics in that. But this all points to the fact that what portals we have should be sufficiently broad (it should not be 1-to-1 portal to wikiproject level of coverage) and minimal overlap, and thus the need to have some means to review existing portals that may not be appropriate, and to require new portals to be approved before creation. (Writing about this, reminds me of the old USENET heirarcy discussions and I feel that's a similar approach to be taken here.). --Masem (t) 16:46, 25 September 2019 (UTC)
I agree with the two comments above. if the question is whether portals should exist, then the fact that some portals are active proves that they should. --Sm8900 (talk) 18:43, 25 September 2019 (UTC)
What benefit does a portal have that the corresponding navbox doesn't? Some may have benefit to the WikiProject, but I see very few which would have benefit to the reader even if the reader could find them. — Arthur Rubin (talk) 01:54, 26 September 2019 (UTC)
the fact that several portals are fully active, means that some users do find them useful. Sm8900 (talk) 03:45, 26 September 2019 (UTC)
  • Comment: I have no strong opinions either way, but I think quality portals could be useful to readers. I also think that there might be a lack of awareness that results in less interest. Maybe it's just me, but I had no idea that portals even existed until I became an editor. Clovermoss (talk) 00:51, 29 September 2019 (UTC)
  • Would like to pointout that since we have more and more users using mobile version we have seen a huge decline in those joining WikiProjects because portals were one of the only places for recruitment.....we now see a further decline because so many portals are gone. Pls note I am for deletion of all portals...justs mentioning a fact that has been brought up before during deletion talks.--Moxy 🍁 18:20, 29 September 2019 (UTC)
    @Moxy, sorry how's that now? Firstly, the relevant Wikiprojects are still listed on every article's talk page; secondly, they're rarely linked on articles except as tiny links in navboxes. Even the projects which are still properly active either don't link to portals from articles at all (e.g. WP:MED and WP:MILHIST; even high-traffic medical and military articles like Cancer or United States Army contain no links to portals). Except in a few rare cases where there's a portal link tucked into a navbox (e.g. London Underground) would the interface used have any effect on whether a reader sees the portal link, and I'd bet a sizeable sum that even on the desktop 99.9% of readers don't even notice that portal link, let alone feel tempted to click on it. (That London Transport portal—which has a lot of incoming links from high-traffic articles—gets roughly ​15 of the views of my user talk page.) ‑ Iridescent 18:39, 29 September 2019 (UTC)
Not sure what your saying.....but portals are the only content namespace that allowed a link back to projects. They are not allowed in navboxes ( systematically removed years ago and not seen in mobile view). Administration pages like talk pages are not viable because of mobile view restrictions. Both cancer and US military articles once had portals leading to projects.....no more because of deletion....thus no project views from cotent namespace.--Moxy 🍁 22:59, 29 September 2019 (UTC)

The way that the community is going about this is entirely screwed up. There's repeated RFCs trying to get consensus to delete all portals, and then when those discussions fail to get consensus there's mass deletion initiatives to delete as many portals as possible, and there's mass creation initiatives to create as many as possible, and then more RFCs to try and force the issue. Certainly this is not good. (As for my own opinion, I wouldn't mind deleting all the portals, but as long as the opportunity remains open to us, I would like to keep the portals open for the subjects that I edit - which is why my position seems inconsistent. But the way the community is going about this is bonkers). --Rschen7754 22:33, 29 September 2019 (UTC)

  • I do not personally use portals, nor work on them, nor do I intend to . I do not find them helpful for the way I browse, or the way I work here. But different people work and browse very differently, and it would be a drastic mistake to judge what to keep in WP on the basis of what I, or any few individuals find helpful. When I cam here I knew from experience as a librarian what I was likely to find helpful, and even what other people in general were likely to find helpful, but discovered that very few people saw it as I did. I therefore decided not to try to convince or reform them, but to let anyone who liked any particular system to proceed as they liked, and myself work on other areas. I recommend this attitude. There are many navigation systems within WP--they seem to suit different readers or editors for different purposes. There is no one best device-- I would go so far as to say we have no really good navigational device, so we should keep whatever might possibly be helpful. The criteria for keep a navigational device ought to be :
1. Some people use it
2. There are some editors who care enough to maintain it
3. It is not harmful.
There have been some portals that fail point 2, and some that have even failed point 1--fom the discussion here, they have been removed already. There is no need to remove any others. It is very easy in WP to adopt an attitude there is one best way, and other competing techniques are best removed, so people can concentrate on the best one. As there is no agreement at all on what to concentrate on, and the great number and wide diversity of WP users means there is not likely to be a single particular one. We should leave alone things that work and are not harmful. I think therefore the best way to proceed would be a moratorium on any further deletion of portals. DGG ( talk ) 09:11, 1 October 2019 (UTC)
  • @DGG: your position seems to amount to saying that because we haven't agreed on a perfect navigational mechanism, we should refrain from individually assessing and deleting any portal, no matter how poor it is or how neglected it is. Basically, keep even the clear failures.
Applying your three tests:
1. "Some people use it". All that the pageview data can tell us is whether someone visited the portal page. Without further server logs, to which we don't have access, they cannot tell us whether the reader actually used any of the curated links on the page they lacked on, or just backed off. However, the very very low readership of portals (massviews shows a median of only 21 views per day) indicates a staggeringly low level of repeat visits, which is strong evidence of lack of actual use. Note that because nearly all portals require a purge to view an alternative selection, a single visit by a single reader causes multiple page views. So the page view stats exaggerate the number of visits to the page in proportion to the extent to which readers actually try to use the portal.
2. "There are some editors who care enough to maintain it". For the overwhelming majority of portals, there is no maintenance other than formatting. The substantive content usually goes untouched for a decade.
3. "It is not harmful". It is simply false to claim that the misconceived, neglected portals are harmless. A failed navigational tool wastes the time of any reader who tries to use it. Any portal imposes a cost on the wider editing community, through maintaining links to it, disambiguating links etc, and trying to figure out how to edit its Rube Goldberg machine structure to stop it spewing out false or outdated info.
Before TTH's portalspamming exercise, there were about 1500 portals. Nearly 900 of those have been deleted, leaving 604 portals, of which 31 are currently being discussed at MFD. Nearly all of those 31 have no maintainer, and AFAICS none of of them has an active, involved WikiProject.
Yet you want a moratorium on deletion even of portals which fail your own over-generous criteria. That's utterly perverse. --BrownHairedGirl (talk) • (contribs) 14:12, 4 October 2019 (UTC)
My point is that since we can never succeed in finding a single navigational medium suitable for all purposes and all users, we should keep whatever some users find helpful. DGG ( talk ) 05:18, 5 October 2019 (UTC)
It is also worth noting that although hundreds of portals have been deleted, there are well over a hundred portals for which deletion was proposed, and there was either an absence of consensus to delete the portal, or a clear consensus to keep the portal. bd2412 T 16:14, 9 October 2019 (UTC)

Another alternative proposal for portals: Merge up and redirect rather than deleting

In the course of deleting hundreds of portals, we have rushed past the fact that we have also deleted thousands of hours of work (of varying quality, some of it usable), and deprived those who actually look for a portal on a certain topic any target at all. I think a better solution would be to 'merge and redirect moribund portals up to the next higher level of abstraction. The result would be a remaining set of portals on the higher-level topics having broader sets of coverage and receiving larger numbers of page views. For example, the deleted Portal:Culture should be restored and merged/redirected to Portal:Society. Anticipating two objections that have been raised to this in specific discussions, this is already a familiar practice in other spaces, as we redirect articles from subtopics to supertopics all the time - we have redirect templates specifically for that function. Also, while it is true that the histories of some portals containing poor work would then be preserved, why wouldn't we preserve failed portals and their histories in the same way we preserve failed projects, for historical reference? bd2412 T 17:07, 1 October 2019 (UTC)

  • @BD2412: Most of that is the WP:HARDWORK/WP:SUNKCOST fallacy. AFD routinely deletes inappropriate pages into which editors have put a lot of work. In most cases, this work was done in good faith, but if it's not appropriate for en.wp, it gets deleted. This is an encyclopedia, not a museum, and it is routine part of any publication that some some work is discarded. Deciding what to keep is one of the core functions of an editor of any publication, and indiscriminate preservation is just a recipe for clutter.
If you want to preserve a failed portal as a relic for the benefit of future wikiarchaeologists who want to study the failed history of redundant content forking, then the solution is to move it to project space. What you are proposing is to keep the stale content forks live by dumping the into another portals, which both is a disservice to readers and a poor means of preservation. But apart from those wikiarchaeologists, I really struggle to see any benefit in preserving stale content forks. By all means, expand the undeleted portals; but for goodness sake don't pollute them with rotted components of abandoned portals.
We redirect from article subtopics to article supertopics all the time. These are not articles; they are portal, and there is long-standing consensus at RFD that a) portals are not plausible search terms, and b) a portal redirect much a broader topic misleads readers. --BrownHairedGirl (talk) • (contribs) 17:30, 1 October 2019 (UTC)
I would definitely support moving moribund portals to project space pending potential further recycling of their contents. I would not suggest redirects from all topics, but there are some distinct subtopics, such as states to countries or major branches of a field of study to the field itself, for which I think this would be appropriate. bd2412 T 17:34, 1 October 2019 (UTC)
@BD2412: I am still astonished that you want to recycle stale content forks. We should long ago have dumped all such forks ... and if for some reason, somebody wants to add a content fork on that topic to another portals, they will do much better to create a new fork from he current version of the article.
As to redirects, there are 50 states of the USA. The state portals which have been deleted are all on smaller states (by population). A significant chunk of the portal should be about federal topics, so on average the US portal should give about 1% of its coverage to any one those states. That's too tenuous to justify a redirect. --BrownHairedGirl (talk) • (contribs) 18:17, 2 October 2019 (UTC)
The United States is made of its 50 states, and most notable people, places, or events in the United States arise within one of those states, with many topics of local importance also being nationally significant. For example, look at the selected biography subjects for Portal:Arkansas: Bill Clinton, a U.S. president; Mike Huckabee, a nationally known repeat presidential candidate; Thomas C. Hindman, a U.S. Congressman and Confederate general; Hillary Clinton, a presidential nominee; Glen Campbell, a nationally known and national award-winning musician; Maya Angelou, a nationally known poet; Darren McFadden, an athlete who won national awards and played professionally for a team in California; and Jermain Taylor, a boxer who competed for the United States in the Olympics. Which of these are not just as appropriately considered a United States subject as an Arkansas subject? bd2412 T 18:48, 2 October 2019 (UTC)
@BD2412: I'm sorry, but you haven't thought this through. Even just the numbers son't work
This only applies in the context of the abominable content fork model of portal. (No content forks = nothing to merge).
Your example there lists ten topics. As you say, there are 50 states. So if we dump ten topics X 50 states into P:USA, that's 500 content forks dumped into a single set. That's unmaintainable, and unusable: how many purges would it take for a reader to see each of those 500, randomly one at a time? (No, the answer isn't 500; it's much more than that) .
So the whole one-at-a-time magazine model doesn't scale.
And that is only the start of the problems. Beyond that: Arkansas is a small state. California has 13 times as many people: should it get 13 times as many articles?
And again: why preserve a content fork? It has zero original content, and can be re-created in seconds in an up-to-date form if anyone wants to. --BrownHairedGirl (talk) • (contribs) 15:43, 4 October 2019 (UTC)
I agree that a portal that spat out one of 500 random featured articles would be of little utility. Some content curation would need to be done, perhaps introducing a Portal:United States structure that offered a larger number of areas (for example dividing biographies of cultural figures from those of political figures, or allowing readers to choose to dig into information on specific states or regions). It is my expectation that developing a more useful structure for a handful of higher-level portals will help clean out currently useless lower-level portals through sheer absorption. bd2412 T 21:48, 4 October 2019 (UTC)
@BD2412:, now that is the kind of positive idea that I can think about and maybe agree with. yes, i can agree with ideas that are intended to improve or refine portals, rather than simply deleting them entirely. Sm8900 (talk) 13:17, 8 October 2019 (UTC)
This is like the old tantric wheel. The history of portals is full of initially attractive ideas like this, but which fail because of their complexity and/or the persistent problem there a) are not enough skilled editors who are both familiar with that content and willing to maintain the portal; b) the Rube Goldberg machine structure of portals deters both readers and users.
The problem with portals is that they have always been an unhealthy combination of vague waffly principles and absurdly complex implementation which fails both readers and editors. There has never been any systematic analysis of the key questions, e.g.:
  1. what are portals for? (e.g. navigation, or showcasing, or magazines, or a playground for editors who like making baroque structures which offer opportunities for page design and building pages which apply none of the normal principles of content creation, such as WP:V. For the last decade, the magazine and playground aspects have dominated, and failed abysmally).
  2. How should portals try to meet those goals? For example, if you are trying to make a showcase, then is there any way in which it is anything other than an abject usability failure to list only one item at a time, with no list on the face of the portals to choose another?
  3. How is content selected? There has never been any clear guidance on how to select content for a portal. I have yet to see any portal which documents its own selection criteria, and in the last few months dozens of portals have had their content lists significantly expanded by a prolific but deeply-unskilled editor with no grounding in the topic area, who doesn't even leave a visible of what articles have been chosen and why.
    If portals actually matter, we shouldn't tolerate this method of topic selection ... and if they don't matter enough to give a lot more prominence to topic selection, we should just delete them all.
  4. Does the resulting portal actually both a) add enough value for enough for enough readers and b) enough interest from readers to justify the community effort in retaining it while the rest of the web has largely abandoned portals?
I have been scrutinising portals in depth for over six months, and in that time I have yet to see any way in which portals serve any significant purpose other than as exercise for their creators. Proposals such that of BD2412 are all ways of putting lipstick on a pig (with apologies to pigs, who are clever creatures, but don't look great with lipstick). --BrownHairedGirl (talk) • (contribs) 01:57, 10 October 2019 (UTC)

subsection 1

  • For the benefit of future wikiarchaeologists who want to study the failed history of redundant content forking, then the solution is to move it to project space. Yes! Same as I said at Wikipedia_talk:Portal/Guidelines/Archive_6#Portals_are_moribund. Not just future wikiarchaeologists, but to acknowledge current learning now, for the immediate future, and to prevent future editors from making the same mistakes. The Main page concept of a portal to showcase subsets of the encyclopedia by subject area is a failure. Deleting the worst of the failures makes it harder to point to the failures. I support archiving not for re-use, but as a reference for what not to re-create.
I previously suggested redirecting every failed portal to its parent article. Parent articles already serve as introductions and starting points for navigation, and lots of "edit" links to tempt readers into becoming editors. I have also suggested that every half reasonable portal can be moved into its corresponding WikiProject.
If you want to rescue portals, start with defining their purpose. Showcasing Wikipedia:Featured articles by subject area is not what readers want, and it is forking from Wikipedia:Featured articles. Readers are not using Portals for navigation. Is this because they are a useless method for navigating, or because they do not even try to meet that purpose. WP:Outlines tries to serve as navigation, but they too fail. Readers do not become editors via Portals. What do portals do? --SmokeyJoe (talk) 05:41, 3 October 2019 (UTC)
@SmokeyJoe: what do portals do? is that your question? they provide a portal into a general topical area, by providing an overview, a set of links to representative articles, and an articulation of some basic concepts of that topic, to enable readers to get a general overview of that topic.
here are just a few examples. Flag of the United Kingdom.svg United Kingdom portal, Aegopodium podagraria1 ies.jpg Environment portal, Flag of the United States.svg United States portal, Issoria lathonia.jpg Biology portal, Papapishu-Lab-icon-6.svg Chemistry portal, Flag of New York City.svg New York City portal, Heinkel He 111 during the Battle of Britain.jpg World War II portal, BS Bismarck.png Battleships portal Washington Crossing the Delaware by Emanuel Leutze, MMA-NYC, 1851.jpg American Revolutionary War portal, Social sciences.svg Society portal, Audio a.svg Music portal, etc etc. there are dozens of other examples. Sm8900 (talk) 13:12, 8 October 2019 (UTC)
Yes. That’s what portals seem to aim to do, and fail. That purpose is redundant to the parent article. Readers aren’t using them. I disagree that they provide an overview, instead they provide a very small pseudo-random sampling. —SmokeyJoe (talk) 21:25, 8 October 2019 (UTC)
I agree with @SmokeyJoe about the redundancy; a well-built head article does a vastly better job of the key portal functions than nearly all portal pages. But I'd go further than Joe on the failure to provide an overview: overwhelmingly, they provide an abysmally-structured, badly designed, redundantly-displayed very small pseudo-random sampling whose selection criteria are completely opaque, and which is nearly always chosen without scrutiny or discussion by an editor who lacks the skills to do it well. --BrownHairedGirl (talk) • (contribs) 02:04, 10 October 2019 (UTC)
  • This is going to be a drive-by comment, these discussions go too quickly and attract too much emotion for me to follow. I agree with preserving content where possible, even if it's part of a widespread project that we've determined has been a failure (which seems to be the case). I suggest that the best way to do that, for portals which have a single upmerge target (and upmerge is probably the wrong term), is to redirect-in-place, not move them to a different location. For example if Portal:Culture is upmerged to Portal:Society, just leave the old history of the culture portal intact where it is, and top it with a redirect. That becomes more difficult for portals that are upmerged to more than one target, for example links to Portal:History of Canada were replaced with links to both Portal:Canada and Portal:History. Maybe that could be handled by some kind of new soft redirect template. Ivanvector (Talk/Edits) 15:53, 4 October 2019 (UTC)
Would be best to place somewhat related portals in a replacement drive...that said we should be changing portal templates from non-mobile versions to the mobile version...no point in changing all the portals if most cant see them anyways (more wasting time). Need to change {{Portal}} to {{Portal-inline}} (only version that is seen on mobile versions). Or fix {{portal}} to a mobile version.--Moxy 🍁 16:03, 4 October 2019 (UTC)
  • @Ivanvector, portals are not content. Overwhelmingly, they are collections of content forks. The rest are just links wrapped in a Rube Goldberg machine. So there's no content to preserve. I have no objection to archiving deleted portals, but it would be a pointless exercise for anything other than wikiarchaeology. We don't for example archive deleted templates or categories, so why archive portals?
As to links, the problem with leaving them as links to redirects that it breaches the principle of minimal surprise. If reader clicked for example on a link to Portal:Port Harcourt and found themselves redirect to Portal:Africa, they would rightly feel misled.
And in many cases this would lead to a page displaying a box of multiple portal links which all redirected to the same destination (e.g. P:Foo City _+ Portal:Foo region + Portal:Foo country all redrecting to P:Africa, which is also listed). That would be highly misleading and annoying. --BrownHairedGirl (talk) • (contribs)
I didn't write it out but I was thinking that redirects of that sort would be like disambiguation links, where articles generally shouldn't link to them and readers would be encouraged to fix them. So if a reader clicked on a link to the Port Harcourt portal and found a message saying something like "this portal is defunct, here is a link to Portal:Africa and here is another link to instructions on how to fix this link", then they might be surprised, but they can find some relevant content if they want, and they have a guide to fixing that surprising link if they decide they want to contribute. It would save you owning replacement of all of those links yourself. Ivanvector (Talk/Edits) 13:06, 6 October 2019 (UTC)

Time to close this

At this point it appears that there is no consensus to get rid of all Wikipedia portals, and the discussion has devolved into a "what do we do now?" situation. If someone wants to centralize a discussion about which portals to keep versus which ones to delete then it should be held separately. - Knowledgekid87 (talk) 16:47, 8 October 2019 (UTC)

  • I second that. bd2412 T 16:56, 8 October 2019 (UTC)
  • Third, since while I don't see the current value in keeping portals we clearly aren't ready to say goodbye to them - or some value can still be gleamed. I just hope the cycle doesn't repeat if this does close as no consensus - that would basically be a drain on the wiki to keep repeating this over and over. Kirbanzo (userpage - talk - contribs) 03:34, 9 October 2019 (UTC)
  • I think it should be clear by now that there is no consensus among the community to delete all of the portals. We do need a guideline on the process to weed out the portals that pose problems, but this discussion isn't going to get there without a fresh start. - Knowledgekid87 (talk) 15:09, 9 October 2019 (UTC)
  • The need for better guidelines is strong. Tompw (talk) 15:58, 9 October 2019 (UTC)
  • Yes, just close as "no consensus" please. Nemo 15:27, 9 October 2019 (UTC)
Actually, I would say there IS a consensus (just not the one that either “side” was hoping for). I would summarize it as - Portals can continue to exist, but must adhere to strict guidelines that limit them. The missing piece is that we need to write those strict guidelines. Blueboar (talk) 16:07, 9 October 2019 (UTC)
I agree. --Sm8900 (talk) 14:58, 11 October 2019 (UTC)
Not quite, Blueboar. Face-smile.svg
The missing piece is that there is still nothing remotely resembling a plan for how to create portals which actually add value for readers in an era when portals are redundant, and how to maintain them when readers don't want them (which is why wise editors put their energies elsewhere, and portalspace is dominated by the less wise).
Where we've actually ended up is is in a situation which the same bunch of editors who have comprehensively mismanaged portal-space for 15 years will probably be reprieved to mismanage a smaller set of portals, while the community urges "do better" to a group who clearly are not up to the job. All that will happen out of this is to shrink their playground, without ever resolving either the fundamental conceptual problems of portals or the fundamental social problem of portals, which is that they have become the refuge of under-skilled editors who like making pretty pages with little or no critical discussion, and without the arduous burdens of WP:V, WP:RS, WP:NPOV etc. There are some skilled editors who work on portals, but they are are not the driving force. --BrownHairedGirl (talk) • (contribs) 02:20, 10 October 2019 (UTC)
  • As Blueboar says, the consensus is that portals should continue to exist. with that said, BrownHairedGirl, other editors with differing opinions have a valid opinion about some pratices to improve portals. however, the simple answer to the inital question is that portals should continue to exist. --Sm8900 (talk) 14:25, 10 October 2019 (UTC)
The main problem I see with portals are not the portals themselves but that no-one uses them.(I mean almost no-one). We should probably implement something to advertise them. TheTrainNoch (talk) 04:29, 10 October 2019 (UTC)
I agree with comment above, by @TheTrainNoch.--Sm8900 (talk) 14:02, 10 October 2019 (UTC)
  • The consensus is that portals should continue to exist? Only if you count just "Support" and "Oppose". If you actually read what those say then it's less clear with a significant number of opposes actually just opposing the removal of some selected portals.Lurking shadow (talk) 08:51, 16 October 2019 (UTC)
    How would you suggest that those selected portals be kept if portal space were to be deleted? bd2412 T 22:14, 16 October 2019 (UTC)
  • The best move for portal space now is to be renamed to "Content:". This will dumb down the importance of the portal itself, de-enshrine it so to speak, do away with all this nonsense all-or-nothing mentality off both sides, and sensibly refocus the purpose and substance of an important project. ~ R.T.G 00:02, 17 October 2019 (UTC)
  • It is apparent that this discussion will never reach a resolution and never come to an end of its own accord. It could occupy the proposals page for years with nothing coming of it. bd2412 T 01:13, 17 October 2019 (UTC)

One idea for continuing with the discussion

Please NOTE: Discussion of some of these topics is continuing at this page: Wikipedia talk:WikiProject Portals#A proposal for portal system overhaul Sm8900 (talk) 19:25, 10 October 2019 (UTC)

Well if anyone wants to start a topic about portal guidelines, then maybe as one good starting point, or maybe as one possible item to include, perhaps we might agree that at least there are some portals which are well-run and which prove the value of portals in general. this might be one possible starting point for establishing and illustrating some good practices for defining portals in general.

here is a HIGHLY incomplete list of some of these. can our group get some consensus that these are some of the portals that are considered valid and worthwhile? Is that one good starting point? By the way, the purpose of this list is just to agree on a few examples; this list is not intended to be complete in any way; i.e., this is not exhaustive, and I am not saying that all portals other than these should be deleted. Thanks!

Useful portals:

Thanks. Sm8900 (talk) 13:59, 10 October 2019 (UTC)


A guideline

I think what we need is a guideline on portals (the discussions says we don't have one, and that there was never a fully suitable one), one that includes a way to get rid(not necessarily delete) of bad portals relatively quick, and then we can look at this issue again. Right now it could be that the issues were simply caused by a lack of guidance and good faith problematic efforts. I have created a draft at User:Lurking shadow/PoG.Lurking shadow (talk) 15:34, 13 October 2019 (UTC)

Yes, we need more clarity on what portals should look like and which ones should exist. We've already got rid of bad portals: we are now down to 582 (including 19 at MfD), compared with 1500 at the time of WP:ENDPORTALS last year. Certes (talk) 16:14, 13 October 2019 (UTC)
We've gotten rid of some bad portals; it is quite possible that only a person who is a subject matter expert and an expert editor could determine the flaws (or value) in some portals. — Arthur Rubin (talk) 16:22, 13 October 2019 (UTC)
If you have any ideas on what to add to a portal guideline feel free to use the talk page or, if you think it's uncontroversial, add it to the page itself. Especially if it are issues with formatting which are not yet covered. Or if something in that draft would be very controversial or even downright a blocking issue on the way to a guideline(in your opinion, of course). I just saw that portals look like a problematic area right now and a guideline could clear things up and possibly prevent bad portals from being added in the first place.Lurking shadow (talk) 17:37, 13 October 2019 (UTC)
I've come up with a basic proposal about whether a portal is "notable" enough to be created here (I created it yesterday after a discussion at Portal talk:Australia). SportingFlyer T·C 13:31, 16 October 2019 (UTC)

The proposed guideline specifies a purpose for portals, but does not describe how the existing model may meet that purpose.
I think the "Purge to change the displayed image/excerpt/ITN/DYK" is, not only difficult to do in Wikipedia, but inappropriate in an encyclopedia. The IMDB model for subsections may be more appropriate. For quotes, for example, it displays one quote, but links to a list of all quotes. This does involve subpages, but the subpages are maintained separately, and (hopefully) transparently, without obscure template mangling. — Arthur Rubin (talk) 15:27, 16 October 2019 (UTC)

Politics Status Note
Portal definition WP:PORTAL Out of date No consensus or prevision for update in the current scenario.
Guidelines WP:POG failed proposal No consensus or prevision for new proposal in the current scenario. Dependent of portal concept update first.
Instructions WP:P/I In MFD process Wikipedia:Miscellany for deletion/Wikipedia:Portal/Instructions
WikiProject Portals WP:WPPORT semi-active The project was emptied after the reversals of several editions of the proposed new layout (single-page). The process of developing new tools and caregorization is stalled. There is no consensus for new goals.

Portals, a space without rules? Guilherme Burn (talk) 17:46, 16 October 2019 (UTC)

Proposal: Rethink Portals completely as a personal project

The current Portal system has clearly failed. While some editors certainly find portals to be useful, the vast majority of readers are either unaware of them or find a bewildering array of links that don't really go anywhere productive.

To that end, I'm proposing a radical re-thinking of what portals are.

With that thought, I stopped to reconsider what portals work like. And what comes to mind are user-curated "galleries" on some image sharing sites. These allow you to select images which already exist on the site and put them into a collection which is then publicly shared to other users.

In my mind, Portals are a personal curation of articles that someone finds useful to cover a specific topic-area. A few are multi-user collaborations, but those are exceptions. While some editors may find portals useful, the general readership has no use for them, and there are few rules governing what goes into a portal. The result is that most portals go neglected and wind up being nothing more than tumbleweeds on the project, while others are simply busy-work for a few folks to play around with.

My proposal is thus: "portals" take on the same role as Userspace essays. Individual editors create portals in their userspace, curate them and maintain them. If a portal is deemed useful enough to the project, it can then go through the WP:PROPOSAL process to be moved into project space. The Portal space itself would be completely deprecated in favor of this system. Instead, a project page would be maintained as a central listing of these featured portal entries, similar to how Guidelines and Essays are curated. Some guidelines for what qualifies as a curated portal page would need to be drafted, but the current ones around Guidelines and Essays give us a framework with which to build upon. Portals which do not meet those standards can continue to exist in Userspace, and portals that become neglected can be deleted or Userfied (upon request).

This is effectively starting over from scratch, but anyone who wishes to take a current Portal to work on could request a portal (or forked copy of a portal) be moved into their Userspace to update it & prepare for the new process. — The Hand That Feeds You:Bite 20:51, 16 October 2019 (UTC)

  • Oppose. If there is no consensus to eliminate Portal space, then there is no reason to move portals out of it. Also, there are numerous portals that are the collective work of multiple editors, so userfication is inapplicable. bd2412 T 22:29, 16 October 2019 (UTC)
    • I mean, that's assuming we have to start from the premise that we we need consensus "to eliminate portals space" in order to rework portal space. And I addressed the multi-editor aspect in my proposal. — The Hand That Feeds You:Bite 18:04, 20 October 2019 (UTC)
      • Yes, we require consensus to eliminate a namespace. Moreover, per WP:RM, consensus is required to move any page if that move is likely to be contested, which the page moves suggested here clearly are. bd2412 T 18:21, 20 October 2019 (UTC)
  • Oppose Seriously, what is this, a "start new votes until you get what you want"-palooza? Adam Cuerden (talk)Has about 7.1% of all FPs 22:40, 16 October 2019 (UTC)
    • I mean, the alternative is to let this be closed as yet another mess where no one agrees to fix a broken system... so yes, I offered another proposal. — The Hand That Feeds You:Bite 18:04, 20 October 2019 (UTC)
  • Reply. Or a more down to earth one. Portals are part of the content browsing system. Instead of punishing them or gaming against them in any way, help them to evolve. Change the portal namespace to the "Content:" namespace. What they need is the focus toward the correct outcome. Nobody should contribute to the discussion if their ultimate aim is not a desired outcome. Portals being the top level is not flying. Simply redefining the standards is not flying (that one's an emu). Abandoning portals is not flying. Give them a higher aspiration while at the same time simplifying this thing. Changing this namespace in this way will have a whole plethora of consequences. Think some of them over. Do it. ~ R.T.G 02:59, 17 October 2019 (UTC)
  • So, you're proposing that portals should be WP:Wikipedia books? :) --Izno (talk) 04:08, 17 October 2019 (UTC)
Woah!! There is another namespace!? I almost fell completely off my cushion... Portal is, I believe, the most wacky on the list. Psychology and aesthetics are a key here. Content:, is just what an encyclopaedia is. We will never be without content. Let's be proud about it, give it a space... Portal space is not a bad idea, but it makes contents a tool of portals, whereas portals should be a tool of content. "Content:", ad infinitum, et ultra... There is a button on the top left of your screen called "Contents", under the button called "Main page". There is a vote on to change the name from Portal:Contents to Wikipedia:Contents. WP space is administrative space. The title is simply back to front. Make it Content:Wikipedia. The portal as the building means a cave. Come out of the caves now, and it will help focus portals in the right direction, no funny business, promise. ~ R.T.G 08:21, 17 October 2019 (UTC)
Nope, that's not right, either. That should be Contents:Wikipedia, as in "table of contents", rather than Content:Wikipedia. The main-space is "content". Other portals, not even the 8 linked from main page, clearly don't qualify, because of the showcase model. Some Outlines might fit in that space, but none of the variable-display portals. — Arthur Rubin (talk) 20:15, 18 October 2019 (UTC)

Make it harder to create new lint errors

Many times a day, editors are making edits like this edit of Contempt of Congress, removing existing close table (|}) markup, which typically results in Table tag that should be deleted or Fostered content lint errors. Ideally, we wouldn't let editors save articles with new lint errors, but at least, we could warn editors on Show preview, something like,

Your edit is causing one or more new Table tag that should be deleted lint errors. Perhaps you have a table with two header lines, or a table without closing markup (|} or </table>).

Other warnings might be like these:

Your edit is causing one or more new Multiple unclosed formatting tags lint errors. Perhaps you are closing a <small> tag with another <small> tag instead of </small>.
Your edit is causing one or more new Self-closed tags lint errors. <small> should be closed with </small>, not <small/>.

We could also display such warnings on Publish changes, as we do now if the user doesn't enter an edit summary, so they have to press Publish changes a second time. It's time to take some steps to warn users of new lint errors when they edit. —Anomalocaris (talk) 20:05, 11 October 2019 (UTC)

  • Hell yes. Much of the reason we have so much WP:GNOME maintenance and cleanup to do is insufficient warnings at the pre-"Publish" state. We can recycle code from the WP:CS1 citation template system to implement this (it already provides warnings about various citation-mangling edits), and it could go further and detect various other problems in the text/code, over time.  — AReaderOutThatawayt/c 06:35, 15 October 2019 (UTC)
  • Support for High and Medium Priority errors in Article and Draft space (see Special:LintErrors for a list and here for a table by namespace). As a gnome who has fixed many thousands of pages with Wikipedia:Linter errors, it is frustrating to be unable to clear out an entire group of errors in a given namespace, only to be confronted with a new batch of preventable errors the next time I turn around. Errors like missing table endings can make whole sections of pages disappear from view. No editor casually breaks a table; it should at least take deliberate effort to do so. – Jonesey95 (talk) 13:38, 18 October 2019 (UTC)
  • Support any system that makes it harder to break an article and easier to fix it. A similar system is used for the TemplateData JSON, which verifies the code has no errors before allowing to save the page. --Gonnym (talk) 13:53, 18 October 2019 (UTC)
  • Only problem I can see is that sometimes, opening or closing tags might be within templates. (That rarely happens in article space, but can happen in template or portal space, for example). So I'd suggest to make this article and draft space only if it is implemented. —Kusma (t·c) 14:03, 18 October 2019 (UTC)
    • That is a good point; I have changed my Support comment above. There are templates that are designed to work only with other templates, and on their own, they may have Linter errors, but when combined as expected with their partner templates, they have no Linter errors. We can sometimes hack those with dummy code inside noinclude tags, but regular template editors shouldn't have to worry about that stuff. Also, template space is essentially free of actual Linter errors that affect transclusions, so it is easy to patrol; the primary population of Linter errors in template space is in DYK pages (which are not transcluded and should not live in template space, but that's a different rant). – Jonesey95 (talk) 18:18, 18 October 2019 (UTC)
    • Yes, we need to allow templates to have missing end tag and stripped tags because they are paired with other templates with the opposite lint error. Unclosed table tags can generate a Table tag that should be deleted lint error, and some templates have other lint errors that go away in actual use. Some Portals pull in linty code from articles, which is not the immediate responsibility of the portal editor. Modules, like templates, have their own idiosyncracies. Other than Template, Portal, Module, and perhaps their respective talk pages, I'd like to make it harder to create new lint errors in all namespaces. As noted at this thread about signatures that contain Linter errors, there are a small number of editors with linty signatures who have ignored or refused requests to bring their signatures into HTML5 compliance, and reminding them every time they try to save edits on a talk page would be a way to coax them into compliance. Of course, the majority of linty signatures have obsolete HTML as their only lint error, so if we don't check for low priority errors, we will miss those. —Anomalocaris (talk) 20:40, 18 October 2019 (UTC)
      • Re obsolete HTML: As far as I know, obsolete HTML does not currently break anything, which is probably why they are listed as low-priority errors. Given the WMF's slowness in implementing changes related to Linter errors (it is not clear to me that the WMF is maintaining attention on this project, leaving it as yet another half-done, buggy project like the Visual Editor), and en.WP's relative slowness in fixing the errors, I don't think it makes sense to block editors from saving low-priority errors. – Jonesey95 (talk) 17:20, 20 October 2019 (UTC)
        • The team has been busy porting Parsoid to PHP, driving toward the parser unification. Parsoid being in Javascript has been some significant technical debt. I expect that they'll return to the regularly scheduled activities later. The signatures issue in particular might be worth tagging for OWC since that's a separate direction from which the problem might be attacked. (I have left a comment on one or two tasks contemplating how best to store signatures that pointed to the linty signatures issue.) --Izno (talk) 18:44, 20 October 2019 (UTC)
          • What User:Izno said. Tidy removal was the first step in unifying parsers. Porting Parsoid to PHP is the second step and we are very very close to deploying it to production. Over the next 12-18 months, we will be integrating the two parsers more closely. We'll get back to some of the linting work - we will clean up some lint categories, and maybe add some other ones, and address some bugs. In principle, I support the display of lint errors pre-save / during preview. However, that needs some thinking around user impact since many lint errors are complex and/or may not have been introduced by the editors and might confuse them. For example, templates may have introduced them. If we try to introduce this feature parser unification is done, it will introduce additional latency to the save / preview time. But, yes, pre-save / preview-time display of lint errors is something we can consider. See previous discussion at https://www.mediawiki.org/wiki/Topic:Tcvi6s2x4fpkkcm6. We should track the feature request, feature details, constraints, etc. in a phab ticket perhaps. SSastry (WMF) (talk) 13:35, 21 October 2019 (UTC)
            • That is all good news. I hope it was not a typo or a slip when you wrote "Lint categories" above (see my thoughts on categories in the discussion page that you linked to; they are the worst way to get errors fixed except for everything else that has been tried). Lint-fixing gnomes would be greatly helped by having Linter errors in actual categories rather than (or in addition to) on the funky Special pages where they currently live. – Jonesey95 (talk) 00:16, 22 October 2019 (UTC)
              • Ha! I did mean "categories" as a generic term, not in terms of wikitext categories. :) But, noted reg. your observation about wiki-gnomes workflow tailored to categories. More broadly, the linter backend and UI needs work since we did not anticipate the volume of lint errors that did turn up. The original backend design isn't well-suited for his volume of lint errors we have encountered. To be continued. SSastry (WMF) (talk) 18:00, 22 October 2019 (UTC)
            • SSastry (WMF): It would probably be more work, but I had assumed that the "Show preview" and "Publish changes" warning would warn only about new lint errors. Perhaps the wiki-gnomes should take time after an edit that fixes recently-introduced lint errors and post a message on the talk page of the user who contributed the lint errors. Perhaps we should have one or more user talk page templates that would make it easy to display something like
Thank you for your contributions to Wikipedia. Your edit of Allama Iqbal Open University caused a Multiline table in list lint error where you used {{Urdu}} on a line that begins with an asterisk (*). {{Urdu}} and other navigation templates must be used on a line that does not begin with an asterisk (*), pound (#), or colon (:). For more information on lint errors and how to avoid them, see WP:Linter.
Anomalocaris (talk) 00:07, 23 October 2019 (UTC)
  • Comment: I'm pretty sure 98% of Wikipedia editors don't have any idea what a lint error is. I have only a vague idea, and most of what I know is based on seeing examples of lint errors, not because there's a good and easily understood definition of them. Keep in mind I've been editing for almost 15 years, and have tens of thousands of edits. Now, I wouldn't mind having a warning that I've made some sort of formatting error, especially if it will point to where the error is and how to fix it. But please let's not guilt-trip editors (let alone think about blocking them) for something as arcane as this. It's a formatting error, it is probably easily fixed (someone could even write a bot or two to do it, if they haven't already), and there is a plan to prevent them in the future. Risker (talk) 07:02, 23 October 2019 (UTC)
  • Strong Support for any assistance. I recall you (Anomalocaris) fixing a deprecated "center" tag on one of my pages, .. although I'm not very knowledgeable about HTML anymore, I think the more we help move things into acceptable HTML 5 and ultimately HTML 6 now - the better off our pages will be as HTML 4 drifts into "No longer supported" land. That's about the limit of any "lint" knowledge I have, but I support any nag screens that help here. — Ched (talk) 14:35, 23 October 2019 (UTC)

Why Rule G13 is not a smart idea.

See:

Wikipedia_talk:Criteria_for_speedy_deletion#Rule_G13_is_really_not_a_good_idea.

This is also relevant to the Village pump, therefore I thought I should refer to it from here as well. — Preceding unsigned comment added by Handroid7 (talkcontribs) 04:33, 12 October 2019 (UTC)

Limit the use of table templates on Wikipedia

Proposal A big example -> https://en.wikipedia.org/wiki/Ryzen

If you read from a PC Computer or a smart phone you see it loading all the contents on the page. Wikipedia better to change its focus to limit amount of table templates (& details related to table) used on "Main articles" and direct them to create sub page specifically for the "List of.." and tables. There commonly or too many on computer articles,transit and sometimes sports. Regice2020 (talk) 17:46, 12 October 2019 (UTC)

Discussion (Support or Oppose)

  • Support or mandate substitution provided that this only applies to templates that are entire tables and doesn't interfere with templatized rows/table elements like {{PresRow}} (a template that I made, for full disclosure), etc. – John M Wolfson (talkcontribs) 19:34, 12 October 2019 (UTC)
    Strongly oppose substitution as a solution, assuming @Regice2020: is referring to the use of templates like Template:AMD Ryzen 1000 Series. Substitution would just fork the content, if the page is getting too big move this content to another article or list. — xaosflux Talk 20:59, 12 October 2019 (UTC)
    I'd be up for that; statistics page like those in elections are not unprecedented here. – John M Wolfson (talkcontribs) 21:05, 12 October 2019 (UTC)
  • Substitution is a terrible idea. Agree with Xaosflux that unwieldy, over-detailed tabular content can be moved to spin-off article when appropriate (as we do with TV seasons' episode lists, etc.)  — AReaderOutThatawayt/c 06:36, 15 October 2019 (UTC)

Visual Editor on Talk Pages

Enable the ability to use visual editor to used on articles talk pages.02:13, 14 October 2019 (UTC)Regice2020 (talk)

Your Thoughts

The VisualEditor is poorly suited for talk pages at the moment, since it was built with content pages in mind and lacks support for signatures, indentation etc. It also doesn't solve some of the usability issues like knowing where to reply. Following the extensive Talk pages consultation 2019 the current development focus is the Talk pages project which will involve improvements to the talk page experience based on the existing wikitext model. the wub "?!" 16:05, 14 October 2019 (UTC)

T235285, the current design ticket, is looking a lot like reply-link so far. Not sure what else it'll bring to the table. Enterprisey (talk!) 16:15, 14 October 2019 (UTC)
I take that back, it looks much better, especially in terms of localization & parser robustness. Enterprisey (talk!) 16:24, 14 October 2019 (UTC)
If you're interested in making it easier to use talk pages, please put the mw:Talk pages project on your watchlist. Whatamidoing (WMF) (talk) 21:53, 20 October 2019 (UTC)

See article sizes in difference view.

I suggest that the difference viewer shows both the size changes and absolute sizes before and after the edit for comparison, just like in the version history (list of revisions).  –– Handroid7  talk 12:24, 17 October 2019 (UTC)

  • I would definitely support this. The more information, the better. bd2412 T 12:36, 17 October 2019 (UTC)
  • Support: Me too. GenQuest "Talk to Me" 12:47, 17 October 2019 (UTC)

The colour of nomination

The "nomination" template is used all over the encyclopaedia alongside the "won" template.

"Won" displays a green background. Green for go if someone won something.

"Nom" is displayed in a pinky pastel colour. It's not as red as other closely related templates, but it almost exclusively looks red where it is used. Red for stop, you lost.

However... Nominated for stuff like Oscars and BAFTAs... That's not a losers game. If you got nominated, you mightn't have won the star prize, but that is not a loss on your resume. It's a win, only it is a lesser win. Now we are not talking participation medals here, we are talking winners circle.

Everybody knows this, but here on Wikipedia we make them look like losers by having green versus red.

Have a look at this article (that's a featured article), for instance, particularly the infobox at the top right. That's a singer who seems to lose all the time.

And try this article (near the bottom). Now those guys are like, just pure losers aren't they?

What a bunch of losers, except, is that us talking about them or...

Let's have a more neutral colour for the nomination template. As pointed out by one of the contributors to the relative template area, it's not going to help talking about it there, because responses are rare in certain template areas, but a change would affect thousands of articles, so a broader discussion may be important. Are nominees losers..? Let's be fair to the nominees with this small but significant item. Support/Oppose, suggest colour.

Edit: Relative template displaying used colours: Template:Table cell templates. (This was requested to be discussed several times in the past but response was unsatisfactory, however this affects colour blind users, apparently 5+% of people, and it affects thousands, if not hundreds of thousands, of articles in the wiki) ~ R.T.G 02:15, 18 October 2019 (UTC)

  • Sounds good to me. – John M Wolfson (talkcontribs) 00:05, 20 October 2019 (UTC)
  • Colours are important. More to some, less to others, but very important to some. When your eyes weaken, and the walls of texts grow, colours are very helpful.
It is important for colours to be correct. Correct? Consistent.
Also important is that they are clear, crisp. High contrast.
Please do this RTG, and do it well. —SmokeyJoe (talk) 00:54, 20 October 2019 (UTC)
RE those losers Midland_(band)#Awards_and_nominations. Better grey than pink (faded red). Nominated is the default minimum to be in the table. Don’t highlight everything, it destroys the function of highlighting. —SmokeyJoe (talk) 00:57, 20 October 2019 (UTC)
  • Umm, wow. Talk about being US-culture-centric. Red is the "better" colour in a lot of other cultures (it's the first place ribbon in Canada, for example, with green as third or sometimes fourth place). Pick two colours that are both highly visible to those who are colourblind, using the appropriate visibility tests. (There are several tests available online, and you might want to ask the MediaWiki developers what tests they use to ensure appropriate visibility.) It's more important that the colours be different but also easily discerned. Risker (talk) 01:08, 20 October 2019 (UTC)
Where I am from, blue is often the sought after colour. Related search thread: "colour red higher chance of winning". ~ R.T.G 10:08, 20 October 2019 (UTC)
  • Ya' really want to fix it? Ditch the colors. There's no need for colors in such a place. --Izno (talk) 04:51, 20 October 2019 (UTC)
  • 86 the colours. They add nothing. —v^_^v Make your position clear! 05:13, 20 October 2019 (UTC)
  • For consistency I have changed Nominated to the "perhaps" style. I am not opposed to deep sixing the colours, but I'm not sure I'm in favour either. For some people the visual colour impact is useful, for others the words are more useful. All the best: Rich Farmbrough, 11:56, 20 October 2019 (UTC).
  • Grey, or neutral colour to contrast the silver, used often to note 2nd place in the same tables, per User:SmokeyJoe above. There is no standard colour for "nominated". ~ R.T.G 14:28, 20 October 2019 (UTC)
I disagree the colour looks red - most people can easily tell the difference between red and pink. I'd say status quo or gold (won) - silver (nom) -bronze (draw). As for the people who suggest ditching the colours, I'd like to know what they think the template should look like without them. Ribbet32 (talk) 18:19, 20 October 2019 (UTC)
Have you considered not USING a template? You will have more flexibility if you format by hand. That said, if you must use the template, perhaps regular print for nomination, and bold print for winners. Blueboar (talk) 19:04, 20 October 2019 (UTC)
This page:- Template:Table cell templates/doc provides a wide and fairly balanced table of examples currently used on "nom", "won", similar and related templates. I think the word is "lowlighted", where an item is highlighted but in a less luminous way. Some of the greys and pastel blues farther down may provide neutral colours without leaving a highlight scheme. However, though I don't strictly support it, a valid alternative is to highlight "won" on green, and to simply not highlight "Nominated" at all ("nom" produces "Nominated"). Bronze, silver and gold, are already in use by tables related to "nom", similarly to 1st, 2nd and 3rd, although, 1st, 2nd and 3rd are currently represented by the "nom" template, coded thus: "{{nom|1}}= 1 in the pinky colour.
Previous discussions have claimed that for the most common colourblindedness, the green and pinky are indistinguishable, by 5% of the population, but response to discussion over the years has been like, between 3 people who seem to have chosen in each case not to act upon such a low level of consensus. The articles which led me to this template have barely had a copyedit from me, so not using a template at all will be up to other, but standardisation seems the norm. ~ R.T.G 20:10, 20 October 2019 (UTC)
  • Support a more neutral color, like beige, tan, grey. Make sure it's compliant with MOS:ACCESS.  — AReaderOutThatawayt/c 08:04, 22 October 2019 (UTC)
    PS: This kind of trivia doesn't belong at WP:VPP; use the template's own talk page, and use {{RfC}} to attract attention to it. If we over-used this page for every little template-twiddling question, it would be so long that browsers would start crashing.  — AReaderOutThatawayt/c 08:05, 22 October 2019 (UTC)
    (Admin/BAG/template editor comment) Just to reply to the "wrong venue" comment, {{nom}} is watched by 9 people, and {{Table cell templates}} by 29, while the former template is used on over 24000 pages. The discussion did start at the template talk, but I encouraged the OP to post here because I have seen a large number of template-related RFCs disappear out of existence because no one wants to comment on template-space RFCs. Additionally, this template family has always raised some ACCESS concerns and I wanted to make sure that there would be a wide enough audience to also get some commentary on that issue. Basically, it's a large enough issue that it should see a wider venue of discussion. Primefac (talk) 21:12, 22 October 2019 (UTC)

RfC on inclusion criteria for lists of political endorsements

We have many stand-alone and embedded lists of political campaign endorsements (see for example, Category:2020 United States presidential election endorsements). The inclusion criteria of these lists are frequently debated, and the lists themselves subject to frequent additions based on unclear language published only on social media. This RfC attempts to create baseline inclusion criteria for such lists, which can be built upon as needed on article talk pages.

Links to some past discussions

Discussions are sprawling across many articles and project pages. This list isn't intended to be exhaustive -- just those which were easily findable.

The scope of this RfC is on lists of endorsements of political campaigns, whether stand-alone or part of another article. It does not apply to endorsements discussed outside of lists.

There are three proposals for inclusion criteria, which should be evaluated separately (one does not depend on the others). (If you would like to add to this list, please start a separate thread rather than add to this one).

1. Lists of endorsements should only include endorsements by notable people or organizations.

Note on #1: Whether or not it is necessary for the person to also have a Wikipedia article can be determined at the article level

2. Lists of endorsements should only include endorsements which have been covered by reliable independent sources.

Note on #2: This means endorsements should not be sourced solely to a Tweet or Instagram post, for example.

3. Lists of endorsements should only include endorsements which are specifically articulated as "endorsements".

Note on #3: Expressions of support, use of particular hashtags, comments about donating to a campaign, and other forms of praise of a candidate is often included as an "endorsement". Support of this criterion would require the endorsement be explicit. In most cases, this would require use of the word "endorsement" by the person endorsing or by media coverage thereof. Other language which can be understood as unequivocal endorsement can be discussed on a case-by-case basis (for example, "I am campaigning for Candidate X" or "I am backing Candidate X").

Rhododendrites talk \\ 14:27, 23 October 2019 (UTC)

Criterion 1: Endorsements should be by notable people or organizations

  • Support as per WP:LISTPEOPLE, et al. — Rhododendrites talk \\ 14:31, 23 October 2019 (UTC)
  • Support, ditto. Bondegezou (talk) 15:52, 23 October 2019 (UTC)
  • Support: this prevents laundry lists of non-notable people. I think whether or not this exempts certain people without their own articles, such as state-level legislators (currently the case on this article), should be determined on a per-article basis. Bobbychan193 (talk) 17:51, 23 October 2019 (UTC)
  • Support. Helps prevent trivia lists and reduces potential BLP problems from ambiguous listings. Potential to override on a case-by-case basis if coverage under criterion #2 below is very strong, such as might occur with an unusual endorsement (cross-party, for example). --RL0919 (talk) 18:09, 23 October 2019 (UTC)
  • Support per common sense: there should be no policy in which I can tweet out an endorsement of Vermin Supreme and be added to a list of endorsements. Both because who cares and for the respect of privacy of non-notable individuals. Wug·a·po·des​ 18:25, 23 October 2019 (UTC)
  • Support ~ R.T.G 18:33, 23 October 2019 (UTC)

Discussion of criterion 1

Criterion 2: Endorsements should be covered by independent reliable sources

  • Support - For reasons of WP:WEIGHT as well as RS. Self-published sources can be reliable for someone's own opinion, but the ephemeral sentiments expressed in a Tweet are far from a formal endorsement in most cases. — Rhododendrites talk \\ 14:31, 23 October 2019 (UTC)
  • (Weak-ish) support I don't think Wikipedia should be engaging in the WP:OR-like behaviour of trawling social media sites to compile lists of people who have tweeted in favour of a candidate. If an endorsement is notable as an endorsement, then it will receive decent secondary source coverage. I say "weak-ish" because I fear this will be difficult to police. Bondegezou (talk) 15:54, 23 October 2019 (UTC)
  • Support as the general rule. This is what we want for most content anyway, and we should not be in business of interpreting statements drawn from original research. If #1 and #3 are both clearly satisfied, then maybe an exception could be made, but those cases will typically draw third-party coverage anyway. --RL0919 (talk) 18:11, 23 October 2019 (UTC)
  • Oppose Let me preface this by saying that of course having a reliable source for every endorsement would be ideal. However, there are many individuals who are notable enough to have their own Wikipedia articles, but are often not notable enough to have their tweets and political sentiments covered by the media. This is especially true for non-politicians, such as many of the individuals who have endorsed Andrew Yang, Tulsi Gabbard, and others via tweets and social media. It is also worth noting that many of these independent sources are actually based on tweets themselves. Elon Musk is a prime example; he made a three-word tweet, and it was instantly picked up by myriad media sources. Also, per WP:TWITTER: Self-published and questionable sources may be used as sources of information about themselves, usually in articles about themselves or their activities, without the self-published source requirement that they be published experts in the field ... This policy also applies to material published by the subject on social networking websites such as Twitter, Tumblr, Reddit, and Facebook. As for the five criteria listed, as far as I'm concerned, none of them are violated by citing tweets that are published by the individuals themselves when they are explicitly endorsements. I agree that sometimes, tweets that are not explicit expressions of support slip in, but these non-endorsements can easily be removed by any editor. I myself have done this extensively on this article for the past few months. Bobbychan193 (talk) 18:13, 23 October 2019 (UTC)
  • The idea that there are many individuals who are notable enough to have their own Wikipedia articles, but are often not notable enough to have their tweets and political sentiments covered by the media strikes me as a highly problematic reason to include something. Inclusion of, well, anything on Wikipedia should be because it's important enough for independent sources to cover it. It's not the case that once a person becomes notable, whatever they say is worth including in the encyclopedia. (For context, a difference of opinion between Bobbychan193 and me on this point at endorsements in the 2020 Democratic Party presidential primaries‎‎ is what led me down a path searching for past discussions, to try to find precedent for a clear inclusion criteria). — Rhododendrites talk \\ 18:40, 23 October 2019 (UTC)
  • The whole point of endorsement lists is to list out endorsements. What makes one endorsement more important than another? Only if the media reports it? I disagree with this sentiment. It's not the case that once a person becomes notable, whatever they say is worth including in the encyclopedia. This is not what I am saying. Again, the whole point of endorsement lists is to list out endorsements, and I don't see why we can't do that if an individual tweets out an endorsement. (Other users have mentioned other reasons on that talk page. Some examples: Given the sheer volume of potential endorsements, not every single expression of support is going to be reported on, so it's inevitable that tweets will sometimes be the only place they will be mentioned and a celebrity's personal account tweeting in support has been used frequently as a source for endorsement and it is often without another citation. When they specifically say they support the candidate, it's an endorsement. If not, then remove most of Bernie Sanders' endorsements. The criteria in 2016 was explicit support and/or the campaign hashtag. Just pointing out arguments that other editors have laid out.) Bobbychan193 (talk) 18:49, 23 October 2019 (UTC)
  • Support per WP:BLP as potentially controversial information about a living person. Wug·a·po·des​ 18:26, 23 October 2019 (UTC)
  • Neutral/Oppose, per Criterion 1, it should be clear this refers to standalone information, and not information itself. ~ R.T.G 18:33, 23 October 2019 (UTC)
  • this refers to standalone information, and not information itself - Hmm. I don't intend to respond to all the opposers here, but I can't make heads or tails of that this means. Would you mind rewording? — Rhododendrites talk \\ 18:41, 23 October 2019 (UTC)
  • We have many stand-alone and embedded lists of political campaign endorsements, This RfC attempts to create baseline inclusion criteria for such lists. As to my words, the key is it should be clear this refers to standalone, as even short lists within independent articles, I imagine, will be regularly challenged by invoking this guideline. Maybe I should have said Conditional and demanded that "standalone" be made clear. Or maybe it should pass and wait and see if further clarification is required to avoid creep. I'll keep my eye on it, but I'm flying by this instant, thanks o/ ~ R.T.G 19:33, 23 October 2019 (UTC)
  • Thanks for clarifying. I did intend this to apply to lists of endorsements in both stand-alone and embedded lists, but not article prose. If people would support for one but not the other, that seems like a reasonable distinction to make, which could be factored in at closing. — Rhododendrites talk \\ 19:39, 23 October 2019 (UTC)

Discussion of criterion 2

  • I guess to clarify my stance, my main issue with this is that we shouldn't exclude an endorsement just because a media source didn't report it. Like, if a notable individual has clearly endorsed a candidate (based on our criteria #3) and the media didn't report it, it's still an endorsement. It just doesn't make sense to me to exclude such endorsements. Bobbychan193 (talk) 18:40, 23 October 2019 (UTC)

Criterion 3: Endorsements should be unequivocal and explicit

  • Support - I was surprised to see how many "endorsements" we include are actually just people using a particular hashtag, expressing positive feelings about a candidate, saying they've donated, talking about going to a fundraiser, etc. This also gets at the problem of using only social media as sources. Something published in a reliable independent source would be less likely to pick something like that up and call it an endorsement. — Rhododendrites talk \\ 14:31, 23 October 2019 (UTC)
  • Maybe As per basic principles, if we're claiming X backs Y, we need a source showing that X backs Y and merely expressing positive feelings or attending an event shouldn't cut it. That said, I am wary about requiring specific language, like expecting the word "endorsement". Different countries, even those notionally speaking the same language, use different words and phrases. There is a particular culture of endorsement in the US and we shouldn't be applying how endorsements are done in the US and the language used around them to other countries. Bondegezou (talk) 15:59, 23 October 2019 (UTC)
  • Preferably, but this is the weakest of the three suggested criteria. If there is a consensus of independent reliable sources under criterion #2 above that X has made an endorsement, then we should follow their lead rather than trying to interpret primary-source material. --RL0919 (talk) 18:14, 23 October 2019 (UTC)
  • Support Donating to a campaign, using particular hashtags, and/or attending any candidate event are not enough to be considered endorsements in isolation. This is because 1. Any individual can donate to multiple candidates or attend the events of multiple candidates (Example: Jack Dorsey donated to both Andrew Yang and Tulsi Gabbard) 2. Hashtags, such as #YangGang, could be interpreted as a way to boost the visibility of a tweet, or attract attention from people who search said hashtag. I think that minor variations of "I endorse xyz", such as "I support xyz", "I am campaigning for xyz", or "I am voting for xyz", are explicit enough to be considered support. (Example: again, Elon Musk's tweet. If myriad independent sources consider this an endorsement, then I don't see any reason we as editors can't similarly interpret other tweets. Why should we wait for a media source to essentially do the same thing?) I agree that this should be discussed on a case-by-case basis, especially for tweets that may be slightly more ambiguous than your standard "I support xyz". Bobbychan193 (talk) 18:25, 23 October 2019 (UTC)
  • Prefer 2. If a reliable independent source calls it an endorsement, we should list it as an endorsement regardless of whether an editor thinks it's equivocal. Obviously we should prefer unequivocal and explicit endorsements, but I'd prefer following RSs over our own judgment on what that constitutes. In the absence of 2, I'd support this, but am otherwise neutral on it. Wug·a·po·des​ 18:30, 23 October 2019 (UTC)
  • @Wugapodes and RL0919: I agree with both of you. I added this as separate from #2 for two reasons. First, in case #2 doesn't pass. Second, because there's still the question of interpreting the language of reliable sources. If a reliable source says that someone attended a fundraiser, tweeted in support of, used a particular hashtag, praised, etc., do we interpret that as an endorsement, or does the RS need to call it an endorsement? There are some other terms which, to me, are quite close in meaning or allow easy inference like "backed," "declared full support for," "campaigned for," etc. but there, too, I think it's tricky. — Rhododendrites talk \\ 19:17, 23 October 2019 (UTC)

Discussion of criterion 3

  • Please give an example of an equivocal or inexplicit endorsement, and why that disqualifies the notability assumed by Criterion 1. ~ R.T.G 18:33, 23 October 2019 (UTC)
Examples
  • "Let's win the era! @PeteButtigieg has me excited about the next generation of American government"
  • "I have listened with an open heart and an open mind and time after time, the individual who has continually impressed me with his consistent, thoughtful, and error-free presentation of our values and needs in this country is @PeteButtigieg. He has risen to the top"
  • "Go #PETE !!⁦@PeteForUSA2020 @PeteButtigieg"
  • "@PeteButtigieg i think you have a shot at uniting this country again. i am a big fan and am sending you all my support. if there is anything i can ever do for you pls let me know"
  • "Same" (responding to the one above)
  • "Buona settimana!!! HAVE A GREAT WEEK!!! Feliz semana! 👊🏻👊🏻👊🏻 @PeteButtigieg #mayorpete #petebuttigieg #accettomiracoli #aceptomilagros #buonacattivasorte #buenamalasuerte #tzn2020"
  • "This guy is so smart and on point and he wore the 🇺🇸 uniform. Good luck @PeteButtigieg - you are what this country needs."
  • "A candidate for #President that speaks, genuinely, of #unity, #prayer and #reflection. I'm all over that, thanks #PeteButtigieg #PeteForAmerica @PeteButtigieg"
  • "Still believe Mayor Pete is our best candidate for the presidency. His unique combination of qualifications is unbeatable. All our candidates are talented and good, but Mayor Pete stands out. He will be a great president. And we desperately need greatness in the Oval Office"
  • "Please RT. Only 174 $1 donations by midnight to reach goal for @TulsiGabbard !pic.twitter.com/KTOCZp0NNR"
  • “Oh noooooo, @KamalaHarris guess what?! @TulsiGabbard has your number. She is by far the better candidate. Go Tulsi"
  • "A Joe Biden/Kamela Harris ticket or a Kamala Harris/Joe Biden ticket would please me greatly!"
  • "GHosts for @BetoORourke fundraiser tomorrow evening in NYC:"
  • "Bernie @SenSanders or @elizabethforma (Elizabeth Warren) would be two people I would LOVE to see in the White House, as both of them would be capable and ready to fix the damage caused by the @GOP and the Trumpino crime family"
  • "God I wish we weren't a sexist hellscape so she'd get the nomination"
  • "Increasingly all-in for Elizabeth Warren, gotta say"
  • "Here's one very good reason to be for Elizabeth Warren. Wall Street is terrified of her"
  • "Greatest Of All Time! #GOAT twitter.com/ewarren/status/1179851099978846209 …"
  • "Russell Brand will be joining me in Los Angeles on Sept. 15"
  • "We need an uprising of consciousness #Marianne2020.com #JoinTheEvolution #WagePeace A #President who leads with #Love & #Intelligence ."
  • "I was there at his launch party in SF!"
  • "Andrew is actually the "not stuck in the past and open to new good ideas guy""
  • "read up on @AndrewYang. he's the only young candidate addressing issues that nobody else is. his politics are actually good (more than just giving every american $1,000/month), and he has a fun and transparent personality. I uhhhh, i think we ✈️ #YangGang 2020"
  • "It takes an amazing amount of strength to be this vulnerable in public. This display of emotion makes me admire @AndrewYang even more..."
  • "I've actually donated for the first time ever. New podcast with @AndrewYangVFA is up! Check it out on offthepillpodcast! #yanggang"
  • "LFG!!!!! #YANGYANG"
  • "Thanks man. Best of luck future Mr President!"
  • "Yanggang"
  • The above are all currently in the endorsements in the 2020 Democratic Party presidential primaries. I had removed them and they were restored. Ran out of steam at the end (there are a lot of refs, and I only searched for twitter). This omits the somewhat clearer but still uncertain "I would vote for this person", "I support this person", "I donated to this person", and so on. — Rhododendrites talk \\ 19:01, 23 October 2019 (UTC)
  • Full disclosure, I was the one who restored them. It was 50KB worth of removals and certainly a bold edit by size alone, so I reverted them (temporarily) based on WP:BRD. I view this RfC as the "Discuss" phase, and if there is strong community consensus to remove tweets as sources, then I do not oppose the re-removal of these entries. Bobbychan193 (talk) 19:09, 23 October 2019 (UTC)
  • My first impression of this is that it lacks a third party reliable source stating that each detail is individually notable beyond the fact of endorsement.
  • The endorsement is possibly notable, but saying yah boo fifty seven ways until Sunday about it is not notable at all. Oh how I love thee is notable, that they do. Oh let me count the ways is a bit wandering, unless you can establish the particular commenters way-counting as notable. ~ R.T.G 20:14, 23 October 2019 (UTC)
  • Oops didn't reply to the second part of your comment. Although I'm not sure what you mean by why that disqualifies the notability assumed by Criterion 1. It has nothing to do with the notability of the people speaking. It has to do with WP:OR, relying on Wikipedians to interpret someone's words to be an "endorsement". — Rhododendrites talk \\ 19:08, 23 October 2019 (UTC)
  • Replied above upon the examples, thanks. ~ R.T.G 20:14, 23 October 2019 (UTC)

General discussion: inclusion criteria for political endorsement lists

  • Personally I'm against ANY list of political support or endorsements in any way shape or form. It's one thing to say "Senator X supported Candidate Y in the past election" in a prose article. To my mind said "lists" or categories of "support political anything" goes against what our project is supposed to stand for and be. It's far too easy to put "list 1" which supports candidate A in a more front and center position than "list 2" which supports candidate B. IMO, there's far too much political POV pushing going on throughout wiki as it is - these "lists" simply add to that, and I can NOT support such things. — Ched (talk) 14:57, 23 October 2019 (UTC)
  • Just to be clear, this RfC isn't about the validity of the lists. Whether we should have them at all may be worth discussing, but at the moment we have oodles of such lists, so let's at least create some baseline rules. — Rhododendrites talk \\ 15:06, 23 October 2019 (UTC)
  • The sheer number of these lists suggests there's consensus for their existence. I agree with Ched that I'm not sure how useful they are, but I think getting consensus for their exclusion would be an uphill battle that would cause more problems than it's worth. Many of these are suitable as standalone lists per WP:LISTN (FiveThirtyEight for example keeps a running list and ranking of primary endorsements), so if we prohibit inclusion in articles they will and (and maybe should) be spun out. Those that can't will probably be included in the relevant article because the community doesn't agree, and we'll just wind up back where we started or worse: fighting edit wars over stupid stuff and blocking people who could otherwise be useful contributors to politics articles. For better or worse, I think it's best to let the lists be and figure out how to curate them to minimize the negative aspects of such lists. Wug·a·po·des​ 18:44, 23 October 2019 (UTC)
  • The US has a particular system of political parties and endorsements that doesn't always translate to other countries. I note that on UK endorsement lists for general elections, we don't cover members of a party endorsing that party, as that goes without saying in a UK context. (If a Conservative MP endorsed anyone other than Johnson in a general election, they'd be out of the party very quickly.) In comparison, intra-party endorsements dominate US endorsement lists. Likewise, when considering recent referendums, we didn't include every single SNP politician as endorsing Scottish independence: we just included the party as a whole doing so. Bondegezou (talk) 16:03, 23 October 2019 (UTC)
  • Just to note 2 things: 1. My comment above is in no way a reflection of or on Rhododendrites who I've seen around and I think they do excellent work. (I even appreciate this particular RfC/proposal) 2. I'm aware of the many lists out there - that doesn't mean I think they belong; hence my statement. I also fully aware that there's not going to be any removal of said lists. While I don't usually stick my nose into any of the political stuff - I am aware of it. I just don't care for how our project deals with it. — Ched (talk) 18:51, 23 October 2019 (UTC)

RfC: Proposed rewrite of the CSD Criteria

Due to the nature of the proposal, I think I should mention it here. Here's the link: WT:CSD#RfC: Proposed rewrite of the CSD Criteria InvalidOS (talk) 15:13, 23 October 2019 (UTC)

Idea lab

Mass create redirects of abbreviations

On Wikipedia I have often created redirects from abbreviations I observed in real life, often abbreviations of U.S. states I see in the media (example: Anywheresville, Tx.)

In Tokyo I noticed that the subway stations are all using the abbreviation "XXX Sta." or "XXX sta." on English signage. Creation of multiple redirects collectively takes a long time, and many editing hours would be saved if an editor writes a bot to do mass creation of redirects like these:

  • XXX Univ. (and variants like "Univ") for universities
  • XXX, U.S. or Canadian state abbreviation (like Houston, TX or Houston, Tx.) for U.S. and Canadian cities
  • XXX HS for senior high schools (Lamar HS)
  • XXX Sta. (and sta.) for railway stations, like Shinjuku Sta.)

WhisperToMe (talk) 00:53, 3 October 2019 (UTC)

If memory serves (and it may not; I'm sick, and my brain melts at low temperatures), User:Headbomb did similar work with academic journal abbreviations, and therefore might be able to help you figure out whether it's a good idea. WhatamIdoing (talk) 19:13, 3 October 2019 (UTC)
Awesome! I would appreciate getting his advice WhisperToMe (talk) 02:17, 4 October 2019 (UTC)
  • Sounds like a useful proposal, but individual classes of redirects need to be carefully thought out first. For example, is there a danger that Foobar, NC, a redirect for the town of Foobar in North Carolina, might not be confused for a village of the same name in South Africa's Northern Cape province, or that Foo, CA might be ambiguous between places in California and in Canada. (I'm admitting these examples are contrived – inasmuch as I don't know if such abbreviations are commonly used in this way in Canada or South Africa, and the chances for such coincidences are generally low – but they're illustrative of the potential for ambiguities that need to be explored.)
    Also, it's a good idea to be parsimonious: for example, don't create both XXX Univ. and XXX Univ – for a variety of reasons (some of which are documented at WP:COSTLY), redirects incur a maintenance cost over the long term and it is best to only create as many redirects as are strictly necessary. – Uanfala (talk) 14:58, 10 October 2019 (UTC)
    • @Uanfala: 1. The part about not wanting to get tied into ambiguous place names sense, and I imagine part of it comes down to using Regex skillfully and part adding a routine a bot that checks what the destination article would be before writing the redirect?
    • 2. As for the bit about creating redirects, I have created both "XXX Univ. and XXX Univ" because of issues with Wikimedia's searching capabilities. Perhaps if they improve it will become less necessary? Also my understanding is that bots make redirect maintenance (often) less necessary as, if the destination article changes location, bots will later retarget all the redirects. **WhisperToMe (talk) 14:44, 15 October 2019 (UTC)

Visual change the appearance of user pages compared to regular pages

Title. When you click to a user page it's still confusing to me, and I assume to regular users, to differentiate immediately between an official edited page and a user page. I think that something very simple like a slightly darker gray background to user pages would be worlds more helpful for every party. Pretty simple suggestion. Kugihot (talk) 19:39, 3 October 2019 (UTC)

At the very top left you should see in big bold letters the title of the page. If it just says some article topic, like Plato, then it's an article. I'm not sure what an "official edited page" is, but if it says "Wikipedia:" with the colon and something follows that - it's a wiki policy, guideline, essay, noticeboard etc.. Example: Wikipedia:Administrators' noticeboard or Wikipedia:Village pump (technical), if it starts with "User:" , like [[User:Kugihot]] then it's a user page. Hope that helps. — Ched (talk) 20:10, 3 October 2019 (UTC)

A slightly darker grey background might make user pages difficult to read. At the top of the user pages there is a note saying user pages are user pages. Vorbee (talk) 06:21, 4 October 2019 (UTC)

Adding the following to your User:YourNameHere/common.css will change the background color of the left and bottom panes of user and user talk pages to the specified color:
[class*="page-User_"] { background-color: #BFFFFF; }
Unfortunately, it will also change the color of pages in article namespace that start with "User ", like User interface. (edited) —[AlanM1(talk)]— 16:21, 9 October 2019 (UTC)
Update: I missed the fact that there are classes for each namespace, named "ns-x", where x is the namespace number from WP:namespace. So, this is better/faster and eliminates the problem with mainspace pages starting with "User ":
.ns-2 { background-color: #BFFFFF; }
To affect multiple namespaces, use a comma-separated list:
.ns-4, .ns-5 { background-color: #E0FFE0; }
—[AlanM1(talk)]— 17:20, 10 October 2019 (UTC)

Anyone who is interested in this idea: Please put mw:Talk pages project on your watchlist. One of the projects might be making "talk" pages (all of them, not just article talk pages) visual different from other pages, so that it's more obvious that you should treat those differently (e.g., sign your comments on a talk page, but don't sign in the middle of articles). Whatamidoing (WMF) (talk) 00:11, 11 October 2019 (UTC)

Why is Wikipedia non-profit?

why don't we run ads at the top or bottom of articles?--SharabSalam (talk) 09:18, 7 October 2019 (UTC)

Two different questions. But the answer is: Because we decided it this way, for a variety of reason. With respect to the second question: Without ads we are not beholden to advertisers. And we do not piss off users. And we waste less bandwidth. And we make the site more performant. --Stephan Schulz (talk) 09:25, 7 October 2019 (UTC)
I thought that if we run ads, Wikimedia wouldn't be non-profit. I think if we added ads at the bottom of the article it wouldn't piss off users. Editors can also earn part of the money Wikimedia gets from the ads. That would be very helpful to editors who are editing here for free. Yesterday I watched an interview with an editor here who had made 1/4 or 3/4 (I don't remember) of what is in Wikipedia and when the interviewer asked him how much money he earns from this, he said none!. Isn't that very disappointing?--SharabSalam (talk) 09:43, 7 October 2019 (UTC)
Non-profits can earn money, they just cannot make a profit (at least not one that is distributed to its principals, or that goes beyond its non-profit purpose). Adding ads would sure piss me off (and I'm a user). I'm sure others would share that sentiment. I doubt that there is an editor who made 1/4 or 3/4 or indeed any reasonable fraction of what is in Wikipedia, although we do have some very prolific contributors. Many of us who donate time to the project do so because it is a non-profit. Why should I give my work to a commercial entity? Unless they pay my going rate, which would be very hard to recoup with ads...at least when applied to all editors. --Stephan Schulz (talk) 12:02, 7 October 2019 (UTC)
Most likely, the OP refers to the editor who was reported to have touched one-third of the articles on en-wiki. Clearly the OP didn't retain much more than the headline. ―Mandruss  03:59, 8 October 2019 (UTC)
According to CBS, as long as I make an edit to every article, I am responsible for the entire Wikipedia. –xenotalk 06:55, 8 October 2019 (UTC)
Looking at that piece of journalism, the non-English Wikipedias have "millions of translated article", which would leave very few original ones. Maybe I should tell the people on de: ;-). --Stephan Schulz (talk) 08:26, 8 October 2019 (UTC)
It would cease to be a free encyclopedia if it were run for profit and running ads results in the inevitable influence of advertisers on content (and other) policies. Wikipedia has been strict about conflicts of interest since forever, so I am sure there would be consensus against this if it was proposed - perhaps it has been in the past, not sure. Quora is a website which thinks it's a "competitor" of Wikipedia but is run for profit and has most of its modus operandi dictated by its advertising partners. In any case, even if the WMF did make money from advertisements on Wikipedia I doubt they would share any of it with the editors. – filelakeshoe (t / c) 🐱 10:02, 7 October 2019 (UTC)
It's not disappointing at all. There are many other reasons to create works than the profit motive. SportingFlyer T·C 11:23, 7 October 2019 (UTC)
Allowing advertising on Wikipedia has been debated in the past (see Wikipedia:Funding Wikipedia through advertisements). The community of editors has consistently and strongly opposed advertising on Wikipedia, and I doubt that will change any time in the foreseeable future. - Donald Albury 13:23, 7 October 2019 (UTC)
Non-profit because it shields from liability .....all because of Section 230 of the Communications Decency Act.--Moxy 🍁 03:42, 8 October 2019 (UTC)
I would say that this is a for-fun kind of thing, not a money-making scheme. Geographyinitiative (talk) 09:40, 8 October 2019 (UTC)
It isn't the non-profit status of the Wikimedia Foundation that allows it to avail itself of section 230 (Internet service providers and Internet search engine companies, for example, benefit from its protections). It's the lack of editorial control on its part, thereby assuring that the "information content provider" (as described in section 230) remains the Wikipedia users. isaacl (talk) 18:38, 8 October 2019 (UTC)
Advertising implies tracking. How else would the advertisers be sure their advert has been delivered as many times as they're paying for? That in turn means violating the privacy of your IP address and your off-wiki identity which you were guaranteed when you signed up - Wikipedia:Why create an account? -- Cabayi (talk) 10:25, 8 October 2019 (UTC)
I would suggest that perhaps Wikipedia should in fact allow some advertising. we are one of the top websites worldwide after all. there's no reason it should be so hard for Wikipedia to obtain enough funding to operate smoothly.--Sm8900 (talk) 13:05, 8 October 2019 (UTC)
The Bible should have advertisements. The Bible is one of the top books in the world. Why not add some advertisements in every copy? No reason not to. Buddhist monks should have ads on their foreheads. Encyclopaedia Britannica should have a page of ads every ten pages. Merriam Webster should have thirty pages of ads at the back. All that wasted ad space on the sides of the Kaaba! Gravestones too! (actually I have seen a discrete ad on a gravestone) Hell, add adverstisements on the dollar bills! That would be awesome. Jails should be sponsored. "Bud Light Correctional Help Center" Your name should be an advertisement man- go change it. If you don't change your name to Dick Microsoft, you have wasted an economic opportunity. That's my opinion~~haha Geographyinitiative (talk) 13:22, 8 October 2019 (UTC)
Pepsi Cola Mars Organic Molecule Analyser Geographyinitiative (talk) 13:45, 8 October 2019 (UTC)
Geographyinitiative, why are Pepsi sponsoring something already sponsored by Mars? Cabayi (talk) 14:18, 8 October 2019 (UTC)
The sad thing is that we already accept advertising, we just don't charge for it. -- RoySmith (talk) 14:07, 8 October 2019 (UTC)
Large chunks of Wikipedia are already advertising. We have some companies’ entire product lines covered. We have navigation templates for many product lines. For example, we have a better catalogue of Microsoft products than Microsoft.com. Levivich 06:21, 12 October 2019 (UTC)
Money is the root of all evil. End. ―Mandruss  17:52, 8 October 2019 (UTC)
I would suggest the OP to look at the history of Enciclopedia Libre - when even the slightest hint of ads came, the userbase of ESwiki rebelled and made a fork. WhisperToMe (talk) 16:21, 15 October 2019 (UTC)

I have a feeling that discussion on whether Wikipedia should allow adverts. is already covered at Wikipedia: Perennial_proposals. Vorbee (talk) 18:46, 16 October 2019 (UTC) It is - it covered at Section 1.4 of this. Vorbee (talk) 18:51, 16 October 2019 (UTC)

Mobile version diffs

Hi, so why isn't there a way to undo changes from the diffs in mobile version like the desktop version? I think if we add a button for undo next to thanks button it would be great. Most editors use mobiles while editing including me! I have to switch to desktop version if I need to revert.--SharabSalam (talk) 09:22, 7 October 2019 (UTC)

@SharabSalam: reliable, consistent code just hasn't been developed yet - but you can try using or forking a userscript for this, such as meta:User:FR30799386/undo. — xaosflux Talk 15:46, 7 October 2019 (UTC)
Xaosflux, I used that tool before, it was awesome. I stopped using it because the editor who made it got blocked (I think indefinitely) from English Wikipedia. I fear that they might use it to compromise editors accounts. I don't know how codes in Wikipedia work. Do you think it is safe?--SharabSalam (talk) 07:34, 8 October 2019 (UTC)
@SharabSalam: I'd have to spend a little time reviewing it, but you can always fork it once you have a version that you think is safe (copy paste it to your own userspace) - you would not gain future "improvements" but you would not be subject to arbitrary changes. — xaosflux Talk 11:09, 8 October 2019 (UTC)
Done! Thank you so much for your support.--SharabSalam (talk) 11:36, 8 October 2019 (UTC)
@SharabSalam: You can undo/rollback changes on mobile if you enable mw:AMC mode on your device. – Ammarpad (talk) 06:38, 15 October 2019 (UTC)

Anti-Vandalism Tools and Edit Conflicts

Some Wikipedians use Anti-Vandalism tools like Twinkle to make reverting easier and faster. These tools can also leave custom warnings on others' talk pages. However, I noticed that a few times, I edit-conflicted others, even those using tools. Then, even though the operator was edit-conflicted, the system will still leave a message on a talk page, even though the person did not revert. Take a look at this diff for an example. I reverted the previous edit, edit-conflicting Serols (who I am inviting to this discussion), who uses Huggle, in the process. I was going to leave a message on the talk page, but he already left a message. My idea to prevent something like this is to have the code in the tool detect when there is an edit conflict, and will not warn the user as a result. I cannot wait for your thoughts. Thanks for reading, and please comment on this. --LPS and MLP Fan (Littlest Pet Shop) (My Little Pony) 21:40, 7 October 2019 (UTC)

@LPS and MLP Fan: I believe Twinkle will open the user warning form for you only after the revert has been performed (successfully). This is the ideal behaviour. I am not familiar with the other tools but if there are issues with them please raise it on the tool's talk page such as at Wikipedia:Huggle/Feedback. SD0001 (talk) 16:54, 9 October 2019 (UTC)

Change in print stylesheet

When you print a page (or use the print stylesheet by any other means), the URL of external links are appended within parentheses after the link (as customary in print stylesheets). Since Wikipedia by nature has a lot of interwiki links, I would suggest that even those links have the URL appended. That would help tremendously in finding those link targets, because not every interwiki link's text is the same as its target.

Example:

The page Entity Framework has in its first paragraph an interwiki link to Visual Studio. When this section is printed, that link will only be underscored.

In the same History section, the second last paragraph, there is an external link to Entity Framework 6's Github repository. When this is printed, that link will be underscored with the URL appended, like this:

   GitHub (https://github.com/aspnet/EntityFramework)

//End example.

I realise that one big downside with implementing interwiki links in the print stylesheet the way I proposed, is that some pages have a lot of interwiki links and those pages would get cluttered very quickly when printed. Could a compromise be that there is a toggle in user settings on whether or not you want interwiki URLs to be visible?

Oliver twistor (talk) 12:48, 15 October 2019 (UTC)

Idea development help needed: Preventing WP:PRIMARYTOPIC from being used as a shield to perpetuate androcentrism

Below is my draft proposal. I would appreciate as much feedback as possible:


WP:PRIMARYTOPIC should not be used as a shield to perpetuate androcentrism.

Okay, I may have lost a few of you there. First, let me explain what I mean by this, then I'll explain how I envisage this rule tweak being used in practice. Per the [Wikipedia article on the topic: ‘Androcentrism is the practice, conscious or otherwise, of placing a masculine point of view at the centre of one’s world view, culture, and history, thereby marginalising femininity’. The essay, WP:WAW, sums it up as ‘language and images that make male the "Self" and female the “other”’. The essay goes on to advise: ‘Avoid labelling a woman as a female author or female politician, unless her gender is explicitly relevant to the article […] Linguists call [the practice] markedness. Treating a man who is a writer as a "writer" and a woman as a "woman writer" presents women as "marked", or the Other, requiring an adjective to differentiate them from the male default’.

Wikipedia article naming policy, however, can occasionally perpetuate (and entrench) such practices. A recent example comes courtesy of a requested page move, which I submitted, seeking to make the England national football team page a disambiguation page, with article currently given that title moved to ‘England men’s national football team’. Another editor, User:Jopal22, suggested “England football team (men’s senior)”. In truth, the new name of the article wouldn’t be of much incidence, so far as it didn’t show men as the ‘default’ gender, with women marginalised.

However, a common response arose. Wikipedia policy on the naming of articles, primarily WP:PRIMARYTOPIC, was used to justify the continued marginalisation of women. Though arguments were made (by myself and others) against the men’s team’s page being any more ‘primary’ than the women’s team, this argument was not persuasive, and no positive consensus was reached. If the wording of WP:PRIMARYTOPIC was amended, Wikipedia would recognise that there is no default gender, with WP:NOPRIMARY then applying. My suggestion is to amend the final paragraph of WP:PRIMARYTOPIC as follows:

In most cases, the topic that is primary with respect to usage is also primary with respect to long-term significance; in many other cases, only one sense of primacy is relevant. In a few cases, there is some conflict between a topic of primary usage (Apple Inc.) and one of primary long-term significance (Apple). In such a case, consensus may be useful in determining which topic, if any, is the primary topic. If a gender qualifier is required to disambiguate one topic from another, it must be mirrored in any corresponding articles (e.g. United States men's national soccer team and United States women's national soccer team, rather than United States national soccer team and United States women’s national soccer team). — Proposed changes in bold.

This small change would help us take a big step towards preventing the marginalisation, the marking, and the othering of women on Wikipedia. We must recognise the harm that Wikipedia does, not only by failing to challenge androcentrism, but by actively perpetuating it. Note: User:LtPowers raised this eight years ago, but I’m not sure it’s been raised since. See here for the discussion that generated at the time. Domeditrix (talk) 20:48, 17 October 2019 (UTC)

This isn't a terrible idea in a vacuum, but I don't think it has any chance of going anywhere in the context of Wikipedia. The general principle is that except in extreme cases, Wikipedia follows general practice; it doesn't try to set it. Moreover, when you frame this in terms of "marginalizing women" and start using dog whistles like "marked" and "othering", I think you're setting yourself up to fail. This sort of approach will undoubtedly alienate a lot of people. And in any case, I think the ultimate problem is with PRIMARYTOPIC. It's vague, and people can often insert their own biases when invoking it. But trying to carve out an exception (even a noble one) for one case is potentially going to lead to many more exceptions being (or at least attempting to be) carved out. And I think that's going to make a lot of people squeamish as well. But that's just me, and others might disagree. –Deacon Vorbis (carbon • videos) 21:12, 17 October 2019 (UTC)
I have a few things to say around this, so will respond a bit more later. But on the whole this is an issue that keeps coming up and it does need clearer guidance in wikipedia across articles. At the moment we are slowly getting messy wikipedia pages like Template:England national football team, where the topic title links to the mens team, but the contents are a mixture of mens/womens/other. But one thing I would say is if it wasn't painful to discuss it in talk pages, I don't think the WP:PRIMARYTOPIC does stop us using the names “England football team (men’s senior)” and “England football team (women’s senior)” as I suggested. The PRIMARYTOPIC is build on what you'd get back when you search for a subject, including wikipedia page views...but the answer to that also depends on when you search. The popularity of these articles is cyclical and if you look at https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org&platform=all-access&agent=user&start=2019-03-26&end=2019-10-16&pages=England_national_football_team%7CEngland_women%27s_national_football_team you will see that undeniably (and this will be in the media too), that the PRIMARYTOPIC could be applied to the womens team for a period, as it was way more popular during the womens world cup. So the argument that there is a clear PRIMARYTOPIC is false. Therefore is might be better if we look to change wikipedia policy to change PRIMARYTOPIC to have the caveat that it must be consistently primary to not need clarification. Also be careful not to come across as WP:RGW in your reasoning for wanting to changes, as there will be big push back on that Jopal22 (talk) 21:57, 17 October 2019 (UTC)
I think there are a lot of interesting ideas here. In particular, one way to circumvent this could be to incorporate language from Wikipedia:Writing about women#Male is not the default. There is policy for this elsewhere, it just isn't articulated explicitly in PRIMARYTOPIC. SiliconRed (talk) 22:42, 17 October 2019 (UTC)
Just noting, that Wikipedia:Writing about women#Male is not the default is not wikipedia policy, it is a WP:ESSAY. i.e. Essays have no official status, and do not speak for the Wikipedia community as they may be created and edited without overall community oversight. Following the instructions or advice given in an essay is optional. Jopal22 (talk) 07:28, 18 October 2019 (UTC)
  • I'm against Domeditrix's version of this, primarily on the grounds of Wikipedia not being designed to try to drive change. It would probably be positive if the media did this (and then us), but I don't want us to have to spend huge amounts of time considering and then defending various attempts to push the public into certain behaviour as if we do this a strong case can be made for other changes being needed. Nosebagbear (talk)
I do, however, think there might be something for Jopal22's idea that PRIMARYTOPIC should include the caveat "consistently primary to not need clarification". I'm not sure where we'd draw the line on consistently (if one group is the primary topic 358 days a year, that would probably be sufficient), but I don't believe it's so damned to vagueness to be ruled out on those grounds. Nosebagbear (talk) 09:35, 18 October 2019 (UTC)
A few things I would challenge
  • Just because something has a female identify does not mean the mirror is "mens". For instance The Open Championship, World Snooker Championship and PDC World Darts Championship have female versions, but the "mirror" version is non gendered and can include women. For instance I wouldn't want Reanne Evans to be changed from This made her the first woman ever to win a World Championship match to This made her the first woman ever to win a Men's World Championship match as if she is competing somewhere she doesn't belong. So I would caveat "mirror" to being backed up by the governing body.
  • With things like Manchester United Football Club and Manchester United Women Football Club this are is still messy. The Football Club includes both mens and womens teams so there should theoretically an article called Manchester United Football Club with Manchester United (men's team) and Manchester United (women's team) subarticles like American college sports (e.g. Kansas Jayhawks). But this is where I back up the WP:PRIMARYTOPIC. Nearly everyone looking at Manchester United Football Club would expect to see it dominated by the mens team/history (womens team has only been around a couple of year). Also given growth of womens football is relatively new, the goal post are moving about how they frame things e.g. changing it from framing as Manchester United Women Football Club to Manchester United Football Club Women. Therefore I think it would be overkill and far too soon to look at altering football club articles. (especially as Man U refer to them as the "First Team" and "Women's team - wikipedia follows the conventions used by the media and governing bodies and does not try push a progressive viewpoint without this)
  • Where it should be quite clear is things like 2020 ICC T20 World Cup being renamed as 2020 ICC Men's T20 World Cup (just look at the logo in the same page!)
Therefore I would look for two changes to primary topic. a) If there is cyclicality for primary topic then we should treat as no primary and disambiguate. b) If the official name or governing body references gender to disambiguate it competitions, then wikipedia should too.
Jopal22 (talk) 14:54, 19 October 2019 (UTC)
I most often get the conclusion or argument in many such male gender tournament or team cases that, it is in-consistent with the other articles , which often create chaos. Today all federation and council of sports are bringing disambiguation in their tournaments. As suggested above by Jopal22, Wikipedia policies should be reformed accordingly, as in recent cases it can be seen that the article name of the tournament is inconsistent with the logo of the tournamnet itself rather than all other previous editions of tournament. And most important point which should be addressed, wikipedia always believe in providing citations and sources, so when all citations show gender disambiguation, why the articles are ambiguous in nature. I think its high time that this things should be addressed. And more than that such a change is not new, many more articles are being created disambiguously like that of Men's Hockey World Cup, 2019 FIVB Volleyball Men's Nations League, 2020 Men's World Ice Hockey Championships, NCAA Division I men's swimming and diving championships and almost all article related to athletics. My simple logic and idea is- If any board, council, federation and authority addressing name of their tournament, competition, meets and even team in a disambiguous way, distinguishing "Men's" from "Women's" and all sources indicating the same, then Wikipedia should also be created with the same official name.Dey subrata (talk) 19:29, 19 October 2019 (UTC)
@Dey subrata: - I guess your fun next task with "If any board, council, federation and authority addressing name of their tournament, competition, meets and even team in a disambiguous way, distinguishing "Men's" from "Women's" and all sources indicating the same" is where the official name gets changed but the sources stick with common usage and don't usually/ever call it by the changed name Nosebagbear (talk) 22:59, 20 October 2019 (UTC)
This is, incidentally, the issue with the England national football team article. The English Football Association website references the "Men's Senior" and "Women's Senior" teams. WP:PRIMARYTOPIC and WP:COMMONNAME have been used to prevent any name change to the article of the men's team reflecting this. Domeditrix (talk) 23:13, 20 October 2019 (UTC)
@Domeditrix: and @Nosebagbear: See if we think every board or federation will do same at a time, it will never happen, so is with the source. There are 100s of games and sports and 1000s of tournaments. It will never happen instantaneously. So our move here will be to change things step by step. Like for example now ICC (cricket council) started to distinguish Men's tournament from Women's tournament, they start it from 2020 ICC Men's T20 World Cup and 2020 ICC Women's T20 World Cup bringing disambiguation. The most interesting thing with it is all major or popular website of cricket are also disambiguously displaying names of tournament and Men's record and Women's record separately. Even ICC too have shown record separately now. Some sports already did are "Hockey" and "Athletics". So I think we need to take one sports at a time and change wikipedia articles accordingly. Otherwise if we wait for all sports to bring disambiguation, it will never gonna happen. Dey subrata (talk) 23:55, 20 October 2019 (UTC)
I never said, or even implied, that'd I'd advise shifting sports wholesale or not at all. Nor did I say that all or nearly all sources on a tournament (et al) would need to change to match the official name before altering the wikipedia article would be warranted. However, for any given sport/tournament/etc, the recent sources would need to be at least someway using the new name. Once it's into "no-consensus territory", then obviously we'd opt for the official name. That doesn't however help in use cases where the sources are always not using it. I supported the consistently as a possible alternative, with the caveat that consistently doesn't mean 100% and further discussion would be needed on that aspect. Nosebagbear (talk) 09:44, 21 October 2019 (UTC)
  • I like and support these ideas. Levivich 01:07, 22 October 2019 (UTC)
I think the proposal as written isn't too helpful. There are reasons why things are listed as "women's" without the opposite. There is a WP:RIGHTGREATWRONGS argument here. The snooker one above is a good one, as is any sport where the rules don't specifically say it's a men's game, but most of the players are men. Other sports do have "men's and women's". For instance, the 2010 WPA Men's World Nine-ball Championship was the only event to be known as the men's event (as opposed to the female event of the same name, but later dropped the name as it stopped women from wanting to play in the qualifiers.


II still haven't seen a compelling argument that the articles for national sides need changing above the Primary topic. Real life has a way of disambiguating these topics, we should follow suit (regardless of how sexist it is). If it changes (and it most likely will) then we should too, but not until then.Best Wishes, Lee Vilenski (talkcontribs) 19:41, 22 October 2019 (UTC)

Use of IUCN range maps

I am writing an online book about birds of Sierra Leone (which will be free) and would like to use the IUCN range maps. IUCN so far has refused to give me permission. Accounts in Wikipedia for many species, however, include the IUCN map. For example the map for African Darter appears to be identical to the IUCN map except for the color. For many other species, neither Wikipedia nor Wiki Commons-Images has a range map. My questions are:

1. Has the specific issue of using IUCN maps in Wikipedia been discussed (I could not find a discussion)? If so where? 2. If not, would it make sense to discuss the issue (hopefully involving IUCN). Topics for possible consideration include: a. Could Wikipedia approach the IUCN asking for help in resolving the issue. The current state in which some maps are reproduced exactly (except for color) seems a little silly. b. If IUCN will not let Wikipedia use its maps, then what is the best way for users like me to make maps based on IUCN.

Thank you.

Jon Bart — Preceding unsigned comment added by Jonathanbart (talkcontribs) 07:32, 22 October 2019 (UTC)

  • The IUCN Terms of Use are pretty clear: [6] If you are certain the African Darter map is the same as the IUCN map except for the colour, it needs to be deleted as a copyright violation as it would be considered a derivative work by the copyright owner. I assume you've emailed them and have not received a response? SportingFlyer T·C 10:28, 22 October 2019 (UTC)

Thanks for the comment. IUCN responded to my request to use the range maps saying I could not but that there might be a product sometime next year that would meet my needs. I replied making some of the points in my initial post and they did not respond. I'll call the person at IUCN but wanted first to learn whether the topic had already been discussed. As to your comment about the Darter, I agree. I'm just saying it is an unfortunate situation: (a) Wikipedia has lots (probably hundreds) of pages that violate copyright law, (b) the only way to avoid breaking the copyright law is to modify the maps but as far as I know no guidelines exist on how much modification is enough, (c) why would we want to modify the maps anyway?, and (d) IUCN is an NGO getting money to carry out charitable work; does it really make sense for it to spend a lot of that donor money and then not let anyone use the results? I just thought Wikipedia might be in a better position to raise these issues than I acting as an individual. - Jon Bart — Preceding unsigned comment added by Jonathanbart (talkcontribs) 22:51, 22 October 2019 (UTC)

  • The short answer is, we unfortunately won't be able to host any maps which are dependent on the IUCN data, even if they're self-created. They will not be willing to change their license to make it compatible with ours (it's not impossible, but it's very unlikely especially given their response to you.) I would concur Wikipedia might be in a better position, but that doesn't mean the answer will change (there's probably very practical reasons why they haven't released it publicly, especially given the number of potential copyright holders in the information.) SportingFlyer T·C 07:41, 23 October 2019 (UTC)

Vital articles, level 6 proposal

I am relatively new to Wikipedia as an editor, so please feel free to redirect me if this is the wrong place to start.

I am a regular consumer of the Vital Articles project and have been following the development of both the level 4 and level 5. I realize it is premature to start a level 6, as level 5 is only at 33,666 articles of the proposed 50,000, however, I would like to propose to the community that they consider starting level 6, mainly to help with some of what I observe in the talk page discussion. (I'm also aware I might be missing entirely a discussion forum where more in-depth collaboration is happening, so if what I'm proposing is already in the works, please let me know; and, if someone can point me to those places, I would be a happy fly on the wall there.)

At level 5, what I notice is that major topics are developing into vast categories. For example, at level 5, mathematics has 1100 (targeted) articles, literature 1000, and language 590. However, these areas easily have well over 1000 important topics. Consider, for example, the more than 7,000 languages known of around the world. As someone who enjoys consuming knowledge in the encyclopedic format Wikipedia offers, I like knowing after level 5, for example, what next order of topics would be important.

My proposal has a more practical motivation, however. Having a level 6 right now, rather than when level 5 is complete, would allow authors/editors a larger dumping ground to lay out many of the proposed articles that might make it into level 5 but are still being debated. Having a preliminary level 6 would allow Wikipedians to make some estimates on how many possible articles might be in a given category at level 6 (for example, the language category might have a target of 2,000 articles at level 6). Additionally, this might inspire some Wikipedians to develop many less-visited articles that are brought to light by this method of prioritizing further topics.

Using the same scaling factor as from level 4 to 5 (being 10,000 articles, to 50,000 articles) one could envision a level 6 focusing on the most important 250,000 articles on Wikipedia. This then could be tackled and refined once level 5 is finished. But having it laid in place would allow the authors/editors of level 5 to lay down many of the competing candidates for level 5 in the level 6 area, then work backwards by refining that through ongoing discussion. It would also allow contributors to suggest topics that might go in level 5 or level 6, giving them more option than simply being allowed, or rejected (and then forgotten about).

Because it is impractical to start dumping 250,000 articles in this possible level 6, I'd propose that if this idea were started, it would be limited to categories, i.e. the language, mathematics, and literature example I gave. One would not need to worry about whether the estimated total is too accurate. It is enough to say, for instance, that we could imagine if language has a target of 590 articles in level 5, then a level 6 target could be 2,000. It might be practical to make sub-categories for each of these level 6 topics, rather than just a level 6 (i.e. "Vital Articles level 6 (language)", "Vital Articles Level 6 (mathematics)"), so that each major category in level 5 could be developed separately as level 6, while level 5 is being put together. This is just a thought.

I appreciate any help / input you might give on this matter. Meanwhile, I will continue to read my way through the vital articles. It is a great endeavor and a good system to organize information, and my hope is over time this approach will allow Wikipedia to curate and refine articles through a method of rigor, in order of priority using the vital articles priority as a guide. — Preceding unsigned comment added by Johnrobinrt (talkcontribs) 05:43, 23 October 2019 (UTC)

Already at the level 5, many of the topics are not very vital, and I suspect that many topics yet to be written should be at this level. Projects probably need to explore possible topics that could be written even at the level 5. A deeper level certainly would not be vital, as it would be beyond most encyclopedias. Graeme Bartlett (talk) 07:22, 23 October 2019 (UTC)
Like Graeme, I find most of the vital-5s not at all vital, and so I'd be firmly against yet another layer Nosebagbear (talk) 09:12, 23 October 2019 (UTC)
I'd already support deleting level 5 with how broad it is. I do not want another level, as I believe that would be waaaaaay too broad. InvalidOS (talk) 15:17, 23 October 2019 (UTC)

Miscellaneous


Feedback wanted on Desktop Improvements project

07:18, 16 October 2019 (UTC)

Pokémon rom hack except it’s made by Wikipedia

We could have new Pokémon based on templates and an evil team of vandals who are out to harm the integrity of the site. I call it Pokémon: Wiki! Cause if 4chan gets one, why can’t we? Derpdart56 (talk) 23:42, 18 October 2019 (UTC)

@Derpdart56: Because this is an encyclopedia, and not a social site or a place for games. There is plenty of vandalism to fight, if you are really interested in that: WP:VANDALISM has tips on how to get started on that. RudolfRed (talk) 21:12, 19 October 2019 (UTC)
@Derpdart56: This isn't a place for original research. Wikipedia isn't a fan site. However, you may make your own wiki unrelated to Wikimedia if you please. From AnUnnamedUser (open talk page) 01:14, 20 October 2019 (UTC)

okay, this was a bad idea Derpdart56 (talk) 20:38, 21 October 2019 (UTC)

Nomination of Wikimedia community for award

I think we should have more eyes on a discussion at WT:WikiProject Climate change#Nomination of_Wikimedia community for award. This is about "nominating the Wikimedia community for the 2019 "Climate Change Public Outreach Award" from Climate Outreach." ♦ J. Johnson (JJ) (talk) 01:20, 22 October 2019 (UTC)

IP user likely sockpuppeting as multiple other IPs

46.211.141.13 and 46.211.152.72 have had no prior history of editing on Wikipedia, but both have come onto Template:Arianespace launches attempting to reinstate edits made by 217.30.192.8 which I had problems with, and reverted as part of the bold, revert, discuss cycle. It's extremely unlikely that two different real editors have come onto the scene out of the blue within such a short timespan on a relatively low-traffic page with the same exact, identical agenda. Thus, I'm almost certain that 217.30.192.8 is sock puppeting as 46.211.141.13 and 46.211.152.72. I'm inexperienced in dealing with sock puppets, so I've come to ask, what should my next actions be in this situation? – PhilipTerryGraham (talk · articles · reviews) 07:14, 22 October 2019 (UTC)

Please see WP:IPHOPPER. The basic fact is that everyone's IP address changes, almost all the time (which also explains a visibly apparent lack of previous edits on each single address). This is obviously the case for the 46.211.* addresses. Whether 217.30.192.8 is the same user or not is a matter of judgment - they are in the same country, and probably near each other, so I'd say they are probably related. This is not particularly sockpuppeting as such; you should just assume that it's obviously the same user. You seem to have both provided explanations in the edit summaries - the next step if the reverting persists, and you can't get a timely message to the user on their talk page, then you may want to start a discussion on the template's talk page. So in short, treat it as a minor content dispute with one user, and not a sockpuppet issue. -- zzuuzz (talk) 07:53, 22 October 2019 (UTC)
@Zzuuzz: Thanks for the information. I just hope this doesn't ugly in some way or another. – PhilipTerryGraham (talk · articles · reviews) 08:00, 22 October 2019 (UTC)
I've seen a fair number of disuptive IPs in my time, and I don't think this will be a major problem. People who provide reasonable edit summaries (even if you disagree with them) are generally open to reason and consensus. As with all disputes, if there's a problem, then get some discussion going. As a final resort if it does get 'ugly', if an IP becomes tendentious or uncommunicative, you can probably apply for semi-protection. -- zzuuzz (talk) 08:12, 22 October 2019 (UTC)

What do you think about capitalization of cocktail names?

Normally, we don't capitalize the names of drinks. E.g., "strawberry milkshake" or "lemonade" aren't capitalized. Nor are some cocktail names like the margarita, gin and tonic or vodka soda.

So why would the rules be different for, say, Long Island Iced Tea? Why would it be considered a proper noun rather than being Long Island iced tea? It's true that with some branded products, like Coke, we might say, "I grabbed a Coke," but we wouldn't say, "I grabbed a Cola" because it's not a proper noun when it's generic like that.

Anyway, the {{IBA Official Cocktails}} uses proper noun capitalization for most mixed drinks, but even there, there are exceptions, like the champagne cocktail or Irish coffee. I can understand, though, that for some cocktails like Sex on the Beach, a disambiguation purpose could be served by capitalization, so that people know what you're referring to when you say, "The Sex on the Beach I had yesterday was amazing." On the other hand, if you capitalize Irish Coffee, then people might think you're referring to Irish Coffee (band) or Irish Coffee (TV series) when you say, "I enjoy Irish Coffee."

Any thoughts on what the standard should be? Thanks, Зенитная Самоходная Установка (talk) 20:58, 22 October 2019 (UTC)

I'm not sure that we should try to establish a standard beyond following how each individual drink is named in reliable sources. The examples listed above demonstrate that there are disparate linguistic pressures on different cocktail names that lead people to establish conventions tailored to the specifics of each drink's name. Attempting to standardize this further doesn't have a clear benefit IMO. signed, Rosguill talk 21:05, 22 October 2019 (UTC)
I would recommend down capsing the lot unless some part of the name is proper i.e. Long Island iced tea and Irish coffee but rather sex on the beach (unless that's about sex on a beach, in which case sex on the beach (drink) seems preferable). We've firmly rejected using capitals for disambiguation purposes in the similar WP:BIRDCON case. --Izno (talk) 21:47, 22 October 2019 (UTC)
Yeah, we use a (cocktail) disambiguator for a lot of drinks, like azalea (cocktail), batanga (cocktail), blinker (cocktail), etc. Зенитная Самоходная Установка (talk) 21:56, 22 October 2019 (UTC)
Lowercase except where proper name status is supported by sources. As for "a disambiguation purpose could be served by capitalization", that is inconsistent with our style as spelled out at MOS:CAPS. As for evidence of what's a proper name, one really does have to look for "consistent" capitalization in sources. Many cocktail names make it to "majority" capitalization in sources just because there are so many sources (such as this mixology guide) that have a style of capping all cocktail names (including "Brandy and Soda"), and therefore juke the stats but provide no evidence of which ones are considered to be proper names. Dicklyon (talk) 22:57, 22 October 2019 (UTC)
I agree; the List of IBA official cocktails sources are the same way. Зенитная Самоходная Установка (talk) 04:26, 23 October 2019 (UTC)
See below. The sources linked there have the names of the cocktails in ALL CAPS. Not really useful to solving our problem, n'est ce pas? --Jayron32 15:25, 23 October 2019 (UTC)
Lowercase. There is absolutely no reason for cocktails to be seen as proper names or exceptions to our usual naming conventions. This seems to be some sort of conceit of cocktail fans, just as military fans and police fans (in particular) support the conceit that all military and police terms should be capitalised. -- Necrothesp (talk) 13:07, 23 October 2019 (UTC)
I think it just makes people feel more important to say, "I drank a Tequila Sunrise" so that they're at least on par with those who can say, "I drank a Budweiser" (which is capitalized because it's a brand name). Now, in the case of the Hand Grenade, it would actually make sense to capitalize it because it's someone's intellectual property. The more advanced cocktail aficionados must feel terrible that these elaborate concoctions of theirs would be lowercase while the most stigmatized, low-effort two-ingredient cocktail, the Jack and Coke, is capitalized. Зенитная Самоходная Установка (talk) 14:03, 23 October 2019 (UTC)
Normal English rules of capitalization apply. Thus, if the name contains elements that would otherwise be capitalized, we capitalize those. If the name contains elements that would otherwise be lowercase, we lowercase those. For example, in "Long Island iced tea", the correct capitalization is to capitalize "Long Island" (because that is a place with a proper name that gets capitalization under normal English rules) but not "iced tea" (because iced tea is not a proper name, and so gets lowercase under normal English rules). Other variations such as "Long Island Iced Tea" or "long island iced tea", or "LoNg IsLAnD ICd teA" should not be used. --Jayron32 14:13, 23 October 2019 (UTC)
Title case It's a proper noun. First, it's not iced tea, so it is not a style of tea. Second, let's follow {{IBA Official Cocktails}}. --evrik (talk) 14:27, 23 October 2019 (UTC)
That's not really useful here, since the IBA source, Here uses ALL CAPS. Are you seriously recommending we use LONG ISLAND ICED TEA because that's how the IBA does it? --Jayron32 14:52, 23 October 2019 (UTC)
How is it a proper noun? It's generic. It's not proprietary; anyone can make one and call it and sell it as a Long Island iced tea. It's used everywhere. It is not in any way a proper name. -- Necrothesp (talk) 14:59, 23 October 2019 (UTC)

Advice needed

I am not certain what to do. There have been several AFD nominations at List of Advanced Dungeons & Dragons 2nd edition monsters ending in no consensus, and I have serious concerns about whether the article in question isn't actually violating copyright law. I started a conversation at Talk:List of Advanced Dungeons & Dragons 2nd edition monsters#Is this list a copyright violation?. However, the AFDs and this conversation seem to be flooded with comments by editors who edit in this area and may be biased because they are fans. I am wanting to just get some neutral people over to this discussion to provide input or better yet experienced editors dealing with copyright concerns. I would feel a lot better knowing if I knew I was getting input from neutral people even if they disagree with me. How do I go about doing this?4meter4 (talk) 18:50, 23 October 2019 (UTC)

I think perhaps going through WP:CP is a better way to deal with copyright concerns than WP:AFD, copyright experts work in the former area. Jo-Jo Eumerus (talk, contributions) 18:57, 23 October 2019 (UTC)
Maybe... I just don't want to be accused of forum shopping. It would be so much better if we just had some more neutral participants at that discussion.4meter4 (talk) 19:42, 23 October 2019 (UTC)