Wikipedia:Village pump (proposals): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 04:22, 11 April 2018

Table of contents
First discussion
End of page
New post

Shortcuts

New ideas and proposals are discussed here. Before submitting:

Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
Consider developing your proposal at Village pump (idea lab).
Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
Proposed policy changes belong at Village pump (policy).
Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
Proposed new wikis belong at meta:Proposals for new projects.
Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Net neutrality

NOT DONE

It's been a few weeks, and there is clearly no consensus to implement this proposal. Most editors opposed on the principle that Wikipedia should generally not take sides in political discussions in order to preserve neutrality. Mz7 (talk) 02:47, 10 April 2018 (UTC)[reply]

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

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

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

Oppose power~enwiki (π, ν) 00:15, 25 March 2018 (UTC)[reply]
No political action please. -- Ajraddatz (talk) 00:39, 25 March 2018 (UTC)[reply]
I strongly support net neutrality and I even tend to rant about it from time to time, but I think it might be good for Wikipedia to be politically neutral. If Wikipedia takes a political stand on just about anything, a certain percentage of users, editors, admins, and etc. will be alienated. Bob Webster (talk) 02:08, 25 March 2018 (UTC)[reply]
I don't think we can. Back when the FCC was going to vote, there was a suggestion to have WP have some similar message to get the word out. I know I supported it, but there's a very strong vocal dismissal of anything that appears to be politically motivated or similar call to action; I doubt that has dissipated since last fall. --Masem (t) 02:20, 25 March 2018 (UTC)[reply]
There is no "we" here with a monolithic political viewpoint. So no. MB 05:04, 25 March 2018 (UTC)[reply]
Oppose in strongest sense. -Wikipedia's neutrality is what we should strive for, it is wha makes Wikipedia great and unassailable.–Ammarpad (talk) 06:21, 25 March 2018 (UTC)[reply]
Comment. It is my view that the Wikimedia Foundation, in consultation with it's communities, is obligated to take any and all action necessarily to protect it's communities' ability to progress towards their goals. This action may at times suffer from a paradox of neutrality (similar to the paradox of tolerance), and this conflict can only be resolved by carefully balancing the threat's effect on our goals and the action's effect on our goals. In the case of the 2012 Wikipedia blackout, a decision was made that the threat presented an overwhelming danger to our continued operation and severe action was taken. My view is there is no blanket prohibition on potentially political action, but that such action needs to be supported by an extensive risk assessment. If you believe that this particular issue deserves such treatment, you are welcome to make your case, however I suspect we have already exhausted our ability to express our view on net neutrality at this time. TheDragonFire (talk) 08:32, 25 March 2018 (UTC)[reply]
Different support This organization knows nothing about free content, open licensing, etc. They need Wiki support, but advertising and named partnerships will neither help them or wiki because their strategic plan actually is ignorant of the basics of a free and open Internet. Instead of asking for the wiki side to do all the work, contact them and ask them for the following:
- They produce educational inforgraphics, explanatory texts about net neutrality, and a suite of other educational resources. Tell them to apply open licenses to this content and post it to Commons.
- They have in-house experts helping them design lobbying campaigns and recruit activists. Tell them that Wikipedia is the most consulted source of information for every topic in their field of expertise. Show them the traffic metrics and bring them into a conversation in which you have them compare Wikipedia's traffic with the audience they are reaching in other social media. They should understand that ~100% of activists, journalists, and anyone researching the basics of social issues will review the wiki articles as they orient themselves to the topic and bring themselves up to date. In their network they ought to be able to send someone to edit wiki, and maybe you can organize training and support for them on the wiki side.
- They organize lots of in-person protests and events. Tell them to train their community organizers to upload good photosets to commons with proper cataloging and documentation.

A partnership with the Wikimedia community cannot be the wiki side giving everything without the other side even understanding the value and significance of it. I know this organization. I appreciate the conversation they are trying to have. I want to draw them and experts on the opposing side to present their best in Wiki's media collection. Blue Rasberry (talk) 11:58, 25 March 2018 (UTC)[reply]

I would support this iff it can be shown that this is an existential threat to Wikipedia. I have yet to see that argument convincingly made. Tazerdadog (talk) 21:31, 25 March 2018 (UTC)[reply]
Oppose we as a movement don't want net neutrality, see Wikipedia Zero. While that program's being winded down, I'm sure the WMF will come up at some point within the next year or so with some idea where it would serve our mission if net neutrality wasn't a thing. When you are the 5th largest website on the planet, net neutrality has the possibility to hurt rather than help. TonyBallioni (talk) 21:51, 25 March 2018 (UTC)[reply]
Oppose We don't need no stinkin' Net Neutrality. GenQuest ^{"Talk to Me"} 22:16, 25 March 2018 (UTC)[reply]
Oppose any activism on the part of Wikipedia, we need to strive to remain politically neutral, regardless of how much I might personally feel about this particular issue. — Insertcleverphrasehere ^{(or here)} 22:18, 25 March 2018 (UTC)[reply]
Oppose: The Internet is not broken, and does not need to be "fixed" by giving the US government more control over the internet. The recently repealed Obama-era net neutrality rules adopted a vague but sweeping "general conduct" standard that gave the FCC the power to crack down on perceived bad behavior by internet providers without providing clear guidance about what would trigger enforcement. --Guy Macon (talk) 22:29, 25 March 2018 (UTC)[reply]
Comment - this is all gibberish to me. Systemic bias or what? The US-based contributors might understand what is going on but I suspect most of the rest of the world, unless IT-savvy, do not. - Sitush (talk) 23:31, 25 March 2018 (UTC)[reply]

@Sitush: Your country India organized the biggest protest for net neutrality in the world at Free_Basics#Net_neutrality_criticism_in_India. It brought popular support and politicians speaking out. May be not everyone gets all the details but lots of people have opinions about colonization and can see neocolonialism regardless of IT skills. Blue Rasberry (talk) 23:52, 25 March 2018 (UTC)[reply]

Do what? India? I'm in the UK. - Sitush (talk) 23:53, 25 March 2018 (UTC)[reply]

Another sort of bias; assuming a country from a username. I get a variation of that a lot. Although I was raised by a family from London speaking the Queen's English (I learned the Americanisms in school), people keep assuming from my name that I am French. That being said, why should the United States Federal Communication Commission In Washington be allowed to have control over the Internet? Why not some government agency in Whitehall? Or Brussels? Or African Union#Headquarters#Addis Ababa? --Guy Macon (talk) 02:14, 26 March 2018 (UTC)[reply]

Oh, indeed, I have no idea why the US should control anything and generally would much rather that country stopped trying to represent the world/throw its weight about etc ... but I also have no real idea what this proposal is referencing. I know, vaguely, of the net neutrality paradigm but that is it. And, contrary to popular opinion among people who take me to ANI, I am not an idiot :) - Sitush (talk) 02:18, 26 March 2018 (UTC)[reply]

@Sitush: Sorry to presume if there is any reason to object. We have developed India-related articles for years and I imagined that your interest in the place made India your own. Blue Rasberry (talk) 02:29, 26 March 2018 (UTC)[reply]

Oppose. Iazyges Consermonor Opus meum 15:50, 26 March 2018 (UTC)[reply]
Oppose. Stop trying to involve wikipedia in politics. Natureium (talk) 16:18, 26 March 2018 (UTC)[reply]
Oppose - WMF as a whole should not get involved with any of this ..... I personally feel NN should never have been thought of but it has and here we are (coming from a UK bloke) ... Point is we IMHO should not involve ourselves with this. –Davey2010^Talk 16:37, 27 March 2018 (UTC)[reply]
Oppose - I don't volunteer to be part of a political movement, I volunteer to build an encyclopedia. Anything that is not directly related to that, I will always oppose. Dennis Brown - 2¢ 15:50, 28 March 2018 (UTC)[reply]
Oppose - Please don't bring politics into this encyclopedia. Do it elsewhere. Not here. Javert2113 (talk) 22:53, 28 March 2018 (UTC)[reply]
Support- We already have enough people here trying out extremely long edit summaries at the village pump, so we can't hand this out to the vandels and trolls of Wikipedia.--Adam Song (talk) 19:29, 30 March 2018 (UTC)[reply]
You've probably commented under a wrong topic. MT Train^Talk 10:19, 31 March 2018 (UTC)[reply]
Oops... Adam Song (talk) 16:53, 3 April 2018 (UTC)[reply]
Oppose- We don't need to bring politics in Wikipedia. MT Train^Talk 10:19, 31 March 2018 (UTC)[reply]
Comment People are so afraid of politicizing Wikipedia in a time where they are so politically divided (esp. in america), that they are not willing to engage in defending the ideals that allowed Wikipedia to be built. I'd look elsewhere for support. Oh and cancel your AT&T and Verizon. They are the sole reason we even need to think about this. —TheDJ (talk • contribs) 12:01, 31 March 2018 (UTC)[reply]
- Rebuttal: The above assumes without evidence that having the US government control the Internet in some vague way "defends the ideals that allowed Wikipedia to be built" Sorry, but Wikipedia was built on internet freedom, not government regulations. Also, the Internet is not broken and does not need fixing. --Guy Macon (talk) 16:10, 31 March 2018 (UTC)[reply]
  - Our Internet freedom existed only until the time that the Internet started to matter to those in power. I don't want the US to control the Internet, I want the US to protect the Internet from the US. The US has its priorities as: itself, capitalism, freedom. This is reshaping the Internet as we knew it and it is bleeding into the rest of the world at an alarming rate. We need to wind that back a bit, to when the first two didn't dominate how the Internet worked. To say that the US has not significantly changed the dynamics of the Internet over the past 15 years is simply turning a blind eye to the USAs shifted priorities. The CLOUD Act is only the latest evidence. I have little hope however of stopping this. It will be fine for a while as we slowly turn 1984 and then it will be chaos. —TheDJ (talk • contribs) 12:25, 5 April 2018 (UTC)[reply]
While this will barely affects Wikipedia given the size of our articles, it will have a huge effect on streaming media/videos and so could affect commons - and if wikipedia gets round to incorporating more free media in articles, ENWP as well. The reason for net neutrality being removed is so the few monopolising companies in the US can charge content providers to prioritise their traffic. Since I doubt the WMF (even with its warchest) will be able or willing to pay Comcast etc to keep its traffic in the fast lane, this will result in a slowdown and delivery of WMF-hosted content to end-users. This isnt some sort of paranoia, I dont think anyone realistically expects the WMF will be a company able to pay the amounts that are needed. The *entire* purpose of rolling back net neutrality is to extract money from heavy-traffic companies because they are limited in what they can charge their customers. So all those opposing and live in the US: You are shooting yourself in the foot long term. Those opposing outside the US: Its in our interest to not have the rolling back of net neutrality be seen as a corporate success in the US, lest our own governments and corporations decide they want to advocate for it here. Only in death does duty end (talk) 16:37, 31 March 2018 (UTC)[reply]
- I strongly disagree. At the very least, could you at least acknowledge the arguments made by those who don't want the US government to micromanage the Internet instead of simply parroting pro-net-neutrality arguments? See [1][2][3][4] --Guy Macon (talk) 19:36, 31 March 2018 (UTC)[reply]
  - Not really no :) There really is no argument that net neutrality being repealed is to allow different internet traffic to be given unequal weight. That is the entire point of it. So if you genuinely believe the WMF's traffic is going to end up in the fast lane, sure there is no issue. But that aint gonna happen. The reason why governments have to 'micromanage' is because left to themselves private corporations would be completely unethical in their pursuit of cash. As I am not an American and live in a country that does actually believe in public services being available without restriction - which the internet clearly falls under - I am more than happy for government oversight to ensure that it is done fairly. I would prefer if the US government had *less* actual influence over it, given its currently being run by someone ruling by proclamation influenced by what he read on twitter, but since thats unlikely anytime soon I will settle for all the traffic being treated equally. Only in death does duty end (talk) 19:46, 31 March 2018 (UTC)[reply]
    - So by your own admission you won't even consider the opposing arguments. I won't bother trying to convince you then. Forgive me if I am misremembering, but you are in the UK, right? And above you claim that "I live in a country that does actually believe in public services being available without restriction". Care to explain this restriction of a public service?[5] It sure looks to me like some households are in the hosepipe slow lane stadiums used for national and international sports are in the hosepipe fast lane. I look forward to your spirited defense of water neutrality in the UK. (And if I did misremember your home country, I have examples for India, Australia, etc.) Oh, by the way, your claim that "While this will barely affects Wikipedia" is factually incorrect. See [6] and the WMF's recent caving in to political pressure from people like you who won't even consider the opposing arguments and cancelling Wikipedia Zero. --Guy Macon (talk) 20:28, 31 March 2018 (UTC)[reply]
      - Having a green lawn is a not a right much as my fellow brits would disagree I am sure. Granted if they told me I could only shower every other day or only boil the kettle twice we might have a problem. Oh and I support Wikipedia Zero in theory, it was just in practice it didnt work. I also worked for Vodafone about ten years ago who routinely zero-rated their own content like many other mobile carriers (it didnt cost anything to use their own music service for example vs other streaming services) and for mobile carriers there are technical reasons it was (to a lesser extent now) an issue. Wikipedia Zero wasnt scuppered solely because of net neutrality issues, it was scuppered because a)it didnt make the WMF money, b)it didnt make the mobile carriers money, c)it was being used to share huge amounts of pirated media costing the carriers money. But there is a marked difference between providing free internet access to information to people who do not have it (which is what Wikipedia Zero attempted to do) and asking people to pay more for the same service they already do have. Although in the case of net neutrality 'asking' is a bit of a nice way to describe what companies will be doing. 'Pay us or else' would be more accurate. Only in death does duty end (talk) 23:27, 31 March 2018 (UTC)[reply]
- Oppose-The less politics the betterAdam Song (talk) 16:56, 3 April 2018 (UTC)[reply]

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

Death knell sounding for Signpost? Proposals required

Signpost, our English Wikipedia 'newspaper', began when the project was started by Michael Snow who continues to contribute to the English Wikipedia. The first issue was released on 10 January 2005. Begun as a weekly publication, in July 2016 the official schedule was changed to every two weeks, but by November the issues were already running late with the next issue appearing on 26 November and the following Signpost not being published until 22 December three weeks later.

Signpost appeared on 17 January 2017 with a lead article from editor-in-chief, Peter Forsyth, entitled Next steps for the Signpost. Forsyth's article, which explained some of the concerns surrounding the newspaper, received a significant number of comments from readers including one from Blue Rasberry who suggested that a grant may be worth considering:

If there were a rotating internship program at The Signpost for journalism students then from one perspective it seems controversial to pay for content, but from another perspective for years the international wiki community has major projects with major investment which are almost unknown for lack of journalism. (…)This is wiki's own newspaper of record and if it has problems then I wish we could explore options to support volunteers in maintaining it.

Aschmidt suggested that Signpost could be made a blog, or even a journal, with James Heilman, known for his work on the Medicine project responding with 'Sort of like the Wiki Journal of Medicine? It is a fair bit of work. But could be good.' Stating that other related projects are '...experiencing parallel attenuation (...) Better to have fewer issues with excellent content than to fake along for the sake of hitting a weekly deadline' , Carrite makes a poignant reflection.

From August 2017 that weekly deadline became monthly; now in its thirteenth year, the most recent issue was published on 20 February with a note that the next one would be due out on 27 February (a week later?). We now have 27 March. Kudpung กุดผึ้ง (talk) 02:46, 27 March 2018 (UTC)[reply]

An indpeendent competing effort, The Citation, appears to have died out as well. Wikipediocracy hasn't had any front-page articles since December. The bread-and-butter article topics of ARBCOM cases, RfAs, etc. occur a lot less frequently than in the past. And personally, I suspect the topics I would be interested in writing about would be viewed by somebody as inappropriate canvassing. power~enwiki (π, ν) 03:39, 27 March 2018 (UTC)[reply]

Perhaps, but if you look at RfCs and such, there are now so many — and some of dubious quality or necessity — that it seems honestly hard to keep up with, beyond the specific interests one chooses at WP:FRS. There are so many discussions happening at once, it's a lot to juggle. ~ Amory (u • t • c) 11:07, 27 March 2018 (UTC)[reply]

Could part of the issue be the continued success of more focused newletters (tech, admin, etc.)? ~ Amory (u • t • c) 11:02, 27 March 2018 (UTC)[reply]

