2017 Community Wishlist Survey/Bots and gadgets

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search

2017 Community Wishlist Survey

Bots and gadgets
10 proposals, 231 contributors, 328 support votes

Go-previous.svg Anti-harassment  •  Citations Go-next.svg

Here are the 2017 Community Wishlist Survey results!
The voting phase has ended. Thanks for your participation :)


Deploy Article Alerts to other languages

Edit proposal/discussion

  • Problem: Article Alerts is an automated subscription-based news delivery system designed to notify WikiProjects and Taskforces when articles tagged by their banners or placed in their categories enter various formal workflows (such as Articles for Deletion, Requests for Comments, Peer Review, and many more). See WikiProject Physics/Article alerts for example. This is currently an English-Wikipedia exclusive, and is maintained by one user (en:User:Hellknowz), meaning the bus factor leaves the whole project in a fragile state.
  • Who would benefit: Every edition of Wikipedia. For scale, on the English Wikipedia, 1467 WikiProjects and Taskforces subscribed to the Article Alerts system. Virtually every active project is subscribed, and the system is one of the best lines of defense against improper deletions and one of the best ways to advertise ongoing high-level discussions to communities of interest.
  • Proposed solution: Have the WMF / larger Wikimedia community create a more solid and scalable framework for Article Alerts that can also be deployed to all languages. Maybe it's not possible to have something as customizable as the English Wikipedia's implementation, but there are loads of things that could be ported and deployed. (Edit: See en:Wikipedia:Article alerts/Roadmap for a tentative roadmap.)
  • More comments:
  • Phabricator tickets:

Discussion

  • I rank this as one of the most useful watchlist tools on en.wikipedia, and the bus factor worries me, although the code could presumably be shared even as is. However the main barrier to overall global implementation is probably on places like simple.wikipedia where there are no WikiProjects and the category’s are generally incomplete. Therefore it will probably be of more use on Wikipedia language editions with a larger userbase like de.wikipedia. A Den Jentyl Ettien Avel Dysklyver (talk) 15:08, 9 November 2017 (UTC)
To clarify, there is redundancy in code access (two people have it), the problem is that there's only one coder. This makes new features / bug fixes /general maintenance dependent on the will, time, and capabilities of one person. Running the bot on the toolforge would also be great and make the bot more reliable during holidays if there's a power failure and such. The bot clearly is more useful for the larger Wikipedias (certainly all 10 Wikipedias feature on the main landing page would greatly benefit from this), but if a framework can be designed and ported, it wouldn't be a lot of work for dedicated subcommunities on smaller wikis to benefit from this as well even if it's easier to follow every discussion on a smaller Wikipedia. Headbomb (talk) 18:33, 9 November 2017 (UTC)
Not even all larger Wikipedias use WikiProjects, though. It's not only a size thing, but also history (how have we organized) and editing culture. It's probably good for editors to be keenly aware of the fact that if they don't have WikiProjects, the infrastructure for something like this isn't there on their home wiki, and it won't work for them. /Julle (talk) 12:29, 4 December 2017 (UTC)
@Julle: To a point. You don't have to be organized by Wikiproject, you can be organized by categories for instance, or organize via any other grouping of topics. For instance, you could have alerts based on the transclusion of an infobox, such as en:Template:Infobox biography. So even if you don't have a Wikiproject structure in your own wiki, there are still ways this could be used. That's part of what the proposal is. Have the WMF take over, and have a team that's dedicated to making it work for the specific needs of other (non-en:wiki) Wikipedias. Headbomb (talk) 20:20, 4 December 2017 (UTC)
  • I love Article Alerts! It is a great tool that can be used for informing large groups of editors about issues that interest them without annoying others. It is also wonderful for those interested in collecting wiki-statistics. Wikiprojects that have been set up to look after a group of articles can add Article Alerts to the wikiproject with minimal effort, and have the Article Alerts available to anyone who knows where to look for them. There was a good Signpost article about Article Alerts back in 2009.
The en.wiki has thousands of Wikiprojects (the Signpost has many articles about individual wikiprojects). Wikiprojects are a great way for editors to find other editors interested in a certain topic, which can be a great motivator for many. Tools such as Article Alerts help shift the burden of running wikiprojects from human editors to BOTs. This in turn helps retain editors since much of this task is repetitive/tedious and tends to burnout humans.
I am shocked to hear that Article Alerts depends on one individual editor. I hope the Wikimedia Foundation has taken out an enormous life insurance policy on this individual. Ottawahitech (talk) 17:17, 12 November 2017 (UTC) Please ping me
  • I would love WMF to make this as a wiki-compatible configurable tool (at least to English WP for start) rather than an external bot. The benefits are too numerous for me to list, but multiple languages is certainly one of them. This would be much too big of a project for me to do to convert it into an extension or tool labs bot or something of the sort. It's been quite a few years since coding AAB and real life certainly means that one volunteer coder for the project is unfeasible for any serious expansion into other languages or complex workflows and on-wiki features. The code is also pretty atrocious and team-unfriendly now that I can look at it with some 10 years of experience. It was more of a "wow, this sounds like a cool bot I can code" rather than a plan for a community-driven open source tool. The things that would be different/new/incompatible for a tool that directly works with database and/or MediaWiki is again too numerous to list. I can fix and keep the bot running when issues occur, but getting to new features and even bugs is a hurdle that could be abruptly terminated by a bus. —  HELLKNOWZ  ▎TALK  ▎enWiki 23:26, 1 December 2017 (UTC)
  • Don’t underestimate yourself User: Hellknowz (and you too User:Headbomb). The code you wrote ten years ago may not be up to your standards of today, but it is robust and has served Wikipedia’s community well. I worry that the code the WMF staff replaces it with will be inferior in terms of features.
Also I wanted to add a comment about statistics, which are not harvested and put to good use. For example, Alerts of AFD discussions show the number of participants in each deletion discussion when they are displayed on the project(s) page(s). However, no one is capturing this information for statistical purposes as far as I know. Wouldn’t it be nce to know how many articles are deleted overall based on the votes/consensus of one or two people? Ottawahitech (talk) 19:39, 2 December 2017 (UTC) Please ping me
@Ottawahitech: The bot has served the community well, we're well aware of that. I gave a restropective at Wikimania this summer, where WMF devs expressed interest in taking over [assuming it's endorsed on the community survey]. To be frank, the code's status has gotten to a point that whatever new feature we wanted to have, we can't have either because it would blow up the whole bot because of en:spaghetti code, or take too much of Hellknowz' time to implement. Very little has been done on en:WP:AALERTS in over two years. WMF taking over would mean much better integration (e.g. possibly even integrate this with en:WP:Notifications), have much better/reliable performance [we need manual restarts on our personal machines if the bot crashes, if we're busy, that can take a few days before we get to it], and allow other languages to benefit from it. It might have less features at first, but over time they would likely do more, and do it better. Headbomb (talk) 19:51, 2 December 2017 (UTC)

