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

Re: governance, fesco, board, etc.

Max Spevack wrote:


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

I have a very primitive understanding of FESCo. Each time I try to understand it (asking on fedora-devel or searching the wiki) I have come up empty-handed. I'm not against FESCo, I simply do not understand what it is supposed to be or do.

The overall impression I got from reading this complete proposal was that FESCo is a layer of "middle-management". Naturally, I find that hard to believe considering the spirit Fedora :) I doubt this is the case so I think being more explicit about FESCo's job would be a good thing for those less familiar.

What FESCo is responsible for?

We need a complete section that states exactly what FESCo is responsible for and what it does on a weekly basis. Stating what FESCo has historically been good at and what the Core Cabal did still does not explicitly explain the responsibilities and authority of FESCo going forward.

The way it reads here is that FESCo's job is to oversee sub-groups. If that is its only responsibility, why don't the sub-groups report directly to the board and "cut out a level of management?" :)


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.

This is vague and more of a commentary on the community as opposed to a direct proposal.

1) What is the specific proposal about how members of FESCo will be elected?
2) All elected by the community?
3) Minimum or maximum number of Red Hat members?

The Fedora Board is going to do a better job of asking FESCO for updates, and will also try to not micromanage.

Why not have the sub-committees give status directly to the FAB? Why do they have to bubble up through FESCo?

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.

Who is actively (more than once a month at the FAB) tracking and reviewing the project's progress against the project's approved schedule? If there is no immediate answer I'm willing to volunteer.

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.

What does this mean and why is it listed here? It wouldn't make sense that non-Red Hat FAB members would answer to Red Hat about a complaint Red Hat had.

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

How about a parallel section to summarize the overall job of FESCo?

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