There has obviously been a problem getting workers for a long time, but unfortunately there is also one with readership. The first "News and Notes" of this year has only had 1800-odd views, which doesn't seem a lot. I think the quality remains high - it's a pity more people don't read it. Johnbod (talk) 15:07, 27 March 2018 (UTC)[reply]

+450 views through the single-page presentation. Cabayi (talk) 15:28, 27 March 2018 (UTC)[reply]

At its bare bones the Signal could be reimagined as a Portal which aggregated the recent featured articles, staffing changes at the Foundation, highest page traffic etc. But that would lack the editorial commentary which is what makes Signpost worth reading, and the release cycle which makes splits it into issues rather than it just being a stream (trickle?). Cabayi (talk) 16:15, 27 March 2018 (UTC)[reply]

Possibly newsletters are partly to blame, but certainly not wholly; those newsletters only inform a fraction of the news and action that is (or used to be) reported in Signpost. There are people who work for and on behalf of Wikipedia who have never or rarely edited it and haven't a clue of what's going on and then claim that even major new developments have been carried out in secret. Signpost does have big messaging and mailing lists as well as social media, so it reaches a larger and much broader spectrum of people. Kudpung กุดผึ้ง (talk) 16:26, 27 March 2018 (UTC)[reply]

From a production perspective, I think the key issue is the degree of co-ordination and commitment required from multiple contributors. For a period of time I edited a project newsletter, and I found most submitters were motivated by deadlines. So personally I think setting target release dates is still desirable. Perhaps there can be regular issues and supplementary ones: regular columns like the traffic report would continue to be in all issues, but feature articles and op-eds would appear on a less frequent basis. isaacl (talk) 17:35, 27 March 2018 (UTC)[reply]

Fund The Signpost with a WMF grant for a paid administrator I posted a proposal at meta:Grants:Project/bluerasberry/fund a Signpost publisher.

The WMF should not fund Wiki content creation and editorial control - everyone agrees on this. I do think that the WMF should fund the tedious tasks which no volunteer finds enjoyable, but which when completed, amplify volunteer engagement. For various reasons, including 1990s software, the need for secretarial documentation and maintenance of a calendar, and demand for adherence to community values which are excessively time intensive for the niche purpose of running a newspaper, being the publisher of The Signpost is a lot of work. We can get a volunteer chief editor, and writers, and all the roles which are "journalism", but managing the very strange back end of publishing in Mediawiki software is tedious beyond anyone's willingness to volunteer. The least expensive way to manage administration is with payment to someone who will stay out of editorial decisions but facilitate what editors and writers submit.

The reason why we should maintain The Signpost is because it has been uniquely responsible for being the communication channel for resolving community discussions which have allocated millions of US$dollars of WMF funds in ways that would not have happened without community engagement in the community newspaper. Here are some options in front of us:
Let The Signpost falter. If we do this, the WMF will invest US$millions in marketing research and strategic planning to come to conclusions which would have arisen spontaneously from volunteer engagement in The Signpost. The Signpost has already proven itself to be an amazing forum for reaching broad consensus in the English and international Wikimedia communities. It has some value and merits some amount of investment for this reason. It has already earned its funding by resolving problems which otherwise are unfathomably complicated, stressful, and high risk to resolve in any other way.

Pay US$300,000 to a software developer to make The Signpost easier to publish. These software changes would still be a pain and go obsolete in 3 years because that is how Mediawiki development goes. Editing a newspaper is unlike publishing The Signpost. There is a bottleneck of ability to publish The Signpost and also the administrative support necessary to communicate in the normal way that any contemporary newspaper would operate is not available, because Mediawiki is not set up for this. Lots of people say "just fix the software, do not pay someone to be publisher", but it is crazy hard and crazy expensive to improve software as opposed to just paying someone outright to do the boring parts.

Pay ~US$100 per issue to an individual for administering The Signpost. This solves the problem, is cheap, and the money can go to a Wikimedia chapter which needs to be developed. India and Bangladesh would be my first choices because those countries, for whatever reason, have a history of attracting journalists as Wikimedia editors. Also in those economies the money would go further, and the WMF already has plans to spend $1000s to recruit volunteers who will contribute labor that could be purchased outright for $100s. I know that the Wiki community places a taboo on buying labor, but for some tasks, paying someone outreach is a lot cheaper than funding the recruitment campaign that will identify and groom the volunteer who would do the task. Administering The Signpost is esoteric and provides no job training or relevance to actually doing journalism, and the fault is in Mediawiki and the Wiki community's overriding need to publish in Mediawiki.

I advocate for paying an individual to publish as the most practical, cheapest, and most likely path to success for getting The Signpost out. We have content submissions, excellent editorial oversight, and readership. It is annoying that the bottleneck is in administration of adapting weird obsolete software to journalism.

Anyone with ideas might also try to form a The Signpost user group - meta:Wikimedia user groups. This would establish a board to oversee The Signpost, appoint a chief editor, and protect the values of the publication. Blue Rasberry (talk) 21:14, 27 March 2018 (UTC)[reply]

I moved this post to Wikipedia_talk:Wikipedia_Signpost/2018-03-29/Op-ed. I do not mean to fork the conversation or dismiss what others say, but the wiki threaded converation system makes it challenging to present a statement in more than one place. I am watching both conversations, but for context, the one that seems more developed and more permanent to me is in the newspaper. Blue Rasberry (talk) 15:53, 30 March 2018 (UTC)[reply]

One possible reason for the overall decline is that the Wikimedia blog is taking up some of what the Signpost used to do, particularly in terms of research reports and Wikipedia/WMF activities. Don't know how much energy this has bled off from the Signpost, but The ed17 and Jayen466 might have input there. I wonder if the Signpost could incorporate blog links to add to regular features such as the traffic report... I don't know. Montanabw^(talk) 21:23, 27 March 2018 (UTC)[reply]

The WMF blog is not run by the community, rather it's corporate communication. It is up to the community to decide whether it will have a voice of its own. That's what the fall of Signpost is all about in the end.--Aschmidt (talk) 21:49, 27 March 2018 (UTC)[reply]

Replace it with something short, snappy, informative and weekly. The Administrators' newsletter could be a nucleus, obviously with a wider topic range and a spot for an opinion piece (limited as to word count). One featured picture is enough: Noyster (talk), 16:22, 28 March 2018 (UTC)[reply]
Well, the Administrators' newsletter already exists, so we would not have to duplicate it, would we? – BTW, thanks for the hint, I didn't even know it even exists, I've just subscribed to it) – Another example for a brief format might be the French fr:Wikipédia:Wikimag. A showcase for a much more lively concept would be, of course, the German de:Wikipedia:Kurier which is, in fact, a multi-author blog that everyone who wants can contribute to. It has become a bit of a nuisance that the German-language Wikimedia chapters have come to use it as a channel for their corporate communication with the community, too, but by and large it still is run by Wikipedians from all projects and colours. Its main advantage over the old Signpost is that you can publish a post whenever it's suitable. There is no weekly, by-weekly, etc. format, and there is no staff that decides what comes in and what stays out. It's a community blog, not a journalists' project.--Aschmidt (talk) 22:57, 28 March 2018 (UTC)[reply]

I guess I stopped taking The Signpost seriously when it went from providing a succinct overview of what was going on, and moved to letting editors grind their personal axes in an attempt to stir controversy and get page views. Given the continued moribund nature of the project and low readership figures, perhaps it is best to just let it die. Certainly I don't think we can seriously argue that it is the vital communications channel that it was in the past. Lankiveil ^{(speak to me)} 01:17, 31 March 2018 (UTC).[reply]

As much as I loved the signpost at one time.. I cannot disagree with your position. —TheDJ (talk • contribs) 08:44, 5 April 2018 (UTC)[reply]

It went through an unfortunate patch, but that is hopefully over, and the role of the Signpost and the need for it remains. I suggest that we try and recruit sufficient volunteers to get at least a minimal signpost regularly circulated. Like that initial creation of a stub article, once it is in being it can attract people who wish to improve it. The problem in my view is in trying to keep such a large publication that it can't achieve its publication schedule. Ϣere SpielChequers 10:06, 5 April 2018 (UTC)[reply]

Respectfully, if it were a "need" for the Signpost, we wouldn't be having this discussion because people would be writing and publishing it. The community seems to have been getting along just fine without it. Lankiveil ^{(speak to me)} 04:34, 9 April 2018 (UTC).[reply]

Well, just pick a date say the 20th of every month publish whatever is ready - that assumes there are people interested in being editors/coordinators/creators of the thing - but if there are not, there are not. It's WP:Sofixit, the do it yourself way, which is generally how anything gets done on WP. Just one has to decide to do it, and hopefully they have the skills to inspire (and deal with) others joining in -- and the foresight to meet the needs of whatever readers they wish to serve. (Note: Many of the past and future likely articles/features are compendia of what is elsewhere on the pedia, gathering together and highlighting things, which is fine and which means all one needs is someone(s) willing to do that) -- Alanscottwalker (talk) 11:08, 5 April 2018 (UTC)[reply]

Once per month, or it's over

If we can't find any editors willing to update the Signpost 'at least' once a month? then the whole thing is doomed. BTW: the title "Signpost", should be changed to "Wikipedia News", for a more accurate description. GoodDay (talk) 16:55, 6 April 2018 (UTC)[reply]

If Signpost is having its thunder stolen by more focused newsletters, why not just aggregate content from those newsletters once a month? bd2412 T 17:25, 6 April 2018 (UTC)[reply]

@GoodDay and BD2412: I write for the publication and I am just one person with an opinion, but my view is that the publication has always had lots of writers, editors, researchers, journalists, etc. The bottleneck is in recruiting a publisher to facilitate the actual publishing of the submitted content in a very weird publishing system. Wiki is 1990s software and not designed for either journal publishing or the kind of communication required to publish a journal. If writers and editors could be without the burden of doing the publishing then there would be more volunteer engagement. As a volunteer activity publishing itself is devoid of fun. The journalism side of The Signpost is fun for lots of people when there is a publisher. Publishing is a technical process unrelated to journalism. Blue Rasberry (talk) 20:36, 9 April 2018 (UTC)[reply]

I'm willing to do one or two "publisher" cycles to keep it running, but not every month (and certainly not every week). Do you have an IRC channel to coordinate things? power~enwiki (π, ν) 20:48, 9 April 2018 (UTC)[reply]

How about every 3 months? We could change the name from Signpost to Wikipedia Quarterly Report. GoodDay (talk) 21:33, 9 April 2018 (UTC)[reply]

Automated article assessment

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

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

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

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

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

Comments on automated article assessment?

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

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

To the first point, ORES seems designed as a generic machine learning tool that can be trained for this and various other tasks. The write-up implies that use on a given language wiki is up to that wiki. Obviously feedback from the ORES people would be welcome. If they are planning to build it into the Mediawiki software so it can do what is proposed, that would be great. The idea here is to get agreement from the people here that it would be a good idea, and then the best implementation approach can be worked out. Aymatth2 (talk) 21:37, 5 April 2018 (UTC)[reply]

There are about 20 inbound links to Nightswimming (Awake), which the bot would rate as mid importance. That typically means something like "Subject is only notable within its particular field or subject and has achieved notability in a particular place or area", the default definition used by WP:Wikiproject Television and WP:Wikiproject United States. The article meets that criterion. AlexNewArtBot does not support Wikipedia:WikiProject Awake, so it would take a human to assess importance for that project. A guess based on number of inbound links is just a guess, as is the ORES assessment, but if they get it right much of the time, it is worth recording the guess. Then a human can review and correct if needed. Aymatth2 (talk) 15:35, 5 April 2018 (UTC)[reply]

The purpose of quality assessments is to help project members prioritise work. This could involve upgrading the quality of important but low-quality articles, or pushing up high-quality articles to GA or FA status. If ORES says an article seems poor quality, and the number of inbound links suggests it is important, that is probably useful even if a strict reading of the criteria would say quality is a bit higher and importance a bit lower. See Wikipedia:WikiProject assessment#Statistics: there is a backlog of over 570,000 articles to be assessed, about 10% of the total, up from 552,983 in May 2017 per Wikipedia:Assessing articles#Statistical analysis. A rough assessment that can be refined by a human any time is better than no assessment at all. Aymatth2 (talk) 15:35, 5 April 2018 (UTC)[reply]

This idea sounds great. Have you seen User:Nettrom's work on m:Research:Screening WikiProject Medicine articles for quality? I found that it sometimes slightly over-rated articles that had long lists of refs, or long bulleted lists, but its stub ratings were spot-on, and if it had a gap of two classes or more, then the current assessment was always wrong.

There's more that I'd like to see a bot doing with assessments. For example, at Category:Unassessed medicine articles, every single article about a person and organization needs not just the quality rating, but also |importance=Low and |society=yes. Even if the bot could tag only stubs about people this way, it could halve the amount of work that needs to be done manually. WhatamIdoing (talk) 04:42, 8 April 2018 (UTC)[reply]

I did not know about User:Nettrom's work. It does not surprise me that many assessments were wrong. Partly that is from drive-by assessors who think: "1-2 paras = Stub/low, else = Start/low", partly from failure to reassess after improvements are made. Once the bot gets settled down there may be a lot of refinements both to the scoring algorithm and to adding more data. Project-specific rules like "individuals and hospitals default to Low for WikiProject Medicine" could be added. I would like to start simple though. Aymatth2 (talk) 14:22, 8 April 2018 (UTC)[reply]

This is a really interesting proposal, Aymatth2! Thanks to WhatamIdoing for pinging me in this discussion, otherwise I would probably not have noticed it. The proposal is right up my alley and describes a setup that I'm fond of, having a bot propose some low-cost changes that a human can review. WhatamIdoing already pointed to the pilot study we did with WPMED on reassessing stubs, where we learned a few important lessons about how to set things up so it finds a good selection of candidate articles.

I thought I'd also mention a couple of related things. First is SuggestBot, which I run. When the bot posts suggestions it also adds info on page views and article quality (both predicted and currently assessed) so that editors can prioritize their work in the way that best suits them, and reassess the article if it's needed. One of the comments that sometimes comes up is "Why did it recommend this to me, it's not a stub?", which is an example of the challenge of keeping assessments up to date.

Secondly, I did a project with Aaron Halfaker a year ago, where we worked on building a model for predicting article importance. There's more information available on the project's research page on meta. During that work, we ran into the challenge that Finnusertop mentions: importance is WikiProject-specific. We therefore ended up training a model for each WikiProject so that it learns their preferences. We again collaborated with WPMED during that project and also incorporated a set of rules that cover their specific preferences on importance ratings for certain types of articles. Using Wikidata to identify the type of entity an article is about, we could then automatically rate all articles about people to Low-importance, for example. The results of that project were promising and suggested that article importance predictions could be useful when they're given as candidates to a human reviewer.

Again, really interesting proposal, it's precisely the type of thing that the wp10 model in ORES was built to help out with. Hope some of this info is helpful, let me know if there are questions about any of this! Cheers, Nettrom (talk) 15:53, 9 April 2018 (UTC)[reply]

@Nettrom: I had no idea how much had been done already. It seems that maybe it would not be too hard to clone and tweak SuggestBot to become a first version of ~~ArtAssBot~~ AutoAssessBot. (?) Aymatth2 (talk) 17:49, 9 April 2018 (UTC)[reply]

How is ORES trained? I suspect a lot of assessors rate quality based on length rather than value to readers, and importance on gut feel rather than project criteria. If we train ORES using these dud assessments, it will learn wrong. Ditto with stale assessments. I started Marcel Lucet the other day with a fairly basic first version, which was assessed as Stub. I expanded it, but it is still Stub and likely to stay that way. We don't want to teach ORES that is what a stub is like. Aymatth2 (talk) 17:49, 9 April 2018 (UTC)[reply]

Length matters, and is a fairly good predictor overall. But I think Nettrom's work is looking at multiple criteria, such as the number of refs and maybe section headings. WhatamIdoing (talk) 23:37, 9 April 2018 (UTC)[reply]

A Start-class article "Provides some meaningful content, but most readers will need more", while a C-class article is "Useful to a casual reader". Start may also be weaker than C on citations, style, etc.. For simple topics the casual reader will often be satisfied with a short, readable and accurate article. I agree that length and quality often go together, but would prefer that ORES did not give length excessive weight. Aymatth2 (talk) 02:26, 10 April 2018 (UTC)[reply]

