On 23 May 2019, at 09:25, Simon Urli <simon.urli(a)xwiki.com> wrote: Hi Caty, On 22/05/2019 14:51, Ecaterina Moraru (Valica) wrote: Let say that a document has 2 sections, and a user is editing section 1, while the other is editing section 2. The merge should work properly without any conflict. I don't really see the point of asking by default the second user if he's ok to merge his work on section 1 with what has been saved on section 2. On the contrary I feel it could be scary for the basic users to see this kind of message and it decreases the easiness of using XWiki IMO. It's automatic but as you mentioned just after, in case of changes are made on the same line there is a conflict that needs to be solved. That's what I meant by "ask in case of merge conflict". On the contrary option 1 was a fully automatic merge, with a predefined strategy to choose one version over another in case of conflict. As I said above I personally don't see the point of always displaying the merge diff especially for basic users when there's no conflict. Now I really think that some users would want that, that's why I proposed the profile option.

Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

On 23 May 2019, at 09:43, Simon Urli <simon.urli(a)xwiki.com> wrote: On 23/05/2019 09:31, Vincent Massol wrote: So in case of "Save&Continue" it's quite easy to change the "Saved" notification message by another one. I'm not quite sure how to inform the user about the merge if he cliks on "Save&View”.

> Ideally I’d like that we poll regularly to see if there have been changes and display some icon if there are with the ability for the current user to click and see the diffs with his version, and if there’s a conflict, that a visible message is displayed on the screen (but without interrupting of his typing).

I like the idea, now would that be enough to inform about the performed merge? If we go in that direction I'd need some design proposal for the UI @Caty :)

By implementing the part below :) ie by providing this info continuously before he clicks any save button. More details: when there’s a conflict, clicking the message/button would show the diff and the conflict. Yes we need to find where to put that information. BTW, even better, we should ideally also display the icons of the users who are editing the same doc and/or who have saved content after the current user started editing. And we already have a design page for this ;) We called it “collaborative editing”: https://design.xwiki.org/xwiki/bin/view/Improvements/CollaborativeEditing Thanks -Vincent