Voting

  • Support Support Tgr (talk) 08:17, 28 November 2017 (UTC)
  • Support Support Dvorapa (talk) 08:33, 28 November 2017 (UTC)
  • Support Support YFdyh000 (talk) 10:23, 28 November 2017 (UTC)
  • Support Support --Liuxinyu970226 (talk) 12:55, 28 November 2017 (UTC)
  • Support Support Sadads (talk) 13:34, 28 November 2017 (UTC)
  • Support Support As proposer. Headbomb (talk) 20:53, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:39, 28 November 2017 (UTC)
  • Support Support Shizhao (talk) 02:53, 29 November 2017 (UTC)
  • Support Support an extremely useful services. Needs further support to survive long-term. --LT910001 (talk) 05:59, 29 November 2017 (UTC)
  • Support Support I'm surprised it doesn't exist elsewhere already. Certainly a useful tool. Tuxipedia (talk) 09:28, 29 November 2017 (UTC)
  • Support Support HighKing (talk) 12:09, 29 November 2017 (UTC)
  • Support Support Absolutely. Dragfyre (talk) 14:46, 29 November 2017 (UTC)
  • Support Support WolreChris (talk) 16:59, 29 November 2017 (UTC)
  • Support Support Article alerts are incredibly important to work that I do on Wikipedia. Expanding and supporting this service is awesome. Megalibrarygirl (talk) 18:38, 29 November 2017 (UTC)
  • Support Support Seb26 (talk) 21:49, 29 November 2017 (UTC)
  • Support Support - Evad37 (talk) 23:11, 29 November 2017 (UTC)
  • Support Support 夢蝶葬花 (talk) 23:11, 29 November 2017 (UTC)
  • Support Support Strong support. Other languages will love this. Recommending especially the Spanish Wikipedia and the German Wikipedia. Mr. Guye (talk) 03:59, 30 November 2017 (UTC)
  • Support Support George Ho (talk) 05:43, 30 November 2017 (UTC)
  • Support Support --L736Etell me 08:09, 30 November 2017 (UTC)
  • Support Support Rlendog (talk) 11:36, 30 November 2017 (UTC)
  • Support Support Danii.3 (talk) 13:08, 30 November 2017 (UTC)
  • Support Support I didn't know this was a thing on en.wikipedia and often wished it existed on fr.wikipedia. Exilexi (talk) 14:46, 30 November 2017 (UTC)
  • Support Support Spinster (talk) 16:49, 30 November 2017 (UTC)
  • Support Support --OrsolyaVirág (talk) 19:38, 30 November 2017 (UTC)
  • Support Support Dromedar61 (talk) 20:39, 30 November 2017 (UTC)
  • Support Support SBaker43 (talk) 00:10, 1 December 2017 (UTC)
  • Support Support Daniel Case (talk) 00:51, 1 December 2017 (UTC)
  • Support SupportAmmarpad (talk) 03:17, 1 December 2017 (UTC)
  • Support Support JAn Dudík (talk) 05:53, 1 December 2017 (UTC)
  • Support Support AndyAndyAndyAlbert (talk) 08:20, 1 December 2017 (UTC)
  • Support Support The reason for keeping an article my be easier to find on another language Hogne (talk) 09:29, 1 December 2017 (UTC)
  • Support Support Balon Greyjoy (talk) 12:04, 1 December 2017 (UTC)
  • Support Support --Superchilum(talk to me!) 16:21, 1 December 2017 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 20:42, 1 December 2017 (UTC)
  • Support Support Xavi Dengra (MESSAGES) 22:54, 1 December 2017 (UTC)
  • Support Support —  HELLKNOWZ  ▎TALK  ▎enWiki 23:03, 1 December 2017 (UTC)
  • Support Support SEMMENDINGER (talk) 00:55, 2 December 2017 (UTC)
  • Support Support I support this, better monitoring for non-English wikipedia would be extremely useful. SunnyBoi (talk) 06:12, 2 December 2017 (UTC)
  • Support Support Bkonrad (talk) 09:49, 2 December 2017 (UTC)
  • Support Support Wostr (talk) 10:37, 2 December 2017 (UTC)
  • Support Support ~Cybularny Speak? 12:16, 2 December 2017 (UTC)
  • Support Support: while I only use a lot for the enwiki Ireland project, I find it great for reviewing proposed deletions that allowed me to save two articles this week alone. I sure other language wikis will find it useful too. Ww2censor (talk) 12:38, 2 December 2017 (UTC)
  • Support Support Wolbo (talk) 12:59, 2 December 2017 (UTC)
  • Support Support SusunW (talk) 14:27, 2 December 2017 (UTC)
  • Support Support Slafayette (talk) 14:31, 2 December 2017 (UTC)
  • Support Support Emir of Wikipedia (talk) 15:30, 2 December 2017 (UTC)
  • Support Support James (talk/contribs) 15:47, 2 December 2017 (UTC)
  • Support Support TheCatalyst31 (talk) 17:03, 2 December 2017 (UTC)
  • Support Support Tacsipacsi (talk) 18:39, 2 December 2017 (UTC)
  • Support Support Ottawahitech (talk) 19:40, 2 December 2017 (UTC) Please ping me
  • Support Support combined with this Doc James (talk · contribs · email) 23:53, 2 December 2017 (UTC)
  • Support Support Jclemens (talk) 02:43, 3 December 2017 (UTC)
  • Support Support. Iazyges (talk) 06:47, 3 December 2017 (UTC)
  • Support Support --Edgars2007 (talk) 12:08, 3 December 2017 (UTC)
  • Support Support Winged Blades of Godric (talk) 16:29, 3 December 2017 (UTC)
  • Support Support ★ Anoop / ಅನೂಪ್ © 18:10, 3 December 2017 (UTC)
  • Support Support Jcc (talk) 19:52, 3 December 2017 (UTC)
  • Support Support This looks promising, I would like it to be configurable per-wiki too. It would be nice to have it as a part of wiki software rather than an external bot. Gryllida 00:35, 4 December 2017 (UTC)
  • Support Support StarryGrandma (talk) 02:58, 4 December 2017 (UTC)
  • Support Support Would be brilliant! ShadessKB (talk) 04:47, 4 December 2017 (UTC)
  • Support Support This is a good idea for any important bots. In particular this is a feature I do use, and it would be a shame to lose it. Graeme Bartlett (talk) 04:51, 4 December 2017 (UTC)
  • Support Support —The preceding unsigned comment was added by Halibutt (talk) 14:22, 4 December 2017 (UTC)
  • Support Support Galobtter (talk) 14:51, 4 December 2017 (UTC)
  • Support Support Davidpar (talk) 15:17, 4 December 2017 (UTC)
  • Support Support vallue (talk) --Vallue (talk) 15:50, 4 December 2017 (UTC)
  • Support Support --Cbyd (talk) 16:51, 4 December 2017 (UTC)
  • Support Support B25es (talk) 17:02, 4 December 2017 (UTC)
  • Support Support —— DePlusJean (talk) 17:47, 4 December 2017 (UTC)
  • Support Support Cedalyon (talk) 19:58, 4 December 2017 (UTC)
  • Support Support Fixer88 (talk) 20:46, 4 December 2017 (UTC)
  • Support Support BlanchardJ (talk) 02:48, 5 December 2017 (UTC)
  • Support Support X:: black ::X (talk) 13:54, 5 December 2017 (UTC)
  • Support Support Alafarge (talk) 18:23, 5 December 2017 (UTC)
  • Support Support Need something that is supported by more than 1 coder. Keith D (talk) 22:49, 5 December 2017 (UTC)
  • Support Support noticed from WOMRED and think this is good enL3X1 ¡‹delayed reaction›¡ 03:31, 6 December 2017 (UTC)
  • Support Support Chicbyaccident (talk) 11:18, 6 December 2017 (UTC)
  • Support Support Couldn't do some of my work without it. So much so that I'm afraid I've rather taken it for granted. Kudpung (talk) 11:26, 6 December 2017 (UTC)
  • Support Support Anthere (talk) 16:17, 6 December 2017 (UTC)
  • Support Support the wub "?!" 00:11, 7 December 2017 (UTC)
  • Support Support Ixocactus (talk) 01:33, 7 December 2017 (UTC)
  • Support Support Muhebbet (talk) 01:57, 7 December 2017 (UTC)
  • Support Support Ahm masum (talk) 08:24, 7 December 2017 (UTC)
  • Support Support Vinegarymass911 (talk) 08:38, 7 December 2017 (UTC)
  • Support Support PamD (talk) 10:18, 7 December 2017 (UTC)
  • Support Support as it is very useful at en.wp. J947 18:44, 7 December 2017 (UTC)
  • Support Support Very useful at times and increasingly valuable as editors dwindle. --Mark viking (talk) 19:56, 7 December 2017 (UTC)
  • Support Support Article alerts are even more valuable for smaller Wikipedias, where there are fewer editors, and their coordination becomes much more important. GregorB (talk) 09:23, 8 December 2017 (UTC)
  • Support Support Richard Nevell (WMUK) (talk) 13:39, 8 December 2017 (UTC)
  • Support Support Jmmuguerza (talk) 20:03, 8 December 2017 (UTC)
  • Support Support The bot is indispensable to what I do. By all means, expand it to other languages! Dolotta (talk) 21:37, 8 December 2017 (UTC)
  • Support Support RandomDSdevel (talk) 01:13, 9 December 2017 (UTC)
  • Support Support Nick Moyes (talk) 09:21, 9 December 2017 (UTC)
  • Support Support I easily see how this will help other projects. I don't at all see how it could negatively affect anyone. R8R (talk) 12:13, 9 December 2017 (UTC)
  • Support Support Ruslik (talk) 13:13, 10 December 2017 (UTC)
  • Support Support Like R8R I can't imagine any negative affects this might have. ----DanTD (talk) 21:43, 10 December 2017 (UTC)
  • Support Support Jack who built the house (talk) 22:22, 10 December 2017 (UTC)
  • Support Support Serhio Magpie (talk) 22:22, 10 December 2017 (UTC)
  • Support Support WikiProjects, as communities of knowledgeable specialists, need all the help they can get. This is very handy for directing users' energies. Choess (talk) 01:15, 11 December 2017 (UTC)
  • Support Support A very useful too that I use daily. IDVtalk 10:44, 11 December 2017 (UTC)
  • Support Support — Luchesar • T/C 13:17, 11 December 2017 (UTC)
  • Support SupportNickK (talk) 13:24, 11 December 2017 (UTC)

