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 use it. 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 > figure > > > out what they wanted and what they were having difficulties with. Why > not > > > 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 > 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 > nor in how to improve Qt Creator in general. In fact, I consider all of > that > 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@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