Grants talk:IdeaLab/Allow users to restrict who can send them email

Functionality already exists

Couldn't this be achieved already by setting up an email filter? As a software engineer I would say, since it is already possible to do this, no resources should be devoted to it, and instead a page should be created to document how to achieve it with common email clients (such as GMail, Outlook, Apple Mail, etc.)--Greenrd (talk) 19:59, 18 June 2016 (UTC)

I don't understand what you're proposing. It sounds like you're talking about blocking specific addresses. That could be done on the email side, but a) it wouldn't help if the sending user changes their email address and b) it doesn't solve the problem of sockpuppets (or indeed casual passing-by nasty people) with throwaway email addresses abusing Special:EmailUser. I'm asking for users to be able to "email protect" themselves, so that in order the Special:EmailUser them, a harasser would have to go to the effort of attaining certain user rights, which would put many off. BethNaught (talk) 21:17, 18 June 2016 (UTC)

Interested in applying for a WMF Grant?

@BethNaught, Coma245745, and MER-C: Thanks for your work on this idea during the Inspire Campaign to allow contributors to exercise some control over who can e-mail them. Having read over the proposal, I wanted to ask if you were seeking funding through a Wikimedia Foundation grant: We have Rapid Grants for projects requiring up to USD 2,000 (applications are welcome anytime), and Project Grants for projects requiring more substantial funding (applications for the current round will be due Aug. 2nd). If you are interested, I wanted to offer my support in helping you develop your proposal. A few things you could do to get started include:

• This primarily seems like a technical project-- do you know any with the development skills needed to test and develop this functionality? If not, can I help find folks who might be interested and able?
• I note that phab:T138165 and phab:T138166 have been created (thanks MER-C!). Would you like me to direct potential developers to these pages?
• It would great to provide this across Wikimedia projects-- based on my read of things, in addition to the potential to fund a developer, a great deal of translation work will be needed, and funding some of that translation work may also be possible. Are there any other places where funding might be needed to make this happen?

As you work on your proposal, we also have sessions on Google Hangouts on Aug. 2nd. If you'd like to chat about your proposal at a different time, let me know and we'll try to arrange something individually. Thanks, I JethroBT (WMF) (talk) 20:25, 29 July 2016 (UTC)

Grants to improve your project

Greetings! The Project Grants program is currently accepting proposals for funding. The deadline for draft submissions is tommorrow. If you have ideas for software, offline outreach, research, online community organizing, or other projects that enhance the work of Wikimedia volunteers, start your proposal today! Please encourage others who have great ideas to apply as well. Support is available if you want help turning your idea into a grant request.

• Submit a grant request
• Learn from examples of completed Individual Engagement Grants or Project and Event Grants

The next open call for Project Grants will be in October 2016. You can also consider applying for a Rapid Grant, if your project does not require a large amount of funding, as applications can be submitted anytime. Feel free to ping me if you need help getting your proposal started. Thanks, I JethroBT (WMF) 22:49, 1 August 2016 (UTC)

Updates from the WMF's Anti-Harassment Tools team

Hello! I'm Trevor Bolliger, Product Manager on the WMF's Anti-Harassment Tools team. Some quick updates for those interested in this topic!

Individual user Notification muting

Just last week, our team released Notifications Mute, which allows a user to name specific other users from whom they do not want to receive on-wiki notifications. This doesn't prohibit the muted user from making any specific edits — they can still make any edit on wiki as they could before. All that is stopped is the delivery of on-wiki notifications and their email counterparts. For example, if User:Apples mutes User:Bananas on English Wikipedia:

• Bananas can still link to the username of User:Apples on a talk page and successfully save their changes, but Apples will not receive a notification that Bananas mentioned them. Bananas will still receive a 'successful mention' notification, if they've enabled that preference.
• Bananas can send 'Thanks' for an edit made by Apples, but Apples will not receive the notification.
• If Bananas reverts an edit made by Apples, Apples will not receive the notification.
• If Bananas writes a message on User_talk:Apples or participates on their Flow page, Apples will receive a notification. This is the only type of notification that Apples will receive.
• The Notifications Mute list does not affect Watchlist. If Bananas edits an article on Apples' watchlist, the edit will appear to Apples when viewing Special:Watchlist, and Apples will receive a watchlist email, if they've enabled that preference.

You can mute users on the 'Notifications' tab of Special:Preferences. We hope it's helpful in controlling your on-wiki communication.

Individual user direct email prohibiting

Our team is anticipating to release the Direct Email Prohibit before the end of September 2017. This feature will work in a similar way — users can list specific usernames that are not allowed to send them direct emails. For example, if User:Carrots prohibits User:Dates:

• Dates will not see the 'Email this user' link in the left navigation when viewing User:Carrots
• If Dates navigates directly to Special:EmailUser/Carrots they will see the standard error message of "This user has chosen not to receive email from other users" as if Carrots had the entire preference disabled.
• The Direct Email Prohibit list does not affect Watchlist or Notifications emails.

User group email prohibiting

Sockpuppets can be used to circumvent the Direct Email Prohibit list, so we also want to build the ability to set which user groups can send emails. Currently the user preference for allowing direct emails is a tickbox — on or off. I think it might work best as a dropdown with a few options underneath, like such:

File:Wireframe of a change to Special-Preferences to allow for setting which user groups can send direct emails.png

I believe this list should be customizable per-wiki, but a smart default would be: All users, autoconfirmed users, admins, nobody.

What do you think? Does this make sense? Will this work? — Trevor Bolliger, WMF Product Manager 🗨 23:35, 7 September 2017 (UTC)

Pinging BethNaught Coma245745 and MER-C to the above. I JethroBT (WMF) (talk) 17:40, 12 September 2017 (UTC)

I think it makes sense - indeed it's what I was suggesting.

One thing to keep in mind: when configuring the list of user groups, I think it ought to be hierarchical (i.e. every member of one group is a member of the previous). This is for usability, so the end user has a clear pattern of increasing protection strength. Your suggested default list (which I approve of) satisfies this: all autoconfirmed users are users, and no admin is realistically not going to be autoconfirmed. If however, for example, the extended confirmed group were added on the list for enwiki, the fact that not all admins are in the EC group might mean that setting one's email protection to EC might unintentionally exclude admins. BethNaught (talk) 20:13, 12 September 2017 (UTC)

I 100% agree. We are planning on building this so each wiki can customize 1) the groups for each list item 2) the label for each list item & 3) the default setting for accounts with newly confirmed email addresses. In your example of extendedconfirmed, the options would probably be all, autoconfirmed, extendedconfirmed and admins, only admins. — Trevor Bolliger, WMF Product Manager 🗨 20:35, 12 September 2017 (UTC)