Wikidata reference "stated in" from url bot

Edit proposal/discussion

  • Problem: Many Wikidata items with reference urls do not have a "stated in" property. This makes it hard to quickly glance at item references to determine source and potential trustworthiness by seeing a name. Also, makes it harder to potentially run queries that could generate a list of potentially notable items by Wikidata references to create a worklist for edit-a-thon organizers using the query engine.
  • Who would benefit: community and people running workshops
  • Proposed solution: a bot is created that sees a url from P184 on references like www.nytimes.com or huffingtonpost.com and adds a "stated in" of "New York Times" or "Huffington Post".
  • More comments: Beyond this, general improvement of referencing section of Wikidata would assist in credibility building, by encouraging more people to add references.
  • Phabricator tickets:

Discussion

  • Isn't this something that should be proposed at the Wikidata community? And if it is approved there, shouldn't it be handled as a regular community-bot task? Alsee (talk) 06:24, 8 November 2017 (UTC)
I don't know enough about bot development to do it. --LauraHale (talk) 10:49, 9 November 2017 (UTC)
I don't think we have to worry about the bot being too complicated, if it gets approved someone can probably do it. A Den Jentyl Ettien Avel Dysklyver (talk) 14:56, 9 November 2017 (UTC)
This should probably be tackled on Wikidata. Sourcing on Wikidata is currently done in different ways and isn't very consistent.
  1. Get agreement on the best and consistent way to source things.
  2. Inform bot operators of the consensus so they can update their code
  3. Run bot jobs to make existing sources more consistent
  4. Set up regular reports and bot jobs to improve sources.
I think the first step is actually the most difficult one. Feel free to copy this somewhere on Wikidata. Haven't really gotten around to starting this discussion. Multichill (talk) 16:51, 17 November 2017 (UTC)

P184 is doctoral advisor, you probably meant something else. --Tgr (WMF) (talk) 05:55, 18 November 2017 (UTC)

