Introducing Telemetry in the Notation Software

• Dec 8, 2019 - 00:25

We're all aware that a lot of improvements need to be made to Musescore 3. In the past, our focus has been directed by conversations held on the forum or feedback sent directly by users. In addition to this, we have now started to regularly user-test the app on a wide variety of musicians (thanks to Tantacrul). This is helping us get a sense of who our users are and where they are succeeding or struggling with Musescore 3.

Feedback and forum conversations help us learn about bugs, missing features and underperforming functionality; testing allows us to see what parts of the app are working well and what parts are invisible to the user. However, there are a lot of other things we want to understand. For example, we currently populate a significant portion of our top bar with large buttons for the following: New, Open, Save, Save to Cloud, Print, Undo, Redo, Zoom Controls & 'Concert Pitch'. What we don't know is the percentage of our audience who use these buttons instead of the file menu or shortcuts. Tantacrul: "From my previous experience designing Paint 3D at Microsoft, I can tell you that our most used control was the Undo button and I would expect that to be the case here." However, we have a suspicion that print, save to cloud, zoom controls and 'concert pitch' are far less used and could safely be moved elsewhere to make space for functions that get a lot more day-to-day use.

The ability to look at telemetry data to understand what aspects of the interface are being used is a vital tool in helping us prioritise effectively. Take the inspector, for example. We all know that it needs to be rearranged to provide better contextual options but how should we go about doing that? Our first problem is trying to determine the 'value' of a certain functionalities over others. If we determine that a feature is niche and demote it to a secondary or 'advanced' menu, there are inevitably going to be complaints. The problem then is determining whether those complaints represent 0.1% of users or 10%? Telemetry can help us answer these types of questions.

Telemetry would also help us determine whether new designs are performing well. At the moment, there's an open question about how many people have used the new customisation features in the Palettes panel and whether it has made much a difference to the experience of first-time users. If we suspected that aspects of the new design are suffering due to poor communication, we could track small experiments to validate that suspicion. In some cases, a big impact can result from very simple changes like rewording a phrase or making an icon less ambiguous.

High level telemetry

Another goal of telemetry is to track why Musescore is being used. For example: how many of our users open Musescore to complete quick musical tasks, like converting one file format to another? How many use it for large-scale orchestration and how many export parts? We'd like to know how much time is spent in the app too: how many sessions are under 30 seconds and how many are over two hours? How many sessions include an export to a midi file? High level telemetry should help us measure retention and stability more reliably too. It would be very useful to know how many people who have downloaded the app in the last 6 months are still using it? What percentage of sessions end in a crash?

The dangers of relying on telemetry

Despite everything mentioned above, I think it's important to state here that we do not intend to rely on telemetry to make decisions. Telemetry can tell you that something isn't being clicked on but it can't tell you whether the problem is down to bad design or just general disinterest. All telemetry can do is provide the smoke. Feedback and user-testing will show us the fire.

Respecting privacy & being transparent

We are now looking into systems that will allow us to track how people interact with Musescore without collecting any personal information and we think the most open way to do this is to ask permission from users (probably via a dialog box) when they install a new version.

This is our thinking so far and we'd like to open it up to the community to get your thoughts. There have been plenty of open source projects that have collected telemetry in the past. The ones that have been relatively successful (Citra, TimeScale DB, etc.) were open and transparent about the process. However, we're aware that there can be a resistance to information collection of any kind and we'd also like to hear the arguments for not doing it, too.

Снимок экрана от 2019-12-05 08-54-21.png


Telemetry is a bad idea.
In any case spyware rumors come out.
I don't approve. In fact, in this case, I prevent this software from accessing the firewall through the Internet.

You can do a survey instead.

Don't produce nonsense ideas, ask users instead, they say what you need.

Who said the "Concert Pitch" button was rarely used?
Someone who wasn't a musician must have said that.

In reply to by Ziya Mete Demircan

As usual, Ziya has hit this nail on the head. This is spying. This will destroy the software's reputation. This makes me feel ill. I wish the mac had a way to prevent apps from accessing the internet at all (I'd gladly upload from the site as in the old days). Or build a build that did not spy. Or write my own editor or go back to pencil and paper at the organ and ink pen for good copy, as I did for decades.

In reply to by Anatoly-os

Because many users would reject it as an unacceptable intrusion on their privacy, and you'll get articles written that list this app among apps that spy. Often there is not a choice, and you'll get more information if you make it not a choice. When I use the new feature in MacOS to say that I trust it enough to have access to my folders, I am making a statement of faith. Spying would erode that faith. Spying is user-hostile, not user-friendly.

In reply to by BSG

The codebase is open. Anyone can check whether the software send some data if users declined the use of telemetry. There will be a dialog asking whether you want to help us improve the software. If a user chooses "No", we won't collect any data.
Why would MuseScore be listed as a spy software?

In reply to by Tantacrul

Agreed! It's complete nonsense to describe a feature gated by a crystal clear opt-in dialog as spying. I'm pretty astonished at some of the resistance shown here. Perhaps people somehow failed to understand the nature of the opt-in? Although even that was very clear from the screenshot.

I also think it's significant over-paranoia to assume that anything more than a tiny fraction of the community would opt-in and then somehow deliberately create fake data. I wonder what these people are expecting - sabotage from rivals in the Sibelius / Dorico camps?! Sounds very far-fetched to me, and I can't think of any other sensible motivation for such attacks.

I think it's a great idea. Keep up the awesome work!

In reply to by Ziya Mete Demircan

What do you mean by "do a survey instead"? Do we need to ask people about the approximate duration of the sessions, the frequency of using buttons and different features of the software? What about crash free? How would we know the number of users that install software and stop using it for some reason?

We know almost nothing about the way people use the software. We know a lot from the ones on the forum and in the community. But we loose the ones who tried to use the software, but stopped without writing anything here. User testing shows different patterns of the behaviour. We see how new users complete simple tasks. And we see that the software is overcomplicated for new users.

The question is whether we want to keep the software in untouchable caste or make it easily accessible for everyone who wants to write music.

PS. Regarding "Concert Pitch", we don't know exactly, because we don't have Telemetry in the editor. It might be No 1 feature for you, but not for 99% of users. Again, we don't know.

In reply to by Anatoly-os

Create a branch of the software that includes telemetry. Then do a randomized email to some portion of the userbase, requesting if they would like to help with the development of the software by using a version (for a period of time) with some telemetry to measure how they use some features. Have this done a while after every major release.

Have them run this version of the software for a week, recording data. Delete the data within a month of the telemetry collection period ending, recording only overall statistics.