On 23 May 2019, at 11:37, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: On Thu, May 23, 2019 at 11:10 AM Simon Urli <simon.urli(a)xwiki.com> wrote: Not sure what you mean by "all-or-nothing" (I guess you just mean that you can't choose a line over another)

but to be safe I prefer to repeat that among the possible choices the user can make in the windows there should be the proposed automatic merge.

-- Thomas Mortagne

On Thu, May 23, 2019 at 12:10 PM Simon Urli <simon.urli(a)xwiki.com> wrote: I don't agree about the all-or-nothing, since I would prefer to accept what we can, warn on conflicts. We should show a resolution conflict when the conflict is on the same line. Auto-merge the rest.

I don't like the option in the profile. IMO we should decide on the behavior and apply it for all users. Edit is a core feature, conflicts again are part of this kind of interaction.

On "Save&View" we can increase the timeout for the notification. The notification could mention also the magnitude: "Saved. Auto-merged 10 conflicts." If cannot save, show the conflict modal.

This mockup might not help, but is something I had in mind that I want to share: https://design.xwiki.org/xwiki/bin/download/Proposal/EditConflict/linescolo… Ideally I would like to see real time, if not the exact changes, but at least the lines affected by the current editor. Thanks, Caty > > 5. The conflict resolution is line-by-line based. > > WDYT? > Simon > > On 23/05/2019 10:00, Vincent Massol wrote: >> >> >>> On 23 May 2019, at 09:43, Simon Urli <simon.urli(a)xwiki.com> wrote: >>> >>> >>> >>> On 23/05/2019 09:31, Vincent Massol wrote: >>>>> On 23 May 2019, at 09:25, Simon Urli <simon.urli(a)xwiki.com> wrote: >>>>> >>>>> Hi Caty, >>>>> >>>>> On 22/05/2019 14:51, Ecaterina Moraru (Valica) wrote: >>>>>> I'm not sure I agree about this profile option. >>>>>> Indeed we want to make things as simple as possible and having > conflict >>>>>> resolutions can be scary, still, there is no way an user could take > this >>>>>> decision in advance. >>>>>> Users will want to have control over what they do and at least know >>>>>> something went wrong. We cannot automatically merge, without any > warning, >>>>>> since users will immediately see that their work was changed. It > will be >>>>>> reported as a bug (in case they notice it) and they will expect to > be able >>>>>> to recover the work. >>>>>> I can't think of a case when an user would not care about the > changes and >>>>>> the result. >>>>> >>>>> Let say that a document has 2 sections, and a user is editing section > 1, while the other is editing section 2. The merge should work properly > without any conflict. >>>>> I don't really see the point of asking by default the second user if > he's ok to merge his work on section 1 with what has been saved on section > 2. >>>>> On the contrary I feel it could be scary for the basic users to see > this kind of message and it decreases the easiness of using XWiki IMO. >>>>> >>>>>> Also the options are not clear to me: like 2: automatically merge, > but ask. >>>>>> Well is automatically or not? >>>>> >>>>> It's automatic but as you mentioned just after, in case of changes > are made on the same line there is a conflict that needs to be solved. > That's what I meant by "ask in case of merge conflict". >>>>> >>>>> On the contrary option 1 was a fully automatic merge, with a > predefined strategy to choose one version over another in case of conflict. >>>>> >>>>>> We need to ask for resolution only if the changes are on the same > line, >>>>>> besides this, we should try to automatically merge, but provide the > info to >>>>>> the user that we did that. Instead of the normal Save message, we > could say >>>>>> that we performed a Merged Save. And in the history I would expect > to be >>>>>> able to see what lines were added by what users, just in case > something >>>>>> went wrong. We are lucky that we have the Blame view :) >>>>>> So not sure we need a configurable option in profile. We just need to >>>>>> decide on the 'default' and implement that. We keep adding options > that >>>>>> only increase the complexity of the product and we never get to test > all >>>>>> the possible mixes and configurations. >>>>>> So what are the use cases when we would need this option in the > profile? >>>>> >>>>> As I said above I personally don't see the point of always displaying > the merge diff especially for basic users when there's no conflict. Now I > really think that some users would want that, that's why I proposed the > profile option. >>>> I agree that option 3 is not great as it gets in the way. Now it could > be interesting for the user to know it happened. Maybe some fleeting > notifications at the bottom of the screen or some info added to the commit > message or some visual info when you’re in edit mode and before you press > save. >>> >>> So in case of "Save&Continue" it's quite easy to change the "Saved" > notification message by another one. I'm not quite sure how to inform the > user about the merge if he cliks on "Save&View”. >> >> By implementing the part below :) ie by providing this info continuously > before he clicks any save button. >> >>> >>>> Ideally I’d like that we poll regularly to see if there have been > changes and display some icon if there are with the ability for the current > user to click and see the diffs with his version, and if there’s a > conflict, that a visible message is displayed on the screen (but without > interrupting of his typing). >> >> More details: when there’s a conflict, clicking the message/button would > show the diff and the conflict. >> >>>> And when he saves, the merge is done then. >>> >>> I like the idea, now would that be enough to inform about the performed > merge? If we go in that direction I'd need some design proposal for the UI > @Caty :) >> >> Yes we need to find where to put that information. >> >> BTW, even better, we should ideally also display the icons of the users > who are editing the same doc and/or who have saved content after the > current user started editing. >> >> And we already have a design page for this ;) We called it > “collaborative editing”: >> > https://design.xwiki.org/xwiki/bin/view/Improvements/CollaborativeEditing >> >> Thanks >> -Vincent >> >>> >>> Simon >>> >>>> WDYT? >>>> Thanks >>>> -Vincent >>>>> >>>>> Simon >>>>>> Thanks, >>>>>> Caty >>>>>> On Wed, May 22, 2019 at 12:04 PM Vincent Massol <vincent(a)massol.net> > wrote: >>>>>>> Hi Simon, >>>>>>> >>>>>>>> On 22 May 2019, at 10:45, Simon Urli <simon.urli(a)xwiki.com> wrote: >>>>>>>> >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> I'm working on the merge on save for the roadmap of 11.5 and I > need some >>>>>>> decision to be taken. >>>>>>>> >>>>>>>> The main idea of the merge on save, is to try to merge users work > in >>>>>>> case of save conflict. Knowing that the merge might led to merge > conflict >>>>>>> in case of edits on the same places. Those merge conflict can be > tackled >>>>>>> automatically, but a priority will be then given to one version over >>>>>>> another. >>>>>>>> >>>>>>>> I first propose to add an option in user profile, so users would > have >>>>>>> the possibility to choose between: >>>>>>>> 1. Always merge automatically the work, even in case of merge > conflict >>>>>>> >>>>>>> I don’t understand this part. If there’s a conflict it means it > cannot be >>>>>>> merged… So would it do? Take latest version and overwrite previous > version? >>>>>>> >>>>>>>> 2. Always merge automatically, but ask what to do in case of > merge >>>>>>> conflict >>>>>>>> 3. Always ask what to do in case of save conflict >>>>>>>> >>>>>>>> Now the question is: what should be the default option? >>>>>>> >>>>>>> Certainly not 1! 2 is really the best to me. >>>>>>> >>>>>>> Thanks >>>>>>> -Vincent >>>>>>> >>>>>>>> Option 1 looks like a good fit for decreasing the number of clicks > to >>>>>>> do, but I'm a bit afraid that in case of conflict they would have > the same >>>>>>> feeling as before the warning conflict window: i.e. to loose some > part of >>>>>>> their work. >>>>>>>> >>>>>>>> WDYT? >>>>>>>> >>>>>>>> Simon >>>>>>>> >>>>>>>> -- >>>>>>>> Simon Urli >>>>>>>> Software Engineer at XWiki SAS >>>>>>>> simon.urli(a)xwiki.com >>>>>>>> More about us at http://www.xwiki.com >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Simon Urli >>>>> Software Engineer at XWiki SAS >>>>> simon.urli(a)xwiki.com >>>>> More about us at http://www.xwiki.com >>> >>> -- >>> Simon Urli >>> Software Engineer at XWiki SAS >>> simon.urli(a)xwiki.com >>> More about us at http://www.xwiki.com >> > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.urli(a)xwiki.com > More about us at http://www.xwiki.com >

I don’t understand why we’d need this at all since if we agree with the poll it’s not needed.

Thanks -Vincent > > Simon >>> >>> Those are the first three priority points. The following points are >>> important too, but might not be finished in 11.5. >>> >>> 4. If another user saved a document that I'm editing, I have a >>> notification in the editor and I can click on it to see the diff/conflicts >>> >> This mockup might not help, but is something I had in mind that I want to >> share: >> https://design.xwiki.org/xwiki/bin/download/Proposal/EditConflict/linescolo… >> Ideally I would like to see real time, if not the exact changes, but at >> least the lines affected by the current editor. >> Thanks, >> Caty >>> >>> 5. The conflict resolution is line-by-line based. >>> >>> WDYT? >>> Simon >>> >>> On 23/05/2019 10:00, Vincent Massol wrote: >>>> >>>> >>>>> On 23 May 2019, at 09:43, Simon Urli <simon.urli(a)xwiki.com> wrote: >>>>> >>>>> >>>>> >>>>> On 23/05/2019 09:31, Vincent Massol wrote: >>>>>>> On 23 May 2019, at 09:25, Simon Urli <simon.urli(a)xwiki.com> wrote: >>>>>>> >>>>>>> Hi Caty, >>>>>>> >>>>>>> On 22/05/2019 14:51, Ecaterina Moraru (Valica) wrote: >>>>>>>> I'm not sure I agree about this profile option. >>>>>>>> Indeed we want to make things as simple as possible and having >>> conflict >>>>>>>> resolutions can be scary, still, there is no way an user could take >>> this >>>>>>>> decision in advance. >>>>>>>> Users will want to have control over what they do and at least know >>>>>>>> something went wrong. We cannot automatically merge, without any >>> warning, >>>>>>>> since users will immediately see that their work was changed. It >>> will be >>>>>>>> reported as a bug (in case they notice it) and they will expect to >>> be able >>>>>>>> to recover the work. >>>>>>>> I can't think of a case when an user would not care about the >>> changes and >>>>>>>> the result. >>>>>>> >>>>>>> Let say that a document has 2 sections, and a user is editing section >>> 1, while the other is editing section 2. The merge should work properly >>> without any conflict. >>>>>>> I don't really see the point of asking by default the second user if >>> he's ok to merge his work on section 1 with what has been saved on section >>> 2. >>>>>>> On the contrary I feel it could be scary for the basic users to see >>> this kind of message and it decreases the easiness of using XWiki IMO. >>>>>>> >>>>>>>> Also the options are not clear to me: like 2: automatically merge, >>> but ask. >>>>>>>> Well is automatically or not? >>>>>>> >>>>>>> It's automatic but as you mentioned just after, in case of changes >>> are made on the same line there is a conflict that needs to be solved. >>> That's what I meant by "ask in case of merge conflict". >>>>>>> >>>>>>> On the contrary option 1 was a fully automatic merge, with a >>> predefined strategy to choose one version over another in case of conflict. >>>>>>> >>>>>>>> We need to ask for resolution only if the changes are on the same >>> line, >>>>>>>> besides this, we should try to automatically merge, but provide the >>> info to >>>>>>>> the user that we did that. Instead of the normal Save message, we >>> could say >>>>>>>> that we performed a Merged Save. And in the history I would expect >>> to be >>>>>>>> able to see what lines were added by what users, just in case >>> something >>>>>>>> went wrong. We are lucky that we have the Blame view :) >>>>>>>> So not sure we need a configurable option in profile. We just need to >>>>>>>> decide on the 'default' and implement that. We keep adding options >>> that >>>>>>>> only increase the complexity of the product and we never get to test >>> all >>>>>>>> the possible mixes and configurations. >>>>>>>> So what are the use cases when we would need this option in the >>> profile? >>>>>>> >>>>>>> As I said above I personally don't see the point of always displaying >>> the merge diff especially for basic users when there's no conflict. Now I >>> really think that some users would want that, that's why I proposed the >>> profile option. >>>>>> I agree that option 3 is not great as it gets in the way. Now it could >>> be interesting for the user to know it happened. Maybe some fleeting >>> notifications at the bottom of the screen or some info added to the commit >>> message or some visual info when you’re in edit mode and before you press >>> save. >>>>> >>>>> So in case of "Save&Continue" it's quite easy to change the "Saved" >>> notification message by another one. I'm not quite sure how to inform the >>> user about the merge if he cliks on "Save&View”. >>>> >>>> By implementing the part below :) ie by providing this info continuously >>> before he clicks any save button. >>>> >>>>> >>>>>> Ideally I’d like that we poll regularly to see if there have been >>> changes and display some icon if there are with the ability for the current >>> user to click and see the diffs with his version, and if there’s a >>> conflict, that a visible message is displayed on the screen (but without >>> interrupting of his typing). >>>> >>>> More details: when there’s a conflict, clicking the message/button would >>> show the diff and the conflict. >>>> >>>>>> And when he saves, the merge is done then. >>>>> >>>>> I like the idea, now would that be enough to inform about the performed >>> merge? If we go in that direction I'd need some design proposal for the UI >>> @Caty :) >>>> >>>> Yes we need to find where to put that information. >>>> >>>> BTW, even better, we should ideally also display the icons of the users >>> who are editing the same doc and/or who have saved content after the >>> current user started editing. >>>> >>>> And we already have a design page for this ;) We called it >>> “collaborative editing”: >>>> >>> https://design.xwiki.org/xwiki/bin/view/Improvements/CollaborativeEditing >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> >>>>> Simon >>>>> >>>>>> WDYT? >>>>>> Thanks >>>>>> -Vincent >>>>>>> >>>>>>> Simon >>>>>>>> Thanks, >>>>>>>> Caty >>>>>>>> On Wed, May 22, 2019 at 12:04 PM Vincent Massol <vincent(a)massol.net> >>> wrote: >>>>>>>>> Hi Simon, >>>>>>>>> >>>>>>>>>> On 22 May 2019, at 10:45, Simon Urli <simon.urli(a)xwiki.com> wrote: >>>>>>>>>> >>>>>>>>>> Hi everyone, >>>>>>>>>> >>>>>>>>>> I'm working on the merge on save for the roadmap of 11.5 and I >>> need some >>>>>>>>> decision to be taken. >>>>>>>>>> >>>>>>>>>> The main idea of the merge on save, is to try to merge users work >>> in >>>>>>>>> case of save conflict. Knowing that the merge might led to merge >>> conflict >>>>>>>>> in case of edits on the same places. Those merge conflict can be >>> tackled >>>>>>>>> automatically, but a priority will be then given to one version over >>>>>>>>> another. >>>>>>>>>> >>>>>>>>>> I first propose to add an option in user profile, so users would >>> have >>>>>>>>> the possibility to choose between: >>>>>>>>>> 1. Always merge automatically the work, even in case of merge >>> conflict >>>>>>>>> >>>>>>>>> I don’t understand this part. If there’s a conflict it means it >>> cannot be >>>>>>>>> merged… So would it do? Take latest version and overwrite previous >>> version? >>>>>>>>> >>>>>>>>>> 2. Always merge automatically, but ask what to do in case of >>> merge >>>>>>>>> conflict >>>>>>>>>> 3. Always ask what to do in case of save conflict >>>>>>>>>> >>>>>>>>>> Now the question is: what should be the default option? >>>>>>>>> >>>>>>>>> Certainly not 1! 2 is really the best to me. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Vincent >>>>>>>>> >>>>>>>>>> Option 1 looks like a good fit for decreasing the number of clicks >>> to >>>>>>>>> do, but I'm a bit afraid that in case of conflict they would have >>> the same >>>>>>>>> feeling as before the warning conflict window: i.e. to loose some >>> part of >>>>>>>>> their work. >>>>>>>>>> >>>>>>>>>> WDYT? >>>>>>>>>> >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Simon Urli >>>>>>>>>> Software Engineer at XWiki SAS >>>>>>>>>> simon.urli(a)xwiki.com >>>>>>>>>> More about us at http://www.xwiki.com >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Simon Urli >>>>>>> Software Engineer at XWiki SAS >>>>>>> simon.urli(a)xwiki.com >>>>>>> More about us at http://www.xwiki.com >>>>> >>>>> -- >>>>> Simon Urli >>>>> Software Engineer at XWiki SAS >>>>> simon.urli(a)xwiki.com >>>>> More about us at http://www.xwiki.com >>>> >>> >>> -- >>> Simon Urli >>> Software Engineer at XWiki SAS >>> simon.urli(a)xwiki.com >>> More about us at http://www.xwiki.com >>> > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.urli(a)xwiki.com > More about us at http://www.xwiki.com

ok makes sense. I’m asking because your plan didn’t mention the different steps and what you propose to do when and you dropped this polling idea from your list of items :)

