[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Metrics: RFC

Mike McGrath wrote:
So I've compiled thoughts and issues we've come across with our first
round of metrics in FC6. and created a wiki page so we can actually
keep track of ideas.  Its a wiki so add/alter stuff as you see fit.


I've posed a similar question to the fedora-users list to see how the
community at large responds.


I love how one of the Cons is just "evil."  :)

So those are a lot of possible mechanisms. Let's talk about goals instead? What do we actually want to know? Here's what I would love to have:

o Rough guess of total number of installs
o Total number of server machines
o Total number of desktop machines
o Number of people who install, use, then never use again
o Total number of people who use on a daily/weekly/monthly basis
o What hardware people are using in the field.

Now I'm going to make an assertion. I assert that people only hate these kinds of things when it gives them no value whatsoever. That is, they don't receive anything in trade for that information. What we need to do is to make sure that in return for becoming part of our network, that people feel like they are getting something in return. Maybe it's direct, maybe it's indirect, but still useful.

Let's look at an actual scenario. I would actually start with the last goal on that list to go off of. If we are able to collect a set of hardware profiles for people, just after an install, and tie that to a unique machine identifier, we could make that really useful for people. The reason being that having access to information about what hardware people are really using allows us to know where we need to concentrate our efforts.

DavidZ wrote a little utility for RHEL that basically says "hey, your suspend failed, your hardware is busted!" (in friendlier terms.) What I would love to do is to do the same thing with FC6, but with tracking over time. For example, let's say you have a machine and you want to suspend it. That suspend succeeds or fails. It would be great if both success + failures of those were reported to us. Then we could really build a good/bad hardware + driver list. No one really has this today, and it's of clear benefit to our users.

Also, we could include in that data what kernel people were using and if we saw a big set of new failures after a certain kernel update, we would know that a certain set of hardware was busted in a release. Really useful at a macro level to people like Dave Jones and upstream kernel people.

Now, what does this have to do with metrics? Everything. Note that the above scenario allows us to gather information about desktops, hardware and daily users, and has per-machine information, but there's clear value to both the people using it and the people providing the software. That's the way that we need to approach gathering metrics. Give _and_ take, not just something we're doing to the people who use the software we so lovingly put together. That's where "Evil" comes from but we want to make sure we're not Evil. Just helpful.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]