That keeps it sufficiently "survey-like" and doesn't require bundling the main software with toxic telemetry.

In reply to by LuuBluum

We will show the dialog asking whether users want to improve software by sending anonymous data. If a user chooses "No", we won't collect any data. Anyone can check this since the codebase is open. Why would we need to make a separate bundle? If you don't want to send data, just say "No".

In reply to by Anatoly-os

I'm sure that local time signatures, plugins, horizontal frames, and figured bass are used by "less that 1% of the users", but that's me -- I couldn't live without them. The English (or Russian, let alone Mandarin) dictionaries contain mostly words that are only used by 1% of the users, yet great writers would be at a loss were they "trimmed out.".

In reply to by BSG

We will never remove the functionality.
Good example! Schools never teach students to use unpopular words. The words are hidden until you find them somehow in a poem or a written story. But MuseScore might use those unpopular words on the main screen. We don't know exactly.
MuseScore should become a software for everyone who wants to write music, not for the ones who read dozens of articles and the book.

In reply to by BSG

It is not about of taking rarely used features away, but to detect them (the smoke) and then possibly move them to a less prominent place (the fire).
I for one detected the cloud icon just very recently, I used File > Save online instead since years, so I could certainly live with it being removed from the basic or even the advanced workspace, to make room for some feature that is more commonly used.

In reply to by Anatoly-os

I don't have any issue with the current menus and toolbars ;-) If I had, I'd know how to fix it.
I am using the cloud icon, now that I had detected it, but would have no problem giving up on it for something that is more important, to others.

I do, however, like to stay as close as possible to the default settings, just to not have to change too many things if and when a factory reset is needed.

My name is Zöe, I am a mermaid and I live in Sparkleville - that's what you'll get from many users if you install telemetry. Most users will simply turn it off but a few % will actively seek to overwhelm the sytem with false data. An even smaller number (say 1:10000) will resent the idea so much that they will track down the initiater of the idea.

Enjoy the unseasonably mild weather tonight, the light rain and light winds, getting slightly brisker.

In reply to by mirabilos

As far as I know Debian also has its own kind of telemetry, also completely optional to a user and with similar goals declared.

But the question of disabling certain features in software packages is something to be decided by their maintainers, so if it is required by Debian to disable telemetry in software distributed by the project then it is indeed completely fine to do so.

In reply to by dmitrio95

