Community Wishlist Survey 2016/Categories/Bots and gadgets

Community Wishlist Survey 2016

Bots and gadgets

13 proposals, 289 contributors, 428 support votes

Admins and stewards  •  Citations

Import Wikidata text for disambiguation pages

• Problem: Curating, maintaining, and creating disambiguation pages is a massive chore. Comprehensive disambiguation pages for more popular names/topics take hours of combing through Wikipedia's search results and flipping back and forth among tabs to complete birth and death information. It feels pointless and it's tiring (anyone's who's done it would probably agree) and as a result many disambiguation pages are incomplete and out of date, therefore not serving their function. Wikidata has all the data needed to help editors maintain and update disambiguation pages more easily, and is easily manipulated to autocomplete them, with minimal editor interaction.

N

• Who would benefit: Editors who care about completeness of disambiguation pages, and readers who use them for disambiguation (and are currently not getting that).

• Proposed solution: Off the top of my head, gadget that takes input from editor on what to compile (e.g. articles that start with the name Sarah, people with the surname Rodriguez), then pulls the article title, birth and death information (if appropriate), and short description (e.g. Australian actress, Australian town). Fictional characters are kept separate. Geolocation data can assist with "places called Sarah" sections. The details can then be checked, cleaned up, and false-positives pulled by the editor before saving. An added bonus is that the editor will be able to see what's missing in Wikidata, and add it there (it would feel far less pointless to fill this in on Wikidata than to repeat it endlessly for dozens and dozens of disambiguation pages).

• More comments: There may be a better, streamlined alternative to disambiguation pages, but in the meantime since that's what we have, they should be appropriately maintained. N.b. I welcome iterations and improvements on this idea!

• Phabricator tickets: Couldn't find any related.

• Proposer: Julia\^talk 17:31, 20 November 2016 (UTC)

• Translations: none yet

Community discussion

• I wrote a proposal for using Wikidata to create disambiguation pages several years ago, but it was turned down. The idea is pretty simple, but it is not quite so simple as it seems. There are actually several different types of pages. One is a page that has some entries locally, and then additional entries for homonyms. They consists of both homographs words with the same spelling, that is "the Wikidata problem", and homophones words with the same pronunciation, that is "the Wikipedia problem". The homographs will be both aliases and labels on Wikidata. Then there are homophones which isn't so easy to find by automatic means. Perhaps it is possible to rewrite the existing labels and aliases, but it is possible to use the IPA strings. It is also an additional problem with the relation between homographs and homophones. A homograph might have several homophones, and all should be listed on a disambiguation page. Note that different languages have different sets of homophones for the same homograph. An additional problem is what to do with strings that has no entry on the site. One possibility is to try to do a lookup on Wikidata with the existing string, looking for any similar entries, and then rebuilding the list as a disambiguation page. This creates a problem for homophones. — Jeblad 18:47, 21 November 2016 (UTC)
  • I personally think this would be very useful for smaller wiki's. Perhaps analogous to the Article placeholder extension ? Another option is to add some Wikidata capabilities to the Disambiguation extension.. —TheDJ (talk • contribs) 15:43, 23 November 2016 (UTC)
• Great idea. I suggested something similar a few years ago at the bottom of Concise Wikipedia#A summary of existing short-options, using an example. Quiddity (talk) 23:50, 24 November 2016 (UTC)
• I remember seeing a tool (was that en:User:Dispenser/Dab solver?) that can comb through the ledes of all articles that can potentially be linked from a given dab page and come up with a decent-looking list of entries (complete with years of birth and date, if these are present in the articles). Uanfala (talk) 23:59, 11 December 2016 (UTC)

