Internal Messaging Between Users (and how to gate it)

[mrfoxtalbot]

There are several scenarios were a (well vetted) internal messaging system would facilitate communication among contributors but I want to focus on security reports to illustrate why I think we should explore this.

Most plugin vulnerabilities are discovered by or reported to sec researchers who are not part of the plugin review team. Depending on the impact of the threat, researchers will first try to contact the plugin author to inform them about the threat before the issue is escalated to the plugins team for their attention. See #1690.

The problem is that researchers often struggle to find a valid method to contact plugin authors. Allowing some kind of internal messaging would make this process a lot easier.

Vetting Internal Messaging

The idea to implemente some type of internal messaging system has always been around and it goes back as #10 but concerns about spamming, harassing and such have always been raised (and rightly so).

There are several approaches we could explore to create this "safe" email list in order to minimize abuse:

• Anyone can completely opt-out of receiving emails from other users.
• Only profiles that have existed for X amount of time and have Y number of badges can contact other accounts.
• The notifications emails would include a link that would allow the recipient to report it as spam. After a set number of reports, that user would be blocked from sending more messages.

As a very raw MVP solution that would recycle existing infrastructure, we could leverage the email forwarding system we use to onboard users into Slack (in my case mrfoxtalbot@…). Currently those emails will only forward messages coming from specific emails but we could conceivably add "safe" email accounts to that list.

Props to @javiercasares for bringing up this idea during WC Torrelodones.

[JavierCasares]

For me, there are several options in a system like this. The primary thing is to facilitate communication between people in the WordPress Community, mainly those who have been part of it for a long time or who are very involved.

This system only applies to logged-in users, never to any Internet user.

— Whoever wants, can open their messages to everyone (in the purest Twitter DM style). This gives you the option to receive messages from anyone at any time.
— In the same way, you can completely close the system and prevent that, even if certain conditions are met, nobody sends you messages.
— By default, if you have a “Team badge” (so you are part of a team), you have the system open. This may apply to people working on some projects, but not part of a team.
— If you have badges of a team in which the badge is not given automatically, you have the system active (Core, Performance, Hosting, Marketing, TV…).
— In teams like Polyglots where the badge is given automatically, you must have a minimum of contributions, for example, have contributed with +100 strings.

There must be “manual” options to force this element. I imagine a situation like Automattic or Yoast including you in the Five for the Future, and you're just getting started, but you're going to be on the Marketing team, and you need to communicate with other people. You may be able to manually activate your system by Meta (or something like that).

Another option to open the system would be to “be a mentor”. Closely related to several projects that are currently underway and that should have the open system, since people who want to be mentored must be able to find those mentors.

In any case, the system should have something to report spam. If someone reports a user with 3 strikes, the system automatically closes with a clear message (in the style of Support flags) informing that the user has spammed.

Another option to implement is more similar to LinkedIn In-Mail, in which you have credits. This system would allow all users who have more than N months (a year?) to send a series of messages to others, but using credits. For example, 1 credit per week. This would give room for anyone to message anyone but only with a limited number of messages, to ensure that spam is not sent (even having the 3-strike system).

[dd32]

There are several scenarios were a (well vetted) internal messaging system would facilitate communication among contributors but I want to focus on security reports to illustrate why I think we should explore this.

While I get the underlying intention here, I don't think a generalised "message someone on WordPress.org" is the appropriate solution for that use-case, where a far more targeted "Report an issue in this plugin" form with appropriate information gathering and escalation would be more valuable.

This proposal obviously has far more uses than that though, which is explored further on, but all comes back to the notion of using email as the transport method, something that I'm not entirely a fan of. WordPress moved away from using email lists (​https://lists.wordpress.org/) quite some time ago for good reason, and reimplementing them in this manner doesn't seem like something that is worth our time.

Ultimately, I think the question needs to be asked of what problem are you trying to solve?, because the answer to that will greatly affect implementation.
If it's "Contact people who have pledged time to a team via 5ftf" then you can ask things like "Should they be auto-subscribed to get Make/$team posts?" or "Should the Make P2s have a feature to send out a notification to everyone who has pledged time?"

The WordPress plugin team already uses an implementation of this, both direct 1:1 through HelpScout and bulk emails to all committers (such as the "New version of WordPress is here, here's what you need to know" emails). Not all teams have a HelpScout inbox obviously, and the needs are very different to other teams.

If we're considering anti-spam and opt-out, then the solution is probably either a) too much or b) poorly thought out, as 1) we can't allow anything-spam to be sent from w.org in the first place and 2) we already have a LOT of moderation happening via the support forums and we don't need to add another location/layer to it.

tl;dr: What's the actual problem being solved here? What's right for one thing might not be for another, we already have communication platforms that should probably be used instead - what's actually preventing those being used?