Wikipedia:Village pump (proposals): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 19:26, 9 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

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]

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]

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. (?) 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]

The auto-classification of importance research results are a bit discouraging. I felt that if ArtAssBot 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 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]

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]

We have one of these for the video game domain. --Izno (talk) 22:45, 8 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]
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]

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]

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]

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]
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)[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]

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]
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,[11] 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 [12] 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]

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]

I may never edit wikipedia again if the deletionist extremists win this proposal.--Broter (talk) 19:05, 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]

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]

@@ Line 474: / Line 474: @@
 * I may never edit wikipedia again if the deletionist extremists win this proposal.--[[User:Broter|Broter]] ([[User talk:Broter|talk]]) 19:05, 9 April 2018 (UTC)
+*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]]--[[User:Broter|Broter]] ([[User talk:Broter|talk]]) 19:26, 9 April 2018 (UTC)
 == Proposed Bot for tagging BadSVG files. ==