16

Compared to GNOME where there is no Control Center in which you can find all system settings, KDE has a single place for all settings - System Settings.

I propose to make program/plugin/whatever to track which settings users prefer. When KDE is installing the user should be asked if he agrees to send anonymous system settings stats, if he agreed, a special code is run every time the user modifies something in System Settings. That code tracks settings changes and sometimes presents the user a window about sending settings usage stats to a server. The window will visually present the information which is going to be sent. The user will be able to confirm the sending, cancel it or disable it completely for future runs.

Based on the accumulated data the developers will be able to see if default options are popular, what are the most often changes in the settings, which options are most popular, what external styles (get new hot stuff) are most popular (and may be included in the default installation).

The goal is to regularly update KDE default settings, themes, styles that KDE would be a pleasant experience.

+1 for the idea

blindvic wrote:When KDE is installing the user should be asked if he agrees to send anonymous system settings stats

KDE is installed by package manager run by system administrator. This question should be asked on per-user basis. Perhaps window pop up on first KDE run is bad idea. Perhaps window pop up when user enters System Settings for first time is bad idea. In both cases - users who just try to check KDE may be repelled from KDE by such questions.
The best we can do is to put checkbox somewhere and disable it by default. Users will have to check it by themselves. But we might have quite low reports in such case...
Maybe this program could check how long has it been since creation of ~/.kde/? If user did not touch this setting in, say, a week, then we may ask him. Most users should be quite familiar with KDE by that time. Of course if user did checked it on and then off, he should not be bothered. And this should be one-timer. If user said "no, thanks", he should not be bothered again.

blindvic wrote:if he agreed, a special code is run every time the user modifies something in System Settings.

What if user modifies files in ~/.kde/share/config/ by hand? I sometimes do.
Maybe just send these info once a week or something? This way it should be easier to track changes. Users who did not change their setting will be included by default, without any special math on server side.

Of course these are implementation default. I really like this idea, so I decided it may be good to talk about them.

Thanks for the feedback!

Minio wrote:

blindvic wrote:When KDE is installing the user should be asked if he agrees to send anonymous system settings stats

KDE is installed by package manager run by system administrator. This question should be asked on per-user basis. Perhaps window pop up on first KDE run is bad idea. Perhaps window pop up when user enters System Settings for first time is bad idea. In both cases - users who just try to check KDE may be repelled from KDE by such questions.
The best we can do is to put checkbox somewhere and disable it by default. Users will have to check it by themselves. But we might have quite low reports in such case...
Maybe this program could check how long has it been since creation of ~/.kde/? If user did not touch this setting in, say, a week, then we may ask him. Most users should be quite familiar with KDE by that time. Of course if user did checked it on and then off, he should not be bothered. And this should be one-timer. If user said "no, thanks", he should not be bothered again.

Maybe ask about submitting regular stats after first click on "apply" in system settings? Then only those who change something in settings will be asked.

Minio wrote:What if user modifies files in ~/.kde/share/config/ by hand? I sometimes do.
Maybe just send these info once a week or something? This way it should be easier to track changes. Users who did not change their setting will be included by default, without any special math on server side.

I think there is no reason to target all possible situations. But even someone modifies the settings editing *rc files manually, once he hits "apply" the changes settings are calculated based on those *rc files, so all the manually changes settings will be tracked too.

Minio wrote:Of course these are implementation default. I really like this idea, so I decided it may be good to talk about them.

I fear all our implementation details will be ignored by the developers, who have their own vision on this...

Please imagine this:
user logs in. A notification pops up with text like "you can help KDE development. Click here to learn more". This pop up stays until user interacts with it (I mean: it automatically hides, but will show up next time on login). If clicked, it displays new window with text about supplying configuration info, purpose, anonymousness, how to disable it and link to web page where user can learn more (possibly with detailed ToS which clearly states what info is gathered and what not). In that window are two buttons: "yes, please" and "no, thank you". When any of these is clicked, it is registered and notification from first sentence is never shown again.
If user decided to help KDE, then some kind of gathering script is run once a week.

This solution is easy to implement - we need one separate program with one configuration file and one checkbox somewhere. In fact, window that I have talked in previous paragraph could be KCModule itself. This way we achieve full modularity without touching of existing codebase. We could also put third button there: "send configuration to KDE right now".
This solution covers all user cases - no matter how configuration was changed (GUI, kwriteconfig, $EDITOR, some other app that messes up with *rc files), it finally gets to KDE.
This solution does not provide configuration to KDE immediately. But we are talking about statistics here - reports will not be generated more often than one a week or once a month (changes in user patterns will be visible only in wider timeframe, and analysis of such report must take time).

On the other hand, your solution excludes some user cases by design and requires us to mess with current codebase. It could also have small performance penalty (each time user clicks "Apply" we have to check two conditionals: if user had interact with our widget before and if he agreed or disagreed).
I agree that your solution may be more traffic-friendly - if send on request (when user click apply), we can send only modified file. But this requires implementation of some kind of caching mechanism, as user may configure KDE when he does not have access to Internet.

I am not trying to say my solution is the best. There may be other factors that I should have considered, and I did not. If taken into account, it may turn out that your implementation proposal is better. Please keep discussion constructive and feel free to point out any mistakes in my implementation proposal.

As usually, people see things differently, and that's normal.

I would like to not disturb people with some popups when a user starts his KDE session for the first time. I would rather show that information when the user actually changes anything in the settings, then the popup will be relevant, as some settings have modified. There is no reason to show that popup to people who never change their settings at all, the popup will annoy them.

The developers will tell us what is easier and better from implementation point of view.

But i think we just have to start with something, and the details will be changed many times. Let's hope this will be somehow implemented, if not ideally.

How about using one of those colorful "info bars" that seem to become popular now in KDE (Dolphin, Kate, ...)?

It could have a message like "Do you want to help KDE by allowing anonymous statistics about your System Settings usage to be transmitted to kde.org? (This can also be changed later using the configuration button above.) [Yes] [No]"

It could just quietly sit at the top or bottom of the systemsettings window, even across restarts, until the user either clicks "Yes" or "No".
At which point it will go away and never appear again, but an appropriate option in the systemsettings configuration will still be available in case the user changes his/her mind.

This way, it would be much less obtrusive than a message box, but just as discoverable.

smls wrote:How about using one of those colorful "info bars" that seem to become popular now in KDE (Dolphin, Kate, ...)?

It could have a message like "Do you want to help KDE by allowing anonymous statistics about your System Settings usage to be transmitted to kde.org? (This can also be changed later using the configuration button above.) [Yes] [No]"

It could just quietly sit at the top or bottom of the systemsettings window, even across restarts, until the user either clicks "Yes" or "No".
At which point it will go away and never appear again, but an appropriate option in the systemsettings configuration will still be available in case the user changes his/her mind.

This way, it would be much less obtrusive than a message box, but just as discoverable.

Nice idea!

As long as it is optional I think it's a good idea.