Fedora Board Recap 2009-10-22 UTC 1600

[Paul W. Frields]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Apologies for this being several days late to the list.  I was working
on a note to publish at the same time, and between that delay and the
FAD I helped run this weekend I simply lost sync.

* * *
https://fedoraproject.org/wiki/Meeting:Board_meeting_2009-10-22

== Roll Call ==
* Present: Christopher Aillon, Bill Nottingham, Dimitris Glezos, Mike
  McGrath, Dennis Gilmore, Matt Domsch, Paul Frields
* Regrets: Josh Boyer, John Poelstra, Tom 'spot' Callaway

== Last meeting ==

https://fedoraproject.org/wiki/Meeting:Board_meeting_2009-10-01

== Proposed Agenda ==

=== Trademark license agreement update ===

* Current status
** Pam Chestek did collaborative editing on the wiki with input from
   FAB
** Final version has been created
** Multiple recipients in queue to receive it
** Door is open for new signers in the future
** We will also offer to current holders so that they have the option
   of switching to the new agreement

=== Commercial non-software goods license ===

https://fedoraproject.org/wiki/Meeting:Board_meeting_2009-09-10#t10_Sep_13:25

* Current status report via Paul
** No time in Comm-Arch team schedule for a Finance meeting
** Paul re-tickled Max, we will set up a meeting to find out whether
   we can set up a receiving fund for Fedora

=== Target audience for distribution ===

https://fedoraproject.org/wiki/User:Pfrields/FAB_roundup

* Paul: The context is "Where do we want to be"
* Need to have more definitive list of the things we expect the target
  audience to be able to do with the Fedora distribution
** Installation/upgrade
** Specific core tasks (reboot, connect to Internet, system update,
   browse, IM/IRC) and what the functional tolerance is -- meaning
   what is acceptable performance for each of these
** Time might be one criterion, errors/fallback might be another
** This helps us make better release criteria, determine blockers,
   etc.
* mmcgrath: Some people think Fedora is for everyone, some don't.
* Chris - The conversation may actually not be about who Fedora is
  for, but rather people just being un happy with the updates.
* General agreement that releases are not known for quality, updates
  after a release get even worse.
* Paul: Probably ad-hoc decisions about updates, blockers,
  prioritization
** Example - we provide help via IRC but a default install didn't
   include a IRC client
** Jesse posted his idea for an unfrozen rawhide and better-managed
   current release target repo
*** Board agrees: GO FORTH AND DO.
** Paul: We should set the audience before setting the process
** caillon: but if we don't fix the process, our target will suffer no
   matter who they are
*** Paul agrees, you can't do one and not the other
** Paul: Our vision should be: "to better fit the needs of *this*
   audience"
*** People voluntarily switching to Linux, not really "my aunt Tessie"
*** People who are not necessarily hackers, but are familiar with
    computers
*** People who are likely to fix something that is not working (or at
    least collaborate or report when it's not working)
*** List of tasks one can do?
**** web browsing, email, office productivity, graphic arts,
     publishing, audio listeners, web serving, collaboration &
     communication, software developers
** There may be network benefits of this approach - by targeting
   these, we may be more usable for other cases, even if they're not
   our goal.
** dimitris: Perceived lack is around polish. We may not be missing
* broad targets horribly, but there's a lot of fine tuning that needs
  to be done better.
** mmcgrath: A big thing we're missing is self-control with updates.
** mdomsch: (channeling skvidal) You as a Fedora packager essentially
   have root access on millions of systems. Treat them with
   appropriate care
** mmcgrath: have FESCo and/or QA come up with a mandated policy
   around stable release updates.
** caillon: also need to make sure that people follow those policies;
   see also
   https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00100.html
* Decision item needed.
** What is our target audience? (see above)
** The Board will now pursue goals for process changes that make
   quality higher for that target
* mdomsch: Board focus on quality instead of quantity of packages
** mmcgrath: how can we measure quality?
*** How many update breakages?
*** How many updates overall? (This is more symptomatic than
    root-cause related)
** This is an area where we can learn from others.
** critical path packages need push approval for stable
   releases. Perhaps we don't have the resources in place to do all
   packages.
** dimitris: If we increase visibility when a breakage happens, it's
   less likely people will be careless.  Are we giving enough
   visibility to breakage, or do we just fix it quietly?
*** Sheriffs will help in this visibility.
** mmcgrath: How do we prevent "Daddy says no, I'll ask Mommy"
*** caillon: With sherrifs, this has not been a big problem. All nos
    get logged, so that should be referenced before saying yes.
* ACTION: Paul will follow note publishing with a summary to FAB of
  the agreed points:
** Target audience statement from above, which represents broadest
   consensus, to be further specified collaboratively
** Board will set update discipline goals and look to FESCo to help
   design/implement
** Board concurs with Jesse Keating's expanded explanation of the
   "Unfozen Rawhide" proposal and will work to make it happen fully in
   the F13 cycle.

== New Business ==

=== Elections ===

* mdomsch looking for someone who might like to take up Fedora
  election coordination work
** Which groups are up? Board 1/2, FESCo 1/2, Ambassadors (all?), F-13
  name... who else?
** What events need to be held?
** When will they be held?
*** start elections after FUDCon, which closes Dec. 7
*** use FUDCon for an additional in-person town hall meeting
* ACTION: MDomsch will kick this off on FAB, and look for existing and
  new volunteers to drive it

== Next meeting ==
* AGREED: 2009-10-29 UTC 1600

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFK5fsZrNvJN70RNxcRAgWKAJ9Tt0zVuxdenTCTNv9x+IHqugb+QgCguR/+
nUW9DoeTiHBsLpx/MkaYSc0=
=7G9P
-----END PGP SIGNATURE-----