Maybe the property P248 "stated in". --X:: black ::X (talk) 14:08, 5 December 2017 (UTC)
  • I don't understand, whether this question concerns about taxon boxes, i.e. why WikiData is filling automatically empty places there. It Should not. --Höyhens (talk) 12:57, 6 December 2017 (UTC)

Voting

  • Support Support --Liuxinyu970226 (talk) 12:58, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:39, 28 November 2017 (UTC)
  • Support Support MichaelSchoenitzer (talk) 00:11, 29 November 2017 (UTC)
  • Support Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 09:53, 29 November 2017 (UTC)
  • Support Support This is a pro–verifiability proposal. Wikidata is under the Meta-Wiki, I don't think it is a problem proposing this here. Mr. Guye (talk) 04:32, 30 November 2017 (UTC)
  • Oppose Oppose I am very pro–verifiability and enthusiastically support improving references on Wikidata, but in case of this proposal I am not sure what are we talking about. I also do not see how doctoral advisor (P184) property fits into the proposal. End even if this is all explained and clarified than I think it should be proposed at d:Wikidata:Bot requests so volunteers can implement it. This forum should focus on tasks for WFM. --Jarekt (talk) 20:54, 30 November 2017 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 20:43, 1 December 2017 (UTC)
  • Support Support Emir of Wikipedia (talk) 15:55, 2 December 2017 (UTC)
  • Oppose Oppose This is a proposal to the community, not developers. Matěj Suchánek (talk) 21:15, 2 December 2017 (UTC)
  • Neutral Neutral Wikidata references definitely need improving, and bot work in this area would be very useful, but this idea needs some more thought. In particular, it's not appropriate to use 'stated in' here - this kind of case is where a set of reference URL/title/publisher/publication date needs to be added, unless each newspaper article had its own Wikidata item. Thanks. Mike Peel (talk) 22:30, 3 December 2017 (UTC)
  • Support Support RandomDSdevel (talk) 01:15, 9 December 2017 (UTC)
  • Neutral Neutral per Mike Peel — NickK (talk) 13:25, 11 December 2017 (UTC)

Make adding "Wikipedia in the News" easier

Edit proposal/discussion

  • Problem: Wikipedia in the News is currently maintained in two locations: WP:Press coverage master list, and article talk pages with Template:Press. It's done manually with high overhead. It's something of a PITA to add stories so coverage is haphazard.
  • Who would benefit: all editors and journalists
  • Proposed solution: A web-based form for adding 'In the News' events. It automatically adds entries to the appropriate places (talk pages and master lists).
  • More comments: Data could be stored in Wikidata. Modify templates to draw from Wikidata. This will allow truly global 'In the News'
  • Phabricator tickets:
  • Proposer: GreenC (talk) 20:35, 9 November 2017 (UTC)

Discussion

  • You're talking only about enwiki, right ? --Framawiki (talk) 17:57, 17 November 2017 (UTC)
Initially that seems like a good idea, but with the vision if the external links were stored in WikiData there's no reason it couldn't become a global database of Wikipedia in the News, regardless of country or language. -- GreenC (talk) 21:02, 18 November 2017 (UTC)
  • Clarification The votes are trending negative and I don't understand the reasons given (or "reason" since they all cite the same reason). To clarify, a tool (website) is used to enter the "In the News" data into Wikidata, where a bot then automatically distributes the data. For example on Enwiki, it would automatically create the WP:Press coverage master list, and article talk pages with Template:Press. Other project languages might have different methods, but same scenario, a bot would automatically create whatever pages or templates they use, drawing from the centrally located "In the News" database which anyone from any language can update. -- GreenC (talk) 22:14, 2 December 2017 (UTC)
    • I don’t know any reason to store this data in Wikidata. It can be stored on the page where it’s currently stored (w:WP:PRESS), and a bot can distribute it without any fancy tool. This bot can be written by an enwiki bot owner for enwiki. I, as a Hungarian speaker, am not interested in Catalan-language news about Wikipedia, it makes no sense to maintain it internationally. –Tacsipacsi (talk) 09:32, 3 December 2017 (UTC)

Voting

  • Support Support --Liuxinyu970226 (talk) 12:58, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:40, 28 November 2017 (UTC)
  • Oppose Oppose It's just a problem for wp:en. Wp:en can resolve it itself. --Nouill (talk) 00:27, 29 November 2017 (UTC)
  • Oppose Oppose per Nouill. NMaia (talk) 13:04, 29 November 2017 (UTC)
  • Support Support As someone who frequently manually updates the page, I strongly support a simpler way to add items to the list. I also support moving the list to Meta-Wiki in order to encompass press coverage from all Wikimedia projects. Daylen (talk) 01:21, 30 November 2017 (UTC)
  • Oppose Oppose per Nouill. --Superchilum(talk to me!) 16:17, 1 December 2017 (UTC)
  • Oppose Oppose per Nouill Aunva6 (talk) 16:21, 1 December 2017 (UTC)
  • Oppose Oppose per Nouill. -Theklan (talk) 18:32, 1 December 2017 (UTC)
  • Oppose Oppose per Nouill. --Terra  (talk) 06:55, 2 December 2017 (UTC)
  • Oppose Oppose as a fancy tool. Talk pages can be edited by a bot based on the master list. —Tacsipacsi (talk) 18:57, 2 December 2017 (UTC)
  • Oppose Oppose I don't see this as a development priority. Kudpung (talk) 20:23, 6 December 2017 (UTC)
  • BA candidate.svg Weak oppose Involves only Wikipedia, Wikinews, and Wikidata. But this really is a problem. Mr. Guye (talk) 22:46, 7 December 2017 (UTC)
  • Support Support RandomDSdevel (talk) 01:17, 9 December 2017 (UTC)
  • Oppose Oppose, each wiki has its own workflow for press mentions. For example, Ukrainian Wikipedia uses a completely different system (uk:ВП:ППВ) which does not have this problem. In my view it is up to English Wikipedia to find which system to use for press mentions tracking — NickK (talk) 13:29, 11 December 2017 (UTC)

Combined Desktop/Mobile/App-View for the Pageviews Analysis

Edit proposal/discussion

  • Problem:

On of the most common questions when it comes to pageviews analysis is, to compare the percentages of the pageviews from different platforms (mobile, desktop, app). With the current tool this is quite complicated, since the tool is not able to display more than one platform at a time. Therefore a direct graphical comparison is impossible.

  • Who would benefit:

