Jump to content

Wikipedia:Village pump (proposals): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Undid revision 836852046 by Special:Contributions/2605:6001:E29B:1A00:1437:BBAA:7C03:6CCB If you have an opposal, please post it instead of just adding a count.
Line 729: Line 729:
* '''Support''' [[WP:TLDR]], but I don't really think there is any purpose for portals above projects, cats, lists and templates.-[[User:TonyTheTiger|TonyTheTiger]] <small>([[User talk:TonyTheTiger|T]] / [[Special:Contributions/TonyTheTiger|C]] / [[WP:FOUR]] / [[WP:CHICAGO]] / [[WP:WAWARD]])</small> 02:43, 17 April 2018 (UTC)
* '''Support''' [[WP:TLDR]], but I don't really think there is any purpose for portals above projects, cats, lists and templates.-[[User:TonyTheTiger|TonyTheTiger]] <small>([[User talk:TonyTheTiger|T]] / [[Special:Contributions/TonyTheTiger|C]] / [[WP:FOUR]] / [[WP:CHICAGO]] / [[WP:WAWARD]])</small> 02:43, 17 April 2018 (UTC)
* '''Support''' - I've worked in a couple of Portals in the past, but I really '''never''' visis them. They're quite useless, containing incorrect and outdated info. Standard links, navigation templates, and categories offer plenty of possibilities all the info one wants to find. [[User:Joshua Jonathan|<font size="2"><span style="font-family:Forte;color:black">Joshua Jonathan</span></font>]] -[[User talk:Joshua Jonathan|<font size="3"><span style="font-family:Monotype Corsiva;color:black">Let's talk!</span></font>]] 04:23, 17 April 2018 (UTC)
* '''Support''' - I've worked in a couple of Portals in the past, but I really '''never''' visis them. They're quite useless, containing incorrect and outdated info. Standard links, navigation templates, and categories offer plenty of possibilities all the info one wants to find. [[User:Joshua Jonathan|<font size="2"><span style="font-family:Forte;color:black">Joshua Jonathan</span></font>]] -[[User talk:Joshua Jonathan|<font size="3"><span style="font-family:Monotype Corsiva;color:black">Let's talk!</span></font>]] 04:23, 17 April 2018 (UTC)
*Strongly Oppose Wikipedia is a necessary reference and is often the best source of information. I visit the 'Current Events' portal every day because it provides the most neutral roundup of daily events with all sources cited. The diversity of events reported are fantastic and overall the portal is very well done and extremely useful. Please do not remove this section!!!


=== Section break - continue survey here ===
=== Section break - continue survey here ===

Revision as of 06:31, 17 April 2018

 Policy Technical Proposals Idea lab WMF Miscellaneous 

New ideas and proposals are discussed here. Before submitting:


Net neutrality

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.


The Senate is headed for a vote on a Congressional Review Act (CRA) resolution to overturn the FCC’s repeal of net neutrality, but we still need at least one more Republican vote to win. According to FightForTheFuture, pressure from local businesses in lawmakers’ own districts is perhaps the single most effective strategy for convincing hard-to-get lawmakers to buck partisan politics and side with the overwhelming majority of voters to speak out for the open Internet.

Could we perhaps link to https://www.businessesfornetneutrality.com/ in a banner at the top of all pages? --Gryllida (talk) 00:12, 25 March 2018 (UTC)[reply]

  • Oppose power~enwiki (π, ν) 00:15, 25 March 2018 (UTC)[reply]
  • No political action please. -- Ajraddatz (talk) 00:39, 25 March 2018 (UTC)[reply]
  • I strongly support net neutrality and I even tend to rant about it from time to time, but I think it might be good for Wikipedia to be politically neutral. If Wikipedia takes a political stand on just about anything, a certain percentage of users, editors, admins, and etc. will be alienated. Bob Webster (talk) 02:08, 25 March 2018 (UTC)[reply]
  • I don't think we can. Back when the FCC was going to vote, there was a suggestion to have WP have some similar message to get the word out. I know I supported it, but there's a very strong vocal dismissal of anything that appears to be politically motivated or similar call to action; I doubt that has dissipated since last fall. --Masem (t) 02:20, 25 March 2018 (UTC)[reply]
  • There is no "we" here with a monolithic political viewpoint. So no. MB 05:04, 25 March 2018 (UTC)[reply]
  • Oppose in strongest sense. -Wikipedia's neutrality is what we should strive for, it is wha makes Wikipedia great and unassailable.–Ammarpad (talk) 06:21, 25 March 2018 (UTC)[reply]
  • Comment. It is my view that the Wikimedia Foundation, in consultation with it's communities, is obligated to take any and all action necessarily to protect it's communities' ability to progress towards their goals. This action may at times suffer from a paradox of neutrality (similar to the paradox of tolerance), and this conflict can only be resolved by carefully balancing the threat's effect on our goals and the action's effect on our goals. In the case of the 2012 Wikipedia blackout, a decision was made that the threat presented an overwhelming danger to our continued operation and severe action was taken. My view is there is no blanket prohibition on potentially political action, but that such action needs to be supported by an extensive risk assessment. If you believe that this particular issue deserves such treatment, you are welcome to make your case, however I suspect we have already exhausted our ability to express our view on net neutrality at this time. TheDragonFire (talk) 08:32, 25 March 2018 (UTC)[reply]
  • Different support This organization knows nothing about free content, open licensing, etc. They need Wiki support, but advertising and named partnerships will neither help them or wiki because their strategic plan actually is ignorant of the basics of a free and open Internet. Instead of asking for the wiki side to do all the work, contact them and ask them for the following:
    • They produce educational inforgraphics, explanatory texts about net neutrality, and a suite of other educational resources. Tell them to apply open licenses to this content and post it to Commons.
    • They have in-house experts helping them design lobbying campaigns and recruit activists. Tell them that Wikipedia is the most consulted source of information for every topic in their field of expertise. Show them the traffic metrics and bring them into a conversation in which you have them compare Wikipedia's traffic with the audience they are reaching in other social media. They should understand that ~100% of activists, journalists, and anyone researching the basics of social issues will review the wiki articles as they orient themselves to the topic and bring themselves up to date. In their network they ought to be able to send someone to edit wiki, and maybe you can organize training and support for them on the wiki side.
    • They organize lots of in-person protests and events. Tell them to train their community organizers to upload good photosets to commons with proper cataloging and documentation.
A partnership with the Wikimedia community cannot be the wiki side giving everything without the other side even understanding the value and significance of it. I know this organization. I appreciate the conversation they are trying to have. I want to draw them and experts on the opposing side to present their best in Wiki's media collection. Blue Rasberry (talk) 11:58, 25 March 2018 (UTC)[reply]
  • I would support this iff it can be shown that this is an existential threat to Wikipedia. I have yet to see that argument convincingly made. Tazerdadog (talk) 21:31, 25 March 2018 (UTC)[reply]
  • Oppose we as a movement don't want net neutrality, see Wikipedia Zero. While that program's being winded down, I'm sure the WMF will come up at some point within the next year or so with some idea where it would serve our mission if net neutrality wasn't a thing. When you are the 5th largest website on the planet, net neutrality has the possibility to hurt rather than help. TonyBallioni (talk) 21:51, 25 March 2018 (UTC)[reply]
  • Oppose We don't need no stinkin' Net Neutrality. GenQuest "Talk to Me" 22:16, 25 March 2018 (UTC)[reply]
  • Oppose any activism on the part of Wikipedia, we need to strive to remain politically neutral, regardless of how much I might personally feel about this particular issue. — Insertcleverphrasehere (or here) 22:18, 25 March 2018 (UTC)[reply]
  • Oppose: The Internet is not broken, and does not need to be "fixed" by giving the US government more control over the internet. The recently repealed Obama-era net neutrality rules adopted a vague but sweeping "general conduct" standard that gave the FCC the power to crack down on perceived bad behavior by internet providers without providing clear guidance about what would trigger enforcement. --Guy Macon (talk) 22:29, 25 March 2018 (UTC)[reply]
  • Comment - this is all gibberish to me. Systemic bias or what? The US-based contributors might understand what is going on but I suspect most of the rest of the world, unless IT-savvy, do not. - Sitush (talk) 23:31, 25 March 2018 (UTC)[reply]
@Sitush: Your country India organized the biggest protest for net neutrality in the world at Free_Basics#Net_neutrality_criticism_in_India. It brought popular support and politicians speaking out. May be not everyone gets all the details but lots of people have opinions about colonization and can see neocolonialism regardless of IT skills. Blue Rasberry (talk) 23:52, 25 March 2018 (UTC)[reply]
Do what? India? I'm in the UK. - Sitush (talk) 23:53, 25 March 2018 (UTC)[reply]
Another sort of bias; assuming a country from a username. I get a variation of that a lot. Although I was raised by a family from London speaking the Queen's English (I learned the Americanisms in school), people keep assuming from my name that I am French. That being said, why should the United States Federal Communication Commission In Washington be allowed to have control over the Internet? Why not some government agency in Whitehall? Or Brussels? Or African Union#Headquarters#Addis Ababa? --Guy Macon (talk) 02:14, 26 March 2018 (UTC)[reply]
Oh, indeed, I have no idea why the US should control anything and generally would much rather that country stopped trying to represent the world/throw its weight about etc ... but I also have no real idea what this proposal is referencing. I know, vaguely, of the net neutrality paradigm but that is it. And, contrary to popular opinion among people who take me to ANI, I am not an idiot :) - Sitush (talk) 02:18, 26 March 2018 (UTC)[reply]
@Sitush: Sorry to presume if there is any reason to object. We have developed India-related articles for years and I imagined that your interest in the place made India your own. Blue Rasberry (talk) 02:29, 26 March 2018 (UTC)[reply]
  • Oppose. Iazyges Consermonor Opus meum 15:50, 26 March 2018 (UTC)[reply]
  • Oppose. Stop trying to involve wikipedia in politics. Natureium (talk) 16:18, 26 March 2018 (UTC)[reply]
  • Oppose - WMF as a whole should not get involved with any of this ..... I personally feel NN should never have been thought of but it has and here we are (coming from a UK bloke) ... Point is we IMHO should not involve ourselves with this. –Davey2010Talk 16:37, 27 March 2018 (UTC)[reply]
  • Oppose - I don't volunteer to be part of a political movement, I volunteer to build an encyclopedia. Anything that is not directly related to that, I will always oppose. Dennis Brown - 15:50, 28 March 2018 (UTC)[reply]
  • Oppose - Please don't bring politics into this encyclopedia. Do it elsewhere. Not here. Javert2113 (talk) 22:53, 28 March 2018 (UTC)[reply]
  • Support- We already have enough people here trying out extremely long edit summaries at the village pump, so we can't hand this out to the vandels and trolls of Wikipedia.--Adam Song (talk) 19:29, 30 March 2018 (UTC)[reply]
    You've probably commented under a wrong topic. MT TrainTalk 10:19, 31 March 2018 (UTC)[reply]
    Oops... Adam Song (talk) 16:53, 3 April 2018 (UTC)[reply]
  • Oppose- We don't need to bring politics in Wikipedia. MT TrainTalk 10:19, 31 March 2018 (UTC)[reply]
  • Comment People are so afraid of politicizing Wikipedia in a time where they are so politically divided (esp. in america), that they are not willing to engage in defending the ideals that allowed Wikipedia to be built. I'd look elsewhere for support. Oh and cancel your AT&T and Verizon. They are the sole reason we even need to think about this. —TheDJ (talkcontribs) 12:01, 31 March 2018 (UTC)[reply]
    • Rebuttal: The above assumes without evidence that having the US government control the Internet in some vague way "defends the ideals that allowed Wikipedia to be built" Sorry, but Wikipedia was built on internet freedom, not government regulations. Also, the Internet is not broken and does not need fixing. --Guy Macon (talk) 16:10, 31 March 2018 (UTC)[reply]
      • Our Internet freedom existed only until the time that the Internet started to matter to those in power. I don't want the US to control the Internet, I want the US to protect the Internet from the US. The US has its priorities as: itself, capitalism, freedom. This is reshaping the Internet as we knew it and it is bleeding into the rest of the world at an alarming rate. We need to wind that back a bit, to when the first two didn't dominate how the Internet worked. To say that the US has not significantly changed the dynamics of the Internet over the past 15 years is simply turning a blind eye to the USAs shifted priorities. The CLOUD Act is only the latest evidence. I have little hope however of stopping this. It will be fine for a while as we slowly turn 1984 and then it will be chaos. —TheDJ (talkcontribs) 12:25, 5 April 2018 (UTC)[reply]
  • While this will barely affects Wikipedia given the size of our articles, it will have a huge effect on streaming media/videos and so could affect commons - and if wikipedia gets round to incorporating more free media in articles, ENWP as well. The reason for net neutrality being removed is so the few monopolising companies in the US can charge content providers to prioritise their traffic. Since I doubt the WMF (even with its warchest) will be able or willing to pay Comcast etc to keep its traffic in the fast lane, this will result in a slowdown and delivery of WMF-hosted content to end-users. This isnt some sort of paranoia, I dont think anyone realistically expects the WMF will be a company able to pay the amounts that are needed. The *entire* purpose of rolling back net neutrality is to extract money from heavy-traffic companies because they are limited in what they can charge their customers. So all those opposing and live in the US: You are shooting yourself in the foot long term. Those opposing outside the US: Its in our interest to not have the rolling back of net neutrality be seen as a corporate success in the US, lest our own governments and corporations decide they want to advocate for it here. Only in death does duty end (talk) 16:37, 31 March 2018 (UTC)[reply]
    • I strongly disagree. At the very least, could you at least acknowledge the arguments made by those who don't want the US government to micromanage the Internet instead of simply parroting pro-net-neutrality arguments? See [1][2][3][4] --Guy Macon (talk) 19:36, 31 March 2018 (UTC)[reply]
      • Not really no :) There really is no argument that net neutrality being repealed is to allow different internet traffic to be given unequal weight. That is the entire point of it. So if you genuinely believe the WMF's traffic is going to end up in the fast lane, sure there is no issue. But that aint gonna happen. The reason why governments have to 'micromanage' is because left to themselves private corporations would be completely unethical in their pursuit of cash. As I am not an American and live in a country that does actually believe in public services being available without restriction - which the internet clearly falls under - I am more than happy for government oversight to ensure that it is done fairly. I would prefer if the US government had *less* actual influence over it, given its currently being run by someone ruling by proclamation influenced by what he read on twitter, but since thats unlikely anytime soon I will settle for all the traffic being treated equally. Only in death does duty end (talk) 19:46, 31 March 2018 (UTC)[reply]
        • So by your own admission you won't even consider the opposing arguments. I won't bother trying to convince you then. Forgive me if I am misremembering, but you are in the UK, right? And above you claim that "I live in a country that does actually believe in public services being available without restriction". Care to explain this restriction of a public service?[5] It sure looks to me like some households are in the hosepipe slow lane stadiums used for national and international sports are in the hosepipe fast lane. I look forward to your spirited defense of water neutrality in the UK. (And if I did misremember your home country, I have examples for India, Australia, etc.) Oh, by the way, your claim that "While this will barely affects Wikipedia" is factually incorrect. See [6] and the WMF's recent caving in to political pressure from people like you who won't even consider the opposing arguments and cancelling Wikipedia Zero. --Guy Macon (talk) 20:28, 31 March 2018 (UTC)[reply]
          • Having a green lawn is a not a right much as my fellow brits would disagree I am sure. Granted if they told me I could only shower every other day or only boil the kettle twice we might have a problem. Oh and I support Wikipedia Zero in theory, it was just in practice it didnt work. I also worked for Vodafone about ten years ago who routinely zero-rated their own content like many other mobile carriers (it didnt cost anything to use their own music service for example vs other streaming services) and for mobile carriers there are technical reasons it was (to a lesser extent now) an issue. Wikipedia Zero wasnt scuppered solely because of net neutrality issues, it was scuppered because a)it didnt make the WMF money, b)it didnt make the mobile carriers money, c)it was being used to share huge amounts of pirated media costing the carriers money. But there is a marked difference between providing free internet access to information to people who do not have it (which is what Wikipedia Zero attempted to do) and asking people to pay more for the same service they already do have. Although in the case of net neutrality 'asking' is a bit of a nice way to describe what companies will be doing. 'Pay us or else' would be more accurate. Only in death does duty end (talk) 23:27, 31 March 2018 (UTC)[reply]
    • Oppose-The less politics the betterAdam Song (talk) 16:56, 3 April 2018 (UTC)[reply]
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.

Automated article assessment

This is to propose that a bot be developed (I may be able to figure out how to do it, with a bit of help) that automatically assesses new articles, and periodically re-assesses these articles, until a real editor steps in and overrides the assessment. The approach would be:

Projects The bot adds a project template to the article talk page for each project that AlexNewArtBot identifies with a score over 100, or for the project AlexNewArtBot scores highest. The template includes a new |autoassess=auto parameter. This:
  • adds text like "This assessment was done mechanically by AutoAssessBot" to the template (linking to an explanation) and
  • puts the talk page into Category:Automatically assessed articles/auto.
Quality The bot calls on mw:ORES#Assessment scale support to assess quality for each project. This is machine-learning software that does a good job of making assessments similar to those made by humans based on analysis of various properties of the article – although it may make mistakes.
Importance The bot assesses importance based on number of inbound links from articles: Up to 10 = Low; 11–99 = Medium; 100 or more = High.

This method will often give identical or similar results to those of a typical drive-by assessor. The benefits are:

  • The bot will reduce the workload, since assessors now only have to tweak assessments they think are wrong, then change to|autoassess=noto show that the bot has been overridden.
  • An editor may show they have reviewed and agreed with an automatic assessment by changing to |autoassess=ok. This will take the article out of Category:Automatically assessed articles/auto (which need review) and put it into Category:Automatically assessed articles/ok (reviewed).
  • Newbies will not be upset when they see a bot has assessed quality based on an algorithm, where they might be upset if a human had decided their work was junk
  • The bot will run periodically until a human overrides it, so will update its assessments. Human assessors typically do not review and adjust their initial assessment
  • The bot's algorithm can be steadily refined, for example to consider results of Flesch–Kincaid readability tests, with the goal of steadily reducing the number of human interventions needed.

Again, as soon as a human editor changes to |autoassess=no the bot stops re-assessing. Real editors remain fully in control. Aymatth2 (talk) 18:58, 4 April 2018 (UTC)[reply]

Comments on automated article assessment?

Quality assessments: How do the WMF devs plan to implement ORES article quality assessments? If they are working toward integrating it with the Mediawiki software itself, then we should probably not develop a hackish bot that does the same thing but worse. Native integration is what they already went for with ORES New filters for edit review. You asked them but didn't get a reply. You should definitely hear from them before us.

Importance assessments: My hunch is that it will be far easier to come up with working solutions for quality than importance (case in point: ORES does quality but not importance). Your proposal doesn't seek to answer the following: unlike quality assessments, importance assessments are supposed to be different for different projects. For instance, "Nightswimming" (Awake), on the Main Page a few days ago, is Top importance for WP:AWAKE, and Low importance for WP:TV and WP:USA; an episode is obviously more important to a project that focuses solely on that series than for one that has as its scope the total history of a broadcasting medium or an entire country. Your bot would crank up the importance of this article for WP:TV and WP:USA, into High and downgrade it for the only directly relevant project. There are so many problems with gauging importance from incoming links that entertaining them is not worth the effort. – Finnusertop (talkcontribs) 13:51, 5 April 2018 (UTC)[reply]

To the first point, ORES seems designed as a generic machine learning tool that can be trained for this and various other tasks. The write-up implies that use on a given language wiki is up to that wiki. Obviously feedback from the ORES people would be welcome. If they are planning to build it into the Mediawiki software so it can do what is proposed, that would be great. The idea here is to get agreement from the people here that it would be a good idea, and then the best implementation approach can be worked out. Aymatth2 (talk) 21:37, 5 April 2018 (UTC)[reply]
There are about 20 inbound links to Nightswimming (Awake), which the bot would rate as mid importance. That typically means something like "Subject is only notable within its particular field or subject and has achieved notability in a particular place or area", the default definition used by WP:Wikiproject Television and WP:Wikiproject United States. The article meets that criterion. AlexNewArtBot does not support Wikipedia:WikiProject Awake, so it would take a human to assess importance for that project. A guess based on number of inbound links is just a guess, as is the ORES assessment, but if they get it right much of the time, it is worth recording the guess. Then a human can review and correct if needed. Aymatth2 (talk) 15:35, 5 April 2018 (UTC)[reply]
The purpose of quality assessments is to help project members prioritise work. This could involve upgrading the quality of important but low-quality articles, or pushing up high-quality articles to GA or FA status. If ORES says an article seems poor quality, and the number of inbound links suggests it is important, that is probably useful even if a strict reading of the criteria would say quality is a bit higher and importance a bit lower. See Wikipedia:WikiProject assessment#Statistics: there is a backlog of over 570,000 articles to be assessed, about 10% of the total, up from 552,983 in May 2017 per Wikipedia:Assessing articles#Statistical analysis. A rough assessment that can be refined by a human any time is better than no assessment at all. Aymatth2 (talk) 15:35, 5 April 2018 (UTC)[reply]
This idea sounds great. Have you seen User:Nettrom's work on m:Research:Screening WikiProject Medicine articles for quality? I found that it sometimes slightly over-rated articles that had long lists of refs, or long bulleted lists, but its stub ratings were spot-on, and if it had a gap of two classes or more, then the current assessment was always wrong.
There's more that I'd like to see a bot doing with assessments. For example, at Category:Unassessed medicine articles, every single article about a person and organization needs not just the quality rating, but also |importance=Low and |society=yes. Even if the bot could tag only stubs about people this way, it could halve the amount of work that needs to be done manually. WhatamIdoing (talk) 04:42, 8 April 2018 (UTC)[reply]
I did not know about User:Nettrom's work. It does not surprise me that many assessments were wrong. Partly that is from drive-by assessors who think: "1-2 paras = Stub/low, else = Start/low", partly from failure to reassess after improvements are made. Once the bot gets settled down there may be a lot of refinements both to the scoring algorithm and to adding more data. Project-specific rules like "individuals and hospitals default to Low for WikiProject Medicine" could be added. I would like to start simple though. Aymatth2 (talk) 14:22, 8 April 2018 (UTC)[reply]
This is a really interesting proposal, Aymatth2! Thanks to WhatamIdoing for pinging me in this discussion, otherwise I would probably not have noticed it. The proposal is right up my alley and describes a setup that I'm fond of, having a bot propose some low-cost changes that a human can review. WhatamIdoing already pointed to the pilot study we did with WPMED on reassessing stubs, where we learned a few important lessons about how to set things up so it finds a good selection of candidate articles.
I thought I'd also mention a couple of related things. First is SuggestBot, which I run. When the bot posts suggestions it also adds info on page views and article quality (both predicted and currently assessed) so that editors can prioritize their work in the way that best suits them, and reassess the article if it's needed. One of the comments that sometimes comes up is "Why did it recommend this to me, it's not a stub?", which is an example of the challenge of keeping assessments up to date.
Secondly, I did a project with Aaron Halfaker a year ago, where we worked on building a model for predicting article importance. There's more information available on the project's research page on meta. During that work, we ran into the challenge that Finnusertop mentions: importance is WikiProject-specific. We therefore ended up training a model for each WikiProject so that it learns their preferences. We again collaborated with WPMED during that project and also incorporated a set of rules that cover their specific preferences on importance ratings for certain types of articles. Using Wikidata to identify the type of entity an article is about, we could then automatically rate all articles about people to Low-importance, for example. The results of that project were promising and suggested that article importance predictions could be useful when they're given as candidates to a human reviewer.
Again, really interesting proposal, it's precisely the type of thing that the wp10 model in ORES was built to help out with. Hope some of this info is helpful, let me know if there are questions about any of this! Cheers, Nettrom (talk) 15:53, 9 April 2018 (UTC)[reply]
@Nettrom: I had no idea how much had been done already. It seems that maybe it would not be too hard to clone and tweak SuggestBot to become a first version of ArtAssBot AutoAssessBot. (?) Aymatth2 (talk) 17:49, 9 April 2018 (UTC)[reply]
How is ORES trained? I suspect a lot of assessors rate quality based on length rather than value to readers, and importance on gut feel rather than project criteria. If we train ORES using these dud assessments, it will learn wrong. Ditto with stale assessments. I started Marcel Lucet the other day with a fairly basic first version, which was assessed as Stub. I expanded it, but it is still Stub and likely to stay that way. We don't want to teach ORES that is what a stub is like. Aymatth2 (talk) 17:49, 9 April 2018 (UTC)[reply]
Length matters, and is a fairly good predictor overall. But I think Nettrom's work is looking at multiple criteria, such as the number of refs and maybe section headings. WhatamIdoing (talk) 23:37, 9 April 2018 (UTC)[reply]
A Start-class article "Provides some meaningful content, but most readers will need more", while a C-class article is "Useful to a casual reader". Start may also be weaker than C on citations, style, etc.. For simple topics the casual reader will often be satisfied with a short, readable and accurate article. I agree that length and quality often go together, but would prefer that ORES did not give length excessive weight. Aymatth2 (talk) 02:26, 10 April 2018 (UTC)[reply]
We can always improve the training-set for ORES' article quality model. If you are interested in doing the work to check the set of assessments used to train ORES, we can improve ORES' prediction quality. We have a system called m:Wiki labels that makes manually assessing random samples for training ORES as easy as possible. I'm thinking we can get decent fitness with 150 observations for each quality class (150 * 6 = 900). We can start by sampling article versions from the labels (WikiProject assessments) we already have in Nettrom's original dataset. It would be a lot of work, but it would be a great way to validate the model.
Alternatively, you could just test out what we have already. It seems to work very well in practice (based on years of feedback). We can always come back to re-train it when/if you identify consistent problems. --EpochFail (talkcontribs) 14:55, 10 April 2018 (UTC)[reply]
Fair enough. If the assessments are usually good, that is what is needed. There will always be cases where it gets it wrong, but those can be fixed by a reviewer. Maybe after the AutoAssessBot has been running for a while it would be useful to look for patterns in articles where the ORES assessment has been manually overridden. Aymatth2 (talk) 16:12, 10 April 2018 (UTC)[reply]
The auto-classification of importance research results are a bit discouraging. I felt that if ArtAssBot AutoAssessBot only assigned an article to a project when AlexNewArtBot gave it a high score for the project, number of inbound links would be a reasonable proxy for importance. This would avoid the problem of giving Winston Churchill Top importance on WikiProject Architecture (he built garden walls as a hobby). Maybe that aspect of the bot has to wait for development of a better importance prediction model. Aymatth2 (talk) 17:49, 9 April 2018 (UTC)[reply]
Assuming ArtAssBot AutoAssessBot was built and settled in, I would like to let it rip on the 570,000 unassessed articles. After that, it could run through all articles adding |autoassess=ok where it came up with the same result as the existing quality/importance assessment for a project. But I have no idea how to deal with the remaining millions of articles with dud or stale assessments. Aymatth2 (talk) 17:49, 9 April 2018 (UTC)[reply]
You might want to consider a less potentially offensive name for your bot. ;-) WhatamIdoing (talk) 23:37, 9 April 2018 (UTC)[reply]
Oops. AutoAssessBot, it should be. (As an ex-Brit I tend to think of "ass" just as a useful beast of burden.) Aymatth2 (talk) 01:45, 10 April 2018 (UTC)[reply]
I'm already doing something similar to this at AFC. It would be fairly trivial to set something up to use the wp10 model to auto-assess talkpages. SQLQuery me! 19:49, 10 April 2018 (UTC)[reply]
I ran wp10 over CAT:FA, results were interesting. SQLQuery me! 22:17, 10 April 2018 (UTC)[reply]
That is very encouraging. The results seem excellent. Aymatth2 (talk) 13:53, 11 April 2018 (UTC)[reply]

AutoAssessBot recap

There seems to be general support for this proposal, since it is very much in line with other work on auto-assessment using ORES. To recap how the bot would work after adjusting for feedback above:

  • AutoAssessBot checks articles in two different modes:
    • Soon after an article has been created, and soon after significant changes have been made. "Soon after" allows for a flurry of edits where the final result is checked
    • Scan through all articles (possibly first all that have never been assessed, then all others)
  • For each article it determines relevant projects using the AlexNewArtBot algorithm. Some experiment may be needed to find the best threshold for deciding an article is relevant to a project
  • If the article does not have a talk page it creates one, with templates for the selected projects
  • If the article does have a talk page, it adds templates for selected projects that are not yet on the talk page, and checks existing project templates to see if they should be updated
  • A new project template parameter |autoassess= is used to control bot assessment
    • When the bot adds a project template, it sets |autoassess=auto, meaning the assessment has not yet been checked.
    • A reviewer may approve the project assessment by changing the parameter to |autoassess=ok.
    • A reviewer may change the project assessment and change the parameter to |autoassess=no, meaning the bot has been overridden.
    • A reviewer may change the parameter to |autoassess=skip, meaning despite the high AlexNewArtBot score this article is irrelevant to this project
    • The talk page is placed in a category for each project / autoassess value. Thus |autoassess=ok for WikiProject Biography would put it in Category:Autoassess ok biography articles.
  • When the bot checks an existing project template, it skips it if |autoassess=no or |autoassess=skip, otherwise it refreshes the assessment if changed
  • The bot creates or refreshes the quality rating on a project template using the result supplied by ORES
  • At this point, the bot leaves the importance rating blank (or unchanged). More experiment is needed to find an algorithm that would give good enough results
  • |autoassess=auto or |autoassess=ok add a note on the template saying, e.g., "This assessment was done mechanically by AutoAssessBot"

This is a tentative outline to be refined in the next step. Aymatth2 (talk) 13:53, 11 April 2018 (UTC)[reply]

AutoAssessBot next steps

@Finnusertop:, @WhatamIdoing:, @Nettrom:, @EpochFail:, @SQL:

I do not feel well-qualified to implement the bot, having never done one in the Wikipedia environment before. I assume there would be some sort of project set-up and standard steps to define specs, activities, acceptance criteria, testing, implementation. Any input on the next steps? Any volunteers? Aymatth2 (talk) 13:54, 11 April 2018 (UTC)[reply]

Aymatth2, I recommend you put all of the details of a WP:BAG proposal together in a sandbox page. Please include a meaty description of how it will behave and what you expect the outputs to look like. If we don't find a taker by the Wikimedia Hackathon (May 18th), I can pitch it to technical contributors there. It would be great if you would be interested in doing some work as a bot-maintainer. Do you have any background in python/pywikibot? Either way, by putting the BAG proposal together, you'll be saving someone some time spec'ing it out and helping them understand what type of work they are signing on for when picking up this project. --EpochFail (talkcontribs) 14:12, 11 April 2018 (UTC)[reply]
Thanks - I have started Wikipedia:Bot Approvals Group/nominations/AutoAssessBot. If anyone wants to add / improve it, feel free. Aymatth2 (talk) 17:42, 11 April 2018 (UTC)[reply]
Moved to Wikipedia:Bot requests/AutoAssessBot since it is not a WP:BAG nomination. — JJMC89(T·C) 03:31, 12 April 2018 (UTC)[reply]
If it helps - here's the code I use to pull ores (and the query to grab the appropriate pages): User:SQL/FA-Ores/getOres. IIRC, ORES is limited to ~2 requests / second, but each request takes on average ~1.1s to complete. SQLQuery me! 15:32, 11 April 2018 (UTC)[reply]
I did not even know SQL had a LIKE operator. Shows how much use I would be! Aymatth2 (talk) 17:42, 11 April 2018 (UTC)[reply]

RFC to dissolve Wikiproject Stub Sorting

Wikipedia:WikiProject Stub sorting (edit | talk | history | links | watch | logs)
Wikipedia:WikiProject Stub sorting/Proposals (edit | talk | history | links | watch | logs)
Wikipedia:WikiProject Stub sorting/Criteria (edit | talk | history | links | watch | logs)
Wikipedia:WikiProject Stub sorting/Naming conventions (edit | talk | history | links | watch | logs)
Wikipedia:WikiProject Stub sorting/Discoveries (edit | talk | history | links | watch | logs) - used to point out BOLD editors who choose to apply IAR to the WSS process
Wikipedia:WikiProject Stub sorting/Stub types (edit | talk | history | links | watch | logs) - move to Wikipedia:Template messages/Stubs
Template:Stubsort (edit | talk | history | links | watch | logs) - used to bug people who use the generic Template:Stub
Template:Stub sort (edit | talk | history | links | watch | logs) - same as stubsort
Template:WPSS-cat (edit | talk | history | links | watch | logs)
Template:WPSS-new (edit | talk | history | links | watch | logs)
redundant over-specific templates - {{underpopulated stub category}}, {{very large stub category}}, {{deprecated stub}}

Do we really need all this bureaucracy for stub templates? I don't think so. You want to create a new stub template? You have to go through WSS first. What's that, you've decided to just be bold and create the template? Too bad; it's going to TFD, where the 5 active TFDers will ignore it, causing it to be automaticallly deleted. I propose that WSS be shut down and the stub template process be made much less process-y, per the Esperanza precedent. (This was originally on MFD, but I was told to go here, despite MFD being where the dissolution of Esperanza was discussed.) Lojbanist remove cattle from stage 01:15, 6 April 2018 (UTC)[reply]

WP:WSS is for coordination. Amongst other things, it is used to ensure that we don't get two stub templates (or two stub categories) created to do the same job; it ensures that template and category names are harmonised and consistent; it ensures that the category tree has a logical structure. The WP:WSS/P process is there to discourage the proliferation of stub templates (or stub cats) that have little potential for use. --Redrose64 🌹 (talk) 10:04, 6 April 2018 (UTC)[reply]
  • I agree with Redrose64. WPSS serves a valid purpose and less "process-y" will likely result is more duplicates and non-maintained categories. It's like proposing to dissolve WP:WPMOS because some people don't like following the MOS and they feel like it's too bureaucratic to have so many rules on how articles look like. The nominator also fails to mention that WikiProjects to organize certain aspects of the project are common (see Wikipedia:WikiProject Council/Directory/Wikipedia#Maintenance). Regards SoWhy 11:07, 6 April 2018 (UTC)[reply]
  • I do agree that if the system continues to exist, there needs to be coordination or it'll become a mess. But TBH I've never understood why there's a system of stub sorting - it all seems very redundant to wikiproject ratings and categories there (though it does provide more specificity, I dunno how much it is actually helpful)
Giving some actual and specific examples of the "bad" that they do would help (e.g a link to specific TfDs etc) Galobtter (pingó mió) 11:30, 6 April 2018 (UTC)[reply]
They're much easier to navigate than WikiProject banners. It's how I first got involved with my early modern conclave project. TonyBallioni (talk) 12:01, 6 April 2018 (UTC)[reply]
  • ICYMI, details of the "Esperanza" project mentioned by nom can be found here. Pegship (talk) 13:52, 6 April 2018 (UTC)[reply]
  • To add, here's the MfD (which I closed) where this was initially raised. ~ Amory (utc) 18:43, 6 April 2018 (UTC)[reply]
  • Stub templates and categories do not affect the content of Wikipedia, but rather its organization, and both the project and its output are easily ignored by users and editors, who are welcome to go on their merry ways. The pages listed here for comment could certainly use some review and possibly some cleanup; some of them are long-abandoned or have already been redirected to more appropriate pages. (Template:Stubsort (edit | talk | history | links | watch | logs) and Template:Stub sort (edit | talk | history | links | watch | logs) have not been implemented since 2011 and aren't used on any article pages; Wikipedia:Template messages/Stubs already redirects to Wikipedia:WikiProject Stub sorting/Stub types (edit | talk | history | links | watch | logs); Wikipedia:WikiProject Stub sorting/Criteria (edit | talk | history | links | watch | logs) consists of an explanation as to why the page was discontinued and where to find the current discussions.) tl;dr: WPSS serves a purpose used and valued by many editors; if deleted or "shut down", I would like to know the form and procedure that would be implemented to serve its function. Pegship (talk) 23:31, 6 April 2018 (UTC)[reply]
  • I have not seen an issue with this WikiProject's modus operandi and therefor oppose this proposal.--John Cline (talk) 04:00, 7 April 2018 (UTC)[reply]
  • I don't know enough about this WikiProject to have an opinion about whether it should be dissolved, but I hope someone who does will respond to Lojbanist's concern about new stub-related templates being sent to TFD, ignored and automatically deleted. If this is actually happening, perhaps some kind of tweak in the process is in order.—Anne Delong (talk) 12:20, 7 April 2018 (UTC)[reply]
    • As a long-time member of WPSS, I can tell you that it's not our practice to arbitrarily delete or nominate for deletion a stub template or category that was created in good faith (and sometimes not so good faith). Believe me, we're sticklers for consensus. If there has been an issue such as those referred to by nom, I'm unaware of it, and I'd appreciate someone bringing it to the attention of me or any other stub sorter. I have looked into nom's past contributions and comments (under both usernames) and can't find any reference to stub-related issues. Pegship (talk) 18:17, 7 April 2018 (UTC)[reply]
  • WSS has been around since 2004, and a lot of its processes date from when the project and Wikipedia as a whole was more active. Perhaps if it is to stick around, it should be optimized to operate with fewer people required to approve things. --Rschen7754 18:38, 7 April 2018 (UTC)[reply]
  • Oppose the specific motivation cited (that stub templates not approved by this group are often deleted at TfD) isn't helped by dissolving the group, and I see no good reasons to get rid of this system. There must be some place to discuss stub templates. power~enwiki (π, ν) 18:19, 8 April 2018 (UTC)[reply]
  • Oppose While some parts of the project may be outdated/inactive, the project as a whole goes on. -- Iazyges Consermonor Opus meum 13:37, 9 April 2018 (UTC)[reply]
  • Oppose I find stub sorting to be helpful in editing and improving articles. Any issues that are a "downside" to the process can be improved or otherwise handled rather than obliterating the entire system.--Paul McDonald (talk) 14:45, 11 April 2018 (UTC)[reply]
  • Oppose Stub sorters may be steadfast in their demands that NPPs stubsort instead of just mark as a stub even though that isn't their job, but stub sorting is helpful. L3X1 ◊distænt write◊ 14:55, 11 April 2018 (UTC)[reply]
Note: As the templates that "demand" sorting above have been unused for 8+ years, I'll be nominating them for deletion once this discussion is closed. Thanks for your positive comment. Pegship (talk) 16:51, 11 April 2018 (UTC)[reply]
Pegship If that was supposed to be sarcastic and mean something else, it went over my head. L3X1 ◊distænt write◊ 21:53, 11 April 2018 (UTC)[reply]
L3X1 - No sarcasm or meanness meant! I'm mildly chagrined that those templates still exist, and my comment on your positive note was meant in good faith. (I tend to avoid use of the word "support/ive" in these discussions unless I'm presenting my own POV.) Cheers, Pegship (talk) 22:45, 11 April 2018 (UTC)[reply]

Page previews - request for feedback

After positive results from our most recent A/B tests on Page Previews on German and English Wikipedias, the Readers web team are planning the next steps of feature rollout for the first half of April 2018. We have requested feedback and there's a discussion happening over on Wikipedia:Village pump (miscellaneous). Yours, OVasileva (WMF) (talk) 21:07, 6 April 2018 (UTC)[reply]

Next Steps - Thanks for your participation in the discussion. Since we haven’t heard any comments in the last few days, we've posted next steps for deployment based on the feedback we received so far. Let us know if you would like more time for discussion. Thanks! OVasileva (WMF) (talk) 14:44, 12 April 2018 (UTC)[reply]

List of sources owned by editors

I would like to see, for want of a better term, an editors library. That is to say, a collection of sources owned by editors which can be searched by other users for the purpose of checking sources or clarifying ambiguous sentences. I think this would be particularly useful for reviewers spotchecking sources at WP:FAC or WP:GAN, see this discussion [[7]], but would also be of value in cases such as this [[8]] where an editor had synthesised or misinterpreted the source.

The library would be searchable by source and by editor thus entering the source in the search box would bring up a list of every editor with access to it, while entering a user name would bring up a list of sources that that editor has. If it was suspected that content had been added with a fake reference or not truly representative of the source, an editor could search for a list of all editors who own the book and ask one or more of those editors to corroborate the content. I imagine quoting the source verbatim would have some copyright issues, although a private email might solve that problem, but In most cases I imagine a simple "Yes, that's okay" or "No, that's not what the source says" would suffice. Searching for a specific editor might be desirable if they are known to have a particular interest in a subject or perhaps are more readily available because they operate in the same time-zone or are simply more active. Another reason one might want to see an editor's library is when trying to fix an ambiguous sentence: After seeing which editors have access to the source, one might want to see whether a particular editor has more books which might clear things up. See the question about HMS Pallas and the French frigate Minerve, and whose guns did what, here [[9]], as an example.

Only sources owned by the editor would be listed so not library books they once borrowed or internet sources which are freely available, although listing any subscription-only sources one had access to would be appropriate. Editors need not catalogue everything and might, for example, only want to include things they are particularly interested in. Entering one's library into the database would indicate one's willingness to check references but there could also be a userbox expressing that the user is happy to help and incorporating a link to his/her library page.

I don't know how much work is involved in setting it up or even if it's something other editors want, so happy to here any comments or suggestions.--Ykraps (talk) 10:14, 8 April 2018 (UTC)[reply]

Well, it's probably worth consulting with WP:RX. I like the idea. Technically, if there's a set of subpages by editor, an ISBN search should be easy (along the lines of the archive search over at WP:ANI. Bellezzasolo Discuss 10:24, 8 April 2018 (UTC)[reply]
Unfortunately, this idea would probably violate all sorts of copyright laws. Most nations have laws which limit scanning published works, and making them available to others on line. Blueboar (talk) 11:43, 8 April 2018 (UTC)[reply]
@Blueboar: actually Ykraps is not suggesting scanning, if you look, only that the editor would be able to check a reference and say whether it is properly employed or not. Peter coxhead (talk) 12:17, 8 April 2018 (UTC)[reply]
But to discover whether a source is properly employed (or not) one needs to actually obtain a copy of the source, and READ it. I am now confused as to what is being suggested. Blueboar (talk) 12:59, 8 April 2018 (UTC)[reply]
@Blueboar:, User:Peter coxhead is correct. All you will see is a list of books. You are asking the person with the book to get it from his bookshelf, read the appropriate page and tell you whether it supports the paragraph in the article. Yes, there is an element of WP:AGF in that you are trusting the book owner to interpret the source faithfully, but that is no different to how it stands now with citations. The advantage is when there are multiple editors with the same book, who can jointly confirm the text is fully supported. In this case above [[10]], User:Slatersteven would've been able to go to the database and see that both I and User:Wiki-Ed own Ferguson's book. He could then ping us. If we hadn't had the article on our watchlists, we would never have known about the issue. This system overcomes all that.--Ykraps (talk) 15:26, 8 April 2018 (UTC)[reply]
Ah... ok. Thanks for clarifying. Blueboar (talk) 15:36, 8 April 2018 (UTC)[reply]


Seems a fair proposal. As long as that is all it is a list. Not sure it is worth all the work though.Slatersteven (talk) 15:30, 8 April 2018 (UTC)[reply]

I'm not saying this is a bad idea, but frankly it does appear to me as a rather inefficient undertaking. Because, what's the point in telling people that Joe has 200 books at home, if Jane has access to a big reasearch library with millions of volumes? If you have just one person frequenting such a library and who is ready to help others check sources - which I think is what WP:RX is about -, the value of all these documentation efforts by individual users is diminished enormously. Not only for reasons of quantity, but also because of a “specialization mismatch”: Joe's books that are of interest to many people will very likely also be available from the library. But Joe's super-specialized books - the ones that even most people with library access might struggle to obtain -, well, how likely is it that there's another Wikipedia editor interested in such a book (and who additionally knows that such a directory actually exists)? This makes me somewhat skeptical, cost-benefit wise. (By the way, Wikipedia:WikiProject Resource Exchange/Shared Resources and de:Wikipedia:Bibliothek pursue a similar goal to that suggested here, though these are lists. Both are also fairly deserted, judging from the version histories.) — Pajz (talk) 16:14, 8 April 2018 (UTC)[reply]

Quite high I would say, given the breadth of users it is more than likely that even then most specialized subject has multiple edss with access to the sources. What is not available is a way of tying that up with the edds who have the sources. The only issue I have is the ABF inherent, one edd claiming to have access to a source is not enough, we want people to check it. — Preceding unsigned comment added by Slatersteven (talkcontribs) 16:21, 8 April 2018 (UTC)[reply]
Pajz This is not about telling someone where to find references for their article, this is about putting an editor in touch with another editor who can very quickly determine whether a sentence in an article is faithful to the supporting citation. I don't see how any of projects mentioned could help with the example scenarios I've given (although I may have underestimated the scope of those projects). If I wanted to know whether Winfield's book (see below) contains an entry for a 74-gun ship called Pearl, I don't want to be told there is a copy of the book in a library thirty miles away, I want to be told whether it does or it doesn't. As regards the amount of work, not being a computer programmer, I don't know what's involved but I would've thought that a searchable set of sub-pages within Wikipedia would a reasonably straightforward thing to set up, for someone with the know-how. I am anticipating that editors who want to take part in the scheme will enter their own data.--Ykraps (talk) 11:49, 9 April 2018 (UTC)[reply]
  • @Ykraps: Check out inventaire.io/, which is a Wikidata front-end in which people can list the books they have and make them available to loan to other people. There are lots of web platforms like this, but this one is unusual for using and contributing to Wikidata's catalog of books. You might want to check this out because they have modeled what you are describing, and their service might be ready now to do what you want. I know it is off wiki but before any such project could ever be part of Wikipedia projects, it has get an off-wiki demo and then go through multiple steps to get closer. Blue Rasberry (talk) 16:59, 8 April 2018 (UTC)[reply]
I fear we may be at cross-purposes, what I'm suggesting is a set of sub-pages within Wikipedia which are searchable. The idea being that you can find a fellow editor who can very quickly corroborate an off-line source without lots of searching, having to visit a library or wait for someone to send them the book in the post. As an example: A user creates an aricle entitled HMS Pearl (1767) which says it's a 74-gun third-rate ship of the line and references the article with Winfield, Rif (2007). British Warships in the Age of Sail 1714–1792: Design, Construction, Careers and Fates. Seaforth Publishing. p. 195. ISBN 978-1-84415-700-6. {{cite book}}: Cite has empty unknown parameter: |titlelink1= (help). Under my proposal, anyone (including ips) can search for the source, which will bring up something like this with a list of Wikipedia editors who own the book. Any or all of those editors will be able to tell you that there is no such ship and that p.195 contains an entry for HMS Pearl (1762), a 32-gun frigate. Can anything you're suggesting help in a case like this?--Ykraps (talk) 17:27, 8 April 2018 (UTC)[reply]
@Ykraps: No one actually has to ship the books. Some people made wiki-based software imagining that the wiki community would want to mail books, but try to imagine that if when you found someone who had the book you wanted, you asked them to check something instead of mailing you the book. I know it is not the same, but this is as close as you are going to find for already-existing software based on Wikimedia projects. Can you imagine yourself joining their project and ask them to add a button that says, "do not mail, just check a page"?
Instead of searching Wikipedia subpages, this project has a Wikidata-based book catalog which is searchable. Does that not sound better to you than a plain text search system on Wikipedia pages? This project produces lists like that example book page you created. Blue Rasberry (talk) 12:04, 9 April 2018 (UTC)[reply]
@Blue Rasberry: Yes, I see how that could work. I guess the advantage of having something within Wikipedia is that Wikipedians are more likely to be interested in maintaining Wikipedia articles, and are almost certainly going to have the sort of specialist books needed for some of the obscure subjects. Added to which, there is already a method of communication, the talk pages, that means there is no need to divulge your email and because it is visible to all, might attract the attention of additional editors. However, there does not seem to be a lot of support for this proposal so may be I need to rethink things.--Ykraps (talk) 05:56, 10 April 2018 (UTC)[reply]
@Ykraps: I would call inventaire a Wikimedia project because of all the Wikidata integration and Wikimedia culture it already uses. No one ever gets access to do weird experiments at Wikipedia.org, and even access to tools.wmflabs.org can be more trouble than developers want. Check the credits at the bottom of inventaire - they obviously care about Wikimedia projects and went to a lot of trouble to integrate these tools with that. These kinds of experiments happen continuously and 1 in 100 actually comes into Wikimedia projects. When the WMF does decide to commit their own staff to software development often it is based on someone else first doing an experiment. I know this inventaire project is not perfect but it is a working demonstration. Things like Wikimedia account integration are just additional features which a developer could install depending on how much funding they have, which depends on how much interest other people have.
I was not showing you this to make you think you have no support for your proposal, and I think you are interpreting this the wrong way. I hoped that when you looked at this you would see that someone cared so much that they coordinated labor worth US$50,000+ to build a demo of your idea. From an optimistic perspective, you could say that your idea has already recruited a massive donation of labor, development, publicity, and community building which resulted in a working demo. Blue Rasberry (talk) 12:02, 10 April 2018 (UTC)[reply]
Sorry, when I said there was little interest, I didn't mean from those that have commented here. I was merely noting that many people have visited this page to comment elsewhere but didn't care sufficiently to contribute to this discussion (which is absolutely fine. I have no problem with that either). It is difficult for me to get a handle on what Inventaire does or is capable of, because I am required to create an account in order to access it and this is something I am uncomfortable doing. I don't think I'm alone in my reluctance to sign up to strange things on the internet either and this is another advantage to running the project in-house; we all already have global accounts.--Ykraps (talk) 11:47, 11 April 2018 (UTC)[reply]
Wikipedia:WikiProject Resource Exchange/Resource Request list many books they can access by posting at Wikipedia:WikiProject Bibliographies and Wikipedia:WikiProject Academic Journals.....that makes lists Wikipedia:List of bibliographies.--Moxy (talk) 12:12, 10 April 2018 (UTC)[reply]
  • I love the idea in principle. I think publicising which editors have access to which specialist publications, and are willing to check and supply reference details for the project, would be absolutely wonderful. When I worked in the GLAM sector, we had access to an amazing array of resources, and I still do within my own specialist areas of UK botany and Alpine mountaineering. I probably see this working best at the WikiProject level, but maybe with a standard format encouraged across Projects. In fact, I posted a selected set of resources I held for alpine mountaineering back in 2015, with the suggestion it could be worth expanding (See here). An issue to consider is removing content listed by an editor when that individual ceases to contribute here. Boy, the number of times I've thrown out (ie sent to charity shops/eBay) specialist books which I've used to enhance an article, or didn't feel I'd ever be likely to want to use again myself. By way of example, some colleagues who adminster my local World Heritage Site recently threw out a number of very detailed reference books they'd been given by other WHS projects around the world - which I saved from the bin. I used one to enhance this article, and thought about offering to post it to someone who might like to access the rest of the amazing detailed inscription details. The cost implication of posting put me off, but keeping it to access on someone else's behalf would have provided me the perfect excuse to retain it! Sadly, I think it went down the paper recycling route in the end. Regards from the UK, Nick Moyes (talk) 20:57, 10 April 2018 (UTC)[reply]
    Nick Moyes, I guess I was thinking that at its most basic, the scheme could be administered/managed/publicised by a Wikiproject, either a new one or an existing one such as WP:RX. With regards to editors leaving, I thought probably a computer programme could take care of that. On joining, the editor would create his/her own library page - something like this. The programme would then create a page for each book, similar to this and add your user name along with any subsequent users who had that same book in their library. When someone retire, they wipe their library page and the programme removes their name from each book page. Again, I'm not a programmer so I don't know what's possible.--Ykraps (talk) 12:14, 11 April 2018 (UTC)[reply]
    I've got a library page that I've been maintaining for years, with an offer to check anything people want verified. I haven't had a single request, ever (I don't offer this too widely, however, as I don't want to be bugged too often). The principle sounds good, but in practice there isn't an easy way for someone to go through every list of editors' books and find those with a copy of a certain title, unless the library was based on a template with some kind of global search function, i.e. a bot scans all libraries that follow a certain format and catalogues all titles so that they can be searched and editors identified. Whether that's even possible with the Wiki software is the question. Having editors keep their lists updated with the right title, author, publisher, year, ISBN, etc is a huge task that can result in lots of errors. — Marcus(talk) 16:25, 13 April 2018 (UTC)[reply]
    @MarcusBritish: Maybe the reason you haven't had a request is that your library hasn't been widely publicised. There have been three occassions I can think of when I would have asked you to check a source for me, had I been aware that you had access to those books. It's an impressive list by the way and I will try to remember it for the future. In return, I will create a similar page. Although, as you say, what is needed is a programme that can collate these lists and a search engine. Perhaps I am over-complicating things and all that's really needed is for each Wikiproject to list it's members sources on a project page.--Ykraps (talk) 09:18, 14 April 2018 (UTC)[reply]

RfC: Ending the system of portals

Should the system of portals be ended? This would include the deletion of all portal pages and the removal of the portal namespace. 14:23, 8 April 2018 (UTC)

Survey: Ending the system of portals

  • TOTAL VOTES COUNTED AS OF 2018/04/17 06:14 UTC:
  • Strong support: 2
  • Support: 116 (120 inc. strong & weak support)
  • Weak/Somewhat support: 2
  • Conditional support: 7
  • Neutral/mixed: 4
  • Weak/Somewhat Oppose: 4
  • Conditional oppose: 4
  • Oppose: 97 (127 inc. strong & weak oppose)
  • Strong oppose: 26
  • Other (alternative proposal, mostly deprecating/making portals historical): 18




  • Somewhat Oppose The portals are a very nifty tool which of course is why they exist. I understand the reasons for deleting them. Personally, I would think an appropriate action would be to leave them as they are.The popular portals, like the ones with multiple millions of visitors, should probably be maintained and updated. The more obscure ones can be saved and left in the order they are. If a change is necessary: Keep the current events.
  • Strongly Oppose I love Wikipedia and reference it as my first source when learning about a new topic, but I visit the 'Current Events' portal at least once a day because to me this is the equivalent of reading the morning newspaper that was the standard about 50 years ago. The diversity of events which individuals take the time to report there is unrivaled. Often I learn of events that only much later become TV-news worthy or never make the circuit. In a sentence, 'The 'Current Events' portal enriches my life and to lose that would be a shame.' Please do not remove this section just because you find it unnecessary, please rather consider the many people who don't contribute but appreciate the thing for what it is. This comment is only my second time ever editing a Wikipedia page. The other time was in the 'Current Events' portal. So there again is another benefit to it, it draws in visitors and entices them to become contributors. Please, PLEASE, let it be.
Something that I've done in the past, please forgive my ignorance here, in relation to clearing disk space on my computer, has been to search for empty folders in my directory and delete them using a third party utility. As this applies to what seems to be the appeal to many here of deleting the portals, mainly clearing up unused namespace, could something similar not be done? If a portal hasn't been edited in a certain amount of time, could there not automatically be a message posted at the top of it, like the one that led me to this discussion, notifying users that unless the portal logs some activity within the next short time frame, it will automatically be deleted? Seems like a good compromise without killing the whole program.
By word count, there are currently 150 'Oppose' and 206 'Support' including multiple usages by single users.
  • Strongly Oppose Wikipedia's Current events page is far more up to date than Wikinews. Until Wikinews catches up, it'd be awful to remove the current events portal. 2601:580:C000:604F:A0A4:9E2B:1137:927 (talk) 02:23, 17 April 2018 (UTC)[reply]

66.76.14.92 (talk) 00:33, 17 April 2018 (UTC)[reply]

  • Strongly Oppose The current events portal provides a very unique concatenation of articles from various topics. Without a portal like this, Wikipedia would lose a critical access point to recently updated articles, articles relating to current events, and pertinent related articles which tie in to topics in the news. If there is not another medium to provide this type of dynamic insight into Wikipedia's content without something like a portal, I think preserving this space which attempts to provide unbiased current events is more important now more than ever. Esa895 (talk) 00:16, 17 April 2018 (UTC)[reply]
  • Strongly oppose I find the current event portal extremely useful. I read it daily to keep up with significant world events.
  • Support Taking at look at one example of Portal:Cricket: it contains a summary of the lead of Cricket, which is out of date (there are now twelve full members); obscure random articles that is just something someone took the effort of making them good - like Yorkshire captaincy affair of 1927; out of date news, random anniversaries and other random stuff like that. Readers aren't looking for random cricket-related stuff - it is clear, from the extremely low page-views, that readers don't care about portals. The most-viewed portals are purely from being featured on the main page; but for example Portal:Science gets only 8 out of 100000 of the views of the main page, a few hundred people a day, and they are likely from random clicks - not from people interested; which would likely account for most views of other portals too. There have been suggestions of automated systems for helping to develop portals, which even if developed wouldn't help, because portals aren't useful in any way. Personally, I've never felt the desire to read, say, a random science article, which is what portals consist of (most portals indeed have literally randomly selected content from a list)
In essence, portals try to straddle reader-facing and editor-facing stuff, but are terrible at both. They aren't really part of the encyclopedia; nor do they help in the backend - they don't benefit the encyclopaedia in anyway (the main page, which could be called a portal of everything, in contrast, encourages people to improve articles). Any navigational purpose, which I don't think portals help with at all, is better served through outlines. Featured articles and other stuff in a topic are cared more by wikiprojects, which generally link them already. Implementation could be reasonably easily done, as nearly all, I reckon, portal links in mainspace and in all pages indeed are through templates like {{portal}} (in all pages I estimate 99% of links are from being linked in wikiproject banners), which can be blanked to remove links; once the links are gone from mainspace, the portal pages can be deleted. Galobtter (pingó mió) 14:29, 8 April 2018 (UTC)[reply]
@Galobtter: You take one example for deleting a whole namespace, some portals are working and there is no need for deleting the work of hundreds of people!--Sinuhe20 (talk) 07:55, 15 April 2018 (UTC)[reply]
  • Support: It is time to abandon this useless relic simply because its function is duplicated (and done better) elsewhere. The portal system are also incomplete and what gets a portal is rather strange and random: take a look at Portal:Contents/Portals#Technology and applied sciences, Why is Portal:Amiga included but not Apple II? Why are Portal:Python programming and Portal:Java included but not C (programming language) or BASIC? Why Portal:Maryland Roads and Portal:Michigan Highways but nothing for Arizona Highways? -- or any roads in the UK? (We do have Portal:UK Trams -- last substantive edit in 2007 -- so there is that.) --Guy Macon (talk) 15:59, 8 April 2018 (UTC)[reply]
  • Support, in the good old days, misguided by the hype, I even created Portal:Lithuania. Agree that portals are not maintained and should be deactivated. There might be one or two portals out there that have some useful stuff worth salvaging, but 99% of the 1500 portals should be deleted. At the very minimum, the {{Portal}} from articles should be removed. Renata (talk) 16:01, 8 April 2018 (UTC)[reply]
  • Support, I've never understood what portals were supposed to be good for to begin with. They've always seemed like a thoroughly obsolete idea to me, and the ones I've seen were almost invariably ill-maintained, magnets for POV editing, or downright useless. Fut.Perf. 16:05, 8 April 2018 (UTC)[reply]
  • Support speaking for myself I’ve only made one portal edit (a reversion) and since that time 9 years ago have not found the desire to edit one since. They don’t seem to have any net benefit to the encyclopaedia side of things and hardly anyone seems to maintain or look at them, so it’s fine by me if they were removed. Aiken D 16:11, 8 April 2018 (UTC)[reply]
  • Support for the reasons explained above and those listed at User:DexDor/Portals. DexDor (talk) 16:25, 8 April 2018 (UTC)[reply]
  • Support, per various comments above but FPaS's in particular. - Sitush (talk) 16:27, 8 April 2018 (UTC)[reply]
  • Support There has never been sufficient either reader or editor interest to maintain portals. I would be open to someday presenting next-generation portals which without any human involvement present Wikimedia content in a category in a human-readable way, perhaps ranked by article importance and quality. I would not want new editors looking at the portal system and using their labor to develop this content when it is a failed project. Portals are a burden for remaining out of date and abandoned. I would not want any reader to find the low quality content here. If portals get shut down then I think it should happen on a schedule of about 1 year to give anyone time to collect the information in them for re-integration, if there is anything to salvage. I think that usually there will be nothing to save, but at the same time, the portal project did recruit 1000s of editor hours and I would not want that deprecated lightly and without time for people to respond. The wind-down plan could be 3-months of comments, then 3 months of removing links pointing to portals, 3 months to move portals out of the portal: space with "deprecated" tags, then at 12 months actually delete or mark them so that they would not appear in search engines. Blue Rasberry (talk) 16:45, 8 April 2018 (UTC)[reply]
  • Strongly Oppose: Many people, including myself have invested many hours to improve and maintain portals. They are usefull to navigate. I propose that all portals which were created should be kept.--Broter (talk) 17:15, 8 April 2018 (UTC)[reply]
This is an example of the Sunk cost fallacy. I get that many people have given an admirable effort to keep the portal system going, but this doesn't invalidate the well thought out reasoning for them being made obsolete. Many other elements of Wikipedia have been depreciated in spite of the hard work that users put into them. User:Axisixa [t] [c] 23:23, 8 April 2018 (UTC)[reply]
  • Support The first item on the top right of the main page, is occupied by Portal:Arts, which hasn't been serious updated in years. This is supposed to be a featured portal. It's "supported" by a project whose page hasn't seen any activity since 2016. It's embarrassing. Vexations (talk) 17:24, 8 April 2018 (UTC)[reply]
No, what's actually embarrassing is that some editors voting for deletion don't appreciate that Portal content is often made via other templates, which are themselves updated in varying amounts. The portal that forms Wikipedia's Main Page hasn't been edited at all this year yet. Nick Moyes (talk) 13:33, 12 April 2018 (UTC)  [reply]
Actually, Portal:Arts, which I hadn't looked at for years, still seems to function fine. The sections have automated rotation of decent lists of articles, the anniversaries are for April. It's like one of those spaceships in Alien and other movies keeping going while the crew are in suspended animation.... It's not a very time-sensitive area, and the reader is still well-served imo, for several visits. Johnbod (talk) 16:16, 13 April 2018 (UTC)[reply]
  • Support despite adding these things for years and creating many see here ... it's clear that these have failed and do not serve their function as intended.--Moxy (talk) 17:36, 8 April 2018 (UTC)[reply]
  • Support They're outdated and the updating of them takes away from precious time that could be spent making 'Outline' articles. These are much better and avoid duplicate and outdated content on portals. I find that most people don't use portals either, rather using the search function or the main articles themselves which can act as portals. For example if wanting to know about economics I would go to the Economics article rather than the outdated Portal:Economics – Craig Davison (talk) 17:40, 8 April 2018 (UTC)[reply]
  • Support Largely unused an unmaintained. An outdated idea that the community clearly does not care to continue supporting. Beeblebrox (talk) 18:04, 8 April 2018 (UTC)[reply]
  • Support Minimally delete the internal spam from every article directing the reader to the related portals. --RAN (talk) 18:11, 8 April 2018 (UTC)[reply]
  • Conditional Support - Support end of portals system as we currently understand it; Oppose deletion of the portals by default - I recently had a conversation about portals with a group of people learning to contribute. A couple of them stumbled upon portals and loved the idea. Sure enough, when I looked at the particular portals they mentioned, they hadn't been updated in years. (Portal:Speculative fiction was one of them that I remember off-hand). Talking a bit more about what they liked about portals, three things stood out: (1) it has a lot of related content gathered together for a particular subject, (2) it was useful to find articles to work on and to get a better feel for the state of Wikipedia's coverage of that topic, and (3) it was much more visually appealing/inviting/useful than a WikiProject page. In other words, portals served them primarily as editors, not as readers, and that's not the way we current understand/use portals. For that reason, I'm supporting. However, it's a partial support because I oppose deletion of the portals by default -- they should be moved to relevant WikiProject subpages by default, and MfDed selectively where the WikiProject does not wish to retain them. I would love to see the portals system reconceived as a way to make WikiProjects more engaging to new editors (or any editors), maybe even thinking about using the main WikiProject page as a sort of portal to a subject. Of course, none of this is to say the outcome of this RfC should in any way mandate that any WikiProject do anything differently. — Rhododendrites talk \\ 18:10, 8 April 2018 (UTC)[reply]
    • If the portals are all deleted, it would be a Good Thing if the Wikiprojects were notified with "heads up; the following portals are about to go away. Feel free to move them to subpages of your Wikiproject before that happens." --Guy Macon (talk) 18:21, 8 April 2018 (UTC)[reply]
      • @Guy Macon: I'm sorry, but that's not very logical. The portals should instead be tagged with {{historical}} in order to preserve their page histories. ToThAc (talk) 18:08, 10 April 2018 (UTC)[reply]
        • What part of "If the portals are all deleted" are you having trouble understanding? --Guy Macon (talk) 21:45, 10 April 2018 (UTC)[reply]
  • Support obsolete with respect to top articles in their subject. Don't delete, but mark as historic, lock them down (full protection), and force de-linking from content namespaces. --Dirk Beetstra T C 18:15, 8 April 2018 (UTC)[reply]
  • Support - efforts should be directed elsewhere, where they are more useful. Tazerdadog (talk) 18:16, 8 April 2018 (UTC)[reply]
  • Support – but move portal pages into Wikipedia/user space automatically or on request. Best, Kevin (aka L235 · t · c) 18:22, 8 April 2018 (UTC)[reply]
  • Support - I find that portals are almost entirely useless. Delete as such. Beyond My Ken (talk) 18:24, 8 April 2018 (UTC)[reply]
  • Oppose - I have never edited the Portal namespace, and I find many of the linked examples to be profoundly useless. However, I don't feel that cutting non-harmful features benefits the project. With a clear proposal to migrate some of these to be part of WikiProject pages, I would be neutral on this proposal. Without such a proposal, I must oppose. power~enwiki (π, ν) 18:30, 8 April 2018 (UTC)[reply]
    • [EC] I do feel that cutting non-harmful but useless features benefits the project. While looking over the technology portals I ran into a sneaky POV criticism of Al Gore that was put there when he was running for president. Because editors almost never read them but some users do, Portals are a great place to hide spam, BLP violations, etc. --Guy Macon (talk) 18:36, 8 April 2018 (UTC)[reply]
what if Portal A was redirect to Outline of A. This was the name function still directs readers to an overview/index of a topic.--Moxy (talk) 18:33, 8 April 2018 (UTC)[reply]
No problem with that if [1] Outline of A exists and isn't abandoned and [2] Portal A is seeing more traffic than we would expect from bots and mis-clicks. --Guy Macon (talk) 22:40, 10 April 2018 (UTC)[reply]
  • Oppose - Reform may be due (which I would be happy to discuss later if this discussion shifts and does not pass), but I do not think abolition is the way to go. — Godsy (TALKCONT) 18:43, 8 April 2018 (UTC)[reply]
I’d be interested to know how we would reform an area that is more or less abandonded. The community and the readers seem to have made it clear they don’t find these particularly useful, we can’t force anyone to look at them or maintain them. Beeblebrox (talk) 23:59, 8 April 2018 (UTC)[reply]
Guns. We need squads of heavily-armed thugs who will kick down the doors of Wikipedia editors who aren't working on what we want them to work on and hold a gun to their head until they comply. Not a practical solution, you say? How do you explain the immense popularity worldwide of similar systems? :( --Guy Macon (talk) 22:46, 10 April 2018 (UTC)[reply]
  • Support — For contentious issues with a strong political POVs it a can be a real problem to maintain a political balance. Take for example Portal:Genocide a far better portal name is Portal:Human rights, but POV warriors prefer labelling "crimes against humanity" genocide for various reasons which include style (shorter more punchy name), blame game, and legalistic (genocide so defined by treaty, crimes against humanity are in part defined by custom). Given the problems of eyes and maintenance, it is too easy for contentious issues in portals to avoid the sort of scrutiny that the major articles on an issue receive see for example Portal:Terrorism which suffers from the aliments to which Galobtter referrers. -- PBS (talk) 19:38, 8 April 2018 (UTC)[reply]
  • Conditional support Deleting them outright is not OK. In general I'm in agreeance that Portals are ill-maintained and not used often. However some are well-maintained, useful for some, and the editors worked very hard on them. They should be userfied, or moved as a subpage of a WikiProject. At the very least, every WikiProject needs to be notified that their related portal is doomed, and let them decide what to do with it. Please don't blindly delete all of them. MusikAnimal talk 19:39, 8 April 2018 (UTC)[reply]
  • Support: I have always thought of portals as redundant and even confusing sometime. They more or less usually look like historical archives due to outdated information with some having information dated over a decade ago. Also they generally duplicate WikiProjects pages which are more lively and better maintained. I am neutral on deleting/merging/moving or whatever, but I believe it is time for "Portals" to go. –Ammarpad (talk) 19:51, 8 April 2018 (UTC)[reply]
  • Support Portals are rarely used or maintained, and they don't jell with the interface or how most readers/editors navigate. Readers want to 'click-through' straight to content. Outline articles and interlinking within standard articles offers this and makes portals obsolete. Cesdeva (talk) 20:06, 8 April 2018 (UTC)[reply]
  • Support. These are largely useless and not well maintained. Natureium (talk) 20:14, 8 April 2018 (UTC)[reply]
  • Support: they are redundant to other means of navigation, mostly poorly maintained, and in some areas provide a view of the structure of the underlying topic that is not neutral and by the nature of portals not sourced. Peter coxhead (talk) 20:27, 8 April 2018 (UTC)[reply]
  • Support because they are usually poorly watched they are a magnet for POV pushing and craziness. I had a heck of a time with a Portal on ISIL as there was no good way to keep it from turning into almost terrorist advertising. I finally got it redirected. The only reason selected Portals get significant traffic is because they are prominately linked. I've NEVER been directed by Google to a Wikipedia portal and you have to click a search box to find portals in internal search. Portals are so 15 years ago, the internet moved on a long time ago. Legacypac (talk) 20:40, 8 April 2018 (UTC)[reply]
  • Support: Poorly maintained, rarely useful, few views except the eight portals on Main Page, not worth editor resources. "Page information" under "Tools" shows page views in the past 30 days. I compared some random portals to their main article, e.g. Portal:The Simpsons 527 views versus The Simpsons 235,536 views. The main portal page gets 0.2% of the views of a single covered article. My other examples: Portal:Cricket 1,527/185,133 = 0.8%, Portal:Tennis = 943/64,213 = 1.5%, Portal:Cars 2,213/91,460 = 2.4%, Portal:Greece 963/223,193 = 0.4%, Portal:Dance, 1,421/60,807 = 2.3%, Portal:King Arthur 373/166,466 = 0.2%, Portal:Microsoft 2,646/230,201 = 1.1%. PrimeHunter (talk) 21:18, 8 April 2018 (UTC)[reply]
  • Support deprecating them. They are utterly useless, and like many dead-end ideas from the early days, become more and more of a maintenance burden as time goes on. Next let's axe the sidebars, outlines, and bibliographies.
However, I don't think mass-deletion is going to work (it rarely does). Instead I'd suggest updating any relevant guidelines to say they are obsolete, then introducing a speedy deletion criteria along the lines of "pages in the portal namespace that are no longer actively maintained". – Joe (talk) 21:37, 8 April 2018 (UTC)[reply]
Very hard to get a new CSD approved but with a clear RFC result that would be a good mechanism to remove them systematically. Perhaps X3? We should statt by removing them from the top of the mainpage - the most important real estate for the least important namespace on the project. That will drop traffic on the portals a lot. Legacypac (talk) 21:44, 8 April 2018 (UTC)[reply]
  • Support - As sad as it is, no one seems to care about portals anymore. I hepled get P:MDRD to Featured Portal status (a process which has been shut down due to inactivity) and also maintain P:USRD every month for the past several years. While I value putting in time to keep the portals updated every month, unfortunately not many other editors care enough to contribute to the portals. Several years ago, many editors would contribute to P:USRD and offer suggestions for selected articles, pictures, and Did you know? hooks, which would make the portal easy to update every month. In recent years, there are very few suggestions for content which usually leads me to have to dig for stuff every month. Perhaps we could reduce the maintenance of portals and have them just randomly generate content and change every time they are refreshed, P:MDRD does this for selected pictures and Did you know? hooks. If no one cares enough to keep portals updated, then maybe it is time to get rid of them. However, I would not want to delete the entire portal namespace but would rather mark all pages in portal namespace as historical and remove links to them from article space. By doing this, we could still keep the attribution of the history of the portal namespace rather than delete a large portion of Wikipedia history. Dough4872 21:41, 8 April 2018 (UTC)[reply]
  • Support - as it appears they are largely pointless in the current environment. Only in death does duty end (talk) 21:43, 8 April 2018 (UTC)[reply]
  • Support per above. Largely useless, with dubious value to readers. -FASTILY 21:45, 8 April 2018 (UTC)[reply]
  • Conditional support I feel that portals result in additional maintenance time that could probably be better invested elsewhere on the project. However, interested editors should be given an opportunity to migrate the content elsewhere, and the portals should not be outright deleted right away. --Rschen7754 22:39, 8 April 2018 (UTC)[reply]
  • Oppose no strong reason to do so and it'd be more of a pain to implement than it is worth. The portal namespace isn't that useful, but I see this proposal as being about equal in usefulness to the namespace as a whole (namely, not very...) When the two options are both washes, there is no reason to change. Change for the sake of change is pointless. TonyBallioni (talk) 22:42, 8 April 2018 (UTC)[reply]
  • Alternative – Why don't we just encourage editors to de-link portals that are unmaintained when they encounter them? Then if someone cares that will prompt them to do some maintenance. Dicklyon (talk) 22:57, 8 April 2018 (UTC)[reply]
Because well meaning but not clued in editors will revert them, and keep add portal links without realizing what a disservice they are doing. Legacypac (talk) 00:07, 9 April 2018 (UTC)[reply]
  • Support There's no reason to let this largely useless part of the encyclopaedia continue to exist and just create problems for readers as well as editors. That said, I'd be open to migrating some content to wikiproject pages (on a case by case basis) if editors find a need . —SpacemanSpiff 23:34, 8 April 2018 (UTC)[reply]
  • Support Portals are obsolete, even the one I helped create and tried to maintain for quite some time has become an irrelevant mouldy pile of arbitrary stuff. Roger (Dodger67) (talk) 23:52, 8 April 2018 (UTC)[reply]
  • Support, unfortunately. They aren't a well-maintained part of the encyclopedia, and updates to most portals come very infrequently. The vast majority of page views are to the main articles themselves, as described above, and the portals are an afterthought. The featured portals process was abolished recently for a similar reason. However, I do think these portals should be archived, whether as Wikipedia project pages or in some other format. epicgenius (talk) 01:58, 9 April 2018 (UTC)[reply]
  • Oppose While they are most definitely obsolete, I don't like having to get rid of a piece of our history. The namespace is generally unseen and unused by the public, anyway. I suggest we use Template:Historical instead. Create a bot job to put it on all "Portal:" pages, and, if so desired, all "Portal talk:" pages, too. Gestrid (talk) 02:01, 9 April 2018 (UTC)[reply]
  • Support - Wikipedia is losing editors, and it therefore does not make sense to expend effort on a portion of the encyclopedia that is barely used and whose function is already accomplished better by other pages. User:Axisixa [t] [c] 02:15, 9 April 2018 (UTC)[reply]
  • Support but do not delete any relevant pages (just mark them as historical instead) - Portals have outlived their usefulness. They were a great idea in the past, but as both Wikipedia and the internet have evolved, they have become moribund. It's true that many had been the result of hard work, but perhaps such energy could better be devoted into our own articles. There have been suggestions that Portals could be more active if they were instead operated by bots, but that wouldn't solve the other main problem (in that no one uses them). With that said, I'm against mass deletion of portals since they did serve some historical value: they could instead simply be marked as historical. As for the Main Page portals, they could simply be moved into the Wikipedia namespace. Narutolovehinata5 tccsdnew 03:18, 9 April 2018 (UTC)[reply]
  • Support deletion per the above. I would not mind archiving them in the Wikipedia namespace and marking them as historical, but I don't feel very strongly about it, so don't mind if they're deleted outright either. Double sharp (talk) 04:00, 9 April 2018 (UTC)[reply]
  • Support - these have long outlived any value they might once have had. Neutralitytalk 04:27, 9 April 2018 (UTC)[reply]
  • Support - Most are no longer maintained, and we should concentrate our work where it matters, on the article pages. Kaldari (talk) 04:29, 9 April 2018 (UTC)[reply]
  • Support, these were never really popular, and it is high time that they be formally deprecated. Trimming useless or unused features is essential to manage bloat and keep the 'cost' of maintenance down. Lankiveil (speak to me) 04:31, 9 April 2018 (UTC).[reply]
  • Support. Portals should be redirected to the index or outline of their parent topic, if possible, rather than deletion, but they should definitely be deprecated. ♠PMC(talk) 06:08, 9 April 2018 (UTC)[reply]
  • Oppose I just sampled a few portals and they all seemed reasonably well-constructed and helpful for navigation. Deleting such hard work would not encourage activity elsewhere. Per WP:BITE, such hostile action would tend to discourage voluntary effort by showing that such hard work can be casually deleted by a flash mob on a whim. I'm not seeing any benefit or necessity for this. Andrew D. (talk) 06:22, 9 April 2018 (UTC)[reply]
    I understand this argument, but the problem is that portals are usually constructed by one or two enthusiastic editors who then move on to other activities or leave Wikipedia. Once they aren't maintained, their usefulness tends to diminish rapidly. We should not be encouraging editors to build stuff that in the long run is not useful to readers. Peter coxhead (talk) 06:48, 9 April 2018 (UTC)[reply]
  • Consider the articles created by Coxhead such as James Eustace Bagnall. These get little maintenance now and, in any case, get few readers -- maybe one or two a day. When their enthusiastic creator moves on, shall we delete those too on similar grounds? Is Wikipedia only for high traffic, high maintenance pages like Kim Kardashian? All that other obscure stuff just gets in the way, right? Why not just delete everything that isn't vital and focus on getting that right before allowing anyone to start anything else? Andrew D. (talk) 13:17, 9 April 2018 (UTC)[reply]
A low-traffic target page hardly has the same maintenance reliance as a portal (which we intentionally try and funnel readers through en-masse). Cesdeva (talk) 15:05, 9 April 2018 (UTC)[reply]
@Andrew Davidson: you didn't pick a good example in James Eustace Bagnall – he's long dead, and the information in the article isn't going to change. I can give you better examples for your argument, e.g. Ponerorchis cucullata, where there's active research going on and the generic placement has changed recently and might change again, requiring the article to be moved and updated. But portals are different, as Cesdeva says. Since they deliberately cross-connect multiple articles they necessarily need regular maintenance, as relevant articles appear, get moved, get promoted or demoted, etc. Peter coxhead (talk) 16:00, 9 April 2018 (UTC)[reply]
Portals for well-established topics like Mathematics don't need to change much. Wikipedia is an encyclopedia not a newspaper and frenetic activity is not required for such pages. The point is that once you start to claim that we can discard pages because they seem to be a backwater then you put most of our content at risk. And Wikipedia is nowhere near finished yet. People are still developing and arguing about structural aspects like infoboxes and Wikidata. It's far too soon to say that everything's settled and we can discard pages which are currently not mainstream. Andrew D. (talk) 16:12, 9 April 2018 (UTC)[reply]
Well, we'll have to agree to differ, but the argument is not that portals are a backwater, but that, unlike articles, the nature of most portals means that they don't work well if they are backwaters. Peter coxhead (talk) 16:26, 9 April 2018 (UTC)[reply]
No, the argument seems to be that because some portals don't work well, we should destroy them all to make sure that none of them work at all. The main benefit seems to be that we will then have some white space where the portals used to be. Presumably the people who didn't use portals will carry on as before while the people who did like and use them will be infuriated and leave Wikipedia. Me, I'm thinking that the next step should then be to tear down the Village Pump too before we get any more bright ideas like this. Andrew D. (talk) 20:17, 9 April 2018 (UTC)[reply]
It's not "some" it is ALL. The topic traffic portals are dismal failures according to our readers considering the have the highest visability links on the project. The readers rejected this failed idea a long time ago. We just need to turn off the lights. Legacypac (talk) 02:01, 10 April 2018 (UTC)[reply]
No, that's a fake fact – facile and false. Some actual stats are listed below to refute it. Andrew D. (talk) 23:25, 10 April 2018 (UTC)[reply]
You have a funny definition of "false" and "refute". Something linked to on the main page and on thousands of pages and talk pages gets fewer clicks than the word "free" in "Welcome to Wikipedia, the free encyclopedia that anyone can edit" and your conclusion is that this shows that readers are interested in it? Can you think of anything -- anything at all -- that might serve as an alternate explanation? I'm just saying. --Guy Macon (talk) 23:09, 11 April 2018 (UTC)[reply]
The list of main page stats below shows that the link free got over 100K views and that most of the portals got even more traffic. This is good evidence of significant usage. Q.E.D.. Andrew D. (talk) 07:22, 13 April 2018 (UTC)[reply]
  • Support Pretty much useless now, per all the above comments. Lugnuts Fire Walk with Me 07:08, 9 April 2018 (UTC)[reply]
  • Selective support: The prominent Main Page link to a set of fragmented and often outdated resources is inappropriate and should be removed. I would support marking each Portal pages itself with Template:Historical but with any Wikiproject which links to that Portal notified so that they can remove the template if their consensus is that the Portal is active. Any Portal which Projects instead consider so poor as to merit removal can be so requested, presumably via WP:MFD. In 12-18 months time, any "orphaned" historical portals can be checked for usage volumes and considered for MFD. AllyD (talk) 07:44, 9 April 2018 (UTC)[reply]
  • Keep some portals including but not limited to the eight linked from the main page, continue maintaining them, and delete the rest. I think there is still some merit to maintaining a few portals about more basic topics, and a number of featured portals still receive a healthy amount of page views, so people are still using them. Portals are prettier than outlines and still serve a limited purpose, IMO. Decreasing the number of portals maintained may be a way forward for them. feminist (talk) 08:15, 9 April 2018 (UTC)[reply]
  • Support. I've done in a distant past a lot of work on two portals (Portal:Belgium, 29 views a day, and Portal:Comics, 47 views a day), and in retrospect it was way too much effort for very little effect compared to article building / maintenance. I no longer see any benefit in having portals on enwiki. Fram (talk) 08:26, 9 April 2018 (UTC)[reply]
But that's still 10,585 and 17,155 people a year respectively who have an opportunity to discover, if they so wish, new topics and sample selected encyclopaedic information in a different way to normal, without having to wade through a lengthy and maybe dull-looking article. Yes, numbers are low on the scheme of things, but there are innumerable Featured Articles like this and this that get less traffic. Shall we delete all low-traffic pages next because they don't attract enough people? The logic makes no sense. Delete a rubbish page because it's flawed and can't be fixed, for sure. But all 1500 Portals (assuming just 50 visitors a day each) still amounts to 27.6 million people a year not having an opportunity to see or discover a broad sample of articles relevant to a topic, usually in a bright, uncomplicated manner, and possibly being enthused enough to learn and study that topic in a way that might even change their direction in life. Why take that away? Nick Moyes (talk) 03:02, 12 April 2018 (UTC)[reply]
  • Oppose I watch and edit two portals, Portal:Germany and Portal:Opera, both featured portals, and up-to-date, - why change? --Gerda Arendt (talk) 09:46, 9 April 2018 (UTC)[reply]
    While you maintain the portals, there may be some point. But the problem is that portals don't continue to be maintained, as noted repeatedly above. Note also that the Germany portal gets less than 1% of the number of views that Germany does. So the value to readers in relation to the work required by editors is grossly disproportionate. Peter coxhead (talk) 10:20, 9 April 2018 (UTC)[reply]
I am not alone, maintaining takes me 3 minutes on days that have DYK related to Germany. It takes someone else 3 minutes to update the news. Why not? To compare portal and country is like apples and pears, - where on the country article would a reader get news and DYK? Some hundred look per day, enough for me to invest 3 minutes now and then. --Gerda Arendt (talk) 12:30, 11 April 2018 (UTC)[reply]
  • Support They are dead (as a whole). Let's do the honours. Although I would not cry my eyes out at the sight of their deletion, I would find it disrespectful for them to be deleted -- mark as {{historical}}. talk to !dave 10:45, 9 April 2018 (UTC)[reply]
  • Support not updated, old, hardly viewed, and not a central part of our mission.--Tom (LT) (talk) 11:00, 9 April 2018 (UTC)[reply]
  • Oppose as written, but would Support a purge of some poor portals. -- Iazyges Consermonor Opus meum 13:15, 9 April 2018 (UTC)[reply]
  • Oppose to Strong Oppose - although many support arguments appear to have quite rational argumentation - It is bit like some who cannot cope with having projects on talk pages - project tags help the process of evaluation - the linked nature of things seems to be lost on most above. Portals can have moribund content and appearance but they are excellent links to a more complex process - where latin names of phenomenon have category pages with no attempt at explaining as to whether they are rock, plant or animal - portal links are useful to clarify the context of many pages in complex category trees that are otherwise too labyrinthian for the average user. Portals are useful, but for whatever reason, those who visit seem to think otherwise, a small problem with dismantling parts of a structure, what is suggested next? Take care with such a suggestion, I would suggest threshold of this argument needs to be considered very carefully. JarrahTree 13:38, 9 April 2018 (UTC)[reply]
Can you give an example of such a latin name category page and how a reader might arrive there without knowing whether it's about rocks/plants/animals? As an editor (when fixing categorization problems) I wouldn't rely on the portal link being correct. DexDor (talk) 21:03, 9 April 2018 (UTC)[reply]
reply to DexDor - having been through birds, and other category page main spacetagging - I believe that some indication on a category page reduces potential confusion as there some binomial latin phrases could be a plant or a bird. I have not found deliberate or accidental project mis-tagging. JarrahTree 09:11, 12 April 2018 (UTC)[reply]
  • Support I think the efforts expended in maintaining them can be better used elesewhere. S a g a C i t y (talk) 16:25, 9 April 2018 (UTC)[reply]
  • Oppose If the proposal here is broad deletion of all, that can and will only end in a mess (see this, followed by this, followed by this this) - extensive one fell swoop, hacking away of multiple pages just is bad for the project, and we do it badly. Some pedians have expressed interest in some of these even in this discussion (over many years) - so, I support those pedians -- I also might support things like removal of links from the Main Page, etc. but I cannot support this. Alanscottwalker (talk) 18:26, 14 April 2018 (UTC) Adding, I agree with User:Kmhkmh, below, we don't delete pages that don't get many views, we don't delete pages that don't get many edits (besides, here once the page is set-up, there are many that don't need a bunch of edits -- once a page is complete, it's complete) and we especially don't delete pages, because 'someone else works on them but not me'. Alanscottwalker (talk) 13:52, 11 April 2018 (UTC) See, WP:NEGLECT, WP:NOBODYREADSIT and WP:IDONTLIKEIT, showing the invalidity of the delete arguments -- adding, that never in Wikipedia history has there been mass deletion like this because it runs afoul Wikipedia:Editing policy. -- Alanscottwalker (talk) 10:41, 12 April 2018 (UTC)[reply]
  • Support Outline articles are more efficient. Would not oppose some method of archival for portals that have been maintained up until at least the past month and archival with deactivation for those maintained up until a year ago, but definitely deletion for those that haven't been maintained in over a year. Ian.thomson (talk) 17:26, 9 April 2018 (UTC) Edit: Broter has (perhaps inadvertantly) provided good evidence that selective action (deleting some but not others) would result in increased bias in the portal area. Whatever action is taken (be it deletion or archival) should be unilateral and affect all portals in an identical manner. Ian.thomson (talk) 20:14, 9 April 2018 (UTC)[reply]
  • Support, they are obsolete, and most are not maintained. Side bars and end bars provide a similar service and do a better job at it. Kierzek (talk) 17:58, 9 April 2018 (UTC)[reply]
  • Support. Portals are largely unviewed and unmaintained. I do think they should be marked as historical rather than deleted outright (though deletion should be an option in some cases). Plantdrew (talk) 19:08, 9 April 2018 (UTC)[reply]
  • Support per Axisixa. Portals (operating like topical main pages) make sense when you have a group of editors (like a WikiProject) actively curating them. The portals (like the Main Page) aren't configured to be static. Because of that, their utility degrades over time and deletion makes sense when they aren't being updated. Maybe if the WMF had done more to retain our "wild west" editors from 2005-2008, we wouldn't be short-staffed and deprecating stuff now. Chris Troutman (talk) 20:24, 9 April 2018 (UTC)[reply]
  • Oppose We shouldn't be deleting pages because (i) they don't receive many page views, or (ii) they haven't been well maintained. How do readers benefit from this proposal? Some readers must find portals useful, and this proposal seems like the wrong solution to specified issues. PaleCloudedWhite (talk) 20:51, 9 April 2018 (UTC)[reply]
    • PaleCloudedWhite, what's your basis for believing that they are useful to some readers? (The mere fact that people sometimes click on them isn't enough, since you click before you know whether the page will be useful to you.) Is there a particular type of reader that you think they'll be more useful to? WhatamIdoing (talk) 05:05, 10 April 2018 (UTC)[reply]
      • And what is the basis for people's assertions that they are not of any use to readers? Do the same editors make such assertions about particular articles, and that therefore they also should be deleted? PaleCloudedWhite (talk) 06:41, 10 April 2018 (UTC)[reply]
        The incredibly low readership of portals - even the 8 linked off the top of the mainpage - proves they are not useful to readers who vote with their clicks. Also every person voting here is a reader too and I've yet to see anyone really say they use portals. The objections are around preserving history or some useful bits or not offending the creators. Legacypac (talk) 06:51, 10 April 2018 (UTC)[reply]
        Portal:Christianity has received an average of 139 pageviews per day over the last 90 days - is that an incredibly low figure? Of all the articles that I've created, the most read is Dark Hedges, which over the same period has received an average of 119 pageviews per day.[11] Obviously Dark Hedges is useless to readers too and should be deleted, along with all the other articles that I have created, as they have even less readership. I am reminded of David Attenborough's comment on public service broadcasting, which he said should "cater for the broadest possible range of interests, popular as well as less popular, a network that measures its success not only by its audience size but by the range of its schedule". PaleCloudedWhite (talk) 07:05, 10 April 2018 (UTC)[reply]
        Thank-you for that comparison as it should help you understand my point and might make you change your vote. 119 pages a day for page with 16 inbound wikilinks about a row of trees is impressive (and an impressive article). We don't need to delete Dark Hedges because it is meeting a need. 139 views a day on Portal:Christianity is indeed incredibly low given it is an an extremely important topic of global interest where the portal is wikilinked from a HUGE number of pages (I gave up counting at around 30,000 page). There are so many ways to get to Portal:Christianity that 139 views a day could be mostly bots and accidental clicks. Legacypac (talk) 07:43, 10 April 2018 (UTC)[reply]
        And my point is that we should not be deleting pages based on pageviews, nor using pageviews as a basis for how useful a page is (unless, perhaps, it always receives zero). PaleCloudedWhite (talk) 07:58, 10 April 2018 (UTC)[reply]
      • PaleCloudedWhite, you said that "some readers must find portals useful". I am therefore asking: Do you use portals? Do you know anyone who does? Can you think of a hypothetical scenario in which a portal would be particularly useful for some reader? Perhaps a situation in which you personally would bypass other alternatives (search, navboxes, see also, links, etc.) and head straight to the portal? I know why the critics think that portals are not useful (critics look at the low page views, and conclude that if portals with tens of thousands of links on hundreds of articles are attracting such low interest, then realistically, some people are looking at them but nobody's finding them useful enough to seek them out.) The critics may not be correct, but it is a reasonable belief. I want to know why you believe that "some readers must find portals useful". Let's say, arguendo, you're absolutely correct. Let's say that there really are some readers who use them, and let's say that portals really are useful to those readers. Now, which readers are using them, and how are portals useful to them? If we can identify a plausible scenario, some sort of user story, then that might change people's minds about deleting them. Otherwise, I think this type of claim is going to be rejected as motivated thinking (e.g., "I spent a hundred hours on portals, so it can't just be wasted effort. It just can't!"). WhatamIdoing (talk) 15:26, 10 April 2018 (UTC)[reply]
        Your last point does not apply to me because I haven't invested time in editing portals. I made the statement about some readers finding portals useful in response to statements higher up the page stating that they are useless. People cannot make such statements; there is no factual foundation. The WMF, as far as I'm aware, has not conducted in-depth market research on how portals may or may not be used by readers, but we do have pageviews showing that some are read at least as much as many articles. That does not quantify to what extent they are useful, nor in what way, but it does establish that they are used. It's really a rather narrow way of looking at something to say, as some have here, 'I haven't read them or edited them much, therefore get rid of them'. I do not look at portals as navigation aids, rather I see them more like the random article feature - showing readers something that they weren't necessarily looking for - but in a more topic-orientated way. If they aren't performing as well as they might, perhaps some thought should be given as to how to improve them and/or give them better functionality. Leaping straight to deletion seems wholly the wrong way to go about this. PaleCloudedWhite (talk) 19:49, 10 April 2018 (UTC)[reply]
        Okay, so I'm understanding that you personally don't use them or know anyone who uses them, I don't use them or know anyone who uses them, and nobody in this discussion seems to use them or know anyone who uses them. We also know that portals get remarkably few page views per link. Portal:Food, for example, is linked on more than 8,000 articles, and it gets a mere 400 page views per day. The article on Food, by contrast, is linked on only a third as many articles, but it gets about seven times as many page views. On a view-per-link basis, the encyclopedia article is 20 times more desired by readers than the portal. That limited popularity suggests that portals are not actually "useful to readers". Maybe they could be – I'd personally be happy to find something that worked for readers, and mw:Extension:RelatedArticles might be one option to consider – but the long-term lack of use, in the face of such heavy "advertising" in articles, suggests that portals (as they currently exist) do not seem to be useful to readers (including for entertainment utility). WhatamIdoing (talk) 15:14, 11 April 2018 (UTC)[reply]
        We have pageviews that show that people visit portals - that is the only concrete information we have. Everything else is unproveable assumptions, which are not adequate basis for deleting a section of the encyclopedia. So what if Portal:Food gets less visits than Food? It doesn't get zero views. Editors could reasonably have a discussion about why a page might receive less pageviews than another, but it is reckless to use such comparisons as a basis for deletion. PaleCloudedWhite (talk) 08:02, 12 April 2018 (UTC)[reply]
  • Oppose Most of the Wikipedia hasn't been well maintained. I don't see how mass deletion of content benefits the project. Hawkeye7 (discuss) 21:00, 9 April 2018 (UTC)[reply]
    It seems that any collection of pages will now be subject to deletion. Hawkeye7 (discuss) 07:35, 10 April 2018 (UTC)[reply]
    @Hawkeye7: Are there any reasons other than mass deletion for which you're opposing? Much of the other editors here (including myself) support only the deprecation of portals, not outright deletion, so I politely ask you to either change or justify your vote. ToThAc (talk) 18:15, 10 April 2018 (UTC)[reply]
    That is not the consensus. And it's the people who haven't been here for over ten years and haven't done any work on portals but still post cursory support votes who need to justify why their comments should not be stricken. Hawkeye7 (discuss) 23:51, 10 April 2018 (UTC)[reply]
    1. There is a mechanism for the deletion of portals, and that is WP:MfD. This is a deliberate attempt to do an end run around our processes, and for a reason: none of the arguments advanced here would be acceptable at MfD. ie WP:NEGLECT, WP:NOBODYREADSIT and WP:IDONTLIKEIT. Could the portals benefit from more automation? Certainly. Is that a reason to delete anything at all? No.
    2. The proposal violates our first pillar, that Wikipedia is an encyclopaedia. It is not enough that information be listed. It has to be organised as well. That is why we have portals and, less usefully, categories.
    3. When writing articles, content creators often focus on a whole series of articles on a particular subject area. Portals and topics are often the locus or goal of such efforts. Hawkeye7 (discuss) 05:35, 12 April 2018 (UTC)[reply]
    Can you clarify what you mean by "mass deletion of content"? Portals mostly consist of just a copy (possibly out of date and copied without attribution) of the lede of an article surrounded by some pretty formatting and links. Hence, deleting a portal doesn't delete encyclopedia content (facts that are of use/interest to readers). DexDor (talk) 20:02, 10 April 2018 (UTC)[reply]
    That's not true. The attribution to the original article is clear, just as it is in TFA. Attribution is required when you're copying a block of text from one article to another. The portals are encyclopaedic content, there's a lot more involved than you think, and the reasons given, ie low traffic and lack of maintenance apply to most of the encyclopaedia and are not valid grounds for mass deletion of content. What value is there in contributing articles under such a regime? Hawkeye7 (discuss) 23:51, 10 April 2018 (UTC)[reply]
  • Support. It seems that better systems of directing users around has become the norm and in falling out of use they have become stagnant. Even looking at Portal:Arts the most highly trafficked portal (due to a link on the main page), it appears to have almost no editor activity (edited twice in 5 months). I'd support removing all mainspace links and adding a historical template to all of the portal pages as a good compromise (preferred choice). — Insertcleverphrasehere (or here) 21:33, 9 April 2018 (UTC)[reply]
  • Support - I checked my edit pie chart & in my 12 yrs on the 'pedia, I've made only 5 edits (2 on main, 3 on talk) to portals. They're basically obsolete & need to be made historical. GoodDay (talk) 21:49, 9 April 2018 (UTC)[reply]
  • Oppose - the portal system would greatly benefit from some sort if integration with the main article space to draw more attention to it from readers and editors. Perhaps, every article linked from a Portal page should have a link back to the Portal displayed automatically. We should also move Main_Page to the Portal: namespace. Its hard to convince people to use Portals when such a visible portal page still hasn't moved there yet. -- Netoholic @ 22:58, 9 April 2018 (UTC)[reply]
  • Support a transition to deprecation. Do not delete anything, they are project history, there may be value in the history. Instead, for each moribund Wikiproject, redirect to the parent article. Exactly as I argue at Wikipedia_talk:Portal#Portals_are_moribund. In short, they are near useless, they are out of date and misleading for people who find them, and they are near worthless time sinks for an editor who feels the desire to update them. Do no merge with WikiProject, most WikiProjects are barely active themselves. User:Abyssal and User:The Transhumanist would like to create an automatically generated indexing/outline and summary system - that would be great, but is not a reason to not deprecate the current form of portals. --SmokeyJoe (talk) 22:59, 9 April 2018 (UTC)[reply]
Deprecating and marking historical would allow anything of value to be harvested by active Wikiprojects, or by others outside Wikipedia who may be inspired to create something better, etc. Also, there are design element in these that may be useful to know about. And the wikimarkup and formatting may be useful for some. I cut my page formatting teeth on portals.     — The Transhumanist    12:43, 11 April 2018 (UTC)[reply]
  • Merge to WikiProjects instead of deleting. Why: There's helpful content in Portals for content organizers, and for readers, and the contents in Portals can often bridge the two groups. E.g. Portal:Mathematics contains some content/structure that is not reflected in either Wikipedia:WikiProject Mathematics nor in Mathematics nor in Template:Areas of mathematics. How: Perhaps we could have a deadline for portal-deprecation, with prominent notices given that all content should be merged before date. After that date, portal namespace could be redirected and frozen, or marked {{historical}} in a unique way. I oppose deletion of the portals and their talkpages. I support removing the 8 big ones from the Main Page, and support redirecting editor energy towards revitalizing WikiProject pages instead of building/maintaining Portals. Quiddity (talk) 00:13, 10 April 2018 (UTC)[reply]
    • Quiddity, may I assume that this would happen only after asking the Wikiprojects and getting a positive response? Some Wikiprojects get a bit annoyed when someone messes with their space, an many other Wikiprojects are completely abandon and have nobody to either give permission or raise an objection. --Guy Macon (talk) 21:54, 10 April 2018 (UTC)[reply]
  • Support. I like the idea of portals, but their execution leaves something to be desired. My main project has a portal that went through the FPo process a few years ago (P:USRD) and now there's really only one editor maintaining it on a regular basis. I agree with some of the others that the content should be merged into the WikiProjects and not deleted outright. –Fredddie 00:20, 10 April 2018 (UTC)[reply]
  • Strong support – I am glad someone did this RFC. I had been thinking for a while and mentioning to editors offsite my opinion about how outdated the concept of Portals were. I used to upkeep two myself, I even have a featured portal. However, in this day and age, I am more the person who wants them to stay but marked historic. They were a nice idea 10 years ago, but really, people can find articles one way or another without a portal. Mitch32(My ambition is to hit .400 and talk 1.000.) 00:59, 10 April 2018 (UTC)[reply]
  • Support As someone who dabbled a few times in creating portals that didn't seem to stick, I think it would be best to merge useful content into project pages and not leave it to rot away in a forgotten namespace. SounderBruce 01:03, 10 April 2018 (UTC)[reply]
  • Oppose in favor of technical overhaul. Specifically, I would like to see a portal system with:
  1. The automatic production of article synopses of the appropriate length when articles relevant to the portal topic are accepted and the ability to edit these synopses if they need improvement.
  2. The automatic addition of these synopses to the pool from which the portal draws its content selections.
  3. The ability to sort or filter the article synopses on the "more articles" page (or "more pictures", "more DYKs").
  4. The criteria portals use to select content should default to chronological rather than random (ie it shows the last article to be featured in that subject).
  5. The automatic addition of DYK hooks after they've been displayed on the Main Page to the pool from which the portal draws its DYK selections.
  6. The automatic addition to the portal's content pool of featured and quality images when they get promoted at Wikimedia Commons.
  7. The automatic generation of an image summary for the featured pictures based on their synopsis at the Commons, but with the ability to edit and improve it if needed.
  8. The ability to automatically pull pictures from DYK articles to be associated with their hooks on the portal.
  9. The ability to randomize all of the individual DYK hooks instead of manually devising "blocks" of hooks.
  10. An automatically generated list of new and recently expanded articles relevant to the subject.
  11. Foundation sanction for direct outreach by Wikiprojects to portal-goers like offering topical reference desks, advertising within-project contests, user adoption drives, etc.
Sorry for the textwall, I just thought it was worth noting that the pro-portal camp has put forth a concrete plan for reform and I think implementing these changes would address most of the ccomplaints people have about our currently busted system. Abyssal (talk) 01:35, 10 April 2018 (UTC)[reply]
  • Oppose. (edit conflict) There are portals that are still well-maintained. I like the idea of tagging unmaintained, out-of-date portals with a one-week deletion notice that flags the creator and the associated WikiProject(s) to either save it or let it be deleted. Project members should be allowed to extend the one-week period if editors are in an ongoing discussion about it. Maybe have a WP:Pfd page where portals can be proposed for discussion/deletion? Frankly, I'm surprised at all the support this RfC gets. What's next? Will someone come up with a case to delete little-viewed categories? or low-pageview articles? How about unused helpspace redirects to projectspace? Where does all of this end, and how much of it is due to an objectionable level of deletionism?  Paine Ellsworth  put'r there  01:46, 10 April 2018 (UTC)[reply]
  • Support. Move all portals into Wikipedia namespace and mark them as historical. Lojbanist remove cattle from stage 03:17, 10 April 2018 (UTC)[reply]
  • Weak Oppose per Paine Ellsworth. I've not edited any portals except for italic runs, so they're not an area I work in. But it's odd that this discussion is taking place without alerting every portal's talk page (my apologies if they have been alerted) as well as giving a good notice on Wales' talk page (and again, apologies if it has, I'm not a constant lurker there). This is a major move, to wipe out an entire sub-culture of Wikipedia. Paine comes up with some good "way to go forward"ness. As for his concerns, I have seen, with my own eyes, editors actually contemplating if navboxes (I call them templates) should be removed from the project. They already are banned from the mobile edition of Wikipedia. Lots of us love navboxes, they are the maps of Wikipedia. To create or add to a well-designed topic map feels like artwork. But since navboxes are already banned for 50% or our reader-views, maybe it won't take much to push them over the side. Is that what comes next? As I said, portals are not my thing here, so I don't know the level of work and care that has been put into them. Probably a lot, I'd guess. So this move is pretty major, either way it goes down, which is why every portal talk page should be alerted, so active editors know about it (I mentioned it in a move review and I think, judging from the recent comments to this discussion, that that mention at that move review alerted quite a few active editors that this discussion was going on, let alone that they'd have a chance to read six "that's" in one sentence). This major discussion is likely not very well known in the community. Randy Kryn (talk) 04:10, 10 April 2018 (UTC)[reply]
  • Support removing the portal links from the Main Page as soon as reasonably possible. I generally support deprecating the portal system, but I think this needs to be a slow, structured process that is developed outside this one-time discussion. There are multiple things that need to be done (e.g., stop making new ones; remove bad ones; re-work supported ones in the mainspace; consider alternatives; stop advertising/linking to them; possibly someday deleting them), and I think that process and an approximate timeline needs to be worked out by a small group of people willing to do the work, rather than being set in stone a single large discussion such as this one. Our goal right now should be setting the direction and some basic parameters. WhatamIdoing (talk) 05:19, 10 April 2018 (UTC)[reply]
  • Support and replace the Main Page links with the corresponding outlines (or how about something completely new and refreshing in the top-right?). Portal space is dusty and fairly dead. The few people who continue to maintain portals could refocus their efforts on other navigational systems, such as navboxes, sidebars, outline pages, and categories. — This, that and the other (talk) 06:18, 10 April 2018 (UTC)[reply]
  • Oppose. I agree with some of the descriptive claims of the supporters. It's true, for example, that I hardly ever edit or use the portals, and I often forget they're even there. But glancing around at a few of them, I don't agree that they're useless — they're a nice way of gathering together related material in a way that catches the eye and sparks interest. It's not a good argument that there are POV problems; there can be POV problems anywhere. --Trovatore (talk) 07:04, 10 April 2018 (UTC)[reply]
  • Support Like many above, I have very rarely edited in the portal space. They have not served their intended purpose many are completely out of the date. It is time to close the book on this chapter of Wikipedia. Prefer the history is maintained and mark as historical rather than delete though. Cheers – Ianblair23 (talk) 08:16, 10 April 2018 (UTC)[reply]
  • Support. The entire idea appears to have been abandoned. Without editor engagement, the portals serve little useful purpose. Sandstein 10:28, 10 April 2018 (UTC)[reply]
  • Support Not useful and distract from work that is useful. I think the portal-linking templates that litter the bottoms of articles should be deleted, as well as the links from the main page. Wholesale deletion of the portal pages themselves might be too demoralizing for the editors who created them. Calliopejen1 (talk) 12:18, 10 April 2018 (UTC)[reply]
  • Support: Redundant with both regular articles and categories which can provide better content and navigation. However, I also support the condition that, should this proposal pass, all portal pages be tagged with {{historical}} instead of being deleted. ToThAc (talk) 18:08, 10 April 2018 (UTC)[reply]
  • Support: I made a proposal to redesign portals, but that's up for a potential eventual return to the concept, if it is accepted. I agree that the portal system, as it is nowadays, does not work and needs to go. However, as requested by others, you should either make portals historical, or give a deadline before deletion. Cambalachero (talk) 19:18, 10 April 2018 (UTC)[reply]
  • deprecate and mark as historical. I have been worked on them in small ways, but they do seem moribund now. I would guess the deep linking of search engines is to blame, taking people directly to articles. Also WP is no longer new, and both editors and readers know their way around much better. So I support removing links to them, but they should be kept, as a record of the work on them, and in case anyone one day thinks of a use for them. Maybe one day when WP is lauched on a new medium it needs a totally new front end, and they may come in useful for such.--JohnBlackburnewordsdeeds 20:25, 10 April 2018 (UTC)[reply]
  • Oppose. In case of discontinue, existing portals should be preserved.  samee  converse  21:17, 10 April 2018 (UTC)[reply]
  • Oppose – There are definitely useful portals on Wikipedia (even if the daily pageviews are only in the hundreds), and even if they are preserved outside a reader-viewable space, they will be made useless even if previously useful and often-updated. Yes, there are many, many useless and deletion-worthy portals of Wikipedia, but there should have been a much larger pre-RfC discussion to consider various approaches to reform (and I do not think this discussion is large or public enough to fit that bill) prior to this proposal of outright abolition given above. Master of Time (talk) 21:28, 10 April 2018 (UTC)[reply]
  • Support, never really took off, and in recent years they've faded almost totally into obscurity. Many of the opposing comments cite the large amount of time people have spent working on portals, which to me is if anything more reason to scrap them... imagine how much better the encyclopedia would be if all that time was spent actually improving articles! Andrew Lenahan - Starblind 21:59, 10 April 2018 (UTC)[reply]
  • Oppose outright deletion. Support marking most of them as historical, similar to inactive projects and other previous good-faith contributions that just no longer work in practise. And as Andrew D.'s numbers below seem to indicate, there is still substantial viewer interest in some of these portals. GermanJoe (talk) 23:45, 10 April 2018 (UTC)[reply]
    • We may be confusing cause and effect here. Is the substantial viewer interest because they are useful, or because they are linked from the main page? Would a link with the same link text to an "overview of" page get any less viewer interest? --Guy Macon (talk) 23:57, 10 April 2018 (UTC)[reply]
  • Support - Most portals are not much of use, as many take too many clicks to access, or so inaccessible that most readers would've found what they have been looking for before seeking the portal. Outside the ten portals linked on the main page, the namespace rarely gets views. I would support marking them as historical, or automate them so it would be low-maintenance. Merging them into WikiProjects is also a good idea.Nova Crystallis (Talk) 00:18, 11 April 2018 (UTC)[reply]
  • Strong Oppose This proposal takes deletionism to new levels. It's equivalent to a mass AFC without any communication to the Portals themselves. This wouldn't even happen to an individual article at AFD. There is already a Guideline and a mechanism for the removal of any Portal that's deemed poor or irrelevant. It's at WP:MFD, and that is the route we should follow, not out and out extermination because editors don't like or don't use Portals, or feel nobody else does either. Admittedly, traffic is not high to many, but using page visitor figures as a guide in deciding whether an entire namespace should be deleted seems to go against our principles of access to information. It's as senseless as proposing that all articles with less than a certain visitor count should also be deleted en masse. Many Portals are linked directly from WikiProjects,some of whcih also have low visitor figures. Shall we delete these all, too, whilst we're about it? Just as there are many ways for newcomers to a library to access its content, so Portals offer one alternative route, and often quite a visual selection of introductory topics, giving a look into a broad subject in a way that a dull template at the foot of a page simply doesn't. To be brutally frank, until this RfC I'd never even noticed there were links to Portals from the top of our Main Page. (My eye never wanders up to these banners.) But if content deletion is based on disinterest and low visitor counts from the Main Page, then we should delete Wikipedia:Local Embassy - linked to from the centre of our Main Page, but with visitor counts far lower than each of the linked Portals. If individual Portals are seen as worthless, they should either be flagged as {{historic}}, or put up for a deletion discussion. At the time the 'Featured Portal' scheme was ended in 2017 there were 176 such Featured pages. They can't all suddenly be worthy of mass deletion! Nick Moyes (talk) 00:49, 11 April 2018 (UTC)[reply]
  • Support. The lack of active maintenance and editor involvement is problematic in some ways beyond merely keeping things up-to-date. There's a small enough community, making few enough edits, that it becomes possible for one editor to create and maintain a topic portal without any meaningful oversight—which leads to potentially serious NPOV issues. Creating a portal allows someone who is careless or unscrupulous to create a content fork, subtly (or not-so-subtly) shifting the tone and emphasis – or even substance – of Wikipedia's presentation of a topic. (And arguing that that's not really a serious problem because so few readers see the Portal pages doesn't really help matters.) TenOfAllTrades(talk) 00:57, 11 April 2018 (UTC)[reply]
  • Support, for many of the same reasons as the above. My opinion of what should happen: These pages are moved to WP space (WP:Portal/Science) and tagged historical. The portal namespace is summarily removed from the database. --Izno (talk) 02:52, 11 April 2018 (UTC)[reply]
  • Support – but what will happen to actually useful portals, such as Portal: Current events?  Nixinova  T  C  04:33, 11 April 2018 (UTC)[reply]
  • @Nixinova: It would be deleted per the argument below that this proposal does not go into detail. - Knowledgekid87 (talk) 13:29, 12 April 2018 (UTC)[reply]
No, any competent closer will see the lack of support for their deletion or marking historical - rfc outcomes don't have to match the original wording and can exclude those specific portals. Galobtter (pingó mió) 13:32, 12 April 2018 (UTC)[reply]
I'm sure you have realized by now that you dove headfirst into a huge issue here. It concerns me a bit that you didn't offer up a proposal on what to do if the portals are deleted, there are also other things that editors have pointed out. Are you going to leave this up to the closer on what should or shouldn't be marked as historical? - Knowledgekid87 (talk) 13:51, 12 April 2018 (UTC)[reply]
  • Strong support. While it was created with good intentions (i.e. to be a "Main page" of each subject), it is no longer practical to maintain the same due to lack of interest altogether. Rehman 07:20, 11 April 2018 (UTC)[reply]
  • Weak Support Major ones should be kept. Bobherry Talk Edits 04:18, 14 April 2018 (UTC)[reply]
  • Detailed proposals needed - it is clear that there is support to make drastic and sweeping changes to the portals system and namespace. What is not clear is the way to do this. This is a massive undertaking that risks causing a lot of disruption to existing infrastructure if not done carefully. I would favour marking such pages as historical, rather than outright deletion (moving pages to WikiProject namespaces is another option, but what if more than one WikiProject have a claim on a portal?). Marking historical retains a record of the contributions made (would removing the portal namespace entirely remove all record of an editor's contributions to that namespace?) and maintains a historical record of the pages. It would also retain the featured portals, which would be a great pity to lose. The point that there should be a deletion notice on each page is also a good one, and that any hard deletion should be done through Miscellany for deletion. It also feels like such a drastic proposal as doing away with an entire namespace needs a series of proposals and RfCs, running for some time and with much publicity to ensure everyone who should get a chance to speak up is afforded that opportunity, and that the whole editing community is notified about the proposed change. Carcharoth (talk) 10:54, 11 April 2018 (UTC)[reply]
    • Oppose the proposal as currently stated, mainly because of the number of opposes that have been made since the tagging of the portals for deletion was carried out (as should have been done in the first place) which appears to have drawn a number of people to this discussion to oppose the proposal. It is clear that there are a group of editors who work on some portals and maintain them; deleting the whole namespace rides roughshod over the work that has been done and is still being done in this namespace. Propose reforms, and selectively nominate some portals for deletion at MfD using certain criteria, and mark some historical (maybe even be WP:BOLD and mark inactive portals as historical without any discussion) but at present this proposal is an end-run around the deletion process. Carcharoth (talk) 09:53, 12 April 2018 (UTC)[reply]
  • Oppose: Portals are what we Indian cinema editors have been using to categorise the various GAs, FAs and FLs on the basis of language and industry. This because WP:ICTF is one convoluted task force and no-one supports the creation of multiple taskforces for each Indian film industry. --Kailash29792 (talk) 11:35, 11 April 2018 (UTC)[reply]
  • Comment. I have not voted in this RfC because I have no firm opinion either way. All I can say is that the portals don't take up any space on the server. That said, the proof of concept as demonstrated in this RfC seems to reflect a consensus that the community want portals deprecated. The actual process would be complex as illustrated by Carcharoth. Is it worth the effort?Kudpung กุดผึ้ง (talk) 11:39, 11 April 2018 (UTC)[reply]
    • As far as I can tell, the placing of a notification tag on all existing portals seems to have only just been done today by The Transhumanist (maybe they could confirm?). Any timings for how long this RfC should run for should take that into account. My gut feeling is that moving the pages to WikiProject space is a waste of effort. Better to mark historical and let individual editors and Wikiprojects move what they want to keep. It is trivial (using the same templates and transclusions) to replicate portals in the Wikipedia namespace for those who want to keep something going at a WikiProject or User namespace level. All that is really needed is to remove links from the article namespace to the deprecated portals. Those who keep working on updated navigational content (where ever it is hosted) will add back in links as needed, and the normal editing process takes over from that point (is it useful to readers of the articles, etc.). I shouldn't really start threaded discussion here, feel free to move if needed. Carcharoth (talk) 11:56, 11 April 2018 (UTC)[reply]
    • Reply: I placed a notice to this effect at the top of this proposal.     — The Transhumanist    12:05, 11 April 2018 (UTC)[reply]
  • Support. Content should, were applicable, be moved to WikiProjects, templates, article content, etc. Chicbyaccident (talk) 11:46, 11 April 2018 (UTC)[reply]
  • Oppose A Portal is no project, projects should support Portals in creating new content. You always find new articles in the portals. Portals provide overview.--NezLe (talk) 11:50, 11 April 2018 (UTC)[reply]
I don't agree that you always find new content in some Portals, but that's not even relevant. But you are right to say they provide an overview - a different way in to a topic if you like. Having provided a taster of articles across a broad sectrum, like many articles here they do not need much modification. If we were to take the approach being proposed here, we would soon be mass deleting every article that hasn't been edited for a year or so and which receives under some unspecified number of visitors per day. How demoralising to all users. I also agree with you that WikiProjects could/should be supporting Portals more - and many are very closely linked - but they are entirely different beasts, and both have their very distinct value in my view. Nick Moyes (talk) 16:48, 11 April 2018 (UTC)[reply]
  • Oppose - I find portals useful and a net positive to Wikipedia. No doubt they can be improved, but this proposal is throwing out the baby with the bath water. I also agree with those pointing out the flaws in notifications regarding this proposal. Jusdafax (talk) 11:57, 11 April 2018 (UTC)[reply]
  • Oppose as they are the best grouping of related articles that exist, far better for readers than books, categories, WikiProjects, or any other groupings. ɱ (talk) · vbm · coi) 12:08, 11 April 2018 (UTC)[reply]
  • Oppose. Nasty little RFC, this. Oppose wholesale removal or deprecating of entire portal system and favor case-by-case review, per Nick Moyes. Full disclosure: I have worked on Portal:Mathematics content quite a bit in the past. As noted by Andrew D., that portal is not per se out of date, as Portal:Cricket is claimed to be. If a particular portal sucks, improve it or get rid of it, using existing procedures (including proper notice to the portal's talk page). If a portal is well constructed, leave it alone (well… or improve it further, like anything else). If this results in some sort of imbalance, as mentioned above (can't find the exact comment at the moment), then fine, remove the Main Page links (although, of course, that should be discussed on Talk:Main Page and not be decided here). Automation ideas of Abyssal are interesting and should be considered by interested parties. Finally, I think this RFC has been mishandled from the beginning, as apparently none of the portals themselves were notified (on their talk pages) about this until 2 or 3 days into the discussion (and Portal:Society, linked to from the Main Page, still hasn't been notified [edit: was done shortly before I posted my comment]). The propsal as stated seems to me to be (frankly) outrageously overbroad and should not be taken seriously (much less agreed to) until other avenues for improvement (as just mentioned) have been pursued. - dcljr (talk) 12:10, 11 April 2018 (UTC)[reply]
  • Support with caution. The vast majority are stale, and any that are being kept up to date should be migrated to e.g. a relevant WikiProject. Stifle (talk) 12:17, 11 April 2018 (UTC)[reply]
  • Oppose I'm shocked this is even being considered! I'm even more shocked that there seems to be a number of editors that support it. My first caution: don't let a large number of people automatically be considered the consensus. I check Wikipedia multiple times a day and just heard of this proposal this morning. Notification to such a wide base of editors will take some time. In any event, portals are useful and helpful for navigation, provide an outlet for enthusiastic editors to promote their favorite subjects, encourage collaboration between editors, expand Wikipedia with distinct layout and design, and are an excellent source. The argument that many portals are out of date is a sign that we need to have a campaign to update the portals, not delete them--which is my second caution: don't confuse an editing issue with a deletion issue. The solution here lies in editing, not deletion.--Paul McDonald (talk) 12:25, 11 April 2018 (UTC)[reply]
  • Support Article pages function as the default "portal" for article topics on Wikipedia. Existing content on portals should, where applicable, be moved to WikiProjects, templates, article content, etc. Mitchumch (talk) 12:31, 11 April 2018 (UTC)[reply]
This suggestion is to completely misunderstand the potential of Portals in providing an alternative and often very visual route into a broad topic, without having to wade through a hugely long, and often tedious article, or visit a complicated WikiProject. Portals are (or should be) a bright window into a broad subject area, allowing the user to 'dip a toe' into topics that might interest or enthuse them. As the main explanation of Portals states: The idea of a portal is to help readers and/or editors navigate their way through Wikipedia topic areas through pages similar to the Main Page. In essence, portals are useful entry-points to Wikipedia content. Compare Mountain or WP:WikiProject Mountains to Portal:Mountain; Biology or WP:WikiProject Biology to Portal:Biology, and Arts or WP:WikiProject Arts to Portal:Arts. I do believe Portals are best off being closely associated with a relevant WikiProject in most cases, even though the latter deliver an utterly different function of focussing editor collaboration. Deleting 1,500 Portals in one go and moving content into a WikiProject would create vast work for absolutely no benefit and similarly misunderstands the purpose of WikiProjects and the role of Portals. Nick Moyes (talk) 14:12, 11 April 2018 (UTC)[reply]
  • Support Dead end, almost entirely unmaintained and out of date, yet included in almost every article. There's several IPs in my watchlist areas that constantly tweak and re-tweak portal bar templates to portals that haven't been updated in 11-12 years. -- ferret (talk) 12:48, 11 April 2018 (UTC)[reply]
  • Comment – some of the portals are actually key projects, such as Portal:Featured content, Portal:Current events (it's Wikipedia's news department), and Wikipedia:Community portal; while Portal:Contents forms the core of Wikipedia's navigation system. Portal:Contents isn't a portal at all, as it is comprised entirely of navigation lists. It was placed in portal space because at the time (over ten years ago), we didn't know where else to put it.     — The Transhumanist    12:56, 11 April 2018 (UTC)[reply]
  • Support - most are not maintained and thus are misleading to the few readers who seem to actually click on them, support deleting all. - Ahunt (talk) 12:58, 11 April 2018 (UTC)[reply]
  • Oppose deletion of all this content. I completely agree that most portals currently do not work, but that is no reason to nuke them all and pretend they never existed. Many collaborations used to be organised through portals, for examples see Portal:Germany/New article announcements or the archives of Portal talk:Poland/Poland-related Wikipedia notice board. Ten years ago, some people tried to use portals as something addressing both readers and editors, trying to showcase the best content in a topic area while attempting to attract further help. The same concept works reasonably well on the German Wikipedia. On the English Wikipedia, portals slowly became sidelined. I assume, however, that some are still alive serving some subcommunities (and for example Portal:Germany/Did you know is very much alive). The suggestion to just delete them all is outrageous and frankly insulting. —Kusma (t·c) 13:14, 11 April 2018 (UTC)[reply]
  • Support and remove namespace. This has been a long time coming, as the system has very limited usefulness coupled with high maintenance overhead. The category system and See Also links effectively do the same job. Huntster (t @ c) 13:23, 11 April 2018 (UTC)[reply]
  • strong oppose. I find none of the reasons I've seen really convincing to justify a wholesale removal. I don't necessarily have objections in removing (or archiving/moving) most unsupported/unmaintained and outdated portals, but that can (and should) be done on an individual basis. In general portals are helpful for navigation and allow for material and discussion that have no place in the article name space and hence cannot simply be replaced by article on the field in article name space (contrary to claims above). Also on occasion they may provide a function similar to projects. So as long as a portal is supported and the maintainers are happy to do so, I see no reason to shut it down. "Many people don't use it (anymore)" is imho no proper argument and no justification to aggravate the (smaller number of) readers and editors who do.--Kmhkmh (talk) 13:40, 11 April 2018 (UTC)[reply]
  • Oppose - Deleting all of these portals just because some are not up to standards is a terrible proposal per WP:BABY. - Knowledgekid87 (talk) 13:41, 11 April 2018 (UTC)[reply]
  • Oppose - This proposal is apparently originated from a personal issue with portals. That the portals are not getting updates is not a problem to be resolved via deleting them, the correct way is to devise schemes encouraging the editors to edit the portals.--Mhhossein talk 13:52, 11 April 2018 (UTC)[reply]
  • Strong oppose A properly created portal, properly supported with inbound links, can be much more effective than a google search, or the WP category system, in helping (non-editor) readers find information related to a particular topic. I don't agree that portals should be deleted on the basis that they are (a) often not properly manually maintained and updated; and/or (b) often not much visited. Assuming that the former is the case (and I'm not sure that it is), then automation is the solution. Google has already automated the incorporation of extracts of WP articles into the results of google searches (eg if you google the name of my home suburb, you get a page including an auto-generated infobox with an auto-incorporated up-to-date extract from the Wikipedia article about the suburb). So it's clearly possible for portals to have auto-incorporated up-to-date content. Assuming that portals are not often visited (and, again, I question the assumption), then it seems to me that a large part of the problem is a lack of links from articles to relevant portals. (When I create a new article, I usually include at least one portal link. However, I just randomly visited more than half a dozen substantial articles linked from the main page, and not one of those articles had a portal link.) I agree with the comment above that the solution lies in editing (and, I would add, in automation), not deletion. Bahnfrend (talk) 14:03, 11 April 2018 (UTC)[reply]
  • Mixed feelings though I agree that we need to find an incremental way to either depreciate portals (especially those that haven't had significant maintenance or public visibility in the last few years), this should be incremental: first with removing portals from the front page/other main subpages of Wikipedia, and then a gradual process of deletions (could probably be done with PROD on portals with less than 20 pageviews a day). The other option, is to overhaul the infrastructure used for portals, to be driven more by Lua Scripts and Wikidata Queries -- we have much better technology than we did when we first developed them 5-10 years ago: there is benefit in helping folks navigate Wikimedia projects. That being said, the portals have a very low level of demand right now. Sadads (talk) 14:08, 11 April 2018 (UTC)[reply]
  • Oppose What the what? I didn't realize this was going on until I saw a portal I have watchlisted tagged by Transhuminist just now. Nobody told me these were outdated when I got Portal:New York City to featured status. All I see here in the supports is that some of them are out of date. Since when do we delete articles that have {{update}} tags on them? I'm not seeing any better reason here. – Muboshgu (talk) 14:13, 11 April 2018 (UTC)[reply]
The fact that the Featured portal process itself was marked as historical last year could mean that, while Portals aren't necessarily outdated, there could be a fundamental flaw in the system that might not be easily solved. As I've mentioned elsewhere, portal automation has been proposed, which would probably solve the editing activity problem but might not be enough to solve the readership problem. Narutolovehinata5 tccsdnew 14:18, 11 April 2018 (UTC)[reply]
The point is more than that they are outdated, it is that they don't add to the encyclopedia the way an article fills gaps in coverage; are more effort than they are worth; and readers are not particularly interesting in them despite how often we link them. Galobtter (pingó mió) 15:50, 11 April 2018 (UTC)[reply]
Of course they don't fill in the encyclopaedia in the same way that an article does - they're not intended to. They're collections of articles which should provide a visual taster and a route in to a wide selection of subjects falling under that Portal's umbrella. More effort than they're worth? Explain please. Interest and deletion arguments are being based purely on numbers again. Like a child at school - if you can open one child's eyes to the wonder of a subject like science, geography, the moon, or whatever, that's a real success. So supporters neeed to demonstrate that all Portals turn users away, or fail to let them access articles, or that the server drain is just too high - then they might have a valid argument for mass deletion. But no-one has. It's all WP:JUSTDONTLIKEIT as far as I can see. Regarding 'outdated' - I do think there could be an argument to deprecate the use of 'News' sections within portals, or at least to have a guideline to remove these templates if not regularly updated. Nick Moyes (talk) 17:10, 11 April 2018 (UTC)[reply]
  • Oppose Per TonyB. They aren't in the way, and deal with POV nonsense on a case by case basis. L3X1 ◊distænt write◊ 14:31, 11 April 2018 (UTC)[reply]
  • Oppose - Portals are not redundant, they are complimentary and should they be depreciated, deletion is the wrong approach.--John Cline (talk) 14:54, 11 April 2018 (UTC)[reply]
  • Strongest Oppose. Stating low readership or out of date is a reason for mass deletion is a very very slippery slope. Stats provided by Andrew D. showed that there is plenty of readers and interest in this namespace. Stats and numbers don't lie, and far better than anecdotal comments. It's also hard to imagine that only new readers would stumble upon portal pages (a classic strawman argument), as Wikipedia has been around for 17 years and portal has been around for 13 years. What's needed is to make it more useful and attract more attention, not deletion. I'm also very displeased with this sneaky RfC which didn't consult with portal individuals before proceeding with RfC. OhanaUnitedTalk page 14:59, 11 April 2018 (UTC)[reply]
    • It was posted at Wikipedia talk:Portal#Ending the system of portals, which is probably the single best place to reach people who care about the portal system (rather than just the portal for one subject). It appeared there one minute after the RFC began. It was also posted at WP:CENT within minutes, and of course at three different RFC lists. It sounds like you didn't happen to see it during the first 72 hours, but this was properly advertised. WhatamIdoing (talk) 16:05, 11 April 2018 (UTC)[reply]
      • That was posted only after RfC began, and doesn't demonstrate any willingness to discuss with portals to address the issue. Rather, the intention was to delete them all from the get go. OhanaUnitedTalk page 13:15, 13 April 2018 (UTC)[reply]
  • Oppose - Neither low readership nor low updating rates are any reason to delete portals. Wikipedia is never complete, it is always being updated. There are many, many articles with low readership and low revisions, - that does not mean they should be deleted either. If Portals serve just a small section of the general readership, that is a good enough reason to keep them. In fact, a portal in need of updating may just prod some reader into editing. Simon Burchell (talk) 15:12, 11 April 2018 (UTC)[reply]
  • Support. I was editing Wikipedia for quite a while before I was even aware of portals. I came across Portal: Science by following the edit history of a vandal and discovered that many of the "Selected Articles" had been vandalised, some going back many years, and no one was monitoring this. I took it upon myself to watchlist all of the selected articles pages and for many years appeared to be the only one doing so (thankfully, there are a couple of others now). Since then, nearly all the edits I've seen on selected articles has been vandalism, mostly from schools. It would seem that pupils in some schools are being pointed towards our portal pages for research. It is not such a problem if navigation page vandalism goes unfixed for a while, but it is a big problem if article information is corrupted and lies unfixed. That directly harms our reputation. The problem with selected articles is that they contain encyclopaedic information, but are not in mainspace. They are summaries of mainspace articles. I might be tempted to support keeping the portal namespace if these selected article summaries were directly transcluded from the mainspace lead, but the current system just encourages vandalism and errors to remain unfixed for years. Also, as many others have commented, I oppose deletion of Portal:Contents. Many users, especially, lets say, of a certain age, will expect a contents page to help them navigate and it is the second from top selection in the navigation menu. SpinningSpark 15:50, 11 April 2018 (UTC)[reply]
  • Strong oppose deletion of existing portals. While I am not exactly opposed to the prevention of new portals being created, deleting the hard work of many editors, past or present, is going way overboard. "I put lots of hard work into this" is not an acceptable 'keep' argument at AfD, but I think it is when it comes to coverage of notable topics, in a non-article mainspace, from a project which is about collecting and giving access to the sum of all human knowledge. There are lots of portals which are brilliant and fascinating; they have a lot of potential for "random fact of the day"-type learning. And many need no further maintenance.
    However, it may be worth deprecating the project in some way which indicates to new editors, or those just stumbling across portals one day, "if you've got time to invest in Wikipedia, we'd prefer you invest it elsewhere". Even this is quite an extreme measure—we are all volunteers and can choose any (productive) way to contribute that we like.
    As for what should or shouldn't be featured on the main page or the sidebar, that's a discussion for elsewhere. The main page is in dire need of serious overhaul, but for what it's worth I think randomly linking to (former?) featured portals would be a fun thing to do, since this fits in with the TFA, DYK etc. theme of promoting obscure information and springboards to learning something completely new. Bilorv(c)(talk) 16:00, 11 April 2018 (UTC)[reply]
  • Oppose There is value in a portal system, especially for topics that don't change much, because it can give a reader a broad sense of the topic without wading through an article. I look at Portal:Mountains as a great example of what an overview of a topic could be, as well as a place to recognize featured and quality content. I do think that Portals probably work best when connected to a WikiProject, but I don't like the idea of a mass deletion. --Enos733 (talk) 16:14, 11 April 2018 (UTC)[reply]
  • Oppose. While we don't gain much from portals existing, we gain nothing from getting rid of them. Their continued existence has more merit than deleting them, and given the volunteer nature of wikipedia, it's not like effort that goes or went into them would automatically be routed elsewhere. GRAPPLE X 16:25, 11 April 2018 (UTC)[reply]
  • Support. I've always found portals to be a bad idea, often pushing POV or ideology, and generally misleading. I think we'd be better off without them. :bloodofox: (talk) 16:46, 11 April 2018 (UTC)[reply]
  • I respect your opinion but want to remind you that there are sometimes many editors on any given project and not all of the portals are alike. - Knowledgekid87 (talk) 16:52, 11 April 2018 (UTC)[reply]
  • If that's true (and I'm not saying that it isn't), that is an indication of an editing issue and not a deletion issue.--Paul McDonald (talk) 18:12, 11 April 2018 (UTC)[reply]
  • Oppose – the very fact that this RfC has generated a massive response shows that portals are being watched, used, and read. Those who do not watch portals are free to ignore them. – S. Rich (talk) 17:40, 11 April 2018 (UTC)[reply]
  • Support - specifically, deprecate, have bots mark them all as historical, and in time convert them to Outlines or Indexes to serve as centralized "See also" listings per topic.
They don't further our goal of being an encyclopaedia. For me, this isn't about whether they are well-maintained, and applies equally to Portal:Arts. Portals are intended to help users stumble upon quality material on random subtopics within a field. That's not a goal I care about or think Wikipedia should pursue. I like Finnusertop's proposal of topic-specific reference desks managed by WikiProjects, but that seems like a whole new idea, not an adjustment of portals. Daask (talk) 18:38, 11 April 2018 (UTC)[reply]
  • Oppose while some portals have been left behind (happens with WikiProjects also), some portals are still maintained regurarly and I wouldn't support just deleting them. I find some of them useful, but if the majority is supporting - I would hope the content of the portals will be moved to another nameroom. --Pelmeen10 (talk) 19:11, 11 April 2018 (UTC)[reply]
  • Support. They are not helpful to our readers and divert the attention and efforts of editors that would be better spent in article improvement. -- 19:16, 11 April 2018 (UTC)
    — Preceding unsigned comment added by Ssilvers (talkcontribs) 19:16, 11 April 2018 (UTC)[reply]
  • Strongly Oppose: I am using portals.--Maxim Pouska (talk) 19:21, 11 April 2018 (UTC)[reply]
  • Support - by the way, there is presumably some canvassing going on - someone left a message on my talk page asking me to !vote to keep portals. But I really don't think that's the best use of resources. There was a heyday ten years ago when most of them were being well-maintained. Now, they are either poorly maintained or have been long-since automated and are never touched or updated. With fewer people trying to maintain more content, portals are just an opportunity for POV forks of controversial issues. --B (talk) 19:40, 11 April 2018 (UTC)[reply]
  • Strongly Oppose: portals are a great way for understanding a topic or for finding your way around a topic quickly. They also help project teams to build a coherent set of particles. But they do need to be properly maintained and that is where our major focus should be. That would raise the quality of the poorer portals. --Bermicourt (talk) 19:44, 11 April 2018 (UTC)[reply]
  • Support – The only reason I click on portal links is to get to the pages for their related WikiProjects. There are definitely significant issues related to how often they're updated. Take this subpage on the Florida portal: Portal:Florida/Exemplary content. A few days ago I decided to add some recently promoted Florida-related featured article links to it, but I stopped when I realized that my edits were the first ones made to it in 8.5 years. When pages like this get severely out-of-date, it can cause problems. These problems can be avoided if we get rid of portals and put more focus on maintaining and updating WikiProject pages. Jackdude101 talk cont 19:44, 11 April 2018 (UTC)[reply]
  • Oppose. Portals have many functions, as I point out below. Even many of the people who want to delete portals see some valuable content in them that needs to be preserved. Here's an idea: why not leave the content where it is? Contrary to the opinions of many here, portals don't really need a lot of maintenance after they are set up. And they take up very little space. Compare them with navboxes: they often add a lot of clutter to a page and contribute to overlinking, making the page load more slowly – yet you can only delete one if there are no articles transcluding it. Portals add just one link to each page, yet the supporters of this proposal are holding them to a higher standard of usage. RockMagnetist(talk) 21:34, 11 April 2018 (UTC)[reply]
  • Opposed While it is necessary to eliminate obsolete software. it is more important not to eliminate the articles associated there on. And though I am in agreement with the elimination of portals that have ceased to function for the purpose that it was originally designed for, however, the elimination of the articles in association with those links should be made with extreme caution.
    Having edited and submitted edits on more than one of these articles; I know that the amount of time place in the study, research, writing and submission process is quite lengthy, due care needs to be taken when entertaining to proposal of elimination of any article. Consequently, I suggest that the 'portals' be reviewed individually, on an article to article basis, rather than the absolute deletion of everything.
    Birdymckee (talk) 21:34, 11 April 2018 (UTC) BirdyMcKee 11 April, 2018 14:34 hrs [Pacific Time] This comment by Birdymckee was moved to here from a section lower on this page by User:Dcljr in order to keep the discussion from becoming fragmented. Some minor reformatting was necessary to harmonize the comment with the surrounding discussion.[reply]
  • Oppose. Portal Poland, just an example, is the best place to go to when in need of having some foreign placename or a piece of difficult text confirmed as properly translated. BTW, is the Foundation running out of space or something? Poeticbent talk 21:40, 11 April 2018 (UTC)[reply]
    Server space is definitely not an issue for the WMF, and deleting things does not free up space, but actually adds to it, as everything is kept on Wikipedia (e.g. deleted pages are viewable by admins) and this would just add data to deletion logs etc. But I don't think anyone has argued that we are running out of space. Bilorv(c)(talk) 13:38, 13 April 2018 (UTC)[reply]
  • Broadly Support ending portals overall, but they should be marked as historical rather than deleted, removed from external search engine results, and links to them removed. The exception is if they are still actively maintained and well-used, although I'm not sure there are many of those. Or if we really want to keep them, then we should fully automate them to automatically stay up-to-date (maybe using Wikidata for things like 'on this day'). Thanks. Mike Peel (talk) 21:42, 11 April 2018 (UTC)[reply]
  • Obiously a lot of people are squeezing their brains trying to come up with original new solutions for the biggest problem of the Wikipedia comunity in these days: How can we drive off still more contributing editors? We've been quite successful in that, but this proposal is liable to do much more. Sorry, but most people who like to join these discussions apparently do not have the slightest respect for other people's work. But they seem to know exactly how other people use Wikipedia. Or at least how they should use Wikipedia according to their limited horizon! Sorry again, most supporters here do so because they were never able to use a portal. That's prove enough that they are useless, so let's do away with them! I've seen quite a number of promising projects die thanks to this sort of distructive frenzy. Obviously those stupid young enthusiasts were never seen again. My opinion: as long as there is only one user making good use of a portal, that's enough to keep it. But that's just my opinion, and I'm sure you all know better. So should I *OPPOSE this fantastic idea or should I simply congratulate everybody for bringing Wikipedia one step closer to suicide? MySpace took a similar highway to oblivion, and several others too. Most astounding: We don't even need Facebook to manipulate ourselves into that direction! Wow!--Lamassus (talk) 22:09, 11 April 2018 (UTC)[reply]
    • WP:AGF, Please. --Guy Macon (talk) 23:01, 11 April 2018 (UTC)[reply]
      • @Guy Macon: I understand the anger here, some editors here are saying in a nutshell that your project's portal is trash that needs to be disposed of. It gets me a bit irked to see these WP:IDLI comments, just because you may not like or use them doesn't mean you get to have your way over dozens of other editors that do. - Knowledgekid87 (talk) 02:09, 12 April 2018 (UTC)[reply]
        • I really don't care if people get angry because they think that they have WP:OWNERSHIP over a page. Accusing other editors of "purposely driving off contributing editors" and "not having the slightest respect for other people's work" is not allowed here. And as for your claim that "just because you may not like or use them doesn't mean you get to have your way over dozens of other editors that do", yes we do get to do exactly that -- if tyhat's what the community decides. This is called WP:CONSENSUS and it is how we make decisions here. Both Lamassus and you should post calm, reasoned arguments supporting your position instead of making this into a toxic conversation by refusing to assume good faith. — Preceding unsigned comment added by Guy Macon (talkcontribs) 03:57, 12 April 2018 (UTC)[reply]
          • This isn't about ownership though, portals are a collaborative effort within the Wiki-projects. If a single editor is taking ownership over a portal then it should be reported like any other ownership issue on Wikipedia. Consensus is also determined by weight of arguments, saying you don't like something because you don't use it isn't going to make your argument go far. In the end... I agree with you, I am saying that in the end I am not surprised with some of the anger comments. - Knowledgekid87 (talk) 12:04, 12 April 2018 (UTC)[reply]
        • (abstainer comment) - Agree with Guy Macon. Lamassus needs to review WP:BATTLEGROUND, WP:AGF, and WP:FOC, and refrain from turning discussions into battles between good guys and bad guys. Knowledgekid87 knows better than to defend or excuse that, let alone participate in it. We have these policies and guidelines for a reason. ―Mandruss  04:18, 12 April 2018 (UTC)[reply]
  • Oppose Portals are an integral and useful part of Wikipedia, and if there are some portals with specific problems they should be fixed. Don't destroy everything because of laziness.--יניב הורון (talk) 22:32, 11 April 2018 (UTC)[reply]
  • Oppose Initially when I first read this proposal I was going to snow !vote support but re-reading this discussion a few days on it's clear that some editors have done a significant amount of work on various portals. I think Wikipedia is now too big for large changes to be made almost overnight- which the deletion of all portals would entail- without affecting a portion of editors with any change above a certain size. Sure- some unmaintained portals which attract as much as vandalism as views should be deleted, but there's some great examples which editors have dedicated a significant amount of time to, and their contributions, time and effort that they've expended for the encyclopedia shouldn't just be deleted overnight. There's a great action plan above with the idea of automating portals which sounds feasible and should reduce the maintenance overhead. jcc (tea and biscuits) 23:22, 11 April 2018 (UTC)[reply]
  • Support - I've never seen the point in portals and still don't ..... I'm all for keeping historical things (even useless things!) but for these I support deleting ...... These aren't going to missed, Severely outdated, Severely underused, Better off deleted. –Davey2010Talk 23:25, 11 April 2018 (UTC)[reply]
  • They wont be missed by you, but yeah all of the other editors who use them... what about them? - Knowledgekid87 (talk) 02:05, 12 April 2018 (UTC)[reply]
  • Supports are at 130 and Opposes are at 62 as of this reply .... that would indicate I'm not the only person who wont miss them, Well I'm sure those that do want them will live (if they get deleted that is). –Davey2010Talk 02:52, 12 April 2018 (UTC)[reply]
  • Davey2010, where do you get the 130 support figure from? Are you counting 'mark historical' as supporting deletion? As of the time of writing (this version) I make it 92 people explicitly supporting the proposal and 64 explicitly opposing (give or take a few sitting on the fence or with lots of caveats in their position). Carcharoth (talk) 10:04, 12 April 2018 (UTC)[reply]
My bad all's I've done is counted the use "Support" and "Oppose" - Probably should've search for "'''Support'''" but oh well, Consider that point struck. –Davey2010Talk 15:24, 12 April 2018 (UTC)[reply]
  • Oppose The whole reason I became a wikipedia editor was to help with a portal. It's useful for me to find all of the information I want easily. However, I think there should maybe be some updates to the portal system? A way to make the news on the topic update without having to manually update it each time would be nice. What I mean about that is that you could put news in it that times out when it is no longer relevant and new things will update into their spots, and the input is just to put in the news, which can be done in advance (for a sports portal, games to be played, stuff like that). Maybe the original purpose of portals isn't what they're used for anymore, but things should adapt and change to fit the new needs of portals. They should not be deleted, but the system should be updated to make them easier to maintain and use. Too many people have spent too much time on portals to just have them be removed, or archived, because many of them will be unhelpful when they aren't up to date. Aabernat (talk) 23:57, 11 April 2018 (UTC)[reply]
  • Oppose straight deletion, support reform - The portals used to be highly valuable in aggregating users around a particular subject, agreeing common formatting and quality standards and organising maintenance of articles to keep them up to date and free of vandalism without duplication of effort. They died out not I would argue because they stopped being useful but because they became a lot less prominently featured and there was more centralisation of disputes and article standards in to a smaller elite of editors. The vast majority of more recent editors who have only ever known the centralised approach have never even seen or used them. WatcherZero (talk) 00:01, 12 April 2018 (UTC)[reply]
  • Slightly Oppose - For me, I understand where both sides are coming from as their are comments for both for and against this argument. In my thoughts, I do think that we need to somehow improve the portal function of Wikipedia, even if its means putting work into stuff that not many would be seeing. But I do think that there is some portals that doesn't get viewed will need to be deleted but its a case by case basis. Animation is developing 00:03, 12 April 2018 (UTC)[reply]
  • Support Some things catch on and others don't. I believe that we have given portals an opportunity, but their disadvantages outweigh their advantages. I'll take Portal:Microsoft as an example. The portal has received less than 100K page views (not bad), but comparing it to Microsoft, which has over 7.6M page views, you start to get the idea of why time spent maintaining them could be better spent elsewhere. Taking it section by section, everything seems to have a place elsewhere.
  • Intro --> Intro paragraph of Microsoft
  • Selected article --> Article of the day or random article
  • Selected picture --> Picture of the day or main article
  • Did you know --> Did you know on the main page
  • In the news --> Timeline of Microsoft
  • Categories/Topics --> Microsoft navbox
  • Featured content --> Wikipedia:WikiProject Microsoft
  • Associated Wikimedia --> Microsoft external links section

Daylen (talk) 00:13, 12 April 2018 (UTC)[reply]

  • Oppose but remove article links and mark as historical the most unused / unmaintained ones, and also ideally ask for some developer resources for easy creation of "automatically" maintained Portals. Portals are obsolete, readers don't use Portals, but they're also basically harmless. If somebody wants to spend a bunch of time making one, go nuts, as long as said editor recognizes nobody is going to read it. As for automatic rotation, it shouldn't be THAT hard for the devs to give us some code that, given a WikiProject or a Category, will automatically rotate between GAs / FAs selected at random and the like, and just dump the lede paragraphs into the Portal. Might vaguely help with freshness issues. SnowFire (talk) 00:36, 12 April 2018 (UTC)[reply]
  • Support I appreciate both the work that editors have put into some portals and the suggestions for reforms, but the ones I checked in the China field have not been edited in years.ch (talk) 02:45, 12 April 2018 (UTC)[reply]
  • Oppose While I never really contributed to portals myself, I don't see any issue with having them there. They are technically not in the way of any article or list, so since people are happy to have them, I oppose deleting them.--NadirAli نادر علی (talk) 04:24, 12 April 2018 (UTC)[reply]
  • Oppose – This would delete the entire portal namespace, and some portals are viewed fairly often. This would also remove a navigational feature that many readers utilize. Perhaps tag outdated ones as historical instead. Deletion of all portals per some of them being outdated, and subjective reasons such as some users not liking or using them, some thinking they are useless, pointless, etc. equates to throwing out the baby with the bathwater, and in the process would throw out thousands of hours of work performed by hundreds of editors in one fell, overarching swoop. It would be quite overly drastic and hasty to mass-delete all of the work that has been performed on portals in such manner. North America1000 04:32, 12 April 2018 (UTC)[reply]
  • Oppose While I agree that most are in need of updates, I don't think that's valid rationale for deletion. The few portals in my watchlist that are continuously updated have helped me out a great deal. Perhaps some other reform would be a better alternative to outright deletion.LM2000 (talk) 04:34, 12 April 2018 (UTC)[reply]
  • Conditionally oppose I personally find some of the portals very useful but if they could be integrated into something else then obviously I would care less; however the historical nature of them should be valued and like many before have stated, just because they are not as popular as they once were should not force deletion. All of the contents and Indices I see being useful. Indices are what I love as I read through articles in order when I am bored. - speednat (talk)
  • Oppose per MuzikAnimal. Let the WikiProjects who scope the portal falls under decide what to do with each portal. That way, the useful ones can be kept and if needed, moved, while other ones in need of improvement can either be worked on by members of that project or deleted. Seems like a common sense solution to me. - theWOLFchild 05:05, 12 April 2018 (UTC)[reply]
  • Strong Oppose: From the very beginning of Wikipedia days I found Portals to be useful for exploring a broad topic and considered them one of the more exciting part of Wikipedia. Here are the reasons why I feel portals should be kept:
    • They facilitate a reader who wants to explore a topic of interest.
    Example: Say I want to explore the topic of Mathematics. As a curious reader I go to mathematics portal. From the selected article section I learn that there is a good article on quadratic equation. I feel interested and I check out the article. If I only visited the Article on Mathematics. I would not have learnt about existence of an article on this topic so easily. Then I look at the DYK section. I see a DYK entry like: “...... that there are 115,200 solutions to the ménage problem of permuting six female-male couples at a twelve-person table so that men and women alternate and are seated away from their partners?” As a person interested in mathematics I immediately become curious. Without encountering this DYK I may not have even known about the existence of ménage problem. Then from Portal:Mathematics I jump into other related portals like Portal:Algebra and so on.
    • They give an opportunity to Wiki projects to showcase the output of their work.
    Example: I started my Wikipedia journey with Portal:Bangladesh and then wanted to improve the portal. To find more materials to showcase on the portal I ended up exploring numerous Bangladesh related topics and often ended up contributing in many articles.
    The below are a couple of reasons why the portals should not be deleted:
    • They should not be deleted because they are under-maintained. By this logic all under maintained contents should be deleted.
    • They should not be deleted because they have lower number of views. By this logic all contents with low view count should be deleted.
    However, we can consider the below:
    • We can introduce “notability” criteria for Portal. For example, we can say, to have a Portal on a topic, the main article on the topic needs to be at least a Level:4 Vital Article.
    • Portals which fail to maintain their “News” section for full 1 Year may be instructed to remove the news section and replace with a section on “Articles on Recent Developments”. Arman (Talk) 05:55, 12 April 2018 (UTC)[reply]
  • Support The portal system proved to be a dead end. Few, if any, are still being maintained, and they're unlikely to be being used by readers. Nick-D (talk) 06:59, 12 April 2018 (UTC)[reply]
  • Hi Nick-D: Out of curiosity, have you checked out any of the page views for portals? Your assessment stating "...they're unlikely to be being used by readers" is countered by page statistics for several portals. For example, Portal:Biography has received 62,874 page views in the last thirty days as of this post. North America1000 07:48, 12 April 2018 (UTC)[reply]
  • @Northamerica1000: Few things. If you'll note my !vote below, I think that they should be marked historical. Whoever made this RfC and said the word "delete" made a really poor decision there. 12k views over 30 days is not "well-used," it's a rounding error. Portal:Contents is linked from the sidebar on every Wikipedia page. Ed [talk] [majestic titan] 16:30, 14 April 2018 (UTC)[reply]
  • Oppose deletion, there are hundreds of excellent pages here. Support change, including marking many as out of date or historical, and possibly removing from the Main Page. – SJ + 07:27, 12 April 2018 (UTC)[reply]
  • Support. Overall their utility is not proportional to the maintainance effort as separate pages. Some elements (e.g. lists of DYKs) make sense as part of WikiProjects, but the remainder could be archived for posterity. T.Shafee(Evo&Evo)talk 07:52, 12 April 2018 (UTC)[reply]
  • Support: Many are confuse masses of content, difficult to update, and in most cases unsourced (since in most cases they do not use a system of sources).--Eckhardt Etheling (talk) 07:57, 12 April 2018 (UTC)[reply]
  • Support But: Wouldn't a technical solution like "no activity for 1 year => auto-delete" be sufficient? Also, portals with >= X hits/d (to be defiend) should probably stay as a public interest is proven. Kind regards, Grueslayer 08:41, 12 April 2018 (UTC)[reply]
  • Oppose deletion; the Science portal had 122,000 hits. --Ancheta Wis   (talk | contribs) 08:53, 12 April 2018 (UTC)[reply]
  • Strongly Oppose
    Like to know more? – well best look soon before it is all deleted
    Having created a couple of portals in recent years, I have a dog in this fight. Portals provide a way of linking articles, images, quotes, DYK’s in a different manner to single articles. Yes they may be out of date, etc. etc. but so are many articles. As per Paul McDonald, this is an editing issue and not a reason for mass deletion...Jokulhlaup (talk) 09:03, 12 April 2018 (UTC)[reply]
  • Support. Appear to be generally unused and unmaintained. Wouldn't necessary mass-delete them, but perhaps they could be integrated into Wikiprojects where people are keen to do so Ivar the Boneful (talk) 09:23, 12 April 2018 (UTC)[reply]
  • Oppose Portals are for readers (this is why enclosing them within WikiProjects is beside the point), and we need the "market research" as suggested by PaleCloudedWhite before we can be sure what forms of navigational aid are most useful to readers. Among portals, indexes, outlines, navboxes, sidebars, TopicTOCs and the rest there is no consistency in which ones exist for a given topic and to what extent they are linked from articles. A save-the-portals plan: (1) take up the ideas for maximum automation of their construction and maintenance; (2) also automate the provision of links from articles, thusly: for each Category assigned to an article, a process follows up the category tree until hitting one that has been marked as corresponding to a portal, then adds a link at the article; (3) keep portals for major topic areas, trimming out those for minor subtopics; (4) be aware that not all readers will have heard of web portals, and the word "portal" otherwise suggests high-flown phrases such as "entering the portals of glory" – so just putting a link saying "All portals" on the main page won't attract many clicks, you need to say "Pick a topic that specially interests you, and here's an overview of how Wikipedia covers that topic": Noyster (talk), 10:03, 12 April 2018 (UTC)[reply]
  • Oppose - For full disclosure, I have a strong personal connection to this issue; I created and have been maintaining Portal:Trains and making daily edits to it since its inception in May 2005, but I have not been the only person viewing it. The pageview count for the last year is almost 30,000. If we assume that my edits amount to five pageviews per day, that reduces the overall views for last year by only 250. When I make edits to the portal, I almost always find other pages within the scope of WikiProject Trains that I can make improvements to, and I will make those improvements when I can. My work editing the portal has led on a daily basis directly to additional work building up the content outside the portal. It has helped to keep me involved as a Wikipedia editor and administrator since my first edit to it 13 years ago. Slambo (Speak) 11:01, 12 April 2018 (UTC)[reply]
    • Spot on Slambo. Another way of looking at portals is that they are an 'intelligent contents page' for a topic. And certainly much easier to use for tracking relevant articles that poring over the often lengthy main article for a topic which is just not structured for the easy location of articles. Many portals are also a valuable project asset, indicating what's been done, what needs improving, what needs adding and so on. Improvement of portals is a worthwhile goal; mass deletion leaves Wikipedia very much poorer. --Bermicourt (talk) 12:29, 12 April 2018 (UTC)[reply]
    • Further, Portal:Trains has translations on 18 other language versions of Wikipedia. Portal:Transport has 24 other language variants, and Portal:Technology has 62 other language variants. I understand that changes on en.Wikipedia don't necessarily mean that changes will also happen on other language Wikis, but having so many different language versions of all the portals shows strong interest worldwide in maintaining them. Slambo (Speak) 12:06, 13 April 2018 (UTC)[reply]
  • Oppose I do not see what harm portals cause to the project. If anything, they are useful for combining several related articles on a topic in one place. There are several well-constructed and featured portals. Mar4d (talk) 12:39, 12 April 2018 (UTC)[reply]
  • Support - My thanks to those who have contributed to them, but I think dropping portals will help concentrate our efforts in more impactful areas. -McGhiever (talk) 12:47, 12 April 2018 (UTC)[reply]
  • Oppose removal of portal space and portal "system/facility". But do support deletion of out of date (and hence by definition) unmaintained portals. These are contrary to the stated purpose of a portal and take away from the reader's experience. I suggest any portal that has not been updated (and should have been) for 12 months more can be nominated for deletion via a process the same as AfD. Aoziwe (talk) 13:18, 12 April 2018 (UTC)[reply]
  • Oppose I think they could serve a very useful purpose, being written in a less formal manner than most articles, and providing a more accessible roadmap to related articles for visitors who are no so familiar with wikipedia categories and other means of navigation. I think the real problem is that they have not been properly promoted. Most links to them are tucked away at the bottom of a page. I think that if they could be linked to at the top of the page, perhaps alongside or under the space where coordinates appear, then they could get more visits and perhaps become better maintained. I must admit that I had pretty much forgotten about them. Derek Andrews (talk) 14:03, 12 April 2018 (UTC)[reply]
  • Oppose No, and especially oppose deleting all portals. How many articles do we have on Wikipedia that no one or few read? How many articles do we have on Wikipedia that are not well maintained. These are not the criteria we use for creating articles and by extension should not be for creating portals to those articles. As well, we do have portals that are well maintained. I just saw RfC today; this has to be more public than it is now.(Littleolive oil (talk) 14:21, 12 April 2018 (UTC))[reply]
  • Oppose To me, Portals act like subsections of a newspaper, if we take our Main Page as the equivalent of the front page of a newspaper. When they are updated, they provide a good current snapshot of a topic area within WP. I do think this RFC leads to the idea that we should reassess what makes a good portal, how to encourage portals to stay updated, and possible investment of time into new tools/processes to automate updates, but the simple lack of updates should not be taken that portals are not needed and should be deleted. --Masem (t) 14:24, 12 April 2018 (UTC)[reply]
  • Neutral or whether portals should continued or not. Strongly oppose wholesale deletion of the entire namespace. If there is consensus for portals to be discontinued, then I'm in favor of a phased approach with some kind of archiving of the contents – of featured portals at the very least, if not all. — Kpalion(talk) 14:34, 12 April 2018 (UTC)[reply]
  • Support the general idea of depreciating the portal namespace (generally speaking—things like the featured content portal should not be included and perhaps moved to the Wikipedia: namespace), but who designed this RfC? Why would you propose to delete them all and guarantee opposition on that front, as opposed to marking historical? Just doesn't make any sense. Ed [talk] [majestic titan] 14:44, 12 April 2018 (UTC)[reply]
    Keep in mind that portal pages are edited through templates. In the end, you should measure the template activity and not the portal page which just presents all the info. - Knowledgekid87 (talk) 14:50, 12 April 2018 (UTC)[reply]
  • Oppose. Far too sweeping a proposition. The issues identified do need addressing, but this is not the way to do so. Andrewa (talk) 14:57, 12 April 2018 (UTC)[reply]
  • Support Portals made sense back in the days before robust search engines, when Yahoo Directory] and Open Directory Project/DMOZ ruled the web and most people's browser home pages were set to iGoogle or My Yahoo!. Portals are best deleted or absorbed into WikiProjects. Give the Wikiprojects a few months to refactor any desired content into their front pages and then delete them. The one exeption to this would have to be Portal:Current events, whose WikiProject is inactive (here, the easy answer is to simply move Portal:Current eventsWikipedia:WikiProject Current events). --Ahecht (TALK
    PAGE
    ) 15:25, 12 April 2018 (UTC)[reply]
  • Oppose This is one of the stupidest proposals I've ever seen in Wikipedia. As it is described in the description "The idea of a portal is to help readers and/or editors navigate their way through Wikipedia topic areas through pages similar to the Main Page." If people do not find portals helpful and useful who on the earth created all those portals? Deleting all the portals just because portals receive a low number of views is a bad decision to make and a bad exemplary for the future editors. They will propose to delete Wikipedia articles also just because they receive a low number of views. If you really want to stop portal function on Wikipedia, then do it. But please don't delete all the portals which were made by so many editors who found portals interesting and useful. ---Randeer (talk) 15:36, 12 April 2018 (UTC)[reply]
  • Oppose "the deletion of all portal pages and the removal of the portal namespace", which is what the RFC proposes. It makes no sense to delete all pages on the basis that some (or even many) are unsatisfactory. Thincat (talk) 16:17, 12 April 2018 (UTC)[reply]
  • Oppose for several reasons.
    1. It looks like this would be a seriously divisive move. It may deeply antagonise a significant number of passionate editors for very little, if any, real advantage. This alone is sufficient for abandoning this proposal.
    2. We are not short of space, and portals take up very little space anyway.
    3. There is insufficient evidence for most of the claims of both sides for them to be taken seriously. This would be a big change, and the possible consequences should be evaluated by experts before making the proposal. The arguments here are mostly emotional or based on opinions and guesswork.
    4. Many of the supports are clearly from people who do not have any personal involvement in portals, so can be reasonably expected to be rather ignorant about their usefulness to those who do use them, work with them and maintain them. Are these really the people who should be forcibly removing something from the people who want to keep them? Portals have been on Wikipedia a long time, there is no question that they are acceptable in terms of tradition and existing policy.
    5. Deletion means that the content is lost. Much of that content may be valuable. Who has checked and can say with evidence that it is not?
    6. Alternative solutions have been suggested, but the practicability of these have not been established. There should be no deletion until after these have been considered and discussed. The proposal is premature. There is no rush.
    7. We do not delete things because they are not perfect, we fix them. This would be a dangerous precedent. We could no longer trust Wikipedia to respect our work and the effort that went into it. It is bad enough that we can't trust the WMF much of the time, we do not need to start mistrusting our own community as well. There are probably fewer support !votes here than the number of portals they want to eliminate. · · · Peter (Southwood) (talk): 16:41, 12 April 2018 (UTC)[reply]
  • Oppose deletion, support reform. Many portals are outdated and long-unmaintained - and those should be moved out of namespace and marked as historical. However, numerous examples have been given above of portals on major subjects which are still being maintained, and I feel like the nuclear option is a massive case of overkill. (The lack of even a plan for things like Portal:Current events particularly illustrates to me that not enough thought has gone into the nuclear option.) The Drover's Wife (talk) 16:45, 12 April 2018 (UTC)[reply]
  • Oppose—deal with outdated portal content the same way as we deal with outdated article content: editing. The various arguments advanced in support of this proposal call for the mass deletion of things that just need fixing or selective deletion. At the most extreme, this proposal calls for the deletion of otherwise perfectly good content. This situation is too nuanced to use mass deletion as a solution. Additionally, if you remove portals, there is no guarantee that their editors will redirect their attention to other tasks. Volunteers will work on projects that attract their own interests and attention, so we can't assume those energies will be channeled to other endeavors. Imzadi 1979  16:55, 12 April 2018 (UTC)[reply]
  • My last intervention here has been harshly criticized, most of all when I wrote that this idea is liable to "drive off contributing editors" and that "most people who like to join these discussions apparently do not have the slightest respect for other people's work". In twelve years I have encountered quite a number of people who gave that impression and as a consequence I've remained attached to Wikipedia just at the very edge. But that's a personal question which doesn't really belong here. Actually I hoped that my hard words would cause some reflection, so I thank everybody for their replies. First of all I want to say that this is not about dividing the citizens in good and bad guys. I could say that my words were ironical, but that would be only half the truth without changing much. Here is what I really think: There are many ways to destroy a democratic community and this one is quite illuminating. What's the trick? You ask a simple question: Do you think Hillary is corrupt? Everybody has seen her in television a number of times, so I guess they are able to answer. Everybody has come across a forum on Wikipedia, so he must have gained some impression whether that was useful. Come on, don't be shy, say your opinion! People have the right to say what they think, that's democracy! If there is a vote or an election it is the only way. But as soon as you answer that question, positive or negative, to decide on the sweeping purpose, you appear as if you don't have the "slightest respect for other people's work". It is inevitable, because you may have lately looked at three or four portals, the most diligent of you even more, but you sentence hundreds of them, judging the intelligence of thousands of people who have tried their best on a million edits which have all been verified by another 10.000 or 100.000 users. Nobody is able to answer this for each and every single portal in question. It's generalization. That's why I think this proposal should be ruled INADMISSIBLE. But now the question is on the table, everybody has understood, it needs an answer and everything else will pass in second place. Like the Athenians who were asked if they would like to rule Sicily. Of course they would. Or more recently the US voters, who were urged to decide whether they were more comfortable with Crooked Hill or Grabbing Don. I wish you a nice discussion then, but don't forget that the purpose of democracy is to include, not to destruct. If only a few of us understand this, there may still be some hope at the bottom of the box.--Lamassus (talk) 18:00, 12 April 2018 (UTC)[reply]
  • Support - When I need information about something, I use the search function or external internet search engines. When I am interested in learning more about the subject, I Ctrl+Click all links that seem interesting to me. I end up with 100 open tabs, hours of delightful reading and no need for any "portal" created by someone else to inform me about the "most interesting" articles on one big topic. I have never even considered opening a portal page. ~ ToBeFree (talk) 18:13, 12 April 2018 (UTC)[reply]
  • Strong Oppose. I've read this entire discussion as well as the discussion that preceded this RfC, and I've seen and considered all of the reasons that have been given in support. And I'm not persuaded. It's not like deleting them will make Wikipedia better. In fact, even if I posit for the sake of discussion that the supporters are right that readers almost never make use of portals, then it follows that readers will almost never even notice if they go away. Although I get it that portals need a significant modernization, the proposal here is a solution in search of a problem. But I would happily support a major effort to improve the portal system. --Tryptofish (talk) 19:09, 12 April 2018 (UTC)[reply]
    • This is the best oppose to a proposal I've seen in a long while. Agreed 100% with everything you've said. If anything, this proposal will be a negative because it will be a massive waste of admin time deleting these things. TonyBallioni (talk) 19:21, 12 April 2018 (UTC)[reply]
  • Support. Monthly upkeep is minimal but so is readership. Less than 100 views per month day. Despite invitation to be bold, only one other editor tried to add to ours in 10 years. -SusanLesch (talk) 19:22, 12 April 2018 (UTC)[reply]
@SusanLesch:
Library front desk display - come in and read more books like these
If whichever portal you refer to is flawed, you have a route to have it removed. It's at WP:MFD. That's not a rationale for mass-deleting the other 1,500 portals. Nor is a lack of recent editing, or having only 36,500 visits a year. Think of Portals like a window or table display in a library. They simply present a minute selection of their holdings to encourage broader use of any of the library's holdings. They're just another route in to content; pick one up and maybe you'll get inspired. Why deny readers that opportunity? Nick Moyes (talk) 00:10, 13 April 2018 (UTC)[reply]
  • Oppose in favor of technical overhaul: Like many others, I agree that keeping portals maintained and updated is a problem, so to is creeping POV. Both are solvable. My suggestion is that portals be highly standardized in some way, possibly by allowing a series of automated templates for featured content, etc. -- though most watched is probably not useful (for WPEQ, I think the article on Princess Anne gets the most pageviews, whereas Horse should be what pops up immediately) Montanabw(talk) 19:47, 12 April 2018 (UTC)[reply]
  • Oppose: A lot of portals are indeed in need of work and in some individual cases may have outlived their usefulness. However I do not think that is an argument for getting rid of all portals. Some however have the potential to be very useful and if a better way to maintain them, as others have suggested, could be found then I feel that that is a better option. Dunarc (talk) 20:12, 12 April 2018 (UTC)[reply]
  • Oppose: Yes, there are some portals that have fallen into neglect and disrepair, but portals are not unique in this respect. There are others that provide a useful summary of a topic. Such a wholesale culling of content on such flimsy grounds would be entirely inappropriate. — Preceding unsigned comment added by DavidCane (talkcontribs) 21:34, April 12, 2018 (UTC)
  • Support. Even at their height, I doubt portals were very useful. I created and maintained a portal, then forgot about it until this deletion notice. No one else stepped up to keep it current. →Wordbuilder (talk) 22:10, 12 April 2018 (UTC)[reply]
errm, but these were Portal:Texas Tech University and Portal:University of Houston - neither being desperately broad topics to start with. You can still WP:MFD either if you wanted to. Nick Moyes (talk) 00:25, 13 April 2018 (UTC)[reply]
  • Strong Oppose the wholesale deletion of portals; Support for some sort of reform. (The broad wording of this proposal, "the deletion of all portal pages and the removal of the portal namespace", worries me, as it would clearly affect portals many use, including Portal:Current Events, etc.) It's clear, though, that this is a contentious topic and yet a somewhat obscure one, at the same time: all portals are created equal, yes, but not all portals turn out equal. While I'm naturally reticent to remove portals as a whole, some reform is needed: many portals (like the one that led me to this discussion, the Gilbert and Sullivan one) fall into disuse, and, thus, disrepair (the G&S one hasn't been updated in three years), but the deletion of portals simply won't marginally improve Wikipedia somehow or another. After all, it's not like we have limited space and need to conserve it (WP:NOTPAPER), and so keeping portals won't waste space or anything of that sort. But reform is needed: less than 100 page views per month means something's wrong. I'm honestly not sure what would work best: I dislike automated upkeep of portals (I guess I like human interaction), and streamlining portals through standardization, let's be honest, is a crapshoot; but I have no better ideas to contribute to the discussion. — Javert2113 (talk) 00:37, 13 April 2018 (UTC)[reply]
  • Deprecate, but don't Delete I don't think portals should be linked from the article namespace. It's just clutter. Simply deleting Portal: tomorrow would have zero downside for 99.99% of readers and 99% of editors, but the other 1% would be reeeally annoyed. OTOH it seems a lot of unnecessary work to have some through review of each portal to assess whether some or all content is moved to another namespace before some deletion deadline date. jnestorius(talk) 00:59, 13 April 2018 (UTC)[reply]
  • Support: A minority of portals are maintained and are never read by the general populace. I support deletion of all portals. –Vami_IV✠ 01:10, 13 April 2018 (UTC)[reply]
  • No strong opinion: I've never really paid attention to the portals (with the notable exception of initially creating the page for Portal:Software) so I can't really say one way or another whether they should be removed. But I do want to say that if they are removed, please make sure they're archived in a manner that preserves all their history, just because the information shouldn't be made inaccessible. flarn2006 [u t c] time: 04:26, 13 April 2018 (UTC)[reply]
  • Oppose - Where to start, I haven't been editing as much as I used to due to issues IRL but I can say that when I edited more profusely that I took it upon myself to improve the portal experience, including creating multiple templates, tweaks and other such tools to improve the portal experience. I even began the maintenance of Portal:Food, Portal:Beer and creating Portal:Drink to compliment P:Food and WP:Food and Drink. Portals can be a great way to present new readers to wealth of subjects in specific areas. So I wholeheartedly disagree with the discontinuation of the Portal namespace and the deletion of the content. What I do support is a system of promoting the Portals that would increase their usage and importance on Wikipedia. I would also support the merging of similar, narrowly-focused portals into more generally-focused ones that cover a broader, similarly grouped areas of ideas. How would we do this, IDK but a discussion on how to start would probably be a good place to begin. Jeremy (blah blahI did it!) 05:01, 13 April 2018 (UTC)[reply]
Perhaps the best way to promote them, as well as to increase their usage and importance, would be to improve their quality, in terms of interactivity and self-updating dynamic content, to keep them interesting and relevant. Inspire repeat visits. Currently, the vast majority of portals are static, and therefore they go stale over time.    — The Transhumanist   13:05, 13 April 2018 (UTC)[reply]
  • Support they serve no discernible function. We don't need them for organization.·maunus · snunɐɯ· 08:57, 13 April 2018 (UTC)[reply]
  • Support - as stated on WP:Spaceflight's talk page a couple of days ago, too much work for not enough benefit. The time could be better spent working on other things. Support full deletion, with no historical pages kept. Kees08 (Talk) 09:51, 13 April 2018 (UTC)[reply]
    @Kees08: You now that Portal:Current events is part of this system right? - Knowledgekid87 (talk) 13:12, 13 April 2018 (UTC)[reply]
    @Knowledgekid87: I was aware, but did not know what it was. I found the link on the main page (even though named different), and I do not think removing it would be a great loss. Even though I am involved in the spaceflight WikiProject, there is spaceflight information on that portal that I was not aware of. There are links to three pages nominated for deletion, several DAB links. Seems like a duplicate of Wikinews and could be replaced with that, since the page does not fit well with the encyclopedia theme. Kees08 (Talk) 05:35, 14 April 2018 (UTC)[reply]
  • Oppose deletion of portals, no opinion on other proposed changes (make them historical, remove links from the main space). Only portal I ever used is Portal:Amiga, which is no longer updated work of one (retired) editor. Sure, content can be moved under WikiProject Amiga (defunct/undead). Pavlor (talk) 10:21, 13 April 2018 (UTC)[reply]
  • Oppose Useful for placing notices on talk pages of portals of related discussion on subject during deletion requests. Semper Fi! FieldMarine (talk) 11:34, 13 April 2018 (UTC)[reply]
  • Support Never understood the point of portals in the 13 years I've been editing. Editors' time would be better spent maintaining the mainspace articles. Number 57 11:36, 13 April 2018 (UTC)[reply]
  • Oppose — keep but reform. What are Portals for? Editors want a forum but Wikiprojects do that better, so move editor-facing Portal content (such as lists of articles to improve) to WP: namespace. Readers want something useful when they click Contents in the left navbar, so keep Portal:Contents or build a replacement. Many subpages such as Portal:Contents/Mathematics and logic just duplicate the better Portal:Mathematics etc. so let's link the latter directly into the contents tree. The more enthusiastic wikiprojects can then reformat their portals with an emphasis on listing contents; the rest can remain in the current state which is better than nothing. Certes (talk) 11:43, 13 April 2018 (UTC)[reply]
  • Oppose deletion en mass of all portals, Support analysis and deletion of inactive ones. There are probably hundreds that haven't been updated in years, some even nearing a decade, and these should be deleted. But others are still viewed semi-frequently and are updated daily and shouldn't be deleted. I don't think this issue can be so black and white.. there is a middle ground. SEMMENDINGER (talk) 13:30, 13 April 2018 (UTC)[reply]
  • Support I've been editing 14 years and I have never used any portal regularly. Also apparently readers don't care about portals. With all the respect to portals editors, time spent to maintain them could be more efficient to improve the articles itself.--Jklamo (talk) 14:05, 13 April 2018 (UTC)[reply]
  • This is not a good link to make and have seen it talked about someplace on Wikipedia I think through an essay. The notion that "editors would be better off doing x" is a slippery slope, should we then go on and say something like: "Editors should focus their time away from plant related articles due to the complexity of the field"? Each portal attracts editors interested in that particular area, just because you may not edit portals nor care about them is a good reason for wholesale deletion. - Knowledgekid87 (talk) 14:14, 13 April 2018 (UTC)[reply]
  • Sorry Jklamo, arguing to delete all portals and respecting portal editors are mutually incompatible. Instead of arguing for deletion of portals, why not spend your time more efficiently improving articles? Sarcasm aside, redirecting volunteer effort away from what they want to do towards what you think they should do is quite a lot of work, and deleting the work of volunteers is not usually a good way to make them volunteer for more. —Kusma (t·c) 14:16, 13 April 2018 (UTC)[reply]
  • Oppose deleting all portals but support deleting particularly bad ones. Portals can be useful from time to time, and even if use rarely, that does not mean they should al be deleted. If someone searches a portal, he will always be happy to find whatever he finds even if is not well-maintained. However, some portals have not been edited in years and should be deleted. The "Many people don't use portals, so let's delete them all" is ridiculous. Mass deleting portals won't make Wikipedia better. L293D ( • ) 14:55, 13 April 2018 (UTC)[reply]
  • Oppose blanket deletion of all portals regardless of current maintenance status. --SarekOfVulcan (talk) 15:08, 13 April 2018 (UTC)[reply]
  • Oppose but de-emphasize. These are not really designed for people like us, but for readers new to WP or a subject area. Some links to them should probably be removed, and the actually bad ones deleted. But many seem to function ok, more or less on autopilot, and they do get views. Johnbod (talk) 16:20, 13 April 2018 (UTC)[reply]
  • Support – I setup the Military History portals for Portal:Napoleonic Wars and Portal:American Civil War many years ago, but the Pageviews for portals are generally so poor, they're just not worth the effort maintaining (ACW and NW). If the trends are similar for other portals, the whole system seems a waste of effort and should be scrapped in favour of focusing on actual article content. Portals seem a bit 1990s phpBB anyway, IMO. — Marcus(talk) 16:31, 13 April 2018 (UTC)[reply]
78,500 views since May 15 (Portal:American Civil War) doesn't seem too bad at all. Do they actually need any more maintaining than any other page? Johnbod (talk) 16:40, 13 April 2018 (UTC)[reply]
When you compare 78,500 views to the 15 million hits on the American Civil War article itself in the same period then yes, it's only 0.5% in fact. Not worth it. — Marcus(talk) 19:23, 13 April 2018 (UTC)[reply]
  • Support the reform of the portals system as we know it, but oppose the deletion of all portals en masse. Perhaps, rather than resorting to a blanket deletion of all portals, it might be better to review them. After review, each portal could either be:
  1. categorised as an active portal, with the general criteria for this status being that they have to be regularly monitored and kept up to date;
  2. marked as inactive through the use of the Historical template; or
  3. deleted outright (for example, if they are particularly poorly and/or rarely maintained).
Portals can come in useful for editors from time to time, but admittedly it is quite easy to gather that they are not quite fit for purpose any longer. I don't think it'd be unreasonable to suggest that many portals, if not most, are very infrequently viewed by most editors and (non-editor) readers alike. I don't think that there needs to be as many portals as there currently are.
Would this proposal to eliminate the portals system provoke such interesting discussion between editors had the system not been in such a sorry state? I can't tell you the answer to that, but what I can say is that the system is in dire need of improvement. A portal should be a useful navigational tool for readers and editors, but the way they are today, most are not. All too often, editing activity fizzles out, leaving a near-abandoned portal that is a sitting duck for POV issues and unsourced material.
Forgive me if this idea is too simple, but it may be wise to try and devise a system that unobtrusively increases the awareness of the portal system to readers so that people are encouraged to visit portals. This would be expected to generate some interest in using portals, so that people are more inclined to contribute to Wikipedia by editing portals. In turn, this would help to improve the encyclopedia by helping people navigate through it.
I don't tend to voice my opinion in community discussions like this, because it can seem quite intimidating to editors like me, who don't consider themselves to as well versed with Wikipedia as many of you, and haven't been contributing for as long as many of you have. So, once again, let me apologise if I am reminding you of something that is bread and butter to you. There are several templates that can be used to include links to a portal or multiple portals. Take the Portal, Portal bar, Portal-inline, Subject bar and Sister project links templates as examples.
A side note: I found it quite difficult to leave my views on this page because of the edit conflict message that kept appearing when I tried to publish changes. If any of you are reading this and know of a way to add your comment without encountering this, it would be a godsend if you’d be kind enough to let me know on my talk page. Thank you. Best wishes, Ntmamgtw (talk) 16:49, 13 April 2018 (UTC)[reply]
  • Oppose - they're neat. I don't have much to say about portals, I don't interact with them frequently, but they seem a useful way to present a useful overview of broad topics. If some of them are in poor shape, fix them, or delete individually if they're individually not useful. Ivanvector (Talk/Edits) 18:01, 13 April 2018 (UTC)[reply]
  • Very Strongly Oppose – Each of the portals I have been to are very useful for navigation and introducing readers to new/interesting topics. The reason why many of the portals have "low traffic" is because they are stashed under the title of "portal", and not many people would naturally search out such page titles (unless they were already familiar with them). (Also see some of the other arguments for keeping the portals above, and some other arguments in the sections below - they are quite reasonable.) Nonetheless, the portals are linked to most of the related/relevant articles via the Portals Templates in the articles' "See also" sections, so I actually believe that a reasonable number of people read through and check out the portals regularly, and thus, page traffic should not be an issue. Low maintenance is a very poor excuse for eliminating the portals; this problem is present on many of the WikiProjects that I have worked at, because some of the most senior/active contributors are no longer as active there - Should we eliminate all of the WikiProjects because some/many of them are no longer regularly maintained? This is just ridiculous. I regularly use some of the portals for navigation and improving articles - and I am well aware that many of our readers regularly do so as well. Let's say we kill off all of the portals - how are we going to replace them then? Are we going to create a "new" navigational set of pages, or are we going to let this entire, useful means of navigation just rot and fade into oblivion? Without the portals, how are readers and active editors going to be able to access many of the articles in a specific WikiProject via one page? Regardless of level of page viewership and maintenance, portals are already too useful to simply be deleted. Portals on Wikipedia are extremely useful for all sorts of navigation within a WikiProject and introducing readers to new topics - I don't see why any of that would be grounds for deleting the portals. LightandDark2000 (talk) 17:54, 13 April 2018 (UTC)[reply]
I have no problems with reforming the portal system or even setting something up to increase reader/user awareness of the various portals (which will help mitigate any maintenance issues), but deleting or redirecting all of the portals outright is simply not a viable option? Are you even aware of how much infrastructural damage or reader shock you will cause if you were to delete all of the portals? LightandDark2000 (talk) 18:02, 13 April 2018 (UTC)[reply]
By the way, a large number of portals, such as Portal:Current events, Portal:Science, Portal:History, and Portal:Tropical cyclones are regularly maintained and have high viewership (to my knowledge). These are only some good examples. Are we going to mass delete all of the portals just because some of them aren't up to ideal standards? This proposal falls under the same fallacy that is often invoked for speedily deleting new/start or stub class articles that have plenty of potential, or eventually became great articles on this site. (There's a reason why you are not supposed to arbitrarily tag new or problematic articles for deletion because they don't look ideal.) I seriously doubt that all of the portals each have enough issues to warrant an actual deletion of all the portals. LightandDark2000 (talk) 18:19, 13 April 2018 (UTC)[reply]
  • General Support, prefer marking portals as historical I've worked on portals, and I stopped because I realized they aren't particularly useful and are more work than they're worth. I don't think deleting them is the best solution. MY prefered solution would be marking the whole system as historical, advising against (prohibiting?) the creation of new ones, and advising against the expansion of all but the most used (or even moving them to Projectspace). Wugapodes [thɔk] [ˈkan.ˌʧɻɪbz] 18:18, 13 April 2018 (UTC)[reply]
I would not support marking all portals as "historical" (or taking them all out of the portal system). Some portals, such as the current events and tropical cyclones portals are still actively maintained and highly essential to accessing the latest articles (in a chronological sense) in relation to their specific WikiProjects. I could support marking the archaic / extremely old portals as historic, but the active/relevant portals are still very much in use and should not be taken out of Wikipedia mainspace in any way. LightandDark2000 (talk) 18:24, 13 April 2018 (UTC)[reply]
  • Keep, but mark inactive/archaic portals as "Historic" – This is my compromise proposal, assuming that something actually comes out of this RfD. However, my original vote (above) still stands. LightandDark2000 (talk) 18:35, 13 April 2018 (UTC)[reply]
You don't get 2 !votes. --Ahecht (TALK
PAGE
) 21:18, 13 April 2018 (UTC)[reply]
I'm not voting twice. I'm specifying my opinion on this a little more. I oppose deleting all of the portals outright, but I'm open to the option I just mentioned above (and other similar proposals by some other users in some of the votes earlier above). LightandDark2000 (talk) 04:38, 14 April 2018 (UTC)[reply]
  • hold - there is little data on the readers. They get quite a few page hits and if automated I'd see them as a good way to display featured content. Need data from readers before we delete wholeslae. Cas Liber (talk · contribs) 19:55, 13 April 2018 (UTC)[reply]
  • Question: What are the currently best-maintained portals? So we can compare with non-maintained ones, for an idea of cost-benefit for a project-wide overhaul.    — The Transhumanist   21:15, 13 April 2018 (UTC)[reply]
  • Oppose - Portals are a great way to explore the millions of Wikipedia articles. They allow to find interesting, unexpected facts. There are issues with portals than can be solved by the community of editors, with tools such as random article selections. --NaBUru38 (talk) 21:54, 13 April 2018 (UTC)[reply]
  • Support - Redundant, useless, and not maintained very well are the words I would use to describe portals. If I am a visitor, I'd just use the search and not go through portals. I do think that the compromise provided by LightandDark2000 is also a good idea, keeping major and active portals. ITSQUIETUPTOWN talkcontribs 03:35, 14 April 2018 (UTC)[reply]
  • Oppose as a mass deletion - The argument that there are some bad or out-of-date portals does not seem to me to justify removing all portals, any more than some bad or out-of-date articles justify removing all articles. Also, I think there will be considerable loss of goodwill from those individuals who do actively maintain portals, possibly to the extent of losing them as contributors entirely. I think a better outcome from this discussion would be a slowly rolled-out campaign to propose deletion of *specific* poor/out-of-date portals. This may either spur individuals to update those portals (and save them) or result in the deletion of those portals. I say slowly-rolled-out because if a person is involved with multiple portals and decides to update them, we should give them time to do so and not put all of them up for deletion simultaneously which would make it impossible for them to update them all. Kerry (talk) 04:51, 14 April 2018 (UTC)[reply]
  • Oppose There is a certain question about whether or not this entire RfC was poisoned based on the inadequate wording of the question. Obviously, all portals should not be deleted. There are portals that Wikipedia themselves maintain and rely on, and which are rather popular. We don't need to blow it all up just because some of the more obscure portals don't get much attention. Nonetheless, there is a question to be made about what could be done about portals that barely crack even 100 views a month (a very generous deadline imho). Portals seem to be a more niche thing that a normal viewer may not want to view but an experienced Wikipedian may visit frequently especially as a topic they're interested in. Though it seems that the very way that they're advertised is the issue. I went through some of the portals via "what links here" feature and find that they're most relegated to the last section of the page, after see also, where barely few readers make it through and it seems that by only luck you would find the link to X portal. This is unacceptable, and probably the main reason that portals are not utilized. They are but a scarce link near the last of a page, barely even a footnote, led alone enticing a reader to click them. I don't think all portals should be removed, but they should be in a more accessible, more GUI-friendly (click me to learn more about X topic) sort of thing. Tutelary (talk) 06:46, 14 April 2018 (UTC)[reply]
  • Support Delete all portals except Portal:Current events, Portal:Science, Portal:History, and Portal:Tropical cyclones, all relatively active. Buckshot06 (talk) 09:27, 14 April 2018 (UTC)[reply]
  • Oppose, portals usually provide one-stop overview of each topic and related articles. Skimming through the main article of the topic is not an easy way to reach those related articles; and browsing through categories/indices is a really horrible way to find things, especially when you don't know what you are finding by its name.

    One might not use portal when they know enough about the topic, but that doesn't negate their usefulness for beginners; it also provide pointers to good/featured articles (and some cases, recent-event articles) on topic of interest. Like Tutelary said above, their presence in relevant articles should be more prominent to encourage more uses. If specific portals are inaccurate or outdated, deal with them case-by-case; turning those into automated ones is nice too. But proposing mass-delete? That is careless.

    Nvtj (talk) 09:36, 14 April 2018 (UTC)[reply]

  • Oppose They are not doing any harm, and can be useful to some users for finding information easier. -Quickfingers (talk) 13:39, 14 April 2018 (UTC)[reply]
  • Support I have been editing here for over five years and almost never pay any attention to any portals (other than, as noted above, Portal:Current events), much less edit them. I have almost always ignored them as they seem to perform basically the same function as sidebars and footer navboxes, but in an unnecessary separate namespace that keeps them pointlessly isolated from the articles they try to link together. Thus the portal namespace/system seems not to serve a purpose as it is now, and will only become more out of date and ignored if it is not eliminated. Every morning (there's a halo...) 13:45, 14 April 2018 (UTC)[reply]
  • Support Many of the portals are not being actively cared for, and as such, are not very useful. I would argue that many casual users of Wikipedia would not ever use a portal to find any information on Wikipedia. Jpmanalo (talk) 13:47, 14
  • Oppose. While some portals might be poorly maintained, the same might be said of many articles. Mass portal deletion seems a very severe way of solving what might not be much of a problem anyway. I've used Portal: Astronomy recently to get opinions (and traction) on an article I started. It gets about ~150 views a day and is maintained. Trashing editors' valuable work would be a negative, not positive, action. Richard Nowell (talk) 13:58, 14 April 2018 (UTC)[reply]
  • Support, I'm afraid they're basically edit-only pages, readers aren't interested in them, and this reader has never used one to find anything. We have plenty of simple and direct ways to get to pages, without even mentioning Dr. Google. Chiswick Chap (talk) 14:09, 14 April 2018 (UTC)[reply]
  • Support - What others have said above in support of this. --Malerooster (talk) 15:46, 14 April 2018 (UTC)[reply]
  • Oppose This is a bad solution to a "problem" that is hardly a problem at all, and the quality of the discussion does not inspire confidence in the process. XOR'easter (talk) 15:50, 14 April 2018 (UTC)[reply]
  • Kind of Oppose I am new to Wikipedia, and I do not use portals a lot. However, one portal that is viewed a lot (by me, and many others) is Portal:Current events. This is viewed several thousand times daily (45,180 times today as I type this). What would happen to it if the Portal namespace was removed? SemiHypercube (talk) 17:23, 14 April 2018 (UTC)[reply]
  • Support the cessation of portal work. There is no consensus for outright deletion so I'd recommend instead a grace period of several months to merge relevant content (for those portals actively maintained) to projectspace. It might be useful, for instance, to import some portal content for WikiProject pages (which, in my opinion, should all be repurposed as subject area noticeboards anyway). If the content is imported, the pages must be preserved for attribution history and thus redirected. Tag the remaining portals and those that aren't merged/redirected within several months should be deleted, though it'd be reasonable (as always) to temporarily restore that content if someone wants to merge after the deadline. There are many case-by-case discussions to be had, but only once we have general agreement on the fate of portals.
The core question that isn't being asked enough here is what portals contribute to our purpose of building an encyclopedia. There is no shortage of lost causes to which we apply ourselves, from the marginally notable to the reams of talk page debate over single sentences, so there is no guarantee that portal maintainers will suddenly decide to steward a high-level topic overview article: The point of editor time spent is neither here nor there. The point of readership is more salient, but gets into a debate over what readership counts as significant, which is the wrong debate. Better to ask what portals contribute in service of a better encyclopedia. Are they actively funneling users from general interest into more specific articles? Are they surfacing content to draw readers further into their own general interests? How are readers even finding portals aside from the main page welcome bar and the bars that sometimes grace the underside of navboxes? I haven't seen any assuaging answers to these questions. Our existing systems of high-level topic overview articles (for readers) and WikiProject/noticeboards (for editors) appear to fulfill all of the objectives of portals, with the added benefit that they already exist and have a dedicated user base. I hope that the work of portal maintainers can be welcomed into these other areas of the encyclopedia. czar 17:27, 14 April 2018 (UTC)[reply]
  • Oppose mass deletion. As some users have discussed above, use WP:Miscellany for deletion for individual portals, with marking as {{historical}} as an option. Polyamorph (talk) 18:38, 14 April 2018 (UTC)[reply]
  • Support. There are so few useful portals that a dedicated namespace is not only unnecessary but invites the kind of useless cruft that does indeed infest it. The Main page is a portal but is not in Portal namespace, others don't need to be either. Any genuinely useful "Portal" information can be integrated into the main article space easily enough, typically in an "Introduction to...", "List of articles about ...", "...overview" or even "...portal" article. Obviously, a transition period would be needed while active portal editors redesigned their information. For example Portal:Current events could be moved to Current events portal (although I don't believe it has any place in a serious encyclopedia, see preceding comment re Wikipedia's purpose, it should be merged over to Wikinews, but that is a different issue). — Cheers, Steelpillow (Talk)
  • Oppose there is obviously no consensus to delete the portals and editors should not be continually bullied to achieve big projects within a couple of months. Suggest only updated portals be linked from mainspace with the out of date ones being delinked except to Wiki Project pages until they are brought up to speed. Also, support the use of automation to update portals as used on the Spanish Wikipedia which is detailed in one of the following subsections, thanks Atlantic306 (talk) 18:51, 14 April 2018 (UTC)[reply]
  • Oppose I have to agree, this is an end-run around WP:MFD. This issue need to be concretely dealt with at MFD before the presumption of a mass deletion. --Mark viking (talk) 20:34, 14 April 2018 (UTC)[reply]
  • Oppose – As a reader who rarely edit the English Wikipedia, I find the portals very very useful. Guycn2 · 20:42, 14 April 2018 (UTC)[reply]
  • Oppose I watch a few of them, i.e Portal:Jane Austen (much of the content written by a specialist) and Portal:Children's Literature. Each gets page views and I think each of these is an asset to the project. It's a type of shop window, a place to stop, look, browse, and maybe decide to enter. They serve the readers; the editors who had the energy to set them up (many of whom are now gone) are to be commended, as are current editors who continue to build and tend portals. Victoriaearle (tk) 21:08, 14 April 2018 (UTC)[reply]
  • Oppose. I find some of them to be useful in regular use. Why not delete on a case by case basis? Xxanthippe (talk) 22:32, 14 April 2018 (UTC).[reply]
  • Weak oppose, while it is true that due to the fluctuations of editor ship, usually trending downward, it is difficult to maintain content, the first thing that came to mind is WP:NOTPAPER, then WP:NOTFINISHED. Until there is time for improvement I like the idea proposed by ToThAc (talk · contribs) in marking the portals as Template:Historical, until something can be done that is constructive with the content.--RightCowLeftCoast (talk) 22:51, 14 April 2018 (UTC)[reply]
  • Conditional Support I only Oppose this if they are deleted. They should be marked as historical instead. MoonyTheDwarf (talk) 23:38, 14 April 2018 (UTC)[reply]
  • Support especially to re-iterate and highlight the points brought forth by Czar (talk · contribs) above. GenQuest "Talk to Me" 04:03, 15 April 2018 (UTC)[reply]
  • Support The portal space is full of abandoned, outdated and often inaccurate content. This is true even portals about major topics. Case in point, Portal:Philosophy has a talk page that hasn’t been used since 2014, and an In the News section which lists events from 2010 to 2011. Additionally, I am concerned that portals can be used to push ideologies and agendas; just a few years ago myself and a few other editors tried to delete a pro-ISIS portal. While many editors have suggested improving the portal systems, this is going to take an utterly massive amount of effort for something that few readers use or even know exists. Quite frankly, I have never understood what our 1,500+ portals are supposed to be accomplishing. Going forward, I would suggest archiving (not deleting) most portals. I would be fine grandfathering in the current events portal as well as a few well-maintained and actively used portals. Spirit of Eagle (talk) 05:40, 15 April 2018 (UTC)[reply]
  • Strongly Oppose Are you serious? A lot hours of work was used to build these portals, a simple deletion would annoy a lot of volunteers, so please stop these proposal!!!--Sinuhe20 (talk) 07:22, 15 April 2018 (UTC)[reply]
That the "deletion would annoy a lot of volunteers" is not a reasoned motivation for keeping the portals. What is put into question here is their usefulness and content accuracy. The goodness of the encyclopedia should come before any personal whim of the users.--2.37.216.231 (talk) 13:37, 15 April 2018 (UTC)[reply]
Comment The term "usefulness" is really arbitrary because it's up to one person or another to determine what that is, and that becomes personal preference. That starts to delve into the range of WP:IDONTLIKEIT which is never a reason to delete anything in Wikipedia. As to "content accuracy" -- this is a valid issue, and if the content is not accurate then the obvious conclusion is to edit the content. Once in a while we find content that is so poorly assembled that deletion is the best step, but that's not the case here... certainly not a blanket deletion for every portal.--Paul McDonald (talk) 14:30, 15 April 2018 (UTC)[reply]
  • Oppose You can just delete the "obsolete" portal(s) instead of removing all of them. Lots of people spending their time building a beautiful and informative portal. Portal also acts as a place to find people that has same interest as you and/or searching a certain article rerlated to a certain theme. Because Wikipedia is not only about making article together, it's also a place to connect people around the world. flixwito ^(•‿•)^ (talk) 10:40, 15 April 2018 (UTC)[reply]
This is really the worst of the motivations that have been put forward to save the portals! Wikipedia is not a social network! The aim of this project is to build an encyclopedia of good-quality (academically supported) content, not to make friends sharing the same interests!--2.37.216.231 (talk) 13:37, 15 April 2018 (UTC)[reply]
While it's true that Wikipedia is not a social network, I disagree with the logic to the step that because it's not a social network there is no value in collaboration with other editors who are enthusiastic on the same general topic or topics. Collaboration is a good thing and if portals help promote collaboration, then that's another reason to keep them around.--Paul McDonald (talk) 14:33, 15 April 2018 (UTC)[reply]
Wikiprojects already serve the purpose of gathering together editors to collaborate on a topic. Portals aren't needed for this reason Cesdeva (talk) 15:11, 15 April 2018 (UTC)[reply]
First of all Wikipedia is a social network as well (but one with a specific purpose). Secondly it is true that much or all functions of portals could be taken over by Wikiprojects (or vice versa actually), but the conclusion from that is (at best) a merging or migration (with a potential phasing out of one) and not a wholesale deletion as suggested above.--Kmhkmh (talk) 15:36, 15 April 2018 (UTC)[reply]
Vice versa? Portals don't even function well for their primary purpose, nevermind incorporating the workings of a wikiproject. Many portals already come under the 'jurisdiction' of wikiprojects, yet they still have major issues. Shifting namespace won't solve anything. Cesdeva (talk) 16:03, 15 April 2018 (UTC)[reply]
Additional comment I further disagree with the premise that collaboration should only come from one source (a "project" or a "portal") -- collaboration can and should come from multiple sources if possible. Further, I do not believe that "need" is the proper measure... do we "need" portals? We don't "need" Wikipedia (see WP:NEED).--Paul McDonald (talk) 22:28, 15 April 2018 (UTC)[reply]
  • Oppose. The proposal is far too extremist for the "problem" that it is designed to solve. If there are portals that are deleterious to the encyclopedia (as posited by the supporters), then those particular items can be considered for deletion or other remedial action such as improvement. No need to deploy thermonuclear weaponry for a problem that can be dealt with by more focused and conventional means. Frankly, I'm surprised that almost half of those voting would support such an extreme measure ... worrisome. Cbl62 (talk) 16:12, 15 April 2018 (UTC)[reply]
  • I can't support the blanket deletion of all portals as some of them are clearly useful. Portal:Current events, for instance, is well maintained, provides a useful resource which isn't duplicated by anything else, and gets 30-50,000 hits a day. Having said that the OP does have a point that most portals aren't maintained and aren't terribly useful, and I think it's fair to say that the general idea hasn't caught on. As a result I would support the general deprecation of the concept. If we want to retain a portal then it should be possible to show that the portal adds significant value to the encyclopedia which isn't duplicated by something else. If a portal doesn't meet this standard (and IMO most of them don't) then it should be archived or deleted. Hut 8.5 17:52, 15 April 2018 (UTC)[reply]
  • Support. I think portals were an interesting concept at the time, but they haven't turned out to actually serve the purpose or function that they were originally intended to — a lot of them have simply been abandoned and/or are badly outdated, and there's very little editor commitment to actually staying on top of making them what they were meant to be in theory. Bearcat (talk) 19:23, 15 April 2018 (UTC)[reply]
  • Support Portals were a fad in web design whose time has come and gone. Shock Brigade Harvester Boris (talk) 23:41, 15 April 2018 (UTC)[reply]
  • Oppose On the one hand I can see the merit in arguments like the one above, that they are a relic of early 2000s thinking about web design and how users would approach Wikipedia, thinking that has not proven correct in the long term. But by that same token we ought not to delete them for that reason. I don't think we can say that just because they don't attract a lot of views now they never will again. Future web usage trends could change, and it would be easier to have the portals around should they become valuable in some way rather than have to rebuild them or some equivalent from scratch. Daniel Case (talk) 02:09, 16 April 2018 (UTC)[reply]
Keeping portals on the off-chance that they become popular again is CRYSTAL, so you've actually invoked policy which is the antithesis of your argument. --Iryna Harpy (talk) 18:55, 16 April 2018 (UTC)[reply]
  • Support but don't delete them. Mark portals as historic and remove links from mainspace. I agree that outlines and indexes work much better than portals. Rreagan007 (talk) 05:13, 16 April 2018 (UTC)[reply]
  • Strong Oppose. If you have problems with specific portals, feel free to nominated them for deletion. However, there are many portals (especially those that are featured) that are excellent. Interestingly, featured portals are the ONLY featured content to never be featured on the Main Page. This has been proposed several times (having a rotating once-a-day link to a portal, or one that loads randomly each page load based on a list of featured portals), but people seem to think it would be a lot of work (it wouldn't be...a feature used in many portals could be used to create it). It takes a lot of work to get an entire portal up to featured status (I've helped with two of them), and if they are built effectively, they don't require much maintenance. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 07:00, 16 April 2018 (UTC)[reply]
  • Oppose I agree that many of the portals are out of date and useless, but there are a few portals that are well maintained and a good source of information. I don't think that they should all be deleted. Rather, each portal should be evaluated and determined to see if it is inactive or not. Those that are can be deleted but others should be kept if they have active support. Draconicfire (talk) 14:05, 16 April 2018 (UTC)[reply]
  • Oppose deletion but support marking portals historical and/or moving to different namespace. I do not see any reason to remove people's ability to read historical portal content, such access would not waste editors' time, and old data on portals will certainly be of interest to some. Also, it's important that certain portals such as Portal:Contents and Portal:Current events are exempted or kept active in a different namespace, as has been discussed multiple times in this proposal -Cake~talk 14:53, 16 April 2018 (UTC)[reply]
  • Support, for reasoning stated previously. Isseubnida (talk) 14:57, 16 April 2018 (UTC)[reply]
  • Conditional Support I would be more in support of pruning and/or freezing portal creation. Some (one?) of the portals are still quite useful, such as Current Events. As long as we don't lose pages that matter, I don't care if portals are overhauled or phased out. But I would hate if my favorite news source disappeared over night. Also, Current Events is a nice time capsule, so it would be a shame for all the years of curated news articles to just disappear.Spoonlesscorey (talk) 15:06, 16 April 2018 (UTC)[reply]
  • Highly oppose Deleting such a good fixture to Wikipedia would disappoint those who used to frequent the portals. In fact, this year alone, I've had more portal edits than anything else. Call me when you get the chance 15:17, 16 April 2018 (UTC)[reply]
  • Strongly Oppose I find it to be a very useful feature that gives a handy and concise summary about a topic. A relative lack of views should never impact an encyclopedia's content, otherwise you could delete 90% of it. --Therexbanner (talk) 16:00, 16 April 2018 (UTC)[reply]
  • oppose.The portals have been very useful. I use the news one dailyArglebargle79 (talk) 15:20, 16 April 2018 (UTC)[reply]
  • Oppose for Contents, Featured Content, and Current Events; Neutral for everything else — the Portal concept is good when done well. A portal serves as a useful topic-based contents page for readers when people actually use it and edit it. However, portals which don't get viewed or edited much should be marked as historical so people don't expect them to be up-to-date. — pythoncoder  (talk | contribs) 16:20, 16 April 2018 (UTC)[reply]
  • Oppose I am far more of a reader “outsider” than editor “insider”. I am not informed about many of the issues involved creating/supporting portals, and have no opinion there. As a content consumer, i read Portal: Current Events every day. Other portals i stumble across as i use Wikipedia, and generally seem useful (from memory). Now, it may be improper for me to use Portal: Current Events as my daily newspaper, but when i go to Wikinews and the headlines don’t change for days and those of Portal: Current Events do, the *de facto active* news source is Portal: Current Events on Wikipedia. I would hate for that to go away with no replacement. It appears that some portals are useful and maintained and some are not, so hopefully there is a less binary approach to resolving portal issues. Sonic Purity (talk) 16:28, 16 April 2018 (UTC)[reply]
Portal Current Events would continue in Wikipedia space. No one wants to close it down. Legacypac (talk) 16:31, 16 April 2018 (UTC)[reply]
  • Strongly oppose The current events portal is perhaps one of the greatest things about Wiki and the reason I became an active editor in the first place. Would be a complete disaster to undo all the hard work me and many others have, and continue to put into it. I can understand inactive portals being deleted but the current events portal needs to remain. GWA88 (talk) 17:12, 16 April 2018 (UTC)[reply]
  • Oppose - largely as pythoncoder's !vote above I am primarily motivated to keep for the portals that promote content and help explain and present newsworthy materials. Also per Andrew D.'s !vote I do not think deleting portals will be beneficial to the project as a whole, just because something might be outdated does not mean it has to be deleted, incompleteness is a call for the content to be improved, not for it to be tossed out (see WP:DINC). Inter&anthro (talk) 17:18, 16 April 2018 (UTC)[reply]
  • Conditional Support I personally only use the Current Events portal, however I think the other portals are outdated.
  • Oppose - Why not nominate them on their individual merit rather deleting them in bulk? There are over 1 million WP articles which are in poor state that doesn't mean delete them in bulk. They will improve if we decrease their quantity. Störm (talk) 18:02, 16 April 2018 (UTC)[reply]
  • Oppose While a large portion of portals are not very popular, you're throwing the baby out with the bathwater in generalizing it to ALL portals. For instance, during the last month, Portal:Current events has had 1.4 million pageviews (43,500 per day), Portal:Featured content has had 200,000 pageviews (6,400 per day) and Portal:science has had 39,400 pageviews (1,200 per day) These compose a mere 0.2% of total Main Page views, but keep in mind that the Main Page is the number one visited place on the 5th most popular website on the entire internet, it's bound to get thousands of times more views than even a prominent article (Stephen Hawking only got a third as many views as the main page on the day of his death!) exoplanetaryscience (talk) 17:19, 16 April 2018 (UTC)[reply]
  • Oppose I volunteer to help find/make a content visualizing tool which organizes related pages into an easy to understand/navigate structure...

and since I don't know any other content organizing tools besides portals, that bit of volunteering coincides with a sense of opposition. I'm coming from the direction of the highly viewed, necessary to most educational institution portals, like Chemistry, Mathematics, Linguistics, etc. Having the pages for these portals all collected in one place isn't perfect, but at the moment it creates a far more accessible method to view many of the co-related pages for an intimidating branch of knowledge. I salute whoever thought to put a blanket delete for the namespace type of data though, invigorating debate has ensued from what I read. Was such a radical proposal that it made me join the conversation, and this is the first time I've done more than solitary edits, which should give everyone some idea of how important portals are to me, and again, only the ones that represent the material used to teach the "necessary subjects." I think there's a lot of promise, and perhaps a solution is better automated portal maintenance. --Silex.logike (talk) 18:49, 16 April 2018 (UTC)[reply]

  • Oppose I do not think all portals should be deleted. I would support marking each Portal with Template:Historical but allow any portal editor to remove the template if they think the Portal is active. Any Portal which does not remove the template after 12 months can be deleted by WP:MFD. --Frmorrison (talk) 19:05, 16 April 2018 (UTC)[reply]
  • Weak support Weak because I'm not very expert about portals. In fact, I've been actively looking up things on Wikipedia for 12 years and editing almost that long and have never used a portal. I assume that I could find out with a few minutes of work, but I don't even know how to find or use portals, and have never had a need for them. Which I think states the situation for most Wikipedia users. Plus, this kind of a method for finding information somewhat outdated because it is less effective/ more difficult to use. For example, compared to a search bar. It requires the user to learn the (portal) categorization method in order to use it to find something.North8000 (talk) 19:19, 16 April 2018 (UTC)[reply]
  • Oppose Portals being deleted in one sweep, is not something I could possibly endorse. As noted earlier Some portals are highly trafficked while other have very low usage, similar to Featured vice Stub articles. Vwanweb (talk) 21:18, 16 April 2018 (UTC)[reply]
  • Section break – post new responses below.

Please post new responses below. This provides a convenient entry in the TOC to help reduce scrolling.    — The Transhumanist   22:25, 16 April 2018 (UTC)[reply]

  • Support - I don't think portals accomplish anything for anybody, frankly. Carrite (talk) 02:04, 17 April 2018 (UTC)[reply]
  • Support WP:TLDR, but I don't really think there is any purpose for portals above projects, cats, lists and templates.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 02:43, 17 April 2018 (UTC)[reply]
  • Support - I've worked in a couple of Portals in the past, but I really never visis them. They're quite useless, containing incorrect and outdated info. Standard links, navigation templates, and categories offer plenty of possibilities all the info one wants to find. Joshua Jonathan -Let's talk! 04:23, 17 April 2018 (UTC)[reply]
  • Strongly Oppose Wikipedia is a necessary reference and is often the best source of information. I visit the 'Current Events' portal every day because it provides the most neutral roundup of daily events with all sources cited. The diversity of events reported are fantastic and overall the portal is very well done and extremely useful. Please do not remove this section!!!

Section break - continue survey here

  • Oppose. Keep portals, and upgrade them – The initial design concept for portals was that they would each be a main page for a subject. The reality has been that most of them have become a snap shot (one day's version) of a main page for their respective subjects. Imagine if Wikipedia's main page never changed its content. That portals never became what they were envisioned to be is the crux of the matter here.
Looking over the problems of portals reported in the discussion, they boil down to 1) out of date / lack of maintenance (lack of volunteer labor) 2) useless (static / unchanging) and 3) low traffic (few repeat visits). These are problems we can solve. The support to do so is obvious from the above discussion.
The 3rd problem (relatively low traffic) is misleading, for two reasons. First, portals as a whole get more traffic now than ever before, with well over 20 million views per year. Second, portals get their traffic internally, rather than from external search engine results.
Please keep in mind that portals are an internal feature intended to enhance the user experience once the user is already here. Traffic is higher for those portals that provide ongoing services that users return to them for.
But, most portals do not have that level of volunteer labor available to them. Therefore, automatically-generated dynamic content, for example, in the form of randomly generated on-topic selections, automated news feeds, and so on, would be a valuable service, turning the portals into a form of periodical or newsletter.
Also, with such pages in place, who knows what enhancements could be made to them in the future. Technology is accelerating as we speak.
I believe the solution is automation, with configurability (to provide flexibility to portal designers). Refreshing the intro entry, using selective transclusion, so it doesn't go stale is one form of automation that can help.
Obviously, there is no consensus to delete. But, the message is loud and clear that the status quo is unacceptable. The portals need a lot of work. They need an upgrade, to turn them into what they were originally intended to be: main pages for their respective subjects. It's time to roll up our shirt sleeves, and get to it. I foresee a major and fun collaboration coming on. You can expect to see me there. Sincerely,    — The Transhumanist   22:17, 16 April 2018 (UTC)[reply]
  • Strong Oppose I come to Wikipedia every day and read the Current Events Portal. Should there come a day when there is no Current Events Portal, I will discontinue my use of and support of Wikipedia as a whole.23.251.93.185 (talk) 23:04, 16 April 2018 (UTC)Dan[reply]
Threats to leave, stop using the site, or even stop donating are generally responded to with an eyeroll or a laugh. Try using other Modes of persuasion such as logic-based ethics or practicality. Ian.thomson (talk) 23:22, 16 April 2018 (UTC)[reply]
They are? I don't see this as a threat but an actual statement that the editor gets value from the portals and will likely not return if they are gone. But I didn't know that I was supposed to roll my eyes at this...--Paul McDonald (talk) 01:00, 17 April 2018 (UTC)[reply]
  • Oppose Portals are useful for navigation. I always use them, especially current events. Persistent Corvid (talk) 23:33, 16 April 2018 (UTC)[reply]
  • Support and first save necessary content in another namespace if needed; and move portals such as Current events to Wikipedia-namespace. Where for example Wikipedia:Your first article, that is also one of the most visited pages, currently is situated. --Treetear (talk) 00:35, 17 April 2018 (UTC)[reply]
  • Support in general. Portal:Current Events, in particular, probably has more WP:BLP violations than mainspace. Cavaet: Most of my activity in Portal:Current Events was reverting "the Michigan Kid", and some reversion of people adding their own information to current year articles as well as Portal:Current Events, but the entries are a good place to hide WP:BLP violations. Needs a more nuanced responce, but the first step is to unlink them from mainspace and Wikipedia space. — Arthur Rubin (talk) 00:51, 17 April 2018 (UTC)[reply]
  • Oppose. This would remove the Current Events portal, which I for one find incredibly useful and better for use than most official news sites. Anon e Mouse Jr. (talk) 01:01, 17 April 2018 (UTC)[reply]
  • Strongly Oppose
I'm posting this again after the Section break because I didn't see this within the first 15 minutes of reading through this discussion.

I love Wikipedia and reference it as my first source when learning about a new topic, but I visit the 'Current Events' portal at least once a day because to me this is the equivalent of reading the morning newspaper that was the standard about 50 years ago. The diversity of events which individuals take the time to report there is unrivaled. Often I learn of events that only much later become TV-news worthy or never make the circuit. In a sentence, 'The 'Current Events' portal enriches my life and to lose that would be a shame.' Please do not remove this section just because you find it unnecessary, please rather consider the many people who don't contribute but appreciate the thing for what it is. This comment is only my second time ever editing a Wikipedia page. The other time was in the 'Current Events' portal. So there again is another benefit to it, it draws in visitors and entices them to become contributors. Please, PLEASE, let it be.

Something that I've done in the past, please forgive my ignorance here, in relation to clearing disk space on my computer, has been to search for empty folders in my directory and delete them using a third party utility. As this applies to what seems to be the appeal to many here of deleting the portals, mainly clearing up unused namespace, could something similar not be done? If a portal hasn't been edited in a certain amount of time, could there not automatically be a message posted at the top of it, like the one that led me to this discussion, notifying users that unless the portal logs some activity within the next short time frame, it will automatically be deleted? Seems like a good compromise without killing the whole program.
Thank you to who ever just moved this to the bottom of this section. Duh, I didn't see that either. Thanks again.

66.76.14.92 (talk) 01:03, 17 April 2018 (UTC)[reply]

Notwithstanding that Portal:Current events was tagged, no one has proposed deleting it. It will likely be moved to Wikipedia:Current events Legacypac (talk) 03:43, 17 April 2018 (UTC)[reply]
  • Comment: Concerning the issue of low reader traffic for a number of portals, perhaps it would be better to move the "portal" portion to the very end of each portal title, such as Tropical cyclones portal, Current events portal, etc. A renaming campaign to this new format would probably attract a lot more readers to the various portals, especially for the newer ones. At least it's better than just simply deleting all of them. LightandDark2000 (talk) 02:25, 17 April 2018 (UTC)[reply]
I can't see how rearranging the names will improve the usefulness Legacypac (talk) 03:43, 17 April 2018 (UTC)[reply]
  • Support deprecating/ending the creation of new portals, oppose deletion en masse. The good ones can be kept, the bad ones can be {{historical}}'d or deleted on a case-by-case basis. FACE WITH TEARS OF JOY [u+1F602] 04:03, 17 April 2018 (UTC)[reply]

First portal bot request submitted

See Wikipedia:Bot requests#Bot needed for updating introduction section of portals.    — The Transhumanist   04:11, 15 April 2018 (UTC)[reply]

Discussion: Ending the system of portals

Some exception would need to be made for the Community portal. This has been getting over 10,000 views daily since it was linked as one of the three exits ("Start helping") from the New user landing page, introduced in conjunction with ACTRIAL. The Help Out section is essential and should be kept as visible as possible. Parts of the Community bulletin board are dusty, but just need more regular maintenance: Noyster (talk), 15:16, 8 April 2018 (UTC)[reply]
Seeing as this Community Portal isn't even in the "Portal" namespace, I don't believe it would be affected either way. Good page too keep in mind, though. ~Mable (chat) 15:22, 8 April 2018 (UTC)[reply]
Indeed, I did think of that, but I also saw that they're not in portal space, and wouldn't be affected. Galobtter (pingó mió) 15:41, 8 April 2018 (UTC) Also, it is entirely different from general portals, being editor facing only (which is presumably why it is in WP space not portal space) and does an okay job of helping editors Galobtter (pingó mió) 15:46, 8 April 2018 (UTC)[reply]
...And of course even if there is the occasional useful portal, we can easily make an exception -- possibly with a move to a better namespace. What are the top ten most-visited pages in the portal namespace? --Guy Macon (talk) 16:03, 8 April 2018 (UTC)[reply]
I'd say 90% likely the top 8 are the ones on the main page, at the top right. But like I said above, I don't think people actually find the ones on the main page useful either, they just click it randomly Galobtter (pingó mió) 16:12, 8 April 2018 (UTC)[reply]
Here's a pageview graph of those main page portals, anyhow - extremely interestingly, they group into 3 clear bunches Galobtter (pingó mió) 16:24, 8 April 2018 (UTC)[reply]
I think the top-visited portals are those linked from the left sidebar, Portal:Contents and Portal:Current events and, to a lesser degree, Portal:Featured content (pageview graph). The arguments for deleting the other 1500 portals may not apply to these. -- John of Reading (talk) 16:49, 8 April 2018 (UTC)[reply]
Ahh, I forgot about them. These seem like they'd be fine in wikipedia namespace, honestly, and would be exempted; they aren't really like the other portals at all, and just seem sort of dumped there because they vaguely explore something Galobtter (pingó mió) 16:58, 8 April 2018 (UTC)[reply]
Agree Current events is a every active portal and should be moved into a different namespace if all Portals are deleted.  Nixinova  T  C  04:39, 11 April 2018 (UTC)[reply]
@Galobtter: To set everyone's mind at ease, please add an amendment to your proposal (at the very top) exempting Portal:Contents, Portal:Current events, and Wikipedia:Community portal. Also consider exempting Portal:Featured content as it is the front page for the various "Featured" content production departments, and has a link on the sidebar menu that appears on every page of Wikipedia. Thank you.     — The Transhumanist    13:26, 11 April 2018 (UTC)[reply]
@Galobtter: @The Transhumanist: In addition, since there seems to be at present significant opposition to outright deleting the namespace and all related pages, maybe there could be some clarification that deprecation/marking as historical (as opposed to outright deletion) is an option too. Some of the oppose votes seem to be more due to the outright deletion proposal rather than or not just because of a support of the portal system. Narutolovehinata5 tccsdnew 13:31, 11 April 2018 (UTC)[reply]
I'm uncertain whether how exactly one should amend a proposal while it has received significant comment - Narutolovehinata5 feel free to add a note like "Note: Certain portals: ...have been suggested for exclusion; other options instead of deletion has also been suggested" or something along the lines of that, keeping neutrality of course Galobtter (pingó mió) 14:56, 11 April 2018 (UTC) and @Transhumanist: too Galobtter (pingó mió) 15:38, 11 April 2018 (UTC)[reply]
I think it would seem rather inappropriate were the nominator to suggest altering or adding to the wording of the RfC in this way now that it is running, and numerous people have expressed their views. Would that be with the hope of better securing the desired outcome? Was not the removal and relocation by the nominator of previous comments also intended to keep the proposal clear and concise? Nick Moyes (talk) 03:27, 12 April 2018 (UTC)[reply]
Namespace ID Namespace Total pages Pages with redirects Pages without redirects
100 Portal 148868 13188 135680
101 Portal talk 36710 2701 34009
  • Question - If the current portal system ends, and the portal namespace disappears, presumably this would not prohibit certain active WikiProjects from creating a portal-like page within the WikiProject space, correct? — Rhododendrites talk \\ 17:16, 8 April 2018 (UTC)[reply]
Yes, but the main thing is that they wouldn't be linked from articles - wouldn't be reader facing - and thus wouldn't be at all like the system currently here. Thus ending Galobtter (pingó mió) 17:19, 8 April 2018 (UTC)[reply]
  • Broter I do understand that people have spent a lot of time on these, and that is is frustrating to see one's work deleted. However I don't see that portals help much with navigation - since they produce random articles, that isn't really navigation; outlines like Outline_of_science do a far better job. Galobtter (pingó mió) 17:23, 8 April 2018 (UTC)[reply]
WP:BLUDGEON. --Guy Macon (talk) 22:04, 10 April 2018 (UTC)[reply]
The following discussion has been closed. Please do not modify it.
  • Please keep the existing portals.--Broter (talk) 17:26, 8 April 2018 (UTC)[reply]
I invested so many hours into portals. Please keep the existing portals.--Broter (talk) 17:31, 8 April 2018 (UTC)[reply]
List of Portals which were created by myself or very much improved by myself:
--Broter (talk) 17:47, 8 April 2018 (UTC)[reply]
  • Compromise? Perhaps we should "mothball" or eliminate portals which haven't been edited or maintained for a certain length of time. Pegship (talk) 18:03, 8 April 2018 (UTC)[reply]

We should only delete the portals which are not maintained.--Broter (talk) 18:06, 8 April 2018 (UTC)[reply]

  • Hmmm, I wouldn't oppose keeping them in wikipedia space - there's no particular reason to prevent people from harvesting the portals if they feel it is useful; and some could be useful to move into the main pages of wikiprojects as a "face". Beetstra I think it'd be better to store them in wikipedia space, free for people to use if there's anything valuable (or not). Easier than force delinking and full protection IMO Galobtter (pingó mió) 18:19, 8 April 2018 (UTC)[reply]

Broter, you can move any portals you have created to subpages of your user page. Some subpages get a lot of traffic, such as my WP:1AM page. --Guy Macon (talk) 18:30, 8 April 2018 (UTC)[reply]

  • We could phase them out by a) prohibiting creation of new portals b) PRODing each portal giving anyone who cares a week (or more) to salvage anything useful. c) shutting down any remaining portals in 3 months. Legacypac (talk) 20:35, 8 April 2018 (UTC)[reply]
  • Brainstorming: This is a good opportunity to radically re-think the Portal system, which isn't working well under its current inception. Feel free to pitch in with some alternatives for a simple mass-deletion. Here are some ideas:
  1. Convert them to links to WikiProjects. This would help readers become editors without the need to route them through the Talk page and a collapsible banner first.
  2. Turn them into Reference Desks for specific topics. While article Talk pages are strictly WP:NOTFORUM, I believe that "off topic" discussions between readers and editors could benefit both groups. We'd get an idea of what readers really want to know outside of our sometimes rigid system of articles, and readers would become contributors before they even know it.
  3. Turn them into links to Outlines or Indexes to serve as centralized "See also" listings per topic.
  4. Automatic listings of Featured content grouped by topics. See Bluerasberry's comment above (cf. Galobtter's for an opposing view).
  5. Limiting the number of portals should help concentrate our efforts. Suitable sets could be those featured on the Main Page, some of the top categories at Portal:Contents/Portals, those corresponding with Featured articles categories, or Core topics.
Some more wild ideas? – Finnusertop (talkcontribs) 21:28, 8 April 2018 (UTC)[reply]
  • If portal pages are moved/created in wikiproject namespace (e.g. Wikipedia:WikiProject Foobar/Portal) then this should (1) only be by or with the agreement of the wikiproject and (2) only be a single page (e.g. not the 45 pages currently in Category:Book of Mormon portal). DexDor (talk) 20:46, 8 April 2018 (UTC)[reply]
  • Would something else replace the links on the main page? It seems like a waste of space to leave almost all of the top banner empty. KSFT (t|c) 21:05, 8 April 2018 (UTC)[reply]
The mainpage is full of information. A little whitespace would be good, or make the rest of the box Wikipedia ... wider and thinner. Legacypac (talk) 21:23, 8 April 2018 (UTC)[reply]
Hey yes, this could be a great opportunity to update the 12-year old main page (only half-kidding!) Aiken D 21:40, 8 April 2018 (UTC)[reply]
  1. Portal:Arts 3,872 / day
  2. Portal:History 2,235 / day
  3. Portal:Biography 2,178 / day
  4. Portal:Science 1,413 / day
  5. Portal:Mathematics 1,404 / day
  6. Portal:Technology 1,398 / day
  7. Portal:Geography 1,063 / day

--Pharos (talk) 22:51, 8 April 2018 (UTC)[reply]

Those are 7 of the 8 portals on Main Page. The 8th there is Portal:Society which is number 8 in page views with 665 / day. Portal:Food with 429 / day is the most for portals not on the main page. linksto:Portal:Food currently says it has 8,045 links from mainspace. PrimeHunter (talk) 23:07, 8 April 2018 (UTC)[reply]
Major takeaway - put a link to something in the best position possible on one of the world's top visited pages and it only gets 665 to 3000 odd hits a day => total rejection by the public of this useless content. There is NOTHING wikipedia can do to drive more traffic than those 8 links. Legacypac (talk) 00:21, 9 April 2018 (UTC)[reply]
Is there any way to find out how many real links go to a particular page as opposed to links because it was added to a template? For example, 1-bit architecture has a huge number of links to it,[12] but if you look at the pages that contain the links they are almost all because it is included in Template:CPU technologies and don't give an accurate picture of how many people are interested enough in 1-bit architectures to link to it. --Guy Macon (talk) 23:25, 8 April 2018 (UTC)[reply]
I don't think that is possible, but It's somehing I've wanted to know for many years too (unrelated to the portals).--Pharos (talk) 23:36, 8 April 2018 (UTC)[reply]
User:PrimeHunter/Source links.js produces Source links on 1-bit architecture. It currently says 26 results in all namespaces (10 in mainspace). I also made {{source links}}. {{source links|1-bit architecture}} produces Source links. PrimeHunter (talk) 00:57, 9 April 2018 (UTC)[reply]
I've done a more comprehensive query, and besides the higher-placed pages that are not conventional portals, the stand-out of those not linked from the Main Page appears to be Portal:Dance, which had 2,227 / day pageviews in 2017.--Pharos (talk) 23:36, 8 April 2018 (UTC)[reply]
Portal:Dance was one of my random examples earlier with only 1,421 views in the past 30 days, meaning 47 per day. The page views graph since the first data in July 2015 [13] shows a jump from around 50 views per day to around 2300 from October 2016 to January 2018, and then back to 50. I don't know the reason but I suspect it's automated views and not humans. PrimeHunter (talk) 23:54, 8 April 2018 (UTC)[reply]
  • I don’t think the idea of turning them over t relevant projects is workable at a time when so many projects are inactive, just as the portals are. The fact that a small number are still being maintained is a credit to those doing so, but it doesn’t change the fact that the system as a whole has been largely abandonded. Beeblebrox (talk) 00:05, 9 April 2018 (UTC)[reply]
  • Regarding it being more effort than it is worth - at minimum this would be blanking templates that link to portals/removing templates like {{portal}} from mainspace; then marking portals as historical; this wouldn't be much effort that I can see. Then we can save fiddling about it, and prevent other people from wasting their time for the next 10 years on portals Galobtter (pingó mió) 03:53, 9 April 2018 (UTC)[reply]

Step 1 - take the portal links of the mainpage and Delete all the portal templates. Readers will not find the portals after that and we can roll up the actual portals whenever we get to them. Dead wikiprojects are another topic for another discussion. Legacypac (talk) 04:00, 9 April 2018 (UTC)[reply]

From use PrimeHunter's script, I see there seems basically 0-1 links per portal in mainspace that are not from templates. So it should be simple to use bot machinery to remove all portal links from mainspace, and then marking 1500 pages historical shouldn't be hard either. Most visible non-mainspace links are from linking portals in wikiproject banners which can be removed by removing the |PORTAL= parameter. Galobtter (pingó mió) 05:11, 9 April 2018 (UTC)[reply]
  • Has anyone thought of keeping a decreased number of portals, which are highly used and of higher quality? They still serve a purpose and are better than an outline. feminist (talk) 08:19, 9 April 2018 (UTC)[reply]
  • We shouldn't be in haste to ditch the portals. Those who say "let them eat outlines, or indexes" should be aware that there over 1,500 portals to 755 outlines and 660 indexes. Many such popular topics as Football, Cricket and Dogs have a portal but no outline or index. Moreover, in all the topics I have looked at where all three types of navigation page are offered – a portal, an outline, and an index – the Portal receives the most page views of the three. I won't bore you with a table but this holds for such a range of topics as Philosophy, Engineering, Film, Forestry and United States. If we don't have the resources to maintain everything, what needs to go may be the outlines and indexes, which between them reproduce the work of the category structure: Noyster (talk), 13:49, 9 April 2018 (UTC)[reply]
    • There are two kinds of pages on Wikipedia: pages people look for and pages people stumble upon. Portals, Outlines and Indexes are almost exclusively in the latter category.
For such pages, page views are determined by visibility: how many incoming links are there and from where. With Portals, we have capitalized screen real estate that will be simply wasted if this proposal results in a mass deletion and unlinking operation. The Main Page, See also sections of countless articles, navigational templates, and WikiProject banners all give visibility to Portal links and that's where all the views come from. Even if we do away with Portals, we could use this visibility for something else. In my comment above, I suggested placing Outline and Index links where Portal links are now. We should definitely think about how to make the best out of these links. – Finnusertop (talkcontribs) 16:23, 9 April 2018 (UTC)[reply]
WP:BLUDGEON. --Guy Macon (talk) 22:04, 10 April 2018 (UTC)[reply]
The following discussion has been closed. Please do not modify it.

Keep the Portals that exist and are in good shape and delete only the poor portals.--Broter (talk) 15:50, 9 April 2018 (UTC)[reply]

Do not delete all Portals. Then you will loose editors. Do only delete the poor portals.--Broter (talk) 15:53, 9 April 2018 (UTC)[reply]

You don't need to keep repeating the same thing. One of the questions asked is about the future of the Portal: namespace. Are you suggesting we keep the 'good' portals in this namespace, but not allow any new creations? In my opinion, it would make more sense to use the Wikipedia: space and move the updated and maintained portals to there, perhaps in the form of Wikiprojects. But, I can't see how allowing some portals and not others would work. Aiken D 15:56, 9 April 2018 (UTC)[reply]
This is technically no problem and we should talk about the criterias which portals need to stay.--Broter (talk) 16:22, 9 April 2018 (UTC)[reply]

It is disrespectfull to delete all portals!--Broter (talk) 15:55, 9 April 2018 (UTC)[reply]

  • If anything can be deleted by a mob, why should someone create something on wikipedia?--Broter (talk) 16:43, 9 April 2018 (UTC)[reply]
    "Mob" is emotive and disrespectful language – WP:AGF applies. It always has been the case that anything can be deleted by consensus. Peter coxhead (talk) 16:49, 9 April 2018 (UTC)[reply]
    Broter, please stop WP:BLUDGEONING. --Guy Macon (talk) 16:54, 9 April 2018 (UTC)[reply]
@Guy Macon: Portals were created to stay on wikipedia! Wikipedians were encouraged to create Portals and improve existing Portals! Now some people want it all to be deleted. Please understand me.--Broter (talk) 17:26, 9 April 2018 (UTC)[reply]
If almost no one uses portals because more efficient means of linking and organizing exist, why should we waste bandwidth and editor time and effort with keeping portals maintained? Please understand what others are getting at. Ian.thomson (talk) 20:25, 9 April 2018 (UTC)[reply]
  • I may never edit wikipedia again if the deletionist extremists win this proposal.--Broter (talk) 19:05, 9 April 2018 (UTC)[reply]
Oh, no... What ever will we do without you... Ian.thomson (talk) 20:10, 9 April 2018 (UTC)[reply]
I agree the left-wing one is definitely not maintained, but yeah, if anything, the bias that would result from one portal being deleted but not the other is an argument against selective deletion/archival and for unilateral action on all portals. Ian.thomson (talk) 20:10, 9 April 2018 (UTC)[reply]
WP:BLUDGEON. --Guy Macon (talk) 22:04, 10 April 2018 (UTC)[reply]
The following discussion has been closed. Please do not modify it.
Everybody can improve the Portal:Left-wing populism. There needs to be only an interested editor.--Broter (talk) 15:16, 10 April 2018 (UTC)[reply]
There exist the politically left wing portals Portal:Communism and Portal:Socialism. The Portal:Left-wing populism is really not needed.--Broter (talk) 15:41, 10 April 2018 (UTC)[reply]
See, though, that's effort that's not being put forth for something that readers aren't using because we have more efficient methods of linking to content. The only way to fix those issues would be automating portal generation, which would pretty much take editors out of the question at any rate. Ian.thomson (talk) 21:57, 10 April 2018 (UTC)[reply]
  • As a first step, I would suggest removing all links to the portal namespace from the mainspace. This would essentially remove portals from the encyclopedia proper and out of the sight of readers, relegating them to the status of "projectspace" pages. The portals themselves would then be allowed to remain for at least 6 months to 1 year so editors and respective wikiprojects have time to preserve any unique content not present elsewhere etc. Particularly useful portals could be preserved as wikiproject subpages. — Godsy (TALKCONT) 19:55, 9 April 2018 (UTC)[reply]
    • My first preference however, would be removing all links to the portal namespace from the mainspace, then marking all portals {{historical}} as has been suggested above.— Godsy (TALKCONT) 20:03, 9 April 2018 (UTC)[reply]
  • Question - if portals are to be discontinued, will there be anything that takes over from their job? Namely (from WP:PORTAL) to help readers and/or editors navigate their way through Wikipedia topic areas. I guess Outline of X and templates at the side of the main article do something like this job, and possibly much better than a portal. Is that the idea?  — Amakuru (talk) 21:03, 9 April 2018 (UTC)[reply]
That's the impression I've had. I've used a portal maybe two or three times the entire time I've been here, but I use those templates pretty regularly and "Outline of..." articles whenever I want to access a lot of articles on a topic really quickly. Ian.thomson (talk) 21:43, 9 April 2018 (UTC)[reply]
Love the "outline of" pages, hate the templates. Look at 1-bit architecture. Instead of that huge wall of links at the bottom, Wouldn't it be nicer to have a simple link to Outline of CPU technologies, and have that page contain the wall of links? What percentage of readers who are interested in 1-bit architectures are looking for a see also link to SUPS? I would say that the answer is "zero". --Guy Macon (talk) 01:06, 10 April 2018 (UTC)[reply]
I'm not opposed to having both. Whichever format I find easier to read depends on the subject and how much caffeine I've had. Sometimes I have an easier time with tables, sometimes with lists.
Since the idea of automation has come up elsewhere in this discussion, I imagine it wouldn't impossible to write a template that'd turn an "Outline of" article into one of those templates. Like, some sort of mark-up that doesn't show up in the article, that you wrap around entries that are supposed to show up in the template, that's look something like {{Subst:OutlineEntry | (line number) | [[Article Title]] }}. Then the template would just be {{ (template name) | 1=[[Article|(name of first row)]] | 2=[[Article2|(name of second row)]] }}. That should be far less work to set up than automating portals. Hell, I could probably work out how to how to do templates for an Outline-to-Table dealy, and the coding nightmare that is WP:BINGO is an anomalous highpoint for me. Ian.thomson (talk) 22:07, 10 April 2018 (UTC)[reply]
Hello, outlines are very different from portals.
Outlines are basically a structured list of links. If you don't click, you don't understand anything. Also they are completely static.
Meanwhile, portals show snippets of articles, interesting facts, images, etc. Also, they are dynamic, as each section rotates automatically. They offer a completely different way to explore the millions of articles. --NaBUru38 (talk) 13:27, 14 April 2018 (UTC)[reply]
  • I am concerned that editors currently maintaining portals may not be aware of this discussion. Can someone create a neutrally-worded edit notice for the portal namespace? And if we want to hear from readers, maybe even a namespace-specific site notice. -- John of Reading (talk) 06:24, 10 April 2018 (UTC)[reply]
Seems a reasonable idea - what do people think of adding to Template:Editnotices/Namespace/Portal? I also wonder if the editnotice should exclude Portal:Current_events and its subpages (which are probably the most active portal pages..but wouldn't be affected by this proposal), Portal:Contents, and Portal:Featured_content from the editnotice Galobtter (pingó mió) 12:59, 10 April 2018 (UTC)[reply]
Seems like a good idea. While relatively few people remain active in portal contribution, nevertheless there should still be the courtesy of informing them or at least letting them be aware of this discussion. We need more input from regular portal contributors so that their voice can be heard, and at the same time their feedback can be used in implementing whatever consensus this discussion results in. Narutolovehinata5 tccsdnew 15:08, 10 April 2018 (UTC)[reply]
WP:BLUDGEON. --Guy Macon (talk) 22:04, 10 April 2018 (UTC)[reply]
The following discussion has been closed. Please do not modify it.

I apologice for my previous behavour and cite now a reason why Portals should stay on wikipedia. Portals get more views than Outlines. For example the Portal:LDS Church gets 71 views a day while the Outline of The Church of Jesus Christ of Latter-day Saints gets 30 views a day.--Broter (talk) 15:31, 10 April 2018 (UTC)[reply]

Once Portals are completed, they are not difficult to maintain. The example for this case is the Portal:Freedom of Speech.--Broter (talk) 16:50, 10 April 2018 (UTC)[reply]

Put well developed Portals on the Mainpage. This is what we should be doing.--Broter (talk) 18:36, 10 April 2018 (UTC)[reply]

  • Deleting portals is beyond pointless, we could end the use of them without deleting anything, the effort this deletion is taking is way more than what it would take to ever maintain the ones we already have.★Trekker (talk) 11:30, 11 April 2018 (UTC)[reply]
  • Question In the first place, how technically feasible is it to delete portals? It seems like a lot of work and honestly sounds like a waste of resources, when archiving and moving to the Wikipedia space (both for active and non-active portals) sounds like a more practical option. Narutolovehinata5 tccsdnew 12:22, 11 April 2018 (UTC)[reply]

I propose we find a new home for some portals that are well maintained. The obvious one is Portal:Current events would could end up as Wikipedia:In the news/Current events. The current events portal is widely viewed, receives lots of edits by many editors, and complements mainspace by effectively serving as a giant list of events. It is used to identify possible entries for WP:ITN/C and editors often also use it to identify information that can/should be added to mainspace articles. As such, it actively improves mainspace. I don't know much about other portals but I imagine similar cases could also find homes. -- BobTheIP editing as 2.28.13.227 (talk) 17:41, 10 April 2018 (UTC)[reply]

One problem is - there are eight linked words and 'All portals' in a corner on the top of the MP - so how many people notice them?
Perhaps the subsidiary question - given that 'a proportion' of Wikipedians (regular or occasional) are involved with starting, developing or improving particular categories of articles, for whom the various portals are, or are potentially, relevant means of navigating Wikipedia, how should the portals' presence be highlighted and/or made user friendly? Can they be variously developed so that the imbalances/absence of coverage on the MP regularly commented on can be addressed to some extent? To what extent should under-achieving portals be highlighted, so that contributors come to their rescue? Jackiespeel (talk) 16:51, 11 April 2018 (UTC)[reply]
I share that concern. Open France and try to find the link to Portal:France. Tip: it's at the bottom of the page inserted in a navbox, with a minuscule font size. Hardly visible at all. I think that links to portals have hardly "capitalized screen real estate". --NaBUru38 (talk) 13:27, 14 April 2018 (UTC)[reply]
  • I would like to address the purpose of portals and the maintenance effort involved. They typically look like topical mini main pages. Some are well integrated with an editing community or a WikiProject, some others are fairly static. From a maintenance point of view, in my personal experience, only the portal pages about editing / collaboration / drawing people into editing are a lot of work, for example Portal:Germany/Things you can do, a page that used to belong both to the wikiproject and the portal, or Portal:Germany/Did you know showing Germany-related DYKs for longer than they appear on the Main Page. Everything else took quite some time to set up but is fairly trivial to maintain, for example the 380 pages that male up Portal:Germany/Anniversaries/All. The main problem with Portals is exactly the same as with Wikiprojects: we do not have enough active editors in many smaller topic areas to create a feeling of an active editing community. Work on supporting and expanding editor subcommunities is often unrewarding, but sorely needed all over Wikipedia, to turn it into a friendlier place. Some Portals used to be part of that community work. I would like to see some positive suggestions how to improve Wikipedia instead of a discussion about destroying a huge amount of work, which is more likely to cause editors to quit than to focus their effort elsewhere. —Kusma (t·c) 13:12, 13 April 2018 (UTC)[reply]
  • Steve Krug identified, years ago, in his excellent book on making useful websites, the principle of giving different kinds of people different ways to get in to what THEY are wanting on the site: deleting all portals because some are derelict is abuse of the people who need a portal-type-central-hub from which to explore ( because we can't visualize star-topology into knowledge the way some other people can ).
  • obliterating everyone's resource just because some find some examples of a kind of resource to be unacceptable to them, is called bullying: when men "protect" women by blocking women from having equal-validity, instead of honestly-protecting women's validity by fighting off glass-ceilings, that is an example of people obliterating someone else's resource ( men obliterating women's resource ). Just because you/someone doesn't want some portals doesn't justify obliterating ALL OUR resource. Some are derelict for a time, if they drift too far from currency, then there should be a system that 1. flags this, so any/all concerned parties can see/know this & understand that if it gets too out-of-date it will be a portal labelled derelict, 2. there should be auto-updating scripts ( oh, this link is to a page that got renamed? autofix the link, OR auto-flag it for some human to correct ), etc... The /actual/ problems include intermittent-interest, complexity in site causing drift between pages to become costly, etc, but the resource that the portal pages can provide ISN'T provided through search, because search _doesn't give you overview and context and interrelatedness_ ( this is the same problem as local businesses being wiped off the map because there is no Browse My Town site by one's village/town/city/county, whereas anyone wanting to find something CAN find it at the biggest online joints: browsing one's town used to be done physically, but the local representative/governments didn't bother making an internet equivalent, and now complain about the economic loss that is a consequence of their inaction! Another side of the same problem is that human memory works through prompting context, so if someone tells me to just remember everything I need to remember & search for them, but human memory works through context-prompting, and I am NOT ALLOWED context to browse in, then my learning is crippled! No, search isn't a complete replacement for context-rich browsing! ) Namaste.

Automated portals

The most common complaint about portals is that they have an insane ammount of maintenance required, and very few users willing to engage in it. And the problem is that we have hundreds of portals, each one with its own set of subpages, and each one is a domain in itself. So, a possible solution: why not automate and centralize the work? Take for example the featured article J. R. R. Tolkien. He may be a suitable featured article for the portals on middle-earth, biography, literature, speculative fiction, etc. Under the current system, each portal has to make their own "Portal:(name)/J. R. R. Tolkien" to place the blurb that will use. And also watch if the article loses the featured article to remove it, or add it when it gets featured. But we may have a single "Portal/J. R. R. Tolkien" general subpage, with a general blurb, and add tags to it to instruct the bots about the portals that should include it. Same for the page for image blurbs, quote blurbs, etc. That would greatly reduce the number of pages, keep them organized at a single place, and most of the work would be done by bots.

A second idea would be to restrict the topics that may get a portal to those truly diverse. A portal for music, or a music genre, is justified, but a portal for a certain band can hardly be. Add a requirement of "At least X articles in scope" and "at least Y good or features articles wihin the scope". Less portals, less pages to mantain, and easier to deal with. The fandom of Z wants a portal, but there are not featured articles enough? Then make those featured articles, and then the portal. Cambalachero (talk) 19:14, 10 April 2018 (UTC)[reply]

This has been proposed above, and while it might solve the editing inactivity problem, it wouldn't solve the Portal system's other major flaw: outside of just a few portals (mentioned by Andrew D. below), the vast majority barely get any views. Even the ones with a high number of views might be better off in the Wikipedia namespace anyway. Narutolovehinata5 tccsdnew 00:07, 11 April 2018 (UTC)[reply]
  • Like: Some portals (such as Portal:Horses) were well set up at the time (ours was named a featured portal in its day) but there does need to be some automation via templates, such as to automatically update DYK, FA, TFA, or even GA-class articles that are tagged for the project or portal into appropriate rotating queues, adding a category tree based on a core parent cat, and so on. Montanabw(talk) 19:44, 12 April 2018 (UTC)[reply]
I like the idea of automated portals to reduce maintenance. If you look at P:MDRD, the Selected picture and Did you know? hooks are set up to rotate randomly every time the portal is refreshed. I think spreading this idea to all portals is a good idea to keep the portals with minimal maintenance. Dough4872 20:33, 12 April 2018 (UTC)[reply]
This does reduce maintenance work and slow the degradation of less-maintained portals, but there are tradeoffs. In one of the sections below there are editors complaining that portals are hard to edit for users who aren't familiar with templates. --RL0919 (talk) 20:50, 12 April 2018 (UTC)[reply]
I set up Portal:London Transport so that the lists of featured articles, good articles, etc. are automatically updated weekly. A series of sub-pages are updated by User:JL-Bot and the bot's outputs for each of the lists are collated together using a set of string trimming and cropping templates to format them in an attractive manner - see Wikipedia:WikiProject London Transport/Recognised content/bot list and its sub-pages. It's not pretty, but it could be standardised for use on other portals and it means that the lists are never more than a few days old. The random selected articles, biographies, pictures and DYKs are relatively straight forward as there are templates specifically designed for this purpose. --DavidCane (talk) 21:01, 12 April 2018 (UTC)[reply]

While I would support some kind of automation of portals should the status quo remain, I'm concerned that it might not be enough to solve the problem that the vast majority of portals aren't getting a meaningful amount of views. It would help solve the editing problem (in that the currently inactive portals would get some love from editors), but that would affect the editing end and not the viewer end. What would be a suitable proposal in order to help promote portals and increase their readership? I know many articles have links to portals but in most cases it doesn't seem to be enough, so perhaps additional steps could be made here. Narutolovehinata5 tccsdnew 12:12, 13 April 2018 (UTC)[reply]

Narutolovehinata5 I know this thread is very long but please see my "oppose" comment above. I'm suggesting automating not only the portals themselves but the linking to them from all relevant articles, and also de-emphasising the term "portal" which may not mean much to a lot of the lay readership: Noyster (talk), 12:47, 13 April 2018 (UTC)[reply]
Honestly I'm skeptical that will be enough. Take the case for example Portal:Anime and manga, which is linked to in several anime-related articles. In the past 30 days, it's gotten a mere 6,871 views (or an average of about 222 views per day). It may seem like a lot at first, but that's far less than what either anime or manga (thousands of edits per day). It also gets far less pageviews that most airing series and even series that have finished airing. Even if Portal:Anime and manga was linked from every single article, it might not make a difference considering it's already linked to from most of the popular articles of the project. I know there are counterexamples to this from other projects, but my point is simply that links to Portals don't seem to be enough to promote them well; there probably has to be another way. Narutolovehinata5 tccsdnew 12:55, 13 April 2018 (UTC)[reply]

Hello, the proposal to increase automation is meant to improve portal quality, which is a major concern. Of course it won't increase page views overnight, since that's another major concern. Each issue requires separate solutions. --NaBUru38 (talk) 13:30, 14 April 2018 (UTC)[reply]

Speaking of automated portals, I have a lot of experience with them on the Spanish-language Wikipedia. I have helped a lot to develop sports portals, anchored in Portal:Deporte, Portal:Fútbol and Portal:Automovilismo. They all share the same templates and article snippets, as do their subportals by region and discipline.
Each portal has a competition calendar of the week / month. Sportspeople appear on their birthdays. Several editors have copied and pasted them to create new portals with minimal effort. --NaBUru38 (talk) 13:34, 14 April 2018 (UTC)[reply]

Main page link traffic in 2018

This proposal to destroy all portals seems to be based on the misconception that they are not used. Here's some actual stats which refute this nonsense. It's a list of the pages currently linked on the main page, ranked by their views in 2018. I've only listed the top 100 as they seem adequate to make the point. One can see from this that the portal pages get plenty of traffic and that this is comparable with other pages. If numbers are what matters then there's a better case for deleting other WP pages such as Wikipedia:Village pump. Andrew D. (talk) 23:22, 10 April 2018 (UTC)[reply]

Long list
Rank Page Readers in 2018
1 Deaths in 2018 10,440,731
2 Portal:Current events 4,387,154
3 Avengers: Infinity War 4,244,723
4 Wikipedia:Featured articles 2,677,238
5 Wikipedia 1,795,210
6 Patrick Reed 1,552,039
7 The Holocaust 1,129,274
8 Wikipedia:Community portal 1,089,287
9 English language 1,022,730
10 Benito Mussolini 821,011
11 Scotland 756,252
12 Association football 633,844
13 Wales 582,933
14 Auschwitz concentration camp 574,151
15 FC Bayern Munich 562,962
16 George Weah 541,623
17 Liberia 526,109
18 Boston 482,016
19 Augusta National Golf Club 471,459
20 Apollo 11 467,370
21 2018 Masters Tournament 463,447
22 Volcano 405,686
23 Big Ben 352,576
24 Portal:Contents/Portals 343,999
25 Portal:Arts 251,984
26 Saskatchewan 251,005
27 United States men's national soccer team 239,197
28 Lega Nord 231,813
29 Wikipedia:In the news/Candidates 225,142
30 Wikipedia:Your first article 224,475
31 2017–18 Bundesliga 223,623
32 Palace of Westminster 220,180
33 Portal:History 210,188
34 The Infinity Gauntlet 208,888
35 Encyclopedia 207,631
36 Portal:Biography 196,294
37 Portal:Geography 193,451
38 Portal:Technology 191,849
39 Hungarian parliamentary election, 2018 185,973
40 Golf 180,084
41 Humboldt Broncos 169,318
42 Isao Takahata 167,146
43 Æthelstan A 149,079
44 Portal:Mathematics 129,103
45 Viktor Orbán 126,546
46 Giuseppe Verdi 123,292
47 Portal:Science 122,774
48 Humboldt Broncos bus crash 120,134
49 Wikipedia:Help desk 119,773
50 Year Without a Summer 115,715
51 Free content 104,088
52 List of historical anniversaries 100,432
53 Wikimedia Foundation 93,859
54 Timothy Weah 91,143
55 Governance 88,460
56 Casting 84,104
57 Viola 79,785
58 Wikipedia:Recent additions 78,397
59 Cecil Taylor 76,464
60 Nagorno-Karabakh War 71,591
61 Mount Tambora 71,576
62 Wikipedia:Featured pictures 70,178
63 Wikipedia:Introduction 67,917
64 April 9 67,820
65 Portal:Society 63,415
66 Wikipedia:Reference desk 55,095
67 Template talk:Did you know 52,856
68 Withypool Stone Circle 50,064
69 Michael Goolaerts 45,856
70 1992 44,359
71 2009 41,091
72 Rif Dimashq offensive (February–April 2018) 40,581
73 Wikipedia:Village pump 38,022
74 Lesser Antillean macaw 37,282
75 Frederick D. Reese 37,031
76 Gustav III of Sweden 36,959
77 Drama dari Krakatau 32,315
78 Samuel Hahnemann 32,202
79 Charter 31,555
80 April 10 30,899
81 Host (biology) 30,205
82 Scribe 29,234
83 Wikipedia:News 25,514
84 Senate of the Republic (Italy) 25,324
85 National Assembly (Hungary) 24,719
86 Kingdom of Strathclyde 24,114
87 Wikipedia:Local Embassy 22,625
88 West Nile virus 21,866
89 1944 21,796
90 April 11 21,714
91 Frank Bainimarama 20,804
92 Un ballo in maschera 16,999
93 2018 Gaza border protests 15,062
94 Rudolf Vrba 14,921
95 Wikipedia:Today's featured article/April 2018 11,380
96 1815 7,559
97 Norman Bel Geddes 7,387
98 Toni Iwobi 7,293
99 President of Fiji 6,376
100 Prime Minister of Fiji 6,210
To give a fair overview, could we please see the above table containing only links that have been on the main page for six month or more? Comparing current movies and events with permanent mainpage links is comparing apples and oranges. --Guy Macon (talk) 23:47, 10 April 2018 (UTC)[reply]
Indeed, every single one of the portals listed in that table is either on the main page or the permanent sidebar. Of course they are going to have massive pageviews. --Izno (talk) 02:49, 11 April 2018 (UTC)[reply]
The top item bolded as a "portal" is Wikipedia:Community portal which is not a portal and not included on this proposal. Legacypac (talk) 04:22, 11 April 2018 (UTC)[reply]
  • Here's the list, edited to show only those pages which have a regular link on the main page. It seems clear that the portal traffic is comparable with other standard features such as the Help desk or Introduction to Wikipedia. These links have all had thousands of readers since the start of the year and so the claim that they are not used is false. Of course, the main users of such links will be new or occasional readers rather than we veterans. But those users are not represented here in this discussion, are they? Andrew D. (talk) 07:56, 11 April 2018 (UTC)[reply]
Rank Page Readers in 2018
1 Deaths in 2018 10,440,731
2 Portal:Current events 4,387,154
4 Wikipedia:Featured articles 2,677,238
5 Wikipedia 1,795,210
8 Wikipedia:Community portal 1,089,287
9 English language 1,022,730
24 Portal:Contents/Portals 343,999
25 Portal:Arts 251,984
29 Wikipedia:In the news/Candidates 225,142
30 Wikipedia:Your first article 224,475
33 Portal:History 210,188
35 Encyclopedia 207,631
36 Portal:Biography 196,294
37 Portal:Geography 193,451
38 Portal:Technology 191,849
44 Portal:Mathematics 129,103
47 Portal:Science 122,774
49 Wikipedia:Help desk 119,773
51 Free content 104,088
52 List of historical anniversaries 100,432
53 Wikimedia Foundation 93,859
58 Wikipedia:Recent additions 78,397
62 Wikipedia:Featured pictures 70,178
63 Wikipedia:Introduction 67,917
65 Portal:Society 63,415
66 Wikipedia:Reference desk 55,095
67 Template talk:Did you know 52,856
73 Wikipedia:Village pump 38,022
83 Wikipedia:News 25,514
87 Wikipedia:Local Embassy 22,625


  • So the word "free" on the main page gets roughly 100,000 hits and an uninteresting link like "Local Embassy" gets roughly 20,000. And how many hits does the main page get? I want to calculate what percentage of visitors click on those two links. --Guy Macon (talk) 12:31, 11 April 2018 (UTC)[reply]

Just because a link gets traffic does not mean it is getting “used”. Viewing a page does not equate to using it. Page views is not the only argument in favour of making portals obsolete. Aiken D 15:17, 11 April 2018 (UTC)[reply]

Yes I was going to say the same. I'm not choosing sides, but the tables above say "readers in YYYY". I assume you mean pageviews, which is not the same thing. One reader could reload the page 100 times, and that's 100 pageviews, yet still the same person. Fly-by edits (that aren't through the API) also get counted as pageviews, even the editor may have read nothing more than a diff. Pinging Guy Macon in case you want to revise the wording MusikAnimal talk 20:50, 16 April 2018 (UTC)[reply]
If you want to delete inactive portals then fine, but don't try and blanket them all as unused and obsolete as this isn't true based on editor comments here. - Knowledgekid87 (talk) 15:20, 11 April 2018 (UTC) In my opinion even the inactive ones should be marked as historical rather than deleted. - Knowledgekid87 (talk) 15:26, 11 April 2018 (UTC)[reply]
  • I reckon anything linked up there, be in a blank page or a portal would get about the same views (and especially if they were also linked in a few hundred/thousand pages, and a few hundred thousand talk pages) - views from being on the main page I don't think signify too much other than random clicks as I said in my support Galobtter (pingó mió) 15:52, 11 April 2018 (UTC)[reply]


Are there statistics that compare "logged in" with "logged out" users? I suspect that a huge portion of the visitors to portals are Wikipedia editors going there to maintain them as opposed to readers randomly looking at them. --B (talk) 19:35, 11 April 2018 (UTC)[reply]

What about Portals that are exempt from this discussion or otherwise kept?

It seems that there's consensus or at least significant support to keep at least some portals: notably Portal:Current events and the like. Assuming the proposal to deprecate the Portal namespace passes, what will happen to these pages? Will the Portal namespace be kept for them alone, or will they be moved to another namespace like the Wikipedia namespace? Narutolovehinata5 tccsdnew 13:39, 11 April 2018 (UTC)[reply]

This is the issue... nobody is thinking these things out. - Knowledgekid87 (talk) 13:43, 11 April 2018 (UTC)[reply]
Hmm? Like I suggested above, the wikipedia namespace seems fine for these, seeing as they are barely like other portals, and the moves shouldn't be too onerous to do Galobtter (pingó mió) 14:58, 11 April 2018 (UTC)[reply]

These are part of Wikipedia's core navigation system:

  1. Portal:Contents

(see this page for the list)

Such as retain the Portal namespace just for these: Portal:Contents, Portal:Featured content, and Portal:Current events.

Thank you.     — The Transhumanist    10:36, 11 April 2018 (UTC)[reply]

I've replaced the list to a more convenient link to prefixindex, that also doesn't burden the page more. Galobtter (pingó mió) 15:58, 11 April 2018 (UTC)[reply]
Move the useful pages to Wikipedia namespace. Remove the Portal namespace completely. Everytime someone brings a Portal to MfD the discussion runs along the lines of "we dislike portals but we wamt to deal with them all, not piecemeal. As long as Portals are allowed to exist we should keep this one." So here we are - discussing them all. Legacypac (talk) 17:22, 11 April 2018 (UTC)[reply]
I don't understand this. Wikipedia namespace is targeted at editors and is mostly used for maintenance and discussion, so it wouldn't make sense for pages that readers use to be located there. The portal namespace, however, is more reader-targeted, similar to article namespace. Master of Time (talk) 06:31, 12 April 2018 (UTC)[reply]
WP:Contents and WP:Featured content currently redirect to Portal:Contents and Portal:Featured content, so just move them to the Wikipedia namespace over the redirects. For Portal:Current events, I would move it to Wikipedia:WikiProject Current events (the WikiProject is currently inactive). --Ahecht (TALK
PAGE
) 16:00, 12 April 2018 (UTC)[reply]

There is one special portal that I watch and maintain: Portal:Example (I also keep an eye on Template:Example, Help:Example, Book:Example, Module:Example, etc. -- mostly reverting vandalism and dealing with misplaced talk page messages). If all other portals are deleted or moved into a different namespace, Portal:Example should be deleted. If a single portal is left in the portal namespace, Portal:Example should be left as well. --Guy Macon (talk) 06:22, 12 April 2018 (UTC)[reply]

If portals are deleted, please move all the topics pages from subject portals to the outline WikiProject, for harvesting

Long list
  1. Portal:1980s/Topics
  2. Portal:A Nightmare on Elm Street/Topics
  3. Portal:AC/DC/Topics
  4. Portal:Abkhazia/Topics
  5. Portal:Abu Dhabi/Topics
  6. Portal:Academy Award/Academy Award topics
  7. Portal:Acadia/Topics
  8. Portal:Adele/Topics
  9. Portal:Aerosmith/Aerosmith topics
  10. Portal:Aesthetics/Topics
  11. Portal:Africa/Topics
  12. Portal:African American/African American topics
  13. Portal:African American/Topics/Tabs
  14. Portal:African American/Topics
  15. Portal:Agriculture and agronomy/Basic Topics
  16. Portal:Agriculture and agronomy/Topic journals
  17. Portal:Agriculture and agronomy/Topic news/Wikinews
  18. Portal:Agriculture and agronomy/Topic news
  19. Portal:Agriculture and agronomy/Topics
  20. Portal:Ajman/Topics
  21. Portal:Alabama/Topics
  22. Portal:Alberta/Topics
  23. Portal:Algebra/Topics
  24. Portal:Algeria/Topics
  25. Portal:Alien/Topics
  26. Portal:Alphabet/Topics
  27. Portal:Alternative rock/Alternative rock topics
  28. Portal:American Civil War/American Civil War topics
  29. Portal:American Old West/American Old West topics
  30. Portal:American Revolutionary War/Topics
  31. Portal:American football/American football topics
  32. Portal:Amiga/Topics
  33. Portal:Amphibians and reptiles/Amphibians and Reptiles topics
  34. Portal:Amusement parks/Topics
  35. Portal:Anabaptism/Anabaptist topics
  36. Portal:Analysis/Topics
  37. Portal:Analytical chemistry/Analytical chemistry Topics
  38. Portal:Anarchism/Anarchism topics
  39. Portal:Anatomy/Topics
  40. Portal:Ancient Egypt/Categories and Main topics/Header
  41. Portal:Ancient Egypt/Categories and Main topics
  42. Portal:Ancient Egypt/Main topics
  43. Portal:Ancient Greece/Ancient Greece topics
  44. Portal:Ancient Greece/Topics
  45. Portal:Ancient Japan/Topics
  46. Portal:Ancient Near East/Key topic/10
  47. Portal:Ancient Near East/Key topic/11
  48. Portal:Ancient Near East/Key topic/12
  49. Portal:Ancient Near East/Key topic/13
  50. Portal:Ancient Near East/Key topic/14
  51. Portal:Ancient Near East/Key topic/15
  52. Portal:Ancient Near East/Key topic/16
  53. Portal:Ancient Near East/Key topic/17
  54. Portal:Ancient Near East/Key topic/18
  55. Portal:Ancient Near East/Key topic/19
  56. Portal:Ancient Near East/Key topic/1
  57. Portal:Ancient Near East/Key topic/20
  58. Portal:Ancient Near East/Key topic/21
  59. Portal:Ancient Near East/Key topic/2
  60. Portal:Ancient Near East/Key topic/3
  61. Portal:Ancient Near East/Key topic/4
  62. Portal:Ancient Near East/Key topic/5
  63. Portal:Ancient Near East/Key topic/6
  64. Portal:Ancient Near East/Key topic/7
  65. Portal:Ancient Near East/Key topic/8
  66. Portal:Ancient Near East/Key topic/9
  67. Portal:Ancient Near East/Key topic/Layout
  68. Portal:Ancient Near East/Key topic
  69. Portal:Ancient Near East/Topics/Tabs
  70. Portal:Ancient Near East/Topics/Topic chart
  71. Portal:Ancient Near East/Topics
  72. Portal:Ancient Rome/Ancient Rome topics
  73. Portal:Ancient Rome/Topics
  74. Portal:Ancient warfare/Topics
  75. Portal:Andorra/Topics
  76. Portal:Anglicanism/Topics
  77. Portal:Angola/Topics
  78. Portal:Animal rights/Topics
  79. Portal:Animals/Animals topics
  80. Portal:Animation/Categories and topics
  81. Portal:Animation/Topics
  82. Portal:Anime and manga/Topics
  83. Portal:Ankara/Topics
  84. Portal:Antarctica/Topics
  85. Portal:Anthropology/Topics
  86. Portal:Apple Inc./Topics
  87. Portal:Architecture/Topics
  88. Portal:Arctic/Topics
  89. Portal:Ariana Grande/Topics
  90. Portal:Arijit Singh/Topics
  91. Portal:Arizona/Topics
  92. Portal:Arkansas/Arkansas topics
  93. Portal:Armenia/Armenia topics
  94. Portal:Arminianism/Arminianism topics/Background
  95. Portal:Arthropods/Related topics
  96. Portal:Arthropods/Topics
  97. Portal:Artsakh/Topics
  98. Portal:Asia/Topics
  99. Portal:Asian Americans/Topics
  100. Portal:Asian Games/Topics
  101. Portal:Assam/Topics
  102. Portal:Association football/Categories and Main topics/Tabs
  103. Portal:Association football/Categories and Main topics
  104. Portal:Association football/Selected topic/1
  105. Portal:Association football/Selected topic/2
  106. Portal:Association football/Selected topic/3
  107. Portal:Association football/Selected topic/4
  108. Portal:Association football/Selected topic/5
  109. Portal:Association football/Selected topic/6
  110. Portal:Association football/Selected topic/Layout
  111. Portal:Association football/Selected topic
  112. Portal:Association football/Topics
  113. Portal:Assyrians/Topics
  114. Portal:Astrobiology/Topics
  115. Portal:Astrology/Related topics
  116. Portal:Atheism/Atheism topics
  117. Portal:Athletics/Topics
  118. Portal:Atlanta/Topics
  119. Portal:Atlas/Topics
  120. Portal:Austin/Austin topics
  121. Portal:Australia/Topics
  122. Portal:Australian Capital Territory/Topics
  123. Portal:Australian roads/Topics
  124. Portal:Australian rules football/Topics
  125. Portal:Austria-Hungary/Topics
  126. Portal:Austria/Austria topics
  127. Portal:Aviation/Aviation Topics
  128. Portal:Aviation/Categories and Main topics/Header
  129. Portal:Aviation/Categories and Main topics
  130. Portal:Avril Lavigne/Topics
  131. Portal:Azad Kashmir/Azad Kashmir Topics
  132. Portal:Azerbaijan/Azerbaijan-related topics
  133. Portal:BBC/BBC topics
  134. Portal:Backstreet Boys/Topics
  135. Portal:Bacon/Topics
  136. Portal:Baden-Württemberg/Topics
  137. Portal:Bahrain/Topics
  138. Portal:Ballet/Topics
  139. Portal:Balochistan, Pakistan/Topics
  140. Portal:Bandai Namco/Topics
  141. Portal:Bangalore/Topics
  142. Portal:Bangladesh Liberation War/Topics
  143. Portal:Baptist/Topics
  144. Portal:Barack Obama/Topics/Books
  145. Portal:Barack Obama/Topics/Campaign
  146. Portal:Barack Obama/Topics/Career
  147. Portal:Barack Obama/Topics/Complete list
  148. Portal:Barack Obama/Topics/Family
  149. Portal:Barack Obama/Topics/Miscellany
  150. Portal:Barack Obama/Topics/Named after
  151. Portal:Barack Obama/Topics/Presidency
  152. Portal:Barack Obama/Topics
  153. Portal:Baseball in Japan/Topics
  154. Portal:Baseball/Baseball topics
  155. Portal:Baseball/Categories and Main topics/Tabs
  156. Portal:Baseball/Categories and Main topics
  157. Portal:Basque/Basque topics
  158. Portal:Bavaria/Topics
  159. Portal:Beer/Beer topics
  160. Portal:Beijing/Topics
  161. Portal:Belgium/Topics
  162. Portal:Bengali cinema/Topics
  163. Portal:Bengali literature/Bengali literature topics
  164. Portal:Bengali/Bengali topics
  165. Portal:Benin/Topics
  166. Portal:Berkshire/Topics
  167. Portal:Berlin/Topics
  168. Portal:Bermuda/Topics
  169. Portal:Beyoncé/Topics
  170. Portal:Bhutan/Topics
  171. Portal:Bible/Bible topics
  172. Portal:Bihar/Major topics
  173. Portal:Biological warfare/Topics
  174. Portal:Biology/Major topics
  175. Portal:Birds/Topics
  176. Portal:Björk/Topics
  177. Portal:Blues/Topics
  178. Portal:Bob Dylan/Topics
  179. Portal:Body modification/Topics
  180. Portal:Bohol/Bohol topics
  181. Portal:Bollywood/Topics
  182. Portal:Book of Mormon/Book of Mormon topics
  183. Portal:Books/Books topics
  184. Portal:Boston/Topics
  185. Portal:Botswana/Topics
  186. Portal:Brandy Norwood/Topics
  187. Portal:Brazil/Topics
  188. Portal:Bridges/Topics
  189. Portal:Brighton/Brighton topics
  190. Portal:British Columbia/British Columbia topics
  191. Portal:British Empire/Topics
  192. Portal:British politics/Topics
  193. Portal:Britney Spears/Britney Spears topics
  194. Portal:Buckinghamshire/Topics
  195. Portal:Buddhism/Topics
  196. Portal:Buenos Aires/Topics
  197. Portal:Buffy the Vampire Slayer/Featured topic
  198. Portal:Bulgaria/Topics
  199. Portal:Bulgarian Empire/Topics
  200. Portal:Burkina Faso/Topics
  201. Portal:Burundi/Topics
  202. Portal:Buses/Topics
  203. Portal:Business and economics/Topics
  204. Portal:Byzantine Empire/Topics
  205. Portal:Calgary/Topics
  206. Portal:California/Topics
  207. Portal:Calvinism/Calvinism topics/Background
  208. Portal:Calvinism/Calvinism topics/Churches
  209. Portal:Calvinism/Calvinism topics/Distinctives
  210. Portal:Calvinism/Calvinism topics/Influences
  211. Portal:Calvinism/Calvinism topics/Peoples
  212. Portal:Calvinism/Calvinism topics
  213. Portal:Cambodia/Topics
  214. Portal:Cambrian/Topics
  215. Portal:Cameroon/Topics
  216. Portal:Canada Roads/Topics
  217. Portal:Canada/Provincial topics/Table
  218. Portal:Canada/Provincial topics
  219. Portal:Canadian Armed Forces/Topics
  220. Portal:Canadian football/Topics
  221. Portal:Canadian politics/Topics
  222. Portal:Cannabis/Cannabis topics
  223. Portal:Cannabis/Major topics
  224. Portal:Cape Cod and the Islands/Topics
  225. Portal:Cape Verde/Topics
  226. Portal:Capitalism/Capitalism topics
  227. Portal:Carboniferous/Topics
  228. Portal:Caribbean Community/Topics/associate members
  229. Portal:Caribbean Community/Topics/core institutions
  230. Portal:Caribbean Community/Topics/full members
  231. Portal:Caribbean Community/Topics/observers
  232. Portal:Caribbean Community/Topics/projects
  233. Portal:Caribbean Community/Topics/related institutions
  234. Portal:Caribbean Community/Topics/secretariat
  235. Portal:Caribbean Community/Topics
  236. Portal:Carpathian Ruthenia/Carpathian Ruthenia topics
  237. Portal:Cartoon Network/Topics
  238. Portal:Cartoon/Topics
  239. Portal:Catalan-speaking countries/Catalan-speaking countries topics
  240. Portal:Category theory/Topics
  241. Portal:Catholicism/Catholicism topics
  242. Portal:Cats/Cats topics
  243. Portal:Celine Dion/Celine Dion topics
  244. Portal:Cenozoic/Topics
  245. Portal:Central African Republic/Topics
  246. Portal:Central Asia/Topics
  247. Portal:Chad/Topics
  248. Portal:Chandigarh/Topics
  249. Portal:Channel Islands/Topics
  250. Portal:Chemistry/Major topics
  251. Portal:Chennai/Topics
  252. Portal:Cher/Topics
  253. Portal:Cheshire/Cheshire topics
  254. Portal:Chicago/Chicago topics
  255. Portal:Chicago/Topics
  256. Portal:Children's literature/Children's literature topics
  257. Portal:Chile/Topics
  258. Portal:China/Topics
  259. Portal:Chitral, Pakistan/Topics
  260. Portal:Chittagong/Topics
  261. Portal:Christadelphian/Topics
  262. Portal:Christian democracy/Topics
  263. Portal:Christian music/Topics
  264. Portal:Christianity in India/Indian Christianity/Topics
  265. Portal:Christianity in India/Topics
  266. Portal:Christina Aguilera/Topics
  267. Portal:Christmas/Topics
  268. Portal:Chronology/Chronology topics
  269. Portal:City of Bankstown/Extra Topics
  270. Portal:City of Bankstown/Topics
  271. Portal:City of Port of Spain/Port of Spain topics
  272. Portal:City of San Fernando/San Fernando topics
  273. Portal:Classical Civilisation/Topic news
  274. Portal:Classical Civilisation/Topics
  275. Portal:Classical guitar/Topics in Classical guitar
  276. Portal:Classical music/Topics
  277. Portal:Cleveland/Topics
  278. Portal:Coatbridge/Topics
  279. Portal:Coke Studio (Pakistan)/Topics
  280. Portal:Cold War/Cold War topics
  281. Portal:College basketball/College basketball topics
  282. Portal:College football/College football topics
  283. Portal:Colonialism/Main topics
  284. Portal:Color/Topics
  285. Portal:Comedy/Topics
  286. Portal:Comics/Categories and topics
  287. Portal:Comics/Topics
  288. Portal:Commonwealth Games/Topics
  289. Portal:Commonwealth realms/Commonwealth realms topics
  290. Portal:Communism/Communism topics
  291. Portal:Community of Christ/Topics
  292. Portal:Community/Community topics
  293. Portal:Complementary and alternative medicine/Topics
  294. Portal:Computer graphics/Topics
  295. Portal:Computer networking/Topics
  296. Portal:Computer programming/Topics
  297. Portal:Computer science/Computer science topics
  298. Portal:Computer security/Computer security topics
  299. Portal:Computer-generated imagery/Topics
  300. Portal:Connecticut/Topics
  301. Portal:Construction/Topics
  302. Portal:Cornwall/Cornwall topics
  303. Portal:Costa Rica/Costa Rica topics
  304. Portal:Country music/Country music topics
  305. Portal:Crawley/Topics
  306. Portal:Creationism/Creationism topics
  307. Portal:Crimea/Crimea topics
  308. Portal:Croatia/Croatia topics
  309. Portal:Crusades/Topics
  310. Portal:Cryptozoology/Cryptozoology topics
  311. Portal:Crystallography/Crystallography topics
  312. Portal:Cuba/Topics
  313. Portal:Cumbria/Topics
  314. Portal:Cycling/Cycling topics
  315. Portal:Cyprus/Cyprus topics
  316. Portal:Czech Republic/Topics
  317. Portal:Daman and Diu/Topics
  318. Portal:Dannii Minogue/Topics
  319. Portal:Death metal/Topics
  320. Portal:Death/Death topics
  321. Portal:Death/Topics
  322. Portal:Delaware/Topics
  323. Portal:Delhi/Topics
  324. Portal:Democratic Republic of the Congo/Topics
  325. Portal:Denmark/Denmark topics
  326. Portal:Dentistry/Dentistry topics
  327. Portal:Desouk/Desouk topics
  328. Portal:Detroit/Topics
  329. Portal:Devon/Devon topics
  330. Portal:Devonian/Topics
  331. Portal:Dhaka/Topics
  332. Portal:Dhallywood/Topics
  333. Portal:Dinosaurs/Topics
  334. Portal:Disasters/Disasters topics
  335. Portal:Discrete mathematics/Topics
  336. Portal:Discrimination/Topics
  337. Portal:Discworld/Discworld topics
  338. Portal:Disney/Topics
  339. Portal:Djibouti/Topics
  340. Portal:Doctor Who/Topics
  341. Portal:Dogs/Dogs topics
  342. Portal:Dominican Republic/Topics
  343. Portal:Donald Trump/Topics
  344. Portal:Dorset/Dorset topics
  345. Portal:Dragon Ball/Dragon Ball topics
  346. Portal:Dragonlance/Dragonlance topics
  347. Portal:Dravidian civilizations/Topics
  348. Portal:Dream Theater/Dream Theater topics
  349. Portal:Drink/Topics
  350. Portal:Dubai/Topics
  351. Portal:Dungeons & Dragons/Topics
  352. Portal:Early modern Britain/Topics
  353. Portal:Earth sciences/Featured content/Topics
  354. Portal:Earth sciences/Related topics
  355. Portal:Earthquakes/Topics
  356. Portal:East Midlands England/Topics
  357. Portal:East Sussex/East Sussex topics
  358. Portal:East Timor/Topics
  359. Portal:EastEnders/EastEnders topics
  360. Portal:Eastern Christianity/Topics
  361. Portal:Ecology/Ecology topics
  362. Portal:Ecology/Topics and categories
  363. Portal:Ecology/Topics
  364. Portal:Ecuador/Ecuador topics
  365. Portal:Ed, Edd n Eddy/Topics
  366. Portal:Ediacaran/Topics
  367. Portal:Edmonton/Edmonton topics
  368. Portal:Edmonton/sub-topics
  369. Portal:Education in India/Topics
  370. Portal:Education in Pakistan/Topics
  371. Portal:Egypt/Egypt topics
  372. Portal:El Salvador/El Salvador topics
  373. Portal:Electronic music/Electronic music topics
  374. Portal:Electronics/Main topics
  375. Portal:Elvis Presley/Topics
  376. Portal:Eminem/Topics
  377. Portal:Energy/Energy topics
  378. Portal:England/Topics
  379. Portal:English football/Topics
  380. Portal:English/English topics
  381. Portal:Environment/Topics
  382. Portal:Epistemology/Epistemology topics
  383. Portal:Eritrea/Topics
  384. Portal:Esperanto/Other topics
  385. Portal:Estonia/Main topics
  386. Portal:Estrie/Topics
  387. Portal:Ethics/Ethics topics
  388. Portal:Ethiopia/Topics
  389. Portal:European Union/Topics
  390. Portal:European military history/Topics
  391. Portal:Evanescence/Topics
  392. Portal:Evolutionary biology/Related topics
  393. Portal:Extinct and endangered species/Extinct and endangered species topics
  394. Portal:Falun Gong/Falun Gong topics
  395. Portal:Family Guy/Topics
  396. Portal:Fascism/Topics
  397. Portal:Fashion/Fashion topics
  398. Portal:Fashion/Topics
  399. Portal:Featured content/Topics
  400. Portal:Feminism/Feminism topics
  401. Portal:Fencing/Fencing topics
  402. Portal:Fergie (singer)/Topics
  403. Portal:Ferrari/Topics
  404. Portal:Fictional characters/Topics
  405. Portal:Film in the United States/Topics
  406. Portal:Film/Topics
  407. Portal:Finger Lakes/Topics
  408. Portal:Fish/Fish topics
  409. Portal:Fishing/Fishing topics
  410. Portal:Florida/Topics
  411. Portal:Folklore/Folklore topics
  412. Portal:Food/Topics
  413. Portal:Football in Africa/Topics
  414. Portal:Football in Argentina/Topics
  415. Portal:Football in Germany/Topics
  416. Portal:Football in India/Topics
  417. Portal:Football in Malaysia/Topics
  418. Portal:Football in the Philippines/Topics
  419. Portal:Forestry/Topics
  420. Portal:France/GeographyTopics
  421. Portal:France/Topics
  422. Portal:Franco-Americans/Topics
  423. Portal:Frank Zappa/Topics
  424. Portal:Free software/Topics
  425. Portal:Freedom of speech/Topics
  426. Portal:French and Francophone literature/French and Francophone literature topics
  427. Portal:French language and French-speaking world/Topics
  428. Portal:French politics/Topics
  429. Portal:Frogs and toads/Topics
  430. Portal:Fungi/Topics
  431. Portal:Futurama/Futurama topics
  432. Portal:Gabon/Topics
  433. Portal:Gangs/Gang topics
  434. Portal:Gardening/Topic news
  435. Portal:Gardening/Topics
  436. Portal:Gaspésie/Topics
  437. Portal:Gastropods/Major topics
  438. Portal:Geert Wilders/Topics
  439. Portal:Gemology and jewelry/Gemology and Jewelry topics
  440. Portal:Gender studies/Topics
  441. Portal:Genealogy/Topics
  442. Portal:Geneva/Topics
  443. Portal:Geography of Canada/Topics
  444. Portal:Geography of Kenya/Topics
  445. Portal:Geometry/Topics
  446. Portal:Georgia (U.S. state)/Topics
  447. Portal:Georgia (country)/Topics/Culture
  448. Portal:Georgia (country)/Topics/Economy
  449. Portal:Georgia (country)/Topics/Geography
  450. Portal:Georgia (country)/Topics/Healthcare
  451. Portal:Georgia (country)/Topics/History
  452. Portal:Georgia (country)/Topics/People
  453. Portal:Georgia (country)/Topics/Politics
  454. Portal:Georgia (country)/Topics
  455. Portal:German Empire/Topics
  456. Portal:Germany/Topics
  457. Portal:Ghana/Ghana topics
  458. Portal:Gibraltar/Gibraltar topics
  459. Portal:Gilbert and Sullivan/Topics
  460. Portal:Gilgit-Baltistan/Topics
  461. Portal:Girls Aloud/Topics
  462. Portal:Glee/Topics
  463. Portal:Global warming/Topics
  464. Portal:Globalization/Key topics
  465. Portal:Globalization/Topics
  466. Portal:Goa/Goa topics
  467. Portal:Google/Topics
  468. Portal:Government of India/Topics
  469. Portal:Government of Pakistan/Topics
  470. Portal:Government of the Philippines/Topics
  471. Portal:Government of the United States/Main topics
  472. Portal:Government of the United States/Topics
  473. Portal:Graffiti/Topics
  474. Portal:Grateful Dead/Topics
  475. Portal:Gravitation/Key Topics
  476. Portal:Greater Manchester/Topics
  477. Portal:Greek mythology/Topics
  478. Portal:Green Day/Topics
  479. Portal:Grenada/Topics
  480. Portal:Grey's Anatomy/Topics
  481. Portal:Guadeloupe/Topics
  482. Portal:Guangzhou/Topics
  483. Portal:Guinea-Bissau/Topics
  484. Portal:Guinea/Topics
  485. Portal:Guitar/Topics in Guitar
  486. Portal:Gujarat/Gujarat topics
  487. Portal:Guyana/Topics
  488. Portal:Gymnastics/Topics
  489. Portal:Haiti/Haiti topics
  490. Portal:Halo/Topics
  491. Portal:Hamburg/Topics
  492. Portal:Hamilton, Ontario/Topics
  493. Portal:Hampshire/Topics
  494. Portal:Haryana/Topics
  495. Portal:Hawaii/Hawaii topics
  496. Portal:Health and fitness/Health topics
  497. Portal:Heavy metal/Topics
  498. Portal:Hellenismos/Topics
  499. Portal:Heraldry/Topics
  500. Portal:Himachal Pradesh/Topics
  501. Portal:Himalaya region/topics
  502. Portal:Hindu mythology/Topics
  503. Portal:Hinduism/Topics
  504. Portal:Hip hop/Hip hop topics
  505. Portal:Hip hop/Topics
  506. Portal:Hisar/Topics
  507. Portal:Hispanic and Latino Americans/Topics
  508. Portal:History of Canada/Topics portals
  509. Portal:History of Canada/Topics
  510. Portal:History of Imperial China/Topics
  511. Portal:History of science/Topics
  512. Portal:History of the Latter Day Saint movement/Topics
  513. Portal:HitchHikers/HitchHikers topics
  514. Portal:Holidays/Holidays topics
  515. Portal:Hong Kong/Hong Kong topics
  516. Portal:Hong Kong/Topics
  517. Portal:Horse racing/Topics
  518. Portal:Horses/Topics
  519. Portal:House, M.D./Topics
  520. Portal:Houston/Topics
  521. Portal:Hudson Valley/Topics
  522. Portal:Human health and performance in space/Topics
  523. Portal:Human rights/Categories and topics/Tabs
  524. Portal:Human rights/Categories and topics
  525. Portal:Human rights/Human rights topics
  526. Portal:Human spaceflight/Topics
  527. Portal:Human–computer interaction/Topics
  528. Portal:Hunger relief/Topics
  529. Portal:Hyderabad/Topics
  530. Portal:Ice hockey/Categories and Main topics/Tabs
  531. Portal:Ice hockey/Categories and Main topics
  532. Portal:Ice hockey/Ice hockey topics
  533. Portal:Iceland/Main topics
  534. Portal:Idaho/Topics
  535. Portal:Igbo/Topics
  536. Portal:Illinois/Illinois topics
  537. Portal:India/Topics
  538. Portal:India/topics
  539. Portal:Indian Premier League/Topics
  540. Portal:Indian classical music/Related topics
  541. Portal:Indian independence movement/Topics
  542. Portal:Indian religions/Topics
  543. Portal:Indian wildlife/Topics
  544. Portal:Indiana Jones/Topics
  545. Portal:Indiana/Indiana topics
  546. Portal:India–Pakistan relations/Topics
  547. Portal:Indigenous peoples in Canada/Topics
  548. Portal:Indigenous peoples of Australia/Topics
  549. Portal:Indigenous peoples of North America/Topics
  550. Portal:Indonesia/Topics
  551. Portal:Indore/Topics
  552. Portal:Industrial music/Topics
  553. Portal:International relations/Topics
  554. Portal:Internet Relay Chat/Topics
  555. Portal:Internet/Topics
  556. Portal:Iran/Topics
  557. Portal:Iranian Azerbaijan/Topics
  558. Portal:Iraq/Topics
  559. Portal:Irem/Topics
  560. Portal:Iron Maiden/Topics
  561. Portal:Islam/Topics
  562. Portal:Islamabad/Islamabad Topics
  563. Portal:Isle of Man TT/Topics
  564. Portal:Isle of Man/Topics
  565. Portal:Isle of Wight/Topics
  566. Portal:Israel/Topics
  567. Portal:Istanbul/Topics
  568. Portal:Italian Wars/Topics
  569. Portal:Jacksonville/Topics
  570. Portal:Jagadguru Rambhadracharya/Topics/list
  571. Portal:Jagadguru Rambhadracharya/Topics
  572. Portal:Jainism/Topics
  573. Portal:Jamaica/Jamaica topics
  574. Portal:James Bond/James Bond topics
  575. Portal:Jane Austen/Topics
  576. Portal:Janet Jackson/Topics
  577. Portal:Japan/Geography/Geological topics
  578. Portal:Japan/Topics
  579. Portal:Japanese cars/Topics box header
  580. Portal:Japanese cars/Topics
  581. Portal:Java/Topics
  582. Portal:Jersey/Topics
  583. Portal:Jessica Simpson/Topics
  584. Portal:Jhelum/Jhelum Topics
  585. Portal:Jodhpur/Topics
  586. Portal:Jordan/Topics
  587. Portal:Journalism/Topics
  588. Portal:Juanes/Topics
  589. Portal:Judaism/Topics
  590. Portal:Jupiter/Topics
  591. Portal:Jurassic/Topics
  592. Portal:Justin Bieber/Topics
  593. Portal:K-pop/Topics
  594. Portal:Kalash Valleys/Topics
  595. Portal:Kandahar/Kandahar Topics
  596. Portal:Kansas/Kansas topics
  597. Portal:Kanye West/Topics
  598. Portal:Karachi/Karachi Topics
  599. Portal:Karate/Topics
  600. Portal:Karnataka/Karnataka topics
  601. Portal:Kashmir/Topics
  602. Portal:Katy Perry/Topics
  603. Portal:Kazakhstan/Kazakhstan topics
  604. Portal:Kelly Clarkson/Topics
  605. Portal:Kent/Categories and Main topics/Categories
  606. Portal:Kent/Categories and Main topics/Featured Content
  607. Portal:Kent/Categories and Main topics/Header
  608. Portal:Kent/Categories and Main topics/Intro
  609. Portal:Kent/Categories and Main topics/Topics
  610. Portal:Kent/Categories and Main topics
  611. Portal:Kentucky/Kentucky topics
  612. Portal:Kenya/Topics
  613. Portal:Kesha/Topics
  614. Portal:Khitan/Articles and topics
  615. Portal:Khyber Pakhtunkhwa/Topics
  616. Portal:Kilkenny/Topics
  617. Portal:King Arthur/King Arthur topics
  618. Portal:Kiribati/Topics
  619. Portal:Knitting/Topics
  620. Portal:Kochi/Topics
  621. Portal:Kolkata/Topics
  622. Portal:Kollam/Topics
  623. Portal:Konami/Topics
  624. Portal:Korea/Korea topics
  625. Portal:Kosovo/Topics
  626. Portal:Kylie Minogue/Topics
  627. Portal:Kyrgyzstan/Topics
  628. Portal:LDS Church/LDS Church topics
  629. Portal:LGBT/Topics
  630. Portal:Lady Gaga/Topics
  631. Portal:Lagos/Topics
  632. Portal:Lahore/Lahore Topics
  633. Portal:Language/Language topic/April 2007
  634. Portal:Language/Language topic/April 2009
  635. Portal:Language/Language topic/August 2006
  636. Portal:Language/Language topic/December 2005
  637. Portal:Language/Language topic/December 2006
  638. Portal:Language/Language topic/February 2007
  639. Portal:Language/Language topic/January 2006
  640. Portal:Language/Language topic/January 2007
  641. Portal:Language/Language topic/July 2006
  642. Portal:Language/Language topic/June 2006
  643. Portal:Language/Language topic/June 2009
  644. Portal:Language/Language topic/March 2007
  645. Portal:Language/Language topic/May 2006
  646. Portal:Language/Language topic/May 2009
  647. Portal:Language/Language topic/Nominate
  648. Portal:Language/Language topic/November 2006
  649. Portal:Language/Language topic/October 2006
  650. Portal:Language/Language topic/September 2006
  651. Portal:Language/Language topic
  652. Portal:Language/Selected topic/1
  653. Portal:Language/Selected topic/2
  654. Portal:Language/Selected topic/3
  655. Portal:Language/Selected topic/4
  656. Portal:Language/Selected topic/5
  657. Portal:Language/Selected topic/Layout
  658. Portal:Language/Selected topic
  659. Portal:Las Vegas/Las Vegas topics
  660. Portal:Latin America/Topics
  661. Portal:Latin music/Topics
  662. Portal:Latter Day Saints/Latter Day Saints topics
  663. Portal:Latvia/Main topics
  664. Portal:Laurentides/Topics
  665. Portal:Law enforcement/Law enforcement topics1
  666. Portal:Law enforcement/Law enforcement topics
  667. Portal:Law of England and Wales/Topics
  668. Portal:Lebanon/Topics
  669. Portal:Led Zeppelin/Topics
  670. Portal:Lepidosaurs/Topics
  671. Portal:Liberalism/Liberalism topics
  672. Portal:Liberia/Topics
  673. Portal:Libertarianism/Libertarianism topics
  674. Portal:Libertarianism/Topics
  675. Portal:Library and information science/Library and information science topics
  676. Portal:Lighthouses/Topics
  677. Portal:Linkin Park/Topics
  678. Portal:Linux/Topics
  679. Portal:Liquor/Related topics
  680. Portal:Liquor/Topics/Distilled beverages
  681. Portal:Liquor/Topics
  682. Portal:Literature/Topics
  683. Portal:Lithuania/Topic news
  684. Portal:Lithuania/Topics
  685. Portal:Logic/Topics
  686. Portal:Lost/Topics
  687. Portal:Louisiana/Louisiana topics
  688. Portal:Louisville/Louisville topics
  689. Portal:Lutheranism/Topics
  690. Portal:Luxembourg/Topics
  691. Portal:Lyon/Topics
  692. Portal:Macaronesia/Topics
  693. Portal:Macau/Topics
  694. Portal:Madagascar/Topics
  695. Portal:Madhya Pradesh/Madhya Pradesh topics
  696. Portal:Madonna (entertainer)/Topics
  697. Portal:Madurai/Topics
  698. Portal:Malacca/Topics
  699. Portal:Malawi/Topics
  700. Portal:Malaysia/Topics
  701. Portal:Maldives/Topics
  702. Portal:Mali/Topics
  703. Portal:Malta/Malta topics
  704. Portal:Mammals/Topics
  705. Portal:Mandatory Palestine/Topics
  706. Portal:Manitoba/Topics
  707. Portal:Mariah Carey/Topics
  708. Portal:Marine life/Topics
  709. Portal:Mario/Mario topics
  710. Portal:Mars/Mars topics
  711. Portal:Mars/Topics
  712. Portal:Martial arts/Martial arts topics
  713. Portal:Marvin Gaye/Topics
  714. Portal:Maryland Roads/Topics
  715. Portal:Maryland/Topics
  716. Portal:Masculinism/Topics
  717. Portal:Massachusetts/Topics
  718. Portal:Mathematics/MathematicsTopics
  719. Portal:Mauricie/Topics
  720. Portal:Mauritania/Topics
  721. Portal:Mauritius/Topics
  722. Portal:Medicine/Medicine topics
  723. Portal:Medieval Britain/Topics
  724. Portal:Mediterranean/Topics
  725. Portal:Meghan Trainor/Topics
  726. Portal:Men's rights movement/Topics
  727. Portal:Mesoamerica/Topics
  728. Portal:Mesozoic/Topics
  729. Portal:Messianic Judaism/Messianic Judaism topics
  730. Portal:Metabolism/Metabolism topics
  731. Portal:Metaphysics/Metaphysics topics
  732. Portal:Methodism/Methodism topics
  733. Portal:Mexico/Topics
  734. Portal:Michael Jackson/Topics
  735. Portal:Michigan Highways/Topics
  736. Portal:Michigan/Topics
  737. Portal:Micronations/Topics
  738. Portal:Micronesia/Topics
  739. Portal:Microsoft/Microsoft topics
  740. Portal:Middle Ages/Middle Ages topics
  741. Portal:Miles Davis/Topics
  742. Portal:Miley Cyrus/Miley Cyrus topics
  743. Portal:Miley Cyrus/Topics
  744. Portal:Military history of the Ottoman Empire/Topics
  745. Portal:Military of Australia/Topics
  746. Portal:Military of Greece/Topics
  747. Portal:Military of Pakistan/Topics
  748. Portal:Military of ancient Rome/Military of ancient Rome topics
  749. Portal:Military of the United States/Topics
  750. Portal:Mining/Topics
  751. Portal:Minnesota/Topics
  752. Portal:Mississippi/Mississippi topics
  753. Portal:Missouri/Missouri topics
  754. Portal:Mitochondria/Mitochondria Topics
  755. Portal:Mitochondria/Topics
  756. Portal:Mitt Romney/Topics
  757. Portal:Molecular and cellular biology/Molecular and cellular biology topics
  758. Portal:Molecular anthropology/Topics
  759. Portal:Mombasa/Topics
  760. Portal:Monarchy/Topics Intro
  761. Portal:Monarchy/Topics
  762. Portal:Mongolia/Topics
  763. Portal:Monmouth/Topics
  764. Portal:Montana/Topics
  765. Portal:Montenegro/Topics
  766. Portal:Montreal/Topics
  767. Portal:Monty Python/topics
  768. Portal:Montérégie/Topics
  769. Portal:Moon/Topics
  770. Portal:Mosses/Topics
  771. Portal:Motörhead/Motörhead topics
  772. Portal:Mozambique/Topics
  773. Portal:Mumbai/Topics
  774. Portal:Munich/Topics
  775. Portal:Muppets/Muppets topics
  776. Portal:Music of Australia/Music of Australia topics
  777. Portal:Music of Canada/Topics
  778. Portal:Musical theatre/Musical theatre topics
  779. Portal:Myanmar/Topics
  780. Portal:NASCAR/Topics
  781. Portal:NATO/NATO topics
  782. Portal:Nairobi/Topics
  783. Portal:Namibia/Topics
  784. Portal:Narnia/Narnia topics
  785. Portal:National Basketball Association/Topics
  786. Portal:National Basketball League (Australia)/Topics
  787. Portal:National Basketball League of Canada/Topics
  788. Portal:National Football League/Topics
  789. Portal:National Register of Historic Places/Topics
  790. Portal:Nautical/Nautical topics
  791. Portal:Negros Oriental/Negros Oriental topics
  792. Portal:Neogene/Topics
  793. Portal:Neue Deutsche Härte/Topics
  794. Portal:Neuroscience/Neuroscience topics
  795. Portal:Nevada/Topics
  796. Portal:New Brunswick/Topics
  797. Portal:New England/Topics
  798. Portal:New Orleans/New Orleans topics
  799. Portal:New South Wales/Topics/Sandbox
  800. Portal:New South Wales/Topics
  801. Portal:New Spain/Topics
  802. Portal:New York (state)/Topics
  803. Portal:New Zealand/Topics
  804. Portal:Newar/topics
  805. Portal:Newfoundland and Labrador/Topics
  806. Portal:Nickelodeon/Topics
  807. Portal:Nicki Minaj/Topics
  808. Portal:Niger/Topics
  809. Portal:Nigeria/Topics
  810. Portal:Nintendo/Nintendo topics
  811. Portal:Nontheism/Nontheism topics
  812. Portal:North America/Topics
  813. Portal:North Carolina/Topics
  814. Portal:North Dakota/Topics
  815. Portal:North East England/Topics
  816. Portal:North Korea/North Korea topics
  817. Portal:North Rhine-Westphalia/Topics
  818. Portal:North West England/North West England topics
  819. Portal:Northamptonshire/Topics
  820. Portal:Northern Territory/Topics
  821. Portal:Northwest Territories/Topics
  822. Portal:Norway/Norway topics
  823. Portal:Nova Scotia/Topics
  824. Portal:Nuclear technology/Related topics
  825. Portal:Number theory/Topics
  826. Portal:Numismatics/Numismatic topics
  827. Portal:Nunavut/Nunavut topics
  828. Portal:Occult/Occult topics
  829. Portal:Odisha/Topics
  830. Portal:Oklahoma/Oklahoma topics
  831. Portal:Olympics/Olympics Topics
  832. Portal:Oman/Topics
  833. Portal:Ontario/Topics
  834. Portal:Opera/Opera topics
  835. Portal:Ordovician/Topics
  836. Portal:Oregon/topics
  837. Portal:Organic chemistry/Organic chemistry Topics
  838. Portal:Organized Labour/Organized Labour topics
  839. Portal:Oriental Orthodoxy/Oriental Orthodoxy topics/Background
  840. Portal:Osaka/Topics
  841. Portal:Oscar Wilde/Topics
  842. Portal:Ottawa/Topics
  843. Portal:Ottoman Empire/Topics
  844. Portal:Oxfordshire/Topics
  845. Portal:Oz/Topics
  846. Portal:Pac-Man/Topics
  847. Portal:Pakistan Super League/Topics
  848. Portal:Paleogene/Topics
  849. Portal:Paleontology/Topics
  850. Portal:Paleozoic/Topics
  851. Portal:Palestine/Topics
  852. Portal:Panama/Panama topics
  853. Portal:Papua New Guinea/Papua New Guinea topics
  854. Portal:Paris/Topic news
  855. Portal:Parliamentary procedure/General topics
  856. Portal:Parliamentary procedure/Topics
  857. Portal:Peer review/Topics
  858. Portal:Pennsylvania/Pennsylvania topics
  859. Portal:Pensacola/Topics
  860. Portal:People's Republic of China/People's Republic of China topics
  861. Portal:Percussion/Topics
  862. Portal:Permian/Topics
  863. Portal:Peru/Topics
  864. Portal:Pharmacy and pharmacology/Major topics
  865. Portal:Pharmacy and pharmacology/Medicinal chemistry/Topics
  866. Portal:Pharmacy and pharmacology/Pharmaceutics/Topics
  867. Portal:Pharmacy and pharmacology/Pharmacognosy and Medical Herbs/Topics
  868. Portal:Pharmacy and pharmacology/Pharmacology and Medications/Topics
  869. Portal:Philippine Basketball Association/Topics
  870. Portal:Philippines/Topics
  871. Portal:Philosophy of science/Topics
  872. Portal:Photography/Topics
  873. Portal:Physical chemistry/Main topics
  874. Portal:Physical chemistry/Physical chemistry Topics
  875. Portal:Physics/Topics
  876. Portal:Piano/Topics
  877. Portal:Pichilemu/Topics
  878. Portal:Pink Floyd/Topics
  879. Portal:Pipe organ/Pipe organ topics
  880. Portal:Piracy/Piracy topics
  881. Portal:Plants/Related topics
  882. Portal:Poetry/Poetry topics
  883. Portal:Pokémon/Categories and Main topics/Header
  884. Portal:Pokémon/Categories and Main topics
  885. Portal:Pokémon/Topics
  886. Portal:Poland/Topics
  887. Portal:Political science/topic/1
  888. Portal:Politics/Categories and topics
  889. Portal:Politics/Topics
  890. Portal:Pondicherry/Topics
  891. Portal:Pop music/Pop music topics
  892. Portal:Pop music/Topics
  893. Portal:Pope/Pope topics
  894. Portal:Pornography/Topics
  895. Portal:Port Harcourt/Topics
  896. Portal:Portugal/Portugal topics
  897. Portal:Powderfinger/Topics
  898. Portal:Precambrian/Topics
  899. Portal:Presidency of the Philippines/Presidency of the Philippines topics
  900. Portal:Primates/Topics
  901. Portal:Prince Edward Island/Topics
  902. Portal:Private revelation/Topics
  903. Portal:Professional wrestling/Topics/10
  904. Portal:Professional wrestling/Topics/11
  905. Portal:Professional wrestling/Topics/12
  906. Portal:Professional wrestling/Topics/13
  907. Portal:Professional wrestling/Topics/1
  908. Portal:Professional wrestling/Topics/2
  909. Portal:Professional wrestling/Topics/3
  910. Portal:Professional wrestling/Topics/4
  911. Portal:Professional wrestling/Topics/5
  912. Portal:Professional wrestling/Topics/6
  913. Portal:Professional wrestling/Topics/7
  914. Portal:Professional wrestling/Topics/8
  915. Portal:Professional wrestling/Topics/9
  916. Portal:Professional wrestling/Topics
  917. Portal:Progressive rock/Progressive rock topics
  918. Portal:Psychiatry/Topics
  919. Portal:Psychology/Psychology topics
  920. Portal:Puerto Rico/topics
  921. Portal:Punjab (Pakistan)/Punjab (Pakistan) topics
  922. Portal:Punjab/Punjab topics
  923. Portal:Pyrotechnics/Pyrotechnics topics
  924. Portal:Python programming/Python programming topics
  925. Portal:Quaternary prehistory/Topics
  926. Portal:Quebec City/Topics
  927. Portal:Quebec/Quebec Topics
  928. Portal:Queen (band)/Topics
  929. Portal:Queens of the Stone Age/Topics
  930. Portal:Queensland/Topics
  931. Portal:Quran/Topics
  932. Portal:R&B and Soul Music/Topics
  933. Portal:Rabbits and hares/Topics
  934. Portal:Rabindranath Tagore/Rabindranath Tagore topics
  935. Portal:Radio/Radio topics
  936. Portal:Ravidassia/Topics
  937. Portal:Regina/Topics
  938. Portal:Religion/Categories and Main topics/Header
  939. Portal:Religion/Categories and Main topics
  940. Portal:Religion/Topics
  941. Portal:Republic of the Congo/Topics
  942. Portal:Republican Party/Topics
  943. Portal:Rhetoric/Rhetoric topics
  944. Portal:Rhode Island/Topics
  945. Portal:Right-wing populism/Topics
  946. Portal:Rihanna/Topics
  947. Portal:Rivers State/Topics
  948. Portal:Rivers/Topics
  949. Portal:Roads/Topics
  950. Portal:Robert E. Howard/Topics
  951. Portal:Robotics/Topics
  952. Portal:Rock climbing/Topics
  953. Portal:Rock music/Topics
  954. Portal:Roman Catholic Church/Portal:Topic/box-header
  955. Portal:Romani people/Romani people topics
  956. Portal:Romanian football/Topics
  957. Portal:Royal Australian Navy/Topics
  958. Portal:Royal Navy/Topics
  959. Portal:Rufus Wainwright/Topics
  960. Portal:Rugby Union/Rugby Union topics
  961. Portal:Rugby league/Categories and main topics/Tabs
  962. Portal:Rugby league/Categories and main topics
  963. Portal:Rugby league/Rugby league topics
  964. Portal:Rugby union/Rugby union topics
  965. Portal:Rugby/Rugby topics
  966. Portal:Rush/Topics
  967. Portal:Russia/Russia topics
  968. Portal:Russian Empire/Topics
  969. Portal:Rwanda/Topics
  970. Portal:Ryukyu/Topics
  971. Portal:SNK/SNK topics
  972. Portal:Sabah/Topics
  973. Portal:Sacred Christian music/Topics
  974. Portal:Saguenay–Lac-Saint-Jean/Topics
  975. Portal:Sailing/Topics
  976. Portal:Saints/Saints topics
  977. Portal:Sakis Rouvas/Topics
  978. Portal:Salamanders/Topics
  979. Portal:San Diego County/Topics
  980. Portal:San Diego–Tijuana/Topics/Header
  981. Portal:San Diego–Tijuana/Topics/Section 1
  982. Portal:San Diego–Tijuana/Topics/Section 2
  983. Portal:San Diego–Tijuana/Topics/Sections
  984. Portal:San Diego–Tijuana/Topics
  985. Portal:San Francisco Bay Area/San Francisco Bay Area topics
  986. Portal:San Francisco Bay Area/Topics/Header
  987. Portal:San Francisco Bay Area/Topics/Section 1
  988. Portal:San Francisco Bay Area/Topics/Section 2/Archive
  989. Portal:San Francisco Bay Area/Topics/Section 2
  990. Portal:San Francisco Bay Area/Topics/Sections
  991. Portal:San Francisco Bay Area/Topics
  992. Portal:Santana/Topics
  993. Portal:Sarawak/Topics
  994. Portal:Sasanian Empire/Topics
  995. Portal:Saskatchewan/Topics
  996. Portal:Saudi Arabia/Saudi Arabia topics
  997. Portal:Schools/Topics
  998. Portal:Science/Categories and Main topics/Header
  999. Portal:Science/Categories and Main topics
  1000. Portal:Scientology/Topics
  1001. Portal:Scotland/Major topics
  1002. Portal:Seattle Sounders FC/Topics
  1003. Portal:Seattle/Topics
  1004. Portal:Sega/Sega topics
  1005. Portal:Selena/Topics
  1006. Portal:Senegal/Topics
  1007. Portal:September 11 attacks/Topics
  1008. Portal:Serbia/Topics
  1009. Portal:Serer people/Topics
  1010. Portal:Serer religion/Topics
  1011. Portal:Serials/Topics
  1012. Portal:Set theory/Topics
  1013. Portal:Seventh-day Adventist Church/Topics
  1014. Portal:Sexuality/Topics
  1015. Portal:Shakespeare/Topics list
  1016. Portal:Shakespeare/Topics
  1017. Portal:Shakira/Topics
  1018. Portal:Shanghai/Topics
  1019. Portal:Shania Twain/Shania Twain topics
  1020. Portal:Sharjah/Topics
  1021. Portal:Shenzhen/Topics
  1022. Portal:Sherlock Holmes/Topics
  1023. Portal:Sierra Leone/Topics
  1024. Portal:Sikhism/Topics
  1025. Portal:Sikkim/Major topics
  1026. Portal:Silent film/Topics
  1027. Portal:Silesia/Silesia topics
  1028. Portal:Silurian/Topics
  1029. Portal:Sindh/Topics
  1030. Portal:Singapore/Singapore topics
  1031. Portal:Slipknot/Topics
  1032. Portal:Smooth jazz/Topics
  1033. Portal:Snakes/Topics
  1034. Portal:Snooker/Snooker topics
  1035. Portal:Soap operas and telenovelas/Topics
  1036. Portal:Soccer in the United States/Topics
  1037. Portal:Social movements/Topics
  1038. Portal:Socialism/Topics
  1039. Portal:Sociology/Sociology topics
  1040. Portal:Soft Rock/Topics
  1041. Portal:Software testing/Software testing topics
  1042. Portal:Software/Software topics
  1043. Portal:Solar System/Solar System topics/imagebox
  1044. Portal:Solar System/Solar System topics
  1045. Portal:Somalia/topics
  1046. Portal:Somaliland/topics
  1047. Portal:Somerset/Topics
  1048. Portal:Sonic the Hedgehog/Sonic topics
  1049. Portal:Sony PlayStation/Sony PlayStation topics
  1050. Portal:Sony Playstation/Sony Playstation topics
  1051. Portal:Sony/Sony topics
  1052. Portal:South Australia/Topics
  1053. Portal:South Korea/South Korea topics
  1054. Portal:South Park/Topics
  1055. Portal:South Sudan/Topics
  1056. Portal:Soviet Union/Soviet topics
  1057. Portal:Space exploration/Topics
  1058. Portal:Space tourism/Topics
  1059. Portal:Space/Topics/Categories
  1060. Portal:Space/Topics/Lists
  1061. Portal:Space/Topics
  1062. Portal:Spaceflight/Key topics
  1063. Portal:Spaceflight/Topics/Categories
  1064. Portal:Spaceflight/Topics
  1065. Portal:Spain/Topics
  1066. Portal:Speculative fiction/Fantasy/Topics
  1067. Portal:Speculative fiction/Horror/Topics
  1068. Portal:Speculative fiction/Science fiction/Topics
  1069. Portal:Speculative fiction/Topics
  1070. Portal:Spirituality/Spirituality-related topics
  1071. Portal:SpongeBob SquarePants/Topics
  1072. Portal:Sports and games/Categories and Main topics
  1073. Portal:Sports in Canada/Topics
  1074. Portal:Sports/Categories and main topics/Tabs
  1075. Portal:Sri Lanka Railways/Topics
  1076. Portal:Sri Lanka/Topics
  1077. Portal:St. John's, Newfoundland and Labrador/Topics
  1078. Portal:Staffordshire/Topics
  1079. Portal:Stamford/Topics
  1080. Portal:Star Trek/Topic news
  1081. Portal:Star Trek/Topics
  1082. Portal:Star Wars/Topics
  1083. Portal:Star/Topics/Tabs2
  1084. Portal:Star/Topics/TabsTop
  1085. Portal:Star/Topics
  1086. Portal:Statistics/Topics
  1087. Portal:Strategy games/Strategy games topics
  1088. Portal:Strictly Come Dancing/Topics
  1089. Portal:Studio Ghibli/Topics
  1090. Portal:Submarine/Topics
  1091. Portal:Sudan/Topics
  1092. Portal:Sufism/Sufism topics
  1093. Portal:Superhero fiction/Topics
  1094. Portal:Supreme Court of the United States/Topics
  1095. Portal:Suriname/Topics
  1096. Portal:Surrey/Surrey topics
  1097. Portal:Sussex/Topics
  1098. Portal:Sustainable development/Topics/Sustainability and energy development
  1099. Portal:Sustainable development/Topics
  1100. Portal:Sweden/Main topics
  1101. Portal:Swimming/Topics
  1102. Portal:Syracuse, New York/Topics
  1103. Portal:Syria/Topics
  1104. Portal:Syriac Christianity/Topics
  1105. Portal:Systems science/Topics
  1106. Portal:São Tomé and Príncipe/Topics
  1107. Portal:Taito/Topics
  1108. Portal:Taiwan/Taiwan topics
  1109. Portal:Taiwan/Topics
  1110. Portal:Tajikistan/Tajikistan topics
  1111. Portal:Tamil Eelam/Topics
  1112. Portal:Tamil People/Topics
  1113. Portal:Tamil civilization/Topics
  1114. Portal:Tank/Topics
  1115. Portal:Tanzania/Topics
  1116. Portal:Tasmania/Topics
  1117. Portal:Taylor Swift/Topics
  1118. Portal:Technology/Topics
  1119. Portal:Television in Australia/Topics
  1120. Portal:Television in Canada/Topics
  1121. Portal:Television in the United Kingdom/Topics
  1122. Portal:Television in the United States/Topics
  1123. Portal:Television/Topics
  1124. Portal:Tennessee/Topics
  1125. Portal:Tennis/Topics
  1126. Portal:Terrorism/Topics
  1127. Portal:Texas/Texas topics
  1128. Portal:Textile arts/Textile arts topics
  1129. Portal:Thailand/topics
  1130. Portal:The Beach Boys/Topics
  1131. Portal:The Clash/Topics
  1132. Portal:The Gambia/Topics
  1133. Portal:The Jackson Family/Topics
  1134. Portal:The Kinks/Topics
  1135. Portal:The Legend of Zelda/Zelda topics
  1136. Portal:The Rolling Stones/Topics
  1137. Portal:The Simpsons/Topics
  1138. Portal:The Sims/Topics
  1139. Portal:The Supremes/Topics
  1140. Portal:The X-Files/Topics
  1141. Portal:Theatre/Theatre topics
  1142. Portal:Theosophy/Topics
  1143. Portal:Thinking/Topics
  1144. Portal:Tibet/Topics
  1145. Portal:Tibetan Buddhism/Topics
  1146. Portal:Time/Time topics
  1147. Portal:Tirana/Tirana topics
  1148. Portal:Tiruchirappalli/Topics
  1149. Portal:Tobago/Tobago topics
  1150. Portal:Togo/Topics
  1151. Portal:Topology/Topics
  1152. Portal:Toys/Topics
  1153. Portal:Traditional African religion/Topics
  1154. Portal:Transgender/Topics
  1155. Portal:Transhumanism/MajorTopics
  1156. Portal:Transhumanism/TopicsTechs
  1157. Portal:Transnational child protection/Topics
  1158. Portal:Transport/Topics
  1159. Portal:Transport/Transport topics
  1160. Portal:Transylvania/Topics
  1161. Portal:Triassic/Topics
  1162. Portal:Trinidad and Tobago/Topics
  1163. Portal:Trucks/Topics
  1164. Portal:Tunisia/Topics
  1165. Portal:Turkey/Topics
  1166. Portal:Turkish Armed Forces/Topics
  1167. Portal:Turkmenistan/Topics
  1168. Portal:Turtles/Topics
  1169. Portal:Tuvalu/Topics
  1170. Portal:Twilight/Topics
  1171. Portal:Typography/Topics
  1172. Portal:U2/U2 topics
  1173. Portal:UK Waterways/Topics
  1174. Portal:Udaipur/Topics
  1175. Portal:Ukraine/Ukrainian topics
  1176. Portal:Ulaanbaatar/Topics
  1177. Portal:Ulcinj/Topics
  1178. Portal:Underwater diving/Topics
  1179. Portal:United Arab Emirates/United Arab Emirates topics
  1180. Portal:United Nations/Topics
  1181. Portal:United States Air Force/Topics
  1182. Portal:United States/Topics
  1183. Portal:Universities in Azerbaijan/Related topics
  1184. Portal:Universities in Azerbaijan/Topics
  1185. Portal:University of Cambridge/Topics
  1186. Portal:University of Chicago/Topics
  1187. Portal:University of Oxford/Topics
  1188. Portal:University/Topics
  1189. Portal:Unix/Topics
  1190. Portal:Uranus/Topics
  1191. Portal:Uruguay/Topics
  1192. Portal:Usher/Topics
  1193. Portal:Utah/topics
  1194. Portal:Uzbekistan/Topics
  1195. Portal:Vajrayana Buddhism/Topics
  1196. Portal:Venezuela/Venezuela topics
  1197. Portal:Venomous snakes/Topics
  1198. Portal:Victoria/Topics
  1199. Portal:Victorian era/Topics
  1200. Portal:Video games/Featured topic/10
  1201. Portal:Video games/Featured topic/11
  1202. Portal:Video games/Featured topic/12
  1203. Portal:Video games/Featured topic/13
  1204. Portal:Video games/Featured topic/14
  1205. Portal:Video games/Featured topic/15
  1206. Portal:Video games/Featured topic/16
  1207. Portal:Video games/Featured topic/17
  1208. Portal:Video games/Featured topic/18
  1209. Portal:Video games/Featured topic/1
  1210. Portal:Video games/Featured topic/2
  1211. Portal:Video games/Featured topic/3
  1212. Portal:Video games/Featured topic/4
  1213. Portal:Video games/Featured topic/5
  1214. Portal:Video games/Featured topic/6
  1215. Portal:Video games/Featured topic/7
  1216. Portal:Video games/Featured topic/8
  1217. Portal:Video games/Featured topic/9
  1218. Portal:Video games/Featured topic
  1219. Portal:Video games/Topics
  1220. Portal:Vienna/Topics
  1221. Portal:Vietnam/Topics
  1222. Portal:Virginia/Virginia topics
  1223. Portal:Viruses/Topics
  1224. Portal:Visual arts/Topics
  1225. Portal:Volcanism of Canada/Volcanism of Canada topics
  1226. Portal:Volcanoes/Volcanoes topics
  1227. Portal:Wales/Topics
  1228. Portal:War of 1812/Topics
  1229. Portal:War/Topics
  1230. Portal:Warhammer/Warhammer topics
  1231. Portal:Washington & Jefferson College/Topics
  1232. Portal:Washington, D.C./Topics
  1233. Portal:Washington/Topics
  1234. Portal:Water sports/Topics
  1235. Portal:Weapons of mass destruction/Weapons of mass destruction topics
  1236. Portal:Weather/Featured content/Topics
  1237. Portal:Weimar Republic/Topics
  1238. Portal:West Bengal/Major topics
  1239. Portal:West Virginia/West Virginia topics
  1240. Portal:Western Australia/Western Australia topics
  1241. Portal:Western Sahara/Western Sahara topics
  1242. Portal:Wetlands/Topics
  1243. Portal:Whitney Houston/Topics
  1244. Portal:Wicca/Wicca topics
  1245. Portal:Wiltshire/Topics
  1246. Portal:Wine/Wine topics
  1247. Portal:Wisconsin/topics
  1248. Portal:Women's association football/Topics
  1249. Portal:World War I/Topics
  1250. Portal:World War II/Topics
  1251. Portal:World War II/World War II topics
  1252. Portal:Writing/Topics
  1253. Portal:Wyoming/topics
  1254. Portal:X-ray astronomy/Topics
  1255. Portal:Xbox 360/Main Topics
  1256. Portal:Xbox 360/Xbox 360 topics
  1257. Portal:Years/Topics
  1258. Portal:Yoga/Topics
  1259. Portal:Yorkshire/Yorkshire topics
  1260. Portal:Yoruba/Topics
  1261. Portal:Yukon/Topics
  1262. Portal:Zambia/Topics
  1263. Portal:Zimbabwe/Topics
  1264. Portal:Zoos and aquariums/Topics
  1265. Portal:Zoroastrianism/Topics

Thank you.     — The Transhumanist    10:27, 11 April 2018 (UTC)[reply]

Notices on every portal

Important: A notice of this deletion discussion should have been placed at the top of every page being proposed for deletion three days ago, when this discussion was started. Such notices are now in place. Enough time should be provided for the users and maintainers of the various portals to weigh in.     — The Transhumanist    12:00, 11 April 2018 (UTC)[reply]
But The Transhumanist, you've put your notice at the top of Community portal as well, which although it has "portal" in the title is not in Portal: space and has been repeatedly stated not to fall within the scope of the proposal: Noyster (talk), 12:55, 11 April 2018 (UTC)[reply]
Thank you for the clarification. It should be exempted in the proposal itself, for clarity, and not just be buried in the huge discussion below. The notice has been removed from the top of the page there, and a more general notice has been included in the Community Bulletin Board further down the page.     — The Transhumanist    13:52, 11 April 2018 (UTC)[reply]
In any case Transhumanist is completely right in pointing out that such a survey should not be performed without informing those primarily affected (many editors and potentially portal users/maintainers do not follow village pump discussions regularly or at all).--Kmhkmh (talk) 13:48, 11 April 2018 (UTC)[reply]
  • I've moved this down; the top of the RfC isn't the place for this discussion and should remain neutral and short. RfC's usually are held open for 30 days, and thus three days is immaterial overall Galobtter (pingó mió) 15:41, 11 April 2018 (UTC)[reply]
  • The Transhumanist next time it'd have been better to use a template and transclude the message, since it is same for all 1500 articles - thus it can be changed as necessary (if the discussion moves, if the wording needs to be changed etc) Galobtter (pingó mió) 16:05, 11 April 2018 (UTC)[reply]
I chose to post a static notice because it is preserved in the historical versions of the pages it is posted on. Templates morph, so what you see in a historical version is not necessarily what actually appeared there when that version was created. Context may be important here. Thank you for your comment.     — The Transhumanist    00:19, 12 April 2018 (UTC)[reply]

The opening text should be "Should the system of portals be ended? This would include the deletion of all portal pages and the removal of the portal namespace" and then add "with the following exceptions:" (and list the exceptions) Cambalachero (talk) 15:58, 11 April 2018 (UTC)[reply]

Tagging this discussion to all portals is close to inappropriate canvassing→ to draw in the handful of users who work on this failed part of Wikipedia. This discussion needs to the input of all users which is why VP is an appropriate venue. Where else can we advertise this RFC to attract in a proper cross section of all users? Legacypac (talk) 17:16, 11 April 2018 (UTC)[reply]
So "all users" doesn't include users watching/editing/reading the portal pages themselves? Your point of view on this strikes me as completely illogical. - dcljr (talk) 23:23, 11 April 2018 (UTC)[reply]
If you are part of a project then there is a good chance it's connected to a portal. - Knowledgekid87 (talk) 17:20, 11 April 2018 (UTC)[reply]
@Legacypac: By the same logic, it is inappropriate canvassing to tag a page when it is nominated for WP:MFD. RockMagnetist(talk) 18:10, 11 April 2018 (UTC)[reply]
Which is why I did not call it out as canvassing. This whole area is so disliked we need to be careful not to influence the results to heavily by advertising. On the plus side, by placing a notification no one can whine when we remove any given portal. Legacypac (talk) 18:25, 11 April 2018 (UTC)[reply]
Considering there appears to still be some support for the use of Portals, at least based on the discussion above, I think calling the Portal system "widely disliked" might be either a stretch or inaccurate to say the least. Also, regardless of our opinions of the system, as these editors are the primary editors for the namespace, they should have been informed sooner, and it's right to have left them messages about this discussion. Narutolovehinata5 tccsdnew 00:26, 12 April 2018 (UTC)[reply]
  • I am concerned that a failure to communicate this RfC to the Portals from the outset (as we would for an AfD/MFD) has built up a 'head of steam' wherein many are already assuming Portals serve no purpose whatsoever, and are wielding their pitchforks and making plans for their imminent global demise. For Legacypac to suggest communicating this RfC at the Portals themselves is ...close to inappropriate canvassing is ridiculous, and seems close to the Vogon Planning Process. Many thanks to The Transhumanist for notifying some of the Portals three days after the RfC began. A quick check reveals many smaller Portal pages have still not been informed (e.g.1, 2, 3, 4, 5, 6, 7, 8, 9, 10). Is this an oversight, or the misfortune of poor original categorisation? Nick Moyes (talk) 01:56, 12 April 2018 (UTC)[reply]
I posted the notice to the 1143 portals listed at Portal:Contents/Portals, for expediency. I'm in the process of tracking down the portals not listed there.  Done I've posted to all other portals (without slashes in the titles).     — The Transhumanist    06:35, 12 April 2018 (UTC)[reply]
I've just added the notice to WP:AALERTS subscriptions. Headbomb {t · c · p · b} 23:49, 12 April 2018 (UTC)[reply]

"Close to inappropriate canvassing"?

I agree with Legacypac that tagging this discussion to 1143 portals (and rising!) portals is close to inappropriate canvassing, but does not actually cross the line. Others, of course will disagree with my personal opinion on this, which is fine.

Instead of focusing on whether it was canvassing ("is close to" does not equal "is"), I would like to instead focus on whether adding the following notice

to over a thousand pages caused (I would assume inadvertently) a biased sample of responses to this proposal. This is not a forgone conclusion. As someone pointed out above, we don't have a problem when we tag a page that is nominated for WP:MFD. The obvious counterargument would be that tagging 1 page and tagging 1143 pages just might have different effects on a discussion.

I don't think that anyone will be willing to argue that this has had no effect on the discussion, but I can see an argument that the effect is not harmful. I could go either way on that question. --Guy Macon (talk) 19:08, 13 April 2018 (UTC)[reply]

  • Comment it has been argued above many times that portals are seldom visited and not used. If that's the case, then the potential "canvassing" has very little impact. Further, whenever a page is proposed for deletion a notice is put on that page so that those who follow that page can comment. I don't see it as "canvassing" at all.--Paul McDonald (talk) 20:44, 13 April 2018 (UTC)[reply]
  • Comment This is the second time the same editor has brought up canvassing. - Knowledgekid87 (talk) 22:00, 13 April 2018 (UTC)[reply]
    • Give it a rest. Your posting comment after comment criticizing me is becoming disruptive. Everyone is aware of your low opinion of me. You don't have to keep pounding on it. If you think you have a legitimate complaint, take it to WP:ANI.. --Guy Macon (talk) 04:22, 14 April 2018 (UTC)[reply]
  • I do not see any problems with these notifications. They are worded accurately, and it is entirely appropriate to notify all editors who see portals on their watchlists. I would, instead, see a concern about a biased sample if such notice had not been made. --Tryptofish (talk) 21:58, 13 April 2018 (UTC)[reply]
  • I see no problem putting notices on pages that would be deleted/redirected/archived as if it were an XfD. Killiondude (talk) 22:01, 13 April 2018 (UTC)[reply]
  • It is very much the business of portal watchers and editors to know that there is a discussion going on about whether to delete the entire portal namespace. There's nothing inappropriate about it. Master of Time (talk) 22:12, 13 April 2018 (UTC)[reply]
  • For the record I fully disagree with calling this "inappropriate canvassing". The idea here is to inform the community that would be impacted from this change which was done through a neutral message. - Knowledgekid87 (talk) 22:17, 13 April 2018 (UTC)[reply]

An admin is needed to put a notice on Portal:Current events

I couldn't put one there because the page is protected.     — The Transhumanist    07:41, 12 April 2018 (UTC)[reply]

  • don't think a notice is necessary there, I don't see anyone really arguing for its deletion. Wasn't my intention at-least to really include it, if the portal namespace is deleted it'd be moved to wikipedia space. Galobtter (pingó mió) 07:44, 12 April 2018 (UTC)[reply]
    • The problem is that there is a difference between what you intended and what you proposed. Your proposal states: "This would include the deletion of all portal pages and the removal of the portal namespace." All portals. And that is what is being surveyed with "Support" and "Oppose". And Legacypac has been quite explicit. So, until the proposal states otherwise, or until you add an amendment up there, that proposal is what I'm notifying others about. As far as I'm concerned your proposal includes Portal:Contents and Portal:Current events because they are portals and your proposal says "all portals". So, please do not remove the notices until the proposal is amended. Thank you.     — The Transhumanist    09:12, 12 April 2018 (UTC)[reply]
 Done. As The Transhumanist correctly points out, the proposal is to delete all pages that begin with Portal:, so all should be tagged. Regards SoWhy 13:59, 16 April 2018 (UTC)[reply]
Uh, hey guys, nice discussion you're having here, but how about putting these templates on talk pages? They'd still look awfully pointy, but at least they wouldn't be in the way. Isa (talk) 17:08, 16 April 2018 (UTC)[reply]
@Isa Few people use portals so it doesn't make much difference Cesdeva (talk) 17:17, 16 April 2018 (UTC)[reply]
@Cesdeva: Yeah, sorry, I'm really not in the market for baits right now. I don't care about this RFC, but may I suggest the templates be either removed or moved to talk pages until it runs its course? Isa (talk) 17:21, 16 April 2018 (UTC)[reply]
I object to including a deletion template on a page thst is not proposed for deletion. That is being very POINTY SoWhy. Legacypac (talk) 17:31, 16 April 2018 (UTC)[reply]
Where do you see in "Should the system of portals be ended? This would include the deletion of all portal pages and the removal of the portal namespace" that it isn't proposed for deletion? - Knowledgekid87 (talk) 17:46, 16 April 2018 (UTC)[reply]
All through the discussion and ^^^ right here. Legacypac (talk) 17:48, 16 April 2018 (UTC)[reply]
This is only chat, the outcome would go by the central survey question. Portal:Current events is still a portal and would be included in the discussion unless otherwise noted by the closing admin. - Knowledgekid87 (talk) 17:51, 16 April 2018 (UTC)[reply]

Right, let's start again. I don't care about what's a portal and what's not. I see little to no discussion on whether these notices should have been posted in the first place, and I'm also seeing some concern on the copy/pasting on thousands of pages. I would propose that these notices are either 1) completely removed, or 2) moved to the talk pages. Isa (talk) 17:59, 16 April 2018 (UTC)[reply]

(UTC)

@Isanae: Sorry! I wasnt aiming it at you, despite the ping. As for the suggestion I think there is confusion over whether to treat this as a normal RfC where talk pages would get notified or treat it like a deletion discussion where the page would get tagged. It really is a pseudo-MfD, don't you think? Either way i'm not the editor to be speaking to. Kind regards, Cesdeva (talk) 18:00, 16 April 2018 (UTC)[reply]
I disagree with your proposal because this is a deletion discussion. When this is RfC closed, we are going to open another to talk about deletion as it has already been done above. - Knowledgekid87 (talk) 19:47, 16 April 2018 (UTC)[reply]

The Main Page is a portal

Remarkably little has been said about what portals do or should do. At present, they largely duplicate the functions of the Main Page, but for a subdomain of Wikipedia. These include boxes for a featured article; a featured picture; Did You Know; related portals; On this day/In this month; In the News; and related content in other Wikimedia projects. They also can have links to related WikiProjects and a list of suggestions for how editors can contribute. Not all portals have all of this content, of course; it depends on the energy of the editors.

So, in essence, the Main Page is a portal. Should we keep it? If so, why should we delete other portals, which serve a very similar function? If there is a benefit, say, to displaying a Featured Article on the Main Page for a few hours, then isn't there an added benefit to displaying it periodically on another portal? RockMagnetist(talk) 17:26, 11 April 2018 (UTC)[reply]

WP:DDMP - Enough said. - Knowledgekid87 (talk) 17:34, 11 April 2018 (UTC)[reply]
Radical idea, but (like YouTube for example) the main page could be a personalised portal, where you’d have links related to your own interests. Of course if you aren’t logged in, something would need to go there instead... Aiken D 19:09, 11 April 2018 (UTC)[reply]
@Aiken D: I like your idea, although I don't know how it would be implemented. RockMagnetist(talk) 00:04, 12 April 2018 (UTC)[reply]
Keep the Main Page, but replace the portal links with links to the nearest equivalent categories. Lojbanist remove cattle from stage 22:17, 11 April 2018 (UTC)[reply]
Main page encourages content - featuring on it is a something that people make articles for. Not the same for other portals. Galobtter (pingó mió) 02:49, 12 April 2018 (UTC)[reply]

Move the Main_Page to the Portal: namespace (maybe Portal:Home) as default for logged out and new users, and then add an ability that allows users to set any other Portal: as their personal "Main_Page". This would certainly up the quality within the Portal namespace. Editors or groups of editors would work together to build the best alternative home pages. Imagine a portal for administrators, linking to various maintenance areas and alerting them to backlogs. Or just being able to set a home page devoted to a topic area you find interesting to edit in. This may not be 100% personalized, but it could build communities around the portals as the interested users keep them updated. That seems to me what they were for, we just have not been doing enough to bring people to the portals in a natural way. -- Netoholic @ 10:51, 12 April 2018 (UTC)[reply]

It seems like deleting the main page is perpetually a forbidden fruit that people raise as a necessary consequence of every proposal in any way that anyone can imagine is necessary. Why does this crazy idea get proposed so much? I wonder if at Google or Amazon or whatever their developers always talk about deleting the main page. Deleting the main page is starting to seem like a sport or perennial proposal. Blue Rasberry (talk) 20:37, 13 April 2018 (UTC)[reply]

Research that hasn't been done yet

There have been a few hundred deletion debates for portals. What were the decisions and what were the reasons for them? My impression based on a short survey was that portals are generally kept if they have been constructed properly and don't largely duplicate other portals. RockMagnetist(talk) 17:36, 11 April 2018 (UTC)[reply]

What exactly is the activity on a portal? Someone commented that Portal:Arts has only been edited twice in 5 months; well, the Main Page has only been edited 13 times! The content of portals is actually in their subpages; the Arts portal has 341 subpages. It would take a lot of effort to determine how much all those pages had been edited, but perhaps someone should do that before they argue that portals are not maintained. I can offer one anecdote: Over the years, I have edited Portal:Earth sciences 13 times, but its subpages 111 times. RockMagnetist(talk) 17:36, 11 April 2018 (UTC)[reply]

What I'd really like to know when making decisions like this is what the readers think. The readers are a silent majority whose desires we are left guessing with very limited data. We know how many page views portals get, but we don't how much time readers spend there and what links they click. This is undoubtedly data that the WMF has serverside. More sophisticated qualitative questions like what do the readers actually think about portals, what do they want, also go unanswered.
In the event that portals will be discontinued, I'd love to see some actual research into what kind of features readers are missing. It would be crucial for the project to find that interface where readers become interested in editing. Portals were supposed to be that, among other things, but I doubt they ever met that goal. – Finnusertop (talkcontribs) 18:21, 12 April 2018 (UTC)[reply]
The fact editors need to edit subpages and templates to work on a portal is structural reason they will always be a problem. I'm over 100,000 edits and only last year I started to figure out how to change a portal. It's not intuitive like regular wikipages. They are also a weird mix of public facing content, and backend to do lists. The overviews provide limited value, often skimming the surface of a topic using only commonly known info most readers would know already. Legacypac (talk) 18:34, 12 April 2018 (UTC)[reply]
This is more an indictment of the software than of the portal concept. Yes, they are tricky to edit, and require a fair amount of work to learn how, so discouraging maintenance by people who were not involved in creating them, This is not so much a reason to abolish them, as to consider simplifying the system. But is it worth the effort for the advantage gained? I really don't know, and doubt if anyone else does. everyone is guessing. · · · Peter (Southwood) (talk): 18:59, 12 April 2018 (UTC)[reply]

What will replace portals?

When we want to find something on/in Wikipedia we need a guide, an index, someplace to start. That guide has to be logically organized. Language, Literature, Mathematics, Science, Social Science, History, Geography, Computer Science, etc.

AgentCachet (talk) 02:50, 12 April 2018 (UTC)[reply]

Those few portals that are useful and maintained can be turned into "overview of" or "outline of" pages. --Guy Macon (talk) 06:31, 12 April 2018 (UTC)[reply]
@Guy Macon: Doesn't that simply move the problem to "overview of" or "outline of" pages? If that can be controlled by XfD, why not portals? ―Mandruss  07:16, 12 April 2018 (UTC)[reply]
I am not sure what you mean by "the problem". The discussion above has established a strong consensus for the following:
[1] The vast majority of portals are abandoned, poorly maintained, seldom used, and better served by other kinds of pages.
[2] A very few portals (and things called portals that are not in portal space) are worth keeping.
Individual XfDs don't properly address #1. Nuking every single portal with no exceptions doesn't properly address #2. Leaving a few portals in portalspace will encourage the creation of new portals, bringing back the issues we are seeing now. Thus the final solution will almost certainly involve mass-deleting (or possibly fully protecting and marking as historical) the vast majority of portals and moving and/or renaming the few we decide to keep. --Guy Macon (talk) 13:57, 12 April 2018 (UTC)[reply]
Where are you seeing this "strong consensus"? This discussion is ongoing and has yet to be closed. - Knowledgekid87 (talk) 14:00, 12 April 2018 (UTC)[reply]
I do not see anything that looks like a strong consensus, and if one considers the objections to the proposal and the middle of the road positions, it looks more like there is a lot more to the subject than simple summaries - there are a range of issues not even considered in the attempt at summarising.JarrahTree 14:03, 12 April 2018 (UTC)[reply]
By my count, there are currently 94 Support !votes and 61 Oppose !votes. --Guy Macon (talk) 14:13, 12 April 2018 (UTC)[reply]
WP:NOTAVOTE. - Knowledgekid87 (talk) 14:14, 12 April 2018 (UTC)[reply]
...said everyone who was in the process of not getting their way in an RfC ever... --Guy Macon (talk) 20:39, 12 April 2018 (UTC)[reply]
As you have repeatedly admonished other users, Guy, please WP:AGF. - dcljr (talk) 22:20, 12 April 2018 (UTC) — Oh, and WP:CIVIL, while we're at it. - dcljr (talk) 23:48, 12 April 2018 (UTC)[reply]
You appear to lack a clear understanding of what "good faith" means. WP:AGF does not mean "never disagree" or "never criticize". It is entirely possible -- I would even say common -- for someone to be acting in good faith and yet be wrong, as I believe that you were above. I am sure that you -- in good faith -- believe that !votes (please note the "!", which is shorthand for "not votes") do not count, but the actual policy says "While not forbidden, polls should be used with care. When polls are used, they should ordinarily be considered a means to help in determining consensus, but do not let them become your only determining factor." Now had I claimed that you are deliberately misstating our policy on !votes, I would have been assuming bad faith on your part. Recent examples of assuming bad faith in this discussion (not by you) include accusing other editors of "purposely driving off contributing editors" and claiming "this is a deliberate attempt to do an end run around our processes". So what I am saying is that I think that you are wrong, but I am not claiming that you knew that you were wrong and deliberately wrote something that you know to be untrue. In fact, I am not even claiming that you being wrong is an established fact, just that in my opinion the way you characterized NOTAVOTE is not supported by the actual text of that policy. So please stop accusing others of violating AGF when there is no evidence of any actual assumption of bad faith. --Guy Macon (talk) 17:26, 13 April 2018 (UTC)[reply]
I think the right wording here is Passive-aggressive behavior. You are telling editors to assume good faith (which is good) but at the same time accused me of adding toxic material to the above conversation along with a side remark about WP:NOTAVOTE which is how a lot of discussions end up resolved. I wont go further into this as we are going off topic here and recommend this discussion be hatted as unproductive. - Knowledgekid87 (talk) 17:42, 13 April 2018 (UTC)[reply]
I repeat, you should post calm, reasoned arguments supporting your position instead of accusing others of violating AGF when there is no evidence of any actual assumption of bad faith. Again I suggest that you study what the phrase "bad faith" means, with an emphasis on how it is entirely possible to add toxic comments and exhibit other undesirable behavior in good faith. By "toxic comment" I include glomming on to a legitimate comment posted to a user who unambiguously failed to assume good faith, engaging in a classic Tu quoque fallacy (again, no assumption of bad faith; I am assuming that you legitimately believe that your use of the tu quoque fallacy is something other than the use of invalid or otherwise faulty reasoning), and accusing others of violating AGF when there is no evidence of any actual assumption of bad faith. Again, not every bad action is done in bad faith and not every criticism is an assumption of bad faith. I would also note that I am not the one who keeps bringing this up, and that if you stop making false accusations about me I will have no reason to respond. So just stop. Don't respond. Drop the stick. --Guy Macon (talk) 18:41, 13 April 2018 (UTC)[reply]
Guy, please review all of your suggestions to other users regarding their behaviors in this discussion and then consider how you could apply them more consistently to yourself. - dcljr (talk) 23:01, 15 April 2018 (UTC)[reply]
I must be incredibly dense, since it seems to me that "overview of" or "outline of" pages can just as easily be "abandoned, poorly maintained, [and] seldom used". Editors who have poured their time and energy into portals will simply pour their time and energy into "overview of" or "outline of" pages instead. The only differences are namespace and format. ―Mandruss  14:04, 12 April 2018 (UTC)[reply]
So you don't see any difference between a very small number of "overview of" or "outline of" pages and a huge number of Portal pages? No difference at all other than namespace and format? Try again. Can you think of anything --- anything at all -- that is different between "a dozen or so" and "many thousands"? --Guy Macon (talk) 14:13, 12 April 2018 (UTC)[reply]
Of course I see that difference. How do you propose to maintain that difference for the long term? Are you proposing that editors should be prohibited from creating more "overview of" or "outline of" pages? Let's assume not, so we will have accomplished nothing in the long term. As I said, editors who have created, developed, and abandoned portals will simply create, develop, and abandon "overview of" or "outline of" pages.
If most portals are in fact "abandoned, poorly maintained, [and] seldom used", then take most portals to MfD or propose some one-off process to fast-path that one-time effort. After that, anybody can take an individual "abandoned, poorly maintained, [and] seldom used" portal to MfD. But I don't see the point in eliminating portals. ―Mandruss  14:44, 12 April 2018 (UTC)[reply]
...or your predictions regarding the future behavior of editors could turn out to be wrong. --Guy Macon (talk) 20:42, 12 April 2018 (UTC)[reply]
Outline pages actually provide utility by linking relevant pages in a topic area. Portals don't really do that, and are not comparable Galobtter (pingó mió) 16:05, 12 April 2018 (UTC)[reply]
@Guy Macon: Are you really saying there are "a dozen or so" outlines and "many thousands" of portals? Someone in this discussion arrived at the figure of 1500 for the number of portals, while I get about 800 outlines using CatScan on Category:Wikipedia outlines. Of course, if some portals were converted to new outlines, the latter number would increase. RockMagnetist(talk) 21:48, 12 April 2018 (UTC)[reply]
OK, 1500, not many thousands. I misremembered. The number of existing outlines is irrelevant. Looking at the discussion above, it looks like we have a dozen or so (maybe even two dozen) portals that pretty much everyone thinks should be retained in some form -- possibly converted to outlines. --Guy Macon (talk) 01:52, 13 April 2018 (UTC)[reply]
  • Why not redirect the portals to the eponymous category pages? Marcocapelle (talk) 18:27, 16 April 2018 (UTC)[reply]

Orderly decommissioning

I agree with the idea of decommissioning portals, but not mass-deleting them. And I think enthusiastic editors should be given alternative venues. Probably most portals can be decommissioned in short order, which would solve most the bad/obsolete content problem. The way I would handle this:

  • Tag all existing portals with a "portal decommissioning" template

that tells editors they can keep the portal open if they remove the template, but that any portals with the tag remaining after say, 7 days, will be merged into other pages and turned into a redirect.

  • Editors who want to keep a local portal open could continue to do so, but any portal that falls into disrepair can get re-tagged for decommissioning.
  • Main content articles like Science, History, etc. would replace the portal links on the main page. These are already high-traffic gateways into these topics, and editor efforts should be concentrated on improving those.

I think decommissioning of individual dead portals can be handled by groups of interested editors as a normal part of editing, and doesn't really need the blessing of an RfC.

As for where all the stuff currently on portals should go, I'm happy to leave that up to the associated WikiProject or the editor doing the decommissioning, but in general, I would suggest:

  • Content aimed at editors (e.g. "Things you can do") should be merged into WikiProjects.
  • Article snippets found on portals should just be deleted. Duplicate text is problematic because updates cause copies to go out of sync, and interested readers can get the most up-to-date content on the article page.
  • Featured pictures should be merged into main articles, outlines, or sub-articles as appropriate.
  • Anniversaries should be merged into timelines, or presented in main topic articles (anniversary infoboxes?) if an automated solution can be used to keep them rotating.
  • "Featured content" lists should be deferred to WikiProjects, where it is probably already tracked by the assessment system. It does seem like this categorization is more useful to editors looking for content to improve, than it is for readers to find content they want to read. I expect people generally just dive deeper into whatever subtopics they find interesting, and whether that's Featured or Class B doesn't really matter. If we want to promote high-quality content to readers, I'm open to that but it should be super low-maintenance. I think we should use the existing tracking system, for example Category:Science articles by quality. Note there's a directive on those categories not to link them from articles, so this would require a general policy change which we don't need to tackle before decommissioning lists of featured content that are no longer updated.
  • "Did you know" content can be deleted or merged into a new special section on main topic articles. Or maybe something like navboxes at the bottom, which can by default be displayed closed? This is mostly a way to publicize new articles; we could also just defer that to the assessment system and automate creation of lists of new articles.
  • Wikipedia isn't a newspaper, so news content isn't a requirement. Maybe it gets users into reading content they otherwise wouldn't, but I'm sure more people just Google something after hearing about it on the news and find the Wikipedia article about that topic. Per-topic news that's actually kept up to date is a good reason to keep a portal alive, or it could be moved to the WikiProject to alert editors where to focus attention. If no one puts in the effort to post frequent news updates on a topic that's a good reason a portal should be decommissioned.
  • Main topic articles are already a good gateway into major subtopics, the category system, and should link directly to any outlines or indexes.

In general, any page (like an outline or index) that only links to articles (as opposed to copying the intro), and doesn't have content that needs to be rotated to avoid looking stale (like "Did You Know" or news or "featured" content) is going to have a much harder time getting out of date. In general, I would only expect outlines to become out of date if Wikipedia articles on the subject are created or merged or deleted. I agree there's an argument to be made that outlines, like portals, are duplicative and not worth maintaining, and I think the answer there is to redirect them into the category system, which is much more automated. Personally, I work hard to keep the category system well-organized, because we need to have at least one topical organization scheme, and this seems like the most universally accepted and useful one at the moment. But that is a topic for another day. -- Beland (talk) 20:51, 16 April 2018 (UTC)[reply]

  • Contents of depricated portals could before deletion and redirect be moved to 1) article content (see also sections), 2) indexes, 3) outlines , 4) templates, 5) WikiProjects. On a final note, there really is no good reason to keep both the portals and WikiProjects. Some of the two systems better go, merging with the other. Chicbyaccident (talk) 23:53, 16 April 2018 (UTC)[reply]

OK, who has been canvassing?

This section led to a "reasonable explanation" on the issue. - Knowledgekid87 (talk) 13:09, 13 April 2018 (UTC)[reply]
The following discussion has been closed. Please do not modify it.


When I see an RfC that starts out with overwhelming support and then suddenly gets hit with a bunch of oppose comments from editors who don't normally hang out at the village pumps, I begin to suspect that someone has been WP:CANVASSing. I could be wrong, of course. --Guy Macon (talk) 20:39, 12 April 2018 (UTC)[reply]

(yes, this is the same editor who has been posting "WP:AGF, Please" in response to other editors above). jcc (tea and biscuits) 21:05, 12 April 2018 (UTC)[reply]
Not unreasonably, a notice has been placed on the talk pages of users who edit/maintain portals and on the portals themselves. That people who edit portals are now turning-up to have their say suggests that there may be some who feel portals might be worth keeping.--DavidCane (talk) 21:08, 12 April 2018 (UTC)[reply]
And it was properly advertised yesterday at Wikipedia:Portal. --NeilN talk to me 21:11, 12 April 2018 (UTC)[reply]
I just found out about this today, because it showed up on a portal that is on my watchlist: [14]. I think portals are being properly tagged, and editors who watch those portals are just finding out now. --Tryptofish (talk) 21:36, 12 April 2018 (UTC)[reply]
Me too. Predictably, the oppose votes started when the authors of the content being discussed found out about the proposal. Certes (talk) 11:50, 13 April 2018 (UTC)[reply]
I have to agree with Jcc, Guy you throw up WP:AGF tags above then you post something like this here? Canvassing is something you either have evidence for or you don't... - Knowledgekid87 (talk) 23:40, 12 April 2018 (UTC)[reply]
You can make all the snarky comments regarding a legitimate question about possible canvassing you want, but accusing other editors of "purposely driving off contributing editors" is not allowed here and I will not stop asking anyone who does such a thing to please stop. I suggest that you drop the stick now, because nothing you say will ever stop me from asking editors to AGF when they clearly fail to do so. --Guy Macon (talk) 01:58, 13 April 2018 (UTC)[reply]
Well other editors have done the same to you so I guess both sides are at fault. - Knowledgekid87 (talk) 02:20, 13 April 2018 (UTC)[reply]
@Guy Macon: the "overwhelming support" that this started out with was apparently due to many users commenting early on who had already extensively discussed this issue in the past (and who all agreed that portals were a bad idea). As pointed out by others, it was only as knowledge about this RFC spread (especially as the portals themselves got notified, which I see as entirely appropriate) that significant opposition started to be expressed. This is why in my !vote above I mentioned (echoing several other users) that this RFC had been poorly handled from the beginning. Remember that only a small proportion of WP users regularly check the Village Pump(s) or any other particular centralized discussion space, so (for this and other reasons) it was appropriate to post notices on the very pages whose existence was being discussed. (As for posting to individual users' pages, that seems to be in line with notifying the authors of pages nominated for deletion, so as long as the wording was neutral, I don't see a problem with that.) - dcljr (talk) 22:46, 12 April 2018 (UTC)[reply]
BTW, that being said, I am not claiming that no canvassing has occurred, as it clearly has (I will not link to any particular examples so as not to further stigmatize the offending users, who have already been admonished). I'm just not sure it has made any noticeable difference in the overall direction this discussion has taken. - dcljr (talk) 23:05, 12 April 2018 (UTC)[reply]
That sounds like a reasonable explanation. Thanks! --Guy Macon (talk) 00:26, 13 April 2018 (UTC)[reply]
  • I'm glad there's recognition that communicating with all the 1500+ Portals potentially to be affected is reasonable and appropriate. It clearly meets the first bullet point in WP:APPNOTE. But so would communicating to all the WikiProject Talk pages as they, too, "...have interest in the topic under discussion" as they are already being lined up by supporters here to take over content responsibility if this RfC goes through. Who will ensure this will happen? Nick Moyes (talk) 00:53, 13 April 2018 (UTC)[reply]
It might be better to think about how to do it with the least amount of effort. Let's see... 1) You could make a list of all portals, and then regex convert the names to WikiProject names. 2) Then you make a list of all WikiProjects. 3) Then you use the list compare feature on AWB to produce all the names that are on list 2 that are also on list 1. That won't give you all the WikiProjects corresponding to portals, but it should give you most of them. 4) Then you feed the resultant list into AWB and prepend a notice to each. 5 You may need to do a second pass, to regex a name marker for the portal to the portal name in the notice.     — The Transhumanist    06:26, 13 April 2018 (UTC)[reply]
Alternative why not merge Portals with their respective Wikiproject? It seems sort of the same thing... --Railfan01 (talk) 20:06, 14 April 2018 (UTC)[reply]

No there’s no need to advertise this more than it has been already. There is no way anyone closing would consider deletion and in fact there’s likely at this stage to be no consensus because of the polarised views. Aiken D 10:41, 13 April 2018 (UTC)[reply]

Summary: Basically, nobody. Please Assume good faith.    — The Transhumanist   21:59, 13 April 2018 (UTC)[reply]

Notification of WikiProjects

Before we proceed any further, we should ensure that all the relevant WikiProjects are informed as they are usually responsible for maintaining the portals and many use the portals inter alia to helps identify, improve and create new articles. --Bermicourt (talk) 18:03, 12 April 2018 (UTC)[reply]

There's no practical way to halt the proceedings. People will post their opinions as they show up. Notifying the corresponding WikiProjects is time consuming, as you'll have to identify each one individually. I know of no automatic way to do this.     — The Transhumanist    05:25, 13 April 2018 (UTC)[reply]
User:Bermicourt do you have any evidence that Wikiprojects really use Portals to "identify, improve and create new articles?" I've never seen any Wikiproject do any such thing, but I'm not looking at every wikiproject. Legacypac (talk) 05:44, 13 April 2018 (UTC)[reply]
I have, but how would anyone know who else does? I don't think it could be recorded anywhere. I do agree that WikiProjects are interested and affected parties and therefore must be notified. Is there not a WikiProjects page that lists all the projects or a category that a bot could work through? · · · Peter (Southwood) (talk): 08:05, 13 April 2018 (UTC)[reply]
@Transhumanist. I'm saying let's notify the WikiProjects - who are key players in this - as soon as possible on their talk pages. Not to do so would be irresponsible. Interestingly I've just seen notices under 'Article alerts' on some project pages, but they've been added in such a way that watching editors aren't notified. Is that a way of saying we've notified people, but in a clandestine way that they mostly wouldn't notice, I wonder? Clever.
@Legacypac. I'm not listing all the projects here, you can check them out yourself. But as a member of several projects, I can tell you that's how they're used. But just to offer two random examples, WP:WikiProject Geography, part of their aim is the "development the navigation aids dedicated to geography" and then lists "Geography-related portals" as one of their navigational aids. Later on participants are referred to Portal:Geography to improve the scope of geography articles. WP:WikiProject United States declares as its aim that "this project was formed to coordinate the development of United States related articles and help maintain the United States Portal."!!! Bermicourt (talk) 08:41, 13 April 2018 (UTC)[reply]
No see my comment above. Not only is there no consensus for change, WikiProjects are very similar to portals in terms of activity and ability anyway, and unless you go around Wikipedia with your eyes closed there’s no way you’ll miss this RfC with the amount of places it’s been advertised. Aiken D 10:45, 13 April 2018 (UTC)[reply]
Au contraire. Portals and WikiProjects are complementary; they support one another. Of course, both projects and portals need to be maintained, but no-ones suggesting we delete all projects just because some have become inactive or ineffective for a season. --Bermicourt (talk) 16:05, 13 April 2018 (UTC)[reply]
I believe that the argument (and it is a good one) is that some wikiprojects are abandoned and/or useless but that most portals are abandoned and/or useless. Thus any solution to the useless wikiproject problem will have to be more nuanced than thye "nuke them all, move the dozen or so that are useful" solution to the useless portal problem being proposed here. --Guy Macon (talk) 19:15, 13 April 2018 (UTC)[reply]
  • Comment: Also see my arguments (and that of others) in the "Survey" section above. Deleting all of the portals would simply be too disruptive to the entire Wikipedia Project itself, in plenty of ways. LightandDark2000 (talk) 18:09, 13 April 2018 (UTC)[reply]
While you are entitled to your opinion User:LightandDark2000 you are not entitled to your own facts. Removing portals is hardly a new idea - it's been discussed for years in varioius places including a page started by User:SmokeyJoe and every time a portal is brought to MfD. There is nothing DISRUPTIVE about a well attended RFC that when closed, I hope will end a 13ish year old experiment that many believe has failed. Comparing deletion of new pages under development to old low traffic portals is not a very valid comparison. Legacypac (talk) 19:24, 13 April 2018 (UTC)[reply]
These are not "my facts." The facts I presented are quite objective, only the analysis I used to back up my arguments are "my own." By the way, all of our various arguments are largely our own opinions, including what you just said. Declaring that the portals are a "failed" project is subjective in itself - it's quite debatable. The portals probably need to be overhauled, but that's definitely not reason enough to just delete them outright. We can't go around using WP:IDONTLIKEIT, WP:THEYDONTLIKEIT, WP:NOBODYREADSIT, WP:NEGLECT, or any such rationale as grounds for deletion. I believe that marking up old/archaic portals as "historic" and/or a major overhaul of the portal system would be much more appropriate as opposed to simply deleting them all. By the way, the portals are still very much a work in progress, especially those that are frequently being used or maintained. Another thing to note, we still need to assume good faith in this discussion, instead of attacking other editors or their opinions. LightandDark2000 (talk) 19:33, 13 April 2018 (UTC)[reply]
Note I was responding to your various recent comments all at once. Legacypac (talk) 19:52, 13 April 2018 (UTC)[reply]

Regarding this survey

It seems that this RfC will become "one for the ages", and that it would serve much better, in such a role, if it were published as a stand alone project page and transcluded here. It's not too late, or too hard to accomplish, and it needn't be rushed. If no one objects, I am inclined to see it through. If others agree, please suggest a few page names for consideration. Thank you.--John Cline (talk) 07:56, 13 April 2018 (UTC)[reply]

Concerning gathering the names of relevant WikiProjects, and posting to them, using AWB and an editor... 1) You could make a list of all portals, and then regex convert the names to WikiProject names. 2) Then you make a list of all WikiProjects. 3) Then you use the list compare feature on AWB to produce all the names that are on list 2 that are also on list 1. That won't give you all the WikiProjects corresponding to portals, but it should give you most of them. 4) Then you feed the resultant list into AWB and prepend a notice to each. 5) You may need to do a second pass, to regex a name marker for the portal to the portal name in the notice.    — The Transhumanist   13:12, 13 April 2018 (UTC)[reply]
"[This RfC] would serve much better, in such a role, if it were published as a stand alone project page and transcluded here"
Actually, I think that all Village pump discussions should be published with that format. --NaBUru38 (talk) 14:11, 14 April 2018 (UTC)[reply]
@John Cline: – excellent idea, please do. I would suggest something like Wikipedia:Consultation on the future of portals.--Newbiepedian (talk · contribs · X! · logs) 22:54, 14 April 2018 (UTC)[reply]

Mobile view and portals

The portal links are not visible in mobile mode. Instead of portals and other hand-curated navigational tools, the mobile versions have a fully automated "related articles" section (usually showing pages you are not interested in). If that valuable space could be given to portal links (or other human-curated navigation aids) instead of this gimmick, we would probably see a lot more portal views. In any case, if portals are kept, we should make them more visible in mobile mode, and encourage improving their layout to look better in mobile. BTW the Android app is an especially horrible way to view portals, as it seems to have its own ideas how to use image resizing to make everything look bad. —Kusma (t·c) 14:00, 14 April 2018 (UTC)[reply]

Hello, at the Spanish-language Wikipedia I have converted several portals to make them screen size responsive. For example in Portal:Fútbol, if the desktop browser window is narrow, the two columns merge into one. The mobile version of the page appears as one column. --NaBUru38 (talk) 14:17, 14 April 2018 (UTC)[reply]
That works here too, at least for Portal:Germany. What I am missing is links TO the portals in mobile mode. —Kusma (t·c) 16:28, 14 April 2018 (UTC)[reply]
More links is not the answer. Take Portal:Bacon which has just 1300 views in the last 30 days. [15] even though it's got nearly 1000 inbound links [16] Bacon alone has over 49,000 views [17] in the last 30 days. Editor interest is damning too. Portal:Bacon has less than 30 watchers (ie so low the system will not tell us) while Bacon has 389 watchers 29 of which have checked recent edits. Legacypac (talk) 07:39, 15 April 2018 (UTC)[reply]
I don't think the number of links is a problem as much as their lack of visibility. Portal links are very unobtrusive, and have to compete with the millions of reference links a typical article has these days. —Kusma (t·c) 14:35, 16 April 2018 (UTC)[reply]

Afterwards

Assuming this proposal passes, I would think the Portal:Contents, Portal:Current events and two portals not in Portal namespace, Main Page and WP: Community portal would remain. If all other portals are deprecated pending later deletion; I should think that the Main Page should be moved into the cleared out PORTALspace, and the Community Portal as well. Also, all OUTLINEs should be moved into PORTALspace to replace all the portals, since they are if anything the same thing in a different format. And all INDEX pages should also be moved to the empty PORTALspace. "PORTAL" would then be our navigational pages namespace. -- 70.51.203.56 (talk) 06:57, 15 April 2018 (UTC)[reply]

Alternative solution

As aforementioned several times in this discussion, portals could be merged into their respective Wikiprojects in order to simplify maintenance of pages and address both editors, members of the project and readers. Useless information shall be removed in both, but the Wikiprojects' main pages should be adapted for navigation. This shall gather members of a project, editors and readers (potential editors) in a common aim: to improve articles of a project and a theme and contribute with sources, their knowledge and more. At this stage, I am just proposing this action --Railfan01 (talk) 08:46, 15 April 2018 (UTC)[reply]

I see that as a solution in name only... I'm not involved in "every" project nor "every" portal... but the projects I am involved in that have portals are maintained by enthusiastic editors on those projects already. This seems to be nothing more than a page move from PORTAL: to WIKIPROJECT:... am I correct?--Paul McDonald (talk) 01:01, 16 April 2018 (UTC)[reply]
@Paulmcdonald: I perfectly understand that portals aren't abandoned by editors everywhere — and this is good news as it benefits to the encyclopedia − but it seems reasonable to me to reduce maintenance and, supposing that readers are potential editors, to make the Wikiprojects' main page as a navigation tool for readers and an opportunity for the readers to contribute in their domain if interested, and improve articles if willing. The Wikiprojects' main page could be a place for navigation and and editing in a same subject. Concerning the nature of this proposition, I think it should be made by merging Portals into Wikiprojects. --Railfan01 (talk) 18:41, 16 April 2018 (UTC)[reply]
I think you'll find that's already done. There's a WikiProject page for those interested in editing and contributing, and a WikiPortal page for those interested in research and reading. It would not make sense to have the same page serve the purpose to reach both. For example, Wikipedia:WikiProject College football is a place for editors and Portal:College football is a place for readers. While I grant there is at least in this project and likely many others a significant amount of cross-over (both readers and editors) I don't see how it could help the encyclopedia to have the same place for both. If a project wants to make a portal, then let the project make the portal. If they don't maintain the portal then someone can propose it be deleted and then we can discuss it like we do everything else.--Paul McDonald (talk) 21:17, 16 April 2018 (UTC)[reply]

Wikipedia is not a social network!

I just noted two comments among those who are against the deletion of portals. One complains that the deletion would "annoy a lot of volunteers"; the other one says that a portal "also acts as a place to find people that has same interest as you". It seems that many put users' personal whims before the project of Wikipedia, which is to build a good-written and sourced encyclopedia, and they interpret Wikipedia as a sort of social network. This is very discouraging. Portals may have contributed to this, and this is another reason for their total elimination.--2.37.216.231 (talk) 13:47, 15 April 2018 (UTC)[reply]

It is more likely that WikiProjects contribute to and reinforce social network aspects of Wikipedia. I suspect people are confusing WikiProjects and Portals in some of the above !votes. The best portals are those that have a large listing of featured (and good articles) to showcase to readers. Plus editors willing to do a little bit of maintenance now and again. One thing that might rejuvenate portals is to have them featured on the main page. Much like featured lists are. Though that would require resurrecting the featured portals process.
I do also get a sense in this discussion that some people who prefer outlines and indexes would like to see these replace portals. But they are different things. It all reminds me a bit of the sometimes uneasy relationship between lists, categories and navboxes, as described at Wikipedia:Categories, lists, and navigation templates. Portals are essentially a form of navbox, with images and more of a structured layout.
Regarding the history, it is worth reading the views expressed 12 years ago in 2005 at Wikipedia talk:Portal/Archive 1. The first section there is particularly ironic in light of this discussion:

Anybody willing to make a Computer Science wikiportal? :) [...] I could make it but someone would have to maintain it... [...] As with anything else here, if you build it, they will come. (February 2005)

Carcharoth (talk) 14:43, 15 April 2018 (UTC)[reply]
@Carcharoth:, @Ausir: The quote mentioned above is an argument for the solution cited before: by merging portals and Wikiprojects (read above), the members of the project could be the "someone to maintain" both the portal and the project... --Railfan01 (talk) 17:31, 15 April 2018 (UTC)[reply]
I find it rather discouraging that some people seem believe you can build a good written and sourced encyclopedia without happy authors and social interaction (and providing space for that). Similarly odd seems the notion that portals would be an obstacle to well written and sourced encyclopedia. There is nothing wrong with allowing voluntary authors some whim if that serves to retain them and foster (needed) social interaction as long as it doesn't impair the project goals.
To put it this way the notion that Wikipedia is not a social network as well and the encyclopedia can be build without without providing a social network on the side seems rather outlandish to me and completely ignores human nature. Wikipedia doesn't differ from facebook & co by not being a social network but by being a very particular social network with a rather specific goal (creating an encyclopedia).--Kmhkmh (talk) 15:27, 15 April 2018 (UTC)[reply]

Indeed it is a distinct question. Our great mish-mosh of talk pages of editors and articles, village pumps, wikiprojects and other fora indeed work as a social network with a narrow focus on helping the encyclopedia. The network operates badly due to trying to apply encyclopedia software for the purpose. That's why we have all this silliness about four tildes and outdent and ping templates and do we alternate between your talk page and mine or do it all on mine. And yes, portals are a small part of the social network. I'm on the side that says they do so little, that our needlessly complex social network ought to be slightly simplified by transferring their good work, such as it is, to Wikiprojects. Jim.henderson (talk) 15:19, 15 April 2018 (UTC)[reply]

Wikipedia can never be a complete non-social network as it is also a collaborative encyclopedia. Editors communicate and work together to get articles improved, and discuss ways to make this place better. This is still social communication... - Knowledgekid87 (talk) 17:42, 15 April 2018 (UTC)[reply]

The comments by IP:2.37.216.231 are clueless (which is rather obvious by the WP:SHOUTING). The portals are for readers, and they are read (although some think they should be read more), not to mention, editors are readers, too. Alanscottwalker (talk) 17:45, 15 April 2018 (UTC)[reply]

Portals do not include links or profiles of users (not the ones I'm aware of, anyway), so they are not meant to help finding users about some topic. That doesn't mean that a resourceful user can't use them for that purpose (the editors of "Portal:Foo" are likely interested in Foo), but that also applies for article history, wikiprojects, certain templates, good and featured article discussions, etc. Cambalachero (talk) 02:34, 16 April 2018 (UTC)[reply]

Just a note to point out that Wikiprojects "also act as a place to find people that has same interest as you". There is nothing wrong with that and "no" they are not a social network either. MarnetteD|Talk 02:52, 16 April 2018 (UTC)[reply]
  • Wikipedia isn't nearly enough of a social network these days, and I think it would be helpful to focus on improving the social aspects of Wikipedia in order to improve editor retention and recruitment. Back to the topic: in my view, an ideal portal should (like an ideal main page or an ideal article) help to turn readers into editors, but that reflects my upbringing as a 2000s era Wikipedian... —Kusma (t·c) 14:38, 16 April 2018 (UTC)[reply]

This discussion at a glance

I attempted to move this RfC in order to allow for a more structured discussion of the various points and counter-proposals raised. This was reverted and, on reflection, I understand that it wasn't my brightest ever idea, in light of certain implications I hadn't really considered. Anyway, I've revamped the page as a kind of assortment of snippets from the conversation that appear most salient to bring to the attention of anyone joining the discussion at this stage. This can be found at WP:FPORTALS (no pun intended).--Newbiepedian (talk · C · X! · L) 05:32, 16 April 2018 (UTC)[reply]

Right now this discussion is all over the place, I see no practical replacement proposals here nor do I see a centralized discussion on what the aftermath would be. I hope this is closed sooner rather than later as too broad so that we can dissect the responses here to come up with solutions. - Knowledgekid87 (talk) 14:15, 16 April 2018 (UTC)[reply]
At this point, I'm concerned how it can be properly closed when the time comes. I shudder to think that one person will be tasked with determining consensus on this. Could it be closed by committee?--Paul McDonald (talk) 21:18, 16 April 2018 (UTC)[reply]
Seems a good way to go about this would be to announce the discussion will be closed at a certain time and the responses reviewed afterward and another discussion will then take place at a set time about only the content of the responses that proposed changes to the current system along with maybe an overview or summary of the support and opposition. This will permit the list to shrink because a lot of people will have proposed the same thing in slightly different wording. At the next discussion, boil down the proposed changes until something workable emerges. Repeat as necessary. 66.76.14.92 (talk) 01:21, 17 April 2018 (UTC) @Newbiepedian:@Knowledgekid87:@Paulmcdonald:[reply]

We're not getting rid of portals, are we?

Portals are a big part of Wikipedia. They always have been. Or at least for me. The site has remained visually the same since the first time I used it in 2010, and from my knowledge it was like that even before. Don't get rid of the portals.— Preceding unsigned comment added by Tin_Can (talkcontribs)

  • Strongly Oppose Portal Removal I really enjoy reading Wikipedia Portal:Current_events. I visit the 'Current Events' portal at least once a day and most of the times few times a day. I like reading the daily items. The calendar display on the right-hand bar is very useful as sometimes articles are written without specifying a weekday but not the MM-DD-YYYY. The On Going events side-bar is very interesting and I learned a lot reading the On Going topics. I don't care to read about the Sports section in the On Going events. The Elections and Referendum section is helpful and nice to know about politics around the world. The Trials section on the right-side bar is also informative. The Sports side-bar does not cover some of the international sports and it should be removed.


If this and other portals are removed, Wikipedia groups who volunteered on portal topics will be impacted. Wikipedia portals are like a community at Wikipedia and its existence must exist. SWP13 (talk) 03:22, 17 April 2018 (UTC)[reply]

Proposed Bot for tagging BadSVG files.

Some SVG files are no more than a bitmap file with an SVG "wrapper". When I have found them in the past, I have added {{BadSVG}} to them. There will be plenty of others I have not seen. It is proposed for a new bot to go through the SVG files we have and when it finds the start of a hex code stream (i.e. like xlink:href="data:image/jpeg;base64,), it tags the file with the {{BadSVG}} template. The file names will then be in Category:SVGs for cleanup where interested editors could consider cleaning them up. Once we have examined the existing files, the bot can be adjusted just to examine new uploads. Ronhjones  (Talk) 20:01, 8 April 2018 (UTC)[reply]

Great idea. Embedding raster graphics in a "scalable" format is pretty pointless and may confuse readers/re-users when they don't scale as expected. -FASTILY 21:51, 8 April 2018 (UTC)[reply]
We also need a better process for getting rid of these images. Uploading a real SVG is preferable in cases where one exists, but in cases where no real SVG can be found, it is still preferable to replace a "fake" SVG with a real raster image. If it's a non-free image, it's fairly simple to swap it out in the article and then tag it as orphaned, but if it's not, I've had {{Obsolete}} tags removed since the replacement image wasn't the same file type. --Ahecht (TALK
PAGE
) 20:48, 13 April 2018 (UTC)[reply]
We could do with a new or expanded speedy to cover that. I've done some in the past, taken out the jpg and replaced it in the article. But there is always the risk that someone will swap it out in the 7 days that F5 takes to mature. Maybe expand G6? Ronhjones  (Talk) 16:19, 16 April 2018 (UTC)[reply]

Remove from watchlist

Perhaps this has been proposed before, or perhaps I'm missing something, but I'd like to have a way to remove an article from the watchlist directly on the watchlist, without having to go to the article to remove it. Save a click, maybe. Peter Flass (talk) 18:14, 9 April 2018 (UTC)[reply]

@Peter Flass: "Add direct unwatch/watch links to watchlist entries (JavaScript required for toggle functionality)" in Special:Preferences#mw-prefsection-watchlist. --Izno (talk) 19:00, 9 April 2018 (UTC)[reply]
Also Special:EditWatchlist allows you to edit without going to the pages, and allows for bulk removals if desired. — xaosflux Talk 19:01, 9 April 2018 (UTC)[reply]
Thanks, that did it. Peter Flass (talk) 23:18, 9 April 2018 (UTC)[reply]
There's even a big button on the watchlist named "Edit your list of watched pages" :) —TheDJ (talkcontribs) 08:26, 10 April 2018 (UTC)[reply]

Move discussion related to proper use of the Template namespace

A move discussion is being held at Wikipedia talk:Did you know#Requested move 10 April 2018 which may be of interest to editors following this page. It relates to the Wikipedia:Did you know nomination process and the Wikipedia:Template namespace guideline. -- Netoholic @ 19:59, 10 April 2018 (UTC)[reply]

Removing or replacing Template:A-ha singles

This template has apparently been merged into "Template A-ha". It's now serving simply as a redirect to the latter. Now check with What links here and find that double occurences of template A-ha occurs in several articles. Who will confirm my observations and make a bot job to remove the "singles template"? -- TorSch (talk) 07:12, 11 April 2018 (UTC)[reply]

 Done manually.--John Cline (talk) 14:28, 11 April 2018 (UTC)[reply]

violation of neutrality

Trade route from the Varangians to the Greeks

Categories: Economy of the Byzantine Empire Economic history of Russia Trade routes Portages History of Kievan Rus' Varangians Medieval economics

and

Russkaya Pravda

Categories: East Slavic manuscripts Kievan Rus society Medieval legal codes Legal history of Russia Cyrillic manuscripts 13th-century manuscripts


it is enough to read history of Ukraine to see usefulness of addition of the categories connected with Ukraine. [[18]]

That is why not professionally to write down objects of Kievan Rus' only as Russians

To add category "the history of Ukraine and other categories across Ukraine In categories Ukraine is thrown out. — Preceding unsigned comment added by Bohdan Bondar (talkcontribs) 08:44, 11 April 2018 (UTC)[reply]

Entirely the wrong venue (if I understand the issue correctly from the above pile o' hay). Take it to the relevant talk pages. --Elmidae (talk · contribs) 10:51, 11 April 2018 (UTC)[reply]

RfC: Ending the system of portals alternatively

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 portals be merged into their respective Wikiprojects? This may mean that the Wikiprojects' main page should be adapted for navigation, but all useless parts removed. --Railfan01 (talk) 20:18, 14 April 2018 (UTC)[reply]

Survey

  • Support I think that Portals, now seeming useless as aforementioned in another RfC on this page, shall be merged into Wikiprojects, or the other way round, both being useless alone --Railfan01 (talk) 20:18, 14 April 2018 (UTC)[reply]
    • I don't know why you have decided WikiProjects are useless, but they definitely aren't (this should be less controversial than the portal issue). Master of Time (talk) 20:53, 14 April 2018 (UTC)[reply]
  • Would this query make sense as part of the Portals RfC? I can see the advantages of concentrating all topic-specific Wiki-things under one system rather than having Portals for readers and WikiProjects for editors and thus splitting editors' attention between two systems. Jo-Jo Eumerus (talk, contributions) 20:24, 14 April 2018 (UTC)[reply]
    • Isn't the other portals RfC finished yet? I think there was no consensus. It is sort of an opportunity to reopen the dicussion --Railfan01 (talk) 20:47, 14 April 2018 (UTC)[reply]
      • No, it isn't, and you should wait for it to finish and for an admin to identify a consensus, if any. Also, the other RfC was strongly criticized for not notifying the portals. If you wish to go through with this, you should be the one to notify them, and also the affected WikiProjects. But I think that you should terminate this right away because it is only going to be confusing and disruptive. RockMagnetist(talk) 20:52, 14 April 2018 (UTC)[reply]
  • Comment – Why would we move portals to WikiProjects which are in the project namespace? That namespace is largely used by editors for Wikipedia maintenance. Portal namespace is targeted at readers. Master of Time (talk) 20:53, 14 April 2018 (UTC)[reply]
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.

Community de-adminship processes

Considering the community has the power to appoint admins, it is only fair that we have a procedure at hand to hold our admins accountable but every community de-adminship proposal has failed, some because the discussion is heavily derailed by a few editors, others due to no consensus. I simply think that this is a necessary process for the validation of WP:ADMINACCT. Sure ArbCom can, but that process takes months at end and sometimes doesn't even have an ideal outcome, they're not the community afterall. A lot of admins are concerned with the fact that they make enemies while their tenure here and that will severely skew the results in such a process, but then the reverse can be true as well, essentially making it a fallacious argument. I don't want such a process to lead the witch hunt against admins who might've made a few errors in judgement but a process to hold the ones accountable who have gamed the system in one or more ways and repetitively abused the trust of the community under the radar. Effectively, a process to be made without the ArbCom cogs to take forever. I'd like to hear more thoughts on this matter. --QEDK () 07:21, 15 April 2018 (UTC)[reply]

The thread at ANI which required me to ask: link. This thread is to elicit new opinions on the matter just, and see if anything has changed from the status quo and if we have the cause to make a new proposal. --QEDK () 07:25, 15 April 2018 (UTC)[reply]
Another navel-gazing discussion would not be helpful. It is obvious that admins who actively work to repel unhelpful editors get a lot of enemies, and such admins would get a lot of heat from socks whom we would have to pretend were good faith editors raising issues of concern. I would prefer that the admins spend their time repelling unhelpful editors rather than spend time arguing with their friends. No one has shown a discussion involving an admin which failed to get the correct outcome within a reasonable time. Arbcom would desysop an admin in under an hour if it were really necessary (they would discuss whether the emergency desysop was warranted). Johnuniq (talk) 07:43, 15 April 2018 (UTC)[reply]
You seem to suggest a "deep state" network of socks would mysteriously arise and we will assume they are here in good-faith when simply they have no credibility for such. I'm sure the state of the community is not so dire and you're exaggerating. ArbCom doesn't make emergency desysops, it's still at the behest of stewards/office@WMF. ArbCom's functioning is the essential defining factor of a bureaucracy, no one's saying they can't do their job, but are they doing it well, not as much as we would want, such is the description of the job. --QEDK () 07:58, 15 April 2018 (UTC)[reply]
That would be somewhat resolved by limiting desysop discussions to an WP:ECP-locked page (I'd say just autoconfirmed, that's really not a hurdle). IP editors and newer accounts could still make arguments and present evidence on the talk page, and if they have any pretense of validity then someone who can edit the ECP-locked page will carry them over. If the talk page gets flooded with "get rid of him!" spam, it could go into pending changes (with the understanding that any good-faith comment, no matter its position, should be approved). No comment one way or another on the original topic, just something that'd prevent pretty much any reasonable claims of sock influence without completely silencing grievances by newer or anonymous users. Ian.thomson (talk) 17:00, 15 April 2018 (UTC)[reply]
Personally I suppose putting the same system of RfA sounds about right, the idea of accountability. The bottom line is, some people are malicious, things will happen, but in the course of time, it will not even reflect in the process. --QEDK () 19:01, 15 April 2018 (UTC)[reply]
[ec] Two of the things we would have to consider:
If you have a plausibly workable idea, describe it somewhere and provide a link, then we can have a discussion about an actual proposal. · · · Peter (Southwood) (talk): 08:01, 15 April 2018 (UTC)[reply]
That's not happening, most opposes are simply based on "we do not want such a process" primarily, so having a proposal without addressing why not would be pointless. There have been workable ideas time and again but it's hard to change beliefs when they are based on assumed ideas. --QEDK () 09:25, 15 April 2018 (UTC)[reply]
Re your above comment about desysops, the procedures for an Arbcom emergency desysop are here. Of course it involves an arb contacting a steward to perform the operation. Re "workable ideas", if starting a discussion it might be worth linking to a couple of such workable ideas, preferably with a mention of how they would avoid adminship becoming a beauty contest where admins who don't spend most of their time charming their voters get replaced by those who do. Johnuniq (talk) 09:46, 15 April 2018 (UTC)[reply]
Johnuniq, I get your point, more than a fair number of these proposals have arose and all of them have gone down, with some actually being pretty good, or some close to consensus even. But, with the community (+ admins) not ready to even accept the idea, making a proposal at any point is useless, considering the same group will shoot down the idea even if it had any merit (since in the end, it's about opinions, isn't it). --QEDK () 18:56, 15 April 2018 (UTC)[reply]
This is a perennial proposal. As the initiator of the thread at that link, I knew from the start that it was a non-binding measure. It was designed to bring attention to an issue, knowing that it wasn't the forum couldn't actually remove admin rights, but useful to see if others agreed that something wasn't working out and to incubate some sort of solution. The situation resolved itself, and I think the project is better for it, but I don't think there is ever going to be agreement for a ground-up community-initiated removal process exactly because admins do tend to perform actions which people could hold grudges against. There may be hope for a peer-level process where other admins can initiate it. -- Netoholic @ 10:17, 15 April 2018 (UTC)[reply]
That's my point. If a few editors who hold grudges could skew results, it could well happen at the RfA stage and why are we being so protective in the case of de-adminship, when it's the community vs. a few editors with grudges. --QEDK () 16:48, 15 April 2018 (UTC)[reply]
The "what about the editors with grudges" argument holds no water whatsoever. Stewards are confirmed on a yearly basis and it has never been a problem - even if it were, you can have a system with safeguards to prevent that sort of abuse. A community-based desysop procedure makes sense. The community elects admins, and it should have the power to remove them. If enwiki were to seriously consider this, I would offer up a system similar to that used on Commons and Wikidata: 1) an ANI/AN thread regarding the misuse of sysop tools gets consensus to initiate a confirmation RFA, then 2) a confirmation RFA is held, requiring a simple majority to remove sysop access. There's no need for some heavily bureaucratic system like those proposed in the past. And if you want more safeguards, replace the simple majority requirement with consensus to remove at the confirmation RFA as well. -- Ajraddatz (talk) 17:06, 15 April 2018 (UTC)[reply]
Yeah, even if there are grudges, they can be enough to sink an rfa, dragging it down from say 75% to 60% etc, but a majority/supermajority voting to remove can't be from grudges, considering especially that usually there are 150+ people !voting. Galobtter (pingó mió) 17:16, 15 April 2018 (UTC)[reply]
Exactly my opinion. Every argument along the line seems like the very definition of exaggeration to me. With a community to back, I'd say unless you've blatantly abused the right, it's harder to lose than gain the rights, considering everyone wants good admins to stick around and with the dwindling numbers of RfAs, they'd be less inclined to vote for the sake of it, without evaluating merit and joining the sides of the few editors who hold grudges. I think the fact that (some) admins think the community will give in to that is a wrong thought in itself, considering they're the ones who picked you in the first place. --QEDK () 18:56, 15 April 2018 (UTC)[reply]
Ajraddatz, as much as I respect you, your comparison is not at all similar. The majority of participants at steward confirmations are individuals from projects that have admins and/or ‘crats, which means stewards have next to nothing controversial to do on the home projects of probably a super-majority of those participating in the discussion. Compared to example, en.wiki, where enforcing our text copyright policy has suddenly become controversial. TonyBallioni (talk) 22:00, 15 April 2018 (UTC)[reply]
Maybe, but you can still look at the community desysop proceedings on other Wikimedia wikis to see the same effect. On Wikidata, we've had one de-RFA and no abuse of the process. On Commons, almost all of their de-RFAs have been in-process and legitimate. The sort of abuse that people fear just doesn't happen in practice, at least to the extent of being able to change the outcome. -- Ajraddatz (talk) 22:29, 15 April 2018 (UTC)[reply]
The de.wiki process the 2015 RfC was based upon gives bad enough numbers to show that the concerns are not exaggerated, and I think that project is probably a better comparison to en.wiki than many of the others used. There is this theory that the reason the community has set higher standards at RfA is because of how difficult a desysop is, and that if we only make it easier to desysop, the RfA standards will become lower.
I don't think that is the case. I think what we would have would be a lot more people resigning the tools under a cloud rather than go through a process that may very well end in their favour and that the RfA process would still have ridiculously high standards. The net result here would be a project that is already struggling to get more admins to replace the attrition of inactive ones still not getting more people at RfA, and also losing more people who would rather resign than go through what is sure to be an unpleasant experience. I think any admin who has lost the trust of the community should resign, and that when there is a valid question as to if they do have community trust, ArbCom should desysop: I brought a case based on this principle. I just also believe that the already established community desysop procedure (which is what ArbCom is) works fine and has less negatives than any alternative that has been proposed. To paraphrase Churchill, it's the worst form of desysop except all the others. TonyBallioni (talk) 22:49, 15 April 2018 (UTC)[reply]
Yeah, but Tony, isn't the question - why you believe so? If an admin were to fear and resign, they would do so in every case, any kind of process - if an admin were to fear and resign, they already know their mistakes will get them desysoped. Community evaluation is faster, and gauges opinions better than ArbCom can, it holds admins accountable where we want them, rather than wait for Arbs to churn out the results after extensive off-wiki conversations. The RfA standards now have nothing to do with this, personally I dislike that the numbers have fallen to this dismal count, but if you want to fix that, this thread won't help. And attrition in admin numbers can only be fixed when we get more RfAs with a community more willing to accept them, not by keeping the few admins who might get de-sysoped due to a community referendum. --QEDK () 04:34, 16 April 2018 (UTC)[reply]
No, it would just mean that someone doesn't feel like going through an abbreviated show trial at an ANI-meets-RfA and that they have better things to do with their life than go through the hell that would be. ArbCom is slow and not fun, but at the very least, every party tends to be treated with respect. The idea I strongly get from your statement is that you are talking about a system where guilt would be assumed and the burden would be on the person up for review to prove they should retain advanced permissions rather those wanting to retain them to prove otherwise (it may not be your intent, but that is how it does come off.) That would be a radical departure from the current system, and one that I could not support. Additionally, I'll raise the point that any system such as this would make the unblockables phenomenon much worse than it already is. TonyBallioni (talk) 13:52, 16 April 2018 (UTC)[reply]
That's an unpleasant idea. I would not entertain such an idea, I am only arguing for a community-deadminship process and assumed guilt is quite far from it. Why do you keep saying it like the community will lead the witch hunt against innocent admins who might've made mistakes, there's almost a nil chance that an innocent user will get caught up in community-based processes. I see that you support the ArbCom's take on sanctions but there's a certain group of people who undoubtedly are not, no system is perfect, but this certainly has to be more perfect that the process ArbCom is. The point is, an admin will not have to prove anything if they are innocent, it's the duty of the community to evaluate. --QEDK () 16:24, 16 April 2018 (UTC)[reply]
  • I would support an amendment to policy where a thread can be opened at AN to request an involuntary RfA for current admins. If that thread is closed with a consensus for an RfA, then one is opened by a crat, without the accouterments of accepting the involuntary nomination. The format and duration of the RfA proceeds (including watchlist notifications) as a normal RfA and is closed as normal by a crat, including the discretionary zone and possible crat chat. If the consensus is to oppose their adminship, then the bit will be removed by the closing crat. But opening one would require a consensus at AN, and an involuntary RfA for community confirmation cannot be opened by any one individual. GMGtalk 19:16, 15 April 2018 (UTC)[reply]
I would grant broad leeway within crat discretion for the timing of the RfA, which could be reasonably delayed if needed to accommodate the asking and answering of community questions by the nominated admin, and require that the AN thread be closed by a crat, as the person who is charged with then opening the broader community discussion at RfA. GMGtalk 19:26, 15 April 2018 (UTC) [reply]
For further clarification, I've been thinking a lot about this exact issue lately. There is a central problem that we have essentially a type of landed aristocracy or peerage, at some level disconnected from the functional pragmatic use of the level of user access. Many of these are seasoned admins who were elected early on, and who have grown to be among our most valued community leadership, but we also have some current admins who absolutely would not pass an RfA in 2018 or even be considered for nomination for one. We have others who conduct themselves occasionally with general disregard for community norms, because the standard is whether you have passed an RfA ever, and not whether you can pass an RfA now.
The standard for desysop at ArbCom is spectacular disaster, and not consistent faithful use of the tools in accordance with community norms. So we reinforce a notion that so long as any admin who happens to be a disaster, can maintain the tools so long as that disaster does not become spectacular. That's a problem and it's one that fundamentally erodes trust in the corps and faith in the community. This would be an overall high bar for a re-RfA, where most comers would be turned away at AN, and most who proceed to a re-RfA would likely have already risen to the level of losing community trust, and would have their access removed. It answers the issue of individual grudges by requiring consensus for a discussion to even happen and at the same time, if that discussion does happen, it holds current admins to exactly the same expectations for conduct and competency as we do new admin candidates. GMGtalk 19:50, 15 April 2018 (UTC)[reply]
I like it, with the exception of the the role you give 'crats in starting the confirmation RFA. I think that the confirmation RFA should be started by someone who wants the admin in question to be desysopped, so they can present their reasons, rather than a bureaucrat creating the request as a procedural action. Plus, that also gives people some time to reflect after the AN thread is closed on whether a desysop discussion is really necessary. Of course, I would prefer this to the status quo. -- Ajraddatz (talk) 21:08, 15 April 2018 (UTC)[reply]
For additional context, you may wish to review Wikipedia:Administrators/RfC for binding administrator recall, the last broadly-held RfC on this topic. Its proposal is similar to yours. (Wikipedia:Requests for de-adminship has a whole slew of other proposals.) isaacl (talk) 21:25, 15 April 2018 (UTC)[reply]
There are some key differences - namely that the proposed dewiki model has an ongoing quorum requirement, whereas this model would move forward from existing community practices (review of actions at AN/ANI). They also require a new RFA with the same passing standard, which is different from this. -- Ajraddatz (talk) 21:46, 15 April 2018 (UTC)[reply]
Sure, that's why I said similar... Like I said, the idea was to see what has been done before and thus learn from it (you can see from the objections that safeguards like a quorum is a concern). (Regarding RfA passing standard, this proposal says "The format and duration of the RfA proceeds (including watchlist notifications) as a normal RfA and is closed as normal by a crat, including the discretionary zone and possible crat chat.") isaacl (talk) 22:20, 15 April 2018 (UTC)[reply]
  • The current process works fine and also has the advantage that the actions of all parties are examined: this has been cited by one person in the past as a reason why they are hesitant to file a desysop case request because they were afraid their actions would be examined. That means it is doing its job: preventing frivolous requests that can be resolved short of a desysop by making people assess how they have behaved in the situation, and possibly getting people to just calm down, which is usually the ideal.
    I’d also like to point out that while it is popular to complain about not having a desysop process short of ArbCom, a large part of the reason we don’t have one is that no one has proposed one that is actually better. That speaks volumes, IMO. This is a grass is always greener issue, and I say this as one of the limited number of people who has brought a successful desysop case before the committee as a filing party. Yes, the case request process sucks, but I’d much rather have it and know that the admin under discussion is getting full hearing than have an AN/ANI mini-trial or RFCU. There is also the factor that some of these cases, such as the MisterWiki case and some other recent admin issues, do involve private information, which the community is not equipped to deal with. The arbitration process is slow and takes a lot of effort, but it works. There is no need to replace something that works, especially when every alternative that has been proposed brings with it other issues. TonyBallioni (talk) 21:50, 15 April 2018 (UTC)[reply]
Sorry Tony, I consider you a friend, as much as people who've never met can be. But the current system is not working. You and I were chatting on IRC at the time, and you only beat me to that ArbCom case because I was actively drafting the request in my sandbox at the time and you beat me to it. Spectacular disaster should not be the standard. The community should be the standard. We're not a country where people live with the choices of their government. We're volunteers, who simply leave when the administration isn't accountable to that community in a meaningful way. If the community is the ultimate authority for making our administration, then the community should be the ultimate authority for breaking it when appropriate. I don't want to end the world; but I would very much like to see the standard for desysop moved from spectacular disaster to simply disaster. My concern is not spectacular disasters that ArbCom doesn't act on; my concern is that admins who realize they can operate at the level of simply disaster with no oversight, are free to do so. GMGtalk 00:28, 16 April 2018 (UTC)[reply]
Sure, but I'm not convinced that there is a better method out there, or at least not one that wouldn't be equally as flawed. My standard for any reform proposal of anything is that it should be an improvement, not just a lateral move that solves some issues while creating others that have the same level of severity. Using the statistics from de.wiki the last time this was formally discussed on en.wiki, ~42% of admins subject to their procedure basically said screw it, and resigned or didn't respond at all. Now, I am of the belief that all admins who have lost the trust of the community should resign, and that when they don't, ArbCom should make that choice for them (that was my basic argument in the MisterWiki case.)
At the same time, given that their actual removal rate by vote was only 13% and their retention rate as a whole was 44%, I suspect that many of those who chose to forgo the process on de.wiki would likely have been retained, but they just decided it wasn't worth it. That has the potential to have a real impact on the number of active sysops simply quitting, which I think we also need to take into account when looking at this. What some people also forget is that admins are also volunteers too, and while we have obligations to the community, if given the choice between their bit and an ANI-meets-RfA style sysop review process, there will be a lot of volunteers who decide it just isn't worth it, even if they shouldn't have anything to worry about. TonyBallioni (talk) 00:46, 16 April 2018 (UTC)[reply]
At the same time, we fret about inactive NPP reviewers skewing our numbers, when if dewiki is anything like enwiki, half of our admin corps is barely active anyway, and half of those are practically mummified, and so of course they wont stand for a confirmation, because the user right is a dusty artifact. Losing an inactive admin isn't an actual loss; it's the status quo with one less user right involved. Any active admin in good standing should pass with flying colors. That many don't would be a feature, and not a bug. GMGtalk 01:29, 16 April 2018 (UTC)[reply]
ArbCom cases can take months—generally in complex cases, where there are multiple issues and multiple parties and where it is not immediately and clearly obvious what the community consensus is with respect to how an issue should be handled. The cases that ArbCom handles slowly and not to the satisfaction of all editors are the cases that the community hands to ArbCom because the community is unable to come to a consensus, and must resort to an independent arbiter because we have no other way to resolve an impasse.
In instances where desysopping is clearly the correct course – and when I say 'clearly', I mean 'clearly to uninvolved parties and not just local partisans' – the ArbCom can and does desysop by motion, and can do so over a few days. (In clear emergencies featuring ongoing misuse of tools or egregious abuses of trust, ArbCom has (and has used) procedures to suspend admin privileges in minutes.) Administrators and the community at large are aware of this, and it is not uncommon for an 'under a cloud' resignation to be tendered as soon as a widely-affirmed concern is presented at AN(/I), or immediately after a well-posed complaint is opened at ArbCom. In the recent Gryffindor case, for instance, a concern was raised at AN/I on 11 April; the weight of opinion in favor of an ArbCom request was established fairly rapidly; Gryffindor read the writing on the wall and resigned on 13 April. That was significantly faster and less wasteful of community time and resources than any new (albeit perennially proposed) process could be. TenOfAllTrades(talk) 00:14, 16 April 2018 (UTC)[reply]
Any de-adminship process would probably have had the same effect on Gryffindor, they had the mindset for it. What you're saying in support of the ArbCom model is pure speculation. But what GMG has said is more true than false. The bars for a de-adminship at AC is spectacular disaster. And that's not a good bar. I'm not rejecting the idea that the ArbCom is inefficient, but with a procedure designed to increase bureaucracy in the system, you can see where things start going wrong. Emergency requests procedures of AC are redundant, Stewards have a full reign over who to desysop or not, even a crat can inform them, AC just makes a binding request (which means that the process can take more time rather than lesser). --QEDK () 04:27, 16 April 2018 (UTC)[reply]
Responding at the bottom rather than in-line because there are a few points I want to address. First, the dewiki system isn't a model I would recommend following. The petitions are stressful for admins, the bar to keep adminship is too high, and the results cited by Tony above prove that it just drives admins away. Clearly that isn't what we're looking for. But that's not the only system, nor is it the most widely used, and Wikidata/Commons use a system which has better results. That said, I don't often pull out my soapbox for this issue because the ArbCom process does work - I just think that, from a philosophical perspective, it is wrong. The community should decide who admins are, and be able to remove them. I think that there might be some room for a proven, simple system with safeguards against abuse here, but any proposal for it would be an uphill battle that probably isn't worth the time. Especially when I could be complaining about RfA standards instead :-) -- Ajraddatz (talk) 00:59, 16 April 2018 (UTC)[reply]
Yes, but I have and will continue to argue that the problem with the barrier to entry is the barrier to exit. GMGtalk 01:34, 16 April 2018 (UTC)[reply]
  • I'll add my 2c here. While I think the current system is stable in people's minds, with a difficult barrier to entry and a quite difficult barrier to exit as well, it isn't exactly ideal given that we are failing to be able to elect a stable admin base (decreasing numbers consistently). There is an issue that an oppose !vote counts for around three times as much as a support !vote. However, I don't think this system is going to change without an increased accountability check on admins, as the difficulty to de-sysop makes a difficult barrier to entry essential in many people's eyes (not unreasonable). If we were to put forth a proposal to simultaneously somewhat lower the barrier to entry as well as lower the bar for de-sysop, that might be feasible. But doing either by itself would I think be very unsatisfactory to many people. What the exact elements of such a proposal would look like, I have no idea, but the current system is generally unsustainable. — Insertcleverphrasehere (or here) 04:38, 16 April 2018 (UTC)[reply]
    I concur with Insertcleverphrasehere on the analysis above. Another possible modification to the current system that might ease matters is a probationary period for admins. Not every admin has experience as an admin on a similar system, so there will often be a learning period with the new tools and responsibilities. If a probationary period of say 6 months and a reasonable number ot tool uses was the standard for a new admin, with a confirmation at the end of it, the bar to getting there might be lowered to a series of two easier bars. If they cock it up in a big way while in the probationary period, they will not make it through confirmation. If no blunders are made, the confirmation should be relatively painless, possibly even boring, if confirmation is the default when no serious complaints are raised. Or we could just wait until there are not enough admins to run the site, then go into panic mode and change the system in desperation to another one which may be just as bad. Some people just need the tools to do what they want to do. I don't need them at present, so there would be no point in RfA, as I have been able to get all the tools I find useful juat by asking for them. If I needed an admin restricted tool I would RfA, but not before, there is too much drama for my tastes. I needed some of the admin tools on other Wikis and got them without drama, but I don't need them here. I prefer the pen to the mop. · · · Peter (Southwood) (talk): 06:37, 16 April 2018 (UTC)[reply]
    A probationary period would lower the RfA rate to non-existent (who wants to go through RfA twice?). I also don't think lowering the pass rate any lower is a good idea: we want admins to have broad support in the community and trust. We already have the discretionary range at 65%, which is basically what it takes to pass any other discussion. I also reject the idea that somehow lowering the exit barrier will have an equal effect on lowering the entrance barrier. I don't think it will have any impact at all: the RfA-standards genie is already out of the bottle. This is a prediction that is brought up all the time but it doesn't take into account the fact that when people collectively raise standards, they rarely lower them. If anything, any proposal on this would decrease the number of successful RfAs because no one would want to have to deal with the constant threat of ANI for a desysop. TonyBallioni (talk) 13:52, 16 April 2018 (UTC)[reply]
  • My tenure here or experience with such discussions is limited, so my opinion may as well be worthless, but here goes...
So far, the discussion has pointed to a two step procedure:
  1. An AN/ANI thread to discuss the abuse/misuse of tools by an admin and consensus on whether reconfirmation RfA is needed. A 'crat closes the thread and assesses the consensus.
  2. If the consensus is in support of a reconfirmation RfA, it is followed by regular procedures of a RfA (watchlist, time frame, etc.), though forced, where the votes are counted. As stated above, people who hold grudges can't sink a majority-vote-based RfA.
However, this raises a few more questions:
  • What is the formality of such an AN/ANI thread? Say, an editor finds three page deletions of an admin problematic and asks for review from other users. That is, the thread is about the deletions and not whether the person's adminship needs reconsidering. If the page deletion is identified as a long term issue, would a comment like "we should really look into the ability of this admin to handle his tools" be considered the "start" of step 1? Or should someone start a new thread (or a sub-section) with a specific title to document the entire consensus building formally so that comments stay on topic? The reason I say this is because a thread that talks about three page deletions would gain much less traction and a few editors might agree with the green highlighted comment I just stated above. Would that mean there is truly a consensus to conduct the reconfirmation RfA? In comparison, a thread titled "Considering reconfirmation RfA for XYZ" would probably catch more eyes. (That is just how I feel; that may not be true with how things work at AN/ANI since I don't frequent there enough).
  • Can any editor start such a thread? Even one quick to call 'Admin abuse!'? Or should there be a proper "case" before step 1 can be started (I've discussed this more in the next point). Keeping with the example I gave, if the 'long term issue' is falsely identified by the editor starting the new thread, people would start commenting that thread was spuriously created and that it's a time sink. Which leads me to next point...
  • How long should the thread last? Can it be snow-closed by a 'crat as a "time sink"? Or should there be a time-frame so that consensus building is given a fair shot?
    • If snow-closes are allowed - the process would be fairly informal providing greater leeway to the closing 'crat and could lead to limited participation. There won't be a lack of participation at the RfA, but there might be at the AN/ANI which is the first step. Since RfA has raised its standard over the years, it would be unfair for admins to be put in the spot so easily and questioned in a re-RfA after an informal-process-led AN/ANI. It could also potentially promote people to start spurious threads, knowing that they can be snow-closed (although, hopefully, a boomerang would follow in such cases).
    • If a time-frame is kept - a barrier would have to be created to ensure there is a proper "case" so that it is not truly a time sink. That would add a third step of assessment of the "case" and complicate things. But, the entire process would be fair. There would be enough time to view the actions of the thread initiator as well as hear the voices of the community. At the same time, there would also need to be a "gap" introduced between reports for a particular admin so they don't get targeted.
This is not like an AfD where both time-frame and snow-closes can be allowed freely since most snow-closes are strongly policy based. Admin conduct is largely subjective since we're assessing the actions of a person. If snow-closes are allowed, they would need to be for particular cases. Say, the idea is implemented with a time frame and someone starts another thread just a few days after the previous closes for an admin. It can then be reasoned that consensus wouldn't have changed (unless the admin royally messes up in those few days) and snow-close the thread. That would be the "gap" I was talking about earlier.
With all this formality, time-frame and "case" stuff, it seems to be getting closer and closer to how ArbCom works. I truly believe that the ins and outs of the process have to be worked out first. Just my views though, I'd love to hear what others have to say! Jiten talk contribs 09:24, 16 April 2018 (UTC)[reply]
The AN thread acts as the "stop-gap" for futile requests. That's not the idea but something we can probably think about, is all. When you have crats closing it, it has to be a responsible close and I doubt there's the leeway you talk of. Set up a minimum time-frame for reach and maximum time-frame for consensus and I'm sure crats can effectively deduce consensus. --QEDK () 10:55, 16 April 2018 (UTC)[reply]
(edit conflict) Hmm...My general feeling is that any editor should be able to open such a thread, yes. This is no different than any other behavioral dispute that arises at AN or ANI where things might spiral out of control for a little while in a general purpose thread, and we end up with someone who's been following developments who decides they think they have a solution by proposing a block or a ban. I don't think you really need to set additional limits on the normal consensus building process. Some discussions will probably be a clear cut consensus one way or the other, and can be easily closed, even by a non-admin (I'm sympathetic to dropping the bit about crat closes). Others may be highly contentious and need a team of experienced admins to close. This is again perfectly in line with our normal consensus building process governed mostly by common sense. The discussion would be closed in accordance with normal procedure, summarizing the consensus and the concerns of the community, and that close would be the rationale for the re-RfA, in place of nominations and the three standard questions.
I think it's also important to point out that this is actually more lenient than what is possible under current policy, since it's simply a consensus for whether a re-RfA should happen, and not deciding to directly take away the mop. It may be perfectly reasonable for someone who thinks a user should retain the mop, to still support a re-RfA in order to solidify the conesnsus for retention, and put down unwarranted pitchforks.
The alternative under current policy and what I fully intend to start proposing at places like AN and ANI given the opportunity if something else doesn't come of this discussion, is to start TBANNING admins from taking any administrative action whatsoever until they appeal to the community to lift the TBAN. This type of administrator probation is as far as I can tell, and I've looked pretty hard, perfectly allowed under current policy. But that type of action is actually less accountable to the broader community, and more likely to be beholden to the types of people who frequent AN and ANI, in disregard for those who don't. GMGtalk 11:04, 16 April 2018 (UTC)[reply]
And before someone calls this a solution in search of a problem, remember that at this moment ArbCom can barely agree whether to even issue a warning to an admin for edit warring, when, if you count page protection as an edit, they were already at 4RR, and would have been blocked were they a regular editor. Besides that, I'll bet someone like...oh...WBoG can probably think off the top of their head of at least one example where a current admin has mostly not yet been dragged to ArbCom because of the onerous bureaucracy, even though a case request is almost certain to be successful. GMGtalk 11:39, 16 April 2018 (UTC)[reply]
As I recall, a community-imposed ban on performing administrative actions has been discussed and recognized as an effective removal of administrative privileges, and thus only within the scope of the Arbitration Committee to put in place. I'm not certain, but I think bans on specific categories of administrative actions have been passed, though it is rare. Usually people feel administrators an editor should either be trusted with the entire range of administrative tools, or none of them. isaacl (talk) 13:45, 16 April 2018 (UTC)[reply]
TBANs on use of specific tools are allowed, yes. There is also the Arthur Rubin example where the community passed a community ban against him pending the ArbCom case and then removed it when he returned. TonyBallioni (talk) 13:52, 16 April 2018 (UTC)[reply]
Yes, that was brought up at my talk page a little while ago. If the community can CBAN someone, then I don't see any reason why they can't enact a TBAN which is in every way a less extreme sanction. It wouldn't be removal of the bit, it would be suspension of the bit, pending a consensus that they have regained community trust. Honestly, I'd welcome ArbCom to try to unilaterally overturn such a TBAN, because there would be no clearer demonstration that they cannot in this one area fulfill their duties as a body to the satisfaction of the community, and we need to formulate another option.
To my mind, a re-RfA, with all the accouterments of a set time table, wider audience, and opportunity for Q&A is the closest thing out there to a compromise between a bureaucratic nightmare on one hand, and outright mob rule at AN or ANI on the other. GMGtalk 14:04, 16 April 2018 (UTC)[reply]
I would support forcing resignation before a reRfA, which would solve the issue people have of them being easy to game. I argued this in either January or December (whenever the last one was). That was shot down as not being something worth writing down. My preferred system here is that admins who have lost community trust, or where that trust has been called into question, resign without the need for a case and if they still want the tools run again. If they refuse to do that, then ArbCom steps in. I think that's where we are in most cases right now. I am disappointed in some of the Arbs over the current motion, but it seems likely to pass and regardless of my views of re: involved full protection, I doubt a community desysop process would have achieved much different. TonyBallioni (talk) 14:44, 16 April 2018 (UTC)[reply]
So in essence, something like what GMG and Ajr suggested but without step 2 (ie, the reRfA)? If I understand correctly, you mean: as soon as there is consensus in an AN/ANI thread that an admin has lost the trust of the community, they must resign. If not, the case would be taken to ArbCom. If they want to bit back after the resignation/forced resignation, they must run a regular RfA just like other editors. Is that correct? I think the main concern here is still that community's say should be final. If an admin loses our trust, they clearly don't deserve the admin tools and ArbCom shouldn't be able to say otherwise. Even if ArbCom is very much in line with community's thoughts, the whole procedure takes time and effort. A forced re-RfA on the other hand, as GMG suggested, is quicker and more accessible to the community. Just from personal feelings and the very little time I've spent reading ArbCom cases, there's more participation at an RfA than a case and the final ruling is determined by the community (which, imo, seems philosophically correct as the community is the one that voted for the admin). I didn't understand the "game" part though. My initial comment only addressed the AN/ANI thread; I hadn't even though about the actual re-RfA! Jiten talk contribs 15:11, 16 April 2018 (UTC)[reply]
Well, my main concern is that 1) a direct desysop has already been rejected more times than anyone remembers, and functionally 2) AN and ANI have a tendency to be volatile and vitriolic, with people rushing to sanctions because they lack the creativity or time to find any other solution (exactly why we just passed a 24 hour minimum to CBAN discussions). So you take away the sanction as an option really and instead make them !vote on whether we have a discussion. Also in comparison, RfAs tend to be more well thought out, and bring out a much wider audience including a lot of our quiet content creators and gnomes who'd rather have a root canal than watchlist a noticeboard. GMGtalk 15:23, 16 April 2018 (UTC)[reply]
Jiten D: Yes, that is roughly my position. I think that once it is clear an admin has lost the trust of the community, or at the very least there is a valid question of community support because of a major breach of trust, they should either resign or ArbCom should desysop. This is the process that we just saw work here and that also worked at Wikipedia:Arbitration/Requests/Case/Conduct of Mister Wiki editors. It works and no one has suggested a process that would work any better given the political realities of en.wiki (again, see the de.wiki numbers. I highly suspect that if a Commons/Wikidata like process were to be followed here, we would see similar attrition, which is not a good thing.) Its also important to note that all ArbCom does in terms of desysop is remove and mandate a reRfA if someone wants the tools again (assuming no other sanctions.) We don't have a perma-RfA-running-ban short of a full site ban.
I also dispute the idea that the ArbCom based desysop process is not a community-based desysop process: they are elected by the community, they take case requests when it is raised by the community, every step of the arbitration process has ample opportunity for community comment. All of the previous desysop reform attempts can fall into two camps: direct desysoping by the community (which I would call forced reRfA an example of). This is rejected because we want protections for admins who make tough calls, and the confidence in ANI at resolving disputes is slightly lower than the popularity of Congress and ArbCom. (See Wikipedia:Administrators/RfC for binding administrator recall. Any version of reRfA or direct desysop will face similar objections, and would likely fail.) The other proposal is to designate a group of trusted editors from the community to review requests for desysop when it is clear that there is community demand for it, so that the community can remove adminship when it feels that an admin no longer has its trust, this is the idea behind proposals such as WP:BARC. The issue there is that ArbCom is already that body: it is elected by the community every year to handle, among other things, desysop requests at the request of the community and with community comment. TonyBallioni (talk) 15:49, 16 April 2018 (UTC)[reply]
Tony, the attrition isn't related at all whether we have a community-desysop process or not, but simply because our RfA standards have increased year-on-year. The solution isn't to make barrier to exit harder but the barrier to entry easier - you're going very roundabout with your argument. There is no consistent evidence across community desysop processes to suggest that it's been the triggering factor in attrition. You keep saying that ArbCom is elected by the community for the purposes of desysoping, but that's not only it, if you've read GMG's comment, the ArbCom's stance on desysop's way too soft, stuff that one crat would probably do if we had the policy to allow that. Instead, we wove in the right with the most complex and busy legal court in all of Wikipedia. You dispute the point, fair, but your point is essentially, "No, this is okay" after citing an example where the admin resigned. Gryffindor would resign under the threat of any such process as well, you just need the mindset to resign. And for the last time, ArbCom is not the community, they're people appointed by us, entrusted with the right to deal with issues in a fair and unbiased manner, while they are certainly good at deliberating, I disagree that admins appointed by the community should be left to desysop at the behest of a group of people who are certainly not the community. --QEDK () 16:16, 16 April 2018 (UTC)[reply]
Tony you can't accept the limitations of the dewiki process and ignore the success of the other community review procedures. Look for yourself at Commons (successful and unsuccessful) to see the lack of frivolous requests. And you're also wrong about the steward confirmations - most of steward work is taking global actions, not acting as a local admin on a project without them. Stewards can thus get grudge users from both homewiki activities (seen this year on ptwiki stewards' confirmations) and for controversial actions they've taken (I once took issue with someone editing my comment on Meta and they came back to oppose my confirmation the next year). The simple fact is a) this doesn't discourage stewards from staying on unless they've really messed up and b) safeguards prevent those grudge users from derailing the process. I also disagree that arbcom desysop is community desysop - arbcom doesn't appoint admins in the first place, the community does through RfA. And a general point regarding the AN/ANI thread requirement - there should be no fixed bureaucratic rule for this, because the intent is to use existing procedures. Admins can already be taken to AN/ANI over bad actions. My proposed system would just allow for a substantive follow up to those discussions. -- Ajraddatz (talk) 16:32, 16 April 2018 (UTC)[reply]
Just as a general comment, I am reminded of a recent RfA on Commons, where the rationale was essentially I want to do this particular cleanup task and when I'm done I'll give the mop back. It ended up getting derailed for reasons other than the rationale, but I have to say it was refreshing to have a rationale that was so pragmatic and 100% I want to do this task with 0% I want to be a community leader of sorts. I wish we could move more toward that on enwiki, and the only way I see for doing it is reforming the back end, because that's what people are thinking about when they cast a !vote at RfA. The barrier to exit is what sets the standard of how bad a mistake at RfA is going to be if one is made. GMGtalk 16:46, 16 April 2018 (UTC)[reply]

Ajr: While I respect the work that stewards do, and think I have pretty good relationships with a good number of you, I disagree with you that there is any equivalency to steward confirmations in this discussion: steward actions are by the very nature of the role supposed to be uncontroversial. A steward who is behaving controversially *should* be removed, which is why the process there works well. Re: Commons, it has a very different culture from en.wiki, and I don't think it would work as well here.

QEDK: I was providing recent examples of the current process working. Thus far, in any of the desysop reform discussions that have taken place over the years, no one has actually demonstrated that the process doesn't work or that there are a huge amount of actually filed case requests where the community would have desysoped but ArbCom didn't (or even one). It does. My basic argument is that while the current process has flaws (i.e. it is slow, which is the only one that has ever had consensus) all of the other possibilities that have been discussed also have flaws that are as bad or worse (I think it would increase attrition and also decrease recruitment, among other things). I'm a pragmatist who doesn't believe in changing something that works for something else that may or may not work and would likely be just as flawed. I also disagree with GMG that lowering the barrier to exit will lower the barrier to entry: the barrier will remain just as high and we will lose plenty of good user who simply don't want to go through public humiliation because of a grudge. TonyBallioni (talk) 16:56, 16 April 2018 (UTC)[reply]

I've been a local admin in a variety of places on Wikimedia and Wikia since 2009. Some of the most controversial actions I've taken are as a steward, because outside of permissions management, we deal with a large number of controversial issues that can draw attention. And I've also found that, regardless of the project, the culture and general function of a wiki are pretty well the same no matter where you go. That is just my experience though, and I can't measure it in any objective way. All of this said, I do understand your core argument that the arbcom process works and ensures that admins are empowered to take controversial actions. -- Ajraddatz (talk) 17:18, 16 April 2018 (UTC)[reply]
I'm unclear why requiring a re-confirmation RfA after a consensus would cause English Wikipedia to "lose plenty of good user who simply don't want to go through public humiliation because of a grudge", but having the same consensus trigger a resignation or an arbitration case wouldn't. I suspect going through an arbitration case would be just as likely to result in someone leaving. isaacl (talk) 17:53, 16 April 2018 (UTC)[reply]

@GreenMeansGo:, regarding why the community doesn't have the ability to remove administrative privileges: as I understand it, originally Jimmy Wales appointed and removed administrators. He then shifted the responsibility for appointing administrators to the bureaucrats as part of the request for administrative privileges process, and the responsibility for removing administrative privileges to the arbitration committee. To change this would require a change to the Administrators policy. There is no effective difference between removing administrative privileges or dictating that an editor cannot use them.

In the end, the basic problems are that consensus doesn't scale up as a community increases in number, there are structural problems with online decision-making (including the limited, self-selected sampling of voices heard), and English Wikipedia's decision-making tradition isn't conducive to determine real consensus. As a result, any attempt to make major decisions by a large community discussion generally gets deadlocked. isaacl (talk) 17:53, 16 April 2018 (UTC)[reply]

Well, regarding TBANS there is a difference between removing access and suspending the use of it. Namely, it takes crats and ArbCom initially out of the loop all together. If an admin on probation decided to flout the TBAN, any passing admin can basically unilaterally hand out a block, and then take them to ArbCom if they unblock themselves (the lenient route). Or we take them directly to ArbCom, because we've created a situation where use of the tools at all is by definition abuse and directly contravening community consensus. Then if ArbCom decides to override consensus...I dunno...I guess we'd just have a wiki-constitutional-crises. Normally a TBANNED administrator (as in, TBANNED from US Politics or something) would be nearly up for the chopping block just by virtue of needing to be TBANNED in the first place.
In a nutshell, it's attempting to set up ArbCom to be in a situation where either their hand is forced, or alternatively they do something totally bonkers and everyone flips their lid, in the hopes that they'll prefer having their hand forced to gratuitous lid flipping. GMGtalk 18:14, 16 April 2018 (UTC)[reply]
To clarify, there is no effective theoretical difference in the community saying administrative privileges shall be removed and an editor shall not use administrative privileges. Accordingly, by policy, the community does not have the scope to enact these restrictions, and the administrator in question would not feel bound by them. There is of course a practical difference today between the community making either of these statements and the Arbitration Committee ruling that administrative privileges shall be removed: the bureaucrats will only act on a statement from the Arbitration Committee. isaacl (talk) 18:22, 16 April 2018 (UTC)[reply]
I doubt that, if such a discussion were to be held in a proper manner, even though the policy doesn't exist, consensus can be reached. Nothing is stopping anyone from reporting the discussion to the stewards directly, and considering that local policy doesn't bind them, they can exercise their right to desysop considering the admin has effectively lost the confidence of community. The community has full scope in every scenario. --QEDK () 18:50, 16 April 2018 (UTC)[reply]
Sorry, I'm not sure if you're responding to me? If so, are you saying that you doubt that consensus can be reached? And then are you subsequently saying that if consensus were reached, the community could appeal to the stewards? isaacl (talk) 18:56, 16 April 2018 (UTC)[reply]
There may not be a practical difference but there is a policy difference, and there is nothing in policy that forbids it. It's already been shown that a current admin can be CBANNED while still retaining the rights, and it's already been shown that the community can restrict the use of the tools using a TBAN (see here). The difference is only one of scope, and possible gratuitous lid flipping by having ArbCom directly override community consensus.
But no, the community doesn't decide everything. There are some things that are decided by the WMF. We cannot, for example, eliminate ArbCom all together. Their existence is mandated by the foundation. We cannot reach a consensus to disregard WP:COPYVIO. We cannot override office actions. And if a steward ever showed up on enwiki and unilaterally removed the admin rights under those circumstances, lids would be violently flipped in every direction. GMGtalk 18:58, 16 April 2018 (UTC)[reply]
Ofc not, I simply meant to say, if the community needs to take action, it will. Unilaterally using rights isn't a question or an idea. @isaacl, I was responding to you, yes. If consensus is reached for the removal of rights, the Stewards are bound to take action even though the local policy is something else, their task is to execute community consensus. I do not mean appealing to the stewards, but requesting for the implementation. --QEDK () 19:05, 16 April 2018 (UTC)[reply]
Note that stewards will not take actions that could be performed by local bureaucrats except in emergency, and loss-of-confidence isn't an emergency situation by itself. See m:Stewards policy#Don't promote users on projects with existing bureaucrats. -- Ajraddatz (talk) 19:08, 16 April 2018 (UTC)[reply]
Sorry, poor choice of words: I did not mean "appeal" in the legal sense, but simply "request". I still don't understand your first sentence, but I understand your line of argument regarding the stewards; thanks for the clarification. isaacl (talk) 19:33, 16 April 2018 (UTC)[reply]
Removing privileges is the tool to enforce the restriction; there is no policy difference in telling someone they can't do X versus telling them they can't do X and no longer have the technical ability to do X. isaacl (talk) 19:40, 16 April 2018 (UTC)[reply]

There is a problem with mis-actions by admins, and lack of accountability of admins. But putting putting the death penalty of desyopping under the random clan & mob mentality that pervades other areas of Wikipedia is not the answer. One component of a fix would be to get rid of the ridiculous system where anybody with the tool belt is considered qualified to act as judge, jury and executioner on behavioral questions on established editors, and or deciding/closing even the most complex and contentious situations. This needs needs to be a second tier above admin; people who are proven to also be wise, careful, thorough, impartial, never hot-headed, with good judgement, analysis and decision-making process capabilities.....the "Yoda" level. And, just like the fix for the broken RFA process, discussions to award this need to be findings on an established framework of the qualities required, not the current random stuff that we have at RFA. Second, there needs to be a process to sanction mis-behaving admins with lighter penalties than desysopping that doesn't require the giant artillery of an arbcom case. Maybe a panel of 3 "Yodas" who could dish out findings on admin behavior and admonishments. And until we have Yodas, a community based process for findings and admonishments but not desysopping. North8000 (talk) 18:26, 16 April 2018 (UTC)[reply]

Binding arbitration on content disputes has been suggested by others and me as a way to give final rulings on content disagreements. Today there's no final stop in the process; people can periodically bring up issues (hoping consensus has changed), and whoever lasts the longest may well succeed, so editors have incentive to be contentious. I appreciate there are pitfalls with binding arbitration to be wary of (for instance, consensus actually can change, and sometimes there are cliques that need to be counteracted). The largest barrier, though, is that people would have to give up their veto right to block changes (one person alone can hold up a change for an astonishingly long time; a few people can do so indefinitely). Until something more drastic happens to Wikipedia's editing environment, I don't foresee binding arbitration being introduced. isaacl (talk) 18:39, 16 April 2018 (UTC)[reply]
I really don't think the answer to fixing a bureaucracy is more bureaucracy. The 3 Yodas will never ideally represent the view of the community and there's nothing to say they can remain completely unbiased. The key to removing bias from a system is to have multitude of opinions, as eventually, bias cannot skew the opinions to one side or the other. Your argument, along with Tony's, is based on the key principle of the community not being able to take care of our decisions, like there's a huge mismanagement that occurs anytime it's upon the community to decide, but that has never been the case. If anything we need to involve the community as a whole more, not less. --QEDK () 18:46, 16 April 2018 (UTC)[reply]
Agreed 100% with QEDK. If the community can be trusted with making admins they can be trusted with removing them. And the three Yodas model falls to the same reason why BARC was rejected - it's just another ARBCOM-like process. As an aside, I don't think that the community does an excellent job of making new admins. But they certainly wouldn't do a worse job of removing them. -- Ajraddatz (talk) 18:52, 16 April 2018 (UTC)[reply]
I didn't say anything about 3 Yodas and I'm not sure if I favour that specific proposal, but in general: consensus doesn't scale up. All of our experience with communities in the real world demonstrates that managing interpersonal interactions requires some form of hierarchy. We can do our best to keep it as grounded as possible with the community at large, but it's just not possible to hold an effective conversation with hundreds of people: it demands too much time and attention. isaacl (talk) 19:27, 16 April 2018 (UTC)[reply]
I mean we do a half decent job of it half the time. There's currently a discussion ongoing at WP:ACREQ where more than 200 people have weighted in so far. GMGtalk 19:48, 16 April 2018 (UTC)[reply]
That conversation is pretty civil, which is good, but it has a lot of redundancy, with people repeating points, because almost no one is going to read over 200 statements (I read many of the opposes and some of the supports at the start of the RfC, but haven't kept up). Due to the traditional structure of discussions on English Wikipedia, people spend a lot of time arguing with individuals over their viewpoints, instead of consolidating discussion around each argument for and against. (I've written about these issues before.) And that discussion isn't related to behavioural issues, or even a content dispute. It's also isn't that evenly split, so it's more a lot of people agreeing with each other, rather than a conversation. That being said, there are a lot of conversations that can (and often do) proceed smoothly. But the contentious ones are hard to resolve without some kind of structure to manage them and provide incentive for collaborative behaviour. isaacl (talk) 20:06, 16 April 2018 (UTC)[reply]
  • WP:BARC was an idea of mine for a new policy that failed to gain traction. Lauched together with Worm That Turned during a period when community desysoping was once again a current topic, it was an experiment in community opinion more than anything else. On the lines of, 'let's try something and see what they say', it's nevertheless interesting reading and IMO is still a fundamental basis for new ideas. 100+ supports was not an insignificant turnout by today's RfC standards and was in fact numerically (115/75) the majority. Mdann52's closure made a very fair assessment that on the strength of the arguments there was no consensus. My main concerns at the time were to find a system that would protect any community desysoping process from an overspill of votes from aggrieved users who fail to understand that some admins do make tough calls - there is clearly a lot of schadenfreude in such participartion. Serious cases of privilege misuse (or serial poor judgement ) are in fact quite rare considering the number of admin actions that are carried out, and the (low) number of truly active admins who do the brunt of the work.
BARC was nearly 3 years ago. With the apparent reduced workload on ArbCom, and a marked drop in coordinated attacks on adminship in general, I question whether today a 'community' desysop system is required - TonyBallioni makes a salient point in clarifying that as elected officials, the Committee mebers are nevertheless members of the community. Whether we are happy or not with the work of each individual who occupies one of those those seats (some do occasionally vote at odds with the other members), at this moment in time I am personally satisfied that the work they do in this area reaches the right conclusions. It's the structure of the ArbCom system that needs streamlining, IMO its own mess of bureucacy is what makes it so slow and ungainly.
Nowadays, although it still suffers from the ocasional disingenous opose votes and what are probaly a lot of drive-by supports, even if it's still not attracting a plethora of contenders, RfA does what it says on the can - most of serious candidacies pass and there is a significant reduction in failed bids for the bit. Like community desysoping however, no one has ever come up with new a idea for it that pleases everyone. Kudpung กุดผึ้ง (talk) 01:09, 17 April 2018 (UTC)[reply]

The grudges

The main counter-argument for a community-initiated desysop process seems to be the "grudges" - users who have been blocked/warned/offended by an admin at some point, who show up at the desysop proceedings to oppose the admin under review without seriously considering the situation and pattern of overall behaviour displayed by the admin. I've been arguing throughout this thread that this is nothing more than a myth that would not actually derail a community desysop process - let's look at this in more detail.

  • Starting with cross-jurisdictional comparisons: do grudge users control the community-initiated desysop processes on other wikis? No, though some (like the dewiki model) can potentially drive off admins who don't want to go through the process. More on this below. But if you look through the archives at Meta, Commons (successful and unsuccessful), steward confirmations and Wikidata you will see a distinct lack of frivilous requests or requests being derailed by "enemies" of the admin under review. This isn't to say that it doesn't happen - but it doesn't happen in large enough numbers to derail the process. I picked those processes because I am the most familiar with them - if anyone else wants to add some analysis of others please do so.
  • Now let's look at enwiki, because I know everyone is going to have "those projects aren't enwiki, enwiki is different and special" on repeat in their brains while reading the above point. Enwiki doesn't have a community-initiated desysop process, but it does have AN/ANI and ArbCom where the community can complain about sysop actions. Some AN/ANI threads can even lead to ArbCom cases for desysopping, so it's a surprisingly similar system to those proposed above, just without any decision-making power for the community. So let's look at how these "grudge" users derail the existing processes. There is a current case request before ArbCom right now about desysopping (found here), without any evidence that the "grudge" users are dominating the discussion. I see maybe one or two comments of questionable value, with most comments being appropriate reflections on the conduct of the user in question. Looking to the ANI thread on the same topic (here), again, I'm not seeing much in terms of users with grudges showing up to derail the process. Does anyone have any actual examples of an AN/ANI thread being filled up with users with grudges trying to get back at a specific admin? And again, I don't mean one or two - one or two people with grudges will show up anywhere, be it RfA or a request for desysopping. I mean enough users to derail the process or to wrongfully desysop an admin who was just taking a necessary but controversial action, or enough to form a consensus that a de-RfA should be initiated.

There's another argument here that deserves some attention. Tony expresses it above, saying that a community-initiated process will cause admins to just quit rather than go through a confirmation RfA. That's a very good point to make when looking at the dewiki system, but it doesn't apply to Meta/Commons/Wikidata/steward confirmations and I doubt it would here. Admins can already be dragged to AN/ANI or ArbCom for their conduct here, and ArbCom proceedings are possibly more stressful than a re-RfA given the timeframe and private nature of the decision. Changing the step after AN/ANI from ArbCom to community process isn't going to cause mass resignations. Admins here already self-select which controversial actions they take to avoid community uproar; this will be no different with or without community-initiated desysopping processes.

The biggest argument I see against a community-initiated process like the one I outlined above is that it would likely have the exact same outcomes as the current ArbCom-led system, and thus the change would only be symbolic. I think this is a fair enough argument to dissuade me from proposing anything on this topic. But I always like to push back against the nebulous claims of possible abuse that could happen whenever something new happens, because whether it's this or IPBE liberalization, it just doesn't pan out that way. Sorry for the long post. -- Ajraddatz (talk) 02:19, 17 April 2018 (UTC)[reply]

Well thought out, as always, but the big counter argument is that the structure of an ArbCom case actively discourages the grudges. There is also the flip side that arguably ArbCom can hold popular admins to account in ways that ANI won’t (and we have plenty of examples of people having their friends stop by ANI). So I think a better counter is: ArbCom works fine, it is arguably more effective than a community process would be for politically popular admins, it provides protection against potential witch hunts in that the actions of all parties are examined, and no one has actually put forward a provsss that would work better. Like Kudpung hinted at above, if anything, the thing that needs work currently is streamlining the process for obvious cases, which the committee has already started to do on its own without some massive reform RfC that would likely end with only minor tweaks to procedure. TonyBallioni (talk) 03:08, 17 April 2018 (UTC)[reply]

Strognly oppose deletion

Keep all portals!Anjuna (talk) 05:10, 17 April 2018 (UTC)[reply]