• I think a more generic approach might be better. We now have Datasets, which allow storing .tab tables on Commons. There might be some work done by @Smalyshev (WMF): to automate copying data from Wikidata to the .tab page using SPARQL. I think the most versatile solution would be to add a template, e.g. {{Disambig FirstName|Sarah}} to the talk page "Data:Disambig/Sarah" on Commons, that would create a SPARQL query to gets all the needed wikidata items. The bot, without knowing anything about first names or any other disambig-specific logic, would simply execute the SPARQL query and copy all available data to that .tab page. Then, it would be enough to place another template like {{Create Disambig Firstname List|Sarah on the Sarah page, and the Lua code would create all the information based on the data. Lastly, because .tab pages are localized, they can be used from all wikis without any extra work.

Why is this, seemingly more complex path is better? Because everyone in the community is in full control of the whole process, instead of just a few bot runners, and because it would take minutes to update/fix/change something. Anyone could change the SPARQL template to produce slightly different dataset. Anyone can alter the Lua code to format that data differently, or create new types of disambig templates.

Voting – Import Wikidata text for disambiguation pages

1.  Support JAn Dudík (talk) 21:34, 28 November 2016 (UTC)
2. Neutral I might support this for the generation of starter disambiguation pages in some circumstances (especially in small to medium wikis), but frankly, I would prefer that this largely stay in the realm of manual editing work. There's just too much at play for reliable automated maintenance. Sometimes, we humans just have to do the work. Stevie is the man! ^{Talk • Work} 23:53, 28 November 2016 (UTC)

   A tool like this doesn't need to fully replace disambiguation to be useful. It could be added to current DABs as a way for users to find content that exists but was not manually added yet. Diego Moya (talk) 10:33, 29 November 2016 (UTC)

   If it works as suggestions and not actual changes to the page, then that seems reasonable. Stevie is the man! ^{Talk • Work} 17:57, 30 November 2016 (UTC)

3. Neutral I think this is possible a little later down the road without additional work when Wikidata can support wiki-embedded lists. --Izno (talk) 00:29, 29 November 2016 (UTC)
4.  Support — Jeblad 01:31, 29 November 2016 (UTC)
5.  Support - This is similar to what is already done with the tags "Search all articles starting with..." and "Search all articles containing...", which are often added to the See also section of disambiguation pages. Diego Moya (talk) 10:33, 29 November 2016 (UTC)
6.  Support - I can imagine a tool similar to creator_from_wikidata by User:Magnus Manske that creates text for disambiguation page based on Wikidata data. Users would be encouraged to modify the wikitext as they see fit, or merge it with current disambiguation page, but the basic facts will come from wikidata. --Jarekt (talk) 17:27, 29 November 2016 (UTC)
7.  Support I do that manually, and I sometimes feel like wasting time. Trizek ^{from FR} 17:51, 30 November 2016 (UTC)
8.  Support --Mess (talk) 18:34, 30 November 2016 (UTC)
9.  Support --Coffins (talk) 15:52, 1 December 2016 (UTC)
10.  Support --Sander.v.Ginkel (talk) 17:43, 1 December 2016 (UTC)
11.  Support --Gerwoman (talk) 18:01, 1 December 2016 (UTC)
12.  Support Libcub (talk) 02:19, 2 December 2016 (UTC)
13.  Support Seems useful. Draceane (talk) 09:42, 2 December 2016 (UTC)
14.  Support--Kiril Simeonovski (talk) 13:13, 2 December 2016 (UTC)
15.  Support--Sannita - not just another it.wiki sysop 14:03, 2 December 2016 (UTC)
16.  Support - but with caution. It should be possible to query Wikidata to do this, but I'm not sure that the basics are in place for this yet. In particular, how will variations in names / use of language be identified? But it would be worth investigating this approach sooner rather than later. Thanks. Mike Peel (talk) 23:39, 2 December 2016 (UTC)
17.  Support--Ranjithsiji (talk) 03:20, 4 December 2016 (UTC)
18.  Support DPdH (talk) 13:29, 6 December 2016 (UTC)
19.  Support Muhraz (talk) 15:41, 6 December 2016 (UTC)
20.  Support, might be implemented as a set of Wikidata query functions either if possible, but it's a useful functionality anyway — NickK (talk) 15:33, 7 December 2016 (UTC)
21.  Support ArgonSim (talk) 17:27, 7 December 2016 (UTC)
22.  Support Miniapolis 19:54, 8 December 2016 (UTC)
23.  Support --Fixer88 (talk) 20:53, 8 December 2016 (UTC)
24. Neutral conditional support provided that User:Stevietheman's concerns, which I share, are taken into consideration. --Waldir (talk) 09:40, 10 December 2016 (UTC)
25.  Oppose I think this sounds like a good idea in principle but I am concerned it would cause too many errors and require too much manual rework. Wikidata has too many problems with missing information and data validation already so I don't think Wikidata is capable of doing this yet but maybe in a couple more years. Reguyla (talk) 18:24, 10 December 2016 (UTC)
26.  Support This will take a bit of tinkering about until it's functional, but the technical capability has to be in place first. Uanfala (talk) 23:59, 11 December 2016 (UTC)
27.  Support Investigation into this at least, per my comment above. Quiddity (talk) 04:30, 12 December 2016 (UTC)
28.  Support KSFT (talk) 22:04, 12 December 2016 (UTC)

New User Landing Page - Article Creation Workflow

• Problem: en.Wiki receives around 850 or more new pages every 24 hours of which up to half are not suitable for publication. New users are unaware of what kind of articles are acceptable for Wikipedia or are unaware of the inclusion criteria before they start creating. New Page Reviewers are too few to contain the influx of inappropriate pages and to render basic assistance to new, good faith creators of articles.

• Who would benefit: (cross-Wiki application, core software extension). Above all, the new users whose first attempts at editing are to create a new article. Other benefits are to those who maintain the processes for deleting inappropriate pages and/or offering basic help and advice to such users. Such a landing page would greatly reduce the need for answering the Why was my page deleted? questions, and processing AfD discussions. The serious backlogs at AfC and New Page Review would also be sigificantly reduced.

• Proposed solution: Resume the development of Article Creation Flow, a WMF project that was begun as a solution to the WP:ACTRIAL project they denied despite an overwhelmingly large community consensus.. The purpose was provide succinct but comprehensive information before the users commenced creation, and to channel all new articles by first time new users through the w:WP:Article Wizard to be reviewed at WP:Articles for Creation or WP:Page Curation before being published in mainspace.

Article Creation Flow was to be the 'other half' of the overall Page Curation project of which the principle objectives are to:

1. Keep the Wikipedia free of spam and paid advocacy (Foundation policy), vandalism pages, hoaxes, and copyright violations.
2. To reduce - or even prevent - the loss of new users bitten by deletions of good faith articles with potential, but which at the time of creation do not immediately meet criteria for inclusion in mainspace.

• Phabricator tickets: phab:T156442

• Proposer: Kudpung (talk) 23:43, 13 November 2016 (UTC)

• Translations: none yet

Community discussion

While I don't disagree with the proposal, I wouldn't have titled it "New user landing page". That title might better be applied to this other proposal, over in the Miscellaneous section. Not all new accounts start by trying to create a new article - I remember reading somewhere that only around a quarter of them do. The other three-quarters could with advantage be told some basics when they register their account, as some of us tried to argue here last year Noyster (talk) 13:02, 14 November 2016 (UTC)

I thought users needed to have some edits under their belt before they could create a new page. In any case, i think this has merit for the first, say, three new pages created to direct through a confirmation page and have review before publication. The delay in publication has down sides for more complicated edits that involve redirects, splitting topics or see also hatnotes. Bcharles (talk) 16:41, 15 November 2016 (UTC)

Unfortunately, any registered user on en.Wiki can create a page directly in mainspace with their very first edit, and many do; that 's why it's important to understand why the community already reached an overwhelming consensus for w:WP:ACTRIAL which was not rolled out by the community in anticipation of the Foundation's promise to deliver the new Landing Page. Kudpung (talk) 16:53, 15 November 2016 (UTC)

because it violates a pillar, and was a notfix by jorm. go whine at him. i see english got its revenge with AfC. seriously, we desperately need a real on boarding process, and a cadre of welcomers to engage with newbies. i do not see any sign of a willingness to change the bitey culture. flow is necessary but not sufficient, needs part 2 - teahouse like welcomers. Slowking4 (talk) 15:09, 16 November 2016 (UTC)

Slowking4, neither the Landing Page nor the ACTRIAL constitute a violation of a pillar. The Foundation had already previously introduced other measures to restrict he creation of articles in mainspace, thus proving that Wikipedia is organic and changes can, and will need to be introduced as the project grows too big to be managed by a tiny handful of willing, voluntary maintenance workers. The irony is, that it was Jorm himself who began developing the excellent new Landing Page, but due to a reshuffle of jobs in the WMF, the project somehow got abandoned. Kudpung (talk) 22:46, 24 November 2016 (UTC)

i guess we will just disagree about the meaning of AGF, or "anyone can edit". i want no part of the bitey culture. i spend all my time at editathons routing newbies around all your gates. you want to be a gatekeeper, go for it. the sooner you go for pending changes, and filters, the sooner you will end up like wikinews. Slowking4 (talk) 22:54, 24 November 2016 (UTC)

en:WP:AFC is broken, has been for years, as contributions almost always languish for weeks before a volunteer gets around to even looking at them. If anything, the trend has been toward raising the bar to discourage "unqualified reviewers", which has only increased the backlog. If I'm a random anon-IP with articles waiting in WP:AFC for the last half-month, I can create an account or two right now and post them all into mainspace as my very first edits - or I can leave them to languish for another week or more. If you want volunteers to review every new article, how do you intend to recruit these volunteers? Unless that question can be addressed, I don't see a purely-technical solution here. K7L (talk) 16:58, 19 November 2016 (UTC)

Absolutely, K7l. The solution is to better inform new users before they even begin to create an article which, like 50% (or more) of new articles may have a high risk of being consigned to the trash can. This would significantly reduce the workload of those few users who are in the predicament of handling a 14,000 page backlog. Kudpung (talk) 22:46, 24 November 2016 (UTC)

what do you mean by "inform"? yet more tl;dr policy page in edit preview? yet more tutorial screens? more hoops to jump through? if you have no welcomers, you have no solution. Slowking4 (talk) 22:56, 24 November 2016 (UTC)

Slowking4 one of the very issues with the current Article Wizard is that most of it is tl;dr. It was developed at a time when there was a low participation of non native speakers. These users now make up a significant number of the articles made by new users. You appear to have missed the point of this piece of software that was begun by the WMF. In contrast to the concerns you have voiced, it is designed to do exactly the opposite. It involves also on the registration page asking a very low number of very simple questions with some bright big buttons to press so that the user will be left in no doubt whatsoever what they can and cannot do on Wkipedia, and where they can get the best help and advice. Currently, around 90% of all new pages created by new users will never be of a kind that are appropriate for an encyclopedia and are rapidly deleted. Kudpung (talk) 02:00, 6 December 2016 (UTC)

hey- i am all for improved AfC. however, without training and welcoming it will not work. part 1- resurrect flow; part 2- train and lead a teahouse-like welcome. 1 without 2 = good luck, have a nice day. we will continue to route around this fubar. Slowking4 (talk) 22:12, 6 December 2016 (UTC)

Though there may be some difficulties with the transition, removing underl-qualified users will greatly help the workflow: first, because it take an inordinate amount of time to detect and correct their many errors. Second, because many qualified people don't participate because they see their work being swamped in a mass of bad workmanship.--good people don't usually like to participate in a project where most of the people are doing it wrong? DGG (talk) 08:52, 20 November 2016 (UTC)

• This must focus not only wikipedia, also Wiktionary needs an article creation wizard and other wikis too. Please consider this scope challenge when designing the new tool. --Gryllida 23:30, 1 December 2016 (UTC)
• Perhaps check out Dialog facilities on one of our wikis, they may be useful for building the article creation tools on any wiki. --Gryllida 23:30, 1 December 2016 (UTC)

Voting – New User Landing Page - Article Creation Workflow

1.  Support--Shizhao (talk) 02:32, 28 November 2016 (UTC)
2.  Support Johnuniq (talk) 21:51, 28 November 2016 (UTC)
3.  Support After reading the above discussion, I was expecting some kind of horror show when looking at Article Creation Flow. However, as I was reviewing the designs, I was pleasantly surprised at the friendly yet serious approach that didn't feel bitey at all. Surely, if people are coming here to write an encyclopedia, they shouldn't be at all surprised that we take this process seriously if not professionally. I think these interfaces would do far more to assure users than "bite" them. The only caveat is that I think a community should decide a reasonable threshold for successful article creations or overall edits for users not to have to go through these flows. Obviously, experienced editors by this determination should be able to directly create an article as it works now. Stevie is the man! ^{Talk • Work} 00:29, 29 November 2016 (UTC)
4.  Support --Izno (talk) 00:34, 29 November 2016 (UTC)
5.  Support · · · Peter (Southwood) ^(talk): 07:16, 29 November 2016 (UTC)
6.  Support --Telaneo (User talk page) 21:23, 29 November 2016 (UTC)
7. Minor  Oppose Page Curation seems somewhat not friendly to me, see phab:T50552. --Liuxinyu970226 (talk) 11:28, 30 November 2016 (UTC)
8.  Support --Micru (talk) 12:28, 30 November 2016 (UTC)
9.  Support After many vain trials on my wiki, we need to have something solid and configurable. Trizek ^{from FR} 17:52, 30 November 2016 (UTC)
10.  Support KylieTastic (talk) 20:40, 30 November 2016 (UTC)
11.  Support Gryllida 23:29, 1 December 2016 (UTC)
12.  Support--Kiril Simeonovski (talk) 13:45, 2 December 2016 (UTC)
13.  Support --Framawiki (talk) 20:12, 2 December 2016 (UTC)
14.  Support --Ranjithsiji (talk) 03:20, 4 December 2016 (UTC)
15.  Support --JustAGuyOnWikipedia JustAGuyOnWikipedia (talk) 19:20, 5 December 2016 (UTC)
16. Neutral I support the principle, but I think that the proposal at 2016 Community Wishlist Survey/Categories/Miscellaneous#Ask new users to disclose paid editing is a more focused and practical way to achieve the same outcome. --Tryptofish (talk) 21:51, 5 December 2016 (UTC)

    Tryptofish, paid editing, while scandalous and must be addressed with the strongest methods possible, does not account for the majority of undesirable new pages. Most are company listings by people who just don't understand that WP is not LinkedIn, autobios of non notable people,garage bands, , and a miscellany of gibberish, no content/context, hoaxes, attack pages, and vandalism. There is currently neither admin nor patroller capacity to address all these pages as they arrive and all attempts to rally more people to page patrolling have failed. Also, most ostensibly paid editors do not disclose their affiliation even when asked. Kudpung (talk) 02:12, 6 December 2016 (UTC)

    Those are good points. Thanks for the ping. --Tryptofish (talk) 02:17, 6 December 2016 (UTC)

17.  Support—English Wikivoyage currently uses "article creation template" links in voy:MediaWiki:Newarticletext, but having a flow the forced selection of a template, provided some text entry fields to help populate standard values, and also explained what subjects do and do not merit a standalone article would be a great improvement that would help new users and reduce the confusion when creating new articles. -- Ryan • (talk) • 04:33, 6 December 2016 (UTC)
18.  Support DPdH (talk) 12:59, 6 December 2016 (UTC)
19.  Support Muhraz (talk) 15:42, 6 December 2016 (UTC)
20.  Support Dan Koehl (talk) 20:58, 6 December 2016 (UTC)
21.  Support, while it is rare for a new user to create a page on en-wiki, it is far more common on other languages. Preferably a new addition needs to have a voluntary opt-out. CFCF💌 📧 20:25, 7 December 2016 (UTC)
22.  Support Miniapolis 20:35, 8 December 2016 (UTC)
23. Neutral I'd be all for a strictly optional workflow support tool for creating new articles - a sort of WikiClippy ;) It makes sense to provide basic guidance on the mechanics of article creation to new editors, many of whom attempt to create a new article among their earliest edits. (This is a common pattern in editathons, for example, and on enwiki we routinely see these new editors' work tagged for deletion when the event hasn't been well-publicized in the community.) However, this proposal seems to be something of a camel's nose in the tent for a rerun of ACTRIAL. The desire to use it to restrict new article creation by newer editors by requiring them to use the tool is already reflected in some of the support comments above. Opabinia regalis (talk) 06:41, 9 December 2016 (UTC)

    Opabinia regalis this is an extremely bad faith assumption - the people voting here have the best interest of Wikipedia at heart. That said, there will be no 're-run' of ACTRIAL; the consensus was so vast that if the community wants it they will just go ahead and do it. The mistake in 2011 was asking the WMF to do it as a MediaWiki extension, and believing the arguments they made against it which turned out later to be completely invalid. Since then we have grown hair on our teeth. This current proposal is all about avoiding ACTRIAL and introducing some sanity into the influx of new article and helping those who don't know any better from being discouraged. Kudpung (talk) 12:43, 11 December 2016 (UTC)

24.  Support --TanvirH (talk) 20:33, 10 December 2016 (UTC)
25.  Support - Meiloorun (talk) 06:59, 11 December 2016 (UTC)
26.  Support Ramaksoud2000 (talk) 07:01, 11 December 2016 (UTC)
27.  Support Mz7 (talk) 07:05, 11 December 2016 (UTC)
28.  Support --Satdeep Gill (talk) 07:06, 11 December 2016 (UTC)
29.  Support Chris Troutman (talk) 07:10, 11 December 2016 (UTC)
30.  Support – GSS (talk) 09:26, 11 December 2016 (UTC)
31.  Support—We need to welcome and advise potential new editors with a truly excellent landing page. PamD (talk) 09:53, 11 December 2016 (UTC)
32.  Support Jcc (talk) 10:18, 11 December 2016 (UTC)
33.  Support - A very good suggestion, helpful for both new editors and reviewers Xyzspaniel (talk) 11:46, 11 December 2016 (UTC)
34.  Support Anarchyte (work | talk) 11:46, 11 December 2016 (UTC)
35.  Support Onel5969 ^{TT me} 12:46, 11 December 2016 (UTC)
36.  Support Spike789 (talk) 12:49, 11 December 2016 (UTC)
37.  Support -- samtar ^{talk or stalk} 13:07, 11 December 2016 (UTC)
38.  Support TonyBallioni (talk) 13:40, 11 December 2016 (UTC)
39.  Support SarahSV ^talk 15:24, 11 December 2016 (UTC)
40.  Support Highest priority --Joe Decker (talk) 15:33, 11 December 2016 (UTC)
41.  Support --Elmidae (talk) 17:32, 11 December 2016 (UTC)
42.  Strong support - anything that helps funnel new article ceation theorugh the creation wizard has to be a major improvement. Velella (talk) 18:08, 11 December 2016 (UTC)
43.  Support HitroMilanese (talk) 18:10, 11 December 2016 (UTC)
44.  Support  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:11, 11 December 2016 (UTC)
45.  Support Support, any feature that prevents blatant violations of policy from being published in the first place should reduce the new page review workload. LoudLizard (talk) 20:50, 11 December 2016 (UTC)
46.  Support Anna Frodesiak (talk) 20:55, 11 December 2016 (UTC)
47.  Support Insertcleverphrasehere (talk) 21:01, 11 December 2016 (UTC)
48.  Support FoCuSandLeArN (talk) 21:44, 11 December 2016 (UTC)
49.  Support DGG (talk) 01:02, 12 December 2016 (UTC)
50.  Support Esquivalience (talk) 01:37, 12 December 2016 (UTC)
51.  Support RexxS (talk) 02:03, 12 December 2016 (UTC)
52.  Support – it's not exactly what I'm after, but it's a start... IJBall (talk) 02:10, 12 December 2016 (UTC)
53.  Support, mostly because I trust the people who are in favor of this approach. Dank (talk) 02:24, 12 December 2016 (UTC)
54.  Support Jbh^Talk 03:17, 12 December 2016 (UTC)
55.  Support Could be very useful if we get something that works well for wikis of all sizes. Quiddity (talk) 04:34, 12 December 2016 (UTC)
56.  Support -- numbermaniac 05:59, 12 December 2016 (UTC)
57.  Support Darylgolden (talk) 13:24, 12 December 2016 (UTC)
58.  Strong support - as proposer and on behalf of all the experienced users who have to hack away at the daily avalanche of unmitigated rubbish and placate the new users whose articles have been irresponsibly tagged by inexperienced self-appointed patrollers. Kudpung (talk) 06:26, 12 December 2016 (UTC)
59.  Support MrX (talk) 14:37, 12 December 2016 (UTC)
60.  Support This would greatly brighten the mood of the task queue and show appreciation for the volunteers who perform this function. Efficient volunteers are happy volunteers and that leads to a better Wikipedia for new users. Blue Rasberry (talk) 15:20, 12 December 2016 (UTC)
61.  Support --Bonadea (talk) 15:27, 12 December 2016 (UTC)
62.  Support BethNaught (talk) 15:59, 12 December 2016 (UTC)
63.  Support PGWG (talk) 16:01, 12 December 2016 (UTC)
64.  Support Highest possible priority. BU Rob13 (talk) 16:21, 12 December 2016 (UTC)
65.  Weak support This would be good if it facilitates rather than trying to obstruct. For example, we had a very successful editathon recently with lots of new women editing about women. Initially, we had problems because of a technical limit on the number of new accounts created at an IP address. This is a major headache for editathons and is a "gotcha" that can bring things to a halt. The editors were then advised to work in their sandbox but that's more like a sandtrap because it steers new editors towards AfC, which is usually quite unhelpful. For an example of this, please see the talk page of Dawn Bonfield, sometime president and chief exec of the Women's Engineering Society. She was trying to create her first article and got spammed by unhelpful AfC templates. Until I got there, noone even thought to give a welcome message. So, more help and less hinder, please. Andrew D. (talk) 19:07, 12 December 2016 (UTC)
66.  Support--Mikheil ^Talk 20:55, 12 December 2016 (UTC)

Quarry maintenance

• Problem: For many months there is an unsolved problem running queries via Quarry. The engine slows down due to queries that seem to be running (though they don't run in fact) or are queued for many weeks or even months without being handled as killed.

• Who would benefit: All Quarry users

• Proposed solution: Until the underlying problem is solved a bot should run once a week that kills queries which are "running" for more than 30 minutes and restarts queued queries.

• More comments: It's annoying if one does queries that under normal conditions run 20 or 25 minutes but are killed because of exceeding the 30 minutes limit.

• Phabricator tickets: phab:T71176, phab:T111779, phab:T133738, phab:T137517, phab:T139162

• See also: mw:Topic:T8ip24a3iragdqrh, mw:Topic:T6sxf1vjyj5shf9e, mw:Topic:Sxnjylmzlh3qojyk, mw:Topic:Sufgjpuvqiqt9q3s, mw:Topic:T1cf94hz5kdsk83j

• Proposer: Achim (talk) 11:08, 12 November 2016 (UTC)

• Translations: none yet

Community discussion

Ping for @Yuvipanda -FASTILY 20:31, 13 November 2016 (UTC)

• Big fan of Quarry tool, but I never noticed the issue mentioned above. I would support any quarry maintenance efforts if they are needed. --Jarekt (talk) 13:31, 16 November 2016 (UTC)
• Quarry is the best Wikimedia related tool/software ever. It has a lot of missing features though and almost not being developed at all --Ilya (talk) 22:23, 19 November 2016 (UTC)

Voting – Quarry maintenance

1.  Support--Wesalius (talk) 06:12, 28 November 2016 (UTC)
2.  Support Matěj Suchánek (talk) 21:43, 28 November 2016 (UTC)
3.  Support --Snaevar (talk) 22:54, 28 November 2016 (UTC)
4.  Support Quarry maintenance as needed, but did not notice the specific stated problem . --Jarekt (talk) 17:30, 29 November 2016 (UTC)
5.  Support --Mess (talk) 18:33, 30 November 2016 (UTC)
6.  Support--Kiril Simeonovski (talk) 13:47, 2 December 2016 (UTC)
7.  Support someone helping Yuvi. I'm sure he'll appreciate an extra hand or two. Multichill (talk) 14:03, 2 December 2016 (UTC)
8.  Support --Ilya (talk) 21:16, 2 December 2016 (UTC)
9.  Support --Ranjithsiji (talk) 03:21, 4 December 2016 (UTC)
10.  Support quarry is an important tool; it's job handling needs improvement. Huji (talk) 19:40, 5 December 2016 (UTC)
11. Neutral It's not clear to me that Quarry is that widely used at all projects. --Tryptofish (talk) 21:54, 5 December 2016 (UTC)
12. Neutral I don't see the pressing issue. Task can be killed by hand? --Hedwig in Washington (talk) 01:49, 6 December 2016 (UTC)
13.  Support - I am not WikiTechnology savvy, but I work on key issues that frequently require the kind of stats that need to be drawn from the SQL. I don't know how to do it my self and I have to rely on the people who can write the scripts that get the results. I don't know such stats were obtained in previous years, but one, now retired, user could get me anything I wanted although it would sometimes take many hours for the computer to do its work. It looks to me that more server capacity is required for this tool. Kudpung (talk) 02:18, 6 December 2016 (UTC)
14.  Support Muhraz (talk) 15:33, 6 December 2016 (UTC)
15.  Support --Jnanaranjan sahu (talk) 21:15, 6 December 2016 (UTC)
16.  Support — NickK (talk) 16:48, 7 December 2016 (UTC)
17.  Support Miniapolis 20:37, 8 December 2016 (UTC)
18.  Support —Godsy (talk • contribs) 20:43, 9 December 2016 (UTC)
19.  Support --OrsolyaVirág (talk) 11:38, 10 December 2016 (UTC)
20.  Support Great idea. Reguyla (talk) 18:10, 10 December 2016 (UTC)
21.  Support --TanvirH (talk) 20:33, 10 December 2016 (UTC)
22.  Support --Plagiat (talk) 17:06, 11 December 2016 (UTC)
23.  Support I'd like to see more help and hardware given to the current maintainer/developer(s). Quiddity (talk) 04:37, 12 December 2016 (UTC)
24.  Support ONUnicorn (talk) 16:23, 12 December 2016 (UTC)

Web-based AutoWikiBrowser alternative

• Problem:

AutoWikiBrowser is a huge success, helping people make millions upon millions of semi-automated edits, making repetitive tasks so much easier to accomplish. However it has lots of problems:

• It is a desktop app, so
  • It's Windows only
  • It requires installation (including dependency as cumbersome as .NET framework)
  • It requires updates
  • It can't follow you across devices
• It was created without localization in mind so making its interface support multiple languages would amount to a rewrite
• While it's written in a language that is reasonably popular, it's less popular among open source developers and overall less popular than modern web stack languages. As a result, it never had enough developers.
• Very early on, it had cosmetic "general fixes" introduced to it, that now generate lots of unnecessary controversy, slow down page processing and drain developer time on supporting them.

• Who would benefit: power users, potentially expanding reach to "simple mortals"

• Proposed solution:

Create a web-based replacement for AWB. Having a web app would also allow users to contribute on mobile platforms (phones and tablets) where typing is hard, but clicking "Save"/"Reject" is something people can do while commuting to work, for example.

Proposed implementation: I envision a site on Tool Labs that hosts a mostly-JS AWB that does editing. The backend would only authenticate users (OAuth), store settings and editing lists, and collect statistics. Most of JS code can be made reusable in Node.js for use by fully-automated bot developers.

• More comments: Full disclosure: the proposer is a former AWB developer.

• Phabricator tickets: phab:T157271

• Proposer: Max Semenik (talk) 23:28, 8 November 2016 (UTC)

• Translations: none yet

Community discussion

• FYI: on ptwiki, I created a gadget inspired by the part of AWB which allows search and replace, to fix common problems in the articles. It has a set of rules and users can define their own rules on their personal js pages. See mw-gadget-APC and pt:WP:APC. Helder 12:48, 9 November 2016 (UTC)
• Statement: I believe this is a good idea. Comment: AWB is use(d|ful) on projects other than Wikimedia wikis. A Tool Labs implementation restricts usage to Wikimedia wiki users. --Izno (talk) 21:11, 9 November 2016 (UTC)
• Good idea. I am unable to use AWB for technical reasons, so I use AutoEd, but it lacks many of the features that would allow me to fix many more minor problems with WP articles. A web-based AWB or AWB-like tool would be excellent. Jonesey95 (talk) 06:09, 10 November 2016 (UTC)
• Good idea. I moved to a chrome book a few years back, and about my only consistent regret is not being able to run AWB. Sadads (talk) 12:31, 10 November 2016 (UTC)
• I also moved to a chromebook for a few years and missed AWB terribly. Also I often log in on other machines and it would be great to have this available websideAntiqueight (talk) 15:05, 10 November 2016 (UTC)
• Good idea. Consider two levels of features:easy for newbies on the learning curve, and advanced for seasoned editors.--Dthomsen8 (talk) 15:12, 10 November 2016 (UTC)
• Good idea Gbawden (talk) 17:28, 10 November 2016 (UTC)
• I really wish to see this comes true.--AddisWang (talk) 20:20, 10 November 2016 (UTC)
• I have often wondered about using AWB; it looks as if it could be most useful, but not being a Windows user keeps me from even trying it. Jerryobject (talk) 21:20, 10 November 2016 (UTC)
• Good idea. Sometimes I am not able to run AWB on my computer, so I would want to use the web version. I support this proposal. Yoshi24517 (talk) 04:06, 11 November 2016 (UTC)
• Great Idea. AWB on Toollab is a fantastic thing. We can leverage all modern technologies like Angular JS. If we can create a chrome extension based on that then that also will be great. Also we can try a desktop version based on Atom Framework called electron. I am also planning for this. If any github repo then definitely ready to contribute. Also I think that there is some limitation for a gadget kind of thing may be --Ranjithsiji (talk) 09:53, 12 November 2016 (UTC)
• Good idea. There appears to be a surprisingly high percentage of regular maintenance volunteers (on en.Wiki at least), who are deprived of the use of AWB because they prefer to use expensive Apple computers. --Kudpung (talk) 10:47, 13 November 2016 (UTC)
• Using a tool as powerful as AWB shouldn't be too easy. It should require a user having to jump through a few hoops of technical understanding. Thus, this makes me a bit queasy about a web-based version. However, it may make sense to port the app to another popular personal computer platform. Stevie is the man! ^{Talk • Work} 15:41, 13 November 2016 (UTC)
  • @Stevietheman: I would expect that the tool would have a similar permissions group (or the same permissions group) as AWB as is implemented right now. Sadads (talk) 02:07, 16 November 2016 (UTC)
• We already have en:User:Joeytje50/JWB, which checks for AWB permissions. Not sure if it covers everything Max wants, but it should be a good starting point.--Strainu (talk) 08:23, 16 November 2016 (UTC)
  • @Strainu: It's a little broken; the regex replacement doesn't work, which is quite annoying for anything involving more than template substitution. Jc86035 (talk) 11:10, 16 November 2016 (UTC)
    • I just installed Javascript Wiki Browser (JWB) and started using it today. Easy to figure out for anyone familiar with AWB. Works great for me and I have yet to run into any limitations for performing simple, routine tasks. Community Tech shouldn't have to reinvent the wheel; this task should be framed as a request to fix any bugs in JWB or add new features to it. -- Wbm1058 (talk) 22:13, 29 November 2016 (UTC)
• Big fan of AutoWikiBrowser with 3M bot edits to prove it. On commons we have VisualFileChange Tool, written by no longer active User:Rillke, which is able to do many tasks of AWB, but in browser. For example regexp based find and replace in large number of files or prepend/append text. VisualFileChange can only do a fraction of things AWB can, but it is very convenient, especially since you can save multiple "profiles" with your favorite replacement rules. Writing "official" tools that merge capabilities of VisualFileChange and AWB would be great. --Jarekt (talk) 13:11, 16 November 2016 (UTC)
• As a mostly Linux user, I am unable to take advantage of AWB. Fully support a cross-platform solution. --Arianit (talk) 10:50, 17 November 2016 (UTC)
• I'dlove tohave it. I've even though of switching to windows—thought it would be only for WP—in order to use AWB. DGG (talk) 08:46, 20 November 2016 (UTC)
• I bought a Windows PC a year ago partly because it would enable me to use AWB. AWB is a great tool, but needs to be cross platform. I would like to go back to chrome or lynux. It would also be good if you could have one click "safe paging" so as to exclude false positives from specific queries. WereSpielChequers (talk) 12:57, 21 November 2016 (UTC)
• Be among the first editors to become members of en:Category:Wikipedians who use Javascript Wiki Browser ! Wbm1058 (talk) 02:39, 30 November 2016 (UTC)
• @Stevietheman and Wbm1058: Vote as you wish... but for the purposes of the survey you may assume WMF is capable of implementing it without it getting in the way of other work. This may not actually be true, but what I'm getting at is the technical evaluation, triaging, etc., is all done after the survey. Here we are solely interested in what you'd like to see happen – regardless of how or when :) MusikAnimal (WMF) (talk) 21:34, 2 December 2016 (UTC)

  So yes, I like the idea of a "Web-based AutoWikiBrowser alternative", but it seems to me like we already have that in the form of en:WP:JWB (apparently one of the best-kept secrets of the project). So at this point, I'm confused about what we're actually voting for. It would be like people voting to implement watchlists, because they didn't know there was any such implementation. Now I don't know about all of its capabilities, but I'm sure that the traditional Windows-based AWB has a few nifty capabilities that I haven't discovered yet, as well! Wbm1058 (talk) 22:11, 2 December 2016 (UTC)

  My 'neutral' goes further than that. I don't want the original AWB developers' work being disrupted by spending time consulting on the new project. The original AWB needs to continue to improve and prosper. Stevie is the man! ^{Talk • Work} 18:10, 4 December 2016 (UTC)

  If JWB does what we want and is manageable, support here means it gets official backing from WMF and we'll continue to maintain and improve it. You can also assume progress of the current AWB will not be hindered :) MusikAnimal (WMF) (talk) 03:14, 5 December 2016 (UTC)

  MusikAnimal (WMF) I think JWB a very good start and it does a good job of copying some of the functionality of the existing AWB which is both a good and a bad thing. The good part is we are familiar with it but it's bad in that the layout for AWB isn't great itself and could be improved as well. And I say that as a big fan of AWB and a major user of it. What I would like to see is the WMF being more active in supporting it as well, which in the past they didn't seem interested in. If they do not want to support AWB, then I find it very surprising and a bit disappointing that they would be interesting in JWB. The only answer I can come up with is that it's because it's a Java based app and it's more fun and interesting to develop. The two apps also do not need to be mirror images of each other in function or in design, but it would be a horrible shame if the AWB app were abandoned just because the WMF decided to favor JWB instead. JWB or any other app will require some major changes from site to site in order to be used where AWB will function on nearly all wiki's including custom ones and Wikia. JWB nor any other java replacement does not and cannot do that. Reguyla (talk) 15:17, 12 December 2016 (UTC)

Voting – Web-based AutoWikiBrowser

1.  Support--Wesalius (talk) 06:12, 28 November 2016 (UTC)
2.  Support Makes sense. Samwalton9 (talk) 09:02, 28 November 2016 (UTC)
3.  Support Léna (talk) 11:07, 28 November 2016 (UTC)
4.  Support Ninovolador (talk) 11:27, 28 November 2016 (UTC)
5.  Support Very good idea. Jules78120 (talk) 12:50, 28 November 2016 (UTC)
6.  Support Facenapalm (talk) 14:01, 28 November 2016 (UTC)
7.  Support Sadads (talk) 14:55, 28 November 2016 (UTC)
8.  Support Silraks (talk) 16:38, 28 November 2016 (UTC)
9.  Support Nocowardsoulismine (talk) 17:53, 28 November 2016 (UTC)
10.  Support as a proposer. Max Semenik (talk) 18:27, 28 November 2016 (UTC)
11.  Support MichaelMaggs (talk) 19:49, 28 November 2016 (UTC)
12. Neutral I understand the desire for greater access to AWB's capabilities, but the development scope seems too tremendous for this survey. This is a very complicated toolset. I wouldn't want the development of this snuffing out a multitude of badly needed smaller projects. Stevie is the man! ^{Talk • Work} 20:41, 28 November 2016 (UTC)

    I would also add that the AWB team might be expected to assist with the development of any new AWB. As a loyal and loving user of this excellent tool, I would rather they spend that time improving the existing AWB, as there are many good suggestions in Phabricator awaiting development. I don't want these improvements bogged down. Stevie is the man! ^{Talk • Work} 00:50, 29 November 2016 (UTC)

13.  Support without the implementation-specific details; "cross-platform AWB" seems like a sensible goal. That said, I agree with Stevie's reserverations re "smaller projects". --Izno (talk) 23:40, 28 November 2016 (UTC)
14.  Support IKhitron (talk) 12:04, 29 November 2016 (UTC)
15.  Support I bought a windows laptop a year ago in order to use AWB and have made more than 10,000 AWB edits since then. I would love to free myself from windows but still be able to use AWB. WereSpielChequers (talk) 12:28, 29 November 2016 (UTC)
16.  Support Arian ^Talk 13:07, 29 November 2016 (UTC)
17.  Support as an AWB user at fawiki. Mahdy Saffar (talk) 13:18, 29 November 2016 (UTC)
18.  Support AWB is great but PC platform only is an issue. Also I think Web version can be be written in such a way so we can more easily share and collaborate on standard solutions to standard problems. It can also more easily interacts with other tools. I do not believe it can totally replace AWB, so we should aim for a tool with large capability overlap. Tricky thing might be that different people use AWB for different purposes and care mostly for narrow range of features. Most important features for me might be different than for other people. For example I use it a lot for data scraping from large number of pages. --Jarekt (talk) 17:47, 29 November 2016 (UTC)
19.  Support Guycn2 · ☎ 17:48, 29 November 2016 (UTC)
20.  Support Ivi104 (talk) 20:15, 29 November 2016 (UTC)
21.  Support --Nikola (talk) 21:54, 29 November 2016 (UTC)
22.  Oppose if this means assigning a team of several community tech developers to develop a new tool from scratch. Support if this means having Community Tech take over support for Javascript Wiki Browser (JWB). As en:User:Joeytje50 is active, I would defer to them. Start by asking them if they need or desire help supporting this. -- Wbm1058 (talk) 22:13, 29 November 2016 (UTC)
23.  Support This would have been immensely useful for my bot work during a period of time when my main computer was down. BU Rob13 (talk) 05:38, 30 November 2016 (UTC)
24.  Support --Mess (talk) 18:39, 30 November 2016 (UTC)
25.  Support--AddisWang (talk) 22:51, 30 November 2016 (UTC)
26.  Support cross-platform or web-based AWB. 4nn1l2 (talk) 13:04, 1 December 2016 (UTC)
27.  Support Ahm masum (talk) 17:00, 1 December 2016 (UTC)
28.  Support --Elisardojm (talk) 18:16, 1 December 2016 (UTC)
29.  Support --JB82 (talk) 01:11, 2 December 2016 (UTC)
30.  Support —Jc86035 (talk) 11:07, 2 December 2016 (UTC)
31.  Support--Kiril Simeonovski (talk) 13:48, 2 December 2016 (UTC)
32.  Support--Sannita - not just another it.wiki sysop 14:04, 2 December 2016 (UTC)
33.  Support --Lam-ang (talk) 16:08, 2 December 2016 (UTC)
34.  Support--George Animal (talk) 16:14, 2 December 2016 (UTC)
35.  Support. Matiia (talk) 23:23, 2 December 2016 (UTC)
36.  Support--SBaker43 (talk) 00:23, 3 December 2016 (UTC)
37.  Support Demostene119 (talk) 18:06, 3 December 2016 (UTC)
38. Worried Comment. This is mostly a sociological problem, not a technological problem. AWB already exists, and is a fairly robust project-team, but the devs are using C# as their language and thus the windows desktop is their only easily-achieved target platform. JWB already exists, in client-side Javascript, but the dev isn't involved with AWB the windows app, and is not always available on-wiki (as opposed to on-wikia). VisualFileChange already exists, not sure what programming language, but is again a completely separate project, and the original dev is no longer involved. It would be a mistake to have the WMF devs create some new *fourth* project, using a completely separate infrastructure, and a new programming language, and different devs. That will just add to the problems, not help solve the problem. What MAY help, is if the WMF can offer some intra-project assistance, to help nudge all the small competing projects towards a common set of core libraries and services which they can all depend on (programming-language-neutral to the degree possible), and a common set of QA harnesses and test-suites... with the ultimate goal that, rather than having a bunch of projects run by small groups re-inventing the wheel, we end up with one reasonably unified project team, working mostly on the same goals (if not necessarily all using the same programming language). Methinks the goal here should be, not for WMF devs to 'take over' this feature-space, with Yet Another Incompatible Project, but rather for the WMF devs to help the existing people working in this feature-space unify where unification makes sense, and build the shared infrastructure to keep the remaining diverse portions fairly compatible. 47.222.203.135 20:44, 3 December 2016 (UTC)

    +1 -- "VisualFileChange"? What's that? Wbm1058 (talk) 17:44, 4 December 2016 (UTC)

39.  Support Eagerly waiting for this --Ranjithsiji (talk) 03:23, 4 December 2016 (UTC)
40.  Support --By erdo can (talk) 14:31, 4 December 2016 (UTC)
41.  Oppose per SteveTheMan and Wbm--Dixtosa (talk) 15:38, 4 December 2016 (UTC)
42. Neutral Not a high priority issue right now. Wold take a lot of manpower away from things that really are important. I think the devs should decide if they WANT to take a shot at this. @Wbm1058: -> Commons:Help:VisualFileChange.js. --Hedwig in Washington (talk) 01:59, 6 December 2016 (UTC)
43.  Support where a cross platform facility for the process can be seen to be inclusive of parts of the community who cannot otherwise facilitate an important management tool, any other aspects such as resource allocation or prioritizing may indeed leave it down the list, so as long as it doesnt cause grief, it seems a valid exercise :JarrahTree (talk) 08:12, 6 December 2016 (UTC)
44.  Support As an AWB user myself, I strongly support this. Muhraz (talk) 15:34, 6 December 2016 (UTC)
45.  Support Is this technically possible with a reasonable budget? I think the user demand is evident by the long history of AWB use. Blue Rasberry (talk) 18:43, 6 December 2016 (UTC)
46.  Support Movses (talk) 21:14, 6 December 2016 (UTC)
47.  Support JWB seems a potentially good basis, but "officially" adopting it, and making sure it can work on any MediaWiki wiki seem important steps to take. --Yodin^T 03:23, 7 December 2016 (UTC)
48.  Support — NickK (talk) 16:49, 7 December 2016 (UTC)
49.  Support ArgonSim (talk) 17:36, 7 December 2016 (UTC)
50.  Oppose Likely to be slower and would take time from developing actually useful tools. CFCF💌 📧 20:29, 7 December 2016 (UTC)
51.  Support --Dirk Beetstra ^{T C} (en: U, T) 08:37, 8 December 2016 (UTC)
52.  Oppose This already exists. Pppery (talk) 17:58, 8 December 2016 (UTC)
53.  Support Miniapolis 20:40, 8 December 2016 (UTC)
54.  Support --Arnd (talk) 13:31, 9 December 2016 (UTC)
55.  Support YES!! I fully support Jarekt's words. I agree with Wbm1058 that this should be implemented by enhancing the existing Javascript Wiki Browser, and moving it to a proper platform enabling collaborative development, issue tracking, etc. --Waldir (talk) 10:07, 10 December 2016 (UTC)
56. Neutral I support this however I would like to see the WMF give more support to the client version of AWB as well. JWB already exists and is a good app but it requires quite a bit of changes between sites in order to work. This seems like an opportunity where the WMF wants to do it because its cool, interesting and web based but they never really wanted to support AWB at all. AWB can be easily tailored to work with other sites like Wikia and custom sites where a Java based one will require significant rework for each site. Additionally, with the increasingly heavy bandwidth requirements of the WMF sites, I already have problems with loading it sometimes and others do as well so continuing to have the client version of AWB would be a great benefit. Reguyla (talk) 18:16, 10 December 2016 (UTC)
57.  Support --TanvirH (talk) 20:34, 10 December 2016 (UTC)
58.  Support --Alaspada (Talk) 04:18, 11 December 2016 (UTC)
59.  Support Giorgos ab1234 (talk) 13:04, 11 December 2016 (UTC)
60.  Support --Plagiat (talk) 17:09, 11 December 2016 (UTC)
61.  Support Double-extra YES. I haven't used AWB in years because it's a Windows-specific tool. If not web-based, at least port it to (or make comparable tool for) X so it can run on Unix, Linux, and Mac OS X.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:14, 11 December 2016 (UTC)
62.  Support The only reason I'm not using AWB is that it doesn't run on Linux. Uanfala (talk) 00:01, 12 December 2016 (UTC)
63.  Support DGG (talk) 01:33, 12 December 2016 (UTC)
64.  Support--Mikheil ^Talk 20:56, 12 December 2016 (UTC)

Auto-congratulatory feature across all Wikimedia projects

• Problem: Many Wikimedia projects are small communities with a few dedicated contributors. We often congratulate fellow members on editing achievements manually, yet there are occasions when we probably forget and thus fail in our minimum courtesy. We would like to avoid it.

• Who would benefit: Dedicated Wikimedia community contributors.

• Proposed solution: We need a bot(s) on Wikimedia projects which will automatically congratulate (1) Users on completion of every 500 edits & (2) Users on reaching an editing milestone of every 50,000 bytes.

• More comments: Urdu Wikipedia Facebook group post

• Phabricator tickets:

• Proposer: Muzammil (talk) 15:28, 20 November 2016 (UTC)

• Translations: none yet

Community discussion

• Urdu village pump discussion to this effect

• Muzammil: There's been some work on a feature that would basically do this: phab:T124003. I don't know if it's feasible, but maybe you could edit this proposal to make sure individual wikis (not just Urdu Wikipedia – that will not get a lot of votes) can get something like this and set when they want it to congratulate editors? /Johan (WMF) (talk) 19:08, 21 November 2016 (UTC)

• Johan: We have no problem if a similar system is in place for all Wikimedia projects. I've made the above request with this update on Phabricator as well. --Muzammil (talk) 17:56, 22 November 2016 (UTC)

  Muzammil: I would also recommend you rephrase the proposal so that it doesn't say Urdu Wikipedia anymore but talks about wikis in general – you'll have a much better chance of getting votes from other projects that way. I could do it, but it's your proposal, so better if you edit so it's the way you like it. (: /Johan (WMF) (talk) 17:59, 22 November 2016 (UTC)

  Done--Muzammil (talk) 18:08, 22 November 2016 (UTC)

  Thanks. (: /Johan (WMF) (talk) 12:19, 25 November 2016 (UTC)

Voting – Cross-wiki auto-congratulatory feature

1.  Support more community-controllable notifications, would be super useful for many different languages, and applications—all of which could increase collaboration, Sadads (talk) 14:57, 28 November 2016 (UTC)
2.  Support cool idea that's probably relatively easy to implement and would also motivate users. The potential problem with it is that people might more or less cheat their way to such congratulations etc. by e.g. making multiple edits while one would have sufficed or add much content just to remove it again later but I don't think this would actually be a noticeable problem (especially not when it's just talk page congratulations) - it could also be awards or alike - w:gamification is good and often underestimated. --Fixuture (talk) 21:02, 28 November 2016 (UTC)
3.  Support I've recently been doing a lot on Quora, there are several features there that are auto congratulatory and we miss a trick by not having them here. But the congratulations need to be meaningful, as well as how many edits you've done also we need articles you have added content to were read by nnnnnn people last month. WereSpielChequers (talk) 12:33, 29 November 2016 (UTC)
4.  Support--مھتاب احمد (talk) 02:52, 2 December 2016 (UTC)
5.  Oppose The problem with auto-congratulation is that no-one gets a nice feeling inside when a robot congratulates them. When we have automated congrats, manual congratulations go out of fashion, and so the net effect is negative. We also don't want to encourage Wikimedia to be viewed as an MMO. BU Rob13 (talk) 05:39, 30 November 2016 (UTC)
6.  Oppose if this is about talk page messages. It's unclear at present. If it's notification-style, like phab:T124003 mentioned by Johan, then I would support. Julia\^talk 22:17, 30 November 2016 (UTC)
7.  Oppose agree with BU Rob13, this would be a damaging change. --Gryllida 23:25, 1 December 2016 (UTC)
8. Strong oppose per BU Rob12. NMaia (talk) 01:50, 2 December 2016 (UTC)
9.  Oppose Net negative. -FASTILY 06:58, 2 December 2016 (UTC)
10.  Oppose --Ganímedes (talk) 13:05, 2 December 2016 (UTC)
11.  Oppose I do not think that leaving congratulatory messages motivates someone to continue editing nor I think that doing it automatically with a bot is a good idea.--Kiril Simeonovski (talk) 13:51, 2 December 2016 (UTC)
12.  Support Daylen (talk) 20:35, 2 December 2016 (UTC)
13.  Oppose I get that we are trying to make everyone feel loved, but a robot giving you a sticker feels hollow. In fact, it might make you even more depressed when you realize the only person who has praised you is made up of 1s and 0s. -- Kndimov (talk) 00:10, 3 December 2016 (UTC)
14. Neutral It is not necessary to make a robot for stickers. But notifications like "You made 100000 edits" are good --Ranjithsiji (talk) 03:26, 4 December 2016 (UTC)
15.  Oppose per BU Rob13. Stevie is the man! ^{Talk • Work} 18:15, 4 December 2016 (UTC)
16.  Oppose --Andropov (talk) 17:29, 5 December 2016 (UTC) Damage possible also in my opinion.
17.  Oppose Too impersonal. --Tryptofish (talk) 21:56, 5 December 2016 (UTC)
18.  Support as a notification, but not a talkpage message. Milestones are motivating to some people, and cause no harm to others. Per w:en:Wikipedia:Userboxes/Wikipedia/Personal statistics some people like statistics! Quiddity (talk) 01:20, 6 December 2016 (UTC)
19.  Oppose Lack of personal touch would be the utmost problem of this proposal. Muhraz (talk) 15:35, 6 December 2016 (UTC)
20.  Oppose The thing that makes congratulations and thanks important is that they are personal. An impersonal message from a machine is pointless. --Carnildo (talk) 02:38, 7 December 2016 (UTC)
21.  Oppose I tend to thank people for edits to articles. I appreciate it when others thank me, because it means I did well in someone's eyes. This proposal seems not a heartfelt appreciation but a mechanical construct to manipulate.Jacqke (talk) 04:46, 7 December 2016 (UTC)
22. Neutral I may not get what this wish asks for but congratulating for milestones already works. Matěj Suchánek (talk) 15:30, 7 December 2016 (UTC)
23. Neutral I could maybe see a badge system working, but I highly doubt that automatic "congratulations for your nth edit!!!" messages would serve any purpose other than spam. ArgonSim (talk) 18:06, 7 December 2016 (UTC)
24.  Oppose Some wiki's actively discourage this sort of notification. So automatically doing it would be bad. -Djsasso (talk) 18:15, 7 December 2016 (UTC)
25.  Oppose Terrible idea. The whole point of congratulating someone is the personal attention. Espresso Addict (talk) 05:36, 8 December 2016 (UTC)
26.  Support Miniapolis 20:42, 8 December 2016 (UTC)
27. Neutral, with sanity check. This would need to be site-configurable, and also scale. I often do 500 edits in under one month. 500 might be a good milestone for a noob, but not a long-term, active editor.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:05, 11 December 2016 (UTC)
28.  Support FoCuSandLeArN (talk) 22:55, 11 December 2016 (UTC)
29.  Support As a concept, though not in all aspects. As others have pointed out, I also do over 500 edits in a month on a fairly regular basis, so after awhile it would become annoying. Montanabw (talk) 04:57, 12 December 2016 (UTC)
30.  Oppose. Not all edits are useful edits. I came across a user some time ago who had made a total of nearly 1,000 edits to their user page and to a totally fictitious article on a user draft, and not a single edit to any other namespace. An interesting proposal, but very low priority. Kudpung (talk) 06:12, 12 December 2016 (UTC)
31.  Oppose as encouraging editcountitis. BethNaught (talk) 16:01, 12 December 2016 (UTC)

Automatic links to Internet Archive

• Problem: Web pages disappear and we are left with broken links. Adding a permanent link is more work for editors.

• Who would benefit: Editors that use web-based references, users that want to verify claims that use web pages as references, and users that want to learn more about a subject.

• Proposed solution: Do the following:

1. Automatically add a link to the corresponding page in Internet Archive if an url and an access-date is provided in a cite.
2. Automatically add access-date to cites, if they are not provided, when an edition is saved.
3. Automatically request archival of web pages in Internet Archive if they are not available there.

• Phabricator tickets: T153354

• Proposer: Aracali (talk) 16:32, 12 November 2016 (UTC)

• Translations: español

Community discussion

I have a few questions/concerns:

• If an editor adds a URL citation & one exists in web.archive.org, presumably we could mine the latter for the most recent archived URL, the archive date (contained in the web.archive.org URL, just would need to be parsed), & set |deadurl=no. Question: would this be done real time by a script, or after the fact via a bot?
• If a URL was not archived at web.archive.org when an editor placed a citation, would a script or bot then make a request to have it archived & then set a timer to later obtain the archived info?
• If an existing citation without archive information was discovered by a bot, then with the bot query web.archive.org to see if the URL existed there?

• If that URL was not archived at web.archive.org, would bot then make a request to have it archived & then set a timer to later obtain the archived info?
• If that URL did exist at web.archive.org, what would be the criteria to select the archived URL? If it's the most recent, the check must be done to ensure that a 404 error or the like was not archived, because this frequently happens at web.archive.org. Should the bot look for a date similar to the date of the citation placement, so that the archived URL would be most similar to the one that the editor placed?

Peaceray (talk) 22:35, 12 November 2016 (UTC)

Ideas:

Archive.org URLs sometimes stop working, such as when a domain changes hands and the new owner puts up a restrictive robots.txt file. Archive.is archives aren't subject to this. Perhaps it's a better choice or both should be used.

The archive-date field should be automatically populated. This can all be done by further enhancing the cite tool that already builds a full citation given just a URL, in most cases.

Thoughts on my and Peaceray's ideas, Aracali? --2601:643:8300:92CB:F860:72D9:4462:D3DC 22:48, 12 November 2016 (UTC)

I have no preference as to whether it should be done in real time or by a bot, but it would be nice if it is done either way. My main points are to reduce the workload of editors that provide references, and to ensure that references can be accessed permanently, regardless of what the editor does. I do not think that I should prescribe the specific implementation, I am sure that people knowledgeable about bots and wikimedia processes would know what is the best or easiest way to accomplish this. If we could check for 404 errors, that would be great. Another important point is that we do not lose the information, and that's why I think that it would be a great idea to automatically archive any url used as a reference in any of the wikis. I tried to query archive.org with an arbitrary date and what it does is to return the last archival with a date earlier than the requested date: https://web.archive.org/web/20151010010203/http://www.ejercitodelaire.mde.es/ea/pag? produces the page archived on Oct 10, 2015: https://web.archive.org/web/20151008052325/http://www.ejercitodelaire.mde.es/ea/pag. Perhaps we should immediately request an archive and set the date for the url one minute or one hour into the future, and hope that is not updated and archived in-between. I am fine with doing it in Iceland, perhaps we should send archival requests to both, or to other archival systems too, to make the process more robust. I would prefer not to have to use the cite tool for this, since not everybody – myself included – uses that. Thanks for you interest and your questions, Aracali (talk) 00:31, 13 November 2016 (UTC)–

I confess: I did a little primary research: when the Wayback Machine is queried with a date in-between two archivals, it seems to return the archival closest to the requested date. This simplifies things, since we would not have to change the time of the request. Possible method:

• On edit save:

• Check if the new text has any templates that have an url field. For each of them:

• Check if there is an archive-url field; if there is one, do nothing.
• Otherwise:

• Submit archival request(s). Do not wait for termination.
• Insert an access-date (current time) if there is none, and archive-url and archive-date fields, using the access-date. (success oriented, I confess)

• The archive-url url can be created automatically for the Wayback Machine, but not for archive.is (as far as I know)

• Profit.

• A bot slowly crawls pages to archive other urls, not corresponding to new edits, and adds archive-url and archive-date fields.

• Editors optionally and manually correct those links when they do not point to the right version.

Aracali (talk) 02:47, 13 November 2016 (UTC)

The bot should add archive-url, archive-date, and |deadurl=no. Peaceray (talk) 06:29, 21 November 2016 (UTC)

Excuse me if I misunderstood this proposal, but I believe this is the same proposal as last year's, Community Tech/Migrate dead external links to archives? SamanthaNguyen (talk) 03:06, 13 November 2016 (UTC)

I think that the difference is that I am proposing to make them available before they die, not after, as soon as an edit with a url is saved. Aracali (talk) 04:36, 13 November 2016 (UTC)

• I think the first paragraph here answers what you're asking for. :) Is that correct? -- NKohli (WMF) (talk) 19:40, 14 November 2016 (UTC)

It surely covers #3 for the English Wikipedia, we should do the same for all the other Wikipedia sites. It would be cool if we could also do #1 and #2, making links to those archival pages available automatically too. Thanks, Aracali (talk) 02:40, 15 November 2016 (UTC)

@Aracali: Internet archive automatically archives urls linked from all language Wikipedias, but the record for those archived URLs is documented on-wiki immediately, you still have to implement the bot, which I believe is in the long term plan, right @NKohli (WMF):? Sadads (talk) 02:09, 16 November 2016 (UTC)

That is correct. External URLs added to articles across all ~280 Wikipedias are automatically archived by InternetArchive. There is a bot InternetArchiveBot which goes through all pages and scans for dead links and replaces them with their IA substitute. The bot is run by @Cyberpower678: and is currently only running on English Wikipedia. There are plans to launch it on other wikipedias in near future. -- NKohli (WMF) (talk) 17:04, 16 November 2016 (UTC)

That's great. I usually contribute to a non-English WP, so I did not realize that this was being done, and I am looking forward to this great feature being deployed everywhere, including also WikiData and the Commons. Some questions: Why do we wait for the link to die before offering a link to IA? Wouldn't it be better to add the link to IA as soon as it is available, so it points to the version of the web page that was used as a reference? Web pages do change with time, and the information that is being used as a reference could disappear in later versions. Should we consider automatically adding access dates if they are not included in the cite? Are we making sure that the version linked to in IA is the one corresponding to the access date? Thanks for your comments, Aracali (talk) 02:50, 17 November 2016 (UTC)

To answer your questions:

1. That decision is up to the community, this option can be controlled via an on wiki configuration page IABot uses to determine how to run on the wiki.
2. This can be done regardless of whether it was added immediately or later.
3. IABot does this for cite templates missing access dates, or when converting to access dates. It can extrapolate the access date, if it's a plain link.
4. This again can be controlled via the config page. On enwiki, it's set to get a snapshot as close to the access-date as possible, or whatever snapshot is already saved in IABot's DB of URLs.

Cheers.—cyberpower ^Chat_Hello! 04:35, 21 November 2016 (UTC)

• This is something I have often thought of implementing. Rich Farmbrough 20:31 17 November 2016 (GMT).

Voting – Automatic links to Internet Archive

1.  Support--Wesalius (talk) 05:17, 28 November 2016 (UTC)
2.  Support Ninovolador (talk) 11:29, 28 November 2016 (UTC)
3.  Support--Aracali (talk) 14:56, 28 November 2016 (UTC)
4.  Support Silraks (talk) 16:42, 28 November 2016 (UTC)
5.  Support--Peaceray (talk) 19:05, 28 November 2016 (UTC)
6.  Support This would be very useful, although I think any such bot should prioritize resolving actual dead links first, and it would have to be a bot and not a script, as we wouldn't want to bog down the saving of a page. Also, I imagine this may need to be merged with InternetArchiveBot, or at least made to work in a complementary manner. Stevie is the man! ^{Talk • Work} 01:31, 29 November 2016 (UTC)
7.  Support · · · Peter (Southwood) ^(talk): 07:22, 29 November 2016 (UTC)
8.  Support 1Or (talk) 14:04, 29 November 2016 (UTC)
9.  Support --Telaneo (User talk page) 21:24, 29 November 2016 (UTC)
10.  Support --Mess (talk) 18:41, 30 November 2016 (UTC)
11.  Support 4nn1l2 (talk) 13:11, 1 December 2016 (UTC)
12.  Support --Coffins (talk) 15:51, 1 December 2016 (UTC)
13.  Support Ahm masum (talk) 17:00, 1 December 2016 (UTC)
14.  Support -- Kaviraf (talk) 17:46, 1 December 2016 (UTC) --
15.  Support—needed for a long time. Beagel (talk) 18:02, 1 December 2016 (UTC)
16.  Support -- Tournasol7 (talk) 18:13, 1 December 2016 (UTC)
17.  Support This is so important. To ensure that Wayback is not archiving a 404, the citation template should have a "cert" parameter added where the editor should enter a string that will be guaranteed to appear in any properly archived copy of that page. Regarding WebCite and Archive.is, the Internet Archive says it has "279 billion pages" archived when it used to say 500. This indicates that the probability of something there being censored later is about half. Connor Behan (talk) 18:30, 1 December 2016 (UTC)
18.  Support Ermahgerd9 (talk) 18:54, 1 December 2016 (UTC)
19.  Support —Patrug (talk) 20:36, 1 December 2016 (UTC)
20.  Support optional comment Juandev (talk) 20:47, 1 December 2016 (UTC)
21.  Support} Miyagawa (talk) 22:37, 1 December 2016 (UTC)
22.  Support This already exists. Cyber678's IA bot rescues dead links and I've been pestering to automatically archive my own links for quite some time. The main holdup was the presumption that there would not be community consensus to allow the bot to automatically create archive links for all citations that omit them. I think an adequate compromise is to have a tag that approves the bot for visiting the page. In any event, I think such a bot action would be a net positive to active editors. For the record, IA supposedly already crawls for new citations on Wikipedia and archives them, regardless of whether we link back to that IA archived version. In practice, I've seen patchy results from that automation but nice to know that it's on IA's radar. czar 00:58, 2 December 2016 (UTC)
23.  Support NMaia (talk) 01:51, 2 December 2016 (UTC)
24.  Support Libcub (talk) 02:13, 2 December 2016 (UTC)
25.  Support Orgio89 (talk) 02:35, 2 December 2016 (UTC)
26.  Support Sounds pretty good to me! JJBers (talk) 02:41, 2 December 2016 (UTC)
27.  Support Jmvkrecords ⚜ (Intra talk) 07:44, 2 December 2016 (UTC).
28.  Support Draceane (talk) 09:40, 2 December 2016 (UTC)
29.  Support —Jc86035 (talk) 11:07, 2 December 2016 (UTC)
30.  Support--Kiril Simeonovski (talk) 12:19, 2 December 2016 (UTC)
31.  Support --Ganímedes (talk) 12:52, 2 December 2016 (UTC)
32.  Support --Continua Evoluzione (talk) 13:47, 2 December 2016 (UTC)
33.  Support --Barcelona (talk) 14:13, 2 December 2016 (UTC)
34.  Support This could also be helpful in preventing link rot. Emir of Wikipedia (talk) 15:06, 2 December 2016 (UTC)
35.  Support --Lam-ang (talk) 16:08, 2 December 2016 (UTC)
36.  Support--SBaker43 (talk) 00:28, 3 December 2016 (UTC)
37.  Support Would be great to fix the dead link issue once and for all. Doc James (talk · contribs · email) 03:41, 3 December 2016 (UTC)
38.  Support --jdx ^Re: 10:08, 3 December 2016 (UTC)
39.  Support Àlex (talk) 10:49, 3 December 2016 (UTC)

    support, but please make the implementation neutral (in the technological API sense, not in the wikipedia NPOV sense) as to what backend archival site is used for the feature. As the comments above mention, there *are* problems with archive.org getting information deleted, partly because they are based in the USA and thus subject to DMCA takedown requests and other types of governmental interference (they are working on a Canadian disaster-recovery site but that is NOT anywhere near operational). There are also technological limitations with respect to certain filetypes, or certain pagetypes. Archive.is handles the interactive javascript-heavy pages the best, and has already attempted to help with wikipedia a few years back, but were turned down for sociological reasons (worry that they would disappear being one of the main ones if memory serves). Webcitation.org has some advantages, in a few corner cases. Archive.org is the big gorilla, but interfacing exclusively with it alone, will be insufficient to accomplish the goal here. Better to implement and test the feature in a backend-agnostic fashion, then let individual wikis decide which (or which several) archival service to depend upon. 47.222.203.135 15:30, 3 December 2016 (UTC) Please log in and sign your comment—we can't accept votes from anonymous users. Thanks! -- DannyH (WMF) (talk) 16:04, 3 December 2016 (UTC)

40.  Support --Yiyi (talk) 16:17, 3 December 2016 (UTC)
41.  Support --Ranjithsiji (talk) 03:26, 4 December 2016 (UTC)
42.  Support -- —The preceding unsigned comment was added by Pamputt (talk) 11:17, 4 December 2016 4 décembre 2016 à 08:45 Logoscope-Unistra
43.  Support Great. Best regards, Kertraon (talk) 11:21, 4 December 2016 (UTC)
44.  Support --Yeza (talk) 12:55, 4 December 2016 (UTC)
45.  Support --By erdo can (talk) 14:32, 4 December 2016 (UTC)
46.  Support Chewbacca2205 (talk) 19:51, 5 December 2016 (UTC)
47.  Support --Papuass (talk) 20:09, 5 December 2016 (UTC)
48. Neutral I wonder whether there would be problems with incorrect links, creating more rather than fewer problems to be checked and fixed manually. --Tryptofish (talk) 21:59, 5 December 2016 (UTC)
49.  Support --Arjuno3 (talk) 23:37, 5 December 2016 (UTC)
50.  Support There are many example for breaking links in the current articles. --Smorteza (talk) 05:32, 6 December 2016 (UTC)
51.  Support --Zone42 (talk) 12:00, 6 December 2016 (UTC)
52.  Support- I find very hard to archive psges that use as sources in the articles I edit. DPdH (talk) 13:14, 6 December 2016 (UTC)
53.  Support Muhraz (talk) 15:36, 6 December 2016 (UTC)
54.  Support Wikipedia + Internet Archive = BFF Blue Rasberry (talk) 18:44, 6 December 2016 (UTC)
55.  Support Tiggerjay (talk) 20:48, 6 December 2016 (UTC)
56.  Support -- Movses (talk) 21:37, 6 December 2016 (UTC)
57.  Support – Preferably as a configurable drop down list somewhat similar to Robust Links that can include other web archiving services. Allen4names (talk) 02:15, 7 December 2016 (UTC)
58.  Support. - Mailer Diablo (talk) 07:01, 7 December 2016 (UTC)
59.  Support--Onioram (talk) 11:41, 7 December 2016 (UTC)
60.  Support, this is a basic need of all projects and this should be simplified — NickK (talk) 15:21, 7 December 2016 (UTC)
61.  Support But only if it gets implemented on every wiki, not just on English. ArgonSim (talk) 17:13, 7 December 2016 (UTC)
62.  Support --Dirk Beetstra ^{T C} (en: U, T) 08:38, 8 December 2016 (UTC)
63.  Support Great idea. Miniapolis 20:44, 8 December 2016 (UTC)
64.  Support Super idea, very important. Akela (talk) 21:35, 8 December 2016 (UTC)
65.  Support Ayack (talk) 11:49, 9 December 2016 (UTC)
66.  Support Way overdue. Links are rotting every day, many with no recovery options. --Waldir (talk) 10:09, 10 December 2016 (UTC)
67.  Support --OrsolyaVirág (talk) 11:39, 10 December 2016 (UTC)
68.  Support -- China Crisis (talk) 13:38, 10 December 2016 (UTC)
69.  Support --Plagiat (talk) 16:56, 11 December 2016 (UTC)
70.  Support Hell yes.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:05, 11 December 2016 (UTC)
71.  Support--David1010 (talk) 20:22, 11 December 2016 (UTC)
72.  Support MrX (talk) 14:38, 12 December 2016 (UTC)
73.  Support Samat (talk) 22:55, 12 December 2016 (UTC)

Auto-suggest Templates Tool

• Problem:

While editing, editors require templates. But the newbies or the existing editors having less technical knowledge, cannot make full use of their editing because they are not aware of the templates Wikipedia offers.

• Who would benefit:

The mass people who would benefit will be editors of-course. Especially the ones, who are new to Wikipedia editing and also, as mentioned above, the editors with less technical knowledge.

• Proposed solution:

One of the solutions can be, that we develop a bot that auto-suggests the list of templates whenever a user types '{{', and also list it's parameters and a small description of the template. (like what it is used for etc.).

• More comments:

It is difficult to show all the things (like parameters and description), so they can be shown to a user as an horizontal dropdown on mouse hover.

• Phabricator tickets:

• Proposer: Wassan.anmol (talk) 18:15, 18 November 2016 (UTC)

• Translations: none yet

Community discussion

• @Wassan.anmol: The visual editor can suggest parameters of a template (see mw:Help:VisualEditor/User guide#Editing templates) if the template has been augmented with TemplateData - the new wikitext editor will also be able to utilize this template-inserter's functionality. However, it sounds like you want each community to to suggest a pre-defined set of templates to educate newcomers about (i.e. provide a list of 10 to 20 of the templates most commonly needed by newcomers at each wiki, e.g. ^{[citation needed]},  , etc, at Enwiki), within the classic wikitext editor, via a gadget that is triggered every time they type {{; is that accurate? If so, please clarify your proposal above. Thanks! Quiddity (WMF) (talk) 23:48, 24 November 2016 (UTC)
• @Wassan.anmol: While I think the problem described here is very real I don't know by what indicators template suggestions could be made in practice. Instead I'd suggest a template-browsing module in the editor that allows one to browse through categorized templates similar to the "Special characters". --Fixuture (talk) 21:07, 28 November 2016 (UTC)
• @Quiddity (WMF): Yes, you got my point. A gadget that automatically shows the list of available templates whenever a user types '{{'. But as you stated most commonly needed templates, it is a better idea to release it as a Beta version with most commonly used templates.
• Check out en:User:ערן/autocomplete as it does the template autocomplete part of this proposal. Stevie is the man! ^{Talk • Work} 01:39, 29 November 2016 (UTC)

Future Scope: The future scope of this bot can be like, it should show the templates available in the category in which the article belongs to. For example, there exists an article XYZ under the category ABC, and an editor wants to edit the article XYZ. The bot can now come handy as whenever the editor types '{{', it should show the most commonly used templates + the templates that fall under the category ABC and might be useful for editing that particular article. Let me know if anything is unclear. Wassan.anmol (talk) 21:44, 28 November 2016 (UTC)

Voting – Auto-suggest Templates Tool

1.  Support Ninovolador (talk) 11:25, 28 November 2016 (UTC)
2. Neutral for now. It seems to me that this feature would have to read the mind of the user. I don't think contextual guessing would be anywhere as easy as the proposal suggests. If this was limited to template autocomplete, I would support making something like the autocomplete script I mention above available on more wikis. Stevie is the man! ^{Talk • Work} 01:47, 29 November 2016 (UTC)
3.  Support in general but it needs a techical solutions which can be more precise than just suggesting hundreds of irrelevant templates. Beagel (talk) 18:05, 1 December 2016 (UTC)
4.  Oppose the solution is still difficult Juandev (talk) 20:48, 1 December 2016 (UTC)
5.  Support, should be configurable per-wiki too. Gryllida 23:26, 1 December 2016 (UTC)
6.  Oppose While a cool feature in principle, it would be technically difficult to implement and maintain, and would probably only see limited use. -FASTILY 06:58, 2 December 2016 (UTC)
7.  Oppose I think we have a pretty clear guides on using templates and there is even a very helpful introductory video, so a more practical solution will be to make sure that the newbies and the less experienced users are well introduced to this specific area of editing rather than looking for technical solutions.--Kiril Simeonovski (talk) 12:35, 2 December 2016 (UTC)
8.  Support I am for the idea, but I am not sure if it is technically feasible.
9.  Support Support for the idea if it works --Ranjithsiji (talk) 03:27, 4 December 2016 (UTC)
10. Weak oppose Per Fastily, it indeed a cool feature, but I'm not sure if it is feasible to maintain. Muhraz (talk) 15:38, 6 December 2016 (UTC)
11.  Oppose Per Fastily. -- Amanda (aka DQ) 20:51, 6 December 2016 (UTC)
12.  Support Probably won't see the light of day, due to sheer difficulty. In my opinion, there should be documented preset templates for common article categories (biography, city, etc), that get automatically added when someone chooses to be guided during an article creation. This automatic article template would be added together with the most used sections and standardized features, like (City, date of birth — City, date of death), infoboxes and portals pertaining to that subject. ArgonSim (talk) 17:20, 7 December 2016 (UTC)
13.  Support It's like IntelliSense in Visual Studio. It may not be easy to develop but the maintenance cost would be low. Developers or the community don't have to define or maintain what templates would appear in the list. All templates will simply appear if the template names match what have been typed. --Gqqnb (talk) 23:33, 7 December 2016 (UTC)
14.  Support Miniapolis 20:46, 8 December 2016 (UTC)
15.  Support Tinss (talk) 17:34, 11 December 2016 (UTC)
16.  Support Bigger wikis have thousands of templates, and even smaller wikis generally have hundreds. Reinforcing the best practices via suggestion, could help newcomers and forgetful old-timers, a lot. Quiddity (talk) 04:19, 12 December 2016 (UTC)

Bot to fix misplaced talk pages

• Problem: Some talk pages are not where they should be. This causes two major problems:

1. Talk page of an article redirects to another article's talk page. For example if you want to discuss about the casino en:Kangwon Land, by clicking on the Talk you will be redirected to the talk page of en:High1 ice hockey team and you leave your text in the wrong place if you don't double check the title.
2. Talk page of an article is practically inaccessible since the corresponding article page is redirect and there is no way back to get to the talk page from the page that the talk page essentially belongs to. For example en:Talk:Battle of Coruscant has some text and history while the corresponding page en:Battle of Coruscant redirects to en:Coruscant and there is NO link from the latter talk page to the former one.

Pages with such issues can be classified as follows to better find appropriate solution:

1. Redirecting article with non-redirecting talkpage
   1. Caused by merging two pages each having its own talk page (en:Jumbo jet and en:Wide-body aircraft).
   2. Caused by moving an article to a page which already had talk page (en:Bosnian Genocide case to en:Bosnian genocide case).
2. Redirecting talk page with non-redirecting article
   1. Caused by moving an article to a title and later on creating a new article in the remained redirect of the page while the talk page is still a redirect ("Kangwon Land" was moved to en:High1 in 2008 and in 2015 a new article is built in en:Kangwon Land).
3. Redirecting article with talkpage redirecting to somewhere else
   1. Caused by moving an article to a title and then changing the remaining redirect and redirect it to another page while leaving the talk page untouched ("More to Life" was moved to en:More to Life (TV series) followed by changing the redirect to en:(There's Gotta Be) More to Life while the talk page en:Talk:More to Life is still indicating en:Talk:More to Life (TV series)).

• Who would benefit: Anyone willing to start/access discussions of those pages

• Proposed solution: Based on our findings there is no single solution to correct all misplaced talk pages, but by breaking down the problem and making specific smaller lists at least part of the problem can be solved. We managed to further narrow down the problem, but I'm not sure here is the right place to go into more details.

• Phabricator tickets:

• Proposer: Saeidpourbabak (talk) 00:39, 17 November 2016 (UTC)

• Translations: none yet

Community discussion

• @Saeidpourbabak: Is this the same as phab:T19775, or if it is 'only' related how is it related to this proposal? Thanks for helping me understand better! :) --AKlapper (WMF) (talk) 11:39, 17 November 2016 (UTC)
  • @AKlapper (WMF): Hello. This is not even related to that since the problems here are not caused by moving talk pages. I added some ways of occurring such cases as "Caused by" for each quarry, but of course the list is not exhaustive. Saeidpourbabak (talk) 17:47, 18 November 2016 (UTC)
• en:User:Mikaey/Broken talk pages
• en:Category:Unsynchronized disambiguation talk pages
  • en:Wikipedia:Bots/Requests for approval/Bot1058 3
• en:Category:Unsynchronized talk page redirects

-- Wbm1058 (talk) 05:46, 18 November 2016 (UTC)

• Redirecting article with non-redirecting talkpage is not generally a problem. I wouldn't worry too much about that. Wbm1058 (talk) 05:53, 18 November 2016 (UTC)
  • @Wbm1058: Hello. The problem for this case is that in many cases there is no proper link to the "lost" talk page and without being aware of those materials we may repeat discussions or the history. Saeidpourbabak (talk) 18:10, 18 November 2016 (UTC)
  • The redirect's talk page might just have a template, e.g. [1] Wbm1058 (talk) 05:57, 18 November 2016 (UTC)
• Redirecting talk page with non-redirecting article is often a disambiguation "article". My Bot1058 handles many of those, but I should expand its web. en:Category:Unsynchronized disambiguation talk pages is populated by four major disambiguation templates, but there are some less common templates that could populate this category as well, such as {{Call sign disambiguation}}. I need to modify them to populate the category, and automate my bot to run on a more regular schedule. If there's a way to completely tell AWB what to do from the Windows command prompt. Wbm1058 (talk) 06:12, 18 November 2016 (UTC)
  • Thanks much for the links. Useful categories and bot that we don't have in our wiki (yet!). I'll look into these stuffs and come back to you later. Saeidpourbabak (talk) 18:10, 18 November 2016 (UTC)
• Some-what unrelated, but I did fix the redirect problem with the casino mentioned in number one...so that is a plus.JJBers (talk) 02:52, 2 December 2016 (UTC)

Voting – Fix misplaced talk pages

1. Neutral Many of these cases may be problematic, but I don't see the need for the WMF to take this on. Many of these cases could be handled manually (using a move request if necessary) or by an existing bot, and perhaps some should be left alone. I don't think a master bot to fix the whole lot is critical. Stevie is the man! ^{Talk • Work} 22:20, 28 November 2016 (UTC)
2.  Oppose not a good task for a bot. I'd support a database report/special page which finds "misplaced" talk pages, but these should only be corrected manually -FASTILY 06:58, 2 December 2016 (UTC)

   I think a database or special page would be best too. Emir of Wikipedia (talk) 15:12, 2 December 2016 (UTC)

3.  Oppose I agree this should be handled manually.--Kiril Simeonovski (talk) 12:51, 2 December 2016 (UTC)
4.  Support Hey I guess I gotta support my own bot which is already doing something others don't think a bot can do and I don't know what they're smoking if they think anyone will ever do this manually. Now, keep in mind, my bot is currently working only one piece of this puzzle, which has several other more complex pieces... Wbm1058 (talk) 22:23, 2 December 2016 (UTC)
5. Neutral I think it's a good idea in theory, but the reality is so much more complex. I almost feel like it would take the same amount of time to build a bot that could do this dependably as it would to do it manually, not that anyone would want to do it manually, which is the other problem. It's a tough call for sure. Sesamehoneytart 04:01, 3 December 2016 (UTC)
6.  Support Miniapolis 20:49, 8 December 2016 (UTC)
7.  Support as a new Special: page. Quiddity (talk) 04:23, 12 December 2016 (UTC)

Bot to fix superfluous blank lines in templates, navboxes

Machine translated from German—please help improve! Falsche Leerzeilen und Vorlagenformatierungen, Naviblöcke

• Problem: Often found at the end of article pages - in particular before submission: spoken article, follow-up, navi boxes, categories - superfluous empty lines as well as incorrect representations of navigation blocks.

Oft finden sich am Ende von Artikelseiten – insbesondere vor Vorlage:Gesprochener Artikel, Folgenleisten, Navi-Boxen, Kategorien – überlüssige Leerzeilen sowie fehlerhafte Darstellungen von Navigationsblöcken.

• Who would benefit:

• Proposed solution: A bot that removes the "wrong" (superfluous) blank spaces and [another bot (?) that] corrects incorrect document formatting that will lead to unsightly blank lines, such as here or additional margins like here, in navboxes.

Ein Bot, der die „falschen“ (überflüssigen) Leerzeilen entfernt sowie [ein anderer Bot (?), der] fehlerhafte Vorlagenformatierungen, die in Naviboxen zu unschönen Leerzeilen wie z. B. hier oder Zusatzrändern wie hier führen, korrigiert.

• More comments: Note: This is also suggested on Wikipedia: Bots / Requests and Wikipedia: Suggestions for Improvement.

Hinweis: Dies wurde entsprechend auch bereits auf Wikipedia:Bots/Anfragen und Wikipedia:Verbesserungsvorschläge vorgeschlagen.

• Phabricator tickets:

• Proposer: Hubon (talk) 19:21, 20 November 2016 (UTC)

• Translations: none yet

Community discussion

I think there isn't a single cause for those lines. Like while most of the time that is an extra new line after (at the beginning) or before (in the end) the noinclude block, but that can be also whatever complexity of bad syntax in the middle. Though those first are easy to fix, basicly you just need to change "/noinclude>\n" to "/noinclude>" and "\n<noinclude" to "<noinclude". But that is not some task which requires WMF capacity IMHO. --Base (talk) 17:21, 28 November 2016 (UTC)

Voting – Fix extra blank lines in templates

1. {{neutral}} Fix manually as necessary, as some are complex cases, as discussed above. I don't see a good case for the WMF to take this on. Stevie is the man! ^{Talk • Work} 22:34, 28 November 2016 (UTC)

    Support for fixing only simple/obvious cases. Stevie is the man! ^{Talk • Work} 16:30, 5 December 2016 (UTC)

2.  Oppose Not a good task for a bot. -FASTILY 06:58, 2 December 2016 (UTC)
3.  Support Though this seems to be a minor stylistic problem, it is too arduous to do it manually.--Kiril Simeonovski (talk) 13:55, 2 December 2016 (UTC)
4.  Support It might be a little hard to get it down at first, but I believe the benefits of not having to waste your time fixing all of these little mistakes will be worth it when we perfect the bot. -- Kndimov (talk) 00:08, 3 December 2016 (UTC)
5.  Support I agree with the above. Taking the time to do this now will save a lot of time down the road. Sesamehoneytart 04:01, 3 December 2016 (UTC)
6.  Support completely agree --Ranjithsiji (talk) 03:18, 4 December 2016 (UTC)
7.  Support Muhraz (talk) 15:39, 6 December 2016 (UTC)
8.  Support Miniapolis 18:39, 8 December 2016 (UTC)
9.  Support --Fixer88 (talk) 20:51, 8 December 2016 (UTC)
10.  Support -- Akela (talk) 21:32, 8 December 2016 (UTC)
11.  Oppose per Fastily.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:07, 11 December 2016 (UTC)

Cat-a-lot improvement

• Problem: unfortunately, Gadget-Cat-a-lot can't remove files from a specified category, when you're viewing any page, except that category's page ("Remove from this category" only works for the category page you're currently viewing).

• Who would benefit: the Commons users trying to sort out the files on a Search results page. And some overcrowded categories would benefit too.

• Proposed solution: add some new functionality to the gadget, i. e.: when users inputs a category name (into the only text input field of this gadget), a new functional hyperlink (e. g., "Remove from the specified category") should appear on this gadget's panel.

• Phabricator tickets:

• Proposer: Djadjko (talk) 02:15, 11 November 2016 (UTC)

• Translations: none yet

Community discussion

• Also, there are many other useful feature requests regarding Cat-a-lot; see: c:Help:Gadget-Cat-a-lot#Open bugs .26 features + c:MediaWiki talk:Gadget-Cat-a-lot.js. XXN (talk) 13:19, 13 November 2016 (UTC)
• Yes yes yes please. Would be incredibly helpful when merging files from Category:A and Category:B into Category:A in B, and so on. Pi.1415926535 (talk) 17:54, 14 November 2016 (UTC)
• Yes that would be a great improvement to Cat-a-lot, which is very important tool (at least on Commons). --Jarekt (talk) 13:14, 16 November 2016 (UTC)
• Also, make it possible to categorize categories with this tool. And some way of alerting the user that an image is also still categorized into a top-level category of the one being moved or copied into. Daniel Case (talk) 21:49, 16 November 2016 (UTC)
• Another suggestion: If cat-a-lot has removed the last category of a page it should add an {{uncategorized}} (if available on the project). --Achim (talk) 16:12, 26 November 2016 (UTC)

Voting – Cat-a-lot improvement

1.  Support Léna (talk) 11:06, 28 November 2016 (UTC)
2.  Support --Jarekt (talk) 17:07, 29 November 2016 (UTC)
3.  Support Libcub (talk) 02:17, 2 December 2016 (UTC)
4.  Support--Kiril Simeonovski (talk) 12:53, 2 December 2016 (UTC)
5.  Support -- SBaker43 (talk) 00:11, 3 December 2016 (UTC)
6.  Support Sesamehoneytart 04:01, 3 December 2016 (UTC)
7.  Support--Ranjithsiji (talk) 03:18, 4 December 2016 (UTC)
8.  Support -- Marcus Cyron (talk) 12:05, 4 December 2016 (UTC)
9.  Support --Thierry613 (talk) 18:26, 4 December 2016 (UTC)
10.  Oppose As a openly accessible tool. Too much work to revert vandals. Commons has a wonderful (ugly) move template and those move-requests usually are processed within a few hours, max a day. Achim's suggestion is more a priority, auto-tagging uncategorized would certainly be helpful. --Hedwig in Washington (talk) 02:40, 6 December 2016 (UTC)
11.  Support Daniel Case (talk) 07:06, 6 December 2016 (UTC)
12.  Support Muhraz (talk) 15:39, 6 December 2016 (UTC)
13.  Support ArgonSim (talk) 17:23, 7 December 2016 (UTC)
14.  Support Daniel Case (talk) 05:47, 8 December 2016 (UTC)
15.  Support Miniapolis 18:41, 8 December 2016 (UTC)
16.  Support --Fixer88 (talk) 20:50, 8 December 2016 (UTC)
17.  Support This would be very, very useful. --Waldir (talk) 10:40, 10 December 2016 (UTC)
18.  Support This would be a great improvement. Reguyla (talk) 18:17, 10 December 2016 (UTC)

Global gadgets

• Problem: it is very inconvenient to manage multiple forks of a script over WMF projects. It should be possible to have global gadgets, that are available by default on the gadget list of each WMF wiki. This is specially useful for keeping a single central copy of popular gadgets, such as HotCat, wikEd, navigation popups, hiding global notices or WikiMiniAtlas, etc.
• Who would benefit: users and maintainers of popular gadgets
• Proposed solution: mw:Gadgets 3.0 (once mw:Gadgets 2.0 is live)
• Phabricator tickets: phab:T22153, phab:T121470
• Proposer: Helder 01:45, 8 November 2016 (UTC)

• Translations: none yet

Community discussion

There must also be some possibilities for translation. Some gadgets on wikidata are now with translation, but only admins can add new translation to gadget code.

Let's have global meta:Mediawiki:Gadget-foo.js. Only meta-admins are allowed to edit it. And there is some user on so.wiki, which wants to use this gadget. He also writes translation for some parts of this gadget, but how to merge it to global gadget?

And second problem: if localization is in gadget-source, there should be gadgets with 20 lines of source and 2700 lines of translations (270×10 messages) - 98% of unnecessary lines (and downlloaded data) for most users There should be localizated subpage, (e.g. mediawiki:Gadget-foo.js/so) but where? If on meta, only meta-admins can edit it. If on so.wiki, local admins can edit it, but so.wikt admins cannot.

Next point: There should be language-specific gadgets which are useful only for wikis with certain language. How to share and edit it? JAn Dudík (talk) 06:51, 8 November 2016 (UTC)

The translation is considered by mw:Gadgets 2.0. So mw:Gadgets 3.0 would continue from there. Helder 11:48, 8 November 2016 (UTC)

Probably related with Wikimodule project wish. JAn Dudík (talk) 07:02, 8 November 2016 (UTC)

In my opinion language specific gadgets could stay with all others in the central repository (meta:Mediawiki), put just a huge banner at the top, that they might not work properly because of the language constraints.

How about enabling localization subpages be edited by other usergroup than just meta-admins? I dont know if that is technically possible. --Wesalius (talk) 07:12, 8 November 2016 (UTC)

In general I strongly support this idea. --Wesalius (talk) 07:12, 8 November 2016 (UTC)

This proposal would require having a Central Global Repository for Templates, Lua modules, and Gadgets. This was also proposed in last year's wishlist. Anyone interested please also see phab:T121470 for an analysis of impact, feasibility and risk, and its dependencies (in the "task graph"). --AKlapper (WMF) (talk) 09:35, 8 November 2016 (UTC)

See Also: Community Tech/Central repository for gadgets, templates and Lua modules for a few more non-technical details. Quiddity (WMF) (talk) 19:50, 8 November 2016 (UTC)

• Good idea --Yann (talk) 16:00, 8 November 2016 (UTC)
• There are also some social issues that need to be handled before we can establish a central repository - an edit on a central repository can affect hundreds of wikis, far more incisively so than say Wikidata's data or Commons's images. Jo-Jo Eumerus (talk, contributions) 15:35, 11 November 2016 (UTC)

  That is already handled for the existing pseudo-global gadgets, such as hotcat and others, which are imported to many wikis. A proper implementation of global would not change that. Helder 16:16, 11 November 2016 (UTC)

  You mean, gadgets that are technically separate and need to be manually synced? Because if so, then it's not the same thing at all. Jo-Jo Eumerus (talk, contributions) 19:12, 11 November 2016 (UTC)

• The premise " it is very inconvenient to manage multiple forks of a script over WMF projects" is already incorrect. You should not copy-and-paste gadget but import it even if you are going to extend it. If you are going to modify the script global gadget repo won't help. --Dixtosa (talk) 10:12, 12 November 2016 (UTC)

  Importing it manually with separate mw.loader.load calls instead of being able to import all the global gadgets used by a given user in a single request, minified by resource loader? Helder 19:22, 13 November 2016 (UTC)

• Would it be possible to also have it reach to wikis such as the beta cluster, wikitech, and other private wikis? --TerraCodes (talk) 12:58, 13 November 2016 (UTC)

  There might be security concerns with wikitech and private wikis. Jo-Jo Eumerus (talk, contributions) 16:06, 14 November 2016 (UTC)

• Yes! I would be very nice to finally get this up and going. It seems to me that it is stalled in part because "i isn't perfect", but also because the individual projects wants to make such things themselves. Start with gadgets, those can be implemented without shadow namespaces. — Jeblad 15:26, 21 November 2016 (UTC)

• Can anyone be more specific and say which scripts have more than one forks that all do the exact same thing?--Dixtosa (talk) 15:41, 4 December 2016 (UTC)

Voting – Global gadgets

1.  Support--Shizhao (talk) 02:30, 28 November 2016 (UTC)
2.  Support--Wesalius (talk) 06:10, 28 November 2016 (UTC)
3.  Support --Stryn (talk) 11:27, 28 November 2016 (UTC)
4.  Support — The preceding unsigned comment was added by Sadads (talk) 14:54, 28 November 2016 (UTC)
5.  Support long overdue. —MarcoAurelio 15:09, 28 November 2016 (UTC)
6.  Support sometimes it is just too difficult to explain admins of small wikis how to enable gadgets there. With this the problem would not exist. That is to boot to other conveniences. --Base (talk) 17:27, 28 November 2016 (UTC)
7.  Support --Peaceray (talk) 19:03, 28 November 2016 (UTC)
8.  Support MichaelMaggs (talk) 19:48, 28 November 2016 (UTC)
9.  Support JAn Dudík (talk) 21:32, 28 November 2016 (UTC)
10.  Support but only with a very gradual rollout. Start with the most popular gadget and iron out all critical issues before adding a second one. There should be some way for a user to select a translation, and thus to know which translations are not yet available. Stevie is the man! ^{Talk • Work} 23:01, 28 November 2016 (UTC)
11.  Support --Izno (talk) 00:27, 29 November 2016 (UTC)
12.  Support — Jeblad 01:30, 29 November 2016 (UTC)
13.  Support  @xqt 13:48, 29 November 2016 (UTC)
14.  Support 1Or (talk) 14:04, 29 November 2016 (UTC)
15.  Support --YMS (talk) 16:28, 29 November 2016 (UTC)
16.  Support Also could be done globally per language, or per sister project, or global at all the wikifarm. --Zerabat (discusión) 16:52, 29 November 2016 (UTC)
17.  Support I supported it last year's Wishlist Survey and still support it this year --Jarekt (talk) 17:10, 29 November 2016 (UTC)
18.  Support StevenJ81 (talk) 17:10, 29 November 2016 (UTC)
19.  Support Guycn2 · ☎ 17:46, 29 November 2016 (UTC)
20.  Support --Telaneo (User talk page) 21:22, 29 November 2016 (UTC)
21.  Support Seems long overdue to me. BU Rob13 (talk) 05:40, 30 November 2016 (UTC)
22.  Support Alexei Kopylov (talk) 08:29, 30 November 2016 (UTC)
23.  Support --ArgonSim (talk) 08:47, 30 November 2016 (UTC)
24.  Support Helder 12:20, 30 November 2016 (UTC)
25.  Support --Micru (talk) 12:31, 30 November 2016 (UTC)
26.  Support. Max Semenik (talk) 22:54, 30 November 2016 (UTC)
27.  Support --Nouill (talk) 12:58, 1 December 2016 (UTC)
28.  Support 4nn1l2 (talk) 13:16, 1 December 2016 (UTC)
29.  Support β₁₆ - (talk) 14:51, 1 December 2016 (UTC)
30.  Support SamanthaNguyen (talk) 16:37, 1 December 2016 (UTC)
31.  Support Ahm masum (talk) 17:00, 1 December 2016 (UTC)
32.  Support -- Kaviraf (talk) 17:44, 1 December 2016 (UTC) --
33.  Support --Vachovec1 (talk) 19:12, 1 December 2016 (UTC)
34.  Support --AmaryllisGardener ^talk 19:13, 1 December 2016 (UTC)
35.  Support Juandev (talk) 20:50, 1 December 2016 (UTC)
36.  Support Mike Peel (talk) 22:41, 1 December 2016 (UTC)
37.  Support Gryllida 23:27, 1 December 2016 (UTC)
38.  Support NMaia (talk) 01:53, 2 December 2016 (UTC)
39.  Support Jmvkrecords ⚜ (Intra talk) 07:47, 2 December 2016 (UTC).
40.  Support --Geraki ^T_L 08:40, 2 December 2016 (UTC)
41.  Support Draceane (talk) 09:41, 2 December 2016 (UTC)
42.  Support —Jc86035 (talk) 11:07, 2 December 2016 (UTC)
43.  Support--Kiril Simeonovski (talk) 12:55, 2 December 2016 (UTC)
44.  Support --Continua Evoluzione (talk) 13:48, 2 December 2016 (UTC)
45.  Support--Sannita - not just another it.wiki sysop 14:00, 2 December 2016 (UTC)
46.  Support Multichill (talk) 14:01, 2 December 2016 (UTC)
47. Conditional  Support - the choice of where to host global gadgets and who is ultimately responsible for them needs careful assessment. Jo-Jo Eumerus (talk, contributions) 16:03, 2 December 2016 (UTC)
48.  Support --Lam-ang (talk) 16:08, 2 December 2016 (UTC)
49.  Support Laurentius (talk) 19:31, 2 December 2016 (UTC)
50.  Support Daylen (talk) 20:33, 2 December 2016 (UTC)
51.  Support. Matiia (talk) 23:17, 2 December 2016 (UTC)
52.  Support Been needed a long time. Doc James (talk · contribs · email) 03:40, 3 December 2016 (UTC)
53.  Support LlamaAl (talk) 04:53, 3 December 2016 (UTC)
54.  Support --Yiyi (talk) 16:14, 3 December 2016 (UTC)
55.  Support --Ranjithsiji (talk) 03:18, 4 December 2016 (UTC)
56.  Support --Tgr (talk) 07:01, 4 December 2016 (UTC)
57.  Support Useful. Best regards, Kertraon (talk) 11:14, 4 December 2016 (UTC)
58.  Support -- Marcus Cyron (talk) 12:05, 4 December 2016 (UTC)
59.  Support Gratus (talk) 12:32, 4 December 2016 (UTC)
60.  Support --Yeza (talk) 12:52, 4 December 2016 (UTC)
61.  Support --By erdo can (talk) 14:23, 4 December 2016 (UTC)
62.  Support -- T.seppelt (talk) 16:20, 4 December 2016 (UTC)
63.  Support it is a good idea to begin with; I find it particularly great because it forces gadget developers to think about l10n and i18n of their gadgets. Huji (talk) 19:41, 5 December 2016 (UTC)
64.  Support --Arjuno3 (talk) 23:41, 5 December 2016 (UTC)
65.  Support That's a high priority task indeed. --Hedwig in Washington (talk) 02:41, 6 December 2016 (UTC)
66.  Support—An ability to (optionally) share gadgets, modules, and other common tools would be a boon to all projects. -- Ryan • (talk) • 06:34, 6 December 2016 (UTC)
67.  Support Pabouk (talk) 13:18, 6 December 2016 (UTC)
68.  Support Urgently needed. Muhraz (talk) 15:39, 6 December 2016 (UTC)
69.  Support Blue Rasberry (talk) 18:45, 6 December 2016 (UTC)
70.  Support -- Amanda (aka DQ) 20:52, 6 December 2016 (UTC)
71.  Support Yes please. Ks0stm ^(T•C•G) 21:08, 6 December 2016 (UTC)
72.  Support -- Movses (talk) 21:33, 6 December 2016 (UTC)
73.  Support. - Mailer Diablo (talk) 07:01, 7 December 2016 (UTC)
74.  Support Matěj Suchánek (talk) 15:25, 7 December 2016 (UTC)
75.  Support. It is easy to have a fork: just imagine a non-English Wikipedia copying a script from English Wikipedia and not updating it until it fails, and then desperately looking for a bug in a version of a script dating back to 2010. There should be a solution to this — NickK (talk) 15:27, 7 December 2016 (UTC)
76.  Support CFCF💌 📧 20:27, 7 December 2016 (UTC)
77.  Support --Dirk Beetstra ^{T C} (en: U, T) 08:35, 8 December 2016 (UTC)
78.  Support Amir (talk) 18:17, 8 December 2016 (UTC)
79.  Support Miniapolis 18:42, 8 December 2016 (UTC)
80.  Support This one's needed. --Fixer88 (talk) 20:52, 8 December 2016 (UTC)
81.  Support Dixtosa (talk) 06:07, 9 December 2016 (UTC)
82.  Support Opabinia regalis (talk) 06:43, 9 December 2016 (UTC)
83.  Support Ayack (talk) 11:49, 9 December 2016 (UTC)
84.  Support --Arnd (talk) 13:28, 9 December 2016 (UTC)
85.  Support --OrsolyaVirág (talk) 11:40, 10 December 2016 (UTC)
86.  Support I agree with MarcoAurelio above. Way overdue and with the transition to global capabilities this would be a great improvement. Reguyla (talk) 18:19, 10 December 2016 (UTC)
87.  Support --Plagiat (talk) 17:02, 11 December 2016 (UTC)
88.  Support--David1010 (talk) 20:24, 11 December 2016 (UTC)
89.  Support – Uanfala (talk) 23:53, 11 December 2016 (UTC)
90.  Support --KuboF (talk) 20:50, 12 December 2016 (UTC)
91.  Support--Mikheil ^Talk 20:57, 12 December 2016 (UTC)
92.  Support KSFT (talk) 22:04, 12 December 2016 (UTC)

Good Article Nominations suggestion bot

• Problem: Lack of reviewers for GAN, large backlog

• Who would benefit: Anyone making a GAN, arguably Wikipedia as a whole due to the speeding up of the process.

• Proposed solution: A bot would suggest GAN's to a user to review, either based upon what they usually edit, or else they could select a genre (or several), and have them sent to them, much like RFC's.

• Phabricator tickets:

• Proposer: Iazyges (talk) 03:24, 16 November 2016 (UTC)

• Translations: none yet

Community discussion

• @Iazyges: What does "GAN" stand for? Any link? This would allow others to understand better which problem you're facing and what you are proposing. Thanks! --AKlapper (WMF) (talk) 10:54, 16 November 2016 (UTC)

Good article nominations. That's the title of this proposal. Wbm1058 (talk) 19:20, 16 November 2016 (UTC)

• SuggestBot could probably be modified to do this. Samsara (talk) 05:11, 17 November 2016 (UTC)
• This already exists at the English Wikipedia: en:Wikipedia:Feedback request service. Users can sign up to receive GAN notifications per genre. Stevie is the man! ^{Talk • Work} 23:12, 28 November 2016 (UTC)

Voting – Good Article Nominations suggestion bot

1.  Support--Wesalius (talk) 06:09, 28 November 2016 (UTC)
2. Neutral Since this appears to be English Wikipedia-oriented, the Feedback request service already handles this per my comment above. Stevie is the man! ^{Talk • Work} 23:12, 28 November 2016 (UTC)
3.  Oppose Already exists, at least on the English Wikipedia. BU Rob13 (talk) 05:36, 30 November 2016 (UTC)
4.  Oppose Wich criteria will run the bot? How determinate what a GA is? By quality of source? By number? By size of article? Not usefull with actual rules of es:WP --Ganímedes (talk) 12:56, 2 December 2016 (UTC)
5.  Oppose As noted above, this already exists on the English Wikipedia. I hope it can be easily introduced on the other Wikipedias that may need it.--Kiril Simeonovski (talk) 13:11, 2 December 2016 (UTC)
6.  Oppose Not a task a bot a can really do. --Hedwig in Washington (talk) 02:42, 6 December 2016 (UTC)
7.  Oppose, this proposal requires too much work to fit all projects as selection processes differ a lot from one project to another, and we do not need single-project proposals here — NickK (talk) 15:29, 7 December 2016 (UTC)
8.  Oppose Sounds like something that only the English community would benefit. ArgonSim (talk) 17:26, 7 December 2016 (UTC)
9.  Support Miniapolis 18:50, 8 December 2016 (UTC)

Identify high-use gadgets and ensure that they have proper long-term maintenance

• Problem: Many gadgets start small, often as a proof of concept, but when they reach some level of popularity and high use than they need to be revisited and possibly rewritten with long-term maintenance and stability in mind. Some popular gadgets are written by people who are no longer active, or more focused on other things than maintenance of old gadgets, and if no one steps up to maintain them problems and incompatibilities accumulate. Some gadgets are copied to other projects and multiple versions diverge. Many users rely heavily on tools and gadgets to do more efficiently their tasks on Wikimedia projects and keeping the tools running is important to keep them happy and busy.

• Who would benefit: Users of gadgets

• Proposed solution: Identify high-use gadgets on different projects and ensure that there is a long-term plan to maintain them. That might require code rewrite to more maintainable version or conversion to extension format. Would require a link to phabricator pages where one can report errors and issues. Current approach on Commons of protected edit requests on gadget's Javascript talk pages seems quite dangerous.

For example on Commons, I suspect we should look more closely at HotCat, Cat-a-lot, VisualFileChange and ImageAnnotator. I am sure Wikipedia might have other popular gadgets.

• Phabricator tickets: phab:T158462 Note: phabricator:T108630 was discussing what to do with HotCat

• Proposer: Jarekt (talk) 17:05, 18 November 2016 (UTC)

• Translations: none yet

Community discussion

• I like the idea and I wonder how to break this down into specific steps which are required to make this become reality. Regarding identifying popular gadgets, we have Special:GadgetUsage. Regarding copying over and diverging, creating a Central Global Repository for Templates, Lua modules, and Gadgets is pretty complex (see the task graph), recognizing that a maintainer is not active anymore might not be trivial either, and where would be a venue (pool?) to find potential new maintainers? Set up process / criteria for taking over abandoned tools and Requests for comment/Abandoned Labs tools feels similar though that topic is about tools on Labs and not gadgets. --AKlapper (WMF) (talk) 18:19, 18 November 2016 (UTC)

I was imagining more of a process of technical community and/or WFM taking more active role in tracking and assuring that high-use gadgets stay up to date and are properly maintained. We can call it "too big to fail" list :) . I did not know about Special:GadgetUsage and it seems like a good way to identify candidates. Community voting process might also be used. Selected gadgets might need to be rewritten as extensions or placed in Central Global Repository. Wider community would be monitoring and assisting with issues related to them. --Jarekt (talk) 19:20, 18 November 2016 (UTC)

@Jarekt: I'm afraid this proposal is a bit too vague to be actionable. Could you specify one or more gadgets that you would specifically want the WMF to become responsible for and what you would want us to do with them? AFAIK, HotCat is the most used gadget across all the projects. Ryan Kaldari (WMF) (talk) 18:59, 21 November 2016 (UTC)

@Ryan Kaldari (WMF): Ryan, There is nothing specific I am proposing for HotCat, other than maybe turning it into extension so we do not have 100+ copies floating around, although that would be fixed by phabricator:T121470. I am just observing that there are a lot of gadgets out there: some are rarely used and some used a lot (like HotCat), some working well and some interfering with other tools, some with active maintainers looking after them and improving them and some written once and never touched. I was imagined some system of oversight of gadgets that would ensure that high-use gadgets keep working, a little like what you started in phabricator:T108630, but to do similar evaluation periodically for all high use gadgets. I also imagine that most used gadgets would be graduated into extensions. I recently wrote this bug report. I was surprised HotCats was not part of MediaWiki software. The issue made me wonder where should I report the problem (some talk page or phabricator)? Is the fix going to be copied to HotCat implementations on other projects? Is anybody actively maintaining this and other high use gadgets. As you can see, I do not have much experience with gadget writing or maintenance, so if my ideas make little sense, they are unlikely to be implemented and I am fine with dropping this proposal. --Jarekt (talk) 21:11, 21 November 2016 (UTC)

@Jarekt: Unfortunately, there isn't really any practical way for us to monitor gadgets. Each wiki has dozens of different gadgets and in most cases there is little documentation about how the gadgets should actually work. For non-English languages it's especially challenging for us to figure out whether a gadget is properly working or not. Some gadgets have lots of different features and some require actually making edits to articles in order to test. They also typically do not have English interfaces available. Due to these issues, gadgets have generally been left in the hands of the local communities and the WMF has only gotten involved when important gadgets break and need to be fixed quickly. Converting a gadget into an extension sounds easy, but is actually a big undertaking. For example, the effort to convert Navigation pop-ups into an extension (Hovercards) has lasted almost 2 years and still isn't out of the Beta feature phase. There's also the issue that converting gadgets into extensions can actually make them less maintainable rather than more since there is a smaller pool of developers that can work on them. In some cases though, like HotCat, I think it probably makes sense to convert them. Mostly, I'm worried that if this proposal is approved it won't actually result in any work, since it is more about a process than a specific task that can be completed. What would really be useful is a proposal about maintaining, rewriting, or extensionifying a specific gadget. That would let us know that there is community support for a specific action (rather than having to guess) and would also let us incorporate that task into our workflow as it would be something that we could analyze, estimate how much work is involved, allocate proper resources, and complete. If there are specific gadgets that you have in mind, what would you think about splitting this proposal into separate proposals for each gadget? That will at least let us know which gadgets the community is legitimately concerned about. Ryan Kaldari (WMF) (talk) 19:08, 23 November 2016 (UTC)

• Ensuring maintenance is best done by making central repos for important gadgets, that will ensure best utilization of the limited resources. (Yes we have a lot of people, no we don't have a lot of people with specific knowledge about the different gadgets.)

Wikis are a kind of super-agile tools, while maintenance is not agile-like at all, so we have a clash of ideas and methods. Enforcing tests and coding standards are easy and probably acceptable, while enforcing documentation and maintenance are much more difficult. Maintenance can although be triggered by failing tests and coding standards, likewise some documentation can be detected as missing, like JS-doc. If we somehow can say which documents we want in addition, then we can make additional skeleton pages.

Making something maintainable has a lot to do with visualizing things that can break. One way to do so is to add a type system, and one such system is Microsoft w:TypeScript, another one is Googles w:Closure Compiler. With those tools we see when the gadgets break, and then we can fix them. We need such tools, together with other tools for maintaining the gadget code.

And yes, we need a better tool for identifying high use gadgets. — Jeblad 20:41, 23 November 2016 (UTC)

need a tool / gadget life-cycle migration to core functionality. need to do assessment of the useful ones, and then on-board. if every gadget is an island, then you will have good things breaking. why do we have to tell every newbie to turn hotcat on? because it was not invented here? Slowking4 (talk) 23:15, 24 November 2016 (UTC)

I think the main thing that the WMF could do here is take a look at some of the most-used gadgets and make sure their code is up-to-date and possibly turn one or two of them into extensions. I don't think it is scalable, however, for the WMF to take over maintenance for a large number of them. This is something that the community is still going to have to be actively involved in. Ryan Kaldari (WMF) (talk) 21:20, 4 December 2016 (UTC)

Voting – Maintaining high-use gadgets

1.  Support--Wesalius (talk) 06:11, 28 November 2016 (UTC)
2.  Support. For example, the Match and split tool on Wikisource : Match and split. --Consulnico (talk) 17:39, 28 November 2016 (UTC)
3.  Support For obvious reasons this is the most important suggestion in this category. I'd prefer if there was a bot/gadget-system that ensures long-term support without any maintenance-work though. But making sure the most used gadgets keep on working should really be #1 on the priorities. There are different ways to identify the "high use" gadgets though (e.g. voting, traffic-measurement, usefulness-assessment, install/activation-counts, multiple of the prior, etc.) --Fixuture (talk) 21:12, 28 November 2016 (UTC)
4. Neutral This sounds very useful but I don't think it complies with the requirements for this survey. This is about a meta wiki process rather than a specific technical project. However, if Global Gadgets moves forward, I think that could be a driver for much of that discussed in this proposal. At any rate, this can happen, gradually, if there's enough committed users willing to focus on all the necessary steps. Stevie is the man! ^{Talk • Work} 23:39, 28 November 2016 (UTC)
5.  Support --Izno (talk) 00:29, 29 November 2016 (UTC)
6.  Support — Jeblad 01:32, 29 November 2016 (UTC)
7.  Support --Jarekt (talk) 17:11, 29 November 2016 (UTC)
8.  Support --Tarjeimo (talk) 21:54, 29 November 2016 (UTC)
9.  Support--Vituzzu (talk) 14:26, 30 November 2016 (UTC)
10.  Support --β₁₆ - (talk) 15:08, 1 December 2016 (UTC)
11.  Support Ahm masum (talk) 17:00, 1 December 2016 (UTC)
12.  Support -- Kaviraf (talk) 17:43, 1 December 2016 (UTC) --
13.  Support --Vachovec1 (talk) 19:15, 1 December 2016 (UTC)
14.  Support many gadgets need a visualeditor port or an update, would be nice to have a proper list where to start Gryllida 23:28, 1 December 2016 (UTC)
15.  Support Libcub (talk) 02:18, 2 December 2016 (UTC)
16.  Support --Thgoiter (talk) 08:13, 2 December 2016 (UTC)
17.  Support--Kiril Simeonovski (talk) 13:11, 2 December 2016 (UTC)
18.  Support--Sannita - not just another it.wiki sysop 14:02, 2 December 2016 (UTC)
19.  Support --Kvng (talk) 16:19, 2 December 2016 (UTC)
20.  Support -- Sandiooses (talk) 17:26, 2 December 2016 (UTC)
21.  Support—I can barely function without my gadgets Barbara (WVS) (talk) 20:15, 2 December 2016 (UTC)
22.  Support. Matiia (talk) 23:21, 2 December 2016 (UTC)
23.  Support Mike Peel (talk) 23:36, 2 December 2016 (UTC)
24.  SupportDoc James (talk · contribs · email) 03:40, 3 December 2016 (UTC)
25.  Support. FastButtons on eswiki! LlamaAl (talk) 04:55, 3 December 2016 (UTC)
26.  Strong support --jdx ^Re: 10:12, 3 December 2016 (UTC)
27.  Support --Yiyi (talk) 16:14, 3 December 2016 (UTC)
28.  Support --Ranjithsiji (talk) 03:19, 4 December 2016 (UTC)
29.  Support—the foundation may need to step into help maintain widely-used gadgets at some level, so it should prepare itself for that situation by monitoring the gadgets. also major gadgets should have a Continuous Integration system in place (automated tests, linting, etc). ImperfectlyInformed (talk) 10:28, 4 December 2016 (UTC)
30.  Support --By erdo can (talk) 14:31, 4 December 2016 (UTC)
31.  Strong support That would be time well spent! Just remember the tools we lost when moving to LABS. --Hedwig in Washington (talk) 02:44, 6 December 2016 (UTC)
32.  Support Noyster (talk) 09:09, 6 December 2016 (UTC)
33.  Support Pabouk (talk) 13:18, 6 December 2016 (UTC)
34.  Support Muhraz (talk) 15:41, 6 December 2016 (UTC)
35.  Support -- Amanda (aka DQ) 20:53, 6 December 2016 (UTC)
36. Support, potentially as a part of #Global gadgets proposal — NickK (talk) 15:30, 7 December 2016 (UTC)
37.  Support TheDragonhunter (talk) 03:32, 8 December 2016 (UTC)
38.  Support --Dirk Beetstra ^{T C} (en: U, T) 08:35, 8 December 2016 (UTC)
39.  Support Miniapolis 19:21, 8 December 2016 (UTC)
40.  Support --Fixer88 (talk) 20:52, 8 December 2016 (UTC)
41.  Support Ayack (talk) 11:49, 9 December 2016 (UTC)
42.  Support --Arnd (talk) 13:30, 9 December 2016 (UTC)
43.  Support --OrsolyaVirág (talk) 11:41, 10 December 2016 (UTC)
44.  Support This is a great idea and a perfect example of the types of workforce/community management support and monitoring the WMF should be doing and isn't. Reguyla (talk) 18:20, 10 December 2016 (UTC)
45.  Support KSFT (talk) 22:04, 12 December 2016 (UTC)