"What is the Fedora Project?"

[Paul W. Frields]

On Tue, Oct 06, 2009 at 09:11:41PM -0700, John Poelstra wrote:
> 
> http://meetbot.fedoraproject.org/fedora-board-meeting/2009-10-01/fedora-board-meeting.2009-10-01-16.03.log.html
> 
> At last week's meeting we said we would continue our discussion
> here. Here I go :)
> 
> 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. :-)
> 
> 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?
> 
> 3) I am proposing a few unanswered questions that must be answered
> to bring greater clarity to why Fedora exists and what it seeks to
> accomplish which will allow us to close this issue.  I'd wager that
> answering these questions will require each of us to sit down and
> spend some time thinking about them vs. replying in 5 minutes to
> this email. Naturally we'd also love feedback from everyone on this
> list.
> 
> (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 should concentrate on the default offering as our point of decision
making for purposes of this discussion.  One of the main purposes of
custom spins is to enable different groups and teams to alter that
target audience.  For instance, the FEL spin is going to have a very
different target audience from the default offering.

As I pointed out in our last meeting, there is a useful discussion of
community composition and how it affects perceptions here:

http://www.useit.com/alertbox/participation_inequality.html

In particular this very early sentence should be important in thinking
about our target audience: "[A] tiny minority of users usually
accounts for a disproportionately large amount of the content and
other system activity."  Note that the model shown in this article
is supported by our experience of bringing users into the community to
participate, first in limited ways and then (in some cases) more
protracted and substantial ones.

This is why I feel so strongly that we should not be assuming that the
people we see every day in our roles in the Fedora community,
participating and contributing in constructive ways, are de facto
representative of our only target audience.  Do we want those people
involved?  Almost invariably the answer is "yes."  But there are many
more people we reach, and more that we want to be reaching, to
encourage an appreciation for sustainable software freedom, on the
terms we set out in our mission and core values:

https://fedoraproject.org/wiki/Overview#Our_Mission
https://fedoraproject.org/wiki/Foundations

I think it's a good idea for this discussion to concentrate not on how
we aren't meeting this goal at present, but rather on where we want to
be in the future.  Here is the kind of lowest common denominator user
for whom I would like Fedora to be the first choice of an operating
system in the next two years.

In terms of characteristics or approach, this person:

* ...is switching from $OTHER_OS to free software after hearing or
  reading about it, or seeing it first hand.
* ...expects things to "just work" as much as possible, and can
  sometimes be impatient as a result.
* ...doesn't want to go back to $OTHER_OS, and is therefore willing to
  fiddle occasionally -- on the order of 10-15 minutes or less per
  month -- to avoid it.
* ...accepts that software freedom has certain limitations, but wants
  to minimize (and if possible eliminate) any difference in
  capabilities vs. $OTHER_OS.
* ...won't pay for software.
* ...will contribute in the form of a bug report or helping others, if
  it's easy to do so with a few mouse clicks, but won't fill out long
  Web forms or do more than a sentence or so of typing.
* ...is interested in sustainable practices in general, but is not
  necessarily fanatic -- recycles packaging and goods, thinks "buying
  local" is worthwhile, volunteers at something a few times a year.

In terms of skills and knowledge, this person:

* ...knows, or is capable of finding out, how to boot a system from an
  alternate device such as CD or USB.
* ...is able to open applications and make selections as directed in
  documentation or by a support agent (be it human or not).
* ...may not understand how free software is built, or how a free
  software project run (but is capable of learning).

Clearly this person is not a developer, but including this person in
our target audience does not disadvantage developers as end-users of
the distribution.  Focusing on this person's needs might mean that we
the Fedora community might have to come up with better strategies for
delivering software, or re-examine our release processes, or develop
some new ways of creating the distribution/tree so that we can allow
developers to maintain a high pace where appropriate, yet not have
that boomerang on all users.

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

The article goes on to show how this inequality skews perceptions of
our actual users, and then goes on to point out some ways to overcome
the inequities.  One of the suggestions is to "make participation a
side effect."  This is something that we are still striving to do in
the software we provide.  We've made some advances in areas like ABRT,
SELinux, and others.  But, as I'm sure their worthy developers would
agree, even those need refinement so that we are better leveraging our
large user base into occasional participation, and giving them a clear
path to increase that engagement with the Fedora Project.

Looking back at the example profile above, this person may not be
fanatical about software freedom when trying Fedora *for the first
time*.  But by providing an improved experience for that person, we
smooth the way for then taking on the specific goal of education in
the context of making participation a side effect of using Fedora.

Right now we provide little to a Fedora user out of the box, in the
way of educating them where Fedora comes from, the enormous size of
our community of contribution, and how we encourage sustainable
software freedom.  We can and should do better, especially with our
unique positioning in terms of innovation and leadership.  We can also
do better in terms of improving this person's experience with some
simple regular processes like updates and upgrades; and finding,
installing and accessing authoritative docs in the native language
that answer Fedora-specific questions.

I've heard a bit of preliminary rumbling about DSCM-like Rawhides -- a
way for developers to have trees that move at their pace, and are
possibly quite broken from time to time in ways that differ from each
other.  If we were able to develop such a scenario, why not also
provide the flipside of this idea -- make the One True Rawhide the
place where we take in changes that don't break the world, while
they're cobbled on in the other trees?  Whether this is an extension
of the "KoPeR" idea or something entirely difficult, it merits serious
consideration.

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

By Fedora 16 (i.e. two years out):

* Build a more robust presence and community in Africa, China, and
  Japan.

* Complete package maintenance interface in one site (i.e. less or no
  shuttling between SCM, Koji, and Bodhi).

* Using the Fedora Community Portal to connect new FAS members
  immediately with short-term tasks, and live mentors through a
  Web-based communication interface.  Devote several FADs and FUDCon
  hackfests to coding the pieces needed as part of a planned project.

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

I'll just add these to the mix:

* A coordinated effort between Alpha and Beta (or even post-Beta) to
  file and fix more bugs as a community effort, perhaps in the form of
  a focused week of effort across the Fedora community.  Community
  Architecture support for bug parties, say $50-75/group to pay for
  hacker snacks.

* A central 'www.fedoracommunity.org' website that functions as a
  directory of other *.fedoracommunity.org domains -- the ones run by
  our community members that are separate and distinct from the
  fedoraproject.org domain.

* Improve the wiki documentation for schedule, freezes, critical path,
  and related info to make it dead simple for any developer (or heck,
  anyone) to figure out what is permissible at any point in the
  cycle.  This should help eliminate guesswork, late code drops, and
  misunderstandings that can negatively affect the community.  Not
  only that, but it means that we can more effectively create more
  robust QA and rel-eng communities because there's a lower barrier to
  learning what sometimes is institutional knowledge.

> This is a great opportunity for each board member to state their
> position so that the community can see where we each stand on these
> issues.

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