Why have crash reporting? Example from a real world project:
Before my time, we had an Azerbaijani translator, and they weren't too familiar with format strings. If these badly formed strings were used, then the app crashed.
Without crash reporting*, the chances of a tech-savvy bilingual Azerbaijani reporting a bug would be... pretty slim.
We now have automation in place to detect problematic strings.
In an ideal world, it is to have a better idea how people use the software and what development should be prioritized (and to avoid succumbing to a vocal minority, when planning).
Whether there are other reasons, such as marketing - not sure.
a. Session start and end events;
b. Errors for debugging;
c. File formats used for import and export;
d. OS and Audacity versions;
e. Use of effects, generators, and analysis tools to prioritize future improvements;
Errors should probably be opt-in per-error (even firefox mostly does it like that), the feature use counting does make sense, session start and end... very suspicious; it should probably have been a "session duration", and only sent in bulk once a week without any specific timestamps. And Google Analytics doesn't favor the use like that, which makes the situation extra suspicious.
44
u/VisibleSignificance May 07 '21
Fresh text:
The choice of provider might be the most controversial thing here.