Hi All! Well, with the proposed Core and Extras merge ( http://www.fedoraproject.org/wiki/FedoraSummit/OpeningCore ) we need to adjust FESCo to the new world order quite soon probably. Here are my thoughts and a rough proposal how it could look like. Feedback much appreciated. BTW, I send some earlier thoughts to the FESCo-list and some people in private -- this proposal is a different one ;-) Note: I'll use FPCSC (Fedora Package Collection Steering Committee) as a phrase for the FESCo successor that will govern the merged Core and Extras repository. That should help to clarifying witch of the two is meant (yes, FPCSC is lame, but it was the best my mind came up with for now; Package Universe would work, too, but it seems some people don't like the term "universe" because it has a different meaning in another repo). Note2: FPCSC in the Fedora Project hierarchy is afaics located below the FPB on the same level as the Infrastructure Group or the Ambassadors. See also: https://www.redhat.com/archives/fedora-advisory-board/2006-November/msg00248.html == Constitution of FPCSC == FPCSC will needs to do what the "Core cabal" and FESCo do now and thus will have a lot more work to do than FESCo currently does. Thus it might be a good idea to make FPCSC a bit bigger. I'd say 14, 16 or 18 people (FESCo currently has 13 members). There were deliberations to assign quite a lot of seats (6-8) to special position instead of letting the contributors vote on the seats. This was discussed in a FESCo meeting (f13 took parts in that discussions; see http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20061122 for details) and most people seemed to disliked the idea. Thus most or all seats should be elected similar to how FESCo got elected (see http://www.fedoraproject.org/wiki/Extras/Policy/FESCoElections for details how a FESCo election is done). We just need to make sure that the community and Red Hat feel represented and heard, thus I propose following mix for FPCSC: * FPCSC consists of 16 seats; * the Chair has veto rights -- that means the particular decision or topic is transfered to the Fedora Project Board for further guidance and considerations * two seats are special for a representative from the Community Committee and a representative from Red Hat (see below for backgrounds of these groups); both have veto rights, too; this positions are not bound to special persons; it would be good if always the same persons from the committee's shows up, but if they are not able to they can send someone else from the committee as stand-in. * all the other seats are elected by the community once a year after a Fedora release * at least 50% of the seats need to be filled by community members. * the chair gets elected on the first meeting after a election * If there is deadlock in a voting the decision is either deferred and brought back up in the next meeting or it is presented to the FPB for further discussion/guidance. * if a member steps down FPCSC chooses someone else to fill the seat. The member can propose someone as his replacement and FPCSC will strongly consider the person proposed. * inactive members get thrown out (we sooner or later need to define how inactive looks in detail; not showing up in the meetings, not participating or following FPCSC work, ...) * FPCSC gets initially filled with the current FESCo members and some appointed people that look like good candidates. The first election of the voted seats will happen after the next release. == Create sub-committees/groups for special tasks == FPCSC will have a lot more to do after the merge. Thus it has to delegate the all the work somehow and should not have to look after each and every detail. Special groups with a committee that leads them rather should look into the details and mostly work out solutions own their own. FPCSC should more act as coordinator and guide the big decisions. The sub-committees should handle small decisions on its own without getting FPCSC involved. Medium sized decisions should be posted to the list to notify the community about them (once before they are ratified and once after that) and to FPCSC so the Committee can speak up if they really don't like something. Big decisions should explicitly be presented to FPCSC and get ACKed there. Only really big decisions should need direct FPCSC (or sometimes even FPB) involvement. Most of these groups should act similar to the scheme how the packaging committee or FESCo are working currently. Rough example: * a members or the committee or some random interested contributor works out a proposal to solve a particular issue. * he sends the proposal to a public mailing list for discussion * he participates in the discussion and integrates suggestions from the community that came up in that discussion * he presents the proposal to the responsible committee. * the committee then might suggest/request further changes (the committee members are strongly urged to raise their concerns directly in the public discussion!) and sooner or later should find a solution and ACK it * a report of the final decision gets send to the lists (and to FPCSC if its a medium sized decision) There are some subgroups that we need on a permanent basis: * release engendering * desktop group * kernel group * installer team * packaging committee * security team * testing/QA team * a community committee (as a second FESCo successor that should handle only the interests of the community to make sure it feels really represented) * a Red Hat committee (as a Core Cabal successor that's representing Red Hat interests) * even more? there are probably some that don't come to my mind just yet. It would be good is someone from each sub-committee/group steps up for the FPCSC election; we really want representatives from the most important groups/committees in FPCSC, but we can have them all, and people should be act smart enough to get elected. Besides those permanent groups there probably now and then will be special groups that exists only on a timely manner to solve a particular issue. Due to the position in the Fedora Project hierarchy FPCSC is able to delegate work to the subgroups to let them solve particular problems. The subgroups are normally strongly encouraged to * have at least one fourth of their members from the community/from Red Hat (exception: Red Hat/Community committees) * maintain a public schedule in the wiki (similar to the stuff FESCo or the Packaging Commitee do now) * the group has to meet regularly in the public and discusses things in public, too We further need to make sure that the sub-groups work well and have someone that is accountable for each sub-group. That is quite hard in a primarily volunteer driven organization -- it often only works if there is enough momentum, if someone that really is interested in the task or if he is payed for his work. Thus for the permanent groups it will often be the best if someone that gets payed for his work is accountable. = Quorum = We all have real life and often a lot to do at work, too, thus is hard to get 50.1% of the committee members together for each meeting to vote on a proposal. Some of the existing community groups and committees with a quorum of at least 50.1% have shown that and were quite slow due to that regulation sometimes. I'd like to avoid that for FPCSC and thus propose that to accept a proposal in FPCSC at least one third of the members vote with +1 if no one dislikes the proposal in the voting -- e.g. if only one members votes with "-1" on a proposal then at least 50,1% of the total members have to vote with +1 to overrule him *or* the decisions is deferred and brought up in the next meeting; then it's enough if 1/3 of the members vote with "+1". Note that there are considerations to set up a online voting system in the long term; then even those that can't make it to the meeting are able to vote on a proposal and participate. *Maybe* we'll also let the community vote on some particular issues, but that quite hard to realize if we want to make it right. = EOF = Comments? CU thl _______________________________________________ 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