We can always improve the training-set for ORES' article quality model. If you are interested in doing the work to check the set of assessments used to train ORES, we can improve ORES' prediction quality. We have a system called m:Wiki labels that makes manually assessing random samples for training ORES as easy as possible. I'm thinking we can get decent fitness with 150 observations for each quality class (150 * 6 = 900). We can start by sampling article versions from the labels (WikiProject assessments) we already have in Nettrom's original dataset. It would be a lot of work, but it would be a great way to validate the model.

Alternatively, you could just test out what we have already. It seems to work very well in practice (based on years of feedback). We can always come back to re-train it when/if you identify consistent problems. --EpochFail (talk • contribs) 14:55, 10 April 2018 (UTC)[reply]

Fair enough. If the assessments are usually good, that is what is needed. There will always be cases where it gets it wrong, but those can be fixed by a reviewer. Maybe after the AutoAssessBot has been running for a while it would be useful to look for patterns in articles where the ORES assessment has been manually overridden. Aymatth2 (talk) 16:12, 10 April 2018 (UTC)[reply]

The auto-classification of importance research results are a bit discouraging. I felt that if ~~ArtAssBot~~ AutoAssessBot only assigned an article to a project when AlexNewArtBot gave it a high score for the project, number of inbound links would be a reasonable proxy for importance. This would avoid the problem of giving Winston Churchill Top importance on WikiProject Architecture (he built garden walls as a hobby). Maybe that aspect of the bot has to wait for development of a better importance prediction model. Aymatth2 (talk) 17:49, 9 April 2018 (UTC)[reply]

Assuming ~~ArtAssBot~~ AutoAssessBot was built and settled in, I would like to let it rip on the 570,000 unassessed articles. After that, it could run through all articles adding |autoassess=ok where it came up with the same result as the existing quality/importance assessment for a project. But I have no idea how to deal with the remaining millions of articles with dud or stale assessments. Aymatth2 (talk) 17:49, 9 April 2018 (UTC)[reply]

You might want to consider a less potentially offensive name for your bot. ;-) WhatamIdoing (talk) 23:37, 9 April 2018 (UTC)[reply]

Oops. AutoAssessBot, it should be. (As an ex-Brit I tend to think of "ass" just as a useful beast of burden.) Aymatth2 (talk) 01:45, 10 April 2018 (UTC)[reply]

I'm already doing something similar to this at AFC. It would be fairly trivial to set something up to use the wp10 model to auto-assess talkpages. SQL ^{Query me!} 19:49, 10 April 2018 (UTC)[reply]

I ran wp10 over CAT:FA, results were interesting. SQL ^{Query me!} 22:17, 10 April 2018 (UTC)[reply]

RFC to dissolve Wikiproject Stub Sorting

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following list:

WikiProjects and collaborations

When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

redundant over-specific templates - {{underpopulated stub category}}, {{very large stub category}}, {{deprecated stub}}

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

WP:WSS is for coordination. Amongst other things, it is used to ensure that we don't get two stub templates (or two stub categories) created to do the same job; it ensures that template and category names are harmonised and consistent; it ensures that the category tree has a logical structure. The WP:WSS/P process is there to discourage the proliferation of stub templates (or stub cats) that have little potential for use. --Redrose64 🌹 (talk) 10:04, 6 April 2018 (UTC)[reply]

I agree with Redrose64. WPSS serves a valid purpose and less "process-y" will likely result is more duplicates and non-maintained categories. It's like proposing to dissolve WP:WPMOS because some people don't like following the MOS and they feel like it's too bureaucratic to have so many rules on how articles look like. The nominator also fails to mention that WikiProjects to organize certain aspects of the project are common (see Wikipedia:WikiProject Council/Directory/Wikipedia#Maintenance). Regards So Why 11:07, 6 April 2018 (UTC)[reply]

I do agree that if the system continues to exist, there needs to be coordination or it'll become a mess. But TBH I've never understood why there's a system of stub sorting - it all seems very redundant to wikiproject ratings and categories there (though it does provide more specificity, I dunno how much it is actually helpful)

Giving some actual and specific examples of the "bad" that they do would help (e.g a link to specific TfDs etc) Galobtter (pingó mió) 11:30, 6 April 2018 (UTC)[reply]

They're much easier to navigate than WikiProject banners. It's how I first got involved with my early modern conclave project. TonyBallioni (talk) 12:01, 6 April 2018 (UTC)[reply]

ICYMI, details of the "Esperanza" project mentioned by nom can be found here. Pegship (talk) 13:52, 6 April 2018 (UTC)[reply]

To add, here's the MfD (which I closed) where this was initially raised. ~ Amory (u • t • c) 18:43, 6 April 2018 (UTC)[reply]

Stub templates and categories do not affect the content of Wikipedia, but rather its organization, and both the project and its output are easily ignored by users and editors, who are welcome to go on their merry ways. The pages listed here for comment could certainly use some review and possibly some cleanup; some of them are long-abandoned or have already been redirected to more appropriate pages. (Template:Stubsort (edit | talk | history | links | watch | logs) and Template:Stub sort (edit | talk | history | links | watch | logs) have not been implemented since 2011 and aren't used on any article pages; Wikipedia:Template messages/Stubs already redirects to Wikipedia:WikiProject Stub sorting/Stub types (edit | talk | history | links | watch | logs); Wikipedia:WikiProject Stub sorting/Criteria (edit | talk | history | links | watch | logs) consists of an explanation as to why the page was discontinued and where to find the current discussions.) tl;dr: WPSS serves a purpose used and valued by many editors; if deleted or "shut down", I would like to know the form and procedure that would be implemented to serve its function. Pegship (talk) 23:31, 6 April 2018 (UTC)[reply]
I have not seen an issue with this WikiProject's modus operandi and therefor oppose this proposal.--John Cline (talk) 04:00, 7 April 2018 (UTC)[reply]
I don't know enough about this WikiProject to have an opinion about whether it should be dissolved, but I hope someone who does will respond to Lojbanist's concern about new stub-related templates being sent to TFD, ignored and automatically deleted. If this is actually happening, perhaps some kind of tweak in the process is in order.—Anne Delong (talk) 12:20, 7 April 2018 (UTC)[reply]
- As a long-time member of WPSS, I can tell you that it's not our practice to arbitrarily delete or nominate for deletion a stub template or category that was created in good faith (and sometimes not so good faith). Believe me, we're sticklers for consensus. If there has been an issue such as those referred to by nom, I'm unaware of it, and I'd appreciate someone bringing it to the attention of me or any other stub sorter. I have looked into nom's past contributions and comments (under both usernames) and can't find any reference to stub-related issues. Pegship (talk) 18:17, 7 April 2018 (UTC)[reply]
WSS has been around since 2004, and a lot of its processes date from when the project and Wikipedia as a whole was more active. Perhaps if it is to stick around, it should be optimized to operate with fewer people required to approve things. --Rs chen 7754 18:38, 7 April 2018 (UTC)[reply]
Oppose the specific motivation cited (that stub templates not approved by this group are often deleted at TfD) isn't helped by dissolving the group, and I see no good reasons to get rid of this system. There must be some place to discuss stub templates. power~enwiki (π, ν) 18:19, 8 April 2018 (UTC)[reply]
Oppose While some parts of the project may be outdated/inactive, the project as a whole goes on. -- Iazyges Consermonor Opus meum 13:37, 9 April 2018 (UTC)[reply]

Back-tagging STiki edits (1,000,000+ revisions)

Noting here that backtagging is (or probably should be) blocked by phab:T185355. Further discussion is of course still welcomed :) — MusikAnimal ^talk 05:09, 9 April 2018 (UTC)[reply]

Hello! First to give some background... I requested that STiki start tagging edits, much like is done with Huggle and other popular off-wiki software. The author of STiki, West.andrew.g, was in favour and I think we're good to go for tagging STiki edits moving forward.

We also pondered at the idea of back-tagging edits made with STiki. I'm generally in favour, as this would make the tag data complete (in particular, this is useful for database reports and analysis). Wikipedia:Tags states "tags cannot be added to revisions yet", but it appears there is now an API endpoint for this. That same information page links to this December 2014 discussion, which seems to give consensus for bot-tagging of edits, subject to individual bot approval.

Meanwhile, Special:Log/tag is nearly empty. This tells me either folks are either unaware that tagging existing revisions is now possible, or consensus has changed. I can't find any evidence of the latter.

So, on behalf of West.andrew.g, I'm proposing we do this for STiki. The thing that is controversial is that there are over a million edits made with STiki. Mass-tagging would certainly pollute Special:Log. I think if the bot task is throttled, say, at 100 revisions a minute, this shouldn't really be that disruptive, and only take around a week to complete.

I'm personally a bit torn myself on whether this is a sane idea... mainly because of the volume of edits. I realize the benefit also isn't far-reaching, but it is of use. For instance XTools has the capability of identifying edits made with specific tools, and listing non-automated contributions, using tags or regular expressions. The latter does work to some degree (searching for edits with "using STiki" in the summary), but this is slow and not comprehensive because anyone can remove the STiki advert from the edit summary. The tag filter at Special:Contributions I'm sure will also be useful.

Thoughts? — MusikAnimal ^talk 17:45, 6 April 2018 (UTC)[reply]

No thank you! Adding a million log entries just for tagging ancient page versions? I'm not seeing how this will make our encyclopedia better - it certainly doesn't help anything for the readers. If this was really that important a one-time database update may be preferable. As for the mechanics of actually doing what you propose - are you going to rely on edit summaries to identify these edits? — xaosflux ^Talk 17:52, 6 April 2018 (UTC)[reply]

Logging is mainly for internal use, it wouldn't benefit readers even if it were a single revision. This is more for the data hungry people, and those who appreciate such statistics, which I realize probably isn't many :) I believe West.andrew.g has been keeping track of STiki edits in his own database, but he'll have to confirm. I had doubts back-tagging this many revisions was good idea (or of interest to many people), but I didn't think it was a bad one either. Andrew asked me to make the proposal, so here I am. WP:DWAP I think applies, especially since MediaWiki is now auto-tagging reverts and the like. And Enwiki's logging isn't that large compared to some other wikis with recent changes patrolling enabled (phab:T184485). Nonetheless, a million rows indeed is a lot! — MusikAnimal ^talk 18:14, 6 April 2018 (UTC)[reply]

Err, and actually STiki edits for each user are already counted at Wikipedia:STiki/leaderboard. So that much is moot, but the concept of viewing non-automated edits, and browsing STiki edits at Special:Contribs still stands. Frankly, overall I'd like to see everything that tags be backfilled (though I know that won't happen). Some things like identifying old reverts aren't possible, but it'd be neat if it was. It's a shame we have the capability of identifying such edits, but the data is incomplete. — MusikAnimal ^talk 18:27, 6 April 2018 (UTC)[reply]

But if the edits are known already, doesn't xaosflux's proposal make more sense? DWAP or not, do we actually need to add a million log entries if the only thing that people really want is to be able use the tags for those edits? Regards So Why 18:38, 6 April 2018 (UTC)[reply]

Yes certainly, but we (the community) aren't capable of doing direct database updates without going through the API, and hence creating log entries. Sysadmins definitely aren't going to grant a request to do this for something as unimportant as STiki tags. In my opinion creating all those log entries sounds worse than it really is, but probably worth running by the DBAs... especially if we wanted to backfill other things. I wasn't following the phab discussions for the MediaWiki auto-tagging of reverts/redirects, but I suspect backfilling would have been desirable there too, except that it isn't feasible. Especially redirect tagging, since that offers a more efficient way of detecting articles created from redirects, and by whom (currently only temporarily available through mw:Extension:PageCuration tables) — MusikAnimal ^talk 18:58, 6 April 2018 (UTC)[reply]

I'm all for this; given that nearly every damn phone edit has mobile edit (13 million and counting) in addition to either the mobile web edit or mobile app edit tag, I don't think tagging stiki is going to overwhelm anything. It's useful, and having better metadata will mean being better able to use metadata. Still, by the same rationale, should we not backtag huggle (1.1 million currently) or AWB (a laughable 13 thousand), or even twinkle (god forbid)? ~ Amory (u • t • c) 18:57, 6 April 2018 (UTC)[reply]

If we want to discuss backtaging things in general I can think of much more relevant things like "uploaded edit", "transwiki import", even "bot". — xaosflux ^Talk 18:59, 7 April 2018 (UTC)[reply]

