"What is the Fedora Project?"

[William Jon McCann]

Hi Spot,

>From an experience design perspective, here is the way I think it should be:
https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience

This set of requirements came out of discussions with members of QE,
rel-eng, and Desktop.

Comments?  If we can agree on these goals then we just have to figure
out how make them happen.

Thanks,
Jon

On Wed, Oct 14, 2009 at 2:30 PM, Tom "spot" Callaway
<tcallawa at redhat.com> 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.
>
> 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?)
>
> 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). 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.
>
> ******
>
> I am interested in hearing the thoughts of others around these ideas.
>
> ~spot
>
> _______________________________________________
> fedora-advisory-board mailing list
> fedora-advisory-board at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-advisory-board
>