Change Details

During the beta feature phase, we have had almost exclusively highly-experienced editors using the new workflow. It's possible that we will run into new issues when we enter "small default" and less-experienced users see our interface. I would like to collect some additional data to understand whether we're allowing data loss. We're also going to grab a bit more information about high-priority usability questions. When first presenting a conflict, [] How many of the chunks could be automatically resolved, and how many are a legitimate conflict? * [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TwoColConflict/+/576902/ | Log complexity metrics when entering a conflict workflow ]] #patch-for-review After a successful merge, [x] How many chunks were edited but not selected? [] How many chunks were selected but not edited, for which the corresponding conflicting chunk included diffs? * Although this is possible to do by replaying conflicts through postprocessing, we can also build the the "sed" edit list using wfMerge, and can log diff lists directly. This a bonus metric, without it we'll postprocess. In case we can intercept abandonment, [x] Were any textboxes edited before abandonment? * Same statistics are logged as above. [x] How did abandonment happen? Cancel button, back button, reload, tab closed... * We can discriminate between "cancel", "save", and everything else will be reported as "action: 'unknown'". [x] Store the "your" text and other edit fields needed to reconstruct the edit (section title, oldid, base revision). * I was unable to access the section title. Maybe EditPage doesn't carry the value forward as a parameter to conflict resolution?

During the beta feature phase, we have had almost exclusively highly-experienced editors using the new workflow. It's possible that we will run into new issues when we enter "small default" and less-experienced users see our interface. I would like to collect some additional data to understand whether we're allowing data loss. We're also going to grab a bit more information about high-priority usability questions. When first presenting a conflict, [x] How many of the chunks could be automatically resolved, and how many are a legitimate conflict? After a successful merge, [x] How many chunks were edited but not selected? [] How many chunks were selected but not edited, for which the corresponding conflicting chunk included diffs? * Although this is possible to do by replaying conflicts through postprocessing, we can also build the the "sed" edit list using wfMerge, and can log diff lists directly. This a bonus metric, without it we'll postprocess. In case we can intercept abandonment, [x] Were any textboxes edited before abandonment? * Same statistics are logged as above. [x] How did abandonment happen? Cancel button, back button, reload, tab closed... * We can discriminate between "cancel", "save", and everything else will be reported as "action: 'unknown'". [x] Store the "your" text and other edit fields needed to reconstruct the edit (section title, oldid, base revision). * I was unable to access the section title. Maybe EditPage doesn't carry the value forward as a parameter to conflict resolution?

During the beta feature phase, we have had almost exclusively highly-experienced editors using the new workflow. It's possible that we will run into new issues when we enter "small default" and less-experienced users see our interface. I would like to collect some additional data to understand whether we're allowing data loss. We're also going to grab a bit more information about high-priority usability questions. When first presenting a conflict, [x] How many of the chunks could be automatically resolved, and how many are a legitimate conflict? * [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TwoColConflict/+/576902/ | Log complexity metrics when entering a conflict workflow ]] #patch-for-review After a successful merge, [x] How many chunks were edited but not selected? [] How many chunks were selected but not edited, for which the corresponding conflicting chunk included diffs? * Although this is possible to do by replaying conflicts through postprocessing, we can also build the the "sed" edit list using wfMerge, and can log diff lists directly. This a bonus metric, without it we'll postprocess. In case we can intercept abandonment, [x] Were any textboxes edited before abandonment? * Same statistics are logged as above. [x] How did abandonment happen? Cancel button, back button, reload, tab closed... * We can discriminate between "cancel", "save", and everything else will be reported as "action: 'unknown'". [x] Store the "your" text and other edit fields needed to reconstruct the edit (section title, oldid, base revision). * I was unable to access the section title. Maybe EditPage doesn't carry the value forward as a parameter to conflict resolution?