Some thoughts regarding the FESCo and Board interaction

Thorsten Leemhuis fedora at
Wed May 2 15:11:07 UTC 2007

(sorry, long mail again :-/)


after yesterdays meeting I'd though it might be helpful for everyone to
outline some of my thoughts on the FESCo and Board interaction that lead
me to writing how it
looks like. It's not meant as a rant; mainly I hope this mail can help
making the ideas behind that document more clear so we can work on
something else that makes everyone happy (which seems to not be the case
with the current document).

= history view =

When the merge was purposed and the question "what to do with FESCo
then" came up for discussion it looked to *me* as some crucial people
from the RH side signaled "FESCo is important, because the community
feels represented by it and it works quite well in keeping Extras running".

When we designed the new FESCo it was explicitly (see archives) be
designed to be a successor of the old FESCo and the Core Cabal (and in
parts the Packaging Committee). I can't remember who brought the "Core
Cabal" into the game (and it doesn't matter much), but it seems to me
now that people have different expectations of what the Core Cabal
exactly did.

To me as a outsider the Core Cabal afaics was directly (getting it done)
or indirectly (it does not take care of each and every feature, but of
some) be responsible for getting a Fedora release in shape and released
every few months and keeping it maintained; e.g. create a Schedule,
discuss some of the Fedora-specific Features that are important for a
particular release, poke the right people to get the Features and
packages in shape right in time, publish test versions and a final now
and then; well that and a lot of other stuff that is needed to get a
distro out.

That's how I understood it -- which in parts seems to be wrong or
interpreted in a different ways by other people. Anyway I started
yelling when I noticed that those "former Core Cabal work" was not done
by FESCo during F7 development. Instead:

- some things got decided by the Board directly; those meetings have
been hold on phone meetings in the past where only the Board members
could join. Thus I as a outsider in parts got the feeling: there is a
new cabal; it has four community members now, but it's still a cabal
that is not much interested in other opinions as they discuss their
stuff behind closed doors. The Board meets on IRC these days, so this
point is in parts moot in between, but the Board afaics is still not
working as good and transparent as FESCo or the Packaging Committee when
it comes to getting those heard that are not part of the Board or in
crucial positions (see below).

- sometimes things were proposed to the list and discussed there without
an outcome; then it happened now and then that developers that were in
the best position simply did what they liked best without bothering to
ask the proper Committee for advice or a decision (e.g. FESCo) -- but
that's IMHo exactly what Committee's like FESCo IMHO are for: find a
solution when one can't be reached in public discussions. (an no, no
each and every detail need to be discussed; but if it got a public
discussion because it's likely important then it should also be a
decisions that should be done by a committee and not just my one
developer that's in a good position; the community members that
participated in those discussion otherwise might get the feeling "it's
not worth discussing if someone simply does what he like without
bothering what we tell him)

- if FESCo doesn't do what the Core Cabal (whatever it is) what will be
left for the new FESCo when the Board, Release-Engineering, EPEL, QA and
Package Committee act on their own? Nearly nothing afaics: FESCo would
mainly enforce what the Packaging Committee decided (even that might
fall under the hood of releng) and organize the package contributors. A
lot of other stuff like getting the repo in shape/rebuilded for a new
release would move to other groups like QA or RelEng.

That lead me to writing how it
looks like. But well, what I like to see can be found below; it can be
realized in a total different ways and I hope this mail is a step into
the direction to maybe find another way that fits other people needs better.

= what I'd like to see =

What I want is mainly this: A committee that is responsible for the
distro as a whole (creation, publishing, maintaining) and works similar
to how FESCo, the Packaging Committee or EPEL act: public meetings,
transparent decision process, a public schedule in the wiki, always
summaries from the meeting, meetings get announced in time with a list
of topics that are planed, community members propose topics to discuss
and take part of the decisions process, always give people that can't
join a meeting a chance to discuss stuff before it's finally getting
decided/realized, a balanced mix of RH and non-RH members so both
"camps" feel represented (until we are just "one camp" where nobody
cares where people work).  Stuff like that, so everyone inside or
outside of RH that is not part of the Committee that makes a decisions
has a chance to get heard to *influence* the decision *before* its made.
The Fedora Project Board does some of this these days, but doesn't do it
as good as FESCo or the other groups do or did (and even FESCo, EPEL or
the Packaging Committee have still room of improvements IMHO, too (at
least I had some thing on my agenda back when I was FESCO chair that
never got realized).

The committee should not only act like this, it should make sure that
sub-committees below it work in a similar way: RelEng, EPEL, Fedora
Packaging Group, QA, ...

The committee should be respected by RH developers and the Fedora
Contributors (Extras Packagers and other Contributors) outside of RH;
FESCo had a good (albeit not perfect) fame in the Fedora Extras
Packagers world, that's why keeping the name or the committee itself in
a strong position had/has some appeal. The Fedora Project Board on the
other hand is not that integrated in the Extras workflow; seems some a
lot of Fedora Extras Contributors people are either not on
fedora-advisory-board (it was invite only and maybe people missed the
change or they are still feel bad about it) or they simply do not care.

The committee should try to keep bureaucracy down, but on the other hand
avoid hallway conversations. It should do everything that's needed to
keep everyone inside or outside of RH aware of the ongoings and the
decisions that in the end might be relevant for the distribution we
create. That includes to announce a lot of stuff to mailing lists and
discuss it there; and, if no agreement can be found by those that are
involved in a discussion, let a committee decide. That overhead and
especially a lot more work for some RH developers, but that's crucial to
get the community properly involved IMHO so they feel respected and
represented. And: the better you get the community involved the bigger
the chances are that non-RH-people jump in to help out/get stuff done.

The committee also needs a to interact a lot with RHEL managers when it
comes to RH-interests like specific features or resale schedule. On the
other hand it should also give the community some stuff it would like to
see. Ask the Community which features it would like to see and pick some
(two or three maybe?) and assign a developer to drive them to realize
them together with the non-RH community (a key driver that has some
minutes for it each day often is helpful to get the community organized
and working productively); that should get people involved. With a bit
of luck the community wants something that has benefits for RHEL, too ;-)

Everything just my 2 cent.

Thorsten "knurd" Leemhuis

More information about the fedora-advisory-board mailing list