I was ask to provide more info about the crash dump server. It is called Socorro:
https://github.com/mozilla-services/socorro <https://github.com/mozilla-services/socorro> Like you can see it was developed originally for Firefox: https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=58.0.2 <https://github.com/mozilla-services/socorro> There are many statistics about crashes and the stack trace which is very helpful for the developer to prioritize bug reports and fix crashes. We already have client support for that in Qt Creator but we need a server instance where we can send the crash dumps. ________________________________ From: Development <development-bounces+marco.bubke=qt...@qt-project.org> on behalf of Marco Bubke <marco.bu...@qt.io> Sent: Monday, February 26, 2018 6:29:22 PM To: Edward Welbourne; Robert Loehning; André Pönitz Cc: development@qt-project.org; Ryein Goddard; qt-crea...@qt-project.org Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Edward Welbourne: > When you look into the feature that no-one uses much, you may find that most > users > that do use it have a crash report following close on the heels of their > use of it; you can make an educated guess at why they don't use it after that. We have already a crash reporter, which would provide us with that information. I am pushing this since some time but we need a server installation. Sorry, with my current experience I don't think that we need something much more complicated and fuzzy if we don't get something simple like a crash handler working. And I only speak about a customization of an already existing server and setting up the VM. I have that done very long ago but nobody stepped in to productise it. So I don't believe that we can fly to the stars if we cannot fly to the moon, but it is much easier to dream about the stars than to go to the moon. 😉 ________________________________ From: Development <development-bounces+marco.bubke=qt...@qt-project.org> on behalf of Edward Welbourne <edward.welbou...@qt.io> Sent: Monday, February 26, 2018 6:06:08 PM To: Robert Loehning; André Pönitz Cc: development@qt-project.org; qt-crea...@qt-project.org; Ryein Goddard Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator Am 23.02.2018 um 11:54 schrieb Edward Welbourne: >> The proposed system provides anonymised and presumably aggregated >> data; so you won't be given, much less asked to evaluate, information >> about a specific user A doing things at a specific time B; your >> objection is a straw man. You'd be getting data on what proportion >> of users spend what proportions of their time doing which things. In >> particular, knowing which bugs bite most users most often might not >> be entirely useless when it comes to prioritising which bug to fix >> first. Robert Loehning (23 February 2018 15:59) > If many users spend much time doing a "thing", does that mean that > this is most important to them? Or that it is most fun to do? Or does > it just mean that the design is so bad that they lose lots of time > there and can't use it efficiently? You don't necessarily know - but you do at least know it sees a lot of use, as distinct from the things that no-one uses. That, in turn, might be because the thing doesn't work, or is too confusing; or it might mean it does a thing no-one feels any need to do. However, you have now separated two classes of feature from one another: you won't waste time asking users why they never use the heavily-used feature; and you won't assume that users know how to use the feature you know none of them use. You'll have more information along with just "what proportion use which features what proportions of the time"; some of this may help you to distinguish between the various possible explanations. When you look into the feature that no-one uses much, you may find that most users that do use it have a crash report following close on the heels of their use of it; you can make an educated guess at why they don't use it after that. For another feature, users may methodically work their way through the steps your tutoral for the feature outlined and never touch it again; it's probagly useless. You won't be throwing away your other ways of getting information from users; you can ask them, in all the usual ways, what they like best and what ticks them off about each feature. That's quite likely to distinguish, among the ones that are commonly used, the ones that are fun from the ones that are time-consuming pain points. Data on how your users use your product can contribute to your understanding of what questions to ask your users and what work to prioritise. Like all data, of course, you have to use it intelligently to get actionable information out of it; the possibility that you might misunderstand it doesn't mean it's worthless; it *supplements* the other sources of insight into how best to use your time, it doesn't replace them. All of which, of course, does depend on taking care that the process of collecting the data does not, in itself, cause greater harm than the benefits that you can glean from using the information, once collected, Eddy. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development