## Path to collaborative editing in Issues/MRs MVC: - Conflict-free, real-time editing among multiple users on an issue description. Viable: - Conflict-free, real-time editing among multiple users on a single document or resource (ex: Description, Comment, File). - [Scalable state synchronization mechanisms](https://gitlab.com/gitlab-org/gitlab/-/tree/master/doc/architecture/blueprints/graphql_api#design-scalable-state-synchronization-mechanisms) between backend and frontend via GraphQL Subscriptions. ### Assumptions For becoming viable, we will focus on collaborative text editing. Future enhancements will explore adding support for collaborative code editing. We will need to support P2P and database conflict resolution via a mechanism like CRDT. ### Experience goals - Presence indicators like GDocs for those actively editing - Cursor indicators representing who is making which changes in real-time. - Version history - Automatic conflict resolution (no “use ours/use theirs” prompts) ### Where we are now - Working on MVC for content editor, initial target is the Wiki - MVC doesn’t include full support for every GFM component - More info on the content editor - Architected to be modular, extensible, and re-usable across GitLab - Could be adapted to use anywhere Markdown content is written - Markdown is our first target, but could be adapted to work with other syntax languages - MVC focused on Wiki due to the more narrow use cases, lack of MR flow, and existing user base writing in Markdown - Next targets are: * Issue/Epic/MR description field * Single File Editor, when viewing a .md file * Web IDE, when viewing a .md file * Comment fields ### What happens next - Roll out content editor in Wiki - Complete support of the entire GFM syntax - Introduce content editor in issuables - Possibly re-implement markdown parsing client-side - Add backend support for conflict resolution and propagating changes from client to client as well as client to server and server to client. - Build UI for collaborative editing ### Technical Dependencies - We will likely want to avoid ProseMirror Collab as it is heavy handed and does not support strong conflict resolution. - We will need to wait for TipTap 2.0 to become generally available. This is currently blocked by a funding threshold set by the maintainers. - TipTap 2.0 is building in native support for YJS to handle the conflict resolution via CRDT. We likely cannot use YJS as it is a node service. We will need to implement CRDT (or similar) data structures within our product. - Automerge could be a great model to fast follow. Implementing a CRDT in GitLab is a non-trivial undertaking. There are currently no efforts underway across R&D to add support for this. Without a focused, dedicated engineering effort around this, conflict-free collaborative editing within GitLab is dead in the water. - Assuming we solve for CRDT and integrate our custom solution into TipTap / Editor, the next constraint will likely be scaling our websocket infrastructure. We’re currently exploring what it would look like to scale our current websockets implementation to support Merge Requests. We will have more information regarding this constraint after that work is completed ### ETAs - Content Editor MVC in Wiki: 14.0 - Complete GFM support in content editor: 14.2-14.3 - Content editor in issue/MR description: 14.5? - There is currently no ETA for the necessary backend support to enable real-time, collaborative editing. ### Considerations - Currently have 1-2 FE engineers dedicated to content editor while we continue working on Settings & Navigation work. - There’s a lot of work that can be parallelized though, so the ETAs could be accelerated by adjusting priorities. - We will need a very experienced engineer to lead the effort to implement a CRDT in GitLab. ### Links/Issues - https://gitlab.com/gitlab-org/gitlab/-/issues/21473