We believe it makes sense to keep both metrics alive for some time, even the feature is default, just to make sure the "old numbers" go down (more specifically: the old and new numbers should be the same then).

@thiemowmde I'm hoping to clarify "How many percents of the conflicts were fixed through the interface?": Does this mean, "What percent of all conflicts resolved were performed through the new interface?" (Easy but we don't have this graph yet.), or "How many of the conflicts merged using the new interface were successfully resolved?" (Does have a graph.)

Update: I made the panel anyway, it seems useful.

An observation from the code: TwoColConflict refers to the conflict count as "pageloads", which sounds like a qualitatively different number than the core conflict count, however they use the same code paths and are therefore directly comparable. In other words, the graphs should be correct.

Also, my previous question has been answered, we only need the "how many conflicts are resolved" panels, rather than the "share of conflicts through each interface".

One of the graphs is giving me trouble, showing "184%" resolved among other badness:

The "Percent resolved" graph bounces around, in nonsensicals ways such as TwoCol Resolved percent dropping from 40% to 10% only when another of the hidden lines is toggled. Line visibility is completely unrelated to the numbers, so I'm assuming something is wrong with Grafana or Graphite, rather than this being a problem with our graph.

Averages should not include null (missing) data points, for example when some groups haven't experienced any conflicts.

The data points were correctly "null", but the client-side average were calculated incorrectly. I found a bug https://github.com/grafana/grafana/issues/3244 which explains that choosing any of the null handling options other than "null as zero" results in a correct average. It makes the graphs look strange, but that's sort of a good thing since it exposes that we have missing data.