All Readers and Editors interested in pageview-statistics

  • Proposed solution:
  1. Create an additional view, where the bars of all the different platfoms are stacked in one diagram.
  2. Or convert the "platform"-selection menu from a singe select dropdown to multiselect radio buttons, so that it is possible to configure a customized diagram
  • More comments:
  1. I agree with the problem and the benefits of a solution. I'm just not sure that the proposed solution is the optimal one. I'm a newby and I have a newby perspective on everything. FWIW I have some experience in 'Application Portfolio Management' which undoubtedly influences my views. From my perspective, I feel that 'the movement' would be better served (now and in the future) by moving towards a much more consolidated, integrated set of apps (functionally, technically and in terms of user experience) rather than by maintaining/improving/expanding the current large collection of disparate individual gadgets/tools. The current gadgets and tools are difficult to find and use for newbies and are limited in scope and functionality. Today (after hours of searching) I discovered the Wikistats 2.0 Design project. The project currently has a prototype up and running for evaluation and will be released soon. It's the first version and improvements/extensions will surely follow. It seems to me that any solutions to limitations on pageviews/platforms would be better integrated with Wikistats 2.0 or follow-up versions. The benefits would be that Wikimedians have just one app for Analytics on any selection of pages/projects/countries/languages/audiences(editor/reader) and devices. I'm used to working with Google Analytics and I hope that something similar becomes available through Meta-Wiki Just my opinion. If this solution proposal is quick/cheap fix then it may be a worthwhile short-term solution. Otherwise, I think the effort would be better spent on a solution consolidated/integrated with other improvements to Analytics.

Mike Morrell49 (talk) 23:18, 29 November 2017 (UTC)

  • Phabricator tickets:

Discussion

User:West.andrew.g does this for the top 5000 medical articles on a weekly bases.[1] And the overall top 5000 articles.[2] Doc James (talk · contribs · email) 01:54, 5 December 2017 (UTC)

Voting

Make Flow database accessible on Tools Labs

Edit proposal/discussion

  • Problem: Flow is a new extension that totally change user experience about discussions, and technical specifications. One of the important problem of the usage of this extension on Wikimedias wiki is that tools, bots and other programs hosted on Tools labs servers can't access easily to these datas. For example, the web service that provide lots of statistics about users can't deal with Flow edits, that are not take into account.
  • Who would benefit: Users of the many applications hosted on the tools. Many bots and other tools could benefit indirectly from it.
  • Proposed solution: Make Flow database available / accessible on Labs/Tools, so developers can access to these datas and show them to readers.
  • More comments:

Discussion

  • Noting that this is currently blocked by phab:T69397 MusikAnimal (WMF) (talk) 18:35, 17 November 2017 (UTC)
    I've changed this proposition according to this consideration, but I'm not sure that it fits completely within the scope of CommunityWishlist. --Framawiki (talk) 20:44, 17 November 2017 (UTC)

Voting

Turn UTCLiveClock into an extension

Edit proposal/discussion

  • Problem: The UTCLiveClock is one of the most used gadgets across the projects (typically within the top 5). There are 3 problems with it:
    1. It loads after the rest of the page loads, which causes the other links in the user toolbar to shift, often leading to people accidentally clicking the "Log out" link.
    2. Some projects don't have the gadget.
    3. Because it's a gadget rather than a preference, it won't be available as a global preference.
    Turning it into a extension will solve all three of these problems.
  • Who would benefit: All current and future users of UTCLiveClock
  • Proposed solution: Turn it into an extension with its own preference. Migrate people who are using the existing extension.
  • Phabricator tickets:
  • Proposer: Kaldari (talk) 20:01, 8 November 2017 (UTC)

Discussion

  • I added a similar idea to mw:Extension:Purge the other day: https://github.com/Hutchy68/Purge/issues/16 Perhaps the UTCclock and MediaWiki:Gadget-purgetab.js could be combined into one extension? Sam Wilson 00:30, 9 November 2017 (UTC)
  • I have all sorts of things up there in my top bar, which looks like: A Den Jentyl Ettien Avel Dysklyver - Alerts (0) - Notices (0) - Talk - Sandbox - AfDs Closing - Page Curation - AfDs Today - AfDs All - Preferences - Beta - Watchlist - Contributions - Log out - 15:10:00, and they load all at different times over a few seconds, anything to get them to load at the same time would be useful. A Den Jentyl Ettien Avel Dysklyver (talk) 15:13, 9 November 2017 (UTC)
  • It's a bit hacky, but you can use peer gadgets to put in the space with CSS before the JavaScript loads, so that things don't jump around. This is already being done with the UTCLiveClock gadget on English Wikipedia and mediawiki.org. If you wanted to source the gadget as a user script (in global.js, for instance), you'd have to add the necessary CSS as well (e.g. see the bottom of User:MusikAnimal/global.css). But an extension is still better! I think it makes just as much sense to include it as part of Purge, too — MusikAnimal talk 20:17, 9 November 2017 (UTC)
  • I understood that Performance team were working to remove the purge action entirely from MediaWiki. This seems to go against that work? Jdforrester (WMF) (talk) 02:16, 15 November 2017 (UTC)
    That's being tracked in phab:T56902, and seems like it'd be a reasonably complex and lengthy project (that ticket's been open for four years). On the other hand, cleaning up these gadgets would be a pretty easy thing to do (and most of the work has already been done). So I think it's still worth it, even if it's only used for a year or two. Maybe. Happy to be convinced otherwise though! Sam Wilson 06:47, 15 November 2017 (UTC)
    Fair. I'm just uneasy about giving such high profile endorsement (even if we don't think of it that way) to a feature we're already planning to kill… People might feel misled. Jdforrester (WMF) (talk) 20:08, 15 November 2017 (UTC)
    The Performance team is working on making sure that purges are never triggered with GET requests. Getting completely rid of them is more of a long-term aspiration (that would require major changes in our caching and parsing architecture) than something being worked on, I think. --Tgr (WMF) (talk) 06:09, 18 November 2017 (UTC)
  • I agree that we should assume that purging will eventually be deprecated (even though it might take a very long time for that to happen). Thus I would favor implementing this as a separate extension that has purging as an optional feature, rather than turning the UTC clock into an optional feature of the Purge extension. Kaldari (talk) 22:46, 16 November 2017 (UTC)
  • The clock thing is one of those usability train wrecks that have been around so long that we have mostly stopped noticing how bad they are. Using a clock to purge the current page, and then putting it into the personal toolbar, just makes no UX sense whatsoever. As a clock, it has poor usability anyway; the reasonable approach would be something like Google Calendar's world clock where you can set which timezones you want to see (plus maybe integration with timestamps on the page). But I doubt anyone cares about the clock part anyway. The purge link should just live in the page action dropdown. --Tgr (WMF) (talk) 06:09, 18 November 2017 (UTC)
    • @Tgr (WMF): Actually, I only care about the clock part (which I use a lot). I don't even want purging ability. I don't think setting the time zone is needed. I just need UTC time so that I can tell when various on-wiki actions occurred. Kaldari (talk) 18:19, 20 November 2017 (UTC)
  • 1) The visible layout change after page-load was fixed on mediawiki.org. 2) Creating an extension seems overkill for this feature, especially because it seems to bypass the existing project for "Global gadgets" which would solve this. This could become one of the first gadgets to be ported to WikimediaGadgets.git. 3) It is indeed safe to assume the current Gadgets system will not support "Global Preferences" because they are per-wiki (similarly named gadgets could be different things on different wikis). However, it is also safe to assume that this restriction does not apply to global gadgets. As such, if this gadget were a global gadget, it would be trivial to add its preference to the list of global preferences. --Krinkle (talk) 04:33, 21 November 2017 (UTC)

