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

FESCo future

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

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:

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

 * 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

 * 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

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 =



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