Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Miscellaneous

< Community Wishlist Survey 2016
Miscellaneous
34 proposals, 334 contributors, 788 support votes



Relaunching Wikitrends statistics tool

  • Problem: As editors, we really enjoyed following Wikitrends Trends on Wikipedia for every Wikipedia. This tool serves two interests: curiosity - finding out what readers of a certain language look for in a certain period of time and also, increase of productivity - when editors pay attention to the fact there's more traffic to a certain article, they can work on this specific article, improve it, or at least, pay more attention to this sudden field of interest. Unfortunately, this tool is no longer usable for few months now and there's no alternative I know for this real time information.
  • Who would benefit: Readers and editors, as well as PR personalities in the Wikimedia community (spokespersons of Wikimedia chapters had been using this information in their updates to local media).
  • Proposed solution: Find a solution to make it work again: give us the top 10 articles visited in the last day, week and month, as well as Uptrends and Downtrends for Wikipedia in each language.
  • More comments: I would be mostly happy to find that I missed something, in case this tool is available now in any other form (-: .
  • Phabricator tickets:

Community discussion

@Ldorfman: Does "this tool is no longer usable for few months now"? refer to "Last updated Sat, 06 Aug 2016", or are there further issues? Trying to better understand... --AKlapper (WMF) (talk) 14:41, 22 November 2016 (UTC)[reply]
@AKlapper (WMF): Hi. We don't get new information anymore at the Most Visited page as well as at the Downtrends and Uptrends pages (at least for Hebrew Wikipedia). It is stuck on the info since, I guess, this day in August. Is it a case of "simple" "clear cache" somehow? Ldorfman (talk) 16:53, 23 November 2016 (UTC)[reply]
@Ldorfman: Please see http://www.trending.eu/ & http://www.wikipediatrends.com/ & w:Wikipedia:Top 25 Report. They aren't really as good / functional as WikiTrends though. I'd support your proposal if there weren't more pressing issues and no current partial solution/s. --Fixuture (talk) 20:39, 30 November 2016 (UTC)[reply]
You have : Wikiscan --Nouill (talk) 13:12, 1 December 2016 (UTC)[reply]
@Fixuture: Thanks for the note, but "Trending" doesn't give the same information as the page I wrote about (like number of vistors for example), plus it's not for all wikis (Hebrew, for example, my home wiki, is not included).
Wikipediatrends is for en.wikipedia only and the same is about "Top 25 Report". The tool I ask for is for all almost 200 Wikipedia projects.
@Nouill: Wikiscan gives a very different information. It's not about page-view statistics/number of watchers, but about modifications volume. It's totally something else, plus, it's a bit problematic to get to it using Google Chrome due to what's mentioned as "safety reasons". Ldorfman (talk) 20:41, 7 December 2016 (UTC)[reply]

Voting – Wikitrends statistics tool

  1.   Support. this just dump link error--Shizhao (talk) 02:52, 28 November 2016 (UTC)[reply]
  2.   Support--Alexmar983 (talk) 17:19, 28 November 2016 (UTC)[reply]
  3.   Oppose Alternatives exists. --Nouill (talk) 13:12, 1 December 2016 (UTC)[reply]
  4.   Neutral per Fixuture. Stevie is the man! Talk • Work 15:16, 4 December 2016 (UTC)[reply]
  5.   Oppose --Hedwig in Washington (talk) 03:53, 6 December 2016 (UTC)[reply]
  6.   Support שי אבידן (talk) 14:41, 11 December 2016 (UTC)[reply]
  7.   Support. We already have a WMF-supported page views tool, it should not be that difficult to find most visited pages using this data — NickK (talk) 01:40, 12 December 2016 (UTC)[reply]
  8.   Support.Ovedc (talk) 05:38, 12 December 2016 (UTC)[reply]

Standardization of the includable special page

  • Problem: The invoke of all includable special page are not uniform. The parameter of some function to set is not all the same. like the Special:NewPages have the parameter 'shownav' to control to show the navigation bar ,but the Special:PrefixIndex does not control it by the parameter which also have the navigation bar. The method of send the parameter is not uniform，They have send them with a string split by comma, key-value map split by pipe operator, and the url request type like '{{Special:NewPages/50}}'. At last we have not enough document to explain the special page,especially the Transclusion.
  • Who would benefit: Editor who need include some Special Page on the page.
  • Proposed solution: For parameter, Maybe it need create a method to collect the parameter from different type of the assignment so It can get the parameters easily by transcluded.
  • Phabricator tickets:

Community discussion

  • @Cwek: Hi, please could you add some example links above, so that people who are not familiar with the problem or pages can see exactly what you mean. Please include examples that currently do work the way you want, and examples that do not (perhaps as a sandbox diff link). Thanks! Quiddity (WMF) (talk) 19:34, 16 November 2016 (UTC)[reply]

Voting – Standardization of the includable special page

  1.   Support Some unifications could be done to this. Matěj Suchánek (talk) 21:16, 1 December 2016 (UTC)[reply]
      Neutral I fail to see the benefit. --Hedwig in Washington (talk) 03:54, 6 December 2016 (UTC)[reply]
  2.   Support - Wishful thinking/moral support. I can see where there would be serious technical challenges to standardizing, but I'd like to see greater ability to transclude special pages with parameters only available through url/get. — Rhododendrites talk \\ 02:47, 8 December 2016 (UTC)[reply]

Thank IPs for their edits

  • Problem: While many IPs do disruptive edits, there are many that do constructive editing.
  • Who would benefit: IP users would recognize that they did good work, and they then might me encouraged to get a username. Users would be able to tell the IPs that they appreciate their work, encouraging them to edit more.
  • Proposed solution: A way to thank IP users for edits, like we can for other users.

Community discussion

  • See also 2015 Community Wishlist Survey/Notifications#Modify "Thank you" so we can thank anonymous editors, which ranked #22 in the 2015 survey. Gnom (talk) 22:36, 14 November 2016 (UTC)[reply]
  • @Kew Gardens 613 and Gnom: The difficulty with this idea, is that IP addresses can be shared, and can frequently change (especially for mobile editors)(c.f. w:en:Template:Shared IP header templates), so a "Thank" sent to an IP address might not ever be seen by the intended recipient. There was some discussion in last year's proposal, and in phab:T63022, about making something different-than-usual happen when we click "Thank" on an IP's edit—perhaps sending an automatic talkpage template message immediately, or perhaps just opening the talkpage and prompting the editor for input—but that wasn't the focus of the original proposal, so it was unclear what the editors who'd participated in the overall discussion thought of that alternative. There are also strong concerns that this new behaviour (A) does not match the existing expectations for how the Thanks links will behave, and (B) it does so by making a very public talkpage message rather than a simple and semi-public "Thank" notification. Please could you (both) clarify the proposal above, to take this into account? (Either: amend it to specify exactly how it might work, given that we can't reliable send Echo Notifications, and thus must rely upon talkpages; or retract it altogether if you are no longer convinced of the pros outweighing the cons; or some other option that I haven't thought of!) Thanks. Quiddity (WMF) (talk) 23:08, 14 November 2016 (UTC)[reply]
Hi Quiddity (WMF)! For me, the proposal was born from the frustrating experience of seeing an edit, wanting to thank the editor, and then seeing that it was an IP who made the edit. I was totally aware that IP addresses can be shared and that they can change. I like the idea of sending the user a thank you notice on their talk page instead. --Gnom (talk) 11:51, 15 November 2016 (UTC)[reply]
  • I think it should be possible. If the thanking occurs within 24 h, a template is left in the talk page, which will be erased or archived according to local policies after a while. Otherwise, the information is stored on some log book as it is for users. It's useful to know that from a cluster of IPs good stuff come more than from other ones. I see no reason why we shouldn't try.--Alexmar983 (talk) 02:52, 16 November 2016 (UTC)[reply]
See the somewhat related idea of using throwaway accounts for anonymous editors (T133452) which would allow them to be reached the same way normal editors can, until their session times out. --Tgr (WMF) (talk) 03:22, 18 November 2016 (UTC)[reply]

Proposed Solution: Send a special session cookie to IP users, when they edit an article. If someone sends a thanks to an IP, it is delivered to the owner of the cookie, if it still exists. After successful delivery the thanker gets a positive echo notice. If the thanks cannot be delivered within 24 hours, the thanker gets a negative echo notification. --𝔊 (Gradzeichen Diſk✉Talk) 09:12, 18 November 2016 (UTC)[reply]

Voting – Thank IPs for their edits

  1.   Oppose IKhitron (talk) 12:13, 29 November 2016 (UTC)[reply]
  2.   Support Jack who built the house (talk) 12:59, 29 November 2016 (UTC)[reply]
  3.   Neutral I started out as neutral last year, then changed to mild support, but now I'm back to neutral. I guess I just can't work up excitement about this, for the reason that IP users are too wiggly (i.e., can barely be pinned down to receive anything) for this to have any significant impact compared to the work needed to implement it. But if somehow it is implemented, I might use it sometimes (which is why I won't outright oppose it). Stevie is the man! Talk • Work 14:05, 29 November 2016 (UTC)[reply]
  4.   Support but only if "thanking" isn't translated into a talk page message (which I consider a different "gesture", often much too "invasive" or "loud" for a small contribution already}). I like the idea to track the IP via session cookie. --Matthiaspaul (talk) 01:50, 30 November 2016 (UTC)[reply]
  5.   Support Alexei Kopylov (talk) 09:03, 30 November 2016 (UTC)[reply]
  6.   Support, people need some kind of feedback. --Fixuture (talk) 20:40, 30 November 2016 (UTC)[reply]
  7.   Oppose Dubious value. IPs may be dynamic, change without warning, etc. Anon may never get the thanks -FASTILY 02:27, 1 December 2016 (UTC)[reply]
    @Fastily: That can be addressed by checking if they still have the last-used cookie. Samsara (talk) 15:16, 4 December 2016 (UTC)[reply]
    Right, but I'm not in disagreement with any of the how-to details; I believe implementing this feature would introduce additional, unnecessary technical overhead, lead to minimal value for the community, and ultimately, Anons many never see the 'thanks'. -FASTILY 22:13, 4 December 2016 (UTC)[reply]
  8.   Oppose Multiple users on a single IP (schools, libraries, etc) makes your thanks go to potentially someone else who isn't helping. Just send a welcome message to their talk page to encourage them to make an account! Semmendinger (talk) 19:48, 1 December 2016 (UTC)[reply]
    @Semmendinger: (1) Users can be distinguished by browser cookie. (2) Encouraging account creation may be against policy on some wikis. Samsara (talk) 15:16, 4 December 2016 (UTC)[reply]
    @Samsara: Well that's a stupid rule, we should be encouraging all editors to put an account to their edits if possible. Thanks for information on the first half though! Semmendinger (talk) 15:58, 4 December 2016 (UTC)[reply]
  9.   Support NMaia (talk) 02:40, 2 December 2016 (UTC)[reply]
  10.   Oppose, too much complexity for too little gain. Max Semenik (talk) 03:23, 2 December 2016 (UTC)[reply]
  11.   Oppose Jmvkrecords ⚜ (Intra talk) 08:22, 2 December 2016 (UTC). People can be thanked for edits they didn't make.[reply]
  12.   Support with a time limit: Possible to thank during 5 minutes (for instance) after the IP edit. - Best regards, Kertraon (talk) 12:08, 4 December 2016 (UTC)[reply]
  13.   Oppose not worth it. --Rschen7754 04:50, 5 December 2016 (UTC)[reply]
  14.   Support A thank you can be very encouraging, and many users edit without a login for many reasons. --WinTakeAll (talk) 22:09, 5 December 2016 (UTC)[reply]
  15.   Oppose Too many IP addresses used by multiple persons. --Tryptofish (talk) 23:26, 5 December 2016 (UTC)[reply]
  16.   Oppose Not worth the effort, too few raisins in too much dung. One can always c&p a nice msg to the ip talk page if needed. --Hedwig in Washington (talk) 03:57, 6 December 2016 (UTC)[reply]
  17.   Support Muhraz (talk) 15:53, 6 December 2016 (UTC)[reply]
  18.   Oppose personally disagree with IP editing. DPdH (talk) 12:56, 9 December 2016 (UTC)[reply]
  19.   Support Miniapolis 16:51, 9 December 2016 (UTC)[reply]
  20.   Support Yes, please! I've wanted to thank IP editors quite often. Not only for them, but also for the public record to show it (even though that's quite hard to find at the moment). --Waldir (talk) 11:20, 10 December 2016 (UTC)[reply]
  21.   Support Именно тех, кто знают википедию минимально, надо убеждать в том, что мы ценим их правок--TOMA646 (mail | talk) 14:10, 10 December 2016 (UTC)[reply]
  22.   Oppose per Tryptofish.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:36, 11 December 2016 (UTC)[reply]
  23.   Oppose The only encouragement for IPs should be to sign up. Matěj Suchánek (talk) 20:50, 11 December 2016 (UTC)[reply]
  24.   Support FoCuSandLeArN (talk) 23:04, 11 December 2016 (UTC)[reply]
  25.   Support – Uanfala (talk) 00:57, 12 December 2016 (UTC)[reply]

Use notifications (echo) for mass messages

  • Problem: Some mass messages should go to users given specific roles, usage, or behaviors, without the sender name the individual recipients
  • Who would benefit: All wikiprojects using the Echo extension, that has community-driven processes for consensus building
  • Proposed solution: Add link on a page that opens a special page for message delivery as notifications. Only users with sufficient rights should be able to send such mass messages. Let the special page be an user interface to "Autopromote", and use the results from that class to filter out users that should be recipients of the mass message. The mass message will then be delivered as a notification, possibly with a link back to the originating page.
  • More comments: It is likely that there should always be an originating page, as the notification itself should be small. Creation of a page describing the notification in-depth also makes the sender reflect about the why, what, and how s/he sends it.
It seems like there are several different use cases for creating recipients. One of them are sending a mass message to all contributors on a page or a list of pages (or category), while another is to send a mass message to all users watching a page or a list of pages (or category).
Common use cases are discussions about candidates for featured articles, and likewise for adminship. Both should have an originating page where the discussion takes place. Policy discussions are also a common use case.
  • Phabricator tickets:

Community discussion

  • This was originally considered as a feature for the Echo extension, but we were worried about it being over-used. I'm not necessarily arguing against this feature, just saying that we should be careful to avoid spamming people with too many notifications. Kaldari (talk) 01:00, 22 November 2016 (UTC)[reply]
I fully agree on that! It is although a lot better than using sitenotices to give information that only makes sense for a small number of people. Imagine elections of admins, where only some users are eligible to cast votes, and those users should be given a warning before the voting begins. — Jeblad 20:34, 22 November 2016 (UTC)[reply]
  • Instead of the proposal here I'd suggest a new WikiProject notification system that allows people to notify all members of a WikiProject of a new discussion (e.g. by a new notification-type or notification-alert-inbox). Spam is a problem here so I guess it needs WikiProject moderators that have to approve the notification first. --Fixuture (talk) 20:48, 30 November 2016 (UTC)[reply]
  • Maybe we need better targeted traditional mass messages rather than using notifications for them. I'm not sure that these should be combined. Stevie is the man! Talk • Work 15:39, 4 December 2016 (UTC)[reply]

Voting – Use notifications for mass messages

  1.   Support --Tarjeimo (talk) 21:53, 29 November 2016 (UTC)[reply]
  2.   Support This would be a great feature to have. For example, if something major is changing with a specific user right (say, Pending Changes Reviewer), then a notification could go out saying, "Hey, Deferred Changes is getting implemented! Read about it here!" or something like that. — Gestrid (talk) 20:52, 1 December 2016 (UTC)[reply]
  3.   Support SamanthaNguyen (talk) 03:20, 8 December 2016 (UTC)[reply]
  4.   Neutral per my comment above. Stevie is the man! Talk • Work 03:23, 8 December 2016 (UTC)[reply]
  5.   Weak oppose - My initial instinct is to like the idea from a basic ease/flexibility of communication standpoint. However, as I understand it this would create a mechanism for one-to-many (or one-to-one) communication that would not have a permanent public history record on-wiki. That puts it in an unusual class of communication that should be avoided if there's a reasonably acceptable substitute within existing systems. — Rhododendrites talk \\ 05:41, 8 December 2016 (UTC)[reply]
  6.   Support Miniapolis 16:53, 9 December 2016 (UTC)[reply]

Activate the warning on unsuccessful login attempts

  • Problem: Many Web-Forums and other IT-systems tell a user on login, if there have been unsuccessful login attempts. The user gets aware of hackers who attack their account by testing popular passwords. A mediawiki extension with this functionality has already been coded. All that needs to be done, is to activate it.
  • Who would benefit: Everyone with an account.
  • More comments: Maybe not the most important thing to do, but useful and can be done in short time with small ressources.

Community discussion

Voting – Activate the warning on unsuccessful login attempts

  1.   Support! — Gestrid (talk) 00:55, 28 November 2016 (UTC)[reply]
  2.   Support. No-brainer. Stevie is the man! Talk • Work 01:59, 28 November 2016 (UTC)[reply]
  3.   Support--Alexmar983 (talk) 05:28, 28 November 2016 (UTC)[reply]
  4.   Support BethNaught (talk) 08:16, 28 November 2016 (UTC)[reply]
  5.   Support--Wesalius (talk) 08:33, 28 November 2016 (UTC)[reply]
  6.   Support Samwalton9 (talk) 09:25, 28 November 2016 (UTC)[reply]
  7.   Support Jules78120 (talk) 12:39, 28 November 2016 (UTC)[reply]
  8.   Support --Kudpung (talk) 14:47, 28 November 2016 (UTC)[reply]
  9.   Support —MarcoAurelio 15:14, 28 November 2016 (UTC)[reply]
  10.   Support Sadads (talk) 15:41, 28 November 2016 (UTC)[reply]
  11.   Support – Meiræ 16:26, 28 November 2016 (UTC)[reply]
  12.   Support Nocowardsoulismine (talk) 18:37, 28 November 2016 (UTC)[reply]
  13.   Support Matěj Suchánek (talk) 21:58, 28 November 2016 (UTC)[reply]
  14.   Support Johnuniq (talk) 22:16, 28 November 2016 (UTC)[reply]
  15.   Support. Gamliel Fishkin 04:22, 29 November 2016 (UTC)[reply]
  16.   Support. I'd like it to be configurable. "One" might just be my own spelling mistake. StevenJ81 (talk) 18:01, 29 November 2016 (UTC)[reply]
  17.   Support – A great extension! Guycn2 · ☎ 18:58, 29 November 2016 (UTC)[reply]
  18.   Support --Telaneo (User talk page) 21:51, 29 November 2016 (UTC)[reply]
  19.   Support --Snaevar (talk) 01:09, 30 November 2016 (UTC)[reply]
  20.   Support --Matthiaspaul (talk) 01:51, 30 November 2016 (UTC)[reply]
  21.   Support I just wonder if the code has already been written, what the Community Tech Team is supposed to do? Just activate it? That seems an easy task :) 4nn1l2 (talk) 13:21, 30 November 2016 (UTC)[reply]
  22.   Support --Fixuture (talk) 20:41, 30 November 2016 (UTC)[reply]
  23.   Support: Kind of amazing it hasn't been done yet. O_o Julia\talk 23:04, 30 November 2016 (UTC)[reply]
  24.   Support -FASTILY 02:27, 1 December 2016 (UTC)[reply]
  25.   Support MER-C (talk) 05:28, 1 December 2016 (UTC)[reply]
  26.   Support --β16 - (talk) 16:06, 1 December 2016 (UTC)[reply]
  27.   Support Reasonable. --Vachovec1 (talk) 19:51, 1 December 2016 (UTC)[reply]
  28.   Support Louis Wu (talk) 21:40, 1 December 2016 (UTC)[reply]
  29.   Support → «« Man77 »» [de] 22:11, 1 December 2016 (UTC)[reply]
  30.   Support — KPFC 💬 23:02, 1 December 2016 (UTC)[reply]
  31.   Support czar 01:32, 2 December 2016 (UTC)[reply]
  32.   Support Draceane (talk) 10:12, 2 December 2016 (UTC)[reply]
  33.   Support —Jc86035 (talk) 11:14, 2 December 2016 (UTC)[reply]
  34.   SupportMaxBioHazard (talk) 11:46, 2 December 2016 (UTC)[reply]
  35.   Support Sannita - not just another it.wiki sysop 14:29, 2 December 2016 (UTC)[reply]
  36.   Support --Framawiki (talk) 20:37, 2 December 2016 (UTC)[reply]
  37.   Support -- SBaker43 (talk) 23:08, 2 December 2016 (UTC)[reply]
  38.   Support as an option people can turn on if they wish. Doc James (talk · contribs · email) 04:18, 3 December 2016 (UTC)[reply]
  39.   Support --Continua Evoluzione (talk) 14:53, 3 December 2016 (UTC)[reply]
  40.   Support --Yeza (talk) 13:07, 4 December 2016 (UTC)[reply]
  41.   Support -- the wub "?!" 15:39, 4 December 2016 (UTC)[reply]
  42.   Support --Rschen7754 04:50, 5 December 2016 (UTC)[reply]
  43.   Support Studmult (talk) 07:37, 5 December 2016 (UTC)[reply]
  44.   Support --Andropov (talk) 18:15, 5 December 2016 (UTC)[reply]
  45.   Support ArgonSim (talk) 20:16, 5 December 2016 (UTC)[reply]
  46.   Support --Tryptofish (talk) 23:27, 5 December 2016 (UTC)[reply]
  47.   Support --Hedwig in Washington (talk) 04:00, 6 December 2016 (UTC)[reply]
  48.   Support Muhraz (talk) 15:54, 6 December 2016 (UTC)[reply]
  49.   Support It is time for more conversations on security in Wikimedia projects. Blue Rasberry (talk) 19:17, 6 December 2016 (UTC)[reply]
  50.   Support Tiggerjay (talk) 20:55, 6 December 2016 (UTC)[reply]
  51.   Support Ks0stm (T•C•G) 21:14, 6 December 2016 (UTC)[reply]
  52.   Support. - Mailer Diablo (talk) 06:58, 7 December 2016 (UTC)[reply]
  53.   Neutral Please make it so that you can opt-out. I hate Google's stupid messages every time I log on through a new work computer... CFCF💌 📧 20:42, 7 December 2016 (UTC)[reply]
  54.   Support TheCatalyst31 (talk) 02:05, 8 December 2016 (UTC)[reply]
  55.   Support --𝔊 (Gradzeichen Diſk✉Talk) 04:20, 8 December 2016 (UTC)[reply]
  56.   Support -Amir (talk) 18:34, 8 December 2016 (UTC)[reply]
  57.   Support - Unclear what's the action to take if attempts are detected. DPdH (talk) 20:05, 8 December 2016 (UTC)[reply]
  58.   Support - Akela (talk) 21:49, 8 December 2016 (UTC)[reply]
  59.   Support Very useful. Espresso Addict (talk) 03:57, 9 December 2016 (UTC)[reply]
  60.   Support Lt2818 (talk) 11:07, 9 December 2016 (UTC)[reply]
  61.   Support Miniapolis 16:55, 9 December 2016 (UTC)[reply]
  62.   Support --Stryn (talk) 18:16, 9 December 2016 (UTC)[reply]
  63.   Support --Tarjeimo (talk) 23:07, 9 December 2016 (UTC)[reply]
  64.   Support —TheDJ (talk • contribs) 23:33, 9 December 2016 (UTC)[reply]
  65.   Support SamanthaNguyen (talk) 00:46, 10 December 2016 (UTC)[reply]
  66.   Support If sll that needs to be done is to activate it, then it won't divert from other, very urgent core issues. Actually, when this was proposed, although I had never realised that we didn't have this feature, I was actually amazed that we didn't have it. Just goes to prove how antiquated the MediaWiki software is and perhaps also the thinking that gors with its developemts. There are of course other requests this wishlist that are far more urgent and on which Wikipedia's very fabric and future reputation for content integrity stands. Kudpung (talk) 02:00, 10 December 2016 (UTC)[reply]
  67.   Support --g (talk) 11:22, 10 December 2016 (UTC)[reply]
  68.   Support --OrsolyaVirág (talk) 13:12, 10 December 2016 (UTC)[reply]
  69.   Support - Bcharles (talk) 14:40, 10 December 2016 (UTC)[reply]
  70.   Support – Definitely. Allen4names (talk) 20:40, 10 December 2016 (UTC)[reply]
  71.   Support --Chrumps (talk) 03:34, 11 December 2016 (UTC)[reply]
  72.   Support --Plagiat (talk) 18:24, 11 December 2016 (UTC)[reply]
  73.   Support — NickK (talk) 09:53, 12 December 2016 (UTC)[reply]

Add new inverted filter options to Special:Contributions

  • Who would benefit: Editors who want to know which of their contributions have been edited.
  • Proposed solution: Add an "Invert filter" checkbox which will mean the filters will "Only show edits that are not the latest revisions", "Only show edits that are not page creations", and "show only minor edits", if selected.
  • More comments: This alone wouldn't actually make my script redundant, because I also have the option to hide subsequent edits.
  • Phabricator tickets:

Community discussion

  • Mark Hurd's script is brilliant and has worked as an alternative watchlist for me for a long time. Being able to review changes since my changes has helped me catch some vandalism and unhelpful tinkering to changes I've made, without having to bloat my regular watchlist. This definitely should be "built in". Stevie is the man! Talk • Work 17:29, 13 November 2016 (UTC)[reply]

Voting – Add new inverted filter options to Special:Contributions

  1.   Support This would be very valuable to many editors and it is likely very easy to implement. Stevie is the man! Talk • Work 02:06, 28 November 2016 (UTC)[reply]
  2.   Support--Wesalius (talk) 08:33, 28 November 2016 (UTC)[reply]
  3.   Support Ninovolador (talk) 11:36, 28 November 2016 (UTC)[reply]
  4.   Support Jules78120 (talk) 12:41, 28 November 2016 (UTC)[reply]
  5.   Support --Alexmar983 (talk) 17:18, 28 November 2016 (UTC)[reply]
  6.   Support Nocowardsoulismine (talk) 18:39, 28 November 2016 (UTC)[reply]
  7.   Support --Izno (talk) 00:54, 29 November 2016 (UTC)[reply]
  8.   Support. Gamliel Fishkin 04:23, 29 November 2016 (UTC)[reply]
  9.   Support --YMS (talk) 16:34, 29 November 2016 (UTC)[reply]
  10.   Support --Telaneo (User talk page) 21:52, 29 November 2016 (UTC)[reply]
  11.   Support --Matthiaspaul (talk) 01:53, 30 November 2016 (UTC)[reply]
  12.   Support Alexei Kopylov (talk) 09:05, 30 November 2016 (UTC)[reply]
  13.   Support -FASTILY 02:27, 1 December 2016 (UTC)[reply]
  14.   Support MER-C (talk) 10:54, 1 December 2016 (UTC)[reply]
  15.   Support --Gerwoman (talk) 18:44, 1 December 2016 (UTC)[reply]
  16.   Support I do this process manually all the time. A built-in button would be great. —Patrug (talk) 23:57, 1 December 2016 (UTC)[reply]
  17.   Support Draceane (talk) 10:12, 2 December 2016 (UTC)[reply]
  18.   Support. LlamaAl (talk) 04:58, 3 December 2016 (UTC)[reply]
  19.   Support --Continua Evoluzione (talk) 14:55, 3 December 2016 (UTC)[reply]
  20.   Support --Andropov (talk) 18:16, 5 December 2016 (UTC)[reply]
  21.   Support ArgonSim (talk) 22:31, 5 December 2016 (UTC)[reply]
      Neutral I don't use the list too often that I need that I assume. --Hedwig in Washington (talk) 04:03, 6 December 2016 (UTC)[reply]
  22.   Support Muhraz (talk) 15:55, 6 December 2016 (UTC)[reply]
  23.   Support —Ynhockey (talk) 09:58, 7 December 2016 (UTC)[reply]
  24.   Support --Elmidae (talk) 15:51, 7 December 2016 (UTC)[reply]
  25.   Support This would be super useful. I use MarkHurd's script all the time. --Waldir (talk) 11:22, 10 December 2016 (UTC)[reply]
  26.   Support --g (talk) 11:23, 10 December 2016 (UTC)[reply]
  27.   Support — Ping08 (talk) 02:24, 11 December 2016 (UTC)[reply]
  28.   Support — NickK (talk) 09:54, 12 December 2016 (UTC)[reply]

