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.
_______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
_______________________________________________ fedora-advisory-board-readonly mailing list fedora-advisory-board-readonly@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