Thanks -Vincent >> Thanks >> -Vincent >>> >>> Simon >>>>> >>>>> Those are the first three priority points. The following points are >>>>> important too, but might not be finished in 11.5. >>>>> >>>>> 4. If another user saved a document that I'm editing, I have a >>>>> notification in the editor and I can click on it to see the diff/conflicts >>>>> >>>> This mockup might not help, but is something I had in mind that I want to >>>> share: >>>> https://design.xwiki.org/xwiki/bin/download/Proposal/EditConflict/linescolo… >>>> Ideally I would like to see real time, if not the exact changes, but at >>>> least the lines affected by the current editor. >>>> Thanks, >>>> Caty >>>>> >>>>> 5. The conflict resolution is line-by-line based. >>>>> >>>>> WDYT? >>>>> Simon >>>>> >>>>> On 23/05/2019 10:00, Vincent Massol wrote: >>>>>> >>>>>> >>>>>>> On 23 May 2019, at 09:43, Simon Urli <simon.urli(a)xwiki.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 23/05/2019 09:31, Vincent Massol wrote: >>>>>>>>> On 23 May 2019, at 09:25, Simon Urli <simon.urli(a)xwiki.com> wrote: >>>>>>>>> >>>>>>>>> Hi Caty, >>>>>>>>> >>>>>>>>> On 22/05/2019 14:51, Ecaterina Moraru (Valica) wrote: >>>>>>>>>> I'm not sure I agree about this profile option. >>>>>>>>>> Indeed we want to make things as simple as possible and having >>>>> conflict >>>>>>>>>> resolutions can be scary, still, there is no way an user could take >>>>> this >>>>>>>>>> decision in advance. >>>>>>>>>> Users will want to have control over what they do and at least know >>>>>>>>>> something went wrong. We cannot automatically merge, without any >>>>> warning, >>>>>>>>>> since users will immediately see that their work was changed. It >>>>> will be >>>>>>>>>> reported as a bug (in case they notice it) and they will expect to >>>>> be able >>>>>>>>>> to recover the work. >>>>>>>>>> I can't think of a case when an user would not care about the >>>>> changes and >>>>>>>>>> the result. >>>>>>>>> >>>>>>>>> Let say that a document has 2 sections, and a user is editing section >>>>> 1, while the other is editing section 2. The merge should work properly >>>>> without any conflict. >>>>>>>>> I don't really see the point of asking by default the second user if >>>>> he's ok to merge his work on section 1 with what has been saved on section >>>>> 2. >>>>>>>>> On the contrary I feel it could be scary for the basic users to see >>>>> this kind of message and it decreases the easiness of using XWiki IMO. >>>>>>>>> >>>>>>>>>> Also the options are not clear to me: like 2: automatically merge, >>>>> but ask. >>>>>>>>>> Well is automatically or not? >>>>>>>>> >>>>>>>>> It's automatic but as you mentioned just after, in case of changes >>>>> are made on the same line there is a conflict that needs to be solved. >>>>> That's what I meant by "ask in case of merge conflict". >>>>>>>>> >>>>>>>>> On the contrary option 1 was a fully automatic merge, with a >>>>> predefined strategy to choose one version over another in case of conflict. >>>>>>>>> >>>>>>>>>> We need to ask for resolution only if the changes are on the same >>>>> line, >>>>>>>>>> besides this, we should try to automatically merge, but provide the >>>>> info to >>>>>>>>>> the user that we did that. Instead of the normal Save message, we >>>>> could say >>>>>>>>>> that we performed a Merged Save. And in the history I would expect >>>>> to be >>>>>>>>>> able to see what lines were added by what users, just in case >>>>> something >>>>>>>>>> went wrong. We are lucky that we have the Blame view :) >>>>>>>>>> So not sure we need a configurable option in profile. We just need to >>>>>>>>>> decide on the 'default' and implement that. We keep adding options >>>>> that >>>>>>>>>> only increase the complexity of the product and we never get to test >>>>> all >>>>>>>>>> the possible mixes and configurations. >>>>>>>>>> So what are the use cases when we would need this option in the >>>>> profile? >>>>>>>>> >>>>>>>>> As I said above I personally don't see the point of always displaying >>>>> the merge diff especially for basic users when there's no conflict. Now I >>>>> really think that some users would want that, that's why I proposed the >>>>> profile option. >>>>>>>> I agree that option 3 is not great as it gets in the way. Now it could >>>>> be interesting for the user to know it happened. Maybe some fleeting >>>>> notifications at the bottom of the screen or some info added to the commit >>>>> message or some visual info when you’re in edit mode and before you press >>>>> save. >>>>>>> >>>>>>> So in case of "Save&Continue" it's quite easy to change the "Saved" >>>>> notification message by another one. I'm not quite sure how to inform the >>>>> user about the merge if he cliks on "Save&View”. >>>>>> >>>>>> By implementing the part below :) ie by providing this info continuously >>>>> before he clicks any save button. >>>>>> >>>>>>> >>>>>>>> Ideally I’d like that we poll regularly to see if there have been >>>>> changes and display some icon if there are with the ability for the current >>>>> user to click and see the diffs with his version, and if there’s a >>>>> conflict, that a visible message is displayed on the screen (but without >>>>> interrupting of his typing). >>>>>> >>>>>> More details: when there’s a conflict, clicking the message/button would >>>>> show the diff and the conflict. >>>>>> >>>>>>>> And when he saves, the merge is done then. >>>>>>> >>>>>>> I like the idea, now would that be enough to inform about the performed >>>>> merge? If we go in that direction I'd need some design proposal for the UI >>>>> @Caty :) >>>>>> >>>>>> Yes we need to find where to put that information. >>>>>> >>>>>> BTW, even better, we should ideally also display the icons of the users >>>>> who are editing the same doc and/or who have saved content after the >>>>> current user started editing. >>>>>> >>>>>> And we already have a design page for this ;) We called it >>>>> “collaborative editing”: >>>>>> >>>>> https://design.xwiki.org/xwiki/bin/view/Improvements/CollaborativeEditing >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>>> WDYT? >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>>> >>>>>>>>> Simon >>>>>>>>>> Thanks, >>>>>>>>>> Caty >>>>>>>>>> On Wed, May 22, 2019 at 12:04 PM Vincent Massol <vincent(a)massol.net> >>>>> wrote: >>>>>>>>>>> Hi Simon, >>>>>>>>>>> >>>>>>>>>>>> On 22 May 2019, at 10:45, Simon Urli <simon.urli(a)xwiki.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi everyone, >>>>>>>>>>>> >>>>>>>>>>>> I'm working on the merge on save for the roadmap of 11.5 and I >>>>> need some >>>>>>>>>>> decision to be taken. >>>>>>>>>>>> >>>>>>>>>>>> The main idea of the merge on save, is to try to merge users work >>>>> in >>>>>>>>>>> case of save conflict. Knowing that the merge might led to merge >>>>> conflict >>>>>>>>>>> in case of edits on the same places. Those merge conflict can be >>>>> tackled >>>>>>>>>>> automatically, but a priority will be then given to one version over >>>>>>>>>>> another. >>>>>>>>>>>> >>>>>>>>>>>> I first propose to add an option in user profile, so users would >>>>> have >>>>>>>>>>> the possibility to choose between: >>>>>>>>>>>> 1. Always merge automatically the work, even in case of merge >>>>> conflict >>>>>>>>>>> >>>>>>>>>>> I don’t understand this part. If there’s a conflict it means it >>>>> cannot be >>>>>>>>>>> merged… So would it do? Take latest version and overwrite previous >>>>> version? >>>>>>>>>>> >>>>>>>>>>>> 2. Always merge automatically, but ask what to do in case of >>>>> merge >>>>>>>>>>> conflict >>>>>>>>>>>> 3. Always ask what to do in case of save conflict >>>>>>>>>>>> >>>>>>>>>>>> Now the question is: what should be the default option? >>>>>>>>>>> >>>>>>>>>>> Certainly not 1! 2 is really the best to me. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> -Vincent >>>>>>>>>>> >>>>>>>>>>>> Option 1 looks like a good fit for decreasing the number of clicks >>>>> to >>>>>>>>>>> do, but I'm a bit afraid that in case of conflict they would have >>>>> the same >>>>>>>>>>> feeling as before the warning conflict window: i.e. to loose some >>>>> part of >>>>>>>>>>> their work. >>>>>>>>>>>> >>>>>>>>>>>> WDYT? >>>>>>>>>>>> >>>>>>>>>>>> Simon >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Simon Urli >>>>>>>>>>>> Software Engineer at XWiki SAS >>>>>>>>>>>> simon.urli(a)xwiki.com >>>>>>>>>>>> More about us at http://www.xwiki.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Simon Urli >>>>>>>>> Software Engineer at XWiki SAS >>>>>>>>> simon.urli(a)xwiki.com >>>>>>>>> More about us at http://www.xwiki.com >>>>>>> >>>>>>> -- >>>>>>> Simon Urli >>>>>>> Software Engineer at XWiki SAS >>>>>>> simon.urli(a)xwiki.com >>>>>>> More about us at http://www.xwiki.com >>>>>> >>>>> >>>>> -- >>>>> Simon Urli >>>>> Software Engineer at XWiki SAS >>>>> simon.urli(a)xwiki.com >>>>> More about us at http://www.xwiki.com >>>>> >>> >>> -- >>> Simon Urli >>> Software Engineer at XWiki SAS >>> simon.urli(a)xwiki.com >>> More about us at http://www.xwiki.com > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.urli(a)xwiki.com > More about us at http://www.xwiki.com

