I’m not clear on whether we should be changing this?

In T203619#4561356, @DLynch wrote:

I’m not clear on whether we should be changing this?

Hmm. I was thinking we definitely needed the init to calculate the edit save rate, which is now our primary program metric. However, it actually looks like we defined this in the past as the number of saveSuccess events over the number of ready events.

But what about the editing performance measurements that we did earlier this year? Both metrics there are defined to start from "the user clicking an "Edit" or "Edit source" button", so I don't know how we calculated that for the 2010 wikitext editor if we don't log init. @Deskana, do you know? I don't see any queries linked from the report.

@DLynch, @Jdforrester-WMF are you sure init has never been logged? This bit in WikiEditorHooks.php really looks like it's doing just that.

Nope, hazy memories only.

I talked about this more with @Jdforrester-WMF, and he pointed out that logging the init event on the server side isn't directly comparable to the visual editor's init. The server side event would come as the server is producing the edit page to send to the client, which will be some time after the user originally clicks the edit button to request that page. The visual editor actually logs the init when the user first clicks the edit button, which it can do because, unlike the 2010 wikitext editor, the editor load does not involve the page reload. Making this fully comparable would probably involve using an editing session ID persisted in session storage and regenerated whenever a new edit is initiated.

He also answered my question about the editing performance report: each ready event contains a readytiming property which is computed by the client, so it's not necessary to compare multiple events on the analysis side to measure performance. Assuming both the visual editor and the 2010 wikitext editor use the Navigation Timing API, the measurements should be comparable.

So yeah, I don't see a strong argument that this needs to be implemented, but we should still figure out why based on the code it seems to already be implemented and consider whether to fix that or strip it out.