On Tue, 2008-07-22 at 08:55 -0700, Luis Villa wrote: > On Tue, Jul 22, 2008 at 5:52 AM, Paul W. Frields <stickster@xxxxxxxxx> wrote: > > During the discussion following the Board election, the subject of term > > limits was raised. Generally those who commented on term limits thought > > they were a good idea, including several Board members. I've written up > > a proposal to amend the Board's succession plan with term limits, in the > > hopes that these limits would encourage continual but gentle change in > > the Board's elected membership over time. > > > > https://fedoraproject.org/wiki/User:Pfrields/Proposal_for_Board_Term_Limits > > > > Comments appreciated either here or in the discussion page for the > > proposal on the wiki. I'll bring this before the Board for final > > discussion and a vote at our August 5th session, which will likely be a > > public IRC meeting. > > This may well reflect my position as an entrenched incumbent ;) but a > little more explanation of what problem this solves would be good. > Incumbents may have a lot of valuable institutional memory, so making > them step away on a schedule might not be ideal. If you're concerned > about people overstaying their welcome and getting new blood on board, > it might be better to focus on how to get new blood involved and > increase the new blood's profile, and how to measure involvement of > incumbents (possibly privately) so that they get the message that they > are fading and ought to formalize that by fading out completely. > > You mention Notting's wisdom in this sense, which reminds me that > getting rid of institutional knowledge is particularly problematic > given the elected/appointed split- if this actually applies only to > elected members, you're automatically putting the elected members at > an institutional memory disadvantage relative to the appointed > members. The problem at hand was the perceived dominance by full-time Fedora people on the Board. People who spend their entire $DAYJOB as well as their spare time on Fedora are automatically very involved and visible. That can translate directly to votes on the basis of name recognition, which really disadvantages people who are very involved, but in a somewhat more limited fashion because they don't have the luxury of doing Fedora all day every day. (Maybe a similar advantage would go to someone unemployed, but let's not argue that for right now.) ;-) As a secondary note, the people who do spend their entire $DAYJOB on Fedora are extremely likely to be Red Hat folks. In an average election then, we generate the *perception* that Red Hat is still stacking the Board. The idea of term limits came up as a way to limit the effects of $DAYJOB on this process to some extent, while not shutting people from Red Hat out based on their $DAYJOB, either. I think the appointed seats do provide a sort of safe harbor for institutional knowledge in a way that a fully elected Board might not. Having said that, I like your thinking about making sure that incumbents are involved. I've been very much a proponent of getting people on the Board to pick up action items and push them to completion. Again, that should be independent of $DAYJOB -- people who are volunteer Board members are equally expected to carry some of this load by dint of their elected position. I'm not sure how to measure that directly other than through tracking of our agenda, maintaining a clear list of action items and the accountable parties for them, and setting deadlines for their completion. Those lists are provided to the community through this mailing list and elsewhere, so any contributor should feel free to hold members' feet to the fire as needed. I do believe that people who don't have the time or energy to see self-assignments through will generally gravitate away from the re-election process. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