Are those tags? I don't see them at Special:Tags. But yes, I'm glad this came up, because maybe we should consider backtagging everything (though I agree STiki isn't the top priority). The tagging feature is there for a reason, so I don't see why we shouldn't take advantage of it. From an analytics perspective, the incomplete data is a problem. I am going to try to talk to a DBA about this to see if the effect on logging is anything meaningful, along with backtagging that many edits in general. Database consumption aside, are there other concerns? Is that we don't want to see all those entries at Special:Log? It's unlikely, but possible, that we can use a maintenance script so that no log entries are created. — MusikAnimal ^talk 23:27, 7 April 2018 (UTC)[reply]

@MusikAnimal:, not yet....phab:T183061...... — xaosflux ^Talk 14:26, 8 April 2018 (UTC)[reply]

I would like to see all edits from the major scripts/tools properly tagged with Special:Tags (not just an edit summary that I could, um, "accidentally" change). AWB just started tagging edits a few weeks ago, but only for people using the latest software version. It would be nice to expand this, so more editors could find out how other people are being so productive.

I'd also like to see tags on all script-based edits, i.e., the ones that aren't using the major tools. Someone replaced the contents of thousands of pages at multiple wikis with basically "testtesttesttest" last week – thousands of pages basically blanked within minutes. IMO every single one of those would ideally have come with Special:Tags that broadcast "Hey, I am NOT a fully manual edit" to any person who even glanced at Special:RecentChanges. WhatamIdoing (talk) 04:52, 8 April 2018 (UTC)[reply]

For the record, that proposal has seen extensive discussion at phab:T188433. Anomie ⚔ 22:47, 8 April 2018 (UTC)[reply]

This thread was originally about back-tagging STiki edits, but I think now we're all wondering about back-tagging everything (at least tools that can easily be identified). It's worth pursuing, getting broader input, etc., but phab:T185355 should be resolved first. That task makes it pretty clear the current system won't scale, so we probably shouldn't introduce millions of more rows into the change_tag table at this time. — MusikAnimal ^talk 05:09, 9 April 2018 (UTC)[reply]

Wikipedia:Wikidata/2018 Infobox RfC

An RfC on the use of Wikidata in infoboxes has just started. Please !vote and/or comment on the RfC page. Thanks. Mike Peel (talk) 20:46, 6 April 2018 (UTC)[reply]

Page previews - request for feedback

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

List of sources owned by editors

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

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

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

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

Well, it's probably worth consulting with WP:RX. I like the idea. Technically, if there's a set of subpages by editor, an ISBN search should be easy (along the lines of the archive search over at WP:ANI. ∰Bellezzasolo✡ Discuss 10:24, 8 April 2018 (UTC)[reply]

Unfortunately, this idea would probably violate all sorts of copyright laws. Most nations have laws which limit scanning published works, and making them available to others on line. Blueboar (talk) 11:43, 8 April 2018 (UTC)[reply]

@Blueboar: actually Ykraps is not suggesting scanning, if you look, only that the editor would be able to check a reference and say whether it is properly employed or not. Peter coxhead (talk) 12:17, 8 April 2018 (UTC)[reply]

But to discover whether a source is properly employed (or not) one needs to actually obtain a copy of the source, and READ it. I am now confused as to what is being suggested. Blueboar (talk) 12:59, 8 April 2018 (UTC)[reply]

@Blueboar:, User:Peter coxhead is correct. All you will see is a list of books. You are asking the person with the book to get it from his bookshelf, read the appropriate page and tell you whether it supports the paragraph in the article. Yes, there is an element of WP:AGF in that you are trusting the book owner to interpret the source faithfully, but that is no different to how it stands now with citations. The advantage is when there are multiple editors with the same book, who can jointly confirm the text is fully supported. In this case above [[10]], User:Slatersteven would've been able to go to the database and see that both I and User:Wiki-Ed own Ferguson's book. He could then ping us. If we hadn't had the article on our watchlists, we would never have known about the issue. This system overcomes all that.--Ykraps (talk) 15:26, 8 April 2018 (UTC)[reply]

Ah... ok. Thanks for clarifying. Blueboar (talk) 15:36, 8 April 2018 (UTC)[reply]

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

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

Quite high I would say, given the breadth of users it is more than likely that even then most specialized subject has multiple edss with access to the sources. What is not available is a way of tying that up with the edds who have the sources. The only issue I have is the ABF inherent, one edd claiming to have access to a source is not enough, we want people to check it. — Preceding unsigned comment added by Slatersteven (talk • contribs) 16:21, 8 April 2018 (UTC)[reply]

Pajz This is not about telling someone where to find references for their article, this is about putting an editor in touch with another editor who can very quickly determine whether a sentence in an article is faithful to the supporting citation. I don't see how any of projects mentioned could help with the example scenarios I've given (although I may have underestimated the scope of those projects). If I wanted to know whether Winfield's book (see below) contains an entry for a 74-gun ship called Pearl, I don't want to be told there is a copy of the book in a library thirty miles away, I want to be told whether it does or it doesn't. As regards the amount of work, not being a computer programmer, I don't know what's involved but I would've thought that a searchable set of sub-pages within Wikipedia would a reasonably straightforward thing to set up, for someone with the know-how. I am anticipating that editors who want to take part in the scheme will enter their own data.--Ykraps (talk) 11:49, 9 April 2018 (UTC)[reply]

@Ykraps: Check out inventaire.io/, which is a Wikidata front-end in which people can list the books they have and make them available to loan to other people. There are lots of web platforms like this, but this one is unusual for using and contributing to Wikidata's catalog of books. You might want to check this out because they have modeled what you are describing, and their service might be ready now to do what you want. I know it is off wiki but before any such project could ever be part of Wikipedia projects, it has get an off-wiki demo and then go through multiple steps to get closer. Blue Rasberry (talk) 16:59, 8 April 2018 (UTC)[reply]

I fear we may be at cross-purposes, what I'm suggesting is a set of sub-pages within Wikipedia which are searchable. The idea being that you can find a fellow editor who can very quickly corroborate an off-line source without lots of searching, having to visit a library or wait for someone to send them the book in the post. As an example: A user creates an aricle entitled HMS Pearl (1767) which says it's a 74-gun third-rate ship of the line and references the article with Winfield, Rif (2007). British Warships in the Age of Sail 1714–1792: Design, Construction, Careers and Fates. Seaforth Publishing. p. 195. ISBN 978-1-84415-700-6. {{cite book}}: Cite has empty unknown parameter: |titlelink1= (help). Under my proposal, anyone (including ips) can search for the source, which will bring up something like this with a list of Wikipedia editors who own the book. Any or all of those editors will be able to tell you that there is no such ship and that p.195 contains an entry for HMS Pearl (1762), a 32-gun frigate. Can anything you're suggesting help in a case like this?--Ykraps (talk) 17:27, 8 April 2018 (UTC)[reply]

@Ykraps: No one actually has to ship the books. Some people made wiki-based software imagining that the wiki community would want to mail books, but try to imagine that if when you found someone who had the book you wanted, you asked them to check something instead of mailing you the book. I know it is not the same, but this is as close as you are going to find for already-existing software based on Wikimedia projects. Can you imagine yourself joining their project and ask them to add a button that says, "do not mail, just check a page"?

Instead of searching Wikipedia subpages, this project has a Wikidata-based book catalog which is searchable. Does that not sound better to you than a plain text search system on Wikipedia pages? This project produces lists like that example book page you created. Blue Rasberry (talk) 12:04, 9 April 2018 (UTC)[reply]

@Blue Rasberry: Yes, I see how that could work. I guess the advantage of having something within Wikipedia is that Wikipedians are more likely to be interested in maintaining Wikipedia articles, and are almost certainly going to have the sort of specialist books needed for some of the obscure subjects. Added to which, there is already a method of communication, the talk pages, that means there is no need to divulge your email and because it is visible to all, might attract the attention of additional editors. However, there does not seem to be a lot of support for this proposal so may be I need to rethink things.--Ykraps (talk) 05:56, 10 April 2018 (UTC)[reply]

@Ykraps: I would call inventaire a Wikimedia project because of all the Wikidata integration and Wikimedia culture it already uses. No one ever gets access to do weird experiments at Wikipedia.org, and even access to tools.wmflabs.org can be more trouble than developers want. Check the credits at the bottom of inventaire - they obviously care about Wikimedia projects and went to a lot of trouble to integrate these tools with that. These kinds of experiments happen continuously and 1 in 100 actually comes into Wikimedia projects. When the WMF does decide to commit their own staff to software development often it is based on someone else first doing an experiment. I know this inventaire project is not perfect but it is a working demonstration. Things like Wikimedia account integration are just additional features which a developer could install depending on how much funding they have, which depends on how much interest other people have.

I was not showing you this to make you think you have no support for your proposal, and I think you are interpreting this the wrong way. I hoped that when you looked at this you would see that someone cared so much that they coordinated labor worth US$50,000+ to build a demo of your idea. From an optimistic perspective, you could say that your idea has already recruited a massive donation of labor, development, publicity, and community building which resulted in a working demo. Blue Rasberry (talk) 12:02, 10 April 2018 (UTC)[reply]

We have one of these for the video game domain. --Izno (talk) 22:45, 8 April 2018 (UTC)[reply]

Wikipedia:WikiProject Resource Exchange/Resource Request list many books they can access by posting at Wikipedia:WikiProject Bibliographies and Wikipedia:WikiProject Academic Journals.....that makes lists Wikipedia:List of bibliographies.--Moxy (talk) 12:12, 10 April 2018 (UTC)[reply]

I love the idea in principle. I think publicising which editors have access to which specialist publications, and are willing to check and supply reference details for the project, would be absolutely wonderful. When I worked in the GLAM sector, we had access to an amazing array of resources, and I still do within my own specialist areas of UK botany and Alpine mountaineering. I probably see this working best at the WikiProject level, but maybe with a standard format encouraged across Projects. In fact, I posted a selected set of resources I held for alpine mountaineering back in 2015, with the suggestion it could be worth expanding (See here). An issue to consider is removing content listed by an editor when that individual ceases to contribute here. Boy, the number of times I've thrown out (ie sent to charity shops/eBay) specialist books which I've used to enhance an article, or didn't feel I'd ever be likely to want to use again myself. By way of example, some colleagues who adminster my local World Heritage Site recently threw out a number of very detailed reference books they'd been given by other WHS projects around the world - which I saved from the bin. I used one to enhance this article, and thought about offering to post it to someone who might like to access the rest of the amazing detailed inscription details. The cost implication of posting put me off, but keeping it to access on someone else's behalf would have provided me the perfect excuse to retain it! Sadly, I think it went down the paper recycling route in the end. Regards from the UK, Nick Moyes (talk) 20:57, 10 April 2018 (UTC)[reply]

RfC: Ending the system of portals

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

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

Survey: Ending the system of portals

Support Taking at look at one example of Portal:Cricket: it contains a summary of the lead of Cricket, which is out of date (there are now twelve full members); obscure random articles that is just something someone took the effort of making them good - like Yorkshire captaincy affair of 1927; out of date news, random anniversaries and other random stuff like that. Readers aren't looking for random cricket-related stuff - it is clear, from the extremely low page-views, that readers don't care about portals. The most-viewed portals are purely from being featured on the main page; but for example Portal:Science gets only 8 out of 100000 of the views of the main page, a few hundred people a day, and they are likely from random clicks - not from people interested; which would likely account for most views of other portals too. There have been suggestions of automated systems for helping to develop portals, which even if developed wouldn't help, because portals aren't useful in any way. Personally, I've never felt the desire to read, say, a random science article, which is what portals consist of (most portals indeed have literally randomly selected content from a list)

In essence, portals try to straddle reader-facing and editor-facing stuff, but are terrible at both. They aren't really part of the encyclopedia; nor do they help in the backend - they don't benefit the encyclopaedia in anyway (the main page, which could be called a portal of everything, in contrast, encourages people to improve articles). Any navigational purpose, which I don't think portals help with at all, is better served through outlines. Featured articles and other stuff in a topic are cared more by wikiprojects, which generally link them already. Implementation could be reasonably easily done, as nearly all, I reckon, portal links in mainspace and in all pages indeed are through templates like {{portal}} (in all pages I estimate 99% of links are from being linked in wikiproject banners), which can be blanked to remove links; once the links are gone from mainspace, the portal pages can be deleted. Galobtter (pingó mió) 14:29, 8 April 2018 (UTC)[reply]

Support: It is time to abandon this useless relic simply because its function is duplicated (and done better) elsewhere. The portal system are also incomplete and what gets a portal is rather strange and random: take a look at Portal:Contents/Portals#Technology and applied sciences, Why is Portal:Amiga included but not Apple II? Why are Portal:Python programming and Portal:Java included but not C (programming language) or BASIC? Why Portal:Maryland Roads and Portal:Michigan Highways but nothing for Arizona Highways? -- or any roads in the UK? (We do have Portal:UK Trams -- last substantive edit in 2007 -- so there is that.) --Guy Macon (talk) 15:59, 8 April 2018 (UTC)[reply]
Support, in the good old days, misguided by the hype, I even created Portal:Lithuania. Agree that portals are not maintained and should be deactivated. There might be one or two portals out there that have some useful stuff worth salvaging, but 99% of the 1500 portals should be deleted. At the very minimum, the {{Portal}} from articles should be removed. Renata (talk) 16:01, 8 April 2018 (UTC)[reply]
Support, I've never understood what portals were supposed to be good for to begin with. They've always seemed like a thoroughly obsolete idea to me, and the ones I've seen were almost invariably ill-maintained, magnets for POV editing, or downright useless. Fut.Perf. ☼ 16:05, 8 April 2018 (UTC)[reply]
Support speaking for myself I’ve only made one portal edit (a reversion) and since that time 9 years ago have not found the desire to edit one since. They don’t seem to have any net benefit to the encyclopaedia side of things and hardly anyone seems to maintain or look at them, so it’s fine by me if they were removed. Aiken D 16:11, 8 April 2018 (UTC)[reply]
Support for the reasons explained above and those listed at User:DexDor/Portals. DexDor^(talk) 16:25, 8 April 2018 (UTC)[reply]
Support, per various comments above but FPaS's in particular. - Sitush (talk) 16:27, 8 April 2018 (UTC)[reply]
Support There has never been sufficient either reader or editor interest to maintain portals. I would be open to someday presenting next-generation portals which without any human involvement present Wikimedia content in a category in a human-readable way, perhaps ranked by article importance and quality. I would not want new editors looking at the portal system and using their labor to develop this content when it is a failed project. Portals are a burden for remaining out of date and abandoned. I would not want any reader to find the low quality content here. If portals get shut down then I think it should happen on a schedule of about 1 year to give anyone time to collect the information in them for re-integration, if there is anything to salvage. I think that usually there will be nothing to save, but at the same time, the portal project did recruit 1000s of editor hours and I would not want that deprecated lightly and without time for people to respond. The wind-down plan could be 3-months of comments, then 3 months of removing links pointing to portals, 3 months to move portals out of the portal: space with "deprecated" tags, then at 12 months actually delete or mark them so that they would not appear in search engines. Blue Rasberry (talk) 16:45, 8 April 2018 (UTC)[reply]
Strongly Oppose: Many people, including myself have invested many hours to improve and maintain portals. They are usefull to navigate. I propose that all portals which were created should be kept.--Broter (talk) 17:15, 8 April 2018 (UTC)[reply]

This is an example of the Sunk cost fallacy. I get that many people have given an admirable effort to keep the portal system going, but this doesn't invalidate the well thought out reasoning for them being made obsolete. Many other elements of Wikipedia have been depreciated in spite of the hard work that users put into them. User:Axisixa [t] [c] 23:23, 8 April 2018 (UTC)[reply]

Support The first item on the top right of the main page, is occupied by Portal:Arts, which hasn't been serious updated in years. This is supposed to be a featured portal. It's "supported" by a project whose page hasn't seen any activity since 2016. It's embarrassing. Vexations (talk) 17:24, 8 April 2018 (UTC)[reply]
Support despite adding these things for years and creating many see here ... it's clear that these have failed and do not serve their function as intended.--Moxy (talk) 17:36, 8 April 2018 (UTC)[reply]
Support They're outdated and the updating of them takes away from precious time that could be spent making 'Outline' articles. These are much better and avoid duplicate and outdated content on portals. I find that most people don't use portals either, rather using the search function or the main articles themselves which can act as portals. For example if wanting to know about economics I would go to the Economics article rather than the outdated Portal:Economics – Craig Davison (talk) 17:40, 8 April 2018 (UTC)[reply]
Support Largely unused an unmaintained. An outdated idea that the community clearly does not care to continue supporting. Beeblebrox (talk) 18:04, 8 April 2018 (UTC)[reply]
Support Minimally delete the internal spam from every article directing the reader to the related portals. --RAN (talk) 18:11, 8 April 2018 (UTC)[reply]
Conditional Support - Support end of portals system as we currently understand it; Oppose deletion of the portals by default - I recently had a conversation about portals with a group of people learning to contribute. A couple of them stumbled upon portals and loved the idea. Sure enough, when I looked at the particular portals they mentioned, they hadn't been updated in years. (Portal:Speculative fiction was one of them that I remember off-hand). Talking a bit more about what they liked about portals, three things stood out: (1) it has a lot of related content gathered together for a particular subject, (2) it was useful to find articles to work on and to get a better feel for the state of Wikipedia's coverage of that topic, and (3) it was much more visually appealing/inviting/useful than a WikiProject page. In other words, portals served them primarily as editors, not as readers, and that's not the way we current understand/use portals. For that reason, I'm supporting. However, it's a partial support because I oppose deletion of the portals by default -- they should be moved to relevant WikiProject subpages by default, and MfDed selectively where the WikiProject does not wish to retain them. I would love to see the portals system reconceived as a way to make WikiProjects more engaging to new editors (or any editors), maybe even thinking about using the main WikiProject page as a sort of portal to a subject. Of course, none of this is to say the outcome of this RfC should in any way mandate that any WikiProject do anything differently. — Rhododendrites ^talk \\ 18:10, 8 April 2018 (UTC)[reply]
- If the portals are all deleted, it would be a Good Thing if the Wikiprojects were notified with "heads up; the following portals are about to go away. Feel free to move them to subpages of your Wikiproject before that happens." --Guy Macon (talk) 18:21, 8 April 2018 (UTC)[reply]
  - @Guy Macon: I'm sorry, but that's not very logical. The portals should instead be tagged with {{historical}} in order to preserve their page histories. ToThAc (talk) 18:08, 10 April 2018 (UTC)[reply]
    - What part of "If the portals are all deleted" are you having trouble understanding? --Guy Macon (talk) 21:45, 10 April 2018 (UTC)[reply]
Support obsolete with respect to top articles in their subject. Don't delete, but mark as historic, lock them down (full protection), and force de-linking from content namespaces. --Dirk Beetstra ^{T C} 18:15, 8 April 2018 (UTC)[reply]
Support - efforts should be directed elsewhere, where they are more useful. Tazerdadog (talk) 18:16, 8 April 2018 (UTC)[reply]
Support – but move portal pages into Wikipedia/user space automatically or on request. Best, Kevin (aka L235 · t · c) 18:22, 8 April 2018 (UTC)[reply]
Support - I find that portals are almost entirely useless. Delete as such. Beyond My Ken (talk) 18:24, 8 April 2018 (UTC)[reply]
Oppose - I have never edited the Portal namespace, and I find many of the linked examples to be profoundly useless. However, I don't feel that cutting non-harmful features benefits the project. With a clear proposal to migrate some of these to be part of WikiProject pages, I would be neutral on this proposal. Without such a proposal, I must oppose. power~enwiki (π, ν) 18:30, 8 April 2018 (UTC)[reply]
- [EC] I do feel that cutting non-harmful but useless features benefits the project. While looking over the technology portals I ran into a sneaky POV criticism of Al Gore that was put there when he was running for president. Because editors almost never read them but some users do, Portals are a great place to hide spam, BLP violations, etc. --Guy Macon (talk) 18:36, 8 April 2018 (UTC)[reply]

what if Portal A was redirect to Outline of A. This was the name function still directs readers to an overview/index of a topic.--Moxy (talk) 18:33, 8 April 2018 (UTC)[reply]

No problem with that if [1] Outline of A exists and isn't abandoned and [2] Portal A is seeing more traffic than we would expect from bots and mis-clicks. --Guy Macon (talk) 22:40, 10 April 2018 (UTC)[reply]

Oppose - Reform may be due (which I would be happy to discuss later if this discussion shifts and does not pass), but I do not think abolition is the way to go. — Godsy^(TALK_CONT) 18:43, 8 April 2018 (UTC)[reply]

I’d be interested to know how we would reform an area that is more or less abandonded. The community and the readers seem to have made it clear they don’t find these particularly useful, we can’t force anyone to look at them or maintain them. Beeblebrox (talk) 23:59, 8 April 2018 (UTC)[reply]

Guns. We need squads of heavily-armed thugs who will kick down the doors of Wikipedia editors who aren't working on what we want them to work on and hold a gun to their head until they comply. Not a practical solution, you say? How do you explain the immense popularity worldwide of similar systems? :( --Guy Macon (talk) 22:46, 10 April 2018 (UTC)[reply]

Support — For contentious issues with a strong political POVs it a can be a real problem to maintain a political balance. Take for example Portal:Genocide a far better portal name is Portal:Human rights, but POV warriors prefer labelling "crimes against humanity" genocide for various reasons which include style (shorter more punchy name), blame game, and legalistic (genocide so defined by treaty, crimes against humanity are in part defined by custom). Given the problems of eyes and maintenance, it is too easy for contentious issues in portals to avoid the sort of scrutiny that the major articles on an issue receive see for example Portal:Terrorism which suffers from the aliments to which Galobtter referrers. -- PBS (talk) 19:38, 8 April 2018 (UTC)[reply]
Conditional support Deleting them outright is not OK. In general I'm in agreeance that Portals are ill-maintained and not used often. However some are well-maintained, useful for some, and the editors worked very hard on them. They should be userfied, or moved as a subpage of a WikiProject. At the very least, every WikiProject needs to be notified that their related portal is doomed, and let them decide what to do with it. Please don't blindly delete all of them. — MusikAnimal ^talk 19:39, 8 April 2018 (UTC)[reply]
Support: I have always thought of portals as redundant and even confusing sometime. They more or less usually look like historical archives due to outdated information with some having information dated over a decade ago. Also they generally duplicate WikiProjects pages which are more lively and better maintained. I am neutral on deleting/merging/moving or whatever, but I believe it is time for "Portals" to go. –Ammarpad (talk) 19:51, 8 April 2018 (UTC)[reply]
Support Portals are rarely used or maintained, and they don't jell with the interface or how most readers/editors navigate. Readers want to 'click-through' straight to content. Outline articles and interlinking within standard articles offers this and makes portals obsolete. Cesdeva (talk) 20:06, 8 April 2018 (UTC)[reply]
Support. These are largely useless and not well maintained. Natureium (talk) 20:14, 8 April 2018 (UTC)[reply]
Support: they are redundant to other means of navigation, mostly poorly maintained, and in some areas provide a view of the structure of the underlying topic that is not neutral and by the nature of portals not sourced. Peter coxhead (talk) 20:27, 8 April 2018 (UTC)[reply]
Support because they are usually poorly watched they are a magnet for POV pushing and craziness. I had a heck of a time with a Portal on ISIL as there was no good way to keep it from turning into almost terrorist advertising. I finally got it redirected. The only reason selected Portals get significant traffic is because they are prominately linked. I've NEVER been directed by Google to a Wikipedia portal and you have to click a search box to find portals in internal search. Portals are so 15 years ago, the internet moved on a long time ago. Legacypac (talk) 20:40, 8 April 2018 (UTC)[reply]
Support: Poorly maintained, rarely useful, few views except the eight portals on Main Page, not worth editor resources. "Page information" under "Tools" shows page views in the past 30 days. I compared some random portals to their main article, e.g. Portal:The Simpsons 527 views versus The Simpsons 235,536 views. The main portal page gets 0.2% of the views of a single covered article. My other examples: Portal:Cricket 1,527/185,133 = 0.8%, Portal:Tennis = 943/64,213 = 1.5%, Portal:Cars 2,213/91,460 = 2.4%, Portal:Greece 963/223,193 = 0.4%, Portal:Dance, 1,421/60,807 = 2.3%, Portal:King Arthur 373/166,466 = 0.2%, Portal:Microsoft 2,646/230,201 = 1.1%. PrimeHunter (talk) 21:18, 8 April 2018 (UTC)[reply]
Support deprecating them. They are utterly useless, and like many dead-end ideas from the early days, become more and more of a maintenance burden as time goes on. Next let's axe the sidebars, outlines, and bibliographies.

However, I don't think mass-deletion is going to work (it rarely does). Instead I'd suggest updating any relevant guidelines to say they are obsolete, then introducing a speedy deletion criteria along the lines of "pages in the portal namespace that are no longer actively maintained". – Joe (talk) 21:37, 8 April 2018 (UTC)[reply]

Very hard to get a new CSD approved but with a clear RFC result that would be a good mechanism to remove them systematically. Perhaps X3? We should statt by removing them from the top of the mainpage - the most important real estate for the least important namespace on the project. That will drop traffic on the portals a lot. Legacypac (talk) 21:44, 8 April 2018 (UTC)[reply]

Support - As sad as it is, no one seems to care about portals anymore. I hepled get P:MDRD to Featured Portal status (a process which has been shut down due to inactivity) and also maintain P:USRD every month for the past several years. While I value putting in time to keep the portals updated every month, unfortunately not many other editors care enough to contribute to the portals. Several years ago, many editors would contribute to P:USRD and offer suggestions for selected articles, pictures, and Did you know? hooks, which would make the portal easy to update every month. In recent years, there are very few suggestions for content which usually leads me to have to dig for stuff every month. Perhaps we could reduce the maintenance of portals and have them just randomly generate content and change every time they are refreshed, P:MDRD does this for selected pictures and Did you know? hooks. If no one cares enough to keep portals updated, then maybe it is time to get rid of them. However, I would not want to delete the entire portal namespace but would rather mark all pages in portal namespace as historical and remove links to them from article space. By doing this, we could still keep the attribution of the history of the portal namespace rather than delete a large portion of Wikipedia history. Dough4872 21:41, 8 April 2018 (UTC)[reply]
Support - as it appears they are largely pointless in the current environment. Only in death does duty end (talk) 21:43, 8 April 2018 (UTC)[reply]
Support per above. Largely useless, with dubious value to readers. -FASTILY 21:45, 8 April 2018 (UTC)[reply]
Conditional support I feel that portals result in additional maintenance time that could probably be better invested elsewhere on the project. However, interested editors should be given an opportunity to migrate the content elsewhere, and the portals should not be outright deleted right away. --Rs chen 7754 22:39, 8 April 2018 (UTC)[reply]
Oppose no strong reason to do so and it'd be more of a pain to implement than it is worth. The portal namespace isn't that useful, but I see this proposal as being about equal in usefulness to the namespace as a whole (namely, not very...) When the two options are both washes, there is no reason to change. Change for the sake of change is pointless. TonyBallioni (talk) 22:42, 8 April 2018 (UTC)[reply]
Alternative – Why don't we just encourage editors to de-link portals that are unmaintained when they encounter them? Then if someone cares that will prompt them to do some maintenance. Dicklyon (talk) 22:57, 8 April 2018 (UTC)[reply]

Because well meaning but not clued in editors will revert them, and keep add portal links without realizing what a disservice they are doing. Legacypac (talk) 00:07, 9 April 2018 (UTC)[reply]

Support There's no reason to let this largely useless part of the encyclopaedia continue to exist and just create problems for readers as well as editors. That said, I'd be open to migrating some content to wikiproject pages (on a case by case basis) if editors find a need . —SpacemanSpiff 23:34, 8 April 2018 (UTC)[reply]
Support Portals are obsolete, even the one I helped create and tried to maintain for quite some time has become an irrelevant mouldy pile of arbitrary stuff. Roger (Dodger67) (talk) 23:52, 8 April 2018 (UTC)[reply]
Support, unfortunately. They aren't a well-maintained part of the encyclopedia, and updates to most portals come very infrequently. The vast majority of page views are to the main articles themselves, as described above, and the portals are an afterthought. The featured portals process was abolished recently for a similar reason. However, I do think these portals should be archived, whether as Wikipedia project pages or in some other format. epicgenius (talk) 01:58, 9 April 2018 (UTC)[reply]
Oppose While they are most definitely obsolete, I don't like having to get rid of a piece of our history. The namespace is generally unseen and unused by the public, anyway. I suggest we use Template:Historical instead. Create a bot job to put it on all "Portal:" pages, and, if so desired, all "Portal talk:" pages, too. — Gestrid (talk) 02:01, 9 April 2018 (UTC)[reply]
Support - Wikipedia is losing editors, and it therefore does not make sense to expend effort on a portion of the encyclopedia that is barely used and whose function is already accomplished better by other pages. User:Axisixa [t] [c] 02:15, 9 April 2018 (UTC)[reply]
Support but do not delete any relevant pages (just mark them as historical instead) - Portals have outlived their usefulness. They were a great idea in the past, but as both Wikipedia and the internet have evolved, they have become moribund. It's true that many had been the result of hard work, but perhaps such energy could better be devoted into our own articles. There have been suggestions that Portals could be more active if they were instead operated by bots, but that wouldn't solve the other main problem (in that no one uses them). With that said, I'm against mass deletion of portals since they did serve some historical value: they could instead simply be marked as historical. As for the Main Page portals, they could simply be moved into the Wikipedia namespace. Narutolovehinata5 ^tccsdnew 03:18, 9 April 2018 (UTC)[reply]
Support deletion per the above. I would not mind archiving them in the Wikipedia namespace and marking them as historical, but I don't feel very strongly about it, so don't mind if they're deleted outright either. Double sharp (talk) 04:00, 9 April 2018 (UTC)[reply]
Support - these have long outlived any value they might once have had. Neutrality^talk 04:27, 9 April 2018 (UTC)[reply]
Support - Most are no longer maintained, and we should concentrate our work where it matters, on the article pages. Kaldari (talk) 04:29, 9 April 2018 (UTC)[reply]
Support, these were never really popular, and it is high time that they be formally deprecated. Trimming useless or unused features is essential to manage bloat and keep the 'cost' of maintenance down. Lankiveil ^{(speak to me)} 04:31, 9 April 2018 (UTC).[reply]
Support. Portals should be redirected to the index or outline of their parent topic, if possible, rather than deletion, but they should definitely be deprecated. ♠PMC♠ (talk) 06:08, 9 April 2018 (UTC)[reply]
Oppose I just sampled a few portals and they all seemed reasonably well-constructed and helpful for navigation. Deleting such hard work would not encourage activity elsewhere. Per WP:BITE, such hostile action would tend to discourage voluntary effort by showing that such hard work can be casually deleted by a flash mob on a whim. I'm not seeing any benefit or necessity for this. Andrew D. (talk) 06:22, 9 April 2018 (UTC)[reply]
I understand this argument, but the problem is that portals are usually constructed by one or two enthusiastic editors who then move on to other activities or leave Wikipedia. Once they aren't maintained, their usefulness tends to diminish rapidly. We should not be encouraging editors to build stuff that in the long run is not useful to readers. Peter coxhead (talk) 06:48, 9 April 2018 (UTC)[reply]

Consider the articles created by Coxhead such as James Eustace Bagnall. These get little maintenance now and, in any case, get few readers -- maybe one or two a day. When their enthusiastic creator moves on, shall we delete those too on similar grounds? Is Wikipedia only for high traffic, high maintenance pages like Kim Kardashian? All that other obscure stuff just gets in the way, right? Why not just delete everything that isn't vital and focus on getting that right before allowing anyone to start anything else? Andrew D. (talk) 13:17, 9 April 2018 (UTC)[reply]

A low-traffic target page hardly has the same maintenance reliance as a portal (which we intentionally try and funnel readers through en-masse). Cesdeva (talk) 15:05, 9 April 2018 (UTC)[reply]

@Andrew Davidson: you didn't pick a good example in James Eustace Bagnall – he's long dead, and the information in the article isn't going to change. I can give you better examples for your argument, e.g. Ponerorchis cucullata, where there's active research going on and the generic placement has changed recently and might change again, requiring the article to be moved and updated. But portals are different, as Cesdeva says. Since they deliberately cross-connect multiple articles they necessarily need regular maintenance, as relevant articles appear, get moved, get promoted or demoted, etc. Peter coxhead (talk) 16:00, 9 April 2018 (UTC)[reply]

Portals for well-established topics like Mathematics don't need to change much. Wikipedia is an encyclopedia not a newspaper and frenetic activity is not required for such pages. The point is that once you start to claim that we can discard pages because they seem to be a backwater then you put most of our content at risk. And Wikipedia is nowhere near finished yet. People are still developing and arguing about structural aspects like infoboxes and Wikidata. It's far too soon to say that everything's settled and we can discard pages which are currently not mainstream. Andrew D. (talk) 16:12, 9 April 2018 (UTC)[reply]

Well, we'll have to agree to differ, but the argument is not that portals are a backwater, but that, unlike articles, the nature of most portals means that they don't work well if they are backwaters. Peter coxhead (talk) 16:26, 9 April 2018 (UTC)[reply]

No, the argument seems to be that because some portals don't work well, we should destroy them all to make sure that none of them work at all. The main benefit seems to be that we will then have some white space where the portals used to be. Presumably the people who didn't use portals will carry on as before while the people who did like and use them will be infuriated and leave Wikipedia. Me, I'm thinking that the next step should then be to tear down the Village Pump too before we get any more bright ideas like this. Andrew D. (talk) 20:17, 9 April 2018 (UTC)[reply]

It's not "some" it is ALL. The topic traffic portals are dismal failures according to our readers considering the have the highest visability links on the project. The readers rejected this failed idea a long time ago. We just need to turn off the lights. Legacypac (talk) 02:01, 10 April 2018 (UTC)[reply]

No, that's a fake fact – facile and false. Some actual stats are listed below to refute it. Andrew D. (talk) 23:25, 10 April 2018 (UTC)[reply]

Support Pretty much useless now, per all the above comments. Lugnuts ^{Fire Walk with Me} 07:08, 9 April 2018 (UTC)[reply]
Selective support: The prominent Main Page link to a set of fragmented and often outdated resources is inappropriate and should be removed. I would support marking each Portal pages itself with Template:Historical but with any Wikiproject which links to that Portal notified so that they can remove the template if their consensus is that the Portal is active. Any Portal which Projects instead consider so poor as to merit removal can be so requested, presumably via WP:MFD. In 12-18 months time, any "orphaned" historical portals can be checked for usage volumes and considered for MFD. AllyD (talk) 07:44, 9 April 2018 (UTC)[reply]
Keep some portals including but not limited to the eight linked from the main page, continue maintaining them, and delete the rest. I think there is still some merit to maintaining a few portals about more basic topics, and a number of featured portals still receive a healthy amount of page views, so people are still using them. Portals are prettier than outlines and still serve a limited purpose, IMO. Decreasing the number of portals maintained may be a way forward for them. feminist (talk) 08:15, 9 April 2018 (UTC)[reply]
Support. I've done in a distant past a lot of work on two portals (Portal:Belgium, 29 views a day, and Portal:Comics, 47 views a day), and in retrospect it was way too much effort for very little effect compared to article building / maintenance. I no longer see any benefit in having portals on enwiki. Fram (talk) 08:26, 9 April 2018 (UTC)[reply]
Oppose I watch and edit two portals, Portal:Germany and Portal:Opera, both featured portals, and up-to-date, - why change? --Gerda Arendt (talk) 09:46, 9 April 2018 (UTC)[reply]
While you maintain the portals, there may be some point. But the problem is that portals don't continue to be maintained, as noted repeatedly above. Note also that the Germany portal gets less than 1% of the number of views that Germany does. So the value to readers in relation to the work required by editors is grossly disproportionate. Peter coxhead (talk) 10:20, 9 April 2018 (UTC)[reply]
Support They are dead (as a whole). Let's do the honours. Although I would not cry my eyes out at the sight of their deletion, I would find it disrespectful for them to be deleted -- mark as {{historical}}. talk to !dave 10:45, 9 April 2018 (UTC)[reply]
Support not updated, old, hardly viewed, and not a central part of our mission.--Tom (LT) (talk) 11:00, 9 April 2018 (UTC)[reply]
Oppose as written, but would Support a purge of some poor portals. -- Iazyges Consermonor Opus meum 13:15, 9 April 2018 (UTC)[reply]
Oppose - although many support arguments appear to have quite rational argumentation - It is bit like some who cannot cope with having projects on talk pages - project tags help the process of evaluation - the linked nature of things seems to be lost on most above. Portals can have moribund content and appearance but they are excellent links to a more complex process - where latin names of phenomenon have category pages with no attempt at explaining as to whether they are rock, plant or animal - portal links are useful to clarify the context of many pages in complex category trees that are otherwise too labyrinthian for the average user. Portals are useful, but for whatever reason, those who visit seem to think otherwise, a small problem with dismantling parts of a structure, what is suggested next? Take care with such a suggestion, I would suggest threshold of this argument needs to be considered very carefully. JarrahTree 13:38, 9 April 2018 (UTC)[reply]

Can you give an example of such a latin name category page and how a reader might arrive there without knowing whether it's about rocks/plants/animals? As an editor (when fixing categorization problems) I wouldn't rely on the portal link being correct. DexDor^(talk) 21:03, 9 April 2018 (UTC)[reply]

Support I think the efforts expended in maintaining them can be better used elesewhere. S a g a C i t y (talk) 16:25, 9 April 2018 (UTC)[reply]
Oppose If the proposal here is broad deletion of all, that can and will only end in a mess - extensive one fell swoop, hacking away of multiple pages just is bad for the project, and we do it badly. Some pedians have expressed interest in some of these even in this discussion (over many years) - so, I support those pedians -- I also might support things like removal of links from the Main Page, etc. but I cannot support this. Alanscottwalker (talk) 17:13, 9 April 2018 (UTC)[reply]
Support Outline articles are more efficient. Would not oppose some method of archival for portals that have been maintained up until at least the past month and archival with deactivation for those maintained up until a year ago, but definitely deletion for those that haven't been maintained in over a year. Ian.thomson (talk) 17:26, 9 April 2018 (UTC) Edit: Broter has (perhaps inadvertantly) provided good evidence that selective action (deleting some but not others) would result in increased bias in the portal area. Whatever action is taken (be it deletion or archival) should be unilateral and affect all portals in an identical manner. Ian.thomson (talk) 20:14, 9 April 2018 (UTC)[reply]
Support, they are obsolete, and most are not maintained. Side bars and end bars provide a similar service and do a better job at it. Kierzek (talk) 17:58, 9 April 2018 (UTC)[reply]
Support. Portals are largely unviewed and unmaintained. I do think they should be marked as historical rather than deleted outright (though deletion should be an option in some cases). Plantdrew (talk) 19:08, 9 April 2018 (UTC)[reply]
Support per Axisixa. Portals (operating like topical main pages) make sense when you have a group of editors (like a WikiProject) actively curating them. The portals (like the Main Page) aren't configured to be static. Because of that, their utility degrades over time and deletion makes sense when they aren't being updated. Maybe if the WMF had done more to retain our "wild west" editors from 2005-2008, we wouldn't be short-staffed and deprecating stuff now. Chris Troutman (talk) 20:24, 9 April 2018 (UTC)[reply]
Oppose We shouldn't be deleting pages because (i) they don't receive many page views, or (ii) they haven't been well maintained. How do readers benefit from this proposal? Some readers must find portals useful, and this proposal seems like the wrong solution to specified issues. PaleCloudedWhite (talk) 20:51, 9 April 2018 (UTC)[reply]
- PaleCloudedWhite, what's your basis for believing that they are useful to some readers? (The mere fact that people sometimes click on them isn't enough, since you click before you know whether the page will be useful to you.) Is there a particular type of reader that you think they'll be more useful to? WhatamIdoing (talk) 05:05, 10 April 2018 (UTC)[reply]
  - And what is the basis for people's assertions that they are not of any use to readers? Do the same editors make such assertions about particular articles, and that therefore they also should be deleted? PaleCloudedWhite (talk) 06:41, 10 April 2018 (UTC)[reply]
    The incredibly low readership of portals - even the 8 linked off the top of the mainpage - proves they are not useful to readers who vote with their clicks. Also every person voting here is a reader too and I've yet to see anyone really say they use portals. The objections are around preserving history or some useful bits or not offending the creators. Legacypac (talk) 06:51, 10 April 2018 (UTC)[reply]
    Portal:Christianity has received an average of 139 pageviews per day over the last 90 days - is that an incredibly low figure? Of all the articles that I've created, the most read is Dark Hedges, which over the same period has received an average of 119 pageviews per day.[11] Obviously Dark Hedges is useless to readers too and should be deleted, along with all the other articles that I have created, as they have even less readership. I am reminded of David Attenborough's comment on public service broadcasting, which he said should "cater for the broadest possible range of interests, popular as well as less popular, a network that measures its success not only by its audience size but by the range of its schedule". PaleCloudedWhite (talk) 07:05, 10 April 2018 (UTC)[reply]
    Thank-you for that comparison as it should help you understand my point and might make you change your vote. 119 pages a day for page with 16 inbound wikilinks about a row of trees is impressive (and an impressive article). We don't need to delete Dark Hedges because it is meeting a need. 139 views a day on Portal:Christianity is indeed incredibly low given it is an an extremely important topic of global interest where the portal is wikilinked from a HUGE number of pages (I gave up counting at around 30,000 page). There are so many ways to get to Portal:Christianity that 139 views a day could be mostly bots and accidental clicks. Legacypac (talk) 07:43, 10 April 2018 (UTC)[reply]
    And my point is that we should not be deleting pages based on pageviews, nor using pageviews as a basis for how useful a page is (unless, perhaps, it always receives zero). PaleCloudedWhite (talk) 07:58, 10 April 2018 (UTC)[reply]
  - PaleCloudedWhite, you said that "some readers must find portals useful". I am therefore asking: Do you use portals? Do you know anyone who does? Can you think of a hypothetical scenario in which a portal would be particularly useful for some reader? Perhaps a situation in which you personally would bypass other alternatives (search, navboxes, see also, links, etc.) and head straight to the portal? I know why the critics think that portals are not useful (critics look at the low page views, and conclude that if portals with tens of thousands of links on hundreds of articles are attracting such low interest, then realistically, some people are looking at them but nobody's finding them useful enough to seek them out.) The critics may not be correct, but it is a reasonable belief. I want to know why you believe that "some readers must find portals useful". Let's say, arguendo, you're absolutely correct. Let's say that there really are some readers who use them, and let's say that portals really are useful to those readers. Now, which readers are using them, and how are portals useful to them? If we can identify a plausible scenario, some sort of user story, then that might change people's minds about deleting them. Otherwise, I think this type of claim is going to be rejected as motivated thinking (e.g., "I spent a hundred hours on portals, so it can't just be wasted effort. It just can't!"). WhatamIdoing (talk) 15:26, 10 April 2018 (UTC)[reply]
    Your last point does not apply to me because I haven't invested time in editing portals. I made the statement about some readers finding portals useful in response to statements higher up the page stating that they are useless. People cannot make such statements; there is no factual foundation. The WMF, as far as I'm aware, has not conducted in-depth market research on how portals may or may not be used by readers, but we do have pageviews showing that some are read at least as much as many articles. That does not quantify to what extent they are useful, nor in what way, but it does establish that they are used. It's really a rather narrow way of looking at something to say, as some have here, 'I haven't read them or edited them much, therefore get rid of them'. I do not look at portals as navigation aids, rather I see them more like the random article feature - showing readers something that they weren't necessarily looking for - but in a more topic-orientated way. If they aren't performing as well as they might, perhaps some thought should be given as to how to improve them and/or give them better functionality. Leaping straight to deletion seems wholly the wrong way to go about this. PaleCloudedWhite (talk) 19:49, 10 April 2018 (UTC)[reply]
Oppose Most of the Wikipedia hasn't been well maintained. I don't see how mass deletion of content benefits the project. Hawkeye7 (discuss) 21:00, 9 April 2018 (UTC)[reply]
It seems that any collection of pages will now be subject to deletion. Hawkeye7 (discuss) 07:35, 10 April 2018 (UTC)[reply]
@Hawkeye7: Are there any reasons other than mass deletion for which you're opposing? Much of the other editors here (including myself) support only the deprecation of portals, not outright deletion, so I politely ask you to either change or justify your vote. ToThAc (talk) 18:15, 10 April 2018 (UTC)[reply]
That is not the consensus. And it's the people who haven't been here for over ten years and haven't done any work on portals but still post cursory support votes who need to justify why their comments should not be stricken. Hawkeye7 (discuss) 23:51, 10 April 2018 (UTC)[reply]

Can you clarify what you mean by "mass deletion of content"? Portals mostly consist of just a copy (possibly out of date and copied without attribution) of the lede of an article surrounded by some pretty formatting and links. Hence, deleting a portal doesn't delete encyclopedia content (facts that are of use/interest to readers). DexDor^(talk) 20:02, 10 April 2018 (UTC)[reply]
That's not true. The attribution to the original article is clear, just as it is in TFA. Attribution is required when you're copying a block of text from one article to another. The portals are encyclopaedic content, there's a lot more involved than you think, and the reasons given, ie low traffic and lack of maintenance apply to most of the encyclopaedia and are not valid grounds for mass deletion of content. What value is there in contributing articles under such a regime? Hawkeye7 (discuss) 23:51, 10 April 2018 (UTC)[reply]
Support. It seems that better systems of directing users around has become the norm and in falling out of use they have become stagnant. Even looking at Portal:Arts the most highly trafficked portal (due to a link on the main page), it appears to have almost no editor activity (edited twice in 5 months). I'd support removing all mainspace links and adding a historical template to all of the portal pages as a good compromise (preferred choice). — Insertcleverphrasehere ^{(or here)} 21:33, 9 April 2018 (UTC)[reply]
Support - I checked my edit pie chart & in my 12 yrs on the 'pedia, I've made only 5 edits (2 on main, 3 on talk) to portals. They're basically obsolete & need to be made historical. GoodDay (talk) 21:49, 9 April 2018 (UTC)[reply]
Oppose - the portal system would greatly benefit from some sort if integration with the main article space to draw more attention to it from readers and editors. Perhaps, every article linked from a Portal page should have a link back to the Portal displayed automatically. We should also move Main_Page to the Portal: namespace. Its hard to convince people to use Portals when such a visible portal page still hasn't moved there yet. -- Netoholic @ 22:58, 9 April 2018 (UTC)[reply]
Support a transition to deprecation. Do not delete anything, they are project history, there may be value in the history. Instead, for each moribund Wikiproject, redirect to the parent article. Exactly as I argue at Wikipedia_talk:Portal#Portals_are_moribund. In short, they are near useless, they are out of date and misleading for people who find them, and they are near worthless time sinks for an editor who feels the desire to update them. Do no merge with WikiProject, most WikiProjects are barely active themselves. User:Abyssal and User:The Transhumanist would like to create an automatically generated indexing/outline and summary system - that would be great, but is not a reason to not deprecate the current form of portals. --SmokeyJoe (talk) 22:59, 9 April 2018 (UTC)[reply]
Merge to WikiProjects instead of deleting. Why: There's helpful content in Portals for content organizers, and for readers, and the contents in Portals can often bridge the two groups. E.g. Portal:Mathematics contains some content/structure that is not reflected in either Wikipedia:WikiProject Mathematics nor in Mathematics nor in Template:Areas of mathematics. How: Perhaps we could have a deadline for portal-deprecation, with prominent notices given that all content should be merged before date. After that date, portal namespace could be redirected and frozen, or marked {{historical}} in a unique way. I oppose deletion of the portals and their talkpages. I support removing the 8 big ones from the Main Page, and support redirecting editor energy towards revitalizing WikiProject pages instead of building/maintaining Portals. Quiddity (talk) 00:13, 10 April 2018 (UTC)[reply]
- May I assume that this would happen only after asking the Wikiprojects and getting a positive response? Some Wikiprojects get a bit annoyed when someone messes with their space, an many other Wikiprojects are completely abandon and have nobody to either give permission or raise an objection. --Guy Macon (talk) 21:54, 10 April 2018 (UTC)[reply]
Support. I like the idea of portals, but their execution leaves something to be desired. My main project has a portal that went through the FPo process a few years ago (P:USRD) and now there's really only one editor maintaining it on a regular basis. I agree with some of the others that the content should be merged into the WikiProjects and not deleted outright. –Fredddie ™ 00:20, 10 April 2018 (UTC)[reply]
Strong support – I am glad someone did this RFC. I had been thinking for a while and mentioning to editors offsite my opinion about how outdated the concept of Portals were. I used to upkeep two myself, I even have a featured portal. However, in this day and age, I am more the person who wants them to stay but marked historic. They were a nice idea 10 years ago, but really, people can find articles one way or another without a portal. Mitch32^{(My ambition is to hit .400 and talk 1.000.)} 00:59, 10 April 2018 (UTC)[reply]
Support As someone who dabbled a few times in creating portals that didn't seem to stick, I think it would be best to merge useful content into project pages and not leave it to rot away in a forgotten namespace. Sounder Bruce 01:03, 10 April 2018 (UTC)[reply]
Oppose in favor of technical overhaul. Specifically, I would like to see a portal system with:

The automatic production of article synopses of the appropriate length when articles relevant to the portal topic are accepted and the ability to edit these synopses if they need improvement.
The automatic addition of these synopses to the pool from which the portal draws its content selections.
The ability to sort or filter the article synopses on the "more articles" page (or "more pictures", "more DYKs").
The criteria portals use to select content should default to chronological rather than random (ie it shows the last article to be featured in that subject).
The automatic addition of DYK hooks after they've been displayed on the Main Page to the pool from which the portal draws its DYK selections.
The automatic addition to the portal's content pool of featured and quality images when they get promoted at Wikimedia Commons.
The automatic generation of an image summary for the featured pictures based on their synopsis at the Commons, but with the ability to edit and improve it if needed.
The ability to automatically pull pictures from DYK articles to be associated with their hooks on the portal.
The ability to randomize all of the individual DYK hooks instead of manually devising "blocks" of hooks.
An automatically generated list of new and recently expanded articles relevant to the subject.
Foundation sanction for direct outreach by Wikiprojects to portal-goers like offering topical reference desks, advertising within-project contests, user adoption drives, etc.

Sorry for the textwall, I just thought it was worth noting that the pro-portal camp has put forth a concrete plan for reform and I think implementing these changes would address most of the ccomplaints people have about our currently busted system. Abyssal (talk) 01:35, 10 April 2018 (UTC)[reply]

Oppose. (edit conflict) There are portals that are still well-maintained. I like the idea of tagging unmaintained, out-of-date portals with a one-week deletion notice that flags the creator and the associated WikiProject(s) to either save it or let it be deleted. Project members should be allowed to extend the one-week period if editors are in an ongoing discussion about it. Maybe have a WP:Pfd page where portals can be proposed for discussion/deletion? Frankly, I'm surprised at all the support this RfC gets. What's next? Will someone come up with a case to delete little-viewed categories? or low-pageview articles? How about unused helpspace redirects to projectspace? Where does all of this end, and how much of it is due to an objectionable level of deletionism? Paine Ellsworth ^put'r there 01:46, 10 April 2018 (UTC)[reply]
Support. Move all portals into Wikipedia namespace and mark them as historical. Lojbanist ^{remove cattle from stage} 03:17, 10 April 2018 (UTC)[reply]
Weak Oppose per Paine Ellsworth. I've not edited any portals except for italic runs, so they're not an area I work in. But it's odd that this discussion is taking place without alerting every portal's talk page (my apologies if they have been alerted) as well as giving a good notice on Wales' talk page (and again, apologies if it has, I'm not a constant lurker there). This is a major move, to wipe out an entire sub-culture of Wikipedia. Paine comes up with some good "way to go forward"ness. As for his concerns, I have seen, with my own eyes, editors actually contemplating if navboxes (I call them templates) should be removed from the project. They already are banned from the mobile edition of Wikipedia. Lots of us love navboxes, they are the maps of Wikipedia. To create or add to a well-designed topic map feels like artwork. But since navboxes are already banned for 50% or our reader-views, maybe it won't take much to push them over the side. Is that what comes next? As I said, portals are not my thing here, so I don't know the level of work and care that has been put into them. Probably a lot, I'd guess. So this move is pretty major, either way it goes down, which is why every portal talk page should be alerted, so active editors know about it (I mentioned it in a move review and I think, judging from the recent comments to this discussion, that that mention at that move review alerted quite a few active editors that this discussion was going on, let alone that they'd have a chance to read six "that's" in one sentence). This major discussion is likely not very well known in the community. Randy Kryn (talk) 04:10, 10 April 2018 (UTC)[reply]
Support removing the portal links from the Main Page as soon as reasonably possible. I generally support deprecating the portal system, but I think this needs to be a slow, structured process that is developed outside this one-time discussion. There are multiple things that need to be done (e.g., stop making new ones; remove bad ones; re-work supported ones in the mainspace; consider alternatives; stop advertising/linking to them; possibly someday deleting them), and I think that process and an approximate timeline needs to be worked out by a small group of people willing to do the work, rather than being set in stone a single large discussion such as this one. Our goal right now should be setting the direction and some basic parameters. WhatamIdoing (talk) 05:19, 10 April 2018 (UTC)[reply]
Support and replace the Main Page links with the corresponding outlines (or how about something completely new and refreshing in the top-right?). Portal space is dusty and fairly dead. The few people who continue to maintain portals could refocus their efforts on other navigational systems, such as navboxes, sidebars, outline pages, and categories. — This, that and the other (talk) 06:18, 10 April 2018 (UTC)[reply]
Oppose. I agree with some of the descriptive claims of the supporters. It's true, for example, that I hardly ever edit or use the portals, and I often forget they're even there. But glancing around at a few of them, I don't agree that they're useless — they're a nice way of gathering together related material in a way that catches the eye and sparks interest. It's not a good argument that there are POV problems; there can be POV problems anywhere. --Trovatore (talk) 07:04, 10 April 2018 (UTC)[reply]
Support Like many above, I have very rarely edited in the portal space. They have not served their intended purpose many are completely out of the date. It is time to close the book on this chapter of Wikipedia. Prefer the history is maintained and mark as historical rather than delete though. Cheers – Ianblair23 (talk) 08:16, 10 April 2018 (UTC)[reply]
Support. The entire idea appears to have been abandoned. Without editor engagement, the portals serve little useful purpose. Sandstein 10:28, 10 April 2018 (UTC)[reply]
Support Not useful and distract from work that is useful. I think the portal-linking templates that litter the bottoms of articles should be deleted, as well as the links from the main page. Wholesale deletion of the portal pages themselves might be too demoralizing for the editors who created them. Calliopejen1 (talk) 12:18, 10 April 2018 (UTC)[reply]
Support: Redundant with both regular articles and categories which can provide better content and navigation. However, I also support the condition that, should this proposal pass, all portal pages be tagged with {{historical}} instead of being deleted. ToThAc (talk) 18:08, 10 April 2018 (UTC)[reply]
Support: I made a proposal to redesign portals, but that's up for a potential eventual return to the concept, if it is accepted. I agree that the portal system, as it is nowadays, does not work and needs to go. However, as requested by others, you should either make portals historical, or give a deadline before deletion. Cambalachero (talk) 19:18, 10 April 2018 (UTC)[reply]
deprecate and mark as historical. I have been worked on them in small ways, but they do seem moribund now. I would guess the deep linking of search engines is to blame, taking people directly to articles. Also WP is no longer new, and both editors and readers know their way around much better. So I support removing links to them, but they should be kept, as a record of the work on them, and in case anyone one day thinks of a use for them. Maybe one day when WP is lauched on a new medium it needs a totally new front end, and they may come in useful for such.--JohnBlackburne^words_deeds 20:25, 10 April 2018 (UTC)[reply]
Oppose. In case of discontinue, existing portals should be preserved. samee converse 21:17, 10 April 2018 (UTC)[reply]
Oppose – There are definitely useful portals on Wikipedia (even if the daily pageviews are only in the hundreds), and even if they are preserved outside a reader-viewable space, they will be made useless even if previously useful and often-updated. Yes, there are many, many useless and deletion-worthy portals of Wikipedia, but there should have been a much larger pre-RfC discussion to consider various approaches to reform (and I do not think this discussion is large or public enough to fit that bill) prior to this proposal of outright abolition given above. Master of Time (talk) 21:28, 10 April 2018 (UTC)[reply]
Support, never really took off, and in recent years they've faded almost totally into obscurity. Many of the opposing comments cite the large amount of time people have spent working on portals, which to me is if anything more reason to scrap them... imagine how much better the encyclopedia would be if all that time was spent actually improving articles! Andrew Lenahan - Starblind 21:59, 10 April 2018 (UTC)[reply]
Oppose outright deletion. Support marking most of them as historical, similar to inactive projects and other previous good-faith contributions that just no longer work in practise. And as Andrew D.'s numbers below seem to indicate, there is still substantial viewer interest in some of these portals. GermanJoe (talk) 23:45, 10 April 2018 (UTC)[reply]
- We may be confusing cause and effect here. Is the substantial viewer interest because they are useful, or because they are linked from the main page? Would a link with the same link text to an "overview of" page get any less viewer interest? --Guy Macon (talk) 23:57, 10 April 2018 (UTC)[reply]
Support - Most portals are not much of use, as many take too many clicks to access, or so inaccessible that most readers would've found what they have been looking for before seeking the portal. Outside the ten portals linked on the main page, the namespace rarely gets views. I would support marking them as historical, or automate them so it would be low-maintenance. Merging them into WikiProjects is also a good idea.Nova Crystallis (Talk) 00:18, 11 April 2018 (UTC)[reply]
Strong Oppose This proposal takes deletionism to new levels. It's equivalent to a mass AFC without any communication to the Portals themselves. This wouldn't even happen to an individual article at AFD. There is already a Guideline and a mechanism for the removal of any Portal that's deemed poor or irrelevant. It's at WP:MFD, and that is the route we should follow, not out and out extermination because editors don't like or don't use Portals, or feel nobody else does either. Admittedly, traffic is not high to many, but using page visitor figures as a guide in deciding whether an entire namespace should be deleted seems to go against our principles of access to information. It's as senseless as proposing that all articles with less than a certain visitor count should also be deleted en masse. Many Portals are linked directly from WikiProjects,some of whcih also have low visitor figures. Shall we delete these all, too, whilst we're about it? Just as there are many ways for newcomers to a library to access its content, so Portals offer one alternative route, and often quite a visual selection of introductory topics, giving a look into a broad subject in a way that a dull template at the foot of a page simply doesn't. To be brutally frank, until this RfC I'd never even noticed there were links to Portals from the top of our Main Page. (My eye never wanders up to these banners.) But if content deletion is based on disinterest and low visitor counts from the Main Page, then we should delete Wikipedia:Local Embassy - linked to from the centre of our Main Page, but with visitor counts far lower than each of the linked Portals. If individual Portals are seen as worthless, they should either be flagged as {{historic}}, or put up for a deletion discussion. At the time the 'Featured Portal' scheme was ended in 2017 there were 176 such Featured pages. They can't all suddenly be worthy of mass deletion! Nick Moyes (talk) 00:49, 11 April 2018 (UTC)[reply]
Support. The lack of active maintenance and editor involvement is problematic in some ways beyond merely keeping things up-to-date. There's a small enough community, making few enough edits, that it becomes possible for one editor to create and maintain a topic portal without any meaningful oversight—which leads to potentially serious NPOV issues. Creating a portal allows someone who is careless or unscrupulous to create a content fork, subtly (or not-so-subtly) shifting the tone and emphasis – or even substance – of Wikipedia's presentation of a topic. (And arguing that that's not really a serious problem because so few readers see the Portal pages doesn't really help matters.) TenOfAllTrades(talk) 00:57, 11 April 2018 (UTC)[reply]
Support, for many of the same reasons as the above. My opinion of what should happen: These pages are moved to WP space (WP:Portal/Science) and tagged historical. The portal namespace is summarily removed from the database. --Izno (talk) 02:52, 11 April 2018 (UTC)[reply]