Indeed. The method of implementation Anatoly described elsewhere (modal dialogue box at startup, explaining clearly what’ll be collected, so users can opt-in) is good and might even be suitable for Debian (I’d have to check), as long as it doesn’t connect anywhere without prior consent (we had to remove the Start Centre from MuseScore in Debian for that reason, it connects to the website, and the website embeds external trackers like Google APIs, Google Analytics and I can’t promise that yet, but it sounds very acceptable.

I personally would not object for such data to be collected by a piece of sw that I have used and trusted for many years, as long as the items collected are clearly enumerated and kept under my control. As for new-comers, I suspect things can be quite different, though.

In reply to by HosAdeeb

I completely agree. In the same way that I don't sign anything without carefully reading it, I would not engage the telemetry without keeping a copy of everything it sends "home". Offering this possibility I think will increase the engagment of many cautious (or paranoid...) people.

If you have doubts on the general usefulness of a button in the menu...
Then the answer is to make the software more customisable, NOT to track users to adapt it to the 75% of users allowing telemetry and deceiving all the other ones.

In reply to by frfancha

Current situation is that 90% of users should adapt to the needs of 10% of the audience. If we can change the situation and meet the requirements of 80% of users, and let other 20% ones customise the interface, I would say, this would make MuseScore at least twice more popular than now.

I don't like the idea. But as long as I can switch it off, I don't care too much (this is what I do to any other software that uses this too). How, why, when and where I use any software is my business alone.

  • If you do this, make sure the dialog that asks for perimissions very clearly states what this is about, why, how, where and by whom the data gets used.
  • Make sure that this setting/decision can get changed later, and without needing a factory reset or be over-complicated (like don't hide it in the Advanced settings)
  • Make sure the dialog buttons are not "OK" and "Cancel", esp. not the latter, as that would cause missunderstandings ("Cancel? The installation?"), but rather "Yes" and "No"
  • Best make "No" the default, 2nd best (and least IMHO) don't use any default, forcing the user to make a decision rather allowing to "Return; Return; ..." over it

I really do appreciate you bring up this discission. And I can see where that data might be of value.

I (vaguely) remember a few softwares already doing that, and I'm OK with it.

As long as I can view the source code and make sure nothing other than collecting non-private usage information is going on :) Not that I don't trust you, it's just "for safety reasons". If it's necessary, we can probably also write a report explaining basically what we change and if users don't have 100% trust, tell them which commit(s) did this and what does the code mean (if not easy to understand).

In reply to by Howard-C

There is a problem with this: not everyone knows how to read the source code, and even if they know, it is difficult to detect exactly where and what information is really sent. Even experienced programmers can fail detecting all that can be happening when a complex piece of software is running (otherwise there would be no bugs, ever!). Another concern would be the possibility of some "third party" malware attack which could take advantage of the existence of that socket --to call it some way-- to deviate information to an unknown destination.

As telemetry to better understand usage is legitimate, I can thank you to have open this post for each people can give it's ideas.
To open this thread broader, I have open an post in the French forum, so you will be able to collect more thinkings.
I will relay here the thinkings of French people who have dificulty to speak English.
The post in French is here :

In reply to by pskunt

Thanks for this post.
I think telemetry, even we can turn it off by choice, will give a bad impressive reputation, even the goal is acceptable.
Dont' forget the numerous instructors who conduct workshops all over the world and who know very well the way of final users, beginners or professional, use the software. A survey would be a good feedback IMHO.

It seems to me that the only way to find out how the software is used is to somehow track it. You could do a survey, but that seems hit an miss, to me. I have yet to use the Inspector, but I know it is useful. I use the keyboard for "undo", but I forget the short-cut for "redo". I undo a lot.
There are many things a survey could ask about that I might answer a certain way, forgetting that I really do something different in practice.
All we hear about on the forum is what people are having trouble with, and that's valuable. But we seldom hear about what they like, or use the most. Or even about some little thing that they wish was different but don't think important enough to mention. I use MuseScore to compose as a hobby. Arranging or things like that are of little interest to me. I am interested in playback and not so much being able to produce a score for real players. I suspect I am a minority. But MuseScore is becoming more appealing to me.
I have no problem with data on how I use MuseScore being collected.

Hello to all of you
First of all, I would like to greet MuseScore, who has the courage to put this idea on the table. Others, and among the most powerful, do not bother with such preliminary precautions: they install telemetry without saying it and by default. It is the temptation of the moment and no one escapes it.
It is for example very, very present in Windows 10 and if you want to avoid it you have to install special programs to counteract its effects.
But let's ask the question differently: Why do system manufacturers, program publishers need so much feedback? Quite simply to avoid disappearing, swept away by more informed and responsive competition. How many programs that we liked have disappeared because they have not kept pace with changing demands and technologies.
Let's admit that we are more and more demanding on performance, possibilities, options, settings, customization etc... etc...
We cannot ask developers to be always at the forefront and at the same time deny them the means to do so.
So that being said, here is my answer on the substance.
MuseScore is a program I use on a daily basis, and I greatly appreciate its capabilities, its free nature, its constant development and, finally, its very responsive community.
I am here in a climate of trustworthy and I would therefore accept, since it is also asked to me, that my behaviour on this program be observed and analyzed. The "yes" or "no" option being clearly visible and disengageable at my request.

In reply to by BSG

Sorry, but (and with the upmost respect) the idea that what Anatoly is proposing is spying is as ridiculous (and dangerous) as not hooking up Windows to the internet. As with any piece of equipment (Mac, PC, or Linux), or software, (MuseScore or Cubebase) you have to learn how to use it.

In reply to by bobjp

I've been programming computers, mainly professionally, for a half a century and know more than a little bit about operating systems (which I helped design), networks, and security, and "how to use computers". Why don't you tell me why keeping a single-application computer permanently offline makes it vulnerable to attack? If you prefer to be spied on, go for it. I don't, and apparently the designers of Debian don't either.

In reply to by BSG

Then you know there are more secure distros than Debian.
But again, I'm just not sure how collecting data on usage of aspects of a program is spying.

I assume you use a browser on your computer to post here.

In reply to by bobjp

I do, and it has queried me about whether I would tolerate its proposed invasion, and the answer was "no". Whether it's "spying" or not is up to the person being raided to determine, not the spy. A long time ago, I worked on mainframe time-sharing systems that had "metering". I even proposed and implemented some of it. But to me, "personal computer" means something different.

In reply to by BSG

Your comments are insightful… to say it with contemporary words, you rock! ☻

I’m not yet half a century old, but I’m more than my arms deep in the innards of operating systems often enough as well… might be nice to meet you at FOSDEM or so, if there weren’t the continental divide…

I have for many years wished we had that sort of data. It could help design better defaults for toolbars and other aspects of workspaces, but also help direct development (like, knowing the percentage of note input done by keybaord vs mouse could be an interesting stat). But of course, I also was sensitive to the idea that it wouldn't be very popular, plus I had no idea how to actually implement it anyhow.

So I think it's a good idea worth exploring, and I too am glad to see the open discussion of the topic, hopefully there will be some sort of consensus on the best way to make it happen without alienating users.

And as I think about it, I can also see value in some survey type questions.
Some of my thoughts would be about the reverb controls. Not enough documentation for my taste. As detailed as the reverb controls are (maybe too much control), I can't have different reverb (not just amounts) on different instruments. If there is, it's not in the manual.
Or how about making drum kits like any other instrument in the mixer and not something that pops up at the bottom of the screen. I know you guys that developed it understand it (again, mouse user, here), but it makes me not want to use drums.
Maybe using the mouse is slower (oh well), but there is more to it than speed. There is intent. Mouse input lets (or makes) me think about every note more. And again, I'm a composer not an arranger. So notes are not a given.

I may be paranoid, but...
When I hear the phrase 'telemetry in software' I immediately think 'keylogger' - which has (mostly) bad connotations wherever I read about it.

In reply to by Jm6stringer

And yet what better way for developers to stick to the demand and improve the program than by closely analyzing the behavior of users who agree to be watched for the benefit of the entire community?
There are two parts here, developers and users. Each party should try to integrate into its reasoning the other party's questions. This is the best way to move forward, especially when you are in a climate of mutual confidence. Which is my case with the MuseScore team....

In reply to by Papibois

There is no question that having 1984-type cameras and microphones in every dwelling would be extremely valuable, and prevent a lot of crimes. Then there is the other side. No, command usage telemetry is not Big Brother cameras, but the feelings and options of those whose activity is being monitored and reported is part of that difference.

Telemetry implementation has just been merged to master branch: Everyone is welcome to audit the code.

Telemetry module is switched off for developer/nightly builds.

@mirabilos "BUILD_TELEMETRY_MODULE" CMake variable is responsible for adding the Telemetry library. It is "OFF" by default and is going to be "ON" in release builds. You can either switch it off in Debian packages or remove the code introduced in the PR mentioned above.

After reading through the comments, I'm not so gung-ho with the potential effectiveness of telemetrical activity. The time required to 'analyze' user-data got by live connections from people who 'come and go' could potentially be -- instead of looking at statistics without knowledge as to stature of the user -- spent moreso on examining user comments, expectations, requests and their implementations or what have you (if the same people are programmers), and participating in bug fixes.

The people who find anything awkward about M.S. or think something particular ought to be changed, in theory, will involve themselves in discussion at the forums. It often takes quite some time before a person can become familiar enough with something like MuseScore before one can conceive of a 'better way' of an implementation or interfacing. To speak of gathering data without the judgments of 'better' and 'good' but merely as a statistical analysis of usage requiring those capable of such judgments to spend time on this rather than other said activities when it's known that notation and the software related to it isn't something that comes easily seems to miss the mark 'imho', but best of luck to those making these decisions. Whatever's best for MuseScore and its users.

In reply to by worldwideweary

OTOH, often someone on the forum is unable to describe what went wrong, how they ended up where they did, or whether what they did actually caused the problem. Users are not programmers. While programmers are users, they write things to be used a certain way. Users find the darnedest ways to cross things up, from keystroke combinations to system configurations.

In reply to by worldwideweary

Telemetry isn't a replacement for feedback, it's an additional tool that helps developers and designers make decisions. For example, one of the most common bits of feedback we get is 'MuseScore is too complicated'. Moreover, users don't (and can't reasonably be expected) to provide precise examples what they consider to be complicated and what they consider to be straight-forward on a button-by-button basis. We can definitely employ strategies to combat this type of issue, but without more information, guesswork and intuition are all we have to go on. And since users also rarely tell us when something is working as expected, we run the risk of hiding something important or promoting something relatively unimportant. Telemetry can tell us about all the parts of the app that people take for granted and don't comment on, which helps redesign work to be as painless as possible.

In reply to by Tantacrul

