When editing in realtime the auto-save can be triggered for any of the users that have made changes since the last save. This creates a new revision in the document history where the user for which the auto-save was triggered is marked as author. But this is not fair, because this revision can contain changes from multiple users (that were editing at the time the save was triggered). There are actually two problems that could be fixed:
know which users have contributed changes to a given document revision
know precisely who did what in a document revision that has contributions from multiple users
The first problem should be relatively easy to fix:
either use the version summary to list the contributors (quick fix)
or change the author field of a document revision to support multiple values
or add another contributors field to the document revision, in order to make a distinction between the user that created the revision and the users that have contributed changes in that revision
Long term option 3 seems the best to me.
The second problem is harder to fix. The only option I see (suggested also by @MichaelHamann) is to save in the document revision the actual chain of operational transformations (along with their author) that led to the current version. But I’m not convinced it’s useful to have so fine-grained tracking of who did what. Moreover, from my limited experience with y.js (an alternative to the ChainPad library we currently use for realtime synchronization), knowing who did what might not even be possible if we switch to a different synchronization library.
So I think we should start by listing the authors (contributors) of a document revision (that was auto-saved by realtime editing), either using the version summary (quick fix) or by adding a new field.
Note that the comment property might currently have a too limited size (1023 characters) to do this safely, so it’s not that quick of a fix, and you might want to do 3. directly.
+1 for proposal 3.. By the way, it might be interesting to let users indicate by hand some contributors when saving (when the content was collaboratively produced, just not in XWiki).
The version summary is supposed to be used by the user when editing (if needed) and thus isn’t supposed to be used by us internally. I’m offline atm and I don’t recall if we already allow a user to use it to save a version when editing in RT but I’m pretty sure we discussed that we should allow that.
when adding support for realtime editing to Cristal’s TipTap-based WYSIWYG editor (based on y.js) and my impression was that this is not supported by default. There is apparently an experimental feature that adds support for this, but it’s not clear to me what’s the state.
The auto-save triggered while editing in realtime doesn’t set any version summary currently. The text input to fill the version summary is visible, and the user can use it, but it’s highly impractical because:
by the time you finish typing the version summary an auto-save could be triggered that will use the partial summary you wrote so far…
an auto-save could be triggered before you start typing the version summary, so you end-up writing a version summary for an empty change (if that empty change is even saved at all on the server side)
For these reasons I think the version summary should be hidden by default when editing in realtime. Of course, we could allow the user to create some tagged / milestone revisions from time to time, where they can specify a version summary.
Anyway, we’re digressing a bit from the topic. I agree that option 3 (a separate field) is better than hijacking the version summary field.