Discussion: Ending the system of portals

Relevant discussion is at Wikipedia talk:Portal#Portals are moribund; Other useful information - there are about 1500 portals 14:31, 8 April 2018 (UTC) 1515 to be precise according to 1 February 2018 dump apparently, listed at User:John_of_Reading/List_of_portals Galobtter (pingó mió) 16:33, 8 April 2018 (UTC)[reply]

Also see: Wikipedia:Village pump (proposals)/Archive 138#RfC about marking the Featured portals process as "historical" --Guy Macon (talk) 15:07, 8 April 2018 (UTC)[reply]

Some exception would need to be made for the Community portal. This has been getting over 10,000 views daily since it was linked as one of the three exits ("Start helping") from the New user landing page, introduced in conjunction with ACTRIAL. The Help Out section is essential and should be kept as visible as possible. Parts of the Community bulletin board are dusty, but just need more regular maintenance: Noyster (talk), 15:16, 8 April 2018 (UTC)[reply]

Seeing as this Community Portal isn't even in the "Portal" namespace, I don't believe it would be affected either way. Good page too keep in mind, though. ~Mable (chat) 15:22, 8 April 2018 (UTC)[reply]

Indeed, I did think of that, but I also saw that they're not in portal space, and wouldn't be affected. Galobtter (pingó mió) 15:41, 8 April 2018 (UTC) Also, it is entirely different from general portals, being editor facing only (which is presumably why it is in WP space not portal space) and does an okay job of helping editors Galobtter (pingó mió) 15:46, 8 April 2018 (UTC)[reply]