If this implementation is to be continued, I'm then curious or looking forward to see what specifically is the "fruit" of paying attention to user activity from within the program. Hopefully those who are going to be spending time looking at that data will be transparent and manifest their decision making processes and influences based upon whatever that is rather than merely give vague statements about "being able to make appropriate decisions".

In reply to by Tantacrul

The method by which changes would be implemented based on user-interaction data with the program is by its very essence vague to someone such as myself as it currently is stated due to not knowing exactly what is inspected and what methods will be used for correlating intention and priority with the data. As is supposedly the case, many people come and go with software, and to speak of priorities based on use case of recurrency may give a false impression. For example, I rarely if ever use the more buttons in the palette area because my palettes are set up usually the way I want, but that doesn't mean the more buttons ought to not exist. Not only this, but on my machine, the palette search function when deleting all its text suffers speed slowdowns, whereas an earlier version of my particular machine had no speed issues, but this problem won't be recognized by merely pulling statistical data from something like this. I might, as a new user, if I encountered this, get iffy and quit without mentioning it on forums. The statistics would give no indication as to what happened 'mentally' for the user, nor would the user's interaction-data provide appropriate information to accurately correlate excellence with priority.

Maybe it's not vague and I'm merely being wishy-washy. Maybe you guys could program something that manifested the exact data that was captured for analysis of the user in a local data file or something? That might help the skeptics be reassured if they could see what exactly was gathered, and not only this, but also, if this continues, again, declare openly what decisions are being made based on what data. If those two were fulfilled faithfully, then the main concern would shift over to the extra computing activity required for the data capturing/sending.

In reply to by worldwideweary

I don't really understand this stance (and I dislike the idea of invasive data exfiltration intensely). Assuming that users understand what data is being collected, how it is used, and why (the general terms of privacy legislation), and actively agree to it (or opt out) it seems that the issue ends there. Saying "I would be concerned if you used this data to remove, or make less accessible, some commands that I like" seems to me inappropriate, and the sole prerogative of the designers/implementors (a team which, in this case of open source software, you are free to join). Response to design/change proposals, or response to implemented changes ("Bring back the album feature!") are highly appropriate, but, as far as I can tell, not "I don't like the idea of your collecting data which might result in design changes i don't like." Just my "two cents" (fiftieth of a semitone). I repeat, I'm in the < 1% of users to whom figured bass is central, but I've been promised it won't go away for lack of use. Leaving aside the very substantial issues of privacy, trust, and reputation, knowledge and data cannot be a bad thing.

In reply to by BSG

No. One thing I am saying, in a sense, is that this data and its interpretations should be transparent and open to the community of "MuseScore" and to its users. This place has conversations about what should and should not be implemented with manifestations of support regarding feature requests and changes in general. Why not lift the burden of making these decisions slightly away from only a particular set of people and provide the community, many of whom like to give their support and lacks thereof, with participation related to this process? Of course, not everyone gives functional reasons for their wants, so that might muddy it up a bit.

Of course, to not trust in another's competence would require a blanket statement or a more intimate knowledge of the ... team :)

In reply to by worldwideweary

Try "responsibility of making these decisions" instead of "burden". Open source does not equal democracy. People who understand the product, its past, its implementation, and have the requisite experience in software engineering "make these decisions". The developers are not a cabal of brigands and rogues who have stolen power over the product from "the people" (pardon my hyperbole; maybe an elliptical parable would be less circular). I sense you feel that the power of developers to develop is élitist and insufficiently legitimate. Open source does not equal democracy, and (in my opinion), rightly so.

I'd like Marc to weigh in.

In reply to by BSG

The power to develop and appropriately harness language melded with functionality in particular systems and the ability to interpret user activity seems to be two separate areas of activity, albeit not entirely distinct. "Those who can, do. Those who can't..." or something like that. I don't necessarily equate power with legitimacy, but I have no negative feelings about developers who have abilities to implement and synthesize functionality. Far from it. I am curious, however, as to the importance of user-data and how the team would interpret this data knowing the larger possibility of its not being bound up with well-informed intentions.

One of the main points here is the desire for full disclosure of the information, or rather data, that is being "seen" by other people, so that the user who is "being watched" knows full well what has been collected. The user should be aware of that information if he should so want it. Either way, the results will speak for themselves in the sense that updates and new versions will indicate what was decided upon, and those in turn will trigger some desire to make forum posts involving user-input for further design/implementation changes so that the vicious cycle may continue >:D

In reply to by worldwideweary

How do you feel about the .com site, whose maintainers do not share their source, their methodology, their forthcoming designs, etc., and surely meter every activity that goes on? Or Amazon, Google, Apple, etc. doing the same? Why do the implementors of musescore have a special responsibility to share the results of their tools? (Again, assuming consenting users; we are not discussing the privacy issues here).

Why do you suspect "not being bound up with well-informed intentions"? It certainly sounds like lack of trust underlies this. You just said that you do not trust a priori that the developers are competent to interpret the data resulting from such instrumentation, or use it as an input to design. Or maybe you believe in principle that such data has no place as design input to any development process (that position is extreme, but defensible).

In reply to by BSG

I'm not concerned much with the .com site, so I have no feeling about it currently. It's merely my opinion that those in relation to this project should share what specific data is observed with those who may want this information. If this equates to "special responsibility" to you, I'm flattered that my should is contrived as such.

The phrase "not being bound up with well-informed intentions" was rather in reference to the users themselves, specifically new users not making well informed decisions within MuseScore, potentially 'muddying up' the data.

In reply to by Tantacrul

To use a software you need to work on it and specialize in it.
For example, if someone tells you that Ph0t0sh0p is too complex, you can't convert it into that can be used by elementary school children, can you?

The company should not make the mistake of removing important features (some Toolbar items, Concert-Pitch, etc) based on the abundance of transactions performed by beginners.
Because the operations that are frequently used by normal or expert users will be less than these. And beginners will use them after mastering.

I hope this telemetry feature doesn't cause MuseScore to be labeled as u n w a n t e d software by some operating systems and virus-scanners. As I stated in my first message: I hope this telemetry feature does not cause MuseScore to be labeled as unwanted software by some operating systems and virus-scanners. As I mentioned in my first message: If a rumor spreads among people, there is almost no way to fix it.

In reply to by Ziya Mete Demircan

I don't think you've read the proposal properly or understand what telemetry is. In my professional career, I've never worked on an app that doesn't collect some kind of information (eg. how many times does the app crash; How many times in a session does the user click on a particular button, etc.) The proposal made it clear that this information being collected is not personal data. It's anonymous. But you seem to be confusing it Facebook-style harvesting of personal information for some reason.

