[Qt-creator] [Development] Requesting repository for telemetry plugin in Qt Creator

[Marco Bubke]

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.io at qt-project.org> on behalf of Marco Bubke <Marco.Bubke at qt.io>
Sent: Monday, February 26, 2018 6:29:22 PM
To: Edward Welbourne; Robert Loehning; André Pönitz
Cc: development at qt-project.org; Ryein Goddard; qt-creator at 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.io at qt-project.org> on behalf of Edward Welbourne <edward.welbourne at qt.io>
Sent: Monday, February 26, 2018 6:06:08 PM
To: Robert Loehning; André Pönitz
Cc: development at qt-project.org; qt-creator at 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 at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20180227/e6981c0c/attachment.html>