"What is the Fedora Project?"

[Josh Boyer]

On Tue, Oct 06, 2009 at 09:11:41PM -0700, John Poelstra wrote:
> 1) I'm still advocating that it is our responsibility to move things  
> forward and own these issues.  Are there any board members that  
> disagree?  Speak now or we will assume you are in agreement. :-)

I think it's our responsibility to (re)evaluate these issues, yes.

> 2) We really need to resolve this topic that has been on the board's  
> agenda since January 2009.  For some of us, since we joined in July  
> 2009.  I'm proposing that we set a hard deadline of "the end of FUDCon."  
>  This means that by the time we leave FUDCon the first part of December  
> 2009, this issue will be officially closed and off our agenda until  
> there is a reason to revisit it and we can start 2010 with a clean  
> slate.  Are there any board members who would not be able to commit to  
> this goal?

I think we can try.  I also think 'resolve' is perhaps the wrong word.

> (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.

We're never going to be "done", so shooting for clarity on how to be done
seems slightly the wrong angle.

I agree with Paul that for this question we should focus on the type of user
we want to target with the default spin.  It seems we have basically boiled
this down to two sets of users.  The first is 'newbie', and the second is
'experienced developer'.  (If there are others that I'm missing, chime in).

I'll define 'newbie' here as:

- Someone that is moving from $OTHER_{OS,DISTRO} and is looking for something
a bit more exciting and a bit less restrictive.
- They likely don't have programming skills, nor necessarily want to become
developers.
- They generally want things to work out of the box, but they don't mind
seeking help or helping developers debug a problem.
- They have a general knowledge of computers, have installed software in
some manner before, are comfortable with basic computer terms like RAM, CPU,
gigabyte, etc.

Generally, not Aunt Tilly but not necessarily someone that is in an undergrad
CS program either.

Defining 'experienced user' is a bit easier, and I haven't seen any debate
on the usage of that term so I'll avoid spelling it out.  If there is someone
that isn't clear on what I mean, just ask.

With that in mind, I think it's interesting to note that there is a lot of
overlap between those two if you target the less experienced user.  E.g.
both classes generally want things just to work.  I also think that
targetting the newbie does increase your possible contributor base as we
have said before.  Whether they turn into uber-contributors or not doesn't
really matter as long as they find using the Fedora distro to be generally
useful and _want_ to be part of the project.

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

As I said in the public IRC meeting, I really stink at this sort of thing.
It's not that I can't lay out long term goals, it's just that things move
and change entirely too fast to lay out a 2 year plan.

I think F15/F16 should be an evolution of what we have today.  Continuing
to showcase the latest stable FOSS and trying to provide a great experience
out of the box.

I believe we need to get a consistent methodolgy in place for how we treat
released versions of the distro in terms of updates, bug fixing, etc.
Consistency across the distro is going to help users gauge what to expect.

I think we need to pick a spin and focus primary development on that.  To
a large degree, we have started down this path already with the webpage
redesigns, the reaffirmation that the desktop spin is our default, etc.
This is not to say that there can't be other spins, or that we don't want
Fedora to allow people to produce derivations.  However I do feel that
treating them all as equals and using terms like 'first among equals' is a
disservice to the distro overall.  A tiered approach provides clarity.

> (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?

I'll try to avoid repeating items that others have already said and I agree
with (like expanded participation, etc).

I would like to see our development community participating in our processes
as a whole.

I would like to see more education efforts for users (extending the Fedora
Classroom ideas, writing content on how to do things, etc.)

I would like to see less aversion to looking at other distros and reusing/
contributing to things they have started that are beneficial to Fedora.

> (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?

QA.  Fortunately, we have made good progress on the rawhide front already.
I'd like to see (and help with) more progress on QA of released versions and
updates.

A higher bar for Features.  We have a hugenormous list of Features and it's
starting to get a bit fuzzy as to what that means and how a new user could
possibly even experience some of those.

An actual secondary architecture release.  We've had 'almost' releases since
F8.  I don't care which arch it is, but if we don't have a secondary arch
that actually does a release I think it's time that we as a project just
move on and stop worrying about it.  (Or maybe we're already at that point
and I'm the only one worrying)

A clear process around the creation of the distribution.  I think rel-eng
is making strides towards this already, and trying to improve the experience
for contributors with no frozen rawhide and auto-qa.  I'd like to see us
support that and invest in it because it will have a wide benefit.

Easy one: auto-sign builds.  Represent signed packages exactly as they are
today: Fedora built this.  That's it.  Signing doesn't imply it's been tested
or QA'd or that it is somehow a known quantity.  It simply means the package
as built by Fedora.

josh