"What is the Fedora Project?"

[Josh Boyer]

On Wed, Oct 07, 2009 at 07:27:34PM -0400, Paul W. Frields wrote:
>On Tue, Oct 06, 2009 at 09:11:41PM -0700, John Poelstra wrote:
 
>> (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

I think this article points out some interesting facts, however I'm not
entirely convinced it's a great example of how we want to approach this
topic.  Certainly some of it makes sense, and some of the examples you have
below are good items to address (abrt, etc).

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

I think it's important to note that even our current developers can and do
have that characteristic.  People generally want things to work, regardless
of how much experience they have.

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

This seems to conflict with the 'less than 10-15' minutes or less per
month goal you have above.  Good bug reports (ideally abrt assisted) will
still take at least 10 min to file.  Actual useful bug particpation is much
more than that.

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

Why is that important to the Fedora project or distro?

>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

The article assumes that you view this inequity as a problem that needs
fixing.  In our case, is it really?  I have no problems with having a
large non-vocal user base.  Nor do I have problems targeting some people
outside of our primary contributor audience.  However at the end of the
day, Fedora is shaped by the people that are putting forth the effort
to actually make something.

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

I won't disagree that extending pariticpation as a side effect is
something we can and possibly should do.  However, I do not feel that it
is something we need to make a _primary_ focus.

Why?  Mostly because while I understand the article's points about
increasing paticipation, I want that participation to be a concious choice
on the users part.  I want our contributors to WANT to contribute.  I want
them to be annoyed at something and motivated enough to do something about
it.  Or to have them have a great direction they want to take Fedora in and
care enough to actually try and see it through.

We have long said that 'Fedora is a meritocracy', and I still think that is
something we want to strive for.

>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

Agreed.  For that we need actual content, and the distro itself is not
the vehicle for that.  We need people making videos, writing documentation,
helping users on IRC or lists, etc.  However, this is outside of the
distribution and more on the project.

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

I very much like the aspect of the more stable rawhide here.

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

Also Russia.  I hear we have quite an active community in Brazil and India,
so perhaps we could look at what our Ambassadors and contributors have done
in those localities.

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

Perhaps s/site/site and tool?  I know that as a developer, if I had to go
to a website for everything I did in order to contribute I wouldn't be overly
thrilled.

(Also, it's worth pointing out that openSUSE already accomplishes this with
their build service.  It is build, SCM, etc all rolled into one.  And they
have a command line tool.)

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

Again with the Web-based focus.  Wouldn't this be potentially alienating
and annoying to a not small subset of the 1% of our development community
that is making the distro today?

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

These all seem like really good ideas.

josh