Add section/tab reset buttons for user preferences

  • Problem: Currently, all user preferences have to be reset at once.
  • Who would benefit: Users.
  • Proposed solution: Add extra buttons for each tab and each section.
  • Phabricator tickets:

Community discussion

@Jc86035: In which situations is this needed and is this really needed for each tab and each section? Personally I'd be reluctant to add more and more options to the user interface if they are barely used so elaborating on the use cases is very welcome. --AKlapper (WMF) (talk) 14:43, 22 November 2016 (UTC)[reply]
@AKlapper (WMF): It's mostly something that would be mildly convenient. Something similar in function to the little d in the Commons preferences gadgets tab, like a list of defaults, would work as well. Jc86035 (talk) 15:00, 22 November 2016 (UTC)[reply]

Voting – Add section/tab reset buttons for user preferences

  Oppose Not convinced this is a problem; I highly doubt this feature would see very much use if implemented. -FASTILY 02:28, 1 December 2016 (UTC)[reply]
  Oppose Solution for a non-existing problem. --Hedwig in Washington (talk) 04:04, 6 December 2016 (UTC)[reply]

Add user profile images (avatars)

  • Problem: Users have no user images, making Wikipedia feel very anonymous and uninviting. Practically all major websites (not just social media, also sites like ebay, google, etc) allow users to have profile images (avatars). On Wikimedia sites there is no such thing, only a photo on a user page. It's not acceptable that users currently must upload their image to Commons and license it in such a way that anyone can then use their face for any purpose for all of eternity. (Yes, some protections come from personality rights which exist in some jurisdictions, but they do not offer protection everywhere, and users should not have to rely on personality rights to protect their image when they should never have been made to give up control of it through a copyleft license in the first place)
  • Who would benefit: You.
  • Proposed solution: Streamline user profile (avatar) image upload. Do not require users to give up rights to their own image.
  • Phabricator tickets: Phabricator has user profile images already. Phabricator users do not have to license their image with a copyleft license. Have a look how it's done there. Copy it for the rest of Wikimedia sites. Integrate it with Wikimedia functionality over time.

Community discussion

  • Wikipedia is not a social newtork and users are not here to develop their personality, they are here to build the encyclopedia and distribute free contents, which include free files. In case local projects decide to (strangely enough) allow the use of avatars, yes, they should be uploaded to Commons at Commons' conditions. --g (talk) 01:18, 11 November 2016 (UTC)[reply]
  • It's true that Wikimedia sites aren't for social networking, but perhaps photos of users helps people see that we're all just humans, and so be kinder to each other? (No idea, really.) Also, where would such an avatar be displayed, other than on user pages? It'd be nice to see it wherever usernames are shown, but that's mostly within other text and so an image wouldn't really work; wikis that use Flow could probably use an avatar to good effect. One other thing: everything on Phabricator is licenced under CC-BY-SA unless otherwise noted, so people do have to licence their image as copyleft to use it there (personally I don't think this is a problem). Sam Wilson 02:06, 11 November 2016 (UTC)[reply]
  • A possibility should be welcome, cooperative environments are not created by ideological limits. People put their images sometimes, why it should be an issue if this concept is also standardized, I don't see it. I never put my image, but I totally welcome your need, if it is shared by others. Just one thing, be sure people click on a statement that they are eighteen years old. That would be enough. A minor can even upload its own image now on commons for his profile, this would actually give slightly more legal protection.--Alexmar983 (talk) 04:34, 11 November 2016 (UTC)[reply]
  • Just wanted to point out the difference between a social networking service and a social network. As Samwilson says, we are not FOR social networking, but our users ARE a social network. And to some degree we already have avatars, in the form of people's customizable signature. See also Wikipedia:Facebookization. Also I support the challenges mentioned by g and Sam regarding the potential conflict with how people are used to dealing with avatar images, vs the licensing basics that we currently adhere to.. —TheDJ (talk • contribs) 11:25, 11 November 2016 (UTC)[reply]
  • Strong objections are raised every time this has come up in the past. Many of them are summarized in mw:User:Isarra/Avatars. TL;DR: This would create a massive amount of additional "friction" between users who disagree on what is "appropriate" as an avatar, and a massive amount of new policy/guideline requirements (and subsequent moderation/enforcement) on what is "acceptable" as an avatar. However, I do agree with the concern about people needing to use Commons, and I think that's worth further discussion, but not as part of this community wishlist because it will mainly be a question of what policy/setup we might want and that is not a software issue. Quiddity (talk) 20:42, 11 November 2016 (UTC)[reply]
  • I believe a setup of something similar down below that I wrote would have to be created:
    • Special pages:
      • Special:UploadAvatar - By default, any user who is not blocked should be able to have access to this special page.
      • Special:RemoveAvatar - By default, any user should be able to remove their own avatar. A different user right which would give the ability to remove other peoples avatars would be given to a set of staff members.
      • Special:Log/avatarupload (Avatar upload log) - For tracking when people upload an avatar.
      • Special:Log/avatarremove (Avatar removal log) - For tracking when people remove an avatar (whether it's their own or someone else's.)
    • User permissions:
      • avatar-upload - Any user who isn't blocked would be granted this right.
      • avatar-remove-own - Any user who isn't blocked would be granted this right.
      • avatar-remove-others - This user right would be given to a group of staff members (for which group would require a discussion)
    • Would have to be implemented into the Vector skin
  • Along with that, whether or not anons should be able to upload avatars would also require a discussion too. The social aspect is quite complicated because of making sure avatars are appropriate, and then the legal aspect aka licensing and copyright. Despite all of that, I support this and would love to help figuring out how all of it would work :) SamanthaNguyen (talk) 23:43, 11 November 2016 (UTC)[reply]
  • I agree with a previous comment: we are a social network of users, even if are not a social platform per se. The more the "internet of people" become "interconnected" with the" internet of things" and so on, this aspect evolves too. We can't be some type of dinosaur in the net on the long term. For example, we did introduce the ping, we allow meta page to work as general user pages everywhere, we are creating global language knowledge template for such pages... in a SUL perspective, if I want people so see my face, why you want me to copy-paste a code on the 5 or more platforms I'm active on instead of making my life simpler with a specific functionality? (not an unusual scenario: commons, data, meta are all crosswiki for example, people know foreign languages more than 10 years ago, they are active on many projects) Also think about the possibility to make a much stronger control on that picture, for example requesting its deletion on commons with a clic when replaced or removed (if commons users agree and don't see why they should have a problem with that) ... finally sometimes who you are is important. What if I need to know for a project for example if you're a women or a man, or if you're 18-25 or above 65? Sometimes there are content-related activities where this could matters. Maybe I don't understand your profile and even if you write that in Indonesian or Chinese, I just don't know. But I can see your picture. If it is ok for you, I can think of many reasons why it's ok for me as well.--Alexmar983 (talk) 04:47, 12 November 2016 (UTC)[reply]
  • Avatars/user photos on Wikipedia? Bonds get created between users for sure, and a lot of us go to meetups and conferences but WP is not a forum or a social networking site. For anyone who wants to put a mug shot on their page, uploading a photo to commons takes only a few seconds. I can't see justification for developing a purpose built feature for it. Kudpung (talk) 11:16, 13 November 2016 (UTC)[reply]
  • Repeatedly rejected perennial proposal. For many users, the standard of anonymity is a major plus. There are also numerous other major issues with this proposal that tend to be enumerated every time this comes up. --Yair rand (talk) 18:13, 13 November 2016 (UTC)[reply]
  • No matter the reasons for not having it, this is, of course, feasible and therefore will make it to the next round. I will oppose it on the grounds that there are much more important changes to make. However, given the proposer sticks to his guns, this will probably be the #1 pick when it comes to voting, and we'll have fun watching the staff find a "really, really good reason" to worm out of doing it. heh. But even if it becomes a reality, I suspect many wikis won't switch on this option unless and until they have a community consensus to do so. Stevie is the man! Talk • Work 17:59, 14 November 2016 (UTC)[reply]
  • Not very needed, but why not. We ARE a social network, even if we try to deny it. Few more friendly features wouldn't hurt. --Piotrus (talk) 08:06, 15 November 2016 (UTC)[reply]
  • I misread above "cooperative environments" as "corporate environment" and in a way this is actually true. We are volunteers, is there really a need to be "professional" and treat it everything as "work"? – Jberkel (talk) 12:34, 17 November 2016 (UTC)[reply]
even at work I often I have to provide a small image of me for a webmaster office or similar, which goes on the canteen or entrance card for example. Sometimes is compulsory, sometimes is not, sometimes it depends on the database. But it's there. Having or not having a profile image does not even make a platform a social media, come on... I didn't have my image on many social media for years. BTW in the end in its simplest implementation would be probably just a feature that makes you 1) upload a picture in an automatic special commons category with an automatic description 2) offer you a menu where you can select on which platform insert automatically that image on your user pages with a basic code and caption. I don't see how something like that, a likely scenario, could be an alteration of our "social ecosystem" more than the SUL and the cross-wiki ping. I guess it could be shown on some user activity summary page with your consensus. At the moment, I click on your user page of the most active platform and see if it is there, if I need to see your face, which I rarely do.Maybe we could forbid all profile-like image... just to prove a point ;)--Alexmar983 (talk) 13:13, 17 November 2016 (UTC)[reply]
  • This could be easily done as a labs tool (get account access via OAUth, upload image to Commons, add it to top of user page). Probably as part of some "generate user page from a template" system. --Tgr (WMF) (talk) 03:37, 18 November 2016 (UTC)[reply]

Info: If you go to the preferences in german wikipedia to section Helferlein (Gadgets) and choose "Navigations-Popups" (first in Navigation) you get a feature similar to Hovercards (Beta-Section), but it also works in talk and user name spaces. So if a user has a picture on his user page, this will be displayed, if you hover over the signature of the user - practically making this the users profile image. --𝔊 (Gradzeichen Diſk✉Talk) 11:04, 18 November 2016 (UTC)[reply]

Voting – User profile images (avatars)

  1.   Support--Shizhao (talk) 02:46, 28 November 2016 (UTC)[reply]
  2.   Support--Alexmar983 (talk) 05:23, 28 November 2016 (UTC)[reply]
  3.   Oppose This would be a nightmare to administer in terms of removing unacceptable images and patrolling for copyright violations. Moreover there isn't really anywhere avatars could be used except in Flow. Please don't add such an administrative burden to admins and patrollers. I'm getting déjà vu from Gather... BethNaught (talk) 08:16, 28 November 2016 (UTC)[reply]
  4.   Oppose not because this is necessarily a "bad" idea, but because there are far more important changes needed to improve the development of the wikis. And, as others have discussed, this is not altogether simple to implement when all aspects are considered. Stevie is the man! Talk • Work 14:22, 28 November 2016 (UTC)[reply]
  5.   Oppose for the reasons I mentioned above. --Kudpung (talk) 15:15, 28 November 2016 (UTC)[reply]
  6.   Oppose If you want bling, use a bling website. Johnuniq (talk) 22:17, 28 November 2016 (UTC)[reply]
  7.   Oppose You can go to the user page to learn more about a user. Aracali (talk) 03:29, 29 November 2016 (UTC)[reply]
  8.   Oppose. 1. Wikipedias and other Wikimedia's wikis are not social networks like VK and Facebook. 2. The purpose of user signature is just to identify the user, more detailed information can be placed on user's personal page. 3. If you do not want to provide some your work under free licences, just do not post that work into Wikipedia and other Wikimedia's wikis. Gamliel Fishkin 04:31, 29 November 2016 (UTC)[reply]
  9.   Oppose This is a project to build an encyclopedia, not a chat or social meeting platform. User avatars are irrelevant and would only cause distraction from our goals. --Matthiaspaul (talk) 02:00, 30 November 2016 (UTC)[reply]
  10.   Support SamanthaNguyen (talk) 04:37, 30 November 2016 (UTC)[reply]
  11.   Oppose 4nn1l2 (talk) 13:26, 30 November 2016 (UTC)[reply]
  12.   Oppose On the contrary, I think avatars will contribute to the alienation of less serious/dedicated/obsessed users. At present, the minimum to be "accepted" as a community member/editor/user is a blue-linked user page. That's pretty simple, and easy to see, easy to create, etc. I'm sure we've all experienced the feeling we get about users on websites - forums, Facebook, Twitter, etc - when we don't see an avatar or profile photo. "They must not come here often." "Maybe this is a spam profile." "I'm not going to follow them, they probably won't have much to contribute." Do we really want to create ANOTHER hurdle to inclusion in Wikimedia projects? (And hurdle is not facetious, uploading teeny tiny profile photos is a pain, and every site's requirements are different.) That's my main objection, but also in reality I imagine thousands of editors will never bother. Many, many editors don't customise their signatures, and that functionality has been around for ages. If this proposal were implemented, it would probably achieve nothing but a small subset of very active editors feeling very pleased with their avatar while everyone else ignores it. Julia\talk 23:25, 30 November 2016 (UTC)[reply]
  13.   Oppose No. -FASTILY 02:27, 1 December 2016 (UTC)[reply]
  14.   Oppose Absolutely not. MER-C (talk) 05:29, 1 December 2016 (UTC)[reply]
  15.   Oppose, Wikipedia is not social network and social media. Beagel (talk) 18:22, 1 December 2016 (UTC)[reply]
  16.   Oppose Not in the philosophy of this site. Semmendinger (talk) 19:50, 1 December 2016 (UTC)[reply]
  17.   Oppose Ugh. Definitely not. --Vachovec1 (talk) 19:53, 1 December 2016 (UTC)[reply]
  18.   Oppose → «« Man77 »» [de] 22:13, 1 December 2016 (UTC)[reply]
  19.   Oppose Jmvkrecords ⚜ (Intra talk) 08:25, 2 December 2016 (UTC).[reply]
  20.   Oppose Draceane (talk) 10:15, 2 December 2016 (UTC)[reply]
  21.   Neutral Mostly because I am uncertain on the consequences. The "we are not a social network" arguments in my eyes have no merit, there is a big difference between having users interact with each other (a prerequisite for a collaborative project, anyhow) and a full blown social network. Jo-Jo Eumerus (talk, contributions) 16:08, 2 December 2016 (UTC)[reply]
  22.   Neutral You can put picture on your user page. Doc James (talk · contribs · email)
  23.   Support Daylen (talk) 06:15, 3 December 2016 (UTC)[reply]
  24.   Oppose no. Jianhui67 talk★contribs 10:04, 3 December 2016 (UTC)[reply]
  25.   Oppose --Slb nsk (talk) 18:53, 3 December 2016 (UTC)[reply]
  26.   Oppose --Ping08 (talk) 02:22, 4 December 2016 (UTC)[reply]
  27.   Oppose This isn't Facebook. --Rschen7754 04:49, 5 December 2016 (UTC)[reply]
  28.   Oppose Studmult (talk) 07:38, 5 December 2016 (UTC)[reply]
  29.   Oppose --Andropov (talk) 18:18, 5 December 2016 (UTC) No need.[reply]
  30.   Oppose Aren't user pages and custom signatures dedicated to that? ArgonSim (talk) 20:18, 5 December 2016 (UTC)[reply]
  31.   Oppose as completely contrary to the purpose of the enterprise. --Tryptofish (talk) 23:29, 5 December 2016 (UTC)[reply]
  32.   Strong oppose Commons is not Facebook or a chat platform. --Hedwig in Washington (talk) 04:06, 6 December 2016 (UTC)[reply]
  33.   Oppose THis is a terrible idea. Muhraz (talk) 15:56, 6 December 2016 (UTC)[reply]
  34.   Oppose — Rhododendrites talk \\ 05:43, 8 December 2016 (UTC)[reply]
  35.   Support Why not. --Piotrus (talk) 13:18, 8 December 2016 (UTC)[reply]
  36.   Oppose. Harmful to the norms of anonymity, more likely to cause users to place the person before the edit(s), and completely outside the goals of the movement. --Yair rand (talk) 18:24, 8 December 2016 (UTC)[reply]
  37.   Oppose as said above --g (talk) 11:28, 10 December 2016 (UTC)[reply]
  38.   Neutral Я сам часто хочу увидеть лицо других участников, и по этому эта идея мне нравится, далшая польза может быть от того, что администраторов, которые своё лицо уже публично показали, это принудит использовать своих прав ответственно, что на чешской википедим можно заметить - чем меньше на странице участника, тем морально худший участник, потому что скрывается за анонимность, большинство админов цсвики анонымних и никто, кто сам не придёт на викисраз (или встречу участников), не узнает, кто они на самом деле, и по этому, также думают, что не несут никакой ответственности. Но с другой стороны, участникам, которые станут жертвой преследования, будто администраторами, или кем то другим это принесёт только неприятности. Я бы просто сказал что это полезная идея для всех, но тем, кто воспользуются этой возможностью без розмысла, или им просто не повезёт, может принести серьёзный ущерб.--TOMA646 (mail | talk) 14:47, 10 December 2016 (UTC)[reply]
  39.   Oppose WP:NOT#FACEBOOK. Will slow loading time. Will get attractive women harassed. Many images would be copyvios. Will take up valuable screen space. You can already put a "profile" pic on your userpage (I do, as do many others).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:38, 11 December 2016 (UTC)[reply]
  40.   Strong oppose WP is not "Face de bouc" --Alaspada (Talk) 20:40, 11 December 2016 (UTC)[reply]
  41.   Oppose FoCuSandLeArN (talk) 23:04, 11 December 2016 (UTC)[reply]
  42.   Oppose, Wikipedia is not a social network. We already have avatars on Phabricator and honestly I don't think they work the way described here: while WMF staffers often have their photos, most other users have either default images or some random stuff. If one wants to use a picture, they can already do put it on their user page. However, many people do not, and it should not be mandatory — NickK (talk) 10:06, 12 December 2016 (UTC)[reply]

Allow a second email address (wikimail, password reset, notifications)

  • Problem: The same email address is used for wikimail and password recovery.
    For password recovery an address with a secure mail provider is a good choice. For wikimail on the other hand a throw-away-mail-address, that can be easily replaced, if it becomes known to a stalker or the public, makes more sense.
  • Who would benefit: This is especially true for accounts with additional rights and prolific authors. These groups cannot work without wikimail and are unlikely to abstain from the possibilty to recover a lost password.
  • Proposed solution: Add the option to specify a second email address in the preferences for all users.
    Add the following global preferences (email and password are already global):
    • checkboxes to select what email address to use with wikimail or none at all
    • checkboxes to select what email address to use for password recovery or none at all
      • if both boxes are checked, different temporary passwords are sent to both addresses and both are needed to login
    • checkboxes to select what email address to use for echo and other notifications
    • in a more ambitious additional approach the local echo preferences could allow the configuration of every notification type to be sent onwiki, to first address, to second address
    • checkboxes to send a TAN to either of the adresses on login (achieving a cheap way of 2FA, at least until true 2FA is implemented)
  • In a given time frame only one email address can be changed. A confirm message is sent to the new address and additionally a "cancel the change" message is sent to the other unchanged address.
  • The option of two addresses would allow the use of a throw-away-email-address for wikimail. So if this address becomes known to a stalker, you can simply change this address, while keeping your secret secure email address for all other uses.
  •  
    preferences page
  •  
    notfications preferences
  •  
    change a mail address
  •  
    change a mail address
  •  
    signup
  • More comments: Nothing changes for any user who does not specify an email address or stays with one address.

Community discussion

This is good, but how if newbie can learn, it may be confused?Murbaut (talk) 14:14, 15 November 2016 (UTC)[reply]
I like the idea of being able to set a separate address for communications and for password security, but "if both boxes are checked" i would send one temp passcode to both addresses so that either could be used for recovery. If higher security is required i would use something other than a second emailed code. Being locked out of an email account because it was hacked or the password was lost and forgotten, is not rare. Bcharles (talk) 23:04, 15 November 2016 (UTC)[reply]

Voting – Allow a second email address

  1.   Support--Wesalius (talk) 08:34, 28 November 2016 (UTC)[reply]
  2.   Support Samwalton9 (talk) 09:19, 28 November 2016 (UTC)[reply]
  3.   Support SamanthaNguyen (talk) 04:40, 30 November 2016 (UTC)[reply]
  4.   Support --MGChecker (talk) 15:13, 4 December 2016 (UTC)[reply]
  5. Weak   Support Would be nice, but very low priority Imo -FASTILY 22:15, 4 December 2016 (UTC)[reply]
  6.   Support --Alexmar983 (talk) 07:09, 5 December 2016 (UTC)[reply]
  7.   Support --Hedwig in Washington (talk) 04:07, 6 December 2016 (UTC)[reply]
  8.   Support Muhraz (talk) 15:56, 6 December 2016 (UTC)[reply]
  9.   Support weakly. Good idea, but extreme low priority. Tiggerjay (talk) 20:56, 6 December 2016 (UTC)[reply]
  10.   Support. - Mailer Diablo (talk) 06:59, 7 December 2016 (UTC)[reply]
  11.   Support — Rhododendrites talk \\ 05:44, 8 December 2016 (UTC)[reply]
  12. Weak   Support per Fastily. Stevie is the man! Talk • Work 14:02, 8 December 2016 (UTC)[reply]
  13.   Support - DPdH (talk) 20:07, 8 December 2016 (UTC)[reply]
  14.   Support Miniapolis 15:54, 9 December 2016 (UTC)[reply]
  15.   Support --R. S. Shaw (talk) 17:57, 9 December 2016 (UTC)[reply]
  16.   Support --Carnildo (talk) 01:53, 10 December 2016 (UTC)[reply]
  17.   Support --g (talk) 10:12, 10 December 2016 (UTC)[reply]
  18.   Support - Bcharles (talk) 15:18, 10 December 2016 (UTC)[reply]
  19.   Support --NaBUru38 (talk)
  20.   Support --𝔊 (Gradzeichen Diſk✉Talk) 06:42, 11 December 2016 (UTC)[reply]
  21.   Support Good. --  AnselmiJuan (discusión) 12:06, 11 December 2016 (UTC)[reply]
  22.   Weak support, very low priority, and allow using second email address only for password recovery to avoid abuse — NickK (talk) 10:08, 12 December 2016 (UTC)[reply]

Allow users to restrict who can send them email

  • Problem: As a victim of harassment, I want control over who can send me email via Special:Emailuser. Email provides a medium for harassment that is private and cannot be monitored or controlled easily when sockpuppets are involved.
  • Who would benefit: Everyone, as long as it is integrated into core MediaWiki.
  • Proposed solution: Right now, I have only two options—accept emails from all users, or no emails whatsoever. This proposal would change this to the following:
  • Allow { all users | autoconfirmed users only | admins only | nobody } (or other predefined groups) to send me email.
  • Prevent $BLACKLIST_OF_USERS from sending me email regardless of their permission level.
  • Allow $WHITELIST_OF_USERS to send me email regardless of their permission level.
  • More comments:
  • $BLACKLIST_OF_USERS may be made available to trusted users to investigate harassment complaints -- after all, if a user is blacklisted by multiple other users action may need to be taken. This is a strictly optional part of this proposal.

Community discussion

Nota Bene: I talked with BethNaught about our proposals some month ago. I had hoped to merge the ideas, but he thought mine to be to complicated and seemed to expect a quicker solution for his proposal. The problem I see with this idea: People will only activate this feature at a time a spammer already has their email address and no longer needs to use wikimail. --𝔊 (Gradzeichen Diſk✉Talk) 09:52, 7 November 2016 (UTC)[reply]

This feature is specifically intended to counter the use of Special:Emailuser to send harassment and spam emails. If I recall correctly, receiving an email through Special:Emailuser does not disclose your email address -- it is disclosed if you reply via email. If a spammer already has your email address there is nothing we can do. MER-C (talk) 12:19, 7 November 2016 (UTC)[reply]
Yes, quite. If person A sends person B an email using EmailUser, person A does not receive person B's address. Person B could then block or protect against person A, who would no longer have any way to email person B. You (Gradzeichen) seem to misunderstand how EmailUser works. BethNaught (talk) 16:09, 7 November 2016 (UTC)[reply]
Also note that email addresses already do get disclosed on mail delivery failure (which can have various reasons, e.g. mail provider policies). --AKlapper (WMF) (talk) 19:06, 7 November 2016 (UTC)[reply]
Oh shit. How come that hasn't been fixed in over a year? Even if the failure isn't handled the leak needs to be plugged. (Thanks for the info, I guess :/ ) BethNaught (talk) 22:37, 7 November 2016 (UTC)[reply]
To clarify, it appears that that bug was actually fixed a while ago, but the people who fixed it weren't aware of the bug, so they didn't close it. BWolff (WMF) (talk) 17:36, 23 November 2016 (UTC)[reply]

Is there some way, if person A - who must be registered editor - sends person B a harassing or spam email using EmailUser, for person B to report the email as harassment? If not, there should be. And if there is, wouldn't it be a good idea to add that at the end of every email? ["If you want to report this email as inappropriate, forward it to bademail@wikimedia.org, with a brief explanation."] -- John Broughton (talk) 01:15, 8 November 2016 (UTC)[reply]

A dumb spammer may indeed only use Special:EmailUser to send messages and never care to get an answer. But as soon as this feature gets implemented, even the dumbest spammer will soon learn to send a friendly request with EmailUser, triggering the victim to give a helpful answer. At that point the spammer has the email address and can now send harrassment from a different sender address (with the additional benefit of not burning his wiki-account, because the identity of his wikimail address and the other email address cannot be proved). This feature is useful for a short time after its implementation and from than on against dumb spammers. An alternative approach (used by many forums and marketplaces) is not to expose the email addresses in wikimail, but to assign temporary addresses for wikimail communication, but this would require routing all this mail through wikimedia servers... --𝔊 (Gradzeichen Diſk✉Talk) 07:47, 8 November 2016 (UTC)[reply]

I remember some discussion about this sort of centrally-mediated user emailing system in the discussions about https://discourse.wmflabs.org (but I can't find it now, sorry). Certainly, if Discourse were to be continued with, it has this functionality built in. Sam Wilson 08:12, 8 November 2016 (UTC)[reply]
Replying via email is something you have control over, and is something I refrain from unless absolutely necessary. That said, it's fairly trivial to change the sender's email address to, say, MER-C no-reply wikimedia org and discard any emails sent to that address. I'll propose this below. MER-C (talk) 06:28, 9 November 2016 (UTC)[reply]

I'm a bit against this feature: even if admins are not required to enable the Special:Emailuser, there might be selected groups of users that we expect to leave an open door for legitimate emails from anyone in case of particular needs (i.e. checkusers). When we visit their user page, we could read the link to the mailing page, but we wouldn't know any more if that user is really accepting mail from any user (as he perhaps should, in given cases). We would then loose the objective immediate information about whether the user generically accepts mail from anyone or not.
However, no one is required to answer to trolls, no one is forced to use a given e-mail address to answer, and it's no shame to put trolls into /IGNORE mode and directly divert spammers' artworks to the dustbin. Either you accept mail or you don't, I think it's simpler and cleaner --g (talk) 18:44, 10 November 2016 (UTC)[reply]

I like the idea of this as I like to leave email on for private info that can't/shouldn't be added on wiki but it would be useful to be able to set to "autoconfirmed users only". KylieTastic (talk) 14:10, 13 November 2016 (UTC)[reply]

@Gradzeichen: If I get a mail from someone I don't want to give my email address, I reply on their talk page (avoiding relevant information sent in the email, of course). --mfb (talk) 12:25, 14 November 2016 (UTC)[reply]

Mfb To put it blunt: This is not for you. You are a power user, you know what you do, you can handle this type of situation. Even wikipedia is not for you. Wikipedia is for people who are not computer savvy, people who create accounts on facebook, twitter, amazon, ebay. people who use the internet and wonder when someone starts to harrass them. this are friendly people. If you send them a message, they answer. And they answer by clicking "respond". In the case of wikipedia they expose their email address. Now, if they answer unknowingly to a spammer/stalker/troll - all is lost. Only at this point they will start to find ways to handle the situation. Whatever solution will be chosen: It has to be one, that works for new users *before* the harrassment starts. This could be done with my proposal of two addresses. This could be done with wikimedia-generatad temporary addresses, or with an other method. BethNaught's idea is helpful, but only to a limit. --𝔊 (Gradzeichen Diſk✉Talk) 12:53, 14 November 2016 (UTC)[reply]
that's true. Some people are truly wiki, they assume it should be nice to answer. They realized too late they shouldn't have.--Alexmar983 (talk) 02:55, 16 November 2016 (UTC)[reply]

Voting – Allow users to restrict who can send them email

  1.   Support BethNaught (talk) 08:16, 28 November 2016 (UTC)[reply]
  2.   Support. Samwalton9 (talk) 09:20, 28 November 2016 (UTC)[reply]
  3.   Support —MarcoAurelio 15:13, 28 November 2016 (UTC)[reply]
  4.   Support Sadads (talk) 15:34, 28 November 2016 (UTC)[reply]
  5.   Support Ocaasi (talk) 18:35, 28 November 2016 (UTC)[reply]
  6.   Oppose as argued at 07:47, 8 November 2016 (UTC). Gamliel Fishkin 03:57, 29 November 2016 (UTC)[reply]
  7.   Support as proposer. MER-C (talk) 06:05, 1 December 2016 (UTC)[reply]
  8.   Support I believe the pros outweigh the cons. This, in combination with #Provide a dummy email address, would be a great idea. — Gestrid (talk) 21:02, 1 December 2016 (UTC)[reply]
  9.   Support NMaia (talk) 02:54, 2 December 2016 (UTC)[reply]
  10.   Support Jmvkrecords ⚜ (Intra talk) 08:27, 2 December 2016 (UTC).[reply]
  11.   Support ie. autopatrolled, administrators ... --Framawiki (talk) 20:38, 2 December 2016 (UTC)[reply]
  12.   Support Opabinia regalis (talk) 04:25, 4 December 2016 (UTC)[reply]
  13.   Support --Yeza (talk) 13:10, 4 December 2016 (UTC)[reply]
  14.   Support Stevie is the man! Talk • Work 16:02, 4 December 2016 (UTC)[reply]
  15.   Support Studmult (talk) 07:38, 5 December 2016 (UTC)[reply]
  16.   Neutral I worry that users might block emails that they really need to receive. --Tryptofish (talk) 23:32, 5 December 2016 (UTC)[reply]
  17.   Oppose Same as dummy email --Hedwig in Washington (talk) 04:09, 6 December 2016 (UTC)[reply]
  18.   Oppose It is very simple to set up a filter through your e-mail provider so that spam from certain addresses or containing certain phrases (e.g. "sent by User:Spammer") automatically goes to the spam folder. Getting around this filter is pretty easy if a user registers new e-mail addresses to spam you, but you can have the exact same problem with users registering new WP-accounts to send you harassment.
    At best this is a waste of resources for something you can solve yourself in 5 minutes.
    At worst it is a waste of resources that doesn't even solve the problem. CFCF💌 📧 20:48, 7 December 2016 (UTC)[reply]
  19.   Support - DPdH (talk) 20:09, 8 December 2016 (UTC)[reply]
  20.   Support Miniapolis 15:56, 9 December 2016 (UTC)[reply]
  21.   Oppose --g (talk) 10:13, 10 December 2016 (UTC)[reply]
  22.   Support - Bcharles (talk) 15:08, 10 December 2016 (UTC)[reply]
  23.   Oppose as this will not resolve anything. On one hand, if you are a harassment victim you can already set your mailbox to reject emails from certain people or at least discard it immediately. On the other hand, it is very easy to game this feature by simply setting a new account with the same email, making this effort just useless. I would prefer let individual users decide how to manage their mailbox instead of putting it on Wikimedia servers — NickK (talk) 10:15, 12 December 2016 (UTC)[reply]
  24.   Support Guettarda (talk) 16:45, 12 December 2016 (UTC)[reply]

Allow users to restrict who can send them notifications

This proposal is identical to 2016 Community Wishlist Survey/Categories/Miscellaneous#Allow users to restrict who can send them email , except it applies to notifications and pings instead. Blacklists and whitelists may or may not be shared, I'll leave this up to community discussion.

Community discussion

All good proposals, @MER-C: but I should point you to the survey policy which states you're limited to 3 proposals. Just so you know. :) Thanks for participating. -- NKohli (WMF) (talk) 08:39, 7 November 2016 (UTC)[reply]

I'll be happy to take over as the proposer if MER-C wants to pare down his proposals. Anyway, I've been a part of a very difficult talk page discussion where a couple particular users saw fit to harass me with pings even after I requested that they didn't need to ping me. I had to turn off pinging altogether for periods of time. I would have rather blocked these specific users from pinging me. Stevie is the man! Talk • Work 00:31, 8 November 2016 (UTC)[reply]

I'll just note that it's a lot easier to get away with harassing someone via excessive notifications (just mention their user name every time you make a comment in a discussion thread) than with email (you have to invent a plausible reason to send the email, and do a lot more typing). So being able to turn off pings/notifications from a specific user sounds like a good idea to me. (A whitelist is less defensible, I think. It seems to me that the effort to create sockpuppets, for pinging, or to mobilize other problematical users to do pinging, would be more effort than it's worth, since adding a name to a blacklist could be very quick.) -- John Broughton (talk) 01:22, 8 November 2016 (UTC)[reply]
If we're going to stick with the arbitrary and counterproductive limitation of three proposals per person, then I'm happy for someone to take this over. MER-C (talk) 02:30, 8 November 2016 (UTC)[reply]

Is there a Phabricator task for this? I wrote the code for it (gerrit:320718). I would appreciate if someone could file a task for this if one doesn't exist yet. Legoktm (talk) 04:38, 10 November 2016 (UTC)[reply]

Done: phab:T150419. MER-C (talk) 12:34, 10 November 2016 (UTC)[reply]

I think the idea has potential. But what about an harassment that is done using this functionality? For example a group of users all disactivate the ping of another user as a form of psychological pressure? I would say that a user should not be excluded from more than another user, to prevent that. As soon as this is done a second time, than maybe there is an issue and it should be discussed in a community environment. I would put that limit, it can't be just a shortcut. Also, is it in the wiki spirit that this is forever, or it should be considered always a temporary measure? Third question: should the log book of an user's personal notification management be private or public? Fourth question: would the user be informed if (s)he is excluded from effectively pinging another user? Because if (s)he is, this also proves the possibility of a reverse group harrassment, and in a wiki spirit it should be temporary. If something like that happens, people should always try to resolve the issue. Or what if it is just a mistake for example because a slip of the mouse? You see, there are small aspects but the way they are combined shape a completely different vision of a wiki environment.--Alexmar983 (talk) 04:35, 12 November 2016 (UTC)[reply]

I imagine these blocks as private, without notifications to those blocked. And they are as "temporary" as entries on a watchlist; that is, the user would be able to edit their list and remove anyone they're blocking. As far as reverse harassment is concerned, I suppose this is a kind of a passive-aggressive thing, but I think the ultimate harm is minimal because, in an active discussion, these users may well come back and see the comment with the blocked ping. It will just be on their own time, without the nag. :) Stevie is the man! Talk • Work 20:29, 20 November 2016 (UTC)[reply]
  • As someone who belongs to the camp of those who like to be notified, and one who probably annoys some editors when notifying them, I wonder if there is a way to let others know which a camp one belong to. Ottawahitech (talk) 22:41, 22 November 2016 (UTC)please ping me[reply]

Voting – Allow users to restrict who can send them notifications

  1.   Support. Ping abuse is real. Stevie is the man! Talk • Work 02:00, 28 November 2016 (UTC)[reply]
  2.   Support the overall research in that direction. Of course the tool will require additional "social" discussion.--Alexmar983 (talk) 05:25, 28 November 2016 (UTC)[reply]
  3.   Support BethNaught (talk) 08:16, 28 November 2016 (UTC)[reply]
  4.   Support Samwalton9 (talk) 09:20, 28 November 2016 (UTC)[reply]
  5.   Support —MarcoAurelio 15:13, 28 November 2016 (UTC)[reply]
  6.   Support Ocaasi (talk) 18:36, 28 November 2016 (UTC)[reply]
  7.   Support Gamliel Fishkin 03:58, 29 November 2016 (UTC)[reply]
  8.   Support ThePlatypusofDoom (talk) 17:27, 29 November 2016 (UTC)[reply]
  9.   Support as proposer. MER-C (talk) 06:05, 1 December 2016 (UTC)[reply]
  10.   Support Opabinia regalis (talk) 04:26, 4 December 2016 (UTC)[reply]
  11.   Support --Yeza (talk) 13:12, 4 December 2016 (UTC)[reply]
  12.   Support --MGChecker (talk) 15:12, 4 December 2016 (UTC)[reply]
  13.   Oppose I don't see any harm in a notification Studmult (talk) 07:39, 5 December 2016 (UTC)[reply]
  14.   Oppose I believe that reporting that user for harassing you should suffice, since turning off notifications from someone who's not actually pestering you goes totally against the notion of a community. ArgonSim (talk) 20:26, 5 December 2016 (UTC)[reply]
  15.   Oppose I agree with ArgonSim. I also want to point out that editors can configure what kinds of notifications that they do or do not receive. More editors should make use of that ability. --Tryptofish (talk) 23:34, 5 December 2016 (UTC)[reply]
  16.   Oppose If someone pings with BS, -> info to admin -> block -> end of story. No need for a ton of coded ballast. --Hedwig in Washington (talk) 04:11, 6 December 2016 (UTC)[reply]
  17.   Comment When pings are overused/abused by users in talk page conversations, it may just be in a heated discussion (like what happened at en:Talk:Kim Davis (county clerk) last year), and therefore it seems a stretch to report those doing the pinging, and I'm not sure there are policies to deal with them anyway. Ultimately this has to do with cutting down on annoyances/distractions while we are working in the wikis. And while blocking all pings is an option, it is also the equivalent of swatting a fly with a sledgehammer. I just want to swat the damn flies with a fly swatter sometimes. I don't think this is too much to ask. Stevie is the man! Talk • Work 11:30, 6 December 2016 (UTC)[reply]
  18.   Oppose Unnecessary. Muhraz (talk) 15:57, 6 December 2016 (UTC)[reply]
  19.   Oppose Just as you can ask someone not to post to your talk page, you can ask them not to ping you—and if they persist regardless, there's cause for intervention. As with that, however, there are times when a missing message does more harm than good—and I can foresee a whole lot of instances of people missing important communications because of this. — Rhododendrites talk \\ 05:50, 8 December 2016 (UTC)[reply]
    Well, right now, we can stop all pings, and this is really our only way to immediately stop abusive/overused pings. Reporting is slow and iffy. So, without this proposal going forward, what you foresee about missing important communications is what is more likely to occur. This proposal with regard to blacklisting is about ignoring the pings from specific users—I highly doubt users would miss much communications because of this. If they are cutting off a group from notifying them, at least that's not everyone like they can do now. Stevie is the man! Talk • Work 13:31, 10 December 2016 (UTC)[reply]
  20.   Support Miniapolis 15:58, 9 December 2016 (UTC)[reply]
  21.   Oppose --g (talk) 10:14, 10 December 2016 (UTC)[reply]
  22.   Oppose Inutility --Alaspada (Talk) 02:49, 11 December 2016 (UTC)[reply]
  23.   Oppose All notifications are public and can be easily tracked. If someone is abusing notifications, we must sanction this user instead of inventing turnarounds — NickK (talk) 10:17, 12 December 2016 (UTC)[reply]
  24.   Support SarahSV talk 17:00, 12 December 2016 (UTC)[reply]
  25.   Oppose --Mikheil Talk 21:07, 12 December 2016 (UTC)[reply]

American Sign Language (ASL) functionality for Wikipedia pages

  • Who would benefit: All deaf readers who use sign language, between 250,000 and 500,000 and anyone who is interested in learning a few signs.
  • Proposed solution: Add some lines of javascript to Wikipedia that will access the SMARTSign Dictionary (best viewed in Chrome browser)that would allow the reader to select a word in a Wikipedia page and then be shown the ASL video via the SMARTSign Dictionary. For a sample of how it could function and look go to this sample page and click on any word and the sign video appears. The same could happen on a Wikipedia page. I already have the code to make this happen with some tweaks. The SMARTSign Dictionary is a project of the Center for Accessible Technology in Sign (CATS). This is the largest English-ASL dictionary in the world and currently covers 80,000 words and will double in the next year. It was built specifically for tasks like the one described here. I am the director of the project so no other permissions are needed.
  • More comments: Adding a few lines of javascript could make Wikipedia truly accessible to deaf readers
  • Phabricator tickets:

Harley Hamilton- I am a research scientist at Georgia Tech, developed the SMARTSign Dictionary and direct CATS

Community discussion

  • @Yair rand: This would not be a word-for-word translation feature. It is an accessibility feature that would allow access for any reader to ASL video for unknown English words. We already have a browser extension for this but it does not work on Wikipedia as Wikipedia blocks YouTube video which is where all our video is stored and served. Also, by adding a few lines of code Wikipedia moves more towards a universal design format. Regardless of whether 500,000 is considered a small group it is still a group that deserves accessibility to the information in Wikipedia. Adding the functionality I suggest would support deaf readers making Wikipedia a truly accessible and usable tool. Currently, it is not such a tool for most deaf readers. This functionality has been shown to increase the vocabulary knowledge and reading comprehension of deaf readers —The preceding unsigned comment was added by Hhamilton (talk) 23:56, 7 November 2016 (UTC)[reply]
    • Why (and how?) does "Wikipedia block YouTube video"? (Could someone add a link to that browser extension?) Wouldn't it be much simpler to fix that block (so that it doesn't happen) than to write more code, whether an extension that has to be maintained or code that is part of every MediaWiki installation? -- John Broughton (talk) 01:27, 8 November 2016 (UTC)[reply]
  • Is there any reason why these videos cannot be uploaded to Commons? This would make this proposal a gadget problem well within volunteer development capability or a dedicated accessibility team, as opposed to a Community Tech one. On that basis, given the highly limited impact, I would have to say no. MER-C (talk) 07:01, 9 November 2016 (UTC)[reply]

Voting – ASL functionality for Wikipedia pages

  1.   Oppose. Gamliel Fishkin 04:00, 29 November 2016 (UTC)[reply]
  2.   Oppose, they can read it. --Fixuture (talk) 22:14, 29 November 2016 (UTC)[reply]
  3.   Neutral Wouldn't wiktionary be a better target for this? Aracali (talk) 05:45, 1 December 2016 (UTC)[reply]
  4.   Comment Honest question, why can't they just read the page? Semmendinger (talk) 19:51, 1 December 2016 (UTC)[reply]
  5.   Oppose. --Yair rand (talk) 20:23, 1 December 2016 (UTC)[reply]
  6.   Oppose duplicates what is already on Incubator. --Rschen7754 04:48, 5 December 2016 (UTC)[reply]
  7.   Comment The problem is not unique to ASL users, many other languages wikipedia are underdeveloped and their speakers often rely on English wikipedia for knowledges. There are little reason to cater a specific language in the problem. Two solutions are possible, a.) develop the wikipedia of the language itself, in this case ASL wikipedia, b.) develop a plugin that would display mouseover tip from wiktionary for words that are being highlighted in user-selected language of user have enabled the functionality. 3. The proposed functionality is best served as a browser plugin so that it would work not just on Wikipedia but also every single other site. You might want to take a look at the software named rikaikun and all its related softwares as an example. C933103 (talk) 10:11, 5 December 2016 (UTC)[reply]
  8.   Oppose.Antiqueight (talk) 14:03, 7 December 2016 (UTC)[reply]
  9.   Support any improved accessibility. Ottawahitech (talk) 15:52, 9 December 2016 (UTC) Template:Please ping[reply]
  10.   Oppose, not a Community Tech project, should follow the same process as proposals for any other language support — NickK (talk) 10:19, 12 December 2016 (UTC)[reply]

