Similar, but different: T19467: Edit conflict notification on Preview/Show Changes

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.

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

In T329975#9206813, @Samwilson wrote:

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.

In T329975#9216593, @DLynch wrote:

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...