On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote: wrote: >> So trying to sum up the discussion to see if we all agree. >> >> All the above is in the case of a save conflict: >> >> 1. Default behaviour for all users is to try an automatic merge, and

what line. Apparently I wasn't clear about my "all or nothing" feature. For me it only concern the resolution of the merge conflicts, but the choice made apply to ALL conflict of the document. That's what I meant.

So you'd go with a -1 for this option?

>> >> 3. When a user save with a merge, the notification message displays

>> it's a merge save. It means that user clicking on "save&view" might

>> it. >> > On "Save&View" we can increase the timeout for the notification. > The notification could mention also the magnitude: "Saved. Auto-merged

How would you quantify this magnitude? The number of versions between the two saves? What about minor/major versions? It looks a bit fuzzy to

>>>>>> >>>>>> Hi Caty, >>>>>> >>>>>> On 22/05/2019 14:51, Ecaterina Moraru (Valica) wrote: >>>>>>> I'm not sure I agree about this profile option. >>>>>>> Indeed we want to make things as simple as possible and having >> conflict >>>>>>> resolutions can be scary, still, there is no way an user could

>> this >>>>>>> decision in advance. >>>>>>> Users will want to have control over what they do and at least

>>>>>>> something went wrong. We cannot automatically merge, without any >> warning, >>>>>>> since users will immediately see that their work was changed. It >> will be >>>>>>> reported as a bug (in case they notice it) and they will expect