Ask new users to disclose paid editing

  • Problem: In Terms of use#4. Refraining from Certain Activities, we have a section about the prohibition against "Paid contributions without disclosure". As more and more persons around the world come to regard the Wikimedia projects as opportunities to gain free advertising or advocacy, we encounter more and more users who violate these terms of use, sometimes due to good-faith lack of awareness. Such activity severely degrades our content, and can present a very time-consuming need for other editors to correct inappropriate content. Uncorrected promotional content reflects poorly on Wikimedia projects in the eyes of the public. This problem is very likely to get larger in the coming years
  • Who would benefit: New editors who are first registering an account would get helpful guidance, and everyone would benefit from wider awareness of, and compliance with, the terms of use. The proposal may not work for bad-faith users who will ignore it, or unregistered users, but there are many good-faith but unaware users who would benefit.
  • Proposed solution: During the process of registering a new account, a single new question would be added to the registration process: "Do you expect to edit Wikipedia for business or promotional purposes?" (The name of the applicable project would be substituted for "Wikipedia".) There would be a "yes"/"no" radio button to answer. An answer of "no" would have no effect. An answer of "yes" would result in the automatic placement of an informational message on the new user talk page, with information about and links to the applicable policies. At the English Wikipedia, this talk page message would be en:Template:Register-COI. The new user could read the message and follow its advice.

Community discussion

The idea of using the account creation process to educate contributors about COI is good. Is there any concern that the template would be viewed as a permanent "scarlet letter"? Let's say a new contributor starts out thinking they're going to write about their business. They get the template, they learn that's not a good idea. Instead, they decide to contribute to a page that has nothing to do with their business—adding sourced information about something that they know—but they make mistakes, and an experienced editor goes to their talk page to explain something to them. Then they see the template, which means this person is a confirmed, self-reported COI editor!!! The question didn't ask what the person was hoping to promote, and therefore, any contribution that they make is potentially COI related. They are tagged with that scarlet letter forever, because the very first thing that they did was a mistake. -- DannyH (WMF) (talk) 23:14, 11 November 2016 (UTC)[reply]

  • @DannyH (WMF): This could be solved simply by requiring the user to enter in a blank who/what they plan to promote f they click Yes. This would then be inserted into the template. — Gestrid (talk) 19:55, 14 November 2016 (UTC)[reply]
  • This partly duplicates my request for a proper landing page which the Foundation appears to have avoided wanting to to build.

—The preceding unsigned comment was added by Kudpung (talk • contribs) 11:19, 13 November 2016 (UTC)

About the issue of a "scarlet letter", I think that can be a function of how the individual project handles it, and it's a problem that can easily be avoided. There is no reason for the template message to create a permanent categorization. For example, at the English WP, it is accepted practice for editors to be free to delete messages on their talk pages, and the proposed template does not imply any past or future wrongdoing. Correctly implemented, this proposal is about providing important information, but not about labeling users. --Tryptofish (talk) 17:11, 19 November 2016 (UTC)[reply]
  • The proposal seems useful and it will help professional PR people to edit according to the rules. However, in similar way we should deal with the activist editors who are not paid for their editing, but who still have COI by promoting their NGO/movement/campaign or using Wikipedia to fight against some projects/organizations or corporations/persons. Therefore I think the question should be broader. Beagel (talk) 18:37, 1 December 2016 (UTC)[reply]
Thanks for the favorable comment. One issue that arises with respect to unpaid COI is that the Terms of Use do not really address that: they are instead about undisclosed paid editing. --Tryptofish (talk) 21:09, 1 December 2016 (UTC)[reply]
My user page on en.wiki contains a userbox which reads "Everyone has points of view with inherent cultural biases - recognition is the first step to achieving NPOV". I'm mainly active on en.wiki and on Commons. In the case of the former, activity right now is dominated by the recently-concluded U.S. presidential election. In the case of the latter, various topic areas are dominated by propaganda images from the U.S. military which appear to have little or no value under COM:EDUSE. This sort of activity is so excessive, it's choking the life out of the rest of those projects. Even if it isn't paid COI, it's certainly resembles the sort of editing that Beagel describes above. It appears to make these projects out to be a dumping ground for low-hanging fruit in very few particular veins and takes us away from the goal of being a comprehensive information resource; en.wiki in particular is more and more resembling another news site and not an encyclopedia.RadioKAOS (talk) 22:06, 12 December 2016 (UTC)[reply]
  • The idea is interesting, but I don't think the newcomers will disclose their affiliation. Particularly when confronted with the phrasing you put. "Are you affiliated with any group or organisation?" could be better. Even-so I doubt people will want to be open-minded about it if they came here to spam. --Gryllida 00:06, 2 December 2016 (UTC)[reply]