The suggestion that this makes MuseScore a virus is ridiculous. Just about every app you use (and the OS themselves) collect some kind of telemetry. Moreover, the proposal made it clear that people are going to be given the choice to OPT-IN - a courtesy most other apps don't bother with.

In reply to by Tantacrul

I try to prevent the software and OS that I use from sending data in many ways. I am also using "OOSU", and I block most software's Internet access from the firewall.
I don't even allow a crash report to be sent to M1crosoft. If I have a problem, I will use the M1crosoft support channel (forum).

I read Proposal and got it. I have no problem with that.

I wrote my comments on the UI according to this and the following sentence in the quote.

  • However, there are a lot of other things we want to understand. For example, we currently populate a significant portion of our top bar with the following buttons: New, Open, Save, Save to Cloud, Print, Undo, Redo, Zoom Controls & 'Concert Pitch'. What we don't know is the percentage of our audience who use these buttons instead of the file menu or shortcuts. Tantacrul: "From my previous experience in designing Paint 3D at Microsoft, I wouldn't expect that to be the case here." However, we have a suspicion that can be used to make a lot of day-to-day use.

  • "We are now looking into systems that will allow us to track how people interact with Musescore without collecting any personal information" *

As for the possibility of rumors and unwanted software: I have stated that I have thoughts about what might happen.

My writing is very positive. And I know I'm right in my warnings. You just need to understand and evaluate in your mind, You don't have to be agree with.

(Apologies about the length.)

What kind of data you collect is the most important decision point in this question.

As a corollary, please treat the list of data you collect as the most important part of the decision.

So please do not have "etc." in that list, and do not just casually list items.

Instead, list each collected data element/item separately, and give clear description to them. A title of a few words, and a sentence or two describing the data exactly, and an explanation of how/why it will be useful down the road for making decisions. Please make these titles and descriptions easy to understand (happy to help). Please allow each of these items to be enabled/disabled separately. When new items are added in future releases, please add new permission items for them, and ask permission for those (while also allowing changing previous permissions).

Please consider an opt-in feature, where developers can reach out to me individually if they have a targeted question to a small subset of users based on telemetry. This could be either a checkbox of something like "allow developers to contact me if they have a question", and then I could enter my email address, and then if a rare to reproduce bug happens and I happen to be one user who can reproduce it, I can be contacted and involved in the process by developers, for the benefit of the community.

Please allow postponing the decision (e.g. "I am considering, please remind me in [___] days"), in which case no (new) telemetry items should be enabled by default until the user decides otherwise, and the user is shown the dialog again after the time they requested elapsed (except if in the meantime the user has gone into telemetry settings in preferences and changed some settings).

I would also suggest features towards capturing the "here and now" moment of the session, to help reproducibility: I have an issue, I want a button or menu item I could use that somehow captures my experience, and relays it to developers. During this process I want to be able to opt in - from a list of checkboxes on the screen with detailed descriptions - to providing as much or as little data, as I feel comfortable with. To save the reoccuring support questions of "what OS? exactly what version of MS (commit)? what is your configuration of X option in MS preferences?", "can you provide a score?", etc. Allow me to take screen shots or capture a short video, demonstrating the problem. This could then channel into automatically opening a bug report on the proper forum, or produce a kind of "dump" file locally on my computer than I can then manually submit in a bug report and gets automatically processed. Kinda like the current "feedback" button on proteins.

Also, a textual search bar/field at a prominent place would be nice, ideally a kind of "answer to all": searching among all menu items/commands, dialog items, setting names, etc. (enriched with synonyms - see below), as well as a locally installed reference or tutorial material. For the case I did not find what I needed, provide an option among the search results ("I did not find what I was looking for, please forward my search to musescore developers"). If enabled in the privacy settings, please allow the option of search for X online - which would search in in manuals, forum posts, etc. and it also would capture my search term/question in a central database at (Or perhaps these two could be unified into the same use case.) This database can be reviewed by developers later to understand what features, terminology/labelling, use cases, etc. users tend to have issues with, and provide an organic use of oft-used synonyms to add to search. Even more pipe dream is: allow me to see a list of my issues/questions I submitted through this, so that if/when I found solutions for those, I can feed the solutions back to go together with my question, crowd-sourcing building up a knowledge base/reference manual. After some curation these could in turn be added to the local documentation, for the search function to find.

"Private mode" (half-baked ideas): if I have telemetry enabled, allow me to turn it quickly off when I don't want it, and back on when I want it. Maybe a button on the toolbar? But what if I forget to turn in back on? Maybe an option so that I can choose to "ask me each time" (e.g. each MuseScore session starts with the question again, whether to enable telemetry for that session). Or make it per document or window. Or any number of permutations of these.

In reply to by bobjp

That's not the sort of thing the telemetry info is intended or designed for, though. It's more about getting aggregate data on what sorts of actions people do, not getting a blow-by-blow analysis of some particular problem with the sort of detail that would be needed to enable developers to reproduce a bug.

Hello! I am an arranger and music editor for publishing, digital, and printing. I moved to Musescore from Sibelius some years ago. I wonder if aside from telemetry or instead of it, wouldn't it be a good thing to adopt pro-workflows and to use workspaces suitable for specific tasks or letting you arrange and save workspaces, with a UI that lets you move the element and stack them into palettes... Like a worspace when writing for guitar which has it owns challenges, or sequencing, midi cleanup, or choir arrangement... etc. Professional composers or Music Publishing experts would give better insights than in many cases, non-pros, clicking here or there going nowhere and giving unclear statistics to the telemetry system. Just my opinion.

In reply to by jeetee

Yes, I did/I am. Sorry I didn't make myself clear enough. I meant, a flexible enough UI to enhance UX... on the style of the Adobe products, i.ex: Adobe InDesign. Maybe it is possible to get something similar inside Musescore but I haven't found it. Also having to open a window to organize UI elements doesn't seem as efficient as having a "live mode" where you could reposition the elements, undock the palettes, not within the main palette but as a separate element. That way you could get more satisfying workspaces, I am going here for a live redesign of the interface for specific tasks and not merely putting the buttons you use the most more visible. Also, factory presets for workspaces just like Blender. As a graphic designer myself, I am after what I consider would make the software easy to understand and customize. Makes sense? This is only a wish list, I am pretty happy with this amazing software, sadly I am not QML proficient enough to contribute with the software myself :-(

Im in the camp that telemetry is an invasion and unnecessary at that. I don't want to have to start looking for another notation program, but I will if this is going to be the path MS follows.

In reply to by Papibois

And how many times now has Facebook, Google, Microsoft (and who knows what other companies and organizations) have said, "Oh, we won't collect data if you don't want us to," and, lo and behold, it comes out that that was a lie.

