Page MenuHomePhabricator

Notify user when another user tries to edit an article that is being edited at the same time
Open, Needs TriagePublicFeature

Description

Imported from the 2023 Community Wishlist Survey proposal by @Elilopes

Feature summary (what you would like to be able to do and where):

When an editor is editing an article, the client should continuously communicate with the server that it is being edited. Then when another editor begins editing an article, the server can notify the user that it is being edited.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

Prevent edit conflicts

Benefits (why should this be implemented?):

Less edit conflicts

Event Timeline

The original proposal mentions a gadget and a Fandom script, but these do not warn you of an edit in progress; instead, they inform you that a new version of the page has been published while you were editing.

Is the request here to display a warning or notification when an article is being edited by 2+ editors who haven't successfully published their changes yet? Or is it intended to warn you of new revisions while you are editing?

When an article is being edited by 2+ editors. I think the latter is already a feature.

dmaza added a subscriber: JSengupta-WMF.

Just to confirm, the goal is to inform editors about other users actively editing the same page via a notification or an info box. What editors do with that information is beyond our control. The message will read something like "This article is currently being edited by multiple users" (TBD). Does that sounds correct?

My plan is to have a delayed timer after keyup events and set the article as being edited while checking if others are also editing. If someone leaves the editor and does not interact with it, they'll be removed from the page as actively editing and thus preventing the article from being stuck in that state.

Some key questions about this

  • How do we define "actively editing"? Is it just typing?
  • How long after a user has stopped typing would it be considered not "actively editing"?
  • Will this functionality be limited to registered users or should it also include unregistered accounts?

@JSengupta-WMF thoughts on the wording and format of the message?

This sounds great. Out of interest, how/where will the "is being edited" flag be stored?

This sounds great. Out of interest, how/where will the "is being edited" flag be stored?

Memcached through BagOStuff is what I have in mind

Some other thoughts:

  • "Editing" should be considered as pressing keys within 1 minute of each other. Why so long? Editors may be referencing sources between typing and pause.
  • Two possible ways we could prevent abuse (autokeys):
    • We should not count users as "editing" if they are considered "editing" for 10 mins+.
    • Show how many minutes other users editing the article have been editing (don't show their username, but show "User 1 has been editing this article for 23 minutes"). We would not show users who have been editing for 1 hour+.
  • We should only count registered users. Counting unregistered users seems like an abuse vector. They also typically only make small edits too.
  • Allow users to select that they would like to be notified via a browser notification when nobody is editing an article. That way this system is actually useful and users don't have to continue to monitor if an article is being edited or not.
  • "Editing" should be considered as pressing keys within 1 minute of each other. Why so long? Editors may be referencing sources between typing and pause.
    • We should not count users as "editing" if they are considered "editing" for 10 mins+.

Sure, we can start with that and tweak as necessary.

  • We should only count registered users. Counting unregistered users seems like an abuse vector. They also typically only make small edits too.

Sounds good to me.

  • Show how many minutes other users editing the article have been editing (don't show their username, but show "User 1 has been editing this article for 23 minutes"). We would not show users who have been editing for 1 hour+.
  • Allow users to select that they would like to be notified via a browser notification when nobody is editing an article. That way this system is actually useful and users don't have to continue to monitor if an article is being edited or not.

These two points, especially the last one, will expand the scope of this task. So, my suggestion is to split them into their own task. They are also not initially included in the proposal's scope, and the task being relatively small was one of the factors I considered when deciding what to work on.

Question, will doing what I'm describing here https://phabricator.wikimedia.org/T329975#9206710 satisfies the requirements of the wishlist proposal?

What editing environments are you looking at hooking it into? (I.e. is this just being put into WikiEditor, or is thought being given to having VisualEditor / MobileFrontend's editor also notifying?)

We should not count users as "editing" if they are considered "editing" for 10 mins+.

Removing longer edit sessions from this seems like it's guaranteed to strip out the kinds of major edits that are most likely to cause a painful edit collision...

It feels like all of the suggestions for removing abuse vectors are going to suffer from the same problem, really. The more we filter out, the higher the odds that we'll neuter the usefulness of the feature. Plus, someone who's trying to abuse it can presumably just call the notify-of-edit API directly, possibly with minor automated hoops jumped through to obtain a new edit-session token every 9.5 minutes.

What editing environments are you looking at hooking it into? (I.e. is this just being put into WikiEditor, or is thought being given to having VisualEditor / MobileFrontend's editor also notifying?)

VE and WikiEditor is what I had in mind.

We should not count users as "editing" if they are considered "editing" for 10 mins+.

Removing longer edit sessions from this seems like it's guaranteed to strip out the kinds of major edits that are most likely to cause a painful edit collision...

What's a good compromise in your opinion?

It feels like all of the suggestions for removing abuse vectors are going to suffer from the same problem, really. The more we filter out, the higher the odds that we'll neuter the usefulness of the feature. Plus, someone who's trying to abuse it can presumably just call the notify-of-edit API directly, possibly with minor automated hoops jumped through to obtain a new edit-session token every 9.5 minutes.

It would be very pointless to abuse this feature but you are right. Which asks the question, how many pages can a single user be actively editing?
As far as usefulness, maybe another piece of useful information is to surface how often the page gets a new revision?

What's a good compromise in your opinion?

I probably wouldn't bother with a limit if there's actual activity. Someone who's spent a few hours interacting with the editor, even irregularly, is plausibly making a wide-reaching edit. As a timeout for "oops, I left this tab open and forgot about it"... an hour or two maybe? I can see arguments for longer, but the "I wrote a major edit and then decided to sleep on it before I submitted" case is one that probably doesn't need too much accommodation.

Which asks the question, how many pages can a single user be actively editing?

At least two. Someone who's working on moving content between two related pages could be said to reasonably be actively editing both at the same time. Probably more, but I'd assume there's a sharp drop-off in how common that is...