> I totally agree. Telemetry is invaluable to making software better.
Can you give 1(one) example of a program which was improved by using telemetry ? And no, trashing the UI in the name of change or modernism does not count.
Thank you.
Can you give 1(one) example of a program which was improved by using telemetry ? And no, trashing the UI in the name of change or modernism does not count.
Thank you.
- We found out by looking at the distribution of software version that we had a strong holdout on one specific revision. It turns out we had a regression in a niche feature which was very important to a sub-community of our users, and users were basically telling each other to just use that old version. No bug report was filed until we found out via analytics and asked.
- We have a "game quirks" mechanism where the emulator reports weird edge cases that happen very rarely. Current list: https://github.com/dolphin-emu/dolphin/blob/master/Source/Co..., example usage: https://github.com/dolphin-emu/dolphin/blob/ffdc8538a162b1ca... . We used this to find games that use currently unimplemented or stubbed features.
- The list of popular games being played on the emulator was extremely surprising because it turns out there's a huge disconnect in what most NA/EU players are playing and what JP players are playing. This led to us adding a bunch of new games to the list we regularly test for performance and stability regressions. Would you have guessed that Inazuma Eleven GO: Strikers 2013 is in the top10 of emulated games on Dolphin?
https://github.com/dolphin-emu/dolphin/blob/master/Source/Co... is the actual code which collects most of the information. We do multiple things to avoid being able to track user activity too much -- for example, while every instance of Dolphin has a unique ID so we can do things like unique counts, events that happen within a play session are associated to truncated_hash(unique ID + game ID) and not directly with the unique ID. This means that we can only correlate events from the same user playing the same game, but not* two events from one user playing different games.
* Our implementation is a bit weak given that the set of all gameids is small and enumerable. We could probably do better there.
I’m talking extremely basic things, like, what are the most popular crashes in the app? Which did I introduce in the most recent version? Why is there an increase in end to end latency in fetching data from the server? Stuff that would fall under “bug fixes and improvements” that you would likely not notice.
The last example sounds detailed enough. And some privacy considerations are moot when the app is a client for your server.
This sounds more like 'MS bad, must hate MS at all costs' then actual legitimate complaints.