Now look, I'm not saying you folks at MS would or are doing anything wrong. What I am saying is that there's already enough telemetry going on and we don't need anymore. It's really not that hard to find other ways other than having MS phone home with what 99.9% of us would never be able to verify by checking the "open source" reference to see what's being sent.

Just produce notation software, ask question, do videos, etc., but leave the intimate connection of what I do out of it. That's all I'm saying. And finally, the option to not send information is, as I've noted, not a trustworthy offer anymore these days. Again, that's not to accuse MS of any wrong-doing. Just stay away from telemetry is what I'm saying.

In reply to by BSG

I don't understand this suggestion that the MuseScore team are generally not trustworthy. This was presented to the community before it was implemented and it can be verified by anyone. Because it's an open source project, any abuse would be exposed immediately.

There's no pathway to evil here.

In reply to by Starkman

Ultimately, you have to trust software that runs on your machine, and reputation and web-lore and the use of packet tracers etc. has everything do with with that. When an vendor announces,, "we're going to have some Send Back to Mother Ship", that trust erodes, no matter what policy is announced with it.

In reply to by Starkman

It's OK that you don't know how, the beauty of open source isn't that you personally can do things with it, but that plenty of other people can and do. By your logic, no one else should have to develop MuseScore either, and yet, we do. If there were not a dedicated group of volunteers constantly examining and improving the software, it wouldn't exist. So I think you can safely forget the possibility that somehow the 100+ people who work on the software would somehow collectively decide none of us we care about privacy at all and just stand by idly if an actual invasion of privacy were to be proposed or implemented.

In reply to by Starkman

Starkman, it seems your concerns have been answered comprehensively and I think the explanations are more than reasonable.

If you opt in, MuseScore does not collect personal info, so there's nothing 'intimate' being turned over. Any developer can right now check the code and verify this for you. If you think this explanation is a lie, then that would make for quite an exposé story, don't you think? How dumb would it be to lie about this when so many people can immediately fact check it?

To reiterate the facts:

All users are presented with a clear set of options that allow them to opt in or opt out. MuseScore does not auto-opt in.

If you choose to opt out, no telemetry will be collected at all.

Can't really see any reason to be angry about this.

In reply to by Tantacrul

Really? No, I haven't been unreasonable, and neither has anyone else here objecting to the use of telemetry. And no, I have not been unwilling to consider the explanations given. I just don't find them compelling, and neither do others here.

I expressed, as several have, my concerned (and objections) to any kind of telemetry. I apologized for my harsh statement about looking elsewhere for notation software. I used organizations that have lied in regard to their use of telemetry—expressing that regardless of the open source availability of MS, I have no knowledge how to verify any telemetry sent to MS; just avoid using it, period is my point. Further, I did not accuse MS of abuse or any wrong doing. As to "intimate" information being sent to MS, the information MS collects IS intimate—however, I said nothing about personal information being sent. As to the information that would be sent, it would be very intimate in the context I'm using the word or it would be of no use to MS.

Finally, the option to opt of enabling telemetry out misses the point: stay away from the practice, period, is the point. As I noted, there are other ways (e.g., snapshots, video recording, etc.,) to garner information for enhancing MS.

So, if that isn't "soberly" engaging the issue, then pray what is?

In reply to by Starkman

Surveys, focus group testing, and what-not are useful, and we do those also. But they end up being pretty skewed, as you can't really collect nearly as much breadth or volume of data. Those methods are mostly useful for confirming specific existing hypotheses, not providing a database of information that can be used to answer questions we haven't even necessarily formed yet. There is no other known way to collect the sort of information really needed to learn the really interesting and useful things we'd really love to learn in order to improve the software in the way we'd like. So that's the question - is your personal squeamishness worth limiting our ability to improve the software for everyone?

BTW, not sure what you think is "intimate" about knowing which button you pressed, but fine, if that's intimate you, don't opt in. That simple. Fortunately, I have little doubt that lots of other people who aren't able to help with actual development will be willing to at least help us out in this small way.

In reply to by Marc Sabatella

Marc, you're a professional musician and composer, and I trust others working on MS are as well. Surely, you and the other developers have a clue as to how a piece of notation software should work, should act, should respond, and intuitively so. The forums have expressed well what people want and what they don't want. MS just hired a fellow (per your recent Cafe video) to take MS even further. Is it really necessary, then, to delve into the arena of telemetry? If you can't get it right based on what you know, then all the telemetry in the world isn't going to help. You already know, well, from what's already been said and observed, what musicians want in a notation software. How about looking at other software to see what they're doing and encorporating what you like into MS?

On the other hand, it's virtually impossible anymore to stop the move into data collecting all the way around. So, really, it's moot to object to the use of telemetry—the opt-out being irrelevant half the time. I just see no need to get to up-close-and-personal with MS software.

In reply to by Starkman

I have my ideas, the few dozen other developers have theirs, the couple of people working on design have theirs. But this is a statistically insignificant data set. It's relying too much on what a few insiders think that leads to interfaces that are hard for beginners to figure out. Forums tell us about the people who are sufficiently engaged with the product to create an account etc. They don't tell us anything about the people who downloaded the software, played with it for 15 minutes, couldn't get anywhere, and deleted it.

Again, no, of course, telemetry data isn't necessary. Improving MuseScore is not necessary. MuseScore is not necessary. Computers aren't necessary. Music isn't necessary. But if you think telemetry data it isn't valuable, then I can only guess you have no experience in software design on this scale. I'll make you a deal, though: I won't try to tell you what might be valuable for you in your life, and you don't try to me what's valuable to me in mine.

I have no idea what you mean about it being impossible to opt out, though. It's as easy as pressing one button, I promise. And it's more than a little insulting to have people accusing us of doing anything but exactly what we say we are doing. Again, I'll make you a deal: don't question our motives or integrity, and I won't question yours.

In reply to by Marc Sabatella

Marc, sir.
Apologies if you thought, in the least, that I was insulting, questioning MS integrity or anything like that. I've said, more than a few times, my issue is not a distrust with MS, leaked data, this, that or the other. My issue is with telemetry in general: I believe that only in very few circumstances should it be used.

My point with regard to not being able to opt out was not with regard to MS but just the whole technological movement of computers in general; one can't get away from telemetry, often even when opting out. Though now, after re-reading my post, I can see how such a statement could have been interpreted as a direct attack against MS, but it wasn't, not at all! I have full faith in MS. It was just a generic, "Oh well, maybe I should just let it (the issue of telemetry) go and be done with it, because it's here and that's that."

