After talking with @MNeisler today, we decided to descope these graphs being dynamic. If/when we come to need this, we'll file a follow-up task and implement then.

Hi @ppelberg

I have a couple of questions:

• Should I consider the time to complete/abandon from init_ or from another step (ready_, loaded_, first_change_)? The task description says once initiated, but I am wondering what might be more helpful to inform the decision for edit stash TTL.
• I am planning to consider one year-to-date data. Let me know if I should go further back (or any other time period).

hi, @KCVelaga_WMF! Great eye spotting these ambiguities. Responses below...

In T338634#8987708, @KCVelaga_WMF wrote:

• Should I consider the time to complete/abandon from init_ or from another step (ready_, loaded_, first_change_)? The task description says once initiated, but I am wondering what might be more helpful to inform the decision for edit stash TTL.

Let's consider the time to complete/abandon from init_

• I am planning to consider one year-to-date data. Let me know if I should go further back (or any other time period).

The time period you're proposing (one year-to-date) sounds great to me.

I am planning to consider one year-to-date data.

@KCVelaga_WMF: For long-term retained data (beyond the last 90 days) you should familiarize yourself with https://wikitech.wikimedia.org/wiki/Analytics/Event_Sanitization (if you haven't already) and review EditAttemptStep's entry in the sanitization allowlist.

@mpopov Yes, I was planning to use the sanitized data. Thank you for sharing the allow list.

In T338634#9018433, @KCVelaga_WMF wrote:

Shared the analysis with @mpopov and @MNeisler for review.

Excellent.

@ppelberg: A quick note in the meantime, initially I was planning to use the dt field, but later had to switch client_dt, after learning dt is logged server-side (leading to a vast number of sessions with 0-sec duration). Currently, client_dt is not allowed during EditAttemptStep sanitization, so the analysis was done using the data from 90 days preceding the date of analysis. Also, we think that client_dt can be included in the allow-list, and I will be submitting a patch for the same.

Thank you for sharing this update. To be doubly sure, would it be accurate for me to understand the impact of what you shared above as the following?

1. Because of an issue with EditAttemptStep's sanitization process, the analysis Megan and Mikhail are reviewing includes data from the previous 90 days as opposed to the past year
2. You've identified the issue I alluded to in "1)" and are submitting a patch to fix it.
3. "2)" means that going forward, it will be possible for us to conduct analyses of the sort this task is "asking" for that include > 90 days worth of data

1.) Because of an issue with EditAttemptStep's sanitization process, the analysis Megan and Mikhail are reviewing includes data from the previous 90 days as opposed to the past year

• Yes, they are reviewing the analysis that considers 90 days of event data, instead of the past year.

2.) You've identified the issue I alluded to in "1)" and are submitting a patch to fix it.

• Yes, I have submitted the patch - T341888

3.) "2)" means that going forward, it will be possible for us to conduct analyses of the sort this task is "asking" for that include > 90 days worth of data

• Once the patch is merged, yes. However, we will need to wait for some time (say a few months), before we can really go beyond 90 days for analyses that need to use client_dt. Allowing the field to pass through event sanitization will not change the historical data, as it was already cleaned and the original (unsanitized) data had been deleted. So once the patch is merged, the client_dt data will be kept beyond 90 days and also, events within the 90 day period (after the merge) will have the data as well.

All that you described in T338634#9029236 makes sense to me – thank you for clarifying, @KCVelaga_WMF

@ppelberg Here is the summary of the analysis

We have analyzed 90 days of unsanitized event data preceding 19 July 2023. The length of an edit session is calculated as a difference between the max and min of client_dt for a given editing_session_id. The data was analysed by desktop and mobile (phone) platforms, and by editing interfaces - visual editor and wikitext-2017 (a mode within visual editor).

Quantiles of edit session length distributions by platform and editing interface:

Time to save

Time to abort

Also, there were sessions with 0-duration. Among successfully saved edits, the number of 0-duration sessions is insignificant (0.02% of ~4.8 million sessions) - inclusion or exclusion of these don't have any effect on the distributions until the 99th percentile. However, among aborted edits, the number of 0-duration sessions is 1.3% of ~16.9 million sessions, and including them affects the distributions beyond the 75th percentile by bringing down the session lengths. For the analysis, 0-duration sessions were not considered, however, they are included in the report's appendix for reference.

The full report of the analysis (including histograms of the distributions) is available at https://github.com/wikimedia-research/edit-session-length-july-2023/blob/main/edit_session_length_analysis.ipynb

Let me know if you have any further questions.