"What is the Fedora Project?"

[Bill Nottingham]

This is probably a bit late to the discussion, but wanted to get my
thoughts down before I started chiming in on everyone else's...

John Poelstra (poelstra at redhat.com) said: 
> (a) Define a target audience for the Fedora distribution (or maybe
> narrow the definition to "default spin")--without a clear target
> audience for our product there is a lack of clarity around when we
> are "done."  It also makes it difficult to make decisions about
> release quality and release composition.

So... we have multiple pieces here.

Fedora, the entire collection of packages. (This could be considered
the Distribution). These can have one target audience.

Fedora, a spin, or all the spins we provide. (This also could be considered
the Distribution). These can have different target audiences, which may
be different from the audience of the collection of packages as a whole.
For example, the Games spin and the Electronics Lab spin have different
audiences, and that should not be a problem.

My feeling is that, if we were to use some sort of mission statement to
describe it, Fedora's essence should be 'innovation made usable'.

We want to present the newest innovations to users, but not so new that
they don't work. And we want to be focused on making it just work, so they
don't have to run 500 arcane commands, cut and paste config snippets from
the web, or jump through other hoops just to use that innovation. Nor
do we want to be pushing new innovation to them so fast that they
can't keep up with it, or find that their way of doing things changes
from week to week during a release.

We also want to grow the base of users, as that's where our contributors
come from, whether they be coders, documentors, artists, support staff
on the forums, or whatever.

Applying this to 'the Distribution'? I think we want to do two things:

1) put our best foot foward
2) innovate around the edges

What does that mean? We should have a single default spin/release/whatever
that puts our best foot forward for a specific use case, allowing us
to attract more people to Fedora, some portion of which will then join
the project as contributors. In order to be able to sanely grow the
community around it, that default should be somewhat fixed - what the
default is shouldn't be changing from release to release.  As for 'target
user'... the stock answer is the computer-literate user who wants a
coherent, easy-to-use system that doesn't get in their way. We don't
necessarily want to target all the way down to the user who's never used
a computer before, but I think attempting to target only those who have
Linux experience, or are  already tinkerers, is too limiting. I feel this
default should be something like the desktop spin; a clean interface
targeted at a wide variety of users that can be easily extended for a
large number of use cases.

For example, a user can start with the desktop, and easily add a package
or three to address the 'graphics designer' use case. Or add a few
packages to address the 'developer' use case.  It doesn't necesarily
scale down to the server use case, but I think that's one case where
we don't need the extra marketing; those in the server business are more
famailiar with the Fedora Family Of Distributions, and don't necessarily
need to be targeted in that way.

But we also want to allow innovation around the edges - if this desktop
doesn't hit the use case that someone wants to address, or someone wants
to extend it into something more specific, we want to allow that. That's
why we allow the wide variety of packages into Fedora, and allow for things
like the Spins process and the Remix idea to target other use cases that we
may not target in the default Fedora spin/distribution/whatchamacallit.
That being said, when the objectives come into conflict between these
usage cases, we should go back to the default spin/focus as the tiebreaker.

You'll note this description doesn't really harp on project directives
such as 'the Fedora Project consistently seeks to create, improve, and
spread free/libre code and content.' That's somewhat intentional - while
I don't want to *change* that focus, and that certainly should drive
technical decisions where necessary, I don't think that's necessarily the
best point to drive the target user around. To go back to the old free beer/free
speech analogy - you bring the users in with free beer, and *then* you get
them with the free speech. If we do our job right in creating the user
experience for our users, the fact that it's all open source may not
even be noticeable to them if they're not looking for it.

> (b) Set some broad goals for where we want the Fedora Distribution
> to look like a few release from now--say when Fedora 15 is released.
> What should those be?

- I'd like the produced images to be:
  - the default Fedora distribution as described above (could be a LiveCD spin)
  - the netinst/rescue iso
  - the spins

  Without a specific target audience, the current Fedora tree should go.

- I'd like there to be a standard set of distribution tests so that when
  we compose a new livecd/spin/tree, we can, in an automated fashion, get
  a large variety of results quickly as to how well it works

- I'd like 'israwidebroken.com' to resoundingly respond 'no' 95% of
  the time.

> (c) Set some broad goals for where we want the Fedora Fedora Project
> to look like a few release from now--say when Fedora 15 is released.
> What should those be?

- Metrics wise, an increase in contributors (hopefully across the board)
- Development-wise, more actual development discussion on the devel list;
  patches, code review, feature proposals/discussion, etc.
- An increase in task-focused spins. Right now, the focus of many of our
  spins appears to be i-want-a-desktop-too-but-not-that-desktop, which
  doesn't necessarily expand the use cases that people can hit with
  Fedora as much.

> (d) Set a goal of five things we believe should be improved or fixed
> by the release of Fedora 13 that will make the Fedora Distribution a
> better product or the Fedora Project a stronger community.  What
> should those things be?

These are more towards 'better product'.

- QA QA QA. AutoQA doing automated tests, AutoQA mailing those test results
  to developers for review, AutoQA using those tests to block packages where
  necessary, AutoQA using those tests to promote packages where necessary.
  A database of past test results so we know what broke, when.
- Defined policy around updating and maintaining released distributions.
  Not being able to concisely explain what sort of updates you get is a
  problem.
- Set up a mechanism where large changes can be built in koji, set up as
  a repo, and tested sanely before being merged, ideally as a self-serve
  mechanism.

That's not five, but if we get that far, we can come up with more.

Bill