Finally, I FULLY respect everyone's right to their opinion about this issue. In the rush of time, my posts, however, have seemingly implied otherwise, which is not the case at all. And though I will choose to opt out of the telemetry feature, I will always be willing to help out by offering suggestions, participating in the Cafe videos contributing to the forums, and what have you (once I get through your course again!), and I look forward to doing so.

Thanks very much.

In reply to by Starkman

Fair enough. But I'm curious - you say you believe that telemetry should be used "only in very few circumstances" - what would those circumstances be, if "improving the usability of the software in ways that benefit all users" is not one of them? To me that is exactly the circumstance in which it should be used.

I can't speak to "the whole technological movement of computers in general". But I will say it's unfair to blame MuseScore for what anyone else does. Let's keep this focused on the actual implementation in MuseScore, not something else it reminds you of in some other application, website, or other unrelated business. So, I can't help you with Facebook issues. But I can say that if it pleases you to not provide this data to MuseScore, then don't opt in, and the data will not be provided, period.

In reply to by Marc Sabatella


You said, “But I will say it's unfair to blame MuseScore for what anyone else does.” Never have I blamed MuseScore for anything or for what anyone else does. (I don’t even know how I could blame MuseScore in those ways.) Sorry you thought that.

As to times when telemetry is important:
* Software for home security: alarm, camera and other information can (selectively) be sent to the software company in order to alert the home owner of a (potential) dangerous intrusion.
* Software for reporting unauthorized use of one’s vehicle.
* Software that monitors and reports to a company one’s (various) health status.
* Software for monitoring a child’s use of his/her cell phone.
* Location software for tracking hikers, boaters, etc.
* Open source operating systems that receive crash reports and other selective information that can be verified by the community as keeping in check with what should be phoned home. (Microsoft uses telemetry and still there’s no way to know exactly what they are receiving, and they aren’t up front with any information about it.)
I could go on, but I hope this is enough to convey my thoughts about when it’s important to have information phoned home.

As to MuseScore, how much can the developers possibly know by the fact that I typed a quarter note, clicked a clef, added an articulation, opened and then closed the Inspector, the palette box or what have you? If I like inputting my notes by clicking, that doesn’t tell you anything except that I’m inputting by clicking. You can’t assume a reason why. If I don’t use the Inspector, you don’t know if it’s because I don’t like it, don’t understand it, or simply prefer another way to access the information.

On the forums, when it comes to problems that are difficult for a user to explain, one of the first thing people responding do is ask to have the user post a snapshot of the issue. I would contend, thus, that if Musescore developers can’t see my score and how I’m creating it and dealing with difficulties of using it, they sure can’t figure out what I’m doing wrong or what is not working correctly or why, for that matter, I’m doing what I’m doing. (To see my scores, be they simple as they may be, is out of the question, in my opinion, on principle.)

Better, in my opinion, would it be to just run some polls in the forums or on your videos: “Say, do you use the Inspector? Do you type or click your notes? Etc.? Send out a monthly email tip, add a 10-15 second video recording ability within MuseScore that will allow users to record exactly what they are doing so you can see the issue first hand.

The development of the program is far enough along now that it’s really only tweaking and adding features here and there. How users face off with MuseScore isn’t going to be solved by telemetry; again, something I think should just be avoided out of principle, in my opinion.

In reply to by Starkman

OK, you are defining telemetry a bit differently, obviously the data essential to the operation of a remote service needs to be sent by any app using that service. Telemetry in this context is more about usage data.

Anyhow, I get that you are not a software developer and are having trouble understanding how valuable this information actually is. So, I offer you another deal: I won't try to tell you what information is valuable to you in your job, and you don't try to tell me what information is valuable to me in mine.

As I've said, polls are useful too, but in a much different way, they don't provide nearly the sort of breadth of information. So here's another deal: don't tell me that X can substitute for Y in my job, and I will extend the same courtesy to you.

In reply to by Starkman

I would almost go so far as to say that surveys and the like are almost useless.

Here is what I see on the forum quite often. Someone has a problem. Something doesn't work. They post a picture and even a score. Someone tries the score and has no problem with it. There are many possibilities. Is the user not doing something properly? Is there something not right with their computer? The user has no idea. I followed one thread where the user couldn't get MuseScore to install no matter what he tried. This went on for a week. Turns out he was trying to install it to the desktop. This question might have been answered much sooner with the right data.
Sure, often the answer is in the manual. Not always. Sure MuseScore is coming along nicely. No software is ever perfect or really finished.Because it is open source and has an ongoing team working on it, I think uses need to give them all the help they need to make a better product. We live in an age where when people see something on the internet, then it must be free. MuseScore actually is free. I think we all need to do our part to make it the best notation software out there. Opt in or opt out, I don't care. Neither should anyone else. Let's get on with it. I'm happy to opt in. Maybe the Russians will be bored to tears with how many "un-do's" I do. I'm sure they already are.

In reply to by Starkman

Sorry, but you are comparing apples with giraffes. These are totally different types of data collection to Facebook/Google/Microsoft.

MuseScore does not have access to your phone number, location, home town, education, current job, photos, status updates, lists of friends, relationship status, sexual preferences, personal interests, or any other personal information. Not anything even remotely close. It even explicitly states this in the proposed dialog:

"We _do_not_ track personal data or sensitive information, such as location, source code, file names or music."

Here we are talking about things like how often you use the Undo button vs. the Edit Undo menu option vs. Control+Z, or how often your MuseScore crashes. Are you seriously saying that you are worried about this kind of data leaking? Even if you are, let's consider these two hugely unlikely scenarios:

a) The MuseScore developers deliberately decide to break their promise to keep the data anonymous.
b) The MuseScore developers or people hosting the telemetry database screw up and it gets hacked and the data leaks.

Firstly, there is zero upside / motivation for the developers to do a). There is only risk of damaging the credibility of the project if they got found out, and it would be extremely likely they would get found out because the source code is open for anyone to review. So I defy anyone to suggest a good reason why this would happen.

b) is (relatively) more likely since people do make honest mistakes, but it's still a very remote risk, because the leaked data would be utterly useless to anyone other than the developers. Noone else cares about this data! Not even the Dorico developers would care how often MuseScore users hit the Undo icon vs. Control+Z.

So this is worlds apart from the data Facebook/Google/Microsoft hold, which are goldmines of highly sensitive and potentially very damaging personal data. I'll happily agree that it's a risk trusting those big data giants with your personal data, but please don't have a knee-jerk reaction which prevents honest open source projects from progressing by politely asking users if they can collect some totally harmless non-personal data.