...And of course even if there is the occasional useful portal, we can easily make an exception -- possibly with a move to a better namespace. What are the top ten most-visited pages in the portal namespace? --Guy Macon (talk) 16:03, 8 April 2018 (UTC)[reply]

I'd say 90% likely the top 8 are the ones on the main page, at the top right. But like I said above, I don't think people actually find the ones on the main page useful either, they just click it randomly Galobtter (pingó mió) 16:12, 8 April 2018 (UTC)[reply]

Here's a pageview graph of those main page portals, anyhow - extremely interestingly, they group into 3 clear bunches Galobtter (pingó mió) 16:24, 8 April 2018 (UTC)[reply]

I think the top-visited portals are those linked from the left sidebar, Portal:Contents and Portal:Current events and, to a lesser degree, Portal:Featured content (pageview graph). The arguments for deleting the other 1500 portals may not apply to these. -- John of Reading (talk) 16:49, 8 April 2018 (UTC)[reply]

Ahh, I forgot about them. These seem like they'd be fine in wikipedia namespace, honestly, and would be exempted; they aren't really like the other portals at all, and just seem sort of dumped there because they vaguely explore something Galobtter (pingó mió) 16:58, 8 April 2018 (UTC)[reply]

Count of Portal pages form Wikipedia:Database reports/Page count by namespace. Renata (talk) 16:52, 8 April 2018 (UTC)[reply]

