Open Dexterp37 opened 1 year ago
@rebecca-burwei (or @perrymcmanis144 , since you were cc'd on the initial bug), would you kindly expand a bit on what do you use the information for / why that's necessary or helpful? Thanks!
Probes change frequently (for evidence, see any of the examples I linked above). It's impossible to interpret our historical data without knowing how the probes have changed (for evidence, see any of the examples I linked above).
Probes change frequently (for evidence, see any of the examples I linked above). It's impossible to interpret our historical data without knowing how the probes have changed (for evidence, see any of the examples I linked above).
@rebecca-burwei the changelog mostly report "thing X was added, thing Y was removed in version Z". Is that good enough? I'm trying to get a better understanding of what you specifically are looking for because there might be an opportunity for us to automate this.
Yes -- that's exactly what's needed. :) We need to answer questions like:
It's very easy to develop misleading analyses without this information. @perrymcmanis144 did indicate that some of this might be automate-able.
Even if nothing else is possible, a simple changelog like:
Even a simple changelog like that would be an improvement because it would turn "unknown unknowns" into "known unknowns", and we could go digging in other docs as needed.
Oh one more that would be very helpful: "After version V, this probe is turned on/off by default for all clients on channels A, B, C."
@rebecca-burwei that's great context , thanks!
@Iinh @badboy do you think the above could be achieved via the probe info service data?
This partly overlaps with glean-annotations, which already allow to add further (unstructured) data to metrics.
Additionally, metrics can have a version
field (example, in use here). The dictionary currently does not show this version. Mapping that metric version to the app's version is currently not (automatically) possible. An app doesn't communicate in its payload which particular metric versions it contains.
To me it's not 100% clear what kind of structured data we'd want to enforce here.
In the end a user will have to digest this information anyway and interpret it when looking at data.
This could therefore become a documented convention for the description
field.
Or if we want to make tooling a little bit more aware of it a new changelog
field under metadata
of each metric.
Couple more thoughts I had on this:
Originally filed here by @rebecca-burwei
With Sponsored Tiles, Suggest and Urlbar on Firefox Desktop (Legacy telemetry), the implementing engineers write changelog-style docs for the probes. Here a few examples that illustrate what the changelog looks like and why this is necessary:
The Glean Dictionary should strongly encourage changelog-style docs. The open-ended commentary section is not sufficiently opinionated.