I agree with you to the extent that neither this nor anything else will identify everyone to whom it might apply. (The alternative question that you suggested is way too vague: I'm "affiliated" with all kinds of groups that have nothing to do with my editing.) And there is no need for the user to disclose which group they might be editing on behalf of. It's just a matter of bringing information to good-faith users who are not aware of it. --Tryptofish (talk) 23:09, 2 December 2016 (UTC)[reply]

Voting – Ask new users to disclose paid editing

  1.   Support We definitely should be letting new editors know a few truths about what they can and can't do on Wikipedia, and doing so at the first opportunity, as soon as they register. Conflict-of-interest and promotional edits aren't confined to creating new articles, and about three-quarters of newly signed up editors will be editing existing articlesNoyster (talk) 21:29, 28 November 2016 (UTC)[reply]
  2.   Support But the language of the query should be phrased more broadly, given the number of new users who deny that they wanted to "promote" their business, claiming that they "just wanted to let the world know about what the business has to offer" (and, alas, I do believe that there are people who genuinely don't understand that those are almost always the same thing) I don't have time at the moment to noodle this in great depth but I'm thinking something more like, "Do you intend to use Wikipedia to promote, or increase public awareness of, a person, group of people, business, or cause?" Julietdeltalima (talk) 00:37, 29 November 2016 (UTC)[reply]
  3.   Support A good idea which will help paid editors not get caught up in the rules. Doc James (talk · contribs · email) 00:59, 29 November 2016 (UTC)[reply]
  4.   Support Arian Talk 13:13, 29 November 2016 (UTC)[reply]
  5.   Support if it can remove some limbos...--Alexmar983 (talk) 05:50, 30 November 2016 (UTC)[reply]
  6.   Support as nom. I've come to feel very strongly that we need to find ways to deal with undisclosed paid editing, and this is a helpful and non-accusatory way to do so. I've been reading the votes so far, and I've thought about that issue of "I just wanted to let the world know". Of course, it's really sophistry to say that there is a difference between that and "promoting", but I can also envision lots of new users who just want in good faith to tell the world about an interesting topic that they plan to write an article about, but that's just good editing. I don't think any question can "catch" all potential abusers, but educating a good percentage of them is a big net positive. And exactly how to educate them is a function of what the talk page message will say. And that is not something determined here at meta, but should be determined at each project. --Tryptofish (talk) 22:10, 30 November 2016 (UTC)[reply]
  7.   Support it's kind of obvious that we need this as another avenue to close "I didn't know I had to do that" loopholes to ToS violators. It will either reduce un-knowing ToS violations, or make it easier to hold willful violators accountable. - Brianhe (talk) 20:42, 1 December 2016 (UTC)[reply]
  8.   Support making it simple for people to do the right thing is always good. For conflicted/paid editors who would want to do the right thing but don't know there even is one (and they exist!) this will be helpful. Has nothing to do with people who want to deceive, and shouldn't be considered in light of them. Jytdog (talk) 20:46, 1 December 2016 (UTC)[reply]
  9.   Support as someone who works with a lot of COI editors in the English Wikipedia Teahouse. — Gestrid (talk) 21:06, 1 December 2016 (UTC)[reply]
  10.   Support this clarifies a lot of things(which editors are paid [1] and which are not)--Ozzie10aaaa (talk) 21:23, 1 December 2016 (UTC)[reply]
  11.   Support helps to reinforce that Wikipedia is intended to be an online encyclopedia, and not social media marketing. Not a fix to all COI or advocacy editing, but it's simple and should help. Geogene (talk) 21:30, 1 December 2016 (UTC)[reply]
  12.   Support As someone says, it may not keep those inclined to break the rules from trying to do so, but it will help honest persons from doing so inadvertently. I might suggest that, when the No button is chosen, a much shorter message might go on the talk page saying, "When registering, you indicated that you do not expect to edit Wikipedia for business or promotional purposes. If that situation should change, please visit [link] for our rules governing this situation." Just a thought. EEng (talk) 22:08, 1 December 2016 (UTC)[reply]
  13.   Support should be given a try → «« Man77 »» [de] 22:21, 1 December 2016 (UTC)[reply]
  14.   Support Herostratus (talk) 22:44, 1 December 2016 (UTC)[reply]
  15.   Support SamanthaNguyen (talk) 23:07, 1 December 2016 (UTC)[reply]
  16.   Support A step in the right direction, and let each Wikipedia decide how to use the feature. I would consider this part of better onboarding, in general czar 01:34, 2 December 2016 (UTC)[reply]
  17.   Support Draceane (talk) 10:16, 2 December 2016 (UTC)[reply]
  18.   Support Trasparency is a good idea. Let people know why they're here to alert others. Oaktree b (talk) 16:29, 2 December 2016 (UTC)[reply]
  19.   Support Recently the community in Ghana has come across people who have even stated on their social media profiles that they create Wikipedia pages for fees. Members receive calls weekly with people asking for articles and opting to pay for them. Yet many are not aware of the paid editing terms and conditions. This will be a great idea. And it can help start the paid editing conversation at the get go at editathons where most people create their very first accounts and edit for the first time Sandiooses (talk) 17:58, 2 December 2016 (UTC)[reply]
  20.   Support great idea LavaBaron (talk) 02:39, 3 December 2016 (UTC)[reply]
  21.   Support Daylen (talk) 06:17, 3 December 2016 (UTC)[reply]
  22.   Support Kinda... to be honest this is certainly not the top item on my list of things that brand-new editors should be informed of/warned about. I'm not even sure it's in my top 10. But it's somewhere on that list, and it might help orient even non-paid new editors to what kind of content is appropriate, and I'm generally in favor of things that might help reduce the general level of moral panic over the possibility that someone might be a paid nuisance as opposed to a regular one. Opabinia regalis (talk) 04:32, 4 December 2016 (UTC)[reply]
  23.   Support -- the wub "?!" 15:43, 4 December 2016 (UTC)[reply]
  24.   Support as undisclosed paid editing is a real problem, and increasing awareness up-front is a good idea. I don't think this is much of a "technical project", though. :) Stevie is the man! Talk • Work 16:32, 4 December 2016 (UTC)[reply]
  25.   Neutral The way the proposal is written, it'd definitely work as a way of singling out "potential" COI editors. Since the template would be the first thing added to the user talk, anyone could access that first edit and check whether or not the user branded him/herself as a paid editor; in case of yes, the user would be automatically labelled as "that one guy who's probably making money out of Wikipedia", and all his/her edits would be seem as suspicious. I believe that adding an additional step during registration, where the user would select five generic topics of interest like "biology", "geography", "businesses and organizations I'm involved with", would be a better way to prevent users from straight-out lying about their intentions. If they select the last one, they'd have to read a resumed version of COI guidelines and transcribe a phrase agreeing to it. After that, maybe the software could flag contributions they make to specific pages, like articles that they've been constantly editing (a common feature of single-purpose accounts), but without warning the patroller the reason that edit was flagged, thus decreasing bias. ArgonSim (talk) 21:08, 5 December 2016 (UTC)[reply]
    I would worry that "businesses and organizations I'm involved with", as opposed to "businesses and organizations I'm not involved with", ends up being a leading question. The other point that you raise is very much like that of the "scarlet letter" in the discussion section above. --Tryptofish (talk) 21:24, 5 December 2016 (UTC)[reply]
    Yeah, I know, but I still think it'd be very damaging to publicly and automatically label users as for-pay/SPA based solely on what they declared during registration. Deleting the added template would only hide it from the current version, but anyone could see it by browsing through the history, especially considering that this added template would also be the edit creating that talk page. Having the software deal with SPA edits by generically flagging them as needing revision instead of tagging them as potential COI would prevent patrollers from being biased by this. As for the leading question problem, I also agree that bad-faith users would probably not fall for that, but it's a lot more likely that this same bad-faith user won't admit s/he's expecting to edit Wikipedia for promotional purposes.
    ArgonSim (talk) 22:24, 5 December 2016 (UTC)[reply]
  26.   Support --Zone42 (talk) 12:21, 6 December 2016 (UTC)[reply]
  27.   Support Muhraz (talk) 15:58, 6 December 2016 (UTC)[reply]
  28.   Support This supposed technical change includes an even bigger social change. Let's do it! Blue Rasberry (talk) 19:20, 6 December 2016 (UTC)[reply]
  29.   Support -- Amanda (aka DQ) 21:07, 6 December 2016 (UTC)[reply]
  30.   Support Tiggerjay (talk) 21:10, 6 December 2016 (UTC)[reply]
  31.   Support Ks0stm (T•C•G) 21:16, 6 December 2016 (UTC)[reply]
  32.   Support. - Mailer Diablo (talk) 06:59, 7 December 2016 (UTC)[reply]
  33.   Support -- Movses (talk) 09:06, 7 December 2016 (UTC)[reply]
  34.   Support CFCF💌 📧 20:52, 7 December 2016 (UTC)[reply]
  35.   Support Rodrigo (talk) 00:05, 8 December 2016 (UTC)[reply]
  36.   Support Yup, this is a good step forward. Educating editors who have a COI is a good way to manage the problem. --Lemongirl942 (talk) 02:36, 8 December 2016 (UTC)[reply]
  37.   Support Absolutely no downside to this. Rivertorch (talk) 05:46, 8 December 2016 (UTC)[reply]
  38.   Weak support — Rhododendrites talk \\ 05:52, 8 December 2016 (UTC)[reply]
  39.   Oppose for certain projects. Some projects like Wiktionary and Wikisource don't have this as an issue, there aren't any (afaik) paid editors, so this shouldn't apply to account creation on those projects. Adding this extra step to signup is likely to cause many to just not create an account. Every additional step added to account creation makes a larger percentage of potential users lose interest. --Yair rand (talk) 18:36, 8 December 2016 (UTC)[reply]
    As long as I understand from your comment that you do not oppose the proposal for enwiki and perhaps for other projects where it is welcome, then I think that you make a good point, thank you. If this proposal is implemented, I think that it would be fine to initially roll it out at enwiki, before migrating it anywhere else. It is really the 'pedia projects where undisclosed paid editing presents a major problem. --Tryptofish (talk) 00:19, 9 December 2016 (UTC)[reply]
  40.   Support - Akela (talk) 21:55, 8 December 2016 (UTC)[reply]
  41.   Support Miniapolis 16:00, 9 December 2016 (UTC)[reply]
  42. Undecided - My concern is abuse as we've already seen occur. After having been a victim of improper targeting in addition to having witnessed what other innocent editors have had to endure, I am as skeptical of this proposal as conventional science is of alternative medicine. I actually do understand the need for disclosure when it's a company - company employee situation, but the ambiguities and variables are many. This proposal reminds me more of being GUILTY UNTIL PROVEN INNOCENT. Another pitfall - if one editor doesn't like another editor for whatever reason....well, you can imagine the events that may transpire. The editor with the strongest support base usually wins in a mobocracy style RfC because we simply don't have a dependable system for closing RfCs. I'm not quite sure where to draw the line because I believe we're opening an incredibly diverse and ambiguous can of worms. It's simply not as B&W as what it appears to be. Atsme📞📧 20:32, 9 December 2016 (UTC)[reply]
    It seems to me that your concern is really with much more than this proposal, and implementation would neither make the concerns better nor worse. All this does is provide new editors with an informational message, that they are free to delete. In fact, I recently added a sentence to the template, that says explicitly that one should feel free to delete the message after reading it, because of feedback in the discussion here. --Tryptofish (talk) 22:57, 9 December 2016 (UTC)[reply]
  43.   Support - but it isn't going to force them, and it won't put an end to campaigns such as en:Orangemoody, and it won't stop me warning (and possibly even blocking) users who are quite obviously creating a remunerated assignment. This should be incorporated in the bigger and more important request elsewhere in this wishlist to create a proper landing page for all new userrs. Kudpung (talk) 06:29, 10 December 2016 (UTC)[reply]
  44.   Support --g (talk) 10:17, 10 December 2016 (UTC)[reply]
  45.   Support--OrsolyaVirág (talk) 13:07, 10 December 2016 (UTC)[reply]
  46.   Oppose I don't think the newcomers will disclose their affiliation. --Alaspada (Talk) 02:58, 11 December 2016 (UTC)[reply]
    I agree that some newcomers would not do this, but at least this proposal makes all newcomers aware that this is something we take very seriously. Stevie is the man! Talk • Work 13:45, 11 December 2016 (UTC)[reply]
  47.   Support Jcc (talk) 10:17, 11 December 2016 (UTC)[reply]
  48.   Support Excellent idea. --  AnselmiJuan (discusión) 11:59, 11 December 2016 (UTC)[reply]
  49.   Support There's only a week basis for doing anything about paid editing that crosses the line, if this is not done.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:22, 11 December 2016 (UTC)[reply]
  50.   Support Doug Weller (talk) 19:01, 11 December 2016 (UTC)[reply]
  51.   Support A top priority! Tdslk (talk) 19:33, 11 December 2016 (UTC)[reply]
  52.   Oppose This is like the US visa form asking if you're a terrorist; useless feature that improves/prevents/fixes nothing. FoCuSandLeArN (talk) 23:08, 11 December 2016 (UTC)[reply]
    At enwiki, there have been multiple instances of users responding very positively when the paid editing policy was explained to them, with no resentment at all. It's very much a matter of the good faith or bad faith intentions of the user, and there is probably no way to help bad faith editors. --Tryptofish (talk) 22:01, 12 December 2016 (UTC)[reply]
  53.   Oppose, paid editing is too complex to be a boolean value defined upon registration. Firstly, policies are different from one project to another, and a librarian editing for business is great for Wikisource but bad for Wikipedia. Secondly, accounts are global, and we do not want a newbie receive 700-something messages on COI policies on various wikis. Thirdly, situation may change, and there are both people who did paid editing and stopped it at some point and people who edited as volunteers but started paid editing at some point. I am afraid that this label of "paid editor" will be just another reason for harassment — NickK (talk) 23:57, 11 December 2016 (UTC)[reply]
    You've brought out a very good point. The registration-triggered message should only be placed on the user talk page at the project from which the user registered. But the Terms of Use are not project-dependent: paid editing is permitted but must be disclosed at any Wikimedia project. The editors who start as paid editors but later stop will be helped by the message, and those who start out as not paid but consider it later will have already had time to learn about rules that a brand-new user will not yet know about. And the "scarlet letter" issue has already been discussed. --Tryptofish (talk) 22:01, 12 December 2016 (UTC)[reply]

Automatic notification of page creators when page is nominated for deletion

  • Problem: I have created dozens of pages on the English Wikipedia that ended up deleted as a result of being nominated but without getting a courtesy notification of the pending deletion As of now I spend a big proportion of my limited wikipedia editing time trying to track down my deleted edits, instead of spending more time building and improving content.
Right now it is only RECOMMENDED that the nominator notify the creator, but this creates a burden that some nominators are reluctant to shoulder. Hundreds of pages are deleted every day but not all the page creators know that their page has been nominated.
  • Who would benefit:
  • Proposed solution: I would like to request that a process be instituted which automatically notifies a page creator when their creation is nominated.
  • More comments: Since Wikipedians believe strongly in attribution, wouldn’t it make sense to also notify those who create content that for various reasons the page they created is not considered suitable?

An automatic notification would help:

  • retain good faith editors
  • save both nominators and page creators time
  • make it easier to track down and maintain statistics of deletion processes
  • help prevent abuse

Community discussion

  • We discussed about something similar for years on itwiki in different occasions. On some platforms it is also compulsory to do that, but users are forced to this manually. The system is much more efficient on commons, where it's just a click. Maybe we can take a look there. Maybe there is another platform that does it, but informing the creator of an article of a deletion should be an easy automatized task everywhere, not something that every platform should implement on its own. Also, it would be nice to inform not only the creator but the most important contributor (edits or added text), as listed in the wikimetrics pages. But this second feature should be possible to be disactivated, and it is not as urgent (although sometimes people who adopted an article are much more interested in helping the deletion process in a constructive way, or they are a user who registered after the creation of the page as an IP)--Alexmar983 (talk) 16:54, 18 November 2016 (UTC)[reply]
  • On Commons page creators are often people that moved the file from other project. We also need to notify the original page creators about pending deletions. --Jarekt (talk) 17:24, 18 November 2016 (UTC)[reply]
Good point.--Alexmar983 (talk) 04:57, 19 November 2016 (UTC)[reply]
In phab:T123866, I proposed that we could "mark" the deletion templates in some way that the notification system will recognize them as such, similar to what the software does with disambiguation templates. עוד מישהו Od Mishehu 08:50, 23 November 2016 (UTC)[reply]
  • There is a problem with these notifications (including or particularly with Twinkle which I have experienced several times. It happens in the cases if the page which is nominated for deletion was originally created as a legitimate redirect to the existing page and only afterward this redirect was converted to be an article. In that case, Twinkle will notify the creator of the original redirect and not the creator of the actual article. It would be necessary that whatever tool would make the notification, it should be check the page against the page size after certain edit to exclude notifying creators of the redirect and notifying the actual creators of the article. Beagel (talk) 18:47, 1 December 2016 (UTC)[reply]
  • I see a fair number of opposes in the votes by experienced editors/admins, and wonder if it is alright to ask some questions?
The opposers use terminology such as: long term abuse and plain vandalism and I wonder what is meant by it. I specifically wonder whether those comments are aimed at me, since I explained above that many of the pages I started ended up being deleted without notification? Ottawahitech (talk) 16:19, 3 December 2016 (UTC)please ping me[reply]
If page creators watchlist their creations, and regularly monitor their watchlists, why isn't this sufficient notification?
Oh, I see. This would notify newbies who haven't activated watchlists. Wbm1058 (talk) 16:20, 4 December 2016 (UTC)[reply]
As the operator of the Requested moves bot, which places various notifications of page moves up for discussion, I could probably leverage that to automate notices to user talk pages, though page creators are not currently notified of requests to change the title of their creations. But, to get approval for that at en:WP:BRFA, I would need to demonstrate that there was community consensus for such a bot. You should initiate a discussion on some high-visibility talk page related to deletions, to obtain a consensus for this before bot development can start. A system that discards oppose !votes is not a valid system for obtaining consensus. Wbm1058 (talk) 16:07, 4 December 2016 (UTC)[reply]
  • I think it bears repeating that this is inappropriate for the Community Tech wishlist as it would effectively force a policy change on all wikis as proposed. Moreover I don't see how it would be doable when each wiki has different deletion processes usually using freeform wikitext. You would have to create a bot with different settings for every wiki. If one wiki has consensus for this, ask for help from CT, but this isn't going to fly on a global level. BethNaught (talk) 22:34, 4 December 2016 (UTC)[reply]
  • It is helpful to develop such a tool especially if I recall correctly some wikipedia already treats unnotified deletion request as invalid request. It should also notify top 5 largest contributor to the page in term of bytes changed which is much easier for computer to identify than human C933103 (talk) 10:20, 5 December 2016 (UTC)[reply]

Voting – Notification when page is nominated for deletion

  1.   Support--Alexmar983 (talk) 05:27, 28 November 2016 (UTC)[reply]
  2.   Support--Wesalius (talk) 08:34, 28 November 2016 (UTC)[reply]
  3.   Support. Gamliel Fishkin 04:01, 29 November 2016 (UTC)[reply]
  4.   Support · · · Peter (Southwood) (talk): 08:46, 29 November 2016 (UTC)[reply]
  5.   Support Golan's mom אמא של גולן (talk) 14:01, 29 November 2016 (UTC)[reply]
  6.   Support (although I'm agnostic whether this should also apply to pages created by IP's) StevenJ81 (talk) 17:49, 29 November 2016 (UTC)[reply]
  7.   Support - while many wikis have rules requiring talk page notification of users, there will always be users who don't bother, and mass-nominations can be nearly impossibe for a human being to notify everyone. עוד מישהו Od Mishehu 20:28, 29 November 2016 (UTC)[reply]
  8.   Support --Jarekt (talk) 04:13, 30 November 2016 (UTC)[reply]
  9.   Support Jane023 (talk) 16:13, 30 November 2016 (UTC)[reply]
  10.   Support As part of a full deletion workflow, for pages, files... Trizek from FR 18:04, 30 November 2016 (UTC)[reply]
  11.   Support, also the addition of the deletion-nomination-template to an article should have a tag that shows on watchlists. Furthermore users should get the option to have it get draftified or moved to userspace instead of getting deleted right away. --Fixuture (talk) 20:53, 30 November 2016 (UTC)[reply]
  12.   Oppose Courtesy notifications are provided as a courtesy; a feature like this makes leaving notifications an effective mandatory policy, which is totally out of scope for community tech team. IMO a change like this doesn't require a software feature and should be discussed at the appropriate forum on each individual Wiki. -FASTILY 02:34, 1 December 2016 (UTC)[reply]
  13.   Oppose Per Fastily. Additionally, there are certain circumstances where deletion notifications are counterproductive (usually involving long term abuse). MER-C (talk) 05:42, 1 December 2016 (UTC)[reply]
  14.   Support Ahm masum (talk) 17:20, 1 December 2016 (UTC)[reply]
  15.   Support --Grabado (talk) 18:46, 1 December 2016 (UTC)[reply]
  16.   Support --Gerwoman (talk) 18:47, 1 December 2016 (UTC)[reply]
  17.   Oppose per Fastily. Also, some page creations are just plain vandalism. I don't want to notify the vandal "Hey, your page was nominated for speedy deletion!" just so I can have fun constantly reverting their attempts to remove the template. — Gestrid (talk) 21:10, 1 December 2016 (UTC)[reply]
    if the user is blocked, he is not informed. Is that enough as a solution? If a vandal is a vandal it does not matter if it appears again on that deletion page or another page if (s)he has not been blocked yet or wants to evade a block. Why we let vandals actually disrupt the need to inform and cooperate between real users? Is it me or is that even worse on global perspective?--Alexmar983 (talk) 07:17, 2 December 2016 (UTC)[reply]
    Right, and I'm sure nobody here disagrees with you on how to treat vandals. The problem with this proposal is how it effectively forces a policy change on local Wikis at the global level by using technical measures (related: Superprotect). While I don't disagree that notifications are important, I'm of the opinion that making them mandatory should be determined locally by each Wiki, and that this does not require a technical measure to enforce. -FASTILY 22:26, 4 December 2016 (UTC)[reply]
    actually it means they can opt-out. Than of course if their users realizes that they are prevented from being informed whilst other users can, on platforms that are probably still working pretty fine, I'm sure they all ask around and change the local policy and it will require big effort to oppose. Otherwise we are stating here that because some communities may disagree (not at all of them , look at the vote here) all the local communities have to force their users to a inefficient and fragmented system.--Alexmar983 (talk) 14:19, 6 December 2016 (UTC)[reply]
  18.   Support although i think implementation needs to involve merging the notifications and watchlist systems into some one more useful and friendly system which does not pop a useless clumsy ugly number (and a tiny popup) like notifications do, and not be so hard to find and to use by newbies as the watchlist. Gryllida 00:11, 2 December 2016 (UTC)[reply]
  19.   Oppose, this proposal mixes the social and the technical. Max Semenik (talk) 08:01, 2 December 2016 (UTC)[reply]
  20.   Oppose per all above BethNaught (talk) 08:15, 2 December 2016 (UTC)[reply]
  21.   Support Draceane (talk) 10:17, 2 December 2016 (UTC)[reply]
  22.   Support - Best regards, Kertraon (talk) 12:12, 4 December 2016 (UTC)[reply]
  23.   Support, though the details of exactly how it works and who it notifies need to be worked out. See my comments above. Wbm1058 (talk) 16:16, 4 December 2016 (UTC)[reply]
  24.   Neutral I think this can be treated as policy development/enforcement at individual wikis, and given policy backing, also resolvable by having a bot (similar to en:User:AAlertBot's triggering) testing if a user has been messaged, and if not, messaging them. Also, like mentioned in comments, page creators should ordinarily be watching their pages to see what is changing on them, including being PROD'd or nominated for deletion. WMF might be good for coordinating this, but I'm not sure. I think I lean toward individual wikis working out solutions. Stevie is the man! Talk • Work 16:51, 4 December 2016 (UTC)[reply]
  25.   Support --Vicedomino (talk) 19:08, 4 December 2016 (UTC)[reply]
  26.   Support Studmult (talk) 07:40, 5 December 2016 (UTC)[reply]
  27.   Oppose This can be easily accomplished with a javascript-based gadget, and it's already been implemented on pt-wiki, for instance, where after nominating an article for deletion you are given the option to notify its creator through his/her talk page by the click of a button. Maybe stripping out the option to send the notification and automatically notifying instead would get around forgetfulness/laziness. ArgonSim (talk) 21:16, 5 December 2016 (UTC)[reply]
    Java-based gadgets do exist for deletion nominations on English Wikipedia, but only for users who care to use them and only for single-page nominations. The former tends to exclude many of the newer users who are just starting to learn the processes, and the latter excludes many nominations because there are too many pages (I recently made a nomination of around 28000 pages, tagging them all using AWB). If e use the already existing notification system, we can deal with these issues - and users can opt out of getting the notifications without confusing other users. עוד מישהו Od Mishehu 04:15, 6 December 2016 (UTC)[reply]
  28.   Oppose Sometimes pages need to be deleted because they were created by disruptive users. --Tryptofish (talk) 23:37, 5 December 2016 (UTC)[reply]
  29.   Support Muhraz (talk) 15:59, 6 December 2016 (UTC)[reply]
  30.   Support May help, can't hurt.--Elmidae (talk) 15:54, 7 December 2016 (UTC)[reply]
  31.   Weak oppose - It seems like it would be easier to adjust the instructions for nominating an article for deletion to require notification under particular circumstances, than to figure out how not to create notifications for the many examples outlined above that shouldn't receive notifications. — Rhododendrites talk \\ 05:55, 8 December 2016 (UTC)[reply]
  32.   Support - Helpful. DPdH (talk) 20:13, 8 December 2016 (UTC)[reply]
  33.   Support Miniapolis 16:03, 9 December 2016 (UTC)[reply]
  34.   Oppose per Fastily --g (talk) 10:19, 10 December 2016 (UTC)[reply]
  35.   Support Всегда пишу участникам уведомление о том, что ими созданую страницу я предложил к удалению.--TOMA646 (mail | talk) 14:00, 10 December 2016 (UTC)[reply]
  36.   Support --NaBUru38 (talk)
  37.   Support--Shriheeran (talk) 12:00, 11 December 2016 (UTC)[reply]
  38.   Oppose per MER-C.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:23, 11 December 2016 (UTC)[reply]
  39.   Support --Plagiat (talk) 18:14, 11 December 2016 (UTC)[reply]
  40.   Support --Kenzia (talk) 20:08, 11 December 2016 (UTC)[reply]
  41.   Support--David1010 (talk) 20:58, 11 December 2016 (UTC)[reply]
  42.   Neutral This is a mix of social and technical. There are already scripts available for this, especially on Commons. Socially this should for sure have a good impact. However, we are speaking about technical features here, and it is rather tricky as deletion and notification rules differ a lot from one project to another — NickK (talk) 00:35, 12 December 2016 (UTC)[reply]
  43.   Oppose This needs discussion on each project. Ramaksoud2000 (talk) 09:22, 12 December 2016 (UTC)[reply]
of course: a discussion to opt out. That's not a problem.--Alexmar983 (talk) 15:07, 12 December 2016 (UTC)[reply]

"Babel" for users area of expertise

  • Problem: If a user tries to find an user within some field, or someone that can answer a specific question, then s/he must track down that user without any help except the user categories. This is time consuming and error prone.
  • Who would benefit:
  • Proposed solution: Assume that we make a Babel-like system where we instead of using language codes use codes from w:International Standard Classification of Occupations. Then assume that we can use a tag in wikitext like #211 or something similar (note how it is done in Flow) and that mention of such a tag will then create a notification for all users having the ISCO-code on their user page. The notification could even estimate how close a question is to the user's area of expertise.
  • More comments: A user should not be notified if he can't understand the language on the page, although he should be able to get notifications for languages where there exist sufficient translation tools. That could be marked as 0-language codes.
There are really three different categories for expertise. One is the occupation-like category, what would use the ISCO-codes, another is the current language codes, and a third is the location of the user. The location isn't really an expertise, but an enabler. If something needs an user on the location, then this is necessary factor.
  • Phabricator tickets:

Community discussion

  • @Jeblad: If I understand correctly, you're suggesting that we should use a globally installed extension for editors to signal that they have expertise in a topic area, and that they willing to be notified about questions in that topic-area, potentially cross-wiki/language. -- This would be in contrast to the existing systems of (per-wiki) userboxes, such as w:en:Wikipedia:Userboxes/Science—And also in contrast to the existing systems of "people signing up for a local WikiProject" (e.g. w:en:Wikipedia:WikiProject Earth science). -- Is that accurate? Also, do you know if there are other websites that have a similar system, which it would be useful to know/think about? Thanks! Quiddity (WMF) (talk) 01:13, 22 November 2016 (UTC)[reply]
@Quiddity (WMF): Yes, I don't think the present user box system works at all, it only makes it possible to find some user. I want the notification routed to the actual users that can answer the question. Note that this will make it possible for users on smaller projects to ask for help, and then get help from users from the larger projects. The more interwoven the projects become the more important this will be.
Use of a global system does not imply that all users have to be notified for all such tags, it should be an opt-in whether they are interested in notifications outside the local site. Notifications about such occupation-tags should be filtered down on language, and that will limit the number of notifications a lot.
The problem of local notifications can be turned around to let the sender define the reach or scope of the identifier. Lets say #211 is global, #w:211 is within Wikipedia, #w:en:211 is within English Wikipedia, and #:211 is within the local project. Obviously this can be wrapped up in templates, like it is done in Flow.
I have not considered local subprojects, but I see no reason why it can't be exteded to cover them too. It would also be necessary to define the meaning of the local identifier somehow, like the special page for interwiki links.
This is a kind of knowledge management system where the system tries to identify the user that has a given qualification, sometimes described as intellectual capital management systems, and initiate a knowledge transfer between the parties.
The function processing a tag (or several tags) can run all kind of inference rules, and also generalize if it can't find a good match. The editors holds the overall knowledge, and we want to somehow dig into that knowledge. An inference engine might even use the actual contribution history together with stated qualifications to pinpoint good matches for a tagged question. — Jeblad 20:23, 22 November 2016 (UTC)[reply]
  • @Jeblad: Isn't this what WikiProjects are there for? In addition to those there are userboxes (and their associated user-categories). But I do think that maybe a message/notification to all members of a WikiProject (not just an entry on the watchlist for a talk page entry) could be useful. --Fixuture (talk) 20:28, 30 November 2016 (UTC)[reply]
WikiProjects are for a small group of users coming together to solve a problem or a limited set of problems. This is about finding those people before they can form a group. Instead of users following projects, the users can declare their area of expertise. I propose to use the ISCO codes, but perhaps it is better to make up codes as we go. — Jeblad 01:27, 1 December 2016 (UTC)[reply]

Voting – "Babel" for users area of expertise

  1.   Support something similar was imagined for years in offwiki discussions and also on some village pump discussion. I support any improvement in that direction.--Alexmar983 (talk) 05:27, 28 November 2016 (UTC)[reply]
  2.   Support it's long time I'm waiting an idea like this. I think it's the normal development of Wikipedia. --Codas (talk) 17:40, 28 November 2016 (UTC)[reply]
  3.   Support Note that the description is pretty simple, but this will be quite hard to implement. — Jeblad 01:45, 29 November 2016 (UTC)[reply]
  4.   Support · · · Peter (Southwood) (talk): 08:49, 29 November 2016 (UTC)[reply]
  5.   Support --Telaneo (User talk page) 21:45, 29 November 2016 (UTC)[reply]
  6.   Support—Makes sense Sandiooses (talk) 18:00, 2 December 2016 (UTC)[reply]
  7.   Support – Perhaps the categories of the Dewey Decimal Classification could be used for this instead. Aracali (talk) 16:30, 3 December 2016 (UTC)[reply]
  8.   Neutral I appreciate the problem, but I honestly feel the proposed solution is too wonky. I'll keep an open mind to other possible solutions. Also, we do have WikiProjects, Village Pump, and other places to ask for assistance. Stevie is the man! Talk • Work 17:05, 4 December 2016 (UTC)[reply]
  9.   Support This sort of looks like Quora, where you subscribe to subjects of your interest and then receive new questions about them on your dashboard. I believe that a tag system would be better than this ISCO proposal: User A tags new topic/talk section as pertaining to subject 1, 2 and 3; User B is currently following subject 2, so s/he gets notified about this new topic. If user A starts abusing the tag system (like adding too many unrelated tags), someone could request an admin to temporarily implement an Edit Filter for user A, as means to prevent s/he from misusing the tags. ArgonSim (talk) 21:31, 5 December 2016 (UTC)[reply]
    This is a tag system like the one you describe. — Jeblad 13:28, 6 December 2016 (UTC)[reply]
  10.   Oppose Quite honestly, I get more requests of this sort just on my enwiki user talk page than I can find the time to deal with. I sure would not want more. But maybe there could be user categories that editors could choose to put themselves into, indicating that they are happy to be asked about a particular area. Otherwise, I much prefer having talk pages, such as those at various WikiProjects, where editors can ask for other editors to help. --Tryptofish (talk) 23:42, 5 December 2016 (UTC)[reply]
  11.   Oppose Useless. Try to find an active Urdu speaking user on Commons. Without a proper search function this is a no-go. --Hedwig in Washington (talk) 04:18, 6 December 2016 (UTC)[reply]
    A traditional search system will not work for the problem you describe. It is although possible with this system. — Jeblad 13:30, 6 December 2016 (UTC)[reply]
    I fulfill these requests all the time: ur-N users with a minimal and recent acitvity on commons are Tahir mq and Hindustanilanguage, for example. It took me 3 minutes. I am begging since years to implement real search functions for all these things, but that's not the point here. Every standardized information is pivotal for creating, together with other tool, a much more interconnected community. Even if some users love to be at the center of the scene, wikiplatforms need a balanced and fluid users network to flourish, and that's one of the step to build it, even if it is not going to be 100% efficient yet. We all talk a lot about building an encyclopedia, we shouldn't oppose to tools that allow competent people to meet and work on that encyclopedia. Do we really prefer to leave a competent person usually alone in dealing with issues? Generic links to help pages are easy to copy and paste but they don't make all the tricks.--Alexmar983 (talk) 05:42, 10 December 2016 (UTC)[reply]
  12.   Weak support Muhraz (talk) 16:00, 6 December 2016 (UTC)[reply]
    Muhraz, "weak support" templates aren't counted in the survey. I changed the template for your vote, with a qualifier. -- DannyH (WMF) (talk) 20:00, 7 December 2016 (UTC)[reply]
  13.   Support Miniapolis 16:06, 9 December 2016 (UTC)[reply]
  14.   Oppose We already have way, way too many userboxes for this kind of stuff already.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:24, 11 December 2016 (UTC)[reply]
yes, mainly the weird or funny ones. So if I ask for a babel to say the country I visited or the dish I like or the sport teams I love, that's fine, but an area of expertise it's not? Where is the good old "we are building an encyclopedia" when you need it? Not all people go to project talks, it is a fact... and some people have a specific expertise in RL but they write about other things in their free time, but they can give you an advice if you ask them.--Alexmar983 (talk) 02:08, 12 December 2016 (UTC)[reply]

  • Problem: There are so many dead links in WP, this reduces the quality of the encyclopedia.
  • Who would benefit: A dead link checker would be of benefit to all!
  • Proposed solution: Not easy to know whom to notify about dead links. Maybe a notice on the article's discussion page?

Community discussion

We have a "deadlinkchecker" package and IABot is using that. Also see phab:T132606 about CyberBot. --AKlapper (WMF) (talk) 13:24, 16 November 2016 (UTC)[reply]
For wikis outside of English WP, this is definitely something that Community Tech could work on. Last year, we contributed to Cyberbot II, which identifies dead links on English WP and then replaces the links with the corresponding archived page from Internet Archive. Making the bot work on other languages is possible, and Cyberpower678, the creator of Cyberbot, is working on it. But there's a painstaking process to adapting Cyberbot to other languages, because it interacts with all of the wiki's citation templates.
Meanwhile, Community Tech could build a simplified version, creating a new bot based on the dead link detection code that we wrote this year. This bot could run through all of the external links on a wiki and identify the dead links, and then post a deadlink template. Those marked links could be fixed manually, or by a bot. So this is a worthwhile proposal, for wikis outside of enwiki. -- DannyH (WMF) (talk) 23:47, 16 November 2016 (UTC)[reply]
There are hundreds of wikis, where there are so few edits, that a list of dead links will never be worked on. While a list like this is useful for larger wikis, for small wikis an automated solution is needed. Using the bot of Cyberpower or the similar GiftBot of Giftplanze for this seems to be the best solution. --𝔊 (Gradzeichen Diſk✉Talk) 09:32, 18 November 2016 (UTC)[reply]
  1.   Support--Shizhao (talk) 02:47, 28 November 2016 (UTC)[reply]
  2.   Support--Alexander Misel (talk) 06:07, 28 November 2016 (UTC)[reply]
  3.   Support BethNaught (talk) 08:16, 28 November 2016 (UTC)[reply]
  4.   Support--Wesalius (talk) 08:34, 28 November 2016 (UTC)[reply]
  5.   Support. This has been of great value to the English Wikipedia, so all the other wikipedias should get to enjoy this benefit. Stevie is the man! Talk • Work 14:28, 28 November 2016 (UTC)[reply]
  6.   Support --XXN (talk) 16:13, 28 November 2016 (UTC)[reply]
  7.   Support Silraks (talk) 17:00, 28 November 2016 (UTC)[reply]
  8.   Support JAn Dudík (talk) 21:51, 28 November 2016 (UTC)[reply]
  9.   Support Aracali (talk) 03:12, 29 November 2016 (UTC)[reply]
  10.   Support · · · Peter (Southwood) (talk): 08:51, 29 November 2016 (UTC)[reply]
  11.   Support אמא של גולן (talk) 14:02, 29 November 2016 (UTC)[reply]
  12.   Support Ivi104 (talk) 20:27, 29 November 2016 (UTC)[reply]
  13.   Support --Telaneo (User talk page) 21:45, 29 November 2016 (UTC)[reply]
  14.   Support 4nn1l2 (talk) 12:00, 30 November 2016 (UTC)[reply]
  15.   Support--Freshman404Talk 12:52, 30 November 2016 (UTC)[reply]
  16.   Support Jane023 (talk) 16:15, 30 November 2016 (UTC)[reply]
  17.   Support Arian Talk 22:34, 30 November 2016 (UTC)[reply]
  18.   Support --β16 - (talk) 16:30, 1 December 2016 (UTC)[reply]
  19.   Support --Grabado (talk) 18:46, 1 December 2016 (UTC)[reply]
  20.   Support --Gerwoman (talk) 18:48, 1 December 2016 (UTC)[reply]
  21.   Support --Vachovec1 (talk) 19:55, 1 December 2016 (UTC)[reply]
  22.   Support We must expand the Great English Wikipedia's influence! (But, seriously, this would be good to have on other wikis. Perhaps there could be a bot that's developed so it could even work on wikis outside of Wikimedia's network.) — Gestrid (talk) 21:13, 1 December 2016 (UTC)[reply]
  23.   Support Louis Wu (talk) 21:40, 1 December 2016 (UTC)[reply]
  24.   Support — KPFC 💬 23:03, 1 December 2016 (UTC)[reply]
  25.   Support NMaia (talk) 02:49, 2 December 2016 (UTC)[reply]
  26.   Support --Alexmar983 (talk) 07:08, 2 December 2016 (UTC)[reply]
  27.   Support Draceane (talk) 10:18, 2 December 2016 (UTC)[reply]
  28.   Support —Jc86035 (talk) 11:14, 2 December 2016 (UTC)[reply]
  29.   Support --Lam-ang (talk) 16:19, 2 December 2016 (UTC)[reply]
  30.   Support MohammadtheEditor (talk) 17:22, 2 December 2016 (UTC)[reply]
  31.   Neutral rather than just tag dead links would want to see them "fixed" if possible. Doc James (talk · contribs · email) 04:23, 3 December 2016 (UTC)[reply]
  32.   Support --Continua Evoluzione (talk) 14:58, 3 December 2016 (UTC)[reply]
  33.   Support Tisfoon (talk) 17:58, 3 December 2016 (UTC)[reply]
  34.   Support -- the wub "?!" 15:44, 4 December 2016 (UTC)[reply]
  35.   Support--Praveen:talk 13:20, 5 December 2016 (UTC)[reply]
  36.   Support --Papuass (talk) 21:11, 5 December 2016 (UTC)[reply]
  37.   Support ArgonSim (talk) 22:40, 5 December 2016 (UTC)[reply]
  38.   Support --Hedwig in Washington (talk) 04:19, 6 December 2016 (UTC)[reply]
  39.   Support Absolutely. Muhraz (talk) 16:01, 6 December 2016 (UTC)[reply]
  40.   Support. - Mailer Diablo (talk) 06:59, 7 December 2016 (UTC)[reply]
  41.   Support - Finding the links is a beginning, not clear what can help fixing. Except for a simpler page archiving solution. DPdH (talk) 20:25, 8 December 2016 (UTC)[reply]
  42.   Support—10:02, 9 December 2016 (UTC)
  43.   Support Miniapolis 16:07, 9 December 2016 (UTC)[reply]
  44.   Support --Tarjeimo (talk) 23:09, 9 December 2016 (UTC)[reply]
  45.   Support Kudpung (talk) 07:16, 10 December 2016 (UTC)[reply]
  46.   Support --g (talk) 10:20, 10 December 2016 (UTC)[reply]
  47.   Support --OrsolyaVirág (talk) 13:08, 10 December 2016 (UTC)[reply]
  48.   Support — Ping08 (talk) 02:21, 11 December 2016 (UTC)[reply]
  49.   Support --Chrumps (talk) 03:26, 11 December 2016 (UTC)[reply]
  50.   Support --Helium4 (talk) 08:25, 11 December 2016 (UTC)[reply]
  51.   Support Crucial.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:24, 11 December 2016 (UTC)[reply]
  52.   Support--David1010 (talk) 20:58, 11 December 2016 (UTC)[reply]
  53.   Support — NickK (talk) 00:38, 12 December 2016 (UTC)[reply]

Feature for addition of common templates

  • Problem: A lot of places there are "something" that makes it necessary to add a template. For example a template for authority data. One thing is injecting those templates, but maintaining them quickly turns into a nightmare.
  • Who would benefit: All projects using wikitext
  • Proposed solution: Make a structure (JSON in Mediawiki-space) that is editable by users/admins that holds (1) a number of accept and reject patterns, and (2) a number of alternate replace patterns. Use the overall result as the wikitext to render, while keeping the original wikitext as the source.
  • More comments: This makes it possible to inject templates for default navigation and links from Wikidata, without the added bot maintenance nightmare. If used without any restrictions it can make it difficult to track why something shows up on a page, especially in raw wikitext. This can be avoided by limiting the insertion points to section headers and a few other markers.
An alternate description of this could be that it is a delayed bot-action that only applies on the rendered content.
This feature can be used to implement part of 2016 Community Wishlist Survey/Categories/Wikidata#Move links for lexicon-like external sites to wd-statements, and add them back under section headers.
  • Phabricator tickets:

Community discussion

Voting – Feature for addition of common templates

  1.   Oppose This is a third-party addon kind of tool, not something for the WMF dev team.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:25, 11 December 2016 (UTC)[reply]

Fix the bug where pages used by #ifexist show up in Special:WhatLinksHere

  • Who would benefit:
  • Proposed solution:

Community discussion

For the second year in a row I'm in favour of anyone who propose this fix. --Andyrom75 (talk) 11:44, 14 November 2016 (UTC)[reply]

Voting – Bug where pages used by #ifexist show up in Special:WhatLinksHere

  1.   Oppose I'm not convinced this is problem. I consider this a useful feature. Matěj Suchánek (talk) 21:57, 28 November 2016 (UTC)[reply]
  2.   Support, FWIW. We implemented a work-around in one template with this problem, which is going to be a quicker solution than waiting for this one to ever find the light of day. -- Wbm1058 (talk) 16:41, 4 December 2016 (UTC)[reply]

Fix the length of edit summary the non-Latin languages can use

  • Problem: In edit summaries in Russian and every other non-Latin-based language, you can enter half (or even 1/3) as many characters compared to English or other languages with a Latin alphabet. For example, it is very inconvenient to use edit summaries in Russian Wikipedia compared to English, as one often can't provide enough details in the summary. This is made even worse by the fact that the average Russian word is longer than English. As a result, edit summaries in ruwiki sometimes look like this.
  • Who would benefit: Wikipedias and other Wikimedia sites on languages using non-Latin alphabets. Wikipedias on Latin-based languages would benefit too, as Unicode characters can appear in edit summaries and section headings.
  • Proposed solution: Restructure database accordingly to count not bytes, but characters.
  • More comments: In 2016, it is rather outdated to depend on technical specifics of software, not on end-user experience. Say, it is impossible to imagine Twitter to count 140 bytes instead of characters.

Community discussion

Not technically feasible—ASCII characters require one byte each, and Cyrillic and others require two or more by definition. Making ASCII characters = 2 bytes is a pointless waste of resources. Fundamentally, in MariaDB—the database software used by the WMF—the VARBINARY and VARCHAR type (which would be used to store this sort of thing) counts its size in bytes. There are merged patches (see phab:T6714 and phab:T6715) to change the data type of the edit summary from TINYBLOB (255 bytes) to VARBINARY(767), tripling the amount of space available, but deploying them will require massive, disruptive and risky schema changes. The WMF will get around to it, but they need to make sure they don't destroy the site in the process. This deployment is a database administration problem, the coding already has been done. There is nothing Community Tech can do here. MER-C (talk) 02:24, 12 November 2016 (UTC)[reply]

What is technically unfeasible? Counting the database field lengths not in bytes? Well, that is obvious, I guess. My proposal is about the experience of the end-user. It doesn't matter, by and large, what the database will look like, but the users of Wikipedias in languages based on other than Latin alphabet should get the same experience as the users of Latin-based. Twitter has somehow overcome this problem, so can MediaWiki. Issues of the machines are irrelevant when there are issues of people. Jack who built the house (talk) 06:30, 12 November 2016 (UTC)[reply]
To clarify something, WMF will not automatically get around to it, the issue needs to be pushed and we need to have discussions with the DBAs about implementing that schema change (Or doing a different one if that schema change is considered unacceptable for whatever reason). This is something that Community tech (or some other group) could indeed push for. BWolff (WMF) (talk) 17:45, 23 November 2016 (UTC)[reply]
  • Well, the database does not necessarily need to count characters instead of bytes, it just needs to have an higher length limit for edit summaries and that is T6714.--Snaevar (talk) 00:06, 13 November 2016 (UTC)[reply]
    • I guess increasing byte length and UI limit could raise questions (after all, it's not just technical restriction—for some reason this length was chosen), while the fact that the lengths across different editions should be the same is less probable to raise them. Jack who built the house (talk) 07:27, 13 November 2016 (UTC)[reply]
  • (I'm splitting the 2 proposals that were here, into 2 sections, for ease of discussion. Also, renaming this section from "Go away from preference of Latin alphabet over Cyrillic and the rest of Unicode" to "Fix the length of edit summary the non-Latin languages can use" to be more precise about the problem that is addressed here. Quiddity (WMF) (talk) 21:10, 13 November 2016 (UTC))[reply]
  • I would also like to add that there are 3 special cases when this problem is especially prominent:
  1. When the section name is long
  2. When undoing an edit
  3. When entering the reason for rename
In this cases the summary is partly filled, and even less bytes are left for providing comments. Check this, for example. Jack who built the house (talk) 21:27, 1 December 2016 (UTC)[reply]
This bug made entry to bugzilla 10 years ago. I am an active follower of the bug since then. This comment feature is not really useful in my home wiki (ml.wikipdia), as well as other Indian language wikis because of the byte limitation. In our languages, usually Character size is at-least thrice of that of Latin characters and we add different Unicode characters to create usable letters. This together worsens the issue further in Mediawiki. Consider the English word "India", it is five characters and five bytes. Consider Malayalam Word "ഇന്ത്യ" (India), which is 6 characters and 18 bytes. I hope this example will help to avoid lame excuses. --Praveen:talk 13:47, 5 December 2016 (UTC)[reply]

Voting – Length of edit summary the non-Latin languages can use

  1.   Support BethNaught (talk) 08:16, 28 November 2016 (UTC)[reply]
  2.   Support Skydrinker (talk) 13:47, 28 November 2016 (UTC)[reply]
  3.   Support --Michgrig (talk) 13:52, 28 November 2016 (UTC)[reply]
  4.   Support --Vladis13 (talk) 14:17, 28 November 2016 (UTC)[reply]
  5.   Support RasabJacek (talk) 15:19, 28 November 2016 (UTC)[reply]
  6.   Support. Cat of the Six (talk) 15:27, 28 November 2016 (UTC).[reply]
  7.   Support. --Есстествоиспытатель (talk) 15:29, 28 November 2016 (UTC)[reply]
  8.   Support Sadads (talk) 15:36, 28 November 2016 (UTC)[reply]
  9.   Support Liasmi (talk) 16:00, 28 November 2016 (UTC)[reply]
  10.   Support – Meiræ 16:17, 28 November 2016 (UTC)[reply]
  11.   Support --Inctructor (talk) 16:27, 28 November 2016 (UTC)[reply]
  12.   Support --Kosun (talk) 17:11, 28 November 2016 (UTC)[reply]
  13.   Support --Arbnos (talk) 17:37, 28 November 2016 (UTC)[reply]
  14.   Support! ~ Starship Trooper ~ 17:55, 28 November 2016 (UTC)[reply]
  15.   Support --A.Savin (talk) 18:16, 28 November 2016 (UTC)[reply]
  16.   Support --VAP+VYK (talk) 18:50, 28 November 2016 (UTC)[reply]
  17.   Support --Wintik (talk) 19:20, 28 November 2016 (UTC)[reply]
  18.   Support. Max Semenik (talk) 19:28, 28 November 2016 (UTC)[reply]
  19.   Support.--Vladimir Solovjev (talk) 20:15, 28 November 2016 (UTC)[reply]
  20.   Support JAn Dudík (talk) 21:52, 28 November 2016 (UTC)[reply]
  21.   Support — Ping08 (talk) 21:59, 28 November 2016 (UTC)[reply]
  22.   Support Permjak (talk) 22:01, 28 November 2016 (UTC)[reply]
  23.   Support --Всезнайка (talk) 22:06, 28 November 2016 (UTC)[reply]
  24.   Support --VladXe (talk) 22:25, 28 November 2016 (UTC)[reply]
  25.   Support Niklem (talk) 22:32, 28 November 2016 (UTC)[reply]
  26.   Support cur. sit. when u. has 2 con. comm. like th. is unacc. Le Loy 23:14, 28 November 2016 (UTC)[reply]
  27.   Support Евгений Мирошниченко (talk) 03:10, 29 November 2016 (UTC)[reply]
  28.   Support Aracali (talk) 03:13, 29 November 2016 (UTC)[reply]
  29.   Support. Gamliel Fishkin 04:03, 29 November 2016 (UTC)[reply]
  30.   Support --Шнапс (talk) 04:12, 29 November 2016 (UTC)[reply]
  31.   Support Mihail Lavrov (talk) 07:48, 29 November 2016 (UTC)[reply]
  32.   Support. Schrike (talk) 08:02, 29 November 2016 (UTC)[reply]
  33.   Support StevenJ81 (talk) 17:52, 29 November 2016 (UTC)[reply]
  34.   Support. Tech. impl. sh’dn’t stand in the way of this. Saint Johann (ru) 19:06, 29 November 2016 (UTC)[reply]
  35.   Support. JukoFF (talk) 19:14, 29 November 2016 (UTC)[reply]
  36.   Support. --Хайзенберг (talk) 19:46, 29 November 2016 (UTC)[reply]
  37.   Support. Kolchak1923 (talk) 20:45, 29 November 2016 (UTC)[reply]
  38.   Support. --User№101 (talk) 22:12, 29 November 2016 (UTC)[reply]
  39.   Support. --GreenZmiy (talk) 04:44, 30 November 2016 (UTC)[reply]
  40.   Support Alexei Kopylov (talk) 08:50, 30 November 2016 (UTC)[reply]
  41.   Support. —Igel B TyMaHe (talk) 09:33, 30 November 2016 (UTC)[reply]
  42.   Support ‏ حمایت از خط فارسی. من خیلی از اوقات برای نوشتن خلاصه‌ویرایش جا کم می‌آورم. ‎ 4nn1l2 (talk) 12:03, 30 November 2016 (UTC)[reply]
  43.   Support --Sunfyre (talk) 12:38, 30 November 2016 (UTC)[reply]
  44.   Support. Azgar (talk) 12:59, 30 November 2016 (UTC)[reply]
  45.   Support-- ARASH PT  talk  14:18, 30 November 2016 (UTC)[reply]
  46.   Support --ShinePhantom (talk) 15:23, 30 November 2016 (UTC)[reply]
  47.   Support --Komap (talk) 15:36, 30 November 2016 (UTC)[reply]
  48.   Support Arian Talk 22:34, 30 November 2016 (UTC)[reply]
  49.   Support. Demidenko 01:44, 1 December 2016 (UTC)[reply]
  50.   Support Ahm masum (talk) 17:20, 1 December 2016 (UTC)[reply]
  51.   Support Ermahgerd9 (talk) 18:47, 1 December 2016 (UTC)[reply]
  52.   Support --Vachovec1 (talk) 19:39, 1 December 2016 (UTC)[reply]
  53.   Support Oliv0 (talk) 20:08, 1 December 2016 (UTC)[reply]
  54.   Support → «« Man77 »» [de] 22:05, 1 December 2016 (UTC)[reply]
  55.   Support --Gryllida 23:58, 1 December 2016 (UTC)[reply]
  56.   Support -- CFynn (talk) 05:41, 2 December 2016 (UTC)[reply]
  57.   Support--Alexmar983 (talk) 07:07, 2 December 2016 (UTC)[reply]
  58.   Support Jmvkrecords ⚜ (Intra talk) 08:13, 2 December 2016 (UTC).[reply]
  59.   SupportMaxBioHazard (talk) 11:35, 2 December 2016 (UTC)[reply]
  60.   Support Sannita - not just another it.wiki sysop 14:32, 2 December 2016 (UTC)[reply]
  61.   Support MohammadtheEditor (talk) 17:17, 2 December 2016 (UTC)[reply]
  62.   Support --Framawiki (talk) 20:40, 2 December 2016 (UTC)[reply]
  63.   Support --Hercules63 (talk) 21:57, 2 December 2016 (UTC)[reply]
  64.   Support Dinamik (talk) 23:23, 2 December 2016 (UTC)[reply]
  65.   Support Давно пора, ничего не видно. Мастер теней (talk) 23:41, 2 December 2016 (UTC)[reply]
  66.   Support Давняя и раздражающая проблема для русского раздела. GAndy (talk) 00:10, 3 December 2016 (UTC)[reply]
  67.   Support Iniquity (talk) 08:28, 3 December 2016 (UTC)[reply]
  68.   Support Tisfoon (talk) 17:56, 3 December 2016 (UTC)[reply]
  69.   Support --Slb nsk (talk) 18:49, 3 December 2016 (UTC)[reply]
  70.   Support --MGChecker (talk) 15:11, 4 December 2016 (UTC)[reply]
  71.   Support -- the wub "?!" 15:46, 4 December 2016 (UTC)[reply]
  72.   Support Facenapalm (talk) 16:49, 4 December 2016 (UTC)[reply]
  73.   Support Stevie is the man! Talk • Work 17:15, 4 December 2016 (UTC)[reply]
  74.   Support --Esetok (talk) 11:55, 5 December 2016 (UTC)[reply]
  75.   Support--Praveen:talk 13:23, 5 December 2016 (UTC)[reply]
  76.   Oppose because it would not help the many projects that do use Latin alphabets. I actually support doing this on behalf of smaller projects, but I don't want to see smaller projects send so many support voters that they crowd worthy proposals that benefit larger projects out of the top ten. --Tryptofish (talk) 23:44, 5 December 2016 (UTC)[reply]
  77.   Support Let's fix this before the bug can draw social security benefits. --Hedwig in Washington (talk) 04:22, 6 December 2016 (UTC)[reply]
  78.   Support --Adv.tksujith (talk) 01:41, 7 December 2016 (UTC)[reply]
  79.   Support--Ranjithsiji (talk) 01:54, 7 December 2016 (UTC)[reply]
  80.   Support --John Vandenberg (talk) 02:00, 7 December 2016 (UTC)[reply]
  81.   Support. - Mailer Diablo (talk) 07:00, 7 December 2016 (UTC)[reply]
  82.   Support —Ynhockey (talk) 10:07, 7 December 2016 (UTC)[reply]
  83.   Support This, that and the other (talk) 13:33, 8 December 2016 (UTC)[reply]
  84.   Support. --Yair rand (talk) 18:40, 8 December 2016 (UTC)[reply]
  85.   Support - DPdH (talk) 20:48, 8 December 2016 (UTC)[reply]
  86.   Support مهرنگار (talk) 01:15, 9 December 2016 (UTC)[reply]
  87.   Support - Bcharles (talk) 14:59, 10 December 2016 (UTC)[reply]
  88.   Support--David1010 (talk) 20:59, 11 December 2016 (UTC)[reply]
  89.   Support, this is a serious obst. to writ. meaningf. comm. in edit summ. if your lang. doesn't use Latin alph. — NickK (talk) 00:44, 12 December 2016 (UTC)[reply]
  90.   Support as long overdue. – Uanfala (talk) 00:46, 12 December 2016 (UTC)[reply]

Free choice in the number of category entries

Machine translation from German—please help improve! -- Freie Gestaltung der Menge an Kategorieeinträgen

  • Problem: Currently, categories are fixed by default to 200 entries per page. There are no variations.
Derzeit sind Kategorien per Voreinstellung auf 200 Einträge pro Seite fixiert. Es gibt keine Variationsmöglichkeiten.
  • Who would benefit: Editors and readers who are looking for something specific
Autoren und Lesern, die etwas gezielt suchen
  • Proposed solution: Abolish the restriction and enable free design of the displayed quantity of articles per category page, via a mask that allows entering the number of articles displayed per category page. A search restricted to a category with the option of searching only article titles or the whole article would also be nice.
Aufhebung der Beschränkung und freie Gestaltung der angezeigten Menge an Artikeln pro Kategorie-Seite über eine Maske, in der man frei die Zahl der pro Kategorieseite angezeigten Artikel eingeben kann. Eine auf eine Kategorie beschränkte Suche mit wahlweise Durchsuchung nur der Lemmas oder der ganzen Artikel wäre zudem auch was Feines.
  • Phabricator tickets:

Community discussion

I agree. While 200 per page is reasonable for most situatios, there may be users with reason to see fewer (e.g slow connections) or more. עוד מישהו Od Mishehu 14:35, 24 November 2016 (UTC)[reply]

Voting – Free choice in the number of category entries

  1.   Support Silraks (talk) 16:53, 28 November 2016 (UTC)[reply]
  2.   Support Nocowardsoulismine (talk) 18:19, 28 November 2016 (UTC)[reply]
  3.   Support JAn Dudík (talk) 21:54, 28 November 2016 (UTC)[reply]
  4.   Support. עוד מישהו Od Mishehu 20:28, 29 November 2016 (UTC)[reply]
  5.   Support The typical viewing 25, 50, 100, or 250 results like on Special:Contributions or the history page for example would be good. SamanthaNguyen (talk) 01:03, 1 December 2016 (UTC)[reply]
  6.   Support → «« Man77 »» [de] 22:07, 1 December 2016 (UTC)[reply]
  7.   Support — KPFC 💬 23:09, 1 December 2016 (UTC)[reply]
  8.   Support Draceane (talk) 10:05, 2 December 2016 (UTC)[reply]
  9.   Support --Fixer88 (talk) 20:50, 2 December 2016 (UTC)[reply]
  10.   Support Sometimes the 200 limit and thus the pagination is annoying. And it's awfully arbitrary. Stevie is the man! Talk • Work 17:43, 4 December 2016 (UTC)[reply]
  11.   Support --Fixuture (talk) 22:05, 4 December 2016 (UTC)[reply]
  12.   Support --Alexmar983 (talk) 07:04, 5 December 2016 (UTC)[reply]
  13.   Support Studmult (talk) 07:41, 5 December 2016 (UTC)[reply]
  14.   Support —Ynhockey (talk) 10:08, 7 December 2016 (UTC)[reply]
  15.   Support--Elmidae (talk) 16:11, 7 December 2016 (UTC)[reply]

Global settings

  • Problem: Sometimes a new setting is introduced on all wikis. Recently, it was Compact interlanguage links, before that Editor selection, MediaViewer etc. When somebody is active on multiple wikis and wants to switch-off (or on) such settings, he must do it on every single wiki.
  • Who would benefit:

Users working on multiple wikis

  • Proposed solution: Have the option to check in settings: Set it globally. There should be two checkboxes: one for local setting, second for global setting.
  • More comments: In the next step, it should ask if the user wants to overwrite the setting on wikis where he had chosen a different setting (he already changed it from default).

Community discussion

  • Good idea! Just to give another example where such an option would be very useful: Switch the frontend language or disable/reenable VisualEditor in all Wikipedias at the same time. Often enough it becomes necessary to edit foreign Wikipedias even without having a grasp of their languages, and most foreign Wikipedias are configured to pop up VE on the first edit. Editors, who cannot use VE for technical or security reasons, will then have to blindly navigate to the "Preferences" dialog, switch the language to English and search for an option to disable the VE before they can carry out the actual edit. This is very time-consuming and an unnecessary wastage of their precious editing resources. Global settings would fix this. --Matthiaspaul (talk) 22:26, 10 November 2016 (UTC)[reply]
  • A way to change the skin on all Wikis would be also very helpful. -- Freddy2001 talk 11:27, 11 November 2016 (UTC)[reply]
  • Yes, I always wanted a way to have all projects to have English as the default language.--Dixtosa (talk) 10:22, 12 November 2016 (UTC)[reply]
  • This sounds useful. A multilingualinterface setting page (language by choice) when possible seems a good idea. We are cross-wiki users de facto under many aspects. Of course if some wiki has some reason to opt out, we can discuss it, but the "default" for an established cross-wiki feature should be some sort of meta-wiki management.--Alexmar983 (talk) 11:38, 12 November 2016 (UTC)[reply]
  • I can see the usefulness of this idea. It fits well into how various wiki aspects being globalized. Stevie is the man! Talk • Work 17:05, 13 November 2016 (UTC)[reply]
  • I think this was suggested before, not sure where exactly. Certainly a really useful feature. Setting the interface language and email settings on xx wikis is annoying. --mfb (talk) 12:30, 14 November 2016 (UTC)[reply]

Voting – Global settings

  1.   Support. This would be make working across multiple wikis considerably more convenient. Stevie is the man! Talk • Work 02:09, 28 November 2016 (UTC)[reply]
  2.   Support--Shizhao (talk) 02:48, 28 November 2016 (UTC)[reply]
  3.   Support--Alexander Misel (talk) 06:10, 28 November 2016 (UTC)[reply]
  4.   Support BethNaught (talk) 08:16, 28 November 2016 (UTC)[reply]
  5.   Support Samwalton9 (talk) 09:22, 28 November 2016 (UTC)[reply]
  6.   Support --Kudpung (talk) 14:35, 28 November 2016 (UTC)[reply]
  7.   Support —MarcoAurelio 15:14, 28 November 2016 (UTC)[reply]
  8.   Support --XXN (talk) 16:09, 28 November 2016 (UTC)[reply]
  9.   Support – Meiræ 16:24, 28 November 2016 (UTC)[reply]
  10.   Support--Alexmar983 (talk) 17:09, 28 November 2016 (UTC)[reply]
  11.   Support -Nocowardsoulismine (talk) 18:20, 28 November 2016 (UTC)[reply]
  12.   Support JAn Dudík (talk) 21:53, 28 November 2016 (UTC)[reply]
  13.   Support --Izno (talk) 00:45, 29 November 2016 (UTC)[reply]
  14.   Support Aracali (talk) 03:15, 29 November 2016 (UTC)[reply]
  15.   Support. I am active in two Wikipedias et caetera (more about me). Gamliel Fishkin 04:08, 29 November 2016 (UTC)[reply]
  16.   Support · · · Peter (Southwood) (talk): 08:54, 29 November 2016 (UTC)[reply]
  17.   Support Arian Talk 13:14, 29 November 2016 (UTC)[reply]
  18.   Support Spinster (talk) 15:16, 29 November 2016 (UTC)[reply]
  19.   Support --YMS (talk) 16:32, 29 November 2016 (UTC)[reply]
  20.   Support Matěj Suchánek (talk) 16:40, 29 November 2016 (UTC)[reply]
  21.   Support Guycn2 · ☎ 18:42, 29 November 2016 (UTC)[reply]
  22.   Support --Telaneo (User talk page) 21:46, 29 November 2016 (UTC)[reply]
  23.   Support --Matthiaspaul (talk) 01:12, 30 November 2016 (UTC)[reply]
  24.   Support Alexei Kopylov (talk) 08:56, 30 November 2016 (UTC)[reply]
  25.   Support to get rid of visual editor in all wikis by a single click! 4nn1l2 (talk) 12:37, 30 November 2016 (UTC)[reply]
  26.   Support-- ARASH PT  talk  14:19, 30 November 2016 (UTC)[reply]
  27.   Support Trizek from FR 18:04, 30 November 2016 (UTC)[reply]
  28.   Support -FASTILY 02:27, 1 December 2016 (UTC)[reply]
  29.   Support MER-C (talk) 05:24, 1 December 2016 (UTC)[reply]
  30.   Support --Nouill (talk) 13:22, 1 December 2016 (UTC)[reply]
  31.   Support --β16 - (talk) 15:57, 1 December 2016 (UTC)[reply]
  32.   Support Ahm masum (talk) 17:20, 1 December 2016 (UTC)[reply]
  33.   Support --Vachovec1 (talk) 19:42, 1 December 2016 (UTC)[reply]
  34.   Support No more having to make sure all my settings are the same would be great! — Gestrid (talk) 20:00, 1 December 2016 (UTC)[reply]
  35.   Support Oliv0 (talk) 20:10, 1 December 2016 (UTC)[reply]
  36.   Support Louis Wu (talk) 21:35, 1 December 2016 (UTC)[reply]
  37.   Support — KPFC 💬 23:08, 1 December 2016 (UTC)[reply]
  38.   Support Gryllida 23:58, 1 December 2016 (UTC)[reply]
  39.   Support NMaia (talk) 02:33, 2 December 2016 (UTC)[reply]
  40.   Support CFynn (talk) 05:45, 2 December 2016 (UTC)[reply]
  41.   Support Draceane (talk) 10:06, 2 December 2016 (UTC)[reply]
  42.   Support —Jc86035 (talk) 11:13, 2 December 2016 (UTC)[reply]
  43.   Support Sannita - not just another it.wiki sysop 14:27, 2 December 2016 (UTC)[reply]
  44.   Support --Entbert (talk) 15:02, 2 December 2016 (UTC)[reply]
  45.   Support Jo-Jo Eumerus (talk, contributions) 16:04, 2 December 2016 (UTC)[reply]
  46.   Support Laurentius (talk) 19:33, 2 December 2016 (UTC)[reply]
  47.   Support --Framawiki (talk) 20:34, 2 December 2016 (UTC)[reply]
  48.   Support --Fixer88 (talk) 20:36, 2 December 2016 (UTC)[reply]
  49.   Support Doc James (talk · contribs · email) 04:24, 3 December 2016 (UTC)[reply]
  50.   Support Jo-Jo Eumerus (talk, contributions) 09:36, 3 December 2016 (UTC)[reply]
  51.   Support --Steinsplitter (talk) 10:04, 3 December 2016 (UTC)[reply]
  52.   Support Jianhui67 talk★contribs 10:08, 3 December 2016 (UTC)[reply]
  53.   Support --Continua Evoluzione (talk) 14:59, 3 December 2016 (UTC)[reply]
  54.   Support --Ping08 (talk) 02:24, 4 December 2016 (UTC)[reply]
  55.   Support --Yeza (talk) 13:15, 4 December 2016 (UTC)[reply]
  56.   Support --MGChecker (talk) 15:09, 4 December 2016 (UTC)[reply]
  57.   Support --Dixtosa (talk) 15:15, 4 December 2016 (UTC)[reply]
  58.   Support --Rschen7754 04:46, 5 December 2016 (UTC)[reply]
  59.   Support Freayd (talk) 06:22, 5 December 2016 (UTC)[reply]
  60.   Support ·addshore· talk to me! 10:47, 5 December 2016 (UTC)[reply]
  61.   Support --Andropov (talk) 18:29, 5 December 2016 (UTC)[reply]
  62.   Support It could be similar to global user page on meta-wiki: all your settings on meta-wiki are automatically copied to wikis where you haven't manually changed them. ArgonSim (talk) 21:36, 5 December 2016 (UTC)[reply]
  63.   Support because it would help individual projects say "no" to features that they do not want. --Tryptofish (talk) 23:46, 5 December 2016 (UTC)[reply]
  64.   Support --Hedwig in Washington (talk) 04:25, 6 December 2016 (UTC)[reply]
  65.   Support Zone42 (talk) 12:23, 6 December 2016 (UTC)[reply]
  66.   Support Muhraz (talk) 16:02, 6 December 2016 (UTC)[reply]
  67.   Support -- Amanda (aka DQ) 21:08, 6 December 2016 (UTC)[reply]
  68.   Support Ks0stm (T•C•G) 21:18, 6 December 2016 (UTC)[reply]
  69.   Support. - Mailer Diablo (talk) 07:00, 7 December 2016 (UTC)[reply]
  70.   Support TheCatalyst31 (talk) 02:18, 8 December 2016 (UTC)[reply]
  71.   Support — Rhododendrites talk \\ 05:58, 8 December 2016 (UTC)[reply]
  72.   Support Amir (talk) 18:34, 8 December 2016 (UTC)[reply]
  73.   Support - Go for commonality. DPdH (talk) 20:50, 8 December 2016 (UTC)[reply]
  74.   Support --Carnildo (talk) 02:13, 10 December 2016 (UTC)[reply]
  75.   Support --OrsolyaVirág (talk) 13:09, 10 December 2016 (UTC)[reply]
  76.   Strong support За один глобальный аккаунт с одными глобальными настройками.--TOMA646 (mail | talk) 14:07, 10 December 2016 (UTC)[reply]
  77.   Support --Alaspada (Talk) 03:10, 11 December 2016 (UTC)[reply]
  78.   Support--David1010 (talk) 21:01, 11 December 2016 (UTC)[reply]
  79.   Support FoCuSandLeArN (talk) 23:04, 11 December 2016 (UTC)[reply]
  80.   Support. For instance, I don't really understand why I have to set my gender in each project individually, as there is no reason to assume that I might want to change it from one project to another — NickK (talk) 00:48, 12 December 2016 (UTC)[reply]
  81.   Support--Shanmugamp7 (talk) 04:20, 12 December 2016 (UTC)[reply]
  82.   Support--Mikheil Talk 21:08, 12 December 2016 (UTC)[reply]
  83.   Support --Yann (talk) 23:27, 12 December 2016 (UTC)[reply]
  84.   Support Samat (talk) 23:36, 12 December 2016 (UTC)[reply]
  85.   Support --Hsarrazin (talk) 11:30, 27 February 2018 (UTC)[reply]

New option: Hide bots in logs

  • Problem: When bots are mass deleting/renaming pages or blocking users (usually open proxies), due to the large number of actions made by bots, it's difficult (for humans) to read logs (Special:Logs).
Example: https://ru.wikipedia.org/w/index.php?title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%96%D1%83%D1%80%D0%BD%D0%B0%D0%BB%D1%8B/delete&offset=20161110130056&limit=200&type=delete&user=
  • Who would benefit: All human users :)
  • Proposed solution:
Front end: Add an option to hide bots, eventually as a link with &hidebots=1, like in Special:RecentChanges or Special:Watchlist
Back end: It may be necessary to modify the logging table by adding a column to store info about bot flag of action performer

Community discussion

none

Voting – Option to hide bots in logs

  1.   Support--Wesalius (talk) 08:34, 28 November 2016 (UTC)[reply]
  2.   Support. Gamliel Fishkin 04:09, 29 November 2016 (UTC)[reply]
  3.   Support Guycn2 · ☎ 18:43, 29 November 2016 (UTC)[reply]
  4.   Support Alexei Kopylov (talk) 08:57, 30 November 2016 (UTC)[reply]
  5.   Support -FASTILY 02:27, 1 December 2016 (UTC)[reply]
  6.   Support MER-C (talk) 10:55, 1 December 2016 (UTC)[reply]
  7.   Support. Matiia (talk) 23:36, 2 December 2016 (UTC)[reply]
  8.   Support. LlamaAl (talk) 04:27, 3 December 2016 (UTC)[reply]
  9.   Support Jo-Jo Eumerus (talk, contributions) 09:33, 3 December 2016 (UTC)[reply]
  10.   Support --Ping08 (talk) 02:31, 4 December 2016 (UTC)[reply]
  11.   Support --MGChecker (talk) 15:09, 4 December 2016 (UTC)[reply]
  12.   Support Stevie is the man! Talk • Work 17:45, 4 December 2016 (UTC)[reply]
  13.   Support Seems simple enough? --Hedwig in Washington (talk) 04:27, 6 December 2016 (UTC)[reply]
  14.   Support Muhraz (talk) 16:03, 6 December 2016 (UTC)[reply]
  15.   Support FoCuSandLeArN (talk) 23:02, 11 December 2016 (UTC)[reply]
  16.   Support. Not a particularly high priority but useful — NickK (talk) 00:49, 12 December 2016 (UTC)[reply]

Human readable HTML emails

  • Problem: Emails from wikipedia for participants in languages different from English are generally coming in alien language %BD%D0%. 50-75% of the text of the letter comes in the language of (for?) the aliens.
  • Who would benefit: participants from Wikipedias, where alphabet without the English letters
  • Proposed solution: In wiki-settings we have the option "send emails as html". So who wants to see a plain text that will change this option. For participants must be sent normal HTML emails. To do so, as it is in Echo notifications emails.

Community discussion

I added an additional ticket regarding sending html emails. —TheDJ (talk • contribs) 12:02, 16 November 2016 (UTC)[reply]

Well, I'd say the actual text in the emails is human readable, it's just that any included URLs might be encrypted and look really confusing, right? Rephrasing the proposal summary is welcome to clarify that. :) --AKlapper (WMF) (talk) 13:22, 16 November 2016 (UTC)[reply]
  • it's not just "looks". From year to year, you make us use it, click inside it %BD%D0%. We are forced to use these links. It's not a "might be", it's "always". Think it's nice for us a multiple of these inside each email:
Удалить страницы из вашего списка
наблюдения
https://ru.wikipedia.org/w/index.php?title=%D0%9E%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0:%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5_%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B8&action=unwatch
--Сунприат (talk) 15:48, 16 November 2016 (UTC)[reply]
T13547 is specifically about links handled by the software (ie. you click the link in the email, and then something happens, such as your email address gets confirmed). As for human-readability of links, obviously HTML emails are the way to go (IIRC there was a GSoC project to enable it, not sure what the outcome was; see also the RfC to merge Echo to core which HTML emails are probably blocked on). In plaintext emails, you either use an URI, which will look like this since most characters must be percent-encoded, or you use an IRI in which case you risk old browsers being unable to handle it and autolinking in the email client quite likely making mistakes in finding the end of the link. --Tgr (WMF) (talk) 21:25, 16 November 2016 (UTC)[reply]
Ah, phab:T15303 ("Implement HTML e-mail support in MediaWiki") is potentially blocked on phab:T128351 ("RfC: Notifications in core"). Thanks, Tgr. Quiddity (WMF) (talk) 18:48, 17 November 2016 (UTC)[reply]
    • No, the anchors is a separate painful problem. In the letters we don't get the anchor. (anchors exist in echo letters, but they are "hidden inside" the action buttons). All %BD%D0% maybe "stay", but be hidden using HTLM tags for links. Here's a typical letter http://pastebin.com/vN0Xj82Z - %BD%D0% inside and "a href" and "a link text"! --Сунприат (talk) 09:33, 17 November 2016 (UTC) (Can you tell me why in letters so much br, so short text lines?--Сунприат (talk) 09:38, 17 November 2016 (UTC))[reply]

Voting – Human readable HTML emails

  1.   Oppose While I can see that HTML emails may improve the situation for some (and I have no objections to use them in such cases), I would strongly opt against making this the default or even make it impossible to select ASCII mails. HTML mails impose a security risk, and since almost all SPAM comes in form of HTML mails, they are often filtered out into a quarantine or SPAM folder. --Matthiaspaul (talk) 01:29, 30 November 2016 (UTC)[reply]
  2.   Oppose not convinced this is an issue. -FASTILY 02:27, 1 December 2016 (UTC)[reply]
  3.   Oppose --Hedwig in Washington (talk) 04:28, 6 December 2016 (UTC)[reply]

  • Problem: The version history shows me a green text "updated since my last visit" to indicate that a given version of an article is an updated version compared to my last visit. To actually see all changes between the last version I have visited and that more recent version, I have to select both versions and click "Compare selected revisions" to create a diff.
  • Who would benefit: All authors who contribute to an article several times over a longer stretch of time.
  • Proposed solution: As a straightforward, easier and faster solution, the text "updated since my last visit" could have a hyperlink to the diff with the changes between my last visit and that version.
  • More comments: This solution would not add to visual clutter, as it would merely add a hyperlink from a text that is already displayed. By the way, other users may not see the text "updated since my last visit" but may have some other indication, like a coloured dot or something similar, depending on the user preferences etcetera. The same solution applies in this case: the dot or whatever it is would have a hyperlink to the diff with the changes between the user's last visit and that version.
  • Phabricator tickets:

Community discussion

  • @Fixuture: Indeed the suggestions are not quite the same because the Hyperlink from "updated since my last visit" to the diff suggestion is for the version history, and the Make it easy to quickly see all changes since last visit suggestion is for the watchlist. Yet there is a lot of synergy: if the version-history-suggestion were implemented, then the watchlist-suggestion would mean inserting the earliest of those version-history-difflinks straight into the watchlist. In brief: I think both suggestions would fit together neatly, each adding to the other's usability. --Chris Howard (talk) 22:23, 24 November 2016 (UTC)[reply]
  1.   Support. Gamliel Fishkin 04:10, 29 November 2016 (UTC)[reply]
  2.   Support, as I've said in my suggestion that I linked above I think this would be the most useful / time-saving suggestion of all. --Fixuture (talk) 22:16, 29 November 2016 (UTC)[reply]
  3.   Support--Alexmar983 (talk) 05:52, 30 November 2016 (UTC)[reply]
  4.   Support -- Haku (talk) 00:02, 2 December 2016 (UTC)[reply]
  5.   Support -- Angelorenzi (talk) 14:25, 3 December 2016 (UTC)[reply]
  6.   Support --Continua Evoluzione (talk) 14:49, 3 December 2016 (UTC)[reply]
  7.   Support Stevie is the man! Talk • Work 17:49, 4 December 2016 (UTC)[reply]
  8.   Oppose - Perhaps I don't understand properly (in which case, ping me), but is the hassle saved just looking at where the "updated since my last visit" ends, clicking the radio button, then clicking compare? — Rhododendrites talk \\ 06:02, 8 December 2016 (UTC)[reply]
  9.   Support - DPdH (talk) 12:26, 9 December 2016 (UTC)[reply]
  10.   Support Very easy to do, and quite effective. --Waldir (talk) 11:17, 10 December 2016 (UTC)[reply]

Improve the stability of the page while loading

  • Problem: while a wiki page is loading in a browser, it keeps jumping about as additional page elements appear, especially promo banners or edit notices at the top, but even parts of the navigation bar at the left. Countless times when editing on my tablet I have clicked a link on a page that was mostly loaded, but the page jumped again as one more element loaded, and the wiki acts on the element that ended up where I clicked, rather than the one that was there at the moment that I clicked. For example, it takes me to "Contact page" rather than "What links here", or to "Help:Edit summary" instead of accepting my click on "Save changes". It may also insert a code from a button on the advanced editing toolbar instead of accepting a click within the text. (This is not just fat-finger syndrome.)
  • Who would benefit: Editors, especially when using mobile devices.
  • Proposed solution: (i) Anticipate the space required for elements yet to appear when displaying the elements that are visible so far; I believe this ought at least to be feasible in the nav bar at the left. (ii) Disable entry in the editing pane until all page elements have appeared; if this would not be universally popular, then give us a preference setting. (iii) Prioritise improvements in speed of loading page elements.
  • Phabricator tickets:

Community discussion

  • Not bad, I hope we could do something in this direction.--Alexmar983 (talk) 09:43, 16 November 2016 (UTC)[reply]
  • I think this is mostly solved for as far as it is solvable. The fact that we need to target different audiences, and by having 100s of tools that need to be visible and/or not for each and every page depending on the user, sort of complicates this problem beyond the ability to solve it. We could consider making the central banners completely float, but I don't think that many people would appreciate that either. If you disable Javascript, then you have fewer tools, but also no problems like these. —TheDJ (talk • contribs) 12:07, 16 November 2016 (UTC)[reply]
  • This is one of the minor problems on the Wikipedia that drives me the most batty, and I was considering proposing this myself. I too end up frequently clicking the wrong tab, like clicking "View history" when I meant to click "Edit". Like TheDJ suggests, there are limitations to what can be done because of how webpage design and personal preferences work together. But, I think we should try to find ways to reduce misclicking incidents. One seemingly simple idea: On the Vector skin, there's two sets of page tabs, one starting from the left (e.g., [Article] [Talk]), and the other from the right (starting with e.g. [Read] [Edit] [View history]) -- it's the tabs on the right that pose a problem as they fill in, moving left, as the page loads. Why not have all tabs load from the lefthand side, moving right, so that you'll know the tab will still be there when you click it? Otherwise, perhaps menu elements (and their relative positions) could be cached or locked somehow. Or have JavaScript run with much better performance. :) Seriously, though, maybe there's many minor interface tweaks that are possible to reduce the jumping around. Stevie is the man! Talk • Work 19:59, 16 November 2016 (UTC)[reply]
  • I have the same issue on Commons I often click on a link which just jumped around and I am heading to a wrong page. Very annoying. But I am not sure if there is a solution other than not using any gadgets that change the interface. --Jarekt (talk) 04:13, 17 November 2016 (UTC)[reply]
yes that occurs so many times! And since it happens when the upload is slow, getting back to the original page to re-click the right link is also slow itself.--Alexmar983 (talk) 04:15, 18 November 2016 (UTC)[reply]

Voting – Stability of the page while loading

  1.   Support per my discussion above. Anything that can be done to improve the positional stability of page elements as the wiki page loads will be good for common use of the wikis. Stevie is the man! Talk • Work 01:57, 28 November 2016 (UTC)[reply]
  2.   Support It's hugely annoying, especially on mobile, to have to guess when the page has finished loading in case you click something by accident. Samwalton9 (talk) 09:23, 28 November 2016 (UTC)[reply]
  3.   Support This is particularly an issue when loading the wikitext edit page. This, that and the other (talk) 11:10, 28 November 2016 (UTC)[reply]
  4.   Support huge problem for power users, Sadads (talk) 15:37, 28 November 2016 (UTC)[reply]
  5.   Support A feature with a high nuisance value: you follow a link to one of many threads on a big discussion page; you are taken straight there; start reading and then the thing's gone and to find it again do you have to go six screens up or six down?Noyster (talk) 21:16, 28 November 2016 (UTC)[reply]
  6.   Support. Gamliel Fishkin 04:11, 29 November 2016 (UTC)[reply]
  7.   Support --YMS (talk) 16:33, 29 November 2016 (UTC)[reply]
  8.   Support StevenJ81 (talk) 17:54, 29 November 2016 (UTC)[reply]
  9.   Support --Telaneo (User talk page) 21:47, 29 November 2016 (UTC)[reply]
  10.   Support This also happens when I click on a link with a section in it. For example, I'll click on a section link that takes me to a section on w:WP:ANI. It takes me to the section, then an additional element on the page loads, causing the section to (usually) go below where it took me, so I have to then scroll down to find it again. (I hope that all made sense.) — Gestrid (talk) 20:09, 1 December 2016 (UTC)[reply]
  11.   Support Gollem (talk) 20:22, 1 December 2016 (UTC)[reply]
  12.   Support I agree this is annoying. I'm afraid, though that this won't be actionable as it's usually caused by addtional features like user scripts. Matěj Suchánek (talk) 21:13, 1 December 2016 (UTC)[reply]
  13.   Support encounter this problem too particularly on big pages, agree it is annoying Gryllida 00:00, 2 December 2016 (UTC)[reply]
  14.   Support NMaia (talk) 02:34, 2 December 2016 (UTC)[reply]
  15.   Support--Alexmar983 (talk) 07:25, 2 December 2016 (UTC)[reply]
  16.   Support --Fixer88 (talk) 20:37, 2 December 2016 (UTC)[reply]
  17.   Support Jack who built the house (talk) 21:19, 2 December 2016 (UTC)[reply]
  18.   Support // Martin Kraft (talk) 23:45, 2 December 2016 (UTC)[reply]
  19.   Support I hate this problem. It slows down my editing when what I am trying to click on keeps moving. I want the things to hold still. Doc James (talk · contribs · email) 04:14, 3 December 2016 (UTC)[reply]
  20.   Support --Ping08 (talk) 02:47, 4 December 2016 (UTC)[reply]
  21.   Support Gareth (talk) 10:45, 4 December 2016 (UTC)[reply]
  22.   Support: Should be useful - Best regards, Kertraon (talk) 11:59, 4 December 2016 (UTC)[reply]
  23.   Support - εΔω 20:50, 4 December 2016 (UTC)
  24.   Support Wikidata is especially susceptible to this. --Rschen7754 04:47, 5 December 2016 (UTC)[reply]
  25.   Support ·addshore· talk to me! 10:47, 5 December 2016 (UTC)[reply]
  26.   Support --Andropov (talk) 18:33, 5 December 2016 (UTC)[reply]
  27.   Support ArgonSim (talk) 21:39, 5 December 2016 (UTC)[reply]
  28.   Neutral Yes, I've been aggravated by this problem too, but I question whether there is a practical fix for it. Some of the problem is with browser performance, and some of it is because there are various sub-elements such as templates on each page. I think having the edit screen not display until everything is loaded will just result in blank screens for a long time. --Tryptofish (talk) 23:52, 5 December 2016 (UTC)[reply]
  29.   Support I would love to see this fixed. It seemed to get worse after the introduction of Wikipedia:Notifications/Thanks. Discussion here in May. SarahSV talk 05:13, 6 December 2016 (UTC)[reply]
  30.   Support Muhraz (talk) 16:03, 6 December 2016 (UTC)[reply]
  31.   Support Annoying problem! Blue Rasberry (talk) 19:22, 6 December 2016 (UTC)[reply]
  32.   Strong support Yes please, definitely! Ks0stm (T•C•G) 21:19, 6 December 2016 (UTC)[reply]
  33.   Strong support -- Amanda (aka DQ) 21:27, 6 December 2016 (UTC)[reply]
  34.   Support. - Mailer Diablo (talk) 07:00, 7 December 2016 (UTC)[reply]
  35.   Support God, yes. Playing "hunt the edit summary bar" after doing a quick revert is driving me nuts.--Elmidae (talk) 16:14, 7 December 2016 (UTC)[reply]
  36.   Support Not a Wikipedia-exclusive problem, but certainly a frustrating one. TheCatalyst31 (talk) 02:20, 8 December 2016 (UTC)[reply]
  37.   Strong support love this — Rhododendrites talk \\ 06:02, 8 December 2016 (UTC)[reply]
  38.   Support I'm forever logging myself out when I mean to click my contributions. Espresso Addict (talk) 04:00, 9 December 2016 (UTC)[reply]
  39.   Support Miniapolis 16:11, 9 December 2016 (UTC)[reply]
  40.   Support --Carnildo (talk) 02:17, 10 December 2016 (UTC)[reply]
  41.   Support --g (talk) 10:26, 10 December 2016 (UTC)[reply]
  42.   Support - Bcharles (talk) 14:51, 10 December 2016 (UTC)[reply]
  43.   Support it's irritating --Alaspada (Talk) 03:23, 11 December 2016 (UTC)[reply]
  44.   Support This would be a nice feature. --Vachovec1 (talk) 12:13, 11 December 2016 (UTC)[reply]
  45.   Support --Kenzia (talk) 20:26, 11 December 2016 (UTC)[reply]
  46.   Support, I particularly hate it with banners on Wikidata, as this mostly results in missing a language or a statement — NickK (talk) 00:51, 12 December 2016 (UTC)[reply]
  47.   Support Samat (talk) 23:38, 12 December 2016 (UTC)[reply]

Linking of accounts controlled by one user

  • Problem: Many users control multiple accounts in addition to their main account, such as bots, staff accounts, or general test accounts. We don't currently have a good way to explicitly link these accounts or allow aspects of them (e.g. notifications, talk pages) to be shared.
  • Who would benefit: All users with multiple accounts; likely to be primarily experienced users
  • Proposed solution: It might take some discussion to find the most desired aspects to this problem, but suggestions include (optional, per linked account) notification sharing, automatically linked talk pages, shared preferences, or even shared login details. Perhaps users could be allowed to switch between their linked accounts on the fly (from a drop down menu next to their username, top right, for example).

Community discussion

  • I can see several instances where such a feature could be useful, but I can't see it as a development priority Kudpung (talk) 11:28, 13 November 2016 (UTC)[reply]
  • I keep asking it. There is also some confusion about the role of allowed suckpuppets. I mean rules are not the same everywhere, and that's a long-term problem. And I find so frustrating also that WIR have to create a new account but there is no way to link it in an efficient way to their main private account, and they write this information here and there, so dispersive. We should in SUL perspective provide an interface where we take the account B (WIR, sockpuppet, bot...) and we store an official information that it belongs to us, account A, too. So people can get this info easily form whichever platform and language they're active. I'm not saying it should be compulsory, but for some of us would be useful. And that's only about the shared information, than there's the rest suggested in the proposal (for example preferences management, being able to open them for both at same time and decide what should be different and what not)--Alexmar983 (talk) 15:07, 16 November 2016 (UTC)[reply]

There was a similar proposal by JAn Dudík, which is archived here: Link main account with bot accounts in notifications. -- DannyH (WMF) (talk) 01:52, 24 November 2016 (UTC)[reply]

Voting – Linking accounts controlled by one user

  1.   Support As proposer (if I'm allowed!). Samwalton9 (talk) 09:23, 28 November 2016 (UTC)[reply]
  2.   Support. Jules78120 (talk) 12:31, 28 November 2016 (UTC)[reply]
  3.   Support--Alexmar983 (talk) 17:21, 28 November 2016 (UTC)[reply]
  4.   Support JAn Dudík (talk) 21:54, 28 November 2016 (UTC)[reply]
  5.   Support I want to be sure that when I revert a bot eddit, the owner of a bot will see this. Alexei Kopylov (talk) 08:59, 30 November 2016 (UTC)[reply]
  6.   Support For me it can be very useful to standardize the use of multi accounts. And more generally, in WMF there are to many redondant user page/user talk page, etc. --Nouill (talk) 13:20, 1 December 2016 (UTC)[reply]
  7.   Oppose as a security risk for Administrators, CheckUsers, Bureaucrats, etc.. We don't want someone gaining access to an admin's non-admin account (Some admins create one for use on public computers.) and then gaining access to the admin's actual admin account using this. — Gestrid (talk) 20:24, 1 December 2016 (UTC)[reply]
  8.   Support for notifications only, and any connecting between accounts should not involve login info (per security), but instead a Bluetooth-like handshaking (one account requests and the other account accepts, and either can disconnect at any time). Otherwise, this would seem insecure per Gestrid. Stevie is the man! Talk • Work 14:03, 4 December 2016 (UTC)[reply]
  9.   Oppose Not often needed feature with high-security risks. I use redirects and that works just fine. --Hedwig in Washington (talk) 04:32, 6 December 2016 (UTC)[reply]
  10.   Support This has implications for important institutional partnerships, as currently, it is challenging for organizations to partner with Wikipedia. Development of this functionality would guide future partnerships. Blue Rasberry (talk) 19:24, 6 December 2016 (UTC)[reply]
  11.   Support Miniapolis 16:33, 9 December 2016 (UTC)[reply]
  12.   Oppose per Gestrid --g (talk) 10:27, 10 December 2016 (UTC)[reply]
  13.   Support A certain level of linking - notifications, in particular - would be useful. Guettarda (talk) 16:41, 12 December 2016 (UTC)[reply]

Make it easy to embed Wikimedia content

Note, this is also an idea over at IdeaLab
  • Problem: There needs to be a consistent, easy way to embed and reuse Wikimedia content outside of WMF-supported wikis. The ability to embed content has been incredibly successful for other online resources of media - Flickr, Soundcloud, YouTube, TED, Instagram and more. Especially with the declining importance of Google in mediating the Internet, exposing the content within our movement outside of our corner of the world can draw more people back to our projects.
  • Who would benefit: People who reuse Wikimedia content outside of our wiki ecosystem and the many contributors who wish to see their contributions used with appropriate attribution. GLAM, researchers, journalists, writers, and the average person sharing a link on social media.
  • Proposed solution: Expose a metadata schema(s) from Wikimedia content sources (article and file URLs are the most obvious) that would allow other parts of the web to consistency, easily, and richly embed content within their web sites.
  • More comments: Please visit the entry at IdeaLab for examples and more information.

Community discussion

  • Not just embedding into websites, but also basic sharing to common social media sites would be great to have. We shouldn't have to rely on search engines for folks to find Wikipedia content. Stevie is the man! Talk • Work 15:25, 20 November 2016 (UTC)[reply]
  • A relatively lightweight (albeit partial) solution to this problem would be to implement some standard like Open Graph as mentioned in the task. That would let us add metadata to pages like its title, image, and so on, to avoid the problem of badly cropped images, weird titles, or text snippets that are too long when an article is shared. The advantage of this is that Open Graph uses an Open Web Foundation licence, so it's not proprietary at all; anyone who reuses our content could benefit from it. Other more complex (and potentially more rewarding) solutions would likely involve more integration with specific proprietary platforms; I don't have anything against that in principle, but it does tend to be looked down on by others. --Dan Garry, Wikimedia Foundation (talk) 01:14, 22 November 2016 (UTC)[reply]

Voting – Easy embedding of Wikimedia content

  1.   Support Long overdue. Needed years ago. Wikis shouldn't depend mostly on search sites for content discovery. Stevie is the man! Talk • Work 02:11, 28 November 2016 (UTC)[reply]
  2.   Support--Wesalius (talk) 08:34, 28 November 2016 (UTC)[reply]
  3.   Support Long overdue, Sadads (talk) 15:38, 28 November 2016 (UTC)[reply]
  4.   Support We are essentially about sharing, and the ability to embed while carrying metadata would be a transformative capability! Ocaasi (talk) 18:33, 28 November 2016 (UTC)[reply]
  5.   Support Spinster (talk) 15:17, 29 November 2016 (UTC)[reply]
  6.   Support--Alexmar983 (talk) 05:53, 30 November 2016 (UTC)[reply]
  7.   Support, why is it not possible to easily embed a Wikipedia article right now? --Fixuture (talk) 20:30, 30 November 2016 (UTC)[reply]
  8.   Support Ahm masum (talk) 17:20, 1 December 2016 (UTC)[reply]
  9.   Support As a Bureaucrat for a (relatively small in comparison) wiki that's outside the Wikimedia "network", I definitely support this. There are too many features that are either exclusive to Wikimedia wikis or just too hard to access/ implement in other wikis. — Gestrid (talk) 20:30, 1 December 2016 (UTC)[reply]
  10.   Support Louis Wu (talk) 21:38, 1 December 2016 (UTC)[reply]
  11.   Support, especially for reasons of improved attribution czar 01:30, 2 December 2016 (UTC)[reply]
  12.   Support NMaia (talk) 02:38, 2 December 2016 (UTC)[reply]
  13.   Support Sannita - not just another it.wiki sysop 14:28, 2 December 2016 (UTC)[reply]
  14.   Support --Fixer88 (talk) 20:38, 2 December 2016 (UTC)[reply]
  15.   Support Gareth (talk) 10:44, 4 December 2016 (UTC)[reply]
  16.   Support But make it in a way that the user doesn't have to magically find out s/he can do it by accidentally clicking a mysterious link on the tools sidebar. It should be intuitive and obvious. ArgonSim (talk) 22:49, 5 December 2016 (UTC)[reply]
  17.   Support in a general sense. It's what the purpose of Wikimedia really is. --Tryptofish (talk) 23:54, 5 December 2016 (UTC)[reply]
  18.   Support Muhraz (talk) 16:04, 6 December 2016 (UTC)[reply]
  19.   Support Ciridae (talk) 09:55, 8 December 2016 (UTC)[reply]
  20.   Support --g (talk) 10:28, 10 December 2016 (UTC)[reply]
  21.   Support This is a decade overdue, and it would also reduce to "piracy" (reuse without credit) of WP content.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:29, 11 December 2016 (UTC)[reply]
  22.   Support Quiddity (talk) 08:53, 12 December 2016 (UTC)[reply]
  23.   Support --Malyacko (talk) 11:58, 12 December 2016 (UTC)[reply]

Make it possible to "+1" statements on talk pages

  • Problem: It is extremely difficult for the community to deal with destructive or even toxic statements on a talk page. Ideally, good-faith editors should step up and add individual messages of "counter speech" addressing the issue or add messages of support to those who have done so. However, only few users choose this option and most simply try to ignore destructive statement. This gives such destructive statements undue weight on talk pages, creating unwelcoming environments. It would be good if the community had a tool to visibly reward or support helpful and constructive statements.
  • Who would benefit: everyone
  • Proposed solution: Create a functionality that enables users to visibly express their support for a statement on a talk page.
  • More comments: This proposal is inspired by the existing Thanks extension, which gives the community a possibility to reward edits invisibly. And yes, I know that talk pages are broken, but we need to find ways to make them a more constructive and welcoming environment.
  • Phabricator tickets:

Community discussion

Please feel free to edit the text of this proposal. --Gnom (talk) 22:24, 14 November 2016 (UTC)[reply]

I am afraid this will discourage minority views, which in the current environment can turn around a discussion given that it is well-expressed and based on policies/guidelines. We should not want to popularize viewpoints when having a discussion about the development of an article. Stevie is the man! Talk • Work 18:55, 16 November 2016 (UTC)[reply]

Hi Stevietheman, how do you think this will discourage minority views? --Gnom (talk) 19:04, 16 November 2016 (UTC)[reply]
I think this would be obvious to most Wikipedians that a +1 would make it easier to "pile on" (without having to even justify the positive feeling). "Piling on" discourages other viewpoints, naturally. Stevie is the man! Talk • Work 20:04, 16 November 2016 (UTC)[reply]
My feeling is quite the contrary. I have the impression that on platforms that allow users to visibly show their support for existing messages such as Facebook, Twitter and (especially) Reddit, this encourages the creation of more useful messages. Also, it can make discussions more easy to follow so there is even more room for other viewpoints. --Gnom (talk) 21:47, 18 November 2016 (UTC)[reply]
This is not Facebook. This is a serious encyclopedia development community that expects editors to state why they agree with an idea, not just that they agree. +1 dramatically reduces the seriousness of the overall effort. Stevie is the man! Talk • Work 13:30, 19 November 2016 (UTC)[reply]
Nobody ever said that this is Facebook. Nobody stops editors to state why they agree with an idea if they have any additional thoughts to share which are not a pure waste of time by having to rephrase a previous comment instead of being able to give a simple +1 or "I agree". --Malyacko (talk) 14:37, 22 November 2016 (UTC)[reply]
I wonder if anyone stops to think if there's any purpose for something. There's no purpose for a +1 in an encyclopedia. We don't need populism here. Stevie is the man! Talk • Work 23:01, 22 November 2016 (UTC)[reply]
Initially I agreed with you but after some thought: If people cant vote they will write a chunk of bs that harms productivity because that is the only way to express it. The discussion loses its constructive feedback while those who do give have to read all the bs. The mindless chatter also forces discussion into the archive. While crude voting will allow much greater information density. 84.106.24.118 16:35, 22 December 2016 (UTC)[reply]
How can you have "information density" with a pile of no information? "Me too!" simply adds nothing to a substantive discussion. Also, the "bs" and "mindless chatter" remarks go against "Assume good faith", and frankly, I've seen little of what you describe outside of an !vote or vote. Fortunately, most seem to realize this proposal would wreck professional discussion. Stevie is the man! Talk • Work 21:38, 22 December 2016 (UTC)[reply]
  • This is a good idea, and has proven itself on sites with a lot more trolling than the Wikimedia sites. There are several measures that can be taken to stop misuse, like only giving each user a very limited number of points to assign, and also to add a cost function. A cost function is something you have to do to earn the right to such points. You must earn them first, then you can assign them.
Equally important, or perhaps even more important, is it to be able to "-1" rude remarks. The problem with this is that a "-1" can be used even more trollish than a "+1" as a popular vote. One way to avoid use of the points for trolling is to only act on the points on certain threshold. It must above or below a certain value before it is shown in the thread. Positive threshold could be as low as a single point, but negative threshold could be -2 or -3. If the positive threshold is always shown people will get used to rank statements, even if negative ranking doesn't always count.
By being able to accumulate both positive and negative remarks the community can counteract unwanted behavior. This will not stop groups from cooperating on "voting up comments". There is a trick that can be used to stop cooperating groups, and that is to check for common behavior between individual users. By checking the correlation (could be Bayesian estimator) against a threshold, and using the result for stopping the user from upranking or downranking a comment, will effectively block any cooperative action from a group.
It could even be possible to add a small limit in time or contributions after a user logs in again, and the time could even be measured from the time of the comment. Thereby enforcing some time for the users calm down.
Users can also be given a metaranking. That is simply a rank on how good they follow ranking given by other users. If they deviate too much from ranking by other users, then their ability to rank comments will be lowered, or even removed completely. That imply that new users should only be allowed to assign points with low weights. As they earn their rights they will assign points with more weight.
It is a good idea, but it is a bit more involved than it seems at first. — Jeblad 23:53, 22 November 2016 (UTC)[reply]
If this +1 is to be signed, I would not object. If it is to be totally anonymous, I would oppose strongly.· · · Peter (Southwood) (talk): 09:03, 29 November 2016 (UTC)[reply]

Voting – "+1" statements on talk pages

  1.   Oppose This isn't Reddit, and I don't see how this could be implemented on free-form wikitext discussion pages. BethNaught (talk) 08:16, 28 November 2016 (UTC)[reply]
  2.   Oppose per my concerns stated above. In the development of serious works, participants should have to explain why they support something, not just do the equivalent of "me too!". Stevie is the man! Talk • Work 14:35, 28 November 2016 (UTC)[reply]
  3.   Support It's important to give editors more ways to voice their opinions. One issue on Wikipedia is that only a minority of editors participate in many discussions. A +1 system could encourage constructive participation. -Nocowardsoulismine (talk) 18:32, 28 November 2016 (UTC)[reply]
    Maybe we should look at this in the inverse. Maybe it's good that only those who are willing to back up their opinion with an explanation are participating in the development of an encyclopedia? What value do empty opinions bring besides some kind of sensation, to the development of a serious work? Stevie is the man! Talk • Work 18:42, 28 November 2016 (UTC)[reply]
    A simple gesture of agreement is a valid form of feedback. If it wasn't, then polling, voting, etc. would be useless. Sometimes, there is nothing "wordy" to add after an eloquent editor sums up an argument. It would be interesting to know whether anybody indeed agrees with that person, or if they are alone in their views. A plus button would help better gauge the community's view on matters.
    This may also benefit editors with intellectual/language/learning differences which make it difficult to formulate gramatically correct sentences. It can also give a mode of expression to timid editors, or newbies who are reluctant to join in discussions with veteran editors. -Nocowardsoulismine (talk) 18:10, 29 November 2016 (UTC)[reply]
    We have 'thanks' for simple gestures of agreement, but luckily they don't become part of a serious professional discussion. Also, I don't think there should be accommodations for timidity in a professional development environment (what job provides for timidity?). And newbies shouldn't feel excluded because they are free to comment and receive feedback on their views, so they will learn. How do we more experienced folks respond to a "+1"? We can't. It's devoid of anything to respond to. "+1" is not discourse and thus does not belong on a talk page. Stevie is the man! Talk • Work 22:36, 29 November 2016 (UTC)[reply]
  4.   Support Can't see why this is done years ago. — Jeblad 01:48, 29 November 2016 (UTC)[reply]
  5.   Oppose   -1   Aracali (talk) 03:21, 29 November 2016 (UTC)[reply]
  6.   Support Guycn2 · ☎ 18:45, 29 November 2016 (UTC)[reply]
  7.   Support --Telaneo (User talk page) 21:48, 29 November 2016 (UTC)[reply]
  8.   Oppose Not Facebook etc. --Matthiaspaul (talk) 01:37, 30 November 2016 (UTC)[reply]
  9.   Oppose Normally, users must not read other users' talk pages! 4nn1l2 (talk) 12:50, 30 November 2016 (UTC)[reply]
  10.   Support Trizek from FR 19:41, 30 November 2016 (UTC)[reply]
  11.   Oppose Please don't. This isn't reddit -FASTILY 02:27, 1 December 2016 (UTC)[reply]
  12.   Oppose Per above—interactions with other editors require effort, free-form discussion and should be backed with argument. MER-C (talk) 05:28, 1 December 2016 (UTC)[reply]
  13.   Support Ahm masum (talk) 17:20, 1 December 2016 (UTC)[reply]
  14.   Oppose. Votes can on occasion be useful, but turning everything into a vote by allowing easy votes on every single comment would lower the quality of discussion and harm the collaborative nature of the projects. --Yair rand (talk) 20:19, 1 December 2016 (UTC)[reply]
  15.   Oppose per all the other Opposes here. — Gestrid (talk) 20:33, 1 December 2016 (UTC)[reply]
  16.   Oppose, if i dislike a comment i need to deal with it manually. Gryllida 00:00, 2 December 2016 (UTC)[reply]
  17.   Oppose waste of resources, and would probably shove us into Flow. --Rschen7754 04:46, 5 December 2016 (UTC)[reply]
  18.   Support for +1 and -1. Or even better, redesign the entire discussion system to not just use a standard wikitext page. --WinTakeAll (talk) 22:15, 5 December 2016 (UTC)[reply]
  19.   Oppose This would definitely induce users to think highly of thumbed-up contributions and unconsciously side by them. ArgonSim (talk) 22:55, 5 December 2016 (UTC)[reply]
  20.   Oppose Discussions should be discussions, not votes. --Tryptofish (talk) 23:55, 5 December 2016 (UTC)[reply]
  21.   Support +1 Blue Rasberry (talk) 19:24, 6 December 2016 (UTC)[reply]
  22.   Oppose while I was inclined to think yes, all this does is tip the discussion to the populous discussion, which isn't what we're about. Tiggerjay (talk) 21:12, 6 December 2016 (UTC)[reply]
  23.   Strong oppose Opening a huge can of worms. If it just creates a line that says "+1" and signs, then it's barely a time saver and will result in clutter; if it results in some sort of tally like in FaceBook, then we're looking at new facebooky/reddity norms developing whereby there are votes, scores, numbers substituting for actual discussion, feelings detached from actual editors... madness! Even if we say "such and such is not a vote" or "the quality of competing arguments is not about numbers", we all know that to some extent the things that are "not a vote" are votes, and that numbers influence. Normal oppose in the first scenario, strongest possible oppose in the second. — Rhododendrites talk \\ 06:09, 8 December 2016 (UTC)[reply]
  24.   Oppose A +1 button is too fuzzy, you won't know why the contributor push the button. A button like "I agree this statement" or "This statement have relevant source" would be far better. You might even add a "Thank the user for this comment", if it doesn't already exist. But a +1 can mean to much things in such an informal context as discussion pages. --10:08, 9 December 2016 (UTC)
    Good thought here. I would be far more comfortable with "Thank the user for this comment" instead of what is being proposed because it's not something that makes itself visible inside the discussion. Stevie is the man! Talk • Work 14:07, 10 December 2016 (UTC)[reply]
  25.   Support Miniapolis 16:35, 9 December 2016 (UTC)[reply]
  26.   Oppose Not Facebook LeadSongDog (talk) 18:52, 9 December 2016 (UTC)[reply]
  27.   Oppose we have something more than gesture to communicate with --g (talk) 10:30, 10 December 2016 (UTC)[reply]
  28.   Oppose Wiki is based on discussion, not voting. If someone wants this for MW installations that are not traditional wikis (maybe tech support sites?), a third-party developer can do it. This is not WMF dev work.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:30, 11 December 2016 (UTC)[reply]
  29.   Strong oppose is not "Face de bouc" with like --Alaspada (Talk) 21:03, 11 December 2016 (UTC)[reply]

Mark thanked edits automatically patrolled for some users

  • Problem: If I am busy and I want to thank a edit, I'd probably forget to mark it as patrolled. That's not very efficient. As I have suggested in d:Wikidata:Project chat/Archive/2016/09#Thanking and patrolling in order to refine the patrolling system, it would be nice to test on some platforms an additional feature for users with patroller rights (or whichever more advanced flag the community prefers) to automatically mark as patrolled an edit when it is thanked. At least on wikidata none opposed, and that is a quite big community, where patrolling of items is very important, as it affects other platforms. It's a drop in the ocean, but it is still a little step forward a more efficient edits revision workflow. Thank you.
  • Who would benefit: all projects that need a slight increase in efficiency in their patrolling workflow, and have a clear group of users with a flag they trust. It's not different than the shortcut we give to rollbackers, for example.
  • Proposed solution: for patrollers, or for some other class of trusted users, it should be possible to chose in the preference an option that mark as patrolled an edit that has been thanked. At least in some namespace, like ns0.
  • Phabricator tickets:

Community discussion

Good idea --Achim (talk) 20:49, 11 November 2016 (UTC)[reply]

Voting – Mark thanked edits automatically patrolled for some users

  1.   Support "It's a drop in the ocean, but it is still a little step forward a more efficient edits revision workflow.": yes! Jules78120 (talk) 12:33, 28 November 2016 (UTC)[reply]
  2.   Support StevenJ81 (talk) 17:57, 29 November 2016 (UTC)[reply]
  3.   Support It will also encourage users thank more offen. Alexei Kopylov (talk) 08:49, 30 November 2016 (UTC)[reply]
  4.   Support Trizek from FR 19:42, 30 November 2016 (UTC)[reply]
  5.   Support Julia\talk 22:57, 30 November 2016 (UTC)[reply]
  6.   Support --Nouill (talk) 13:14, 1 December 2016 (UTC)[reply]
  7.   Support --Framawiki (talk) 20:35, 2 December 2016 (UTC)[reply]
  8.   Support --Fixer88 (talk) 20:38, 2 December 2016 (UTC)[reply]
  9.   Support -- SBaker43 (talk) 22:56, 2 December 2016 (UTC)[reply]
  10.   Support for edit patrolling, but absolutely not for new page patrolling. I'm mentioning the latter just in case there's any confusion. Stevie is the man! Talk • Work 14:18, 4 December 2016 (UTC)[reply]
    it depends of the flag architecture, as some wikis do not have a new page patrolling system, they just have a edit-base patrolling system or a version-base patrolling (there are different way to patrol, also expert users unfortunately sometimes make a lot of confusion between them). in edit-based patrolling system if a patroller think a page is ok, there isprobably no problem per se to thank the creation of the page, that means for example the first edit that creates the page, if it is of a good level. In any case, every platform will see what to do. They just have to know how they patrol when they decide to which level give this advanced functionality.--Alexmar983 (talk) 05:17, 5 December 2016 (UTC)[reply]
  11.   Neutral This seems to be more useful for some projects than for others. At enwiki, we don't mark edits as patrolled unless pending changes has been enacted at the page. --Tryptofish (talk) 23:59, 5 December 2016 (UTC)[reply]
  12.   Support Miniapolis 16:38, 9 December 2016 (UTC)[reply]
  13.   Neutral. I happen to thank for edits that cannot be patrolled as is: for instance, I might want to thank a user who created an article on a topic I am really interested in even if this article needs some cleanup (e.g. it has no categories) — NickK (talk) 00:58, 12 December 2016 (UTC)[reply]
add separate bottoms "thank - patrol - thank and patrol" . I never actually intended it as exclusive. I could also be a menu "do you want to thank and patrol or just thank?". I don't think it is too complicated. I also thanked a lot of stuff I didn't patrol. In any case, on other platforms there are additional way to thank users, like simple templates for talk page. --Alexmar983 (talk) 03:07, 12 December 2016 (UTC)[reply]

Non-Latin section headings are displayed terribly in URL anchors and can't be reached directly

(Note: This was split out from the proposal above.)

  • Problem: Non-Latin section headings:
  1. are displayed terribly in URL anchors (https://ru.wikipedia.org/wiki/Википедия:Снятие_защиты#.D0.A1.D0.B8.D0.B1.D0.B8.D1.80.D1.81.D0.BA.D0.B8.D0.B9_.D1.8F.D0.B7.D1.8B.D0.BA.2C_.D0.A1.D0.B8.D0.B1.D0.B8.D1.80.D1.81.D0.BA.D0.B8.D0.B9_.D0.B8.D1.81.D0.BA.D1.83.D1.81.D1.81.D1.82.D0.B2.D0.B5.D0.BD.D0.BD.D1.8B.D0.B9_.D1.8F.D0.B7.D1.8B.D0.BA)
  2. can't be reached directly (https://ru.wikipedia.org/wiki/Википедия:Снятие_защиты#Сибирский_язык,_Сибирский_искусственный_язык).
  • Who would benefit: Wikipedias and other Wikimedia sites on languages using non-Latin alphabet. Wikipedias on Latin-based languages would benefit too, as Unicode characters can appear in section headings.
  • Proposed solution: At least make Unicode anchors work when they have somehow got in the address bar (when copypasting path from wikilinks like this: [[Ссылка#Якорь]], or via links other than [[[wikilinks]]), if total transition (i.e. using unencoded links when converting wikilinks) is not possible due to some hard-to-overcome technical restrictions. Though total transition is obviously preferrable.

Community discussion

Not only non-latin, also latin characters with diacritics. JAn Dudík (talk) 10:11, 14 November 2016 (UTC)[reply]

+1 to that. However, isn't it related to some recent changes in Firefox? I think I can remember someone mentioning it on Wikimedia CEE group on FB... Halibutt (talk) 22:36, 16 November 2016 (UTC)[reply]

This is a browser limitation. See my wikitech-l email about it a while ago (when we had to decide how to use anchors in MediaViewer) and the related Chrome bug report (which got ignored). Filing bugs to browser vendors and getting people to show support there is probably the most effective thing that can be done about it. --Tgr (WMF) (talk) 02:58, 18 November 2016 (UTC)[reply]

@Tgr (WMF): Chrome bug report was closed and archived, unfortunately, due to only 2 stars. Well, at least, you could add an element with alternative id / <a name=""></a> tag to each section heading. Right now user scripts are doing that job in ruwiki, in order to 1) allow editors working with wikicode to jump to section specified by wikilinks like this: [[Ссылка#Якорь]], by copypasting their contents into the address bar, which is a common scenario (otherwise you have to open the page, find the section in Contents and click on it); 2) allow links to sections look pretty in Skype/IRC conversations. Jack who built the house (talk) 12:49, 21 November 2016 (UTC)[reply]
@Jack who built the house: the question is, do we want to encourage such links, knowing that they have poor interoperability and will probably break in some browsers (and almost certainly will break autolinking in email clients etc)? --Tgr (WMF) (talk) 21:01, 21 November 2016 (UTC)[reply]
Maybe I am misunderstanding the proposal. Do wikilinks like [[Ссылка#Якорь]] actually fail to work? If that's the case, please file a bug about it; that should be fixed ASAP.
Also, we could probably output both .D0.A1 and %D0%A1 style anchors; those are both valid URIs and the second one is the standard way of representing Unicode characters in the fragment part of the URL. Maybe all we need is a campaign to convince browser vendors to properly support it. --Tgr (WMF) (talk) 21:15, 21 November 2016 (UTC)[reply]
@Tgr (WMF): No, you understood it right. It's just useful for the editors to work with wikilinks in such way: they can open the sections which are linked from the article they are working with without having to go to the page first or press "Preview" and search for that link. (There are also instruments in ruwiki for quickly getting section links to insert into an article, not in the form [[Ссылка#.D0.AF.D0.BA.D0.BE.D1.80.D1.8C]] which can be copied from the address bar, but in the correct form.) Jack who built the house (talk) 10:06, 23 November 2016 (UTC)[reply]
I can't see how this can be solved in the address bar? It is solved in links, but it does not seems to be the problem the user propose to solve? — Jeblad 13:34, 6 December 2016 (UTC)[reply]
Sure, the aimed result is the transition from .D0.AF to Я in links & in address bar. Half of the problem is the fact that Google Chrome right now shows Unicode characters in #anchors as %D0%AF, so this kind of transition would better be done simultaneously with fixing the issue in Chrome, otherwise it doesn't help. Jack who built the house (talk) 11:36, 7 December 2016 (UTC)[reply]

Voting – Non-Latin section headings and URL anchors

  1.   Support Skydrinker (talk) 13:48, 28 November 2016 (UTC)[reply]
  2.   Support --Vladis13 (talk) 14:11, 28 November 2016 (UTC)[reply]
  3.   Support --Deinocheirus (talk) 15:03, 28 November 2016 (UTC)[reply]
  4.   Support RasabJacek (talk) 15:19, 28 November 2016 (UTC)[reply]
  5.   Support. Cat of the Six (talk) 15:31, 28 November 2016 (UTC).[reply]
  6.   Support Sadads (talk) 15:39, 28 November 2016 (UTC)[reply]
  7.   Support Liasmi (talk) 16:02, 28 November 2016 (UTC)[reply]
  8.   Support --Micru (talk) 16:03, 28 November 2016 (UTC)[reply]
  9.   Support – Meiræ 16:19, 28 November 2016 (UTC)[reply]
  10.   Support --Inctructor (talk) 16:28, 28 November 2016 (UTC)[reply]
  11.   Support --Kosun (talk) 17:12, 28 November 2016 (UTC)[reply]
  12.   Support! This is very annoying and can be a huge turnoff for new and less experienced editors. --SSneg (talk) 17:14, 28 November 2016 (UTC)[reply]
  13.   Support! --~ Starship Trooper ~ 17:26, 28 November 2016 (UTC)[reply]
  14.   Support--Arbnos (talk) 17:38, 28 November 2016 (UTC)[reply]
  15.   Support --A.Savin (talk) 18:17, 28 November 2016 (UTC)[reply]
  16.   Support --VAP+VYK (talk) 18:51, 28 November 2016 (UTC)[reply]
  17.   Support.--Vladimir Solovjev (talk) 20:16, 28 November 2016 (UTC)[reply]
  18.   Support JAn Dudík (talk) 21:55, 28 November 2016 (UTC)[reply]
  19.   Support Permjak (talk) 22:00, 28 November 2016 (UTC)[reply]
  20.   Support — Ping08 (talk) 22:03, 28 November 2016 (UTC)[reply]
  21.   Support --Всезнайка (talk) 22:09, 28 November 2016 (UTC)[reply]
  22.   Support --VladXe (talk) 22:26, 28 November 2016 (UTC)[reply]
  23.   Support Niklem (talk) 22:32, 28 November 2016 (UTC)[reply]
  24.   Support Le Loy 23:14, 28 November 2016 (UTC)[reply]
  25.   Support --Iluvatar (talk) 23:18, 28 November 2016 (UTC)[reply]
  26.   Support Евгений Мирошниченко (talk) 03:11, 29 November 2016 (UTC)[reply]
  27.   Support Aracali (talk) 03:22, 29 November 2016 (UTC)[reply]
  28.   Support --Шнапс (talk) 04:13, 29 November 2016 (UTC)[reply]
  29.   Support. Gamliel Fishkin 04:14, 29 November 2016 (UTC)[reply]
  30.   Support--Alexmar983 (talk) 05:01, 29 November 2016 (UTC)[reply]
  31.   Support --Wanderer777 (talk) 07:41, 29 November 2016 (UTC)[reply]
  32.   Support Mihail Lavrov (talk) 07:48, 29 November 2016 (UTC)[reply]
  33.   Support. Schrike (talk) 08:02, 29 November 2016 (UTC)[reply]
  34.   Support Centaurus~ruwiki (talk) 10:16, 29 November 2016 (UTC)[reply]
  35.   Support StevenJ81 (talk) 17:57, 29 November 2016 (UTC)[reply]
  36.   Support. Most browsers already handle Unicode correctly. Saint Johann (ru) 19:06, 29 November 2016 (UTC)[reply]
  37.   Support. JukoFF (talk) 19:14, 29 November 2016 (UTC)[reply]
  38.   Support. --Хайзенберг (talk) 19:47, 29 November 2016 (UTC)[reply]
  39.   Support.Kolchak1923 (talk) 20:47, 29 November 2016 (UTC)[reply]
  40.   Support --Telaneo (User talk page) 21:48, 29 November 2016 (UTC)[reply]
  41.   Support. --User№101 (talk) 22:13, 29 November 2016 (UTC)[reply]
  42.   Support --GreenZmiy (talk) 04:45, 30 November 2016 (UTC)[reply]
  43.   Support P.Fisxo (talk) 04:54, 30 November 2016 (UTC)[reply]
  44.   Support Alexei Kopylov (talk) 08:49, 30 November 2016 (UTC)[reply]
  45.   Support. —Igel B TyMaHe (talk) 09:33, 30 November 2016 (UTC)[reply]
  46.   Support. Azgar (talk) 13:00, 30 November 2016 (UTC)[reply]
  47.   Support ‏ حمایت از خط فارسی-عربی. آن کدهای عجیب‌وغریب در آدرس‌بار مرورگر من غیرقابل خواندن هستند و من می‌خواهم آن‌ها را بخوانم. ‎ 4nn1l2 (talk) 13:11, 30 November 2016 (UTC)[reply]
  48.   Support-- ARASH PT  talk  14:20, 30 November 2016 (UTC)[reply]
  49.   Support --ShinePhantom (talk) 15:24, 30 November 2016 (UTC)[reply]
  50.   Support --Komap (talk) 15:38, 30 November 2016 (UTC)[reply]
  51.   Support. Demidenko 01:45, 1 December 2016 (UTC)[reply]
  52.   Support --Nouill (talk) 13:14, 1 December 2016 (UTC)[reply]
  53.   Support → «« Man77 »» [de] 22:08, 1 December 2016 (UTC)[reply]
  54.   Support --Gryllida 00:02, 2 December 2016 (UTC)[reply]
  55.   SupportMaxBioHazard (talk) 11:39, 2 December 2016 (UTC)[reply]
  56.   Support Sannita - not just another it.wiki sysop 14:28, 2 December 2016 (UTC)[reply]
  57.   Support MohammadtheEditor (talk) 17:23, 2 December 2016 (UTC)[reply]
  58.   Support NBS (talk) 17:55, 2 December 2016 (UTC)[reply]
  59.   Support --Framawiki (talk) 20:36, 2 December 2016 (UTC)[reply]
  60.   Support BethNaught (talk) 21:27, 2 December 2016 (UTC)[reply]
  61.   Support --Hercules63 (talk) 21:59, 2 December 2016 (UTC)[reply]
  62.   Support Dinamik (talk) 23:23, 2 December 2016 (UTC)[reply]
  63.   Support Iniquity (talk) 08:29, 3 December 2016 (UTC)[reply]
  64.   Support Tisfoon (talk) 17:59, 3 December 2016 (UTC)[reply]
  65.   Support --Slb nsk (talk) 18:49, 3 December 2016 (UTC)[reply]
  66.   Support - Best regards, Kertraon (talk) 12:03, 4 December 2016 (UTC)[reply]
  67.   Support the exploration of any possible improvements. Stevie is the man! Talk • Work 14:23, 4 December 2016 (UTC)[reply]
  68.   Support Facenapalm (talk) 16:49, 4 December 2016 (UTC)[reply]
  69.   Support Studmult (talk) 07:35, 5 December 2016 (UTC)[reply]
  70.   Support --Esetok (talk) 11:55, 5 December 2016 (UTC)[reply]
  71.   Support--Praveen:talk 13:11, 5 December 2016 (UTC)[reply]
  72.   Support Do notice that this also happens with latin diacritics (ã = %C3%A3), (â = %C3%82), (é = %C3%89) and so on. ArgonSim (talk) 20:11, 5 December 2016 (UTC)[reply]
  73.   Support --Papuass (talk) 21:04, 5 December 2016 (UTC)[reply]
  74.   Oppose because it would not help the many projects that do use Latin alphabets. I actually support doing this on behalf of smaller projects, but I don't want to see smaller projects send so many support voters that they crowd worthy proposals that benefit larger projects out of the top ten. --Tryptofish (talk) 23:20, 5 December 2016 (UTC)[reply]
  75.   Support—Same issue facing in ml.wikipedia. Adv.tksujith (talk) 01:47, 7 December 2016 (UTC)[reply]
  76.   Support—In addition to non-Latin projects and Latin diacritics, this has a huge impact on English Wikipedia, and probably every single project in the top ten. See this featured article section link : https://en.wikipedia.org/wiki/John_Douglas_(architect)#Early_works_.281860.E2.80.9370.29 . This is one of the most visible "ugly" still in English Wikipedia on MediaWiki (from a user perspective). It is going to be hard work to fix it. @Tryptofish: John Vandenberg (talk) 02:15, 7 December 2016 (UTC)[reply]
  77.   Support, long overdue - Mailer Diablo (talk) 07:01, 7 December 2016 (UTC)[reply]
  78.   Support —Ynhockey (talk) 10:13, 7 December 2016 (UTC)[reply]
  79.   Support Amir (talk) 18:34, 8 December 2016 (UTC)[reply]
  80.   Support - Akela (talk) 21:58, 8 December 2016 (UTC)[reply]
  81.   Support—10:10, 9 December 2016 (UTC)
  82.   Support - DPdH (talk) 12:44, 9 December 2016 (UTC)[reply]
  83.   Support Miniapolis 16:40, 9 December 2016 (UTC)[reply]
  84.   Support --Chrumps (talk) 03:27, 11 December 2016 (UTC)[reply]
  85.   Support --Plagiat (talk) 18:19, 11 December 2016 (UTC)[reply]
  86.   Support--David1010 (talk) 21:04, 11 December 2016 (UTC)[reply]
  87.   Support, and this concerns not just non-Latin headings (per John Vandenberg) — NickK (talk) 01:07, 12 December 2016 (UTC)[reply]
  88.   Support --Yann (talk) 23:30, 12 December 2016 (UTC)[reply]

Notify users of newly created articles added to categories or WikiProjects

  • Problem: Newly created articles or categories (a user creating a new category can't be expected to find all relevant wiki articles themselves) typically require the involvement of people knowledgeable on the topic to reach a good status, be neutral and contain all the necessary information. These users (for the respective article) could get invited via the article's categories and set WikiProject (banner on the talk page).
  • Who would benefit: Readers of new Wikipedia articles, users knowledgeable on particular topics who are interested in helping out with new articles, creators of new articles
  • Proposed solution: There are many possible ways that users might be able to "subscribe" to new articles (or categories) of particular categories or WikiProjects. I'd suggest adding an entry to the drop-down of the watchlist star of category pages that already I proposed here saying "Notify me for newly created articles" (or so) with 2 yes & no radio buttons (with the default which can be set in the settings being selected) and an actual membership system for WikiProjects (that I proposed here; until then a temporary solution could be simply assuming the users listed in the membership section of WikiProject pages to be their members or to use the WikiProject userbox categories). Then once new articles are added to any of the "subscribed" category or WikiProject one is member of one might get a typical notice in the upper right or have it listed on some specific page or have an entry on the watchlist.
  • More comments: This would improve collaboration, involvement and new article creation and -quality much.
  • Phabricator tickets:

Community discussion

@Ottawahitech: Which bot? Does it notify users of pages that were recently added to the WikiProject or new articles recently added to the WikiProject? If that bot does what I described above and is still functional I guess it should be made more popular or built into a/the new WikiProject system. --Fixuture (talk) 16:43, 20 November 2016 (UTC)[reply]
The bot on en produces a log of recently added pages to the WikiProject, with the format Wikipedia:Version 1.0 Editorial Team/{WikiProjectName} articles by quality log Stevie is the man! Talk • Work 20:15, 20 November 2016 (UTC)[reply]
@Stevietheman: I guess it's w:User:WP 1.0 bot then. Thanks for that! The bot seems useful and relevant here - however it's not what I suggested (it logs all pages getting tagged with a WikiProject's banner and not just the new ones). Also I couldn't find a way to get it doing its thing for WikiProject Science Fiction. And lastly imo every WikiProject should get such a log without having to configure anything - it should be built into the WikiProject system (this also means that it'S not hidden away on some obscure subpage nobody will ever find but embedded in the updated WikiProject page). --Fixuture (talk) 20:49, 28 November 2016 (UTC)[reply]
@Gradzeichen: What do you mean? Did you mean to comment on this suggestion here instead maybe? --Fixuture (talk) 19:29, 20 November 2016 (UTC)[reply]
Notification of an article being added to a category is already built into MediaWiki. Just watch the category, and de-select "Hide page categorization" in the Watchlist options. Then, you'll see pages being added to the category as they are added. Stevie is the man! Talk • Work 20:09, 20 November 2016 (UTC)[reply]
@Stevietheman: Thanks for the clarification and I know that. But my suggestion above is for newly created articles & categories and not just for newly categorized articles & categories. Alternatively it could also be stub articles & categories instead of just recently created ones. --Fixuture (talk) 20:34, 20 November 2016 (UTC)[reply]
OK. Well, on the English Wikipedia, you can color-code the stubs using en:User:Anomie/linkclassifier. Maybe that would work as a partial workaround? Stevie is the man! Talk • Work 20:40, 20 November 2016 (UTC)[reply]
  • Since we already have a way to "subscribe" to category additions (like via watchlist), I'm going to suggest a solution that won't have to involve the WMF: Ask the developer of en:User:Anomie/linkclassifier to support the color coding of new articles. It's important to define what 'new' means, of course. I can only assume you mean perhaps less than one week old. Stevie is the man! Talk • Work 14:37, 4 December 2016 (UTC)[reply]
    • @Stevietheman: Actually that's a good idea! However I'd first ask for some settings to control which of the link-types should be colored - I don't want my articles to look all rainbowish (I'd just like to have some few, specific types stand out). And for the timespan for new articles the best thing would be to have that configurable as well. But there's still one major problem with this improvised solution: you'd have to browse through all the additions and pick out the ones with the right color instead of just being notified about the new articles (also I couldn't use it this way anyways because of this). --Fixuture (talk) 22:04, 4 December 2016 (UTC)[reply]

Voting – Notification of newly created articles added to categories or WikiProjects

  1.   Support IKhitron (talk) 12:12, 29 November 2016 (UTC)[reply]
  2.   Support Beagel (talk) 18:19, 1 December 2016 (UTC)[reply]
  3.   Support Gryllida 00:02, 2 December 2016 (UTC)[reply]
  4.   Neutral per my latest comment. I think a solution outside the WMF team can be found. Stevie is the man! Talk • Work 14:37, 4 December 2016 (UTC)[reply]
  5.   Support —Ynhockey (talk) 10:25, 7 December 2016 (UTC)[reply]
  6.   Support--Elmidae (talk) 16:18, 7 December 2016 (UTC)[reply]
  7.   Support Miniapolis 16:42, 9 December 2016 (UTC)[reply]
  8.   Support local communities have not addressed this problem efficiently so far, IMHO.--Alexmar983 (talk) 05:51, 10 December 2016 (UTC)[reply]
  9.   Support Yes please! The fact that we can't watchlist anything but the (usually zero) wikitext content of a category is very frustrating and major productivity problem.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:31, 11 December 2016 (UTC) Would help in topically specific patrolling.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  08:16, 12 December 2016 (UTC)[reply]
    SMcCandlish, you can also watchlist additions/removals from categories today by unchecking "hide page categorization". This proposal is about somehow noting which of the additions are newly created articles. Stevie is the man! Talk • Work 22:40, 11 December 2016 (UTC)[reply]
    Noted; thanks. That feature got added without me noticing.  :-) I revised my support, above.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  08:16, 12 December 2016 (UTC)[reply]
  10.   Support--David1010 (talk) 21:05, 11 December 2016 (UTC)[reply]

Provide a dummy email address

  • Problem: As a victim of harassment, I may not want my email address disclosed every time I use Special:Emailuser.
  • Who would benefit: Everyone.
  • Proposed solution: Github has a setting "Keep my email address private" that sets all publicly facing email addresses (e.g. in commit metadata) to, say, MER-C users noreply github com. A preference should be added to MediaWiki that, when enabled, sets all emails sent via Special:Emailuser to have a sender of, say, MER-C no-reply wikimedia org. All emails sent to this address would be discarded silently.

Community discussion

  • hmm... I'm afraid this would encourage harassment, instead: currently you can sometimes find someone who insults you, threatens you or otherwise disturb you, even if the interface tells them that their email address will be visible and their address has been confirmed. If you tell them they would be hidden, I'd bet they would feel more comfortable in acting badly. Also, at a legal level, this would bring the Foundation to be responsible of this correspondence, and any time a user should need to act against harassers, or police legitimately requires quick help, WMF would be bureaucratically called each time to reveal the hidden address, resulting in a useless heavy complication: someone should study each case, evaluate it, decide, and take a further responsibility when not revealing the address. Wikis are public by definition, when you need to exchange private messages you are not on wiki any more: in this case you can well bear giving your email address, maybe a dedicated secondary one (as above proposed). Afaik, email addresses are not disclosed in our wikis (and should never be, anyway). --g (talk) 01:03, 11 November 2016 (UTC)[reply]

This would just allow harassers to spam you emails that you could not easily block as it would all just be email from wikimedia. This could only work if we also had the "Allow users to restrict who can send them email" blacklist option as well. KylieTastic (talk) 14:24, 13 November 2016 (UTC)[reply]

  • When the voting phase starts, I would support this if there is also a sure way on the Wikimedia side of things (as opposed to the email client side) to block certain users from sending you emails. As others have noted above, this could provide spammers with extra security as well, because their email addresses would be anonymous, too. As a suggestion, I know that, when an email is sent using Special:EmailUser, the fact that an email was sent (nothing else) is recorded in a log somewhere. We could somehow use that log to monitor emails incoming to one of these anonymous email addresses. What the log records (that an email was sent) would not change. — Gestrid (talk) 19:26, 14 November 2016 (UTC)[reply]

Agree with KylieTastic that this has the potential to embolden harassers and it should probably only be implemented if we also have some sort of blacklisting feature. Ryan Kaldari (WMF) (talk) 01:28, 22 November 2016 (UTC)[reply]

Voting – Provide a dummy email address

  1.   Support with the restrictions people gave in the discussion above. — Gestrid (talk) 00:54, 28 November 2016 (UTC)[reply]
  2.   Support BethNaught (talk) 08:16, 28 November 2016 (UTC)[reply]
  3.   Support This, that and the other (talk) 11:11, 28 November 2016 (UTC)[reply]
  4.   Support It seems to me that the desire is some sort of private messaging system and not necessarily email. Implementing a wikitext (or Flow) based private message system seems like a good idea and could still be viewable by administrators. --Izno (talk) 00:51, 29 November 2016 (UTC)[reply]
  5.   Oppose Wouldn't it work both ways and so enable anonymous harassing? Do not use email if you don't want your email address to be disclosed. Aracali (talk) 03:25, 29 November 2016 (UTC)[reply]
  6.   Support. Gamliel Fishkin 04:15, 29 November 2016 (UTC)[reply]
  7.   Oppose StevenJ81 (talk) 17:58, 29 November 2016 (UTC)[reply]
  8.   Support, if you want to send a private message (email), there is no reason why should a receiver get your email, as it's private information. --Stryn (talk) 20:53, 29 November 2016 (UTC)[reply]
  9.   Support -FASTILY 02:27, 1 December 2016 (UTC)[reply]
  10.   Support as proposer. MER-C (talk) 06:06, 1 December 2016 (UTC)[reply]
  11.   Support --Grabado (talk) 18:42, 1 December 2016 (UTC)[reply]
  12.   Support --Gryllida 00:03, 2 December 2016 (UTC)[reply]
  13.   Oppose This would simply open up people to being harassed anonymously. I could support it if they used a bounce email instead, something like mer-c@bounce.en.wikipedia.org which would bounce it to your actual email address. Jerodlycett (talk) 13:09, 2 December 2016 (UTC)[reply]
  14.   Support but only if the receiver can see the username of the sender. I oppose making this totally blind. Stevie is the man! Talk • Work 14:45, 4 December 2016 (UTC)[reply]
    This proposal talks nothing about hiding the username of the sender. This is only about revealing the email address. --Stryn (talk) 15:11, 4 December 2016 (UTC)[reply]
    Thanks. I just wanted it to be clear that the receiver should at least know the username so they can report abuse if necessary, and at least they have something they can match for blocking. Stevie is the man! Talk • Work 15:21, 4 December 2016 (UTC)[reply]
  15.   Oppose Too easily abused. --Rschen7754 04:51, 5 December 2016 (UTC)[reply]
  16.   Oppose Studmult (talk) 07:36, 5 December 2016 (UTC)[reply]
  17.   Support--Praveen:talk 13:17, 5 December 2016 (UTC)[reply]
  18.   Support But only as pointed out by Stevietheman. ArgonSim (talk) 22:36, 5 December 2016 (UTC)[reply]
  19.   Neutral I understand the idea but don't think enabling anon harassment is the answer. Pain in the ass, tho. --Hedwig in Washington (talk) 03:49, 6 December 2016 (UTC)[reply]
  20.   Support Muhraz (talk) 15:52, 6 December 2016 (UTC)[reply]
  21.   Oppose There are other solutions to this problem, such that I have a specific wiki email address. Using an anon service would open up WMF/ORTIS to increased workloads by becoming the proxy for abuse and complains. Currently abuse can be deferred off to the email provider, but once WMF gets in the middle of it, we now have to play middle man... Tiggerjay (talk) 20:53, 6 December 2016 (UTC)[reply]
  22.   Oppose Per Rschen -- Amanda (aka DQ) 21:04, 6 December 2016 (UTC)[reply]
  23.   Support Miniapolis 16:45, 9 December 2016 (UTC)[reply]
  24.   Oppose a tool for heavier harassment, I'm afraid - and a legal issue for WMF --g (talk) 10:32, 10 December 2016 (UTC)[reply]
  25.   Support --NaBUru38 (talk)
  26.   Oppose anonymous harassment --Alaspada (Talk) 03:31, 11 December 2016 (UTC)[reply]
  27.   Oppose Just register with an alternative or munged address.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:32, 11 December 2016 (UTC)[reply]
  28.   Support FoCuSandLeArN (talk) 23:05, 11 December 2016 (UTC)[reply]
  29.   Oppose, I can hardly think of any good-faith use that one cannot achieve with current email: you can actually get the same result but using a temporary email and not using it afterwards. On the other hand, sending an email and knowing that a person will not be able to answer it has a huge potential for bad-faith uses — NickK (talk) 01:13, 12 December 2016 (UTC)[reply]
  30.   Oppose Might help harassment instead. --Yann (talk) 23:31, 12 December 2016 (UTC)[reply]

Provide a tool to efficiently analyze the usage of a template

  • Problem: Users who amend templates need to be sure that their changes are concordant with the way the template has been in use so far or adapt those transclusions which are not compatible with the amended template. The tool (https://tools.wmflabs.org/templatetiger/) currently in use has three big flaws:
    • it only provides an outdated analysis of a dump which can date back to times more than half a year ago. This is not helpful for efficient template curation.
    • it cannot display more than 30 results at a time.
    • there is no interface, you have to know how to manipulate the URL in order to rearrange your query result.
  • Who would benefit: Primarily users who curate and amend templates, secondarily authors who use templates in their articles
  • Proposed solution: For the three flaws specified above:
    • Make sure at least once per month a new dump gets fed in the tool. As petscan provides live coverage in its scope of application, a live analysis of templates has, of course, to be mentioned as optimum.
    • Get rid of that limit. (Provide a link to a longer partial list and to a full list of results.)
    • Minimal version: Make the list of results sortable by clicking on the parameter in the headline of the table. Targeted version: Provide an interface similar to petscan which lets you filter and sort your list of results.

Community discussion

  • @Man77: Hi, I'm wondering if you've already talked to User:Kolossos about any or all of this, as he appears to be the primary developer of that tool (per). Any links would be appreciated. :) Quiddity (WMF) (talk) 23:25, 14 November 2016 (UTC)[reply]
    Actually, no. Honestly, I didn't realize that he is caretaker of that tool until last autumn, and according to my information he's been really busy for quite some time. → «« Man77 »» [de] 13:45, 15 November 2016 (UTC)[reply]
    Ah, ok, that makes sense. I'll ask here to keep things clearer: Hello @Kolossos: There are some suggestions here for improvements to your helpful tool. Is there anything other people can do to help (design suggestions, or technical assistance)? Do you foresee having any time in the future to work on some or all of these? I think suggestion #2 and #3 (minimal version) might be relatively clear and quick, and might help a significant percentage of the editors who use the tool. Thanks! Quiddity (WMF) (talk) 01:44, 16 November 2016 (UTC)[reply]
To #2 and #3: You can increase the limit of rows in the table if know how to edit the URL example(Parameter limit has an maximum of 3000). Yes I'm not an UI expert. The code is now old, messy PHP shit , so an rewrite in Python (with Pandas) seems usefull.
To #1: Updating is really a problem, especially for the huge english wikipedia. Support from WMF would be welcome, I have problems to use linux commands an WMFs linux cloud [2].
So, my main interests are now in other areas and I have limited time, but I would give support if somebody would like to work on the project. --Kolossos (talk) 19:20, 16 November 2016 (UTC)[reply]
  • I am genuinely puzzled by this request because I have no idea what the purpose of https://tools.wmflabs.org/templatetiger/ is (I've never seen it before) and what is meant by the concept of "template curation". And I'm a pretty technically-oriented editor. So I'm really puzzled that this many editors actually do understand what's needed here and are supporting it. Better explanation of what the problem is that this solves is needed. Wbm1058 (talk) 15:36, 4 December 2016 (UTC)[reply]
    • "Template curation" in other words: Fixing something which is broken with a template or where there is reasonable room for improvement. In order to do so you need to know how the given template has been used → «« Man77 »» [de] 15:47, 4 December 2016 (UTC)[reply]

Voting – Tool to efficiently analyze usage of a template

  1.   Support --Izno (talk) 00:52, 29 November 2016 (UTC
  2.   Support--Alexmar983 (talk) 05:02, 29 November 2016 (UTC)[reply]
  3.   Support → «« Man77 »» [de] 21:41, 30 November 2016 (UTC)[reply]
  4.   Support --Grabado (talk) 18:43, 1 December 2016 (UTC)[reply]
  5.   Support --Entbert (talk) 15:07, 2 December 2016 (UTC)[reply]
  6.   Neutral Improvements should be done eventually, but I think this is too low a priority for the WMF to consider. Stevie is the man! Talk • Work 15:18, 4 December 2016 (UTC)[reply]
  7.   Neutral per Stevietheman. --Liuxinyu970226 (talk) 10:25, 5 December 2016 (UTC)[reply]
  8.   Oppose I think that template writers can get by if they use "what links here" from the template page. --Tryptofish (talk) 23:24, 5 December 2016 (UTC)[reply]
    Every time I tried to use "what links here" for analyzing templates connectivity it wasn't great.--Alexmar983 (talk) 05:49, 10 December 2016 (UTC)[reply]
    "What links here" is not a tool to efficiently analyze template usage; in fact, it's not a tool to analyze template usage at all. If it comes to that, insource+hastemplate search helps more than this tool. Jack who built the house (talk) 09:31, 10 December 2016 (UTC)[reply]
  9.   Strong support. While I have big respect to Kolossos' instrument, it's just not enough. Jack who built the house (talk) 09:31, 10 December 2016 (UTC)[reply]
  10.   Support Would be very useful for template editors.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:34, 11 December 2016 (UTC)[reply]
  11.   Support Matěj Suchánek (talk) 20:52, 11 December 2016 (UTC)[reply]
  12.   Support seems like a powerful tool that could use more improvements and advertisement. Quiddity (talk) 08:58, 12 December 2016 (UTC)[reply]

Publish translated page in different location

  • Problem: When translation is performed with translate tool, the only possibility too see wiki code of page is to publish it.
But yet, more corrections is necessary with access to wiki-code
  • Who would benefit: everyone who uses translator tool
  • Proposed solution: Add checkbox to "create new translation" window which allows user to translate page to user's private area "User:Joshnsmith/Translations" for further wiki-code editing in usual "wikipedian" way
  • this will avoid publishing raw translations to mainspace and reduce unneeded page revisions history
  • this will avoid showing to others unready article
  • this is convenient to translate separate paragraphs of article without overwriting entire article
  • so far all listed is possible to do manually, but a little of automation would be good
  • Phabricator tickets:

Community discussion

There are also translation tools that allow to edit in wikicode. Like Minority Translate. Kruusamägi (talk) 16:46, 16 November 2016 (UTC)[reply]
Well, maybe it takes some hours to do more work on that. Our users use a trick that they translate page to their subpage (new one for each case) and later ask admin to delete it. It might influence translation stats, though. Could be useful and not that hard to implement. --Papuass (talk) 21:08, 5 December 2016 (UTC)[reply]

Voting – Publish translated page in different location

  1.   Oppose. I translate pages just by my head and hands. Such named "translation tool" limits the possibilities of translators and so has to be turned off completely. Partial solutions like this can not add usefulness to that strang "translation tool". Gamliel Fishkin 04:22, 29 November 2016 (UTC)[reply]
  2.   Support --Telaneo (User talk page) 21:51, 29 November 2016 (UTC)[reply]
  3.   Support --Papuass (talk) 21:08, 5 December 2016 (UTC)[reply]
  4.   Oppose It is possible to publish article to own's userspace just now. --KuboF (talk) 23:58, 12 December 2016 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2016/Categories/Miscellaneous&oldid=24950202"