Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Miscellaneous

< Community Wishlist Survey 2016
(Redirected from 2016 Community Wishlist Survey/Categories/Miscellaneous)
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]