how to govern and manage the new combined repository

Sun Jan 7 11:07:05 UTC 2007

Hi all!

Quoting Bill from:
https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00091.html

> What's left of the Core Steering Committee
> is going to work with the Fedora Board and FESCO to figure out just
> how this new combined repository is going to be governed and managed.

Yeah, that becomes more an more urgent afaics. The idea was raised to
sort this out in a special IRC-meeting and/or conference call with
people from the Core Cabal, FESCo and the Board.

That's probably a good idea, but that needs a bit of preparation, too.
Thus (and because a board members ask me to) I sat down and will roughly
outline my thoughts on the issue with this mail. I don't want to start
yet another endless discussion with this mail/proposal (I know, I'm good
with that, but I'm not proud of it) -- rather I'd like to see similar
mails/proposals from other people where they describe how this whole
thing should be governed. Then we can mix the best ideas into each
others scheme and then discuss one or two proposals further to find the
final one eventually.

Find attached a small image that roughly outlines how I think the
organization structure should look like. Description:

The Fedora Board sits on the top (hey, that was easy!). It's job is to
govern the Fedora as a whole; as such it has to coordinate the different
projects like Ambassadors, Infrastructure, the merged Core and Extras
repo and other sub-projects I just hinted in the drawing. The Board
should further set the big long-term strategies and thus has to decide
or at least ACK important things that the sub-projects worked out.

The Board should normally *not* have to handle technical decisions. That
IMHO should be the job of the FESCo/Core Cabal successor. We need a name
for it -- Jesse Suggested "FTC - Fedora Technical Commitee". I like that
in general and can live with it, but it's IMHO way to easily confused
with the Federal Trade Commission ( http://www.ftc.gov ). Maybe someone
else has a better idea. I'll nevertheless use the term now for the rest
of this mail.

The FTC will have a lot to do. Thus I think it should only work out the
really the big decisions -- the roadmap for example (such big things
would need a ACK from the Board). The other work should be handed over
to sub-groups, that are each responsible for parts of the whole picture
and report to the FTC periodically so it can coordinate the different
groups.

>From the top of my head and with help from Jesse (he told me about some
groups that currently exist internally at Fedora / Red Hat) I came up
with this rough list of groups we could have:

 * Packaging Guidelines Group -- The Packaging Committee (create the
guidelines for packaging and reviewing, but don't enforce those rules)

 * Packages/Repo Group -- a kind of FESCo successor that actually takes
care of maintaining the repo, reviewing new packages and enforcing what
the Packaging Committee decided. (¹); has sub-groups (missing in the
drawing) in the form of SIGs (special interest groups) that take care of
specific type of packages (games, python for example) or archs (PPC and
x86_64, ...)

 * QA -- wwoods and his recruits (also (¹))

 * Desktop

 * base OS (kernel, rpm, initscripts)

 * core tools (gcc, glibc, ...)

 * server software (apache, bind, samba, sendmail ...)

 * others like ET (emerging Technologies like xen and kvm), cluster
stuff, selinux, java, ... (needs to be discussed what we really need)

 * Release Team -- a kind of core cabal successor that create the
distributions spins. This group might need sub-groups again for each
spin in the long term:

  * GNOME

  * KDE

  * Server

  * more to come over time

Note: there are interdependencies between those groups sometimes
(Desktop Group and Gnome/KDE Spin; Server-Apps and Server Spin;
Packaging Guidelines and Packages/Repo Group, which itself need to
coordinate with the the Release Team), but that should be big problem
afaics. Sure, some people will say "that's way to complicated/to many
groups" -- but if you look closer you'll notice that all of those groups
(expect the FTC and those for the Distributions spins, witch are more a
long-term idea) exist in some form already today.

Each of those group should have its own Steering Committee with 3 to 10
people (7 normally). It should normally be a balanced mix of community
members and red hat employees -- especially the FTC (²). Having a
committee with mostly red hat employees is fine if those do all the
work. But even in that case the committees are strongly urged to make
sure the community feels heard, respected and integrated -- thus it
should have at least some community members and public meetings. The
desktop-group is probably an area where that did not work in the past
(see the recent discussions on fedora-devel).

In other words: "Fedora is a meritocracy" -- that should be valid for
the committees outlined, too. I'm not yet sure how to best make sure we
reach that goal when it comes to the constitution of those committees.
Maybe a mix of elected and appointed (the FTC could appoint them or the
groups could try to do it them selfs) members?

Further: The committee's should work similar to the scheme that's was
used by FESCo up to know. To be more precise: The committee's must meet
at least every two weeks (bigger groups weekly) in the public (IRC
normally); additional meetings in private (e.g. release engineers sit
down on a table or in the pub and work out how to plan the next big
thing) are acceptable, but the stuff that got decided should at least be
revisited once in the public. Community contributors must be able to
participate in the (bi-)weekly meetings, and all the important stuff
should also be discussed on the mailinglists, too, to give people that
can't or don't like to participate in the meetings have a chance to
influence the decisions to make sure they feel heard.

A schedule needs to be maintained in the wiki; the meeting planing and
the topics that will come up should be send out to a public mailing list
24 hours before the meeting. A summary has to be send to the list *and*
to the FTC after the meeting. The above rules are of course valid for
the FTC itself, too; it will collect the reports, discuss issues if
needed and will send a trimmed report to the Board.

Closing words: Yes, the things described in the last two paras (³) and
the organization structure is a bit more overhead then we had in the
past -- especially for red hat folks. But remember: that stuff gives the
community a chance to get involved -- and if we get the community
involved properly it will be in the end a better product for everyone
and less work for each of us as the load gets spread over more shoulders.

Thanks for reading.

CU
thl

(¹) -- FIXME -- the security team either needs to become a separate
group or gets under the hood of the Package/Repo Group or the QA group

(²) -- I'd prefer if we could have a defined 50% community and 50% red
hat mix for the FTC (at least in the beginning), as it will be a crucial
committee for the whole game. But it seems I'm the only one that want
something like this :-/

(³) -- We should probably sooner or later define a "how does a ideal
committee work" template, to avoid that each of the groups has to work
out the generic rules on its own. FESCo and it's structure in parts
should act as a starting point;
https://www.redhat.com/archives/fedora-advisory-board/2006-November/msg00258.html
has some ideas, too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fesco-successor.png
Type: image/png
Size: 25028 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20070107/bf6515cb/attachment.png 