Telemetry is a great idea for MuseScore, and given how clearly and respectfully it has been implemented, I fully support it. Thanks and kudos to Anatoly-os, Tantacrul, and all the developers - keep up the great work, and I look forward to seeing the UI improve even further as a result!

In reply to by adam.spiers

Please, just stick to the issue that we who object to telemetry are raising: the use of telemetry, period, is, in our opinion, unnecessary and a step in the wrong direction. You are confusing the the matter of what data is sent verses data, period, being sent.

You said, "Here we are talking about things like how often you use the Undo button vs. the Edit Undo menu option vs. Control+Z, or how often your MuseScore crashes. Are you seriously saying that you are worried about this kind of data leaking?"

First, it's unncessary for MS to collect this data. Just make the software, interact with people on forums, videos, etc., to enhance the product.

Second, I don't like the idea of it even being suggested that MS can collect how often I use the Undo button vs. the Edit Undo menu option vs. Control+Z, etc. (And, again, opting out, in my opinion, misses the point.)

As to the matter of leaking information and what have you: irrelevant. I never brought that up. I simply don't like the idea of what I'm doing even potentially being broadcasted.

In reply to by Starkman

I think people have come to expect that local apps are their property once purchased or licensed, and work for them and them alone. There is a reason SOME people use local applications as opposed to web applications for SOME things. People, certainly I, am of the expectation that I can run an app locally and nothing about my activity at all, repeat, nothing about my activity at all is being reported to anyone. I think that's part of the local-app vs web distinction that people have come to expect, and ought be a bright red line. Yes, I can spell "opt out".

In reply to by BSG

I would say there are many reasons why any given person might choose a local app. Concerns about transmission of data are probably about 57th on the list overall. Also, not sure why anyone would "expect" local apps to not transmit any information when pretty clearly, a very large number of them do. So seeing a dialog asking about this should hardly come as any sort of surprise., Are these people also surprised every morning when their toast is crunchy?

But again, if you don't want to help us, that's fine, just don't opt in.

In reply to by Starkman

Of course it's not necessary. Nothing is necessary except to eat and breathe. MuseScore itself isn't necessary, new features or design improvements aren't necessary. But I think most people agree that MuseScore is valuable, and having new version with new improvements is valuable too. Similarly, it's extremely valuable to developers to have the sort of data that will allow us to better improve the software. Not having it will continue to limit us to only being able to collect that small and skewed amount of data that can be collected through other means.

So again, if you don't want us to provide us with the sort information that can help us better improve the software, fine, don't opt in. I have confidence that plenty of other people will pick up the slack and help us help you and everyone else by providing us with information that can enable us to better decisions on how to best improve the software. So you'll benefit whether you participate or not.

I suppose we could consider making some new improvements only available to the people who opted in and helped provide the data that guided the development (just kidding!!!!!!)

In reply to by Starkman

"Please, just stick to the issue that we who object to telemetry are raising: the use of telemetry, period, is, in our opinion, unnecessary and a step in the wrong direction."

In your opinion - that's the key bit. There are users (like myself) and developers who hold a very different opinion, therefore the only sensible solution is to allow people to choose individually. And that's exactly what they've done.

"First, it's unncessary for MS to collect this data."

It's not "necessary" to improve MuseScore either, but that doesn't mean it's a bad idea to do so. The rationale has been explained very clearly in the original post, so I don't think this claim holds any water unless you can suggest a better way of achieving the same results. Your suggestion was "Just make the software, interact with people on forums, videos, etc., to enhance the product." but gathering this data manually would be far less effective / efficient and would waste precious developer time.

"Second, I don't like the idea of it even being suggested that MS can collect how often I use the Undo button vs. the Edit Undo menu option vs. Control+Z, etc."

Why not? What are you worried about, really?

"(And, again, opting out, in my opinion, misses the point.)"

What point does it miss? I totally respect your decision to opt out of any data collection. So please respect my decision to gladly share my usage data with the developers so that they can make MuseScore even better.

"As to the matter of leaking information and what have you: irrelevant. I never brought that up. I simply don't like the idea of what I'm doing even potentially being broadcasted."

So just opt out. There is no need to try and enforce your personal position on everyone else.

In reply to by Papibois

No, I wouldn't run off and look for other software. I was just a bit upset when I wrote the initial post. I love MS and suppor it. I do NOT however, support any idea, whatsoever, of telemetry. So, forigive me, please, for being a bit harsh.

In reply to by Starkman

My final thoughts and post on this subject.

Somehow, when replying to a post (from my email), the post doesn't seem to go where I thought it would (in response to someone else's post), and when I come to this sight to see the posts, I can't find the post that was sent to my email, so if I've caused confusion, or my posts don't make sense (for lack of reference to the original), I'm sorry about that. Not sure what happened.

As to the telemetry issue, I've stated my thoughts: completely unnecessary for notation software development. But never have I meant to accuse MS of wrong-doing or of any mal-intentions. Not at all.
So, I'm finished.

In reply to by Starkman

So, here’s the thing. A bunch of brilliant coders get together and write an open source program. It works great for them. They know computers inside and out. Their computers run better than most of ours. The program they write works just the way they want on their computers. So, they put it out into the world. Sure enough, right away they start to hear about problems some folks have with it. These folks, bless their hearts, have no idea what went wrong and don’t know how to find out or describe just what happened. There are just about as many setups out there as people using them. Developers can’t rely on users to describe what went wrong because the user doesn’t know.
There are problems like this with software as well as OS’s. Just ask any number of people trying to figure out Catalina. And if you think Apple isn’t collecting and selling your data, think again. They don’t need to sell it to as many vendors because Apple already sells devices for three times as much as anyone else. They are fine computers, don’t get me wrong. But I digress.
I don’t understand what part of “don’t opt in” is so hard to understand. “I don’t like it”? “It’s not needed”? Really? If you go on the internet, your privacy is already shot. If someone wants your data, they probably already have it despite what you do. You must be smart, of course. But hackers break into government computers every day. What chance have we got.
I have no problem with MuseScore collecting data about how I use it.

Question for the team:
Will the people who spend their time analyzing other peoples' usage data be sharing the results explicitly as relates to what directly influences design changes or other activities based on that handling of data with version upgrades and/or message updates in the forums, or will this be a sort of passive-influence without recognition as to the direct influences? Thanks.

In reply to by worldwideweary

I like questions including OR statement. The answer is Yes :) Yes to the first part of the statement. Design decisions based on the data will be shared. Btw, almost all design decisions are based on some sort of data. For example, recent single click improvements are based on user testing activities. We are not allowed to share details of that interviews due to different personal data protection laws. Meanwhile, we will share as much info and insights as we can.

Do you still have an unanswered question? Please log in first to post your question.