section >> 1, while the other is editing section 2. The merge should work

>> without any conflict. >>>>>> I don't really see the point of asking by default the second user

section >> 2. >>>>>> On the contrary I feel it could be scary for the basic users to

>> this kind of message and it decreases the easiness of using XWiki IMO. >>>>>> >>>>>>> Also the options are not clear to me: like 2: automatically

conflict. >>>>>> >>>>>>> We need to ask for resolution only if the changes are on the same >> line, >>>>>>> besides this, we should try to automatically merge, but provide

>> info to >>>>>>> the user that we did that. Instead of the normal Save message, we >> could say >>>>>>> that we performed a Merged Save. And in the history I would

>> to be >>>>>>> able to see what lines were added by what users, just in case >> something >>>>>>> went wrong. We are lucky that we have the Blame view :) >>>>>>> So not sure we need a configurable option in profile. We just

to >>>>>>> decide on the 'default' and implement that. We keep adding

test displaying Now I >> really think that some users would want that, that's why I proposed

could commit press the continuously current >> user to click and see the diffs with his version, and if there’s a >> conflict, that a visible message is displayed on the screen (but

would performed >> merge? If we go in that direction I'd need some design proposal for

UI >> @Caty :) >>> >>> Yes we need to find where to put that information. >>> >>> BTW, even better, we should ideally also display the icons of the