Namespace ID	Namespace	Total pages	Pages with redirects	Pages without redirects
100	Portal	148868	13188	135680
101	Portal talk	36710	2701	34009

Question - If the current portal system ends, and the portal namespace disappears, presumably this would not prohibit certain active WikiProjects from creating a portal-like page within the WikiProject space, correct? — Rhododendrites ^talk \\ 17:16, 8 April 2018 (UTC)[reply]

Yes, but the main thing is that they wouldn't be linked from articles - wouldn't be reader facing - and thus wouldn't be at all like the system currently here. Thus ending Galobtter (pingó mió) 17:19, 8 April 2018 (UTC)[reply]

Broter I do understand that people have spent a lot of time on these, and that is is frustrating to see one's work deleted. However I don't see that portals help much with navigation - since they produce random articles, that isn't really navigation; outlines like Outline_of_science do a far better job. Galobtter (pingó mió) 17:23, 8 April 2018 (UTC)[reply]

WP:BLUDGEON. --Guy Macon (talk) 22:04, 10 April 2018 (UTC)[reply]

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

Please keep the existing portals.--Broter (talk) 17:26, 8 April 2018 (UTC)[reply]

I invested so many hours into portals. Please keep the existing portals.--Broter (talk) 17:31, 8 April 2018 (UTC)[reply]

List of Portals which were created by myself or very much improved by myself:

--Broter (talk) 17:47, 8 April 2018 (UTC)[reply]

Compromise? Perhaps we should "mothball" or eliminate portals which haven't been edited or maintained for a certain length of time. Pegship (talk) 18:03, 8 April 2018 (UTC)[reply]

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

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

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

We could phase them out by a) prohibiting creation of new portals b) PRODing each portal giving anyone who cares a week (or more) to salvage anything useful. c) shutting down any remaining portals in 3 months. Legacypac (talk) 20:35, 8 April 2018 (UTC)[reply]

Brainstorming: This is a good opportunity to radically re-think the Portal system, which isn't working well under its current inception. Feel free to pitch in with some alternatives for a simple mass-deletion. Here are some ideas:

Convert them to links to WikiProjects. This would help readers become editors without the need to route them through the Talk page and a collapsible banner first.
Turn them into Reference Desks for specific topics. While article Talk pages are strictly WP:NOTFORUM, I believe that "off topic" discussions between readers and editors could benefit both groups. We'd get an idea of what readers really want to know outside of our sometimes rigid system of articles, and readers would become contributors before they even know it.
Turn them into links to Outlines or Indexes to serve as centralized "See also" listings per topic.
Automatic listings of Featured content grouped by topics. See Bluerasberry's comment above (cf. Galobtter's for an opposing view).
Limiting the number of portals should help concentrate our efforts. Suitable sets could be those featured on the Main Page, some of the top categories at Portal:Contents/Portals, those corresponding with Featured articles categories, or Core topics.

Some more wild ideas? – Finnusertop (talk ⋅ contribs) 21:28, 8 April 2018 (UTC)[reply]

If portal pages are moved/created in wikiproject namespace (e.g. Wikipedia:WikiProject Foobar/Portal) then this should (1) only be by or with the agreement of the wikiproject and (2) only be a single page (e.g. not the 45 pages currently in Category:Book of Mormon portal). DexDor^(talk) 20:46, 8 April 2018 (UTC)[reply]

Would something else replace the links on the main page? It seems like a waste of space to leave almost all of the top banner empty. KSFT ^(t|c) 21:05, 8 April 2018 (UTC)[reply]

The mainpage is full of information. A little whitespace would be good, or make the rest of the box Wikipedia ... wider and thinner. Legacypac (talk) 21:23, 8 April 2018 (UTC)[reply]

Hey yes, this could be a great opportunity to update the 12-year old main page (only half-kidding!) Aiken D 21:40, 8 April 2018 (UTC)[reply]

If this is done, remember to move Portal - No Escape and portal – Libraries and the Academy back to the titles they should be at (I had to do a similar thing myself when Flow was uninstalled). {{3x|p}}ery (talk) 21:33, 8 April 2018 (UTC)[reply]
Top 7 portals: I think it would be useful to list here the top 7 portals, those that have recieved over 1,000 pageviews a day in 2017. Perhaps we can learn something from them, or focus on replacing/improving their function —

Portal:Arts 3,872 / day
Portal:History 2,235 / day
Portal:Biography 2,178 / day
Portal:Science 1,413 / day
Portal:Mathematics 1,404 / day
Portal:Technology 1,398 / day
Portal:Geography 1,063 / day

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

Those are 7 of the 8 portals on Main Page. The 8th there is Portal:Society which is number 8 in page views with 665 / day. Portal:Food with 429 / day is the most for portals not on the main page. linksto:Portal:Food currently says it has 8,045 links from mainspace. PrimeHunter (talk) 23:07, 8 April 2018 (UTC)[reply]

Major takeaway - put a link to something in the best position possible on one of the world's top visited pages and it only gets 665 to 3000 odd hits a day => total rejection by the public of this useless content. There is NOTHING wikipedia can do to drive more traffic than those 8 links. Legacypac (talk) 00:21, 9 April 2018 (UTC)[reply]

Is there any way to find out how many real links go to a particular page as opposed to links because it was added to a template? For example, 1-bit architecture has a huge number of links to it,[12] but if you look at the pages that contain the links they are almost all because it is included in Template:CPU technologies and don't give an accurate picture of how many people are interested enough in 1-bit architectures to link to it. --Guy Macon (talk) 23:25, 8 April 2018 (UTC)[reply]

I don't think that is possible, but It's somehing I've wanted to know for many years too (unrelated to the portals).--Pharos (talk) 23:36, 8 April 2018 (UTC)[reply]

User:PrimeHunter/Source links.js produces Source links on 1-bit architecture. It currently says 26 results in all namespaces (10 in mainspace). I also made {{source links}}. {{source links|1-bit architecture}} produces Source links. PrimeHunter (talk) 00:57, 9 April 2018 (UTC)[reply]

I've done a more comprehensive query, and besides the higher-placed pages that are not conventional portals, the stand-out of those not linked from the Main Page appears to be Portal:Dance, which had 2,227 / day pageviews in 2017.--Pharos (talk) 23:36, 8 April 2018 (UTC)[reply]

