Appointment of Board Members.

[Toshio Kuratomi]

On Mon, Aug 16, 2010 at 09:02:45PM -0400, Max Spevack wrote:
> On Mon, 16 Aug 2010, Toshio Kuratomi wrote:
> 
> > Poelcat was asking for examples where the Board interfered with things 
> > that were rightly in fesco's sphere of influence.
> 
> This got me thinking:
> 
> Let's forget the past for the moment, and worry about the present.  How 
> well articulated is FESCo's *current* spheres of influence?
> 
> http://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee
> 
> "FESCo handles the process of accepting new features, the acceptance of 
> new packaging sponsors, Special Interest Groups (SIGs) and SIG 
> Oversight, the packaging process, handling and enforcement of maintainer 
> issues and other technical matters related to the distribution and its 
> construction."
> 
> How good is this description?
> 
So... if we go with this... FESCo seems to fit poelcat's view that it's
middle management.  FESCo isn't expected to be innovative here.  They're
expected to take care that the routines of creating the distribution are
there and no wheels come off in the process.  So how good is that
description?  I don't know -- did the current FESCo members run for FESCo
with that understanding of what they were going to do?  Despite your
expectations, is that what you've ended up doing?

I know that I lobied for the Feature Process to be delegated rather than
handled directly by FESCo just before my term ended (way back when...) and
it seems like this could have been when FESCo became more about keeping
things rolling than making things new.... Now a days, the main coders for
our applications are in infrastructure, the dist-git rollout was handled by
releng (in particular, Jesse), the idea of what updates should go into the
distribution was decided by the Board and not fesco....

> Where do things like Infrastructure, QA, Release Engineering, etc. live 
> in our structure (I use that word purposefully rather than saying 
> "hierarchy")?
> 
Looking in on these, it seems like they live to the side.  Having been on
infrastructure, I think that Infrastructure always set itself up as a side
group.  We're everyone's servant but nobody's slave :-)  Other groups can
ask us to help them fulfill some need but we really don't get ordered to do
anything (except, perhaps, not talk about the Incident which came down from
the FPL so not a good indicator of where we stand wrt the Board or FESCo).

releng and qa seem to operate on the side as well.  Although the question of
whether that's the way that FESCo operates or if it's an actual fact,
I don't know.

> Is there a place where the leaders (either individuals or leadership 
> committees) of all those different technical sub-sections of Fedora are 
> able to coordinate and communicate?
> 
> Or is that what the release readiness meetings are used for?  If so, is 
> that sufficient?
> 
I don't think it's sufficient for running Fedora the Project but it may be
sufficient for creating Fedora the distribution.  I don't think that it's
sufficient for being innovative about where our distribution is going --
I think that we sort of use FUDCon for that but not consciously or well.
I think the FESCo meetings (in the pre-feature process-approval days) was
a place for this type of cross-project coordination to happen... but much
less so now.  Most of the innovation that's seen there is in the Features
and only reported at fesco, not discussed there.

> At the end of the year when FESCo members look at each other and say 
> "what kind of year did we have?" how is that answer determined?
> 
I think I've been too busy taking care of fires to have thought about
this.  Maybe we should make that an ice breaker at FUDCon hackfests -- Hi,
I'm Toshio and this year I think the most important achievement I worked on for
Fedora Infrastructure was: _____.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20100816/6d7d96db/attachment.bin