Implementation wise, that seems to match what now kuserfeedback clearly in mind, so ++.

UX wise, I'm not completely sold. It still sounds like it's on by default till you read the long explanatory text to explain that just because it's not not disabled doesn't mean it's enabled - which is a bit confusing.

Assuming we keep kuserfeedback as-is, I think the wording needs to be something along the lines of "never prompt to enable feedback". It needs something that helps convey what the opposite of being forbidden is.
Though that still leaves a checkbox as a negative, which is against the HIG.

I would really prefer a for the UX to indicate that that telemetry is off by default and needs to be manually turned on, or else it's confusing and disconcerting to the user. If the framework doesn't really support this, then we should change the implementation in the framework IMO.

If the framework doesn't really support this

To hopefully clarify, the framework works as follows:

Global Enabled      | App Enabled* | Result
    off                      |    off               | off
    off                      |    on               | off
    on                      |    off               | off     <----- KDE default
    on                      |    on               | on

So the framework does support being off by default, and it is.

Thanks. Can we just surface that then? We'd show a UI for the global on/off switch and than additionally allow turning telemetry on or off for apps and Plasma. That seems like it might be less confusing than coming up with an abstraction surrounding it.

In D24635#547136, @ngraham wrote:

Thanks. Can we just surface that then? We'd show a UI for the global on/off switch and than additionally allow turning telemetry on or off for apps and Plasma. That seems like it might be less confusing than coming up with an abstraction surrounding it.

That's exactly what we are doing right now.
We probably need better wording for it.

In D24635#547168, @apol wrote:

In D24635#547136, @ngraham wrote:

Thanks. Can we just surface that then? We'd show a UI for the global on/off switch and than additionally allow turning telemetry on or off for apps and Plasma. That seems like it might be less confusing than coming up with an abstraction surrounding it.

That's exactly what we are doing right now.
We probably need better wording for it.

Ok, just tried this out. The problem is that the global on/off switch that's presented to the user is still reversed from what it should be: instead of saying, "forbid KDE software from bla bla bla", it should say "allow KDE software to bla bla bla". Otherwise the user looks at the unchecked checkbox and wonders, "is KDE software able to send information unless I check this?" And it's a valid concern because apparently that is in fact possible.

IMO we need to make the global killswitch be on by default (so all telemetry is forced off, which is what I thought we'd all agreed to). If we do that, then it's actually safe to have apps and Plasma turn telemetry on by default, because the global killswitch will be overriding them. And then when a user enables telemetry in this KCM, the global killswitch turns off and then apps and Plasma will instantly start sending information.

Does that make any sense?

Ok, just tried this out. The problem is that the global on/off switch that's presented to the user is still reversed from what it should be: instead of saying, "forbid KDE software from bla bla bla", it should say "allow KDE software to bla bla bla". Otherwise the user looks at the unchecked checkbox and wonders, "is KDE software able to send information unless I check this?" And it's a valid concern because apparently that is in fact possible.

IMO we need to make the global killswitch be on by default (so all telemetry is forced off, which is what I thought we'd all agreed to). If we do that, then it's actually safe to have apps and Plasma turn telemetry on by default, because the global killswitch will be overriding them. And then when a user enables telemetry in this KCM, the global killswitch turns off and then apps and Plasma will instantly start sending information.

Does that make any sense?

I understand what you say but I don't think that's even feasible. Does it really make sense that from e.g. KMail you need to ask the Plasma KCM for permission to send feedback?
Furthermore, a KMail user may not even be on Plasma, how would you enable feedback then?

In D24635#547820, @apol wrote:

I understand what you say but I don't think that's even feasible. Does it really make sense that from e.g. KMail you need to ask the Plasma KCM for permission to send feedback?
Furthermore, a KMail user may not even be on Plasma, how would you enable feedback then?

The global on/off switch would be in the KCM, which I think is where people would expect it to be. Once it's turned on, then I suppose the settings for whether or not KMail should send feedback would live in KMail (but it could also be visible in a central location, in the KCM). That's my vision for how it should work, at least.

I'll insist, this KCM is distributed by Plasma.
An Okular user on Windows won't have it available, this makes for tendentious data.

Even with Plasma users, the process of explaining people "you have to go to enable it in system settings, then you go to enable it in the app" is unnecessarily complex. This is something we must account for.