The KIPI fate

[Tobias Leupold]

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

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.