I can't decide whether we should send StatsD metrics, or include in the EventLogging data. StatsD is easy to integrate with Grafana, but EventLogging allows us to slice along any dimension, e.g. per-wiki, and do deeper analysis of the exact conflicts.

I'll include this in the EventLogging data, I'm expecting to do some calculations before turning into a graph. In another task, Nuria recommends that we use a EventLogging -> Presto -> Superset pipeline.

In T245420#5897305, @awight wrote:

I can't decide whether we should send StatsD metrics, or include in the EventLogging data. StatsD is easy to integrate with Grafana, but EventLogging allows us to slice along any dimension, e.g. per-wiki, and do deeper analysis of the exact conflicts.

+1 On having this as part of EventLogging. I think it makes more sense there and it also might be helpful to have more context if we want to understand why people end up doing certain things a lot regarding selecting more "my" or "other" chunks. Or generally why some conflicts seem to show a lot chunks a lot.

@Lena_WMDE Please give the metrics one more sanity check at your convenience, I changed them quite a bit.

Quick note: it turns out to not be easy to tell which column includes diffs against the base revision. The available diff markup is for "mine - other", which isn't useful for the purposes of this task. We'll have to come up with other heuristics for detecting data loss.

While sifting through the data, I discovered that roughly half of the TwoColConflict conflicts in February were on *new* pages (baseRevisionId = 0), which shouldn't be the case. It's possible that we can dramatically reduce the number of conflicts happening in the first place.

select
    sum(if(event.baseRevisionId == 0, 1, 0)),
    count(*)
from twocolconflictconflict
where
    year=2020 and month=2
    and event.twoColConflictShown=true;

new | total
271 | 598

It gets weirder. Of the remaining conflicts in the same sample, 190 had parent revid equal to the latest revid--which should not result in a conflict, as I currently understand it.

select
    sum(if(event.baseRevisionId == event.latestRevisionId,1,0)),
    count(*)
from twocolconflictconflict
where
    year=2020 and month=2
    and event.twoColConflictShown=true
    and event.baseRevisionId != 0

equal | total
190   | 327

These two strange cases appear in similar numbers for January,

select
    sum(if(event.baseRevisionId == 0, 1, 0)) as new,
    sum(if(event.baseRevisionId == event.latestRevisionId and event.baseRevisionId != 0,1,0)) as head,
    count(*) as total
from twocolconflictconflict
where
    year=2020 and month=1
    and event.twoColConflictShown=true

new     head    total
218     231     617

Same report for the legacy conflict workflow shows the same proportions:

select sum(if(event.baseRevisionId == 0, 1, 0)) as new, sum(if(event.baseRevisionId == event.latestRevisionId and event.baseRevisionId != 0,1,0)) as head, count(*)
as total from twocolconflictconflict where year=2020 and month=1 and event.twoColConflictShown=false;

new     head    total
1181    1696    4646

The mystery conflict investigations are split into new tasks, not blocking this one: T246439: High proportion of edit conflicts seem to come from new article creation and T246440: High proportion of edit conflicts seem to not involve a conflicting edit.

We can log some additional information to help diagnose these issues.

Change 576291 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/TwoColConflict@master] [WIP] Track usage potentially leading to data loss

https://gerrit.wikimedia.org/r/576291

For review: changes to the EventLogging schema,
https://meta.wikimedia.org/w/index.php?title=Schema%3ATwoColConflictConflict&type=revision&diff=19866753&oldid=18155295

Change 576902 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/TwoColConflict@master] Log complexity metrics when entering a conflict workflow

https://gerrit.wikimedia.org/r/576902

Side research done in order to understand what can be done with our current logging and what's lacking: https://etherpad.wikimedia.org/p/conflict_queries

Change 576291 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Log conflict UI details at exit

https://gerrit.wikimedia.org/r/576291

Change 576902 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Log complexity metrics when entering a conflict workflow

https://gerrit.wikimedia.org/r/576902