vincent(a)massol.net> wrote: >>>>>>>>> >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> I'm working on the merge on save for the roadmap of 11.5 and I >> need some >>>>>>>> decision to be taken. >>>>>>>>> >>>>>>>>> The main idea of the merge on save, is to try to merge users

over >>>>>>>> another. >>>>>>>>> >>>>>>>>> I first propose to add an option in user profile, so users

>> have >>>>>>>> the possibility to choose between: >>>>>>>>> 1. Always merge automatically the work, even in case of

>> conflict >>>>>>>> >>>>>>>> I don’t understand this part. If there’s a conflict it means it >> cannot be >>>>>>>> merged… So would it do? Take latest version and overwrite

clicks >> to >>>>>>>> do, but I'm a bit afraid that in case of conflict they would

>> the same >>>>>>>> feeling as before the warning conflict window: i.e. to loose

On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote: > On Thu, May 23, 2019 at 12:10 PM Simon Urli

wrote: > >> So trying to sum up the discussion to see if we all agree. >> >> All the above is in the case of a save conflict: >> >> 1. Default behaviour for all users is to try an automatic

>> display a window conflict resolution in case of merge

>> conflict resolution is an all-or-nothing based, allowing

>> version over another. >> > > I don't agree about the all-or-nothing, since I would

what > we can, warn on conflicts. > We should show a resolution conflict when the conflict is

line. Apparently I wasn't clear about my "all or nothing" feature.

only concern the resolution of the merge conflicts, but the

apply to ALL conflict of the document. That's what I meant.

> > >> >> 2. There is an option in the user profile to be able to

>> diff in case of save conflict, to accept or not the merge,

>> there's no conflict. >> > > I don't like the option in the profile. IMO we should

> behavior and apply it for all users. Edit is a core

So you'd go with a -1 for this option?

> >> >> 3. When a user save with a merge, the notification message

>> it's a merge save. It means that user clicking on

>> it. >> > > On "Save&View" we can increase the timeout for the

> The notification could mention also the magnitude: "Saved.

How would you quantify this magnitude? The number of versions

the two saves? What about minor/major versions? It looks a

in case of Save&View, so making the user wait on a notif

diff/conflicts >> > > This mockup might not help, but is something I had in mind

> > Ideally I would like to see real time, if not the exact

> least the lines affected by the current editor. > > Thanks, > Caty > > >> >> 5. The conflict resolution is line-by-line based. >> >> WDYT? >> Simon >> >> On 23/05/2019 10:00, Vincent Massol wrote: >>> >>> >>>> On 23 May 2019, at 09:43, Simon Urli

