Another point: if you do collect usage data, please bear in mind that
sometimes a feature can be used very rarely, but still be vital. In other
words, do not consider a feature as "unnecessary" or "can be deprecated" if
it is not used often.
For example, I mostly do mobile and desktop apps, but I still do want the
remote linux deployment to work smoothly for rare occasions when I need to
On 22 February 2018 at 20:05, André Pönitz <apoen...@t-online.de> wrote:
> On Thu, Feb 22, 2018 at 04:42:55PM +0300, Konstantin Tokarev wrote:
> > 22.02.2018, 16:39, "Ryein Goddard" <ryein.godd...@gmail.com>:
> > > This might be nice to make pretty charts to show to managers, but to be
> > > completely honest I think it is 100% useless.
> I fully subscribe to that.
> > > If you don't know what people
> > > are using your software for, or how then you aren't communicating with
> > > them. You know once upon a time companies just talked with people to
> > > out what they wanted and what they were having difficulties with. Why
> > > just take a few surveys a year?
> > Well, there are things that are hard to report via survey, e.g. rate of
> > crashes or memory leaking in clangbackend
> 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.
> 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
> 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
> 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
> working on project named D" will translate into making my work more
> nor in how to improve Qt Creator in general. In fact, I consider all of
> irrelevant and detrimental and would strongly prefer to *not* get access
> to such
> information, and neither to anyone's interpretation what bug report this
> information may relate to.
> That makes a clear -1 from my side for technical reasons already.
> Neither legal nor ethical considerations are likely to improve that.
> Andre' (not speaking for any company etc etc)
> Development mailing list
Development mailing list