Voting

  • Support Support Rschen7754 19:24, 27 November 2017 (UTC)
  • Oppose Oppose Seems like overkill. As a user of this script, I'm not seeing how this will improve editor productivity over the existing solution. Fix this "problem" properly by giving us global gadgets. MER-C (talk) 01:51, 28 November 2017 (UTC)
  • Support Support This isn't really needed for all MediaWiki sites around the world, let's split it from Core, @MER-C: Okay? --Liuxinyu970226 (talk) 12:54, 28 November 2017 (UTC)
  • Support Support Jc86035 (talk) 14:28, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:38, 28 November 2017 (UTC)
  • Support Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 09:51, 29 November 2017 (UTC)
  • Support Support Djsasso (talk) 11:53, 29 November 2017 (UTC)
  • Support Support Seb26 (talk) 21:50, 29 November 2017 (UTC)
  • Support Support kennethaw88talk 21:05, 30 November 2017 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 20:42, 1 December 2017 (UTC)
  • Oppose Oppose per MER-C. --Terra  (talk) 06:50, 2 December 2017 (UTC)
  • Oppose Oppose It works perfectly well on MediaWiki.org. If it would be converted to an extension, I foresee that it would be impossible to turn it off. When sandbox link became an extension, and I asked for an opt-out (as I have opted the gadget out), I got the answer “use CSS and shut up”. (N.B. I do use UTCLiveClock, but I don’t want to see it as an extension.) —Tacsipacsi (talk) 19:07, 2 December 2017 (UTC)
  • Oppose Oppose per above - "Don't fix what isn't broken". –Davey2010Talk 15:40, 4 December 2017 (UTC)
  • Support Support It is broken. I hate logging my self out by accident. enL3X1 ¡‹delayed reaction›¡ 03:59, 6 December 2017 (UTC)
  • Support Support I haven't encountered the logging out problem, but I can imagine that it's annoying.--Sphilbrick (talk) 14:59, 6 December 2017 (UTC)
  • GA candidate.svg Weak support I have accidentally logged out with it before and allowing all users to Purge pages by default is egalitarian, but I'm concerned about the situation encountered by Tacsipacsi, especially since I'm not very good with CSS. —The preceding unsigned comment was added by Mr. Guye (talk) 22:40, 7 December 2017 (UTC)
  • Support Support Zppix (talk) 20:43, 8 December 2017 (UTC)
  • Support Support RandomDSdevel (talk) 01:05, 9 December 2017 (UTC)
  • Support Support Haxpett (talk) 23:40, 10 December 2017 (UTC)

Convert AWB into a special page

Edit proposal/discussion

  • Problem:
    • Malfunctions
    • No translations
    • Need to download program and install continuous updates
  • Which users are affected?
  • Who would benefit:
    • All program users (including administrators)
  • Proposed solution:
  • More comments:

Discussion

  • @Magioladitis, Reedy, and Rjwilmsi: FYI this proposal. Please help improve the proposal if you can, or give other input on the difficulties that might be involved. Thanks! Quiddity (WMF) (talk) 23:04, 13 November 2017 (UTC)
  • This sounds good, but I worry we don't have enough resources to complete this *rewrite*.--YFdyh000 (talk) 10:17, 28 November 2017 (UTC)
  • I am concerned that this is such a backwater discussion page that very few people who use the program even know of its existence. The voting should reflect the community. The handful of people who have logged in votes here are not representative of the AWB using community. Also, the proposal is so vague as to be almost incomprehensible. Who will be allowed to use it? And who will be making that determination? On Wikipedia, the Wikipedia community decided the restrictions. Will those restrictions still be honored, and how? The Transhumanist (talk) 00:41, 2 December 2017 (UTC)
  • I think en:WP:JWB already takes care of whatever this proposal is supposed to be. Headbomb (talk) 04:03, 3 December 2017 (UTC)
  • It sounds like not everyone will have access to it. It also sounds like it will be starting over, with fewer features. If it will have the same access restrictions as we currently have (anyone with 500 main namespace edits can use it), and will start out with all the same features as the current version of AWB, I would support. Otherwise, it will be a major step backwards. The Transhumanist (talk) 23:27, 1 December 2017 (UTC)
  • Question Question: I'm unclear on the permissions here... Right now anyone can use AWB. Would that change? --Zackmann08 (talk) 02:25, 2 December 2017 (UTC)

