"What is the Fedora Project?"

[Paul W. Frields]

Trying today to catch up with this and the many other related threads
after roughly a week of travel.

On Wed, Oct 14, 2009 at 02:30:41PM -0400, Tom spot Callaway wrote:
> On 10/14/2009 01:45 PM, Máirín Duffy wrote:
> > - Fedora had been the favored Linux distro for both her and many of her
> > prominent customers, including well-known government and military
> > agencies. Up until FC6. Over the past two years, distros such as CentOS,
> > SuSe,  Ubuntu, Scientific Linux, and Oracle Linux are showing greater
> > stability and thus customer interest has shifted away from Fedora.
> 
> There is a certain amount of irony here, as FC6 was the last release
> where the core was built, maintained, and updated solely by Red Hat.

Also interesting that she cites CentOS, Scientific, and Oracle, since
those are all RHEL rebuilds, i.e. downstream of Fedora.  It's a valid
point that RHEL and thus its rebuilds are more stable, and even if the
community starts to use a more disciplined approach to updates, I
expect that will always be the case.

> In many ways, Red Hat built Fedora internally (in those days) like it
> did RHEL. There are obvious pros (and cons) to that approach, but I do
> not think it is worthwhile spending too much time reflecting on the past.
> 
> I do however, tend to agree with this user's conclusions: Fedora needs a
> measure of controlled stability and improved usability.
> 
> I think there are a few things that we need to do to accomplish that:
> 
> * Fedora needs a dedicated focus on usability. This is something that
> requires coordinating the efforts of designers and programmers, along
> with usability testing. I'm proud to have been able to take the first
> baby step towards that by providing Mo with a portable Usability lab, so
> we can begin gathering data and doing research, but there is much that
> still needs to be done.
>
> * Fedora needs a dedicated focus on QA. This is something where I feel
> confident we are currently making solid progress, especially around
> AutoQA, but we are not making enough noise about. The fact that Chris
> Aillon (a Board member) was unaware of this initiative illustrates that
> failing. :) Our improved Test Days and Bug Triage are wins, but we need
> to continue to be more aggressive here, and try to find ways to involve
> and incorporate our community.
> 
> * Fedora needs to improve how it handles updates. Part of this problem
> is defining what merits an update. Some of this is covered by the
> Critical Path initiative, but I think we can build upon that foundation.
> 
> Just off the top of my head, how about something like this:
> 
> * Clearly mark Critical Path packages as such in Fedora infrastructure
> * Critical Path packages may not do "enhancement" updates on a
> non-rawhide release branch (exceptions permitted only with FESCo approval).
> * Critical Path packages must have a QA test plan for updates to ensure
> that there is no loss in functionality.
> * Where applicable, the user experience should not change for a Critical
> Path package as part of an update (with the notable exception of a bug
> fix or security hole closed)
> * Packages not defined as Critical Path are permitted to do
> "enhancement" updates on a non-rawhide release branch, but are strongly
> encouraged to minimize the amount and frequency of these updates.
> * Any non-Critical Path update which alters the user experience must be
> documented as a part of the update announcement, and announced to the
> relevant mailing lists (perhaps all "enhancement" updates go out to
> fedora-list?)

There are two things here I especially like:

* The involvement of FESCo as a decision-making authority, which
  ensures that update discipline comes from the community through a
  fully-elected body of representatives.

* Informing the users directly, although I would advocate that we
  might need to adjust the venue depending on update timing and
  volume.  Some possibilities that come to mind, none of them set in
  stone, include a new mailing list, an RSS feed, and/or a beat in
  FWN.
 
> FWIW, I also think that "updates-testing", as it is today, does not work
> for Fedora. In all of my packages, I am lucky if I can convince even one
> individual to provide karma on an update, and I have never managed more
> than that, even when I know there are tens/hundreds of users aware of
> the bug (and waiting for the update to fix it).

You're not alone.  A very annoying bug in one of my packages was
recently fixed and although I got scads of duplicate bugs and had cc'd
many of the reporters, only one person reported back on the
updates-testing package.

> A few ideas on how to fix it:
> 
> * Make a period of time in updates-testing mandatory for all updates.
> This can still be overridden by "bodhi karma" votes from testers, but
> nothing can be pushed directly to stable. I'm not a fan of this on its
> own, as I think it will merely encourage people to game the system, as
> we have seen before when individual maintainers have imposed similar
> policies on their own packages... but if paired with my other idea...
> 
> * Encourage community testing of updates-testing, via "Fedora kudos". If
> every package had a list of functionalities and features, and
> instructions on how to test those features, every update would be
> reasonably testable by a competant Fedora user. Any user who tested an
> update and indicated that it:
>  - No longer illustrated the bug it fixed.
>  - Functioned as expected and documented
> Would receive "a Fedora kudo". (Heck, they'd even get one if they showed
> that the update was broken, that's just as useful to know!)
> We'd also give out kudos for users who help define the
> functionalities/features of a Fedora package (with screenshots, testing
> commands to run). Package maintainers can always sanity check these, and
> we will also want to encourage folks to be doing peer review of such items.
> 
> This requires some infrastructure to be built to enable this, but I
> think the payoff potential here is huge. I'm hopeful that we can do this
> as part of the next major milestone of the "Fedora Community" Moksha
> project.

It might be difficult to develop test plans for some packages, and/or
to convince the maintainers to actually make them even with kudos, but
the point would be to make kudos desirable enough to overcome such
obstacles.  What would kudos provide to the user other than a sort of
karma rating?

I'm slightly leery of widespread reward systems in general, since some
studies show they actually *demotivate* people when overused.  But at
the same time, *focused* reward systems that value all contributions
might provide entertainment and collaboration and keep the competitive
aspect to a friendly minimum.  Maybe the top kudos earner in a release
cycle would earn a FUDCon trip, for example, or something the
community feels is of sufficient value.  That's a conversation we the
community can probably have further down the road of actually putting
such a system in place.

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