Jump to content

Wikipedia:Village pump (proposals)/Archive 162

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

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

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Proposal to delete Portal space

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

Shortcuts

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

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

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

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

Top Portals.

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

Main Page linked portals (alphabetical):

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

I propose:

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

Section break 1

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

Section break 2

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


Section break 3

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

Section break 4

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

Intermediate proposal: de-link from article space

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

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

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

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

Significance of mobile Wikipedia to portals

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

Alt-Proposal 1 to total deletion of Portal space

Proposal withdrawn by proposer - Knowledgekid87 (talk) 17:34, 22 September 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

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

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

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

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

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

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

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

subsection

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

Thoughts on the value of portals

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

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

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

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

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

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

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

subsection 1

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

Time to close this

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

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

One idea for continuing with the discussion

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

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

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

Useful portals:

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


A guideline

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

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

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

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

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

Proposal: Rethink Portals completely as a personal project

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

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

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

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

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

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

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

The colour of nomination

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

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

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

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

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

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

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

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

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

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

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

Make it harder to create new lint errors

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

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

Other warnings might be like these:

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

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

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

RfC: Proposed rewrite of the CSD Criteria

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

See article sizes in difference view.

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

Block users with less than 10 edits from creating a user page

Withdrawn by proposer. Wug·a·po·des​ 22:27, 24 October 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Not the sandbox, or any user subpages, the userpage itself.

Reasoning

It is quite common for spammers/people wishing to make a page on themselves to immediately dump all the information in their userpage about themselves. It is also common for a user to create a user page on themselves, and them simply leave. Preventing this, and providing a notice to the creator that wikipedia is WP:NOTAWEBHOST could possibly help stop some of this.

--MoonyTheDwarf (Braden N.) (talk) 16:34, 24 October 2019 (UTC)

So, you want to stop many highly respected users from other Wikimedia projects to create a user page in enwiki? Ruslik_Zero 17:56, 24 October 2019 (UTC)
Ruslik0, Not the intention. Checking global edits would likely be viable. MoonyTheDwarf (Braden N.) (talk) 17:57, 24 October 2019 (UTC)

Discussion

  • An alternative is to have a default edit notice when creating one's user page, saying "please don't write your autobiography here (or anywhere else)". Certes (talk) 17:15, 24 October 2019 (UTC)
  • The main reason these users do this is because they mistakenly believe that Wikipedia is akin to a profile site, where your username also represents the person you're writing about/on behalf of. If we do this, they'll just dump it onto their user talk page instead. Education is the cure here. —v^_^v Make your position clear! 17:49, 24 October 2019 (UTC)
    Jéské Couriano, Just noting that it wouldn't be too hard to prevent a user from immediately creating their talkpage either (Just let them edit it after someone else creates it.) But otherwise, that is a good point. MoonyTheDwarf (Braden N.) (talk) 17:53, 24 October 2019 (UTC)
  • Opposed - we WANT editors to register and create a user page. And remember, having a short “who am I” bio statement on your user page is fine. Just keep it to a paragraph or two, and don’t make it promotional in tone. Blueboar (talk) 18:04, 24 October 2019 (UTC)
  • Obviously, we can't have a bot enforce "not promotional in tone". Perhaps a character limit on user pages; although, we don't want to discourage copying appropriate userboxes, do we? — Arthur Rubin (talk) 18:18, 24 October 2019 (UTC)
  • This doesn't seem like a good idea to me. Perhaps I am biased because my own first edit was to create my own (spam-free) user page. --RL0919 (talk) 18:46, 24 October 2019 (UTC)
  • Opposed - Preventing a user from creating a user or user talk page seems to conflict with the requirements for posting COI and PAID disclosures. RudolfRed (talk) 19:04, 24 October 2019 (UTC)
  • No per WP:BITE and WP:AGF. Few things on-wiki are more hostile than receiving a technical prohibition, and even more so when you get it in your own userspace. Have you tried treating these people like human beings and explaining NOTWEBHOST to them rather than creating new and more baroque technical restrictions? If the content is inappropriate, have you tried being bold and removing the inappropriate content with an informative edit-summary like B did on my userpage when in the first month of editing I didn't know about NFCC and had a fair use image on my user page? If you're too busy to have an actual conversation, there's also {{subst:Uw-userpage}}. Wug·a·po·des​ 19:22, 24 October 2019 (UTC)
    Wugapodes, This is a good point as well. Point taken, I believe the general consensus here is no. And you convinced me. How do I withdraw a proposal? --MoonyTheDwarf (Braden N.) (talk) 22:10, 24 October 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Abdul Haq Vidyarthi

