As long as two people can edit the same content, there is the chance for edit conflicts. I don't think there is a way for us to solve that in Flow without also having solved it in MediaWiki proper.

Recommend closing until they are solved in MediaWiki.

MediaWiki proper does address edit conflicts: if two users edit the same version of a page, the first one saving changes goes through and the second one gets a warning saying that there was an edit conflict, this is your version, it hasn't been saved. Please go back and try again.

How does Flow respond when the same happens with a message?

I don't think this is an urgent topic. We can test when the functional prototype is ready, actually not that far from now. Then we can see whether this report still makes sense or we can close it with the appropriate resolution.

It responds exactly the same way. This is a MediaWiki problem, not a Flow problem.

(In reply to comment #0)

If users with special permissions (e.g. admins) can edit Flow posts then
there is a potential for edit conflicts between these special users and other
regular or special users.

I hope anyone (i.e., not just privileged users) will be able to edit Flow posts, otherwise it opens up an enormous attack vector.

I'm not working in the Flow project, but according to the current specifications (not final, subject to change based on user needs etc) at https://www.mediawiki.org/wiki/Flow_Portal/MVP only you and certain users with special permissions can edit your own posts. If you have feedback about this a good place to comment is at the Flow Portal/MVP discussion page.

fwiw looking at

https://www.mediawiki.org/wiki/Flow_Portal/Functional_Specifications/Moderation,_Protection,_and_Refactoring#Refactoring

one can see that there are more situations where the actions of two different users might enter in conflict e.g. merging or splitting topics when someone else is editing them. I wonder whether Flow will need specific dialogs to address these?

But as said, we can simply wait for the prototype and start testing on actual code, not just specs.

The above is all correct, none of this is set in stone within Flow currently.

There is the concept of "most recent revision" of something. Just like mediawiki core if you attempt to edit the content on a revision that is not the most recent you will get an edit conflict. The original idea to reduce edit conflicts was to handle "unwanted data" via moderation instead of content editing. IF the user that created the comment is the only one that is allowed to edit the content then edit conflicts should be fairly rare. This is not some global decision enforced by Flow, who can edit a post is a configurable role that wiki's are free to do with as they please.

For just moderation we can(but don't yet) do a bit of "conflict resolution" when there has been a mid-air collision. For a random idea, we could accept the most restrictive of the moderation states and use some messaging to let a user know what happened. Obviously this has not been fully considered, but with some planning seems doable.

Topic splits/merge's are another interesting point. This is another thing that we could detect and do some conflict resolution on. Re-parenting a tree currently only requires re-parenting one post. If it's worthwhile to try and write conflict resolution strategy's for the various scenarios is still to be decided.

In summary, conflicts exist. We have options for how to reduce the number of conflicts that affect average end users. The small group of sysop(or >) will be much more likely to get edit conflicts, and it's probably not worth our time(in the Minumum Viable Product) to reduce those conflicts, but there are options. There are also non-technical ways to reduce edit conflicts through user interface. They are all trade offs that are yet to be decided.

Prioritization and scheduling of this bug is tracked on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/272

This is a currently-tracked thing to work on; as such it's more of a story than a bug :). Closing as invalid as a result.

(In reply to comment #8)

This is a currently-tracked thing to work on; as such it's more of a story
than a bug :). Closing as invalid as a result.

Story, bug, issue, ticket, feature request... it doesn't really matter what it's called, but it's not invalid. :-)

Perhaps this bug report should be converted into a tracking ticket, though.

I guess "duplicate" would be a better description. So, we have two priorities when it comes to surfacing software changes/issues/features/whatever:

*Transparency to the community working on it. BZ doesn't directly provide for that - that's more a mw.org/enwiki kind of thing.
*Transparency to the developers working on it. BZ has traditionally provided for this and served as a repository for not only "bugs" or individual "enhancements" but complex behavioural and interaction changes, such as this'n. The issue is we're switching to using Mingle for projects under active development, and so we've done work to integrate BZ and Mingle for bugs and put big, thorny issues such as how we handle edit conflicts in Mingle so they can be tracked within the team and dealt with with design/product/engineering/community input.

So, having this in bugzilla feels somewhat wrong for our workflows (we're not using BZ for tracking complex problems, since the sort of long-form conversations you need to have don't make sense here), somewhat duplicative (bugzilla entries are copied over into mingle for bug-tracking, so we now have two tickets, effectively, covering this problem) and not really aiding in transparency (BZ is opaque to the community and the devs working on this problem are participating in the conversations about it elsewhere).

What I'd suggest in this case is closing as..something - Duplicate, maybe? Or just marking it as lowest-priority and closing it as fixed when we've got edit conflict behaviour worked out - and pushing design (who are currently working on EC behaviour, as I understand it) to be transparent about what they're doing and thinking via mw.org, the design and flow FAQs on enwiki and mw.org, and invite participation from end users there. Does that make any sense?

Since I opened this unusual report bypassing the Flow team workflow (with the best of my intentions, but still)...

You could link to the corresponding Mingle URL where the work on this issue is documented and then resolve here as INVALID/DUPLICATE.

It is true that it is not a bug report per se and it is neither an enhancement request. It was meant to be a reminder to the dev team about a potential problem.

That makes sense; https://mingle.corp.wikimedia.org/projects/flow/cards/318 seems to be the pertinent story. We'll update it as we work on the problem and requirements become clearer :).