Voting

  • Oppose Oppose Sounds bad, it's better to make it as a Portable application than either download-install or on-wiki application. --Liuxinyu970226 (talk) 12:52, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:38, 28 November 2017 (UTC)
  • Support Support Xaris333 (talk) 19:22, 29 November 2017 (UTC)
  • Support Support Luan (discussão) 20:03, 29 November 2017 (UTC)
  • Support Support I like this idea, would make page maintenance easier. Reception123 (talk) 19:30, 30 November 2017 (UTC)
  • Support Support Syced (talk) 15:41, 1 December 2017 (UTC)
  • Support Support --Superchilum(talk to me!) 16:18, 1 December 2017 (UTC)
  • Support Support Honischboy (talk) 21:31, 1 December 2017 (UTC)
  • I do not understand the proposal as written (perhaps someone with native English-language skills could clarify the description for us), but it sounds like the proposal is to convert AWB from a downloadable program (for Windows only) to a web-based interface of some sort. If that is the case, I Support Support the proposal. As a Mac OS user, I have been unable to use AWB, which would enhance my gnome editing significantly. Jonesey95 (talk) 23:37, 1 December 2017 (UTC)
  • GA candidate.svg Weak support I like the idea but I think this proposal needs to be better explained. --Zackmann08 (talk) 19:57, 2 December 2017 (UTC)
  • Support Support in theory, subject to being able to restrict access to those with a user right. This proposal really needs more detail before anyone can make an informed decision, though. ~ Rob13Talk 03:15, 2 December 2017 (UTC)
  • Oppose Oppose What? This proposal is hard to understand. Are you trying to turn the AWB program in to a webpage? Do you plan on it running server side? What about people that use it on non-WMF wikis? Is this a "FORK AWB" proposal? — xaosflux Talk 04:44, 2 December 2017 (UTC)
    Also, who will maintain this? (WMF? Volunteers?) — xaosflux Talk 04:47, 2 December 2017 (UTC)
  • Oppose Oppose per Liuxinyu and Xaosflux. --Terra  (talk) 06:53, 2 December 2017 (UTC)
  • Oppose Oppose as unclear. I'm concerned that the "database scanner" may disappear; I use it with regexes that are far too complex for the MediaWiki search box. I'm concerned that I may lose the ability to configure find+replace rules in a text file; my rules are up to 2.5 megabytes and are sometimes edited with Notepad. -- John of Reading (talk) 08:04, 2 December 2017 (UTC)
  • Oppose Oppose is the proposal trying to make AWB an online tool like twinkle? Simply put: I dont think it would work reliably. Also per TerraCodes, and John of Reading. —usernamekiran(talk) 11:39, 2 December 2017 (UTC)
  • Oppose Oppose, improve the existing tool instead. Currently it’s absolutely possible to internationalize and localize C# programs, and even to run them on *nix systems like macOS and Debian GNU/Linux. —Tacsipacsi (talk) 18:27, 2 December 2017 (UTC)
  • Oppose Oppose - If this is proposing to change AWB into a page then I can't see how it's going to work and as Xaosflux says who's going to run it and keep tabs on it ?, If I have read this right then I don't the point in changing it all at all ..... if I've read it wrong and it's Twinkle or something else related then you've lost me ..... –Davey2010Talk 15:44, 4 December 2017 (UTC)
  • Oppose Oppose - the proposal is too vague. Having fun! Cheers! Checkingfax (talk) 20:27, 4 December 2017 (UTC)
  • Support Support AWB is hard to get started on, and making the onramps a little nicer would help. NessieVL (talk) 18:34, 5 December 2017 (UTC)
  • Oppose Oppose For all of its esoteric and arcane controls and processes and its supposed faults and steep learning curve, AWB is valuable tool. The proposal appears to be based on the assumption that turning it into a special page will somehow remove its problems. There's no reason to suppose that such a translation would deliver the expected benefits. More probably, it would result in a neutered tool with a reduced feature-set.--DavidCane (talk) 21:44, 5 December 2017 (UTC)
  • GA candidate.svg Weak support as this is egalitarian, but the proposal is vague. Mr. Guye (talk) 22:33, 7 December 2017 (UTC)
  • Oppose Oppose per John of Reading and Xaosflux Ronhjones (talk) 16:27, 8 December 2017 (UTC)
  • Support Support This sounds like a wonderful idea! It's always good to see software go cross-platform! RandomDSdevel (talk) 01:07, 9 December 2017 (UTC)
  • Oppose Oppose Per xaosflux SQLQuery me! 04:41, 9 December 2017 (UTC)
  • Support Support Haxpett (talk) 23:42, 10 December 2017 (UTC)
  • Strong Oppose Oppose - AWB give us Modulity. We can add plugin and and can make module according to our requrement. But Wikimedia will allow anyone to upload .dll file into their Server (For Secuirt Resons). And This will destory AWB wide uses. Hence I am oppsing this. And Other thing which is "Same Faciltiy is given by JWB. But you can see major Diff between Both". Thanks-Jayprakash >>> Talk 06:27, 17 December 2017 (UTC)

Fix search in AWB

Edit proposal/discussion

  • Problem: For AutoWikiBrowser it is impossible to make the list using insource with regexp and other keywords. The list has to be done in other complex ways, although in Wikipedia everything works through a simple search.
  • Who would benefit: AWB editors
  • Proposed solution: Improve the search in AWB so that it works with keywords and so that you can pick up a list of what you can get in the search on the site. Would be useful search option in a separate namespace.
  • More comments:
  • Phabricator tickets:

Discussion

insource: does work in AutoWikiBrowser. It used to not work, but version 5.9.0.0 already supports it (and maybe some earlier versions too). —Tacsipacsi (talk) 18:50, 2 December 2017 (UTC)

Why has this proposal not been retracted yet? --bdijkstra (talk) 19:38, 8 December 2017 (UTC)

Voting

Keep maintenance categories and links up to date

Edit proposal/discussion

  • Problem: Changes to MediaWiki code related to parsing can leave links tables out of date. Sometimes code changes will add new tracking categories, typically related to error tracking. But until the page is edited, null edited, or purged with links update, the page will not show up in the category. Some pages do not get edited or refreshed for years, which means that errors in pages will go undetected and unfixed.
  • Who would benefit: Gnomes; WMF developers who want to move to new technologies but need editors to clean up existing pages first; readers who encounter strange page behavior.
  • Proposed solution: Null-edit all unedited pages, or do some equivalent action, on a known periodic basis, perhaps once a month. Publicize the schedule so that it is known that any new template changes or MW code changes may take N weeks to be reflected in all relevant locations on the corresponding MW site.

