4 ms·
Believe me, I understand the appeal. Yesterday we were discussing something dropping support for some platforms from an open source project and the issue is...
by ocdtrekkie 5y ago
Believe me, I understand the appeal. Yesterday we were discussing something dropping support for some platforms from an open source project and the issue is... we have no way of determining how many installs are on such platforms.
Telemetry would fix this, but it's not our right to collect data from other people's machines. So our best bet would be to detect the condition we expect to cause problems, notify them in advance, and allow time for feedback before implementing a change.
Is it less pretty and a worse user experience than telemetry? Absolutely. But when you realize you have no right to data collection on someone else's machine, telemetry isn't a viable option, and we would betray people's trust by doing it.
- gostsamo 5y agoThis would be true if you had an involved user based that follows your communication channels and can give you feedback through the proper channel for each change that you might make. If you have a change surface of hundreds of features/parameters, then it gets rather tricky. Edit: typo.
- judge2020 5y agoA checkbox (defaulted to disabled) during setup is the best option in my opinion.
- josefx 5y ago> Yesterday we were discussing something dropping support for some platforms from an open source project and the issue is... we have no way of determining how many installs are on such platforms. You seem to be assuming that your users are always online and not sitting somewhere isolated, the ideal place for platforms old enough that you want to stop supporting them. Telemetry only tells you if something is there, it doesn't tell you if something isn't.
- asoneth 5y agoI'm in a similar predicament for a business application. We've resorted to the "scream test". When there are features that are expensive to maintain that we suspect aren't being used (based on surveys, interviews, and usability tests) then we insert a notification when the feature is used announcing it's pending removal in some subsequent version. The notification includes contact information so if we get a higher-than-expected number of complaints then we may keep the feature.
- Brian_K_White 5y ago[ ] shitty option A [ ] shitty option B Telemetry showed that users overwhelmingly approve of shitty option B!
- recursive 5y agoWhether or not any of your options are good is a completely separate concern from whether or not you're using telemetry. If option B is the least bad option available, it's still better than A. Of course, you could also include a good option, and then telemetry would show a preference for that one.
- Brian_K_White 5y agoWill you next explain that water is wet? The point of the comment is to show that telemetry is used to conclude things that aren't true, and it absolutely is, and only says the subset of things that someone wants to hear, or that even occurs to them to ask. It's not even really a seperate issue, because even if you think you are only concerned with say how long a certain operation takes or how frequently it fails & retries, the more important issue may be why or whether that operation was even used at all in the first place. This aspect of telemetry is simply a fact to be aware of and stands on it's own, and does not necessarily mean to say "therefor telemetry is an invalid tool that should not exist and should never be used" It just means it's incomplete at best and very susceptible to both deception and self deception.