Appointment of Board Members.

Greg DeKoenigsberg greg.dekoenigsberg at gmail.com
Tue Aug 17 20:31:45 UTC 2010


Quite a thread -- and difficult to follow, so I'll just make up my own and
pretend it was in response to this one.  :)

1. Well-articulated, well-bounded responsibilities are good and conducive to
Getting Things Done.  The less well-articulated and the less well-bounded
people's responsibilities are, the more effort people expend in efforts to
clarify what, exactly, is going on.  I believe that's the largest cause of
the disagreements we're seeing now.

2. When working with big teams, this is even more important.  When you're a
lone gun making your own SIG, the responsibilities are in one head.  In an
Official Steering Committee, significant time needs to be spent figuring out
which direction people are marching in.  This is extremely important work.

3. When the "E" in FESCO stood for "Extras", the responsibilities were
crystal clear.  Get a build system together.  Get packaging policy
together.  Now that the "E" stands for "Engineering", there's higher
aspirations, but also more confusion.  I think it's imperative to return to
basics and figure out what FESCO's goals are -- and make sure that everyone
understands them.

4. Point 3. should be a collaboration between the Board and FESCO.  FESCO
should say "these are the things that we think we should own," and the Board
should say "yes, that's right" or "mostly yes, but not this one thing and
these other two things instead" or "no, your services are no longer needed
anymore, thank you."  Just spell it out.  And if, as I suspect, FESCO simply
has Too Much Going On, then it's up to FESCO to say to the Board "hey, you
know these two things?  We don't do those things anymore, sorry."  And it's
up to the Board to figure out other means of getting those things done -- or
not.

5. To expand on that last point: IMO, the Board should be in the business of
exactly three things.  One, articulating the aspirations of the project.
Two, building up (and perhaps tearing down) whatever governance structures
that allow project participants to understand and achieve those
aspirations.  If the current structures don't work, identify why and fix
them.  Three, walking like ship captains back and forth between those
structures to check their soundness.  Every other meeting should be with
members of a steering committee, checking on their progress, offering
counsel and resources and a friendly ear.  Be bold in these things.  That's
what a Board is for.   If we need a Feature Wrangler Steering Committee,
create one.  That's how we created the Extras committee, and the Docs
committee, and the Ambassadors committee -- by fiat, because the Board
decided that those things needed to be done.

6. I believe, increasingly, that we have erred on the side of Too Many
Elections.  The only elected positions should be on the Board (which should
be almost entirely elected, IMO, since Red Hat's nuclear option to throw
away the entire governance model at will is a sufficient hedge against
shenanigans, and the Board will usually end up with a plurality of
Redhatters anyway.  Besides, election fatigue sucks.)  I believe that the
other steering committees should consist of a Chair, appointed by the Board,
and then whomever else shows up at the meetings, all of whom have power just
by showing up.  If people must be "elected" to a Steering Committee title to
be motivated to do things, then I think the model is broken.  Everyone
should be empowered to do stuff for a committee.  Votes, when necessary,
should be among whomever shows up and is motivated to vote.  If the
committee chair doesn't want to run their committee by vote, so be it -- let
him or her run the committee as he or she sees fit, until the constituents
all run off in a huff and the Board cans the tone-deaf chair.

7. What is a committee chair, by the way?  It's not the person who does
everything.  Rather, it's a person who is organized, persistent, knows
enough about the subject at hand to ask the right questions, knows enough
about the people to push the right buttons, and is a servant to their
committee, not a master.  And when those people show up, everyone knows who
they are.

8. Make no mistake: the Fedora Board will never be able to decide how Red
Hat engineers spend their time if Red Hat Engineering management doesn't
agree.  So the Board should be spending most of their time (a) figuring out
how to align with what RHEng wants where it makes sense, and where
reasonable, cajoling RHEng into "doing the right thing", and (b) figuring
out how to accomplish things for Fedora that RHEng doesn't care much about
-- i.e. leading by example.  As has happened in the past.

9. Remember that these are good problems to have, and that you are, despite
your flaws, a model that the entire software world follows with great
interest.  Respect that.

All my $0.02us.  Good luck, y'all.  ;)

--g
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20100817/1802b2ca/attachment.html 


More information about the advisory-board mailing list