Bugzilla

(In reply to :Gijs (he/him) from comment #4)
> TBH I'm sorta confused about what motivated this and what question you need answered from me. The JIRA ticket helped, but the comment could have done with more context...

Apologies; I definitely could have done better there.

> The counts of bookmarks/history/bookmarks imported are already recorded, I believe, albeit in histograms because that telemetry is old. It's `FX_MIGRATION_BOOKMARKS_QUANTITY` and friends. Same thing for error counts. If data science is happy there's no data continuity problem there then I'm happy to review patches to change those to telemetry events or scalars if that's preferred, I guess?

a) I'm guessing what we would want to do is implement new probes and convince ourselves that they're generating correct data on the release channel before removing the old ones.

> > See Also section of this bug links to a Import 2.0 spec, and the Telemetry section of that page (which appears to be in very early stages) proposes having three pieces of "total bookmarks/history/password items imported".  We could easily do that here, and then we'd just look at whether one of these prefs is zero or non-zero instead of using a boolean pref, and I'm inclined to do it.  That said, Gijs, do you have any thoughts on this, given that that Telemetry section doesn't seem to have gotten a lot of attention yet?

> This is also confusing - are we talking about prefs or telemetry? Why would we store counts of imported data in prefs?

b) The idea is to collect this information in telemetry in a way that would be useful for various things, including sizing experiments or messaging rollouts, and also useful for targeting experiments or messaging system messages. Since it's easy to target experiments against the value of the pref, the idea is to write the data to a pref when it changes, and then use that pref as backing store to send the telemetry.  For this particular case, since we don't have any specific plans to target against "number of items imported", one could imagine make the telemetry and targeting separate, but it would be more work, and we'll already be collecting the data in telemetry anyway, so it's not clear to me why we would want to do that.

> Maybe this needinfo should have gone to Ania? I don't know what kind of my thoughts you're looking for. ;-)

I'll hold off on needinfo-ing you until :loines has verified that comment 3 and comment 5 (this comment) describes a system that does what DS wants, or, if not, how a system that DS wants would be different...

(In reply to :Gijs (he/him) from comment #4)
> TBH I'm sorta confused about what motivated this and what question you need answered from me. The JIRA ticket helped, but the comment could have done with more context...

Apologies; I definitely could have done better there.

> The counts of bookmarks/history/bookmarks imported are already recorded, I believe, albeit in histograms because that telemetry is old. It's `FX_MIGRATION_BOOKMARKS_QUANTITY` and friends. Same thing for error counts. If data science is happy there's no data continuity problem there then I'm happy to review patches to change those to telemetry events or scalars if that's preferred, I guess?

a) I'm guessing what we would want to do is implement new probes and convince ourselves that they're generating correct data on the release channel before removing the old ones.

> > See Also section of this bug links to a Import 2.0 spec, and the Telemetry section of that page (which appears to be in very early stages) proposes having three pieces of "total bookmarks/history/password items imported".  We could easily do that here, and then we'd just look at whether one of these prefs is zero or non-zero instead of using a boolean pref, and I'm inclined to do it.  That said, Gijs, do you have any thoughts on this, given that that Telemetry section doesn't seem to have gotten a lot of attention yet?

> This is also confusing - are we talking about prefs or telemetry? Why would we store counts of imported data in prefs?

b) The idea is to collect this information in telemetry in a way that would be useful for various things, including sizing experiments or messaging rollouts, and also useful for targeting experiments or messaging system messages. Since it's easy to target experiments against the value of the pref, the idea is to write the data to a pref when it changes, and then use that pref as backing store to send the telemetry.  For this particular case, since we don't have any specific plans to target against "number of items imported", one could imagine making the telemetry and targeting separate, but it would be more work and more complex, and we'll already be collecting both kinds of data in telemetry anyway, so it's not clear to me why we would want to do that.

> Maybe this needinfo should have gone to Ania? I don't know what kind of my thoughts you're looking for. ;-)

I'll hold off on needinfo-ing you until :loines has verified that comment 3 and comment 5 (this comment) describes a system that does what DS wants, or, if not, how a system that DS wants would be different...