[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

governance, fesco, board, etc.

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.




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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]