Am 23.02.2018 um 11:54 schrieb Edward Welbourne:
André Pönitz (22 February 2018 20:05)
Any number for a "measured" value for rate of crashes or memory leaks
is uninteresting for me when I run into the problem myself reqularly.
And trust me, I do.
I trust you.
It is, however, possible your usage patterns of the UI are not typical;
consequently, you'll prioritise the bugs you see most often; which might
not be the bugs most often encountered by other users. Analytics may
give you the data to know the pain points everyone else is as acutely
aware of as you are of the pain points you meet most often.
As someone who has been working on Qt Creator for more than a decade I
*do* know about issues in the IDE by my own use of it, by the
significant backlog of bug reports in JIRA, and by interacting with
(sometimes referred to as "talking to") actual users.
The currently 399 open issues assigned to me personally would already
be enough to keep me busy for approximately a $WHILE, full time, not
including time spent in review processes etc.
I certainly do not need another input channel that makes me spent time
on guessing how the information that "user A spent at time B an amount
of C minutes working on project named D" will translate into making my
work more efficient
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.
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?
This won't enable you to write new features any faster or fix bugs any
faster; but it may enable you to prioritise the things that are causing
most pain to most users, and the things that would give the most win to
the most users. *That* is what analytics is good for. The fact that it
doesn't do a bunch of other things is beside the point, and no reason to
reject it out of hand.
Now, fortunately for you, most of the folk who use the product you work
on are in fact software developers, so may well have similar habits to
yours; so if the scope of this project is only Qt Creator, it may well
be a waste of time; and, if it's intended to be a more general tool,
this may also be a reason to *not* focus on Qt Creator as initial
test-bed, as seems to be the present plan - that's apt to skew what we
develop to be something that only works when the user-base thinks like
the developers, which is not where (honest, open, ethical) analytics is
at its best - where it reveals things to the developer that users see
all the time, but the developer never encounters.
Development mailing list
Qt-creator mailing list