There are many things to do, I would recommend to start with setting up a similar system as used for getting Slicer download statistics:
Set up an nginx the server (based on Kitware’s recommendation) that returns success (200 OK) and an empty page whenever it receives a valid web request and it logs the request into a file.
You can run a simple flask application to check the validity of the request (similar to this but much simpler as you don’t need to return any real content)
Implement a script (almost the same as this) that parses the server logs and saves results into a database and/or json file
Implement web frontend that can display statistics (almost the same as this) - we would want the same kind of filtering based on geography, maybe operating system, display of graph; but instead of download count, we could select any of the events (module_DICOM_activate, module_SampleData_activate, extension_LungCTAnalyzer_AISegmentation, extension_LungCTAnalyzer_ClassicSegmentation, etc.)
Great, thanks for the feedback! We discuss this topic very openly for complete transparency and to make sure that everyone’s point of view is taken into account.
As you can see from the detailed discussion above, we absolutely don’t want to change Slicer to some online-only service. That would not make sense and you do not need to worry about that.
The main motivation for collecting feedback from users automatically is that most extension developers don’t get any financial compensation for their work; and their enthusiasm is only kept alive by seeing that people use their extensions. Of course everyone is busy, so people do not take the time to give feedback, which often causes developers to lose interest and give up maintaining and improving their extensions. The idea is that we could collect information about how many people use an extension and make it available to its developer, without requiring any efforts from the user. Of course users can opt out, or we could make reporting disabled by default (but then users would need to take an effort to enable reporting if they want to keep their beloved modules alive).
If you have any specific concerns or have ideas on how to do this well then let us know.
Thanks for replay, my answer was a bit ‘shizo’ but backed by many years and many similar examples from past. Just keep an eye on this ‘future’ and how it is used. It can be beneficial or dangerous for end user and even for project.
I cant demand and I dont demand anything (because I didnt contributed yet to project), I was only opinion. Thanks for reading and taking this biased opinion into account.
Thanks for great software (I dont use it commercially, I use it 100% as hobbyst)
Like … Spying on users? How could it be bad? I have no idea.
For projects like audacity (audio editor) - it had to drop the idea of telemetry but still have a bad PR to this day. But it was big project with lots of people using it, and after announcing telemetry to improve this program - it headed stright to /dev/null. So they have no choice and revert the idea of telemetry.
So, why its bad and why people dont like it?
-the way the data is sent is not transparent, its different than making a text file, that user can read and sending it via email attachment or similar mean.
-data collection dont really improve the software, like really, some of them are getting worse, and use more resources to just collect the data.
-(CubeIDE - for ARM microcontrollers).
-its slippery slope to collect more and more so called ‘telemetry’ data
-if you want to improve software - first improve bug/issue reporting, is it easy to ‘normal’ user, how its managed, what is the outcome?
Nobody really reads that stuff, and this fact can be used against user. Its user fault - but still can be used against user (that can assume that nobody will abuse him).
Does program provide a clear and easy way to view all data that will be sent (not only data type but FULL data) before sending?
can user say yes/no before each data send? Decide when, what and how this data will be sent?
can user easily without consequences (that program still works 100% as before), at any time disable / enable telemetry?
These specifics are very useful. We can very easily implement telemetry so that we can answer Yes to all these 3 questions.
Is there any information that you would be comfortable with sharing and any specific data that you would not want to share? (number of times Slicer is started, specific modules or features used; CPU, GPU, RAM, operating system, screen size information, …)
I think its OK, anything above that can be considered “fingerprinting” like kernel compilation, more specyfic hardware details etc. and even more - like accesing files and usage of fule etc. is in my opinion not apropriate. Thank You
Following up this morning weekly hangout, sources of the website that will be used to visualize the 3D Slicer application and extensions usage statistics will be organized in the following GitHub repository.
A pull request has been submitted that proposes to add qSlicerCoreApplication::logUsageEvent(QString component, QString event) method, which can be called by modules in Slicer core and extensions to indicate that certain software feature is used. The application itself does not process the event, just emits a usageEventLogged(QString, QString) signal, which can be connected to slots in external modules.
This API can be used for example for implementing an extension that collects usage data and computes usage statistics of various features. If no extensions are installed that processes software usage data then calling qSlicerCoreApplication::logUsageEvent has no effect.
Any questions and suggestions are welcome, preferably at the pull request, so that we have all the discussions related to this proposed change at one place.
I’m working on a repo where I’m developing a website to visualize the usage statistics of the 3D Slicer application and its extensions. So far, I’ve managed to create a bar chart that displays modules and functions. When you click on a bar in the modules chart, it filters the functions chart to show only the functions from the selected module.
I would appreciate a review of the charts and would love to hear any ideas on how to improve them.
I recognize that many of you have had reservations about the use of counters in the Lung CT Analyzer extension. In response, I have removed all counters from the extension. Additionally, due to the mechanism being buggy, all related data have been deleted.
Let’s collaborate to develop a more intelligent solution for this issue.
Wishing everyone a wonderful, counter-free weekend!
NOTE: I think on first iterations of the Telemetry extension we should auto-exclude (or even forbid) telemetry from european citizens because General Data Protection Regulation (GDPR) is very strict. We can always support european users later.
We don’t need to exclude European countries, as long as we don’t store any information that can identify individuals (such as email, IP address, hash created from fingerprinting the hardware components, etc.). Since many people would prefer not to be individually identified anyway, it is probably the best to just not store such information, only anonymous, aggregate data.