>>>> >>>> >>>> >>>> On 23/05/2019 09:31, Vincent Massol wrote: >>>>>> On 23 May 2019, at 09:25, Simon Urli

>>>>>> >>>>>> Hi Caty, >>>>>> >>>>>> On 22/05/2019 14:51, Ecaterina Moraru (Valica) wrote: >>>>>>> I'm not sure I agree about this profile option. >>>>>>> Indeed we want to make things as simple as possible

>> conflict >>>>>>> resolutions can be scary, still, there is no way an

>> this >>>>>>> decision in advance. >>>>>>> Users will want to have control over what they do and

>>>>>>> something went wrong. We cannot automatically merge,

>> warning, >>>>>>> since users will immediately see that their work was

>> will be >>>>>>> reported as a bug (in case they notice it) and they

>> be able >>>>>>> to recover the work. >>>>>>> I can't think of a case when an user would not care

>> changes and >>>>>>> the result. >>>>>> >>>>>> Let say that a document has 2 sections, and a user is

section >> 1, while the other is editing section 2. The merge should

>> without any conflict. >>>>>> I don't really see the point of asking by default the

>> he's ok to merge his work on section 1 with what has been

section >> 2. >>>>>> On the contrary I feel it could be scary for the basic

>> this kind of message and it decreases the easiness of

>>>>>> >>>>>>> Also the options are not clear to me: like 2:

>> but ask. >>>>>>> Well is automatically or not? >>>>>> >>>>>> It's automatic but as you mentioned just after, in

>> are made on the same line there is a conflict that needs

>> That's what I meant by "ask in case of merge conflict". >>>>>> >>>>>> On the contrary option 1 was a fully automatic merge,

>> predefined strategy to choose one version over another in

conflict. >>>>>> >>>>>>> We need to ask for resolution only if the changes are

>> line, >>>>>>> besides this, we should try to automatically merge,

>> info to >>>>>>> the user that we did that. Instead of the normal Save

>> could say >>>>>>> that we performed a Merged Save. And in the history I

>> to be >>>>>>> able to see what lines were added by what users, just

>> something >>>>>>> went wrong. We are lucky that we have the Blame view :) >>>>>>> So not sure we need a configurable option in profile.

to >>>>>>> decide on the 'default' and implement that. We keep

>> that >>>>>>> only increase the complexity of the product and we

test >> all >>>>>>> the possible mixes and configurations. >>>>>>> So what are the use cases when we would need this

displaying >> the merge diff especially for basic users when there's no

Now I >> really think that some users would want that, that's why I

>> profile option. >>>>> I agree that option 3 is not great as it gets in the

could >> be interesting for the user to know it happened. Maybe

>> notifications at the bottom of the screen or some info

commit >> message or some visual info when you’re in edit mode and

press >> save. >>>> >>>> So in case of "Save&Continue" it's quite easy to change

>> notification message by another one. I'm not quite sure

the continuously >> before he clicks any save button. >>> >>>> >>>>> Ideally I’d like that we poll regularly to see if there

>> changes and display some icon if there are with the

current >> user to click and see the diffs with his version, and if

>> conflict, that a visible message is displayed on the

>> interrupting of his typing). >>> >>> More details: when there’s a conflict, clicking the

would >> show the diff and the conflict. >>> >>>>> And when he saves, the merge is done then. >>>> >>>> I like the idea, now would that be enough to inform

performed >> merge? If we go in that direction I'd need some design

UI >> @Caty :) >>> >>> Yes we need to find where to put that information. >>> >>> BTW, even better, we should ideally also display the

>> who are editing the same doc and/or who have saved content

vincent(a)massol.net <mailto:vincent@massol.net>> >> wrote: >>>>>>>> Hi Simon, >>>>>>>> >>>>>>>>> On 22 May 2019, at 10:45, Simon Urli

wrote: >>>>>>>>> >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> I'm working on the merge on save for the roadmap of

>> need some >>>>>>>> decision to be taken. >>>>>>>>> >>>>>>>>> The main idea of the merge on save, is to try to

>> in >>>>>>>> case of save conflict. Knowing that the merge might

>> conflict >>>>>>>> in case of edits on the same places. Those merge

>> tackled >>>>>>>> automatically, but a priority will be then given to

over >>>>>>>> another. >>>>>>>>> >>>>>>>>> I first propose to add an option in user profile,

>> have >>>>>>>> the possibility to choose between: >>>>>>>>>    1. Always merge automatically the work, even in

>> conflict >>>>>>>> >>>>>>>> I don’t understand this part. If there’s a conflict

>> cannot be >>>>>>>> merged… So would it do? Take latest version and

>> version? >>>>>>>> >>>>>>>>>    2. Always merge automatically, but ask what to

>> merge >>>>>>>> conflict >>>>>>>>>    3. Always ask what to do in case of save conflict >>>>>>>>> >>>>>>>>> Now the question is: what should be the default option? >>>>>>>> >>>>>>>> Certainly not 1! 2 is really the best to me. >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>> >>>>>>>>> Option 1 looks like a good fit for decreasing the

clicks >> to >>>>>>>> do, but I'm a bit afraid that in case of conflict

>> the same >>>>>>>> feeling as before the warning conflict window: i.e.

On Thu, May 23, 2019 at 6:33 PM Simon Urli &lt;simon.urli(a)xwiki.com&gt; wrote: to > >> display a window conflict resolution in case of merge conflict. The > >> conflict resolution is an all-or-nothing based, allowing to choose a > >> version over another. > >> > > > > I don't agree about the all-or-nothing, since I would prefer to

Here it was the confusion, since in my mind, I though we were going line

