Overhauling telemetry
We implemented KUserFeedback very conservatively, not reporting very much information at all. Then during the initial roll-out we got an amount of negativity and FUD for it as if we had actually implemented really intrusive telemetry! IMO we ended up with the worst of both worlds.
We also have a technical problem that we lack a method of changing what information is collected since this would require either creating new levels of data collection beyond the existing ones (which is not practical or scalable) or asking the user to re-agree to the new amounts of data collection for the level they've already chosen (which is not implemented).
The net result is that the information we collect is not very useful overall. At least for projects I'm familiar with (Plasma, Discover, and Dolphin), it has rarely been used for its intended purpose of guiding development.
As such, I'd like to propose overhauling how our telemetry works to improve the usefulness of the system for KDE developers.
- Make the System Settings KCM show all apps that have opted into KUserFeedback and serve as a central hub for managing the on/off status and level of telemetry of all your KDE software. Give it a central killswitch to turn it off everywhere.
- Implement the ability to change over time what is collected, and prompt the user to change their settings to opt into the new amount of data collection or stick with the current amount
- As a standard thing for one of the built-in levels of data collection, collect information on any default settings that have been changed, which can be used to help developers understand what settings users are changing and therefore what might not be the most ideal set of default settings.