Page MenuHomePhabricator

Consider how to best inform anonymous users that their edit has been actively deferred
Open, MediumPublic

Assigned To
None
Authored By
jmatazzoni
Jan 24 2017, 12:43 AM
Referenced Files
F5663011: post-defer.PNG
Feb 17 2017, 3:37 AM
F5663017: anon-notif.PNG
Feb 17 2017, 3:37 AM
F5493342: deferred-anon-notifs.png
Feb 6 2017, 4:49 PM
F5493337: deferred-article-note.png
Feb 6 2017, 4:49 PM
Tokens
"Like" token, awarded by MGChecker.

Description

Deferred changes is a technical way to mark for review and if necessary delay the visibility of suspicious edits by new or unregistered users until they have been manually reviewed by an editor. Registered users whose edits are "actively deferred," meaning they will not be published pending review, are informed of this via a notification. But anonymous users don't get notifications. Respect for anonymous users' efforts and participation requires that we inform them, at a minimum, of why their edit has not been published. This could be done, for example, via a dialog box or pop-up of some kind.

In this task, we will consider the best means of alerting anonymous users and the messaging that will be most helpful. Some questions that need to be answered:

  • Evaluating edits for deferral presumably causes some delay. How long will that typically be?
  • If the delay is too long for a pop-up message to be practical (because the user may have moved away from the page or closed the browser), what other means would work?
    • E.g., Deferred Changes applies to new and anonymous users only. Would it be possible to delay Save of these users only so that the Deferred Changes analysis can be part of the Save function for them?
  • Besides informing users that their edit was delayed, is there any other useful information we can direct them to. E.g., more about Deferred Changes process. Or how they can defend their edit? Or fix it?

Event Timeline

@jmatazzoni: I'm actually working on implementing anon notifications in echo, which I think is the only proper way of notifying anons of a deferred change. See T58828.

@jmatazzoni: I'm actually working on implementing anon notifications in echo, which I think is the only proper way of notifying anons of a deferred change. See T58828.

Hi Cenarium. Our messages crossed paths. As you can see on T58828, this task was created precisely so that we can consider whether Notifications are in fact the only or best way to deal with IP users impacted by Deferred Changes. The project of extending Notifications to IP users is more complex than might at first meet the eye. It's not something we want to wade into without considering alternatives.

Of course, your input on this is earnestly desired. Why do you say notifications are the only proper way?

Hi Cenarium. Our messages crossed paths. As you can see on T58828, this task was created precisely so that we can consider whether Notifications are in the only or best way to deal with IP users impacted by Deferred Changes. The project of extending Notifications to IP users is more complex than might at first meet the eye. It's not something we want to wade into without considering alternatives.

I see now :)
I don't see any alternative, we need an asynchronous system, we can't delay the save for performance reasons,. I don't mind delaying deferred changes implementation until we get anon notifications in place personally, which IMO is a must have for various reasons. I don't think we should build a system just for deferred changes when a general one exists.

@jmatazzoni wrote:

Evaluating edits for deferral presumably causes some delay. How long will that typically be?

Technically, isn't it potentially unlimited, since bots can decide "your edit is deferred" via API? But we may want to ignore bot-caused deferrals, in which case we can probably estimate this figure (but technically it could still vary unless edit filters are time-limited). It's at least the ORES delay, and also at least the edit filter delay (whichever is longer). However, the edit filter delay is already there.

If the delay is too long for a pop-up message to be practical (because the user may have moved away from the page or closed the browser), what other means would work?

Things to think about:

  • Ignoring the bot issue, can we delay send for this? If so, we can use the cookie technique setPostEditCookie does (maybe generalized). As stated below, we should be really careful with this since it can cause a user-perceived delay (but then again, edit filters already delay send).
  • If it's too slow to delay send, how should we do it:
    • Server-sent events (https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events) make sense, but I don't think we have that yet on the MW side.
    • Otherwise, we'd have to use polling. Due to page navigation, we might have to do it for all their recent edits, but that's actually not that big a deal. Add every page that was edited to a LIFO stack in localStorage, and check everything in the stack ("was it actively deferred?"). Not as a good as SSE but workable.

E.g., Deferred Changes applies to new and anonymous users only. Would it be possible to delay Save of these users only so that the Deferred Changes analysis can be part of the Save function for them?

I think this is just a social convention currently (though we could change that). Edit filters could be used to defer anyone, I think.

Also, new users are the quickest to leave over various barriers, so we really don't want them to perceive bad performance, and it adds up.

Besides informing users that their edit was delayed, is there any other useful information we can direct them to. E.g., more about Deferred Changes process. Or how they can defend their edit? Or fix it?

The null hypothesis case is to post to their talk page with T123522: Implement a server-side mw.MessagePoster equivalent. That also allows us to leave a decent message with links, etc. which they can reference later (rather than a nice, short message that flashes once never to be seen again).

E.g., Deferred Changes applies to new and anonymous users only. Would it be possible to delay Save of these users only so that the Deferred Changes analysis can be part of the Save function for them?

I think this is just a social convention currently (though we could change that). Edit filters could be used to defer anyone, I think.

It is not possible to defer edits authored by users who have the 'review' right (which there are few of: admins and designated reviewers), but AIUI that's the only limitation. Users with the 'autoreview' right (which there are many of: all non-new users) presumably would not have their edits deferred upon save, but how that works exactly isn't clear to me.

I don't exactly know how FlaggedRevs works in English Wikipedia, but in German Wikipedia it's well possible to explicitly defer an edit od an user with 'review' permission after his edit is done.

E.g., Deferred Changes applies to new and anonymous users only. Would it be possible to delay Save of these users only so that the Deferred Changes analysis can be part of the Save function for them?

