FESCO

[Toshio Kuratomi]

Thorsten Leemhuis wrote:
> I think it just happened without purpose; in fact I suppose
> it's likely that a lot of things might be similar if I would still be in
> FESCo(²), because FESCo has a whole lot more to do these days. Maybe to
> much, especially if you want to keep up with FESCo work as spare-time
> contributer.
> 
<nod>.  You touched on this with your note about the Feature Process as 
well.  One possibility is that FESCo should be delegating smooth running 
processes more.  In the features case, the Feature Policy is working 
pretty well for making features better but there's no reason to couple 
it so tightly to FESCo.  There's a procedure for getting a new feature 
into Fedora now so FESCo could delegate the review of Features to a 
subgroup.

However, see below for a larger, more general discussion.

[snip]

> And that is in fact the biggest problem *I* have with FESCo these days.
> FESCo afaics is mostly event driven these days (triggered by releases or
> people that poke FESCO to approve or do something); the contact
> to/interest in the contributers (and their option) was lost/got a lot worse.
> 
> In the Extras days it IMHO was different -- FESCo then of course had to
> do some things that were triggered by events as well, but a lot of time
> was spend in a "how to improve Extras to make it better for users and
> contributers to keep both groups happy (and make them even
> happier!)"-mode. For that we were in closer contact with the
> contributers (their number of course was smaller and thus it was also
> easier).
> 
I can't honestly say whether this was better in the Extras days (looking 
back on things is always subject to idealization) but it's definitely a 
worthwhile goal for the future.  So part of the question would be how do 
we reach that goal?  I know that many of the FESCo members are on IRC 
reading conversations of contributors all day everyday. Likewise with 
fedora-devel.  So problems that get mentioned there would nearly always 
be seen.  Is there a failure to push from IRC chatter to official FESCo 
business?  (I recall jwb, tibbs, and nirik, all bringing problems 
noticed through other channels to FESCo so I personally don't think this 
is the case.)  Is the problem getting issues to percolate from reports 
in bugzilla out to a more public venue?  (Perhaps this is something bug 
triage would like to take on?  Noticing a problem in 
Guidelines/unresponsive maintainers/etc and querying whether the issue 
should be mentioned on the mailinglist?)

Although that is all still event driven.  Perhaps the need is for more 
ideas to be started in FESCo?  Policies, features, new projects started 
by FESCo to make growth occur?  The only issue with that is that FESCo 
has limited manpower.  FESCo itself can't implement all the projects it 
could come up with.  Being event driven means that someone cares enough 
about the issue to work on it outside of FESCo.  But it does change the 
role of FESCo from "movers and shakers" to "arbitrators and judges".

So here's a question -- should FESCo embrace the arbitrators and judges 
role and we, the project, need to start implementing new outlets for 
people who want to actually do things?  (ie: Feature Process allows 
developers to get buyin for implementing global distro changes and 
provides a mechanism for developer work to be communicated to other 
people in the project who are affected by those changes.)

or

should FESCo concentrate on being the drivers of new changes?  Which 
means, being more involved with creating new policies, new subprojects, 
etc.  This, in turn, means that FESCo would be a much more active body, 
with less time for arbitration and judgement of current projects.  So it 
should be delegating those responsibilities out while it works on 
building new communities around new subprojects.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080426/b30a5ac7/attachment.sig>