Re: Appointment of Board Members.

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

 



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
_______________________________________________
advisory-board mailing list
advisory-board@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/advisory-board

[Index of Archives]     [Fedora Users]     [Fedora Outreach]     [Fedora Desktop]     [Fedora KDE]     [KDE Users]     [Fedora SELinux]     [Yosemite Forum]     [Linux Audio Users]

  Powered by Linux