It's time to finish up all the conversations that we've had about
governance, boards that need to be elected/appointed, decision-making,
etc.
And to try to learn some things from past releases.
Here's my thoughts. I'm sure there will be lots of comments. I hope
this gets us a good portion of the way to where we need to be, though.
--Max
============================
FEDORA BOARD
+ Comes up with the high level goals for Fedora (like merging
core/extras, live cd, an external build system and compose tools, custom
spins). Talking about these things in public, saying with an
"authoritative" voice "this is what is most important for Fedora" at
least sets up the possibility for innovation in those areas to happen.
+ Make decisions that cannot be made at a lower level, and that bubble
all the way up to the top.
+ Manage other Fedora sub-projects and delegate. The Fedora Board is
not meant to be an engineering group. It's meant to be an overall
executive kind of group that handles the big picture issues, the legal
stuff, any topics that must remain private, etc.
The Fedora Board will be turning over some of its seats shortly. Chris
Blizzard and Bill Nottingham will remain in Red Hat appointed seats.
Seth Vidal will move from an "elected" seat to an "appointed" seat,
since he is starting full time at Red Hat. Karsten Wade has accepted a
Red Hat appointed seat. The fifth Red Hat appointed seat will be filled
after the elected seats are determined.
Matt Domsch is going to carry over in one of the elected seats. The
other three will be left open for election. The process around that
will be discussed separately.
http://fedoraproject.org/wiki/Board/History
http://fedoraproject.org/wiki/Board/SuccessionPlanning
Moving on to the next "decision making body" brings us to what was
previously the Fedora Extras Steering Committee and is now the Fedora
Engineering Steering Committee.
What has FESCO historically been very good at?
+ Representing the voice of non-RH Fedora contributors.
+ Building up and running Fedora Extras
- the "theory" of Fedora packaging (via packaging committee)
- the "practice" of Fedora packaging (the sponsor process, etc.)
- increasing the amount of software in the Fedora world.
Similarly, there was the "Fedora Core Cabal" which handled (not as
openly as was required):
+ A general release schedule for Core.
+ A feature list for a given release.
+ Release engineering-type stuff.
+ Release ready-ness.
These groups need to combine in the new Fedora world. They need to
combine in a way that ensures that discussions are all had in public,
but also in a way that can make sure that people who have expertise in
various areas listed above still have the ability to make sure those
parts of Fedora work well. For example, we're not going to create a
release engineering body that doesn't involve Jesse.
I propose a Fedora Engineering Steering Committee, that "reports" to the
Fedora Board and that "oversees" the following sub-groups
(1) Features, led by John Poelstra. This group tracks feature
development (from spec through code) for various things that we'd like
to have end up in Fedora at some point. They work with the schedule to
see where things might land, and also determine what features are
"critical" for a certain version of Fedora, and what features are able
to go in "when they are ready". This group, by necessity, will have to
interact with RHEL engineering management at times. The work this group
does should be on the Fedora wiki, and any meetings held with RHEL folks
should have their key points summarized back to the group at large.
(2) The Theory of Packaging. We have a packaging committee that works
great. It should keep doing its job.
(3) The Practice of Packaging. One of the responsibilities of the "old"
FESCO. It continues to be one of the most important things that we do
in Fedora. Keeping the process for getting new code into Fedora
repositories working, keeping sponsorship moving, getting new packages
built and into the repositories.
(4) Release Engineering, led by Jesse Keating.
(5) QA and release ready-ness, led by Will Woods.
I think that the community at large has the maturity to appoint certain
people to FESCO, and to elect others, in order to ensure that these
various groups are all getting the right people involved in them, and
working properly.
The Fedora Board is going to do a better job of asking FESCO for
updates, and will also try to not micromanage.
Things like the release schedule can work as follows:
The Fedora Board has said "we'd like to get as close to a Halloween/May
Day release cycle as possible."
The Features and Release Engineering teams can discuss a potential
schedule that comes close to that, and present it to the Board for an
ack. As changes are needed to that schedule, they too can be presented
to the Board for an ack.
The Fedora Board's overall job remains the same:
- have a general plan for a release's timeframe and big goals
- handle the brunt of Red Hat's internal complaints.
- manage FESCO/engineering parts of Fedora as needed
- be the point of contact for all other parts of Fedora that needs
to escalate issues upward.