Contrib.social

Discuss Conflict Resolution Strategy

Open on Drupal.org →
Created on 2 October 2024, 7 months ago

Problem/Motivation

I thought it would be good to have a public discussion of the conflict resolution strategy.

A key use case for my clients is the ability to continue allowing edits for content that is also being staged for a mass publication. A team of content managers are often working up a large content change that touches many pieces of content and their dependencies. This process takes a long time and needs layers of approval. The process often takes such a long time, that fine grained edits need to be published on the same content that is being re-crafted.

Workspaces, with the current restriction that content can be edited if it is assigned to a workspace, blocks me from using Workspaces. The demo at Drupalcon Barcelona, showed a work around where you could allow an edit of piece of content to get fast-tracked to publication, but that "fix" would be insufficient as the content team would have to undo all of their edits for a piece of content to reduce it down to the fine-grained change that needs to go out now.

In the end, content would diverge. To bring the content back to a single definition, we would need to handle any conflicts with the content. For my use case, the only conflict resolution strategy that is needed is the "force commit" strategy (to continue the GIT analogy). Last in wins.

That sounds like an easier strategy to implement that complex conflict resolution. Do you think we could do that today? Then handle the "git merge" strategy in the future?

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

🌱 Plan
Status

Active

Version

2.0

Component

Code

Created by

🇺🇸United States cosmicdreams Minneapolis/St. Paul

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @cosmicdreams
  • Comment 7 months ago →
    🇺🇸United States cosmicdreams Minneapolis/St. Paul

    In addition, please consider http://dgo.re/workspace_parallel to be included in your plans.

  • Comment 7 months ago →
    🇬🇧United Kingdom catch

    but that "fix" would be insufficient as the content team would have to undo all of their edits for a piece of content to reduce it down to the fine-grained change that needs to go out now.

    One way to do this that's doesn't require conflict resolution, would be to revert to the published revision when when moving the content to a new workspace for the quick edit, then after that revert back to the previous draft state in the original workspace - i.e. redoing the changes that have just been undone. That leaves the content editors responsible for manually integrating whatever changes was just published to live, but it doesn't destroy their work. I think this might be pretty close to the 'force push' you're talking about, not sure what a good UX for it would look like.

    At DrupalCon, hchonov mentioned https://www.drupal.org/project/conflict → 2.x branch handles auto-merge of conflicts where changes are in different fields, that seems like a great step towards not blocking changes and already exists.

  • Comment 7 months ago →
    🇺🇸United States cosmicdreams Minneapolis/St. Paul

    Thanks catch that does sound like it would work. I want to focus in on side thought you brought up:

    not sure what a good UX for it would look like.

    What I can see as good UX for this is to not provide a new UX. Simply remove the constraint for editing content that is also in a Workspace. Allow content to diverge. And then when it comes time for conflict resolution, default to "force push" logic. Which would mean the last revision saved is the new revision.

    Since that seems like the obvious choice, and was likely considered, I'm pretty sure there are problems with that approach I'm not thinking of. Otherwise, why not just do this?

  • Comment 7 months ago →
    🇬🇧United Kingdom catch

    @cosmicdreams I think this is what CPS module did (with a warning), but when it came to the core MR, we defaulted to 'not losing data' in the hope we could add proper conflict resolution later on.

    Are you already using http://dgo.re/workspaces_parallel ? Or to put it differently, why does that module not solve the problem?

  • Comment 7 months ago →
    🇺🇸United States cosmicdreams Minneapolis/St. Paul

    My next workspace adventure will focus on giving workspaces_parallel a try. My focus needed to shift to End-of-Month / Start-of-Month work. Which in part means supporting a content team as they use a solution that leverages cloning entities for a content push. After the push is over, I'll have a window of opportunity to demo a solution that uses workspaces / workspaces_parallel as an alternative to what we're currently doing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024