Page MenuHomePhabricator

Investigation: Ping users from edit summary
Closed, ResolvedPublic5 Estimated Story Points

Description

An investigation task for wish #2, Ping users from the edit summary.
Existing related tickets: T32750 and T51446.

Notes on the approach we're taking on the project page:
https://meta.wikimedia.org/wiki/Community_Tech/Ping_users_from_the_edit_summary

We need to fill out the New Notification Data Form for the Collaboration team, as seen on T174388.

For the investigation: What's the basic technical approach? Any hidden dangers?

Implementation plan

This is very easy. Let's just do it. Add summary parsing to EchoDiscussionParser:: generateEventsForRevision(). The code parsing edit summaries into HTML lives in Linker::formatComment() and can be referenced for implementation details.

Caveats

Some discussions may have user page link in section autosummary (e.g. /* [[User:Foo]] is eating my babies! */). While MediaWiki tries to filter such links out of autosummaries, it can still be tricked. We should avoid pinging the users in question every time such sections are edited, so all links between /* and */ should be ignored.

New possibility of harrassment

Because all such pings will be public, the abusers will not have any plausible deniability. Users will have all the usual options of disabling the particular type of notifications or ignoring specific senders.

Questions

Should this create a new class of notifications in user preferences, or a generic "Mention" should be enough?

Event Timeline

DannyH triaged this task as Medium priority.Jan 3 2018, 2:19 AM
DannyH updated the task description. (Show Details)
kaldari set the point value for this task to 5.Jan 10 2018, 12:24 AM

Based on results of this investigation, I've made a technical WIP at https://gerrit.wikimedia.org/r/405371 - it covers detecting and processing pings in summaries, but it needs a notification specification to be complete.

Anything else left here?

@kaldari & @MaxSem can we talk about how this might be relevant to T123529 at all hands? -- in theory the same filtering strategy for identifying/logging these contacts cc' @Slaporte

@Astinson: From a technical point of view, I don't think there would be any overlap between an implementation for T123529 and this task. This task is just looking for a username in the edit summary, and if one exists, pinging the user. T123529 would involve handling a new query string parameter, making sure it is persistent across various actions, and auto-filling it in the edit summary when the user is on the edit page. T123529 is mostly "pre-edit" code, while this task is all "post-edit" code.

Based on results of this investigation, I've made a technical WIP at https://gerrit.wikimedia.org/r/405371 - it covers detecting and processing pings in summaries, but it needs a notification specification to be complete.

Anything else left here?

Yes, a couple more things to investigate:

  • Revert/rollback edit summaries automatically include a linked username, and there is already a Notification type for 'Edit revert.' — How should the notifications work when reverts and rollbacks occur? We would prefer to only send one notification, the existing 'Edit revert' notification.
  • Will this trigger the Mention success/fail notifications? If not, what additional work is required to trigger these success/fail notifications?
  • What existing throttling rules exist for Mention notifications? Do we need to add any new throttling logic?

I've also added a first draft list of requirements on T32750 — is there anything that is surprising or that would change the implementation?

Answers are on metawiki https://meta.wikimedia.org/wiki/Community_Tech/Ping_users_from_the_edit_summary#January_31,_2018 I don't really know why they aren't here..

Sorry, but I'm not sure I understand your question — I think the meta page is up-to-date with both this ticket and T32750. The three bullets I listed in my previous comment (which I minorly edited since your comment) are for @MaxSem to investigate from a technical perspective.

Another question for @MaxSem:

  • To support all wikis of all languages, we want to be able to identify the local language variant of [[User: (e.g. [[Benutzer:Apples]] in German or [[利用者:Apples]] in Japanese.) What is the best way to accomplish this?

Sorry, but I'm not sure I understand your question — I think the meta page is up-to-date with both this ticket and T32750. The three bullets I listed in my previous comment (which I minorly edited since your comment) are for @MaxSem to investigate from a technical perspective.

I'm sorry :( I must have misplaced that scattered information.

No worries! Sometimes it's difficult to keep multiple tickets and wiki pages in sync, especially when they're similar but not identical. :-)

Revised list of questions for @MaxSem as part of investigation:

  • What work will be required to trigger the the Mention success/fail notifications? Nothing? Small effort? Significant effort?
  • What existing throttling rules exist for Mention notifications?
  • To support all wikis of all languages, we want to be able to identify the local language variant of [[User: (e.g. [[Benutzer:Apples]] in German or [[利用者:Apples]] in Japanese.) What is the best way to accomplish this?

What work will be required to trigger the the Mention success/fail notifications? Nothing? Small effort? Significant effort?

Depends on exact product requirements to these, but most likely small.

What existing throttling rules exist for Mention notifications?

As far as I can see, Echo doesn't throttle mentions per time. There's however a limit of 500 mentions per edit per mention type, which is not a problem for summaries that can contain only so much user links.

To support all wikis of all languages, we want to be able to identify the local language variant of [[User: (e.g. [[Benutzer:Apples]] in German or [[利用者:Apples]] in Japanese.) What is the best way to accomplish this?

MW already takes care of this.

@TBolliger: Apparently the plan for the future is to limit edit summaries to a maximum of 1000 Unicode characters.

What existing throttling rules exist for Mention notifications?

As far as I can see, Echo doesn't throttle mentions per time. There's however a limit of 500 mentions per edit per mention type, which is not a problem for summaries that can contain only so much user links.

I think we should introduce our own throttling for this feature. There's a possibility that this could lead to spam/harassment, especially with the new 1000 character limit.

So 500 pings per diff is OK but 20 pings per summary is not?

So 500 pings per diff is OK but 20 pings per summary is not?

Diffs can be reverted. Edit summaries are more permanent.

Diffs can be reverted. Edit summaries are more permanent.

Both result in a ping once and once only.

Diffs can be reverted. Edit summaries are more permanent.

Both result in a ping once and once only.

I realize that. I do not think 500 pings per diff is OK but that's not something for us to fix. I don't think pinging 20ish people from an edit summary is a use case from my reading of the proposal and comments. If someone is pinging 20 people from an edit summary it seems pretty likely that it's a spammer. And 20 is low -- with 1000 characters, they could ping a lot more than 20.

In my opinion, 20 is too high. This is supposed to be a small heads-up, not a discussion starter. I would advocate for a limit of 1, 2, or 5.

In my opinion, 20 is too high. This is supposed to be a small heads-up, not a discussion starter. I would advocate for a limit of 1, 2, or 5.

I think 5 makes sense.

(in my volunteer capacity): I would think that anyone pinging more than 3, is using the wrong channel for communication -- 5 probably gives enough wiggle room for other collabroations, but is likely to solicit complaints from some of the more active communities (thinking English).

Niharika moved this task from Needs Review/Feedback to Q1 2018-19 on the Community-Tech-Sprint board.

Done. Thanks Max!