Discussion

  • In theory that sounds like a great idea, which I support. However, it worries me that that could lengthen the category update time even more, and right now they're SLOW. What can we do to mitigate this risk?--Strainu (talk) 12:31, 7 November 2017 (UTC)
    • The proposal is for the back-end software (MediaWiki itself, or a job queue, or something similar) to null-edit pages that are stale. The proposal, if implemented, would shorten category update times, not lengthen them. Jonesey95 (talk) 23:48, 1 December 2017 (UTC)
  • I like it but who would be responsible for the Null editing/updating the categories you reference? Zppix (talk) 19:37, 7 November 2017 (UTC)
    • The proposal is for the back-end software to null-edit pages that are stale. Jonesey95 (talk) 23:48, 1 December 2017 (UTC)
  • That's a big problem on Commons. In general, most (if not all) pages the categories of which are assigned via templates suffer from that. Right now about 1,400,000+ pages on Commons are not categorised correctly due to that problem. If a category is changed by altering the template a touch on every template-categorised page is necessary to fix the categorisation that else stays pointing to a redirecting page. Another example: Because c:Category:Non-empty disambiguation categories had become completely useless keeping about 8000 empty categories I started many months ago a weekly touch run for to keep it usable. --Achim (talk) 20:24, 8 November 2017 (UTC)
    • I think the issue with c:Category:Non-empty disambiguation categories is that {{PAGESINCAT:... is not considered a dynamic parser function (like e.g. {{CURRENTDAY}}) which would cause the pages to be reparsed regularly. We also don't keep track of links for pagesincat, so we can't purge when someone adds something to a category via job queue. Given this is using {{PAGESINCAT:... for the current category, we probably wouldn't even need to keep track of links, only if the current page is checking how many cats are in itself, so we could probably fix that much easier than purging all pages. BWolff (WMF) (talk) 22:23, 28 November 2017 (UTC)
  • I would support this, but only if the null edit does not appear in edit history's, and happens at a long schedule, something like monthly or yearly runs, repeating, with all articles spread over the month/year to avoid server load. A Den Jentyl Ettien Avel Dysklyver (talk) 14:51, 9 November 2017 (UTC)
    • Null edits never appear in page histories. Jonesey95 (talk) 23:48, 1 December 2017 (UTC)
  • null edit can be done using pywikibot's touch.py. But this is solution only for smaller wikis, ~100k pages takes ca 10 hours. JAn Dudík (talk) 11:54, 10 November 2017 (UTC)
  • I think it would be useful to add touch capability to AutoWikiBrouwser, as proposed in phabricator:T167283, so there is more than one way to touch pages. --Jarekt (talk) 19:36, 15 November 2017 (UTC)
  • I'm doubtful how practical this is for all pages on large wikis. I have no idea how long such a reparse would take. It wouldn't surprise me if we're talking months to run through all pages. Maybe even years. BWolff (WMF) (talk) 22:23, 28 November 2017 (UTC)
    • The first step in implementing this proposal would be to investigate a few different methods for doing this refresh and assessing their practicality. The status quo is that some pages never get updated, so even "years" would be an improvement, but I think we can get it down into the "months" or even "weeks" range with some clever work. Jonesey95 (talk) 23:48, 1 December 2017 (UTC)

Voting

Commons deletion notification bot

Edit proposal/discussion

  • Problem: When images that are used in a Wikipedia article are put up for deletion on Commons, the Wikiproject or article associated with those images are not notified.
  • Who would benefit: The Wikiprojects may have connections with the uploading institution and thus able to get permission or may be able to find a substitute for the image being deleted. Either way it will improve collaboration between WP and Commons.
  • Proposed solution: Add links to these Commons discussions to the Article Alerts for Wikiprojects and / or the article talk page
  • More comments:

Discussion

Supposedly there is something on Fr WP that does this.[3] Doc James (talk · contribs · email) 21:49, 13 November 2017 (UTC)

  • @Doc James: Hi. (1) I suggest you tweak this proposal to be more focused on individual uploaders, and less focused on WikiProjects which don't exist (or work in consistent ways) in many language Wikipedias and sibling projects. (2) See also 2016 wishlist...#Automatic notification of page creators when page is nominated for deletion, and the more positive 2016 wishlist...#Notifications for when your image is used for related ideas & discussions from last year. :) Quiddity (WMF) (talk) 00:10, 14 November 2017 (UTC)
    • Sure the bot could also notify the individual account that uploaded it and put a note on the talk page of the article that will be affected. Doc James (talk · contribs · email) 00:15, 14 November 2017 (UTC)
      • A notice on the talk page of the article (where the file is used) would be really nice. The notice can be uniform, but it should use prepared translations (f. e. German translation for German wikiprojects). --Vachovec1 (talk) 20:56, 14 November 2017 (UTC)
      • @Doc James: Please update the actual proposal wording above, so that when voting begins, people can get the clear summary from just reading the summary. (This discussion section might be collapsed when the voting starts, as it was last year. This section is primarily for us to discuss improvements to the proposal wording, before the voting starts.) Thanks! Quiddity (WMF) (talk) 21:51, 16 November 2017 (UTC)

Happened to notice this discussion right after I posted about the same thing at w:Wikipedia:Village pump (idea lab)#Notification system for files on Commons nominated for deletion. If there's enough support for it then I'm happy to tackle this task -FASTILY 23:46, 16 November 2017 (UTC)

Daniel Kinzler's bot CommonsTicker did that a long time ago, but fell into disrepair. --Tgr (WMF) (talk) 05:50, 18 November 2017 (UTC)

phab:T91192 may be an alternative. Jo-Jo Eumerus (talk, contributions) 10:10, 26 November 2017 (UTC)

For article Alerts, as they currently exist, you'll have to talk to en:User:Hellknowz and make a Features Request for Article Alerts. However, see this Article alerts-related proposal. A dedicated bot putting notices on talk pages could be handled at en:WP:BOTREQ. Headbomb (talk) 04:38, 29 November 2017 (UTC)

  • Note that there is currently a discussion about this exact issue at the Englosh Wikiversity, so this idea is certainly wanted. Also note that at the English Wikiversity it was being discussed independently from this suggestion so this bot should be created, and I agree that the talk pages of the affected pages are the best target. --Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 13:08, 1 December 2017 (UTC)
I made the proposal on Wikiversity, which was a response to a problem: Users trust Commons content, use it, and years later someone finds (or imagines) a copyright problem and the Commons file is deleted, then Commons Delinker comes and removes the link. At that point, all the file information from Commons is now deleted. (Really, that information should never be deleted even if the image itself is removed). The original user may be long gone. So content is damaged and fixing it can be time-consuming, creating a possibly unnecessary maintenance cost). We could go to Commons and ask an admin for a copy of the file, but that's cumbersome and not actually legal, if the copyright failure was real. However, if the file is hosted on Commons, there is no doubt that we can legally copy it to Wikiversity. We just don't do it because it seems unnecessary. Later, if the file is deleted from Commons, our own copy could be tagged, if appropriate, for fair use (or deleted if fair use is not appropriate, whatever it takes to satisfy the EDP requirements -- but Wikiversity tends to have liberal fair use practice.) So the proposal was to copy all WV-used Commons content to Wikiversity, by local bot. However, if Commons would notify Wikiversity of pending deletions, for all files used on Wikiversity, we wouldn't need that dual hosting. The NonFreeWiki proposal would be far more efficient if it were simply a filespace on Commons, where used files were moved. That's basically a no-cost solution. --Abd (talk) 14:48, 1 December 2017 (UTC)

Voting