line. You said that in the first version we won't have this, but ideal implementation it should go like that (and even at the word / character level for realtime-editing). > > > > > >> > >> 2. There is an option in the user profile to be able to always see

> >> diff in case of save conflict, to accept or not the merge, even when > >> there's no conflict. > >> > > > > I don't like the option in the profile. IMO we should decide on the > > behavior and apply it for all users. Edit is a core feature,

We should add a new configuration only if it's needed. Again, I think we are introducing a lot of things (parent/child relation, accessibility options, etc.) that we never test. We don't reach a conclusion by ourselves, so trying to make everyone happy, we are just increasing the complexity of selection for the user and for the testers. that miss > >> it. > >> > > > > On "Save&View" we can increase the timeout for the notification. > > The notification could mention also the magnitude: "Saved.

10 me. The magnitude I had in mind applied for the line by line case. If you

at the image

, 3 lines were successfully merged, while having conflict on 1 line. So

were tacking about different things. The idea was to redirect the user as soon as possible in the View mode, just display the bottom page notification a bit longer (or add a notification display for the View step). Thanks, Caty > > Simon > > > >> > >> Those are the first three priority points. The following points are > >> important too, but might not be finished in 11.5. > >> > >> 4. If another user saved a document that I'm editing, I have a > >> notification in the editor and I can click on it to see the > diff/conflicts > >> > > > > This mockup might not help, but is something I had in mind that I

to

> > > > Ideally I would like to see real time, if not the exact changes, but

> > least the lines affected by the current editor. > > > > Thanks, > > Caty > > > > > >> > >> 5. The conflict resolution is line-by-line based. > >> > >> WDYT? > >> Simon > >> > >> On 23/05/2019 10:00, Vincent Massol wrote: > >>> > >>> > >>>> On 23 May 2019, at 09:43, Simon Urli &lt;simon.urli(a)xwiki.com&gt;

wrote: take know > >>>>>>> something went wrong. We cannot automatically merge, without

> >> warning, > >>>>>>> since users will immediately see that their work was changed.

to properly > >> without any conflict. > >>>>>> I don't really see the point of asking by default the second

if see > >> this kind of message and it decreases the easiness of using XWiki

merge, > >> but ask. > >>>>>>> Well is automatically or not? > >>>>>> > >>>>>> It's automatic but as you mentioned just after, in case of

> >> are made on the same line there is a conflict that needs to be

> >> That's what I meant by "ask in case of merge conflict". > >>>>>> > >>>>>> On the contrary option 1 was a fully automatic merge, with a > >> predefined strategy to choose one version over another in case of > conflict. > >>>>>> > >>>>>>> We need to ask for resolution only if the changes are on the

the > >> info to > >>>>>>> the user that we did that. Instead of the normal Save message,

expect need options the > >> profile option. > >>>>> I agree that option 3 is not great as it gets in the way. Now it > could > >> be interesting for the user to know it happened. Maybe some fleeting > >> notifications at the bottom of the screen or some info added to the > commit > >> message or some visual info when you’re in edit mode and before you > press > >> save. > >>>> > >>>> So in case of "Save&Continue" it's quite easy to change the

> >> notification message by another one. I'm not quite sure how to

without the users

> >>> > >>> Thanks > >>> -Vincent > >>> > >>>> > >>>> Simon > >>>> > >>>>> WDYT? > >>>>> Thanks > >>>>> -Vincent > >>>>>> > >>>>>> Simon > >>>>>>> Thanks, > >>>>>>> Caty > >>>>>>> On Wed, May 22, 2019 at 12:04 PM Vincent Massol < > vincent(a)massol.net&gt; > >> wrote: > >>>>>>>> Hi Simon, > >>>>>>>> > >>>>>>>>> On 22 May 2019, at 10:45, Simon Urli &lt;simon.urli(a)xwiki.com&gt; > wrote: > >>>>>>>>> > >>>>>>>>> Hi everyone, > >>>>>>>>> > >>>>>>>>> I'm working on the merge on save for the roadmap of 11.5 and

work > >> in > >>>>>>>> case of save conflict. Knowing that the merge might led to

> >> conflict > >>>>>>>> in case of edits on the same places. Those merge conflict can

> >> tackled > >>>>>>>> automatically, but a priority will be then given to one

would merge > >> conflict > >>>>>>>> > >>>>>>>> I don’t understand this part. If there’s a conflict it means

previous > >> version? > >>>>>>>> > >>>>>>>>> 2. Always merge automatically, but ask what to do in case

have some

On 22 May 2019, at 10:45, Simon Urli &lt;simon.urli(a)xwiki.com&gt; wrote: Hi everyone, I'm working on the merge on save for the roadmap of 11.5 and I need some decision to be taken. The main idea of the merge on save, is to try to merge users work in case of save conflict. Knowing that the merge might led to merge conflict in case of edits on the same places. Those merge conflict can be tackled automatically, but a priority will be then given to one version over another. I first propose to add an option in user profile, so users would have the possibility to choose between: 1. Always merge automatically the work, even in case of merge conflict

2. Always merge automatically, but ask what to do in case of merge conflict 3. Always ask what to do in case of save conflict Now the question is: what should be the default option?

Option 1 looks like a good fit for decreasing the number of clicks to do, but I'm a bit afraid that in case of conflict they would have the same feeling as before the warning conflict window: i.e. to loose some part of their work. WDYT? Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

On 23 May 2019, at 09:14, Simon Urli &lt;simon.urli(a)xwiki.com&gt; wrote: Hi Vincent, all, On 22/05/2019 11:03, Vincent Massol wrote: We have an automatic fallback in case of conflict, for which we can choose the strategy: use current, previous or next version. By default the strategy is to take the current version. So the merge is never stucked in case of conflict, by default it returns the current version.

Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com