I think this is just a social convention currently (though we could change that). Edit filters could be used to defer anyone, I think.

It is not possible to defer edits authored by users who have the 'review' right (which there are few of: admins and designated reviewers), but AIUI that's the only limitation. Users with the 'autoreview' right (which there are many of: all non-new users) presumably would not have their edits deferred upon save, but how that works exactly isn't clear to me.

Edits are immediately autoreviewed in the NewRevisionFromEditComplete handler, while abuse filter deferrals are run in a deferred update, so the deferral always occurs after the autoreview, thus these users would still be deferred.

I don't exactöy know how FlaggedRevs works in English Wikipedia, but in German Wikipedia it's well possible to explicitly defer an edit od an user with 'review' permission after his edit is done.

You probably refer to the action to "deprecate"/unreview a revision, which is possible but distinct from deferring.

Regarding the feasibility of anon notifications (T58828), I had made a rough patch that didn't alter the db and was mostly OK for the purpose of deferred changes, so it can be done without hassle. But we might as well provide full support for anon notifications while we're at it; the implementation is relatively straightforward, I've updated the patch (https://gerrit.wikimedia.org/r/#/c/329374). We just need to make sure that the changes in the db schema are OK.

There are several points in the process where knowing that your edit is pending review seems relevant. Ideally it would be great to be able to tell editors of issues on their edits as the users makes them, or as soon as they try to save.

Notifications can work well to inform of the deferral event right when it happens. This approach is consistent on how we inform about related events such as edits being reverted. For the case of anonymous users, we may want to inform that those notifications may be because of activity from a different user:

deferred-anon-notifs.png (768×1 px, 287 KB)

Another situation where it is relevant to know you have edits pending review is when you visit the page you edited again. If we tell the users nothing, editors may assume their edits are gone because they were removed by another user (as part of the review or not), adding those again can be confusing since the version they edit will have those changes visible. Providing a contextual notice as part of the page, telling that you have edits pending review for that page will help to add clarity:

deferred-article-note.png (768×1 px, 378 KB)

I included a "what can you do?" action since it makes sense to provide a clear entry point to move forward. In this case, the action can lead to a panel or page with further information and relevant actions. These are some of the aspects I think we may want to inform about:

  • What happened. Explain clearly what does it mean to get your edit deferred.
  • Which edit you made. Provide access to the edit you made could be useful to add context especially if the user made it some time ago.
  • Which are the next steps. Explain the options the user has: wait for the edit to be reviewed, discuss the deferral (with a direct link to the place to do so), etc.
  • Who made the decision. Especially in the case of automated systems it is good to blame the robots, and not other community members.
  • Avoid demotivation. Invite to keep editing despite heir edit becoming blocked. This is specially relevant for newcomers acting in good-faith (so maybe ORES can help decide whether to show such information to a given editor).
  • Help improve. Provide advice on how to make their edits better for the next time, for this not to happen again.

There are several points in the process where knowing that your edit is pending review seems relevant. Ideally it would be great to be able to tell editors of issues on their edits as the users makes them, or as soon as they try to save.

In case of abuse filter deferral, I've made so that the user is shown a notice after saving the page:

post-defer.PNG (786×1 px, 123 KB)

Of course we can customize the notice as needed. It's based on the notice shown when editing pages under pending changes, message key "revreview-edited".

Notifications can work well to inform of the deferral event right when it happens. This approach is consistent on how we inform about related events such as edits being reverted. For the case of anonymous users, we may want to inform that those notifications may be because of activity from a different user:

deferred-anon-notifs.png (768×1 px, 287 KB)

I've added a warning about that, see image below. I've put it at the bottom to avoid being too obtrusive to experienced IPs and in light yellow from the color palette to differentiate it from other notifications.

anon-notif.PNG (650×1 px, 129 KB)

Another situation where it is relevant to know you have edits pending review is when you visit the page you edited again. If we tell the users nothing, editors may assume their edits are gone because they were removed by another user (as part of the review or not), adding those again can be confusing since the version they edit will have those changes visible. Providing a contextual notice as part of the page, telling that you have edits pending review for that page will help to add clarity:

deferred-article-note.png (768×1 px, 378 KB)

In that case there will be a "view pending changes" tab so the user will know they still are pending. And ultimately either the edit gets reviewed, in which case the user is notified, or reverted, in which case the user is notified too.

I included a "what can you do?" action since it makes sense to provide a clear entry point to move forward. In this case, the action can lead to a panel or page with further information and relevant actions. These are some of the aspects I think we may want to inform about:

  • What happened. Explain clearly what does it mean to get your edit deferred.
  • Which edit you made. Provide access to the edit you made could be useful to add context especially if the user made it some time ago.
  • Which are the next steps. Explain the options the user has: wait for the edit to be reviewed, discuss the deferral (with a direct link to the place to do so), etc.
  • Who made the decision. Especially in the case of automated systems it is good to blame the robots, and not other community members.
  • Avoid demotivation. Invite to keep editing despite heir edit becoming blocked. This is specially relevant for newcomers acting in good-faith (so maybe ORES can help decide whether to show such information to a given editor).
  • Help improve. Provide advice on how to make their edits better for the next time, for this not to happen again.

This could probably be done directly in the defer notification or in the help page linked from there.

I really like this feature especially for wikis which have unreviewed changes by default, because it can help to avoid irritations and to get a better understanding about the things that happened.

SBisson changed the subtype of this task from "Task" to "Feature Request".Oct 16 2018, 1:06 PM
SBisson changed the subtype of this task from "Feature Request" to "Task".Oct 16 2018, 6:41 PM