Portal:Dance was one of my random examples earlier with only 1,421 views in the past 30 days, meaning 47 per day. The page views graph since the first data in July 2015 [13] shows a jump from around 50 views per day to around 2300 from October 2016 to January 2018, and then back to 50. I don't know the reason but I suspect it's automated views and not humans. PrimeHunter (talk) 23:54, 8 April 2018 (UTC)[reply]

I don’t think the idea of turning them over t relevant projects is workable at a time when so many projects are inactive, just as the portals are. The fact that a small number are still being maintained is a credit to those doing so, but it doesn’t change the fact that the system as a whole has been largely abandonded. Beeblebrox (talk) 00:05, 9 April 2018 (UTC)[reply]

Regarding it being more effort than it is worth - at minimum this would be blanking templates that link to portals/removing templates like {{portal}} from mainspace; then marking portals as historical; this wouldn't be much effort that I can see. Then we can save fiddling about it, and prevent other people from wasting their time for the next 10 years on portals Galobtter (pingó mió) 03:53, 9 April 2018 (UTC)[reply]

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

From use PrimeHunter's script, I see there seems basically 0-1 links per portal in mainspace that are not from templates. So it should be simple to use bot machinery to remove all portal links from mainspace, and then marking 1500 pages historical shouldn't be hard either. Most visible non-mainspace links are from linking portals in wikiproject banners which can be removed by removing the |PORTAL= parameter. Galobtter (pingó mió) 05:11, 9 April 2018 (UTC)[reply]

Has anyone thought of keeping a decreased number of portals, which are highly used and of higher quality? They still serve a purpose and are better than an outline. feminist (talk) 08:19, 9 April 2018 (UTC)[reply]

We shouldn't be in haste to ditch the portals. Those who say "let them eat outlines, or indexes" should be aware that there over 1,500 portals to 755 outlines and 660 indexes. Many such popular topics as Football, Cricket and Dogs have a portal but no outline or index. Moreover, in all the topics I have looked at where all three types of navigation page are offered – a portal, an outline, and an index – the Portal receives the most page views of the three. I won't bore you with a table but this holds for such a range of topics as Philosophy, Engineering, Film, Forestry and United States. If we don't have the resources to maintain everything, what needs to go may be the outlines and indexes, which between them reproduce the work of the category structure: Noyster (talk), 13:49, 9 April 2018 (UTC)[reply]
- There are two kinds of pages on Wikipedia: pages people look for and pages people stumble upon. Portals, Outlines and Indexes are almost exclusively in the latter category.

For such pages, page views are determined by visibility: how many incoming links are there and from where. With Portals, we have capitalized screen real estate that will be simply wasted if this proposal results in a mass deletion and unlinking operation. The Main Page, See also sections of countless articles, navigational templates, and WikiProject banners all give visibility to Portal links and that's where all the views come from. Even if we do away with Portals, we could use this visibility for something else. In my comment above, I suggested placing Outline and Index links where Portal links are now. We should definitely think about how to make the best out of these links. – Finnusertop (talk ⋅ contribs) 16:23, 9 April 2018 (UTC)[reply]

WP:BLUDGEON. --Guy Macon (talk) 22:04, 10 April 2018 (UTC)[reply]

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

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

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

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

This is technically no problem and we should talk about the criterias which portals need to stay.--Broter (talk) 16:22, 9 April 2018 (UTC)[reply]

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

If anything can be deleted by a mob, why should someone create something on wikipedia?--Broter (talk) 16:43, 9 April 2018 (UTC)[reply]
"Mob" is emotive and disrespectful language – WP:AGF applies. It always has been the case that anything can be deleted by consensus. Peter coxhead (talk) 16:49, 9 April 2018 (UTC)[reply]
Broter, please stop WP:BLUDGEONING. --Guy Macon (talk) 16:54, 9 April 2018 (UTC)[reply]

@Guy Macon: Portals were created to stay on wikipedia! Wikipedians were encouraged to create Portals and improve existing Portals! Now some people want it all to be deleted. Please understand me.--Broter (talk) 17:26, 9 April 2018 (UTC)[reply]

If almost no one uses portals because more efficient means of linking and organizing exist, why should we waste bandwidth and editor time and effort with keeping portals maintained? Please understand what others are getting at. Ian.thomson (talk) 20:25, 9 April 2018 (UTC)[reply]

I may never edit wikipedia again if the deletionist extremists win this proposal.--Broter (talk) 19:05, 9 April 2018 (UTC)[reply]

Oh, no... What ever will we do without you... Ian.thomson (talk) 20:10, 9 April 2018 (UTC)[reply]

Broter, please stop your disruptive editing. If you continue to keep repeating yourself in message after message you may be blocked from editing. You had your say, now it is time to drop the stick. --Guy Macon (talk) 20:14, 9 April 2018 (UTC)[reply]

Example of a Portal which should stay on wikipedia is: Portal:Right-wing populism
- Example of a Portal which should be deleted on wikipedia is: Portal:Left-wing populism--Broter (talk) 19:26, 9 April 2018 (UTC)[reply]

I agree the left-wing one is definitely not maintained, but yeah, if anything, the bias that would result from one portal being deleted but not the other is an argument against selective deletion/archival and for unilateral action on all portals. Ian.thomson (talk) 20:10, 9 April 2018 (UTC)[reply]

WP:BLUDGEON. --Guy Macon (talk) 22:04, 10 April 2018 (UTC)[reply]

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

Everybody can improve the Portal:Left-wing populism. There needs to be only an interested editor.--Broter (talk) 15:16, 10 April 2018 (UTC)[reply]

There exist the politically left wing portals Portal:Communism and Portal:Socialism. The Portal:Left-wing populism is really not needed.--Broter (talk) 15:41, 10 April 2018 (UTC)[reply]

See, though, that's effort that's not being put forth for something that readers aren't using because we have more efficient methods of linking to content. The only way to fix those issues would be automating portal generation, which would pretty much take editors out of the question at any rate. Ian.thomson (talk) 21:57, 10 April 2018 (UTC)[reply]

As a first step, I would suggest removing all links to the portal namespace from the mainspace. This would essentially remove portals from the encyclopedia proper and out of the sight of readers, relegating them to the status of "projectspace" pages. The portals themselves would then be allowed to remain for at least 6 months to 1 year so editors and respective wikiprojects have time to preserve any unique content not present elsewhere etc. Particularly useful portals could be preserved as wikiproject subpages. — Godsy^(TALK_CONT) 19:55, 9 April 2018 (UTC)[reply]
- My first preference however, would be removing all links to the portal namespace from the mainspace, then marking all portals {{historical}} as has been suggested above.— Godsy^(TALK_CONT) 20:03, 9 April 2018 (UTC)[reply]
Question - if portals are to be discontinued, will there be anything that takes over from their job? Namely (from WP:PORTAL) to help readers and/or editors navigate their way through Wikipedia topic areas. I guess Outline of X and templates at the side of the main article do something like this job, and possibly much better than a portal. Is that the idea? — Amakuru (talk) 21:03, 9 April 2018 (UTC)[reply]

That's the impression I've had. I've used a portal maybe two or three times the entire time I've been here, but I use those templates pretty regularly and "Outline of..." articles whenever I want to access a lot of articles on a topic really quickly. Ian.thomson (talk) 21:43, 9 April 2018 (UTC)[reply]

Love the "outline of" pages, hate the templates. Look at 1-bit architecture. Instead of that huge wall of links at the bottom, Wouldn't it be nicer to have a simple link to Outline of CPU technologies, and have that page contain the wall of links? What percentage of readers who are interested in 1-bit architectures are looking for a see also link to SUPS? I would say that the answer is "zero". --Guy Macon (talk) 01:06, 10 April 2018 (UTC)[reply]

I'm not opposed to having both. Whichever format I find easier to read depends on the subject and how much caffeine I've had. Sometimes I have an easier time with tables, sometimes with lists.

Since the idea of automation has come up elsewhere in this discussion, I imagine it wouldn't impossible to write a template that'd turn an "Outline of" article into one of those templates. Like, some sort of mark-up that doesn't show up in the article, that you wrap around entries that are supposed to show up in the template, that's look something like {{Subst:OutlineEntry | (line number) | [[Article Title]] }}. Then the template would just be {{ (template name) | 1=[[Article|(name of first row)]] | 2=[[Article2|(name of second row)]] }}. That should be far less work to set up than automating portals. Hell, I could probably work out how to how to do templates for an Outline-to-Table dealy, and the coding nightmare that is WP:BINGO is an anomalous highpoint for me. Ian.thomson (talk) 22:07, 10 April 2018 (UTC)[reply]

I am concerned that editors currently maintaining portals may not be aware of this discussion. Can someone create a neutrally-worded edit notice for the portal namespace? And if we want to hear from readers, maybe even a namespace-specific site notice. -- John of Reading (talk) 06:24, 10 April 2018 (UTC)[reply]

Seems a reasonable idea - what do people think of adding to Template:Editnotices/Namespace/Portal? I also wonder if the editnotice should exclude Portal:Current_events and its subpages (which are probably the most active portal pages..but wouldn't be affected by this proposal), Portal:Contents, and Portal:Featured_content from the editnotice Galobtter (pingó mió) 12:59, 10 April 2018 (UTC)[reply]

Seems like a good idea. While relatively few people remain active in portal contribution, nevertheless there should still be the courtesy of informing them or at least letting them be aware of this discussion. We need more input from regular portal contributors so that their voice can be heard, and at the same time their feedback can be used in implementing whatever consensus this discussion results in. Narutolovehinata5 ^tccsdnew 15:08, 10 April 2018 (UTC)[reply]

WP:BLUDGEON. --Guy Macon (talk) 22:04, 10 April 2018 (UTC)[reply]

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

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

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

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

A new home for some useful portals

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

Automated portals

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

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

This has been proposed above, and while it might solve the editing inactivity problem, it wouldn't solve the Portal system's other major flaw: outside of just a few portals (mentioned by Andrew D. below), the vast majority barely get any views. Even the ones with a high number of views might be better off in the Wikipedia namespace anyway. Narutolovehinata5 ^tccsdnew 00:07, 11 April 2018 (UTC)[reply]

Main page link traffic in 2018

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

Long list

Rank	Page	Readers in 2018
1	Deaths in 2018	10,440,731
2	Portal:Current events	4,387,154
3	Avengers: Infinity War	4,244,723
4	Wikipedia:Featured articles	2,677,238
5	Wikipedia	1,795,210
6	Patrick Reed	1,552,039
7	The Holocaust	1,129,274
8	Wikipedia:Community portal	1,089,287
9	English language	1,022,730
10	Benito Mussolini	821,011
11	Scotland	756,252
12	Association football	633,844
13	Wales	582,933
14	Auschwitz concentration camp	574,151
15	FC Bayern Munich	562,962
16	George Weah	541,623
17	Liberia	526,109
18	Boston	482,016
19	Augusta National Golf Club	471,459
20	Apollo 11	467,370
21	2018 Masters Tournament	463,447
22	Volcano	405,686
23	Big Ben	352,576
24	Portal:Contents/Portals	343,999
25	Portal:Arts	251,984
26	Saskatchewan	251,005
27	United States men's national soccer team	239,197
28	Lega Nord	231,813
29	Wikipedia:In the news/Candidates	225,142
30	Wikipedia:Your first article	224,475
31	2017–18 Bundesliga	223,623
32	Palace of Westminster	220,180
33	Portal:History	210,188
34	The Infinity Gauntlet	208,888
35	Encyclopedia	207,631
36	Portal:Biography	196,294
37	Portal:Geography	193,451
38	Portal:Technology	191,849
39	Hungarian parliamentary election, 2018	185,973
40	Golf	180,084
41	Humboldt Broncos	169,318
42	Isao Takahata	167,146
43	Æthelstan A	149,079
44	Portal:Mathematics	129,103
45	Viktor Orbán	126,546
46	Giuseppe Verdi	123,292
47	Portal:Science	122,774
48	Humboldt Broncos bus crash	120,134
49	Wikipedia:Help desk	119,773
50	Year Without a Summer	115,715
51	Free content	104,088
52	List of historical anniversaries	100,432
53	Wikimedia Foundation	93,859
54	Timothy Weah	91,143
55	Governance	88,460
56	Casting	84,104
57	Viola	79,785
58	Wikipedia:Recent additions	78,397
59	Cecil Taylor	76,464
60	Nagorno-Karabakh War	71,591
61	Mount Tambora	71,576
62	Wikipedia:Featured pictures	70,178
63	Wikipedia:Introduction	67,917
64	April 9	67,820
65	Portal:Society	63,415
66	Wikipedia:Reference desk	55,095
67	Template talk:Did you know	52,856
68	Withypool Stone Circle	50,064
69	Michael Goolaerts	45,856
70	1992	44,359
71	2009	41,091
72	Rif Dimashq offensive (February–April 2018)	40,581
73	Wikipedia:Village pump	38,022
74	Lesser Antillean macaw	37,282
75	Frederick D. Reese	37,031
76	Gustav III of Sweden	36,959
77	Drama dari Krakatau	32,315
78	Samuel Hahnemann	32,202
79	Charter	31,555
80	April 10	30,899
81	Host (biology)	30,205
82	Scribe	29,234
83	Wikipedia:News	25,514
84	Senate of the Republic (Italy)	25,324
85	National Assembly (Hungary)	24,719
86	Kingdom of Strathclyde	24,114
87	Wikipedia:Local Embassy	22,625
88	West Nile virus	21,866
89	1944	21,796
90	April 11	21,714
91	Frank Bainimarama	20,804
92	Un ballo in maschera	16,999
93	2018 Gaza border protests	15,062
94	Rudolf Vrba	14,921
95	Wikipedia:Today's featured article/April 2018	11,380
96	1815	7,559
97	Norman Bel Geddes	7,387
98	Toni Iwobi	7,293
99	President of Fiji	6,376
100	Prime Minister of Fiji	6,210

To give a fair overview, could we please see the above table containing only links that have been on the main page for six month or more? Comparing current movies and events with permanent mainpage links is comparing apples and oranges. --Guy Macon (talk) 23:47, 10 April 2018 (UTC)[reply]

Indeed, every single one of the portals listed in that table is either on the main page or the permanent sidebar. Of course they are going to have massive pageviews. --Izno (talk) 02:49, 11 April 2018 (UTC)[reply]

The top item bolded as a "portal" is Wikipedia:Community portal which is not a portal and not included on this proposal. Legacypac (talk) 04:22, 11 April 2018 (UTC)[reply]

Proposed Bot for tagging BadSVG files.

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

Great idea. Embedding raster graphics in a "scalable" format is pretty pointless and may confuse readers/re-users when they don't scale as expected. -FASTILY 21:51, 8 April 2018 (UTC)[reply]

Remove from watchlist

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

@Peter Flass: "Add direct unwatch/watch links to watchlist entries (JavaScript required for toggle functionality)" in Special:Preferences#mw-prefsection-watchlist. --Izno (talk) 19:00, 9 April 2018 (UTC)[reply]

Also Special:EditWatchlist allows you to edit without going to the pages, and allows for bulk removals if desired. — xaosflux ^Talk 19:01, 9 April 2018 (UTC)[reply]

Thanks, that did it. Peter Flass (talk) 23:18, 9 April 2018 (UTC)[reply]

There's even a big button on the watchlist named "Edit your list of watched pages" :) —TheDJ (talk • contribs) 08:26, 10 April 2018 (UTC)[reply]

Move discussion related to proper use of the Template namespace

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

@@ Line 811: / Line 811: @@
 :To give a fair overview, could we please see the above table containing only links that have been on the main page for six month or more? Comparing current movies and events with permanent mainpage links is comparing apples and oranges. --[[User:Guy Macon|Guy Macon]] ([[User talk:Guy Macon|talk]]) 23:47, 10 April 2018 (UTC)
 ::Indeed, every single one of the portals listed in that table is either on the main page or the permanent sidebar. Of course they are going to have massive pageviews. --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 02:49, 11 April 2018 (UTC)
+:::The top item bolded as a "portal" is [[Wikipedia:Community portal]] which is not a portal and not included on this proposal. [[User:Legacypac|Legacypac]] ([[User talk:Legacypac|talk]]) 04:22, 11 April 2018 (UTC)
 == Proposed Bot for tagging BadSVG files. ==