Skip to content
This repository has been archived by the owner on Feb 20, 2023. It is now read-only.

For #17972: fix startup-timeline data in GLAM + split framework start metric #18043

Merged
merged 2 commits into from
Feb 19, 2021

Conversation

mcomella
Copy link
Contributor

@mcomella mcomella commented Feb 18, 2021

@boek or @mmccorks for data review
@MarcLeclair for full review

Request for data collection review form

All questions are mandatory. You must receive review from a data steward peer on your responses to these questions before shipping new data collection.

  1. What questions will you answer with this data?
  • How long does the framework take to start? Especially when the clock ticks per second is the expected value of 100
  1. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements? Some example responses:
  • Establish baselines or measure changes in product or platform quality or performance.
  • Determine if we should invest effort in improving the time it takes the framework to start
  1. What alternative methods did you consider to answer these questions? Why were they not sufficient?

We can measure locally but it's hard to know if the behavior we see locally is representative of actual user behavior.

  1. Can current instrumentation answer these questions?

Yes but it's not set up to be easily analyzed. THe change makes it easy to analyze in glam.

  1. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories found on the Mozilla wiki.

Note that the data steward reviewing your request will characterize your data collection based on the highest (and most sensitive) category.

frameworkPrimary - duration from process start to appInit when clock ticks per second is 100 Technical #17972
frameworkSecondary - duration from process start to appInit when clock ticks per second is not 100 Technical #17972
  1. Please provide a link to the documentation for this data collection which describes the ultimate data set in a public, complete, and accurate way.

https://github.com/mozilla-mobile/fenix/blob/master/docs/metrics.md

  1. How long will this data be collected? Choose one of the following:
  • I want this data to be collected for 6 months initially (potentially renewable).
  1. What populations will you measure?
  • Which release channels?

All

  • Which countries?

All

  • Which locales?

All

  • Any other filters? Please describe in detail below.

No

  1. If this data collection is default on, what is the opt-out mechanism for users?

Telemetry settings toggle in app

  1. Please provide a general description of how you will analyze this data.

Read durations, especially 95th percentile, to determine if there are perf issues with it.

  1. Where do you intend to share the results of your analysis?

Internally: GLAM

  1. Is there a third-party tool (i.e. not Telemetry) that you are proposing to use for this data collection? If so:

No.

Pull Request checklist

  • Tests: This PR includes thorough tests or an explanation of why it does not
  • Screenshots: This PR includes screenshots or GIFs of the changes made or an explanation of why it does not
  • Accessibility: The code in this PR follows accessibility best practices or does not include any user facing features. In addition, it includes a screenshot of a successful accessibility scan to ensure no new defects are added to the product.

To download an APK when reviewing a PR:

  1. click on Show All Checks,
  2. click Details next to "Taskcluster (pull_request)" after it appears and then finishes with a green checkmark,
  3. click on the "Fenix - assemble" task, then click "Run Artifacts".
  4. the APK links should be on the left side of the screen, named for each CPU architecture

…ate docs.

This addresses the root problem we're experiencing for this issue - data
not showing up in GLAM.
@mcomella mcomella requested review from a team as code owners February 18, 2021 04:41
We do this in order to make it easier to analyze in GLAM: see the metric
descriptions for more details.

Additionally, we change the time unit to milliseconds to make it easier
to analyze in GLAM.
@codecov-io
Copy link

Codecov Report

Merging #18043 (4ab95fe) into master (7e70ecc) will increase coverage by 0.01%.
The diff coverage is 100.00%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master   #18043      +/-   ##
============================================
+ Coverage     32.83%   32.84%   +0.01%     
- Complexity     1382     1383       +1     
============================================
  Files           461      461              
  Lines         19426    19429       +3     
  Branches       2712     2713       +1     
============================================
+ Hits           6379     6382       +3     
  Misses        12511    12511              
  Partials        536      536              
Impacted Files Coverage Δ Complexity Δ
...lla/fenix/perf/StartupFrameworkStartMeasurement.kt 92.30% <100.00%> (+1.00%) 11.00 <0.00> (+1.00)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7e70ecc...4ab95fe. Read the comment docs.

Copy link
Contributor

@MarcLeclair MarcLeclair left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

Copy link

@mmccorks mmccorks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Data Review:

  1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?
    Yes, this will be documented in docs/metrics.md

  2. Is there a control mechanism that allows the user to turn the data collection on and off?
    Yes, users can opt out of telemetry collection.

  3. If the request is for permanent data collection, is there someone who will monitor the data over time?
    Not permanent data collection.

  4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
    Category 1, Technical data.

  5. Is the data collection request for default-on or default-off?
    Default on.

  6. Does the instrumentation include the addition of any new identifiers?
    No new identifiers.

  7. Is the data collection covered by the existing Firefox privacy notice?
    Yes.

  8. Does there need to be a check-in in the future to determine whether to renew the data?
    Check in in 6 months (August 2021).

  9. Does the data collection use a third-party collection tool?
    No.


data-review +

@mcomella mcomella merged commit 359f27a into mozilla-mobile:master Feb 19, 2021
@mcomella mcomella deleted the 17972-framework-start branch February 19, 2021 21:21
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants