Collecting information

[Jeff Spaleta]

On 7/7/05, Rahul Sundaram <sundaram at redhat.com> wrote:
> Marketing: Where do we stand in terms of number of users and what kind
> of users Fedora is attracting

You need to be very careful here...  Are there plans to attract or
discourage a specific "kind" of user? I'm not sure knowing precise
numbers as to the demographics of users provides any useful
information unless there is a stated goal or a commitment to service a
specific demographic or a stated goal or commitment to reach certain
adoption levels (relative or absolute) among different demographics. I
haven't seen any discussion about aims or goals about demographics
targets. If Fedora installs seem to be relatively low in Finland
compared to Brazil, does it matter?  Is there a number of installed
systems target we are shooting for?
If Fedora is popular with one "kind" of users and not so popular with
another "kind" of user... do you work to balance that, even if it
means making it less popular with the larger group? Or do you aim
efforts at making things more appealing to the "kind" of user already
drawn to the project and the distro?  I think these larger questions
need to be answered before you collect any demographics data.  As I
said before, Gnome at least has some (wacky) stated adoption goals for
which that want data for to use to track progress towards that goal.
Fedora doesn't have any adoption goals really, and until we agree on
goals with regard to adoption demographics I don't see a reason to
collect data about it.

> Development : What type of hardware works,  

Is there a commitment from anyone to actually mine that data as it comes in?
And just as importantly... to follow up on reports of brokenness as
updated packages come.
A usable HCL list is going to take real manpower.. and can't be
automated. Creating a big data dump without someone committed to
actively maintain it seems counter-productive to me.  You run the very
real risk of having issues linger as "broken" well after they are
fixed.   if it takes 6 months for a human being to actual mine data
about broken hardware... thats not particularly useful information for
this project, thats a pretty long time scale in comparison to how
quickly update packages get pushed out that impact hardware.  This
might be useful raw data for developers,  I'd like to see what the
kernel and X.org developers think about auto-collecting data about
"working" or "broken" hardware and if having a big datadump like that
would be useful for them in terms of identifying problem areas. If
they don't find it useful to build up databank of "raw" data, its
probably not going to be worthwhile for end-users.  An end-user
oriented HCL is going to require a team of people who are committed to
sifting through the reports and following up on broken issues as they
get fixed with updates quickly.
I want to see people step up and commit to that before data is collected.  

>Whats packages is being utilised more?.  What can be moved into extras?

Even if you could measure the utility of a package in an accurate way
that reasonable accounted for the skew related to "default
installs.".. i've seen NO credible discussion among the release team
nor the Core developers that popularity or utility is an important
criteria for any decisions with regard to Core.   I do not want data
to be collected about popularity until there is consensous that
relative "popularity", "installed", or "usage" of a package is
something that is actually going to impact decision-making by the
people who actually make those decisions.  Taking this data, without a
commitment to use this data.. is just going to create opportunities
for people to argue unconstructively.  First get agreement from Core
release team and maintiainers that "utility" or "popularity" of a
package is important to the decision to keep it in Core or not, then
take the data if that is the concensous view of the people who make
these decisions.

-jef