Target audience

Paul W. Frields stickster at gmail.com
Mon Oct 26 20:37:47 UTC 2009


Yup, it's another long FPL email, be warned! :-) I wanted to write out
some summary and context about previous discussions here, and by the
Board, that would be helpful in setting up some of the sessions I
would like to hold at FUDCon.

In our Thursday meeting[1], the Board talked at length about the
lengthy discussions that have been happening on this list, which have
been both spirited and, as always, very helpful.  Continuing to make
the best possible Fedora distribution is a top priority to everyone
who works on it.  We all want to see the Fedora Project succeed as the
leader in advancing free and open source software, and the Fedora
distribution is how we put our best work in front of a wide audience
twice a year (and at all times in between!).  And of course we want
the Fedora Project to continue to be a vibrant community where
contributors pursue a variety of goals, sharing our core values of
Friends, Freedom, Features, and First.

The specific discussion about making the best possible distro has
focused in on target audience.  This is a sensible (and arguably
overdue) step, because to provide a Fedora that satisfies someone, we
first have to know who that person is, and differentiate them from the
mass of "everyone," and also we need to be clear in what we expect
them to be able to do.  We found four defining characteristics that we
believe best describe the Fedora distribution's target audience:
Someone who (1) is voluntarily switching to Linux, (2) is familiar
with computers, but is not necessarily a hacker or developer, (3) is
likely to collaborate in some fashion when something's wrong with
Fedora, and (4) wants to use Fedora for general productivity, either
using desktop applications or a Web browser.

This target audience does not a major shift away from what most people
in the Fedora community believe.  Having a target audience also does
not preclude any feature development that goes beyond that audience.
By having an audience in mind, we as a community can prioritize
resources, and at the same time make it possible for people who want
to concentrate on other audiences to build community around those
efforts.  Fedora teams already are making progress on this, and one
example is our Fedora QA team -- which opens a schedule of community
test days for every release, and provides information on hosting them.
Thanks to our remixing tools, anyone can put together test day spins
to facilitate the testing.  Anyone who is interested in technical
goals, whether they are part of the target audience focus or not, has
a place and resources in the Fedora Project to help achieve them.

The Board members and I believe that making the experiences of
getting, using, and contributing to Fedora better for the target
audience will also improve them for our close community as well.  This
is not an either-or proposition, but a win-win.  In essence, the
target audience is much larger than the group of people in Fedora who
are, say, subscribed to this list; or who develop features,
collateral, and other content for Fedora; or who do great Fedora
advocacy work, whether through speaking, writing, or in any number of
other ways.  When we improve Fedora from the perspective of that
superset of people, we are also very likely improving it for our core
contributor community as well.

Those people may end up telling others about their experience, and
thereby expand our actual user base even beyond its substantial
current size.  That's a very fortunate consequence of making a better
product, but our goal is not to simply target "everyone," which isn't
a reasonable goal given finite resources.  We wouldn't be unhappy if
more people started using Fedora casually, even outside our audience,
but at the same time we want to continue to build something designed
for the people we think we can reasonably please.

We don't delude ourselves that the target audience definition is now
"done."  What we have now is simply a shared understanding of where to
start, and we can start adding definitions of tasks and expectations,
to understand an example or profile of our target audience -- what
this person wants, understands, needs, is like.  That work is going to
require input from people who know more about user design than any
single person in one meeting.  I'm hoping people here can
constructively help us draft this profile on the wiki, or use other
collaboration tools to create a better shared understanding of this
profile.  Mairin Duffy recently posted her take[2] on starting this
work and I'd like to see even more definition added to the profile.

Of course, this doesn't magically happen overnight.  In fact, it can't
happen at all without coming together as a community to address the
nuts and bolts of actually fixing things that are broken.  Part of the
miracle of the Fedora community is that we aren't afraid to admit a
failure, understand it, and fix it and move on.  Hoping to contribute
to solutions, the Board discussed some of the brokenness, issues we
often hear from people who do fall within our target audience,
including people who are in our large community of contributors.
Among those were frequency and reliability of updates and upgrades.
If we want to attain the goal of making our audience happy, as a
community we need to do a better job of not breaking their systems or
causing them to doubt the quality of the software they're receiving.

This is a topic that will bear further discussion, obviously.
Together we need to figure out the best ways to balance our desire for
advancing free and open source software (i.e. the Fedora Project
mission) with the provision and promotion of a platform that our
target audience can confidently use.  I've referred to this in the
past as "update discipline" but not in a flippant manner.  I don't
mean "discipline" in the sense of reward/punishment or anything like
that -- rather, in the sense of a community dedication to doing things
well, consistently.  At least one set of ideas has been written up
already[3] to brainstorm on the problem, and while I think there's
still work to do to figure out a solution, I think there's already
quite some consensus that the problem exists, is important, and is
worth trying to solve.

Finally, the Board talked about the proposal for "unfrozen
Rawhide,"[4] which Jesse Keating offered at a Fedora event this
summer.  Just like many of our contributors, we've felt the pain of
having an uninstallable Rawhide, which negatively affects everyone's
ability to more efficiently deliver new code and features.  In
essence, Rawhide has been too often "eating babies" indiscriminately,
and we need to improve its contribution to our develoment ecosystem.
The Board feels that Jesse's proposal not only has the potential to
help us achieve a more installable Rawhide, but if it's managed
correctly we could have a Rawhide that more of our core contributors
could actually use during and prior to test phases -- while not
undoing our ability to allow and encourage innovation and new ideas.

So in summary the three points that came out of Thursday's board
meeting -- target audience, better update discipline, and a more
useful Rawhide -- are all topics that we intend to discuss further
here, and at the FUDCon in Toronto[5].  We'll have a majority of both
the Board and FESCo representatives together then, along with a wide
selection of our community, to help put together a roadmap for the
next evolution of Fedora.  I'm very excited about that event, and
can't wait to take advantage of the opportunity to help move Fedora
forward.  And although it goes without saying, as always I'm very
grateful to be working with such an impassioned and dedicated
community of contributors.

* * *
[1] https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00349.html
[2] https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00313.html
[3] https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience
[4] https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00318.html
[5] https://fedoraproject.org/wiki/FUDCon:Toronto_2009

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug




More information about the advisory-board mailing list