I propose to reverse this article because i have found a lot of reliable source of notablity on him on google books (see here and here) and I will add them on the article. Lazy-restless 23:46, 25 October 2019 (UTC)

@Lazy-restless: This is the wrong place to comment. As an expired PROD from 2012, if you have sources (which I haven't checked), you might as well create the article. You might request WP:REFUND to see what was there before, but it's not essential. — Arthur Rubin (talk) 01:07, 26 October 2019 (UTC)

Visual Editor on Talk Pages

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

Your Thoughts

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

T235285, the current design ticket, is looking a lot like reply-link so far. Not sure what else it'll bring to the table. Enterprisey (talk!) 16:15, 14 October 2019 (UTC)
I take that back, it looks much better, especially in terms of localization & parser robustness. Enterprisey (talk!) 16:24, 14 October 2019 (UTC)
If you're interested in making it easier to use talk pages, please put the mw:Talk pages project on your watchlist. Whatamidoing (WMF) (talk) 21:53, 20 October 2019 (UTC)
It lacks support for ":" indentation but it can indent using bullet points and it can do signatures (using 4 tildes) - I know because I just did this edit using it (which you can confirm looking at the history.). Kerry (talk) 13:42, 28 October 2019 (UTC)
All you have to do is add "&veaction+edit" to the end of the URL and you can use the Visual Editor on most pages including Talk pages (and this page). The limitations are not technical but political. Kerry (talk) 13:42, 28 October 2019 (UTC)
If you would like to make it easier to let VE users to write on your User Talk page or a project Talk page or whatever, add the {{VEFriendly}} template at the top of the Talk page (see my User Talk page). As someone who does outreach and that is almost always with people using Visual Editor, I have to be able to have VE users to be able to talk to me. But it seems many people want to treat them like 2nd class contributors by denying them the right to cmmunicate with other contributors and to deny them the right participate in discussions like this by making it not possible for them to do it. Personally I use both editors, they have their strengths and weaknesses for different kinds of editing. Tables are a breeze in Visual Editor, for example. Unless there is a bug in the VE itself, VE users cannot normally break synax (noting that another proposal here is concerned with broken syntax). Having new users use VE by default would get rid of a lot of broken syntax. Kerry (talk) 13:42, 28 October 2019 (UTC)

Dark Mode display preference

Tracked in Phabricator
Task T26070

Screen technology has been changing, and OLED displays are becoming more common. Enabling a dark mode option for the Wikipedia site would save energy and reduce eye-strain. I have no doubt it would increase readership with a younger demographic.— Preceding unsigned comment added by DillC137 (talk • contribs) 23:40, 30 October 2019 (UTC)

I read Wikipedia with Firefox's "Dark Reader" add-on, though I stick to a standard view when editing to match what most readers will see. Certes (talk) 00:36, 31 October 2019 (UTC)
I would like that, too. It's rather difficult to edit Wikipedia before bed without some sort of dark mode. — Javert2113 (Siarad.|¤) 01:19, 31 October 2019 (UTC)
This is being (slowly) worked on - for updated you can subscribe to phab:T26070 or one of its subtasks. — xaosflux Talk 01:22, 31 October 2019 (UTC)
What good news. It's not just vector that tires the eyes, monobook is also far too bright. I started working on User:Wugapodes/DarkThemeTest.css but it's got a lot of problems. People are welcome to fork it until the phabricator ticket gets resolved. Wug·a·po·des​ 02:54, 31 October 2019 (UTC)
  • I admit, I love looking "L33T", but it's a bit jarring — moreover, the contrast when someone adds a significant amount of information is difficult to notice (that is, the dark green is difficult to make out). — Javert2113 (Siarad.|¤) 00:29, 1 November 2019 (UTC)

Automatic solicitation of minor scientific review

This proposal is meant to deal with all fields of science, but may be relevant to other fields as well.

When a citation reference is added, an automated process may be able to discover the e-mail address of the corresponding author of the original source. Then, a short and succinct message can be automatically sent to the original author requesting their support by reviewing the cited section. This message should be very clear, very short, and provide a really easy and direct way (links) for editing the specific sentence. For scientists, reviewing one sentence citing their own research and revising it if needed should take only a minute or two. Yet, this would result in a much more accurate article. — Preceding unsigned comment added by Butbutbat (talk • contribs) 08:34, 31 October 2019 (UTC)

That is an interesting suggestion. -Roxy, the dog. wooF 08:41, 31 October 2019 (UTC)
Somewhat related: User:ExpertIdeasBot, see coverage here. Regards, HaeB (talk) 08:49, 31 October 2019 (UTC)
Seems like an interesting idea, but let's poke at it a bit. The bot should perhaps know how many times to message the same person somehow, just so to prevent message spam. Jo-Jo Eumerus (talk, contributions) 09:12, 31 October 2019 (UTC)
  • Just so I understand the intent here... the goal is have an automated mechanism to double check that Wikipedia is accurately presenting what the source says? Why limit this to just science related citations? I would think this could be used for any citation to an academic source. Blueboar (talk) 14:39, 31 October 2019 (UTC)
Wouldn't anyone replying be accused of having a conflict of interest? Thincat (talk) 17:13, 31 October 2019 (UTC)

→ True- this goes for any academic source. Why conflict of interests? I imagine that participation of experts in editing the content is in the interest of Wikipedia users. Note that this proposal is for double checking citation by the cited person (which is probably **the** expert regarding the accuracy of the citation, if not the content itself). The motivation for this automatic process is to increase the involvement of academics specifically in the curation of academic citations. This is almost effortless for the expert, while primarily contributing to the content is much more demanding. — Preceding unsigned comment added by Butbutbat (talk • contribs) 07:47, 1 November 2019 (UTC)

I am an academic. I love editing Wikipedia. I'd love to know every time I was cited. But I suspect most of my colleagues would be horrified by what they would see as extra spam. Bondegezou (talk) 16:19, 1 November 2019 (UTC)
I agree. No automatic process should be sending out emails, especially to people who have not expressed their consent. Phil Bridger (talk) 20:47, 1 November 2019 (UTC)
What about a monthly report (if there's anything to report) for those who expressed their consent in some way? — Preceding unsigned comment added by Butbutbat (talk • contribs) 06:46, 3 November 2019 (UTC)
It's hard to imagine any method being accepted as polite, other than opt-in. And that raises the question, how shall sources be alerted about this service? Jim.henderson (talk) 22:13, 3 November 2019 (UTC)

use font differentiation to separate two components in edit view

By means of font, differentiate between citations and article text in edit view. This would be easier on the eyes. Bus stop (talk) 15:43, 3 November 2019 (UTC)

I don't edit use VisualEditor. When editing articles, which generally have citations interspersed with text that appears in articles, it would be helpful if all citations were rendered one way and all text appearing in articles were rendered another way. It doesn't matter how this differentiation is achieved, but I think differentiation by color would be a good idea. As for non-"text" elements such as templates and nowiki tag enclosures these could either be lumped together with citations or separated out further, by for instance color. My idea is not to have any further breakdown of the components found in edit view. My idea is just to differentiate article text from everything else. Bus stop (talk) 22:04, 3 November 2019 (UTC)
Interesting. Thank you. OK, I guess this suggestion can be withdrawn. Bus stop (talk) 22:38, 3 November 2019 (UTC)
Followup. I've already had to turn it off. It is an annoyance. Bus stop (talk) 22:57, 3 November 2019 (UTC)

How can I invite contributors to improve an existing Wikipedia page?

Duplicate post, responded at Teahouse. Regards SoWhy 16:06, 11 November 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Hi! I would like to make a call to independent, reliable contributors that are part of the Wikipedia community to improve an existing page that is low in quality. Is the Village Pump (proposals) area an appropriate option? If not, would you be able to guide me to the right place? Thanks in advance. --KatherineBusby2019 (talk) 15:57, 11 November 2019 (UTC)

I replied at Wikipedia:Teahouse#How can I invite contributors to improve a page? Regards SoWhy 16:05, 11 November 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Tracked in Phabricator
Task T237268

Hello!

I would like to have a "By user(s)" parameter in advanced search. If you for example search with "Search in" set to "File" and "By user(s)" set to "Jonteemil" you would see all files uploaded by me. Can this be done?Jonteemil (talk) 13:35, 4 November 2019 (UTC)

@Jonteemil: Special:Contributions/Jonteemil with Namespace set to File may do the job you need. (Expand "Search for Contributions" to see the Namespace box.) Certes (talk) 13:55, 4 November 2019 (UTC)
@Certes: Special:ListFiles/Jonteemil would also solve that problem but if I for example want to find all the files, uploaded by me that contains the word "extracted", which really is the reason I made this proposal, there isn't a way that I know of.Jonteemil (talk) 14:02, 4 November 2019 (UTC)
@Certes: Same here. Someone asked ”Hi, what is the underlying use case for that?”. I want to useit to find all the files uploaded by me that have been extracted from a PDF. In the source parameter in {{Logo fur}} in all of them I have written ”extracted from /pdf/”. I would therefor search ”extracted from” and by user(s) Jonteemil and find the wanted files.Jonteemil (talk) 22:59, 4 November 2019 (UTC)

Source reliability RfCs to counter systemic bias in new page patrol

While new page patrol has largely been able to keep its backlog in check, one problem that we have is that, due to the relatively small roster of new page reviewers, we lack editors who are familiar with (or capable of researching) sources from many parts of the world. This is further compounded by Wikipedia's systemic bias, with the end result that articles reliant on sources from biased-against regions take significantly more time and effort to review, and even then reviewers are less likely to make an accurate decision in their review. In an effort to address this, for the past few months I and a few other editors have been compiling a source guide, WP:NPPSG, primarily for use by new page patrol. The purpose is to help combat systemic bias in page reviewing by providing baseline, consensus-backed reliability information about sources for all topics and geographic regions. The main differences between it and WP:RSP are that NPPSG is sorted by topic and region, and that it has a much lower bar for inclusion on the list (consequently, NPPSG has explicit instructions that the inclusion of a source on that list should not be used as an argument for the (un)reliability of a source above and beyond whatever consensus the listing is cited to).

I started out this project by first transcribing all of the RSP entries to the list, and then further expanding it by keeping tabs on RSN discussions as they are archived. However, this reliance on just monitoring RSN means that while there's still some useful information at NPPSG (and more importantly, useful information that would not belong at RSP), we're not closing our systemic-bias blindspots at anything faster than a glacial pace. Those of us who have been working on this guide, and others involved with NPP, have had previous discussions here and here to determine what our next steps should be, with a local consensus that we should move to start having regular discussions about regions that are underrepresented on RSP, likely using the RfC format, and inviting editors from NPP, relevant WikiProjects and other language Wikis, and the broader Wikipedia community to participate. Given that the close for the recent RfC about moratoriums at RSN included language about not having RfCs about sources that have never been discussed before, I wanted to get broader community support for this proposal before opening up a discussion. It is my opinion that a lot of the pushback against reliability RfCs has been from editors who are alarmed that these RfCs being used to aggressively deprecate sources; the sole purpose of this proposal is to address systemic bias in our ability to evaluate sources, particularly in the context of new page patrol.

Here is a draft of what a regional source discussion RfC could look like. I anticipate that some people may object to the amount of background summary provided; I would be amenable to cutting down the introduction to a list of links to relevant RS and Wikipedia articles, and to leave only completely uncontroversial statements in the sections for individual sources (any further relevant information can always be added in a signed comment in the discussion section).

TL;DR New page patrol has a systemic bias problem, WP:NPPSG is an attempt to help close that gap, but in order for it to be effective we need to proactively have discussions about sources covering regions and topics that do not often come up at RSN on their own. Please comment with your general thoughts on this proposal, as well as constructive criticism for the proposed discussion format. signed, Rosguill talk 04:48, 6 November 2019 (UTC)

I read it and still don't understand it. What is being proposed here and why?--Paul McDonald (talk) 13:23, 6 November 2019 (UTC)

Notices about this discussion have been posted at the talk pages for the reliable sources noticeboard, WikiProject Countering systemic bias, new page patrol and WikiProject Reliability signed, Rosguill talk 05:01, 6 November 2019 (UTC)

  • I think this is a nice idea. Provided the RfCs make clear that their scope is only for broad guidance in reviewing AfCs, and not to be used as a definitive statement of reliability or deprecation, I don't see any issues. Sam Walton (talk) 09:37, 6 November 2019 (UTC)

The essay at Wikipedia:Systemic bias attempts to address a wide variety of biases. I have my doubts about an omnibus RfC meant to address them all.

  • Any new-page-patrol-level countermeasure addressing those without access to an Internet-connected computer is unlikely to have any resemblance to a new-page-patrol-level countermeasure addressing editing by corporations who deploy staffers and pay outside consultants to create/edit articles about themselves.
  • Any discussion on Wikipedia among experienced editors tends to focus far more on paid editing than on things like gender bias. That doesn't necessarily mean that paid editing is a bigger problem as opposed to just being something that pisses those editors off.
  • Any discussion on Wikipedia among brand new editors tends to focus on things like alt med or on whether Wikipedia is more based against Team Read or Team Blue, simply because so many people feel strongly about those issues and do not feel strongly about things like topics lacking sources in the native language of the topic. Alas, the proposed RfC is quite likely to become Yet Another Battleground About Alt Med, Donald Trump, Etc.
  • Some of the biases listed at Wikipedia:Systemic bias may not be a problem at all. That page says that regions where English is an official language or English-language schooling is common participate more than countries without broad teaching of English. It is not clear to me that this is an actual problem. I would expect the French language Wikipedia to have more participation by French speakers than Spanish speakers, but is it an established fact that this is a real problem? Who decided that the Polish Wikipedia focusing in on Polish issues and the English Wikipedia focusing in on English issues is a real problem?

One possible countermeasure to the above problems: separate sections for these different areas of bias with aggressive pruning of off-topic comments. --Guy Macon (talk) 10:29, 6 November 2019 (UTC)

If editors of an English-language encyclopedia tend to create more articles about subjects known in the English-speaking world then that's no great problem, but if new page patrollers are using different standards for evaluating articles according to the origin of their subjects and the sources about them then it is a problem. Phil Bridger (talk) 18:07, 6 November 2019 (UTC)
As I read this proposal. it seems to be saying just the opposite: that new page patrollers are using the same standards -- standards that are more appropriate for the US, UK, etc. -- no matter what the the origin of their subjects and sources. I am pretty sure that this is correct in my case. I have been studying WP:NPPSG and find that I already have a good feel for the reliability of a lot of the sources listed for North America, and far less familiarity with the sources listed for some other regions. --Guy Macon (talk) 18:49, 6 November 2019 (UTC)
I think it's less a question of standards and more a question of our ability to actually meet those standards, and these errors occur in two places.
Any good page reviewer knows that before nominating an article for deletion, they need to put in a good faith effort to find sources that weren't included in the article. But if the article is about a Turkish singer, and the reviewer not only know nothing about Turkish music, but nothing about Turkish media landscape (or even enough of the language to begin to look for sources), then they're not going to be able to properly do such a search.
The other case is evaluating if sources already in the article are sufficiently reliable to establish notability. While there are publishing norms in American and British media that make it easy to spot a trash tabloid vs. a newspaper of record, these norms are not universal. For example, coverage of movie stars in highly regarded Indian dailies often adopts a tone that would be instantly dismissed as PR cruft in an American publication, and that's before we even deal with a language barrier. A reviewer might be able to evaluate English-language coverage from sources that they don't recognize on the basis that they can tell from the content itself whether information about the subject is significant, but when they have to rely on a machine translation (and especially a machine translation from a non-Latin alphabet) it becomes a shot in the dark. signed, Rosguill talk 19:12, 6 November 2019 (UTC)
For what it's worth, I don't think anyone is under the impression that this will solve systemic bias issues once and for all (and as you pointed out, some systemic biases are less problematic––I have no intent to mitigate the yes we are biased biases with this process). The goal here is simply to improve our ability to evaluate and find (and thus, our ability to rely on) sources that are unlikely to be familiar or to the typical enWiki editor. The main obstacles to source comprehension are language and the difference in media landscapes and formats across the globe; however, there are also some niche topics that are also difficult for the average editor to evaluate properly (in my experience at NPP: anime, theology, firearms, metal music) and I wouldn't rule out dedicating a discussion to establishing some baseline reliability assessments for sources that cover such topics signed, Rosguill talk 19:01, 6 November 2019 (UTC)
Also in case it wasn't clear, the idea being proposed here is to make this a semi-regular thing that progressively moves across different types of sources. For example, one month we could have a discussion about Turkish sources, the next month one about Vietnamese sources, a third about Arabic-language sources from the Gulf states, etc. signed, Rosguill talk 19:17, 6 November 2019 (UTC)
The above comments have pretty much cleared up my doubts. --Guy Macon (talk) 10:27, 7 November 2019 (UTC)

This regional sources RfC format is a wonderful idea. Regional sources are indeed underrepresented on the perennial sources list. Less popular sources are typically given the benefit of the doubt if they have an editorial team, and haven't been the subject of a reliability dispute. However, in many cases, the lack of guidance around regional sources causes new page patrollers to skip articles that are based on these sources, especially if the sources are in a foreign language. As a result, articles based on these regional sources receive less attention, and aren't vetted as rigorously as articles that are primarily based on international or English-language sources.

The results of these regional sources RfCs would allow new page patrollers to become less hesitant with reviewing articles based on regional and foreign-language sources. I like how the main goal of these RfCs is to identify reliable sources from media landscapes that were previously undocumented in Wikipedia discussions.

Since there is some discussion about systemic bias, I want to clarify that this is absolutely not an affirmative action proposal, i.e. the proposed RfCs would not result in editors being more lenient when evaluating regional sources. Instead, this proposal would help new page patrollers apply the verifiability policy and the reliable sources guideline consistently across all regions, since patrollers would have more information on foreign-language sources and sources that are less familiar to them. It's not easy to research the reliability of sources in a foreign language that one doesn't understand, since there is a lot of translating involved, and because it's difficult to assess usage by other reliable sources when there is no readily available data on most of the sources in the region. This proposal would help resolve all of this, one region at a time.

Finally, I'd like to thank Rosguill for their work in maintaining the new page patrol source guide, which has been very useful for determining how much trust to assign to foreign-language sources when I encounter them in articles. — Newslinger talk 08:14, 9 November 2019 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_162&oldid=1208456263"