Non-originators should be able to edit the main document directly, not just feedback forms.
This would enhance collaborative working. The creator of the document should be able to choose whether to allow non-creators to edit the main part of the document.
• A delegate locks a paragraph and does not unlock it (on purpose or because he forgets). How to unlock it?
=> 10 minute timer with 10mins timeout. And/Or unlocking by moderator (with rejection of unsaved changes). And/Or voting. And/Or writing an email.
• Another delegate wants to modify a paragraph, but cannot, because it is locked. What can he do?
=> Wait 10 minutes. An/Or ask moderator. And/Or vote. And/Or write and email. And/Or copy pasting the locked paragraph to continue work on it, in case any of the before is not possible (though malicious use of system should be rare).
• Does locking paragraphs allow for a fluid discussion-like workflow?
=> One (or more) paragraph per company. Just like in current RAN4 summaries.
• I did not understand your example of two companies adding an option 3. How can company B add the same option, when company A locked the paragraph?
=> Exactly. They cannot since the paragraph is locked.
Though, I was more referring to the same option number/reference. So, B will at least see that there is a bullet point being worked on and naturally chose a different option number; or at least write the text to be option number independent.
Wouldn’t option (3) have the same downsides as paragraph locking, though?
Users cannot see the latest version while the latest version is just being worked on and not the baseline version. So either there is a sign that something is being worked on. Or we have the same high collision probability, as we discussed before and what we observe day to day in the current RAN4 eMeetings.
Locking of paragraphs raises a couple of questions:
A delegate locks a paragraph and does not unlock it (on purpose or because he forgets). How to unlock it?
Another delegate wants to modify a paragraph, but cannot, because it is locked. What can he do?
Does locking paragraphs allow for a fluid discussion-like workflow?
I did not understand your example of two companies adding an option 3. How can company B add the same option, when company A locked the paragraph?
If you describe the use case as ‘company introduces new options and then directly refers to it in their comments’ then workflow 3), then I agree that the current workflow needs to be adapted. Workflow 3) as described by Ultan above, could work. The rebase can be implemented reliably, users can see the latest version before adding their own modification (this can avoid most conflicts), and potential conflicts can be resolved in various ways (simplest way is to append the new conflicting paragraph below the existing one).
Hello,
Thank you for the detailed feedback.
Yes, the NWM tool was conceived with a different goal in mind. The very procedure heavy CR process lends itself very well to automatization.
However to apply the tool to moderation of dialogs and discussions in eMeetings, some fundamental adaptations are required (in our opinion).
We don’t know what the technical basis for the tool is, but it seems like each paragraph could be locked/semaphored by a delegate clicking into it. Then real-time collaboration/discussion without conflict becomes straightforward.
Btw: We don’t think that Word/OneDrive does a good job of enabling robust and well-performing collaboration :-). They seem to accept too many compromises to hide the underlying “semaphoring”.
I am a bit worried about solution (2) described below. In the current email discussion summaries, we often introduce new options and then directly refer to them in our comments. Conflict resolutions could change references, e.g., two companies add option 3, and declare support for option 3, but conflict resolution makes one of them option 4. Also, I continue to fear that the overhead of handling complete revised versions from different companies, will overload moderators in certain “highly active” agenda items.
The debasing solution (3) might be too complex to reliably implement. The delegates can deal with some “discomfort” due to locking of paragraphs.
Finally, solution (1) is not in line with how efficient dialogs and efficient constructive technical discussions are currently carried out. It also increases moderator workload.
Ah, OK, I understand now. You're talking about concurrent editing of the same file, like in Google Docs or Word with OneDrive.
This is not the approach we took with this platform (in fact, we don't need to implement this because it already works very well in Google Docs or Word/OneDrive). This platform was intended for specification development in ETSI and 3GPP, where changes are proposed, discussed and only when agreed are they edited in.
There are 3 ways we can come close to this workflow in NWM:
1) the Feedback Form allows delegates to submit posts concurrently without moderator approval. But only posts can be submitted.
2) We will allow delegates to submit Variants, or proposals for change, which the moderator then has to accept/reject and integrate. It's not a huge workload for moderators, there will be conflict detection as part of it, so it should reduce to a few clicks per variant.
3) We could allow delegates to submit AND ACCEPT AND INTEGRATE their own variants. This is closest to the Google Docs or Word/OneDrive approach. This means that each delegate will make a variant, integrate it, and upgrade the document to a new version. For this we need some extra functionality, not yet developed: a Rebase function. This is to cater for a delegate who writes a variant, and before they submit it, another delegates upgrades the document to a new baseline version. The first delegate needs to rebase their variant to the new baseline before they can submit it.
We expect to develop the Rebase function if we get an extension to our budget.
Please consider changing the "alredy exists" evaluation of this feature request.
Allowing other contributors to create new revisions is not practically usable in the 3GPP meetings. Having [3] revisions by different companies and asking the moderator to check/merge/conflict resolve each of them, places too much stress and work on the moderator. Esecially in high conflict peak periods.
When creating a new revision by company C, it is very helpful to already see what company B has proposed in their revision. This can directly avoid most conflicts. The easiest way to achieve this, is to allow everyone to work in a single common revision with change marks at the same time.
This function (non-originators creating variants of the main document) already exists but has been deactivated for the first trial of Discussion Summary Documents to simplify the workflow. We will need to activate it soon, and train users on it.
Viewing changes (Diff function) is coming soon, before RAN Plenary trial.
Guest
Hi Sebastian,
A couple of answers:
• A delegate locks a paragraph and does not unlock it (on purpose or because he forgets). How to unlock it?
=> 10 minute timer with 10mins timeout. And/Or unlocking by moderator (with rejection of unsaved changes). And/Or voting. And/Or writing an email.
• Another delegate wants to modify a paragraph, but cannot, because it is locked. What can he do?
=> Wait 10 minutes. An/Or ask moderator. And/Or vote. And/Or write and email. And/Or copy pasting the locked paragraph to continue work on it, in case any of the before is not possible (though malicious use of system should be rare).
• Does locking paragraphs allow for a fluid discussion-like workflow?
=> One (or more) paragraph per company. Just like in current RAN4 summaries.
• I did not understand your example of two companies adding an option 3. How can company B add the same option, when company A locked the paragraph?
=> Exactly. They cannot since the paragraph is locked.
Though, I was more referring to the same option number/reference. So, B will at least see that there is a bullet point being worked on and naturally chose a different option number; or at least write the text to be option number independent.
Wouldn’t option (3) have the same downsides as paragraph locking, though?
Users cannot see the latest version while the latest version is just being worked on and not the baseline version. So either there is a sign that something is being worked on. Or we have the same high collision probability, as we discussed before and what we observe day to day in the current RAN4 eMeetings.
Attachments Open full size
Hi Axel,
Locking of paragraphs raises a couple of questions:
A delegate locks a paragraph and does not unlock it (on purpose or because he forgets). How to unlock it?
Another delegate wants to modify a paragraph, but cannot, because it is locked. What can he do?
Does locking paragraphs allow for a fluid discussion-like workflow?
I did not understand your example of two companies adding an option 3. How can company B add the same option, when company A locked the paragraph?
If you describe the use case as ‘company introduces new options and then directly refers to it in their comments’ then workflow 3), then I agree that the current workflow needs to be adapted. Workflow 3) as described by Ultan above, could work. The rebase can be implemented reliably, users can see the latest version before adding their own modification (this can avoid most conflicts), and potential conflicts can be resolved in various ways (simplest way is to append the new conflicting paragraph below the existing one).
Attachments Open full size
Hello,
Thank you for the detailed feedback.
Yes, the NWM tool was conceived with a different goal in mind. The very procedure heavy CR process lends itself very well to automatization.
However to apply the tool to moderation of dialogs and discussions in eMeetings, some fundamental adaptations are required (in our opinion).
We don’t know what the technical basis for the tool is, but it seems like each paragraph could be locked/semaphored by a delegate clicking into it. Then real-time collaboration/discussion without conflict becomes straightforward.
Btw: We don’t think that Word/OneDrive does a good job of enabling robust and well-performing collaboration :-). They seem to accept too many compromises to hide the underlying “semaphoring”.
I am a bit worried about solution (2) described below. In the current email discussion summaries, we often introduce new options and then directly refer to them in our comments. Conflict resolutions could change references, e.g., two companies add option 3, and declare support for option 3, but conflict resolution makes one of them option 4. Also, I continue to fear that the overhead of handling complete revised versions from different companies, will overload moderators in certain “highly active” agenda items.
The debasing solution (3) might be too complex to reliably implement. The delegates can deal with some “discomfort” due to locking of paragraphs.
Finally, solution (1) is not in line with how efficient dialogs and efficient constructive technical discussions are currently carried out. It also increases moderator workload.
Attachments Open full size
Ah, OK, I understand now. You're talking about concurrent editing of the same file, like in Google Docs or Word with OneDrive.
This is not the approach we took with this platform (in fact, we don't need to implement this because it already works very well in Google Docs or Word/OneDrive). This platform was intended for specification development in ETSI and 3GPP, where changes are proposed, discussed and only when agreed are they edited in.
There are 3 ways we can come close to this workflow in NWM:
1) the Feedback Form allows delegates to submit posts concurrently without moderator approval. But only posts can be submitted.
2) We will allow delegates to submit Variants, or proposals for change, which the moderator then has to accept/reject and integrate. It's not a huge workload for moderators, there will be conflict detection as part of it, so it should reduce to a few clicks per variant.
3) We could allow delegates to submit AND ACCEPT AND INTEGRATE their own variants. This is closest to the Google Docs or Word/OneDrive approach. This means that each delegate will make a variant, integrate it, and upgrade the document to a new version. For this we need some extra functionality, not yet developed: a Rebase function. This is to cater for a delegate who writes a variant, and before they submit it, another delegates upgrades the document to a new baseline version. The first delegate needs to rebase their variant to the new baseline before they can submit it.
We expect to develop the Rebase function if we get an extension to our budget.
Attachments Open full size
Please consider changing the "alredy exists" evaluation of this feature request.
Allowing other contributors to create new revisions is not practically usable in the 3GPP meetings. Having [3] revisions by different companies and asking the moderator to check/merge/conflict resolve each of them, places too much stress and work on the moderator. Esecially in high conflict peak periods.
When creating a new revision by company C, it is very helpful to already see what company B has proposed in their revision. This can directly avoid most conflicts. The easiest way to achieve this, is to allow everyone to work in a single common revision with change marks at the same time.
Attachments Open full size
This function (non-originators creating variants of the main document) already exists but has been deactivated for the first trial of Discussion Summary Documents to simplify the workflow. We will need to activate it soon, and train users on it.
Viewing changes (Diff function) is coming soon, before RAN Plenary trial.
Attachments Open full size
Change tracking would also be useful in this case.
Attachments Open full size