One big thing this would solve is discovering what features are NOT used - for example we'd know if people know keyboard shortcuts.

For example if we implement the "FX mixer strips auto-rename" feature, by logging all operations of mixer-strip manual renaming we could measure how useful (or not) this feature is - if it's broken or works not as users expect, they're gonna use manual renaming a lot, but if they stop manual renaming at all - I'd interpret this that auto-rename is working great.

Maybe we have some cool features that are not used, not because they are useless, but because they are not known.

This feature could also be connected with a "Tip of the day" feature (new idea, just got it) - displaying tips that users probably don't know, based on local feature usage statistics.
Let's show them tips about what they never done before in the first place!

A button "This tip was useful" and "This tip was useless" for user feedback could also help us review the tips and decide what to do to improve them.

A button or context menu item "Send feedback about this..." that opens a text input window allowing users to write personal notes about anything in the program would also be a great way of gathering instant and fresh comments about what works and what doesn't in the program.

I think anonymous statistics and feedback could make a big difference in how developers understand users.

2014/1/15 Jonathan Aquilina <eagles051387@gmail.com>
You are ok. Thing is things get discussed then they vanish and never get
completed as there was no issue filed in the tracker.

On Wednesday 15 January 2014 16:03:15 you wrote:
> It's me. Mea culpa ;)
>
> On 15 Jan 2014 16:01, "Jonathan Aquilina" <eagles051387@gmail.com> wrote:
> > Can we put this on the issue tracker please and get it tagged as an
> > enhancement request please.
> >
> > Thanks please include the below discussion and the names of hte person in
> > the
> > initial post that way we dont have to start the discussion from scratch
> >
> > On Wednesday 15 January 2014 15:59:01 Tobiasz Karoń wrote:
> > > Absolutely.
> > >
> > > On 15 Jan 2014 14:50, "Vesa" <dii.dii@nbl.fi> wrote:
> > > >  On 01/15/2014 03:32 PM, Israel wrote:
> > > > That might be useful.  I think including a 'Report Problem ' button
> >
> > would
> >
> > > > be nice so all the bug reports can go to a common area.  I get bug
> >
> > reports
> >
> > > > for Ubuntu occasionally (though honestly a lot of them have been for
> >
> > the
> >
> > > > packaging... which I have been chipping away at fixing)
> > > > But if someone has a real problem with the actual program, having an
> >
> > easy
> >
> > > > way to send a bug report is a good idea!
> > > >
> > > > On 01/14/2014 03:37 PM, Tobiasz Karoń wrote:
> > > >
> > > > This idea comes back to me again: could LMMS gather some statistics if
> > > > users agree to participate?
> > > >
> > > > What info and why?
> > > >
> > > > - LMMS version
> > > > - operating system
> > > > - screen resolution
> > > > - audio back-end
> > > > - instruments/plugins usage
> > > > - feature usage (clicks on every UI element)
> > > > - crashes per month
> > > > - problem reports (user input - would require a "report problem"
> >
> > feature)
> >
> > > > - ?
> > > >
> > > >
> > > >
> > > > This could be implemented BUT - a huge BUT: it needs to be entirely
> > > > transparent, voluntary and opt-in, and respectful of the user's
> >
> > privacy.
> >
> > > > Here's the bare minimum requirements:
> > > >
> > > > - when you first run LMMS a dialog could pop up asking if the user
> >
> > wants
> >
> > > > to participate, and if the user selects "no" they won't be bothered
> >
> > about
> >
> > > > it again.
> > > > - this dialog should also explain clearly what kind of data is sent
> > > > and
> > > > where.
> > > > - the feature should also be able to be later manually turned off/on
> >
> > from
> >
> > > > the settings, and that setting must be easy to find.
> > > > - we should also collect data on a strictly need-to-know basis, ie.
> >
> > only
> >
> > > > collect things that are a) strictly necessary/useful for the
> >
> > development
> >
> > > > of
> > > > LMMS, and b) anonymous - can't be used to identify/track the user.
> > > >
> > > > Post-Snowden, there's no playing around with this kind of stuff...
> >
> > --------------------------------------------------------------------------
> >
> > > > ---- CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> > > > Learn Why More Businesses Are Choosing CenturyLink Cloud For
> > > > Critical Workloads, Development Environments & Everything In Between.
> > > > Get a Quote or Start a Free Trial Today.
> >
> > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clkt
> >
> > > > rk _______________________________________________
> > > > LMMS-devel mailing list
> > > > LMMS-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/lmms-devel
> >
> > --------------------------------------------------------------------------
> > ---- CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> > Learn Why More Businesses Are Choosing CenturyLink Cloud For
> > Critical Workloads, Development Environments & Everything In Between.
> > Get a Quote or Start a Free Trial Today.
> >
> > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clkt
> > rk _______________________________________________
> > LMMS-devel mailing list
> > LMMS-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/lmms-devel




--
Tobiasz unfa

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$ !N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv b+>+++ DI>+ D+ G e h-->- !r y--() 
------END GEEK CODE BLOCK------