On 16/4/22 18:11, Tobias Leupold wrote:
Hi all,
I'm just the small junior dev here, with surely no authority to decide
anything.
But don't do that. That will make a lot of people stop using our software. I'm
pretty sure about that. Either, we create a surveillance state or, in the best
case, it's just plain annoying (would you like to collect and submit telemetry
data? -- No).
Do we really want to shift in this direction?! Please someone say no.
At least for the projects I created or work on, I want my user feedback via
IRC, mailing lists, bug reports, feature requests or whatever. But not via
data collected by my applications and sent to some central server.
Cheers, Tobias
FWIW, the KDE telemetry policy can be found at
https://community.kde.org/Policies/Telemetry_Policy
It's _always_ opt-in, i.e. the user has to explicitly enable it if he/she chooses so. also any such
changes, to add kuserfeedback support, in KDE software are required to go through code review ...etc.
It's just like any other software that has an option to collect anonymous data for the sake of
improving the software, not for tracking users.
Am Samstag, 16. April 2022, 17:09:39 CEST schrieb o lu:
On 4/15/22 07:42, Harald Sitter wrote:
Going off on a tangent:
I think you are hitting on a very important point. No matter what
happens with kipi here, we should add userfeedback support for
features that we'd like to remove and get a sense of the users the
removal impacts. Right now we have no metrics, so all we are left with
is removing stuff and see how many people complain and possibly
backpedaling after the fact. That is not ideal.
HS
I used to be *completely* against telemetry of any sort until I saw an
article a couple of weeks ago that explained a use case in Firefox: they
were able to make a "heat map" of where users click in the toolbar to
see which buttons were being pressed and with what frequency. So I
think that all KDE applications should have a (configurable and
inspectable) telemetry option to let developers know exactly which
features are being used and how much. This would solve (at least in
part) the problem described above.
--
Ahmad Samir
