Community Wishlist Survey 2016/Categories/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[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[reply]
@Ldorfman: Please see & & 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[reply]
You have : Wikiscan --Nouill (talk) 13:12, 1 December 2016 (UTC)Reply[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[reply]

Voting – Wikitrends statistics tool

  1.   Support. this just dump link error--Shizhao (talk) 02:52, 28 November 2016 (UTC)Reply[reply]
  2.   Support--Alexmar983 (talk) 17:19, 28 November 2016 (UTC)Reply[reply]
  3.   Oppose Alternatives exists. --Nouill (talk) 13:12, 1 December 2016 (UTC)Reply[reply]
  4.   Neutral per Fixuture. Stevie is the man! TalkWork 15:16, 4 December 2016 (UTC)Reply[reply]
  5.   Oppose --Hedwig in Washington (talk) 03:53, 6 December 2016 (UTC)Reply[reply]
  6.   Support שי אבידן (talk) 14:41, 11 December 2016 (UTC)Reply[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[reply]
  8.   Support.Ovedc (talk) 05:38, 12 December 2016 (UTC)Reply[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

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[reply]
      Neutral I fail to see the benefit. --Hedwig in Washington (talk) 03:54, 6 December 2016 (UTC)Reply[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[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[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[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[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[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[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ſkTalk) 09:12, 18 November 2016 (UTC)Reply[reply]

Voting – Thank IPs for their edits

  1.   Oppose IKhitron (talk) 12:13, 29 November 2016 (UTC)Reply[reply]
  2.   Support Jack who built the house (talk) 12:59, 29 November 2016 (UTC)Reply[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! TalkWork 14:05, 29 November 2016 (UTC)Reply[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[reply]
  5.   Support Alexei Kopylov (talk) 09:03, 30 November 2016 (UTC)Reply[reply]
  6.   Support, people need some kind of feedback. --Fixuture (talk) 20:40, 30 November 2016 (UTC)Reply[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[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[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[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[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[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[reply]
  9.   Support NMaia (talk) 02:40, 2 December 2016 (UTC)Reply[reply]
  10.   Oppose, too much complexity for too little gain. Max Semenik (talk) 03:23, 2 December 2016 (UTC)Reply[reply]
  11.   Oppose Jmvkrecords (Intra talk) 08:22, 2 December 2016 (UTC). People can be thanked for edits they didn't make.Reply[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[reply]
  13.   Oppose not worth it. --Rschen7754 04:50, 5 December 2016 (UTC)Reply[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[reply]
  15.   Oppose Too many IP addresses used by multiple persons. --Tryptofish (talk) 23:26, 5 December 2016 (UTC)Reply[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[reply]
  17.   Support Muhraz (talk) 15:53, 6 December 2016 (UTC)Reply[reply]
  18.   Oppose personally disagree with IP editing. DPdH (talk) 12:56, 9 December 2016 (UTC)Reply[reply]
  19.   Support Miniapolis 16:51, 9 December 2016 (UTC)Reply[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[reply]
  21.   Support Именно тех, кто знают википедию минимально, надо убеждать в том, что мы ценим их правок--TOMA646 (mail | talk) 14:10, 10 December 2016 (UTC)Reply[reply]
  22.   Oppose per Tryptofish.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:36, 11 December 2016 (UTC)Reply[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[reply]
  24.   Support FoCuSandLeArN (talk) 23:04, 11 December 2016 (UTC)Reply[reply]
  25.   SupportUanfala (talk) 00:57, 12 December 2016 (UTC)Reply[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[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[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[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! TalkWork 15:39, 4 December 2016 (UTC)Reply[reply]

Voting – Use notifications for mass messages

  1.   Support --Tarjeimo (talk) 21:53, 29 November 2016 (UTC)Reply[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[reply]
  3.   Support SamanthaNguyen (talk) 03:20, 8 December 2016 (UTC)Reply[reply]
  4.   Neutral per my comment above. Stevie is the man! TalkWork 03:23, 8 December 2016 (UTC)Reply[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[reply]
  6.   Support Miniapolis 16:53, 9 December 2016 (UTC)Reply[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[reply]
  2.   Support. No-brainer. Stevie is the man! TalkWork 01:59, 28 November 2016 (UTC)Reply[reply]
  3.   Support--Alexmar983 (talk) 05:28, 28 November 2016 (UTC)Reply[reply]
  4.   Support BethNaught (talk) 08:16, 28 November 2016 (UTC)Reply[reply]
  5.   Support--Wesalius (talk) 08:33, 28 November 2016 (UTC)Reply[reply]
  6.   Support Samwalton9 (talk) 09:25, 28 November 2016 (UTC)Reply[reply]
  7.   Support Jules78120 (talk) 12:39, 28 November 2016 (UTC)Reply[reply]
  8.   Support --Kudpung (talk) 14:47, 28 November 2016 (UTC)Reply[reply]
  9.   SupportMarcoAurelio 15:14, 28 November 2016 (UTC)Reply[reply]
  10.   Support Sadads (talk) 15:41, 28 November 2016 (UTC)Reply[reply]
  11.   SupportMeiræ 16:26, 28 November 2016 (UTC)Reply[reply]
  12.   Support Nocowardsoulismine (talk) 18:37, 28 November 2016 (UTC)Reply[reply]
  13.   Support Matěj Suchánek (talk) 21:58, 28 November 2016 (UTC)Reply[reply]
  14.   Support Johnuniq (talk) 22:16, 28 November 2016 (UTC)Reply[reply]
  15.   Support. Gamliel Fishkin 04:22, 29 November 2016 (UTC)Reply[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[reply]
  17.   Support – A great extension! Guycn2 · 18:58, 29 November 2016 (UTC)Reply[reply]
  18.   Support --Telaneo (User talk page) 21:51, 29 November 2016 (UTC)Reply[reply]
  19.   Support --Snaevar (talk) 01:09, 30 November 2016 (UTC)Reply[reply]
  20.   Support --Matthiaspaul (talk) 01:51, 30 November 2016 (UTC)Reply[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[reply]
  22.   Support --Fixuture (talk) 20:41, 30 November 2016 (UTC)Reply[reply]
  23.   Support: Kind of amazing it hasn't been done yet. O_o Julia\talk 23:04, 30 November 2016 (UTC)Reply[reply]
  24.   Support -FASTILY 02:27, 1 December 2016 (UTC)Reply[reply]
  25.   Support MER-C (talk) 05:28, 1 December 2016 (UTC)Reply[reply]
  26.   Support --β16 - (talk) 16:06, 1 December 2016 (UTC)Reply[reply]
  27.   Support Reasonable. --Vachovec1 (talk) 19:51, 1 December 2016 (UTC)Reply[reply]
  28.   Support Louis Wu (talk) 21:40, 1 December 2016 (UTC)Reply[reply]
  29.   Support«« Man77 »» [de] 22:11, 1 December 2016 (UTC)Reply[reply]
  30.   SupportKPFC💬 23:02, 1 December 2016 (UTC)Reply[reply]
  31.   Support czar 01:32, 2 December 2016 (UTC)Reply[reply]
  32.   Support Draceane (talk) 10:12, 2 December 2016 (UTC)Reply[reply]
  33.   SupportJc86035 (talk) 11:14, 2 December 2016 (UTC)Reply[reply]
  34.   SupportMaxBioHazard (talk) 11:46, 2 December 2016 (UTC)Reply[reply]
  35.   Support Sannita - not just another sysop 14:29, 2 December 2016 (UTC)Reply[reply]
  36.   Support --Framawiki (talk) 20:37, 2 December 2016 (UTC)Reply[reply]
  37.   Support -- SBaker43 (talk) 23:08, 2 December 2016 (UTC)Reply[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[reply]
  39.   Support --Continua Evoluzione (talk) 14:53, 3 December 2016 (UTC)Reply[reply]
  40.   Support --Yeza (talk) 13:07, 4 December 2016 (UTC)Reply[reply]
  41.   Support -- the wub "?!" 15:39, 4 December 2016 (UTC)Reply[reply]
  42.   Support --Rschen7754 04:50, 5 December 2016 (UTC)Reply[reply]
  43.   Support Studmult (talk) 07:37, 5 December 2016 (UTC)Reply[reply]
  44.   Support --Andropov (talk) 18:15, 5 December 2016 (UTC)Reply[reply]
  45.   Support ArgonSim (talk) 20:16, 5 December 2016 (UTC)Reply[reply]
  46.   Support --Tryptofish (talk) 23:27, 5 December 2016 (UTC)Reply[reply]
  47.   Support --Hedwig in Washington (talk) 04:00, 6 December 2016 (UTC)Reply[reply]
  48.   Support Muhraz (talk) 15:54, 6 December 2016 (UTC)Reply[reply]
  49.   Support It is time for more conversations on security in Wikimedia projects. Blue Rasberry (talk) 19:17, 6 December 2016 (UTC)Reply[reply]
  50.   Support Tiggerjay (talk) 20:55, 6 December 2016 (UTC)Reply[reply]
  51.   Support Ks0stm (TCG) 21:14, 6 December 2016 (UTC)Reply[reply]
  52.   Support. - Mailer Diablo (talk) 06:58, 7 December 2016 (UTC)Reply[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[reply]
  54.   Support TheCatalyst31 (talk) 02:05, 8 December 2016 (UTC)Reply[reply]
  55.   Support --𝔊 (Gradzeichen DiſkTalk) 04:20, 8 December 2016 (UTC)Reply[reply]
  56.   Support -Amir (talk) 18:34, 8 December 2016 (UTC)Reply[reply]
  57.   Support - Unclear what's the action to take if attempts are detected. DPdH (talk) 20:05, 8 December 2016 (UTC)Reply[reply]
  58.   Support - Akela (talk) 21:49, 8 December 2016 (UTC)Reply[reply]
  59.   Support Very useful. Espresso Addict (talk) 03:57, 9 December 2016 (UTC)Reply[reply]
  60.   Support Lt2818 (talk) 11:07, 9 December 2016 (UTC)Reply[reply]
  61.   Support Miniapolis 16:55, 9 December 2016 (UTC)Reply[reply]
  62.   Support --Stryn (talk) 18:16, 9 December 2016 (UTC)Reply[reply]
  63.   Support --Tarjeimo (talk) 23:07, 9 December 2016 (UTC)Reply[reply]
  64.   SupportTheDJ (talkcontribs) 23:33, 9 December 2016 (UTC)Reply[reply]
  65.   Support SamanthaNguyen (talk) 00:46, 10 December 2016 (UTC)Reply[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[reply]
  67.   Support --g (talk) 11:22, 10 December 2016 (UTC)Reply[reply]
  68.   Support --OrsolyaVirág (talk) 13:12, 10 December 2016 (UTC)Reply[reply]
  69.   Support - Bcharles (talk) 14:40, 10 December 2016 (UTC)Reply[reply]
  70.   Support – Definitely. Allen4names (talk) 20:40, 10 December 2016 (UTC)Reply[reply]
  71.   Support --Chrumps (talk) 03:34, 11 December 2016 (UTC)Reply[reply]
  72.   Support --Plagiat (talk) 18:24, 11 December 2016 (UTC)Reply[reply]
  73.   SupportNickK (talk) 09:53, 12 December 2016 (UTC)Reply[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! TalkWork 17:29, 13 November 2016 (UTC)Reply[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! TalkWork 02:06, 28 November 2016 (UTC)Reply[reply]
  2.   Support--Wesalius (talk) 08:33, 28 November 2016 (UTC)Reply[reply]
  3.   Support Ninovolador (talk) 11:36, 28 November 2016 (UTC)Reply[reply]
  4.   Support Jules78120 (talk) 12:41, 28 November 2016 (UTC)Reply[reply]
  5.   Support --Alexmar983 (talk) 17:18, 28 November 2016 (UTC)Reply[reply]
  6.   Support Nocowardsoulismine (talk) 18:39, 28 November 2016 (UTC)Reply[reply]
  7.   Support --Izno (talk) 00:54, 29 November 2016 (UTC)Reply[reply]
  8.   Support. Gamliel Fishkin 04:23, 29 November 2016 (UTC)Reply[reply]
  9.   Support --YMS (talk) 16:34, 29 November 2016 (UTC)Reply[reply]
  10.   Support --Telaneo (User talk page) 21:52, 29 November 2016 (UTC)Reply[reply]
  11.   Support --Matthiaspaul (talk) 01:53, 30 November 2016 (UTC)Reply[reply]
  12.   Support Alexei Kopylov (talk) 09:05, 30 November 2016 (UTC)Reply[reply]
  13.   Support -FASTILY 02:27, 1 December 2016 (UTC)Reply[reply]
  14.   Support MER-C (talk) 10:54, 1 December 2016 (UTC)Reply[reply]
  15.   Support --Gerwoman (talk) 18:44, 1 December 2016 (UTC)Reply[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[reply]
  17.   Support Draceane (talk) 10:12, 2 December 2016 (UTC)Reply[reply]
  18.   Support. LlamaAl (talk) 04:58, 3 December 2016 (UTC)Reply[reply]
  19.   Support --Continua Evoluzione (talk) 14:55, 3 December 2016 (UTC)Reply[reply]
  20.   Support --Andropov (talk) 18:16, 5 December 2016 (UTC)Reply[reply]
  21.   Support ArgonSim (talk) 22:31, 5 December 2016 (UTC)Reply[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[reply]
  22.   Support Muhraz (talk) 15:55, 6 December 2016 (UTC)Reply[reply]
  23.   SupportYnhockey (talk) 09:58, 7 December 2016 (UTC)Reply[reply]
  24.   Support --Elmidae (talk) 15:51, 7 December 2016 (UTC)Reply[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[reply]
  26.   Support --g (talk) 11:23, 10 December 2016 (UTC)Reply[reply]
  27.   SupportPing08 (talk) 02:24, 11 December 2016 (UTC)Reply[reply]
  28.   SupportNickK (talk) 09:54, 12 December 2016 (UTC)Reply[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[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[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[reply]
  Oppose Solution for a non-existing problem. --Hedwig in Washington (talk) 04:04, 6 December 2016 (UTC)Reply[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[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[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[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 (talkcontribs) 11:25, 11 November 2016 (UTC)Reply[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[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[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[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[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[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! TalkWork 17:59, 14 November 2016 (UTC)Reply[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[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[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[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ſkTalk) 11:04, 18 November 2016 (UTC)Reply[reply]

Voting – User profile images (avatars)

  1.   Support--Shizhao (talk) 02:46, 28 November 2016 (UTC)Reply[reply]
  2.   Support--Alexmar983 (talk) 05:23, 28 November 2016 (UTC)Reply[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[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! TalkWork 14:22, 28 November 2016 (UTC)Reply[reply]
  5.   Oppose for the reasons I mentioned above. --Kudpung (talk) 15:15, 28 November 2016 (UTC)Reply[reply]
  6.   Oppose If you want bling, use a bling website. Johnuniq (talk) 22:17, 28 November 2016 (UTC)Reply[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[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[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[reply]
  10.   Support SamanthaNguyen (talk) 04:37, 30 November 2016 (UTC)Reply[reply]
  11.   Oppose 4nn1l2 (talk) 13:26, 30 November 2016 (UTC)Reply[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[reply]
  13.   Oppose No. -FASTILY 02:27, 1 December 2016 (UTC)Reply[reply]
  14.   Oppose Absolutely not. MER-C (talk) 05:29, 1 December 2016 (UTC)Reply[reply]
  15.   Oppose, Wikipedia is not social network and social media. Beagel (talk) 18:22, 1 December 2016 (UTC)Reply[reply]
  16.   Oppose Not in the philosophy of this site. Semmendinger (talk) 19:50, 1 December 2016 (UTC)Reply[reply]
  17.   Oppose Ugh. Definitely not. --Vachovec1 (talk) 19:53, 1 December 2016 (UTC)Reply[reply]
  18.   Oppose«« Man77 »» [de] 22:13, 1 December 2016 (UTC)Reply[reply]
  19.   Oppose Jmvkrecords (Intra talk) 08:25, 2 December 2016 (UTC).Reply[reply]
  20.   Oppose Draceane (talk) 10:15, 2 December 2016 (UTC)Reply[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[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[reply]
  24.   Oppose no. Jianhui67 talkcontribs 10:04, 3 December 2016 (UTC)Reply[reply]
  25.   Oppose --Slb nsk (talk) 18:53, 3 December 2016 (UTC)Reply[reply]
  26.   Oppose --Ping08 (talk) 02:22, 4 December 2016 (UTC)Reply[reply]
  27.   Oppose This isn't Facebook. --Rschen7754 04:49, 5 December 2016 (UTC)Reply[reply]
  28.   Oppose Studmult (talk) 07:38, 5 December 2016 (UTC)Reply[reply]
  29.   Oppose --Andropov (talk) 18:18, 5 December 2016 (UTC) No need.Reply[reply]
  30.   Oppose Aren't user pages and custom signatures dedicated to that? ArgonSim (talk) 20:18, 5 December 2016 (UTC)Reply[reply]
  31.   Oppose as completely contrary to the purpose of the enterprise. --Tryptofish (talk) 23:29, 5 December 2016 (UTC)Reply[reply]
  32.   Strong oppose Commons is not Facebook or a chat platform. --Hedwig in Washington (talk) 04:06, 6 December 2016 (UTC)Reply[reply]
  33.   Oppose THis is a terrible idea. Muhraz (talk) 15:56, 6 December 2016 (UTC)Reply[reply]
  34.   OpposeRhododendrites talk \\ 05:43, 8 December 2016 (UTC)Reply[reply]
  35.   Support Why not. --Piotrus (talk) 13:18, 8 December 2016 (UTC)Reply[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[reply]
  37.   Oppose as said above --g (talk) 11:28, 10 December 2016 (UTC)Reply[reply]
  38.   Neutral Я сам часто хочу увидеть лицо других участников, и по этому эта идея мне нравится, далшая польза может быть от того, что администраторов, которые своё лицо уже публично показали, это принудит использовать своих прав ответственно, что на чешской википедим можно заметить - чем меньше на странице участника, тем морально худший участник, потому что скрывается за анонимность, большинство админов цсвики анонымних и никто, кто сам не придёт на викисраз (или встречу участников), не узнает, кто они на самом деле, и по этому, также думают, что не несут никакой ответственности. Но с другой стороны, участникам, которые станут жертвой преследования, будто администраторами, или кем то другим это принесёт только неприятности. Я бы просто сказал что это полезная идея для всех, но тем, кто воспользуются этой возможностью без розмысла, или им просто не повезёт, может принести серьёзный ущерб.--TOMA646 (mail | talk) 14:47, 10 December 2016 (UTC)Reply[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[reply]
  40.   Strong oppose WP is not "Face de bouc" --Alaspada (Talk) 20:40, 11 December 2016 (UTC)Reply[reply]
  41.   Oppose FoCuSandLeArN (talk) 23:04, 11 December 2016 (UTC)Reply[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[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.
  • 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[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[reply]

Voting – Allow a second email address

  1.   Support--Wesalius (talk) 08:34, 28 November 2016 (UTC)Reply[reply]
  2.   Support Samwalton9 (talk) 09:19, 28 November 2016 (UTC)Reply[reply]
  3.   Support SamanthaNguyen (talk) 04:40, 30 November 2016 (UTC)Reply[reply]
  4.   Support --MGChecker (talk) 15:13, 4 December 2016 (UTC)Reply[reply]
  5. Weak   Support Would be nice, but very low priority Imo -FASTILY 22:15, 4 December 2016 (UTC)Reply[reply]
  6.   Support --Alexmar983 (talk) 07:09, 5 December 2016 (UTC)Reply[reply]
  7.   Support --Hedwig in Washington (talk) 04:07, 6 December 2016 (UTC)Reply[reply]
  8.   Support Muhraz (talk) 15:56, 6 December 2016 (UTC)Reply[reply]
  9.   Support weakly. Good idea, but extreme low priority. Tiggerjay (talk) 20:56, 6 December 2016 (UTC)Reply[reply]
  10.   Support. - Mailer Diablo (talk) 06:59, 7 December 2016 (UTC)Reply[reply]
  11.   SupportRhododendrites talk \\ 05:44, 8 December 2016 (UTC)Reply[reply]
  12. Weak   Support per Fastily. Stevie is the man! TalkWork 14:02, 8 December 2016 (UTC)Reply[reply]
  13.   Support - DPdH (talk) 20:07, 8 December 2016 (UTC)Reply[reply]
  14.   Support Miniapolis 15:54, 9 December 2016 (UTC)Reply[reply]
  15.   Support --R. S. Shaw (talk) 17:57, 9 December 2016 (UTC)Reply[reply]
  16.   Support --Carnildo (talk) 01:53, 10 December 2016 (UTC)Reply[reply]
  17.   Support --g (talk) 10:12, 10 December 2016 (UTC)Reply[reply]
  18.   Support - Bcharles (talk) 15:18, 10 December 2016 (UTC)Reply[reply]
  19.   Support --NaBUru38 (talk)
  20.   Support --𝔊 (Gradzeichen DiſkTalk) 06:42, 11 December 2016 (UTC)Reply[reply]
  21.   Support Good. --  AnselmiJuan (discusión) 12:06, 11 December 2016 (UTC)Reply[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[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ſkTalk) 09:52, 7 November 2016 (UTC)Reply[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[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[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[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[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[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, with a brief explanation."] -- John Broughton (talk) 01:15, 8 November 2016 (UTC)Reply[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ſkTalk) 07:47, 8 November 2016 (UTC)Reply[reply]

I remember some discussion about this sort of centrally-mediated user emailing system in the discussions about (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[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[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[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[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[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ſkTalk) 12:53, 14 November 2016 (UTC)Reply[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[reply]

Voting – Allow users to restrict who can send them email

  1.   Support BethNaught (talk) 08:16, 28 November 2016 (UTC)Reply[reply]
  2.   Support. Samwalton9 (talk) 09:20, 28 November 2016 (UTC)Reply[reply]
  3.   SupportMarcoAurelio 15:13, 28 November 2016 (UTC)Reply[reply]
  4.   Support Sadads (talk) 15:34, 28 November 2016 (UTC)Reply[reply]
  5.   Support Ocaasi (talk) 18:35, 28 November 2016 (UTC)Reply[reply]
  6.   Oppose as argued at 07:47, 8 November 2016 (UTC). Gamliel Fishkin 03:57, 29 November 2016 (UTC)Reply[reply]
  7.   Support as proposer. MER-C (talk) 06:05, 1 December 2016 (UTC)Reply[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[reply]
  9.   Support NMaia (talk) 02:54, 2 December 2016 (UTC)Reply[reply]
  10.   Support Jmvkrecords (Intra talk) 08:27, 2 December 2016 (UTC).Reply[reply]
  11.   Support ie. autopatrolled, administrators ... --Framawiki (talk) 20:38, 2 December 2016 (UTC)Reply[reply]
  12.   Support Opabinia regalis (talk) 04:25, 4 December 2016 (UTC)Reply[reply]
  13.   Support --Yeza (talk) 13:10, 4 December 2016 (UTC)Reply[reply]
  14.   Support Stevie is the man! TalkWork 16:02, 4 December 2016 (UTC)Reply[reply]
  15.   Support Studmult (talk) 07:38, 5 December 2016 (UTC)Reply[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[reply]
  17.   Oppose Same as dummy email --Hedwig in Washington (talk) 04:09, 6 December 2016 (UTC)Reply[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[reply]
  19.   Support - DPdH (talk) 20:09, 8 December 2016 (UTC)Reply[reply]
  20.   Support Miniapolis 15:56, 9 December 2016 (UTC)Reply[reply]
  21.   Oppose --g (talk) 10:13, 10 December 2016 (UTC)Reply[reply]
  22.   Support - Bcharles (talk) 15:08, 10 December 2016 (UTC)Reply[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[reply]
  24.   Support Guettarda (talk) 16:45, 12 December 2016 (UTC)Reply[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[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.