Some errors are fixed by updates. But an update is effective only if it is installed.
We have data about how quickly updates are installed, because the frequency of an error goes down after an update is published. But we don't have a way to visualize this data.
I suggest presenting it like this:
Let the *relative error rate* of an error, on a day, be the error rate (not the raw frequency, but the error rate) of just that error on that day, divided by the maximum rate that error ever reached. So on its most common day, the relative error rate for any error is exactly 1.
Let U = the date when an update is issued.
Then for each error that is fixed, calculate the relative error rate for each day, in a date range from about U–14 to about U+28.
Finally, plot the averages of all the relative error rates for U–14, U–13, U-12, and so on through to U+28.
The graph should look like half a skateboard halfpipe: fairly flat where the date < U, dropping steeply shortly after U, then flattening out.
Some errors are fixed by updates. But an update is effective only if it is installed.
We have data about how quickly updates are installed, because the frequency of an error goes down after an update is published. But we don't have a way to visualize this data.
I suggest presenting it like this:
Let the *relative error rate* of an error, on a day, be the error rate (not the raw frequency, but the error rate) of just that error on that day, divided by the maximum rate that error ever reached. So on its most common day, the relative error rate for any error is exactly 1.
Let U = the date when an update is issued.
Then for each error that is fixed, calculate the relative error rate for each day, in a date range from about U–14 to about U+28.
Finally, plot the averages of all the relative error rates for U–14, U–13, U-12, and so on through to U+28.
The graph should look like half a skateboard halfpipe: fairly flat where the date < U, dropping steeply shortly after U, then flattening out.